Subject: Re: Operational Protocols - LDAPv3

From: "David P. Kemp" <[email-masked]>
Date: Fri, 7 Jul 2000 16:40:37 -0400 (EDT)

> From: "David Chadwick" <[email-masked]>
> To: Rich Salz <[email-masked]>, [email-masked]
> Date: Fri, 7 Jul 2000 20:22:42 +0100
> Subject: Re: Operational Protocols - LDAPv3
> 
> 
> > I think it's worth adding a warning that clients who retrieve CRLs
> > without some way of verifying the server run the risk of being sent an
> > obsolete CRL.
> >  /r$
> 
> Good point. Clearly an attacker cannot create a false CRL (without 
> compromising the CA), but an attacker does have a window of 
> opportunity to use a compromised key by denying access to the 
> latest CRL and providing access to a still-valid-but-superceded CRL.
> 
> How does this text sound
> 
> "However, clients that retrieve CRLs
> without some way of verifying the server run the risk of 
> being sent a still valid but superceded CRL."
> 
> David

Professor Chadwick,

An observation and an opinion:

1. Clients that do verify the server still run the risk of being
   sent a "still valid" but superceded CRL.  The attacker just
   denies the server access to the latest CRL.

2. Using the term "still-valid-but-superceded" implies that CRLs
   have a validity period.  Certificates have a Validity period,
   but CRLs have values for thisUpdate and nextUpdate.  A CRL does not
   become invalid when the next CRL is issued, although some
   applications behave as though it does.  In addition to forcing CAs
   to populate CRLs with deliberately incorrect values for nextUpdate,
   this "CRL Validity" interpretation eliminates the ability of the client
   to decide, based on the value of information, how fresh its revocation
   information needs to be.  If CRLs are issued every hour, I might
   demand a CRL less than 3 hours old to authenticate a purchase.  When
   reading PKIX mail on the road, however, I'd be quite happy with
   whatever CRLs were available the last time I was online, say yesterday
   or even the day before :-).  If a CA issues CRLs every month, I'd
   rather be warned that, according to my application preferences, that
   CA's certs shouldn't be used for purchases.  I don't want the
   application to blindly treat them as just as fresh as certs from CAs
   who issue CRLs daily or hourly.
   
Dave Kemp

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 8 Jul 2000 23:40:05 +0100

David

thanks for the complement, but I am not a professor in the UK, just 
a lecturer

>    denies the server access to the latest CRL.

Agreed, this can happen, but the sender (particularly if its a CA or 
part of the CA administration) will then be aware of a fault or an 
attack and may be able to quickly counteract it. A user on the other 
hand will be less likely to be aware of the attack. So the risk is 
greater.

>    applications behave as though it does. 

We are playing with fine semantics here. Is a superceded CRL 
invalid or not? No, its not technically invalid, as everything it contains 
is good and true, but it is certainly incomplete (in the scenario we 
are discussing). Is an incomplete CRL invalid or not? I would say 
from a trust perspective yes, given that another CRL has been 
issued and therefore one or more other certificates have been 
revoked and I dont know which ones they are, therefore I cannot 
rely on the superceded CRL, therefore it might as well be invalid. In 
other words, for certificate X, where X is not in the list of revoked 
certificates in the superceded CRL, using the superceded CRL or 
using an invalid CRL give me exactly the same answer, viz: I dont 
know if X has been revoked or not. The superceded CRL can only 
be regarded as being valid, if X is in the list of revoked certificates. 

Conclusion. The superceded CRL is valid if it contains the certificate 
we are checking, and is invalid otherwise.

I dont need to quote the following to you, but here is what X.509 
says about nextUpdate:

The next revocation list could be issued before the indicated date, 
but it will *not* be issued any later than the indicated time. 

Therefore after nextUpdate has passed I know that a later CRL 
definately exists, and I am open to attack if I dont have it. If I dont 
have the later one, I should treat the earlier as valid for certificates 
it contains, and invalid for all others.

> In addition to forcing CAs

By this I assume you mean overly long values. There is a difference 
between knowing that another CRL has been published and 
knowing that one has not. In the later case the current CRL is valid 
for all certificates, in the former case it is not. Thus a CA that has 
failed to publish before nextUpdate expires, forces the RPs to 
assume the former when the later is the truth (which is secure but 
inconvenient to the users) By having an overly long nextUpdate, and 
publishing before it expires, those users who dont have the latest 
CRL will believe the latter whilst the former is true (which is 
insecure for the users but convenient to them.) Thus security 
dictates a CA should have a shorter nextUpdate whilst user 
convenience dictates the opposite. This phenomenon often occurs 
i.e. that user convenience is opposite to security. (You have 
probably heard about Lotus having a configuration switch to say 
"use expired certificates" as it was inconvenient to users that they 
could not check signatures with expired certificates. This is another 
facet of the same phenomenon)

>    this "CRL Validity" interpretation eliminates the ability of the
>    client to decide, based on the value of information, how fresh its
>    revocation information needs to be.

I dont fully agree with you. I think rather that it is actually a user 
interface issue and an administration issue. If user interfaces had a 
"get latest CRL now" button, a client could decide before each 
signature verification, irrespective of update period and validity, 
whether to refresh now or not. But as we stand now without this 
button, with a long update period the client believes there is no need 
to decide, and everything is OK. With a short update period the 
client may have to make a decision if his current CRL has expired 
and he does not have the latest one. And this is the administration's 
decision of how long to make the update period. Do they want to 
inconvenience the users by having short times and force them to 
make decisions occasionally, or have long times so that they do not 
need to bother ever. If you are an administrator, then you are in the 
fortunate position of being able to make this choice. Enjoy

David

>  If CRLs are issued every hour,
>    I might demand a CRL less than 3 hours old to authenticate a
>    purchase. 

It depends upon the size of the purchase. For a large one you 
would want the latest. Risk vs Size of Loss is important. For a one 
dollar purchase you probably would not bother with a CRL at all.

> When reading PKIX mail on the road, however, I'd be
>    quite happy with whatever CRLs were available the last time I was
>    online, say yesterday or even the day before :-).  If a CA issues
>    CRLs every month, I'd rather be warned that, according to my
>    application preferences, that CA's certs shouldn't be used for
>    purchases.  I don't want the application to blindly treat them as
>    just as fresh as certs from CAs who issue CRLs daily or hourly.
> 
> Dave Kemp
> 
> 

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

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

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

---

From: Marc Branchaud <[email-masked]>
Date: Mon, 10 Jul 2000 10:16:03 -0700

"David P. Kemp" wrote:
>    information needs to be.

An interesting perspective if you consider a couple of points:

 - The CA gets to decide when a revocation is important enough to issue a
pre-emptive CRL.

 - The relying party typically has no legal relationship with the issuing CA.

So the CA is under no obligation to care about the relying party's values. 
The relying party can demand the latest CRL every 10ms if he wants, but the
CA isn't necessarily going to cough up any newer revocation data.

Seems like the client never has the ability to decide freshness based on
their own values, regardless of how they interpret CRL validity.  Sure, the
client can decide "I need data fresher than the CRL issuance frequency of
this CA, so I'm not going to trust it."  Refusing to talk to other people
isn't a good way to use a network though.

Later, you do put a slightly different spin on things:

> I prefer an environment where the CA is
> incentivized to improve service - to advertise "status updates every hour",
> "every 15 minutes" or "every minute", and fastest would be unequivocably
> best.

For this to work sensibly, CAs should really ignore the provision of X.509
that says that CRLs can be issued before nextUpdate.  Although it may seem
wise to take the position that an "important" revocation warrants an early
CRL, doing so really throws RPs' trust assumptions out the window:

RP: "Gee, your honor, the CA only updates its revocation info every hour, so
I didn't see the need to check again since my CRL was only 20 minutes old..."

CA: "But your honor, this was an important revocation, so we issued an early
update to our revocation data.  We're just trying to provide the best
possible service, and since we already published the revocation, we can't be
held liable for the RP's damages."

Lovely can of big, fat wriggly worms that is.  More importantly, though, even
if the issue were resolved the client is still stuck with whatever regime the
CA chooses.  If there isn't a CA that meets the client's freshness
requirements, the client is SOL.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+