Subject: RE: CRL sequence issues

From: "Vittek Robert" <[email-masked]>
Date: Wed, 8 Jun 2005 11:13:04 +0200

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.

Mgr. Robert Vittek
 
DITEC, a.s.
Bratislava Business Center V
Plynárenská 7/C
821 09 Bratislava
 
voice: +421 2 58 222 487
fax: +421 2 58 222 777
cell: +421 908 797 827
e-mail: [email-masked]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, June 02, 2005 11:35 AM
To: Vittek Robert
Cc: [email-masked]
Subject: Re: CRL sequence issues

Since you are talking about "electronically signed documents " and TSTs, you should also take a look at RFC 3126.

Denis

> Dear gentlemen,
> 
> I am involved in development of a system that is supposed to process electronically signed documents (possibly ten thousands per hour) while the response time (on the question if the signature is valid or not) should be "as low as possible". At the same time, it is crucial that the response is correct because a mistake can have serious legal consequences.
> 
> I have questions concerning certificate status validation when CRLs are the revocation mechanism. All of the references are made to RFC 3280.
> 
> CRL Validation algorithm described in 6.3 assumes usage of a local cache and somehow alibistically "assumes that all of the needed CRLs are available in a local cache". In 6.3.3, there are some rules to be followed on fetching all needed CRLs, one of them being very interesting.
> 
>          (2)  If the current time is before the value of the next update
>          field and use-deltas is set, then obtain the current delta CRL
>          that can be used to update the locally cached complete CRL as
>          specified in section 5.2.4.
> 
> There is no rule specified if use-deltas is not set. At the same time description of Next Update field (5.1.2.5) says:
> 
>    This field indicates the date by which the next CRL will be issued.
>    The next CRL could be issued before the indicated date, but it will
>    not be issued any later than the indicated date.
> 
> So, there is a possibility that a complete CRL has been issued invalidating the one in local cache for the time in question (e.g. from Time Stamp Token) and this CRL should be downloaded. I think that the above mentioned paragraph in 6.3.3 should be modified to obtain a complete CRL in any case or at least make a check.
> 
> Anyway, it's been kind of a theoretical problem so far. In real world it is not feasible to make HTTP or FTP call to CA for every validated signature at the rate "ten thousands per hour". Even if it was, how can I be sure (using untrusted HTTP or FTP communication with most of CAs) that some traitor did not fetch my request and did not provided me with older CRL which still has next update field greater than time from TST. I can not. My uncertainty will disappear only after a CRL with ThisUpdate greater than TST is issued and I have downloaded all CRLs issued so far. Btw, CRL with ThisUpdate greater than TST is sometimes the first CRL that can invalidate a revoked certificate which makes the rules for fetching CRLs in algorithm for CRL Validation all erroneous.
> 
> So, this leads me to a question what mechanism can be exploited to ensure that I have downloaded a complete set of CRLs issued so far. First, I thought that crlNumber is sufficient. But crlNumbers must convey only monotonically increasing sequence - NOT LINEAR sequence. That means, some of the numbers can be omitted and I have no means to determine it. Do you have any suggestions?
> 
> Moreover, it may be critical to be sure to download the next CRL issued right after TST, because RFC 3280 states that:
> 
>    A complete CRL lists all unexpired certificates, within its scope,
>    that have been revoked for one of the revocation reasons covered by
>    the CRL scope.
> 
>                An entry is added to the CRL as part of the next update
>    following notification of revocation.  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.
> 
> If TST < Cert.validTo < CRL(n).thisUpdate then CRL(n) is crucial for certificate status validation with respect to Time Stamp Token. Another reason to have a mechanism for a check if I am missing some CRL from sequence or not. Otherwise, there are cases when one is not able to say if a certificate was valid at TST time or not, hence if the signature is valid wrt. TST.
> 
> Maybe, I am just missing something in RFC 3280 (or any other) that will suddenly make everything clear to me.
> In that case I apologize to the readers of this forum.
> 
> Sincerely,
> 
> Mgr. Robert Vittek
>  
> DITEC, a.s.
> Bratislava Business Center V
> Plynárenská 7/C
> 821 09 Bratislava
>  
> voice: +421 2 58 222 487
> fax: +421 2 58 222 777
> cell: +421 908 797 827
> e-mail: [email-masked]
>  
>

---

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 8 Jun 2005 12:06:11 +0100

> 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: "Vittek Robert" <[email-masked]>
Date: Wed, 8 Jun 2005 13:28:58 +0200

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

> 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: "Denis Pinkas" <[email-masked]>
Date: Wed, 8 Jun 2005 13:40:40 +0100

>complete and up-to-date. The point is, that I MUST NOT miss any CRL.

Unless the signer's certificate is close to expiration, you MAY miss some CRLs 
since later CRLs will continue to advertise already revoked certificates.

If this does not answer your question, please reformulate it completely.

Denis

>See section. "4.2.2  Complete Revocation Refs Attribute Definition".

Regards,

Denis Pinkas

---

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 9 Jun 2005 11:21:13 +0100

>Yes, that's it! The problem is if the signer's certificate is close to
>expiration.

>RFC 3280 states that:
>An entry MUST NOT be removed

>This CRL may be crucial for the validation process, hence I MUST NOT
>miss it.
>I ask if there are any means to check (in CRLs themselves) that I did
>not miss any previous CRL.
>The crlNumber extension does not seem to be sufficient, since it allows
>some numbers to be skipped
>and I do not see any other.

>I looked at the previous contributions to this mailing list and I have
>found that there were attempts to address this problem
>by the "retention period" back in 2001
>http://www.imc.org/ietf-pkix/old-archive-01/thrd2.html#02198 (Removing
>expired certificates from CRL).
>The retention period may decrease the probability of missing revocation
>information of recently expired certificate to the acceptable limit.

>Has this been standardized already? In what RFC (or perhaps ETSI
>document)?

There is a simple and practical way to deal with this "non-issue".

Signers SHOULD receive their new certificate before their current certificate expires, 
and SHOULD use it as soon as they receive that new one. If they do it, then there is 
no problem. 

If they don't do it (or if they can't), then electronic signatures CANNOT be verified anymore,
when the verification time is after the end of validity of the signer's certificate.

There is no need for new extensions.

Denis 

>Best regards,
>Sent: Wednesday, June 08, 2005 2:41 PM
>To: Vittek Robert
>Cc: pkix
>>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.
>
>Unless the signer's certificate is close to expiration, you MAY miss
>some CRLs since later CRLs will continue to advertise already revoked
>certificates.
>
>>With hope that my question will be addressed, Robert Vittek
>>
>>

---

From: "Vittek Robert" <[email-masked]>
Date: Thu, 9 Jun 2005 13:16:24 +0200

First, I have to make one correction: the verification time (referenced
in validation process) is of course BEFORE the end of validity of the
signer's certificate, even though the verification process itself occurs
later. The problem is the certificate that expired soon after the (time
stamped) signature was made.

Now, to your proposal: Yes, I agree...it is simple and practical in most
of the cases.

But, certificates cost money (significant for some people here). And
someone may insist on being able to use the certificate until its very
end, because he paid for it. At the same time, he might not want to buy
another certificate from CA for whatever reasons. How is any signature
validator (usually the third party) supposed to explain a refused signed
document to the customer (the signer)?

For me, the best solution seems to be the expiredCertsOnCRL extension
(mentioned by Mr. David Cooper). Until CAs do not start to include this
extension in their CRLs, the signature verification systems will have to
mark such controversial signatures as undecidable and let the decision
for human. I admit that this can work in systems that we produce and I
might not be able to cover all use cases.

Robert Vittek

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, June 09, 2005 12:21 PM
To: Vittek Robert
Cc: pkix
Subject: Re: RE: CRL sequence issues

>some numbers to be skipped and I do not see any other.

>found that there were attempts to address this problem by the 
>"retention period" back in 2001

Signers SHOULD receive their new certificate before their current
certificate expires, and SHOULD use it as soon as they receive that new
one. If they do it, then there is no problem. 

If they don't do it (or if they can't), then electronic signatures
CANNOT be verified anymore, when the verification time is after the end
of validity of the signer's certificate.

Denis

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 9 Jun 2005 12:29:26 +0100

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

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Tom Gindin
> Sent: den 9 juni 2005 05:15
> To: Stefan Santesson
> Cc: Denis Pinkas; [email-masked]; 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" <[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,
> 
> 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
> 
> > 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,
> process,
> > able to obtain some CRL at the time it was issued from CA. So, I
need
> to
> > cache (on the basis of which I compose and later fully validate
ES-C)
> is
> > > I went through the  rfc 3126, but it does not address the problem
I
> > was asking about.