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

["Michael Myers" <mmyers@xxxxxxxxxxxx>]

Paul,

One the primary reasons a CRL is signed in the first place is to relieve any
repository containing them of security requirements.  A certificate
processing system determines that a CRL is expired by examining nextUpdate.
This value is protected by CA signature, not by presumptions of the
functional correctness or assurances provided by the security architecture
of the repository.

If a repository provides an old CRL instead of a new CRL, then one of two
cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
with respect to the current system time of the certificate processing
software or it isn't.  If it is, an exception condition should be raised.
If not, the information in the old CRL is still reliable.

Mike


> -----Original Message-----
> From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On Behalf
> Of Paul Hoffman / IMC
> Sent: Monday, April 20, 1998 3:11 PM
> To: ietf-pkix@imc.org
> Subject: Security section of draft-ietf-pkix-opp-ftp-http
>
>
> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
> the Security section is incomplete. Specifically, it doesn't mention the
> hidden security problems that HTTP proxy caches can introduce. I propose
> that the following be added to the Security section:
>
> The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
> for repeated requests for URLs. Although RFC 2068 carefully specifies how
> HTTP proxies should work, there are many non-conformant proxies in use on
> the Internet. A non-conformant HTTP proxy can have serious security
> implications for requesting CRLs. If a new CRL is issued before the
> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the
> requestor
> an older CRL, the requestor will get wrong revocation information and will
> have no way of knowing that the information is out of date. CRL
> distributors following this specification have no way of forcing
> the latest
> CRL through to a requestor.
>
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>