[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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