On Friday, 16 August 2013 12:01:51 UTC+3, Gervase Markham wrote: > On 15/08/13 11:22, Mikko Rantalainen wrote: > > > No. The site's public key does not need to be changed to request a > > new certificate. > > Technically, no. But there are other occasions on which it does - key > length upgrade, cert private key loss or compromise (or possible > compromise). In the current system, none of these things have to bother > the user.
Perhaps I'm not an average user but I would like to be informed about changed key in all those cases. > > 2 year certs if time limit increases security? Why not issue a new > > signature every day and be done with broken revocation lists?) > > 1. That's what OCSP is. The equivalent of a new signature every few minutes. Yeah, and the browser support for this is approximately zero. Certificates served by the server itself would work with all user agents today. Sure, some servers make updating the certificate a bit too hard to do automatically or every day, but fixing the servers is a lot easier than fixing all the user agents. > 2. Limited cert lifetimes mean that if an algorithm starts to look dodgy > (e.g. as MD5 did) we can move the industry to new algorithms without > having to worry about 20-year end-entity certs. This is why we have been > pushing in the CAB Forum for shorter max cert lifetimes. It's the CAs > who want longer lifetimes! As long as the CA key X is signed with algorithm Y and its lifetime is N years, there's no additional security for signing chained keys for shorter lifetimes. For example, if a CA has 2048 bit RSA key with self signature using SHA-1 and lifetime of 20 years, it really does not matter if chained server keys have better algorithms and longer key lengths. If we really believed that shorter lifetime is required for the keys, we would be replacing those CA keys already. As far as I know, the problem with SSL/TLS certificates is inadequate verification done by the CAs or leaking the whole private key, not the key strength. -- Mikko _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
