Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years
On 2012-05-02 12:23 AM, Peter Gutmann wrote: Thor Lancelot Simont...@panix.com writes: NIST says 2048 bit RSA keys should have a 3 year lifetime. Who here really wants to explain to customers (or investors!) that he willfully ignored that recommendation and just reused the same old key when making the CSR for that new certificate? This is standard practice in a significant chunk of the industry, to the extent that renew a certificate means get the same key recertified. You don't wilfully ignore NIST recommendations, you click on renew certificate. Dealing with cert rollover is painful enough already without having to try and find PKI documents you've never heard of telling you what to do. That certs are painful, means they will be done wrong. Despite numerous assurances that certs are easy, and I must be a complete idiot to find them difficult, I have never found them easy, and I have been the certificate guy in various companies because every single other person in the company found them more difficult than I did. Rather than having an elaborate and disfunctional certificate revocation system, if certificates are needed, what is needed is a system where certificates have an expiry time of a week or so, and a new key is auto generated and certified every week or so if humans do nothing about it and know nothing about it. Of course, attempting to implement such a system immediately brings us to the fact that the certifying authority does not know the people it is certifying, nor what it is certifying, which is why certification is difficult. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years
The idea of using fresh certs (not necessarily short-lived) came up in the TLS WG list in the context of the OCSP multi-stapling proposal. So far the most important objection to fresh-lived certs was that it exacerbates clock synchronization issues, but I'm willing to live with that. Short-lived certs would be much easier to implement than OCSP multi-stapling. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years
On Tue, Apr 24, 2012 at 12:07:33PM -0500, Nico Williams wrote: On Tue, Apr 24, 2012 at 11:20 AM, Marsh Ray ma...@extendedsubset.com wrote: On 04/23/2012 08:47 PM, Peter Maxwell wrote: I look at it this way: * Revocation is junk. It doesn't work. It especially doesn't work when an attacker wants it not to work. It is so broken that Chrome isn't even going to bother with OCSP checking anymore: http://www.imperialviolet.org/2012/02/05/crlsets.html But this too is revocation. Assuming some revocation scheme works at all, then longer lived certs merely increase the size of the revocation database. This is at least obnoxious. If no revocation scheme works then the only revocation mechanism left is certificate expiry. Until now no revocation mechanism has worked well or universally, so shorter certificate lifetimes are better. That said, short certificate lifetimes do nothing to mitigate undetected private key compromises when the new certificates have the same subject public key as the ones they replace. That said, those who follow the relevant NIST recommendations will not do that (reuse keys when writing new certs). The recommendations on cryptoperiod are with regard to keys, with a recommendation per algorithm, and though there are many ugly holes punched in the standard for commercial PKI implementations, I do not see one that would allow writing a new cert with an old key if the old key is past its allowed cryptoperiod. NIST says 2048 bit RSA keys should have a 3 year lifetime. Who here really wants to explain to customers (or investors!) that he willfully ignored that recommendation and just reused the same old key when making the CSR for that new certificate? Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Symantec/Verisign DV certs issued with excessive validity period of 6 years
On 23 April 2012 22:41, Marsh Ray ma...@extendedsubset.com wrote: Thought the list might be interested in this little development in the PKI saga. Do you all agree with my assertion that No one with a clue about PKI security would believe that a revoked cert provides equivalent security from misuse as a naturally-expired cert. ? - Marsh With current client implementations, I agree your statement does hold. I do however disagree with your general premise that six years is too long. Say two companies, A and B, have adopted similar security practices and assume the probability of a cert compromise in a given year for one of them is roughly one in ten thousand, p_yr = 0.0001 Company A has their cert issued with a two year validity, so their probability of compromise is p_2yr = 1 - ( 0. ) ^ 2 ~= 2.10^-4 Company B has their cert issued with a six year validity, so their probability of compromise is p_6yr = 1 - ( 0. ) ^ 6 ~= 6.10^-4 In other words, it makes not a jot of difference to company B: they may be roughly three times more at risk than company A but that's still only a six in ten thousand chance, say. Even if the original p_yr were higher, say one in a thousand, it still doesn't merit any concern for the individual company. If we then turn our attention to the system as a whole: assuming we look at all certificates, does extending the expiry period help reduce the impact on users? Well, actually, counter-intuitively it does not. The rationale is as follows... i. assume at any given time, some rate of compromise of all available issued certs, r; ii. assume also that most certificate forgery is to steel money or commit fraud, so there is an incentive to act quickly and the outlier cases of long-term attacks can be discounted for now; iii. further assume that the maximum time of utility for the attackers to use the cert in ii. is approximately a day. It immediately follows that for a whole-system expiry period of two years the attacker is impeded and r is reduced by roughly 1 / ( 2 . 365 ) = 0.13%. For expiry times of six years that changes to a reduction of 1 / ( 6 . 365 ) = 0.05%. That's a fairly marginal result and if we assume the attacker(s) know(s) this, they will simply avoid tackling certs near expiry, rendering the difference null. So does the expiry period actually matter that much? Intuitively yes, rationally, no. Regards, Peter ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
