Subject: RE: keyCertSign and cRLSign Key Usage Bits

From: Santosh Chokhani <[email-masked]>
Date: Fri, 27 Apr 2001 17:13:11 -0400

Russ:

I think that checking the basic constraints for CRL is a security
requirement on the clients we can do without.  No one has given any security
benefit of it.  All added checks do is add to complexity and hinder
interoperability. 

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Friday, April 27, 2001 4:05 PM
To: David A. Cooper
Cc: [email-masked]
Subject: RE: keyCertSign and cRLSign Key Usage Bits

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.

---

From: "Peter Lipp" <[email-masked]>
Date: Sat, 28 Apr 2001 00:45:27 +0200

Folks,

while I understand the mechanics of some of the extensions or parts of them
specified in x.509 and the certificate profice, I have not been able to
imagine under which circumstances these things would be useful and used.
Could somebody be kind enough to scetch a practical real-world scenario
where this would be the case:

- inhibitPolicyMapping
- inhibitAnyPolicy, including value for certificates that may follow...

Peter