Re: Embedded certificate image

[Stephen Farrell <stephen.farrell@xxxxxxxxx>]

Another -1 to the complexity here.

There are folks who try to spot images that contain stego
stuff and flag those as suspect. I guess we don't want
certs to start showing up in such lists (or maybe that'd
be amusing;-)

S.

Santosh Chokhani wrote:
> Dave,
> 
> What you propose and Tom proposed seem to work from security viewpoint.
> I do not know the impact on processing.  I assume some noise in graphics
> should not impact it. 
> 
>> -----Original Message-----
>> From: owner-ietf-pkix@xxxxxxxxxxxx 
>> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Kemp, David P.
>> Sent: Monday, August 03, 2009 4:47 PM
>> To: ietf-pkix
>> Subject: RE: Embedded certificate image
>>
>>
>> If a CA were going to accept user input to an image composed 
>> by the CA, then the composition process can provide 
>> confounding data by doing more than just "inserting a 
>> customer-provided graphic into a [known] template provided by 
>> the CA".  The Security Considerations section could recommend 
>> steganographic techniques for unpredictably modifying the 
>> image in perceptually-insignificant ways, such as by adding 
>> noise to the image data and/or inserting random tags in image 
>> formats for which tags are defined.
>>
>>
>> -----Original Message-----
>> From: owner-ietf-pkix@xxxxxxxxxxxx 
>> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
>> On Behalf Of Santosh Chokhani
>> Sent: Monday, August 03, 2009 10:39 AM
>> To: Timothy J. Miller; Tom Gindin
>> Cc: Stefan Santesson; ietf-pkix
>> Subject: RE: Embedded certificate image
>>
>>
>> Tim,
>>
>> Depending on the nature of collision, randomly reordering 
>> extensions may not help at all or may not provide 
>> sufficiently low probability of successful collision.
>>
>>> -----Original Message-----
>>> From: Timothy J. Miller [mailto:tmiller@xxxxxxxxx]
>>> Sent: Monday, August 03, 2009 8:51 AM
>>> To: Tom Gindin
>>> Cc: Stefan Santesson; ietf-pkix; Santosh Chokhani
>>> Subject: Re: Embedded certificate image
>>>
>>> Tom Gindin wrote:
>>>>         Stefan:
>>>>
>>>>         While it is unreasonable to dictate what a CA can 
>> accept, I 
>>>> think that the Security Considerations section should say 
>> something
>>>> like: "the information about the certificate subject
>>> contained in the
>>>> image SHOULD NOT include any graphic supplied by the
>>> applicant".  The
>>>> "tumor" construct which we saw in MD5 collisions could be
>>> placed into
>>>> such a graphic.  Thus if a CA were to construct a graphic
>>> by inserting
>>>> a customer-provided graphic into a template provided by 
>> the CA, it 
>>>> would be subject to the same attacks as MD5 certificates 
>> have been, 
>>>> but it would not be evident from the certificate syntax.
>>> I'd rather require the CA to include a confounder in the 
>> prefix than 
>>> restrict the CAs ability to accept input.  There are 
>> multiple places 
>>> where a CA can do this; serial number being one (but more or less 
>>> difficult for some PKIs to implement), random-skew validity periods 
>>> being another.  To confound a prefix using this extension, random 
>>> reordering extensions is enough.
>>>
>>> -- Tim
>>>
>>
> 
>