Ian,
Ian G 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!
There is no process to unrevoke a cert, only to state whether the cert
is revoked or valid at a current time. Valid certs don't add to the size
of a CRL at all, since their serial number is simply not listed on the CRL.
CRLs don't grow without bounds, because the CAs can drop the revoked
certs from the CRLs as soon as the cert expires, ie. when the CRL
thisUpdate is after than the cert's notAfter field.
CAs are allowed to keep the certs on CRLs longer, even indefinitely if
they wish, but they are under no obligation to do so according to the
standards.
Certs can never be unrevoked. It is against the standard for a CA to
attempt to do so. But there is no way for the client side to enforce it.
The client trusts the CA to follow the standard. A client doesn't
necessarily know about yesterday's CRL or tomorrow's CRL to see that a
serial number got dropped from the CRL before the cert expired.
All that the client sees is an ever-changing list of serial numbers
between two CRLs issued at different dates. Unless the client has a copy
of all the certs for all those serial numbers, it can't check if the
serial numbers were legitimately removed from a CRL due to expiration,
or because the CA violated the spec by "unrevoking" the cert. With OCSP
the story is the same - if you make a query for an expired cert's serial
number, the response is undefined. Ie. the responder could have deleted
the revocation information due to the expiration of the cert, and deem
the cert valid, but that is besides the point, since the cert is expired.
If a CA attempted to do that, its issuer should revoke the CA cert.
Again, you can see that it's not possible if it is a root.
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.
That's simply not true. The OCSP standard works perfectly fine in an
online environment with no caching as well, minus performance
considerations - the cost of sending queries to the OCSP server and
getting responses from it . If the server is not available at a given
time, the client can simply choose to temporarily not validate that cert.
If the CA server cert itself is compromised (the one that signs OCSP
responses), then the client will find out when asking the issuer if the
CA cert is revoked. That can't work if they are one and the same - ie. a
trusted self-signed cert (trust anchor).
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.
Local caching is a performance consideration for clients. It is neither
required nor disallowed. A security protocol must keep working at any
given instant. It cannot depend on caching.
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 client knows that once revoked, a cert is always revoked. But if the
client is only interested in a single verification operation, it does
not make sense for it to do caching. It is a performance optimization in
case it needs to do another verification.
The basic concept of a revocation protocol is to
ask whether there are any revocations today, right?
No. The purpose of a revocation checking protocol is to determine if an
entity cert is still valid.
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!
The fundamental problem is one of trust. You cannot trust a cert to make
any particular statement about itself. You can only believe someone else
that you trust to make that statement. If there is no one else, then
there is no possible statement.
_______________________________________________
Mozilla-security mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-security
