[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Removing expired certificates from CRLs.....
Michael,
> Denis,
>
> What are your thoughts on the timeliness characteristic between OCSP and
> CRLs?
Well ...
I must admit that the definition of the archive cutofff (section 4.4.4) from
RFC 2560 has always been very strange for me, since it defines a time
interval rather then an absolute time. I read several times the text and
could not figure out how in practice it would be used.
The text talks about a retention interval without saying explictly to which
event it is relative to.
Is it the time interval beyond the notAfter date from a certificate ?
The text does not say so.
In addition, the text is talking, as an example, of a retention interval of
7 years (!) whereas in the context of that thread we are only talking of
about a month.
If I had to define from scratch the extension I would simply define an
absolute date (e.g. called ExtendedRevocationInformationDate, quite a
long name, but explicit) that could directly override the notAfter field
from the Validity field of a certificate. This would mean that this
extension allows to know until when the revocation information is
maintained. It is not directly related to the produceAt time. The only
condition is that, when it is present, it is always later than produceAt.
This is a problem because, if I understand correctly RC 2560, we have the
following equation:
ArchiveCutoff = producedAt - retention interval.
I do not see a clear relationship between these two concepts.
Unless you see one, it would mean that an extension different from
ArchiveCutoff would be necessary for OCSP responses so that we can have
identical concepts for CRLs and OCSP responses.
Thanks for raising the question.
Denis
> Mike
>
> Michael Myers
> t: +415.819.1362
> e: mailto:mike@xxxxxxxxxxxxxxxxxxxxxx
> w: http://www.traceroutesecurity.com
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> > Sent: Wednesday, September 12, 2001 12:35 AM
> > To: Michael Myers
> > Cc: IETF-PKIX
> > Subject: Re: Removing expired certificates from CRLs.....
> >
> >
> >
> > > All,
> > >
> > > I think a unique extension creates the least impact.
> > >
> > > More broadly though, what's really bothering me is my sense that we're
> > > backing into the notion of a 1-1 between CRLs and online status
> > mechanisms.
> > >
> > > Assume an environment that both publishes CRLs and offers OCSP-based
> > > services against the same set of certificates. What if:
> > >
> > > a) The CA receives a revocation request at T1;
> > >
> > > b) A database state variable is flipped at T1+N;
> > >
> > > c) An OCSP request is received at T1+N+M;
> > >
> > > d) An OCSP response is transmitted at T1+N+M+K;
> > >
> > > e) Yet the next CRL cycle won't run (i.e. the cron
> > > job won't fire) until T1+X where X >> (N+M+K).
> > >
> > > Thus relying parties are enabled to pick and choose between CRLs or OCSP
> > > depending on how it might benefit their argument for remedy
> > under digital
> > > signature laws.
> > >
> > > Thoughts, anyone?
> >
> > Some validation policies, like Signature policies are able to say whether
> > CRLs or OCSP responses shall be used.
> >
> > As an example see: draft-ietf-smime-espolicies-01.txt
> >
> > EnuRevReq ::= ENUMERATED {
> > clrCheck (0),
> > --Checks must be made against current CRLs
> > -- (or authority revocation lists (ARL))
> > ocspCheck (1), -- The revocation status must be checked
> > -- using the Online Certificate Status Protocol
> > -- (OCSP),RFC 2450.
> > bothCheck (2),
> > -- Both CRL and OCSP checks must be carried out
> > eitherCheck (3),
> > -- At least one of CRL or OCSP checks must be
> > -- carried out
> > noCheck (4),
> > -- no check is mandated
> > other (5)
> > -- Other mechanism as defined by signature policy
> > -- extension
> > }
> >
> > If either CRL (i.e.clrCheck) or OCSP (i.e. ocspCheck) is mandated, then
> > there is no conflict between the two mechanisms.
> >
> > Denis
> >
> >
> > > Mike
> > >
> > > Michael Myers
> > > t: +415.819.1362
> > > e: mailto:mike@xxxxxxxxxxxxxxxxxxxxxx
> > > w: http://www.traceroutesecurity.com g
> >