I suggest leaving aside the delivery and corresponding verification of addresses by MTA.
Please correct me if I am wrong.
On 11/15/18 3:29 AM, Dmitry Belyavsky wrote:
> Dear John,
>
> On Wed, Nov 14, 2018 at 7:59 PM Dmitry Belyavsky <beldmit@gmail.com
> <mailto:beldmit@gmail.com>> wrote:
>
> I've got a response from Victor Dukhovni. His position is:
>
> 1. It's better to ask OpenSSL about their plans :) via
> openssl-project@openssl.org <mailto:openssl-project@openssl.org>
> 2. (Limiting scope to EAI certificates) OpenSSL must trust the CA software
> that has provided punycode representation of the domain name. So we can
> decode
> A-labels and compare them. So the certificate itself can be verified,
> and questions
> whether the EAI address matches the address in From: header is out of
> scope of the
> certificate validation process.
>
That doesn't sound right at all ...
RFC 7508 (https://tools.ietf.org/html/rfc7508) specifically handles how
the email headers are protected by S/MIME verification (and OpenSSL
specifically supports embedding these headers with their own command
line tool).
I did not find this special handling, at least by 'grep -ri SecureHeader'.
Either I did not find it in man cms/man smime.
RFC 8398 (https://tools.ietf.org/html/rfc8398) specifically lists out
the cases of where either an A-label or U-label go in the certificate;
it's complicated but basically depending on the LDR component, it can be
an A-Label or U-Label.
Depressingly, it doesnt look like OpenSSL supports SmtpUTF8Mailbox at
all (or at least I can't find it with a grep). As to how this all works,
Dmitry, here's my understanding.
Sure. I do not know about other implementors of RFC 8398 except me.
And my implementation is very limited too.
The short version here is that the From: and To: field is specifically
set by the user, and is used in SMTP specifically as the MAIL FROM and
RCPT TO commands. These could be A or U labels as they're user entered.
Both should generally support UTF-8, is used for bounced emails (which
can be S/MIME signed if the MTA supports it). Because of this, the
From/To field should always be U-Labels, and the MIME fields be those
resulting U-Labels; they shouldn't ever be converted to A-Labels directly*
I haven't gone through the RFCs to make sure of this, but this is what I
recall off the top off my head. For a EAI-to-EAI email the following
steps need to happen
- MUA sets From and To fields as U-labels
- MUA to sends email to their outbound SMTP server
- The SMTP server breaks the email into the user part and the domain
part, the domain part is converted to an A-label
- If DANE is being used, the outbound server checks TLSA records after
STARTTLS
- IDN translation happens if necessary, standard SMTP processing
happens here. MX records are downloaded, checks against DKIM/SPF run
against the A-label of the From field address
- Receiving SMTP server gets MAIL FROM/RCPT TO in U-Label form
- Mail is delivered.
This seems to be out of scope of the OpenSSL toolkit but in scope of the MTA in whole.
S/MIME adds the following additional steps:
- When an email is sent, *before* it is submitted to the SMTP server,
MIME headers are duplicated, and signed within the message body. This
prevents the headers from being tampered with in such a way that they're
undetectable. The email (with headers) is signed with the receiver's
public key.
Do you mean signing with the sender's public key or encrypting with the receiver's public key?
- When the email is received, the email is decrypted, and the From
field is matched to the CN/SAN fields in the S/MIME certificate to know
which public key to load/verify. If this mismatches, the email gets a
broken lock.
There may be more than one reason to get a broken lock icon.
1. The trust chain cannot be established. RFC 8398 provides extra cases when it happens.
But there we can refer only on CA software that provides A-labels and U-labels in nameConstraints
and SAN. I do not think that it's a good idea to correct CA behaviour in OpenSSL.
2. The chain of trust is established, but the certificate used for signing does not match the From: address.
This can happen in case of bad EAI representation either in the certificate or in MTA/MUA of sender.
I think that MUA are a legitimate place to ensure IDNA2008-compliance here.
3. Everything is OK on stages 1-2, but the signature is broken.
Nothing seem to depend on EAI here, because the signature depends on data, not on its semantics.
It seem to be verified on the OpenSSL level too.
For verification to work as the OpenSSL guys say, verification would
fail because the From label would be a U-label, and the cert would have
an A-label. From where I'm sitting, validation should pass if the From
field is punycoded for compatibility with old/broken MUAs/MTAs as long
as it comes out to the right thing and the cert should always what spec
says.
As I wrote before, there are at least 3 possible way to fail the verification.
If I got anything wrong from the RFCs, corrections welcome, but this is
how I understand how it should work but I could very easily gotten the
finer points wrong.
Michael
* - an exception exists for Forwarded-By/Path headers amended by SMTP
which could reasonably put an A label in to allow emails to pass through
non EAI-aware SMTP servers; that should work as long as the starting and
end point are both EAI aware.