Subject: RE: Dedicated CRL signing keys

From: "Housley, Russ" <[email-masked]>
Date: Fri, 27 Apr 2001 08:58:35 -0400

Yes.  So, I guess we agree.

At 04:47 PM 4/26/2001 -0400, Santosh Chokhani wrote:

Russ:
Will a CA that signs the certificates and CRLs using different keys, but
same Issuer DN be considered compliant?  If yes, then we
agree.

-----Original
Message-----

From: Housley, Russ
[mailto:[email-masked]]

Sent: Thursday, April 26, 2001 4:36 PM

To: Santosh Chokhani

Cc: [email-masked]

Subject: RE: Dedicated CRL signing keys

Santosh:

Optional is
sufficient.  It should NOT be mandatory to have separate signing
keys for certificates and CRLs.

Thanks.  I think we agree.

If CAs issue CRLs, then the CA can sign certificates and CRLs with the
same key, or the CA can use separate keys.

Certificate-using applications must be able to handle certificates and
CRLs signed by the same key.  Certificate-using applications may
handle CRLs signed by a different key than the certificates.

If you agree with this position, then we agree.

Russ

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 30 Apr 2001 11:52:57 -0400

If certificate-using applications MAY handle CRLs signed by a different key
than the certificates, then CAs have no real ability to exercise that option.

I believe:

Certificate-using applications SHOULD handle CRLs signed by a different key
than the certificates.

Dave

"Housley, Russ" wrote:
> > Russ: Will a CA that signs the certificates and CRLs using different keys,
> > but same Issuer DN be considered compliant?  If yes, then we agree.
> >
> > From: Housley, Russ [mailto:[email-masked]]
> > > Certificate-using applications must be able to handle certificates and CRLs
> > > signed by the same key.  Certificate-using applications may handle CRLs
> > > signed by a different key than the certificates.
> > >

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 30 Apr 2001 16:08:20 -0400

Dave:

The current text supports your position.  That is, CAs MAY use separate 
keys, and applications SHOULD be able to handle it.

Russ

= = = = = = = = = = =

5.1.1.3  signatureValue

    The signatureValue field contains a digital signature computed upon
    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
    is used as the input to the signature function.  This signature value
    is then ASN.1 encoded as a BIT STRING and included in the CRL's
    signatureValue field.  The details of this process are specified for
    each of the supported algorithms in [PKIXALGS].

    CAs MAY use one private key to digitally sign certificates and CRLs,
    or CAs MAY use separate private keys to digitally sign certificates
    and CRLs.  When separate private keys are employed, each of the
    public keys associated with these private keys is placed in a
    separate certificate, one with the keyCertSign bit set in the key
    usage extension, and one with the cRLSign bit set in the key usage
    extension (see sec. 4.2.1.3).  When separate private keys are
    employed, certificates issued by the CA contain one authority key
    identifier, and the corresponding CRLs contain a different authority
    key identifier.  The use of separate CA certificates for validation
    of certificate signatures and CRL signatures can offer improved
    security characteristics; however, it imposes a burden on
    applications, and it might limit interoperability.  Many applications
    construct a certification path, and then validate the certification
    path (see sec. 6).  CRL checking in turn requires a separate
    certification path to be constructed and validated for the CA's CRL
    signature validation certificate.  Applications that perform CRL
    checking MUST support certification path validation when certificates
    and CRLs are digitally signed with the same CA private key.  These
    applications SHOULD support certification path validation when
    certificates and CRLs are digitally signed with different CA private
    keys.