Re: Embedded certificate image

[Tom Gindin <[e-mail]>]

        But isn't the subject organization's logotype precisely the entity 
which could be manipulated to produce a collision?  What other 
unpredictable data is in the image?  The certificate (as distinct from its 
image) is always assembled and created by the CA, but that didn't stop the 
collision attacks at New Year's.  I tend to agree with Timothy about this 
one.
        The simplest way to make this safe against collisions IMHO is to 
add an optional OCTET STRING as the first item (not the last) in the 
logotype extension and have the CA set it to a random value the same size 
as the digest output whenever it puts in an image.  That should break up 
the prefix attack.  Unfortunatly, there is no corresponding field in the 
base definition.
        I have seen Santosh's citation from 3709, but is the subject 
organization's logotype more a "relationship asserted by the issuer" than 
an OU value?

                Tom Gindin




Stefan Santesson <[e-mail]> 
Sent by: [e-mail]
07/30/2009 03:52 PM

To
Santosh Chokhani <[e-mail]>, "Timothy J. Miller" 
<[e-mail]>
cc
ietf-pkix <[e-mail]>
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
>>> 
>> 
>> 
>> 
>