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

[Stephen Kent <kent@xxxxxxx>]

Paul,

>>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.

If we agree that this comment data ought not be verified, then the argument
is really over the inclusion of non-verified data in certs, which is a long
standing debate in this community.  Deliverability is not the issue here,
but rather the opportunity for users to be mislead.

>>  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).

This is a user interface issue, but it is also a security issue and this is
a security standard.  The user ID in a cert is of greatest concern to me
because of its likely extensive use in secure e-mail, where user's will
often make value judgements, vs. IP addresses and DNS names being processed
by software in IPsec.

>>  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.

We cannot standardize user behavior, but we can avoid obvious pitfalls that
users might encounter.

>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.

Not sure where "DirectoryString" enters into our discussion.  It seems that
there is a catch 22 here:  you seem to be saying that it's OK to not verify
this data as a CA, but then suggest that it is important to include because
of it's user friendliness.  This suggests that the latter quality is
important for user comsumption, but that user consumption of unverified
data from what purports to be a secure form of identiofication is OK in
this context.  That's hard for me to accept.

Steve