RE: Dedicated CRL signing keys

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx>]

Mandating SKI and AKI changes nothing as these are just hints as to
which key signed. The client are already failing since they cannot find
the right public key that signed the CRL. As you not, it is possible to
have CA with multiple keys, so having a different AKI in the CRL may
simply indicate a problem with distribution.

-----Original Message-----
From: Nada Kapidzic Cicovic [mailto:nada@xxxxxxxxxxxxx] 
Sent: Friday, April 20, 2001 5:13 AM
To: Trevor Freeman; Bengt Ohlsson; Russ Housley
Cc: ietf-pkix@xxxxxxx
Subject: RE: Dedicated CRL signing keys

Would it not be easier to mandate the support for Authority and Subject
key 
identifiers, than to require the CA to use different DNs when different 
keys are used for issuing certificates and CRLs. As Tim noted, this
problem 
may occur even for regular CAs (which use the same key for issuing 
certificates and CRLs) after a key pair rollover.

At 09:29 AM 4/19/01 -0700, Trevor Freeman wrote:
>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

I agree with Bengt that key identifier extensions provide enough 
information for the client to go looking for the right cert path to
perform 
the verification of the signature on the CRL. If the client is not able
to 
locate the proper path it can fail with a meaningful error.

Nada

>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