CRL sequence issues

["Vittek Robert" <vittek@xxxxxxxx>]

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