|
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 -----
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)
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
|