Subject: RE: SubjectAltName verification

From: Warwick Ford <[email-masked]>
Date: Thu, 18 May 2000 06:50:19 -0700

Steve:

A common example of a nonverified name, as mentioned by Denis, is an alias
which is deliberately not verified, sometimes because of privacy or
annonymity requirements.  There are also examples where a part of a name is
not verified at all. For example, when issuing a certificate to an
organizational system (server, even intermediate CA) it is not uncommon for
the CA to verify the organization name, but allow any name the organization
cares to ask for in the OU fields.  Also, as both Denis and I pointed out,
there are wide variations in the meaning of "verify", some of them being
arguably very weak. Where does one draw the line between very weak
verification and no verification?

I respectfully propose that, as in the past, we leave such issues as a
matter of policy, and expressly exclude judgements on them from the PKIX
standards.  I certainly do not believe that PKIX should be in the business
of "censuring" CAs over their policies.

Warwick

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 May 2000 17:57:21 -0400

Warwick,

>annonymity requirements.

I presume you mean pseudonym here, a rare case, but even here I think 
there is a consistent interpretation of my argument. Specifically, a 
pseudonym, appearing as a subject name or subject alt name must 
clearly be identified as such, else the CA is misrepresenting the 
information in these fields. One might reasonably require that such 
names be drawn from a name space that precludes easy confusion with 
"real" names.  I recall that we did just that in RFC 1422.

>There are also examples where a part of a name is
>cares to ask for in the OU fields.

An organization is authoritative for its internal naming, so it is 
fine for a CA to rely on an authorized rep for the organization to 
declare an OU in such cases. I'd say that the CA is doing its job by 
relying on an authorized RA in this case.

>Also, as both Denis and I pointed out,

Fair point.  I think its important that PKIX continue to express the 
notion that a CA is expected to perform verification (directly or 
indirectly) for all attributes in a cert, leaving to the policy 
and/or CPS to refine the level of verification performed.  As another 
WG member noted, it would seem that a major rationale for violating 
this rule is a desire to put too much into a single certificate.

The bigger security issue here is that we create new opportunities 
for vulnerabilities whenever we represent information that is not 
vouched for in a context where RPs ought to be able to rely on the 
accuracy of the information.  Anything one does that leads to easy 
confusion on the part of a user or system administrator is a 
contribution to the security failures that will inevitably result.

>of "censuring" CAs over their policies.

It is a pity that PKIX cannot effectively censure CAs :-).  Still, I 
do believe PKIX should continue to promote the notion, through our 
standards, that the contents of a certificate represent data that the 
issuer has verified and thus stands behind. To do otherwise would 
endorse behavior that creates confusion, a generally undesirable 
security characteristic.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 May 2000 10:53:54 +0200

Steve,

Let me extract two of your statements:

(snip) 

> Fair point.  

> I think its important that PKIX continue to express the
> and/or CPS to refine the level of verification performed.
  
(snip) 

> Still, I

The later statement is different from the former. I like the former. 
Can we build a consensus around it ?

If so, this should be reflected in the "son-of-RFC2459".

Denis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 May 2000 12:52:58 -0400

Denis,

>If so, this should be reflected in the "son-of-RFC2459".

The former is more appropriate for inclusion in the revised RFC;  the 
latter statement was more of a rationale for my position.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 24 May 2000 10:30:11 +0200

Steve,

Let us try now to agree on a text replacement. I have had some
private exchanges with Russ where I have proposed the following:

The current text is as follows:

   Because the subject alternative name is considered to be
   definitiviely bound to the public key, all parts of the subject
   alternative name MUST be verified by the CA.

Using a mixture of both texts, here *was* the proposal:

Because the subject alternative name is considered to be
definitiviely bound to the public key, the CA is expected
to perform verification (directly or indirectly) for all 
parts of the subject alternative name, leaving to the policy
and/or CPS to refine the level of verification performed.

In order to incorporate a "MUST", I would propose the following:

Because the subject alternative name is considered to be
definitiviely bound to the public key, the CA MUST
perform verification (directly or indirectly) for all 
parts of the subject alternative name, leaving to the policy
and/or CPS to refine the level of verification performed.

Can you agree on this ?

Denis

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 May 2000 11:05:24 -0400

Denis,

>and/or CPS to refine the level of verification performed.

I worry that we are unduly singling out this attribute, even though 
ALL the attributes have the same sort of requirement. How about:

"The subject alternative name, like all other fields in a certificate 
and all certificate extensions, is considered to be definitively 
bound to the public key. Thus the CA MUST verify (directly or 
indirectly) all subject alternative names. The precise nature of the 
verification is detailed in the certificate policy and/or the CPS."

Steve