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

[Michael Myers <mmyers@xxxxxxxxxxxx>]

Bob,

Semantics of nextUpdate in OCSP and in CRLs are identical.  Implementors
should support an update to a CRL prior to expiration of nextUpdate on a
current CRL.

Mike


At 07:21 PM 4/20/98 -0600, Bob Jueneman wrote:
>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
>>
>
>
>
>