[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