Re: Embedded certificate image

[Stefan Santesson <stefan@xxxxxxxxxxx>]

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" <SChokhani@xxxxxxxxxxxx> 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: 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
>>> 
>> 
>> 
>> 
>