On 08.01.2009 23:15, Nelson B Bolyard wrote:
I encourage people to read through that bug, especially the early
comments, before contributing here. (The later comments are mostly "me
too")
Esp. because the first are from you (and are dissenting, and therefore
important, while agreeing comments are just "me too", right?).
* Require website owners to continue using the same private key.
This flies in the face of best current practices.
I think the current practices, of the whole PKI system on many levels,
are extremely bad.
Please be specific and rational in your arguments. "This is how we're
doing things so far" or "This is how this system was defined" is not an
argument.
Certs expire for the same reason that credit cards do. Do you
understand why that is?
No, quite frankly, I do not.
First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013.
My GPG key expires in 10 years or something, and it hasn't been any
problem. My SSH keys also never expire, and that's good. The CA root
certs don't expire for 20 years.
If the private key on the server is secure, all is fine. If somebody
breaks into the server and the private key gets known to the attacker,
it's being revoked.
It means that a CA's list of revoked certs will grow boundlessly. It makes
CRLs become impractically big.
With OCSP, it's not a problem anymore, because the question is "is
*this* cert still valid?" not "tell me all revoked certs".
It requires that CAs NEVER "forget" about any certs they previously
issued, not even after they expire.
They get paid for it, for each cert. Hotmail and Yahoo also never forget
the email addresses that were issued (they may get deactivated, but the
account still exists), and it's not even a paid service.
This is what GPG
does, too. This shows us that the new key is authorized by the old
owner, so continuity is maintained.
So, after a key is compromised, it remains desirable that replacement keys
are authorized by a signature made with the compromised key?
Yes. It - at worst - means that either rightful owner or the attacker
endorses the new key, reducing the candidates from the whole world to
two. The CA needs to approve the new key as well, though, so the
attacker has to gain *both* the old private key and get the approval of
the CA.
More importantly, it helps the normal situation that a the owner decides
to use a new key, for whatever reason, and prevents a spurious warning
for users in that case.
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.
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.)
CAs and their verification processes are currently a potential
vulnerability, even if my systems are entirely secure. They would no
longer be for me and my friends.
Is it technically possible for a cert to have two or more signatures?
No. X.509 certificates do not have multiple signatures.
No, because the content of all extensions are included in the computation of
the signature.
Can we create another extension? The signature itself is a shell around
the certified bits. Add the second signature around that first signature.
There must be a way to add signatures. It's a base feature in PGP! If
it's entirely impossible to have two signatures, and no way to add it to
the spec, that's a design error. It's hard to believe that it's so limited.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
