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

[Paul Hoffman / IMC <paulh@xxxxxxx>]

>The type of verification
>a CA does on a name is fundamentally different than what it does on an
>SMTP address, regardless of whether one is stronger than the other.

Quite right.

>If the CPS states that an entire attribute is verified, it seems
>inconsistent to have the two parts of a single attribute verified using
>separate procedures.

It doesn't seem inconsistent to me. Are you saying that if a CPS says "We
have verified the following two attributes: common name and email address",
you would find that inconsistent?

>  If the procedures are "equivalent" strength,
>there may not be a problem.

Ah, I think I see the problem. A CPS says what attributes it will vouch
for, and might say how the CA chooses to make this trust. These are two
different issues. An end entity MUST care about what is assured, and SHOULD
care about how that assurance comes about. However, if both the common name
and the email address are vouched for, it shouldn't matter if the common
name appears as part of the email address attribute, nor should it matter
if it doesn't. That is, the end entity takes the set of what is assured and
trusts that (and, hopefully, trusts only that).

The rfc822Name isn't the only type that will have the problem you see.
otherName and EDIPartyName will as well. These are all two-part names where
each part can be verified using very different methods. However, all three
can have the parts be equally assured because the CA trusts whoever
presented the credentials for the attribute. A CPS that says "we trust
these attributes because we know the person, and he wouldn't lie to us" is
a perfectly valid CPS, and one that most corporate CAs would issue.

I don't want PKIX to go down the slippery slope (into the slimy slop) of
saying how to verify the contents of the attributes. How would you "verify"
a uniformResourceIdentifier? An iPAddress? A dNSName? Requiring these be
"verified", as compared to "vouched for", is impossible and therefore
confusing to end users.

--Paul Hoffman, Director
--Internet Mail Consortium