Hi Paul,
Just to repeat it one more time: #3 does not prevent the
published attack.
It does if the random fluff is inserted by the CA. The
attack depends on their ability to predict the entire TBS part.
I may have misunderstood the paper, but I think that changes
after the subjectPublicKeyInfo do not affect the attack.
Almost correct. A random looking "collision block" has to be inserted
somewhere. We chose to insert it in the public key, as that seems
the most convenient. Somebody else may find another place where
it can be hidden (maybe in a "subject key identifier" field or something,
I don't know what would be feasible). Everything after the "collision
block" must be copied bitwise into the twin certificate, and must be
'harmless' there. If 'random fluff' is inserted by the CA after the
"collision block", this 'random fluff' can be copied into the twin
certificate as well, retaining the collision property, and this
would indeed be irrelevant to our attack.
Also, I've updated today and all the "bad" CAs with MD5
signatures are still in the TAS.
As was pointed out to me earlier: it does not matter if the
CA has its cert signed with MD5, only whether that CA *signs*
with MD5. RapidSSL, for example, is still signed with MD5 but
is now signing with SHA-1.
Correct.
Grtz,
Benne de Weger