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

From: Russ Housley <[email-masked]>
Date: Tue, 07 Mar 2017 19:10:50 -0000

Viktor:

[bottom posting]

> 
>> RFC 5280 says:
>> 
>> A name constraint for Internet mail addresses MAY specify a
>> particular mailbox, all addresses at a particular host, or all
>> mailboxes in a domain.  To indicate a particular mailbox, the
>> constraint is the complete mail address.  For example,
>> "[email-masked]" indicates the root mailbox on the host
>> "example.com".  To indicate all Internet mail addresses on a
>> particular host, the constraint is specified as the host name.  For
>> example, the constraint "example.com" is satisfied by any mail
>> address at the host "example.com".  To specify any address within a
>> domain, the constraint is specified with a leading period (as with
>> URIs).  For example, ".example.com" indicates all the Internet mail
>> addresses in the domain "example.com", but not Internet mail
>> addresses on the host "example.com”.
>> 
>> I think you are talking about constraints on addresses at a particular
>> host and constraints on mailboxes in a domain, but not constraints on a
>> particular mailbox.  Please correct me is I got that wrong.
> 
> Primarily, but not exclusively.  In the case that an issuer CA is
> constrainted to a specific rfc822Name, it should not be possible
> to evade that constraint by using the same (all-ASCII) address as
> an SmtpUtf8Name.
> 
>> I think you are suggesting that any A-label in the rfc822Name be converted
>> to a U-label, and the result is used to constrain the SmtpUtf8Name.
> 
> No.  I am *not* suggesting *any* conversions.  If a CA has rfc822Name
> constraints and no SmptUtf8Name constraints, and the rfc822Name
> constraints limit the CA to "example.com", ".example.com", or as
> you suggest above, a particular set of explicit rfc822Name addresses,
> my suggestion is that it MUST NOT be able to issue SmtpUtf8Name altnames
> that violate those constraints.  For example:
> 
> * CA is constrained to permitted subtree rfc822Name: example.com
> 	- can issue SmtpUtfName: [email-masked]
> 	- cannot issue SmtpUtf8Name: [email-masked]
> 
> In the current form of the draft both would be allowed, the second
> is a clear violation of the principle of least surprise (and the
> policy of the parent CA that created the name constraint).
> 
>> If people like your suggestion, then a constraint for a particular mailbox
>> will still require a SmtpUtf8Name, so I think the mechanism described in
>> the draft is needed.  It would just be used in combination with the above.
> 
> As to particular addresses, again:
> 
> 
> * CA is constrained to permitted subtree rfc822Name: [email-masked]
> 	- cannot SmtpUtfName: [email-masked]
> 	- cannot issue SmtpUtf8Name: [email-masked]
> 
> In the current form of the draft both would be allowed, in clear
> violation of the name constraint on the permitted email addresses.

Wei is arguing that the two (ffc822Name and SmtpMUtf8Name) should be completely separate.

You are arguing for some crossover, but I do not understand how A-labels in the rfc822Name are handled in your proposal.

If rfc822Name permits 'xn--fa-hia.de’ then it would need to be translated to 'faß.de’ for comparison in SmtpUtf8Name.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 7 Mar 2017 17:17:59 -0500

> On Feb 9, 2017, at 7:06 PM, Russ Housley <[email-masked]> wrote:
> 
> 
> You are arguing for some crossover,

I am not arguing for "some crossover", I am arguing to stop bypass attacks
when rfc822Name constraints are specified by a (legacy) CA, and SmtpUtf8Name
constraints are not.

Anything that prevents the creation of SmtpUt8Name entries that violate the
intent of the rfc822Name constraints is sufficient.  In particular, it is
not absolutely necessary to allow "faß.de" to be used via a name-constained
legacy certificate.  The most recently proposed compromise was to just ban
all SmtpUtf8Name altnames when rfc822Name constraints are set, with no
corresponding SmtpUtf8Name constraints.

> but I do not understand how A-labels in the rfc822Name are handled in your proposal.

No special treatment, just disallow bypass via use of unconstrained SmtpUtf8Name.

> If rfc822Name permits 'xn--fa-hia.de’ then it would need to be translated to 'faß.de’ for comparison in SmtpUtf8Name.

Simplest to avoid translation, and just deny.

-- 
	Viktor.