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(_at_)example(_dot_)com" 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(_at_)dukhovni(_dot_)org> 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.