Subject: Email Handling Opinion Needed

From: <[email-masked]>
Date: Sat, 31 Jan 2009 15:29:20 -0800 (PST)

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

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

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

Privacy Statement |
Terms & Conditions |
Contact

KEYWORD Ltd.

Tower Bridge Business Complex. Unit 8, B042. 660 Clements Road. London. SE75 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 n0UGrhhE093022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:53:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UGrhDF093018; Fri, 30 Jan 2009 09:53:43 -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 n0U3HXhj054535 (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 n0U3HXwj054533; 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 n0TMspYt044398 (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 n0TMspbc044397; 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 n0TBGID1004887 (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 n0TBGIEo004885; 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 n0T2qgFp083108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 19:52:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0T2qgwu083107; Wed, 28 Jan 2009 19:52:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sjpexch1.corp.ad.entrust.com (ej2.entrust.jp [122.216.181.182]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0T2qUpv083097 for ; Wed, 28 Jan 2009 19:52:41 -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: Fwd: Invitation to the ETSI 3rd Remote XAdES/CAdES Plugtests
Date: Thu, 29 Jan 2009 11:52:28 +0900
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Fwd: Invitation to the ETSI 3rd Remote XAdES/CAdES Plugtests
Thread-Index: AcmBvJ8lnxxE5jQeTHibaTTps8yIjg==
From: "Kenji Urushima"
To:
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,

Let me apologize for a brief advertisement.

I would like to bring the following interoperability event related
to RFC 5126 CAdES (CMS Advanced Electronic Signature,=20
http://tools.ietf.org/html/rfc5126) to your attention.

########

Dear Madam,
Dear Sir,

The ETSI Plugtests Service is pleased to invite you to participate in
a new remote XAdES plugtests!

After the success of the first remote plugtest event, ETSI has
continued the development of the supporting Remote Plugtest Portal,
which now offers on-line PKI-related services (Certificates provision,
OCSP server, LDAP and Time-stamp).

The purposes of these new events are:

* To consolidate solutions to already identified interoperability
issues of CAdES and XAdES.

* To enable participants to assess the level of interoperability of
CAdES.

* To identify additional issues that should be taken into account in
future XAdES/CAdES standardization activities.

* To improve the quality of XAdES/CAdES specifications.

* To ease the introduction of XAdES/CAdES signatures, by providing the
means to solve interoperability problems before widespread deployment.

The event will evaluate (X-C)AdES interoperability by focusing on all
the different XAdES forms standardized in ETSI TS 101 903 and ETSI 101
733, including (X-C)AdES-BES, (X-C)AdES-EPES, (X-C)AdES-T,
(X-C)AdES-C, (X-C)AdES-X Type 1, (X-C)AdES-X Type 2, (X-C)AdES-XL and
(X-C)AdES-A.

Participants will also be able to generate new test case definitions
and signatures, which will be taken into consideration for extending
the test cases set according to ETSI's discretion.

The registration deadline for the 3rd event is 6th February 2009. We
recommend you to register as soon as possible. All details about the
events, including all the technical information are available at the
following URL:_

http://www.etsi.org/plugtests/XAdES2/html/XAdES2.htm
http://xades-portal.etsi.org/pub/XAdES2.shtml

Should you need any further information, please feel free to=20
contact us at: [email-masked]

The Plugtests Team

-------------------------------

Please accept our apologies if you receive multiple copies of this
announcement.

#########

Kenji Urushima ([email-masked])
Entrust Japan Co., Ltd.
http://japan.entrust.com/
ETSI STF-351
http://portal.etsi.org/stfs/STF_HomePages/STF351/STF351.asp

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 n0SJd7N2065526 (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 n0SJd7eS065525; 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 n0SHE4Gd059483 (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 n0SHE4ku059481; 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 n0SEZWZv050545 (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 n0SEZWpN050543; 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 n0SEZLZI050509 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 n0RLN9A3002892 (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 n0RLN9Dv002891; 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 n0RGRjCv086362 (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 n0RGRjQo086359; 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 n0RFLh5b082579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 08: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 n0RFLhjn082578; Tue, 27 Jan 2009 08: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 smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0RFLV3q082566 for ; Tue, 27 Jan 2009 08:21:42 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 33171 invoked from network); 27 Jan 2009 15:21:31 -0000
Received: from unknown (HELO ?192.168.1.2?) ([email-masked] with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 27 Jan 2009 15:21:30 -0000
X-YMail-OSG: 1ysCHigVM1lGaecx2imusUsukZ.7d5lks.sVAwwL3tofn9lFxxp2jZE2qkYgmXhwUBiTEdsmlOKGPbvVdo0c7_aWkMhdqocORnJjmpoISojixfhLQpMc_exIdqo7aVIY14HGuZE8.44CRBmUw_cTk6iXUcIzLtCfK5EnzI9Wz0KEMq2sFbLgmh7JmWGeaDD3_oun.6BOgvYqUeP.WY_AiyGHxJ_k
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Tue, 27 Jan 2009 10:21:56 -0500
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Peter Gutmann
CC: [email-masked]
Subject: Re: CMS Questionnaire
References:
In-Reply-To:
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:

Peter Gutmann wrote:
> Sean Turner writes:
>
>> Russ and Tim have challenged me to try to advance CMS to Draft Standard
>> using the process in BCP 97 to deal with the dependencies that have not
>> yet advanced (or aren't advancing). To that end, I've drawn up the
>> following questionnaire that I'd like implementers to complete and
>> return to me. What we're shooting for is to find two implementations
>> that generate messages for each feature, and two implementations that
>> process each feature. We don't think it should matter if the same two
>> implementations are used in both stages.
>
> Are you just after straight yes-or-no answers, or are you interested in
> metadata as well? By metadata I mean things like "I probably support method
> XYZ but since I've never found anything else that does to test against I can't
> guarantee that it's correct", or "I've implemented XYZ but since no user has
> ever asked for it it's never been tested". It may be useful to get (or at
> least I'd be very interested in seeing) data on what's actually being used in
> the real world. Motivated by the history of RFC 4134, I'd also prefer to be
> able to qualify a claim of "I support XYZ" with further details if there's
> never been any opportunity to test whether it's actually implemented as
> required (in other words to differentiate "I'm pretty sure I support XYZ" vs.
> "I definitely support XYZ and have interoperated with others using it").

I'm definitely interested in metadata.

spt

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 n0R3MT0t048596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 20:22:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0R3MTbB048595; Mon, 26 Jan 2009 20:22:29 -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 n0R3MIA8048570 for ; Mon, 26 Jan 2009 20:22:29 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 979D29E347; Tue, 27 Jan 2009 16:22:16 +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 5V4ozRoLrSsy; Tue, 27 Jan 2009 16:22:16 +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 09D9E9E296; Tue, 27 Jan 2009 16:22: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 752F11AE4003; Tue, 27 Jan 2009 16:22:10 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LReWg-0007XA-Df; Tue, 27 Jan 2009 16:22:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: CMS Questionnaire
In-Reply-To: <[email-masked]>
Message-Id:
Date: Tue, 27 Jan 2009 16:22:10 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Sean Turner writes:

>Russ and Tim have challenged me to try to advance CMS to Draft Standard
>using the process in BCP 97 to deal with the dependencies that have not
>yet advanced (or aren't advancing). To that end, I've drawn up the
>following questionnaire that I'd like implementers to complete and
>return to me. What we're shooting for is to find two implementations
>that generate messages for each feature, and two implementations that
>process each feature. We don't think it should matter if the same two
>implementations are used in both stages.

Are you just after straight yes-or-no answers, or are you interested in
metadata as well? By metadata I mean things like "I probably support method
XYZ but since I've never found anything else that does to test against I can't
guarantee that it's correct", or "I've implemented XYZ but since no user has
ever asked for it it's never been tested". It may be useful to get (or at
least I'd be very interested in seeing) data on what's actually being used in
the real world. Motivated by the history of RFC 4134, I'd also prefer to be
able to qualify a claim of "I support XYZ" with further details if there's
never been any opportunity to test whether it's actually implemented as
required (in other words to differentiate "I'm pretty sure I support XYZ" vs.
"I definitely support XYZ and have interoperated with others using it").

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 n0QKmWLt035310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 13:48:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QKmWeJ035309; Mon, 26 Jan 2009 13:48:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0QKmLiV035298 for ; Mon, 26 Jan 2009 13:48:31 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 37268 invoked from network); 26 Jan 2009 20:48:21 -0000
Received: from unknown (HELO ?192.168.1.2?) ([email-masked] with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 26 Jan 2009 20:48:20 -0000
X-YMail-OSG: xPmTWCYVM1kXoILeZnYyUYgt_4cdKVgYsujHvcqgTytrldZ_e5gRh8V.iKYCr7w9hwsoZsRJDkLR9b82DXUchGTDAunGFqx5nz1Y5CwFUU1w5umwsMkf79sT3nwp8cEZSL6KKldVkO4wzIecM22VAqbjLCvyCTYUMtXSfEuUDAuctkkUQKEqm78asN2e.w--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Mon, 26 Jan 2009 15:48:47 -0500
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [email-masked]
Subject: CMS Questionnaire
Content-Type: multipart/mixed; boundary="------------060909090602040808030106"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.
--------------060909090602040808030106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Russ and Tim have challenged me to try to advance CMS to Draft Standard
using the process in BCP 97 to deal with the dependencies that have not
yet advanced (or aren't advancing). To that end, I've drawn up the
following questionnaire that I'd like implementers to complete and
return to me. What we're shooting for is to find two implementations
that generate messages for each feature, and two implementations that
process each feature. We don't think it should matter if the same two
implementations are used in both stages.

Thanks in advance,

spt

--------------060909090602040808030106
Content-Type: text/plain;
name="cms-questionnaire.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="cms-questionnaire.txt"

UGxlYXNlIGxpc3QgdGhlIHByb2R1Y3QgYW5kIHZlcnNpb24gbnVtYmVyIChpZiBhcHBsaWNh
YmxlKSBjb3ZlcmVkIGJ5IHRoaXMgcXVlc3Rpb25uYWlyZS4NCg0KDQpXaGF0IGV2aWRlbmNl
IGRvIHlvdSBoYXZlIHRoYXQgeW91IGNhbiBpbnRlcm9wIHdpdGggb3RoZXIgaW1wbGVtZW50
YXRpb25zPw0KSGF2ZSB5b3Ugd29ya2VkIHRocm91Z2ggdGhlIGV4YW1wbGVzIGRyYWZ0Pw0K
DQpXaGljaCBvZiB0aGUgZm9sbG93aW5nIGNvbnRlbnQgdHlwZXMgZGlkIHlvdSBpbXBsZW1l
bnQ6DQotIENvbnRlbnRJbmZvLA0KLSBpZC1kYXRhLA0KLSBpZC1zaWduZWQtZGF0YSwNCi0g
aWQtZW52ZWxvcGVkLWRhdGE/DQoNCkZvciB0aG9zZSB0aGF0IGltcGxlbWVudGVkIFNpZ25l
ZERhdGE6DQotIHdoaWNoIHZlcnNpb24ocyk6IHYxLCB2MywgdjQsIHY1Pw0KLSB3aXRob3V0
IENlcnRpZmljYXRlcyAmIENSTHM/DQotIHdpdGggQ2VydGlmaWNhdGVzPw0KLSB3aXRoIENS
TD8NCi0gd2l0aCBlbWJlZGRlZCBjb250ZW50Pw0KLSB3aXRoIGRldGFjaGVkIGNvbnRlbnQ/
DQotIFNpZ25lckluZm8gd2l0aG91dCBzaWduZWQgYXR0cmlidXRlcz8NCi0gU2lnbmVySW5m
byB3aXRoIHNpZ25lZCBhdHRyaWJ1dGVzOiBpZC1tZXNzYWdlRGlnZXN0LCBpZC1jb250ZW50
VHlwZSwgaWQtc2lnbmluZ1RpbWUsIGlkLWNvdW50ZXJTaWduYXR1cmU/DQotIFNpZ25lcklu
Zm8gd2l0aCB1bnNpZ25lZCBhdHRyaWJ1dGVzPw0KLSBTaWduZXJJbmZvIHdpdGggU0tJLCBp
c3N1ZXIvc2VyaWFsbnVtYmVyLCBvciBib3RoPw0KDQpGb3IgdGhvc2UgdGhhdCBpbXBsZW1l
bnRlZCBFbnZlbG9wZWREYXRhOg0KLSB3aGljaCB2ZXJzaW9uKHMpOiB2MCwgdjIsIHYzLCB2
ND8NCi0gd2l0aCB1bnByb3RlY3RlZCBhdHRyaWJ1dGVzPw0KLSB3aGljaCBSZWNpcGllbnRJ
bmZvOiBrdHJpLCBrYXJpLCBrZWtyaSwgcHdyaSwgb3JpPw0KLSBmb3Iga3RyaSwgd2hpY2gg
aWRlbnRpZmllciBpc3N1ZXIvc2VyaWFsLCBTS0ksIG9yIGJvdGg/DQotIGZvciBrYXJpLCB3
aGljaCBpZGVudGlmaWVyIGlzc3Vlci9zZXJpYWwsIFNLSSwgb3IgYm90aD8NCi0gZm9yIGth
cmksIHdhcyB1a20gc3VwcG9ydGVkPw0KLSBmb3Iga2VrcmksIGlzIGRhdGUsIG90aGVyIG9y
IGJvdGggc3VwcG9ydGVkIGluIEtFS0lkZW50aWZpZXI/DQoNCkZvciB0aG9zZSB0aGF0IGlt
cGxlbWVudGVkIGJvdGggU2lnbmVkRGF0YSBhbmQgRW52ZWxvcGVkRGF0YToNCi0gQ2FuIHlv
dSBzdXBwb3J0IHJlY2VpdmluZyBhIHRyaXBsZSB3cmFwcGVkIG1lc3NhZ2U6IEFuIGlkLXNp
Z25lZERhdGEgZW5jYXBzdWxhdGVkIGluIGFuIGlkLWVudmVsb3BlZERhdGEgZW5jYXBzdWxh
dGVkIGluIGlkLWVudmVsb3BlZERhdGE/DQoNCkJvbnVzIHF1ZXN0aW9ucywgd2hpY2ggYXJl
IG5vdCBnb2luZyB0byBiZSBpbmNsdWRlZCBpbiB0aGUgQ01TIGludGVyb3AgcmVwb3J0Og0K
LSBGb3IgU2lnbmVkRGF0YSwgZG8geW91IHN1cHBvcnQgdGhlIG11bHRpc2lnIElEPw0KLSBG
b3IgQXV0aGVudGljYXRlZERhdGEsIGRvIHlvdSBzdXBwb3J0IERpZ2VzdGVkRGF0YSwgQ29t
cHJlc3NlZERhdGEsIEVuY3J5cHRlZERhdGEsIGFuZC9vciBBdXRoRW52ZWxvcGVkRGF0YT8N
Ci0gRm9yIFNpZ25lZERhdGEgd2hhdCBkbyB5b3UgZG8gd2hlbiB5b3UgZW5jb3VudGVyIGFu
IGF0dHJpYnV0ZSB0aGF0IHlvdSBkb24ndCBzdXBwb3J0Pw==
--------------060909090602040808030106--

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 n0P60iPb036696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2009 23:00:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0P60iWC036695; Sat, 24 Jan 2009 23:00:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.245]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0P60Xuw036689 for ; Sat, 24 Jan 2009 23:00:44 -0700 (MST) (envelope-from [email-masked])
Received: by rv-out-0708.google.com with SMTP id c5so6259782rvf.34 for ; Sat, 24 Jan 2009 22:00:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=5K2G+l5Ki+ktBe9o8DlACCdSLTZng7hRPubu62ZKvME=; b=h3G7ZeyGmXrIctSPEfVq/+jVcazJCrci0bN9flZVFBZEuB8V3fnnelUFEPa/Fz6CrF MwJ2Tmt9cvIVMBMJm308WdljrDi3k/avGehhfAIAVQE0M0N7j8doBh+1TGUQFvs3ML+s H1rZsXzUQMDrCOeqAUE1rEnei/TzV83L75+zs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=vdfMPTH3dlQAWS54K1+tHh8G1hhizwb7GymS9zs/5N4PQcVFsQQaY3hlKZ43P8I9Vj 5U1v55XV77WhADst8ox3XqpYIVHPd0vehNdnxJRg5DWyR33uGha5lg7TkwTrLBTsrOJM +zB3Chp2E+nNdD6cRxzXzeES99Mksgi2Jc9K4=
MIME-Version: 1.0
Received: by 10.141.52.5 with SMTP id e5mr1971495rvk.55.1232863233286; Sat, 24 Jan 2009 22:00:33 -0800 (PST)
Date: Sat, 24 Jan 2009 22:00:33 -0800
Message-ID: <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-new-asn1-02
From: Blake Ramsdell
To: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This message initiates an SMIME Working Group Last Call on the document:

Title : New ASN.1 Modules for CMS and S/MIME
Author(s) : P. Hoffman, J. Schaad
Filename : draft-ietf-smime-new-asn1-02.txt
Pages : 61
Date : 2009-01-09

The Cryptographic Message Syntax (CMS) 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-smime-new-asn1-02.txt

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Standards Track RFC.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues may be
sent to the document editor.

The Last Call period will end on 30 January 2009.

Upon completion of the last call, the WG chairs will take action based upon
the consensus of the WG. Possible actions include:

1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as an Informational RFC
(which generally involves an IETF-wide Last Call); or

2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to ensure
the quality of our documents and of the Internet Standards process. So,
please read and comment!

Blake
--
Blake Ramsdell | http://www.blakeramsdell.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 n0O0DITK070578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 17:13:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0O0DIn5070577; Fri, 23 Jan 2009 17:13:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0O0DITw070569 for ; Fri, 23 Jan 2009 17:13:18 -0700 (MST) (envelope-from [email-masked])
Received: by bosco.isi.edu (Postfix, from userid 70) id 2B1731F6DD8; Fri, 23 Jan 2009 16:13:18 -0800 (PST)
To: [email-masked], [email-masked]
Subject: RFC 5408 on Identity-Based Encryption Architecture and Supporting Data Structures
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Fri, 23 Jan 2009 16:13:18 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

A new Request for Comments is now available in online RFC libraries.

RFC 5408

Title: Identity-Based Encryption Architecture and Supporting
Data Structures
Author: G. Appenzeller, L. Martin,
M. Schertler
Status: Informational
Date: January 2009
Mailbox: [email-masked],
[email-masked],
[email-masked]
Pages: 30
Characters: 62160
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-smime-ibearch-09.txt

URL: http://www.rfc-editor.org/rfc/rfc5408.txt

This document describes the security architecture required to
implement identity-based encryption, a public-key encryption
technology that uses a user's identity as a public key. It
also defines data structures that can be used to implement the
technology. This memo provides information for the Internet
community.

This document is a product of the S/MIME Mail Security Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences 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 n0O09POW070270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 17:09:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0O09Pk6070269; Fri, 23 Jan 2009 17:09:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0O09E3J070259 for ; Fri, 23 Jan 2009 17:09:24 -0700 (MST) (envelope-from [email-masked])
Received: by bosco.isi.edu (Postfix, from userid 70) id F0C061F6DD4; Fri, 23 Jan 2009 16:09:13 -0800 (PST)
To: [email-masked], [email-masked]
Subject: RFC 5409 on Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Fri, 23 Jan 2009 16:09:13 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

A new Request for Comments is now available in online RFC libraries.

RFC 5409

Title: Using the Boneh-Franklin and Boneh-Boyen
Identity-Based Encryption Algorithms with the Cryptographic
Message Syntax (CMS)
Author: L. Martin, M. Schertler
Status: Informational
Date: January 2009
Mailbox: [email-masked],
[email-masked]
Pages: 13
Characters: 25481
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-smime-bfibecms-10.txt

URL: http://www.rfc-editor.org/rfc/rfc5409.txt

This document describes the conventions for using the Boneh-Franklin
(BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the
Cryptographic Message Syntax (CMS) to encrypt content-encryption keys.
Object identifiers and the convention for encoding a recipient's
identity are also defined. This memo provides information for the
Internet community.

This document is a product of the S/MIME Mail Security Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked]. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences 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 n0KITuuk030702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 11: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 n0KITujP030699; Tue, 20 Jan 2009 11: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 mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KITjX9030686 for ; Tue, 20 Jan 2009 11:29:56 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 39B443A6B39; Tue, 20 Jan 2009 10:30:00 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-sha2-11.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Tue, 20 Jan 2009 10:30: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 S/MIME Mail Security Working Group of the IETF.

Title : Using SHA2 Algorithms with Cryptographic Message Syntax
Author(s) : S. Turner
Filename : draft-ietf-smime-sha2-11.txt
Pages : 11
Date : 2009-1-20

This document describes the conventions for using the Secure Hash
Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384,
SHA-512) with the Cryptographic Message Syntax (CMS). It also
describes the conventions for using these algorithms with CMS and the
Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and
Elliptic Curve DSA (ECDSA) signature algorithms. Further, it
provides SMIMECapabilities attribute values for each algorithm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-11.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-smime-sha2-11.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 n0F58wgA022693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 22:08:58 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0F58wAH022692; Wed, 14 Jan 2009 22:08:58 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0F58lfO022670 for ; Wed, 14 Jan 2009 22:08:57 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 50151 invoked from network); 15 Jan 2009 05:08:46 -0000
Received: from unknown (HELO ?192.168.1.2?) ([email-masked] with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 15 Jan 2009 05:08:46 -0000
X-YMail-OSG: 5Ky74zEVM1nUpMrwERDphsifrqP3OZKlYkmBeVerTYDUhb3dCxcSPRmaI7GoQRe1MscOqOoWHxCQVd8YlXCqt89_SYokYk6AsmEqmWePN5k2Kthuytcm8uTqLKtUXESetdsUbiFj0b0Fj_ONJtowEMRuhI.sMb3OmhYJ9W4jF5d_Yb.bnnXc0KVIknP1mUUsjtH0cSERyOGWP2VTVEZwvOz.62vA
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Thu, 15 Jan 2009 00:08:59 -0500
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: [email-masked]
Subject: [Fwd: Fwd: RFC 5378 and Draft Submissions]
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:

IETF Chair Russ Housley has asked WG chairs to apprise their WGs of the
following information.

If you've been following the IETF mailing list, you may be aware of the
ongoing discussion about the impact of RFC 5378 on revised draft
submissions. Briefly, RFC 5378 requires Contributors to grant a more
expansive set of rights than were granted by RFC 3978, and 4748. If you
are submitting a document which contains text contributed by others
prior to the publication of RFC 5378 you may need to obtain additional
rights from the copyright holders of that text in order to contribute
under the 5378 terms.

The IESG and the IETF Trustees are working to resolve those issues
(see
http://trustee.ietf.org/docs/Background-to-Draft-Update-to-IETF-Trust-Legal-Provisions.txt).
However, at present I would advise care prior to submitting any draft
which contains material derived from an RFC, draft, or mailing list
message published prior to November 10, 2008.

Please take any general discussion of RFC 5378 to [email-masked]

spt
[As WG Chair]

PS I copied most of ekr's message.

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 n0EGtvMN084253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 09:55:58 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0EGtvU3084251; 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 n09GxnMM027692 (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 n09GxnEG027690; 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 n09Gxmnl027676 for ; Fri, 9 Jan 2009 09:59:49 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id D2A603A6917; Fri, 9 Jan 2009 09:00:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-smime-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 S/MIME Mail Security Working Group of the IETF.

Title : New ASN.1 Modules for CMS and S/MIME
Author(s) : P. Hoffman, J. Schaad
Filename : draft-ietf-smime-new-asn1-02.txt
Pages : 61
Date : 2009-01-09

The Cryptographic Message Syntax (CMS) 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-smime-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-smime-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 n09GqPA2027240 (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 n09GqPVn027239; Fri, 9 Jan 2009 09:52:25 -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 n09GNlxt025072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 09:23:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09GNlaJ025071; Fri, 9 Jan 2009 09:23:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n09GNZfJ025052 for ; Fri, 9 Jan 2009 09:23:46 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 84302 invoked from network); 9 Jan 2009 16:23:35 -0000
Received: from unknown (HELO ?192.168.1.2?) ([email-masked] with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 9 Jan 2009 16:23:34 -0000
X-YMail-OSG: nWEfxsQVM1mofIpDcvIG8eWXmbkMNdc5Vzihp7nGy3Il6Y2215mbC9SoCho4UvOqbCnhvIIxSCm3Pauj11lUKE04Y6.9R4TyUc2.gP5I4LbdByD6tU8FXFS4ZmdYLYRX5kru.rWBHVRkr8FhSjyiwhJL8bTFS2QLqIaodJMkgsapgK48eNmY3BKDE4EkYA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Fri, 09 Jan 2009 11:23:29 -0500
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Paul Hoffman
CC: Tim Polk , =?ISO-8859-1?Q?Alfred_H=CEnes?= , [email-masked]
Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes
References: <[email-masked]>
In-Reply-To:
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:

Paul Hoffman wrote:
> At 9:13 AM -0500 1/8/09, 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.
>> Setting any lower bound
>> seems to imply that there is a significant break point, and I did not want to give
>> that implication. 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.
>>
>> 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?
>
> I cannot say if it affects Alfred's concern, but I *strongly* object to such a normative change at this late date in the document cycle. Your original logic (don't imply a break point) is still valid. There may be perfectly valid local policy for a site to want to support shorter keys for historical reasons. We have already made it clear what the interoperability issues are, and we have set them based on security in the Internet context. The current wording obviously discourages anything under 1024 bits.

I think I'm with Paul on not including this text. We're giving a pretty
darn big hint not to use keys less than 1024, but if they really really
need to they ought to be able to without being considered non-compliant.

spt

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 n092S1pL086805 (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 n092S1LC086804; 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 n08MNuFT076677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 15:23:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08MNuXs076676; Thu, 8 Jan 2009 15:23:56 -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 n08MNfI5076658 for ; Thu, 8 Jan 2009 15:23:53 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA218623322; Thu, 8 Jan 2009 23:22:02 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA09406 for [email-masked]; Thu, 8 Jan 2009 23:22:01 +0100 (MEZ)
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 H\Nnes"
To: [email-masked]
Cc: [email-masked]
In-Reply-To: from Tim Polk at Jan "8, 2009 09:13:47" am
Message-Id: <[email-masked]>
Date: Thu, 8 Jan 2009 18:28:22 +0100 (MEZ)
Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes
Mime-Version: 1.0
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 n08K0ehQ069460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 13:00:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08K0e6n069459; Thu, 8 Jan 2009 13:00:40 -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 n08K0WSm069446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 13:00:33 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Thu, 8 Jan 2009 12:00:30 -0800
To: Tim Polk , Alfred HÎnes
From: Paul Hoffman
Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 9:13 AM -0500 1/8/09, 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.
>Setting any lower bound
>seems to imply that there is a significant break point, and I did not want to give
>that implication. 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.
>
>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?

I cannot say if it affects Alfred's concern, but I *strongly* object to such a normative change at this late date in the document cycle. Your original logic (don't imply a break point) is still valid. There may be perfectly valid local policy for a site to want to support shorter keys for historical reasons. We have already made it clear what the interoperability issues are, and we have set them based on security in the Internet context. The current wording obviously discourages anything under 1024 bits.

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 n08IL1a8064571 (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 n08IL1Qd064569; 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 n08GYl9U057363 (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 n08GYlXx057361; 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 n08G5hj5055328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:05:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08G5hrw055327; Thu, 8 Jan 2009 09:05: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.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08G5Vce055312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Jan 2009 09:05:42 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n08G5Ouu006074; Thu, 8 Jan 2009 11:05:26 -0500
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id:
Cc: [email-masked]
Content-Transfer-Encoding: quoted-printable
From: Tim Polk
Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes
Date: Thu, 8 Jan 2009 09:13:47 -0500
To: =?ISO-8859-1?Q?Alfred_H=CEnes?=
X-Mailer: Apple Mail (2.753.1)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Alfred,

The lower bound was dropped for a couple of reasons. Practically =20
speaking,
any RSA/DSA keys smaller than 1024 bits offer little security. =20
Setting any lower bound
seems to imply that there is a significant break point, and I did not =20=

want to give
that implication. I also thought that implementations might want to =20
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 =20
because it
was specified in the table.

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 =20
RSA and DSA key
sizes at 512 bits; implementations that support verification of =20
certificates or CRLs
generated with weak keys MUST NOT support RSA or DSA keys of less =20
than 512 bits.

For 3851bis:

Note that previous versions of this standard set the lower bound for =20
RSA and DSA key
sizes at 512 bits; implementations that support verification of =20
digital signatures
generated with weak keys MUST NOT support RSA or DSA keys of less =20
than 512 bits.

Would that address your concern?

Thanks,

Tim Polk

On Jan 7, 2009, at 6:16 AM, Alfred H=CEnes 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 3581 bis, 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 ?
>
>
> Finally, nits for 3851bis, in (1) / Section 4.2 :
>
> - I suggest s!generated!generating!
>
> - Also, for alignment with (2) / Section 4.3,
> it might be preferable to use plural:
>
> s!an S/MIME agent!S/MIME agents!
>
>
> Kind regards,
> Alfred.
>
> --=20
>
> +------------------------=20
> +--------------------------------------------+
> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-=20
> Phys. |
> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: =20
> -18 |
> | D-71254 Ditzingen | E-Mail: ah@TR-=20
> Sys.de |
> +------------------------=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 n08EpBXU049968 (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 n08EpBav049966; 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 n08ELhLB048009 (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 n08ELhYU048006; 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 n08E8YfZ046642 (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 n08E8Xvc046636; Thu, 8 Jan 2009 07:08:33 -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 n08DwI6C045768 (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 n08DwI77045767; Thu, 8 Jan 2009 06: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 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 n08DI64x043625 (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 n08DI68f043624; 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 n08CVZAT041158 (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 n08CVZRS041156; 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 n087OGNn024769 (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 n087OGDK024767; 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 n086aV3w022852 (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 n086aUHw022850; 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 n085jpxo020636 (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 n085joYf020634; Wed, 7 Jan 2009 22:45:50 -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 n084Lf8C017116 (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 n084LfAm017115; 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 n07BIHXS067536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 04:18:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07BIHmj067535; Wed, 7 Jan 2009 04:18:17 -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 n07BI4Gr067525 for ; Wed, 7 Jan 2009 04:18: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 AA211216984; Wed, 7 Jan 2009 12:16:24 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA06692; Wed, 7 Jan 2009 12:16:22 +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], [email-masked]
Date: Wed, 7 Jan 2009 12:16:22 +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,

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 3581 bis, 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 ?

Finally, nits for 3851bis, in (1) / Section 4.2 :

- I suggest s!generated!generating!

- Also, for alignment with (2) / Section 4.3,
it might be preferable to use plural:

s!an S/MIME agent!S/MIME agents!

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 n06E91dt004043 (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 n06E918k004041; 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 n068iKVi085152 (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 n068iKfH085149; 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 n063EnT3069461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 20:14:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n063Enq8069459; Mon, 5 Jan 2009 20:14:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n063EcWn069425; Mon, 5 Jan 2009 20:14:48 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.1.5] ([71.191.34.86]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <[email-masked]>; Mon, 05 Jan 2009 21:14:21 -0600 (CST)
Date: Mon, 05 Jan 2009 22:14:22 -0500
From: Tim Polk
Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes
In-reply-to:
To: Paul Hoffman
Cc: S-MIME / IETF
Message-id:
MIME-version: 1.0 (Apple Message framework v753.1)
X-Mailer: Apple Mail (2.753.1)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7bit
References:
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Jan 5, 2009, at 5:05 PM, Paul Hoffman wrote:

> At 4:24 PM -0500 1/5/09, Tim Polk wrote:
>> I have had some private discussions with one of the authors
>> (Sean), and we have collaborated on some language that would
>> reflect that discussion. However, I understand that this was a
>> sensitive and somewhat controversial topic on the working group
>> list. I would like the working group to review the proposed RFC
>> Editor Notes for 3850bis and 3851bis, and confirm that these
>> changes are acceptable given the feedback received from the wider
>> Internet community. That is, please consider whether the proposed
>> new text addresses the working group's concerns given that the
>> minimum strength of the mandatory to implements need to be raised.
>
> The new ranges and new text work for me.
>
> What does *not* work for me is this being done as an RFC Editor
> note. It should be done instead as a new draft before IESG
> consideration so the whole IETF community can see the changes. The
> IETF is supposed to be working on transparency, and keeping these
> out of the Internet Draft hurts that effort.

I have to agree, these changes are too substantial to be buried in an
RFC Editor Note while it sits in queue. It is a nice format to frame
the discussion, though. If the working group is happy, I will ask
the editors for new drafts before I request an approval announcement.

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 n062uZRp068427 (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 n062uYqX068422; Mon, 5 Jan 2009 19:56:34 -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 n060xoK3062805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 17:59:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n060xo5h062804; Mon, 5 Jan 2009 17:59:50 -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 n060xok7062795 for ; Mon, 5 Jan 2009 17:59:50 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 0838D3A6825; Mon, 5 Jan 2009 17:00:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3278bis-05.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 5 Jan 2009 17:00:02 -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 S/MIME Mail Security Working Group of the IETF.

Title : Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
Author(s) : S. Turner, D. Brown
Filename : draft-ietf-smime-3278bis-05.txt
Pages : 56
Date : 2009-1-5

This document describes how to use Elliptic Curve Cryptography (ECC)
public-key algorithms in the Cryptographic Message Syntax (CMS). The
ECC algorithms support the creation of digital signatures and the
exchange of keys to encrypt or authenticate content. The definition
of the algorithm processing is based on the NIST FIPS 186-3 for
digital signature, NIST SP800-56A and SEC1 for key agreement, RFC
3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-
3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC
4231 for message authentication code standards. This document
obsoletes RFC 3278.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3278bis-05.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-smime-3278bis-05.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 n05NJinV058422 (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 n05NJiY3058420; 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 n05M5TmH055557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 15:05:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05M5TM3055556; Mon, 5 Jan 2009 15:05:29 -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] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05M5QDS055544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 15:05:27 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Mon, 5 Jan 2009 14:05:24 -0800
To: Tim Polk , S-MIME / IETF
From: Paul Hoffman
Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 4:24 PM -0500 1/5/09, Tim Polk wrote:
>I have had some private discussions with one of the authors (Sean), and we have collaborated on some language that would reflect that discussion. However, I understand that this was a sensitive and somewhat controversial topic on the working group list. I would like the working group to review the proposed RFC Editor Notes for 3850bis and 3851bis, and confirm that these changes are acceptable given the feedback received from the wider Internet community. That is, please consider whether the proposed new text addresses the working group's concerns given that the minimum strength of the mandatory to implements need to be raised.

The new ranges and new text work for me.

What does *not* work for me is this being done as an RFC Editor note. It should be done instead as a new draft before IESG consideration so the whole IETF community can see the changes. The IETF is supposed to be working on transparency, and keeping these out of the Internet Draft hurts that effort.

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 n05LP2J2054069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 14:25:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n05LP2lC054068; Mon, 5 Jan 2009 14:25:02 -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 n05LP0ml054056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jan 2009 14:25:01 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n05LOsIc030165; Mon, 5 Jan 2009 16:24:54 -0500
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id:
Content-Transfer-Encoding: quoted-printable
From: Tim Polk
Subject: 3850bis and 3851bis: proposed changes to cryptographic key sizes
Date: Mon, 5 Jan 2009 16:24:56 -0500
To: S-MIME / IETF
X-Mailer: Apple Mail (2.753.1)
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,

3850bis and 3851bis are tentatively scheduled for discussion on this =20
week's IESG telechat (Thursday, January 8). Those that read the IETF =20=

Last Call email or subscribe to the saag or cfrg mailing lists =20
already know that I have concerns about the cryptographic key sizes =20
specified in these documents (especially the mandate to support 512 =20
bit RSA in 3850bis). While the IETF Last Call was largely silent on =20
this issue, the saag and cfrg feedback indicate that the mandatory to =20=

implements should not include cryptography weaker that 1024 bit RSA, =20
but that the interoperability concerns should be clearly specified.

I have had some private discussions with one of the authors (Sean), =20
and we have collaborated on some language that would reflect that =20
discussion. However, I understand that this was a sensitive and =20
somewhat controversial topic on the working group list. I would like =20=

the working group to review the proposed RFC Editor Notes for 3850bis =20=

and 3851bis, and confirm that these changes are acceptable given the =20
feedback received from the wider Internet community. That is, please =20=

consider whether the proposed new text addresses the working group's =20
concerns given that the minimum strength of the mandatory to =20
implements need to be raised.

Early feedback would be appreciated!

Thanks,

Tim Polk

--------------------

RFC Editor Note for draft-ietf-smime-3850bis

(1) In Section 4.2., Certificate and CRL Signing Algorithms and Key =20
Sizes, please make the following substitution:

OLD:

The following are the RSA key size requirements for S/MIME receiving =20
agents during certificate and CRL signature verification:

0 < key size < 512 : MAY (see Section 6)
512 <=3D key size <=3D 4096 : MUST (see Section 6)
4096 < key size : MAY (see Section 6)

The following are the DSA key size requirements for S/MIME receiving =20
agents during certificate and CRL signature verification:

512 <=3D key size <=3D 1023 : MAY (see Section 6)
1024 =3D key size : SHOULD- (see Section 6)

NEW:

The following are the RSA key size requirements for S/MIME receiving =20
agents during certificate and CRL signature verification:

key size <=3D 1023 : MAY (see Section 6)
1024 <=3D key size <=3D 4096 : MUST (see Section 6)
4096 < key size : MAY (see Section 6)

The following are the DSA key size requirements for S/MIME receiving =20
agents during certificate and CRL signature verification:

key size <=3D 1023 : MAY (see Section 6)
1024 =3D key size : SHOULD- (see Section 6)

(2) In Section 6 Security Considerations, please make the following =20
substitution:

OLD:

The 4096-bit RSA key size requirement for certificate and CRL =20
verification is larger than the 2048-bit RSA key sizes for message =20
signature generation/verification or message encryption/decryption in =20=

[SMIME-MSG] because many Root CAs included in certificate stores have =20=

already issued Root certificates with 4096-bit key. The standard =20
that defines comparable key sizes for DSA is not yet available. In =20
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes =20=

between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only =20
allowed DSA key sizes of 1024 bits. A revision to support larger key =20=

sizes is being developed, and once it is available, implementors =20
ought to support DSA key sizes comparable to the RSA key sizes =20
recommended in this specification.

Today, 512-bit RSA and DSA keys are considered by many experts to be =20
cryptographically insecure.

NEW:

The 4096-bit RSA key size requirement for certificate and CRL =20
verification is larger than the 2048-bit RSA key sizes for message =20
signature generation/verification or message encryption/decryption in =20=

[SMIME-MSG] because many Root CAs included in certificate stores have =20=

already issued Root certificates with 4096-bit key. The standard =20
that defines comparable key sizes for DSA is not yet available. In =20
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes =20=

between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only =20
allowed DSA key sizes of 1024 bits. A revision to support larger key =20=

sizes is being developed, and once it is available, implementors =20
ought to support DSA key sizes comparable to the RSA key sizes =20
recommended in this specification. Further, 4096-bit keys are =20
normally only used by Root certificates and not by subordinate CA =20
certificates; thereby, lengthening the Root CA certificate=92s validity =20=

period.

RSA and DSA keys of less than 1024 bits are now considered by many =20
experts to be cryptographically insecure (due to advances in =20
computing power), and should no longer be used to sign certificates =20
or CRLs. Such keys were previously considered secure, so processing =20
previously received signed and encrypted mail may require processing =20
certificates or CRLs signed with weak keys. Implementations that =20
wish to support previous versions of S/MIME or process old messages =20
need to consider the security risks that result from accepting =20
certificates and CRLs with smaller key sizes (e.g., spoofed =20
certificates) versus the costs of denial of service. If an =20
implementation supports verification of certificates or CRLs =20
generated with RSA and DSA keys of less than 1024 bits, it MUST warn =20
the user. Implementers should consider providing a stronger warning =20
for weak signatures on certificates and CRLs associated with newly =20
received messages than the one provided for certificates and CRLs =20
associated with previously stored messages. Server implementations =20
(e.g., secure mail list servers) where user warnings are not =20
appropriate SHOULD reject messages with weak cryptography.

--- end of RFC Editor Note for draft-ietf-smime-3850bis ---

RFC Editor Note for draft-ietf-smime-3851bis

(1) In Section 4.2 Signature Generation, please make the following =20
substitution:

From:

The following are the requirements for an S/MIME agent generated RSA =20
signatures:

512 <=3D key size < 1024 : MAY (see Security Considerations)
1024 <=3D key size <=3D 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)

The following are the requirements for an S/MIME agent generated DSA =20
signatures:

512 <=3D key size <=3D 1023 : MAY (see Security Considerations)
1024 =3D key size : SHOULD- (see Security Considerations)

To:

The following are the requirements for an S/MIME agent generated RSA =20
signatures:

key size <=3D 1023 : MAY (see Security Considerations)
1024 <=3D key size <=3D 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)

The following are the requirements for an S/MIME agent generated DSA =20
signatures:

key size <=3D 1023 : MAY (see Security Considerations)
1024 =3D key size : SHOULD- (see Security Considerations)

(2) In Section 4.3 Signature Verification, please make the following =20
substitution:

OLD:

The following are the requirements for S/MIME receiving agents during =20=

signature verification of RSA signatures:

512 <=3D key size <=3D 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)

The following are the requirements for S/MIME receiving agents during =20=

signature verification of DSA signatures:

512 <=3D key size <=3D 1023 : MAY (see Security Considerations)
1024 =3D key size : SHOULD- (see Security Considerations)

NEW:

The following are the requirements for S/MIME receiving agents during =20=

signature verification of RSA signatures:

key size <=3D 1023 : MAY (see Security Considerations)
1024 <=3D key size <=3D 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)

The following are the requirements for S/MIME receiving agents during =20=

signature verification of DSA signatures:

key size <=3D 1023 : MAY (see Security Considerations)
1024 =3D key size : SHOULD- (see Security Considerations)

(3) In Section 6 Security Considerations, please make the following =20
substitution:

OLD:

Today, 512-bit RSA and DSA keys are considered by many experts to be =20
cryptographically insecure.

Using weak cryptography in S/MIME offers little actual security over =20
sending plaintext. However, other features of S/MIME, such as the =20
specification of AES and the ability to announce stronger =20
cryptographic capabilities to parties with whom you communicate, =20
allow senders to create messages that use strong encryption. Using =20
weak cryptography is never recommended unless the only alternative is =20=

no cryptography. When feasible, sending and receiving agents SHOULD =20
inform senders and recipients of the relative cryptographic strength =20
of messages.

NEW:

Using weak cryptography in S/MIME offers little actual security over =20
sending plaintext. However, other features of S/MIME, such as the =20
specification of AES and the ability to announce stronger =20
cryptographic capabilities to parties with whom you communicate, =20
allow senders to create messages that use strong encryption. Using =20
weak cryptography is never recommended unless the only alternative is =20=

no cryptography.

RSA and DSA keys of less than 1024 bits are now considered by many =20
experts to be cryptographically insecure (due to advances in =20
computing power), and should no longer be used to protect messages. =20
Such keys were previously considered secure, so processing previously =20=

received signed and encrypted mail will often result in the use of =20
weak keys. Implementations that wish to support previous versions of =20
S/MIME or process old messages need to consider the security risks =20
that result from smaller key sizes (e.g., spoofed messages) versus =20
the costs of denial of service. If an implementation supports =20
verification of digital signatures generated with RSA and DSA keys of =20=

less than 1024 bits, it MUST warn the user. Implementers should =20
consider providing different warnings for newly received messages and =20=

previously stored messages. Server implementations (e.g., secure =20
mail list servers) where user warnings are not appropriate SHOULD =20
reject messages with weak signatures.

--- end of RFC Editor Note for draft-ietf-smime-3851bis ---

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 n05IFVK4027133 (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 n05IFV7f027132; Mon, 5 Jan 2009 11:15:31 -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 n05EetuG096013 (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 n05EetdR096012; 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 n05EBY8q094113 (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 n05EBYMV094111; 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 n05DRKP3091711 (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 n05DRKMd091709; 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 n057kQ1T073939 (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 n057kQqE073938; 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 n057bq5u073695 (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 n057bqeH073693; 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 n04MYZx6055363 (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 n04MYZ3Q055361; 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 n04MYNpR055337 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 n04MUS0p055191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 15:30:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n04MUShH055190; 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 n04M2SU6054050 (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 n04M2SMe054048; 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 n04KeJ9p050767 (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 n04KeJ7N050766; 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 n04KOb4L050325 (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 n04KObef050323; 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 n04JBJHt047548 (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 n04JBJ8Z047547; 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 n047TvT2021249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2009 00:29:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n047TupB021248; 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 n02FagHF036840 (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 n02Fag1O036838; 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 n02EfVkv034476 (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 n02EfVZj034475; 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 n01JmhPw095180 (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 n01Jmh8b095177; 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 n01JmfdP095154 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 n01JdraA094547 (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 n01JdrPG094545; 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 n01JU0dK093881 (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 n01JU0RY093877; 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 n01JTmav093844 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 n01Higb7086887 (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 n01Hig7k086882; 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 n01HKGos085008 (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 n01HKG1B085006; 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 n01GowVU082693 (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 n01GovJl082691; 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 n01FqYVU077523 (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 n01FqYju077522; 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 n01FF3II074324 (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 n01FF3Pj074322; 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 n01FEp6C074280 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 n01Be5WX053633 (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 n01Be5LA053632; 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 n01BdrH6053588 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 n01BIANN052421 (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 n01BIAuj052418; 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 n01BBcIS051836 (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 n01BBb2R051834; 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.