Just to be clear, lets not confuse what I may happen to want as
an individual contributor to PKIX or any other list, with what
I state as 509 editor (they're not necessarily always the same :-)
My comments were purely from the editor's perspective and yes,
the current 509 text is quite clear that the CA that issues a
certificate is responsible for stating whether or not that certificate
can be revoked, and if so, what mechanism is used to inform
relying parties. If that mechanism is CRLs, these are issued by
the certificate issuer or by another authority delegated that
task by the certificate issuer (that doesn't necessarily mean that
509 requires a cert to be issued to that authority, nor that the cert
contain the basic constraints extension though, that is the job of
profile groups to determine and incidentally I don't believe they'll
all adopt the same solution so I would want 509 to remain flexible).
My own personal view is that industry has moved to a point where there
probably isn't any real requirement for a CRL issuer to also be a cert
issuer as long as that CRL issuer is delegated that responsibility
by the cert issuer and there is a cryptographic way to ensure that
binding for relying parties. To achieve that, I believe some changes
are required in 509.
On the separate keys for cert and CRL signing (by the same authority), my
personal opinion is that anything you read into 509 text on that specific
topic would be accidental as I don't recall any specific discussion on it.
However, since that is a real world requirement, I would want to be sure
that 509 did not prohibit it.
Hope that clarifies where my comments are coming from :-)
> -----Original Message-----
> From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
> Sent: Friday, April 20, 2001 11:44 AM
> To: ietf-pkix@xxxxxxx
> Subject: RE: cA flag and CRL issuers (was Re: Last Call:
> draft-ietf-pkix-n ew-part1-06.txt comments)
>
>
> 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
> > >
> > >
>
>