Subject: Re: CRL sequence issues

From: Denis Pinkas <[email-masked]>
Date: Thu, 02 Jun 2005 11:35:16 +0200

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: "David A. Cooper" <[email-masked]>
Date: Wed, 08 Jun 2005 16:51:19 -0400

Robert,

The certification path validation algorithm in section 6 of RFC 3280, 
including the CRL validation algorithm in section 6.3, was designed to 
determine whether a certificate is valid at the current time:

   The algorithm presented in this section validates the certificate
   with respect to the current date and time.  A conforming
   implementation MAY also support validation with respect to some point
   in the past.  Note that mechanisms are not available for validating a
   certificate with respect to a time outside the certificate validity
   period.

This may not be the information that you need for your application, in 
which case you may need to make some adjustments to the algorithm.

See responses in-line.

Vittek Robert wrote:

>There is no rule specified if use-deltas is not set.
>
The idea of step (a) in section 6.3.3 is to ensure that the relying 
party is using CRLs that are not out-of-date.  If the complete CRL is 
out-of-date, it will be updated in step (a)(1)(ii).  If use-deltas is 
set and delta-CRLs are issued that cover this certificate then the 
relying party needs an up-to-date delta-CRL in addition to (possibly) an 
up-to-date complete CRL.  Step (a)(2) only deals with ensuring that the 
delta-CRL is up-to-date and so it can be skipped if the relying party 
chooses not to use delta-CRLs.

>At the same time description of Next Update field (5.1.2.5) says:
>
One of the main advantages of CRLs is that they can be cached.  
Requiring the relying party to check for a new CRL at every validation 
would eliminate this advantage.  Besides, as you note below, if a CRL 
issuer posts a new CRL before the announced nextUpdate time, there is no 
guarantee that the relying party will get that CRL even if the relying 
party checks for an update since CRLs are not distributed through secure 
channels.

>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…
The algorithm was designed to determine whether a certificate is valid 
at the current time.  Information may become available in the future 
that will indicate that the certificate has been revoked, but the 
algorithm can only base its decision on information that is currently 
available.  SCVP allows for the client to specify a validation time and 
section 3.2.7 of the current draft 
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-18.txt) 
indicates that one may want to specify a validation time that is after 
the time that the private key was used in order to allow time for a 
revocation notification to propagate through the system.  But, RFC 3280 
only addresses the question of whether the certificate is valid at the 
current time, not whether the use of the corresponding private key 
is/was valid.  In some cases it may be possible to wait for a while 
after the private key was used to validate the certificate, but in other 
cases that is not a possibility (e.g., verifying the certificate as part 
of an authentication operation).

>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 so…
Since RFC 3280 only deals with validating the status of the certificate 
at the current time, this is not an issue.  If the certificate is 
expired at the current time, then validation will fail (section 6.1.3, 
step (a)(2)).  If the certificate is still valid at the current time, 
then the certificate must not have at the time that any CRLs used in the 
validation were issued and the CRLs will provide status information for 
the certificate.

>In that case I apologize to the readers of this forum.
It seems that the question that you want answered is whether was 
legitimately used at the time that the document was signed.  This 
requires not only ensuring that the certificate was valid at the time 
that the signature was generated but that the certificate continued to 
be valid (i.e., was not revoked) for some period of time after the 
signature was generated.  This is a much more difficult question.

In order to do this you need to ensure that the validation is not 
performed until some time after the signature was generated.  The 
difference between the two times, D, must be enough to allow any 
revocation notifications to entered into and propagate through the 
system as noted in section 3.2.7 of the SCVP draft.

You also need to ensure that revocation information will be available 
for the certificate at the time that you perform the validation.  The 
easiest way is to not accept signatures that are created immediately 
before the certificate expires.  That is, if the signature is created at 
time Ts then the certificate must not expire until after time Ts + D 
when the certificate is validated.  Another option is to rely on CRL 
issuers to continue to include information about certificates in CRLs 
even after the certificates expire.  There is proposal for a new CRL 
extension in the Final Proposed Draft Amendment to X.509 (see page 14 in 
ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf).  
The new extension, called expiredCertsOnCRL, is a non-critical extension 
that allows the CRL issuer to indicate that the scope of the CRL 
includes some certificates that have already expired.  If this extension 
were included in the CRLs, it would be possible to validate a 
certificate even if the certificate had expired after time Ts but before 
time Ts + D.  Of course, the expiredCertsOnCRL is not currently being used.

Dave