headers
Tom Gindin | 1 Aug 2009 02:07
Picon
Favicon

Re: Embedded certificate image


        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.

                Tom Gindin

Stefan Santesson <stefan <at> aaa-sec.com> 
Sent by: owner-ietf-pkix <at> mail.imc.org
07/31/2009 02:19 PM

To
"Timothy J. Miller" <tmiller <at> mitre.org>, Santosh Chokhani 
<SChokhani <at> cygnacom.com>
cc
ietf-pkix <ietf-pkix <at> imc.org>
Subject
Re: Embedded certificate image

Tim,

It is not reasonable for this standard to dictate what a CA accepts as
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Hoffman | 1 Aug 2009 11:11

Two IETF Last Calls of interest to this WG


>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Clearance Sponsor Attribute '
>   <draft-turner-clearancesponsor-attribute-01.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>ietf <at> ietf.org mailing lists by 2009-08-28. Exceptionally,
>comments may be sent to iesg <at> ietf.org instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-turner-clearancesponsor-attribute-01.txt
>

>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Device Owner Attribute '
>   <draft-turner-deviceowner-attribute-01.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>ietf <at> ietf.org mailing lists by 2009-08-28. Exceptionally,
>comments may be sent to iesg <at> ietf.org instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timothy J. Miller | 3 Aug 2009 14:50
Picon
Favicon

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
Attachment (smime.p7s): application/x-pkcs7-signature, 3492 bytes
Permalink | Reply | 7 comments |
headers
Santosh Chokhani | 3 Aug 2009 16:39
Favicon

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 <at> mitre.org] 
> 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.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stephen Farrell | 3 Aug 2009 21:03
Picon
Picon

draft-turner-deviceowner-attribute last call comment


Hi Sean,

It seems odd to me that the only options for naming a device
owner are to use a country code or an OID that might represent
a group of countries (or something else).

Either this draft is only referring to some very special
devices or else its missing *much* more natural identifiers
for device owners, e.g. DNS names, email addresses etc.

So I think either change the ASN.1 (perhaps to include
a GeneralName in the choice) or else change the text to
say which kind(s) of device tend to be owned by countries
or groups of countries so that readers of the resulting RFC
have some kind of clue as to what the document is really
about.

I guess I'd prefer the former option, but since this is
going to be informational am fine with the latter so long
as its clear about the kind(s) of device to which the
putative RFC is meant to apply.

Cheers,
Stephen.
Permalink | Reply | 0 comments |
headers
Kemp, David P. | 3 Aug 2009 22:46

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 <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
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 <at> mitre.org] 
> Sent: Monday, August 03, 2009 8:51 AM
> To: Tom Gindin
> Cc: Stefan Santesson; ietf-pkix; Santosh Chokhani
> Subject: Re: Embedded certificate image
(Continue reading)

Permalink | Reply | 5 comments |
headers
Santosh Chokhani | 3 Aug 2009 23:05
Favicon

RE: Embedded certificate image


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 <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org] 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 <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Santosh Chokhani
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kemp, David P. | 4 Aug 2009 14:37

RE: Embedded certificate image


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: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
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,

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Farrell | 4 Aug 2009 15:36
Picon
Picon

Re: Embedded certificate image


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 <at> mail.imc.org 
>> [mailto:owner-ietf-pkix <at> mail.imc.org] 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Kent | 4 Aug 2009 16:27
Picon

RE: Embedded certificate image


At 4:46 PM -0400 8/3/09, Kemp, David P. wrote:
>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.
>

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
Permalink | Reply | 1 comment |

Gmane