On Thu, Feb 23, 2017 at 5:16 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > For example, in a certificate request, while the attacker can "choose" > such a bunch of bits in the public key, the value also has to be a valid > public key for which the attacker can generate at least one digital > signature (the one on the CSR).
I do not believe this is correct. Can you please point me to the Baseline Requirements' requirement that the Applicant demonstrate proof of possession of a private key through a CSR? > For RSA certificates, this might be done by requesting a longer that 2048 > bit public key found by searching for primes whose most significant 1024 > bits multiply to form the attack value (such prime searching is a standard > part of legitimate key generation). The length of the request DN would > then need to be adjusted to align the public key just right for the public > key to start at a 64 byte boundary after adding the stuff the victim CA > adds. And after that, the actual 128 byte block would need the very costly > calculation for a prefix corresponding to the combination of the chosen > request parameters and whatever the CA is predicted to add, including any > random serial number bits and whatever "predictable" serial number and > timestamp will be used after the multi-month calculation period. > What you describe is not wrong, but it's also not right either. Perhaps it'd be easier to simply point to the original, more accurate, and more comprehensive description of the MD5 Rogue CA, which more accurately addresses where the weaknesses are in the issuance process - https://www.win.tue.nl/hashclash/rogue-ca/ > As a further countermeasure, I would suggest that CAs operating > continued SHA-1 services (such as Windows XP compatible code signing > certificate issuance and signature timestamping) should run a > variation of the "sha1collisiondetection" check released Tuesday by the > CWI/Google team, and simply refuse requests that this check flags as > suspicious. The checking for SHA-1 collision detection has been available from Marc-et-al since 2012. There have been several improvements over the years since, but that basic piece of advice is one that the community has already been sharing for five years now. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
