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