Subject: [AAA-WG]: [issue] Revalidation of certificates in cache

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 28 Aug 2001 12:35:20 +0200

Submitter name: Miguel A. Monjas
Submitter email address: [email-masked] 
Date first submitted: 2001-08-27
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00083.html and
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html
Document: CMS-02
Comment type: T
Priority: S
Section: 
Rationale/Explanation of issue: 

According to the CMS draft (3.1, Usage Scenario), the implementations
of CMS may cache DSA setup information. Also, they must honor the TTL
setting and re-validate certificates before using cached data. The
draft looks a little bit confused, so that Stephen Farrel proposed and
additional text in order to make it clear (see
http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html).

His basic statement was the following: Depending on the parameters of
the certificates belonging to the certificate chain (or belongint to
the OCSP response or the CRL), a "safe" period with no revocation
checks will be computed (I assume that if this safe period is smaller
than the length of the DSA, a revocation check must be done once the
safe period ends; but in the other hand, if the safe period is bigger
than the DSA length, the revalidation must be done once the DSA
expires). Additional checks might be done depending on the local PKI
policy.

However, from my humble point of view, the text just partially solved
the problem since its approach was very PKI-centric.

I'll explain my approach with some figures. This is the scenario as
far as I understood it:

 ____________________________________________
               DSA                           |
 ==================================          |
|             |                    |         |
beginning of  |                    |         |
 the DSA      t1 (any special time |         |
              in which a message   |         |
              is issued)           |         |
                                   end of    |
                                    the DSA  |
                                             t2 (other 
                                              issued message)

What I wanted to assure is that in t1, the implementation may choose
not to revalidate the certificates. But in t2, the implementation must
revalidate the certificates. This statement wasn't clear (in my
oppinion), and I wanted to make it more explicit.

Requested change: 

The following paragraph must be changed:

   Implementations MAY cache the information required to establish a
   DSA, but MUST honor time-to-live settings and MUST re-validate
   certificates (possibly including revocation checks) before using
   cached data.

With this paragraph (which includes Stephen's contributions):

   Implementations MAY cache the information required to establish a
   DSA. However, they MUST honor time-to-live settings so that 
   certificates MUST re-validated (possibly including revocation
   checks) once the DSA has expired.

   Revalidations MIGHT also occur before the DSA expires according to
   PKI policies. During the process of certificate path validation 
   some implementations will calculate a duration for which the 
   certificate path may be considered "safe". For example, if an
   implementation did not support certificate revocation checks, then
   the "safe" period would be from the time of initial validation 
   until the earliest notAfter time in the set of certificates in the
   path. An implementation which does support certificate revocation
   checks will typically be able to calculate a "safe" period based
   additionally on the earliest nextUpdate field in a CRL or OCSP
   response. Basically, the safe period is from the time of
   certificate validation to the earliest value from the set of
   notAfter and nextUpdate fields encountered during certificate
   validation.
   
   However, implemetors should note that CAs MAY issue additional 
   CRLs before the nextUpdate period. Generally it is a matter of 
   local PKI policy as to whether an implementation will make 
   additional checks even during the calculated "safe" period. For 
   the purposes of this specification implementations are NOT REQUIRED 
   to make such checks and MAY assume that no re-validation of 
   certificates is required during the "safe" period defined above.

Regards

  // M.A.

-- 
  Miguel Angel Monjas Llorente
  Systems Engineer, GSM/UMTS Systems Management
  Ericsson España, S.A. (EEM) UMTS/GSM Databases
  Tel: +34 91 3393605                 Mob: +34 629 570196
  <mailto:[email-masked]>  Fax: +34 91 3392538
  Retama 1, 4th. 28045 Madrid - SPAIN -