[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CRL sequence issues


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:


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.
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:

  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.
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 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.
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). 


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.
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. 


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.
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