On Wednesday 25 May 2005 20:27, Julien Pierre wrote: > By signing a CRL that does not include a particular cert's serial > number, or by signing an OCSP response that says this cert's serial > number is still valid, a CA makes the statement that the cert in > question is not revoked.
Surely not! That can't scale CRLs would grow without bound and OCSPs could now be used to revoke a revocation! > As I have already explained, if the CA key was > compromised, anyone could use it to make such incorrect statements . > Thus, one could never rely on this "is valid" statement. Let's break this down into small steps. Once a revocation is seen, one should never rely on a statement by that cert again. That seems fairly basic. To rely on that revocation, you have to cache it. Otherwise you are totally reliant on the online network, and that's not an acceptable assumption (see Lynn's voluminous notes on offline assumption behind PKI there). Any design should cache all revocations however they are delivered. Without caching one would be subject to phase errors, offline behaviour and issuer vaguery. So once a revocation is delivered, it's delivered. If a design were to allow itself to accept the revoking of a revocation, by whatever means, then ... it's done something that is just plain dumb. There is no way you could reliably make a statement about security in such a system, it would be like saying, well, yes, today the cert is revoked, but I need to check every time because tomorrow it might not be revoked. It's like saying "here's a signed statement that this is revoked, but it is only signed until I stop signing it....." This would so fundamentally break the offline assumption because it reduces to an online database operation that ... well, now I'm beginning to sound like Lynn ;-) > A revocation checking protocol that only would only allow an "is > revoked" response wouldn't be very useful, now, would it ? If it > existed, you would already know the answer before you made the query, so > why even make the query ? The basic concept of a revocation protocol is to ask whether there are any revocations today, right? One could ask if this particular revocation had happened, such as id=1234. But, as there is a hierarchy in operation, and as you can't see up that hierarchy, which could be 1, 2, 3, or 10 certs high, you must expect to get a set of revocations in the answer, right? If you get a set of revocations, you cache them, then try your local cache check again - recursively. If there is a root cert that revokes itself in there, no problema! Now, maybe there is something in the PKI world that said "we aren't going to do that." If there is, it looks like a bona fide blooper. Oh well, worse things happen at sea... but it would be very interesting to know what were the design and requirements and political circumstances that led up to that blooper, as when we design secure systems (which we all do from time to time), we want to avoid that failure. iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
