JH> On 30/09/14 03:30, Michael Sierchio wrote: >> There are many places where a PKI breaks - hash collisions are far >> down the list. Most internal CA implementations offer no more >> effective security or trust than just using self-signed certs - the >> objective seeming to be to make browsers not complain about the SSL >> connection. Without subsidiary CAs, good discipline about their use, a >> CRL distribution point baked into certs (or OCSP), you can only verify >> that a cert was valid when it was signed, but have no way of dealing >> with private key compromise, etc. which happens all the time. Spend >> some time thinking about revocation, cert lifespan, etc.if you want to >> make a CA "stronger." JH> On 30/09/14 03:30, Michael Sierchio wrote: >> There are many places where a PKI breaks - hash collisions are far >> down the list. Most internal CA implementations offer no more >> effective security or trust than just using self-signed certs - the >> objective seeming to be to make browsers not complain about the SSL >> connection. Without subsidiary CAs, good discipline about their use, a >> CRL distribution point baked into certs (or OCSP), you can only verify >> that a cert was valid when it was signed, but have no way of dealing >> with private key compromise, etc. which happens all the time. Spend >> some time thinking about revocation, cert lifespan, etc.if you want to >> make a CA "stronger."
Hoping this doesn't veer into a flame-fest [it's intended in the most friendly way possible.] but, I think there are two non-mutually exclusive factors at play. [Actually I'm quite sure there are more, but these are two that I see.] 1) As mentioned, operational flaws, not technical ones are often the ones that "get" people/organizations, and it's easy to focus on "technical" issues [practically exclusively] to our detriment. So, worrying *too much* about your hashing method [i.e. SHA1 vs SHA-4096] is probably a bad endeavor. The reason: A persistent threat to your organization is likely to find an operational flaw and penetrate your organization through some other means...it probably won't be by breaking SHA1. [For example you're a high value industrial espionage target.] ...BUT... 2) Say, 10 years from now, with a lot more horsepower, an attacker who just happens to have the data stream from an old session, tries to make a run at that historic data. Why would we want to make it easy for the attacker by using SHA1? Sure, the likelihood of such an attack is small, but spending at least *some* time in re-thinking how well our choices might stand the test of time probably makes sense. [20 years ago, probably a lot of people would have said. "DES - well, yeah, it's theoretically possible someone will break it, but why are you focusing on that!?!"] So, I do see merit in the question. It's not an either/or sort of game. We can chew gum and walk at the same time. [At least usually...] IMO, focusing *purely/exclusively* on operational *or* technical methods is a poor choice. Spending some time re-assessing the security of generated certs and what's currently possible and likely to work for a large percentage of clients/hosts makes sense. As I see it, even discussing all the ramifications of operational security for a particular situation is very time consuming and, IMO, really quite difficult to do well on the list since each persons/organizations needs and capabilities are so very different. Discussing technical issues tends to be a lot more modular and "easy." [And perhaps it's this ease that lulls us into spending too much time on it.] So, while I think the advice below is excellent *general* advice, I think it does a bit of a dis-service to the OP and those of us who just happen to be looking at these issues at the moment. [And it avoids answering the original question in any detail. And unfortunately, I don't have the data to impart, so I'm not doing a lot better. :) ] -Greg
