RE: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-n ew-part1-06.txt comments)

["David A. Cooper" <david.cooper@xxxxxxxx>]

Sharon,

Are you suggesting that in order for an entity to issue CRLs on behalf of a certificate issuer, that CRL issuer would need to issue certificates as well (so that it can qualify as an authority)?  I don't think there should be such a requirement, but even if there were it wouldn't settle the issue.

Even if only authorities can issue CRLs, there is nothing to prevent that authority from using different keys to sign certificates and CRLs.  X.509 states that "[t]he cA component indicates if the certified public key may be used to verify certificate signatures."  So, the proper value of the cA bit is determined by the allowable uses of the subject public key, not by the type of entity the subject is.  So, even if the certificate subject is a CA, and issues certificates under some key, the cA bit should not be set unless the particular subject public key in the certificate can be used to verify certificate signatures. If an authority is the subject of a certificate and the particular public key of that authority that is being certified is only to be used to verify signatures on CRLs, then the cA bit should not be set.

Dave

At 10:48 AM 4/20/01 -0400, Sharon Boeyen wrote:

>David, sorry but I disagree with your assertions about X.509's 
>position on this issue. Either by design or by accident, X.509 requires that if CRLs are being issued, they are issued by an 'authority'. Remember that the definition of "authority" is "An entity responsible 
>
>for the issuance of certificates". Much of the text in X.509 predates OCSP or the concept of a validation authority, but I do know that the quotes below are new text added within the past couple of years with the intent of clarifying the role of CAs with respect to CRLs.
>
>Clause 7.3 says:  
>
>"An authority that issues certificates is required to state, possibly through a published statement of their practices, through the certificates themselves, or through some other identified means, whether:
>
>-       The certificates cannot be revoked; or 
>-       The certificates may be revoked by the same certificate-issuing authority directly; or 
>-       The certificate-issuing authority authorizes a different authority to perform revocation." 
>
>further down in the same clause is the text: 
>
>" 
>An authority that issues and subsequently revokes certificates: 
>a)      may be required to maintain an audit record of its revocation events for all certificate types issued by that authority (e.g. public-key certificates, attribute certificates issued to end-entities as well as other authorities);
>
>b)      shall provide revocation status information to relying parties using CRLs, on-line certificate status protocol or some other mechanism for the publication of revocation status information;
>
>c)      if using CRLs, shall maintain and publish CRLs even if the lists of revoked certificates are empty." 
>
>The quotes that you included in your message tie in with this base text, since the authority that issued the certificates has these responsibilities around revocation, there was no need for X.509 to state anything specific to CRL issuance. In the indirect CRL case, this was envisioned to be another CA or AA, that combined revocation notices from several CAs/AAs. 
>
>Having said that (with my X.509 editor's hat on), if there is a requirement to have entities that are not CAs or AAs be authorized to issue CRLs on behalf of the certificate issuer (because remember that a CRL is an indication that a certificate is no longer considered valid "by its issuer")changes to X.509 would be needed. I'm not necessarily opposed to such changes, I'm just clarifying, in this message, that they would be needed in order for such implementations to be conformant. This, as usual could be done through the enhancements work or could be proposed through the defect process. One way to enable that kind of change might be to redefine authority and to talk about 3 types rather than two. However, it would take some careful review to ensure that the set of changes was thorough and complete.
>
>Sharon 
>
> > -----Original Message----- 
> > From: David A. Cooper [<mailto:david.cooper@xxxxxxxx>mailto:david.cooper@xxxxxxxx] 
> > Sent: Thursday, April 19, 2001 5:08 PM 
> > To: ietf-pkix@xxxxxxx 
> > 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 
> > 
> >