Subject: RE: keyCertSign and cRLSign Key Usage Bits

From: Sharon Boeyen <[email-masked]>
Date: Thu, 26 Apr 2001 10:41:48 -0400

Santosh I see your point on the schema - actually 509 contains the exact
same text and would also need to 
be modified. I assume that the appropriate change would be to delete the
text that requires the ca bit to be set in 
any cert that goes into the cACertificate attribute. As for the
crossCertificatePair attribute, I guess it would need
to be lifted there as well (assuming a CA would want to issue a cert to
another CA for purposes of verifying signatures
on CRLs but not on certificates)?
 
That raises another point - if we modify all this "stuff" to allow entities
other than authorities to sign CRLs, where 
would those certificates be stored? The subjects aren't CAs so they don't
really belong in either of these attributes. Inventing another attribute and
object class isn't very attractive either. Thoughts?
 
Dave, I realize you weren't suggesting we do this, but I do want to say that
I would not support changing the 
meaning of the ca bit in basic constraints. That is there as one of many
'business controls" that a CA can use to 
ensure that the certificate it issues (containing those constraints), when
used by conforming path validation systems, 
achieves that CAs intended result. That is very specific, very important,
and I wouldn't want to see it generalized. 
Nor would I support requiring any ties between the basicConstraints
extension and other extensions within X.509. 509
needs to remain flexible to allow PKIX and other profiles to determine their
own requirements for such combinations.
 
As for the definition of a CA, in addition to issuing certificates it has
responsibility for certificate revocation, which it may perform directly or
delegate to another 'authority/entity'. If that delegation can be to an
entity other than an authority, then you still have a schema problem
regardless of what you do with the ca bit and keyUsage. 
 
Taking a step back at what is 'technically important'. A cert issued for
purposes of cert signature verification contains at least the ca bit set and
the keyUsage keyCertSign. A cert issued for purposes of verifying the
signature on a CRL contains at least the digitalSignature and cRLSign bits
of keyUsage. If a CRL is to be issued by an entity other the CA that issues
the certificate, then there needs to be a way to identify that delegation
with integrity. If the crlDistributionPoints extension is in the
certificate, this can be done by populating the cRLIssuer field and that
value needs to correspond with the issuer name of the CRL being used (and
the other requirements outlined so nicely by 
Santosh in Annex B of 509 also need to be met of course). Other mechanisms
could also be used. As for the schema, there was no problem with the PKI
schema components as long as the crl issuers were also CAs(except that the
requirement for the CA bit to be set in all cases should probably be
removed). 
 
Assuming PKIX reaches consensus on wanting entities other than authorities
to issue crls, then additional schema work is at least needed and some
re-writing of text in 509 to permit that would also be needed. Hoyt and I
have already 
started working on a proposed draft defect report for that text, in
anticipation of that consensus, but we haven't looked
at schema implications yet.     

 -----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 9:53 AM
To: David A. Cooper; [email-masked]
Subject: RE: keyCertSign and cRLSign Key Usage Bits

Dave:
 
My opinion are based on the fact that the current X.509 text says that CA
issues CRLs.  Thus, if the key is used to sign the CRL, it is a CA and hence
the caCertificate.
 
I think this is not a security issue (in my mind).  We need to make sure
that the X.509 language and ldap schema align.
 
I still believe that those clients that do not make checks that are not
relevant to security, should be considered compliant.
 
-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 9:37 AM
To: [email-masked]
Subject: RE: keyCertSign and cRLSign Key Usage Bits

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] <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]
<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: "David P. Kemp" <[email-masked]>
Date: Thu, 26 Apr 2001 11:31:11 -0400

Sharon,

1) A cert issued for purposes of verifying the signature on a CRL contains
   at least the cRLSign bit. The digitalSignature bit (which is used for
   purposes other than b, f, or g), is not necessary.

2) If a CRL is issued by an entity other than the CA that issues the
   certificate, that delegation is identified with integrity by the
   fact that the CA which issued the EE certificate has also issued
   issued a certificate containing the cRLSign bit to the CA's
   revocation agent.  This agent is by definition an "authority",
   by virtue of being the subject of the cRLSign certificate.

Dave

Sharon Boeyen wrote:
> signature on a CRL contains at least the digitalSignature and cRLSign bits of
> keyUsage. If a CRL is to be issued by an entity other the CA that issues the
> certificate, then there needs to be a way to identify that delegation with
> integrity. If the crlDistributionPoints extension is in the certificate, this
> can be done by populating the cRLIssuer field and that value needs to
> correspond with the issuer name of the CRL being used (and the other
> requirements outlined so nicely by