Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

[Stephen Farrell <[e-mail]>]

Hi Russ, all,

So I've thought about this a bit and chatted with a few
folks, and I'm just not quite convinced that we've had
enough time or eyeballs to process the perfectly reasonable
looking (but significant) changes that were made during
and since the end of IETF LC by this Thursday's IESG
telechat. So I've taken this document off that agenda.

Apologies that that'll cause a bit more delay due to the
handover of ADs around IETF98 but I hope that that won't
be a bad delay.

I guess these LC changes are ones that it'd be good to go
over in Chicago as well, just to be sure that we've landed
in a good place.

Note that after Chicago, the new AD can re-inject the
document back into the process at IESG evaluation again
if that's the right thing to do, so this change does not
mean that a new IETF last call will be needed. Though of
course if there are further changes that might end up
being the right thing to do. In any case, for those who
like process minutiae, I've left this in the "waiting
for writeup" state but just taken it off this week's
agenda.

Cheers, and sorry again for being a cause of delay,
S.

On 13/03/17 15:14, Russ Housley wrote:
> It appears that autocorrect made a typo much worse.  I meant so say...
> 
> These changes were made in response to an IETF Last Call comment.  Please review them.  The vast bulk of the changes are in Section 6.  Please speak promptly if you think this is the wrong technical solution.
> 
> Russ
> 
>> From: Russ Housley [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Monday, March 13, 2017 10:45 AM
> To: SPASM
> Subject: Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
>  
> These changes were made in response to an IETF Last Call comment.  Please review them.  The vast bulk of the changes are in Section 6.  Please speak promptly if you think this is the word technical solution.
>  
> Russ
>  
>  
>  
> On Mar 12, 2017, at 5:40 PM, Wei Chuang <[e-mail] <mailto:[e-mail]>> wrote:
>  
> The latest draft 08 is up:
> https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dlamps-2Deai-2Daddresses-2D08&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=1MWONujUfB8F3GUGv6AW8UGwQuNDq0G3TEAGmYYij6I&s=bRu_sJbqhowJkrhC9p2CRMvk6nCfIJUndl7MrfSRMk0&e=>
>  
> The diff is:
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dlamps-2Deai-2Daddresses-2D08.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=1MWONujUfB8F3GUGv6AW8UGwQuNDq0G3TEAGmYYij6I&s=PKrOrXVJsbBO0wcBMB-rgIRT7iOO4OFjgtoR64Bf9Wg&e=>
>  
> This draft attempts to capture Viktor's name constraint verifier logic, and illustrate the examples in the diagrams.
>  
> -Wei
>  
>  
> On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang <[e-mail] <mailto:[e-mail]>> wrote:
> There seems to be a consensus here and internally to the changes that Viktor proposes.  We can put that in the next draft update.
>  
> -Wei
>  
> On Thu, Mar 9, 2017 at 1:34 AM, tom p. <[e-mail] <mailto:[e-mail]>> wrote:
> ----- Original Message -----
> From: "Viktor Dukhovni" <[e-mail] <mailto:[e-mail]>>
> To: <[e-mail] <mailto:[e-mail]>>; "IETF general list" <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, March 09, 2017 3:19 AM
>> On Mar 8, 2017, at 8:17 PM, Wei Chuang <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Okay.  I think the direction then is to have SmtpUTF8Name respect
> rfc822Name name constraints and vice versa.
> 
> Well, no, the simplest proposal on the table is for SmtpUTF8Name to
> be *prohibited* when rfc822Name constraints are present and SmtpUTF8Name
> constraints are not.  When both present, they can operate independently.
> 
> <tp>
> 
> Getting security right can be tricky as the legion of failed attempts
> that make it to RFC testify but what you are proposing here seems so
> simple, so obviously the right thing to do that I am puzzled, bewildered
> even, that anyone can disagree with you.
> 
> Tom Petch
> 
> The verifier logic is then:
> 
> 1. If neither rfc822Name constraints nor SmtpUTF8Name constraints
>            are present in any CA certificate in the chain, any mixture
> of
>            rfc822Name and SmtpUTF8Name SAN elements is valid.
> 
> 2. If some certificate in the chain contains *only* rfc822Name
>    constraints, then these apply to rfc822Name SAN elements, but
>    all SmtpUTF8Names are prohibited.
> 
> 3. When both types of constraints are present in all CA certificates
>            that have either type, then constraints for each SAN type are
>    exclusively based on just the corresponding constraint type.
> 
> 4. If some certificate in the chain contains only SmtpUTF8Name
>      constraints then those are unavoidably at risk of bypass via
>            rfc822Name SAN elements when processed by legacy verifiers.
>    Therefore, this should be avoided, and the CA needs to
>      publish rfc822Name constraints that prevent bypass.  Such
>    constraints *need not* be equivalent (not always possible)
>    to the desired SmtpUTF8Name constraints.  Rather, it suffices
>    to not permit rfc822Name elements that would be prohibited
>    if they were simply cut/pasted (with no A-label to U-label
>            conversions) as SmtpUTF8Name elements.  It is not necessary
>    for these to permit everything that SmtpUTF8Name permits.
> 
> Thus for example, if SmtpUtf8Name only permits addresses in the non
> NR-LDH
> domain "духовный.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__xn-2D-2Db1adqpd3ao5c.org_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=1MWONujUfB8F3GUGv6AW8UGwQuNDq0G3TEAGmYYij6I&s=Oe17K7ooNPBDUmFvzu-ND8age2YROKJisOoK3yEMDGE&e=>" (or a specific set of addresses in such a domain),
> then the corresponding rfc822Name constraint could just permit "." (or
> the
> reserved "invalid" TLD if that's preferable) which is not a usable email
> domain.  This ensures that only the permitted SmtpUTF8Name SANs are used
> and no rfc822Name SANs are used.
> 
> If, instead the Smtp8Name constraints are excluded non-ASCII address
> forms,
> then since these have no literal rfc822Name equivalents, the rfc822Name
> constraints can be omitted with the same effect.
> 
> Only when the intention is to permit NR-LDH domains with either ASCII or
> UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and
> SmtpUTF8Name constraints need to be fully equivalent.  This is of course
> trivial to do.  Just cut/paste the same string into both types of
> constraint.
> 
> --
> Viktor.
> 
> 
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>