Subject: RE: SubjectAltName verification

From: Warwick Ford <[email-masked]>
Date: Wed, 24 May 2000 13:48:19 -0700

With Steve's concurrence, I propose the following modified wording to the
clause of concern:

"The subject alternative name, like all other fields in a certificate and
all certificate extensions, is considered to be bound to the public key.
Thus the CA MUST verify (in accordance with the applicable certificate
policy and/or the CPS) all subject alternative names."

Warwick

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, May 24, 2000 8:05 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: SubjectAltName verification

[snip]

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 24 May 2000 16:02:02 -0700

I prefer Steve's wording to Warwick's. It is clearer and describes 
more of the limitations.

---

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 10:28:12 -0400 (EDT)

Echoing Paul Hoffman's comment...  I find Steve's text to be
preferable.  For one thing, retaining "definitively" seems a good
thing to do.

      paul

>>>>> "Warwick" == Warwick Ford <[email-masked]> writes:

 Warwick> With Steve's concurrence, I propose the following modified
 Warwick> wording to the clause of concern:

 Warwick> "The subject alternative name, like all other fields in a
 Warwick> certificate and all certificate extensions, is considered to
 Warwick> be bound to the public key.  Thus the CA MUST verify (in
 Warwick> accordance with the applicable certificate policy and/or the
 Warwick> CPS) all subject alternative names."

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

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 May 2000 17:15:09 +0200

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
in
  Denis> the certificate policies and/or the CPSs."

Denis

  Warwick> "The subject alternative name, like all other fields in a
  Warwick> certificate and all certificate extensions, is considered
to
  Warwick> be bound to the public key.  Thus the CA MUST verify (in
  Warwick> accordance with the applicable certificate policy and/or
the
  Warwick> CPS) all subject alternative names."

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 26 May 2000 11:28:44 -0400

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

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 30 May 2000 10:30:32 +0200

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.

> scope of the comment to just the subject alternate name.

ORIGINAL MESSAGE:

Paul and others,

Some major details: 

In RFC 2459 we have:

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. 

Denis> in the certificate policies and/or the CPSs."

Denis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 May 2000 11:04:53 -0400

Denis,

I agree with your analysis of where to put which text.  In fact, I 
think an early message from me on this topic acknowledged that since 
the text in question was only present in the Subject alt name 
section, that the broader attribute verification issue might better 
be addressed elsewhere, but that got lost along the way. Sorry.

So, let's make the alt name text match the base attribute text, as 
you suggest. I am happy with your proposed rewording for this text.

Separately, I'd like to insert a comment re verification of all 
attributes contained in a certificate. Again, I am happy with your 
wording, and the suggested placement of the text in 4.1.1.1.

Thanks for the response,

Steve

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2000 16:47:28 -0400

Denis:

I believe that a CA can operate in accordance with one or more 
certification policies at the same time.  The way that the CA is able to 
fulfill the requirements of more than one certification policy is 
documented in a single CPS.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 31 May 2000 09:04:52 +0200

Russ,

> documented in a single CPS.

OK. Let us remove the "s" from "CPS". :-)

Denis