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.