[Ach] Algorithm Check on Path Validation?
iang at iang.org
Sat Jan 25 21:22:27 CET 2014
On 25/01/14 21:12 PM, Rainer Hoerbe wrote:
> A potential problem with weak CA signatures (using RSA 1024 and/or MD5) will remain for some time. According the the current cab policy RSA 1024 and MD5 have been banned only for certificates issued from 2011 onwards.
I think ordinary MD5 is already out. What is allowed now is MD5+nonce.
Which is fine into the distant future as it rules out the collision attack.
> Certificates with lifetimes of 5 or 6 years (like Go Daddy Secure Certification Authority, or a-sign-SSL-03) will weaken the PKI-ecosystem until 2016 (or later, if some CP allow for that).
> As a mitigation these CAs would have to disappear from the hardened crypto universe. What are the options?
> 1. remove the weak ones from the trust list in advance:
> 1.1 eliminated root CAs that use weak self-signing algorithms
There's no such thing as a root CA weak self-signing algorithm. The
signature is on the cert only in order to turn it into a cert; all
security for a root CA is derived by its position on a root list, not on
any cryptographic properties on the signature.
As a practical non-security issue, eager beavers in the browser world
are deprecating MD5 for *everything* without resort to its still good
non-collision properties. So they are in effect dropping it for root
CAs as well. Oh well.
> 1.2 find out popular intermediate CAs and apply the same
> 1.3 check CPs to find out those that create weak end entity certs
(These two steps are being conducted by Browser Vendors and/or CABForum.
> 2. Limit the trust store to a small number of ... CAs
Now we're talking ... So, who gets dumped?
> 3. check for algorithms during the cert path validation
(That's tech, not config. Interesting but out of scope here.)
> Re 1. The first step (1.1) seems to be quite feasible to do, but does not really protect agains weak certificates down the chain. Intermediate CAs may be discovered dynamically, so weak intermediate CAs or those issuing weak end entity certs are hard to protect against.
> Re 2. As already discussed on this list, this is probably more complicated than making long-lasting peace in the Middle East.
> Re 3. I am not aware of tools that would do this. Yes, one could write some mod_ssl_extra_path_val, but that seems to be more than a lost weekend.
> BTW, the NIST Path Validation Test Suite (PKITS) does require products to use only SHA-256 for signatures. But it is only applicable to a subset of vendors supplying the US federal government (the IBM/Oracle/Entrust/etc. world).
(Everything NIST does is oriented towards the USG for crypto at least.
It's their mandate. They don't do industry ... why is anyone listening
to them? I have no idea...)
> Any ideas?
Relax. Ignore NIST, ignore CABForum. Just so we're not accused of
racism or xenophobia, ignore all other standards bodies. Those guys are
high on their own cryptographic numerology. If they were actually
interested in security they'd be telling the browsers to sort out their
They're not doing that. You might note that friends of theirs are
implicated in spear-phishing attacks against the browsers'
non-security-UIs. LinkedIn is repeatedly mentioned. Nobody wants to
stop the party, everyone's courting the sex, not watching the alcohol
Remember, nobody's crunched 1024 as yet. When they do, it's only one
RSA key... MD5 was collision attacked in around 2005. It wasn't until
2009 or so that Jake&friends did a collision attack on a root cert using
More information about the Ach