Subject: RE: SubjectAltName verification

From: Warwick Ford <[email-masked]>
Date: Wed, 17 May 2000 15:39:43 -0700

The meaning of "verify" (in this context) is entirely a matter of policy,
and needs to be made clear in the CP/CPS wrt all fields of material
significance.  Re our long-ago discussion on "non-verified subscriber
information", I recall us agreeing that a certificate *may* (subject to
policy) contain non-verified subscriber information.  However, because
"verification" means different things for different fields, a binary flag
was not the answer.  The extent to which different fields are verified (or
not) by a CA is expressed in the CP/CPS. 

I believe this interpretation extends to subjectAltName since different
alternatives will unquestionably be "verified" in different ways.

Warwick

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, May 15, 2000 9:46 PM
To: Robert Moskowitz
Cc: [email-masked]
Subject: RE: SubjectAltName verification

Bob,

The underlying assumption is that the CA is vouching for the accuracy 
of ALL data in a certificate.  A syntax check is NOT what one would 
expect. yes, the CPS may hedge on how good a check the CA does, but 
there IS a presumption that the CA has made some effort to verify the 
info.  We long ago debated this issue; some folks wanted to have a 
flag for a CA to set to indicate the presence of non-verified data. 
We rejected that approach.

Steve

---

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

Warwick,

>alternatives will unquestionably be "verified" in different ways.

We disagree wrt inclusion of non-verified info, and the consensus of 
the WG in this regard.  I agree that a CA policy may declare that a 
CA has chosen to do this, but I believe that such behavior warrants 
censure.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 18 May 2000 08:53:08 +0200

Hum !!! Interesting discussion between the two co-chairs.  :-)

Whatever information is contained in a certificate, there are
various degrees of verification that can apply. The verification
level may even be different for each field. To this respect, Warwick
is right to say that a flag would not be adequate.

A certificate must contain a name that may be carried in the DN
field or the SubjectAltName extension. That name must be unique and
is assigned by the CA. The name, wherever it is placed, must be
verified (well with the exception of pseudonyms that can only be
verified not to collide) with some *reasonable* degree of
verification.

All other extra fields related to the user that we allow to be
present in a certificate are not mandated. If a phone number is
included does that means that the CA has simply accepted the phone
number that was included in the registration form ? or that the CA
has requested a proof from a telephone company that the applicant
was the legitimate subscriber of the phone line ? or that the CA has
made a phone call to that number to get the person on the phone ? 

The answer to the issue raised is not black or white. Today there
exists (free) certificates where no verification (except uniqueness
of name) is performed. There are used for testing purposes, and
should be recognized as such (but they are not). A next level is to
verify very loosely the name, in particular when it is an E-mail
address, by sending back an E-mail to that address. A next level is
to use some background check with a data base to make sure of the
information that is provided. A next level is to ask for one proof
of identity and other related information. A next level is to ask
for two proofs of identity and other related information. I will
stop here these examples.

The industry has introduced the concept of classes of certificates.
The problem is that each CA issuer has made its own definition of
what such a class is. 

Maybe it is now the right time to raise the question whether we
should standardize the concept of classes of certificates. 

In this way we would recognize various levels of verification. We
would also need to say how the express the concept of class in the
certificate. We do not necessarily need a new extension for this.
Let us keep certificates slim.  :-).

Denis

---

From: Al Arsenault <[email-masked]>
Date: Thu, 18 May 2000 08:28:24 -0400

> Hum !!! Interesting discussion between the two co-chairs.  :-)

I agree with Steve on this one.

> made a phone call to that number to get the person on the phone ?

In general, if the CA is not also the RA, the CA accepts the RA's
assertion that the RA is either authoritative for all information to go
in the certificate, or that the RA has verified the information with
whomever is authoritative.  That is, the RA has certified that "this is
Al's e-mail address, because I issued it", and "this is Al's phone
number, which I ran around to his desk and verified or called the
company phone office to verify or ..."  If the CA is also acting as the
RA, then it is the CA's job to do this verification.

Of course, how well this job is done is a function of the CPS (or other
policy document which serves in place of the CPS, as I was reminded at a
meeting yesterday :-), but it needs to be done.  Giving me a certificate
with a subjectAltName, OtherName type, of Phone_number =
the_White_House_switchboard is somewhat irresponsible on the part of the
CA, and should not be condoned by PKIX.

> should standardize the concept of classes of certificates.

For PKIX, I would vote "NO" to this question. Maybe the PKI Forum or
somebody else should pick it up.
 
> Let us keep certificates slim.  :-).

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.

---

From: Paul Koning <[email-masked]>
Date: Thu, 18 May 2000 09:52:03 -0400 (EDT)

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Warwick,
 >> The meaning of "verify" (in this context) is entirely a matter of
 >> policy, and needs to be made clear in the CP/CPS wrt all fields of
 >> material significance.  Re our long-ago discussion on
 >> "non-verified subscriber information", I recall us agreeing that a
 >> certificate *may* (subject to policy) contain non-verified
 >> subscriber information.  However, because "verification" means
 >> different things for different fields, a binary flag was not the
 >> answer.  The extent to which different fields are verified (or
 >> I believe this interpretation extends to subjectAltName since
 >> different alternatives will unquestionably be "verified" in
 >> different ways.

 Stephen> We disagree wrt inclusion of non-verified info, and the
 Stephen> consensus of the WG in this regard.  I agree that a CA
 Stephen> policy may declare that a CA has chosen to do this, but I
 Stephen> believe that such behavior warrants censure.

I'm inclined to agree.

If Warwick's interpretation is to be adopted, then the text urgently
needs to be repaired so it does not mislead.  The current text (i.e.,
its intuitive meaning in plain English) supports Steve's
interpretation and not Warwick's.  If the other interpretation is
intended, then the text needs to say so quite explicitly.  For
example, with words like this:

 "Whether the subjectAltName or any other field of the certificate has
 been verified by the CA is a matter of policy and can be ascertained
 only by examination of the CPS.  If a RP needs to know that a
 particular attribute is definitively bound to the public key of the
 subject, it must examine the CPS to learn whether the CA has indeed
 verified this binding."

It would be possible to take a middle ground between the two
positions, i.e., encouraging the definitive binding but not requiring
it.  That of course means changing the "MUST" to a "SHOULD" and
perhaps adding words to the effect that the CPS must indicate what is
done. 

Personally, I prefer Steve's position.  I wonder if it is necessary to
add words to the effect that a conforming CA cannot use the CPS to get
out of supporting mandatory items in the RFC and still be considered
conforming.  After all, that's we're talking about right now.  It
really shouldn't be, after all that's why we use standardized
terminology (like "MUST").

	     paul

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 18 May 2000 15:46:34 +0200

Al,

There was indeed two open questions (one explicit, one implicit).
You answered to the first one, and I agree that some "other" body
might be more appropriate to start the work and, maybe, when they
are done, they should present their work to us.

The second question is our concern. I said : "We would also need to
say how to express the concept of class in the certificate." 

So the question is: Should we say how/where to express the concept
of class in a certificate (in particular an end-user certificate) ?

Maybe we already have the right field and the right syntax to
accommodate the information, but we would need to extend/modify some
rules.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 18 May 2000 18:00:58 +0200

Paul,

I like your proposal in general.  ... However, I would reword it a
litlle bit differently, changing "whether" by "how" in two places. 
The other concern I have is that your proposed text mentions "THE
CPS". This is assuming ONE CP, which is the RECOMMENDATION we
presently have in RFC 2459. I raised the question whether we should
relax this a little bit, to be able to include some "well known"
OIDs which would state how the verification of the registration
information has been performed.

>  subject, it must examine the CPS to learn whether the CA has indeed

 "How the subjectAltName or any other field of the certificate has
 been verified by the CA is a matter of policy and can be
ascertained
 only by the knowledge of the CP(s) or by examination of the
CPS(s).  
 If a RP needs to know how a particular attribute is bound to the 
 public key of the subject, it must now have the knowledge of the 
 CP(s) or examine the CPS(s) to learn how the CA has indeed verified
 this binding."

Denis

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 18 May 2000 11:53:15 -0700

> should standardize the concept of classes of certificates.

This whole issue of different levels of verification for the values in a
certificate stems from the misguided idea that a single certificate needs to
contain everything about a subject.  This is misguided because it expands the
scope of the CA's responsibility beyond reasonable limits.

For example, it seems to me that a domain name registrar, not a CA, is
authoritative about who owns a domain.  Similarly for email addresses, IP
addresses, and pretty much all of the other altName forms.

CAs should be authoritative for only one thing: linking a public key value to
a name.  This provides a level of indirection that allows other authorities
to attach attributes to that name.  In other words, the public-key
certificate allows relying parties to identify the owner of a name, and
attribute certs (or other attribution protocols) allow relying parties to
discern facts about the owner of that name.

Clearly separating the scope of responsibility has numerous benefits.  Each
authority's legal liabilities are vastly reduced, as each is solely
responsible for its own domain.  Attribute and key management is also greatly
simplified, as compared to using more "monolithic" certs where a cert must be
revoked and re-issued if any of its attributes changes.

Trying to define standardized classes of levels of validation is frankly a
bit naive, since no two CAs will ever operate in the same way.  It also
perpetuates the misguided notion of a single authority for several
attributes.

This notion must be abandoned if PKI is ever to reach the wide-scale
deployment we're all hoping for.  Few organizations want to take
responsibility for all the attributes in current certificate profiles. 
Giving them a way to state which bits they really take responsibility for is
just complicating the whole thing, rather than solving the problem.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+