Re: Dedicated CRL signing keys

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Russ,

That'd be a bad resolution since it would break deployed CAs who
use the same name and different cert and CRL signing keys (and
those do exist and are operating).

Any other ideas or should we just require clients to understand
what's going on based on key usage?

Stephen.

Russ Housley wrote:
> 
> Trevor:
> 
> I propose the following solution that builds on the Indirect CRL
> capabilities that are already available.  When a CA wants to employ
> separate private keys to sign certificates and CRLs, then that CA MUST
> delegate CRL signing to a separate authority.  That separate authority MUST
> have a different Distinguished Name that the CA, but it could be operated
> by the same organization.  In this way, the IDP CRL extension would flag
> the "unusual" circumstances.  Clients that do not support Indirect CRLs can
> fail gracefully (unsupported optional feature), and clients that support
> Indirect CRLs can happily handle the certificates and CRLs.
> 
> Thoughts?
> 
> Russ
> 
> At 01:32 PM 4/18/2001 -0700, Trevor Freeman wrote:
> >There has been some discussion regarding the proposal to have CRLs
> >signed with CA keys which do not also sign certificates. Since this will
> >not be a mandatory to implement feature, I am concerned about the impact
> >on pkix compliant clients who encounter CRL signed in this way, and how
> >we expect them to behave. What seem unacceptable with the current
> >proposal is that the signage check on the CRL will fail, and the client
> >will have little clue as to why and if this failure is expected. The
> >information in the chain, while present, is in the CAs certificate, is
> >difficult to find and subtle so would be easily missed by someone
> >debugging this problem. I would like to see some clearer indication in a
> >critical extension in the CRL itself that would indicate what was going
> >on. In expressing these semantics in a critical extension, we maintain
> >the principal that if you don't understand the extension, the client
> >knows to fail due to its own inadequacies and that failure is by design,
> >therefore allowing the client's to return an error unsupported option
> >rather than invalid signature.
> >Trevor

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com