Peter Hesse wrote:
Is there anything that could be added to RP software to reliably
detect and thwart the use of a rogue CA certificate? Or would
any attempt to do that just cause too many problems?
Since MD5 is known bad and potentially dangerous at this point, I would
suggest that the best client side action would be to fail to verify any
signatures created using MD5. This will break some things, especially if
existing business processes are relying on a certificate signed with MD5.
However, it is a fail-safe and would prevent a rogue CA certificate created
in this fashion from being considered trustworthy.
And to Santosh's point (and others), my earlier email about
removing/replacing trust anchors was not because the self-signed
certificates are signed using MD5; I agree the trust anchor public keys are
protected using other mechanisms. I am recommending that if CAs do nothing
to prevent this kind of attack (non-random serial numbers, issue
certificates signed with MD5, issue certificates in an automated,
predictable fashion) that those CAs should be removed from trust lists
because they are no longer acting in the interest of the relying party--they
are an accomplice to the creation of these rogue certificates.
This sounds great at an IETF mike, but out in the field how do you get
all those millions of browsers to pull down a new trust list that will
no longer include CA foobar?
Can't happen now, and the way things are going, ain't going to happen
before 2026 either.
So what tool do we have to get compliance to best practices? The good
old 5th estate, get out their and give bad press to foobar until they
fix their behaviour or their business model collapses and they go out of
business and can no longer issue potentially rogue certs.
We can talk and posture all we want in the IETF. We are rather good at
that, IMNSHO. But this is perfect proof of our impact as such on the
business model of companies that use our technology; they will do what
is expedient, not what is Best Practices.