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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
From: "Viktor Dukhovni" <ietf-dane@xxxxxxxxxxxx>
To: <spasm@xxxxxxxx>; "IETF general list" <ietf@xxxxxxxx>
Sent: Thursday, March 09, 2017 3:19 AM
> On Mar 8, 2017, at 8:17 PM, Wei Chuang <weihaw@xxxxxxxxxx> 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" (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.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]