[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Removing expired certificates from CRLs.....
Denis,
Thank you for your consideration of historic aspect of digital signatures.
I'm sure more work remains to be done in this area. I for one however
remain more concerned of our broad assumptions regarding the use of periodic
CRLs as the basis for aperiodic OCSP-based services that deliver on-demand
class timeliness. Several systems-level issues are under-explored in this
context. Within closed environments there might exist data exchange
mechanisms that are fully responsive to the security requirements CRLs
satisfy but do so in a means that enables not only the timely inter-domain
exchange of revocation status, but validation status as well.
Mike
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Denis Pinkas
> Sent: Thursday, September 13, 2001 1:31 AM
> To: Michael Myers
> Cc: IETF-PKIX
> Subject: 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
> > >
>