This is another easy one, like the 64-bit binaries.
NIST 800-57 stated that 1024 bit SSL keys should only be used through 2008 (so that a 2-year key expiring in 2010 would still be considered secure), yet EZproxy still allows generating 512 and 1024 SSL certificates.
I don't know of any CA's that will sign keys less than 2048 bits these days, and anything less is a false sense of security given modern computing speeds. Removing the lower bit options will help users to not generate a CSR that is going to be rejected by the CA, saving time and aggravation.
The 512 bit key is a thing of the past. Even Microsoft has effectively patched them out of existence.
Now, I personally have no problem with letting someone shoot themselves in the foot, so I'm OK with OCLC leaving the 1024 bit options there if someone just wants a self-signed SSL certificate for SSL's sake, but go ahead and give us options for 3072 and 4096 bits as well.
Why 3072 and 4096 bits? Well if you're running your own CA, it is not unheard of for those to generate SSL certificates with a lifetime of 10 years or more. The 3072-bit keys are projected to be secure until sometime around 2030. The 4096 will be secure for quite a bit longer. If your internal CA is generating 15 year keys, you should already be planning the move up to 4096 bits.
And some of us just like big bits, and I cannot lie.
Oh, and while we're on the topic of SSL, making a pass through section 4.2 of NIST 800-57 would be a good thing for OCLC to do, and enabling/disabling cipher suites as appropriate. After all, if we're going to use SSL, we should at least be getting the best bang for the buck from it.
Bonus points if a directive akin to Apache's SSLCipherSuite is added to tune the SSL ciphers in play. There is always the possibility that a weakness could be found in a cipher, and being able to disable them individually would be a good ability to have.
No comments:
Post a Comment