RE: Removing expired certificates from CRLs.....

["Michael Myers" <myers@xxxxxxxxxxxxx>]

Denis,

What are your thoughts on the timeliness characteristic between OCSP and
CRLs?

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
>