Folks:
Over the last few days, I have suppressed the urge to respond to this thread, largely because while I have a great deal of respect for the individuals debating this and know them personally, there either seems to be a general misunderstanding of the concepts, or their positions seems to be misstated, or they seem to have simply not explained themselves well enough.
Also, this chain seems to imply that several issues are getting mixed.
So, here is my take on it all.
First, I think that the restriction that a CA who desires to issue Indirect CRL needs to set itself up as a separate name is unduly restrictive. There is no need for a CA to do that. A CA can issue a full CRL as well as an Indirect CRL and populate these in the same or different entries (i.e., CRL DP) in the directory. Please review Annex B of X.509 for how to process CRL. So, may be Russ can explain why this requirement comes about.
Second, when we say that a CA may not use different keys for signing certificates and CRLs, we are again not thinking of operations. Operationally, a CA is going to rekey. When it does, it will have issued the certificates using the old key and will sign CRL with new key. There are your different keys.
Also, I think a standard should be flexible and promote security. From operational security viewpoint, a CA may not want to keep the certificate signing key active all the time, but may need to keep the CRL signing key active to help meet CRL issuance obligations. This will mean a separate CRL signing key since compromise of that key still does not compromise anything. The attacker needs to compromise some subscriber keys to create a true compromise, denial-of-service notwithstanding. Thus, we should accommodate separate keys for certificates and CRLs.
In short, requiring the CA to use a different name to issue indirect CRL is not well-grounded and should be deleted. Requiring a CA to use different key for indirect CRL is not well-grounded and should be deleted. Requiring the same key for certificate and CRL signing may not be possible due to rekey or operational security requirements and should be deleted.
Finally, as to Steve Farrell's question regarding client simplicity, I wish I could answer that. The client will need intelligence to handle rekey and secure CA who use different keys for certificate and CRL signing.
-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxxxxx]
Sent: Saturday, April 21, 2001 4:08 PM
To: Trevor Freeman
Cc: Russ Housley; ietf-pkix@xxxxxxx
Subject: Re: Dedicated CRL signing keys
Hi Trevor,
I'm sympathetic and would also like to see a nice solution that'd
ease graceful failure for clients. However, if the proposal breaks
existing CAs then its not a solution (as Tim pointed out for a
different reason).
Stephen.
Trevor Freeman wrote:
>
> 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
--
____________________________________________________________
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