First off, please note that this is a proposed *change* to the PKI
system. A small change, but nevertheless a change, yes. We're trying to
make it more secure. So, "That goes against current definitions" is not
an argument, it's inherent.
No, the question OCSP asks is ... "is this cert revoked, as of the
current date" ?
That's what we need, yes.
The OCSP responder is also allowed to forget about the revocation
status of any cert that's outside its validity period.
Our CAs would not be allowed to do that. It's fairly trivial to keep the
whole list.
It's not going to grew over a Gigabyte, any MySQL could do that.
Including the replication to have it redundant.
Thanks for the note, though.
[Key continuity by old key signing new one]
When someone chooses to use a new key, they can simply get a new
certificate containing the public key and get it signed by the CA.
Currently, yes. But so could anybody else in the world who manages to
get past the CA. And immediately get access to all customers. (See below)
This is what I consider the inherent and most important weakness of the
PKI system, what makes it impossible for me to trust it. This is exactly
what this proposal is supposed to stop.
The warning, in turn, ensures that you cannot just walk to *any* CA,
without any connection to the victim site, and get a valid cert. It
*has* to be signed by the private key, which means the attacker *has*
to break into my systems.
You could also solve that problem by having only one trusted root, or
having roots that use name constraints. Then everybody would have only
one CA they could go to.
No. If that one CA then doesn't do a decent job, makes an error, that's
no help either.
With "connection to the victim site", I meant that *I* (as cert owner)
have to be involved somehow in approving the certificate when it wants
to be valid for my existing users. "Involved" includes my site being
hacked, but that's at least something I can influence to some degree.
I have absolutely no control over how a CA does it job.
I don't want it to get into the middle of my *existing* relationships,
that's the core.
This means that if I can manage to keep my systems secure, there's
really no way an attacker can get between me and my existing users /
communication partners. This is as secure as it gets. (If an attacker
breaks into one of the partners' systems, all bets are off, in any
system.)
Given what we know about warnings and how they are ignored by most
users who don't understand them, I certainly wouldn't put too much
faith into that !
If you assume that users ignore and override all warnings, we are
already screwed with the current system, because the user can also
override a self-signed cert. Yet, that warning is now a serious stopgap
for attackers of a bank. And it definitely helps security-conscious users.
If one wanted to have another signature, it wouldn't be as an
extension, since, as Nelson pointed out, extensions are part of what
gets signed.
Yes, sorry for the inprecision, I meant here "extension" in the sense
that it's something added to the cert definition, not the existing
extension mechanism.
The current single signature is not an extension.
Well, I guess somebody did it anyway :
http://www.freepatentsonline.com/y2008/0270788.html
Thanks for the link.
What I am thinking of (which I think is different from that patent) is
that we attach something to the end (or beginning) of the binary blob
that is the cert, in a way that it treated as garbage by older browsers.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
