RE: Embedded certificate image

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

Tim,

Stefan is saying that the data is not applicant chosen. 

> -----Original Message-----
> From: Timothy J. Miller [mailto:tmiller@xxxxxxxxx] 
> Sent: Thursday, July 30, 2009 4:34 PM
> To: Santosh Chokhani
> Cc: Stefan Santesson; ietf-pkix
> Subject: Re: Embedded certificate image
> 
> 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 
> > attack and 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
>