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

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Michael, I'm not entirely sure I agree with your semantics. 
Maybe I've missed something, but I always interpreted 
the traditional CRL nextUpdate semantics to mean "if you 
haven't gotten an new CRL by this time, you are potentially 
missing something", not "I'm not going to have another 
word to say on this subject until this time, even if the world 
is about to come to an end."

In other words, I believe that a CA (at least some CAs) 
would feel that they are allowed, and perhaps even 
compelled, to issue a CRL PRIOR to the time of the 
nextUpdate, especially in the event of a known key 
compromise. Certainly I would take my business elsewhere 
if a CA or repository would not provide me that service.

I haven't followed the OCSP discussion that closely, 
I'm afraid, but surely the semantics haven't changed
all that much?

bob

>>> "Michael Myers" <mmyers@verisign.com> 04/20 5:36 PM >>>
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
>