Subject: RE: RE: CRL sequence issues

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 8 Jun 2005 14:13:36 +0100

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: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Vittek Robert
> Sent: den 8 juni 2005 13:29
> To: Denis Pinkas
> Cc: [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, June 08, 2005 1:06 PM
> To: Vittek Robert
> Cc: [email-masked]
> 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
> 
>

---

From: Tom Gindin <[email-masked]>
Date: Wed, 8 Jun 2005 23:14:55 -0400

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" <[email-masked]>
Sent by: [email-masked]
06/08/2005 09:13 AM
 
        To:     "Vittek Robert" <[email-masked]>, "Denis Pinkas" 
<[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: RE: CRL sequence issues

Robert,

Stefan Santesson
 
about.
process,
to
is
have
not