Subject: Re: Embedded certificate image

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 3 Aug 2009 07:50:38 -0500

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 3 Aug 2009 10:39:29 -0400

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:[email-masked]] 
> 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
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 3 Aug 2009 16:46:41 -0400

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: [email-masked] [mailto:[email-masked]]
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,

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 3 Aug 2009 17:05:59 -0400

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. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kemp, David P.
> Sent: Monday, August 03, 2009 4:47 PM
> To: ietf-pkix
> 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.
> 
> 
> Depending on the nature of collision, randomly reordering 
> extensions may not help at all or may not provide 
> sufficiently low probability of successful collision.
> 
> prefix than

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 4 Aug 2009 08:37:22 -0400

Well, image processing and extension reordering and the like *are*
baroque solutions to a simple problem.  We geeks like to brainstorm
about that sort of stuff.  But then we have to get real.

> 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.

I concur entirely.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Monday, August 03, 2009 5:06 PM
To: Kemp, David P.; ietf-pkix
Subject: RE: Embedded certificate image

Dave,

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 3 Aug 2009 16:46:41 -0400

-----Original Message-----

Tim,

> confound a prefix using this extension, random reordering 

This email was received from the INTERNET and scanned by the Government Secure Intranet anti-virus service supplied by Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number 2007/11/0032.) In case of problems, please call your organisation’s IT Helpdesk. 
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

****************************************************************************
Communications with GCHQ may be monitored and/or recorded 
for system efficiency and other lawful purposes. Any views or 
opinions expressed in this e-mail do not necessarily reflect GCHQ 
policy.  This email, and any attachments, is intended for the 
attention of the addressee(s) only. Its unauthorised use, 
disclosure, storage or copying is not permitted.  If you are not the
intended recipient, please notify [email-masked].  

This information is exempt from disclosure under the Freedom of 
Information Act 2000 and may be subject to exemption under
other UK information legislation. Refer disclosure requests to 
GCHQ on 01242 221491 ext 30306 (non-secure) or email
[email-masked]

****************************************************************************

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Aug 2009 14:36:46 +0100

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:
>> [mailto:[email-masked]]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Aug 2009 10:27:17 -0400

>image data and/or inserting random tags in image formats for which tags

David,

I think a CA-selected, random prefix may be a better choice here. An 
organization may be very "attached" to its logo and not want any form 
of manipulation.  In many (most?) cases I expect the organization to 
provide the artwork in precisely the form they will want it to be 
displayed. It would be much easier for a CA to just generate random 
bit string and insert in into a data structure used to convey the 
image, rather than having to be able to watermark the image in some 
fahsion.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 14 Aug 2009 15:43:24 +0200

I would like to conclude this discussion, at least with respect to this
draft.

The fact of the case is that the scope of this draft is limited to defining
a new image type to be referenced through the logotype extension defined in
RFC3709.

All RFC 3709 allows in this context is to define an OID and its semantics.
There are no extensibility mechanism available through which one can provide
any extra random bits to the image.

The question is therefore not what could be done to safely include image
data in a certificate signed with a poor signature algorithm, but if it is
reasonable to reference the data URL scheme as one optional way to store the
referenced image without adding any random data.

My proposal is to allow the data url scheme for embedding an image, but to
clarify the risk of including images provided by a potential attacker in
combination with a week signing hash.

Would anyone strongly object?

/Stefan