RE: Embedded certificate image

["Santosh Chokhani" <[e-mail]>]

Then, a security considerations section describing how this field does
not aid in collision attack should be sufficient. 

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]] 
> Sent: Thursday, July 30, 2009 3:53 PM
> To: Santosh Chokhani; Timothy J. Miller
> Cc: ietf-pkix
> Subject: Re: Embedded certificate image
> 
> This is data generated by the CA.
> 
> Some included elements, like logotype of the subject 
> organization may be provided by the applicant but the 
> certificate image is assembled and created by the CA.
> 
> /Stefan
> 
> 
> On 09-07-30 8:55 PM, "Santosh Chokhani" 
> <[e-mail]> 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.
> > 
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Stefan Santesson
> >> Sent: Thursday, July 30, 2009 2:32 PM
> >> To: Timothy J. Miller
> >> Cc: ietf-pkix
> >> Subject: Re: Embedded certificate image
> >> 
> >> 
> >> So, with all things taken into account, what is your 
> opinion on what 
> >> we should do?
> >> 
> >> Do you argue that we should ignore the feature because it 
> may enhance 
> >> hash attacks?
> >> 
> >> /Stefan
> >> 
> >> On 09-07-30 5:32 PM, "Timothy J. Miller" <[e-mail]> wrote:
> >> 
> >>> Stefan Santesson wrote:
> >>> 
> >>>> However, I can't escape that it feels a bit warped if we abandon 
> >>>> useful features because we must design protocols to resist weak 
> >>>> hashes instead of making sure that we can and do use
> >> adequate hash algorithms.
> >>> 
> >>> It's a risk-management decision, in the end.  The question
> >> is, whose
> >>> risk is it?  The protocol designer's, or the end user's?
> >>> 
> >>>> On the second point, the data in both SVG and PDF/A are
> >> highly structured.
> >>>> SVG is for example an XML based vector graphic language.
> >>> 
> >>> I can bury arbitrary amounts of unstructured data in both
> >> SVG and PDF/A.
> >>>   SVG allows the same RFC2397 data URLs that you were discussing 
> >>> previously, and you can embed fonts in both PDF/A (it's actually
> >>> required) and SVG.  :)
> >>> 
> >>> -- Tim
> >>> 
> >> 
> >> 
> >> 
> > 
> 
> 
>