Re: Security section of draft-ietf-pkix-opp-ftp-http

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

> From: Paul Hoffman / IMC <phoffman@imc.org>
> 
> At 11:26 AM 4/21/98 +0300, Moshe Litvin wrote:
> >The problem you describe is inherent to CRL and not to the distribution
> >method.
> 
> I disagree. If I send a request to a CA for the latest CRL, and I might get
> an old response if I use HTTP but am sure to get a current response if I
> use FTP, then the problem is in the distribution method.


I agree completely with Mike on this one.  The CA signature on a CRL
(or OCSP response) allows the use of unreliable repositories.  FTP is
no more or less reliable a protocol than HTTP, it's just that the
use of caching proxies is more prevalent with HTTP (caching FTP
proxies do exist).  In addition to inadvertent errors due to caching,
one must also consider deliberate manipulation of repository contents,
which could result in a superceded-but-still-valid CRL being used.

Mike left out the obvious solution to the problem: just don't do it.
PKIX does not prohibit CAs from issuing CRLs before the nextUpdate of a
prior CRL, but the policy of individual CAs should take into account
the trustworthiness and reliability of the distribution mechanism when
deciding how to set nextUpdate and whether to ever issue interim CRLs.
The no-brainer approach is to assume that revocation distribution is
completely untrustworthy and expire the revocation information often
enough that there is no motivation to issue interim information.

Carl Ellison has a colorful description of CRLs which are not required
by the verifier: wandering anti-matter which may or may not happen to
collide with the revoked certificates in time to prevent them from being
used.  PKIX should not encourage the "statistical revocation" approach,
and should point out the dangers of using it, as Paul has done in his
Security Considerations text.

  Dave Kemp