Subject: [AAA-WG]: Revalidation of cache in CMS

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 14 Aug 2001 12:11:06 +0200

Hi,

just a question about the re-validation of DSA information. According
to the CMS draft (3.1, Usage Scenario), the implementations of CMS may
cache that information. Also, they must do one thing (honor the TTL
setting) AND another (re-validate certificate) before using cached
data. The paragraph is as follows:

   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.

What I think is that this re-validation must take place once the TTL
has been passed, but the draft looks a little bit confused, because
both conditions are suposed to be checked every time (so that, a
certification re-validation must be done always). Am I right? Which is
the right answer?

Regards

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 14 Aug 2001 09:43:23 -0700

> certification re-validation must be done always). Am I right? Which is

That certainly is what the text currently reads. I'm not sure about rechecking
a cert each time it needs to be used, but I suspect that's the way most
implementations work.

Anyone have any thoughts on this one?

PatC

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Aug 2001 12:21:25 +0100

Miguel,

I agree that the text is a bit vague. I'd suggest adding the 
additional text below. Note that this is a "lax" PKI policy
which assumes e.g. that no new (relevant) CRLs are produced
before the nextUpdate field, but I'd argue that that's ok
for Diameter since I wouldn't expect very frequent 
revocations in this context.

The next text should go in below the current text.

Does this solve the problem?

Regards,
Stephen.

   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.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 23 Aug 2001 10:24:35 +0200

Hi Stephen,

sorry for the latency, but I've hardly had time to review the whole
specification.

> Does this solve the problem?

From my humble point of view, just partially. As far as I understand,
you're approach is very PKI-centric. I mean, my original question was
really about how the "vague" original paragraph should be understood.

Let me explain it with some figures.

This is the scenario as far as I understood it (before you added your
clarification time):

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

You've introduced a very interesting point (more related to PKI). In
short, it's the following (please, correct me if I'm wrong):

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.

My conclusion is that the following paragraph must be changed:

With this paragraph:

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

and the rest of the contributions by Stephen

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 -

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 23 Aug 2001 11:05:11 +0200

Sorry. Some of you might have received this mail badly. I hope this
one will be received better...

===========================================

Hi Stephen,

With this paragraph:

Regards

  // M.A.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 27 Aug 2001 20:45:36 -0700

This really needs to be added as an official issue, otherwise I will 
most certainly miss it in my review of pending issues.

PatC

---

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

> most certainly miss it in my review of pending issues.

OK. I'll do it in the appropriate way

Regards

  // M.A.