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

[Paul Hoffman / IMC <paulh@xxxxxxx>]

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

Quite right. I agree with the "allow non-verified data" camp as long as we
put lots of words in the document about what things we know can't be
verified, then let CAs decide what to do with it. It seems like
over-regulation to say "we know better what you shouldn't put into a cert,
so we're going to prohibit it even though you might have done it well." The
comment in RFC 822 names is a very good example of this.

Since the mailing list archive has a huge hole in it, I don't know if this
debate was ever resolved for PKIX.

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

Right.

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

It isn't for me. How do you know how well the CA verified the 822 address?
Did they send mail to it and get it back? Did they just do a VRFY on it?
Did they ever check it again? At what intervals? Did they check with the
Postmaster at the site to make sure the address was known to her/him and
not a hacker who got a temporary account by fraud? All of these things are
determined by reading the CA's policy before trusting them. Whether or not
they verified the comment part of the name is just one more thing on the
list of things that the CA tells you they verified.

--Paul Hoffman, Director
--Internet Mail Consortium