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

[Wei Chuang <[e-mail]>]

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]> wrote:

> ----- Original Message -----
> From: "Viktor Dukhovni" <[e-mail]>
> To: <[e-mail]>; "IETF general list" <[e-mail]>
> Sent: Thursday, March 09, 2017 3:19 AM
> > On Mar 8, 2017, at 8:17 PM, Wei Chuang <[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 <http://xn--b1adqpd3ao5c.org>" (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.
>
>