[Re-Tx: Dedicated CRL signing keys]

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Seems like the list is acting funny today. Here's a re-send.

Stephen Farrell wrote:
> 
> 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

-- 
____________________________________________________________
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