Santosh Chokhani wrote:
I do not mean to intrude, but is this data being provided by the applicant or is this something structured created by the CA or gotten by the CA from a source that applicant does not control. I ask because depending on the answer, this may become pre-image attackand hence impractical.
I went and refreshed myself on Stevens et.al.'s paper (and Lenstra's site on colliding X.509) and while I continue to struggle to understand it I think the following is true:
The presence of a large applicant-controlled data block like an image in the extensions would allow a chosen prefix attack using the extension to house the colliding suffixes (S and S') and the tail construction (T). This eliminates the restriction that S||T and S'||T must form a valid RSA modulus, and opens the possibility that the attacker can use more near-collision blocks (if the image is larger than the key). This would make the attack easier, but I have no earthly idea by how much.
On the other hand, the larger prefixes P and P' (as they now include the whole cert up to the extensions) makes it easier for the CA to confound the chosen-prefix attack. The CA would only need to place an unpredictable extension *before* the id-pe-logotype prior to signing; that's a simple enough reordering step.
It's worth noting that I think this concern applies to RFC3709 too. So what would I do? To be safe, you could do one or more of the following:- Require the CA to reorder the extensions prior to signing, and never place id-pe-logotype first.
- Specify that the image data is entirely CA controlled, or contains only minimal data that is applicant controlled (and that applicant-controlled data in total is less than the key length). Ideally, take the applicant data from other fields in the request, rather than having the applicant submit his own image data.
- Place an upper limit on refStructURI length. A length less than the key would probably be sufficient. Whether this would be sufficient to house a data URL is an open question; I don't know.
- Finally, prohibiting data URLs entirely is always an option.The reason I say limit applicant data to less than the key length is because that would restrict the number of collision blocks the cert image can hold to less than those that can be held in the modulus. This increases complexity and time for the attacker if he uses this extension for his collision. He can always use the key unless the CA takes other steps to prevent chosen prefix attacks on its own--which, naturally, prevents chosen prefix attacks in the extension as well, but requiring certain CA behavior for *all* certificates is beyond the scope of this document. Might be worth a paragraph in the security considerations, though.
All of this presumes that a chosen-prefix attack against SHA is someday possible, of course. But it's always good to be proactive if it's not too difficult.
-- Tim
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature