RE: RE: CRL sequence issues

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Tom,

I don't have an answer to your question since it depends on so many
unknown factors. We know that CRLs isn't a solution for immediate
communication of current status. I second David Cooper's last response
to the list on the limited scope of RFC 3280.

I think Robert asked more than one question.
I simply tried to provide Robert with a tip on how one can use http 1.1
headers and conditioned get to do some checking that you have the most
recent CRL without necessarily downloading it.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Tom Gindin
> Sent: den 9 juni 2005 05:15
> To: Stefan Santesson
> Cc: Denis Pinkas; ietf-pkix@xxxxxxx; Vittek Robert
> Subject: RE: RE: CRL sequence issues
> 
> 
>         Stefan:
> 
>         I do have a question here.  How is any RP ever expected to
know
> whether a given CRL issued after the certificate of interest's
expiration
> is "regularly scheduled" in the sense of RFC 3280?  What Robert is
looking
> for is actually the primary use case for that particular MUST NOT ("An
> entry MUST NOT be removed from the CRL until it appears on one
regularly
> scheduled CRL issued beyond the revoked certificate's validity
period") in
> RFC 3280 3.3 - an attempt to prove that a certificate was not revoked
at a
> time shortly before its expiration.  Why else is that MUST NOT
included,
> if not to facilitate such a check?
>         Do we need a SHOULD which an RP actually could verify as well?
> E.g., "An entry SHOULD continue to be included in any CRL for which
the
> thisUpdate time is less than or equal to the greatest nextUpdate time
> included in any CRL issued prior to the certificate's expiration".  An
RP
> which has two CRL's, one issued before the certificate's expiration
and
> one after, would know that the later CRL's absence of an entry for the
> expired certificate meant something if the earlier CRL's nextUpdate
was
> not greater than the later CRL's thisUpdate.
> 
> Tom Gindin
> 
> 
> 
> 
> 
> "Stefan Santesson" <stefans@xxxxxxxxxxxxx>
> Sent by: owner-ietf-pkix@xxxxxxxxxxxx
> 06/08/2005 09:13 AM
> 
>         To:     "Vittek Robert" <vittek@xxxxxxxx>, "Denis Pinkas"
> <denis.pinkas@xxxxxxxx>
>         cc:     <ietf-pkix@xxxxxxx>
>         Subject:        RE: RE: CRL sequence issues
> 
> 
> 
> Robert,
> 
> There is no means in the PKI standards or any information in the CRL
you
> can use to make sure that the CRL issuer has not issued a more recent
> CRL.
> 
> Microsoft has defined and makes use of a private extension (CRL Next
> Publish) which specifies when the next CRL is scheduled to be
published
> (prior to expiry date) but that is no guaranteed date. It's just a
hint
> when you could start looking for an updated CRL.
> 
> But there are still means to get very close to what you want by
caching
> http headers and make a conditioned http get based on e.g. the ETag of
> the last CRL fetch. If the Etag has not changed, the currently
available
> CRL is not changed.
> 
> This technique can also be used when implementing http 1.1 proxies to
> cache CRLs for a large number of local clients that share a proxy on
the
> local network. Caution has to be made however to man-in-the-middle
> attacks in unprotected exchanges.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > On Behalf Of Vittek Robert
> > Sent: den 8 juni 2005 13:29
> > To: Denis Pinkas
> > Cc: ietf-pkix@xxxxxxx
> > Subject: RE: RE: CRL sequence issues
> >
> >
> > Dear Mr. Pinkas,
> > I really appreciate that at least you replied to my contribution
but,
> > please, try to pay a little more attention to what I am concerned
> about.
> >
> > The Complete Revocation Refs attribute (described in 4.2.2)
references
> > the full set of the CRL or OCSP responses that HAVE BEEN used in the
> > validation of the signer and CA certificates used in ES with
Complete
> > validation data.
> >
> > My question relates more to the initial phase of the validation
> process,
> > when I am still collecting various validation data (e.g. CRLs) to be
> > able to perform the full validation. For various reasons, I may not
be
> > able to obtain some CRL at the time it was issued from CA. So, I
need
> to
> > perform some automatic checks regularly to make sure that my local
CRL
> > cache (on the basis of which I compose and later fully validate
ES-C)
> is
> > complete and up-to-date. The point is, that I MUST NOT miss any CRL.
> >
> > Do CRLs themselves (or any other PKIX objects) provide any means to
> > ensure this?
> >
> > With hope that my question will be addressed,
> > Robert Vittek
> >
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:denis.pinkas@xxxxxxxx]
> > Sent: Wednesday, June 08, 2005 1:06 PM
> > To: Vittek Robert
> > Cc: ietf-pkix@xxxxxxx
> > Subject: Re: RE: CRL sequence issues
> >
> >
> > > I went through the  rfc 3126, but it does not address the problem
I
> > was asking about.
> >
> > > I will try to make it more simple:
> > > How can I check (automatically) using only CRL extensions that I
> have
> > > all needed CRLs in my local cache. It may be crucial in some cases
> not
> > to miss any single CRL.
> >
> > RFC 3126 uses revocation status information references.
> > The crlHash may be used to make sure that the information is in the
> > cache.
> > See section. "4.2.2  Complete Revocation Refs Attribute Definition".
> >
> > Denis
> >
> >
> 
> 
>