Subject: Check out hot deals

From: <[email-masked]>
Date: Fri, 30 Jan 2009 15:21:14 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.noblelowly.com, click on "My Account",
click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.

Or unsubscribe at
http://noblelowly.com/faq.php

Privacy Statement |
Terms & Conditions |
Contact

KEYWORD Ltd.

Tower Bridge Business Complex. Unit 1, B535. 416 Clements Road. London. SE59 3DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGrg2d093017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:53:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UGrg1F093016; Fri, 30 Jan 2009 09:53:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGrVc5092997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:53:42 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-178.bbn.com ([128.89.89.178] helo=gardiner-xp.bbn.com) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LSwcT-0004EY-BG; Fri, 30 Jan 2009 11:53:29 -0500
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 30 Jan 2009 11:53:26 -0500
To: Paul Hoffman , "Carl Wallace" , ,
From: "Charles W. Gardiner"
Subject: RE: New modules drafts -- proposed ASN.1 downgrade tutorial
In-Reply-To:
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 12:13 PM 1/28/2009, Paul Hoffman wrote:

>At 9:35 AM -0500 1/28/09, Carl Wallace wrote:
> >I volunteer to help write the document.
>
>Thank you! Who wants to help Carl?

I'd be glad to try.

Charlie Gardiner

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U3HXl3054534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 20:17:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0U3HXnI054532; Thu, 29 Jan 2009 20:17:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U3HT9S054522; Thu, 29 Jan 2009 20:17:31 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA046855344; Fri, 30 Jan 2009 04:15:44 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id EAA16899; Fri, 30 Jan 2009 04:15:43 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: RE: New modules drafts -- proposed ASN.1 downgrade tutorial
To: [email-masked], [email-masked]
Date: Fri, 30 Jan 2009 04:15:43 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,

ASN.1 guru's will regret, but some on the list might be interested in
a few more hints and (firstly) an idea regarding ASN.1.

a) Help the IETF EDU team prepare a 'New ASN.1' tutorial session
for IETFers with a working knowledge of the 'Old ASN.1'.
First opportunity: Sunday afternoon in Stockholm ?

b) Beyond ...
the primary X.680/690 series Recommendations available from:
http://www.itu.int/rec/T-REC-X/e ,
http://www.itu.int/rec/T-REC-X.680-X.693/e ,
the SG-17 home page:
http://www.itu.int/ITU-T/studygroups/com17/index.asp , and
the ASN.1 & OID Project pages:
http://www.itu.int/ITU-T/asn1/index.html ,
the ITU-T web site offers ASN.1 delta material:
http://www.itu.int/ITU-T/studygroups/com17/changing-ASN/index.html
- Differences
- Advantages
- How-to-Change
+ Pointers to books ...

c) John Larmouth,
"ASN.1 Complete",
printed: Morgan Kaufmann / Academic Press, ISBN 0-12233-435-3;
also downloadable from the web.

d) Olivier Dubuisson, translated by Philippe Fouquart,
"ASN.1 - Communications between heterogenous systems",
printed: Elsevier - Morgan Kaufmann,
ISBN 0-12-6333361-0 (?? -- literally from below! :-))

e) OSS Nokalva Inc. hosts lots of web resources including online
versions of the above books, and offers professional training
services; start with: http://www.oss.com/asn1/

Kind regards,
Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U1HqPp050155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 18:17:52 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0U1HqV8050154; Thu, 29 Jan 2009 18:17:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U1HdjA050145 for ; Thu, 29 Jan 2009 18:17:51 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA046128154; Fri, 30 Jan 2009 02:15:54 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id CAA16675; Fri, 30 Jan 2009 02:15:53 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: OIDs for AES in CTR Mode
To: [email-masked]
Date: Fri, 30 Jan 2009 02:15:52 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> Title: OIDs for AES in CTR Mode
> Hi Folks,
>
> Is anyone aware of any OID (or URI) for using AES in CTR mode?
>
> Thanks,
> Aram

NOPE! Never seen!

Obviously AES-CTR is *not* supported by NIST for general use in
environments that require OIDs, and so they did not assign OIDs.

See:
http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html

This should be the most official page for basic AES OIDs available.

Perhaps you might better target AES-CCM or AES-GCM.

Kind regards,
Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TMspqJ044401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 15:54:51 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TMspfp044400; Thu, 29 Jan 2009 15:54:51 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TMsehF044380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Thu, 29 Jan 2009 15:54:51 -0700 (MST) (envelope-from [email-masked])
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=[email-masked]; q=dns/txt; s=qcdkim; t=1233269690; x=1264805690; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Perez,=20Aram"=20|To:=20"ie [email-masked]"=20,=0D=0A=20=20=20 =20=20=20=20=20"[email-masked]"=0D=0A=09|Date:=20Thu,=2029=20Jan=202009=2014:54:38=20-0800 |Subject:=20OIDs=20for=20AES=20in=20CTR=20Mode |Thread-Topic:=20OIDs=20for=20AES=20in=20CTR=20Mode |Thread-Index:=20AcmCZI/wD4GwM7kDFU+1+2a6VU53FA=3D=3D |Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C5A773AE19D48arampqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5510"=3B=20a=3D"15046448"; bh=yD9Cj39quSXsNHpDRkgrmlDIpScMm+lbmmngZ4LkzIY=; b=c3/mChMKblreTGy9GXiB4xaLMMvGSeDMbaEzz2x316xfLihrbzkfbK+O HQ3N8ZPGOKafmm9Vf1K+eV2VuBlM6rDr2C6sa6X7H1YNeESeQiVJgt9PR SHR3I+wqf8r0ZlvaNQz6UuLgN6XoYFF5zWMXgw82qNslLR6FzLz6JngmF 8=;
X-IronPort-AV: E=McAfee;i="5100,188,5510"; a="15046448"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jan 2009 14:54:40 -0800
Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0TMsexc010215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Jan 2009 14:54:40 -0800
Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0TMsdY3012761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Jan 2009 14:54:39 -0800
Received: from NASANEXMB05.na.qualcomm.com ([129.46.52.178]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Thu, 29 Jan 2009 14:54:39 -0800
From: "Perez, Aram"
To: "[email-masked]" , "[email-masked]"
Date: Thu, 29 Jan 2009 14:54:38 -0800
Subject: OIDs for AES in CTR Mode
Thread-Topic: OIDs for AES in CTR Mode
Thread-Index: AcmCZI/wD4GwM7kDFU+1+2a6VU53FA==
Message-ID:
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C5A773AE19D48arampqualcommcom_"
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--_000_C5A773AE19D48arampqualcommcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Folks,

Is anyone aware of any OID (or URI) for using AES in CTR mode?

Thanks,
Aram

--_000_C5A773AE19D48arampqualcommcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Folks,

Is anyone aware of any OID (or URI) for using AES in CTR mode?

Thanks,

Aram

--_000_C5A773AE19D48arampqualcommcom_--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TDpJgA014250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 06:51:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TDpJ5a014249; Thu, 29 Jan 2009 06:51:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TDpIoi014243 for ; Thu, 29 Jan 2009 06:51:18 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0TDpHc8022866 for ; Thu, 29 Jan 2009 08:51:18 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0TDpHjJ022863; Thu, 29 Jan 2009 08:51:17 -0500
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 29 Jan 2009 08:51:17 -0500
From: "Miller, Timothy J."
To: Santosh Chokhani , Stephen Kent
CC: "David A. Cooper" , "[email-masked]"
Date: Thu, 29 Jan 2009 08:51:15 -0500
Subject: Re: SAN semantics question
Thread-Topic: SAN semantics question
Thread-Index: AcmBnIe6w827pWoWQ3KMZ9FlSLYl5AAeMf49AACerCAAADcpgg==
Message-ID:
In-Reply-To:
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On 1/29/09 8:46 AM, "Santosh Chokhani" wrote:

> This serial number attribute is in the DN and has nothing to do with the
> certificate serial number field.

I realized I'd misread that just after hitting send. It's been a long week=
.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TDkYck013926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 06:46:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TDkYh1013925; Thu, 29 Jan 2009 06:46:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0TDkNj4013914 for ; Thu, 29 Jan 2009 06:46:33 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 26161 invoked from network); 29 Jan 2009 13:46:49 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;29 Jan 2009 13:46:49 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 29 Jan 2009 13:46:49 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: SAN semantics question
Date: Thu, 29 Jan 2009 08:46:18 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: SAN semantics question
Thread-Index: AcmBnIe6w827pWoWQ3KMZ9FlSLYl5AAeMf49AACerCA=
References:
From: "Santosh Chokhani"
To: "Miller, Timothy J." , "Stephen Kent"
Cc: "David A. Cooper" ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Tim,

This serial number attribute is in the DN and has nothing to do with the
certificate serial number field.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
> Sent: Thursday, January 29, 2009 8:27 AM
> To: Stephen Kent
> Cc: David A. Cooper; [email-masked]
> Subject: Re: SAN semantics question
>=20
>=20
> On 1/28/09 6:02 PM, "Stephen Kent" wrote:
>=20
> > RFC 4122 provides a URN syntax, but it does not seem to have the=20
> > structure you seem to want, in order to impose name=20
> constraints. If=20
> > the node value is just a MAC address, there are extant=20
> conventions for=20
> > representation of that value employed by DOCSIS and WIMAX folks.
> > (I personally think the conventions are awful, but that's another=20
> > matter :-)). If the UUIDs are arbitrary, then I can imagine why you=20
> > might want a qualifier to indicate the UUID assigner. Frankly, I=20
> > think this is a questionable approach.
>=20
> I've been advocating deriving the UUID from the public key=20
> (using a variation on method 5). This provides binding=20
> between cert and UUID, and, in fact, we wouldn't need to put=20
> the UUID in the cert at all (the application can derive the=20
> UUID on the fly during authZ). I keep losing the argument=20
> because then the identifier isn't "permanent;" though I=20
> contend that the requirement for periodic re-validation=20
> creates the opportunity to re-assign identifiers.
>=20
> Anyway.
>=20
> > The serial number attribute for a DN is a reasonable place to put a=20
> > device ID that is serial-number-like in form, as a series=20
> of decimal=20
> > digits. The UUID can be translated into such a sequence. You could=20
> > use a common name to specify the UUID assigner. Of course=20
> this might=20
> > conflict with other Subject attributes you may plan to use,=20
> but since=20
> > you didn't specify what those might be ...
>=20
> That's an idea, but I don't know if it would fly;=20
> non-sequential serial numbers make people nervous given our=20
> existing OCSP implementation.
>=20
> -- Tim
>=20
>=20

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TDRaTn012818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 06:27:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TDRaiB012817; Thu, 29 Jan 2009 06:27:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TDROYI012799 for ; Thu, 29 Jan 2009 06:27:35 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0TDRNFS023439 for ; Thu, 29 Jan 2009 08:27:24 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0TDRNMC023434; Thu, 29 Jan 2009 08:27:23 -0500
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 29 Jan 2009 08:27:23 -0500
From: "Miller, Timothy J."
To: Stephen Kent
CC: "David A. Cooper" , "[email-masked]"
Date: Thu, 29 Jan 2009 08:27:20 -0500
Subject: Re: SAN semantics question
Thread-Topic: SAN semantics question
Thread-Index: AcmBnIe6w827pWoWQ3KMZ9FlSLYl5AAeMf49
Message-ID:
In-Reply-To:
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On 1/28/09 6:02 PM, "Stephen Kent" wrote:

> RFC 4122 provides a URN syntax, but it does not seem to have the
> structure you seem to want, in order to impose name constraints. If
> the node value is just a MAC address, there are extant conventions
> for representation of that value employed by DOCSIS and WIMAX folks.
> (I personally think the conventions are awful, but that's another
> matter :-)). If the UUIDs are arbitrary, then I can imagine why you
> might want a qualifier to indicate the UUID assigner. Frankly, I
> think this is a questionable approach.

I've been advocating deriving the UUID from the public key (using a
variation on method 5). This provides binding between cert and UUID, and,
in fact, we wouldn't need to put the UUID in the cert at all (the
application can derive the UUID on the fly during authZ). I keep losing th=
e
argument because then the identifier isn't "permanent;" though I contend
that the requirement for periodic re-validation creates the opportunity to
re-assign identifiers.

Anyway.

> The serial number attribute for a DN is a reasonable place to put a
> device ID that is serial-number-like in form, as a series of decimal
> digits. The UUID can be translated into such a sequence. You could
> use a common name to specify the UUID assigner. Of course this might
> conflict with other Subject attributes you may plan to use, but since
> you didn't specify what those might be ...

That's an idea, but I don't know if it would fly; non-sequential serial
numbers make people nervous given our existing OCSP implementation.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TBGITX004886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 04:16:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TBGIEu004884; Thu, 29 Jan 2009 04:16:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TBGEYd004871; Thu, 29 Jan 2009 04:16:16 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA042267669; Thu, 29 Jan 2009 12:14:29 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA14919; Thu, 29 Jan 2009 12:14:28 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: New ASN.1 Modules drafts (cont'd)
To: [email-masked], [email-masked]
Date: Thu, 29 Jan 2009 12:14:28 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Continuing my 'sliced' review of the New ASN.1 drafts,
below are some more remarks on the AlgorithmInformation Module
and general elements of concern for both drafts.

The various RFC specific ASN.1 modules will be dealt with in
subsequent messages sent to the 'responsible' list (PKIX/SMIME) only.

(4) AlgorithmInformation Module

I had already raised the question of where this module should go to
-- in the PKIX draft only or in both drafts.
For more precise reference, I hereby renumber that issue to # (4a)
and continue the previous enumeration.

In the meantime, I have reported a bunch of comments for this
module off-list, mostly editorial in nature.
However, the following 3 items included in my message to the authors
might deserve feedback from the lists and are rephrased here:

(4b)
Some 'simple type' definitions from the RFC 5280 (PKIX1) modules
are needed in many modules.
It might make sense to move such definitions into the basic
PKIX-CommonTypes module, to simplify the module dependency graph.

Opinions?

(4d) DIGEST-ALGORITHM

DISCUSS:
Should the module new AlgorithmInformation module prepare for RHASH
(Krawczyk et al. Randomized Hashing) addition in a future document ?
Would need a bucket for the Nonce -- unless implemented as a parameter.
[ cf. draft-irtf-cfrg-rhash-01 (expired) and NIST Draft SP 800-106. ]

Opinions?

(4n) COMBINED ALGORITHMS

DISCUSS: Should a specific CLASS for combined (authenticated-
encryption) algorithms be added ?

Opinions?

(5) General topics for RFC specific ASN.1 modules

(5a) additional information?

To enhance the readability and utility of the drafts, I suggest to
add the following type of information to all respective sections
of both drafts:

(5a.1) Keyword in Section title

Ex. (PKIX draft) :

|4. ASN.1 Module for RFC 2560
---
|4. ASN.1 Module for RFC 2560 (OCSP)

(5a.2) Short intro to the purpose and scope of the module

At the very beginning of each section, I would appreciate a short
(one-sentence) paragraph that describes the scope and content of the
subsequent module. This can also be used to expand acronym[s] used
in the section headline (introduced by the above suggestion),
as required by RFC style policy.
Notable specifics should also be mentioned there.

Ex. (PKIX draft, section 4) :

| The subsequent ASN.1 module formally specifies the syntax of
| the 'basic' OCSP (Online Certificate Status Protocol) request
| and response messages as defined in [RFC2560] and includes the
| related OIDs.
| It also corrects an oversight in the original (1988 ASN.1) module
| in [RFC2560], supplying the missing definition for CRLReason.

(5a.3) IMPORTS pointers

I would appreciate to see the FROM clauses in all IMPORTS statements
amended by comments precisely pointing to the definition of the
referenced ASN.1 module.

Ex. (PKIX draft):

IMPORTS

.......
FROM PKIX1Implicit88 -- Section
{ ... }

.....
FROM -- Section of RFC
{ ... }

etc.

(5b) order of modules

Currently, the RFC specific modules are presented (in both drafts)
in ascending RFC number order, but the 'elementary' new module(s)
are presented first.
In the PKIX draft, it strikes that so many dependencies exist to
the PKIX1 modules from RFC 5280 which appears in tha last module
section of the PKIX draft.
Thus, the placement of the 'elementary' modules could be seen as
an indication of a reader-friendly bottom-up staggering of the
modules, but this principle is not followed subsequently.

If a general reordering following a topological sort of the
IMPORTS module dependency graph shall not be undertaken,
two relatively simple measures should be considered:

* moving more 'elementary type' definitions into the
PKIX-CommonTypes module, to simplify the module
dependency graph;

* moving the frequently uesd PKIX1 modules immediately after
the new 'basic' module(s), and leaving the remaining modules
in ascending RFC number order.

Opinions?

(5c) names of PKIX1 modules

Notwithstanding the remarks in Section 1.2 on module OIDs,
IMHO the _names_ of the new PKIX1 modules should be changed;
having "1988" in these names simply is very confusing.
s/1988/1992/ ?

[[ to be continued with per-RFC-module comments ]]

Kind regards,
Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0T3m1gi085385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 20:48:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0T3m1xL085384; Wed, 28 Jan 2009 20:48:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0T3logl085378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Jan 2009 20:48:01 -0700 (MST) (envelope-from [email-masked])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0T3ji20026369 for ; Wed, 28 Jan 2009 22:45:44 -0500
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0T3lm4D188970 for ; Wed, 28 Jan 2009 22:47:48 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n0T3lmXM010209 for ; Wed, 28 Jan 2009 22:47:48 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n0T3lm8F010205 for ; Wed, 28 Jan 2009 22:47:48 -0500
In-Reply-To:
To: "Miller, Timothy J."
Cc: "[email-masked]"
MIME-Version: 1.0
Subject: Re: SAN semantics question
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin
Message-ID:
Date: Wed, 28 Jan 2009 22:47:47 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 01/28/2009 22:47:48, Serialize complete at 01/28/2009 22:47:48
Content-Type: text/plain; charset="US-ASCII"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Why wouldn't that be an otherName with the semantics you want and
value IA5String or UTF8String (or a choice between them)? The semantics
of GeneralNames don't suggest that there are any links between different
GeneralName values within it.

Tom Gindin

"Miller, Timothy J."
Sent by: [email-masked]
01/28/2009 02:04 PM

To
"[email-masked]"
cc

Subject
SAN semantics question

A quick question to inform a discussion I'm having elsewhere:

Is there an intent behind SAN semantics?

Put another way, is it within the intent of the RFC to use an otherName to
add a qualifier to another SAN name type? E.g., set otherName to { NULL
IDENTIFIED BY some-OID }, where some-OID semantics say something like "The
SAN must include a URI name of ."

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SN2j30073592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 16:02:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SN2jLI073591; Wed, 28 Jan 2009 16:02:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SN2i0U073584 for ; Wed, 28 Jan 2009 16:02:44 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LSJQh-00078s-Fo; Wed, 28 Jan 2009 18:02:44 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 28 Jan 2009 18:02:41 -0500
To: "Miller, Timothy J."
From: Stephen Kent
Subject: Re: SAN semantics question
Cc: "David A. Cooper" , "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Tim,

RFC 5280 limits the types of SANs that a compliant RP need be able to
process relative to the name constraints extension. OtherName is not
included. URIs are included, but only the DNS name portion is covered.

RFC 4122 provides a URN syntax, but it does not seem to have the
structure you seem to want, in order to impose name constraints. If
the node value is just a MAC address, there are extant conventions
for representation of that value employed by DOCSIS and WIMAX folks.
(I personally think the conventions are awful, but that's another
matter :-)). If the UUIDs are arbitrary, then I can imagine why you
might want a qualifier to indicate the UUID assigner. Frankly, I
think this is a questionable approach.

The serial number attribute for a DN is a reasonable place to put a
device ID that is serial-number-like in form, as a series of decimal
digits. The UUID can be translated into such a sequence. You could
use a common name to specify the UUID assigner. Of course this might
conflict with other Subject attributes you may plan to use, but since
you didn't specify what those might be ...

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SMQLg3072127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 15:26:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SMQLfu072126; Wed, 28 Jan 2009 15:26:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SMQAUW072117 for ; Wed, 28 Jan 2009 15:26:20 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LSIrJ-0006or-DE; Wed, 28 Jan 2009 17:26:09 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 28 Jan 2009 17:18:49 -0500
To: "Miller, Timothy J."
From: Stephen Kent
Subject: Re: SAN semantics question
Cc: "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 2:04 PM -0500 1/28/09, Miller, Timothy J. wrote:
>A quick question to inform a discussion I'm having elsewhere:
>
>Is there an intent behind SAN semantics?
>
>Put another way, is it within the intent of the RFC to use an otherName to
>add a qualifier to another SAN name type? E.g., set otherName to { NULL
>IDENTIFIED BY some-OID }, where some-OID semantics say something like "The
>SAN must include a URI name of ."
>
>-- Tim

My short answer is no. Each SAN type is nominally independent of the
others, so it would be odd (at best) to have one SAN be used to
qualify another.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SLSTkN069623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 14:28:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SLSTsJ069622; Wed, 28 Jan 2009 14:28:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SLSSKO069616 for ; Wed, 28 Jan 2009 14:28:28 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0SLSRUD000742 for ; Wed, 28 Jan 2009 16:28:27 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0SLSNdY000535; Wed, 28 Jan 2009 16:28:23 -0500
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 28 Jan 2009 16:28:23 -0500
From: "Miller, Timothy J."
To: "David A. Cooper"
CC: "[email-masked]"
Date: Wed, 28 Jan 2009 16:28:19 -0500
Subject: Re: SAN semantics question
Thread-Topic: SAN semantics question
Thread-Index: AcmBit/jRDfdv2NgSZmcNIbQ1t/E5AABHa19
Message-ID:
In-Reply-To: <[email-masked]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On 1/28/09 3:54 PM, "David A. Cooper" wrote:

> I do not understand the purpose behind your example, but I don't believe
> that it would be appropriate. What would be the reason for including a
> statement of the form "the SAN must include a URI ..."?

I was trying to not use the real case and ask a more general question, but
yeah, I see how it would be better to be more concrete. So:

An project I'm involved with wants to use X.667 UUIDs as subject identifier=
s
(I dislike using 'names' for non-human-readable values; it helps keep
people's heads clear). UUIDs may or may not be included in the subject DN;
an argument can be made that the DN should contain a readable name.

One natural place to include UUIDs in a cert is in the SAN as a
uniformResourceIdentifier, using RFC4122 URN syntax.

The discussion is if and how to qualify that identifier. In part, this is
so it can be constrained--either by application logic in a direct trust
environment, or in validator logic using nameConstraints in a cross-cert
environment. =20

Appending a simple namespace identifier to the UUID would work, but would
mean encoding the UUID as an otherName rather than a URI, which some of us
feel should be avoided.

I was thinking that we could define an otherName to encode *only* an
assigner (by OID) without a value, and define the OID semantics to refer to
the URI name type for the value. This would avoid having the assigned UUID
encoded twice. Seemed logical enough at the time, but the objection was
raised that this violates the intent of SAN.

I do see a problem if a cert has multiple URIs in the SAN. Didn't think of
that. :/

> Note that even if the subjectAltName extension is marked critical, the
> relying party is only required to be able to recognize and process at
> least one of the names that appears in the extension and may ignore any
> names with an unrecognized or unsupported name form. So, if one chose
> to ignore the semantics of the extension and include a qualifier as an
> additional "name", relying parties may ignore the qualifier even if the
> extension is marked critical.

Good point. That would apply to some other proposals on the table as well.

> 2) Permanent Identifier (RFC 4043)

I've looked at PI before, and that's of course an option, but has anyone
defined a method to apply nameConstraints to PI?

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SKsQi1068370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 13:54:26 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SKsQQp068369; Wed, 28 Jan 2009 13:54:26 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SKsEAA068360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Jan 2009 13:54:25 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n0SKs9GP008318; Wed, 28 Jan 2009 15:54:09 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n0SKs3Am023124; Wed, 28 Jan 2009 15:54:04 -0500
Message-ID: <[email-masked]>
Date: Wed, 28 Jan 2009 15:54:03 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.19 (X11/20090114)
MIME-Version: 1.0
To: "Miller, Timothy J."
CC: "[email-masked]"
Subject: Re: SAN semantics question
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Miller, Timothy J. wrote:
> A quick question to inform a discussion I'm having elsewhere:
>
> Is there an intent behind SAN semantics?
>
> Put another way, is it within the intent of the RFC to use an otherName to
> add a qualifier to another SAN name type? E.g., set otherName to { NULL
> IDENTIFIED BY some-OID }, where some-OID semantics say something like "The
> SAN must include a URI name of ."
>
Tim,

I do not understand the purpose behind your example, but I don't believe
that it would be appropriate. What would be the reason for including a
statement of the form "the SAN must include a URI ..."? If a CA, by
including this information in the certificate is imposing a requirement
on itself, why would it then issue the certificate with contents that do
not satisfy the qualifier? A CA could possibly wish to impose such a
constraint on certificates that appear later in the certification path,
but any constraints (or qualifiers) should appear in another extension,
not the SAN. The subjectAltName extension should only contain a list of
names for the subject.

Note that even if the subjectAltName extension is marked critical, the
relying party is only required to be able to recognize and process at
least one of the names that appears in the extension and may ignore any
names with an unrecognized or unsupported name form. So, if one chose
to ignore the semantics of the extension and include a qualifier as an
additional "name", relying parties may ignore the qualifier even if the
extension is marked critical.

BTW, several name forms have already been defined for inclusion in
otherName. Some of these are:

1) Jabber Identifier (RFC 3920)

2) Permanent Identifier (RFC 4043)

3) hardware module name (RFC 4108)

4) KRB5PrincipalName (RFC 4556)

5) service name (RFC 4985)

6) User Principal Name (http://support.microsoft.com/kb/281245)

7) Federal Agency Smart Credential Number (FASC-N)
(http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf)

Dave

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJd7bV065524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 12:39:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SJd7V1065522; Wed, 28 Jan 2009 12:39:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJcqL4065503; Wed, 28 Jan 2009 12:39:04 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA038221421; Wed, 28 Jan 2009 20:37:01 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA13854; Wed, 28 Jan 2009 20:37:00 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: New ASN.1 Modules drafts
To: [email-masked], [email-masked]
Date: Wed, 28 Jan 2009 20:36:59 +0100 (MEZ)
Cc: [email-masked], [email-masked]
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul & Jim,

as promised quite some time ago, I have started a review of the
New ASN.1 Modules drafts, now that they have arrived at WGLC.

Firstly, I want to thank you for this huge effort and the
'orthogonalization' of the naming style performed, which in part
might not have been possible before this synoptical re-working
of many less coordinated previous efforts.

In order to speed things up and keep message lengths bounded,
I'll report my detailed findings in successive pieces, as soon
as time avails.

(0)

I have derived from the PKIX list discussion that both drafts
need additional language in their 'executive level text' to better
motivate the long-term switch to the new ASN.1, and hence the aim
for Standards Track, which I strongly support.

There would indeed be no reason for Standards Track if the single
benefit of the whole effort only would be "simply a change to the
syntax". It already has been pointed out that the major benefit
is the formatization of a significant amount of syntactical
information that in the 1988 ASN.1 could only be represented
*informally* as ASN.1 comments, or in explanations in the prose
-- most notably the mess with unspecified sets of allowed OIDs and
dependent objects with 'ANY' syntax (e.g. algorithm parameters).

We all need to get acquainted with the 'new ASN.1', but I expect
that the long-term benefits in precision will far outweigh the
necessary one-time effort.

As some kind of 'draft marketing', the benefits of migrating to the
new syntax should be emphasized at first place, in the Abstract and
in the leading paragraph(s) of Section 1, in both drafts.

Below are a few nits and comments for the (almost) common parts of
both drafts. More TBD.

For brevity, I'll denote the two drafts,
draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-asn1-02,
by "PKIX draft" and "CMS draft", respectively.

(1) Section 1, paragraphs below the bullets -- typo (both drafts)

The following typo occurs 3x :
- in the two last paragraphs in the PKIX draft, and
- in the penultimate para in the CMS draft.

s/defintions/definitions/
^^ ^^^

(2) Section 1.2.1 (both drafts)

Let's take the authoritarian way.
The figures in the OIDs are not worth of lenghty discussions.
Russ Housley, the maintainer of
http://www.imc.org/ietf-pkix/pkix-oid.asn
seems to be the canonical trusted 3rd party to do this. :-)

(3) PKIX-CommonTypes module ( PKIX draft, Section 2 )

(Linear walk-through)

(3a) typo

-- ATTRIBUTE
--
| -- Describe the set of data assoicate with an attribute of some type.
--- ^^^^^^
-- ATTRIBUTE
--
| -- Describe the set of data associated with an attribute of some type.
^^^^^^^
(3b) punctuation

Better use a semicolon -- full sentence follows:
v
| -- &Type is the ASN.1 type structure for the attribute, not all
-- attributes have a data struture, so this field is optional
--- v
| -- &Type is the ASN.1 type structure for the attribute; not all
-- attributes have a data struture, so this field is optional

(3c) typo
v
| -- &minCount contains the mininum number of time the attribute can
-- occur in an AttributeSet
--- v
| -- &minCount contains the minimum number of time the attribute can
-- occur in an AttributeSet

(3d) typo
vv
| -- Currently we are using two differen prefixes for attributes.
--- vvv
| -- Currently we are using two different prefixes for attributes.

(3e) ref.?

-- MATCHING-RULE is imported from InformationFramework.asn

For completeness: Can you give a reference?

[ Sorry, shame on me: I did not arrive yet at studying
the complete X.68* document set. :-) ]

(3f) word shuffling?

| -- MATCHING-RULE information object class specification

Too many nouns in sequence; semantics depend on how you set the
imaginary brackets.
Is this a better, less ambiguous alternative? :

| -- specification of MATCHING-RULE information object class

(3g) AttributeSet vs. SingleAttribute

The formal parameter is a placeholder, isn't it?
Because it plays the same role in both cases, wouldn't it be
reasonable to reuse 'Attrs' for SingleAttribute (in favor of
'AttributeSet') ?
Alternatively, in both cases 'AttributeSet' might be used, in a
similar manner as the draft does for Extensions (subsequently).

IMO, using the long version specifically for SingleAttribute might
be confusing for human readers (mixing up the different meta levels).

(3h) EXTENSION -- word omission

v
-- This class definition is used describe the association of
-- object identifier and ASN.1 type structure for extensions
--- vvvv
-- This class definition is used to describe the association of
-- object identifier and ASN.1 type structure for extensions

(3i) EXTENSION ff. -- need more info

The intent of the commented-out &Critical needs to be explained.

Is this a proposal to be judged/evaluated by the WG?

(3j) Security Category -- use of case

I suggest to always use uppercase "RFC" in favor of mixing it with
lowercase "rfc". Hence, please change:

-- Security categories are used both for specifing clearances and for
| -- labeling objects. We move this here from rfc 3281 so that they
-- will use a common single object class to express this information.
---
-- Security categories are used both for specifing clearances and for
| -- labeling objects. We move this here from RFC 3281 so that they
-- will use a common single object class to express this information.

(4) AlgorithmInformation Module(s)

It turns out that Section 3 of the PKIX draft and Section 2 of the
CMS draft are identical.
I did not find a statement clearly announcing this important fact.
This is a poor service level for potential readers.

Concern: Duplicated specification incurs danger of divergence
and duplicated maintenance efforts in the future;

Benefit: Better readability / self-containment of both drafts.
However: PKIX-CommonTypes module is only in the PKIX draft!

Possible ways to deal with:

a) Leave module in both drafts;
add statement to first paragraph (intro) of the
abovementioned sections clearly stating the duplication.

b) Leave module in both drafts, but declare the copy in the
PKIX draft as normative and the copy in the CMS draft as
non-normative; adjust wording in to first paragraph (intro)
of the abovementioned sections of both drafts to clearly
indicate the duplication and the role of the sections;
also update the final part of Setcion 1 accordingly,
in both drafts.

c) Only keep this module in the PKIX draft;
change language in CMS draft, end of Section 1, accordingly.

d) Move both 'fundamental' modules to a third draft.

Opinions?

My personal preference is for c).

[[ to be continued ]]

Kind regards,
Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJ4kV2064124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 12:04:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SJ4kYM064123; Wed, 28 Jan 2009 12:04:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJ4XD6064111 for ; Wed, 28 Jan 2009 12:04:44 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0SJ4W3c025745 for ; Wed, 28 Jan 2009 14:04:32 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0SJ4Wed025721 for ; Wed, 28 Jan 2009 14:04:32 -0500
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 28 Jan 2009 14:04:32 -0500
From: "Miller, Timothy J."
To: "[email-masked]"
Date: Wed, 28 Jan 2009 14:04:28 -0500
Subject: SAN semantics question
Thread-Topic: SAN semantics question
Thread-Index: AcmBez4fGF5eJziJxk6DuMY468Sh6Q==
Message-ID:
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

A quick question to inform a discussion I'm having elsewhere:

Is there an intent behind SAN semantics?

Put another way, is it within the intent of the RFC to use an otherName to
add a qualifier to another SAN name type? E.g., set otherName to { NULL
IDENTIFIED BY some-OID }, where some-OID semantics say something like "The
SAN must include a URI name of ."

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SHE45O059482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 10:14:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SHE4LO059480; Wed, 28 Jan 2009 10:14:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SHE0cn059467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 10:14:01 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Wed, 28 Jan 2009 09:13:58 -0800
To: "Carl Wallace" , ,
From: Paul Hoffman
Subject: RE: New modules drafts -- proposed ASN.1 downgrade tutorial
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 9:35 AM -0500 1/28/09, Carl Wallace wrote:
>I volunteer to help write the document.

Thank you! Who wants to help Carl?

> > - I agree with Alfred that it should be a separate document
>> that covers all ASN.1 modules in (at least) the Security Area
>> of the IETF.
>
>Do you in mind a draft that provides guidance on how to convert 2002
>syntax into equivalent 1988 syntax or a document that includes 88 syntax
>for all security area drafts? The former seems worthwhile, I'm not sure
>about the latter.

Only the former; sorry I wasn't clearer.

> > - Future document authors can pick whether they want to do
>> their modules in 2002 or 1988 and the WGs can decide if they
>> like the decision that the authors made.
>
>Allowance of 88 syntax may make an "upgrade tutorial" component of the
>draft nice too.

That would certainly be useful as well.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SEZW8D050544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 07:35:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SEZWmW050542; Wed, 28 Jan 2009 07:35:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0SEZLOX050510 for ; Wed, 28 Jan 2009 07:35:32 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 16178 invoked from network); 28 Jan 2009 14:35:48 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;28 Jan 2009 14:35:48 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 28 Jan 2009 14:35:47 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: New modules drafts -- proposed ASN.1 downgrade tutorial
Date: Wed, 28 Jan 2009 09:35:19 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New modules drafts -- proposed ASN.1 downgrade tutorial
Thread-Index: AcmAxppGlKJqWvTHTp+ETJLuMDPqMwAjbhRg
References: <[email-masked]>
From: "Carl Wallace"
To: "Paul Hoffman" , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I volunteer to help write the document. A few comments below.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Tuesday, January 27, 2009 4:23 PM
> To: [email-masked]; [email-masked]
> Subject: Re: New modules drafts -- proposed ASN.1 downgrade tutorial
>=20
>=20
> In thinking about this a bit more:
>=20
> - I agree with Alfred that it should be a separate document=20
> that covers all ASN.1 modules in (at least) the Security Area=20
> of the IETF.

Do you in mind a draft that provides guidance on how to convert 2002
syntax into equivalent 1988 syntax or a document that includes 88 syntax
for all security area drafts? The former seems worthwhile, I'm not sure
about the latter.=20
=20
> - It is not needed if the eventual PKIX and S/MIME documents=20
> are Informational RFCs instead of Standards Track.
>=20
> - Future document authors can pick whether they want to do=20
> their modules in 2002 or 1988 and the WGs can decide if they=20
> like the decision that the authors made.

Allowance of 88 syntax may make an "upgrade tutorial" component of the
draft nice too.
=20
> Given that, I propose that someone other than Jim and I start=20
> such a "downgrade tutorial". I volunteer to review it, and=20
> I'm sure that some of the modules from Jim and my documents=20
> would be good fodder for examples in the new document.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
>=20
>=20

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RLN9qs002890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 14:23:09 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RLN9Th002889; Tue, 27 Jan 2009 14:23:09 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.163] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RLN7bH002878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 14:23:08 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 27 Jan 2009 13:23:05 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman
Subject: Re: New modules drafts -- proposed ASN.1 downgrade tutorial
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

In thinking about this a bit more:

- I agree with Alfred that it should be a separate document that covers all ASN.1 modules in (at least) the Security Area of the IETF.

- It is not needed if the eventual PKIX and S/MIME documents are Informational RFCs instead of Standards Track.

- Future document authors can pick whether they want to do their modules in 2002 or 1988 and the WGs can decide if they like the decision that the authors made.

Given that, I propose that someone other than Jim and I start such a "downgrade tutorial". I volunteer to review it, and I'm sure that some of the modules from Jim and my documents would be good fodder for examples in the new document.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RGRjvw086361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 09:27:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RGRjGH086360; Tue, 27 Jan 2009 09:27:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RGRVuQ086346; Tue, 27 Jan 2009 09:27:43 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA031413545; Tue, 27 Jan 2009 17:25:46 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA12336; Tue, 27 Jan 2009 17:25:44 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: New modules drafts -- proposed ASN.1 downgrade tutorial
To: [email-masked], [email-masked]
Date: Tue, 27 Jan 2009 17:25:44 +0100 (MEZ)
Cc: [email-masked]
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

In his recent message
( http://www.imc.org/ietf-pkix/mail-archive/msg05274.html )
Paul Hoffman wrote:

>> It's also easy enough (i.e., hit the delete key a lot) to convert
>> from the new syntax to the old syntax. Maybe we should have
>> an annex that explains how to do that?
>
> We could certainly add that if that would make the spec more useful
> to people.
>
> --Paul Hoffman, Director
> --VPN Consortium

I fully support that idea of an "ASN.1 Downgrade Tutorial" --
but _not_ as an annex to the current draft(s), as a _standalone_ draft!

Major reasons:

o much more general scope and applicability
(e.g., for LTANS et al.);

o otherwise: annex to the PKIX draft, to the CMS + S/MIME draft,
or to both? -- needless discussion!

o make it possible to reference that tutorial without
being tied to one of the two drafts;
readers will certainly appreciate an independent memo
with a less intimidating page count!

o not holding off the two "New ASN.1" drafts' progress unduely --
other work in progress already has dependencies on it;

o entirely new memo not infringed with RFC 5378 implementation issue.

BTW:
For those folks hoping for a chance of continued availability of
'CCITT' X.208/X.209 'somewhere':
Did you ever see an ITU-T Recommendation 'mirror site' ?
Please precisely read the ITU-T copyright statements,
and please ask your legal advisor before planning to make
copies available yourself, or asking other folks to do so ! :-(

Kind regards,
Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RFaEc8083392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 08:36:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RFaEmJ083391; Tue, 27 Jan 2009 08:36:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RFa2Bi083373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jan 2009 08:36:13 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-178.bbn.com ([128.89.89.178] helo=gardiner-xp.bbn.com) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LRpys-0003pW-9j; Tue, 27 Jan 2009 10:36:02 -0500
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 27 Jan 2009 10:35:59 -0500
To: Paul Hoffman , [email-masked]
From: "Charles W. Gardiner"
Subject: Re: New modules drafts posted
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 06:09 PM 1/26/2009, Paul Hoffman wrote:
>
> >It's also easy enough (i.e., hit the delete key a lot) to convert from
> the new syntax to the old syntax. Maybe we should have an annex that
> explains how to do that?
>
>We could certainly add that if that would make the spec more useful to people.

That would help a lot.

Charlie Gardiner

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0R0fGfd043400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 17:41:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0R0fG4B043399; Mon, 26 Jan 2009 17:41:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0R0f5Wn043391 for ; Mon, 26 Jan 2009 17:41:15 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 6951593C9A for ; Mon, 26 Jan 2009 19:41:04 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id EA17493C99 for ; Mon, 26 Jan 2009 19:41:03 -0500 (EST)
Message-ID: <[email-masked]>
Date: Mon, 26 Jan 2009 16:40:29 -0800
From: "Michael D'Errico"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: New modules drafts posted
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 2D8FC812-EC0B-11DD-A17E-CC4CC92D7133-38729857!a-sasl-fastnet.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> I think the modules are easier to read with the new syntax.

Then you would be someone who consults the optional '02 syntax.
Nothing wrong with that. Let's also keep the '88 syntax and we'll
both be happy.

> Because there's no bits on the wire changes....

Precisely. If there were changes that mandated using the newer
syntax, then there would be no choice but to adopt it. But since
there are none, I don't see why we should throw away perfectly
understandable structures for something more cryptic (in my opinion).

> It's also easy enough (i.e., hit the delete key a lot) to convert from
> the new syntax to the old syntax.

I disagree with this -- I can't decipher many of the structures.

Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0R08WBl042150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 17:08:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0R08W6i042149; Mon, 26 Jan 2009 17:08:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0R08UpB042143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Jan 2009 17:08:31 -0700 (MST) (envelope-from [email-masked])
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id E9BE542C7; Tue, 27 Jan 2009 00:08:29 +0000 (GMT)
Received: from [10.87.48.8] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n0R08Qek032183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jan 2009 00:08:27 GMT
Message-ID: <[email-masked]>
Date: Tue, 27 Jan 2009 00:10:27 +0000
From: Stephen Farrell
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: Sean Turner
CC: [email-masked]
Subject: Re: New modules drafts posted
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.60 () [Hold at 8.00] J_CHICKENPOX_52
X-Canit-Stats-ID: 36609125 - bbf5e2831cfc
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Sean Turner wrote:
>
> I think the modules are easier to read with the new syntax.

As someone who's not written code for this for some years,
I disagree with Sean and Paul - I find the '88 syntax easier
to understand. And that was true when I was still writing
relevant code.

It might be that there're cases where '88 syntax is under
specified all right, however, I'd guess that code for most
of the interesting ones of those is already written and
deployed.

The fact that ITU-T have withdrawn the '88 spec would be
ameliorated were that spec to be actually available
regardless. I thought that that was the case, but maybe I'm
wrong? (I.e. can I find it easily, regardless of what the
official position is?)

S.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QN9shw040290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 16:09:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QN9s2b040289; Mon, 26 Jan 2009 16:09:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QN9pv4040281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 16:09:52 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 26 Jan 2009 15:09:49 -0800
To: Sean Turner , [email-masked]
From: Paul Hoffman
Subject: Re: New modules drafts posted
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 4:28 PM -0500 1/26/09, Sean Turner wrote:
>I think the modules are easier to read with the new syntax. For example, it's much easier for me to figure out an algorithm's parameters from the proposed syntax than from having to hope that an author put comments in the module to link the OID and the parameters (assuming I don't both to read the text of the RFC).
>
>Because there's no bits on the wire changes, parsers/decoders that interpret '88 DER encoded octet strings will continue to parse '02 DER encoded octet strings. To go from the new ASN.1 to C, there's at least one free ASN.1 compiler (http://code.google.com/p/a2c/) and I've been told there are others that also compile these modules. Not sure about encoders.
>
>A reason to use the newer syntax, which may have been mentioned a while ago, is that the '88 ASN.1 specifications aren't available from ITU-T anymore. If somebody is trying to be a pain they just have to ask where do I get those specifications from and unless you've got a copy handy you're sunk ... or they've got to find a developer who's got them (nice job security ;)

I'm with Sean on all of the above. I can see why some people think the old syntax is easier to read for parameters: all of the real stuff is in human-written comments. That doesn't make for interoperable protocols, however.

The ITU has pushed strongly on the IETF to abandon the '88 syntax, and has in fact made the specification for that unavailable. Whether you like it or not (I don't particularly...), it's their spec.

>It's also easy enough (i.e., hit the delete key a lot) to convert from the new syntax to the old syntax. Maybe we should have an annex that explains how to do that?

We could certainly add that if that would make the spec more useful to people.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QLSW4l036732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 14:28:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QLSWBm036731; Mon, 26 Jan 2009 14:28:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0QLSLTW036721 for ; Mon, 26 Jan 2009 14:28:31 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 9325 invoked from network); 26 Jan 2009 21:28:18 -0000
Received: from unknown (HELO ?192.168.1.2?) ([email-masked] with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 26 Jan 2009 21:28:17 -0000
X-YMail-OSG: _07tBJ4VM1lEhOLovUHBTpKJrozvNRFLBQxTFlj1czXraV2tf0WXPqO4tWnVssyT28v5DDCJoqgpLYKkVqsMkH8LH0MnhZjsrQUzeR7zV_TdzaOBuTnwUuQQBgdN1tY8EtnzfVfEUSqDc2X9du_U4Dw3I0qFosC450TuN0LUTGq9TNzCmVOUX2k4YiRt6oJ533Miv6ZquflBp4fwqi5UZfZLZrrwPvDsr5c7RVg-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Mon, 26 Jan 2009 16:28:44 -0500
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: New modules drafts posted
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I think the modules are easier to read with the new syntax. For
example, it's much easier for me to figure out an algorithm's parameters
from the proposed syntax than from having to hope that an author put
comments in the module to link the OID and the parameters (assuming I
don't both to read the text of the RFC).

Because there's no bits on the wire changes, parsers/decoders that
interpret '88 DER encoded octet strings will continue to parse '02 DER
encoded octet strings. To go from the new ASN.1 to C, there's at least
one free ASN.1 compiler (http://code.google.com/p/a2c/) and I've been
told there are others that also compile these modules. Not sure about
encoders.

A reason to use the newer syntax, which may have been mentioned a while
ago, is that the '88 ASN.1 specifications aren't available from ITU-T
anymore. If somebody is trying to be a pain they just have to ask where
do I get those specifications from and unless you've got a copy handy
you're sunk ... or they've got to find a developer who's got them (nice
job security ;)

It's also easy enough (i.e., hit the delete key a lot) to convert from
the new syntax to the old syntax. Maybe we should have an annex that
explains how to do that?

Obviously, I'm in favor of standards track.

spt

Michael D'Errico wrote:
>
> I would like to request that the new ASN.1 documents be given an
> Informational rating rather than standard track. The new ASN.1,
> in my personal opinion, makes it more difficult for *humans* to
> understand; the benefit is supposedly for ASN.1 compilers. I
> make this request so that the new ASN.1 does not eventually end
> up in standard-track documents which make use of the structures,
> where it is paramount that implementers understand them. People
> who have advanced ASN.1 compilers can easily grab the new ASN.1
> from an Informational document and realize the benefits it is
> supposed to provide.
>
> Mike
>
>
> Paul Hoffman wrote:
>> Since I sent out this message below, we had one group of folks respond
>> with a few small technical changes, but no other comments.
>>
>> In the spirit of forward motion, we would like the chairs of PKIX and
>> S/MIME to put the respective documents into WG Last Call so we can
>> shake out any last comments and put these on standards track.
>>
>> At 8:52 AM -0800 1/9/09, Paul Hoffman wrote:
>>> Greetings again. This message should appear after the posting
>>> announcements for draft-ietf-pkix-new-asn1-02 and
>>> draft-ietf-smime-new-asn1-02 appear. If not, please wait a bit. :-)
>>>
>>> Jim and I have major changes to the modules, and we think that our
>>> work is now done, modulo bug fixes. To that end, we would *really*
>>> like folks on either of these two lists who have ASN.1 compilers that
>>> handle the 2002 syntax to review the modules carefully and let both
>>> lists know if there are any errors. In addition, we are still open to
>>> comments on our choice of style for the new objects in the modules.
>>>
>>> If you want to get copies of the modules without tedious
>>> copy-and-pasting, get the latest version of a2c from the a2c project
>>> (), specifically either
>>> or
>>> . The modules are in the
>>> test/ directory. The makefile in that directory has all of the
>>> dependencies needed, although we are happy to have you test your own
>>> dependencie chain yourself.
>>>
>>> At this point, we think that comments to both lists are appropriate,
>>> given the shared design between the two drafts and the heavy
>>> cross-dependencies between the modules.
>>>
>>> --Paul Hoffman, Director
>>> --VPN Consortium
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QJeuF8032330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 12:40:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QJeu7b032329; Mon, 26 Jan 2009 12:40:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from helios.bolet.org (helios.bolet.org [88.191.25.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QJei7A032318 for ; Mon, 26 Jan 2009 12:40:55 -0700 (MST) (envelope-from [email-masked])
Received: by helios.bolet.org (Postfix, from userid 1001) id 9E3365C167; Mon, 26 Jan 2009 20:40:43 +0100 (CET)
Date: Mon, 26 Jan 2009 20:40:43 +0100
From: Thomas Pornin
To: [email-masked]
Subject: Re: New modules drafts posted
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Mon, Jan 26, 2009 at 02:06:53PM -0500, Charles W. Gardiner wrote:
> Like Mike, I have also implemented an ASN.1 parser based on the 1988
> syntax (plus a simple method for implementing the "ANY DEFINED BY"
> construct) and have used it quite extensively for processing
> certificates and CRLs.

So did I. That is a generic and common pattern. I see two main reasons
for that:

-- It is considerably simpler to write a parser for the 1988 syntax
than for the 1993 syntax.

-- RFC 3280 included only the 1988 syntax modules.

In the ideal world, one would not write an ASN.1 parser. The ideal model
predicts that application developpers would simply use an existing ASN.1
compiler. However, ASN.1 compilers translate the ASN.1 syntax into some
code or templates for a given BER/DER library. It often happens that
existing encoding libraries are not adequate for some platforms,
especially embedded architectures (e.g., one does not always have the
luxury of a malloc() function...). So, invariably, developpers find out
that they must parse ASN.1 themselves, either by writing a parser, or
even manually (I did that, too). The 1988 syntax is much more convenient
for that.

I do not mind new modules becoming the standard -- as long as equivalent
modules in the 1988 syntax are available, and somebody makes sure that
both versions are synchronized (I do NOT volunteer for that), so that
application development can keep on using the simple syntax when needed.

Theoretically, an existing ASN.1 parser (for the new syntax) could be
modified to output equivalent modules in the 1988 syntax automatically.
Does such a code exist somewhere ?

--Thomas Pornin

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QJ7BWt030673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 12:07:11 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QJ7BrJ030672; Mon, 26 Jan 2009 12:07:11 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QJ6xFK030660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Jan 2009 12:07:10 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-178.bbn.com ([128.89.89.178] helo=gardiner-xp.bbn.com) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LRWnP-0004sI-CY; Mon, 26 Jan 2009 14:06:55 -0500
Message-Id: <[email-masked]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 26 Jan 2009 14:06:53 -0500
To: [email-masked]
From: "Charles W. Gardiner"
Subject: Re: New modules drafts posted
Cc: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I agree with Michael D'Errico's suggestion that the proposed new
documents remain as optional. They are very difficult for mere mortals to
comprehend. The criss-cross of imports and the extensive use of
higher-level abstractions make them very complicated. I fear that such
complexity may aid those who wish to deceive. Like Mike, I have also
implemented an ASN.1 parser based on the 1988 syntax (plus a simple method
for implementing the "ANY DEFINED BY" construct) and have used it quite
extensively for processing certificates and CRLs.

Charlie Gardiner

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0PApMYp047217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2009 03:51:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0PApMKv047216; Sun, 25 Jan 2009 03:51:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0PApBsr047206 for ; Sun, 25 Jan 2009 03:51:22 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9503027ACE for [email-masked]; Sun, 25 Jan 2009 11:51:10 +0100
Message-ID: <6270775D12B04980BE63B339AA646996@AndersPC>
From: "Anders Rundgren"
To:
Subject: FIPS 140-2 Compliant On-line Key Provisioning
Date: Sun, 25 Jan 2009 11:51:13 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C97EE3.38B87B20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_0086_01C97EE3.38B87B20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FIPS 140-2 Compliant On-line Key Provisioning

What does that mean? My interpretation of this is that the =
characteristics ("quality") of a device's cryptographic module must be =
verifiable in a secure manner by an issuer without requiring visual =
inspection or OOB-acquired knowledge of the device in question.

Currently no such thing exists because there haven't really been any =
requirements for such facilities since most critical schemes rely on =
physical distribution of smart card tokens. However, as recently shown =
in the news, even the US president wants to use a mobile device for =
communication:
http://news.cnet.com/obamas-new-blackberry-the-nsas-secure-pda

In order to make this scale better (not everyone gets the same attention =
as Mr. Obama), I have since some time back been plotting with a protocol =
that should support FIPS 140-2 measurements over the air. There are =
other things needed (and included) as well but to not unnecessary =
complicate interpretation, this particular feature has so far been =
described separately:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

How does this relate to PKIX? I leave that to you as a group to =
consider. My current plan is making this (in due time) available on =
Google's Android because open source seems to be the fastest route these =
days.

An observation made during the development that you may find interesting =
(or alarming), is that there seems to be a requirement that the =
cryptographic module and the protocol are tightly matched in order to =
achieve anything of this kind.

Anders Rundgren

FIPS 140-2:
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf=20

------=_NextPart_000_0086_01C97EE3.38B87B20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FIPS 140-2 Compliant On-line =
Key=20
Provisioning

What does that mean?  My =
interpretation of=20
this is that the characteristics ("quality") of a device's cryptographic =
module=20
must be verifiable in a secure manner by an issuer without requiring =
visual=20
inspection or OOB-acquired knowledge of the device in =
question.

Currently=20
no such thing exists because there haven't really been any requirements =
for such=20
facilities since most critical schemes rely on physical distribution of =
smart=20
card tokens.  However, as recently shown in the news, even the US =
president=20
wants to use a mobile device for communication:
<=
FONT=20
face=3DArial=20
size=3D2>http://news.cnet.com/obamas-new-blackberry-the-nsas-secure-pda

In order to make this scale better (not everyone =
gets the same=20
attention as Mr. Obama), I have since some time back been plotting with =
a=20
protocol that should support FIPS 140-2 measurements over the air.  =
There=20
are other things needed (and included) as well but to not unnecessary =
complicate=20
interpretation, this particular feature has so far been described=20
separately:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

How does this relate to PKIX?  I leave that =
to you as a=20
group to consider.  My current plan is making this (in due time) =
available=20
on Google's Android because open source seems to be the fastest route =
these=20
days.

An observation made during the development that you may =
find=20
interesting (or alarming), is that there seems to be a requirement that =
the=20
cryptographic module and the protocol are tightly matched in order to =
achieve=20
anything of this kind.

Anders Rundgren

FIPS =
140-2:
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

------=_NextPart_000_0086_01C97EE3.38B87B20--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0NLcxKa064680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 14:38:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0NLcxwM064679; Fri, 23 Jan 2009 14:38:59 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0NLclm3064626 for ; Fri, 23 Jan 2009 14:38:58 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227] helo=[192.168.1.4]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LQTji-00020m-FA for [email-masked]; Fri, 23 Jan 2009 16:38:47 -0500
Mime-Version: 1.0
Message-Id:
Date: Fri, 23 Jan 2009 16:38:42 -0500
To: [email-masked]
From: Stephen Kent
Subject: this document may of interest to PKIX members
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>
>
>The IESG has no problem with the publication of 'Syntax for binding
>documents with time stamps' as an
>Informational RFC.
>
>The IESG would also like the IRSG or RFC-Editor to review the comments in
>
>the datatracker
>(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16302&rfc_flag=0)
>related to this document and determine whether or not they merit
>incorporation into the document. Comments may exist in both the ballot
>and the comment log.
>
>The IESG contact person is Tim Polk.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-santoni-timestampeddata-04.txt
>
>
>The process for such documents is described at
>http://www.rfc-editor.org/indsubs.html.
>
>Thank you,
>
>The IESG Secretary
>
>Technical Summary
>
> This document describes a syntax which can be used to bind a generic
> document (or any set of data, not necessarily protected by means of
> cryptographic techniques) to one or more time-stamp tokens obtained
> for that document, where "time-stamp token" has the meaning defined
> in RFC 3161. Additional types of temporal evidence are also
> supported.
>
>Working Group Summary
>
> This document is not the product of any IETF WG.
>
>Protocol Quality
>
> The documents were reviewed by Tim Polk for the IESG. Carl Wallace
> also reviewed the document for conflicts with the LTANS working group.
>
>RFC Editor Note
>
> The IESG thinks that this work is related to IETF work done in the
> Long-Term Archive and Notary Services (ltans) WG, but this does not
> prevent publishing.
>
>IESG Note
>
> This RFC is not a candidate for any level of Internet Standard.
> The IETF disclaims any knowledge of the fitness of this RFC for
> any purpose and notes that the decision to publish is not based on
> IETF review apart from IESG review for conflict with IETF work. The
> standards track specification RFC 4998, Evidence Record Syntax (ERS),
> specifies an alternative mechanism. Readers are encouraged to also
> review RFC 4998 when evaluating the suitability of this mechanism.
> The RFC Editor has chosen to publish this document at its
> discretion. See RFC 3932 for more information.
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-announce

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0NIQxpX056013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 11:26:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0NIQxC0056012; Fri, 23 Jan 2009 11:26:59 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0NIQlkl055971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jan 2009 11:26:59 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227] helo=[192.168.1.4]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LQQju-0003s8-CY for [email-masked]; Fri, 23 Jan 2009 13:26:47 -0500
Mime-Version: 1.0
Message-Id:
Date: Fri, 23 Jan 2009 13:26:43 -0500
To: [email-masked]
From: Stephen Kent
Subject: WGLC on 5 documents
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,

I have been asked (more properly, reminded :-)) by several authors to
initiate WGLC on documents, so here goes:

1. 3281 Update: this is an update of the attribute cert
profile, now at version 03, published on 12/22/08. This seems to be
non-controversial.

2. New ASN.1: this is the new ASN.1 modules for PKIX
document. Version 2 was posted on 1/9/09. The only suggested change I
have seen on the list recently is that use of these modules be
optional, not mandatory, i.e., to allow both the 1988 and the 2002
version of ASN.1 to be considered as equally valid syntaxes. I have
not seen a response from the authors on this detail, but that can be
addressed during last call, e.g., with proposed text to accommodate
the comment from the two folks who raised the issue.

3. Authority Clearance Constraints: This document is at
version 02 and was posted just before the IETF meetings in November.
The minutes from that meeting said the document appeared to be ready
for WGLC. I wrote the minutes, so let's do it and see if that
assertion was correct!

4. PRQP: this is an I-D targeted toward experimental status.
Max posted a new version (02) after the IETF meeting, and I have seen
no comments on the list, so let's see if we can move forward with
this one as well.

5. Trust Anchor Management Requirements: Based on the
discussion on the list, it seems that there is agreement to NOT
publish the TA requirements document (ta-mgmt-reqs, version 02) as an
RFC at this time. Rather, as Stefan suggested, PKIX can keep it
active as a live document and update it as needed as work progresses
on the TA format and TAMP documents. Nonetheless, I would like to
initiate a WGLC at this time, so that we can determine if we have
consensus on the requirements statement as of now, even though we
will NOT YET move it to RFC status.

Let's provide last call comments, if needed, on all 5 of these
documents over the next two week. WGLC will end for all of them on
February 6. Based on the comments received and the responses provided
by document editors, we'll proceed with each as appropriate.

Steve

P.S. The November PKIX minutes also said that Stephen Farrell's
Other Certs I-D would be ready for last call after removal of
embedded comments. No new version has been posted yet, but when
Stephen does post the next version, we can move to WGLC on this
document as well.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LD4RPV079905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 06:04:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LD4ReP079904; Wed, 21 Jan 2009 06:04:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LD4FuL079896 for ; Wed, 21 Jan 2009 06:04:26 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1E93B481549; Thu, 22 Jan 2009 02:04:15 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+wL4qLLhJm8; Thu, 22 Jan 2009 02:04:15 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3BD43481545; Thu, 22 Jan 2009 02:04:11 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 33C2F1BE4001; Thu, 22 Jan 2009 02:04:08 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LPcka-0001zA-2M; Thu, 22 Jan 2009 02:04:08 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: A proxy certificate validation question.
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Thu, 22 Jan 2009 02:04:08 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Timothy J. Miller" writes:

>IMHO that's not a planning failure, that's an execution failure.

It's neither an execution failure nor a planning failure, it's a design
failure. A system that requires you to download anything more than a boolean
yes/no response to "is this cert I've got OK" (with a little extra crypto
protection as required) is broken. Don't blame the users when the tools are
at fault.

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LB9QFx072161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 04:09:26 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0LB9Qdu072160; Wed, 21 Jan 2009 04:09:26 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0LB9Ce8072144 for ; Wed, 21 Jan 2009 04:09:24 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 06BEC9D413; Thu, 22 Jan 2009 00:09:12 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBPuWVIt0TtA; Thu, 22 Jan 2009 00:09:11 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2FFEA9D410; Thu, 22 Jan 2009 00:09:10 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 466181BE4001; Thu, 22 Jan 2009 00:09:07 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LPaxH-0004UP-3k; Thu, 22 Jan 2009 00:09:07 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: A certificate validation question.
Cc: [email-masked], [email-masked]
In-Reply-To:
Message-Id:
Date: Thu, 22 Jan 2009 00:09:07 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stephen Kent writes:
>At 7:13 PM +1300 1/14/09, Peter Gutmann wrote:
>>Eric Norman writes:
>>
>>>After all, if you're going to do an on-line status check every time a
>>>certificate is used, then why are you using this certificate stuff in
>>>the first place?
>>
>>Ooh, ooh, I know that one, the answer is:
>>
>> "because of digital ancestor-worship of closed-door OSI standards
>> from the 1980s"
>>
>>and it was from an NCSC(?) paper some years ago.
>
>for bonus points (and to help validate your comment) can you provide a cite
>of the relevant OSi standards, or the NCSC paper?

Uhh, I think it should be obvious which OSI standard OCSP is a digital
ancestor-worship of. As for the conference, all I have is the quote on
my home page:

[PKI designs are based on] digital ancestor-worship of closed-door-generated
standards going back to at least the mid 80's. [...] The result seems to be
protocols so convoluted and obtuse that vendor implementation is
difficult/impossible and costly.
- William Flanigan Jr. and Deborah Mitchell

Unfortunately I don't recall exactly where that came from, whatever it is it's
a paper-only publication since Google doesn't find any hits for it, and one of
the NCSC proceedings seemed to be a good match. However I'm not actually
going to plough through them all to see if it really was from there.

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KMaoCS040999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 15:36:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KMaoj2040998; Tue, 20 Jan 2009 15:36:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KMamwY040991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jan 2009 15:36:49 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LPPDD-00031o-CO; Tue, 20 Jan 2009 17:36:48 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 20 Jan 2009 16:56:24 -0500
To: "Timothy J. Miller"
From: Stephen Kent
Subject: Re: A proxy certificate validation question.
Cc: "Kemp, David P." , "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Tim,

One of my favorite examples of poor CAC CRL planning has to do with
the fact that when a CAC holder is promoted, the CAC has to be
replaced (the rank info on the physical card is no longer accurate).
One result of this replacement is revocation of the 3 certs on the
card. The DoD must have some reasonable data on the expected
promotion frequency of personnel at various rungs in the career
ladder, and this info could have been used to adjust the validity
interval to more closely track the expected lifetime of the certs
relative to this very common revocation reason.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KLpHXk039316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 14:51:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KLpHY3039315; Tue, 20 Jan 2009 14:51:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KLp66A039303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jan 2009 14:51:17 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LPOUw-0002Ns-9k; Tue, 20 Jan 2009 16:51:02 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 20 Jan 2009 14:12:43 -0500
To: "Timothy J. Miller"
From: Stephen Kent
Subject: Re: A proxy certificate validation question.
Cc: Nelson B Bolyard , "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 11:20 AM -0600 1/20/09, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>CRLs of that size are usually an indication of very poor planning,
>>the CRL for CACs being a prime example.
>
>Which is of course what I was thinking of. However, you can blame
>planning all you want but folks still have to deal with the
>consequences.
>
>However, IMHO it's unfair to call this poor planning, since the DoD
>PKI was (is?) unique in scale.
>
>-- Tim

The DoD PKI folks (at DISA, Mitre, and NSA) were advised about some
of the inevitable, adverse side effects of their strategies well
before the CRL turned into Godzilla. I know, because I was one of
those who delivered the warnings. The response was of the form "we're
too far along in our planning to change now" and the result was as
expected.

This was an train wreck that folks chose to not avoid.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KKbVWg036260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 13:37:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KKbVHD036259; Tue, 20 Jan 2009 13:37:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KKbKi6036249 for ; Tue, 20 Jan 2009 13:37:30 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KKbJbZ008271 for ; Tue, 20 Jan 2009 15:37:19 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KKbJGn008266; Tue, 20 Jan 2009 15:37:19 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 20 Jan 2009 15:37:19 -0500
Message-ID: <[email-masked]>
Date: Tue, 20 Jan 2009 14:36:34 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Kemp, David P."
CC: "[email-masked]"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070301070901040008030201"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms070301070901040008030201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kemp, David P. wrote:
> It absolutely is fair to call it poor planning, since CRLs could be
> partitioned into small chunks of 1,000-10,000 subjects each regardless
> of the total scale of the PKI.

Partitioning CRLs doesn't address the overall size issue, it just
divides it into smaller pieces. This may benefit a client, but a server
is still going to have to pull all the chunks every nextUpdate interval,
with the same impact on the source's bandwidth.

The core issue is the failure to get a handle on the number of
administrative revocations going on, and the lack of a functioning
feedback from operational experience into planning. For instance, how
many CACs last until the end of the current three year key cryptoperiod?
I know mine rarely last more than 1.5-2 years. Why isn't this fed
back into planning to reduce the cryptoperiod? That alone would ease
pressure on CRL growth.

IMHO that's not a planning failure, that's an execution failure.

> Using pre-signed OCSP responses of
> 20-subject partitions provides no benefit over 20-subject CRLs, but is
> hugely inefficient of bandwidth and storage.

Batched OCSP is used because producing single responses takes so long
the process doesn't finish before the new CRL is available.

-- Tim

--------------ms070301070901040008030201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMjAyMDM2MzRaMCMGCSqGSIb3DQEJBDEWBBTW/aYQgjn+6Cp5mu0ap1N8pYjGdzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgA5Wu4TJmCu59rTRics1RZpvB3Z4AVz9Ar8HeJL8bze6HvIZ9P1MRYtWb8KP
SDSvo994zcJ2/W6jyQ/lRHVaJyad3qchmFThABL7V9jIXBgO6YgvaY2xEYMPPmtEJxhnO1Z7
3xyS/rzK3ba3D21bE4jlS/tGX0ohxDKEdOijIpYVAAAAAAAA
--------------ms070301070901040008030201--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KJoiBh034105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 12:50:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KJoi2W034104; Tue, 20 Jan 2009 12:50:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KJoX4o034087 for ; Tue, 20 Jan 2009 12:50:43 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: A proxy certificate validation question.
Date: Tue, 20 Jan 2009 14:50:14 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: A proxy certificate validation question.
Thread-Index: Acl7KFgom12UsHZXQ/uQIssr8z1JBQADkqXw
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Kemp, David P."
To:
X-OriginalArrivalTime: 20 Jan 2009 19:46:46.0312 (UTC) FILETIME=[D3C57280:01C97B37]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

It absolutely is fair to call it poor planning, since CRLs could be
partitioned into small chunks of 1,000-10,000 subjects each regardless
of the total scale of the PKI. Using pre-signed OCSP responses of
20-subject partitions provides no benefit over 20-subject CRLs, but is
hugely inefficient of bandwidth and storage.

If we think the current revocation structure is inadequate for 4 million
active users, what happens when it expands to cover 40 million
dependents and retirees? A little planning would be nice.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Timothy J. Miller
Sent: Tuesday, January 20, 2009 12:21 PM
To: Stephen Kent
Cc: Nelson B Bolyard; [email-masked]
Subject: Re: A proxy certificate validation question.

Stephen Kent wrote:

> CRLs of that size are usually an indication of very poor planning,=20
> the CRL for CACs being a prime example.

Which is of course what I was thinking of. However, you can blame=20
planning all you want but folks still have to deal with the
consequences.

However, IMHO it's unfair to call this poor planning, since the DoD PKI=20
was (is?) unique in scale.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KHLRBZ028378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 10:21:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KHLRSM028377; Tue, 20 Jan 2009 10:21:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KHLPc1028370 for ; Tue, 20 Jan 2009 10:21:26 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KHLPpY018318 for ; Tue, 20 Jan 2009 12:21:25 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KHLPH5018310; Tue, 20 Jan 2009 12:21:25 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 20 Jan 2009 12:21:24 -0500
Message-ID: <[email-masked]>
Date: Tue, 20 Jan 2009 11:20:38 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Stephen Kent
CC: Nelson B Bolyard , "[email-masked]"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090700010504030800030908"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms090700010504030800030908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> CRLs of that size are usually an indication of very poor planning,
> the CRL for CACs being a prime example.

Which is of course what I was thinking of. However, you can blame
planning all you want but folks still have to deal with the consequences.

However, IMHO it's unfair to call this poor planning, since the DoD PKI
was (is?) unique in scale.

-- Tim

--------------ms090700010504030800030908
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMjAxNzIwMzhaMCMGCSqGSIb3DQEJBDEWBBTQuOws7cSLiHUgc2ksnTX3gvtY7zBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgGN4cptjB85wW8xim6Nugv50Lyo/e/15vgoXhOl7Sj5361JCYRYXMIjcdvNe
Nb7wsoW4LryNx7Zp9uUa+Jq6LGT5f08P5xvsARaPEtLQq9rGWHdDqhZp5AwyXssROpgHuipc
RvnZbUc2CdSlyYiey7oV36zwYjty4V2bmPmRPU5nAAAAAAAA
--------------ms090700010504030800030908--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KHCT2c027870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 10:12:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KHCTTc027869; Tue, 20 Jan 2009 10:12:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KHCIOj027842 for ; Tue, 20 Jan 2009 10:12:29 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LPK9B-0002xM-Df; Tue, 20 Jan 2009 12:12:17 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 20 Jan 2009 11:49:45 -0500
To: "Timothy J. Miller"
From: Stephen Kent
Subject: Re: A proxy certificate validation question.
Cc: Nelson B Bolyard , "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 10:35 AM -0600 1/20/09, Timothy J. Miller wrote:
>Nelson B Bolyard wrote:
>
>>TLS servers that request client authentication prefer to use CRLs than
>>OCSP for validating client certs because it's faster and more efficient
>>to use a CRL downloaded (say) daily than to do an OCSP query for every
>>connection.
>
>That's all well and good until your CRLs get to a couple of hundred megabytes.
>
>-- Tim

CRLs of that size are usually an indication of very poor planning,
the CRL for CACs being a prime example.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KGacPl026185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 09:36:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KGac82026184; Tue, 20 Jan 2009 09:36:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KGaQcX026144 for ; Tue, 20 Jan 2009 09:36:37 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KGaPEo030019 for ; Tue, 20 Jan 2009 11:36:25 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KGaOSQ029997; Tue, 20 Jan 2009 11:36:24 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 20 Jan 2009 11:36:24 -0500
Message-ID: <[email-masked]>
Date: Tue, 20 Jan 2009 10:35:38 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Nelson B Bolyard
CC: "[email-masked]"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060307090404010508070404"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms060307090404010508070404
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Nelson B Bolyard wrote:

> TLS servers that request client authentication prefer to use CRLs than
> OCSP for validating client certs because it's faster and more efficient
> to use a CRL downloaded (say) daily than to do an OCSP query for every
> connection.

That's all well and good until your CRLs get to a couple of hundred
megabytes.

-- Tim

--------------ms060307090404010508070404
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMjAxNjM1MzhaMCMGCSqGSIb3DQEJBDEWBBSDBndZoagp1mt2FPV2Vbc9p81cwjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAKGruU9LdzK56lQjSE2aw51UOm9L9flOMQDvLGSyIQJklgt8K856k2NMNq/
sAZGg/9ykC0XHSneBD7g1ojeicq4XSpjPbpDCuLV6VnyU7X+tWscf82ji7W80YtkcN11EWdv
01xQ2h5pvOYnar6mH/CrtskMlgmPJdloeAENnuLFAAAAAAAA
--------------ms060307090404010508070404--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GNx8s6049519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 16:59:09 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0GNx8YR049518; Fri, 16 Jan 2009 16:59:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GNwudl049498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Jan 2009 16:59:08 -0700 (MST) (envelope-from [email-masked])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0GNvMD5024293 for ; Fri, 16 Jan 2009 18:57:22 -0500
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0GNwt8a187342 for ; Fri, 16 Jan 2009 18:58:55 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n0GNwtid006454 for ; Fri, 16 Jan 2009 18:58:55 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n0GNwt96006451; Fri, 16 Jan 2009 18:58:55 -0500
In-Reply-To: <[email-masked]>
To: Eric Norman
Cc: [email-masked]
MIME-Version: 1.0
Subject: Re: A certificate validation question.
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin
Message-ID:
Date: Fri, 16 Jan 2009 18:58:54 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 01/16/2009 18:58:55, Serialize complete at 01/16/2009 18:58:55
Content-Type: text/plain; charset="US-ASCII"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Eric:

May I be equally flippant, but less dismissive? If an RP
developer goes out on the Internet for a certificate status check, he
expects a recent signature as assurance of the result. He won't bother
otherwise, as some don't even with signed responses.

Tom Gindin

Eric Norman
Sent by: [email-masked]
01/13/2009 04:13 PM

To
[email-masked]
cc

Subject
Re: A certificate validation question.

On Jan 12, 2009, at 1:54 PM, Stephen Kent wrote:

> The X.509 PKI model has never assumed that one should check the
> validity of a cert by looking for it in some repository.

After all, if you're going to do an on-line status check
every time a certificate is used, then why are you using
this certificate stuff in the first place?

Eric Norman

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GNJsYQ047788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 16:19:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0GNJsAH047787; Fri, 16 Jan 2009 16:19:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0GNJh4m047771 for ; Fri, 16 Jan 2009 16:19:53 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29151 invoked from network); 16 Jan 2009 23:19:42 -0000
Received: from unknown (64.202.165.38) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 16 Jan 2009 23:19:42 -0000
Message-ID: <[email-masked]>
Date: Fri, 16 Jan 2009 15:19:41 -0800
From: Nelson B Bolyard
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: [email-masked]
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Phillip Hallam-Baker wrote:
> On the CRL thing, yes people will continue to use CRLs. In particular
> for describing the status of OCSP responder certs. But if folk come
> along and say reduce two mechanisms to one, OCSP is going to be the one
> left in virtually all application level applications.

David P. Kemp wrote:
> â€¦ and for the status of CA certificates, server certificates, or any
> other class of subjects for which the revocation rate is very low. CRLs
> are an attractive approach when the only information to be transmitted
> is akin to â€œyes, the stars are still shining in the heavensâ€ and only
> the occasional supernova needs to be individually enumerated.

TLS servers that request client authentication prefer to use CRLs than
OCSP for validating client certs because it's faster and more efficient
to use a CRL downloaded (say) daily than to do an OCSP query for every
connection.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GLh8Fn043790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 14:43:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0GLh85U043789; Fri, 16 Jan 2009 14:43:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GLgvOt043777 for ; Fri, 16 Jan 2009 14:43:07 -0700 (MST) (envelope-from [email-masked])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97823.50573031"
Subject: RE: A proxy certificate validation question.
Date: Fri, 16 Jan 2009 16:42:22 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: A proxy certificate validation question.
Thread-Index: Acl1uqUK4dCerQTNR02JcbTeWNvhoACXqrMJAAImRmA=
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Kemp, David P."
To:
X-OriginalArrivalTime: 16 Jan 2009 21:39:15.0031 (UTC) FILETIME=[E0AB3E70:01C97822]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C97823.50573031
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

... and for the status of CA certificates, server certificates, or any =
other class of subjects for which the revocation rate is very low. CRLs =
are an attractive approach when the only information to be transmitted =
is akin to "yes, the stars are still shining in the heavens" and only =
the occasional supernova needs to be individually enumerated.

=20

=20

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Hallam-Baker, Phillip
Sent: Friday, January 16, 2009 3:43 PM
To: Stephen Kent
Cc: Johannes Merkle; Philipp G=FChring; [email-masked]
Subject: RE: A proxy certificate validation question.

=20

On the CRL thing, yes people will continue to use CRLs. In particular =
for describing the status of OCSP responder certs. But if folk come =
along and say reduce two mechanisms to one, OCSP is going to be the one =
left in virtually all application level applications.

=20

=20

------_=_NextPart_001_01C97823.50573031
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: A proxy certificate validation question.

… and for the status of CA certificates, server
certificates, or any other class of subjects for which the revocation =
rate is very
low.=A0 CRLs are an attractive approach when the only information to be
transmitted is akin to “yes, the stars are still shining in the =
heavens”
and only the occasional supernova needs to be individually =
enumerated.

From:=
=
[email-masked]
[mailto:[email-masked]] On Behalf Of Hallam-Baker, =
Phillip

Sent: Friday, January 16, 2009 3:43 PM

To: Stephen Kent

Cc: Johannes Merkle; Philipp G=FChring; [email-masked]

Subject: RE: A proxy certificate validation =
question.

On
the CRL thing, yes people will continue to use CRLs. In particular for
describing the status of OCSP responder certs. But if folk come along =
and say
reduce two mechanisms to one, OCSP is going to be the one left in =
virtually all
application level applications.

------_=_NextPart_001_01C97823.50573031--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GLCjq5042866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 14:12:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0GLCjc7042865; Fri, 16 Jan 2009 14:12:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GLCiMu042857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Jan 2009 14:12:44 -0700 (MST) (envelope-from [email-masked])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n0GKnM3Y017042 for ; Fri, 16 Jan 2009 12:50:02 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 13:12:42 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9781F.2B673C2C"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Why use PKI? [was: A certificate validation question]
Date: Fri, 16 Jan 2009 13:12:42 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Why use PKI? [was: A certificate validation question]
Thread-Index: Acl2kOlM0W/NfqOYRiiNSw8wdpDZ8gBijnao
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: ,
X-OriginalArrivalTime: 16 Jan 2009 21:12:42.0619 (UTC) FILETIME=[2B8474B0:01C9781F]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9781F.2B673C2C
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Not to labor the point, but XKMS is a PKI as well. The original =
code-name was Trust Assertion XML Infrastructure.
=20
The static assertions were then separated from the dynamic protocol. The =
dynamic protocol turned into XKMS. The static protocol led to the =
assertion layer of SAML.
=20
=20
What you really want though is simply a CKI. A Cryptographic Key =
Infrastructure. There is really no point is committing yourself up front =
to only use one form of cryptography.=20
=20

________________________________

From: [email-masked] on behalf of Stephen Wilson
Sent: Wed 1/14/2009 3:37 PM
To: [email-masked]
Subject: Why use PKI? [was: A certificate validation question]

Eric Norman 14/Jan/2009 wrote:
>
> On Jan 12, 2009, at 1:54 PM, Stephen Kent wrote:
>
>> The X.509 PKI model has never assumed that one should check the
>> validity of a cert by looking for it in some repository.
>
> After all, if you're going to do an on-line status check
> every time a certificate is used, then why are you using
> this certificate stuff in the first place?

Using certificates in an online-all-the-time environment can indeed look
like overkill. But in my view, the greatest and most unique benefit
of PKI comes in offline environments where it is important to be able to
check the historical validity of a transaction. Because certificates
bake in the attributes of a sender as they were at the time of the
transaction, and the validity at any time in the past can be easily
checked by the CRLs and delta CRLs (OK, now I'm veering away from online
status check).

My favorite examples are from e-health. Take an electronic
prescription, digitally signed by a physician, using her certificate
issued by a medical registration board. The script might also be
counter signed by the patient using a smartcard. In the case of
narcotics or other scheduled medications, a special license is required
and this can be represented as an attribute in the physician =
certificate.

Now, in processing prescriptions, electronic messages plus copies of the
digital signatures and certificates are sent all over the place: to the
pharmacist, to the government, to one or more electronic health records,
to special monitoring agencies in the case of scheduled prescriptions,
to insurance companies, and so on. And these messages need to be
verifiable not just the day that the script was written, but for a long
time down the track (when more courses of treatment are dispensed from a
repeat script, when an in-patient is discharged from hospital, when the
patient transfers their care from one provider to another, when
electronic health record entries are retrieved and validated by other
carers or researchers, when insurance claims are processed, when a
specialist reviews the case, or when occasionally some invesitigation
into drug prescribing is undertaken ...). Furthermore, as copies of
these messages wend their way across disparate systems and the world,
increasingly distant form the original transaction event, they need to
maintain their fidelity and integrity.

The digital signature of the physician, plus her certificate, bakes into
the transaction her medical qualifications as they were at the time she
wrote the script. Even after her certificate expires, or is revoked
(because she retires or whatever), the signature remains easily
verifiable.

In contrast, what sort of alternative authentication technology could
provide easily verifiable confirmation of all parties' credentials as
they were at the time? What system allows all parties' credentials and
other attributes at all times in the past to be retrieved and validated?

The online-all-the-time paradigm (which I think deeply informs design
assumptions in most federated ID systems as well especially the Identity
Metasystem) seems to overlook the fact that often times, old transaction
events remain important.

It's not just healthcare. Environments with similar hallmarks -- long
lived transactions and multiple, distant relying parties -- include
trade documentation, conveyancing, superannuation (pension funds)
management, insurance, and business banking. These are the sorts of
niche areas where PKI has tended to do best historically.

Cheers,

Steve Wilson
Lockstep Technologies.

------_=_NextPart_001_01C9781F.2B673C2C
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Why use PKI? [was: A certificate validation =
question]
=0A=
=0A=
=0A=
=0A=

=0A=

Not to labor =
the point, but XKMS is a PKI as well. The original code-name was Trust =
Assertion XML Infrastructure.
=0A=

=0A=

The static assertions =
were then separated from the dynamic protocol. The dynamic protocol =
turned into XKMS. The static protocol led to the assertion layer of =
SAML.

=0A=

=0A=

=0A=

What you really want though is simply a CKI. A =
Cryptographic Key Infrastructure. There is really no point is committing =
yourself up front to only use one form of cryptography.
=0A=

=0A=

=0A=

=0A=

=0A=
=0A=

=0A=

From: =
[email-masked] on behalf of Stephen Wilson
Sent: =
Wed 1/14/2009 3:37 PM
To: [email-masked]
Subject: =
Why use PKI? [was: A certificate validation =
question]

=0A=

=0A=

Eric Norman 14/Jan/2009 wrote:
> On Jan =
12, 2009, at 1:54 PM, Stephen Kent wrote:
>> The X.509 =
PKI model has never assumed that one should check the
>> =
validity of a cert by looking for it in some repository.
> =
After all, if you're going to do an on-line status check
> every =
time a certificate is used, then why are you using
> this =
certificate stuff in the first place?

Using certificates in =
an online-all-the-time environment can indeed look
like =
overkill.  But in my view, the greatest and most unique =
benefit
of PKI comes in offline environments where it is important to =
be able to
check the historical validity of a transaction.  =
Because certificates
bake in the attributes of a sender as they were =
at the time of the
transaction, and the validity at any time in the =
past can be easily
checked by the CRLs and delta CRLs (OK, now I'm =
veering away from online
status check).

My favorite examples =
are from e-health.  Take an electronic
prescription, digitally =
signed by a physician, using her certificate
issued by a medical =
registration board.  The script might also be
counter signed by =
the patient using a smartcard.  In the case of
narcotics or =
other scheduled medications, a special license is required
and this =
can be represented as an attribute in the physician =
certificate.

Now, in processing prescriptions, electronic =
messages plus copies of the
digital signatures and certificates are =
sent all over the place: to the
pharmacist, to the government, to one =
or more electronic health records,
to special monitoring agencies in =
the case of scheduled prescriptions,
to insurance companies, and so =
on.  And these messages need to be
verifiable not just the day =
that the script was written, but for a long
time down the track (when =
more courses of treatment are dispensed from a
repeat script, when an =
in-patient is discharged from hospital, when the
patient transfers =
their care from one provider to another, when
electronic health =
record entries are retrieved and validated by other
carers or =
researchers, when insurance claims are processed, when a
specialist =
reviews the case, or when occasionally some invesitigation
into drug =
prescribing is undertaken ...).  Furthermore, as copies of
these =
messages wend their way across disparate systems and the =
world,
increasingly distant form the original transaction event, they =
need to
maintain their fidelity and integrity.

The digital =
signature of the physician, plus her certificate, bakes into
the =
transaction her medical qualifications as they were at the time =
she
wrote the script.  Even after her certificate expires, or is =
revoked
(because she retires or whatever), the signature remains =
easily
verifiable.

In contrast, what sort of alternative =
authentication technology could
provide easily verifiable =
confirmation of all parties' credentials as
they were at the =
time?  What system allows all parties' credentials and
other =
attributes at all times in the past to be retrieved and =
validated?

The online-all-the-time paradigm (which I think deeply =
informs design
assumptions in most federated ID systems as well =
especially the Identity
Metasystem) seems to overlook the fact that =
often times, old transaction
events remain important.

It's not =
just healthcare.  Environments with similar hallmarks -- =
long
lived transactions and multiple, distant relying parties -- =
include
trade documentation, conveyancing, superannuation (pension =
funds)
management, insurance, and business banking.  These are =
the sorts of
niche areas where PKI has tended to do best =
historically.

Cheers,

Steve Wilson
Lockstep =
Technologies.

------_=_NextPart_001_01C9781F.2B673C2C--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GKh6Mw041499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 13:43:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0GKh6Rm041498; Fri, 16 Jan 2009 13:43:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GKh5Mb041491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Jan 2009 13:43:06 -0700 (MST) (envelope-from [email-masked])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n0GKKBow016127; Fri, 16 Jan 2009 12:20:11 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 12:42:52 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9781B.002A5370"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: A proxy certificate validation question.
Date: Fri, 16 Jan 2009 12:42:51 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: A proxy certificate validation question.
Thread-Index: Acl1uqUK4dCerQTNR02JcbTeWNvhoACXqrMJ
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: "Stephen Kent"
Cc: "Johannes Merkle" , =?iso-8859-1?Q?Philipp_G=FChring?= ,
X-OriginalArrivalTime: 16 Jan 2009 20:42:52.0375 (UTC) FILETIME=[0072E670:01C9781B]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9781B.002A5370
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Actually the group did keep the band and change the semantics. The draft =
of OCSP I wrote, the last one submitted before the conversion to ASN.1 =
described key status semantics.
=20
But we are still firmly inside the scope of reporting certificate status =
here. The only change is that we are looking for ways to build in extra =
security in cases where we are slightly less certain about the security =
of SHA1.
=20
At present there is one place where SHA1 is hard coded into OCSP as the =
only alg choice. That may have been the right decision then. It is =
certainly not something that we would consider acceptable today.
=20
=20
On the CRL thing, yes people will continue to use CRLs. In particular =
for describing the status of OCSP responder certs. But if folk come =
along and say reduce two mechanisms to one, OCSP is going to be the one =
left in virtually all application level applications.
=20

________________________________

From: Stephen Kent [mailto:[email-masked]]
Sent: Mon 1/12/2009 2:58 PM
To: Hallam-Baker, Phillip
Cc: Johannes Merkle; Philipp G=FChring; [email-masked]
Subject: RE: A proxy certificate validation question.

At 6:20 AM -0800 1/9/09, Hallam-Baker, Phillip wrote:
>Lets start with a principle here: No new protocols.
>
>
>This is not an opportunity for people to deploy their pet protocol.
>So far we have SCVP and SPKI proposed as somehow being a 'simpler'
>option than OCSP, the protocol that is widely deployed by CAs and
>employed by relying applications for the express purpose of
>reporting certificate validity.

Trust me, SPKI is not on the table :-) as a option.

>If the group had wanted to make SCVP a replacement for OCSP then it
>should have accepted Mike Meyer's proposal to make SCVP an extension
>to OCSP, which was in any case the logic behind the earlier change
>of the original OCSP to ASN.1 syntax.

right, but PKIX did not take the path of keeping the brand and
changing the semantics.

>As far as I am aware, SCVP or SPKI deployment would require an
>entirely new infrastructure for every single member of the
>CA/Browser forum. That is not consistent with my view of a 'simpler'
>solution.

SCVP is in a different category from SPKI, but the bottom line impact
you cite is correct.

>I do not think using SCVP for something it is not designed to do is
>simpler. I do not think that introducing SPKI, an entirely different
>PKI is 'simpler'. Neither is going to happen.

agreed.

>Even if they were simpler (which they are not). What I am interested
>in here is 'more practical'. In particular, what solutions are most
>likely to be acceptable to members of the CA/Browser forum.
>Solutions that do not gain the support of at least one major CA and
>at least one major application provider are irrelevant. The current
>expectation amongst CAs is that the core PKI infrastructures are
>X.509v3 certificates, X.509v2 CRLs and OCSP with an expectation that
>use of CRLs will be replaced by use of OCSP at some point.

I don't agree with this last point. CRLs are still viable in many
contexts, and can serve as the reference for many OCSP servers, so
...

>Any proposal involving any other mechanism is going to be less
>attractive than one based on those mechanisms.

to first order, I agree.

>Looking at the OCSP specification, there is an SHA1 problem in any
>case. The key reference mechanism specifies SHA1 as the only
>algorithm. We have to fix that in any case if we are going to take
>OCSP to DRAFT status. Having a digest reference to the whole
>certificate is the most logical alternative.

right, we have to fix the lack of algorithm agility and the use cases
you briefed at the 72nd IETF.

Steve

------_=_NextPart_001_01C9781B.002A5370
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: A proxy certificate validation =
question.
=0A=
=0A=
=0A=
=0A=

=0A=

Actually the =
group did keep the band and change the semantics. The draft of OCSP I wrote, the last one submitted =
before the conversion to ASN.1 described key status =
semantics.
=0A=

=0A=

But we are still firmly =
inside the scope of reporting certificate status here. The only change =
is that we are looking for ways to build in extra security in cases =
where we are slightly less certain about the security of =
SHA1.
=0A=

=0A=

At present there is one place =
where SHA1 is hard coded into OCSP as the only alg choice. That may have =
been the right decision then. It is certainly not something that we =
would consider acceptable today.
=0A=

=0A=

=0A=

On the CRL thing, yes people =
will continue to use CRLs. In particular for describing the status of =
OCSP responder certs. But if folk come along and say reduce two =
mechanisms to one, OCSP is going to be the one left in virtually all =
application level applications.

=0A=

=0A=

=0A=
=0A=
From: Stephen Kent =
[mailto:[email-masked]]
Sent: Mon 1/12/2009 2:58 =
PM
To: Hallam-Baker, Phillip
Cc: Johannes Merkle; =
Philipp G=FChring; [email-masked]
Subject: RE: A proxy =
certificate validation question.

=0A=

=0A=

At 6:20 AM -0800 1/9/09, Hallam-Baker, Phillip =
wrote:
>Lets start with a principle here: No new =
protocols.
>
>
>This is not an opportunity for people =
to deploy their pet protocol.
>So far we have SCVP and SPKI =
proposed as somehow being a 'simpler'
>option than OCSP, the =
protocol that is widely deployed by CAs and
>employed by relying =
applications for the express purpose of
>reporting certificate =
validity.

Trust me, SPKI is not on the table :-) as a =
option.

>If the group had wanted to make SCVP a replacement =
for OCSP then it
>should have accepted Mike Meyer's proposal to =
make SCVP an extension
>to OCSP, which was in any case the logic =
behind the earlier change
>of the original OCSP to ASN.1 =
syntax.

right, but PKIX did not take the path of keeping the =
brand and
changing the semantics.

>As far as I am aware, =
SCVP or SPKI deployment would require an
>entirely new =
infrastructure for every single member of the
>CA/Browser forum. =
That is not consistent with my view of a =
'simpler'
>solution.

SCVP is in a different category from =
SPKI, but the bottom line impact
you cite is correct.

>I do =
not think using SCVP for something it is not designed to do =
is
>simpler. I do not think that introducing SPKI, an entirely =
different
>PKI is 'simpler'. Neither is going to =
happen.

agreed.

>Even if they were simpler (which they =
are not). What I am interested
>in here is 'more practical'. In =
particular, what solutions are most
>likely to be acceptable to =
members of the CA/Browser forum.
>Solutions that do not gain the =
support of at least one major CA and
>at least one major =
application provider are irrelevant. The current
>expectation =
amongst CAs is that the core PKI infrastructures are
>X.509v3 =
certificates, X.509v2 CRLs and OCSP with an expectation that
>use =
of CRLs will be replaced by use of OCSP at some point.

I don't =
agree with this last point. CRLs are still viable in many
contexts, =
and  can serve as the reference for many OCSP servers, =
so
...

>Any proposal involving any other mechanism is going =
to be less
>attractive than one based on those =
mechanisms.

to first order, I agree.

>Looking at the =
OCSP specification, there is an SHA1 problem in any
>case. The key =
reference mechanism specifies SHA1 as the only
>algorithm. We have =
to fix that in any case if we are going to take
>OCSP to DRAFT =
status. Having a digest reference to the whole
>certificate is the =
most logical alternative.

right, we have to fix the lack of =
algorithm agility and the use cases
you briefed at the 72nd =
IETF.

Steve

------_=_NextPart_001_01C9781B.002A5370--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GKUuV0041075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 13:30:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0GKUu7Z041074; Fri, 16 Jan 2009 13:30:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GKUiMZ041065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Jan 2009 13:30:55 -0700 (MST) (envelope-from [email-masked])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n0GK7vNB015737; Fri, 16 Jan 2009 12:07:57 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 12:30:38 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97819.4AA5CFEB"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: A certificate validation question.
Date: Fri, 16 Jan 2009 12:30:37 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: A certificate validation question.
Thread-Index: Acl1zHqmum2s7UyiSwOkO+Dd6uz90wCSvFhC
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: "Eric Norman" ,
X-OriginalArrivalTime: 16 Jan 2009 20:30:38.0011 (UTC) FILETIME=[4ABBD8B0:01C97819]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C97819.4AA5CFEB
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, if you adopt this approach PKIX eventually becomes at the technical =
level merely an inefficient version of XKMS.
=20
I don't see anything particularly wrong with that. My concerns here are =
simply to enable as many applications as possible use the web as =
predictably securely as possible. Since the legacy base only supports =
PKIX based PKI that requires a certain quantity of what Peter refered to =
as 'ancestor worship of OSI standards'.
=20
=20
Which is precisely why Steve's point is relevant. You do not want to do =
so much to OCSP that you have made it into XKMS.
=20
On the other hand, we do need to work out an effective transition =
strategy for SHA1 here given the fact that deployment of SHA256 is =
minimal and we do not yet have SHA3.
=20
=20
We need a transition plan that maintains maximal security and =
functionality for as many applications for as long as possible that =
involves touching as few parts of the infrastructure as possible.=20
=20
It is not an immediate concern but the longer we wait to take action the =
greater the eventual cost will be.=20

=20
________________________________

From: [email-masked] on behalf of Eric Norman
Sent: Tue 1/13/2009 4:13 PM
To: [email-masked]
Subject: Re: A certificate validation question.

On Jan 12, 2009, at 1:54 PM, Stephen Kent wrote:

> The X.509 PKI model has never assumed that one should check the
> validity of a cert by looking for it in some repository.

After all, if you're going to do an on-line status check
every time a certificate is used, then why are you using
this certificate stuff in the first place?

Eric Norman

------_=_NextPart_001_01C97819.4AA5CFEB
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: A certificate validation =
question.
=0A=
=0A=
=0A=
=0A=

=0A=

Yes, if you =
adopt this approach PKIX eventually becomes at the technical level =
merely an inefficient version of XKMS.
=0A=

=0A=

I don't see anything =
particularly wrong with that. My concerns here are simply to enable as =
many applications as possible use the web as predictably securely as =
possible. Since the legacy base only supports PKIX based PKI that =
requires a certain quantity of what Peter refered to as 'ancestor =
worship of OSI standards'.
=0A=

=0A=

=0A=

Which is precisely why =
Steve's point is relevant. You do not want to do so much to OCSP that =
you have made it into XKMS.
=0A=

=0A=

On the other hand, we do need =
to work out an effective transition strategy for SHA1 here given the =
fact that deployment of SHA256 is minimal and we do not yet have =
SHA3.
=0A=

=0A=

=0A=

We need a transition plan =
that maintains maximal security and functionality for as many =
applications for as long as possible that involves touching as few parts =
of the infrastructure as possible.
=0A=

=0A=

It is not an immediate =
concern but the longer we wait to take action the greater the eventual =
cost will be.

=0A=

=0A=

=0A=

=0A=
=0A=

=0A=

From: =
[email-masked] on behalf of Eric Norman
Sent: =
Tue 1/13/2009 4:13 PM
To: [email-masked]
Subject: =
Re: A certificate validation question.

=0A=

=0A=

On Jan 12, 2009, at 1:54 PM, Stephen Kent =
wrote:

> The X.509 PKI model has never assumed that one should =
check the
> validity of a cert by looking for it in some =
repository.

After all, if you're going to do an on-line status =
check
every time a certificate is used, then why are you =
using
this certificate stuff in the first place?

Eric =
Norman

------_=_NextPart_001_01C97819.4AA5CFEB--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0F0gnC0011008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 17:42:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0F0gn5i011007; Wed, 14 Jan 2009 17:42:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0F0giDq011001 for ; Wed, 14 Jan 2009 17:42:49 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id D22701C65A for ; Wed, 14 Jan 2009 19:42:41 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 87A541C473 for ; Wed, 14 Jan 2009 19:42:41 -0500 (EST)
Message-ID: <[email-masked]>
Date: Wed, 14 Jan 2009 16:42:52 -0800
From: "Michael D'Errico"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: New modules drafts posted
References: <[email-masked]> <00c301c97685$8ccef0b0$a66cd210$@com>
In-Reply-To: <00c301c97685$8ccef0b0$a66cd210$@com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 6AAD8B66-E29D-11DD-85EF-2E3B113D384A-38729857!a-sasl-quonix.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jim,

I am not asking you to change your document, but am asking that the
new ASN.1 remain as optional information for implementers who need/
want it. It is my understanding that the current plan is for the new
ASN.1 to eventually replace the existing modules in all the important
security documents. That would be a HUGE mistake, in my opinion,
since security is hard enough as it is, without making it ten times
harder with cryptic, impenetrable syntax. I speak as someone who
understands the 1988 syntax, enough to have actually implemented an
ASN.1 parser and X.509 certificate and CRL processing and generation
software.

Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EKbu9w099108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 13:37:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EKbuaM099107; Wed, 14 Jan 2009 13:37:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp132.sat.emailsrvr.com (smtp132.sat.emailsrvr.com [66.216.121.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EKbj4R099089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 13:37:55 -0700 (MST) (envelope-from [email-masked])
Received: from relay13.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id ED7CF1B4EBA for ; Wed, 14 Jan 2009 15:37:44 -0500 (EST)
Received: by relay13.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPSA id 4B7E71B4CF1 for ; Wed, 14 Jan 2009 15:37:44 -0500 (EST)
Message-ID: <[email-masked]>
Date: Thu, 15 Jan 2009 07:37:26 +1100
From: Stephen Wilson
Reply-To: [email-masked]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [email-masked]
Subject: Why use PKI? [was: A certificate validation question]
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Eric Norman 14/Jan/2009 wrote:
>
> On Jan 12, 2009, at 1:54 PM, Stephen Kent wrote:
>
>> The X.509 PKI model has never assumed that one should check the
>> validity of a cert by looking for it in some repository.
>
> After all, if you're going to do an on-line status check
> every time a certificate is used, then why are you using
> this certificate stuff in the first place?

Using certificates in an online-all-the-time environment can indeed look
like overkill. But in my view, the greatest and most unique benefit
of PKI comes in offline environments where it is important to be able to
check the historical validity of a transaction. Because certificates
bake in the attributes of a sender as they were at the time of the
transaction, and the validity at any time in the past can be easily
checked by the CRLs and delta CRLs (OK, now I'm veering away from online
status check).

My favorite examples are from e-health. Take an electronic
prescription, digitally signed by a physician, using her certificate
issued by a medical registration board. The script might also be
counter signed by the patient using a smartcard. In the case of
narcotics or other scheduled medications, a special license is required
and this can be represented as an attribute in the physician certificate.

Now, in processing prescriptions, electronic messages plus copies of the
digital signatures and certificates are sent all over the place: to the
pharmacist, to the government, to one or more electronic health records,
to special monitoring agencies in the case of scheduled prescriptions,
to insurance companies, and so on. And these messages need to be
verifiable not just the day that the script was written, but for a long
time down the track (when more courses of treatment are dispensed from a
repeat script, when an in-patient is discharged from hospital, when the
patient transfers their care from one provider to another, when
electronic health record entries are retrieved and validated by other
carers or researchers, when insurance claims are processed, when a
specialist reviews the case, or when occasionally some invesitigation
into drug prescribing is undertaken ...). Furthermore, as copies of
these messages wend their way across disparate systems and the world,
increasingly distant form the original transaction event, they need to
maintain their fidelity and integrity.

The digital signature of the physician, plus her certificate, bakes into
the transaction her medical qualifications as they were at the time she
wrote the script. Even after her certificate expires, or is revoked
(because she retires or whatever), the signature remains easily
verifiable.

In contrast, what sort of alternative authentication technology could
provide easily verifiable confirmation of all parties' credentials as
they were at the time? What system allows all parties' credentials and
other attributes at all times in the past to be retrieved and validated?

The online-all-the-time paradigm (which I think deeply informs design
assumptions in most federated ID systems as well especially the Identity
Metasystem) seems to overlook the fact that often times, old transaction
events remain important.

It's not just healthcare. Environments with similar hallmarks -- long
lived transactions and multiple, distant relying parties -- include
trade documentation, conveyancing, superannuation (pension funds)
management, insurance, and business banking. These are the sorts of
niche areas where PKI has tended to do best historically.

Cheers,

Steve Wilson
Lockstep Technologies.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EKKorj098139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 13:20:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EKKoQ0098138; Wed, 14 Jan 2009 13:20:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EKKduu098124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Jan 2009 13:20:50 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 7EF666A667; Wed, 14 Jan 2009 12:20:38 -0800 (PST)
From: "Jim Schaad"
To: "'Michael D'Errico'" ,
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: New modules drafts posted
Date: Wed, 14 Jan 2009 12:20:31 -0800
Message-ID: <00c301c97685$8ccef0b0$a66cd210$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acl2gIsy+NgXdLFRSoiWOScL8nszHAAA6XSg
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Mike,

I am curious as to why you think it is more difficult to understand the new
syntax as oppose to the old syntax. I can think of any number of issues
that could contribute to this and would like to narrow them down to the ones
that you feel are detracting from your understanding.

Possible responses could include:

1. The introduction of the objects appears to add complexity without any
additional benefits.

2. The addition of constraints makes things difficult to follow.

3. The use of the macros such as SIGNED hide information that was
previously explicit

If we have a good understanding of why you believe that things are "too
complicated" then we can potentially restructure things so that they are
easier to follow.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Michael D'Errico
> Sent: Wednesday, January 14, 2009 11:38 AM
> To: [email-masked]
> Subject: Re: New modules drafts posted
>
>
> I would like to request that the new ASN.1 documents be given an
> Informational rating rather than standard track. The new ASN.1,
> in my personal opinion, makes it more difficult for *humans* to
> understand; the benefit is supposedly for ASN.1 compilers. I
> make this request so that the new ASN.1 does not eventually end
> up in standard-track documents which make use of the structures,
> where it is paramount that implementers understand them. People
> who have advanced ASN.1 compilers can easily grab the new ASN.1
> from an Informational document and realize the benefits it is
> supposed to provide.
>
> Mike
>
>
> Paul Hoffman wrote:
> > Since I sent out this message below, we had one group of folks
> respond with a few small technical changes, but no other comments.
> >
> > In the spirit of forward motion, we would like the chairs of PKIX and
> S/MIME to put the respective documents into WG Last Call so we can
> shake out any last comments and put these on standards track.
> >
> > At 8:52 AM -0800 1/9/09, Paul Hoffman wrote:
> >> Greetings again. This message should appear after the posting
> announcements for draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-
> asn1-02 appear. If not, please wait a bit. :-)
> >>
> >> Jim and I have major changes to the modules, and we think that our
> work is now done, modulo bug fixes. To that end, we would *really* like
> folks on either of these two lists who have ASN.1 compilers that handle
> the 2002 syntax to review the modules carefully and let both lists know
> if there are any errors. In addition, we are still open to comments on
> our choice of style for the new objects in the modules.
> >>
> >> If you want to get copies of the modules without tedious copy-and-
> pasting, get the latest version of a2c from the a2c project
> (), specifically either
> or
> . The modules are in the
> test/ directory. The makefile in that directory has all of the
> dependencies needed, although we are happy to have you test your own
> dependencie chain yourself.
> >>
> >> At this point, we think that comments to both lists are appropriate,
> given the shared design between the two drafts and the heavy cross-
> dependencies between the modules.
> >>
> >> --Paul Hoffman, Director
> >> --VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EKDO13097784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 13:13:24 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EKDOiZ097783; Wed, 14 Jan 2009 13:13:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EKDBuP097763 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 13:13:23 -0700 (MST) (envelope-from [email-masked])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1LNC6o-0000nu-9w; Wed, 14 Jan 2009 21:13:07 +0100
From: Simon Josefsson
To: "Michael D'Errico"
Cc: [email-masked]
Subject: Re: New modules drafts posted
References: <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090114:[email-masked]::C2MSYRUo98BGaMuS:0ZIX
X-Hashcash: 1:22:090114:[email-masked]::bIDG2w5J/RrsiawK:3WqU
Date: Wed, 14 Jan 2009 21:13:01 +0100
In-Reply-To: <[email-masked]> (Michael D'Errico's message of "Wed, 14 Jan 2009 11:38:28 -0800")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Being an implementer who do not always use completely ASN.1 2002
compliant tools, I agree with Michael's concern.

/Simon

"Michael D'Errico" writes:

> I would like to request that the new ASN.1 documents be given an
> Informational rating rather than standard track. The new ASN.1,
> in my personal opinion, makes it more difficult for *humans* to
> understand; the benefit is supposedly for ASN.1 compilers. I
> make this request so that the new ASN.1 does not eventually end
> up in standard-track documents which make use of the structures,
> where it is paramount that implementers understand them. People
> who have advanced ASN.1 compilers can easily grab the new ASN.1
> from an Informational document and realize the benefits it is
> supposed to provide.
>
> Mike
>
>
> Paul Hoffman wrote:
>> Since I sent out this message below, we had one group of folks respond with a few small technical changes, but no other comments.
>>
>> In the spirit of forward motion, we would like the chairs of PKIX and S/MIME to put the respective documents into WG Last Call so we can shake out any last comments and put these on standards track.
>>
>> At 8:52 AM -0800 1/9/09, Paul Hoffman wrote:
>>> Greetings again. This message should appear after the posting announcements for draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-asn1-02 appear. If not, please wait a bit. :-)
>>>
>>> Jim and I have major changes to the modules, and we think that our work is now done, modulo bug fixes. To that end, we would *really* like folks on either of these two lists who have ASN.1 compilers that handle the 2002 syntax to review the modules carefully and let both lists know if there are any errors. In addition, we are still open to comments on our choice of style for the new objects in the modules.
>>>
>>> If you want to get copies of the modules without tedious copy-and-pasting, get the latest version of a2c from the a2c project (), specifically either or . The modules are in the test/ directory. The makefile in that directory has all of the dependencies needed, although we are happy to have you test your own dependencie chain yourself.
>>>
>>> At this point, we think that comments to both lists are appropriate, given the shared design between the two drafts and the heavy cross-dependencies between the modules.
>>>
>>> --Paul Hoffman, Director
>>> --VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EJcRNA096070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 12:38:27 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EJcRDX096069; Wed, 14 Jan 2009 12:38:27 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EJcGZa096050 for ; Wed, 14 Jan 2009 12:38:26 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 813861C868 for ; Wed, 14 Jan 2009 14:38:15 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 26C551C867 for ; Wed, 14 Jan 2009 14:38:14 -0500 (EST)
Message-ID: <[email-masked]>
Date: Wed, 14 Jan 2009 11:38:28 -0800
From: "Michael D'Errico"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: New modules drafts posted
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: E3188F04-E272-11DD-BB78-2E3B113D384A-38729857!a-sasl-quonix.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I would like to request that the new ASN.1 documents be given an
Informational rating rather than standard track. The new ASN.1,
in my personal opinion, makes it more difficult for *humans* to
understand; the benefit is supposedly for ASN.1 compilers. I
make this request so that the new ASN.1 does not eventually end
up in standard-track documents which make use of the structures,
where it is paramount that implementers understand them. People
who have advanced ASN.1 compilers can easily grab the new ASN.1
from an Informational document and realize the benefits it is
supposed to provide.

Mike

Paul Hoffman wrote:
> Since I sent out this message below, we had one group of folks respond with a few small technical changes, but no other comments.
>
> In the spirit of forward motion, we would like the chairs of PKIX and S/MIME to put the respective documents into WG Last Call so we can shake out any last comments and put these on standards track.
>
> At 8:52 AM -0800 1/9/09, Paul Hoffman wrote:
>> Greetings again. This message should appear after the posting announcements for draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-asn1-02 appear. If not, please wait a bit. :-)
>>
>> Jim and I have major changes to the modules, and we think that our work is now done, modulo bug fixes. To that end, we would *really* like folks on either of these two lists who have ASN.1 compilers that handle the 2002 syntax to review the modules carefully and let both lists know if there are any errors. In addition, we are still open to comments on our choice of style for the new objects in the modules.
>>
>> If you want to get copies of the modules without tedious copy-and-pasting, get the latest version of a2c from the a2c project (), specifically either or . The modules are in the test/ directory. The makefile in that directory has all of the dependencies needed, although we are happy to have you test your own dependencie chain yourself.
>>
>> At this point, we think that comments to both lists are appropriate, given the shared design between the two drafts and the heavy cross-dependencies between the modules.
>>
>> --Paul Hoffman, Director
>> --VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EHMrdX087691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 10:22:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EHMrcD087690; Wed, 14 Jan 2009 10:22:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EHMgd4087668 for ; Wed, 14 Jan 2009 10:22:52 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LN9Rw-0000Tj-E2; Wed, 14 Jan 2009 12:22:40 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 14 Jan 2009 12:11:46 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent
Subject: Re: A certificate validation question.
Cc: [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 7:13 PM +1300 1/14/09, Peter Gutmann wrote:
>Eric Norman writes:
>
>>After all, if you're going to do an on-line status check every time a
>>certificate is used, then why are you using this certificate stuff in
>>the first place?
>
>Ooh, ooh, I know that one, the answer is:
>
> "because of digital ancestor-worship of closed-door OSI standards
> from the 1980s"
>
>and it was from an NCSC(?) paper some years ago.
>
>Peter.

Peter,

for bonus points (and to help validate your comment) can you provide
a cite of the relevant OSi standards, or the NCSC paper?

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EGtvOC084252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 09:55:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EGtv0O084250; Wed, 14 Jan 2009 09:55:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.163] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0EGttGV084237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 09:55:56 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Wed, 14 Jan 2009 08:55:54 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman
Subject: Re: New modules drafts posted
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Since I sent out this message below, we had one group of folks respond with a few small technical changes, but no other comments.

In the spirit of forward motion, we would like the chairs of PKIX and S/MIME to put the respective documents into WG Last Call so we can shake out any last comments and put these on standards track.

At 8:52 AM -0800 1/9/09, Paul Hoffman wrote:
>Greetings again. This message should appear after the posting announcements for draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-asn1-02 appear. If not, please wait a bit. :-)
>
>Jim and I have major changes to the modules, and we think that our work is now done, modulo bug fixes. To that end, we would *really* like folks on either of these two lists who have ASN.1 compilers that handle the 2002 syntax to review the modules carefully and let both lists know if there are any errors. In addition, we are still open to comments on our choice of style for the new objects in the modules.
>
>If you want to get copies of the modules without tedious copy-and-pasting, get the latest version of a2c from the a2c project (), specifically either or . The modules are in the test/ directory. The makefile in that directory has all of the dependencies needed, although we are happy to have you test your own dependencie chain yourself.
>
>At this point, we think that comments to both lists are appropriate, given the shared design between the two drafts and the heavy cross-dependencies between the modules.
>
>--Paul Hoffman, Director
>--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0E6DnqP040363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 23:13:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0E6Dn84040362; Tue, 13 Jan 2009 23:13:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0E6DcTW040354 for ; Tue, 13 Jan 2009 23:13:48 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 54B8E481111; Wed, 14 Jan 2009 19:13:37 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDwLMLDresVz; Wed, 14 Jan 2009 19:13:37 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B6420481110; Wed, 14 Jan 2009 19:13:36 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CF79E1BE4001; Wed, 14 Jan 2009 19:13:35 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LMz0R-0001hd-LW; Wed, 14 Jan 2009 19:13:35 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: A certificate validation question.
In-Reply-To: <[email-masked]>
Message-Id:
Date: Wed, 14 Jan 2009 19:13:35 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Eric Norman writes:

>After all, if you're going to do an on-line status check every time a
>certificate is used, then why are you using this certificate stuff in
>the first place?

Ooh, ooh, I know that one, the answer is:

"because of digital ancestor-worship of closed-door OSI standards
from the 1980s"

and it was from an NCSC(?) paper some years ago.

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DLDsUf018065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 14:13:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DLDsA7018064; Tue, 13 Jan 2009 14:13:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DLDgUv018054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 13 Jan 2009 14:13:54 -0700 (MST) (envelope-from [email-masked])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) id <[email-masked]> for [email-masked]; Tue, 13 Jan 2009 15:13:42 -0600 (CST)
Received: from [192.168.0.14] (static.unknown.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[email-masked]> for [email-masked]; Tue, 13 Jan 2009 15:13:38 -0600 (CST)
Date: Tue, 13 Jan 2009 15:13:39 -0600
From: Eric Norman
Subject: Re: A certificate validation question.
In-reply-to:
To: [email-masked]
Message-id: <[email-masked]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=97.92.189.144
X-Spam-PmxInfo: Server=avs-11, Version=5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.1.13.205540, SenderIP=97.92.189.144
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Jan 12, 2009, at 1:54 PM, Stephen Kent wrote:

> The X.509 PKI model has never assumed that one should check the
> validity of a cert by looking for it in some repository.

After all, if you're going to do an on-line status check
every time a certificate is used, then why are you using
this certificate stuff in the first place?

Eric Norman

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DK8E0c014971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 13:08:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DK8Erv014969; Tue, 13 Jan 2009 13:08:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DK82UG014955 for ; Tue, 13 Jan 2009 13:08:13 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LMpYP-0006eW-G7; Tue, 13 Jan 2009 15:08:02 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 12 Jan 2009 14:58:42 -0500
To: "Hallam-Baker, Phillip"
From: Stephen Kent
Subject: RE: A proxy certificate validation question.
Cc: "Johannes Merkle" , Philipp =?iso-8859-1?Q?G=FChring?= ,
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 6:20 AM -0800 1/9/09, Hallam-Baker, Phillip wrote:
>Lets start with a principle here: No new protocols.
>
>
>This is not an opportunity for people to deploy their pet protocol.
>So far we have SCVP and SPKI proposed as somehow being a 'simpler'
>option than OCSP, the protocol that is widely deployed by CAs and
>employed by relying applications for the express purpose of
>reporting certificate validity.

Trust me, SPKI is not on the table :-) as a option.

>If the group had wanted to make SCVP a replacement for OCSP then it
>should have accepted Mike Meyer's proposal to make SCVP an extension
>to OCSP, which was in any case the logic behind the earlier change
>of the original OCSP to ASN.1 syntax.

right, but PKIX did not take the path of keeping the brand and
changing the semantics.

>As far as I am aware, SCVP or SPKI deployment would require an
>entirely new infrastructure for every single member of the
>CA/Browser forum. That is not consistent with my view of a 'simpler'
>solution.

SCVP is in a different category from SPKI, but the bottom line impact
you cite is correct.

>I do not think using SCVP for something it is not designed to do is
>simpler. I do not think that introducing SPKI, an entirely different
>PKI is 'simpler'. Neither is going to happen.

agreed.

>Even if they were simpler (which they are not). What I am interested
>in here is 'more practical'. In particular, what solutions are most
>likely to be acceptable to members of the CA/Browser forum.
>Solutions that do not gain the support of at least one major CA and
>at least one major application provider are irrelevant. The current
>expectation amongst CAs is that the core PKI infrastructures are
>X.509v3 certificates, X.509v2 CRLs and OCSP with an expectation that
>use of CRLs will be replaced by use of OCSP at some point.

I don't agree with this last point. CRLs are still viable in many
contexts, and can serve as the reference for many OCSP servers, so
...

>Any proposal involving any other mechanism is going to be less
>attractive than one based on those mechanisms.

to first order, I agree.

>Looking at the OCSP specification, there is an SHA1 problem in any
>case. The key reference mechanism specifies SHA1 as the only
>algorithm. We have to fix that in any case if we are going to take
>OCSP to DRAFT status. Having a digest reference to the whole
>certificate is the most logical alternative.

right, we have to fix the lack of algorithm agility and the use cases
you briefed at the 72nd IETF.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DK8EMu014972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 13:08:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DK8Ell014970; Tue, 13 Jan 2009 13:08:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DK826H014954 for ; Tue, 13 Jan 2009 13:08:13 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LMpYP-0006eW-E1; Tue, 13 Jan 2009 15:08:01 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 12 Jan 2009 14:54:36 -0500
To: Johannes Merkle
From: Stephen Kent
Subject: Re: A proxy certificate validation question.
Cc: Philipp =?iso-8859-1?Q?G=FChring?= , [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 11:48 AM +0100 1/9/09, Johannes Merkle wrote:
>Philipp,
>
>>> 2) Employ OCSP as a means of introducing a stronger algorithm (and
>>> addressing concerns previously raised in this list)
>>
>> You mean using something similar like OCSP, that provides a re-signature
>> for an existing certificate?
>>
>
>Actually, SCVP could help to tell original and rogue certificates
>apart. This requires the following
>1) The SCVP server uses a secure hash function and signature algorithm
>2) The client requests inclusion of the certificate in question in
>the response by means of the wantBack id-swb-pkc-cert.
>3) The server is able to retrieve the certificate from a trustworthy
>source (only containing authentic certificates),
>i.e. from the CA's repository.

The X.509 PKI model has never assumed that one should check the
validity of a cert by looking for it in some repository. I realize
that some European CAs have advocated this model, but PKIX said NO to
this a few years ago. The discussion context was whether OCSP is a
cert validation protocol vs. a cert revocation status protocol.

>If SCVP was widely deployed, it could mitigate the risks implied by
>hash function weaknesses.
>
>In Germany, the OCSP responders provided by CA's issuing qualified
>certificates typically provide a similar white-list
>lookup feature:
>1) They respond with status "good" only if the certificate has
>actually been issued by the CA. In particular, they have
>access to the CA's repository (or a replication) and do not only
>rely on a CRL.
>2) They use a private OCSP response extension CertHash (defined by
>the Common PKI standard) to include the hash value of
>the certificate in question in the response.
>
>There are some German signature verification tools and email clients
>which support this white-list lookup feature and
>check the certificate against the cert hash included in the
>response. Of course this features exceeds standard OCSP,

yes, and moreover, this runs contrary to the scope of OCSP as
expressed in the development and RFC publication of SCVP.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09Gxndg027691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 09:59:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09GxnjL027689; Fri, 9 Jan 2009 09:59:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09GxmWc027677 for ; Fri, 9 Jan 2009 09:59:49 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id CAD3928C0DB; Fri, 9 Jan 2009 09:00:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-new-asn1-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 9 Jan 2009 09:00:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

Title : New ASN.1 Modules for PKIX
Author(s) : P. Hoffman, J. Schaad
Filename : draft-ietf-pkix-new-asn1-02.txt
Pages : 115
Date : 2009-01-09

The PKIX certificate format, and many associated formats, are
expressed using ASN.1. The current ASN.1 modules conform to the 1988
version of ASN.1. This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1. There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-pkix-new-asn1-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09GqP4c027237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 09:52:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09GqOJ7027236; Fri, 9 Jan 2009 09:52:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09GqMx0027225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 09:52:23 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
Date: Fri, 9 Jan 2009 08:52:21 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman
Subject: New modules drafts posted
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Greetings again. This message should appear after the posting announcements for draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-asn1-02 appear. If not, please wait a bit. :-)

Jim and I have major changes to the modules, and we think that our work is now done, modulo bug fixes. To that end, we would *really* like folks on either of these two lists who have ASN.1 compilers that handle the 2002 syntax to review the modules carefully and let both lists know if there are any errors. In addition, we are still open to comments on our choice of style for the new objects in the modules.

If you want to get copies of the modules without tedious copy-and-pasting, get the latest version of a2c from the a2c project (), specifically either or . The modules are in the test/ directory. The makefile in that directory has all of the dependencies needed, although we are happy to have you test your own dependencie chain yourself.

At this point, we think that comments to both lists are appropriate, given the shared design between the two drafts and the heavy cross-dependencies between the modules.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09EKdNw018540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 07:20:39 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09EKdxQ018539; Fri, 9 Jan 2009 07:20:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09EKRqn018530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 9 Jan 2009 07:20:38 -0700 (MST) (envelope-from [email-masked])
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n09EKL43011596; Fri, 9 Jan 2009 06:20:21 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 06:20:21 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97265.678002FB"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: A proxy certificate validation question.
Date: Fri, 9 Jan 2009 06:20:21 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: A proxy certificate validation question.
Thread-Index: AclyUBjzVbK6JNDMRiCkvMNSs6LEmAAESG4+
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: "Johannes Merkle" , =?iso-8859-1?Q?Philipp_G=FChring?=
Cc:
X-OriginalArrivalTime: 09 Jan 2009 14:20:21.0626 (UTC) FILETIME=[67D845A0:01C97265]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C97265.678002FB
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Lets start with a principle here: No new protocols.

This is not an opportunity for people to deploy their pet protocol. So =
far we have SCVP and SPKI proposed as somehow being a 'simpler' option =
than OCSP, the protocol that is widely deployed by CAs and employed by =
relying applications for the express purpose of reporting certificate =
validity.

If the group had wanted to make SCVP a replacement for OCSP then it =
should have accepted Mike Meyer's proposal to make SCVP an extension to =
OCSP, which was in any case the logic behind the earlier change of the =
original OCSP to ASN.1 syntax.

As far as I am aware, SCVP or SPKI deployment would require an entirely =
new infrastructure for every single member of the CA/Browser forum. That =
is not consistent with my view of a 'simpler' solution.

I do not think using SCVP for something it is not designed to do is =
simpler. I do not think that introducing SPKI, an entirely different PKI =
is 'simpler'. Neither is going to happen.

Even if they were simpler (which they are not). What I am interested in =
here is 'more practical'. In particular, what solutions are most likely =
to be acceptable to members of the CA/Browser forum. Solutions that do =
not gain the support of at least one major CA and at least one major =
application provider are irrelevant. The current expectation amongst CAs =
is that the core PKI infrastructures are X.509v3 certificates, X.509v2 =
CRLs and OCSP with an expectation that use of CRLs will be replaced by =
use of OCSP at some point. Any proposal involving any other mechanism is =
going to be less attractive than one based on those mechanisms.

Looking at the OCSP specification, there is an SHA1 problem in any case. =
The key reference mechanism specifies SHA1 as the only algorithm. We =
have to fix that in any case if we are going to take OCSP to DRAFT =
status. Having a digest reference to the whole certificate is the most =
logical alternative.

-----Original Message-----
From: [email-masked] on behalf of Johannes Merkle
Sent: Fri 1/9/2009 5:48 AM
To: Philipp G=FChring
Cc: [email-masked]
Subject: Re: A proxy certificate validation question.
=20

Philipp,

>> 2) Employ OCSP as a means of introducing a stronger algorithm (and
>> addressing concerns previously raised in this list)
>=20
> You mean using something similar like OCSP, that provides a =
re-signature
> for an existing certificate?
>=20

Actually, SCVP could help to tell original and rogue certificates apart. =
This requires the following
1) The SCVP server uses a secure hash function and signature algorithm
2) The client requests inclusion of the certificate in question in the =
response by means of the wantBack id-swb-pkc-cert.
3) The server is able to retrieve the certificate from a trustworthy =
source (only containing authentic certificates),
i.e. from the CA's repository.
If SCVP was widely deployed, it could mitigate the risks implied by hash =
function weaknesses.

In Germany, the OCSP responders provided by CA's issuing qualified =
certificates typically provide a similar white-list
lookup feature:
1) They respond with status "good" only if the certificate has actually =
been issued by the CA. In particular, they have
access to the CA's repository (or a replication) and do not only rely on =
a CRL.
2) They use a private OCSP response extension CertHash (defined by the =
Common PKI standard) to include the hash value of
the certificate in question in the response.

There are some German signature verification tools and email clients =
which support this white-list lookup feature and
check the certificate against the cert hash included in the response. Of =
course this features exceeds standard OCSP, but
it is actually used.

> I think some RFC defines that a certificate must be unique according =
to
> issuer+serial number. And some software actually implemented that and
> completely declares a whole (root?) CA invalid as soon as it sees two
> different certificates with same issuer+serial number.
This problem would not occur with a validation service providing =
white-list lookup.

> What if we use something like OCSP that delivers a renewed (with
> different serial number) certificate when someone presents an old
> certificate?
Better: SCVP or OCSP with white-list lookup.

Johannes

------_=_NextPart_001_01C97265.678002FB
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: A proxy certificate validation question.

Lets start with a principle here: No new =
protocols.

This is not an opportunity for people to deploy their pet protocol. So =
far we have SCVP and SPKI proposed as somehow being a 'simpler' option =
than OCSP, the protocol that is widely deployed by CAs and employed by =
relying applications for the express purpose of reporting certificate =
validity.

If the group had wanted to make SCVP a replacement for OCSP then it =
should have accepted Mike Meyer's proposal to make SCVP an extension to =
OCSP, which was in any case the logic behind the earlier change of the =
original OCSP to ASN.1 syntax.

As far as I am aware, SCVP or SPKI deployment would require an entirely =
new infrastructure for every single member of the CA/Browser forum. That =
is not consistent with my view of a 'simpler' solution.

I do not think using SCVP for something it is not designed to do is =
simpler. I do not think that introducing SPKI, an entirely different PKI =
is 'simpler'. Neither is going to happen.

Even if they were simpler (which they are not). What I am interested in =
here is 'more practical'. In particular, what solutions are most likely =
to be acceptable to members of the CA/Browser forum. Solutions that do =
not gain the support of at least one major CA and at least one major =
application provider are irrelevant. The current expectation amongst CAs =
is that the core PKI infrastructures are X.509v3 certificates, X.509v2 =
CRLs and OCSP with an expectation that use of CRLs will be replaced by =
use of OCSP at some point. Any proposal involving any other mechanism is =
going to be less attractive than one based on those mechanisms.

Looking at the OCSP specification, there is an SHA1 problem in any case. =
The key reference mechanism specifies SHA1 as the only algorithm. We =
have to fix that in any case if we are going to take OCSP to DRAFT =
status. Having a digest reference to the whole certificate is the most =
logical alternative.

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

From: [email-masked] on behalf of Johannes Merkle

Sent: Fri 1/9/2009 5:48 AM

To: Philipp G=FChring

Cc: [email-masked]

Subject: Re: A proxy certificate validation question.

Philipp,

>> 2) Employ OCSP as a means of introducing a stronger algorithm =
(and

>> addressing concerns previously raised in this list)

> You mean using something similar like OCSP, that provides a =
re-signature

> for an existing certificate?

Actually, SCVP could help to tell original and rogue certificates apart. =
This requires the following

1) The SCVP server uses a secure hash function and signature =
algorithm

2) The client requests inclusion of the certificate in question in the =
response by means of the wantBack id-swb-pkc-cert.

3) The server is able to retrieve the certificate from a trustworthy =
source (only containing authentic certificates),

i.e. from the CA's repository.

If SCVP was widely deployed, it could mitigate the risks implied by hash =
function weaknesses.

In Germany, the OCSP responders provided by CA's issuing qualified =
certificates typically provide a similar white-list

lookup feature:

1) They respond with status "good" only if the certificate has =
actually been issued by the CA. In particular, they have

access to the CA's repository (or a replication) and do not only rely on =
a CRL.

2) They use a private OCSP response extension CertHash (defined by the =
Common PKI standard) to include the hash value of

the certificate in question in the response.

There are some German signature verification tools and email clients =
which support this white-list lookup feature and

check the certificate against the cert hash included in the response. Of =
course this features exceeds standard OCSP, but

it is actually used.

> I think some RFC defines that a certificate must be unique =
according to

> issuer+serial number. And some software actually implemented that =
and

> completely declares a whole (root?) CA invalid as soon as it sees =
two

> different certificates with same issuer+serial number.

This problem would not occur with a validation service providing =
white-list lookup.

> What if we use something like OCSP that delivers a renewed =
(with

> different serial number) certificate when someone presents an =
old

> certificate?

Better: SCVP or OCSP with white-list lookup.

Johannes

------_=_NextPart_001_01C97265.678002FB--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09AmjLD006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 03:48:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09AmjSZ006405; Fri, 9 Jan 2009 03:48:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from a.mx.secunet.com (a.mx.secunet.com [213.68.205.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09AmXAF006395 for ; Fri, 9 Jan 2009 03:48:44 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id AFD0D20C0BC; Fri, 9 Jan 2009 11:48:31 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 51F9A20C0BB; Fri, 9 Jan 2009 11:48:31 +0100 (CET)
Received: from [10.208.1.240] ([10.208.1.240]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 11:48:31 +0100
Message-ID: <[email-masked]>
Date: Fri, 09 Jan 2009 11:48:30 +0100
From: Johannes Merkle
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Philipp_G=FChring?=
CC: [email-masked]
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jan 2009 10:48:31.0248 (UTC) FILETIME=[CFDE8100:01C97247]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Philipp,

>> 2) Employ OCSP as a means of introducing a stronger algorithm (and
>> addressing concerns previously raised in this list)
>
> You mean using something similar like OCSP, that provides a re-signature
> for an existing certificate?
>

Actually, SCVP could help to tell original and rogue certificates apart. This requires the following
1) The SCVP server uses a secure hash function and signature algorithm
2) The client requests inclusion of the certificate in question in the response by means of the wantBack id-swb-pkc-cert.
3) The server is able to retrieve the certificate from a trustworthy source (only containing authentic certificates),
i.e. from the CA's repository.
If SCVP was widely deployed, it could mitigate the risks implied by hash function weaknesses.

In Germany, the OCSP responders provided by CA's issuing qualified certificates typically provide a similar white-list
lookup feature:
1) They respond with status "good" only if the certificate has actually been issued by the CA. In particular, they have
access to the CA's repository (or a replication) and do not only rely on a CRL.
2) They use a private OCSP response extension CertHash (defined by the Common PKI standard) to include the hash value of
the certificate in question in the response.

There are some German signature verification tools and email clients which support this white-list lookup feature and
check the certificate against the cert hash included in the response. Of course this features exceeds standard OCSP, but
it is actually used.

> I think some RFC defines that a certificate must be unique according to
> issuer+serial number. And some software actually implemented that and
> completely declares a whole (root?) CA invalid as soon as it sees two
> different certificates with same issuer+serial number.
This problem would not occur with a validation service providing white-list lookup.

> What if we use something like OCSP that delivers a renewed (with
> different serial number) certificate when someone presents an old
> certificate?
Better: SCVP or OCSP with white-list lookup.

Johannes

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n092S1rB086803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 19:28:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n092S1As086802; Thu, 8 Jan 2009 19:28:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n092RmBk086781; Thu, 8 Jan 2009 19:28:00 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E119D480B69; Fri, 9 Jan 2009 15:27:47 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQwQOQG9i2MP; Fri, 9 Jan 2009 15:27:47 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 103DF480A1A; Fri, 9 Jan 2009 15:27:37 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 83FDB1AE4003; Fri, 9 Jan 2009 15:27:35 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LL75z-0005wf-CT; Fri, 09 Jan 2009 15:27:35 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Fri, 09 Jan 2009 15:27:35 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Eric Gray" writes:

>Since the consumer ultimately pays the price in any case, perhaps a good
>argument can be made for paying a portion of it up front?

And how are you going to convince the consumer of this? They get "free"
protection currently with their credit cards, and now they have to pay for it?

(In fact there's already been a case of this failing in the past, when banks
asked customers to pay a little extra to get their photos put on their credit
cards for fraud protection. Went down like a lead zeppelin).

Anything that involves customers having to pay for something that they
consider as a right to get for free is going to fail before it even starts.
That's actually not as bad as it sounds since it's one of the few hard-and-
fast design guidelines for this area, unlike most other things ("this may or
may not work, depending on the circumstances").

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08L7KRe073087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 14:07:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08L7KXp073086; Thu, 8 Jan 2009 14:07:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08L79MD073068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 8 Jan 2009 14:07:20 -0700 (MST) (envelope-from [email-masked])
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n08KiLxj027708; Thu, 8 Jan 2009 12:44:21 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 13:06:42 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C971D5.01626E3E"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: A proxy certificate validation question.
Date: Thu, 8 Jan 2009 13:06:42 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: A proxy certificate validation question.
Thread-Index: AclxuhsypsmCGZgpR1uNV/z3H5iG+AAGgp/j
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: "Timothy J. Miller" , =?iso-8859-1?Q?Philipp_G=FChring?=
Cc: , "Stephen Kent" , "Simon Josefsson" ,
X-OriginalArrivalTime: 08 Jan 2009 21:06:42.0628 (UTC) FILETIME=[01A43040:01C971D5]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C971D5.01626E3E
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am a big fan of randomized hashing.
=20
Problem is that some MAC constructions do not offer collision =
resistance. In particular CMAC does not which means that we can use =
HMAC-SHA512 but not CMAC-AES.
=20
Which is a serious limitation as SHA2 is one of the things we are trying =
to get away from.=20
=20
=20
I think we need to find a better construction than CMAC. I don't see why =
we can't have a MAC function constructed from a block cipher that has =
all the provably secure features of CMAC plus provably secure collision =
resistance with a known key.
=20
So the current situation is that I am a big fan of something I do not =
currently have a standard for doing. Which means that we can't use =
randomized hashing as a shortcut for getting a replacement digest =
function.
=20
=20
=20
________________________________

From: Timothy J. Miller [mailto:[email-masked]]
Sent: Thu 1/8/2009 12:53 PM
To: Philipp G=FChring
Cc: Hallam-Baker, Phillip; [email-masked]; Stephen Kent; Simon =
Josefsson; [email-masked]
Subject: Re: A proxy certificate validation question.

Philipp G=FChring wrote:

> It seems that it even matters where the randomness is inserted.
> As far as I have understood it, randomness in the beginning (somewhere
> around the serial number) is better than randomness at the end (some
> X.509v3 extensions)

Use randomized hashing and the whole vector is moot for all hashes
unless a pre-image break is discovered.

-- Tim

------_=_NextPart_001_01C971D5.01626E3E
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: A proxy certificate validation =
question.
=0A=
=0A=
=0A=
=0A=

=0A=

I am a big =
fan of randomized hashing.
=0A=

=0A=

Problem is that some MAC =
constructions do not offer collision resistance. In particular CMAC does =
not which means that we can use HMAC-SHA512 but not =
CMAC-AES.
=0A=

=0A=

Which is a serious limitation =
as SHA2 is one of the things we are trying to get away from. =

=0A=

=0A=

=0A=

I think we need to find a =
better construction than CMAC. I don't see why we can't have a MAC =
function constructed from a block cipher that has all the provably =
secure features of CMAC plus provably secure collision resistance with a =
known key.
=0A=

=0A=

So the current situation is =
that I am a big fan of something I do not currently have a standard for =
doing. Which means that we can't use randomized hashing as a shortcut =
for getting a replacement digest function.
=0A=

=0A=

=0A=

=0A=

=0A=
=0A=

=0A=

From: Timothy J. =
Miller [mailto:[email-masked]]
Sent: Thu 1/8/2009 12:53 =
PM
To: Philipp G=FChring
Cc: Hallam-Baker, Phillip; =
[email-masked]; Stephen Kent; Simon Josefsson; =
[email-masked]
Subject: Re: A proxy certificate validation =
question.

=0A=

=0A=

Philipp G=FChring wrote:

> It seems that it =
even matters where the randomness is inserted.
> As far as I have =
understood it, randomness in the beginning (somewhere
> around the =
serial number) is better than randomness at the end (some
> =
X.509v3 extensions)

Use randomized hashing and the whole vector =
is moot for all hashes
unless a pre-image break is =
discovered.

-- Tim

------_=_NextPart_001_01C971D5.01626E3E--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08IVlqf065205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 11:31:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08IVlXT065204; Thu, 8 Jan 2009 11:31:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08IVaaf065189 for ; Thu, 8 Jan 2009 11:31:47 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LKzfL-0006MA-Fm; Thu, 08 Jan 2009 13:31:36 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 8 Jan 2009 13:31:33 -0500
To: "David A. Cooper"
From: Stephen Kent
Subject: Re: I-D ACTION:draft-ietf-pkix-tac-02.txt
Cc: pkix
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

David,

First, thanks for reading the I-D and providing comments. It will
take a whole for my co-authors and me to respond to all of them, but
I wanted to let acknowledge receipt of the comment.

Thanks,

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08IL1dD064573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 11:21:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08IL1hX064570; Thu, 8 Jan 2009 11:21:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08IKuSG064552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 11:20:57 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 8 Jan 2009 10:20:55 -0800
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Paul Hoffman
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks: is rehashing the blue-sky discussions of how to create a better trust model for SSL without a stable proposal to look at really a good use of the the CFRG, SAAG, S/MIME, and PKIX mailing lists?

If you want to be serious about this, please write an Internet Draft and set up a mailing list for the discussion. Invite people from these lists to join, and maybe announce revisions to your draft. Be sure to invite people from the Mozilla security community: they are having their own (perpetually repeating) discussion of this, again without a stable document to comment on.

We *can* change the security model, but not with the current method of discussion-without-focus.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08HsIhH062541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 10:54:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08HsIsF062540; Thu, 8 Jan 2009 10:54:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08Hs7pm062527 for ; Thu, 8 Jan 2009 10:54:17 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n08Hs5EX012376 for ; Thu, 8 Jan 2009 12:54:06 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n08Hs5pe012358; Thu, 8 Jan 2009 12:54:05 -0500
Received: from [129.83.200.2] (129.83.200.2) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 8 Jan 2009 12:54:05 -0500
Message-ID: <[email-masked]>
Date: Thu, 8 Jan 2009 11:53:29 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Philipp_G=FChring?=
CC: "Hallam-Baker, Phillip" , "[email-masked]" , Stephen Kent , Simon Josefsson , "[email-masked]"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040004050909040303070809"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms040004050909040303070809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Philipp G=FChring wrote:

> It seems that it even matters where the randomness is inserted.
> As far as I have understood it, randomness in the beginning (somewhere
> around the serial number) is better than randomness at the end (some
> X.509v3 extensions)

Use randomized hashing and the whole vector is moot for all hashes=20
unless a pre-image break is discovered.

-- Tim

--------------ms040004050909040303070809
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMDgxNzUzMjlaMCMGCSqGSIb3DQEJBDEWBBTfgSB1PXbyOteAV/Y+FsGmnXnO4DBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgIevwlfMSkg6xkfJIL4DZsu2ADqmekYkooPh7anplHvMdEbjmziqhDhgbu30
cOWEsgAJMyEnNWhLda/wBNfdKDyuMID63AawL7pZluiAwy/JT8HGjDG+cKimlot05yRAAlHo
naYtab7RJpNjxxtpcglJ5eZ038nMmpxoU3+F249dAAAAAAAA
--------------ms040004050909040303070809--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08HUIwb061374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 10:30:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08HUIKD061373; Thu, 8 Jan 2009 10:30:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08HU4Pj061358 for ; Thu, 8 Jan 2009 10:30:16 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA217455704; Thu, 8 Jan 2009 18:28:24 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA09062; Thu, 8 Jan 2009 18:28:23 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes
To: [email-masked]
Date: Thu, 8 Jan 2009 18:28:22 +0100 (MEZ)
Cc: [email-masked]
In-Reply-To: from Tim Polk at Jan "8," 2009 "09:13:47" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Thu, 8 Jan 2009 09:13:47 -0500, Tim Polk wrote:

> Hi Alfred,
>
> The lower bound was dropped for a couple of reasons. Practically
> speaking, any RSA/DSA keys smaller than 1024 bits offer little
> security. ...

Agreed.
(... I bet by all -- maybe except the majority of lazy users
and admins, and a few vendors ... :-) )

> ... Setting any lower bound seems to imply that there is
> a significant break point, and I did not want to give that
> implication.

My primary observation was that removing the break (that more or
less explicitely was present in S/MIME v3.1) might be observed by
implementers updating their software as indicating the converse.

> I also thought that implementations might want to set a more
> aggressive bound (e.g., 768 bits) and leaving off the lower
> bound might encourage making an explicit choice rather than
> supporting 512 because it was specified in the table.

That conceivably is comprised in the "MAY".

> Perhaps the right thing would be to add one more sentence in each
> of the security considerations sections.
>
> For 3850bis:
>
> Note that previous versions of this standard set the lower bound
> for RSA and DSA key sizes at 512 bits; implementations that support
> verification of certificates or CRLs generated with weak keys MUST
> NOT support RSA or DSA keys of less than 512 bits.
>
> For 3851bis:
>
> Note that previous versions of this standard set the lower bound
> for RSA and DSA key sizes at 512 bits; implementations that support
> verification of digital signatures generated with weak keys MUST
> NOT support RSA or DSA keys of less than 512 bits.
>
> Would that address your concern?

Only marginally.

These additions are useful as they contain additional information
not present elsewhere.

But my major concern was *not* the considerations for *receiving*
agents (signature / certificate / CRL *verification*), it was for
agents *generating* signatures (cf. the final paragraph quoted below).

All arguments w.r.t. installed base, existing certs, filed messages,
etc. hold for the verifier case, but they should not entangle the
production of new signatures.

Furthermore, despite the iterated parenthetical clause
"see Security Considerations" in the quoted requirements sections,
I strongly fear that many folks will be tempted to conceive the
striking tabular form there as "the message" the memo sends to
implementors.
If (only) the above explanations (and/or similar text for signature
generation) were added to the Security Considerations, then *their*
message should be clear -- but it might be overlooked.

Furthermore, arguably the tabular forms and the explanations would
be inconsistent, with a "MUST NOT" superimposed over the "MAY" in the
tabular form. I strongly suspect that this would be perceived as
confusing, and at best cause never-ending discussions after the next
succcessfully solved RSA Challenge.

Therefore, I'd prefer having the "MUST NOT" lines for key size < 512
also added to the tabular listing of (at least) the signature
generating requirements.

> Thanks,
> Tim Polk

One more point:

Based on the still ongoing discussion on rogue certificates,
the 3850bis Security Considerations should perhaps also be
amended giving a perspective on probable ongoing consequences,
for instance raising the awareness of the reader for expected
enhancements, e.g. the use of Randomized Hashing.

I suggest that the PKIX working group should start working
on that topic ASAP, and SMIME should build on such work,
with a document amending 3850bis.

> On Jan 7, 2009, at 6:16 AM, Alfred HÎnes wrote:
>
>> Folks,
>>
>> I agree with Paul with regard to the process (new I-D preferable).
>>
>> The AD proposed changes at first glance are intended to make the
>> requirements *stronger* (as far as possible without relying on
>> an official version of FIPS PUB 186-3) without sacrificing
>> backwards compatibility.
>>
>> Therefore, I agree with the amended Security Considerations text,
>> for both 3850bis and 3581bis, and the changes proposed for
>> receiving agent (signature verifier) behavior -- although these
>> now allow small key sizes (< 512) which were not allowed by
>> RFC 3850, and hence this change comes a bit to surprise.
>>
>> However, I really do not understand why, at the 'low end', signature
>> *generating* agents shall now be allowed (via 'MAY') to generate
>> signatures with the even worse key sizes < 512, for both RSA and DSA.
>> Since already S/MIME v3.1 agents had no requirement for being able
>> to verify such signatures, why now adding the capability to produce
>> such signatures ?
>>
>> ...

Kind regards,
Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08HNrH9060953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 10:23:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08HNrYr060952; Thu, 8 Jan 2009 10:23:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08HNfrs060897 for ; Thu, 8 Jan 2009 10:23:52 -0700 (MST) (envelope-from [email-masked])
Received: from 62.218.140.156 (authenticated user [email-masked]) by mailbox.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 5-md50000000159.tmp for ; Thu, 08 Jan 2009 18:23:39 +0100
Message-ID: <[email-masked]>
Date: Thu, 08 Jan 2009 18:23:40 +0100
From: =?ISO-8859-1?Q?Philipp_G=FChring?=
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: "Hallam-Baker, Phillip"
CC: [email-masked], Stephen Kent , Simon Josefsson , "Timothy J. Miller" , [email-masked]
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Authenticated-Sender: [email-masked]
X-Spam-Processed: mailbox.go-now.at, Thu, 08 Jan 2009 18:23:39 +0100 (not processed: spam filter disabled)
X-Return-Path: [email-masked]
X-MDaemon-Deliver-To: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi,

> 1) Enables a limit to be placed on a path length

Path-Length limitation only helps against a Sub-CA attack.
It doesn't help against an attack where EE' is a certificate for *.com
(According to the researchers, that attack is even easier than a Sub-CA
attack.)

> SHA1 is not an immediate threat but it is certainly something that we
> should worry about.

I fully agree. SHA1 will likely follow with the same kind of attack in a
few years.

> At the moment I see three potential insurance policies
>
> 1) Introduce additional randomness into the digest value.

It seems that it even matters where the randomness is inserted.
As far as I have understood it, randomness in the beginning (somewhere
around the serial number) is better than randomness at the end (some
X.509v3 extensions)

> 2) Employ OCSP as a means of introducing a stronger algorithm (and
> addressing concerns previously raised in this list)

You mean using something similar like OCSP, that provides a re-signature
for an existing certificate?

Something we should be careful about:
I think some RFC defines that a certificate must be unique according to
issuer+serial number. And some software actually implemented that and
completely declares a whole (root?) CA invalid as soon as it sees two
different certificates with same issuer+serial number.
So if we re-sign an old certificate, and the client would exchange the
signature, this would cause a different certificate (at least the
signature at the end and the SHA-1 (or MD5) Hash of the whole
certificate would change). If it passes the modified certificate on to
another module, the other module might declare the CA invalid.

What if we use something like OCSP that delivers a renewed (with
different serial number) certificate when someone presents an old
certificate?

> 3) Employ path length constraints in the CA cert to defeat the single
> bit attack.

I personally do not believe in Path-Length constraints.

> I like all three approaches and do not consider them to be exclusive. If
> we pick just one I think we are more likely to see a failure.

Best regards,
Philipp Gühring

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08GYlwT057364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:34:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08GYlmt057362; Thu, 8 Jan 2009 09:34:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from thunker.thunk.org (THUNK.ORG [69.25.196.29]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08GYiSg057336 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:34:45 -0700 (MST) (envelope-from [email-masked])
Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LKxq3-0007Zm-7B; Thu, 08 Jan 2009 11:34:31 -0500
Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LKxq2-0007BP-72; Thu, 08 Jan 2009 11:34:30 -0500
Date: Thu, 8 Jan 2009 11:34:30 -0500
From: Theodore Tso
To: Eric Gray
Cc: Peter Gutmann , [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogueCAcertificate
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-SA-Exim-Connect-IP:
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Thu, Jan 08, 2009 at 09:11:21AM -0600, Eric Gray wrote:
> As a result, some organizations already pay for news-feeds
> from known (verifiably) reliable sources. Because on-line news is
> also valuable because it's quickly delivered. No matter how you
> get it, it's not necessarily free.

Some do; some of us even subscribe to dead-tree versions of the
newspapers even though we do most of our reading on-line, on the
general theory that it's good public policy to support the Fourth
Estate (since they serve a critical function keeping the government
honest), even though we do most of our news reading online. The
problem is very few people are willing to pay for on-line news when
they can get the New York Times at http://www.nytimes.com (and many
other news sources) for free.

> As the Heinlein acronym "TANSTAAFL" says, there ain't no
> such thing as a free lunch. And I suspect that an increasingly
> large number of people are coming to really understand that.

Yes, but there are a huge number of people who are used to receiving a
lot of these services either for free, or bundled into prices (which
have gotten cheaper as a result of e-commerce). This is basically the
classic Tragedy of the Commons problem; how many people can *honestly*
say that they've never gone to Best Buy or Circuit City to examine
some device or gadget in person, and then gone on to buy it on-line
because it was cheaper? And did so even though it should be *obvious*
that the TANSTAAFL principle applied, and would in the long-run lead
to the weakening or disappearance of the bricks-and-morter stores?

- Ted

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08GUgBM057001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:30:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08GUge3057000; Thu, 8 Jan 2009 09:30:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08GUVka056933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 8 Jan 2009 09:30:41 -0700 (MST) (envelope-from [email-masked])
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n08GUDI8009393; Thu, 8 Jan 2009 08:30:13 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 08:30:13 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C971AE.6177D142"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: A proxy certificate validation question.
Date: Thu, 8 Jan 2009 08:30:13 -0800
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: A proxy certificate validation question.
Thread-Index: AclxJMrZFNXPOwpcRwWrOmiPdw31OgAhxc97
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hallam-Baker, Phillip"
To: , "Stephen Kent"
Cc: , "Simon Josefsson" , "Timothy J. Miller" ,
X-OriginalArrivalTime: 08 Jan 2009 16:30:13.0291 (UTC) FILETIME=[61A03FB0:01C971AE]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C971AE.6177D142
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think that as far as the IETF is concerned we need to stop thinking =
about the MD5 issue and instead think about the SHA1 issue. That is =
harder because the legacy base does not provide universal support for =
something stronger. So any transition comes with a significant cost.

Lets break this down, I think there might have been a good idea that was =
missed.

The particular feature of the compressor attack is that you only get to =
flip a single bit. Therefore you have to make it count. Flipping the =
cert signing bit from on to off is the most effective way of making it =
count.

So if the initial chain is

R -> C1 -> C2 -> EE

The new chain is

R -> C1 -> C2 -> EE' -> EE

There are two places we can apply constraints to defeat this attack. One =
is in EE, the other is somewhere higher up in the chain, C1 or C2.

So the question now is, is there an extension that is implemented today =
that

1) Enables a limit to be placed on a path length
2) Is implemented in existing browsers
3) Can be used without interfering with other browsers, i.e.
3a) MAY be marked not-critical
3b) Is accepted by every legacy browser without exception.

In terms of 3a, I am quite happy taking an existing extension and =
changing a MUST to a SHOULD provided that we don't have a deployed base =
that attempts to enforce compliance. If ou are using the extension for =
the purpose of issuing proxy certs then the requirement is necessary. =
But the critical bit means 'break if you do not understand this' and =
this is not the desired semantics for an insurance policy.

The ideal case is that we find something that works today. The less =
ideal case is that we can only impose restrictions going forward which =
is still valuable, but not so much.

SHA1 is not an immediate threat but it is certainly something that we =
should worry about. At the moment I see three potential insurance =
policies

1) Introduce additional randomness into the digest value.
2) Employ OCSP as a means of introducing a stronger algorithm (and =
addressing concerns previously raised in this list)
3) Employ path length constraints in the CA cert to defeat the single =
bit attack.

I like all three approaches and do not consider them to be exclusive. If =
we pick just one I think we are more likely to see a failure.

-----Original Message-----
From: [email-masked] on behalf of Von Welch
Sent: Wed 1/7/2009 6:16 PM
To: Stephen Kent
Cc: [email-masked]; Simon Josefsson; Timothy J. Miller; =
[email-masked]
Subject: Re: A proxy certificate validation question.
=20

Steve,

Yes, while both the basic constraints with CA !=3D True and the
critical extension should cause a failure in that case, the basic
constraints failure should come first per processing rules.

Von

Stephen Kent wrote:
>=20
> Von,
>=20
> I think David Cooper's response is correct, i.e., because the issuer =
of
> the proxy cert is an EE, and an EE is NOT normally allowed to pose as =
a
> CA, the cert path validation should fail if an RP is not aware of the
> special processing required for a proxy cert.
>=20
> Steve

------_=_NextPart_001_01C971AE.6177D142
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: A proxy certificate validation question.

I think that as far as the IETF is concerned we need =
to stop thinking about the MD5 issue and instead think about the SHA1 =
issue. That is harder because the legacy base does not provide universal =
support for something stronger. So any transition comes with a =
significant cost.

Lets break this down, I think there might have been a good idea that was =
missed.

The particular feature of the compressor attack is that you only get to =
flip a single bit. Therefore you have to make it count. Flipping the =
cert signing bit from on to off is the most effective way of making it =
count.

So if the initial chain is

R -> C1 -> C2 -> EE

The new chain is

R -> C1 -> C2 -> EE' -> EE

There are two places we can apply constraints to defeat this attack. One =
is in EE, the other is somewhere higher up in the chain, C1 or C2.

So the question now is, is there an extension that is implemented today =
that

1) Enables a limit to be placed on a path length

2) Is implemented in existing browsers

3) Can be used without interfering with other browsers, i.e.

3a) MAY be marked not-critical

3b) Is accepted by every legacy browser without =
exception.

In terms of 3a, I am quite happy taking an existing extension and =
changing a MUST to a SHOULD provided that we don't have a deployed base =
that attempts to enforce compliance. If ou are using the extension for =
the purpose of issuing proxy certs then the requirement is necessary. =
But the critical bit means 'break if you do not understand this' and =
this is not the desired semantics for an insurance policy.

The ideal case is that we find something that works today. The less =
ideal case is that we can only impose restrictions going forward which =
is still valuable, but not so much.

SHA1 is not an immediate threat but it is certainly something that we =
should worry about. At the moment I see three potential insurance =
policies

1) Introduce additional randomness into the digest value.

2) Employ OCSP as a means of introducing a stronger algorithm (and =
addressing concerns previously raised in this list)

3) Employ path length constraints in the CA cert to defeat the single =
bit attack.

I like all three approaches and do not consider them to be exclusive. If =
we pick just one I think we are more likely to see a failure.

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

From: [email-masked] on behalf of Von Welch

Sent: Wed 1/7/2009 6:16 PM

To: Stephen Kent

Cc: [email-masked]; Simon Josefsson; Timothy J. Miller; =
[email-masked]

Subject: Re: A proxy certificate validation question.

Steve,

Yes, while both the basic constraints with CA !=3D True and =
the

critical extension should cause a failure in that case, the basic

constraints failure should come first per processing rules.

Von

Stephen Kent wrote:

> Von,

> I think David Cooper's response is correct, i.e., because the =
issuer of

> the proxy cert is an EE, and an EE is NOT normally allowed to pose =
as a

> CA, the cert path validation should fail if an RP is not aware of =
the

> special processing required for a proxy cert.

> Steve

------_=_NextPart_001_01C971AE.6177D142--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08EpB2n049969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 07:51:11 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08EpBCx049967; Thu, 8 Jan 2009 07:51:11 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from thunker.thunk.org (THUNK.ORG [69.25.196.29]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08Ep9jx049956 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 07:51:10 -0700 (MST) (envelope-from [email-masked])
Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LKwDr-0007QE-7O; Thu, 08 Jan 2009 09:50:59 -0500
Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LKwDq-0006X6-A8; Thu, 08 Jan 2009 09:50:58 -0500
Date: Thu, 8 Jan 2009 09:50:58 -0500
From: Theodore Tso
To: Eric Gray
Cc: Peter Gutmann , [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-SA-Exim-Connect-IP:
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Thu, Jan 08, 2009 at 08:16:33AM -0600, Eric Gray wrote:
> The notion of merchants and bankers "bearing the burden" is a
> great fiction - at least if you're considering them as a group. In
> individual cases, individual merchants/bankers will absorb losses,
> but either that means they go out of business (which we see
> sometimes) or they survive to defray their losses by charging
> consumers more for their products and services.

I didn't say it was a good way to run a railroad --- just as having
more and more people read their news on-line for free, while reporters
are paid via a business model that depends on rapidly diminishing
advertising revenues for print and on-line banner ads, plus the
vanishingly small number of people willing to pay for dead-tree
versions of newspapers is a great way of running things.

But the problem is very similar; if at least in the US, consumers are
used to a model where they only pay for the costs of fraud via a
surcharge which is hidden in the cost of the on-line merchant's
prices, how do you convince them that it is worthwhile to pay for a
trust certification service? Especially given that a merchant is
still going to have to pay the 3% credit card fee to the credit card
companies, which ends up showing up in the price of goods and/or
services?

> Since the consumer ultimately pays the price in any case,
> perhaps a good argument can be made for paying a portion of it up
> front?

>From a public policy POV, perhaps. How you actually convince the
consumers, merchants, credit card companies, and the rest of the
system to transition from the current scheme to this new scheme is
much more difficult than writing an RFC, alas. (And as we all know,
writing and publishing RFC is no guarantee that the market will listen
to us.)

- Ted

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08ELhH8048008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 07:21:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08ELh0C048007; Thu, 8 Jan 2009 07:21:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08ELV97047986; Thu, 8 Jan 2009 07:21:41 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n08ELTmP012803; Thu, 8 Jan 2009 09:21:30 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n08ELSka012744; Thu, 8 Jan 2009 09:21:28 -0500
Received: from [129.83.200.2] (129.83.200.2) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 8 Jan 2009 09:21:28 -0500
Message-ID: <[email-masked]>
Date: Thu, 8 Jan 2009 08:20:59 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Jeffrey Hutzelman
CC: Peter Gutmann , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
References:
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000306050806080101080606"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms000306050806080101080606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jeffrey Hutzelman wrote:

> Note that charging a fee for this service is not absurd. Lots of people
> (consumers) pay fees for up-to-date lists of virus signatures, phishing
> sites, spam-blocking rules, and so on.

Actually, most consumers keep these up-to-date only as long as the free
trial period given to them when they bought the computer lasts, and then
cease to care.

The core business for these companies is business contracts.

-- Tim

--------------ms000306050806080101080606
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMDgxNDIwNTlaMCMGCSqGSIb3DQEJBDEWBBRhJ8OPKskpKyb409QzoLQfobWV4jBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgDBLEFj0m7V/YBruCeqkQOL5+50I4wjSl4F7hbwnsA/gW3p7PxNvfJS69qTn
6YVdQIoNfYEsr4bhwHtn1fz373t0puwCZG3u4koo1P7KuagH0ja1JKvuJBwHNWI2wU+6g9CF
xKN5jCoDe+7QmWB1WLOpC1S/M6mpmc+c3XbX4y2EAAAAAAAA
--------------ms000306050806080101080606--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08E8YJg046643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 07:08:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08E8YTw046641; Thu, 8 Jan 2009 07:08:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08E8Wud046617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jan 2009 07:08:33 -0700 (MST) (envelope-from [email-masked])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n08E8MJp005143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:08:22 -0500 (EST)
Date: Thu, 08 Jan 2009 09:08:22 -0500
From: Jeffrey Hutzelman
To: Peter Gutmann , [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Message-ID: <[email-masked]>
In-Reply-To:
References:
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Friday, January 09, 2009 02:17:44 AM +1300 Peter Gutmann
wrote:

> Jeffrey Hutzelman writes:
>
>> Note that charging a fee for this service is not absurd. Lots of people
>> (consumers) pay fees for up-to-date lists of virus signatures, phishing
>> sites, spam-blocking rules, and so on.
>
> Conceptually it's not absurd, but how are you going to persuade a
> billion-odd users that they need to pay for something that they've been
> conditioned to get for free? Will you promise to indemnify them against
> identity theft (via phishing) if they sign up to your service? What
> value-add will you offer that will convince the drool-and-click masses to
> pay for your service?

Convince the insurance companies to give discounts on "identity theft"
insurance (yes, this product exists and is pretty common; it covers the
costs of tracking down and fixing the results of fraud that, under the
present system, are borne _not_ by the banks or merchants but by the
individual who was impersonated).

Convince the security software companies to add this service to their
bundles. Plenty of people buy that stuff.

Convince the banks to change their rules to make you responsible for
unauthorized access if it would have been prevented by such a service and
you weren't using one.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08DwHpS045766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 06:58:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08DwHjU045765; Thu, 8 Jan 2009 06:58:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from thunker.thunk.org (THUNK.ORG [69.25.196.29]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08Dw5vT045732 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 06:58:16 -0700 (MST) (envelope-from [email-masked])
Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LKvOT-0007Ly-J8; Thu, 08 Jan 2009 08:57:53 -0500
Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LKvOS-0006Ca-R3; Thu, 08 Jan 2009 08:57:52 -0500
Date: Thu, 8 Jan 2009 08:57:52 -0500
From: Theodore Tso
To: Peter Gutmann
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Message-ID: <[email-masked]>
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-SA-Exim-Connect-IP:
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Fri, Jan 09, 2009 at 02:17:44AM +1300, Peter Gutmann wrote:
>
> Conceptually it's not absurd, but how are you going to persuade a
> billion-odd users that they need to pay for something that they've
> been conditioned to get for free? Will you promise to indemnify
> them against identity theft (via phishing) if they sign up to your
> service? What value-add will you offer that will convince the
> drool-and-click masses to pay for your service?

Especially since the market has already come up with a solution that
involves the merchants and the credit card companies bearing the
burden of most fraud losses...

- Ted

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08DI6M8043626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 06:18:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08DI6LU043623; Thu, 8 Jan 2009 06:18:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08DHs51043586; Thu, 8 Jan 2009 06:18:05 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0A48E199E2; Fri, 9 Jan 2009 02:17:54 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFtiCLKZ2K+g; Fri, 9 Jan 2009 02:17:53 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2C9BB19ABA; Fri, 9 Jan 2009 02:17:51 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 761C91BE4002; Fri, 9 Jan 2009 02:17:44 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LKulc-0003IJ-4X; Fri, 09 Jan 2009 02:17:44 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To:
Message-Id:
Date: Fri, 09 Jan 2009 02:17:44 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jeffrey Hutzelman writes:

>Note that charging a fee for this service is not absurd. Lots of people
>(consumers) pay fees for up-to-date lists of virus signatures, phishing
>sites, spam-blocking rules, and so on.

Conceptually it's not absurd, but how are you going to persuade a billion-odd
users that they need to pay for something that they've been conditioned to get
for free? Will you promise to indemnify them against identity theft (via
phishing) if they sign up to your service? What value-add will you offer that
will convince the drool-and-click masses to pay for your service?

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08CVZge041157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 05:31:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08CVY0t041155; Thu, 8 Jan 2009 05:31:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08CVNS7041129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jan 2009 05:31:34 -0700 (MST) (envelope-from [email-masked])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n08CV9b5003696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 07:31:10 -0500 (EST)
Date: Thu, 08 Jan 2009 07:31:09 -0500
From: Jeffrey Hutzelman
To: Peter Gutmann , [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Message-ID:
In-Reply-To:
References:
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Thursday, January 08, 2009 08:23:55 PM +1300 Peter Gutmann
wrote:

> Jeffrey Hutzelman writes:
>
>> Perhaps a solution to this is a new model.
>
> A good start...
>
>> which for a fee provides
>
> ... and it just failed right there.

Perhaps, but it's fairly well essential. That fee is the basis for the
trust anchor provider's contractual obligation to the end user. Drop that,
and the whole thing falls apart.

Note that charging a fee for this service is not absurd. Lots of people
(consumers) pay fees for up-to-date lists of virus signatures, phishing
sites, spam-blocking rules, and so on.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n087OGcr024770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 00:24:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n087OGfS024768; Thu, 8 Jan 2009 00:24:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n087O4X0024746; Thu, 8 Jan 2009 00:24:15 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2516B9E5B5; Thu, 8 Jan 2009 20:24:04 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+pssntYkJXL; Thu, 8 Jan 2009 20:24:04 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5EB4C9E529; Thu, 8 Jan 2009 20:24:01 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BDC571BE4002; Thu, 8 Jan 2009 20:23:55 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LKpFD-0002LS-Ks; Thu, 08 Jan 2009 20:23:55 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Thu, 08 Jan 2009 20:23:55 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jeffrey Hutzelman writes:

>Perhaps a solution to this is a new model.

A good start...

>which for a fee provides

... and it just failed right there.

Peter :-).

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n086aU3w022851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 23:36:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n086aUub022849; Wed, 7 Jan 2009 23:36:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n086aIi7022835; Wed, 7 Jan 2009 23:36:29 -0700 (MST) (envelope-from [email-masked])
Received: from ASCUK001 ([87.201.190.32]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Thu, 08 Jan 2009 06:36:45 +0000
From: "Liaquat Khan"
To: "'Jeffrey Hutzelman'" , "'Peter Gutmann'" ,
Cc: , , , ,
References: <[email-masked]> <[email-masked]>
Subject: RE: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Date: Thu, 8 Jan 2009 10:35:31 +0400
Message-ID: <5FAA73B18D1A43E088BFE298631450BB@ASCUK001>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <[email-masked]>
Thread-Index: AclxVRJNA4tWjn2gR7CFY2ggvUDA7wAAvShw
X-ME-Bayesian: 0.000000
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jeff, what you describe is similar to the concept of a "validation
authority", which has been around for a while. A VA service has a
contractual relationship with RPs, and is responsible for responding on
trustworthiness of certificates (and/or signatures). XKMS/SCVP/DSS
protocols support this concept. There is at least one commercial entity
(our partner DNV), which is offering such a service currently:
http://www.dnv.com/services/verification/vas/index.asp

Importantly in addition to validating the trustworthiness of the
certificate, DNV also offer a security quality rating for the certificate
(based on the CA's audited policy/practices, hash and public key algorithms
used and key lengths etc.). Such a quality rating service is important in
examples like this where a certificate is trusted because it chains to a
trust anchor, but is not considered acceptable because it fails a minimum
quality rating required by the RP.

However although Ascertia offers products which interface with Validation
Authority service providers, the standard browser is not yet capable of this
and is unlikely to be for some time.

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jeffrey Hutzelman
Sent: 08 January 2009 09:45
To: Peter Gutmann; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

--On Thursday, January 08, 2009 05:21:22 PM +1300 Peter Gutmann
wrote:

> Even then it's a rather indirect approach that doesn't really target the
> guilty party since you're scaring the user who is supposed to exert
> pressure on the site which is then supposed to pressure the CA for a fix.

This cuts to the root of the problem: there are no contractual relations
between a relying party and the cartificate authorities upon whom he
relies. As a result, there is no incentive for certificate authorities to
adopt practices which benefit the relying party. Instead, the incentive is
to adopt practices which benefit the CA and its customers, which are the
parties to whom it issues certificates (but _not_ the parties to whom only
other CA's issue certificates).

Perhaps a solution to this is a new model. Under the new model, each
relying party who chooses to participate would punt the trust anchors that
come with his or her browser or other software, and instead subscribe to a
trust anchor service, which for a fee provides a regularly-maintained list
of trust anchors, or perhaps a single trust anchor which signs "root" CA
certificates and for which a well-maintained OCSP server is provided. Such
a trust anchor service would be an obvious candidate for bundling with ISP
services or for sale by security software vendors.

The trust anchor service, then, reaches agreements with the various
certificate authorities, under which the CA is included in the list of
trust anchors in exchange for the CA agreeing to maintain practices which
are acceptable to the trust anchor provider. Note that some browser
vendors already do essentially this, except that the CA has no contractual
obligation to the browser vendor to meet the cirteria for inclusion in the
trust anchor list on an ongoing basis, and the browser vendor has no
contractual obligation to the users of its product to include only those
CA's which meet a suitable set of criteria.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n085jpWA020637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 22:45:51 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n085joXK020635; Wed, 7 Jan 2009 22:45:51 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n085jcKB020614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Jan 2009 22:45:50 -0700 (MST) (envelope-from [email-masked])
Received: from 68-246-165-160.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n085jJwe008311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 00:45:21 -0500 (EST)
Date: Thu, 08 Jan 2009 00:45:19 -0500
From: Jeffrey Hutzelman
To: Peter Gutmann , [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Thursday, January 08, 2009 05:21:22 PM +1300 Peter Gutmann
wrote:

> Even then it's a rather indirect approach that doesn't really target the
> guilty party since you're scaring the user who is supposed to exert
> pressure on the site which is then supposed to pressure the CA for a fix.

This cuts to the root of the problem: there are no contractual relations
between a relying party and the cartificate authorities upon whom he
relies. As a result, there is no incentive for certificate authorities to
adopt practices which benefit the relying party. Instead, the incentive is
to adopt practices which benefit the CA and its customers, which are the
parties to whom it issues certificates (but _not_ the parties to whom only
other CA's issue certificates).

Perhaps a solution to this is a new model. Under the new model, each
relying party who chooses to participate would punt the trust anchors that
come with his or her browser or other software, and instead subscribe to a
trust anchor service, which for a fee provides a regularly-maintained list
of trust anchors, or perhaps a single trust anchor which signs "root" CA
certificates and for which a well-maintained OCSP server is provided. Such
a trust anchor service would be an obvious candidate for bundling with ISP
services or for sale by security software vendors.

The trust anchor service, then, reaches agreements with the various
certificate authorities, under which the CA is included in the list of
trust anchors in exchange for the CA agreeing to maintain practices which
are acceptable to the trust anchor provider. Note that some browser
vendors already do essentially this, except that the CA has no contractual
obligation to the browser vendor to meet the cirteria for inclusion in the
trust anchor list on an ongoing basis, and the browser vendor has no
contractual obligation to the users of its product to include only those
CA's which meet a suitable set of criteria.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n084LfCi017117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 21:21:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n084LfiI017114; Wed, 7 Jan 2009 21:21:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n084LRaq017099; Wed, 7 Jan 2009 21:21:39 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9E02319A23; Thu, 8 Jan 2009 17:21:26 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPAH1uc8SBNx; Thu, 8 Jan 2009 17:21:26 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 987C719A2C; Thu, 8 Jan 2009 17:21:23 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6D18E1BE4002; Thu, 8 Jan 2009 17:21:22 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LKmOY-0001mL-AH; Thu, 08 Jan 2009 17:21:22 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Thu, 08 Jan 2009 17:21:22 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Viviani Paz" writes:

>1- browser vendors strongly encouraging the CA organisations vulnerable to
>this problem (using MD5) to get their act together. I'd like to see the
>browser vendors giving them a cut off timeframe and remove these root certs
>from their trust lists for good.

The problem with this is that it's not going to be so easy to tell who's at
fault, the first MD5 cert may not appear until several levels down the food
chain so there's no way to tell whether a particular root ends in an MD5 cert.
And if you do remove a root because some unrelated party five steps down the
food chain uses MD5 I can see lawsuits happening...

>2- meanwhile browser vendors could issue a warning when certificates relying
>on MD5 are in use, this is simpler to be done and shame goes a long way
>sometimes. It doesn't resolve the problem, but sets things in motion.

That one would definitely work, but has the downside of penalising innocent
customers of the CA that issued the cert and not the CA that made the mess.
You'd have to convince the CA to issue free replacements for this to work,
possibly by framing the warning message in terms of the CA using unsafe
practices rather than the site itself being insecure. Even then it's a rather
indirect approach that doesn't really target the guilty party since you're
scaring the user who is supposed to exert pressure on the site which is then
supposed to pressure the CA for a fix.

(This is one of those great all-care-and-no-responsibility situations, the CAs
can pretty much screw up as much as they want but there's no real
repercussions for anyone because of the collateral damage issue. The debate
on the Mozilla forums shows this, there's all manner of knee-jerk reactions
possible to make an example of someone convenient but none of them really get
to the root of the problem).

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07NGt54005487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 16:16:55 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07NGtUT005486; Wed, 7 Jan 2009 16:16:55 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from rimantadine.ncsa.uiuc.edu (rimantadine.ncsa.uiuc.edu [141.142.2.77]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07NGsAS005479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Jan 2009 16:16:55 -0700 (MST) (envelope-from [email-masked])
Received: from vons-mac.ncsa.uiuc.edu (vpn-user-18.ncsa.uiuc.edu [141.142.18.18]) by rimantadine.ncsa.uiuc.edu (8.14.3/8.14.3) with ESMTP id n07NGfSC029361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 17:16:41 -0600
Message-ID: <[email-masked]>
Date: Wed, 07 Jan 2009 17:16:41 -0600
From: Von Welch
Reply-To: [email-masked]
Organization: NCSA
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Stephen Kent
CC: [email-masked], Simon Josefsson , "Timothy J. Miller" , "[email-masked]"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Null-Tag: 508c6b73d89f4ec6f674ab2a3e9fbc8f
X-NCSA-MailScanner-Information: Please contact [email-masked] for more information, rimantadine.ncsa.uiuc.edu
X-NCSA-MailScanner-ID: n07NGfSC029361
X-NCSA-MailScanner: Found to be clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Steve,

Yes, while both the basic constraints with CA != True and the
critical extension should cause a failure in that case, the basic
constraints failure should come first per processing rules.

Von

Stephen Kent wrote:
>
> Von,
>
> I think David Cooper's response is correct, i.e., because the issuer of
> the proxy cert is an EE, and an EE is NOT normally allowed to pose as a
> CA, the cert path validation should fail if an RP is not aware of the
> special processing required for a proxy cert.
>
> Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07N3eZJ004984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 16:03:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07N3dKF004983; Wed, 7 Jan 2009 16:03:39 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07N3S6B004971 for ; Wed, 7 Jan 2009 16:03:38 -0700 (MST) (envelope-from [email-masked])
Received: by gxk12 with SMTP id 12so889389gxk.10 for ; Wed, 07 Jan 2009 15:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=OcaKgg0lUm2VUz0erPYigUOfVOKcLYCYra17gAbmvC8=; b=cSOdfxR++A470+DcDUb7iyyDpxSUUAyCdKf+bK9pQG7OJsurht6DSz0ykBjlcyzIVJ WLwuFti8XFt2qNnt3+ccvJ4PxHYyUNs3MaFtJAoNxMQdqf+7jY4ilf/peNlY8v4HlnLU OiPaiydYrKdDPebGPi8BrnqRRqJDQ4K/JcxPo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=v8mO0oKDnatsuMmzBf/BxqHQMkE1W1BhgiHranbk11nqmpPnphoN0U5mjzfqJGVydg Uv9Flvw/yoyQCH+nnKMlsvp2Zn8zCn/ZIYtb6hZI1j483lEoz0X8+OjjIls9KL9Nx9vR wYhq+SOhAViWMlcwRj8pXhyJtL+p2RAR8NafQ=
Received: by 10.150.144.9 with SMTP id r9mr18502667ybd.189.1231369407793; Wed, 07 Jan 2009 15:03:27 -0800 (PST)
Received: by 10.150.158.3 with HTTP; Wed, 7 Jan 2009 15:03:27 -0800 (PST)
Message-ID:
Date: Wed, 7 Jan 2009 18:03:27 -0500
From: "Tom Scavo"
To: "Stephen Kent"
Subject: Re: A proxy certificate validation question.
Cc: [email-masked], "Simon Josefsson" , "Timothy J. Miller" , "[email-masked]"
In-Reply-To:
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[email-masked]> <[email-masked]> <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Wed, Jan 7, 2009 at 5:26 PM, Stephen Kent wrote:
>
> I think David Cooper's response is correct, i.e., because the issuer of the
> proxy cert is an EE

The issuer of a PC is either an EE or another PC.

> and an EE is NOT normally allowed to pose as a CA, the
> cert path validation should fail if an RP is not aware of the special
> processing required for a proxy cert.

Yes, I think you're right. It's a race condition between
basicConstraints and an unrecognized critical extension. AFAICT by
reading 5280, basicConstraints wins.

Tom

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07MRCmG003648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 15:27:12 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07MRCDV003647; Wed, 7 Jan 2009 15:27:12 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07MR1uo003633 for ; Wed, 7 Jan 2009 15:27:11 -0700 (MST) (envelope-from [email-masked])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LKgrZ-0005v2-DL; Wed, 07 Jan 2009 17:26:57 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 7 Jan 2009 17:26:51 -0500
To: [email-masked]
From: Stephen Kent
Subject: Re: A proxy certificate validation question.
Cc: Simon Josefsson , "Timothy J. Miller" , "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Von,

I think David Cooper's response is correct, i.e., because the issuer
of the proxy cert is an EE, and an EE is NOT normally allowed to pose
as a CA, the cert path validation should fail if an RP is not aware
of the special processing required for a proxy cert.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07LQk8n001520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 14:26:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07LQkRZ001519; Wed, 7 Jan 2009 14:26:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from rimantadine.ncsa.uiuc.edu (rimantadine.ncsa.uiuc.edu [141.142.2.77]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07LQYc6001508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Jan 2009 14:26:45 -0700 (MST) (envelope-from [email-masked])
Received: from vons-mac.ncsa.uiuc.edu ([150.108.235.22]) by rimantadine.ncsa.uiuc.edu (8.14.3/8.14.3) with ESMTP id n07LQNhS019824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 15:26:26 -0600
Message-ID: <[email-masked]>
Date: Wed, 07 Jan 2009 15:26:23 -0600
From: Von Welch
Reply-To: [email-masked]
Organization: NCSA
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Simon Josefsson
CC: "Timothy J. Miller" , "[email-masked]"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Null-Tag: 5bc7cd22391e383b307b4205c1e676ca
X-Scanned-By: milter-spamc/1.13.385 (relay-3.ncsa.uiuc.edu [141.142.2.247]); Wed, 07 Jan 2009 15:26:28 -0600
X-Spam-Status: NO, hits=-0.30 required=4.90
X-Spam-Report: Spam detection software, running on the system "rimantadine.ncsa.uiuc.edu", has | identified this incoming email as possible spam. The original message | has been attached to this so you can view it (if it isn't spam) or label | similar future email. If you have any questions, see | [email-masked] for details. | | Content preview: Simon Josefsson wrote: > "Timothy J. Miller" | writes: > >> Just to take a break from discussing MD5 for a moment, let me | make >> sure I understand the implications of the proxy cert (PC) path >> | validation algorithm: >> >> A relying party that does *not* understand PCs | will fail to validate a >> chain from root->EE->PC *if and only if* one of | the CAs in the chain >> has pathLenConstraint set to a value that exhausts | at the EE cert. > > Per RFC 3820 the proxyCertInfo extension MUST be marked | as critical, and > if I understand RFC 3280 correctly, verifiers MUST reject | the > certificate if it encounters a critical extension it does not recognize. | [...] | | Content analysis details: (-0.3 points, 4.9 required) | | pts rule name description | ---- ---------------------- -------------------------------------------------- | -0.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1p | [score: 0.0000] | 0.2 RDNS_NONE Delivered to trusted network by a host with no rDNS |
X-NCSA-MailScanner-Information: Please contact [email-masked] for more information, rimantadine.ncsa.uiuc.edu
X-NCSA-MailScanner-ID: n07LQNhS019824
X-NCSA-MailScanner: Found to be clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Simon Josefsson wrote:
> "Timothy J. Miller" writes:
>
>> Just to take a break from discussing MD5 for a moment, let me make
>> sure I understand the implications of the proxy cert (PC) path
>> validation algorithm:
>>
>> A relying party that does *not* understand PCs will fail to validate a
>> chain from root->EE->PC *if and only if* one of the CAs in the chain
>> has pathLenConstraint set to a value that exhausts at the EE cert.
>
> Per RFC 3820 the proxyCertInfo extension MUST be marked as critical, and
> if I understand RFC 3280 correctly, verifiers MUST reject the
> certificate if it encounters a critical extension it does not recognize.

That is correct, the fact the PC extension is critical is the
mechanism that prevents a relying party ignorant of proxy
certificates from validating one.

The fact that the subject name of the PC must be a single CN
component appended to the subject name of its issuer (see Sections
3.4 and 4.1.3.a.4) prevents any spoofing of an EE subject name in a
PC at a PC-aware relying party.

Von

> The latter is not reflected in the section 6 path validation algorithm,
> as far as I can tell, though, but it is mentioned in section 4.2.
>
> /Simon
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07IRSoY092895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 11:27:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07IRS5w092894; Wed, 7 Jan 2009 11:27:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07IRR7G092888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Jan 2009 11:27:28 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n07IRU5c011107; Wed, 7 Jan 2009 13:27:30 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n07IRGfZ029817; Wed, 7 Jan 2009 13:27:16 -0500
Message-ID: <[email-masked]>
Date: Wed, 07 Jan 2009 13:27:16 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.18 (X11/20081120)
MIME-Version: 1.0
To: "Timothy J. Miller"
CC: "[email-masked]"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

No pathLenConstraint is necessary. If the EE certificate is really an
EE certificate, then it will either not include a basicConstraints
extension or it will include a basicConstraints extension with
cA=FALSE. In either case, a relying party that does not understand
proxy certificates will not validate any certification paths that
include the EE certificate as an intermediate certificate, and so would
reject a path of the form ...->EE->PC.

Dave

Timothy J. Miller wrote:
> Just to take a break from discussing MD5 for a moment, let me make
> sure I understand the implications of the proxy cert (PC) path
> validation algorithm:
>
> A relying party that does *not* understand PCs will fail to validate a
> chain from root->EE->PC *if and only if* one of the CAs in the chain
> has pathLenConstraint set to a value that exhausts at the EE cert.
>
> In other words, in order to prevent EEs from issuing PCs to spoof
> other EEs, the last CA in a chain can set pathLenConstraint=0.
> Relying parties that understand PCs will validate chains with PCs
> because they only do the 3280 validation algorithm starting from the
> EE cert, but a relying party that *does not* understand PCs will do
> the 3280 validation starting from the last PC--causing the
> pathLenConstraint check to fail.
>
> Do I have that right? Seems to be an important protection to me.
>
> I'm assuming the RP is obeying basicConstraints, of course. Yes,
> Peter, I know that's not always true. :)
>
> -- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07HZlvY089975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 10:35:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07HZl52089974; Wed, 7 Jan 2009 10:35:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07HZXpr089958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 7 Jan 2009 10:35:46 -0700 (MST) (envelope-from [email-masked])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1LKcJU-0000s2-T0; Wed, 07 Jan 2009 18:35:31 +0100
From: Simon Josefsson
To: "Timothy J. Miller"
Cc: "ietf-pkix\@imc.org"
Subject: Re: A proxy certificate validation question.
References: <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090107:[email-masked]::94gct28c1G1rIyQa:9LZU
X-Hashcash: 1:22:090107:[email-masked]::gue7fGRPExlwmNeZ:Apvv
Date: Wed, 07 Jan 2009 18:35:26 +0100
In-Reply-To: <[email-masked]> (Timothy J. Miller's message of "Wed, 7 Jan 2009 10:57:35 -0600")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Timothy J. Miller" writes:

> Just to take a break from discussing MD5 for a moment, let me make
> sure I understand the implications of the proxy cert (PC) path
> validation algorithm:
>
> A relying party that does *not* understand PCs will fail to validate a
> chain from root->EE->PC *if and only if* one of the CAs in the chain
> has pathLenConstraint set to a value that exhausts at the EE cert.

Per RFC 3820 the proxyCertInfo extension MUST be marked as critical, and
if I understand RFC 3280 correctly, verifiers MUST reject the
certificate if it encounters a critical extension it does not recognize.
The latter is not reflected in the section 6 path validation algorithm,
as far as I can tell, though, but it is mentioned in section 4.2.

/Simon

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07GwJGY087421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 09:58:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07GwIG8087419; Wed, 7 Jan 2009 09:58:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07Gw7ad087411 for ; Wed, 7 Jan 2009 09:58:18 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n07Gw6er015523 for ; Wed, 7 Jan 2009 11:58:06 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n07Gw66g015518 for ; Wed, 7 Jan 2009 11:58:06 -0500
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 7 Jan 2009 11:58:06 -0500
Message-ID: <[email-masked]>
Date: Wed, 7 Jan 2009 10:57:35 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "[email-masked]"
Subject: A proxy certificate validation question.
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070504020107010801080409"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms070504020107010801080409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Just to take a break from discussing MD5 for a moment, let me make sure
I understand the implications of the proxy cert (PC) path validation
algorithm:

A relying party that does *not* understand PCs will fail to validate a
chain from root->EE->PC *if and only if* one of the CAs in the chain has
pathLenConstraint set to a value that exhausts at the EE cert.

In other words, in order to prevent EEs from issuing PCs to spoof other
EEs, the last CA in a chain can set pathLenConstraint=0. Relying
parties that understand PCs will validate chains with PCs because they
only do the 3280 validation algorithm starting from the EE cert, but a
relying party that *does not* understand PCs will do the 3280 validation
starting from the last PC--causing the pathLenConstraint check to fail.

Do I have that right? Seems to be an important protection to me.

I'm assuming the RP is obeying basicConstraints, of course. Yes, Peter,
I know that's not always true. :)

-- Tim

--------------ms070504020107010801080409
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMDcxNjU3MzVaMCMGCSqGSIb3DQEJBDEWBBQWI+PqieIzcQ0eanPUdQwTsVDk/TBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgJAN74hn/NMX+WhwBjaqUmmCOqM4OnGuZxxgTRdPIqJFyibCXZE+Z4B7/jKe
peNDI/nawe1NOFePTCxn5c+KM8g8VZFAE/09Ww9USzzwZaIu4hNSB2pSFT2s9hnLQafaDchX
25TVsxwHQzvmhJ27nfMUAKK2xU912EPFW6M/8wMVAAAAAAAA
--------------ms070504020107010801080409--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n06E915X004042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 07:09:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n06E91ue004040; Tue, 6 Jan 2009 07:09:01 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n06E8iNh004015; Tue, 6 Jan 2009 07:08:54 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n06E8eNx012872; Tue, 6 Jan 2009 09:08:42 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n06E8dZg012792; Tue, 6 Jan 2009 09:08:39 -0500
Received: from [129.83.200.4] (129.83.200.4) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 6 Jan 2009 09:08:39 -0500
Message-ID: <[email-masked]>
Date: Tue, 6 Jan 2009 08:08:07 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Peter Gutmann
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
References:
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000103090206070301000309"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms000103090206070301000309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:
> "Timothy J. Miller" writes:
>
>> The only reliable way to nuke a trusted cert from Windows is touch management
>> of workstations.
>
> It's worse than that, there is no reliable way to remove trusted certs from
> Windows. See Paul Hoffman's analysis at
> http://www.proper.com/root-cert-problem/.

I've corresponded with Paul about that in the past. Root
auto-installation can be disabled, users can be blocked from installing
roots in both the machine and user store (requires domain GPO, IIRC),
and subjectInfoAccess chasing can be disabled (Vista "feature").

Incomplete answer for general users, yes, but it's there nonetheless.
Presumably if you're touch managing workstations for trust anchor
removal you can verify that these settings are all in place. :)

The roots that shouldn't be removed are the ones needed to boot (i.e.,
validate authenticode signatures). That's more than a few in XP.

-- Tim

--------------ms000103090206070301000309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMDYxNDA4MDdaMCMGCSqGSIb3DQEJBDEWBBSVwyNPDjTW1JWkewjwuwqOgzrNdzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgA+rbTeKDp1QXxK7oj1xFjfCEPxO7OdxC1S2IU4zLkMB733Yk1gLoV7Hk7TC
i80TgdfLJUXt4tg6SXyQnHSJmsskCtH/mh43NyDoK0zBczSgi7VOO2a6NQV2VI19g0vw8SW6
kx3SuvzveDY6klEiVXBXpbdHJHIQ/VwJj5E5NoC/AAAAAAAA
--------------ms000103090206070301000309--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n068iKHT085151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 01:44:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n068iKAJ085150; Tue, 6 Jan 2009 01:44:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n068i7L1085128; Tue, 6 Jan 2009 01:44:19 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7CAC71A20F; Tue, 6 Jan 2009 21:44:06 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXHL334utc-6; Tue, 6 Jan 2009 21:44:06 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 057771A202; Tue, 6 Jan 2009 21:44:00 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 78D7D1BE4002; Tue, 6 Jan 2009 21:43:56 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LK7XY-0004kA-BQ; Tue, 06 Jan 2009 21:43:56 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Tue, 06 Jan 2009 21:43:56 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Timothy J. Miller" writes:

>The only reliable way to nuke a trusted cert from Windows is touch management
>of workstations.

It's worse than that, there is no reliable way to remove trusted certs from
Windows. See Paul Hoffman's analysis at
http://www.proper.com/root-cert-problem/.

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n062uZNV068428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 19:56:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n062uZEf068425; Mon, 5 Jan 2009 19:56:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n062uLeo068402; Mon, 5 Jan 2009 19:56:31 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.16.95.209]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LK26z-0000cO-DW; Mon, 05 Jan 2009 21:56:09 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 5 Jan 2009 21:53:15 -0500
To: "Timothy J. Miller"
From: Stephen Kent
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: Ben Laurie , Santosh Chokhani , Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 8:10 AM -0600 1/5/09, Timothy J. Miller wrote:
>Ben Laurie wrote:
>
>>I am not suggesting that we should fix X.509, I am pointing out, in my
>>own roundabout way, that X.509 certs are supposed to have a canonical
>>form. But it seems they do not.
>
>That was last month's major discussion on PKIX. The upshot: there's
>no canonical form other than what's in memory.
>
>-- Tim

Tim,

Your response is an oversimplification, in several respects.

Ben's comment was a bit ill-formed. It's not that certs in general do
or do not have a canonical form, but whether a given cert has a
canonical representation. If the cert has no extensions, then it
does. If it has extensions, then since the top level extension syntax
is a SEQUENCE, there the order of extensions in that sequence (when
the cert was signed) is definitive. (if that syntax had called for a
SET, then DER encoding would impose an order at this level, so use
of the SEQUENCE construct here make life a bit easier.)

The context in which there is some disagreement is whether an
extension needs to be DER encoded below the next level, where it is
defined as an OCTET string. If one stops at the OCTET string level,
the life is easy and an RP can always encode to DER upon receipt
(since the base cert format IS known by all RPs and they are
technically capable of encoding it in DER).

If one interprets X.509 to require DER for the lower levels of the
structure of a cert extension, then a problem can arise. It was noted
that a non-critical extension (which therefore ought not be rejected
out of hand by an RP) might have a syntax unknown to an RP. Thus the
RP needs to assume that what it received is DER encoded when
computing the signature, as it has no way to recompute the DER.

Steve

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05NJioQ058423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 16:19:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05NJi5L058421; Mon, 5 Jan 2009 16:19:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05NJWTk058399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Jan 2009 16:19:43 -0700 (MST) (envelope-from [email-masked])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n05NJOQL025577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 18:19:25 -0500 (EST)
Date: Mon, 05 Jan 2009 18:19:24 -0500
From: Jeffrey Hutzelman
To: Philipp Guehring , Santosh Chokhani
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Thursday, January 01, 2009 05:01:33 AM +0100 Philipp Guehring
wrote:

>> It should be noted, though, that yanking the trust anchors is not
>> enough. You really should change the relying party to not recognize
>> this algorithm. Otherwise, it's perfectly valid for a CA whose
>> certificate is signed with SHA1 to sign an intermediate CA certificate
>> with MD5 (although they usually don't do that, I hope)
>
> I also thought so, but then I realized that if we invalidate MD5
> completely, then we would also invalidate root certificates that are MD5
> self-signed, which isn't a security issue. So that would give lots of
> unnecessary false-positives.

Except that the validation process doesn't actually need to check the
signature on a "root certificate", because that signature is not part of
the chain.

> I would like to propose the following idea:
>
> We should define a date for expiring MD5 in certificate chains for the
> Internet. I would suggest the 1. June 2009, which is 6 months from now.

Hahahahaha!

If we all agreed, today, that this is the right approach, and the browser
vendors all agreed with us, and they all managed to have updated versions
available, by, say, next week...

It would be after June before anyone even had the new software.

If we're going to propose that browser vendors make a software change, it
should not be to remove MD5 support; it should be to allow configuration of
which signature algorithms are supported, just as they allow configuration
of which TLS ciphersuites are supported.

It certainly should _not_ be to generate a warning every time an MD5
signature is used. All that will do is train users to click away security
warnings without reading them, which they are already quite good at.

-- Jeff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05IFUem027125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 11:15:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05IFU3H027124; Mon, 5 Jan 2009 11:15:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05IFT9q027107 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Mon, 5 Jan 2009 11:15:30 -0700 (MST) (envelope-from [email-masked])
X-IronPort-AV: E=Sophos;i="4.36,332,1228089600"; d="p7s'?scan'208";a="224066225"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2009 18:15:29 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n05IFTwg004793; Mon, 5 Jan 2009 10:15:29 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n05IFTt1024062; Mon, 5 Jan 2009 18:15:29 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 10:15:29 -0800
Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 10:15:28 -0800
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Message-Id: <[email-masked]>
From: David McGrew
To: RJ Atkinson
In-Reply-To:
Content-Type: multipart/signed; boundary=Apple-Mail-28--530943312; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: attacks on keyed-hash constructions [was: Re: [cfrg] Further MD5 breaks: Creating a rogue CA certificate]
Date: Mon, 5 Jan 2009 10:15:26 -0800
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 05 Jan 2009 18:15:28.0611 (UTC) FILETIME=[969C5B30:01C96F61]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5059; t=1231179329; x=1232043329; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20David=20McGrew=20 |Subject:=20attacks=20on=20keyed-hash=20constructions=20[wa s=3A=20Re=3A=20[cfrg]=20Further=20MD5=20breaks=3A=20Creating =20a=20rogue=20CA=20certificate] |Sender:=20; bh=qPhI4WZyZUZj1QJj+mjGuOCPBHDq0ZmCR0YsJEtfVis=; b=jLe9CpwfbLw6qFZiLttqNAHMr3IckcKvlUyuj0O3RSjvj7W+2q0K8ZOsfm i6/sXhyWMPuxWIseEY7CbLm4+1NyhFHB4TZ6C3+eFDZ0FC/ZJ4VwuHnPi5uv rtI8RjGvfhStRo0a+jdc5Ydow8QC76wKUkpfpqtbas/QDxwbVTXZI=;
Authentication-Results: sj-dkim-1; header.From=[email-masked]; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--Apple-Mail-28--530943312
Content-Type: text/plain;
charset=WINDOWS-1252;
format=flowed;
delsp=yes
Content-Transfer-Encoding: quoted-printable

Hi Ran,

On Jan 5, 2009, at 5:26 AM, RJ Atkinson wrote:

>
> On 5 Jan 2009, at 04:57, der Mouse wrote:
>> What I, as an amateur, take away from it is approximately "MD5 is
>> showing more and more cracks and nobody should use it for anything =20=

>> that
>> needs to withstand a malicious adversary".
>
> Within the CA world, many folks here seem to agree.
>
> However, the usage in CAs is rather different from
> some other modes of operation (e.g. Keyed-Hash, HMAC-Hash).
>
> So far, there are no known attacks on those other modes of operation.
> [If someone knows of a refereed paper that's been published
> on those latter topics, please share a citation here.]

I'm not sure what you mean by keyed-hash, but here are some attacks =20
that might be relevant.

[1] B. Preneel and P. van Oorschot, =93MD-x MAC and building fast MACs =20=

from hash
functions,=94 Advances in Cryptology =96 Crypto 95 Proceedings, Lecture =20=

Notes in Computer
Science Vol. 963, D. Coppersmith ed., Springer-Verlag, 1995.

[2] B. Preneel and P. van Oorschot, =93On the security of two MAC =20
algorithms,=94 Advances
in Cryptology =96 Eurocrypt 96 Proceedings, Lecture Notes in Computer =20=

Science Vol. ??,
U. Maurer ed., Springer-Verlag, 1996.

RFC 2385 uses the method broken in Section 4.2 of [1].

HMAC seems to be secure given some reasonable assumptions about the =20
hash functions (namely, that the underlying hash has a compression =20
function that is a PRF - no collision resistance is required); see =
http://eprint.iacr.org/2006/043

>
>
>> These may be the best openly published breaks of MD5 at the moment,
>
> Mind, there are published "serious attacks" [using NIST's words
> from their web site] against SHA-0 and SHA-1 also. Timothy
> Miller seemed to suggest in recent email that perhaps the PKIX WG
> might enhance the CA structure to increase attack resistance in an
> algorithm-independent way.
>
> Now, may I suggest that folks please LOOK AT and possibly
> REDUCE/EDIT the CC line as they reply to this thread going forward.
> Items that are PKIX specific likely belong only on the PKIX
> list. Ditto for SMIME specific issues to the SMIME list.
> That would leave only generic comments for the SAAG list.
>

Done.

David

--Apple-Mail-28--530943312
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDnjCCA5ow
ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE
CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN
AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV
MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER
MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM
5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H
SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY
UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr
IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB
AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS
gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+
SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W
6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V
zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7
mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR
gCmxsHqcL1uMMYIDBDCCAwACAQEwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dyZXcxEzARBgNVBAgM
CkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEfMB0GCSqGSIb3DQEJ
ARYQbWNncmV3QGNpc2NvLmNvbQIBZDAJBgUrDgMCGgUAoIIBZzAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAxMDUxODE1MjdaMCMGCSqGSIb3DQEJBDEWBBSXSan/
gRHaf9+QPHq7m6l0XczZ+DCBgQYJKwYBBAGCNxAEMXQwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dy
ZXcxEzARBgNVBAgMCkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEf
MB0GCSqGSIb3DQEJARYQbWNncmV3QGNpc2NvLmNvbQIBZDCBgwYLKoZIhvcNAQkQAgsxdKByMG0x
FTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMx
ETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMA0G
CSqGSIb3DQEBAQUABIIBABVUvthNkhYllLAjRtmJy0tf+00evlXhRTx0bq+50TyFYSf4aSSGW3m+
wkwhu+lCVdLGUZeyfjyDvTDpEPI2Glol6WHM2P0R0L7bL/IC5ZwYv9NAtLuP1e6jOGFzmN9V+bOG
5W5x5qWUCAkJVVScgH2ZAC7+wU2lmWaZMffDY8MKRhsW4Pwjx7r666Yl5LqjWRXLOMLF495KfgFE
IdHUcM377I/JRTXvLxZeEs0r6K6+oI+5k/syJLiJ2Gg2OiVX7w6HdODcM6cXNHe5OaXjjvAwFD9K
7Ceckf0Hj42TLmvjEkV31AdWlNEhyl6XFkIDnTaSHRtDtOKgN4fZDIUT5hwAAAAAAAA=

--Apple-Mail-28--530943312--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05GnSFA004293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 09:49:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05GnSiv004292; Mon, 5 Jan 2009 09:49:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05GnFVN004252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jan 2009 09:49:27 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n05GnB1w007652 for ; Mon, 5 Jan 2009 11:49:11 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n05Gn4lS011333 for ; Mon, 5 Jan 2009 11:49:05 -0500
Message-ID: <[email-masked]>
Date: Mon, 05 Jan 2009 11:49:04 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.18 (X11/20081120)
MIME-Version: 1.0
To: pkix
Subject: Re: I-D ACTION:draft-ietf-pkix-tac-02.txt
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

All,

I read through the "Traceable Anonymous Certificate" draft and wrote up
some comments with the respect to what I consider to be the most
significant issues in this document. My comments are below.

Dave
------------------------------------------------------------------
Section 1 (Introduction):

- The final paragraph begins:

The conditional traceability offered by this model assumes
strong separation between the RA and CA roles, and employs
technical means (threshold cryptography and "blinded"
signatures), to enforce that separation.

The threshold cryptography and "blinded" signatures do not
enforce separation, as they actually require the RA and CA roles
to work more closely together than if these techniques were not
used. The use of the Token provides a technical means to
*permit* the separation of the RA and CA roles, but does not
enforce it. The TAC protocol cannot prevent the RA and CA from
sharing identity information (either by exchanging the
information in non-TAC messages or by the RA encoding the user's
identity in the UserKey of the Token. A more appropriate
statement would be:

The conditional traceability offered by this model assumes
strong separation between the RA and CA roles, and employs
technical means to facilitate that separation.

Section 3 (Requirements):

- This section begins by stating that the "document describes a
new separation-of-authority model". How does the model in this
document differ from the one in [13], "An Architecture for
Pseudonymous e-Commerce"? What properties does the protocol
in this document have that the protocol in [13] does not?

- The document explains the need to be able to learn the true
identity of the holder of a TAC, but not the need to learn
a user's pseudonym given the user's true identity, yet this
section states that the solution must enable determining the
TAC from the true identity? Why is this a requirement? What
protocol messages support this capability?

Section 5 (Issuing a TAC):

- The protocol involves a complicated scheme involving split
signatures and blind signatures. The use of split signatures
complicates the issuance of both certificates and CRLs, yet
the need for this scheme is not clear. It was previously
argued that the split signature scheme prevents the CA from
issuing a certificate to a user by itself, which could
result in a non-traceable certificate. However, the CA
could still create a non-traceable certificate by simply
not maintaining the link between the TAC and the Token.
An untrustworthy CA could even use a Token issued by the BI
to one user as the basis for issuing a certificate to a
different user. Similarly, a BI could issue a Token to a
user without first identifying that user. Since both the AI
and BI need to cooperate to identify the user associated with
a TAC, there is no benefit in trying to prevent the AI from
issuing a non-traceable certificate, as there is no way to
force the AI (or BI) from cooperating in the tracing of a
certificate if the AI (or BI) simply chooses not the store
the information required to perform the trace.

- The document says that "The reader is referred to [17] and [18]
where procedures for implementing RSA and DSA threshold
signatures are described, respectively." I am assuming that this
text intended to refer to [16], "Two-Party Generation of DSA
Signature", for DSA rather than [18]. However, [16] specifies
protocols that require either 4 or 8 messages, but the protocol
in this paper only allows for a single round trip between the AI
and BI when performing the split signing operation. This seems
to suggest that the current protocol cannot support split
signing using DSA.

- Section 5 says that "Blinding is also defined for signature
algorithms like DSA, but the explanation is more complex, since
DSA does not natively encrypt data." Can a reference be
provided? I can only find references to papers that propose
blinding schemes for variants of DSA.

- Section 5.1, Step 1 states "The signature on a Token is
generated by the BI using a private key employed only for
this purpose." Step 2 states "The signature (SignatureValue
of SignerInfo) is generated using the BI's private signature
key, corresponding to the public key present in the BI's
certificate. (Note that this certificate is just a certificate
suitable for use with TLS, and is NOT the split-key certificate
used to verify a TAC.)" May the BI use the same private key
and certificate to sign Tokens and for TLS authentication? If
not (as stated in Step 1), then why is it necessary for the
certificate corresponding to the Token signing key to be
"suitable for use with TLS"? Many other places in the document
state that certificates used to verify signatures on CMS
messages should be "suitable for use with TLS".

- Section 5.1, Step 2 (and Appendix A) states
"Token ::= SignedData". However, according to Appendix C,
a Token is a CMS message. That is, a Token is a ContentInfo
with a contentType of id-signedData and a content that holds
a SignedData. Writing "Token ::= SignedData" suggests that
there is no ContentInfo wrapper. In order to avoid confusion,
the Token should always include the ContentInfo wrapper.

- Section 5.1, Step 4: Why does the AI need to sign the
Token and BlindedCertificateHash when they are being sent to
the BI over a two-way authenticated secure channel? Even
if CMS is used, that doesn't mean that the content has to be
signed. The CMS message sent by the the AI to the BI could
simply be:

ContentInfo ::= SEQUENCE {
contentType ContentType, -- id-data
content [0] EXPLICIT ANY DEFINED BY contentType }
-- the content is the DER encoded SEQUENCE
-- of the Token and BlindedCertificateHash

- Section 5.1, Step 5: Same as Step 4? Why does the response
need to be signed?

- Section 5.1, Step 6 states:
The AI then "un-blinds" the blindHashValue, using the other
key from the key pair employed Step 4. This reveals the
partially-signed certificate hash. The AI then applies its
part of the split private key to complete the signature of
the certificate for the user.

Has it been verified that this will always yield the correct
result? My guess is that it will for RSA, but I would need
to be convinced that for DSA one could perform the unblinding
operation on a partial signature, then complete the signing
operation, and be guaranteed to get the correct result. The
safer alternative would be for the AI to complete the signing
operation and then perform the unblinding operation. (Since
I have not seen the paper, I am not even certain that a DSA
signature on a blinded hash is performed in the exact same way
as a normal DSA signature. If not, then the split-signing
protocol may not work on a blinded hash.)

- Section 5.1, Step 6 states:
Note that the user should be prepared to accommodate delays
in the certificate issuance process. For example, a
connection between the user and the AI might fail sometime
after the user submits a certificate request at the end of
Step 3 and before the AI returns the certificate at the end
of Step 6. If this happens, the user should resubmit the
request. The AI and BI retain sufficient state to be able to
match the resubmitted request to the original request, and
respond accordingly.

This seem appropriate, but it is contradicted by the following
text in Section 5.1, Step 4:
Next, the AI compares the received Token against a cache of
recent (i.e., not "timed out"), validated Tokens. If a
duplicate is detected, the certificate request is rejected as
a replay.

In addition, only the AI should be able to "match the
resubmitted request to the original request".

- Section 5.2, Step A states that "we propose creating a second
CA, under the TAC CA and have it be the CRL issuer for the EE
certificates issued by the TAC CA." However, the actual
proposal is to create a second (CRL signing only) key for the
CA, not to create a second CA.

- Section 5.2, Step A states that "Each EE TAC certificate MUST
contain a CRLDP that points to the CRL issued by this CA, to
ensure that RPs know to check this CRL vs. the CRL that covers
only the CRL CA." This is not sufficient. If the CRL that is
signed using the CA's split certificate-signing key does not
include an issuingDistributionPoint extension then RPs may
use this CRL to determine the status of any certificates issued
by the CA. So, the self-issued certificate including the CRL
signing key MUST include a CRLDP extension and the corresponding
CRL MUST include an IDP extension to ensure that this CRL will
not be used to verify the status of any other certificates.
Inclusion of a CRLDP in the EE TAC certificates is useful, but
does not ensure that RPs will use the correct CRL.

- Section 5.2, Step A states that "If the AI uses OCSP [14] or
SCVP [15] to convey the revocation status of TACs, an equivalent
procedure is employed." SCVP cannot be used by a CA to convey
status information in the same way that CRLs and OCSP can, and
so it should not be mentioned here.

- Section 5.3.1, Subject begins "If present, ...." The subject
field in CertificationRequestInfo is not OPTIONAL and so must
be present.

- Section 5.3.1, Subject continues with "value of this field
[subject] SHOULD be empty". However, section 5.1, Step 3 says
"The Subject field of the certificate contains a pseudonym
generated by the user." There is no suggestion in section 5.1,
Step 3 that the user may leave the subject field empty rather
than including a proposed pseudonym for the subject name. These
two sections should be made consistent.

- Section 5.3.1, Attributes: "This attribute contains
X509v3 Certificate Extensions." Which attribute? Not the
id-kisa-tac attribute mentioned in the previous sentence? Is
inclusion of extension in the PKCS10 optional or are there
certain extensions that must be included?

- Section 5.3.1 says:
This profile applies the following additional constraints to
fields that MAY appear in a CertificationRequest Object:

signatureAlgorithm
This field specifies the signature algorithm.

What does this mean? The signatureAlgorithm is mandatory and
this text does not impose any constraints on the field.

- Section 5.3.2, Subject: "If present, the value of this
field SHOULD be empty, ...." As with Section 5.3.1, this text
need to be consistent with section 5.1.

- Section 5.3.2, Extensions: Is inclusion of extension optional
or are there certain extensions that must be included?

General:

- In many places in the document seem to include the wrong
references. For example, Section 5 refers to [18] for
implementing threshold signatures using DSA rather than [16].

- The protocol messages defined in this document all use the
same basic format: a CMS signed data object. For all of these
messages, the eContentType is specified as id-data and
(presumably) the MIME type is application/pkcs7-mime, perhaps
with the parameter smime-type=signed-data. Each of the
protocol messages should have its own MIME type and/or
eContentType. Otherwise, there is no way for the recipient to
know how to process the data.

- Referring to the certificates issued using this protocol as
anonymous rather than pseudonymous is confusing. The editors
note in the Introduction that pseudonymous is the correct term,
but still choose to use the misleading term "anonymous". I do
not agree that the terms are commonly used interchangeably, and
believe that the use of the correct term, pseudonymous, would
make the privacy properties of the certificates more clear.
People already understand the idea of using different names
(pseudonyms) in different contexts in order to increase privacy.
Anonymity is achieved by not identifying (authenticating)
oneself at all, not by identifying oneself using a pseudonym.

- The protocol should allow for the possibility of rekey. In many
cases, users will want to use the same pseudonym for an
extended period of time. For example, many people use a
pseudonym when posting to message boards or when selling items
on-line (e.g., on eBay). People who earn good reputations as
sellers would not want to have to periodically change
pseudonyms. A TAC for these users would allow them perform
strong authentication to prevent others from accessing their
accounts. The TAC would allow the sellers to keep their true
identities a secret while at the same time reassuring buyers
that sellers' true identities could be determined in case a
seller committed fraud. While this type of scenario may not
have been the original motivation for TAC, is there any reason
that it should not be supported?

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05Eet30096015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 07:40:55 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05EetH8096014; Mon, 5 Jan 2009 07:40:55 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05Eermp096000; Mon, 5 Jan 2009 07:40:53 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EepRd014015; Mon, 5 Jan 2009 09:40:52 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EepET013978; Mon, 5 Jan 2009 09:40:51 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 5 Jan 2009 09:40:51 -0500
Message-ID: <[email-masked]>
Date: Mon, 5 Jan 2009 08:40:20 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Yoav Nir
CC: Robert Moskowitz , Peter Hesse , "[email-masked]" , "'Mike'" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070001040001010905020508"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms070001040001010905020508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yoav Nir wrote:

>> This sounds great at an IETF mike, but out in the field how do you
>> get all those millions of browsers to pull down a new trust list
>> that will no longer include CA foobar?

>> Can't happen now, and the way things are going, ain't going to
>> happen before 2026 either.

> There's this one company such that if they use Windows update to
> update their browsers, the others will follow. Technically, it's very
> easy to get rid of the bad CAs. However, that company is not going to
> modify their browsers, not now, probably not in the next few years.

I hate to burst your bubble, but there's no automated way to *remove*
certs from the MS cert store. You have to script it, and the script can
fail any number of different ways.

The only reliable way to nuke a trusted cert from Windows is touch
management of workstations.

-- Tim

--------------ms070001040001010905020508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMDUxNDQwMjBaMCMGCSqGSIb3DQEJBDEWBBQSPC3dPpk05tig2GinEiQq/mA0sDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgCWU5pWSQ26W1GWOS1O6u2maERpV1SaNQz8CO2ZgJOiaEVaMd+PWQW5X085o
VdD79oEPRc7V/Ow7Ti/y160IXe2663qiEpPLRmHwUBBu65OLBPI7cOE7l88IP6qyat8ct7XX
/Jy6tYLuFBDyyiCYutOesjuQK8B5J8QZhwLlDonwAAAAAAAA
--------------ms070001040001010905020508--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05EBYFx094112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 07:11:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05EBYnQ094110; Mon, 5 Jan 2009 07:11:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05EBMi0094084; Mon, 5 Jan 2009 07:11:32 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EBLrJ024501; Mon, 5 Jan 2009 09:11:21 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n05EBK0m024486; Mon, 5 Jan 2009 09:11:20 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 5 Jan 2009 09:11:20 -0500
Message-ID: <[email-masked]>
Date: Mon, 5 Jan 2009 08:10:49 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Ben Laurie
CC: Santosh Chokhani , Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030202050805090401080206"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--------------ms030202050805090401080206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:

> I am not suggesting that we should fix X.509, I am pointing out, in my
> own roundabout way, that X.509 certs are supposed to have a canonical
> form. But it seems they do not.

That was last month's major discussion on PKIX. The upshot: there's no
canonical form other than what's in memory.

-- Tim

--------------ms030202050805090401080206
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTAxMDUxNDEwNDlaMCMGCSqGSIb3DQEJBDEWBBSDPQhbY26jaDdUKPOtB4gReiXvRTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgC2068jNlWSn64YcsvU04REhtJnMOZYhx6rrMPrjFmoq7bvNJ2vIBA91zWAz
ypaQhqHqYODjapnJ1CwHoHts1Ff/A0jeBcqdWUMEZFnkJCtZwGruMClZJwLiHeYdzBueizld
FQYycjbD+jNX17S8GB288wkFDYJzInkII3V6qwgtAAAAAAAA
--------------ms030202050805090401080206--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05DRKO7091712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 06:27:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05DRKX6091710; Mon, 5 Jan 2009 06:27:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05DR8ke091693; Mon, 5 Jan 2009 06:27:19 -0700 (MST) (envelope-from [email-masked])
Received: from [10.30.20.71] ([70.104.193.39]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <[email-masked]>; Mon, 05 Jan 2009 07:26:57 -0600 (CST)
Date: Mon, 05 Jan 2009 08:26:52 -0500
From: RJ Atkinson
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
In-reply-to: <[email-masked]>
To: der Mouse
Cc: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Message-id:
MIME-version: 1.0 (Apple Message framework v930.3)
X-Mailer: Apple Mail (2.930.3)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7bit
References: <[email-masked]> <[email-masked]> <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On 5 Jan 2009, at 04:57, der Mouse wrote:
> What I, as an amateur, take away from it is approximately "MD5 is
> showing more and more cracks and nobody should use it for anything
> that
> needs to withstand a malicious adversary".

Within the CA world, many folks here seem to agree.

However, the usage in CAs is rather different from
some other modes of operation (e.g. Keyed-Hash, HMAC-Hash).

So far, there are no known attacks on those other modes of operation.
[If someone knows of a refereed paper that's been published
on those latter topics, please share a citation here.]

> These may be the best openly published breaks of MD5 at the moment,

Mind, there are published "serious attacks" [using NIST's words
from their web site] against SHA-0 and SHA-1 also. Timothy
Miller seemed to suggest in recent email that perhaps the PKIX WG
might enhance the CA structure to increase attack resistance in an
algorithm-independent way.

Now, may I suggest that folks please LOOK AT and possibly
REDUCE/EDIT the CC line as they reply to this thread going forward.
Items that are PKIX specific likely belong only on the PKIX
list. Ditto for SMIME specific issues to the SMIME list.
That would leave only generic comments for the SAAG list.

Cheers,

Ran

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n057kQg6073937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 00:46:26 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n057kQ7o073936; Mon, 5 Jan 2009 00:46:26 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n057kOq2073915; Mon, 5 Jan 2009 00:46:24 -0700 (MST) (envelope-from [email-masked])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F169929C002; Mon, 5 Jan 2009 09:46:23 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1F4D629C001; Mon, 5 Jan 2009 09:46:23 +0200 (IST)
X-CheckPoint: {4961B8EC-10000-88241DC2-7B6}
Received: from gilg-7800.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n057kMfE028615; Mon, 5 Jan 2009 09:46:22 +0200 (IST)
Cc: Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked]
Message-Id:
From: Yoav Nir
To: "B.M.M. de Weger"
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Mon, 5 Jan 2009 09:46:21 +0200
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Oh, OK. I got it now. Eek.

On Jan 5, 2009, at 9:37 AM, Yoav Nir wrote:

> OK. Now I'm a lot confused :-)
>
> On Jan 5, 2009, at 12:02 AM, Weger, B.M.M. de wrote:
>
>> Hi Paul,
>>
>>>>> Just to repeat it one more time: #3 does not prevent the
>>> published attack.
>>>>
>>>> It does if the random fluff is inserted by the CA. The
>>> attack depends on their ability to predict the entire TBS part.
>>>
>>> I may have misunderstood the paper, but I think that changes
>>> after the subjectPublicKeyInfo do not affect the attack.
>>
>> Almost correct. A random looking "collision block" has to be inserted
>> somewhere. We chose to insert it in the public key, as that seems
>> the most convenient. Somebody else may find another place where
>> it can be hidden (maybe in a "subject key identifier" field or
>> something,
>> I don't know what would be feasible). Everything after the "collision
>> block" must be copied bitwise into the twin certificate, and must be
>> 'harmless' there. If 'random fluff' is inserted by the CA after the
>> "collision block", this 'random fluff' can be copied into the twin
>> certificate as well, retaining the collision property, and this
>> would indeed be irrelevant to our attack.
>
> If you inserted a random looking collision block in the public key,
> how did your signature on the PKCS#10 request verify?
>
>>
>>
>>>> Also, I've updated today and all the "bad" CAs with MD5
>>> signatures are still in the TAS.
>>>
>>> As was pointed out to me earlier: it does not matter if the
>>> CA has its cert signed with MD5, only whether that CA *signs*
>>> with MD5. RapidSSL, for example, is still signed with MD5 but
>>> is now signing with SHA-1.
>>
>> Correct.
>
> Sure, but the other authorities that signed with MD5 (no idea if
> they've changed their evil ways) are still there.
>

Email secured by Check Point

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n057bqtX073694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 00:37:52 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n057bqVN073692; Mon, 5 Jan 2009 00:37:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n057bdmS073671; Mon, 5 Jan 2009 00:37:50 -0700 (MST) (envelope-from [email-masked])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 42E2D29C003; Mon, 5 Jan 2009 09:37:38 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A8C0129C001; Mon, 5 Jan 2009 09:37:12 +0200 (IST)
X-CheckPoint: {4961B6C6-10000-88241DC2-7B6}
Received: from shiramnew.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n057bCfE026492; Mon, 5 Jan 2009 09:37:12 +0200 (IST)
Cc: Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Message-Id: <[email-masked]>
From: Yoav Nir
To: "Weger, B.M.M. de"
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Mon, 5 Jan 2009 09:37:11 +0200
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

OK. Now I'm a lot confused :-)

On Jan 5, 2009, at 12:02 AM, Weger, B.M.M. de wrote:

> Hi Paul,
>
>>>> Just to repeat it one more time: #3 does not prevent the
>> published attack.
>>>
>>> It does if the random fluff is inserted by the CA. The
>> attack depends on their ability to predict the entire TBS part.
>>
>> I may have misunderstood the paper, but I think that changes
>> after the subjectPublicKeyInfo do not affect the attack.
>
> Almost correct. A random looking "collision block" has to be inserted
> somewhere. We chose to insert it in the public key, as that seems
> the most convenient. Somebody else may find another place where
> it can be hidden (maybe in a "subject key identifier" field or
> something,
> I don't know what would be feasible). Everything after the "collision
> block" must be copied bitwise into the twin certificate, and must be
> 'harmless' there. If 'random fluff' is inserted by the CA after the
> "collision block", this 'random fluff' can be copied into the twin
> certificate as well, retaining the collision property, and this
> would indeed be irrelevant to our attack.

If you inserted a random looking collision block in the public key,
how did your signature on the PKCS#10 request verify?

>
>
>>> Also, I've updated today and all the "bad" CAs with MD5
>> signatures are still in the TAS.
>>
>> As was pointed out to me earlier: it does not matter if the
>> CA has its cert signed with MD5, only whether that CA *signs*
>> with MD5. RapidSSL, for example, is still signed with MD5 but
>> is now signing with SHA-1.
>
> Correct.

Sure, but the other authorities that signed with MD5 (no idea if
they've changed their evil ways) are still there.

Email secured by Check Point

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04MYZfN055364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 15:34:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n04MYZb4055362; Sun, 4 Jan 2009 15:34:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n04MYN4s055336 for ; Sun, 4 Jan 2009 15:34:33 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 6928 invoked from network); 4 Jan 2009 22:34:40 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;04 Jan 2009 22:34:40 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 4 Jan 2009 22:34:40 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Sun, 4 Jan 2009 17:34:21 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclurKoRqf7W7I+NT92pGLSCmb5SbAAD7uUg
References: <[email-masked]> <[email-masked]><[email-masked]>
From: "Santosh Chokhani"
To: "Paul Hoffman" , "Yoav Nir"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I agree with Paul.

Unless the Length of TBD certificate as part of DER is made
unpredictable, any values on extensions just go in the tumor.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Hoffman
Sent: Sunday, January 04, 2009 3:40 PM
To: Yoav Nir
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

At 10:23 PM +0200 1/4/09, Yoav Nir wrote:
>On Jan 4, 2009, at 9:11 PM, Paul Hoffman wrote:
>
>>At 9:02 AM +0200 1/4/09, Yoav Nir wrote:
>>>Best we can do is to get the CAs to
>>>
>>>(1) not issue MD5 certs anymore and
>>>(2) randomize the serial number and/or
>>>(3) and a random fluff extension that people are talking about
>>
>>Just to repeat it one more time: #3 does not prevent the published
attack.
>
>It does if the random fluff is inserted by the CA. The attack depends
on their ability to predict the entire TBS part.

I may have misunderstood the paper, but I think that changes after the
subjectPublicKeyInfo do not affect the attack.

>>>But still, I don't see Microsoft removing a root CA because one of
their sub-CAs is issuing non-compliant certificates.
>>
>>It is hard to see Microsoft removing or adding CAs. If anyone knows of
a public interface (mailing list, web site, whatever) for when this
happens, by all means please the world know.
>
>I managed to find a page with their policy on adding new root CAs.
Nothing there about removing old root CAs.

I'm not talking about the policy: I'm talking about the actual trust
anchors themselves.

>>>And if Microsoft don't, nobody else will. The
Firefox/Opera/Safari/Chrome people don't want any sites that "only work
with Explorer".
>>
>>At least with respect to Firefox, I think that statement is false.
>
>They've done quite a bit to render broken sites that were made for IE.

That is irrelevant for this thread. There are active discussions in the
Firefox community about adding and removing trust anchors that are and
are not already in the IE trust anchor pile.

>Also, I've updated today and all the "bad" CAs with MD5 signatures are
still in the TAS.

As was pointed out to me earlier: it does not matter if the CA has its
cert signed with MD5, only whether that CA *signs* with MD5. RapidSSL,
for example, is still signed with MD5 but is now signing with SHA-1.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04MUS5K055194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 15:30:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n04MUSaR055193; Sun, 4 Jan 2009 15:30:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04MUGmm055177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jan 2009 15:30:27 -0700 (MST) (envelope-from [email-masked])
Received: from [172.16.209.63] (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n04MTvn9029995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 17:29:58 -0500 (EST)
Date: Sun, 04 Jan 2009 17:29:57 -0500
From: Jeffrey Hutzelman
To: Yoav Nir , Paul Hoffman
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--On Sunday, January 04, 2009 10:23:58 PM +0200 Yoav Nir
wrote:

> On Jan 4, 2009, at 9:11 PM, Paul Hoffman wrote:
>
>> At 9:02 AM +0200 1/4/09, Yoav Nir wrote:
>>> Best we can do is to get the CAs to
>>>
>>> (1) not issue MD5 certs anymore and
>>> (2) randomize the serial number and/or
>>> (3) and a random fluff extension that people are talking about
>>
>> Just to repeat it one more time: #3 does not prevent the published
>> attack.
>
> It does if the random fluff is inserted by the CA. The attack depends on
> their ability to predict the entire TBS part.

No, it does not. It depends on their ability to predict that portion of
the TBS part which occurs prior to the computed collision blocks, which in
the real certificate occur in the subject public key modulus. The portion
of the TBS part which occurs after the collision blocks does not need to be
predictable; they just need to be able to copy it as-is, which is done by
copying the collision blocks, the rest of the original subject public key
modulus, and all of the original certificate's extensions into a netscape
comment extension in the forged certificate.

>>> And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/
>>> Chrome people don't want any sites that "only work with Explorer".
>>
>> At least with respect to Firefox, I think that statement is false.
>
> They've done quite a bit to render broken sites that were made for IE.
> Also, I've updated today and all the "bad" CAs with MD5 signatures are
> still in the TAS.

Again, there is nothing "bad" about CA certifiates with MD5 signatures.
The signature on a root certificate is not used for anything, and in
practice is not an accurate predictor of what algorithms that CA uses to
sign certificates.

-- Jeffrey T. Hutzelman (N3NHS)
Carnegie Mellon University - Pittsburgh, PA

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04M2SZs054049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 15:02:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n04M2SpZ054047; Sun, 4 Jan 2009 15:02:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04M2Gu9054027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 15:02:27 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by mailhost.tue.nl (Postfix) with ESMTP id 01BC45C005; Sun, 4 Jan 2009 23:02:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at tue.nl
Received: from mailhost.tue.nl ([131.155.2.19]) by localhost (pastinakel.tue.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHJqCkviIVtX; Sun, 4 Jan 2009 23:02:14 +0100 (CET)
Received: from EXCHANGE5.campus.tue.nl (xserver6.campus.tue.nl [131.155.6.9]) by mailhost.tue.nl (Postfix) with ESMTP id BACDA5C002; Sun, 4 Jan 2009 23:02:14 +0100 (CET)
Received: from webmail11.campus.tue.nl ([131.155.6.51]) by EXCHANGE5.campus.tue.nl with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Jan 2009 23:02:14 +0100
Received: from EXCHANGE11.campus.tue.nl ([131.155.6.30]) by webmail11.campus.tue.nl ([131.155.6.51]) with mapi; Sun, 4 Jan 2009 23:02:14 +0100
From: "Weger, B.M.M. de"
To: Paul Hoffman , Yoav Nir
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Date: Sun, 4 Jan 2009 23:02:36 +0100
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclurK43+Y7mFmYNToKiFNQb0Pgg2QAChf2w
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: nl-NL, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2009 22:02:14.0620 (UTC) FILETIME=[1A02D1C0:01C96EB8]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Paul,

> >>Just to repeat it one more time: #3 does not prevent the=20
> published attack.
> >
> >It does if the random fluff is inserted by the CA. The=20
> attack depends on their ability to predict the entire TBS part.
>=20
> I may have misunderstood the paper, but I think that changes=20
> after the subjectPublicKeyInfo do not affect the attack.

Almost correct. A random looking "collision block" has to be inserted
somewhere. We chose to insert it in the public key, as that seems
the most convenient. Somebody else may find another place where
it can be hidden (maybe in a "subject key identifier" field or something,
I don't know what would be feasible). Everything after the "collision
block" must be copied bitwise into the twin certificate, and must be
'harmless' there. If 'random fluff' is inserted by the CA after the
"collision block", this 'random fluff' can be copied into the twin=20
certificate as well, retaining the collision property, and this
would indeed be irrelevant to our attack.

> >Also, I've updated today and all the "bad" CAs with MD5=20
> signatures are still in the TAS.
>=20
> As was pointed out to me earlier: it does not matter if the=20
> CA has its cert signed with MD5, only whether that CA *signs*=20
> with MD5. RapidSSL, for example, is still signed with MD5 but=20
> is now signing with SHA-1.

Correct.

Grtz,
Benne de Weger

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04KeJ8X050768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 13:40:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n04KeJV1050765; Sun, 4 Jan 2009 13:40:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04KeBuF050753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 13:40:13 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Sun, 4 Jan 2009 12:40:10 -0800
To: Yoav Nir
From: Paul Hoffman
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 10:23 PM +0200 1/4/09, Yoav Nir wrote:
>On Jan 4, 2009, at 9:11 PM, Paul Hoffman wrote:
>
>>At 9:02 AM +0200 1/4/09, Yoav Nir wrote:
>>>Best we can do is to get the CAs to
>>>
>>>(1) not issue MD5 certs anymore and
>>>(2) randomize the serial number and/or
>>>(3) and a random fluff extension that people are talking about
>>
>>Just to repeat it one more time: #3 does not prevent the published attack.
>
>It does if the random fluff is inserted by the CA. The attack depends on their ability to predict the entire TBS part.

I may have misunderstood the paper, but I think that changes after the subjectPublicKeyInfo do not affect the attack.

>>>But still, I don't see Microsoft removing a root CA because one of their sub-CAs is issuing non-compliant certificates.
>>
>>It is hard to see Microsoft removing or adding CAs. If anyone knows of a public interface (mailing list, web site, whatever) for when this happens, by all means please the world know.
>
>I managed to find a page with their policy on adding new root CAs. Nothing there about removing old root CAs.

I'm not talking about the policy: I'm talking about the actual trust anchors themselves.

>>>And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/Chrome people don't want any sites that "only work with Explorer".
>>
>>At least with respect to Firefox, I think that statement is false.
>
>They've done quite a bit to render broken sites that were made for IE.

That is irrelevant for this thread. There are active discussions in the Firefox community about adding and removing trust anchors that are and are not already in the IE trust anchor pile.

>Also, I've updated today and all the "bad" CAs with MD5 signatures are still in the TAS.

As was pointed out to me earlier: it does not matter if the CA has its cert signed with MD5, only whether that CA *signs* with MD5. RapidSSL, for example, is still signed with MD5 but is now signing with SHA-1.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04KObwP050324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 13:24:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n04KObeT050322; Sun, 4 Jan 2009 13:24:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04KOPJl050304; Sun, 4 Jan 2009 13:24:36 -0700 (MST) (envelope-from [email-masked])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 163CA29C002; Sun, 4 Jan 2009 22:24:25 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3510F29C001; Sun, 4 Jan 2009 22:24:03 +0200 (IST)
X-CheckPoint: {49611904-10000-88241DC2-7B6}
Received: from [172.31.21.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n04KNwfE013740; Sun, 4 Jan 2009 22:23:59 +0200 (IST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Message-Id:
From: Yoav Nir
To: Paul Hoffman
In-Reply-To:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Date: Sun, 4 Jan 2009 22:23:58 +0200
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Jan 4, 2009, at 9:11 PM, Paul Hoffman wrote:

> At 9:02 AM +0200 1/4/09, Yoav Nir wrote:
>> Best we can do is to get the CAs to
>>
>> (1) not issue MD5 certs anymore and
>> (2) randomize the serial number and/or
>> (3) and a random fluff extension that people are talking about
>
> Just to repeat it one more time: #3 does not prevent the published
> attack.

It does if the random fluff is inserted by the CA. The attack depends
on their ability to predict the entire TBS part.

>> But still, I don't see Microsoft removing a root CA because one of
>> their sub-CAs is issuing non-compliant certificates.
>
> It is hard to see Microsoft removing or adding CAs. If anyone knows
> of a public interface (mailing list, web site, whatever) for when
> this happens, by all means please the world know.

I managed to find a page with their policy on adding new root CAs.
Nothing there about removing old root CAs.

>> And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/
>> Chrome people don't want any sites that "only work with Explorer".
>
> At least with respect to Firefox, I think that statement is false.

They've done quite a bit to render broken sites that were made for IE.
Also, I've updated today and all the "bad" CAs with MD5 signatures are
still in the TAS.

Email secured by Check Point

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04JBJn3047546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 12:11:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n04JBJ8T047545; Sun, 4 Jan 2009 12:11:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n04JBA90047521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 12:11:11 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Sun, 4 Jan 2009 11:11:09 -0800
To: Yoav Nir
From: Paul Hoffman
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 9:02 AM +0200 1/4/09, Yoav Nir wrote:
>Best we can do is to get the CAs to
>
>(1) not issue MD5 certs anymore and
>(2) randomize the serial number and/or
>(3) and a random fluff extension that people are talking about

Just to repeat it one more time: #3 does not prevent the published attack.

>But still, I don't see Microsoft removing a root CA because one of their sub-CAs is issuing non-compliant certificates.

It is hard to see Microsoft removing or adding CAs. If anyone knows of a public interface (mailing list, web site, whatever) for when this happens, by all means please the world know.

>And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/Chrome people don't want any sites that "only work with Explorer".

At least with respect to Firefox, I think that statement is false.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n047TuiL021247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 00:29:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n047TuQ5021246; Sun, 4 Jan 2009 00:29:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n047TiJe021226; Sun, 4 Jan 2009 00:29:55 -0700 (MST) (envelope-from [email-masked])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4FBC5200DFE; Sun, 4 Jan 2009 09:29:43 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9F8852004D6; Sun, 4 Jan 2009 09:29:18 +0200 (IST)
X-CheckPoint: {49606375-10000-88241DC2-7B6}
Received: from owoloch-x32.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n047TIfE017615; Sun, 4 Jan 2009 09:29:18 +0200 (IST)
Cc: Peter Hesse , [email-masked], "'Mike'" , [email-masked], [email-masked], [email-masked]
Message-Id: <[email-masked]>
From: Yoav Nir
To: Robert Moskowitz
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Date: Sun, 4 Jan 2009 09:02:00 +0200
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Jan 2, 2009, at 5:35 PM, Robert Moskowitz wrote:

>> Since MD5 is known bad and potentially dangerous at this point, I
>> would
>> suggest that the best client side action would be to fail to verify
>> any
>> signatures created using MD5. This will break some things,
>> especially if
>> existing business processes are relying on a certificate signed
>> with MD5.
>> However, it is a fail-safe and would prevent a rogue CA certificate
>> created
>> in this fashion from being considered trustworthy.
>>
>> And to Santosh's point (and others), my earlier email about
>> removing/replacing trust anchors was not because the self-signed
>> certificates are signed using MD5; I agree the trust anchor public
>> keys are
>> protected using other mechanisms. I am recommending that if CAs do
>> nothing
>> to prevent this kind of attack (non-random serial numbers, issue
>> certificates signed with MD5, issue certificates in an automated,
>> predictable fashion) that those CAs should be removed from trust
>> lists
>> because they are no longer acting in the interest of the relying
>> party--they
>> are an accomplice to the creation of these rogue certificates.
> Peter,
>
> This sounds great at an IETF mike, but out in the field how do you
> get all those millions of browsers to pull down a new trust list
> that will no longer include CA foobar?
>
> Can't happen now, and the way things are going, ain't going to
> happen before 2026 either.

There's this one company such that if they use Windows update to
update their browsers, the others will follow. Technically, it's very
easy to get rid of the bad CAs. However, that company is not going to
modify their browsers, not now, probably not in the next few years.

> So what tool do we have to get compliance to best practices? The
> good old 5th estate, get out their and give bad press to foobar
> until they fix their behaviour or their business model collapses and
> they go out of business and can no longer issue potentially rogue
> certs.

I don't think you can get a message like that across. This story
evokes more of the "Wow! Clever hackers with 200 playstations"
sentiment, not the "criminal negligence" sentiment. You can't get the
media angry with a company unless the negligence causes something
spectacular, like an exploding Ford Pinto. Even Jesse Walker's "unsafe
at any keylength" article didn't have quite the impact of the
original. And people still use WEP.

> We can talk and posture all we want in the IETF. We are rather good
> at that, IMNSHO. But this is perfect proof of our impact as such on
> the business model of companies that use our technology; they will
> do what is expedient, not what is Best Practices.

Best we can do is to get the CAs to

(1) not issue MD5 certs anymore and
(2) randomize the serial number and/or
(3) and a random fluff extension that people are talking about

But still, I don't see Microsoft removing a root CA because one of
their sub-CAs is issuing non-compliant certificates.

And if Microsoft don't, nobody else will. The Firefox/Opera/Safari/
Chrome people don't want any sites that "only work with Explorer".

Email secured by Check Point

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n02Fagja036839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2009 08:36:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n02Fagcq036837; Fri, 2 Jan 2009 08:36:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [208.83.67.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n02FaUmS036815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2009 08:36:41 -0700 (MST) (envelope-from [email-masked])
Received: from z9m9z.htt-consult.com (localhost.localdomain [127.0.0.1]) by z9m9z.htt-consult.com (8.13.8/8.13.8) with ESMTP id n02FZsW3016664; Fri, 2 Jan 2009 10:35:54 -0500
Received: from nc2400.htt-consult.com (onlo.htt-consult.com [208.83.67.148]) by z9m9z.htt-consult.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Fri, 02 Jan 2009 10:35:43 -0500 (EST)
Date: Fri, 2 Jan 2009 10:35:34 -0500
From: Robert Moskowitz
To: Peter Hesse
cc: "'Mike'" , [email-masked], [email-masked], [email-masked], [email-masked]
Message-ID: <[email-masked]>
In-Reply-To: <0c6f01c96ce8$2c13d700$843b8500$@com>
References: <[email-masked]>
References:
References: <[email-masked]>
References:
References: <[email-masked]>
References: <0c6f01c96ce8$2c13d700$843b8500$@com>
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
x-scalix-Hops: 1
User-Agent: Thunderbird 2.0.0.18 (X11/20081120)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.4
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on z9m9z.htt-consult.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter Hesse wrote:
>> Is there anything that could be added to RP software to reliably
>> detect and thwart the use of a rogue CA certificate? Or would
>> any attempt to do that just cause too many problems?
>>
>
> Since MD5 is known bad and potentially dangerous at this point, I would
> suggest that the best client side action would be to fail to verify any
> signatures created using MD5. This will break some things, especially if
> existing business processes are relying on a certificate signed with MD5.
> However, it is a fail-safe and would prevent a rogue CA certificate created
> in this fashion from being considered trustworthy.
>
> And to Santosh's point (and others), my earlier email about
> removing/replacing trust anchors was not because the self-signed
> certificates are signed using MD5; I agree the trust anchor public keys are
> protected using other mechanisms. I am recommending that if CAs do nothing
> to prevent this kind of attack (non-random serial numbers, issue
> certificates signed with MD5, issue certificates in an automated,
> predictable fashion) that those CAs should be removed from trust lists
> because they are no longer acting in the interest of the relying party--they
> are an accomplice to the creation of these rogue certificates.
Peter,

This sounds great at an IETF mike, but out in the field how do you get
all those millions of browsers to pull down a new trust list that will
no longer include CA foobar?

Can't happen now, and the way things are going, ain't going to happen
before 2026 either.

So what tool do we have to get compliance to best practices? The good
old 5th estate, get out their and give bad press to foobar until they
fix their behaviour or their business model collapses and they go out of
business and can no longer issue potentially rogue certs.

We can talk and posture all we want in the IETF. We are rather good at
that, IMNSHO. But this is perfect proof of our impact as such on the
business model of companies that use our technology; they will do what
is expedient, not what is Best Practices.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n02FTVnF036615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2009 08:29:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n02FTVW0036613; Fri, 2 Jan 2009 08:29:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n02FTTS4036606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Jan 2009 08:29:30 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n02FTPR4028301 for ; Fri, 2 Jan 2009 10:29:25 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n02FTChU025337 for ; Fri, 2 Jan 2009 10:29:13 -0500
Message-ID: <[email-masked]>
Date: Fri, 02 Jan 2009 10:29:12 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.18 (X11/20081120)
MIME-Version: 1.0
To: pkix
Subject: ordering of extensions (was Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate)
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I suppose that the real question is not whether DER is being used
correctly, but whether Extensions should have been defined as "SET OF
Extension" rather than "SEQUENCE OF Extension".

While to the best of my knowledge, for all extensions that have been
defined so far (and likely for any extensions that may be defined in the
future), Paul is correct that extensions may be placed in the SEQUENCE
in any order and the order in which extensions appear in the extensions
SEQUENCE has no effect on their meaning,X.509 says that this does not
have to be the case. Clause 7 of X.509 says:

For those extensions where ordering of individual extensions
within the
SEQUENCE is significant, the specification of those individual
extensions
shall include the rules for the significance of the order therein.

I hope that no one will ever define an extension with a specification
that places a significance on the ordering of extensions within the
SEQUENCE, but X.509 would allow for that to happen.

Dave

Ben Laurie wrote:
> Paul Hoffman wrote:
>
>> At 3:06 PM +0000 1/1/09, Ben Laurie wrote:
>>
>>> Surely the whole point of DER is that there's only one correct way to
>>> encode any particular certificate?
>>>
>> Not so "surely". The SEQUENCE for extensions does not say what order they should be in.
>>
>
> That doesn't change the _point_ of DER. If extensions should have been
> specified as a SET but are defined as a SEQUENCE, then they are broken
> (technically).
>
>
>>> So, either extensions must be sorted, or changing their order changes
>>> their meaning. Either way, nothing can be reordered.
>>>
>> Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order.
>>
>
> My point was about the correct use of DER. It seems extensions use it
> incorrectly.
>
>
>> However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper.
>>
>
> I am discussing the correct use of DER :-)
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n02EfV8L034477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2009 07:41:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n02EfVbR034474; Fri, 2 Jan 2009 07:41:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n02EfJ06034457; Fri, 2 Jan 2009 07:41:30 -0700 (MST) (envelope-from [email-masked])
Received: from PeterVistaSP1 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTPSA id CBF81A2746; Fri, 2 Jan 2009 14:41:17 +0000 (GMT)
From: "Peter Hesse"
To: "'Mike'" ,
Cc: , ,
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Fri, 2 Jan 2009 09:41:15 -0500
Message-ID: <0c6f01c96ce8$2c13d700$843b8500$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AclsKjT6Oz0PcIiFQN+3Ed6VEEQeYAAvNWMA
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> Is there anything that could be added to RP software to reliably
> detect and thwart the use of a rogue CA certificate? Or would
> any attempt to do that just cause too many problems?

Since MD5 is known bad and potentially dangerous at this point, I would
suggest that the best client side action would be to fail to verify any
signatures created using MD5. This will break some things, especially if
existing business processes are relying on a certificate signed with MD5.
However, it is a fail-safe and would prevent a rogue CA certificate created
in this fashion from being considered trustworthy.

And to Santosh's point (and others), my earlier email about
removing/replacing trust anchors was not because the self-signed
certificates are signed using MD5; I agree the trust anchor public keys are
protected using other mechanisms. I am recommending that if CAs do nothing
to prevent this kind of attack (non-random serial numbers, issue
certificates signed with MD5, issue certificates in an automated,
predictable fashion) that those CAs should be removed from trust lists
because they are no longer acting in the interest of the relying party--they
are an accomplice to the creation of these rogue certificates.

--Peter

----------------------------------------------------------------
Peter Hesse [email-masked]
http://securitymusings.com http://geminisecurity.com

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01JrJHP095776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 12:53:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01JrJHW095775; Thu, 1 Jan 2009 12:53:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from helios.bolet.org (helios.bolet.org [88.191.25.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01Jr8sI095757 for ; Thu, 1 Jan 2009 12:53:19 -0700 (MST) (envelope-from [email-masked])
Received: by helios.bolet.org (Postfix, from userid 1001) id BF9D55C239; Thu, 1 Jan 2009 20:53:07 +0100 (CET)
Date: Thu, 1 Jan 2009 20:53:07 +0100
From: Thomas Pornin
To: [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Message-ID: <[email-masked]>
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Wed, Dec 31, 2008 at 10:21:12AM -0500, Santosh Chokhani wrote:
> We are simply not vigilant enough. This issue has been on our plate
> since 2004.

That's actually good news.

RFC 4998 defines the ERS syntax for long-term proofs of existence (i.e.
glorified time stamps). One point of ERS is that data is hashed, and
must be rehashed with a new hash function if the previously used one
becomes a bit cranky. There was some debate about whether such a model
is valid, i.e. whether it is plausible that rehashing and update of
evidence records could be achieved in the time frame between the first
publicly known weaknesses, and the actual attack.

MD5 became a bit stale by 1996 (with the collisions on the compression
function) and the first collisions were published in 2004. However, it
still took four years for those collisions to be transformed into a real
attack on X.509 certificates. Hence, the ERS model is valid: even
discounting the 1996 warnings, we now know that it still takes several
years for a known attack to become applicable in real situations.

That four years are still not enough for deployed PKI software to be
amended is another issue. It is bad, but hardly bad _news_. Endemic
sloppiness is known to exist.

--Thomas Pornin

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01JmhZO095178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 12:48:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01JmhFL095176; Thu, 1 Jan 2009 12:48:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n01Jmffu095155 for ; Thu, 1 Jan 2009 12:48:41 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 12536 invoked from network); 1 Jan 2009 19:49:03 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;01 Jan 2009 19:49:03 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 19:49:03 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Date: Thu, 1 Jan 2009 14:48:40 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclsSLgggyxnPlLcRtiDUadx0CecswAANOjQ
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Ben Laurie"
Cc: "Paul Hoffman" , , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I do not think canonical means only one way to represent.

Extensions have always been a SEQUENCE with their OID denoting what
extension is next and their syntax.

Actually, we find SET in the case of RDN problematic.

-----Original Message-----
From: Ben Laurie [mailto:[email-masked]]=20
Sent: Thursday, January 01, 2009 2:40 PM
To: Santosh Chokhani
Cc: Paul Hoffman; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

Santosh Chokhani wrote:
> We must fix X.509 since it is not broken.

I am not suggesting that we should fix X.509, I am pointing out, in my
own roundabout way, that X.509 certs are supposed to have a canonical
form. But it seems they do not.

Makes me wonder why we go to all the effort of using a supposedly
canonical encoding that isn't? If we can only rely on the original bits
in the cert when checking the signature, why bother?

--=20
http://www.apache-ssl.org/ben.html http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01JdrfD094546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 12:39:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01JdrOM094544; Thu, 1 Jan 2009 12:39:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01Jdp9b094527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 12:39:52 -0700 (MST) (envelope-from [email-masked])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6A66333C1E; Thu, 1 Jan 2009 19:41:23 +0000 (GMT)
Message-ID: <[email-masked]>
Date: Thu, 01 Jan 2009 19:39:54 +0000
From: Ben Laurie
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Santosh Chokhani
CC: Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Santosh Chokhani wrote:
> We must fix X.509 since it is not broken.

I am not suggesting that we should fix X.509, I am pointing out, in my
own roundabout way, that X.509 certs are supposed to have a canonical
form. But it seems they do not.

Makes me wonder why we go to all the effort of using a supposedly
canonical encoding that isn't? If we can only rely on the original bits
in the cert when checking the signature, why bother?

--
http://www.apache-ssl.org/ben.html http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01JU0uQ093880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 12:30:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01JU0Tt093878; Thu, 1 Jan 2009 12:30:00 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n01JTmYA093845 for ; Thu, 1 Jan 2009 12:29:58 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 12442 invoked from network); 1 Jan 2009 19:30:10 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;01 Jan 2009 19:30:10 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 19:30:10 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Date: Thu, 1 Jan 2009 14:29:46 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclsOJwh2A/o+dm4RcK781oKyPwOkAADl7sA
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Ben Laurie" , "Paul Hoffman"
Cc: , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

We must fix X.509 since it is not broken.

We must preserve MD5 since it is weak.

We must provide economic and political support to client side vendors
who refuse to implement SHA-256. We must treat them with kid gloves and
work around them.

The world economy is in the tank.

People want to shoot each other.

I see a patent here that is not very random.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Laurie
Sent: Thursday, January 01, 2009 12:45 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

Paul Hoffman wrote:
> At 3:06 PM +0000 1/1/09, Ben Laurie wrote:
>> Surely the whole point of DER is that there's only one correct way to
>> encode any particular certificate?
>=20
> Not so "surely". The SEQUENCE for extensions does not say what order
they should be in.

That doesn't change the _point_ of DER. If extensions should have been
specified as a SET but are defined as a SEQUENCE, then they are broken
(technically).

>> So, either extensions must be sorted, or changing their order changes
>> their meaning. Either way, nothing can be reordered.
>=20
> Wrong on both counts. Each extension has stand-alone semantics, and
they can be in any order.

My point was about the correct use of DER. It seems extensions use it
incorrectly.

> However, this is irrelevant for the MD5 break discussion, as is
clearly shown in the paper.

I am discussing the correct use of DER :-)

--=20
http://www.apache-ssl.org/ben.html http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01Hign8086881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 10:44:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01HigpD086880; Thu, 1 Jan 2009 10:44:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01HiTqF086851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 10:44:41 -0700 (MST) (envelope-from [email-masked])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5BA8133C1E; Thu, 1 Jan 2009 17:46:01 +0000 (GMT)
Message-ID: <[email-masked]>
Date: Thu, 01 Jan 2009 17:44:32 +0000
From: Ben Laurie
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Paul Hoffman
CC: Ben Laurie , Peter Gutmann , [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <[email-masked]> <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul Hoffman wrote:
> At 3:06 PM +0000 1/1/09, Ben Laurie wrote:
>> Surely the whole point of DER is that there's only one correct way to
>> encode any particular certificate?
>
> Not so "surely". The SEQUENCE for extensions does not say what order they should be in.

That doesn't change the _point_ of DER. If extensions should have been
specified as a SET but are defined as a SEQUENCE, then they are broken
(technically).

>> So, either extensions must be sorted, or changing their order changes
>> their meaning. Either way, nothing can be reordered.
>
> Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order.

My point was about the correct use of DER. It seems extensions use it
incorrectly.

> However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper.

I am discussing the correct use of DER :-)

--
http://www.apache-ssl.org/ben.html http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01HKGKW085009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 10:20:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01HKGnx085007; Thu, 1 Jan 2009 10:20:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01HK1Rw084974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 10:20:02 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 1 Jan 2009 09:20:00 -0800
To: Ben Laurie , Peter Gutmann
From: Paul Hoffman
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 3:06 PM +0000 1/1/09, Ben Laurie wrote:
>Surely the whole point of DER is that there's only one correct way to
>encode any particular certificate?

Not so "surely". The SEQUENCE for extensions does not say what order they should be in.

>So, either extensions must be sorted, or changing their order changes
>their meaning. Either way, nothing can be reordered.

Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order.

However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper.

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01Gowjw082692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 09:50:58 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01GovZs082690; Thu, 1 Jan 2009 09:50:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01GolS6082663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 09:50:57 -0700 (MST) (envelope-from [email-masked])
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5783750822; Thu, 1 Jan 2009 09:07:06 -0800 (PST)
Date: Thu, 01 Jan 2009 09:07:05 -0800
From: Eric Rescorla
To: Mike
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At Thu, 01 Jan 2009 07:51:38 -0800,
Mike wrote:
>
>
> Is there anything that could be added to RP software to reliably
> detect and thwart the use of a rogue CA certificate? Or would
> any attempt to do that just cause too many problems?
>
> Mike (who is writing "I am not a security expert" 100 times on
> the chalkboard)

You could certainly add a check for this particular certificate
and any others you discovered. To the extent to which CAs no
longer use MD5, this would likely quickly clean up the damage.
It's less clear that you could safely detect this kind of
cert in a generic way.

-Ekr

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01FqY69077524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 08:52:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01FqYUI077521; Thu, 1 Jan 2009 08:52:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01FqMXt077493; Thu, 1 Jan 2009 08:52:33 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 485131B89A; Thu, 1 Jan 2009 10:52:22 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 43CE11B898; Thu, 1 Jan 2009 10:52:16 -0500 (EST)
Message-ID: <[email-masked]>
Date: Thu, 01 Jan 2009 07:51:38 -0800
From: Mike
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 2D5E92AE-D81C-11DD-B34D-F83E113D384A-38729857!a-sasl-quonix.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Is there anything that could be added to RP software to reliably
detect and thwart the use of a rogue CA certificate? Or would
any attempt to do that just cause too many problems?

Mike (who is writing "I am not a security expert" 100 times on
the chalkboard)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01FF3mW074323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 08:15:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01FF3un074321; Thu, 1 Jan 2009 08:15:03 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n01FEpu0074279 for ; Thu, 1 Jan 2009 08:15:01 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 11256 invoked from network); 1 Jan 2009 15:15:13 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;01 Jan 2009 15:15:13 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 15:15:13 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Date: Thu, 1 Jan 2009 10:14:49 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclsIoYaC7zrH+YEQlGlPwinB2nccwAAQV+A
References: <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Ben Laurie" , "Peter Gutmann"
Cc: , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Changing the order of extensions does not change their meaning.

Actually, a CA could put the extensions in random order for various
certificates. The attack will still work if the certificate size does
not change.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Laurie
Sent: Thursday, January 01, 2009 10:06 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

On Thu, Jan 1, 2009 at 11:17 AM, Peter Gutmann
wrote:
>
> Mike writes:
> >There is a simple fix -- a CA can just reorder the extensions prior
to
> >issuing a certificate.
>
> That's actually a nice fix, but unfortunately not universally
applicable: for
> some types of signed data (e.g. S/MIME attributes) the DER rules
require
> sorting the encoded extensions, so there's only one valid order for
them (and
> some applications actually check for this, so you have to do it or sig
checks
> will start failing).

Surely the whole point of DER is that there's only one correct way to
encode any particular certificate?

So, either extensions must be sorted, or changing their order changes
their meaning. Either way, nothing can be reordered.
_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01BgXXF053803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 04:42:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01BgXhF053802; Thu, 1 Jan 2009 04:42:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.grid.kiae.ru (mail.grid.kiae.ru [144.206.66.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01BgKUl053774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Jan 2009 04:42:32 -0700 (MST) (envelope-from [email-masked])
Received: from phoenix.codelabs.ru (ppp85-141-67-174.pppoe.mtu-net.ru [85.141.67.174]) by mail.grid.kiae.ru (Postfix) with ESMTPSA id 826D454D02C; Thu, 1 Jan 2009 14:42:19 +0300 (MSK)
Date: Thu, 1 Jan 2009 14:42:18 +0300
From: Eygene Ryabinkin
To: "David A. Cooper"
Cc: pkix
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
Message-ID:
Reply-To: [email-masked]
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

David,

Wed, Dec 31, 2008 at 04:49:02PM -0500, David A. Cooper wrote:
> You are correct that a change anywhere in the certificate will change
> the hash. However, the attacker does not need to know in advance what
> the hash value will be, only that the hash of the real certificate and
> the rogue certificate will be the same. If you look at the image
> depicting the generation of the collision in the attack
> (http://www.win.tue.nl/hashclash/rogue-ca/downloads/alignment.pdf), you
> will see why these two statements are not the same.

Yes, now I am starting to get the meaning of the "chosen prefix" ;))

Thanks a lot!
--
Eygene Ryabinkin, Russian Research Centre "Kurchatov Institute"

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01Be5dw053634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 04:40:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01Be58Q053631; Thu, 1 Jan 2009 04:40:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n01BdrJM053587 for ; Thu, 1 Jan 2009 04:40:03 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 10279 invoked from network); 1 Jan 2009 11:40:15 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;01 Jan 2009 11:40:15 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 1 Jan 2009 11:40:15 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Date: Thu, 1 Jan 2009 06:39:50 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclsApjZvyr7mv5ST36mpmxAU3jJIwAAnlMA
References: <[email-masked]>
From: "Santosh Chokhani"
To: "Peter Gutmann" , ,
Cc: , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Also, for the actual attack, the ordering of extensions will not work as
long as the certificate size does not change. If you look at the actual
attack, collision block in the real certificate is up to the SPKI. The
extension values from the real certificate are simply copied in the
tumor of the rogue certificate.

Given the property that if H(M) =3D H (M') then H(M | X) =3D H (M' | X), =
the
attacker simply copies the extensions from actual certificate in the
tumor.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Gutmann
Sent: Thursday, January 01, 2009 6:18 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

Mike writes:

>> We are simply not vigilant enough. This issue has been on our plate
>> since 2004.
>>
>> SHA-1 is next and neither the client side vendors nor the big
>> Enterprises have pushed to move to SHA-256.
>
>There is a simple fix -- a CA can just reorder the extensions prior to
>issuing a certificate.

That's actually a nice fix, but unfortunately not universally
applicable: for
some types of signed data (e.g. S/MIME attributes) the DER rules require
sorting the encoded extensions, so there's only one valid order for them
(and
some applications actually check for this, so you have to do it or sig
checks
will start failing).

Peter.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01BIAW1052422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 04:18:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01BIALG052420; Thu, 1 Jan 2009 04:18:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01BHqnm052370; Thu, 1 Jan 2009 04:18:09 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B9719481C06; Fri, 2 Jan 2009 00:17:51 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPAZbKuv7Db5; Fri, 2 Jan 2009 00:17:51 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 048B4481BFB; Fri, 2 Jan 2009 00:17:51 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2436B1BE4002; Fri, 2 Jan 2009 00:17:50 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LILYj-00066V-WE; Fri, 02 Jan 2009 00:17:50 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
Message-Id:
Date: Fri, 02 Jan 2009 00:17:49 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Mike writes:

>> We are simply not vigilant enough. This issue has been on our plate
>> since 2004.
>>
>> SHA-1 is next and neither the client side vendors nor the big
>> Enterprises have pushed to move to SHA-256.
>
>There is a simple fix -- a CA can just reorder the extensions prior to
>issuing a certificate.

That's actually a nice fix, but unfortunately not universally applicable: for
some types of signed data (e.g. S/MIME attributes) the DER rules require
sorting the encoded extensions, so there's only one valid order for them (and
some applications actually check for this, so you have to do it or sig checks
will start failing).

Peter.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01BBcBO051835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 04:11:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n01BBbhI051833; Thu, 1 Jan 2009 04:11:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n01BBP2m051800; Thu, 1 Jan 2009 04:11:36 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 576539D817; Fri, 2 Jan 2009 00:11:23 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StmylvlTOtW7; Fri, 2 Jan 2009 00:11:23 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DE48F9D81F; Fri, 2 Jan 2009 00:11:07 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7EC871BE4002; Fri, 2 Jan 2009 00:11:01 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LILS9-0005ff-DN; Fri, 02 Jan 2009 00:11:01 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To:
Message-Id:
Date: Fri, 02 Jan 2009 00:11:01 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Santosh Chokhani" writes:

>We are simply not vigilant enough. This issue has been on our plate since
>2004.

It's not just this, the fact that there were CA certs out there with the CA
flag (in basicConstraints) not set was known for at least five years before
widespread bad publicity forced CAs to address it, the RSA exponent=1 debacle
was known for at least that long but no-one cared until there was lots of bad
publicity about it... there's a really serious problem with CAs and vendors
simply not caring about PKI security until bad publicity forces a change, the
curent MD5 issue (and the mozilla.com cert debacle and the Gromozon malware-
signing cert issue and ...) are just the latest examples. It's like the
Microsoft of ten years ago, security holes just get ignored until bad
publicity forces a fix (and even then it's often more of a sidestep to avoid
further criticism than an actual fix).

It's small wonder that there's such widespread cynicism about PKI when even
the organisations pushing it don't seem to care whether it's done properly or
not.

Peter.