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