Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions

[Paul Hoffman / IMC <paulh@xxxxxxx>]

>I'd like to suggest that we not allow all of these representations of RFC
>822 names, despite your obeservation that they are all syntactically
>allowed under RFC 822.  My reasoning is that we ought to not confuse the
>bounds of what is being certified.  As a CA, I can readily validate a pure
>user_name@FQDN syntax, but when someone includes a parenthetical comment,
>it makes the verification harder and subject to errors.

I completely disagree. The RFC 822 syntax is absolutely clear that the
other stuff is a comment with no relation to the deliverability of the
address. It doesn't make "the verification harder and subject to errors":
it is *never verified* because it can't be.

>  A user seeing such
>a name is likely to pay more attention to a more human-readable part of the
>name, which may not be verified, while software is almost certain to pay
>attention to the more tightly constrained synatx that actually supports
>addressing of the message.

Possibly true. However, a user might also believe that the bare email
address is valid because the cert is value, when in fact the address was
only valid for the five minutes in which the CA checked it. Or the user
might believe that "joe@ibm.com" means Joe is associated with IBM, even
though he is no longer. And so on and so on. This is a user interface
issue, not a reliability issue. And you'll have the same issue with many
kinds of otherNames, uniformResourceIdentifiers, and iPAddresses (for IPv6).

>  Thus a mismatch may occur if a secure e-mail
>package or IPsec implementation validates based on the more restricted
>syntax, but the user thinks in terms of the comment part of the name.

Well, they shouldn't do that, should they? A comment in the draft would fix
that.

You are making the field less friendly for fear of confusing people, but
there are lots of room for other confusions in DirectoryString. I'd say
leave it as it is and put a note in the text saying "nothing other than
the address portion of the name can be verified based on the definition in
RFC 822" and leave it at that.

--Paul Hoffman, Director
--Internet Mail Consortium