ietf
[Top] [All Lists]

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

2017-02-11 12:42:51
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,
"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.

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: виктор@example.com
      - cannot issue SmtpUtf8Name: виктор@example.net

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: 
viktor(_at_)example(_dot_)com
      - cannot SmtpUtfName: виктор@example.com
      - cannot issue SmtpUtf8Name: виктор@example.net

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


<Prev in Thread] Current Thread [Next in Thread>