Ben,
Ben Bucksch wrote:
With OCSP, it's not a problem anymore, because the question is "is
*this* cert still valid?" not "tell me all revoked certs".
No, the question OCSP asks is not that . It is "is this cert revoked, as
of the current date" ?
Note that OCSP does not allow revocation checks for date prior to the
current date (whether of not that makes sense without secure timestamps,
is another discussion). CRLs do.
The OCSP responder is also allowed to forget about the revocation status
of any cert that's outside its validity period.
For more info on this, see RFC 2560, section 4.4.4, "Archive cutoff".
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.
Nevertheless, the X.509 and PKIX standards don't require them to
remember revocation status after cert expiration. It is allowed, but not
required.
I heard that the Archive cutoff extension was also allowed for CRLs, but
I haven't found any reference that confirms that.
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.
Sorry, but that just doesn't make sense. And old keys can and do get
lost all the time.
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.
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. There
doesn't need to be any spurious warnings for anybody.
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. That actually fits with x.500 pretty well. But
of course that would mean the end of competition between CAs, and it
would be a bad thing.
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 !
Having roots with name constraints would be much more secure - since you
couldn't have other CAs issuing valid certs for your identity.
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.
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.
The current single signature is not an extension.
Well, I guess somebody did it anyway :
http://www.freepatentsonline.com/y2008/0270788.html
sigh.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
