Subject: RE: Operational Protocols - LDAPv3

From: "Miklos, Sue A." <[email-masked]>
Date: Mon, 10 Jul 2000 10:33:00 -0400

Forgive what may be an ignorant question, but if the client 'verifies' the
server, does that indicate some form of two-way strong authentication? 

we ran into issues when trying to require two way strong authentication.
The client required a crl to complete the path processing on the signed bind
response from the server. (this is my understanding of 'verifying' the
server) 

Subsequently, it was easiest to allow unauthenticated reads to retrieve CRLs
at start up.

If there's a more effective way to achieve this, please advise.

Regards,
Sandi Miklos 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, July 09, 2000 11:31 PM
To: [email-masked]
Cc: Kemp David P.; [email-masked]
Subject: Re: Operational Protocols - LDAPv3

     Comments below:

"David Chadwick" <[email-masked]> on 07/08/2000 06:40:05 PM

Please respond to [email-masked]

To:   "David P. Kemp" <[email-masked]>, [email-masked]
cc:
Subject:  Re: Operational Protocols - LDAPv3

> Professor Chadwick,

David

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

[Tom Gindin] I'm sure you would be at least an assistant professor in the
USA.

>
> An observation and an opinion:
>
> 1. Clients that do verify the server still run the risk of being
>    sent a "still valid" but superseded CRL.  The attacker just
>    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.

> 2. Using the term "still-valid-but-superseded" 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.

We are playing with fine semantics here. Is a superseded 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 superseded CRL, using the superseded CRL or using an
invalid CRL give me exactly the same answer, viz: I don't know if X has
been revoked or not. The superseded CRL can only be regarded as being
valid, if X is in the list of revoked certificates.

[Tom Gindin] Actually, if X is in the list but its reason is
"certificateHold" its status is no more final than if it were not in the
list.  Of course, the RP will refuse to trust it when he possibly should,
which is less of a security flaw than the other way around.

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

[Tom Gindin] My conclusion is only slightly different: the superseded CRL
is trustworthy if it contains the certificate we are checking and that
certificate does not have either reason "certificateHold" or reason
"removeFromCRL", and is not fully trustworthy otherwise.  The term "valid"
here gets into the semantic debate above.

(snip)

****************************************************************************
*
This confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
****************************************************************************
**