Subject: RE: SubjectAltName verification

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Jun 2000 19:16:09 -0400

Peter,

>Denis,
>
>The mandatory operational policy element
>that was advocated by one co-chair based
>off of your suggestion is potentially
>very damaging to the current Internet PKI,
>as we who built what individual users can
>use, know it.  Please reconsider your text, given
>how others may apply it, carefully.

The claim that this text would be "{very damaging to the current 
Internet PKI" is an overstatement, at best.  See below for details.

>
>Based on Al's and Steve's replies
>to my deliberately contentious policy
>scenario, we can now apply the interpretive
>principles established as community standards. That
>exercise showed clearly that naming verification
>policy is not only now mandatory on PKIX CAs, but
>which policies are conforming is determined by PKIX.
>The conformance testing procedure is unspecified
>in the text, but none the less it evidently
>exists - as a subjective process.

I think most people have an informal understanding of what it means 
to verify information in a cert, even allowing for latitude in a CA's 
policy on the extent and nature of the verification.  I agree that we 
can debate the details of this forever, especially considering past 
experience with analogous topics on this list.

>
>Lets apply
>the principles to VeriSign's branded services, to
>see the ramifications.
>
>Some or all of VeriSign's Class 1 offering
>of its Public Certification Service(s) is/are
>apparently no longer PKIX-conforming, if one applies
>the conformance principles now proposed by Steve. It
>was conforming, last week. (A "national"
>ie governmental CA service to residents also suddenly
>became non-conforming last week, also, because
>of other subtle tweaks)

VeriSign Class 1 certs have been non-conforming in several respects 
in the past, e.g., the insertion of e-mail addresses into CN 
attributes.  Maybe this, and other practices have ceased; I don't 
know.  Are you seriously saying that that Class 1 certs from VeriSign 
would be completely PKIX compliant if only we paid not attention to 
the procedures used to verify the accuracy of their contents?  Maybe. 
But, if so, what are they worth (vs. what do they cost)?

>
>Goto a formal certificate repository
>https://digitalid.verisign.com/services/client/index.html
>and perform the instructions. Type in
>[email-masked], and see (apparently)
>that a certificate is recorded, with "pending"
>status. The common name is "No Such Agency"
>and an unverified email address exists
>in the name form selected by VeriSign.

That sounds like a good example of what one would NOT want in a 
certificate.  Are you sure you're arguing against my position :-)? 
Still, you seem to have jumped to a conclusion, based on just this 
example.

>
>To be fair to VeriSign, I have not completed
>all procedures. To complete, someone
>must send a challenge-response pin sent
>to [email-masked] to VeriSign to
>verify that such email account-name exists.
>(This is apparently a non-conforming
>verification event.)

Says who?  The point I, and several others are trying to make, is 
that it is negligent for a CA to include data in a cert without 
making some effort to verify that data, either directly or via some 
RA(s).  Also, if sending the challenge to the e-mail address does not 
complete the registration procedure, but rather the recipient must 
respond, then that does represent some effort at verification.  It's 
not perfect, but it is a credible effort for a low assurance 
certificate, IF the Subject name or Subject alt name is an e-mail 
address.  If it's some pseudo DN, then NO, this does not count as 
verification.

>The resulting  certificate binds one legally
>to certain digital signatures, according
>to the governing policy.

Personally I'm not comfortable with that, because the level of 
verification is pretty low, but that's just my opinion, and it's one 
reason I'm not a VeriSign Class 1 certificate holder.  (Another 
reason is that it doesn't seem to be a very useful thing to have, 
i.e., I don't seem to have much use for one of those certs, 
personally.)

>
>VeriSign PCS's Class 1 Service is apparently
>(suddenly) no longer conforming with PKIX, under
>any interpretion of the new mandatory
>policy language concerning name field
>verification
>
>This seems an excessive impact of your
>suggestion. I, as one of its co-designers, would
>like to include VeriSign PCS's current Class 1
>offering within the PKIX family of conforming CAs.

There may be other reasons that it is non-conforming, e.g., other 
attributes for which VeriSign makes no effort to verify the data, but 
what you cited above would not rule it out based on the proposed text 
(if the other constraints I cited above were not violated).

Steve