RE: Dedicated CRL signing keys

["Carlin Covey" <ccovey@xxxxxxxxxx>]

Tim, Russ and Juergen,

I agree that CRL signature checks following CA key changeover
need to work properly.  This could be done via the same
"new-with-old" certificate that extends the RP's trust to the
new CA keypair.  But why can't it also be done via an IDP extension
in a CRL signed with the soon-to-be-retired CA private key?  I echo
Juergen's question.  Russ, why must the DN be different?


Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation



-----Original Message-----
From: Tim Polk [mailto:tim.polk@xxxxxxxx]
Sent: Thursday, April 19, 2001 8:41 AM
To: ietf-pkix@xxxxxxx
Cc: Russ Housley; Trevor Freeman
Subject: Re: Dedicated CRL signing keys


Folks,

When we discussed this solution offline yesterday, I was enthusiastic.  It
appeared to resolve a problem using the tools we already have available.

However, upon further reflection, this proposal creates as many problems as
it resolves.

Consider a CA that issues certificates and CRLs under using key pair "A"
for three years, then switches to key pair "B" for the next three
years.  In this case, the CA does not maintain private key "A" after the
rollover certificates are issued.

Under the proposed solution, the CA would have to change its name, since it
was going to issue CRLs under a different key pair than the certificates
were issued under.  Even worse, there would be no way to insert the CDP
with the new name in the old certificates.

I think our solution ... isn't.  Sigh.

Tim Polk

At 05:07 PM 4/18/01 -0400, 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
>