RE: Dedicated CRL signing keys

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx>]

Stephen,
The route problem is that this is an optional feature, and the net
result with the current proposal of profile compliant clients who
encounter a CA operating with this option will simply be a signature
failure. This presents a fairly high bar to anyone trying to establish
why the revocation check is failing. The rational behind using a
critical extension in the CRL is that now the conformant client knows
that failure is by design without understanding what the problem is
since it does not understand the extension and can return a more
informative error like option not supported.
Trevor

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxxxxx] 
Sent: Thursday, April 19, 2001 7:07 AM
To: Russ Housley
Cc: Trevor Freeman; ietf-pkix@xxxxxxx
Subject: Re: Dedicated CRL signing keys


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