RE: Dedicated CRL signing keys

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx>]

Bengt,
Theorizing what could be possible, do not change that support for these
semantics is not mandatory under this profile, which means we are trying
to establish how that client fails gracefully with some kind of
meaningful error
Trevor
-----Original Message-----
From: Bengt Ohlsson [mailto:bengt.ohlsson@xxxxxxxxxxxxxx] 
Sent: Thursday, April 19, 2001 8:10 AM
To: Trevor Freeman; Russ Housley
Cc: ietf-pkix@xxxxxxx
Subject: RE: Dedicated CRL signing keys

Trevor and Russ,

I don't see why the clients should fail to verify the signature
on the CRL. Assume a CA uses separate keys, same DN,
for certificate signing and CRL signing and sets the
AuthorityKeyIdentifier extension in both the certificates
and the CRLs. Then PKIX compliant clients should be able
to build the correct certificate chains for verifying both the
certificates and the CRLs.

The legislation may require the CA keys to be stored in
hardware without any copies. If you lose a key due to HW
failure you will probaly want to continue to issue the CRLs
with a new key and the same DN.

This requires the clients to handle the AKI extension to be
able to verify the signature on the new CRLs. This is a
small requirement compared to handle indirect CRLs if
you must change the DN.

Bengt

-----Original Message-----
From: Trevor Freeman [mailto:trevorf@xxxxxxxxxxxxxxxxxxxxx]
Sent: den 19 april 2001 01:40
To: Russ Housley
Cc: ietf-pkix@xxxxxxx
Subject: RE: Dedicated CRL signing keys


Hi Russ,
That addresses my concerns. A pkix compliant client can now be
reasonability expected to fail with a more informative error, and the
problem should be in people's faces since the CRL contains a critical
extension.
Trevor

-----Original Message-----
From: Russ Housley [mailto:rhousley@xxxxxxxxxxxxxxx] 
Sent: Wednesday, April 18, 2001 2:08 PM
To: Trevor Freeman
Cc: ietf-pkix@xxxxxxx
Subject: Re: Dedicated CRL signing keys

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