RE: Embedded certificate image

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] 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" <tmiller@xxxxxxxxx> 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
> > 
> 
> 
>