Subject: RE: keyCertSign and cRLSign Key Usage Bits

From: Sharon Boeyen <[email-masked]>
Date: Thu, 26 Apr 2001 13:27:37 -0400

Hi Dave, my understanding of the crlsign bit is not that it is for
delegating 
that indirect authority, but that it is similar to the keyCertSign bit in
that
it indicates that the certified key can be used to verify signatures on CRLs

issued by the subject of the containing cert. It has nothing to do with
delegating
authority to issue CRLs on behalf of the issuing CA for the set of
certificates issued 
by that issuer. 

This bit would be typically be set in any cert issued by one CA to another
CA where relying parties would beexpecting to verify signatures on both
certificates and CRLs issued by the subject authority and in conjunction
with a certification path that contains the cert with this extension. 

Hoyt, can you comment from the perspective of the historian??  

Sharon 

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Thursday, April 26, 2001 12:35 PM
> To: [email-masked]
> Cc: Hoyt Kesterson
> Subject: Re: keyCertSign and cRLSign Key Usage Bits
> 
> 
> The second point is one where some clarifying language in X.509 and
> PKIX might be useful.
> 
> I've always assumed that the cRLSign bit is set exclusively for the
> purpose of delegating to an ICRLA or other agent (including 
> the CA's own
> online CRL-signing key which is different from its offline 
> cert-signing
> key).  In other words, for these certs:
> 
>    CA-1
>     |  CA-2-cert
>    CA-2
>     |  EE-cert
>    EE
> 
> where CA-2-cert contains a critical keyUsage extension with 
> keyCertSign
> asserted and cRLSign *un-asserted*, the private key which 
> signs EE-cert
> also signs the CRL issued by CA-2 which covers EE.  A CA can always
> revoke its own certificates without needing permission from 
> an upstream CA.
> 
> If CA-2-cert had cRLSign asserted, then CA-2 could also sign 
> CRLs covering
> certificates signed by the private key which signed CA-2-cert (CA-1's
> private key).
> 
> Is this not the intent of X.509?
> 
> Dave
> 
> 
> 
> Sharon Boeyen wrote:
> > 
> > I agree with your first point but not completely with the 
> second point. The
> > cRLSign bit means "for verifying a CA's signature on CRLs". 
> In a hierarchy,
> > for example, one might set this bit, along with the 
> keyCertSign bit in a cert
> > issued to a subordinate CA. The CRLs that you would anticipate that
> > subordinate CA to issue are ones for the set of 
> certificates that the
> > subordinate issues, not ones for the certs issued by the CA 
> issuing that
> > subordinate's certificate. That is not the same delegation 
> we've been
> > discussing, where a CA hands off responsibility for issuing 
> CRLs for its own
> > set of certificates to another entity. That needs to be 
> indicated differently
> > so that a relying party knows what entity is authorized to 
> issue CRLs 'on
> > behalf of' another CA.
> > 
> > Sharon
> > 
> > > -----Original Message-----
> > > From: David P. Kemp [mailto:[email-masked]]
> > > Sent: Thursday, April 26, 2001 11:31 AM
> > > To: [email-masked]
> > > Cc: Hoyt Kesterson
> > > Subject: Re: keyCertSign and cRLSign Key Usage Bits
> > >
> > >
> > > 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:
> > > >
> > > > 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).
> > >
>

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Thu, 26 Apr 2001 11:00:36 -0700

hi dave

this will be unusually short for me - i got 3 sets of guys
working on my roof

as i told sharon earlier today. the group created the ca and crl
keyusage flags early on in the work (i may be able to find the initial
contributions from nick pope). crl distribution point was just being
discussed, we wanted to shorten crls. the first proposal was to have
crls responsible for ranges of certificates (using the serial number).
later we decided to adopt the proposal to have the certificate point
to other crl locations but the first texts confined that to points
under the CA. later we expanded to the ability to point anywhere, e.g.
crl issuer.

i have proposed some text to sharon to describe how a non-ca
entity would be identified as a crl issuer for a set of
certificates.

i believe your proposed interpretation of using crlsign as an
indication of delegation is too divergent from that for ca sign. if CA
x issues a certificate to entity y with the CAsign flag on, x is
merely granting the right for CA y to issue certificates in CA y's
name, not CA x's. i think it is reasonable to keep the same
interpretation for cRLsign.

got to go talk to the electrician!

hoyt

At 1:27 PM -0400 4/26/01, Sharon Boeyen wrote:

Hi Dave, my understanding
of the crlsign bit is not that it is for delegating

that indirect authority, but that it is similar to the
keyCertSign bit in that

it indicates that the certified key can be used to
verify signatures on CRLs

issued by the subject of the containing cert. It has
nothing to do with delegating

authority to issue CRLs on behalf of the issuing CA
for the set of certificates issued

by that issuer.

This bit would be
typically be set in any cert issued by one CA to another CA where
relying parties would beexpecting to verify signatures on both
certificates and CRLs issued by the subject authority and in
conjunction with a certification path that contains the cert with this
extension.

Hoyt, can you comment
from the perspective of the historian??

Sharon

>     |
CA-2-cert

>     |
EE-cert

> CRLs for its
own

> > >    revocation agent.
This agent is by definition an "authority",

> > > > integrity. If the
crlDistributionPoints extension is in the