On 08.01.2009 22:09, Ben Bucksch wrote:
* How to deal with cert expiry
A possible solution (already posted in comment 18 in the bug):
* Require website owners to continue using the same private key.
* A fingerprint of that private key is put in the certificate.
* We store on first site: host, port, cert fingerprint, private key
fingerprint
* After expiry of the cert (even now, only the cert expires, not the
private key), the web site owner requests another cert from the
CA, which certifies the same private key for another year, with a
new certificate.
* We see that the private key stayed the same, and we're happy -
it's the same party. We can implement "KCM".
* Revocation in case of key loss via CRL or OSCP is still possible.
* If, for some reason - be it key stolen, cryptographic weakness, or
that the admin prefers to generate a new private key all the time
- the private key changes, the public cert *must* also be signed
by the old private key, in addition to the CA. This is what GPG
does, too. This shows us that the new key is authorized by the old
owner, so continuity is maintained. The CA certification shows
that it's not a fraudster who stole the private key.
The only problem is if the admin is ignorant of this new scheme and does
not sign the new cert or the private key is lost insofar as the admin
cannot find it anymore. This is a separate discussion, see thread opener.
Is it technically possible for a cert to have two or more signatures? (I
think it is - if I'm not mistaken, a cert can also have both MD5 and
SHA2 signatures.) If not, can it be added by extensions?
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
