Viktor: 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, "root@xxxxxxxxxxx" 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. 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. 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. Russ On Feb 9, 2017, at 12:57 PM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > [ Sorry about the duplicate post, Somehow the original body got > "Content-Disposition: attachment", reposting as "inline". ] > > On Thu, Feb 09, 2017 at 09:34:27AM -0800, Wei Chuang wrote: > >>>> The draft says the rfc822Name and SmtpUtf8Name >>>> name constraints are applied separately, and don't affect other results >>>> (see section 6). >>> >>> Yes, that's what I'm objecting to. This is a design error in the >>> draft. The namespaces are *not* separate, and orthogonal constraints >>> are not desirable. >> >> You are stretching the language used above. They are "applied separately". > > Separate application is not sufficient when the issuer's certificate > contains only rfc822Name constraints. > >> I think we're open to changing how name constraints are applied. But its >> worth spelling out the design concern clearly before going down that path. >> The concern is that as we add a new representation for international email >> address that we are seeing that combinatorial increase in comparisons >> needed for name constraints. > > My proposal creates no combinatorial increase of any kind. When > the issuer CA has *only* rfc822Name constraints, any SmtpUtf8Name > subjectAltNames in the certificate, instead of getting a free ride, > would have to satisfy the rfc822Name constraints. Each rfc822Name > constraint becomes (under the identity function) a valid SmtpUtf8 > constraint. > >> This design chooses to simplify that by keeping rfc822Name name >> constraint behavior and separately defining a new SmtpUtf8Name name >> constraint behavior that works only on SmtpUtf8Name names. > > Yes, buts this evades rfc822Name constraints created SmtpUtf8-agnostic > parent issuers. The namespaces are not disjoint. > >> That simplifies >> the work of the path verifier and eliminates potential domain (A/U label) >> conversions between the alternate forms. Work is now shifted to the issuer >> which must explicitly define SmtpUtf8Name name constraint. > > The simplest thing for the verifier is to do no checks at all. > Presumably we make things as simple as possible, but no simpler. > The security requirements should be to correctly process existing > name constraints. And I don't believe that *any* conversions are > required to do this. > > Specifically, rfc822Name constraints that include a non-empty list > of permitted subtrees, in the absence of explicit SmtpUtf8Name > constraints would imply that the CA cannot issue *any* email altnames > for a non-ASCII domain. If the domain is all-ASCII, no conversions > are required. If the rfc822Name constraints have only excluded > subtrees, then no non-ASCII domain is excluded. > >>> The issuer may be SmtpUtf8 aware, but the parent CA that sets the >>> issuer's constraints (possibly some time ago in the past) may not. >>> The issuer should not be able to evade name constraints. >> >> Assuming we keep the current name constraint design, we can add a >> requirement that name constraints on email addresses has to be consistently >> applied on the certificate issuance path. In other words, an issuer with >> only rfc822Name name constraints in its path can only issue rfc822Name >> subAltName email addresses. > > No that's too limiting. If the issuer is permitted to issue altnames > for "example.org", it should be able to issue "виктор@example.org". > > -- > Viktor. >