Subject: RE: SubjectAltName verification

From: Peter Williams <[email-masked]>
Date: Tue, 30 May 2000 07:57:48 -0700

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.

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. 

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)

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.

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

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

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.

Peter.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, May 30, 2000 1:31 AM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: SubjectAltName verification

Steve,

It took me longer to respond to your message because you did not
included my message in your response. :-(

Several comments to your E-mail:

The place where we intend to have the text is section 4.2.1.7. which
is only related to the subject
alternative name. Hence it is not the right place to cover other
topics.

Maybe I misread the text while reading the sentence "definitively
bound" and I guess this hides a much bigger issue here. :-(

In RFC 2459, section 4.1.2.6  Subject, we currently have:

   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN). The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name
field. A
   CA may issue more than one certificate with the same DN to the
same
   subject entity.

Let us suppose that we use an *empty* distinguished name (which is
allowed by the standard). Should the above property also apply to
the alternative name ? I would think so and I understood 
"definitively bound" as equivalent to "unique". In other words the
subject Alternative name once assigned must never be re-assigned for
a different entity by the CA. To this respect, the other fields that
where mentioned are not "definitively bound". So you now understand
the rational of the change that was made.

If we want to fix this, I propose that we do the fixing in the
appropriate sections.

For the subject alternative name (section 4.1.2.6) I would propose
the following: 

The subject alternative name MUST be unique for each subject 
entity certified by the one CA as defined by the issuer name 
field. The CA MUST verify (directly or indirectly) all subject 
alternative names. The precise nature of the verifications 
is detailed in the certificate policies and/or the CPSs."

Somewhere else we could have a general statement to cover the point
that all fields MUST be verified. This could be, for example, at the
end of section 4.1.1.1. which would look like:

4.1.1.1  tbsCertificate

 The field contains the names of the subject and issuer, a public
key
 associated with the subject, a validity period, and other
associated
 information.  The fields are described in detail in section 4.1.2;
 the tbscertificate may also include extensions which are described
in
 section 4.2. 

 The CA MUST verify (directly or indirectly) all the fields
contained
 in this field. The precise nature of the verifications is detailed 
 in the certificate policies and/or the CPSs.

Denis

Note: At the end of this E-mail, you will find my original message.

> Denis,
> 
> The latter part of your message gets at the contentious point in this
> discussion.
> 
> Some of us believe that ALL data in a certificate is definitively
> bound to the public key.  After much debate the WG rejected the
> notion of marking data in a cert as non-verified.  So, the current
> posture is that the EXTENT to which data is verified is a matter of
> CA policy, but the basic notion is that the CA has verified all of
> the data.
> 
> Warwick gave some examples that he felt supported the notion that not
> all certificate data is verified, but my response argued that these
> examples were either not a violation of the verification notion
> (e.g., OUs), or were anomalous (pseudonyms).
> 
> So, while I agree with your suggestions re pluralizing the references
> in the cited text, I don't agree with the suggestion to limit the
> scope of the comment to just the subject alternate name.
> 
> Steve

ORIGINAL MESSAGE:

Paul and others,

Some major details: 

1) I would propose to add an "s" to "certificate policy" making it
"certificate policies".

In RFC 2459 we have:

4.2.1.5  Certificate Policies

The certificate policies extension contains a sequence of one or
more policy information terms, each of which consists of an 
object identifier (OID) and optional qualifiers. 

2) In the same way, I would add an "s" to "CPS" making it "CPSs".

3) Finally, since the verification is not uniform, I would also add
an "s" to "verification".

The final sentence would thus look like:

"The precise nature of the verifications is detailed in the
certificate policies and/or the CPSs."

4) ... and a comment on the use of "definitively":

We were looking for text replacement related only to the subject
alternative name section 4.2.1.7. Now the sentence has been extended
to cover parameters like "all other fields in a certificate" and
"all certificate extensions". So "definitively" also applies to them
now, and this is wrong.

I would thus propose to delete the sentence "like all other fields
in a certificate and all certificate extensions," and thus keep the
idea  from RFC 2459, where only the subject alternative name is
considered to be definitiviely bound to the public key, which was:

   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.

The new text would thus look like:

Denis> "The subject alternative name is considered to
Denis> be definitively bound to the public key. Thus the CA MUST
Denis> verify (directly or indirectly) all subject alternative
Denis> names. The precise nature of the verifications is detailed
Denis> in the certificate policies and/or the CPSs."

Denis

---

From: Al Arsenault <[email-masked]>
Date: Tue, 30 May 2000 11:32:44 -0400

I'll try to step lightly here, because the company is question is a
partner of my own employer.  However, I'm in complete disagreement with
one of Peter's central points:

Peter Williams wrote:
><snip>
> was conforming, last week. 
> 
<snip>
> offering within the PKIX family of conforming CAs.

In general, writing requirements in any standard to ensure that a
particular product or implementation succeeds is a really bad idea.
(Else I'd be proposing requirements to ensure that Diversinet's products
suddenly become PKIX-conformant, even though we currently rely heavily
on an unpublished proprietary protocol for communication between RAs and
CAs.)  While we should not single out any company's product or
implementation unfairly, neither should we tailor a requirement or set
of requirements to fit a particular product or implmentation.  Thus, if
VeriSign's Class 1 service is not "PKIX-conformant", my response would
be to question why.  If it's because VeriSign has chosen not to meet a
requirement that this group deems useful, then that's too bad - VeriSign
loses.  If it's because we're imposing a requirement that's not really
important, okay, I could see deleting the requirement, but I don't
believe that that's the case.

As for

>(A "national"

okay, I'll bite.  I'll assume that you're alluding to ACES here, since
that's the only major "national" program that fits your description.  I
know how ACES policy says that information in certs is to be verified -
it's done indirectly, using existing Government databases to provide
verification of data to the approved CAs.  However, I'm confused, since
(a) VeriSign's class 1 service was never and will never be "good enough"
for ACES; and (b) I'm not sure what tweaks killed any existing PKIX
conformance for the ACES vendors.  (BTW:  did just one ACES vendor
become non-conformant, or all three of them?)

And if there's something else you're talking about here, please be less
obtuse.  Be specific, even.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

---

From: Al Arsenault <[email-masked]>
Date: Tue, 30 May 2000 12:02:51 -0400

Al Arsenault wrote:

<snip>
>  I'll assume that you're alluding to ACES here, since
> that's the only major "national" program that fits your description.  

Geesh - working for a Canadian company, you'd think I'd know better by
now.  My apologies for that remark - ACES is the only "national" program
IN THE US that fits Peter's description, and since he now mostly resides
in the US, I jumped to the conclusion that he was referring to a US
program.  Of course, there are major national PKI-based programs in any
number of countries - if it was one of them we knocked out of PKIX
conformance last week (without a good reason for doing so), I'd be
interested in hearing about it.