[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Removing expired certificates from CRLs.....
Hi Denis,
The ArchiveCutoff text is a little difficult to understand,
but is correct I believe.
The way I think about it, the response is saying that "as long
as your certificate didn't expire before the date specified in
the ArchiveCutoff field, the status reflected in this response
is correct". Conversely, if your certificate expired before the
ArchiveCutoff date, it might have been revoked before expiry, but
I am not saying anything about that status.
The equation you have derived is absolutely correct and this is
exactly the semantics that I was expecting from the CRL extension
we are talking about.
Do we agree?
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: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> 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
> > >
>