Ian G wrote:
Revocation checks cannot be done at the root level, by definition. The
standards don't allow support for revocation checking of self-signed certs.
Oh... so it's written in the standard. Are you
saying that the standard defines no way to revoke
a lost CA root? Or that it is impossible to revoke
a CA root? They are two entirely different things.
I'm saying the standard defines no way to revoke a lost CA root, because
it doesn't make sense. When a root is compromised, there is no PKI
standard that can fix this.
Yes, of course anyone can make a fake product
once they have the root, which is why the revocation
(signed by the same key) needs to be distributed.
Presumably once a revocation is sent around the
place, it is sticky, it itself cannot be revoked?
revocations are only effective until cert expiration . After that, they
are irrelevant. Nobody is supposed to use a cert after its expiration,
including a root cert.
OCSP responses typically are not persisted by clients beyond the life of
the process, whereas CRLs often are. Currently, Mozilla/NSS only uses an
OCSP response once, at the time it's received, in the context of a given
revocation check, and then it's thrown away immediately. There is no RAM
cache or persistent cache. CRLs on the other hand are stored to
cert8.db/cert8.dir . Only one CRL per issuer gets stored ; newer CRLs
replace old ones.
Please explain why a self-signed certificate cannot
sign a revocation of itself? It's not as if you care if
a thief does it to you...
Because that statement would offer no assurance if it came out as
negative (not revoked response).
If the root is compromised, then the root key thief is always going to
make that statement come out as not revoked, unless he is incompetent.
Thus, checking for that statement is useless. It offers no benefit over
not making a check at all, because a negative is no guarantee of
anything whatsoever.
You need to check for the state with another party that you trust. But
there is no one above the root. Thus, you need to resort to external
mechanisms, such as manual user revocation / disabling of roots, or a
software update (you trust the manufacturer of the client ...).
OK, so maybe a more likely path is to simply roll out
a new root, patch the browsers as I described, and
watch and wait for the phishers to use the root.
Leaving a lot of users vulnerable in between. It's much better if the
root in question is never added. The risk level can be assessed based on
the security measures in place to protect the root key. If one of the
root keys is in a software token on the hard drive of somebody's laptop,
then obviously it isn't very secure ;-) ... This is in part what
Webtrust is about.
Do you mean to say that you could issue instructions
to users such that they remove certain roots from their
root lists?
That's possible, but wouldn't be ideal.
Sure, that's another path, might be easier
than patching, yes, and you could issue the new root
at the same time.
An automated process is preferrable, IMO, if it is a secure one - eg.
if the software update is signed by Mozilla's root key .
But as you point out, that doesn't cover the merchants
who are still using the old certs. I guess the CA simply
has to mail them out and hope for a faster half life.
If a root key is compromised and made public, anybody can create server
certs and setup fake servers for anyone they like ... And nothing will
stop them automatically until the root expires, or the client software
is updated.
One could make the root checking work in a standards-compliant way by
having a single trusted root in the browser - mozilla.org's. All the CA
certs that are currently roots could be replaced by certs issued by the
mozilla.org CA, which could distribute its own very little (hopefully
zero-size!) CRL . But the cost of hosting the CRL or OCSP server in that
case would be prohibitive - every client in the world would need to
access either one . Ultimately though, the size of the that's what you
need if you want to do revocation checking on "roots"
Well, either CRL/OCSP works, or it won't work for Verisign
who have about half the market. If these things don't
scale, then there is a need to think up other ways to deal
with it.
It can work, but it will be expensive. Verisign can afford it ...
mozilla.org probably cannot.
Also, the current roots would probably object to their demotion to mere
mozilla.org intermediate certs . They would probably sue for copyright
infringment on their public key or something ;) .
And of course, in this scenario, the risk would remain that
mozilla.org's root would be compromised . But the risk is much lower
when you only trust 1 root rather than 75 ! It only takes 1 compromised
root for the whole system to fall apart.
That of course is one way to look at it. I'm sure
Netscape had some good reasons not to become
the meta-CA when they got into the PKI biz.
The reasons probably had to do with liability, as they were a business.
With the current situation and mozilla.org, it might make sense to
distribute the updated "roots" that way. No new code outside of regular
PKI would need to be written to verify the software update if they did
that. They can just sign the software/root updates with the mozilla root
key. It could all be very seamless. I haven't checked the format of the
windows root updates, but it's got to be signed as well ...
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
