[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: serial numbers // push/pull CRL's
At 02:34 AM 4/7/97 -0400, J. Lasser wrote:
>On Apr 7, Carl Ellison <email@example.com> wrote:
>> The soap box I keep getting on is that you can not say "oops". You can not
>> issue a general CRL which tells the world that a given certificate is bad
>> because you have no guarantee that someone who has that cert will ever be
>> in touch again to discover there's a CRL, unless you force him to.
>While the technical reasoning behind this issue is clear, and clearly in
>favor of your point, this is unfortunately not real-world functional. Just
>about every contract on the planet, from a software package's shrinkwrap
>license to a lease on a house to whatever else is for a given length of time
>_UNLESS_ certain conditions are violated.
>While from a technical perspective you're absolutely correct, it's rather
>counterintuitive (like the is-a-person vs. is-a-key identity issue). I'm
>afraid that making counterintuitive decisions like this is bound to affect
>the willingness of people to implement the standard.
the online test provision is for this condition testing.
To restate my soapbox issue in firmer security terms, you mustn't allow the
enemy to prolong the apparent validity of a certificate you have revoked
merely by selectively blocking your communication. Having the certificate
require fetching of a CRL, having the CRL signed and having the CRL carry a
validity interval turns this into something the enemy can't trivially defeat.
For example, an online test which might fetch such a CRL could be:
(online <uri> crl <public-key> <serial #>)
and that could be a field of the certificate. The <public-key> would give
the public key of the CRL service while the <serial #> would give the ID
by which this cert would be found in the CRL you get from <uri>.
It's the wandering anti-matter CRL I'm bothered by, not one which
arrives as a response to an online test.