Subject: Re: Operational Protocols - LDAPv3

From: "David P. Kemp" <[email-masked]>
Date: Mon, 10 Jul 2000 17:32:32 -0400 (EDT)

> From: "David Chadwick" <[email-masked]>
> 
> > > Conclusion. The superceded CRL is valid if it contains the
> > > certificate we are checking, and is invalid otherwise.
> > 
> > This conclusion depends on some assumptions: all clients have the same
> > revocation freshness requirements, those requirements don't depend on
> > the value of the information being processed at the time, and the CA
> > is the controlling authority for how often clients must check CRLs.
> 
> Sorry David, I disagree with you on the above. They are irrelevant 
> in my opinion to the statement I made. However, they may be 
> relevant to the client (who is choosing to ignore the fact that a later 
> CRL is available, but that is its choice. The fact still stands that the 
> old CRL is not fully trustworthy (or valid) in an absolute sense. But it 
> might be good enough for the client.)

Assume CA "A" which issues scheduled CRLs every day, but will issue
an unscheduled CRL within 3 hours of receiving a
revocation-for-compromise request.  Assume CA "B" which issues
scheduled CRLs every hour and no unscheduled CRLs.

Assume a client which fetches a CRL every three hours, regardless
of nextUpdate.

                               client             client
                                gets     com-     validates
             CRL A     CRL B    CRL     promise   cert X
             -----     -----    ----    -------   --------
thisUpdate:  t         t        ***
nextUpdate:  t + 24h   t + 1h

thisUpdate:            t + 1h
nextUpdate:            t + 2h

thisUpdate:            t + 2h           t + 2h
nextUpdate:            t + 3h

thisUpdate:            t + 3h   ***
nextUpdate:            t + 4h

thisUpdate:            t + 4h
nextUpdate:            t + 5h                       t + 4h

thisUpdate:  t + 5h    t + 5h
nextUpdate:  t + 24h   t + 6h

thisUpdate:            t + 6h    ***
nextUpdate:            t + 7h
                        .
                        .
                        .
thisUpdate:  t + 24h   t + 24h   ***
nextUpdate:  t + 48h   t + 25h

What you are saying is that the client which fetches CRL A is always
using an up-to-date CRL which is fully trustworthy (valid) in an absolute
sense.  But the same client which fetches CRL B is two thirds of the
time using an old (superceded) CRL which is not fully trustworthy
(invalid if the cert it is looking for is not present).

I respectfully disagree.  CRLs are not "valid" in any absolute sense,
they are only "fresh" or "stale" in an absolute sense.  CRL B (issued at
t+3h) is, despite being superceded, fresher than CRL A at time t+4 hours.

Put another way, clients can use nextUpdate (or not use it) however
they see fit in fetching information from a repository.  But the only
value that has any security relevance is thisUpdate -- the time after
which revocation events will not be reflected in the CRL.

Regards,
Dave

---

From: Rich Salz <[email-masked]>
Date: Tue, 11 Jul 2000 10:15:10 -0400

> which revocation events will not be reflected in the CRL.

I agree with this.

I also believe that, if the connection to the repository is
authenticated,
then a client can detect "old data" attacks.  It is worth noting this
in the RFC.

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 11 Jul 2000 17:14:37 +0100

> which revocation events will not be reflected in the CRL.

This is surely flawed, for example for e-commerce transactions. 
thisUpdate can only ever be in the past by definition (it can never be 
in the future). Thus a RP can never be sure that the current sender 
of the e-commerce transaction has not been revoked, so who takes 
the hit if he has been and a CRL has or has not been published that 
reflects this?

I think that nextUpdate is important from a liability perspective. If a 
client (RP) uses a CRL after nextUpate time has past, thus 
KNOWING that another one has been issued, and fails to get it, 
then the RP must take the loss if the current certificate has been 
revoked.

If the RP uses a CRL before nextUpdate, when another CRL has 
been issued but he did not get it, again he must take the loss as he 
could have checked if he wanted to. But this is perhaps in the area 
of worms that Marc referred to in his email, depending upon the 
exact meaning of nextUpdate (not before, or not after - the 
standard says not after, which I support. You seem to be saying 
not before).

Finally we have the case of using a CRL before nextUpdate, when 
no other CRL has been issued, but a certificate revocation notice 
has been sent to the CA but it is holding it until the next CRL is due 
to be published. Thus no RP can ever know that the certificate has 
been revoked (without OCSP that is). I would suggest that the CA 
takes the loss in this case. Otherwise if you are suggesting that this 
is still the RPs responsibility it would seem to me that few e-
commerce transactions will ever be instant (except in cases of low 
value transactions) because the RP will wait until it gets a CRL with 
thisUpdate AFTER the time of the transaction.

David

> Dave

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************