[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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