Re: Embedded certificate image

[Stefan Santesson <stefan@xxxxxxxxxxx>]

The draft we are discussing is the certificate image draft, not the use of
subject logotype with RFC 3709.

A certificate image is composed by the CA even if there may be part of the
image that has been imported, such as a subject logo appearing somewhere
inside the certificate image. The fact that the certificate image is
composed by the CA creates the situation described by Tom. I.e. the imported
image appears somewhere inside the certificate image, therefore it will be
preceded and mixed with data provided by the CA.

/Stefan


On 09-07-31 4:03 PM, "Tom Gindin" <tgindin@xxxxxxxxxx> wrote:

> 
>         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 <stefan@xxxxxxxxxxx>
> Sent by: owner-ietf-pkix@xxxxxxxxxxxx
> 07/30/2009 03:52 PM
> 
> To
> Santosh Chokhani <SChokhani@xxxxxxxxxxxx>, "Timothy J. Miller"
> <tmiller@xxxxxxxxx>
> cc
> ietf-pkix <ietf-pkix@xxxxxxx>
> 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" <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
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
>