RE: CRL sequence issues

["Vittek Robert" <vittek@xxxxxxxx>]

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: vittek@xxxxxxxx
 

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx] 
Sent: Thursday, June 02, 2005 11:35 AM
To: Vittek Robert
Cc: ietf-pkix@xxxxxxx
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: vittek@xxxxxxxx
>  
>