Tom:
I agree with most of what you said. If the CRL signing certificate is self-issued, then it should appear in caCertificate attribute.
But, if it is issued by another authority, then it must appear in the crossCertificatePair attribute. In addition, if the issuing authority is in the domain of the subject CA, it must also appear in the caCertificate attribute.
The above is based on my understanding on LDAP schema language we agreed to back in 1998 or 1999 after much debate.
-----Original Message-----
From: Tom Gindin [mailto:tgindin@xxxxxxxxxx]
Sent: Tuesday, April 24, 2001 1:02 PM
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx; Russell Housley (E-mail)
Subject: RE: Dedicated CRL signing keys
On a related point, is it agreed by all that directory publication of
CRL signing certificates with the same DN as the CA signing certificate
should occur in the caCertificate attribute, and thus a directory-enabled
client may find CRL signing certificates by scanning that attribute for
certificates which either contain the CRLSign bit within the KeyUsage
extension or don't contain the KeyUsage extension at all? RFC 2587 doesn't
say anything about this as far as I can tell.
Tom Gindin
Santosh Chokhani <chokhani@xxxxxxxxxxxx> on 04/24/2001 08:54:47 AM
To: ietf-pkix@xxxxxxx, "Russell Housley (E-mail)"
<rhousley@xxxxxxxxxxxxxxx>
cc:
Subject: RE: Dedicated CRL signing keys
Russ:
One of your comments yesterday was that we can make a choice between
simpler client and operational security when I said that some
implementations require separate CRL signing keys for operational security
reasons.
While I agree with you that this is a trade-off an enterprise needs to
make. But, I think the Internet RFC should not make such a choice. I am
saying that the RFC should permit both: simple client (same key for
certificate and CRL signing) as well as different keys for certificate and
CRL signing.
PKIX working group is after all, all about security. We should not say
that a secure implementation is not compliant with PKIX.