Subject: RE: keyCertSign and cRLSign Key Usage Bits

From: "David A. Cooper" <[email-masked]>
Date: Thu, 26 Apr 2001 09:37:03 -0400

Santosh,

I think you bring up an interesting issue with the LDAP schema no matter what we do. As I pointed out yesterday, a CA may have a key pair that it only uses for PKI transaction messages. A certificate that includes the public key from this key pair would only have the digitalSignature KeyUsage bit set. The proposed text below states that the cA bit in basicConstraints should not be set. So, we would still have cases in which a certificate has been issued to a CA and either basicConstraints is absent or cA is set to false. (Technically, according to RFC 2587, we are OK if basicConstraints is absent, but this isn't really a good way out of the problem). A CA may also be issued a certificate in which the public key is intended to be used for key management. Same problem.

I asked yesterday what the meaning of the cA bit was. X.509 states that "[t]he cA component indicates if the certified public key may be used to verify certificate signatures." Do we intend to change X.509 and PKIX to state that the cA bit should be set whenever the subject is a CA? If not, then the LDAP schema will need to deal with certificates issued to CAs in which either basicConstraints is absent or is present with cA set to FALSE. If so, then we need to change the text to eliminate any tying between the cA bit and the contents of KeyUsage.

If we want to go with the proposed text below, then we will need to change both X.509 and PKIX to state that "the cA component indicates if the certified public key may be used to verify certificate or CRL signatures". We will also need to do something about the awkward connection between the cA bit and CRLs. Currently the text states that the cA bit should be set if the CRL issuing subject is issuing CRLs that cover public key certificates, but not attribute certificates. It further states that "
>AA certificates MUST NOT be used to verify signatures on CRLs containing revocation information for public key certificates". The problem is that, even if a single entity is not allowed to issued both public key certificates and attribute certificates, there is the possibility that a single, indirect CRL could cover both types of certificates. If one is using a CRL to check the status of a public key certificate, then it is clear that the text below requires that the certificate containing the key needed to verify the CRL signature must have the cA bit set. But what about when one is using a CRL to check the status of an attribute certificate? The quote text seem to suggest that, if the cA bit is not set in the certificate, the relying party is required to verify that the CRL does not contain any revocation information for public key certificates. I can't imagine that there was any intention to impose such a requirement, but that is what the text seems to say.
>
I think I have made my own opinion on this topic clear. X.509 does not state that the cA bit in basicConstraints should be set if the subject is a CA, it states that the bit should be set if the certified public key may be used to verify certificate signatures. The two are not synonymous.  If we change the standard to state that the cA bit indicates whether the subject is a CA, it may solve the LDAP schema problem, but it will require that the remove any dependencies between the cA bit and the KeyUsage extension.

As Tony said yesterday, we need to go back and clearly define the terms we are using. X.509 defines a CA as an entity that issues public key certificates. Is this the correct definition? Or is a CA an entity that issues public key certificates or CRLs that provide revocation information about public key certificates? Or it is something else? Does the cA bit indicate if the certified public key can be used to verify signatures on certificates, as X.509 states, or does it indicate that the subject is a CA, or something else? If we can't get agreement that the standard means what it says, how can we expect people to understand the standard?

Dave

At 08:20 AM 4/26/01 -0400, Santosh Chokhani wrote:
>Steve:
>  
>My rationale is as follows: There is no security benefit to checking the bit.  The basic constraints and associated path length may determine whether a CA can create a CA or not.  But, that is only useful for certificate path and since keyCertSign bit will not be set, the entity will NOT be able to create new CAs.
>  
>So, I think check is not relevant from security viewpoint.
>  
>Now, it may break some of the language (again not security) in ldap schema if we populate the certificate in caCertificate or crossCertificatePair and do not set the basic constraints.
>  
>So, it is a mixed bag.  I still think we should ask for the CAs to set the basic constraint bit so the ldap schema does not get screwed up and NOT require the client to check the bit.  My rule on clients is simple.  Maximize security and interoperability.  Make all checks that are security relevant and no more and that will lead to greater interoperability.
>  
>  
>-----Original Message-----
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Wednesday, April 25, 2001 3:51 PM
>To: Ambarish Malpani
>Cc: [email-masked]
>Subject: RE: keyCertSign and cRLSign Key Usage Bits
>
>At 10:55 AM -0700 4/24/01, Ambarish Malpani wrote:
>>  
>>I agree, also.
>>
>>Ambarish
>
>I disagree. We need to make a decision on whether a cert without a CA flag enabled can sign CRLs. If so, then we need to modify a lot of text in 2459, and in X.509, to say this clearly. Suggesting that a client be "forgiving" in this context is not a viable proposal for a standard.
>
>Steve
>>
>>  
>>---------------------------------------------------------------------
>>Ambarish Malpani
>>Architect                                                650.567.5457
>>ValiCert, Inc.                                  [email-masked]
>>339 N. Bernardo Ave.                          <http://www.valicert.com/>http://www.valicert.com
>>Mountain View, CA 94043
>>>-----Original Message----- 
>>>From: Santosh Chokhani [mailto:[email-masked]] 
>>>Sent: Tuesday, April 24, 2001 8:22 AM 
>>>To: Housley, Russ; [email-masked] 
>>>Subject: RE: keyCertSign and cRLSign Key Usage Bits
>>>
>>>Russ: I agree with the text.
>>>
>>>I also know that Steve Kent and Sharon Boeyen feel that X.509 states that only CA can issue CRL (the context of my comments being PKI only and not PMI).
>>>
>>>But, using the theory that you suggest that the client be forgiving, I would consider a client compliant if it did NOT check the basic constraint extension while verifying a signature on a CRL.  It need to ensure that the cRLSign bit is set in the keyUsage extension.
>>>
>>>-----Original Message----- 
>>>From: Housley, Russ [<mailto:[email-masked]>mailto:[email-masked]] 
>>>Sent: Tuesday, April 24, 2001 10:37 AM 
>>>To: [email-masked] 
>>>Subject: keyCertSign and cRLSign Key Usage Bits
>>>
>>>
>>>
>>>The consensus on these bits is not totally clear to me.  Yet, several 
>>>points have been consistently, and I think that the following text 
>>>incorporates them.  The debate regarding he linkage between these bits and 
>>>the cA bit in the basic constraints extension does not seem to be over, and 
>>>I have not made any changes in that area.  Please use this new thread to 
>>>discuss any remaining unresolved points.
>>>
>>>        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 a certificate revocation list (e.g., 
>>>        a CRL or an ARL).  This bit MUST be asserted in CA and Attribute 
>>>        Authority (AA) 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 AA 
>>>        certificate, then the cA bit in the basic constraints extension 
>>>        MUST NOT be asserted.  Such AA certificates MUST NOT be used to 
>>>        verify signatures on CRLs containing revocation information for 
>>>        public key certificates; however, these AA certificates MAY be 
>>>        used to verify signatures on CRLs containing revocation 
>>>        information concerning 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.
>>>
>>>Russ 
>

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 27 Apr 2001 16:05:04 -0400

David:

My intent was to impose a requirement on the CAs and AAs.  I can see that 
the proposed wording imposes a difficult requirement on clients.

Would anyone object to the deletion of that sentence?

If not, I think that the current state of these paragraphs is:

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on public key 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 a certificate revocation list (e.g.,
       a CRL or an ARL).  This bit MUST be asserted in CA and Attribute
       Authority (AA) 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 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.

Russ

At 09:37 AM 4/26/2001 -0400, David A. Cooper wrote:
>AA certificates MUST NOT be used to verify signatures on CRLs containing 
>revocation information for public key certificates". The problem is that, 
>even if a single entity is not allowed to issued both public key 
>certificates and attribute certificates, there is the possibility that a 
>single, indirect CRL could cover both types of certificates. If one is 
>using a CRL to check the status of a public key certificate, then it is 
>clear that the text below requires that the certificate containing the key 
>needed to verify the CRL signature must have the cA bit set. But what 
>about when one is using a CRL to check the status of an attribute 
>certificate? The quote text seem to suggest that, if the cA bit is not set 
>in the certificate, the relying party is required to verify that the CRL 
>does not contain any revocation information for public key certificates. I 
>can't imagine that there was any intention to impose such a requirement, 
>but that is what the text seems to say.