Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 14:55:55 -0400
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48C73CD1@scygexch1.cygnacom.com>
In-Reply-To: <C697B3BD.3A6E%stefan@aaa-sec.com>
Thread-Topic: Embedded certificate image
thread-index: AcoRRATVJ9elVxril0+14j0wFrBD8wAAyVcg
References: <4A71BD2B.60606@mitre.org> <C697B3BD.3A6E%stefan@aaa-sec.com>
From: "Santosh Chokhani" <SChokhani@cygnacom.com>
To: "Stefan Santesson" <stefan@aaa-sec.com>,
 "Timothy J. Miller" <tmiller@mitre.org>
Cc: "ietf-pkix" <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk

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.=20

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org=20
> [mailto:owner-ietf-pkix@mail.imc.org] 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
>=20
>=20
> So, with all things taken into account, what is your opinion=20
> on what we should do?
>=20
> Do you argue that we should ignore the feature because it may=20
> enhance hash attacks?
>=20
> /Stefan
>=20
> On 09-07-30 5:32 PM, "Timothy J. Miller" <tmiller@mitre.org> wrote:
>=20
> > Stefan Santesson wrote:
> >=20
> >> However, I can't escape that it feels a bit warped if we abandon=20
> >> useful features because we must design protocols to resist weak=20
> >> hashes instead of making sure that we can and do use=20
> adequate hash algorithms.
> >=20
> > It's a risk-management decision, in the end.  The question=20
> is, whose=20
> > risk is it?  The protocol designer's, or the end user's?
> >=20
> >> On the second point, the data in both SVG and PDF/A are=20
> highly structured.
> >> SVG is for example an XML based vector graphic language.
> >=20
> > I can bury arbitrary amounts of unstructured data in both=20
> SVG and PDF/A.
> >   SVG allows the same RFC2397 data URLs that you were discussing=20
> > previously, and you can embed fonts in both PDF/A (it's actually
> > required) and SVG.  :)
> >=20
> > -- Tim
> >=20
>=20
>=20
>=20