• The Netscape Comment Block won't conform to the ASN.1 IA5String type. From the paper:
  

  These two problems together ask for a place in the rogue CA certificate to hide 427 bytes of data in, some of which are random looking, and some of which have an interpretation that should not be shown in certificate viewers. The solution we adopted is to define a so called "Netscape Comment" block. This is a proprietary extension in which any data can be stored, which will be ignored by most certificate processing applications, including the major browsers. There is a small problem here in that formally the contents of this field must be of type IA5String, and our content is not of that form. An ASN.1 parser that strictly follows the standard will complain about this, as happens e.g. with Peter Gutmann's program "dumpasn1". But as most application software ignores the extension anyway, the certificate with this standard violating field in it will still be accepted in practice. It is conceivable that the 427 bytes could have been hidden in a different extension field (there is even an X.509 certificate with a movie hidden inside).

  This won't work if an end-use cert, such as a website cert is generated instead of a CA cert, as in the former's case the 'tumour' can be hidden in the public key block.
   
• The signing certificate of the rogue CA will be the wrong one for an intermediary CA, if the CA has set their PKI up properly:
  My reasoning for this, is that if you have (for example) a three tier PKI. With an off-line root CA, and intermediary issuing CA, and end-point signing CAs; then any intermediary CA certs issued should be signed by the middle point in the tier and not the end-point. Once again, this won't work if the rogue cert is a an end-use cert instead of an intermediary CA cert, but this reduces the scope of the attack significantly, as a weekend of burning through 200 Playstation cores will only break one site, instead of allowing a transparent mitm.
   
• The CA that signed a certificate uses the MD5 hashing algorithm:
  By itself this does not indicate a problem, but combined with the other two factors above, if false, it would allow the cert to be excluded as untrusted.
   

If these and other factors can be discovered, certificate validation routines can be updated to proactive detect rogue certs based on the current attack (Firefox add-on anyone?). I'm not sure how modifications to the attack will affect these. For example, if MD5 collision attacks become advanced enough to generate collision blocks that are ASN.1 valid, it would be excluded, although it feels like a a significantly big hurdle for it to remain effective.