Subject: Last Call: draft-ietf-pkix-new-part1-06.txt comments

From: "Jim Schaad" <[email-masked]>
Date: Fri, 13 Apr 2001 16:37:23 -0700

1. As currently written in section 4.2.1.3, it is not possible for a non-CA
CRL issuer to be created for attribute certificates.  Was this the final
resolution of this issue?  This seems to me to be problematic as it means as
an end-user one can issue an attribute certificate, but one must always use
a different agent, which is a CA, to issue the CRLs.  This means that all
attribute CRL issuers are indirect.

2. Section 4.2.1.3, paragraph last:  Current Text: "set in An instantiation"
modify to "set in an instantiation".

3. Section 6.2 paragraph 2: change "prresented" to "presented"

4. Section 6.2 paragraph 2:  The text "For example, an implementation may
specify name constraints that apply to a specific trust anchor." is diffcult
for me given that the validation algorithm explicitly states that name
constraints are not applied to self signed certificates. Suggest "For
example, an implemenation may modify the algorithm to apply name constaints
during the initialization phase."

5. ASN module:
part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never
referenced

jim

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Apr 2001 13:32:49 -0400

>attribute CRL issuers are indirect.

I do not recall a consensus on this point.  Should an AA that supports CRLs 
have the cRLSign bit set in its public key certificate?  If so, this text 
must change.

>modify to "set in an instantiation".

Fixed.

>3. Section 6.2 paragraph 2: change "prresented" to "presented"

Fixed.

>during the initialization phase."

Self-signed certificates are a common mechanism for distributing public 
keys for trust anchors, but they are not a mandated mechanism.  That said, 
I think that your text it an improvement.   How about a hybrid:

    For example, an implementation MAY modify the algorithm
    to apply name constraints to a specific trust anchor
    during the initialization phase.

>part1a.asn(352) : warning XXXXX: The imported symbol 'id-ad' is never

Agree. I removed it.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 16 Apr 2001 11:59:33 -0700

Russ,

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, April 16, 2001 10:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
>
>
> Jim:
>

I don't recall anything except private discussions on this issue.  It is
here for the mailing list to comment on.

It is my option that an AA that supports CRLs SHOULD have the cRLSign bit
set.  Either that or we ask X509 to create AACertSign and AACrlSign bits and
keep this current text as is.

>     during the initialization phase.

I have no problems with this new text.

jim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Apr 2001 14:31:18 +0100

I'd also go along with Jim here - that an AA be allowed to 
have cRLSign set without having cA set in basicConstraints,
i.e. that AA's be an exception to the general rule for EE's
and that this be explicitly called out in son-of-2459. I'm
assuming that keyCertSign is therefore not set for AA's too
(and the text for keyCertSign shouldn't say "certificates",
but "public key certificates").

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Apr 2001 09:25:01 -0400

Based on this discussion, I think that the working group wants the 
keyCertSign and cRLSign key usage text to read as follows:

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key certificates.  This
       bit MUST only be asserted in CA certificates.  If the keyCertSign
       bit is asserted, then the cA bit in the basic constraints
       extension (see 4.2.1.10) MUST also be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on certificate revocation lists (CRLs).
       This bit MUST only be asserted in CA certificates and Attribute
       Authority (AA) certificates.  If the cRLSign bit is asserted in a
       CA certificate, then the cA bit in the basic constraints extension
       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
       asserted in an AA certificate, then the cA bit in the basic
       constraints extension MUST NOT be asserted.  If neither the
       cRLSign bit nor the keyCertSign bit are asserted, then the cA bit
       in the basic constraints extension MUST NOT be asserted.

Let me know if you disagree.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Apr 2001 11:06:32 -0400

Tim Polk and I just got off the phone.  After a lengthy discussion, we 
propose a revision to the cRLSign discussion:

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on revocation information (e.g., a CRL).
       This bit MUST be asserted in CA certificates that are used to
       verify signatures on CRLs.  If the cRLSign bit is asserted in a CA
       certificate, then the cA bit in the basic constraints extension
       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
       asserted in a non-CA certificate, then the cA bit in the basic
       constraints extension MUST NOT be asserted.  Such non-CA
       certificates MUST NOT be used to verify signatures on CRLs
       containing revocation information for public key certificates;
       however, these non-CA certificates MAY be used to verify
       signatures on CRLs containing revocation information concerning
       other types of certificates (e.g., attribute certificates).  If
       neither the cRLSign bit nor the keyCertSign bit are asserted, then
       the cA bit in the basic constraints extension MUST NOT be
       asserted.

Hey, this section was only one sentence in RFC 2459...

Please let us know if anyone has any remaining concerns.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Apr 2001 16:22:36 +0100

I thought it was clearer first time! But its still ok.

Stephen.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 18 Apr 2001 09:15:58 -0700

Russ,

Two items:

1.  You also need to change the text on the basic constraints extension.
2.  This text implies to me that the cRLSign bit must be set for an OCSP
responder (it does revocation information) is that what you want?

jim

> Sent: Wednesday, April 18, 2001 8:07 AM
> To: [email-masked]
> >> > > Subject: Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments
> >> > >
> >> > >
> >> > > Jim:
> >> > >
> >> > set.  Either that or we ask X509 to create AACertSign
> and AACrlSign
> >> bits and

---

From: Marc Branchaud <[email-masked]>
Date: Wed, 18 Apr 2001 09:35:50 -0700

> responder (it does revocation information) is that what you want?

The way I read it, the bit can only be set for OCSP responders that serve
status for non-public-key certs.  In other words, the cRLSign bit MUST NOT be
asserted in all deployed OCSP responder certs.  (AFAIK, there are no OCSP
responders currently serving status on attribute certs, though it certainly
would be easy for them to do so.)  OTOH, the CRLSign bit MAY be asserted for
OCSP responders that _only_ serve status for non-public-key certificates.  If
an OCSP responder serves status for both types of certificate, then I guess
the bit would stay off...

Either way, the situation WRT OCSP responders is vague.  I suggest that the
first sentence be changed as follows:

   The cRLSign bit is asserted when the subject public key is used for BOTH
   verifying a signature on a certificate and for verifying a signature on
   revocation information (e.g., a CRL).

I think this aligns most closely with the intended use of the bit, i.e. that
it should only apply to entities that issue certificates.  Thus, a plain OCSP
responder would not have the bit asserted in its cert.  But if a CA or AA key
is used to sign OCSP responses, then the bit SHOULD (MUST?) be asserted in
the CA/AA's cert.  To emphasize that, I recommend changing the second
sentence to:

   This bit MUST be asserted in CA certificates that are used to verify
   signatures on CRLs and/or OCSP responses.

		Marc

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 18 Apr 2001 12:54:12 -0400

The 9:25 AM version was clearer.  This version adds a restriction on
which type of authority may sign which type of revocation list.  Neither
version defines "CA certificate"; my impression was that

  If the cA bit is set, then the certificate *is* a CA certificate,

not the backwards-sounding

  If the cRLSign bit is asserted in a CA certificate, then the cA bit
  MUST be asserted.

How about the following:

      The cRLSign bit is asserted when the subject public key is used
      for verifying a signature on a CertificateList (e.g., a CRL).
      If the cA bit in the basic constraints extension (see 4.2.1.10)
      is not asserted, then the public key MUST NOT be used to verify
      signatures on CRLs containing revocation information for public
      key certificates, however it may be used to verify signatures
      on CRLs containing revocation information for other types of
      certificates (e.g., attribute certificates).
   *  If the cA bit is asserted, then the public key MUST NOT be used
   *  to verify signatures on CRLs containing revocation information
   *  for certificates other than public key certificates.

      If the keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension MUST be asserted.  If neither the cRLSign
      bit nor the keyCertSign bit are asserted, then the cA bit in the
      basic constraints extension MUST NOT be asserted.

The third sentence (marked ***) is new; I don't know if you intended
the asymmetry of allowing CAs to revoke ACs but forbidding AAs from
revoking PKCs.  If neither CAs nor AAs can revoke the other's certs,
then the third sentence is needed.

Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 18 Apr 2001 13:08:09 -0400

P.S., my preference is to not use the cA bit to make a distinction
between types of CRL signers, in which case the text is much simpler:

      The cRLSign bit MUST be asserted when the subject public key is
      used for verifying a signature on a CertificateList (e.g., a CRL).
      
      If the keyCertSign bit is asserted, then the cA bit in the 
      basic constraints extension (see 4.2.1.10) MUST be asserted.
      If the keyCertSign bit is not asserted, then the cA bit
      in the basic constraints extension MUST NOT be asserted.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 18 Apr 2001 13:40:08 -0400

Dave,

I agree with you. I see no basis in X.509 for setting the cA flag in basicConstraints for certificate subjects that can issue CRLs but not certificates. The current discussion about how to deal with CRLs for attribute certificates vs. public key certificates just further goes to show that it was a mistake to suddenly change the rules at the last IETF meeting.

I must say, though, that I am still confused about what is the correct thing to do when dealing with attribute certificates. If the subject of a public key certificate can issue attribute certificates but not public key certificates, what bits in the key usage extension should be set? My understanding is that the keyCertSign bit should not be set, but this seems to leave digitalSignature as the next best option.

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Apr 2001 16:05:07 -0400

Jim:

>You also need to change the text on the basic constraints extension.

You are correct.  I propose:

    The cA bit indicates whether the certified public key may be used to
    verify signatures on other certificates.  If the cA bit is asserted,
    then either the keyCertSign bit or the cRLSign bit in the key usage
    extension (see 4.2.1.3) MUST also be asserted.  If the cA bit is not
    asserted, then the keyCertSign bit in the key usage extension MUST
    NOT be asserted.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Apr 2001 19:17:35 -0400

Dave Cooper,

>Dave,
>
>I agree with you. I see no basis in X.509 for setting the cA flag in 
>basicConstraints for certificate subjects that can issue CRLs but 
>not certificates. The current discussion about how to deal with CRLs 
>for attribute certificates vs. public key certificates just further 
>goes to show that it was a mistake to suddenly change the rules at 
>the last IETF meeting.

We disagree on this point. Nowhere in X.509 or in previous PKIX 
documents has there ever been text to suggest that other than a CA 
can sign a CRL for a public key certificate. So, the rules were not 
changed at the last meeting, they were reasserted and clarified.

Also, in responde to other messages I've just been reading, I want to 
pont out that OCSP responses are not CRLs, so the value of the 
cRLSign bit should not be an issue for an OCSP responder. This 
suggests that the Lation abbreviation "e.g.," is inappropriately used 
when referring to revocation status info verified using a cert with 
the cRLSign bit enabled. CRLs are the only data structures the 
validation of which is relevant to this bit.  They are not an example.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 18 Apr 2001 21:34:20 -0700

Steve,

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2001 4:18 PM
>
> . . .
> . . .  Nowhere in X.509 or in previous PKIX
> documents has there ever been text to suggest
> that other than a CA can sign a CRL for a
> public key certificate.

I take it you mean CA as an entity vs. CA as the key the signed the
certificate.

> pont out that OCSP responses are not CRLs . . .

But one could (in fact it is being done) use OCSP to functionally replace
CRLs.

Mike

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Apr 2001 10:40:37 -0400

>I take it you mean CA as an entity vs. CA as the key the signed the

yes.

>But one could (in fact it is being done) use OCSP to functionally replace

yes, one could, but the name for the bit is specific to CRLs, not to 
any revocation status mechanism that exists or might exist in the 
future.

Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 19 Apr 2001 11:05:03 -0400

Steve,

I have no preference whether in the phrase "CertificateList (e.g., CRL)"
the "e.g.," stays or goes.  Note that some people use CRL to refer
to every instance of a CertificateList, whereas others use CRL, ARL,
ACRL, ICRL, DCRL, etc. to distinguish lists used for different
purposes.  Thus CRL may be either an example of, or a synonym for,
CertificateList.

I agree that the state of the cRLSign bit is not relevant to OCSP
responses and that CertificateList is the only data structure
which requires this bit.

Dave K

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 Apr 2001 18:48:58 +0200

Russ,

> propose a revision to the cRLSign discussion:

1) The only problem is that I concur with Stephen Farrel: I thought the text
was clearer first time! 

Since you do no provide any rational for having that change, only the two of
you can understand the rational. :-(

I prefer the first text unless you can explain to everybody the rational for
the change and then change the text to make that rational a little bit more
understandable. :-)

Maybe the answer to this point is in a subsequent message, but there has
been so many messages on that topic that I have not yet found the time to
look at each of them.

2) I am also sensible to the vocabulary problem raised by David Kemp when he
says: some people use CRL to refer to every instance of a CertificateList,
whereas others use CRL, ARL, ACRL, ICRL, DCRL, etc. to distinguish lists
used for different purposes.  Thus CRL may be either an example of, or a
synonym for, CertificateList.

Which convention do we use in PKIX-1 or plan to use ?

3) One last remark that is likely to impact the wording, but before we would
need to make a distinction between an ARL and a CRL for leaf certificates:
it makes sense from a security point of view, to distinguish between an ARL
and a CRL for leaf certificates.

The key for signing CRLs containing only leaf certificates (do we have an
acronym to designate this ?) SHOULD be different from the CA issuing key. If
the key used for signing such CRLs is compromised then the CA may then
revoke the CRL Issuer using an ARL and the CA issuing key does NOT need to
be changed.

There is no advantage to have a different key for signing ARLs since if the
key used for signing ARLs is compromised then the CA issuing key MUST be
changed. So using the CA issuing key for signing ARLs is not a higher risk
and should certainly be allowed. 

Denis

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Apr 2001 13:18:06 -0400

>responses and that CertificateList is the only data structure

Good points. If one considers ARLs and the other examples above, then 
I have to admit that "e.g.," is appropriate, though it would be 
better to include other instances here to make the distinction 
clearer.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 19 Apr 2001 17:08:07 -0400

At 07:17 PM 4/18/01 -0400, Stephen Kent wrote:
>Dave Cooper,
>
>>At 01:40 PM 4/18/01 -0400, David A. Cooper wrote:
>>I see no basis in X.509 for setting the cA flag in basicConstraints for certificate subjects that can issue CRLs but not certificates. The current discussion about how to deal with CRLs for attribute certificates vs. public key certificates just further goes to show that it was a mistake to suddenly change the rules at the last IETF meeting.
>
>We disagree on this point. Nowhere in X.509 or in previous PKIX documents has there ever been text to suggest that other than a CA can sign a CRL for a public key certificate. So, the rules were not changed at the last meeting, they were reasserted and clarified.

Steve,

You may say that X.509 and PKIX do not suggest that entities other than CAs can sign CRLs. However, I think we all agree that both X.509 and PKIX allow for a CRL to be signed with a different key than the key used to sign the certificates that are covered by that CRL. This may be a result of the CA that issued the certificates signing the corresponding CRLs with a different key or the CA that issued the certificates delegating the CRL issuing to another entity (via the distribution points extension). There is no requirement that the key used to sign the CRL also be used to sign certificates. So, I think we agree that there will be times where we will be issuing certificates to entities (whether those entities are CAs or not) where the intent is to specify that the public keys in the certificates may be used to verify signatures on CRLs but not on certificates.

The only place we seem to disagree is on the contents of the certificates issued in such circumstances. In particular, should the certificates contain a basicConstraints extension with the cA bit set? On this point, both X.509 and the previous PKIX documents are quite clear that the cA bit should not be set. Why? Because a CA is defined as an entity that issues public-key certificates and both documents similarly state that the cA bit is used to specify whether the certificate subject can issue certificates. There is no similar connection made between being a CA and issuing CRLs.

The following are some quotes from X.509 and pkix-new-part1-05:

In X.509 a CA is defined as "[a]n authority trusted by one or more users to create and assign public-key certificates."

Section 7 of X.509 states that "[a] CA-certificate is a certificate issued by a CA to a subject that is itself a CA and therefore is capable of issuing public-key certificates."

The description of basic constraints in X.509 further supports the idea that the cA bit is used to specify certificate issuing, not certificate and/or CRL issuing:

"This field indicates if the subject may act as a CA, with the certified public key being used to verify certificate signatures. … The cA component indicates if the certified public key may be used to verify certificate signatures. … if the value of cA is not set to true then the certified public key shall not be used to verify a certificate signature"

pkix-new-part1-05 states something similar:

"The cA bit indicates if the certified public key may be used to verify signatures on other certificates. If the cA bit is asserted, then the keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be asserted. If the cA bit is not asserted, then the keyCertSign bit in the key usage extension MUST NOT be asserted."

The description of the key usage bits are consistent with this as well.

X.509:
"The bit keyCertSign is for use in CA-certificates only. If KeyUsage is set to keyCertSign and the basic constraints extension is present in the same certificate, the value of the cA component of that extension shall be set to TRUE."

pkix-new-part1-05:
"The keyCertSign bit is asserted when the subject public key is used for verifying a signature on certificates.  This bit may only be asserted in CA certificates.  If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (see 4.2.1.10) MUST also be asserted. If the keyCertSign bit is not asserted, then the cA bit in the basic constraints extension MUST NOT be asserted.

The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information (e.g., a CRL)."

So, both X.509 and pkix-new-part1-05 go to great lengths to clearly state that only CAs can issue certificates and that basicConstraints with the cA bit set to true must be present in the certificates where the public key is to be used to verify signatures on certificates. There are no similar statements about CRLs. In fact, both documents are quite clear that the cA bit must not be set when the subject public key can not be used to verify certificates. So, if the subject public key can be used to verify CRLs, but not certificates, the cA bit must not be set.

X.509 is also careful not to preclude the public keys of non-CAs from being used to verify signatures on CRLs. For instance, an end entity is defined as "[a] certificate subject that uses its private key for purposes other than signing certificates or an entity that is a relying party." This leaves room for an end entity to use its private key to sign CRLs.

So, if PKIX wants to require that the cA bit be set whenever the subject public key can be used to verify CRLs and also wants to maintain consistency with X.509, PKIX would have to require that any certificate authorizing the use of a public key for verifying CRL signatures also authorize the use of that public key for verifying certificate signatures. Since we are in agreement that we do not want to impose such a restriction and that we do want to maintain consistency with X.509, we can not require that the cA bit be set when the subject public key can only be used to verify CRL signatures.

Dave

---

From: "Liaquat Khan" <[email-masked]>
Date: Fri, 20 Apr 2001 14:46:20 +0100

Yes, I agree with this too.

The actual value of the cA flag over and above what is already provided through the keyCertSign and cRLSign seems limited.  

Liaquat  
  ----- Original Message ----- 
  From: David A. Cooper 
  To: [email-masked] 
  Sent: Thursday, April 19, 2001 10:08 PM
  Subject: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)

  Steve,

  "This field indicates if the subject may act as a CA, with the certified public key being used to verify certificate signatures. . The cA component indicates if the certified public key may be used to verify certificate signatures. . if the value of cA is not set to true then the certified public key shall not be used to verify a certificate signature"

  X.509:

  pkix-new-part1-05:

  Dave

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Apr 2001 13:31:19 -0400

At 5:08 PM -0400 4/19/01, David A. Cooper wrote:
>>>I see no basis in X.509 for setting the cA flag in 
>>>not certificates. The current discussion about how to deal with 
>>>CRLs for attribute certificates vs. public key certificates just 
>>>further goes to show that it was a mistake to suddenly change the 
>>>rules at the last IETF meeting.
>>
>You may say that X.509 and PKIX do not suggest that entities other 
>than CAs can sign CRLs.

Sharon has explained what X.509 stated re this topic and it is clear, 
although the wording might be improved. PKIX had the same notion, but 
was too concise and a bit oblique in its wording.

>However, I think we all agree that both X.509 and PKIX allow for a 
>CRL to be signed with a different key than the key used to sign the 
>certificates that are covered by that CRL.

yes.

>This may be a result of the CA that issued the certificates signing 
>the corresponding CRLs with a different key or the CA that issued 
>the certificates delegating the CRL issuing to another entity (via 
>the distribution points extension).

yes.

>There is no requirement that the key used to sign the CRL also be 
>used to sign certificates. So, I think we agree that there will be 
>times where we will be issuing certificates to entities (whether 
>those entities are CAs or not) where the intent is to specify that 
>the public keys in the certificates may be used to verify signatures 
>on CRLs but not on certificates.

yes.

>The only place we seem to disagree is on the contents of the 
>certificates issued in such circumstances. In particular, should the 
>certificates contain a basicConstraints extension with the cA bit 
>set? On this point, both X.509 and the previous PKIX documents are 
>quite clear that the cA bit should not be set. Why? Because a CA is 
>defined as an entity that issues public-key certificates and both 
>documents similarly state that the cA bit is used to specify whether 
>the certificate subject can issue certificates. There is no similar 
>connection made between being a CA and issuing CRLs.

We disagree here.

>In X.509 a CA is defined as "[a]n authority trusted by one or more 
>users to create and assign public-key certificates."
>
>Section 7 of X.509 states that "[a] CA-certificate is a certificate 
>issued by a CA to a subject that is itself a CA and therefore is 
>capable of issuing public-key certificates."

These definitions address the cert issuing aspect of a CA, but the 
fact that they don't address the revocation responsibilities of a CA 
does not mean that other than a CA issues CRLs. Prior to the 
introduction of CRL DPs and indirect CRLs, there was no way for other 
than a CA to issue a CRL. I have seen no text introduced along with 
v3 certs and v2 CRLs to suggest the existence of a non-CA entity that 
signs CRLs, and that suggests that CRL signing is still the province 
of CAs, not of some other class of as yet unnamed entities.

>The description of basic constraints in X.509 further supports the 
>idea that the cA bit is used to specify certificate issuing, not 
>certificate and/or CRL issuing:
>
>"This field indicates if the subject may act as a CA, with the 
>certified public key being used to verify certificate signatures. … 
>The cA component indicates if the certified public key may be used 
>to verify certificate signatures. … if the value of cA is not set to 
>true then the certified public key shall not be used to verify a 
>certificate signature"
>
>
>"The cA bit indicates if the certified public key may be used to 
>then the keyCertSign bit in the key usage extension (see 4.2.1.3) 
>MUST also be asserted. If the cA bit is not asserted, then the 
>keyCertSign bit in the key usage extension MUST NOT be asserted."

again, this supports the notion that a CA signs certs, but it says 
nothing about whether a CA or some other entity signs CRLs. We have 
uncovered a number of instances where less than perfect wording has 
lead to confusion and our recent dialogue suggests that some of the 
quotes you cite are examples of this.

>"The bit keyCertSign is for use in CA-certificates only. If KeyUsage 
>is set to keyCertSign and the basic constraints extension is present 
>in the same certificate, the value of the cA component of that 
>extension shall be set to TRUE."
>
>pkix-new-part1-05:
>"The keyCertSign bit is asserted when the subject public key is used 
>for verifying a signature on certificates.  This bit may only be 
>asserted in CA certificates.  If the keyCertSign bit is asserted, 
>then the cA bit in the basic constraints extension (see 4.2.1.10) 
>MUST also be asserted. If the keyCertSign bit is not asserted, then 
>the cA bit in the basic constraints extension MUST NOT be asserted.
>
>The cRLSign bit is asserted when the subject public key is used for 
>verifying a signature on revocation information (e.g., a CRL)."

You have conveniently omitted the various parts of the  2459 and 2459 
bis text that refer to what a CA must do to comply with the RFC when 
it signs CRLs, quotes that have been distributed on this list earlier 
but which do not support your position.

>So, both X.509 and pkix-new-part1-05 go to great lengths to clearly 
>state that only CAs can issue certificates and that basicConstraints 
>with the cA bit set to true must be present in the certificates 
>where the public key is to be used to verify signatures on 
>certificates. There are no similar statements about CRLs. In fact, 
>both documents are quite clear that the cA bit must not be set when 
>the subject public key can not be used to verify certificates. So, 
>if the subject public key can be used to verify CRLs, but not 
>certificates, the cA bit must not be set.

The text was inconsistent in this regard and we are fixing it.

>X.509 is also careful not to preclude the public keys of non-CAs 
>from being used to verify signatures on CRLs. For instance, an end 
>entity is defined as "[a] certificate subject that uses its private 
>key for purposes other than signing certificates or an entity that 
>is a relying party." This leaves room for an end entity to use its 
>private key to sign CRLs.

True, the quoted text does not prohibit an EE from signing a CRL, but 
that is far from supporting the notion that other than CAs do sign 
CRLs. The fact that CRL signing is in no way mentioned here 
undermines the argument I think you are trying to make.

>So, if PKIX wants to require that the cA bit be set whenever the 
>subject public key can be used to verify CRLs and also wants to 
>maintain consistency with X.509, PKIX would have to require that any 
>certificate authorizing the use of a public key for verifying CRL 
>signatures also authorize the use of that public key for verifying 
>certificate signatures. Since we are in agreement that we do not 
>want to impose such a restriction and that we do want to maintain 
>consistency with X.509, we can not require that the cA bit be set 
>when the subject public key can only be used to verify CRL 
>signatures.

Dave, as Sharon pointed out, this is NOT just a PKIX issue; it would 
require changes to X.509 as well.

Like Sharon, I am not opposed to making such changes, if folks want 
to delay 2459 bis for this, and if there is a consensus, but there is 
ample evidence that neither X.509 nor PKIX has ever envisioned EEs 
signing CRLs. You've heard this from both editors in previous 
messages.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 25 Apr 2001 13:25:23 -0400

Steve,

If we are going to change PKIX to require the cA bit in basicConstraints to be set even when the subject public key can only be used to verify signatures on CRLs, then we need to be sure that the text clearly explains to readers when the cA bit should or should not be set. Currently new-part1-06 states that "[t]he cA bit indicates if the certified public key may be used to verify signatures on other certificates." The clearly is not accurate, since if the cA bit is set one still does not know whether the subject public key may be used to verify signatures on certificates. One must look at the keyUsage extension to make that determination.

I think it would be helpful to the discussion that we are having if you would clearly state your interpretation of the meaning of the cA bit in basicConstraints.

 From what I have read so far, it appears that you believe that the cA bit should be used to indicate if the subject of the certificate is a CA. But, if this is the case, then new-part1-06 still does not accurately reflect your notion of the cA bit. Currently the text states that the cA bit may only be set if the keyCertSign bit or the cRLSign bit in keyUsage is set. However, a CA does more than just issue certificates and CRLs. A CA may have a private key dedicated to signing PKI transaction messages (e.g., certification response, revocation response, proof-of-possession challenge). If a certificate were issued to a CA with its PKI transaction message verification key as the subject public key, neither the keyCertSign nor the cRLSign bit in KeyUsage would be set, but the subject of the certificate would still be a CA.

So, should the cA bit be used to indicate if the certificate subject is a CA or to indicate that the subject public key may be used to verify signatures on certificates and/or CRLs? If the latter, then not all certificates issued to CAs will have the cA bit set.

Dave

At 01:31 PM 4/20/01 -0400, Stephen Kent wrote:
>again, this supports the notion that a CA signs certs, but it says nothing about whether a CA or some other entity signs CRLs. We have uncovered a number of instances where less than perfect wording has lead to confusion and our recent dialogue suggests that some of the quotes you cite are examples of this.

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 25 Apr 2001 11:54:09 -0700

All,

In trying to parse this issue (and Russ Housley's previous proposed text) it
appears that terminology needs a bit of shoring up, at least for me.

Can anyone answer these "simple" questions?

1.  Is a "CA Certificate" defined to be:

     a.  A certificate whose subject is a CA
     b.  A certificate with "cA" bit set.
     c.  A certificate with either kCertSign or cRLSign set?

         (Are (a) and (b) equivalent "if its a CA certificate"?)

2.  Is the term "public key certificate" intended to represent:

     a.  Only certificates that bind keys to "DN/Identity"
     b.  Certificates that bind keys to anything (e.g., "attributes")

     For instance, is an "Attribute Certificate" considered to be a
     subset of "public key certificates", or not?

3.  Is an "AA" considered to be:

     a.  A "CA that certifies attributes and not DN/Identity",
         (yet still a CA, since they author/authorize certificates.)
     b.  Not a CA, since the term CA is "reserved" to "DN/Identity"

4.  Is an "AA Certificate" a form of "CA Certificate" or not?
     (Answer should be derived from response to (3).

5.  If both "CRLs and ARLs" are examples of "certificate revocation lists"
     then is an ARL:

     a.  An instance of CRL (that happens not to revoke any DN/ID certs)?
     b.  Never a CRL, since every CRL involves DN/ID certificates?

I submit that more than half of the dialogs/debates on this list can
be traced to confusion regarding these fundamental terms.

___tony___

At 01:25 PM 4/25/01 -0400, David A. Cooper wrote:
>Steve,
>
>If we are going to change PKIX to require the cA bit in basicConstraints 
>to be set even when the subject public key can only be used to verify 
>signatures on CRLs, then we need to be sure that the text clearly explains 
>to readers when the cA bit should or should not be set. Currently 
>new-part1-06 states that "[t]he cA bit indicates if the certified public 
>key may be used to verify signatures on other certificates." The clearly 
>is not accurate, since if the cA bit is set one still does not know 
>whether the subject public key may be used to verify signatures on 
>certificates. One must look at the keyUsage extension to make that 
>determination.
>
>I think it would be helpful to the discussion that we are having if you 
>would clearly state your interpretation of the meaning of the cA bit in 
>basicConstraints.
>
>  From what I have read so far, it appears that you believe that the cA 
> bit should be used to indicate if the subject of the certificate is a CA. 
> But, if this is the case, then new-part1-06 still does not accurately 
> reflect your notion of the cA bit. Currently the text states that the cA 
> bit may only be set if the keyCertSign bit or the cRLSign bit in keyUsage 
> is set. However, a CA does more than just issue certificates and CRLs. A 
> CA may have a private key dedicated to signing PKI transaction messages 
> (e.g., certification response, revocation response, proof-of-possession 
> challenge). If a certificate were issued to a CA with its PKI transaction 
> message verification key as the subject public key, neither the 
> keyCertSign nor the cRLSign bit in KeyUsage would be set, but the subject 
> of the certificate would still be a CA.
>
>So, should the cA bit be used to indicate if the certificate subject is a 
>CA or to indicate that the subject public key may be used to verify 
>signatures on certificates and/or CRLs? If the latter, then not all 
>certificates issued to CAs will have the cA bit set.
>
>Dave
>
> >>The description of basic constraints in X.509 further supports the idea 
> that the cA bit is used to specify certificate issuing, not certificate 
> and/or CRL issuing:
> >>
> certified public key being used to verify certificate signatures. … The 
> cA component indicates if the certified public key may be used to verify 
> certificate signatures. … if the value of cA is not set to true then the 
> certified public key shall not be used to verify a certificate signature"
> >>
> >>
> >>"The cA bit indicates if the certified public key may be used to verify 
> signatures on other certificates. If the cA bit is asserted, then the 
> keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be 
> asserted. If the cA bit is not asserted, then the keyCertSign bit in the 
> key usage extension MUST NOT be asserted."
> >
> uncovered a number of instances where less than perfect wording has lead 
> to confusion and our recent dialogue suggests that some of the quotes you 
> cite are examples of this.

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900