[UA-discuss] OpenSSL, was Where should IDN translation happen?

[Michael Casadevall]

On 11/15/18 3:29 AM, Dmitry Belyavsky wrote:
> Dear John, 
> 
> On Wed, Nov 14, 2018 at 7:59 PM Dmitry Belyavsky <beldmit at gmail.com
> <mailto:beldmit at 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 at openssl.org <mailto:openssl-project at 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).

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.

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.

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.

 - 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.

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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2468 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20181115/5ca2304c/pEpkey.asc>