[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Removing expired certificates from CRLs.....
Mike, it is unclear to me why you consider CRLs to be a bad
mechanism for passing revocation data to OCSP responders.
The 2 big problems with CRLs are:
a. distribution of full CRL data to a large number of clients.
b. notifying all relying clients whenever a new (unexpected) CRL
has been produced due to a revocation event (ie. a CRL produced
earlier than the nextUpdate period on an old CRL).
We have deployed responders in a large number of places, where
we have used a push mechanism to send CRLs to our VA (our
OCSP server). This method has worked very well, even for pretty
large installations - the time to produce 100K CRLs isn't very
large. Neither is the time to get it from the CA to the VA.
The final relying parties are using OCSP and therefore getting
up to date responses, without needing to incur the overhead of
downloading full CRLs every time.
The CRL is just a standards based data
format for getting revocation information from the CA to the
VA - think of it as a database snapshot that is created
whenever the database changes.
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@xxxxxxxxxxxx
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Michael Myers [mailto:myers@xxxxxxxxxxxxx]
> Sent: Thursday, September 13, 2001 11:26 AM
> To: Denis Pinkas
> Cc: IETF-PKIX
> Subject: 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
> > > >
> >
>