Subject: Lost my number? )

From: <[email-masked]>
Date: Thu, 1 Jan 2009 00:41:20 -0800 (PST)

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 mBVJKaAX000152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVJKaQE000151; Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJKPvX000128; Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Wed, 31 Dec 2008 14:20:23 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: Aclq5IgC5ZANbzGKQ/GkJqeRHNnrQgAkuFSw
References: <[email-masked]> <[email-masked]> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]>
From: "Kemp, David P."
To: , , ,
X-OriginalArrivalTime: 31 Dec 2008 19:17:00.0562 (UTC) FILETIME=[5B1E9F20:01C96B7C]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Just to be precise, past MD5 certificates should be safe as long as
there
are no second-preimage attacks. I have no idea* whether there are any
computational shortcuts to finding a second preimage (where both the
hashed data and its digest value are known) relative to finding a
preimage
(where only the digest value is known), but in principle second-preimage
attacks might be feasible sooner.

Dave

* for example, http://www.springerlink.com/content/yut517362112765h/
indicates
that 1 in 2^56 messages may be "weak" against a specified attack on MD4.
What is needed is an attack on MD5 where many or all messages are
"weak".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jeffrey Hutzelman
Sent: Tuesday, December 30, 2008 6:46 PM
To: Santosh Chokhani; Peter Hesse; RL 'Bob' Morgan; Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

--On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani=20
wrote:

> Since the attack is computing pre-image, I suspect that past MD5
> certificates are safe until the attack was devised.

The attack does _not_ involve computing a preimage; it involves
computing a=20
colliding pair one of which has a prefix which is predictable but not=20
controllable, followed by a controllable component consisting of some=20
minimum number of bits followed by at least three aligned message
blocks.=20
What makes existing certificates safe is that there are no known
preimage=20
attacks against MD5, couple with limitations of the technique used to=20
construct the colliding pair.

However, there is a limit to how "safe" existing certificates are,
because=20
the attack does not require anything that was not known 3-4 years ago.
The=20
only change is that with the latest techniques for computing collisions,
it=20
is possible to do so in a short enough time to be able to predict the=20
validity and serial number that will be used by the issuer with fairly
high=20
probability.

-- 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 mBVIuUAC098365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:56:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIuUYO098364; Wed, 31 Dec 2008 11:56:30 -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 mBVIuSu2098351 for ; Wed, 31 Dec 2008 11:56:29 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4657 invoked from network); 31 Dec 2008 18:56:51 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:56:51 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:56:51 -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: Wed, 31 Dec 2008 13:56:27 -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: AclreTiLOa9qi39USCibRTE4UToJHQAABQ1A
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Timothy J. Miller"
Cc: "Dr Stephen Henson" , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

You have some time there and work with client vendors to implement
SHA-256 and next generation SHA.

I would support a random value extension if clients checked for it.

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]]=20
Sent: Wednesday, December 31, 2008 1:54 PM
To: Santosh Chokhani
Cc: Dr Stephen Henson; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Santosh Chokhani wrote:

> So, if you are relying on CAs, why not ask them to switch to SHA-1 as
> opposed to adding more software to the CA. SHA-1 is purely a
> configuration item for the CA deployments.

Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject=20
to a similar collision generation attack, and the presence of=20
unpredictable data in the cert will defeat it as well.

Just trying to be proactive here.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIsXSE098229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:54:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIsXVY098228; Wed, 31 Dec 2008 11:54:33 -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 mBVIsWLG098215; Wed, 31 Dec 2008 11:54: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 mBVIsUIg021783; Wed, 31 Dec 2008 13:54:31 -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 mBVIsUrK021773; Wed, 31 Dec 2008 13:54:30 -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; Wed, 31 Dec 2008 13:54:30 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:53:59 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: Dr Stephen Henson , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106060408020209040905"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Santosh Chokhani wrote:

> So, if you are relying on CAs, why not ask them to switch to SHA-1 as
> opposed to adding more software to the CA. SHA-1 is purely a
> configuration item for the CA deployments.

Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject
to a similar collision generation attack, and the presence of
unpredictable data in the cert will defeat it as well.

Just trying to be proactive here.

-- Tim

--------------ms010106060408020209040905
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
Fw0wODEyMzExODUzNTlaMCMGCSqGSIb3DQEJBDEWBBRvm0ZUBx2kUMXPZMdTcjy9VsI7hTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgFfgtFy7Di89XncxZPvVvOWVa1zy05iBeqhstrmEKD0MBObvNiR0lbvnC/Xt
VQOKE9jnfS6QSzzE2Iik8Y92fDAhbOWgKdlWcxV9q4+qHjf4Q9aefulpw1SObVxtCcHGhSCt
i64UPYyummro3guFQumjkhIxhu8Wcy9LbvN3z1yrAAAAAAAA
--------------ms010106060408020209040905--

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 mBVIoH9l097944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:50:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIoGos097942; Wed, 31 Dec 2008 11:50:16 -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 mBVIoEco097928 for ; Wed, 31 Dec 2008 11:50:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4597 invoked from network); 31 Dec 2008 18:50:37 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:50:37 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:50:37 -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: Wed, 31 Dec 2008 13:50:13 -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: AclrdpWRZ2DsZT93SYeylkbr3Wg+mAAAUebw
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Timothy J. Miller"
Cc: "Dr Stephen Henson" , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

These things need to be thought through.

If all the CAs did this, it might work. But, what if the client side
was looking for junk in the certificate as evidence of collision?

Also, client will not enforce this.

So, if you are relying on CAs, why not ask them to switch to SHA-1 as
opposed to adding more software to the CA. SHA-1 is purely a
configuration item for the CA deployments.

I just find that all three mail lists are getting work out and real
message and analysis is getting lost.

For example, folks are still posting misinformation that self-signed
roots have a hash problem. Signatures on self-signed roots are
gratuitous from security viewpoint. So, we do not want to cry wolf and
undertaken replacing roots which will be a humongous waste to time and
money. Signatures and hence hash used to sign these do not matter. =20

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]]=20
Sent: Wednesday, December 31, 2008 1:35 PM
To: Santosh Chokhani
Cc: Dr Stephen Henson; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Santosh Chokhani wrote:
> I am a bit concerned about random goo when random goo is one of the
> things the attacker uses to cause collision. This may limit human or
> machine's ability to discern mischief.

I don't see how, if the random goo is added by the CA. It defeats=20
chosen prefix attacks as a class.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIZgLv096979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:35:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIZgp6096976; Wed, 31 Dec 2008 11:35:42 -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 mBVIZesj096966; Wed, 31 Dec 2008 11:35:40 -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 mBVIZdvc006788; Wed, 31 Dec 2008 13:35:40 -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 mBVIZdEj006785; Wed, 31 Dec 2008 13:35:39 -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; Wed, 31 Dec 2008 13:35:39 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:35:09 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: Dr Stephen Henson , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010007000707070000040106"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Santosh Chokhani wrote:
> I am a bit concerned about random goo when random goo is one of the
> things the attacker uses to cause collision. This may limit human or
> machine's ability to discern mischief.

I don't see how, if the random goo is added by the CA. It defeats
chosen prefix attacks as a class.

-- Tim

--------------ms010007000707070000040106
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
Fw0wODEyMzExODM1MDlaMCMGCSqGSIb3DQEJBDEWBBQ7wSCe4F6a7ye+v4kS0uvOGSEZxjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgCTIqWUo25RX2p72ZoyshHyXDNPdtnFa2cGv0bRgIZSCX0rIi5+1Nl8n3imi
L3lCMkQOeE0Ai3QU62e1BzsBzXl4VavVhoeb8JHhzeTZAdrXmxQCJ48CB4R1k+TKB8mtkCCT
E1FJ8rPqf9EeE4BVdvHvPSb8zf3mUy3iG4rA9D7zAAAAAAAA
--------------ms010007000707070000040106--

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 mBVIYbmG096919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:34:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIYbIw096918; Wed, 31 Dec 2008 11:34:37 -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 mBVIYZ0D096908; Wed, 31 Dec 2008 11:34:35 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYY60003982; Wed, 31 Dec 2008 13:34:35 -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 mBVIYYd0003979; Wed, 31 Dec 2008 13:34:34 -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; Wed, 31 Dec 2008 13:34:34 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:34:04 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Dr Stephen Henson
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406060900010800080503"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Timothy J. Miller wrote:
> Dr Stephen Henson wrote:
>> Mike wrote:
>>> I sent my last message a bit too hastily. Other ideas that I was
>>> contemplating should have been mentioned including:
>>>
>>> - remove any unrecognized extensions
>>> - remove tumors
>>>
>>> Those could potentially cause problems if for some reason they were
>>> actually needed. This one, though, shouldn't cause trouble:
>>>
>>> - add a private EKU with a random number (or two) in the OID
>>>
>>> That would not mess up the serial number scheme in use or modify the
>>> subject name as has been suggested.
>>>
>>
>> Or add a non-critical extension with some randomness in it...
>
> Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce
> 55} or should I? :)

draft-01 already: Make that id-ce-magicNumber instead. :)

-- Tim

--------------ms070406060900010800080503
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
Fw0wODEyMzExODM0MDRaMCMGCSqGSIb3DQEJBDEWBBSSJNMK3zrvAhp1fLThyKuCS2ZbzDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgChOMbV+0oDSDKO7kDjIuxQIjRDbYZag6cll5l/fgLT0BVA+ko8npPtOmf1v
ctmCWIwx3wUmGBqLvXlnZIJ17XPwuT8Pkkqwte0q7M4aY3HW0J7UICoVIi9PXBsV75NklUR9
nh8lnb3TROTWQO2G2MG/8Z7Po5Sw1wOvBlDbyElIAAAAAAAA
--------------ms070406060900010800080503--

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 mBVIUkVg096658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:30:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIUjbQ096657; Wed, 31 Dec 2008 11:30:45 -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 mBVIUiF3096646; Wed, 31 Dec 2008 11:30:44 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUhxA026624; Wed, 31 Dec 2008 13:30:44 -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 mBVIUh7u026614; Wed, 31 Dec 2008 13:30:43 -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; Wed, 31 Dec 2008 13:30:43 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:30:13 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Dr Stephen Henson
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[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="------------ms060500070900000409080503"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Dr Stephen Henson wrote:
> Mike wrote:
>> I sent my last message a bit too hastily. Other ideas that I was
>> contemplating should have been mentioned including:
>>
>> - remove any unrecognized extensions
>> - remove tumors
>>
>> Those could potentially cause problems if for some reason they were
>> actually needed. This one, though, shouldn't cause trouble:
>>
>> - add a private EKU with a random number (or two) in the OID
>>
>> That would not mess up the serial number scheme in use or modify the
>> subject name as has been suggested.
>>
>
> Or add a non-critical extension with some randomness in it...

Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce
55} or should I? :)

-- Tim

--------------ms060500070900000409080503
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
Fw0wODEyMzExODMwMTNaMCMGCSqGSIb3DQEJBDEWBBTDOGnW2taEtjPNTda+B7sp3jwHXjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgI4Tiunxma0T7GovwYWUekJusn0Fg6S544dlebV3nxswPVkGqdvuGRb4yaBq
qYonL0ehGR+ZMi1kFYNOLd0bBOibJOtHdubkqmjHMBENsjbiaUnFwd8pN4NW0GIinVLnUTYa
1vfzSaor2vdmDWTBBGF8QAXJPFF76ZsLkkqoz8BJAAAAAAAA
--------------ms060500070900000409080503--

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 mBVIOWQo096305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIOWL5096303; Wed, 31 Dec 2008 11:24:32 -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 mBVIOKme096278; Wed, 31 Dec 2008 11:24:31 -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 mBVIOK0d010078; Wed, 31 Dec 2008 13:24:20 -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 mBVIOKfI010073; Wed, 31 Dec 2008 13:24: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; Wed, 31 Dec 2008 13:24:20 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 12:23:50 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: Mike , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010602050007000404020402"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

How about adding an otherName to the SAN? You'd need an OID for random
data though.

Or the CA could insert a method 4 UUID as a URI in the SAN. That's
intentionally random. This might upset anyone wanting to use UUIDs as
unique names, though (and these people do exist :).

Just thinking out loud.

-- Tim

Santosh Chokhani wrote:
> Private EKU could cause problems if EKU is not otherwise present in the
> certificate.
>
> The certificate may not be usable for intended purpose. Not all clients
> may recognize "any key purpose" as intended by 5280.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Mike
> Sent: Wednesday, December 31, 2008 12:50 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
> CAcertificate
>
>
> I sent my last message a bit too hastily. Other ideas that I was
> contemplating should have been mentioned including:
>
> - remove any unrecognized extensions
> - remove tumors
>
> Those could potentially cause problems if for some reason they were
> actually needed. This one, though, shouldn't cause trouble:
>
> - add a private EKU with a random number (or two) in the OID
>
> That would not mess up the serial number scheme in use or modify the
> subject name as has been suggested.
>
> Mike
>
>
> I wrote:
>> There is a simple fix -- a CA can just reorder the extensions prior
>> to issuing a certificate.
>>
>> Mike
>

--------------ms010602050007000404020402
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
Fw0wODEyMzExODIzNTBaMCMGCSqGSIb3DQEJBDEWBBTEu3+INXFh8y7RIME+TF+hrvAoaTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgFUNkYNyIak1Rk2H6NPqM7XEBS4j05b8blOT9+hLnMM2Lwb+t6eFS8jW88JJ
MaI6+q3G3oh7PiX3BXiOI8IxlNBAi0a6kegxF9sFnt7Kzrw6Tw8OvefCiDISs8QEWbTFv49g
ISeuzouWk+0O/27KhDbO0Y+JG4BzqQeu4tCJRnLnAAAAAAAA
--------------ms010602050007000404020402--

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 mBVIO1q3096256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:01 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIO18s096253; Wed, 31 Dec 2008 11:24:01 -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 mBVINoep096228 for ; Wed, 31 Dec 2008 11:24:00 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4386 invoked from network); 31 Dec 2008 18:24:12 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:24:12 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:24:12 -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: Wed, 31 Dec 2008 13:23: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: AclrdI9/sOJPqIrSRxWmhrDCQYi/6wAADprw
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Dr Stephen Henson" ,
Cc: , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I am a bit concerned about random goo when random goo is one of the
things the attacker uses to cause collision. This may limit human or
machine's ability to discern mischief.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dr Stephen Henson
Sent: Wednesday, December 31, 2008 1:12 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Mike wrote:
>=20
> I sent my last message a bit too hastily. Other ideas that I was
> contemplating should have been mentioned including:
>=20
> - remove any unrecognized extensions
> - remove tumors
>=20
> Those could potentially cause problems if for some reason they were
> actually needed. This one, though, shouldn't cause trouble:
>=20
> - add a private EKU with a random number (or two) in the OID
>=20
> That would not mess up the serial number scheme in use or modify the
> subject name as has been suggested.
>=20

Or add a non-critical extension with some randomness in it...

Steve.
--=20
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

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 mBVIBfMZ095598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:11:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIBfE2095596; Wed, 31 Dec 2008 11:11:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay10.mail.uk.clara.net (relay10.mail.uk.clara.net [80.168.70.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIBTXB095574; Wed, 31 Dec 2008 11:11:40 -0700 (MST) (envelope-from [email-masked])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49616 helo=[192.168.7.8]) by relay10.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1LI5XR-0000nh-An; Wed, 31 Dec 2008 18:11:26 +0000
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 18:11:35 +0000
From: Dr Stephen Henson
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: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Mike wrote:
>
> I sent my last message a bit too hastily. Other ideas that I was
> contemplating should have been mentioned including:
>
> - remove any unrecognized extensions
> - remove tumors
>
> Those could potentially cause problems if for some reason they were
> actually needed. This one, though, shouldn't cause trouble:
>
> - add a private EKU with a random number (or two) in the OID
>
> That would not mess up the serial number scheme in use or modify the
> subject name as has been suggested.
>

Or add a non-critical extension with some randomness in it...

Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

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 mBVI3Gl2095202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:03:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVI3GL8095200; Wed, 31 Dec 2008 11:03:16 -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 mBVI3Esm095187 for ; Wed, 31 Dec 2008 11:03:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4249 invoked from network); 31 Dec 2008 18:03:37 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:03:37 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:03:37 -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: Wed, 31 Dec 2008 13:03:13 -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: AclrcaZvjthE5F+NRLKwI78nj+9Z5AAACsDQ
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Mike" ,
Cc: , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Private EKU could cause problems if EKU is not otherwise present in the
certificate.

The certificate may not be usable for intended purpose. Not all clients
may recognize "any key purpose" as intended by 5280.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mike
Sent: Wednesday, December 31, 2008 12:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

I sent my last message a bit too hastily. Other ideas that I was
contemplating should have been mentioned including:

- remove any unrecognized extensions
- remove tumors

Those could potentially cause problems if for some reason they were
actually needed. This one, though, shouldn't cause trouble:

- add a private EKU with a random number (or two) in the OID

That would not mess up the serial number scheme in use or modify the
subject name as has been suggested.

Mike

I wrote:
> There is a simple fix -- a CA can just reorder the extensions prior
> to issuing a certificate.
>=20
> Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVHoaIH094527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:50:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVHoabT094526; Wed, 31 Dec 2008 10:50:36 -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 mBVHoPh7094500; Wed, 31 Dec 2008 10:50:35 -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 88E0F1B777; Wed, 31 Dec 2008 12:50:24 -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 B7C771B787; Wed, 31 Dec 2008 12:50:19 -0500 (EST)
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 09:49:45 -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: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 80508BAC-D763-11DD-889F-F83E113D384A-38729857!a-sasl-quonix.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I sent my last message a bit too hastily. Other ideas that I was
contemplating should have been mentioned including:

- remove any unrecognized extensions
- remove tumors

Those could potentially cause problems if for some reason they were
actually needed. This one, though, shouldn't cause trouble:

- add a private EKU with a random number (or two) in the OID

That would not mess up the serial number scheme in use or modify the
subject name as has been suggested.

Mike

I wrote:
> There is a simple fix -- a CA can just reorder the extensions prior
> to issuing a certificate.
>
> Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4LsR091876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:04:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVH4Ln6091874; Wed, 31 Dec 2008 10:04:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4AP1091758; Wed, 31 Dec 2008 10:04:20 -0700 (MST) (envelope-from [email-masked])
Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id A7EB98CD08; Wed, 31 Dec 2008 12:04:09 -0500 (EST)
Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id AD05D8CCFD; Wed, 31 Dec 2008 12:04:05 -0500 (EST)
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 09:03:37 -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: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 0A5CA3DC-D75D-11DD-B70C-5720C92D7133-38729857!a-sasl-fastnet.pobox.com
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Mike

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFbCgM087822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:37:12 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFbC5s087820; Wed, 31 Dec 2008 08:37:12 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVFaxcB087773 for ; Wed, 31 Dec 2008 08:37:10 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 28690 invoked from network); 31 Dec 2008 15:36:57 -0000
Received: from [email-masked] by sottccs1.entrust.com with EntrustECS-Server-8.0;31 Dec 2008 15:36:57 -0000
Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 31 Dec 2008 15:36:56 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="--=_NextPart_EE_103656811.38200976"
Date: Wed, 31 Dec 2008 10:36:56 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclrXBEEqsU/Y6e/ROuPhuoyz8ZfcAAAQNmw
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
From: "Tim Moses"
To: "Timothy J. Miller"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

----=_NextPart_EE_103656811.38200976
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Colleagues - It has been confirmed that no EV issuer is signing certific=
ates with MD5. Also, EV certificates cannot be issued by an automated p=
rocess, putting another obstacle in the path of an attacker. All the be=
st. Tim.

Tim Moses
+1 613 270 3183

-----Original Message-----
From: owner-ietf-smime=40mail.imc.org =5Bmailto:owner-ietf-smime=40mail.=
imc.org=5D On Behalf Of Timothy J. Miller
Sent: Wednesday, December 31, 2008 10:18 AM
To: Santosh Chokhani
Cc: ietf-pkix=40imc.org; ietf-smime=40imc.org; cfrg=40irtf.org; saag=40i=
etf.org
Subject: Re: =5BCfrg=5D =5Bsaag=5D Further MD5 breaks: Creating a rogue C=
Acertificate

Santosh Chokhani wrote:
> One would think we want to start using SHA-1 or even SHA256 (assuming=20
> client vendors implement SHA256 ASAP) and ask the CAs emanating from=20
> commercial roots to perform responsible I&A before issuing certificate=
s.

Speaking of I&A, I found it interesting to note that the CA/Browser foru=
m guidelines for EV certs allows (but recommends against) MD5 until 2010=
=2E

The spot check of EV issuers I did yesterday didn't turn up anyone actua=
lly using MD5, but I didn't have all of 'em available.

-- Tim

----=_NextPart_EE_103656811.38200976
Content-Type: application/pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCTAHBgUrDgMCGjCABgkqhkiG9w0BBwEAAKCCIIIwggKf
MIICCKADAgECAgRGJ7vgMA0GCSqGSIb3DQEBBQUAMCwxCzAJBgNVBAYTAkNBMR0wGwYDVQQK
ExRFbnRydXN0IFRlY2hub2xvZ2llczAeFw0wODA1MDcxMzA4MzlaFw0xMTA1MDcxMzM4Mzla
MDIxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczCB
nTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA0IBgoGWlwptmAbxopaoSELaZIvJHlWg+vqcq
kQlA6mSAzTEHQl79k5aUq4cPZQTK5SnsUoY3aPN8IyTN8+SDmIJ/3qwFvxG1Xkbi1UDo6qB/
TR1zwBoxpz7iL8XH5gLWSaijFab+bMeTamSeL05l0JjF0AoAmxnwAjU7Zl4kdWkCAQOjgckw
gcYwHQYDVR0OBBYEFAUkiCBOsLJRzMuh2elnJIbV+bBFME4GA1UdHwRHMEUwQ6BBoD+kPTA7
MQswCQYDVQQGEwJDQTEdMBsGA1UEChMURW50cnVzdCBUZWNobm9sb2dpZXMxDTALBgNVBAMT
BENSTDEwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFDGPKjFGWl7oabci0fgBq6xQXgF1MAwG
A1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCAIEwDQYJKoZIhvcNAQEFBQAD
gYEAbdDF5a/A+vjthvR7ofXzM3UxI/62yW9yJPzQ7sN1AS9zKgPB9Nm4tySDwSeFvqQ1/KOv
JTEeYABGRaZ1YrTXc2mFhTlcLQAZ16DsS2VxnKqhEVWq4JaUaJAe9qvKvdkvpDieKQMkfM0c
WZCa9b396rZKqSd+j86yP6FauYSrw6wwggLfMIICSKADAgECAgRGS07GMA0GCSqGSIb3DQEB
BQUAMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQcm9kMB4X
DTA3MDUyMjE0NTQ0N1oXDTEwMDUyMjE1MjQ0N1owLDELMAkGA1UEBhMCQ0ExHTAbBgNVBAoT
FEVudHJ1c3QgVGVjaG5vbG9naWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5SPAE
WITHCc04wRiDaJpJY8ZF7bCJ1ohhSyKRA2ouJ+sjRMqzfxXcxQTKuE4GQg1dvZjvmmZJq5KZ
71yZnvK+Kb1ixXP1y/zAy6CiiatTPrf8SNzXpSDon3VdKo8zuKQ6ELKaWP3nK4O4eOiXdmfn
a2bOLzFi7TpKICfieMOdlQIDAQABo4IBCjCCAQYwHQYDVR0OBBYEFDGPKjFGWl7oabci0fgB
q6xQXgF1MIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9MQswCQYDVQQGEwJjYTEQMA4GA1UEChMH
ZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UEAxMEQ1JMMTA5oDegNYYzZmlsZTovL1xc
U09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2NhX2NybGZpbGUuY3JsMAsGA1UdDwQEAwIB
BjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAMBgNVHRMEBTADAQH/MBkGCSqG
SIb2fQdBAAQMMAobBFY3LjEDAgCBMA0GCSqGSIb3DQEBBQUAA4GBAEnSrabNwGiiZNjhIFce
7VctEE5uR6RaADbc6hszcn50pYoliCY5T53dUpOvznUuDX0HWFfH+YXl3Isol2p0DbSSAFNv
8OWyEAd2SoYRinBNpMOyQlrTWt5FBiCB2dglbxx/I2eyTqr5COy8u/ijLKvVn00yBf3f1kCw
d+//jQluMIIC7TCCAlagAwIBAgIEMkbEozANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJD
QTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNOTgwODE5MTkxMjA2
WhcNMTgwODE5MTk0MjA2WjAyMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8G
A1UECxMIQnVzaW5lc3MwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBANCAYKBlpcKbZgG8
aKWqEhC2mSLyR5VoPr6nKpEJQOpkgM0xB0Je/ZOWlKuHD2UEyuUp7FKGN2jzfCMkzfPkg5iC
f96sBb8RtV5G4tVA6Oqgf00dc8AaMac+4i/Fx+YC1kmooxWm/mzHk2pkni9OZdCYxdAKAJsZ
8AI1O2ZeJHVpAgEDo4IBEDCCAQwwEQYJYIZIAYb4QgEBBAQDAgAHMFQGA1UdHwRNMEswSaBH
oEWkQzBBMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5l
c3MxDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMTk5ODA4MTkxOTEyMDZagQ8yMDE4MDgx
OTE5MTIwNlowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFAUkiCBOsLJRzMuh2elnJIbV+bBF
MB0GA1UdDgQWBBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/MBkGCSqGSIb2
fQdBAAQMMAobBFY0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4GBAJg+gIo2VG7EqPRBAJ3Q6sho
xP/8pMCk/3UyKbuu4En4aRn+5kAXmjhqJR98uZsR89G5S1I68pn+xhg6FK3gNgC/OLOZ6bRG
ABcQGkRov8vvIoJPRRN3JYcAyJSRykY2CZhPsW99pO69qlxS4lRIfIFuflaXs7PY2LTzftsO
6o1cMIIDJTCCAo6gAwIBAgIERktOCjANBgkqhkiG9w0BAQUFADAuMQswCQYDVQQGEwJjYTEQ
MA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDAeFw0wNzA1MTYxODAxMzhaFw0xNzA1
MTYxODMxMzhaMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQ
cm9kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpd6zp2+OYdJe2JvS/+IlSax3c1GWf
xpm/6G11szZ9iRTy0UCpcVZ7e7pEnu/ySNSDN0CLFfj2XMnC2b5YgnuL9/rDz+jVCylLJbuJ
HjpYmGWQqG1vbmSUBQeH9TCdTHEqScibjV77r81cfyOpjWe0iETErEUlq5jsnuZOYKkuXQID
AQABo4IBTjCCAUowEQYJYIZIAYb4QgEBBAQDAgAHMIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9
MQswCQYDVQQGEwJjYTEQMA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UE
AxMEQ1JMMTA5oDegNYYzZmlsZTovL1xcU09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2Nh
X2NybGZpbGUuY3JsMCsGA1UdEAQkMCKADzIwMDcwNTE2MTgwMTM4WoEPMjAxNzA1MTYxODMx
MzhaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAdBgNV
HQ4EFgQU0eQ7z6drsAXxsf5suRJkMtCUG7owDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAE
EDAOGwhWNy4xOjQuMAMCBJAwDQYJKoZIhvcNAQEFBQADgYEAWATjTT62BcA4MaxLVJTG5alA
BUYnKzbtbpoZrckpmEVZfcoLooJcgRq58DeGVihhvl9lfUOE3YIQUFxDXA6svFD8Fn99y3Iy
RGM+itL/rRdbSAlH2Xa6HLBhjTJff9oa6n67WW/RU0106O8jqS3bcVjWeI0WLh7LKxxHnGz3
TFUwggMwMIICmaADAgECAgQ4xeeqMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkNBMRAw
DgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczAeFw0wNDA5MjkxNzExNThaFw0w
ODA5MjkxNzQxNThaMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQL
EwdSIGFuZCBEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvIeIjfoD5D86sD8C
ehB+kVhYJTL+VuaUZiVijGevUTlnUAwy1WpOYVpFCa8VK116TJ+o99axN1jMbsVBYfRzFk9S
Wl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoPqXhCwRlkvupreNlFx3FFk2Uf5jG/i9SCP925
OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BWUIgtRwFvzbh1J57+gNdHxMYLZmvj5saS
1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuVtKp17pzhwicoWAGKXrKeDRWDYeZB
TJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4HPMIHMMB0GA1UdDgQWBBTz8Cwo
5jmnNBmrmpGopmZAkpzicTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAO
BgNVBAoTB0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMQ0wCwYDVQQDEwRDUkwxMAsGA1Ud
DwQEAwIBBjAfBgNVHSMEGDAWgBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/
MBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgCBMA0GCSqGSIb3DQEBBQUAA4GBAI8B1Aa8TTla
mxl1BgP6ch4CZUEADT/1xNwEaPveZFajVrURlnKqMfDQ704aNc2qFnLHJDI3dS49vJEJ8LsK
Hvd7sf6WqRCuGkF3D8qsIWKxBK6muWdSfKAYWLB/4wDm2CcZDyXt/A3OYFjMzQ5pVBKeAXNA
k6fZ32SGLVNvVqc/MIIDMDCCApmgAwIBAgIESCCkSzANBgkqhkiG9w0BAQUFADAyMQswCQYD
VQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNMDgwOTI0
MTQzNjA0WhcNMTIwOTI0MTUwNjA0WjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz
dDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALyH
iI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyfqPfWsTdY
zG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZRcdxRZNl
H+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824dSee/oDX
R8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c4cInKFgB
il6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOBzzCBzDAdBgNV
HQ4EFgQU8/AsKOY5pzQZq5qRqKZmQJKc4nEwVAYDVR0fBE0wSzBJoEegRaRDMEExCzAJBgNV
BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UEAxME
Q1JMMTALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUBSSIIE6wslHMy6HZ6WckhtX5sEUwDAYD
VR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG9w0BAQUFAAOB
gQDHUhDfQdNFmborkeOSyqtTmpiIESBES6KULodyCmdHbcoV4L1H5vpjBO0HdUx+YXlIZxUj
pTKDv2mowbCAdcWihfW3LjY+3RoqoMu2iR8nSDexR+TesS8drRF9Mrmy30/ddj+sneR7KeaG
KL8WGcZBDmxGIvoOaCYGuxsgrC9/LzCCA2gwggLRoAMCAQICBEZLTsUwDQYJKoZIhvcNAQEF
BQAwLjELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QwHhcN
MDcwNTIyMTQ0MTIxWhcNMTAwNTIyMTUxMTIxWjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMH
RW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALyHiI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyf
qPfWsTdYzG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZ
RcdxRZNlH+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824
dSee/oDXR8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c
4cInKFgBil6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOCAQow
ggEGMB0GA1UdDgQWBBTz8Cwo5jmnNBmrmpGopmZAkpzicTCBjQYDVR0fBIGFMIGCMEWgQ6BB
pD8wPTELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QxDTAL
BgNVBAMTBENSTDEwOaA3oDWGM2ZpbGU6Ly9cXFNPVFRQUk9EQ0FcQ1JMXHByb2RfZW50cnVz
dF9jYV9jcmxmaWxlLmNybDALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU0eQ7z6drsAXxsf5s
uRJkMtCUG7owDAYDVR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkq
hkiG9w0BAQUFAAOBgQCQBw6L+mclwk7Z64xW4jbrS1CZpTHFGNmVuow0GbxBdFWHsDNE9H0s
4AUS59qW2T8JQRhm062vhZwpj29bCkOwDgciGq2POfOachGypOnV09x5Dcs3s+5M7c3gpbEP
dcO8G7GPIcociDNPPj+Kd8ceoMvcZySp22u4MWuI1bOxyjCCA28wggJXoAMCAQICBEZD+x4w
DQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNV
BAsTB1IgYW5kIEQwHhcNMDgxMDIxMTMyOTM2WhcNMDkwNDIxMTM1OTM2WjBVMQswCQYDVQQG
EwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEiMA4GA1UEBRMHMDUw
NDA2NzAQBgNVBAMTCVRpbSBNb3NlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0gtt
TXg2dN9WsLP92LJQzIYPjdXOXewCcdviTglJfIFKO+RU3O76TPR6pKsZNgPADZL6Q0QHo5I2
ygrRBXCnMOH7xKutmI2QujgX5FW6kEFrHPRom65/XkuMXNW57BjRt+C4hXKU8fHp6WaiKhOM
It2WG2jTHU8IYcYnWiiK4dMCAwEAAaOB7jCB6zALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EV
dGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQswCQYDVQQGEwJD
QTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMFQ1JMNDIw
HwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFMXxKqPWd83GEHAC
aXkPSw+P2UHrMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZI
hvcNAQEFBQADggEBAClPCYWYRjj5Q0uz74Ldr4FhH4KYkt35rgTXAWR9T2cSLbq6wssHiBS5
YGmM9lsYkQHXc9yPji03n9/Xco/0VjkZY2Fmc03f+3+6WkvvnfAbZFV0HfK1IR/i3hKC5vp9
D8DjcoSXOGwucv7L9iKARJ6jJSXIHl/fTIkt1gqtpfcSAesOhq9u/XO+zxGD8GL1tKF5k1F9
0GN5MQd7HNAZsrwEBDWAO7P3MbCBmOiArjno61cQMUU7k+tgMTt4W2Eeoc0yyzIrRtamz2q8
zbxmnKdEHt140yUXmsxuG04ZM2+iL/MtVD0F69WTAr2JNGsBeeNB8KMGDlCmM8Co2uQOSTkw
ggOeMIIChqADAgECAgRGQ/sdMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYD
VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTA4MTAyMTEzMjkzNloXDTA5MDQy
MTEzNTkzNlowVTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1Ig
YW5kIEQxIjAOBgNVBAUTBzA1MDQwNjcwEAYDVQQDEwlUaW0gTW9zZXMwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBALT3bXGkvn4caHYy/u5MXZsEw0q0/s9nj6j7wNkOkyrw394HoLN7
JY404tmf3zCa+qbCXS5eC9hmbU2Rdxo1eZhlB2sZpP/aY8KaHSzUAUcv0LmtQS25qEkSZkLn
WSgczRts/EvOf7q0U4COQwI0dP/vBNk+fvJ+jkjVRZxZX32dAgMBAAGjggEcMIIBGDALBgNV
HQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwODEwMjExMzI5MzZagQ8yMDA5MDIyNTIyNTkzNlow
IAYDVR0RBBkwF4EVdGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBB
MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwG
A1UEAxMFQ1JMNDIwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYE
FCrFDow3ATgAarWOHil+N5udd2xJMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcu
MQMCBLAwDQYJKoZIhvcNAQEFBQADggEBAFGhTfDY3PVBPb1xQezRSKyd6kfj6d1Gl/rqsOk7
1skHSE89plfdYHMoNEBfSCkr+O2au7hx2DBLLK/zjfaqfpr5Scu8IsYz5LrNKsukP46qwOna
2yprT9VVyCsTuByOnG//9U2CEDIwCZ/GBw1i6MHCXssSdZIjxn5oxmO4OBDHhfBIFXT2vIKC
x/yEM+BgU+qWPu5T8V3Q3XR+kCE6jQDRp9cSTJy2Otzw+k+ASXASWO4hzEOH/X8Prd/lx1iS
clEK1lOXl5k4gCnQu/KcpM5CGKUhwFjcO9LJb/Xkeab4+Z8yEXSvNrjc5xLuFDW3BLaFPyNa
hWsrINpm/kC1goAwggP1MIIC3aADAgECAgQySKogMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV
BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTAyMDQxNzAy
MjAyNloXDTIyMDQxNzAyNTAyNlowMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3Qx
EDAOBgNVBAsTB1IgYW5kIEQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8h4iN
+gPkPzqwPwJ6EH6RWFglMv5W5pRmJWKMZ69ROWdQDDLVak5hWkUJrxUrXXpMn6j31rE3WMxu
xUFh9HMWT1JaXiIAf4/InVLoPliXn3cqMc+EEJ90PS/0qg+peELBGWS+6mt42UXHcUWTZR/m
Mb+L1II/3bk5dvPfCh3aZ0i7y541aBOYDZcA4F0dmDodgqjnQFZQiC1HAW/NuHUnnv6A10fE
xgtma+PmxpLWYNNKJuQ8f8Bj4P7ECjNGbI5hrhJjYdV9lIzZI/syS5W0qnXunOHCJyhYAYpe
sp4NFYNh5kFMmMeg0/9Jcp2lLNjutXwY+t9YWiiBzjfnRVujAgMBAAGjggETMIIBDzARBglg
hkgBhvhCAQEEBAMCAAcwUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYD
VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQk
MCKADzIwMDIwNDE3MDIyMDI2WoEPMjAyMjA0MTcwMjUwMjZaMAsGA1UdDwQEAwIBBjAfBgNV
HSMEGDAWgBTz8Cwo5jmnNBmrmpGopmZAkpzicTAdBgNVHQ4EFgQU8/AsKOY5pzQZq5qRqKZm
QJKc4nEwDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNi4wOjQuMAMCBJAwDQYJ
KoZIhvcNAQEFBQADggEBAIA+ebVGmfnJrmQEsWlyRG3D5e5j8bmbq5Af2FVeB5yGn6Lr+1eV
iNDxxycnLUdw6Y9LvXwuQbh2vEF+uGM71pO52/5M0gxH2LNrLv3qGwGTutoGli3Fq84SPFvy
N+n4R6XO2BxJmjvfuZjNyuv2kOPMmV2yuILM8NT83TnZH5EnhGz/QiK5bMhUfvL31L076sbX
g+MQo1CEDf2BPCD2IwG1CiSwN8q7T1QJoWwTtphQLx4TTDOSLgb4OXlEoTnswZpgCH5xxybI
9HpfD+CXxijdgaE5bPepq0CFtumUAKb0tKZ24xItdDJuR7pyrklRvxz1UzOL1wiK/odt/X/E
5s8xggJoMIICZAIBATA5MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD
VQQLEwdSIGFuZCBEAgRGQ/sdMAcGBSsOAwIaoIIBiTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEyMzExNTM2NTZaMCMGCSqGSIb3DQEJBDEWBBRJYJQR
3LOeOmLPQl5+lI5BWAQlBjCCASgGCSqGSIb3DQEJDzGCARkwggEVMAoGCCqGSIb3DQMHMAcG
BSsOAwIaMAoGCCqGSIb3DQICMAoGCCqGSIb3DQIEMAoGCCqGSIb3DQIFMA4GCCqGSIb3DQME
AgIAgDANBggqhkiG9w0DBAIBKDAHBgUrDgMCBzAOBgkqhkiG9n0HQgMCAUAwDgYJKoZIhvZ9
B0IDAgEoMA8GCSqGSIb2fQdCCgICAIAwEQYLKwYBBAGBPAcBAQICAgCAMA8GCWCGSAFlAwQB
AgICAIAwDwYJYIZIAWUDBAEWAgIAwDAPBglghkgBZQMEASoCAgEAMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBODANBggqhkiG9w0DAgIBKDALBgkqhkiG
9w0BAQEEgYAZ5wG6uFoDAwofzu92qRcG76k3WrqXjHB3b6RsWMe+Jt5xlI2JRzHZbSD10yJu
ETUcGMyhvZEVDEwaR3dsN6N3kjF+WpqoK6OAQNA1OO6WmXXfpDJYsucllmfv+JWA0GX4M5Ux
uMCHY3dvQnet5UldSEs3dAMT6wfaMlkXHTghlwAAAAAAAA==
----=_NextPart_EE_103656811.38200976--

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 mBVFLFTl087122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:21:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFLFYV087120; Wed, 31 Dec 2008 08:21:15 -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 mBVFLDgA087109 for ; Wed, 31 Dec 2008 08:21:13 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 3243 invoked from network); 31 Dec 2008 15:21:36 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:21:36 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:21:36 -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: Wed, 31 Dec 2008 10:21:12 -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: AclrWwxnY5KUcnr6RkKSgCgRHyNxcgAADcag
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[email-masked]>
From: "Santosh Chokhani"
To: "Timothy J. Miller"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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.

-----Original Message-----
From: Timothy J. Miller [mailto:[email-masked]]=20
Sent: Wednesday, December 31, 2008 10:18 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

Santosh Chokhani wrote:
> One would think we want to start using SHA-1 or even SHA256 (assuming
> client vendors implement SHA256 ASAP) and ask the CAs emanating from
> commercial roots to perform responsible I&A before issuing
certificates.

Speaking of I&A, I found it interesting to note that the CA/Browser=20
forum guidelines for EV certs allows (but recommends against) MD5 until=20
2010.

The spot check of EV issuers I did yesterday didn't turn up anyone=20
actually using MD5, but I didn't have all of 'em available.

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIaND086980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:18:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFIaRF086978; Wed, 31 Dec 2008 08:18:36 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIY1l086966; Wed, 31 Dec 2008 08:18:34 -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 mBVFIXwR002392; Wed, 31 Dec 2008 10:18:33 -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 mBVFIXZb002386; Wed, 31 Dec 2008 10:18:33 -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; Wed, 31 Dec 2008 10:18:33 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 09:18:00 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Santosh Chokhani
CC: "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
In-Reply-To:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050306030909090007020003"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Santosh Chokhani wrote:
> One would think we want to start using SHA-1 or even SHA256 (assuming
> client vendors implement SHA256 ASAP) and ask the CAs emanating from
> commercial roots to perform responsible I&A before issuing certificates.

Speaking of I&A, I found it interesting to note that the CA/Browser
forum guidelines for EV certs allows (but recommends against) MD5 until
2010.

The spot check of EV issuers I did yesterday didn't turn up anyone
actually using MD5, but I didn't have all of 'em available.

-- Tim

--------------ms050306030909090007020003
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
Fw0wODEyMzExNTE4MDBaMCMGCSqGSIb3DQEJBDEWBBTYJibxLOyG1SEmTVXB/AhI0/Bt8jBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAZCH6+J56WxRyI0sA7T1gbC1tsCwYnjNsqIpESy0TwpwrdIYDgtwOARQOev
InbqiDYQerQmWIIH+ovlzYIUazy21FVc8ReHKFTXOrx4GLrDvGSwGfsDrc8Rz8l5dcP0rXUS
J6/YQsvvbM90MY/o0TBIWI2i8PG5c5mVmkkYr+E9AAAAAAAA
--------------ms050306030909090007020003--

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 mBVF4tXw086352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:04:55 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVF4sl7086350; Wed, 31 Dec 2008 08:04:54 -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 mBVF4g3w086328 for ; Wed, 31 Dec 2008 08:04:52 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 3140 invoked from network); 31 Dec 2008 15:05:05 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:05:05 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:05:04 -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: Further MD5 breaks: Creating a rogue CA certificate
Date: Wed, 31 Dec 2008 10:04:40 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclrWAfbgnf2g3ujTbSdpg9MXzs4IAAANDWw
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Mini CRL are not a standard.

That said, using implementators agreement (based on whether high order
to low order bits are true serial number) one bit per certificate can be
assigned and the random prefix or appendage to the serial number
ignored.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Timothy J. Miller
Sent: Wednesday, December 31, 2008 9:43 AM
To: Russ Housley
Cc: Eric Rescorla; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate

Russ Housley wrote:
>=20
>> I'm not sure I understand the issue here, but
>> they don't actually have to be totally randomized. You could use a
>> PRF so they were predictable to the CA.
>=20
> That works. This works too: the serial number could be composed of=20
> two parts, where the most significant bits are a counter and the=20
> least significant bits are randomly generated.

How would Corestreet's miniCRL format fare under this?

-- Tim

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEn0Zx085546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:49:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEn0xf085544; Wed, 31 Dec 2008 07:49:00 -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 mBVEmnk9085526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:48:59 -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 BFE4650822; Wed, 31 Dec 2008 07:05:05 -0800 (PST)
Date: Wed, 31 Dec 2008 07:05:05 -0800
From: Eric Rescorla
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To:
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
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 Wed, 31 Dec 2008 14:20:39 +1300,
Peter Gutmann wrote:
>
> "Peter Hesse" writes:
>
> >Ceasing the issuance of certificates with MD5 used in the signature doesn't
> >solve the problem of the certificates that have already been issued and are
> >still out there, any number of which may be rogue.
> >
> >Replacing, or marking as untrusted all root certificates which have any
> >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in
> >the signature could have tremendous undesirable impact and be an untenable
> >solution.
>
> I hate to be the one to point to the elephant in the room (well OK, I don't
> hate it, it's rather fun actually) but you need to keep this in perspective:
> one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks
> have no problems at all obtaining certs from commercial CAs using stolen
> identities and credentials for pretty much any use they want. The current MD5
> attack is very cool but there's no need to worry about bad guys doing much
> with it because it's much, much easier to get legitimate CA-issued certs the
> normal way, you buy them just like everyone else does (except that you use
> someone else's credit card and identity, obviously).
>
> In other words, if this problem is fixed, would anyone other than security
> geeks even notice? I doubt the crooks will.

Well, if we're going to be pointing ot the obvious, then code signing actually
seems kind of off-point as well. > 50% of IE users are not running up-to-date
copies of their browser.[0] In many cases this means that the browsers have
remote exploits. Why worry about AuthentiCode?

-Ekr

[0] http://www.techzoom.net/publications/insecurity-iceberg/index.en

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 mBVEheG1085340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:43:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEhe3s085338; Wed, 31 Dec 2008 07:43:40 -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 mBVEhQJ1085321; Wed, 31 Dec 2008 07:43:37 -0700 (MST) (envelope-from [email-masked])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhO1a005883; Wed, 31 Dec 2008 09:43:24 -0500
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhOWH005873; Wed, 31 Dec 2008 09:43:24 -0500
Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 09:43:24 -0500
Message-ID: <[email-masked]>
Date: Wed, 31 Dec 2008 08:42:56 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Russ Housley
CC: Eric Rescorla , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606080405090908050504"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Russ Housley wrote:
>
>> I'm not sure I understand the issue here, but
>> they don't actually have to be totally randomized. You could use a
>> PRF so they were predictable to the CA.
>
> That works. This works too: the serial number could be composed of
> two parts, where the most significant bits are a counter and the
> least significant bits are randomly generated.

How would Corestreet's miniCRL format fare under this?

-- Tim

--------------ms090606080405090908050504
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
Fw0wODEyMzExNDQyNTZaMCMGCSqGSIb3DQEJBDEWBBTfbxF7sn3oqEN3WXpHFQsd8theZDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgBZT/e02nOU5oLHw8SlL6T03B11F/xNZ0nz2O8tH5cZlJO9MLivLWFMt7kuj
+OfGq/Rbd1s8iuLaOutkrqN86npxL/gDNTA9HhiOUS7uN6rWywF/2tptx4S0l7lJRMDg/BcX
0kefE1Ivxq3RU/taMplV1KFiHkJ7LJUnlyHecbu2AAAAAAAA
--------------ms090606080405090908050504--

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 mBV87f5W065612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 01:07:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV87fix065611; Wed, 31 Dec 2008 01:07:41 -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 mBV87Se7065596 for ; Wed, 31 Dec 2008 01:07:38 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 936 invoked from network); 31 Dec 2008 08:07:51 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 08:07:51 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 08:07:51 -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: Wed, 31 Dec 2008 03:07:26 -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: Aclq5ghrPG8EOOIcREilhQIvujxQYwAOEaVA
References: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
From: "Santosh Chokhani"
To: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

One would think we want to start using SHA-1 or even SHA256 (assuming
client vendors implement SHA256 ASAP) and ask the CAs emanating from
commercial roots to perform responsible I&A before issuing certificates.

It will also help if the client side certificate policy processing
became more of a norm.

But, all of this is probably expecting too much. My fear is that
expecting any of this is also too much.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Gutmann
Sent: Tuesday, December 30, 2008 8:21 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

"Peter Hesse" writes:

>Ceasing the issuance of certificates with MD5 used in the signature
doesn't
>solve the problem of the certificates that have already been issued and
are
>still out there, any number of which may be rogue.
>
>Replacing, or marking as untrusted all root certificates which have any
>current valid (i.e. non-expired, non-revoked) certificates with MD5
used in
>the signature could have tremendous undesirable impact and be an
untenable
>solution.

I hate to be the one to point to the elephant in the room (well OK, I
don't
hate it, it's rather fun actually) but you need to keep this in
perspective:
one in ten AuthentiCode-signed Windows binaries is malware, and
cybercrooks
have no problems at all obtaining certs from commercial CAs using stolen
identities and credentials for pretty much any use they want. The
current MD5
attack is very cool but there's no need to worry about bad guys doing
much
with it because it's much, much easier to get legitimate CA-issued certs
the
normal way, you buy them just like everyone else does (except that you
use
someone else's credit card and identity, obviously).

In other words, if this problem is fixed, would anyone other than
security
geeks even notice? I doubt the crooks will.

Peter.
_______________________________________________
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 mBV1Kx0A050093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:20:59 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV1KxR2050090; Tue, 30 Dec 2008 18:20:59 -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 mBV1KkLi050051; Tue, 30 Dec 2008 18:20:58 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C6E079D3C9; Wed, 31 Dec 2008 14:20:45 +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 JJ47zQCpU9p7; Wed, 31 Dec 2008 14:20:45 +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 EF5B69D3C8; Wed, 31 Dec 2008 14:20:44 +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 0EEEE1BE4002; Wed, 31 Dec 2008 14:20:40 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LHplH-0006Xw-V6; Wed, 31 Dec 2008 14:20:39 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
Message-Id:
Date: Wed, 31 Dec 2008 14:20:39 +1300
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

"Peter Hesse" writes:

>Ceasing the issuance of certificates with MD5 used in the signature doesn't
>solve the problem of the certificates that have already been issued and are
>still out there, any number of which may be rogue.
>
>Replacing, or marking as untrusted all root certificates which have any
>current valid (i.e. non-expired, non-revoked) certificates with MD5 used in
>the signature could have tremendous undesirable impact and be an untenable
>solution.

I hate to be the one to point to the elephant in the room (well OK, I don't
hate it, it's rather fun actually) but you need to keep this in perspective:
one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks
have no problems at all obtaining certs from commercial CAs using stolen
identities and credentials for pretty much any use they want. The current MD5
attack is very cool but there's no need to worry about bad guys doing much
with it because it's much, much easier to get legitimate CA-issued certs the
normal way, you buy them just like everyone else does (except that you use
someone else's credit card and identity, obviously).

In other words, if this problem is fixed, would anyone other than security
geeks even notice? I doubt the crooks will.

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 mBUNjtin045192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:45:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNjtxd045190; Tue, 30 Dec 2008 16:45:55 -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 mBUNjr9K045178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:45:54 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (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 mBUNjjIx018330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:45:46 -0500 (EST)
Date: Tue, 30 Dec 2008 18:45:45 -0500
From: Jeffrey Hutzelman
To: Santosh Chokhani , Peter Hesse , "RL 'Bob' Morgan" , Paul Hoffman
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]> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <[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 Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani
wrote:

> Since the attack is computing pre-image, I suspect that past MD5
> certificates are safe until the attack was devised.

The attack does _not_ involve computing a preimage; it involves computing a
colliding pair one of which has a prefix which is predictable but not
controllable, followed by a controllable component consisting of some
minimum number of bits followed by at least three aligned message blocks.
What makes existing certificates safe is that there are no known preimage
attacks against MD5, couple with limitations of the technique used to
construct the colliding pair.

However, there is a limit to how "safe" existing certificates are, because
the attack does not require anything that was not known 3-4 years ago. The
only change is that with the latest techniques for computing collisions, it
is possible to do so in a short enough time to be able to predict the
validity and serial number that will be used by the issuer with fairly high
probability.

-- 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 mBUNeogg044869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:40:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNeoAn044866; Tue, 30 Dec 2008 16:40:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNebSX044839; Tue, 30 Dec 2008 16:40:48 -0700 (MST) (envelope-from [email-masked])
Received: by fg-out-1718.google.com with SMTP id l26so2736323fgb.26 for ; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=DDpekhM52VkOAoRXt2PZCjhH4t1PiBNvOlzCNzEqzL4=; b=ZZz3YvRMqfdLQsd/8ahiFloECdUPBawdLeuuNZH8Cr46ZHYLNXsoZ+HMY+zLRX6zYI h+P2eWBjHI0CacQWPFxFZXccAWRnZLdIAa2ZIivutA9pgNYpKm9PZOVdbDda45599etK ntwcXzkHyb9uMG1+RTH91bwmHp47itVwiUsgY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rIO56ncxno48IvUn931cZzc48cPja3c6sVugRkSlz07p+kL31iFVgv0xYSnUpIRGhc 9l8VIIu5uelDeSjEMvZMXmMvlH94d3yEPdueUvJdVnE1X+piIepre66GsXldcD7HYouL S1ChvvQEJXezzzv/SuiCz/3ifmbLVWzeW8SV8=
Received: by 10.86.95.20 with SMTP id s20mr2438156fgb.39.1230680436423; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
Received: by 10.86.93.6 with HTTP; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
Message-ID:
Date: Tue, 30 Dec 2008 18:40:36 -0500
From: "Hugo Krawczyk"
To: "Eric Rescorla"
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: "Paul Hoffman" , [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_143378_5086089.1230680436411"
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Google-Sender-Auth: 51d21de5a352475d
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

------=_Part_143378_5086089.1230680436411
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Paul, Eric and everyone else,

Paul said

>
> If the IETF feels that adding randomization to signatures is
> important, we should define randomized signature functions. We could
> start with NIST Draft SP 800-106
> (<
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>).
However,
> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

and Eric responded

> I certainly agree we should be encouraging the use of non-broken hash
> functions. However, randomizing the SN seems like very cheap backward
> compatible insurance against the fact that that's going to take a long
time.

I believe that the best answer to the above arguments regarding the use of
randomized hashing vs. the "patch" of using random SNs is given by Sotirov
et
al, the cryptanalysts that carried out the remarkable MD5-certificate attack
(see their website). They say:

*We do note however that this use of randomness in the serial number is a
workaround, made possible by lucky choices in the X.509 standard. It is
not a
bad idea in general to add randomness to a hash input when a possible
attacker
is able to choose the input. A much more reliable, since designed,
solution is
to use randomized hashing, see [HK]. Such a solution introduces
randomization
as a "mode of operation" for hash functions, which is a much more
fundamental
approach to the problem than relying on features that happen to be present
in
existing standards for non-security reasons, or for no reason at all.*

In this light, I disagree with Paul's statement:

> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

The two things are not exclusive. We should do BOTH:
Adopt a randomized hashing technique (as a mode of operation for hash
functions) and continue our quest for better hash functions.

We must aim at the best possible hash function, but we cannot guarantee its
security in the long term. As stated in the above text by Sotirov et al,
randomized hashing is a more fundamental (I would call it "infrastructural")
approach. It strengthens digital signatures with any hash function and for
any
digital signature application, not just certificates.

Let's take the example of HMAC: Its development in mid-90's was motivated to
a
large extent by the weaknesses found in MD5 by Dobbertin and others.
If we took the approach of "let's use a better hash function" we should have
adopted the key-append method
MAC(K,X) = SHA1(X||K)
which used SHA1 for which there was ample belief that it was a very good
collision resistant hash function. However, had we done that, we would now
have a broken MAC since the above design breaks with collisions on the
underlying hash function.

I believe that the responsible course of action for the IETF and
particularly
SAAG is to adopt the standardization process started by NIST with
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf
and create a deployment path that could accommodate a randomized hashing
approach as a mode of operation. This includes the consideration of
randomized
hashing in protocol changes and new protocol design that support algorithm
agility.

No one in the world will think that by doing that we should keep using MD5,
or not pay attention to NIST's hash competition, or should stop from moving
to
SHA2.

The just-published attack indicates that it is time that we take seriously
our
digital signatures, and randomized hashing is the best long-term insurance
we know against future collision vulnerabilities.

You can find more details on the specific randomized hashing approach behind
NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/
In particular, some of the documents in that site provide some guidance
regarding implementation and deployment issues (it also includes a
now-expired
internet draft).

Hugo

------=_Part_143378_5086089.1230680436411
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Paul, Eric and everyone else,

Paul said

>
> If the IETF feels that adding randomization to signatures is
> important, we should define randomized signature functions. We could
> start with NIST Draft SP 800-106

> (<http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However,
> I think that doing so is sending the wrong message: we should

> instead be encouraging the use of non-broken hash functions.

and Eric responded

>  I certainly agree we should be encouraging the use of non-broken hash
>  functions. However, randomizing the SN seems like very cheap backward

>  compatible insurance against the fact that that's going to take a long time.

I believe that the best answer to the above arguments regarding the use of
randomized hashing vs. the "patch" of using random SNs is given by Sotirov et

al, the cryptanalysts that carried out the remarkable MD5-certificate attack
(see their website). They say:

We do note however that this use of randomness in the serial number is a
workaround, made possible by lucky choices in the X.509 standard. It is not a

bad idea in general to add randomness to a hash input when a possible attacker
is able to choose the input. A much more reliable, since designed, solution is
to use randomized hashing, see [HK]. Such a solution introduces randomization

as a "mode of operation" for hash functions, which is a much more fundamental
approach to the problem than relying on features that happen to be present in
existing standards for non-security reasons, or for no reason at all.

In this light, I disagree with Paul's statement:

> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

The two things are not exclusive. We should do BOTH:

Adopt a randomized hashing technique (as a mode of operation for hash
functions) and continue our quest for better hash functions.

We must aim at the best possible hash function, but we cannot guarantee its
security in the long term. As stated in the above text by Sotirov et al,

randomized hashing is a more fundamental (I would call it "infrastructural")
approach. It strengthens digital signatures with any hash function and for any
digital signature application, not just certificates.

Let's take the example of HMAC: Its development in mid-90's was motivated to a
large extent by the weaknesses found in MD5 by Dobbertin and others.
If we took the approach of "let's use a better hash function" we should have

adopted the key-append method
MAC(K,X) = SHA1(X||K)
which used SHA1 for which there was ample belief that it was a very good
collision resistant hash function.  However, had we done that, we would now
have a broken MAC since the above design breaks with collisions on the

underlying hash function.

I believe that the responsible course of action for the IETF and particularly
SAAG is to adopt the standardization process started by NIST with
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf

and create a deployment path that could accommodate a randomized hashing
approach as a mode of operation. This includes the consideration of randomized
hashing in protocol changes and new protocol design that support algorithm

agility.

No one in the world will think that by doing that we should keep using MD5,
or not pay attention to NIST's hash competition, or should stop from moving to
SHA2.

The just-published attack indicates that it is time that we take seriously our

digital signatures, and randomized hashing is the best long-term insurance
we know against future collision vulnerabilities.

You can find more details on the specific randomized hashing approach behind
NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/

In particular, some of the documents in that site provide some guidance
regarding implementation and deployment issues (it also includes a now-expired
internet draft).

Hugo

------=_Part_143378_5086089.1230680436411--

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 mBUNUHbb044383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:30:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNUHmK044382; Tue, 30 Dec 2008 16:30:17 -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 mBUNUEBx044363 for ; Tue, 30 Dec 2008 16:30:15 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29881 invoked from network); 30 Dec 2008 23:30:38 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:30:38 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:30:38 -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] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 18:30:13 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclqylLTk2EWxsuuQ1C7rI9Jvd/JmAADAnAQ
References: <[email-masked]><[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "Yoav Nir" , "RL 'Bob' Morgan"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Let us leave the trust anchors alone. Your challenge of protecting
trust anchors does not change even if you use SHA 512 or next generation
hash function yet to be determined.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Tuesday, December 30, 2008 5:02 PM
To: RL 'Bob' Morgan
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

>> Regardless of that, the authors of the MD5 paper are correct: trust =20
>> anchors signed with MD5 are highly questionable as of today (well, =20
>> actually, since they published their last paper). Hopefully, the =20
>> maintainers of the popular trust anchor repositories (Microsoft, =20
>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and =20
>> MD2!) as soon as possible.
>
> This is a different claim than "CAs should stop issuing certs with =20
> MD5 signatures", which is what I as an amateur take away from a =20
> quick scan of the material. Obviously MD5 is suspect in various =20
> ways, but does this new work lead to the conclusion that MD5-signed =20
> roots are untrustworthy today?
> Replacing a root is a much bigger deal then changing signing =20
> practices.
>
> - RL "Bob"

CAs should have stopped issuing certs with MD5 signatures 4 years ago, =20
when the first practical attacks on MD5 were published.

Now it would be more correct to say that "relying parties should treat =20
as invalid any certificate chain that contains an MD5 (or MD2, MD4) =20
signature"

Since in the HTTPS context the relying parties are the browsers, it =20
falls to the vendors (if Microsoft leads, everyone will follow) to, as =20
Paul said, yank the trust anchors.

It should be noted, though, that yanking the trust anchors is not =20
enough. You really should change the relying party to not recognize =20
this algorithm. Otherwise, it's perfectly valid for a CA whose =20
certificate is signed with SHA1 to sign an intermediate CA certificate =20
with MD5 (although they usually don't do that, I hope)

Email secured by Check Point
_______________________________________________
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 mBUNSAgu044293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:28:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNSArV044291; Tue, 30 Dec 2008 16:28:10 -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 mBUNS8iY044272 for ; Tue, 30 Dec 2008 16:28:08 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29840 invoked from network); 30 Dec 2008 23:28:32 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:28:32 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:28:32 -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] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 18:28:07 -0500
Message-ID:
In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtAAAQJILA=
References: <[email-masked]> <[email-masked]> <08bb01c96ac7$1cd5a750$5680f5f0$@com>
From: "Santosh Chokhani"
To: "Peter Hesse" , "RL 'Bob' Morgan" , "Paul Hoffman"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Peter,

Roots need not be replaced since they need protected migration and
storage.

Since the attack is computing pre-image, I suspect that past MD5
certificates are safe until the attack was devised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Hesse
Sent: Tuesday, December 30, 2008 4:40 PM
To: 'RL 'Bob' Morgan'; 'Paul Hoffman'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate

Ceasing the issuance of certificates with MD5 used in the signature
doesn't
solve the problem of the certificates that have already been issued and
are
still out there, any number of which may be rogue.

Replacing, or marking as untrusted all root certificates which have any
current valid (i.e. non-expired, non-revoked) certificates with MD5 used
in
the signature could have tremendous undesirable impact and be an
untenable
solution.

The right tool for the job is a client-side solution to fail validation
of
any signature which uses MD5, especially certificate signatures. I will
not
hold my breath for such a solution.

--Peter=20

----------------------------------------------------------------
Peter Hesse [email-masked]
http://securitymusings.com http://geminisecurity.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, December 30, 2008 4:18 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

> Regardless of that, the authors of the MD5 paper are correct: trust=20
> anchors signed with MD5 are highly questionable as of today (well,=20
> actually, since they published their last paper). Hopefully, the=20
> maintainers of the popular trust anchor repositories (Microsoft,=20
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5=20
signatures", which is what I as an amateur take away from a quick scan
of=20
the material. Obviously MD5 is suspect in various ways, but does this
new=20
work lead to the conclusion that MD5-signed roots are untrustworthy
today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

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 mBUNQ7AN044212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:26:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNQ7ot044210; Tue, 30 Dec 2008 16:26:07 -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 mBUNQ5uv044190 for ; Tue, 30 Dec 2008 16:26:05 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29815 invoked from network); 30 Dec 2008 23:26:29 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:26:29 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:26:29 -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] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 18:26:04 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate
Thread-Index: AclqxZr3n+guWOOLTkmzRrRAnrk5JgAEETnQ
References: <[email-masked]> <[email-masked]>
From: "Santosh Chokhani"
To: "RL 'Bob' Morgan" , "Paul Hoffman"
Cc: , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

As mentioned, self-signed roots have their own problems and hash is not
one of them. They need other means to protect since signatures on them
are useless.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, December 30, 2008 4:18 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

> Regardless of that, the authors of the MD5 paper are correct: trust=20
> anchors signed with MD5 are highly questionable as of today (well,=20
> actually, since they published their last paper). Hopefully, the=20
> maintainers of the popular trust anchor repositories (Microsoft,=20
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5=20
signatures", which is what I as an amateur take away from a quick scan
of=20
the material. Obviously MD5 is suspect in various ways, but does this
new=20
work lead to the conclusion that MD5-signed roots are untrustworthy
today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

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 mBUNNTe6044008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:23:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNNTnh044002; Tue, 30 Dec 2008 16:23:29 -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 mBUNNGED043974 for ; Tue, 30 Dec 2008 16:23:27 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 29788 invoked from network); 30 Dec 2008 23:23:40 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:23:40 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:23: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: Tue, 30 Dec 2008 18:23:15 -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: AclqwLMO5Ztz1GDZSjWorp7026VgfQAFJdBA
References: <[email-masked]><[email-masked]>
From: "Santosh Chokhani"
To: "Paul Hoffman" , , , ,
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

I disagree in the matter of trust anchors, assuming you mean self-signed
ones.

Signatures on Trust anchors are inherently useless from security
viewpoint. Thus, they could be signed using even MD4.

Their security relies on protecting them from unauthorized modification.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Hoffman
Sent: Tuesday, December 30, 2008 3:53 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
>This is a practical application of an approach that I remember being
brought up during discussions about MD5 at a saag meeting some time ago.
I also recall someone mentioning at the time that many/most CA's were
already issuing certificates with random rather than sequential serial
numbers, which would have thwarted this particular attack.

Your recollection may be off. I believe I was the person who brought up
the serial number hack at the mic, and I'm pretty sure I said "some",
not "many" (and certainly not "most"!). When I looked at a handful of
popular CAs earlier this week, I only found a few who are using
randomization in their serial numbers.

Regardless of that, the authors of the MD5 paper are correct: trust
anchors signed with MD5 are highly questionable as of today (well,
actually, since they published their last paper). Hopefully, the
maintainers of the popular trust anchor repositories (Microsoft,
Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
MD2!) as soon as possible.

At 3:10 PM -0500 12/30/08, Russ Housley wrote:
>RFC 5280 does not include this advice. It is sound advice that was
discussed in PKIX and other venues. Perhaps a BCP is in order.

Man, that is really stretching the definition of "best".

For one, it is only needed in signatures that use known-attackable hash
functions. A "best practice" in that case is to use a better hash
function in the signature. Also, it relies on the ability of the
software using the random number to be sure that the result is a
positive integer in ASN.1, which seems overly optimistic.

If the IETF feels that adding randomization to signatures is important,
we should define randomized signature functions. We could start with
NIST Draft SP 800-106
(). However, I think that doing so is sending the wrong
message: we should instead be encouraging the use of non-broken hash
functions.

--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 mBUNF3cl043683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16: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 mBUNF3q6043681; Tue, 30 Dec 2008 16: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 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 mBUNF1RH043670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:15:02 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (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 mBUNEtxp017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:14:56 -0500 (EST)
Date: Tue, 30 Dec 2008 18:14:55 -0500
From: Jeffrey Hutzelman
To: Nicolas Williams
cc: Eric Rescorla , Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] 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]> <[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 Tuesday, December 30, 2008 04:36:12 PM -0600 Nicolas Williams
wrote:

> Applying a principle of redundancy in RTI algorithms to symmetric key
> protocols is fairly simple. Applying such a principle to PKI seems
> rather more difficult -- it's not just hash algorithms, but pk
> algorithms too. Your example was to require not just the implementation
> of multiple hash (but not pk) algorithms, but to require the *use* of
> those. That makes sense to me, but it's not quite the same principle
> being applied to PKI as to SSH.

Correct. I'm suggesting that in the case of PKI, merely having two RTI
algorithms wouldn't be sufficient; at least for long-term certificates you
need to actually sign using two algorithms in order to get the
interoperability benefit. Validating using both isn't necessary, though it
does have a benefit, in that no code or configuration changes are required
to continue to be safe as long as at least one is good enough.

IMHO, one of the biggest problems in the current PKI standards is that
there is no ability to future-proof certificates by generating signatures
with multiple algorithms. The result is that you can't start signing with
a new algorithm until everyone understands it, and you can't stop accepting
an old algorithm without either reissuing lots of certificates with a new
one or waiting for them to expire. This means movement is very slow and we
are unable to abandon a broken algorithm in a hurry. The former is poor;
the latter is a disaster waiting to happen.

-- 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 mBUN0ktc042873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUN0ko5042871; Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN0Z99042846; Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from [email-masked])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBUN0ZCC027191; Tue, 30 Dec 2008 23:00:35 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBUN0ZOK044664; Tue, 30 Dec 2008 16:00:35 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBUMb2LL003035; Tue, 30 Dec 2008 16:37:02 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBUMaCUE003034; Tue, 30 Dec 2008 16:36:12 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [email-masked] using -f
Date: Tue, 30 Dec 2008 16:36:12 -0600
From: Nicolas Williams
To: Jeffrey Hutzelman
Cc: Eric Rescorla , Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate
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.7i
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Tue, Dec 30, 2008 at 05:01:12PM -0500, Jeffrey Hutzelman wrote:
> Incidentally, the recently reported problems with CBC mode ciphers in SSH
> have gotten me to thinking that in some situations, a single REQUIRED
> algorithm isn't enough, because if something goes wrong and you have to
> abandon that algorithm in a hurry, operators may be in a position of having
> to choose between seriously compromising either security or
> interoperability.

+1

But note that in the case of the SSH CBC mode ciphers the vulnerable
ciphers had only the cipher mode in common. The SSH vulnerability, in
any case, doesn't stem from the use of CBC, but is more general, and
well could have been worse, but let's ignore that for this argument.

So in the SSH case one would have liked to have seen two or more
REQUIRED to implement ciphers with very distinct properties. Say
3DES in CBC mode, AES in counter mode, and arcfour.

Applying a principle of redundancy in RTI algorithms to symmetric key
protocols is fairly simple. Applying such a principle to PKI seems
rather more difficult -- it's not just hash algorithms, but pk
algorithms too. Your example was to require not just the implementation
of multiple hash (but not pk) algorithms, but to require the *use* of
those. That makes sense to me, but it's not quite the same principle
being applied to PKI as to SSH.

Nico
--

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 mBUMcbj4041942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMcbok041940; Tue, 30 Dec 2008 15:38:37 -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 mBUMcaVV041923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:36 -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 0E36550822; Tue, 30 Dec 2008 14:54:54 -0800 (PST)
Date: Tue, 30 Dec 2008 14:54:53 -0800
From: Eric Rescorla
To: "Timothy J. Miller"
Cc: Eric Rescorla , Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[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:

Here's Tim Callan from VEriSign posting about this:

https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php

-Ekr
y

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 mBUMVYU1041609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMVYac041607; Tue, 30 Dec 2008 15:31:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMVLtP041578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:32 -0700 (MST) (envelope-from [email-masked])
Received: from newdasher.Dartmouth.EDU (newdasher.dartmouth.edu [129.170.208.30]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mBULqtr9007948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:30:44 -0500
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from c-65-96-146-181.hsd1.nh.comcast.net [65.96.146.181] by newdasher.Dartmouth.EDU (Mac) via SMTP for id <138927721>; 30 Dec 2008 17:30:43 -0500
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 17:30:14 -0500
From: Scott Rea
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Russ Housley
CC: "RL 'Bob' Morgan" , Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-SpamCheck: spam, SpamAssassin on mailhub2 (score=1.651, required 1, BAYES_00 -2.60, BLITZ_DISCLAIMER 0.05, HELO_DYNAMIC_IPADDR 4.20)
X-MailScanner-SpamScore: s
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Russ Housley wrote:
>
>
>>> Regardless of that, the authors of the MD5 paper are correct: trust
>>> anchors signed with MD5 are highly questionable as of today (well,
>>> actually, since they published their last paper). Hopefully, the
>>> maintainers of the popular trust anchor repositories (Microsoft,
>>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
>>> MD2!) as soon as possible.
>>
>> This is a different claim than "CAs should stop issuing certs with
>> MD5 signatures", which is what I as an amateur take away from a quick
>> scan of the material. Obviously MD5 is suspect in various ways, but
>> does this new work lead to the conclusion that MD5-signed roots are
>> untrustworthy today?
>
> We recommended a migration (walk, don't run) away from MD2, MD4, and
> SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit
> hash values; even without the attacks, these are getting to be too
> small. SHA-1 has been shown to be weaker than its design goal, and
> the 160 bit hash value will be getting too short in a couple of
> years. We recommended SHA-256 while fully recognizing that NIST was
> starting a hash competition, and that we might recommend the winner of
> that competition as the successor to SHA-256.
>
> I still strongly encourage the migration to SHA-256.
>
> The use of the random bits in the serial number are insurance against
> similar problems being found in other hash functions. This insurance
> will hopefully provide time to migrate to another hash function when
> cryptanalysis begins to show flaws in any future hash function.
>
> Russ

But one of the things that has kept the brakes on migration has been
support in clients for SHA256 - the largest vendor of client machines
only just recently added SHA256 to its XP platform (if you upgrade to
SP3). I keep running into folks using OpenSSL as their crypto base and
they haven't updated to a distribution that supports SHA256. I think it
will take a little more time before it becomes the default...

--
Scott Rea

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 mBUMNxJ1040994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:24:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNxXw040993; Tue, 30 Dec 2008 15:23:59 -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.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNgDm040924; Tue, 30 Dec 2008 15:23:53 -0700 (MST) (envelope-from [email-masked])
Received: by rv-out-0708.google.com with SMTP id c5so5433808rvf.34 for ; Tue, 30 Dec 2008 14:23:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SOjf1T9xI3MBJb+v+mg2/Dsw2wPmsmYSixQ9iXiIRcA=; b=jLU/hS5jNIbna5Zku6U+axs1KV2KLYrQTa+hHCR/6kqe207G+tXYDsVPGgTJk0qupA RJNQu5TWWaiQBDzj6O/tCx4phcCEZunboOs+VpniRcdvoADq3XwUZ1mzr83/ud5RY47H 8qdO/4Hzhx0900vj2XpDMmQJIaimvjR/nKQhg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fNUP7Tab+VzvZPlIZjRGwRfpijhSl5e12WjdlWGoMMTJAQLgGCUXaBh6fPtA/Uex4x SNJMbQy/susUqr3OwRpb03aw46n6l9v8rUN4Gu8YA/jVRFYUFah7cKKcTeg4ApodNWJq EylztJzNVq1Niy3z4I7ag/Xk1/BlZfI+34MHY=
Received: by 10.140.226.14 with SMTP id y14mr7464473rvg.59.1230675822107; Tue, 30 Dec 2008 14:23:42 -0800 (PST)
Received: by 10.141.169.13 with HTTP; Tue, 30 Dec 2008 14:23:42 -0800 (PST)
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 14:23:42 -0800
From: "Blake Ramsdell"
To: "Timothy J. Miller"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
Cc: "Eric Rescorla" , "Paul Hoffman" , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Tue, Dec 30, 2008 at 2:05 PM, Timothy J. Miller wrote:
> Randomizing serial numbers has implications for OCSP operations,
> particularly those that use presigned responses in order to optimize
> performance.

It seems that the disruption caused by modifying serial number
generation for existing CAs is pretty high. Would an easier solution
be to either a) make the validity period vary slightly (in the
documented attack, the notBefore was always a fixed interval from the
submission time, and making this vary in a period of just a few
minutes would have thwarted it, if I'm understanding correctly), or b)
the CA sticks some random junk in the subject DN (not an MPEG of a
cat, but maybe OU=sf9fj3 [some base64 PRNG data]).

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 mBUMNsLQ040976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNsdI040973; Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMNqDL040943 for ; Tue, 30 Dec 2008 15:23:52 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 24294 invoked by uid 0); 30 Dec 2008 22:23:45 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:23:45 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 17:23:33 -0500
To: Eric Rescorla
From: Russ Housley
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>I'm not sure I understand the issue here, but
>they don't actually have to be totally randomized. You could use a
>PRF so they were predictable to the CA.

That works. This works too: the serial number could be composed of
two parts, where the most significant bits are a counter and the
least significant bits are randomly generated.

Russ

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 mBUMIhNu040692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMIhQ3040691; Tue, 30 Dec 2008 15:18:43 -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 mBUMIg9v040670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:42 -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 48BD350822; Tue, 30 Dec 2008 14:35:00 -0800 (PST)
Date: Tue, 30 Dec 2008 14:34:59 -0800
From: Eric Rescorla
To: "Timothy J. Miller"
Cc: Eric Rescorla , Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[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 Tue, 30 Dec 2008 16:05:56 -0600,
Timothy J. Miller wrote:
>
> [1 ]
> Eric Rescorla wrote:
> > At Tue, 30 Dec 2008 12:53:06 -0800,
> > Paul Hoffman wrote:
>
> >> Your recollection may be off. I believe I was the person who brought
> >> up the serial number hack at the mic, and I'm pretty sure I said
> >> "some", not "many" (and certainly not "most"!). When I looked at a
> >> handful of popular CAs earlier this week, I only found a few who are
> >> using randomization in their serial numbers.
>
> > I don't know whether many or most do it. IMO everyone should.
>
> Randomizing serial numbers has implications for OCSP operations,
> particularly those that use presigned responses in order to optimize
> performance.
>
> Why presign? Because for a large network with varying levels of
> support, it may be easier to move around sets of pre-produced responses
> to distributed keyless OCSP responders than to guarantee connectivity to
> a keyed OCSP service.
>
> Why presign batches rather than individual responses? Because for a
> large PKI the response pre-production time can exceed the CRL update
> frequency.

I'm not sure I understand the issue here, but
they don't actually have to be totally randomized. You could use a
PRF so they were predictable to the CA.

-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 mBUMH8on040618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:17:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMH8Tv040615; Tue, 30 Dec 2008 15:17:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMH7iV040596 for ; Tue, 30 Dec 2008 15:17:07 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 20400 invoked by uid 0); 30 Dec 2008 22:17:00 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:17:00 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 17:12:02 -0500
To: "RL 'Bob' Morgan" , Paul Hoffman
From: Russ Housley
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>>Regardless of that, the authors of the MD5 paper are correct: trust
>>anchors signed with MD5 are highly questionable as of today (well,
>>actually, since they published their last paper). Hopefully, the
>>maintainers of the popular trust anchor repositories (Microsoft,
>>Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
>>MD2!) as soon as possible.
>
>This is a different claim than "CAs should stop issuing certs with
>MD5 signatures", which is what I as an amateur take away from a
>quick scan of the material. Obviously MD5 is suspect in various
>ways, but does this new work lead to the conclusion that MD5-signed
>roots are untrustworthy today?

We recommended a migration (walk, don't run) away from MD2, MD4, and
SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit
hash values; even without the attacks, these are getting to be too
small. SHA-1 has been shown to be weaker than its design goal, and
the 160 bit hash value will be getting too short in a couple of
years. We recommended SHA-256 while fully recognizing that NIST was
starting a hash competition, and that we might recommend the winner
of that competition as the successor to SHA-256.

I still strongly encourage the migration to SHA-256.

The use of the random bits in the serial number are insurance against
similar problems being found in other hash functions. This insurance
will hopefully provide time to migrate to another hash function when
cryptanalysis begins to show flaws in any future hash function.

Russ

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 mBUM6bSu039980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:06:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM6bMr039979; Tue, 30 Dec 2008 15:06:37 -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 mBUM6P1i039959; Tue, 30 Dec 2008 15:06:36 -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 mBUM6OPb025827; Tue, 30 Dec 2008 17:06:25 -0500
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6Ocb025814; Tue, 30 Dec 2008 17:06:24 -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; Tue, 30 Dec 2008 17:06:24 -0500
Message-ID: <[email-masked]>
Date: Tue, 30 Dec 2008 16:05:56 -0600
From: "Timothy J. Miller"
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: Eric Rescorla
CC: Paul Hoffman , "[email-masked]" , "[email-masked]" , "[email-masked]" , "[email-masked]"
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000706050700070408070900"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Eric Rescorla wrote:
> At Tue, 30 Dec 2008 12:53:06 -0800,
> Paul Hoffman wrote:

>> Your recollection may be off. I believe I was the person who brought
>> up the serial number hack at the mic, and I'm pretty sure I said
>> "some", not "many" (and certainly not "most"!). When I looked at a
>> handful of popular CAs earlier this week, I only found a few who are
>> using randomization in their serial numbers.

> I don't know whether many or most do it. IMO everyone should.

Randomizing serial numbers has implications for OCSP operations,
particularly those that use presigned responses in order to optimize
performance.

Why presign? Because for a large network with varying levels of
support, it may be easier to move around sets of pre-produced responses
to distributed keyless OCSP responders than to guarantee connectivity to
a keyed OCSP service.

Why presign batches rather than individual responses? Because for a
large PKI the response pre-production time can exceed the CRL update
frequency.

-- Tim

--------------ms000706050700070408070900
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
Fw0wODEyMzAyMjA1NTZaMCMGCSqGSIb3DQEJBDEWBBQ4RbejFRP0hZy6Vjhh795xqhnGfDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgELzHlPR7X3MOFLP5ZcY1mbMXJyVuu8D6m/7NK0eZrsmu7YMbLzv7t5txCiQ
6CHlVuWg0WcLwT24dUazLur+cNII/+p5MiS42K0qScSEoWc7uJDgKtmol40n1brGU7mVvLVm
oNAh3ZUvQV/gAJ3VbnN61DL/Eld+TlsdEjGJ8SirAAAAAAAA
--------------ms000706050700070408070900--

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 mBUM2X0M039874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2Xfm039873; Tue, 30 Dec 2008 15:02:33 -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 mBUM2UYN039852; Tue, 30 Dec 2008 15:02:31 -0700 (MST) (envelope-from [email-masked])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E614A29C002; Wed, 31 Dec 2008 00:02:29 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7F09C29C001; Wed, 31 Dec 2008 00:02:08 +0200 (IST)
X-CheckPoint: {495A98AD-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 mBUM27fE029359; Wed, 31 Dec 2008 00:02:08 +0200 (IST)
Cc: Paul Hoffman , [email-masked], [email-masked], [email-masked], [email-masked]
Message-Id: <[email-masked]>
From: Yoav Nir
To: "RL 'Bob' Morgan"
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] Further MD5 breaks: Creating a rogue CA certificate
Date: Wed, 31 Dec 2008 00:02:07 +0200
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

>> Regardless of that, the authors of the MD5 paper are correct: trust
>> anchors signed with MD5 are highly questionable as of today (well,
>> actually, since they published their last paper). Hopefully, the
>> maintainers of the popular trust anchor repositories (Microsoft,
>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
>> MD2!) as soon as possible.
>
> This is a different claim than "CAs should stop issuing certs with
> MD5 signatures", which is what I as an amateur take away from a
> quick scan of the material. Obviously MD5 is suspect in various
> ways, but does this new work lead to the conclusion that MD5-signed
> roots are untrustworthy today?
> Replacing a root is a much bigger deal then changing signing
> practices.
>
> - RL "Bob"

CAs should have stopped issuing certs with MD5 signatures 4 years ago,
when the first practical attacks on MD5 were published.

Now it would be more correct to say that "relying parties should treat
as invalid any certificate chain that contains an MD5 (or MD2, MD4)
signature"

Since in the HTTPS context the relying parties are the browsers, it
falls to the vendors (if Microsoft leads, everyone will follow) to, as
Paul said, yank the trust anchors.

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)

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 mBUM2LlM039832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2Li2039827; Tue, 30 Dec 2008 15:02:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUM2Jug039809 for ; Tue, 30 Dec 2008 15:02:20 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 12655 invoked by uid 0); 30 Dec 2008 22:02:12 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:02:12 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 16:33:19 -0500
To: Paul Hoffman
From: Russ Housley
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul:

>If the IETF feels that adding randomization to signatures is
>important, we should define randomized signature functions. We could
>start with NIST Draft SP 800-106
>().
>However, I think that doing so is sending the wrong message: we
>should instead be encouraging the use of non-broken hash functions.

This is a very different thing than a BCP that the recommends that
the certificate serial number include some random bits.

Russ

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 mBUM1XhY039745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:01:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM1Xp8039743; Tue, 30 Dec 2008 15:01:33 -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 mBUM1Lqj039727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 15:01:32 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (173-101-98-177.pools.spcsdns.net [173.101.98.177]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUM1Cht017220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:01:14 -0500 (EST)
Date: Tue, 30 Dec 2008 17:01:12 -0500
From: Jeffrey Hutzelman
To: Eric Rescorla , Paul Hoffman
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[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 Tuesday, December 30, 2008 01:39:34 PM -0800 Eric Rescorla
wrote:

> At Tue, 30 Dec 2008 12:53:06 -0800,
> Paul Hoffman wrote:
>>
>> At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
>> > This is a practical application of an approach that I remember being
>> > brought up during discussions about MD5 at a saag meeting some time
>> > ago. I also recall someone mentioning at the time that many/most CA's
>> > were already issuing certificates with random rather than sequential
>> > serial numbers, which would have thwarted this particular attack.
>>
>> Your recollection may be off. I believe I was the person who brought
>> up the serial number hack at the mic, and I'm pretty sure I said
>> "some", not "many" (and certainly not "most"!). When I looked at a
>> handful of popular CAs earlier this week, I only found a few who are
>> using randomization in their serial numbers.
>
> So it's in my deck from SAAG at IETF 62.
>
> http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf
>
> I don't know whether many or most do it. IMO everyone should.

I just checked my records, and shortly after that IETF, our internal CA
started issuing certificates with SHA-1 signatures and randomized serial
numbers, as a direct result of that discussion.

>
>> > RFC 5280 does not include this advice. It is sound advice that was
>> > discussed in PKIX and other venues. Perhaps a BCP is in order.
>>
>> Man, that is really stretching the definition of "best".
>>
>> For one, it is only needed in signatures that use known-attackable
>> hash functions. A "best practice" in that case is to use a better
>> hash function in the signature. Also, it relies on the ability of
>> the software using the random number to be sure that the result is a
>> positive integer in ASN.1, which seems overly optimistic.

On the contrary, IMHO best practice is to take every reasonable measure to
reduce the likelyhood of an attack. In my book, that means both using a
better hash function _and_ using randomized serial numbers, since the
latter clearly helps when the hash is broken, and hash functions may become
broken over time, and before you realize it.

>> If the IETF feels that adding randomization to signatures is
>> important, we should define randomized signature functions.

I think that's a very good idea. However...

> I certainly agree we should be encouraging the use of non-broken hash
> functions. However, randomizing the SN seems like very cheap backward
> compatible insurance against the fact that that's going to take a long
> time.

"what he said".

Incidentally, the recently reported problems with CBC mode ciphers in SSH
have gotten me to thinking that in some situations, a single REQUIRED
algorithm isn't enough, because if something goes wrong and you have to
abandon that algorithm in a hurry, operators may be in a position of having
to choose between seriously compromising either security or
interoperability.

In the case of usages like certificates where no live negotiation is
possible and implementations may have to interoperate over a long period of
time, I believe additional care is necessary. For example, I think it
would be a good idea to define a composite signature function which uses
more than one hash computed independently. This would likely make some
attacks harder, but more importantly, it means that as long as at least one
of the underlying hashes is strong enough, the signature is still usable.

-- 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 mBULdlVE038673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:39:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULdlKE038672; Tue, 30 Dec 2008 14:39:47 -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 mBULdaRA038639; Tue, 30 Dec 2008 14:39:46 -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 14CD01ECC7; Tue, 30 Dec 2008 21:39:34 +0000 (GMT)
From: "Peter Hesse"
To: "'RL 'Bob' Morgan'" , "'Paul Hoffman'"
Cc: , , ,
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate
Date: Tue, 30 Dec 2008 16:39:34 -0500
Message-ID: <08bb01c96ac7$1cd5a750$5680f5f0$@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: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtA
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Ceasing the issuance of certificates with MD5 used in the signature doesn't
solve the problem of the certificates that have already been issued and are
still out there, any number of which may be rogue.

Replacing, or marking as untrusted all root certificates which have any
current valid (i.e. non-expired, non-revoked) certificates with MD5 used in
the signature could have tremendous undesirable impact and be an untenable
solution.

The right tool for the job is a client-side solution to fail validation of
any signature which uses MD5, especially certificate signatures. I will not
hold my breath for such a solution.

--Peter

----------------------------------------------------------------
Peter Hesse [email-masked]
http://securitymusings.com http://geminisecurity.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of RL 'Bob' Morgan
Sent: Tuesday, December 30, 2008 4:18 PM
To: Paul Hoffman
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate

> Regardless of that, the authors of the MD5 paper are correct: trust
> anchors signed with MD5 are highly questionable as of today (well,
> actually, since they published their last paper). Hopefully, the
> maintainers of the popular trust anchor repositories (Microsoft,
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5
signatures", which is what I as an amateur take away from a quick scan of
the material. Obviously MD5 is suspect in various ways, but does this new
work lead to the conclusion that MD5-signed roots are untrustworthy today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

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 mBULNIXh038042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULNIp4038041; Tue, 30 Dec 2008 14:23:18 -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 mBULNH61038023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:17 -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 C219450822; Tue, 30 Dec 2008 13:39:34 -0800 (PST)
Date: Tue, 30 Dec 2008 13:39:34 -0800
From: Eric Rescorla
To: Paul Hoffman
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To:
References: <[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 Tue, 30 Dec 2008 12:53:06 -0800,
Paul Hoffman wrote:
>
> At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
> >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack.
>
> Your recollection may be off. I believe I was the person who brought
> up the serial number hack at the mic, and I'm pretty sure I said
> "some", not "many" (and certainly not "most"!). When I looked at a
> handful of popular CAs earlier this week, I only found a few who are
> using randomization in their serial numbers.

So it's in my deck from SAAG at IETF 62.

http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf

I don't know whether many or most do it. IMO everyone should.

> >RFC 5280 does not include this advice. It is sound advice that was
> >discussed in PKIX and other venues. Perhaps a BCP is in order.
>
> Man, that is really stretching the definition of "best".
>
> For one, it is only needed in signatures that use known-attackable
> hash functions. A "best practice" in that case is to use a better
> hash function in the signature. Also, it relies on the ability of
> the software using the random number to be sure that the result is a
> positive integer in ASN.1, which seems overly optimistic.
>
> If the IETF feels that adding randomization to signatures is
> important, we should define randomized signature functions. We could
> start with NIST Draft SP 800-106
> (). However,
> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

I certainly agree we should be encouraging the use of non-broken hash
functions. However, randomizing the SN seems like very cheap backward
compatible insurance against the fact that that's going to take a long time.

-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 mBULIeU2037911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:18:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULIe2Z037909; Tue, 30 Dec 2008 14:18:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULIShF037889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 14:18:39 -0700 (MST) (envelope-from [email-masked])
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIO3h014517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2008 13:18:24 -0800
X-Auth-Received: from D-140-142-21-194.dhcp4.washington.edu (D-140-142-21-194.dhcp4.washington.edu [140.142.21.194]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIOpq023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Dec 2008 13:18:24 -0800
Date: Tue, 30 Dec 2008 13:17:50 -0800 (PST)
From: "RL 'Bob' Morgan"
X-X-Sender: [email-masked]
To: Paul Hoffman
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To:
Message-ID:
References: <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.5.0.356843, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2008.12.30.210424
X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='BODY_SIZE_1000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_700_799 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> Regardless of that, the authors of the MD5 paper are correct: trust
> anchors signed with MD5 are highly questionable as of today (well,
> actually, since they published their last paper). Hopefully, the
> maintainers of the popular trust anchor repositories (Microsoft,
> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
> MD2!) as soon as possible.

This is a different claim than "CAs should stop issuing certs with MD5
signatures", which is what I as an amateur take away from a quick scan of
the material. Obviously MD5 is suspect in various ways, but does this new
work lead to the conclusion that MD5-signed roots are untrustworthy today?
Replacing a root is a much bigger deal then changing signing practices.

- RL "Bob"

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 mBUKrch0036781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKrcgc036780; Tue, 30 Dec 2008 13:53:38 -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] ([207.62.247.66]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrXOU036766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:34 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Tue, 30 Dec 2008 12:53:06 -0800
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Paul Hoffman
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
>This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack.

Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers.

Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible.

At 3:10 PM -0500 12/30/08, Russ Housley wrote:
>RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order.

Man, that is really stretching the definition of "best".

For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic.

If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions.

--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 mBUKGscq035035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:16:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKGsJC035032; Tue, 30 Dec 2008 13:16:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUKGhh2035005 for ; Tue, 30 Dec 2008 13:16:53 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 14731 invoked by uid 0); 30 Dec 2008 20:16:37 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 20:16:37 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 15:10:45 -0500
To: Jeffrey Hutzelman
From: Russ Housley
Subject: Re: Further MD5 breaks: Creating a rogue CA certificate
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jeff:

>>http://www.win.tue.nl/hashclash/rogue-ca/
>>
>>MD5 considered harmful today
>>Creating a rogue CA certificate
>>
>>December 30, 2008
>>
>>Alexander Sotirov, Marc Stevens,
>>Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de
>>Weger
>>
>>We have identified a vulnerability in the Internet Public Key
>>Infrastructure (PKI) used to issue digital certificates for secure
>>websites. As a proof of concept we executed a practical attack scenario
>>and successfully created a rogue Certification Authority (CA) certificate
>>trusted by all common web browsers. This certificate allows us to
>>impersonate any website on the Internet, including banking and e-commerce
>>sites secured using the HTTPS protocol.
>>
>>Our attack takes advantage of a weakness in the MD5 cryptographic hash
>>function that allows the construction of different messages with the same
>>MD5 hash. This is known as an MD5 "collision". Previous work on MD5
>>collisions between 2004 and 2007 showed that the use of this hash
>>function in digital signatures can lead to theoretical attack scenarios.
>>Our current work proves that at least one attack scenario can be
>>exploited in practice, thus exposing the security infrastructure of the
>>web to realistic threats.
>
>
>This is a practical application of an approach that I remember being
>brought up during discussions about MD5 at a saag meeting some time
>ago. I also recall someone mentioning at the time that many/most
>CA's were already issuing certificates with random rather than
>sequential serial numbers, which would have thwarted this particular attack.

RFC 5280 does not include this advice. It is sound advice that was
discussed in PKIX and other venues. Perhaps a BCP is in order.

Russ

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 mBUK78Nb034464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUK78Vw034462; Tue, 30 Dec 2008 13:07:08 -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 mBUK6sZq034429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -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 DFF4550822; Tue, 30 Dec 2008 12:23:11 -0800 (PST)
Date: Tue, 30 Dec 2008 12:23:11 -0800
From: Eric Rescorla
To: Jeffrey Hutzelman
Cc: Russ Housley , [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
In-Reply-To: <[email-masked]>
References: <[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 Tue, 30 Dec 2008 13:33:46 -0500,
Jeffrey Hutzelman wrote:
>
> --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley
> wrote:
>
> > http://www.win.tue.nl/hashclash/rogue-ca/
> >
> > MD5 considered harmful today
> > Creating a rogue CA certificate
> >
> > December 30, 2008
> >
> > Alexander Sotirov, Marc Stevens,
> > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de
> > Weger
> >
> > We have identified a vulnerability in the Internet Public Key
> > Infrastructure (PKI) used to issue digital certificates for secure
> > websites. As a proof of concept we executed a practical attack scenario
> > and successfully created a rogue Certification Authority (CA) certificate
> > trusted by all common web browsers. This certificate allows us to
> > impersonate any website on the Internet, including banking and e-commerce
> > sites secured using the HTTPS protocol.
> >
> > Our attack takes advantage of a weakness in the MD5 cryptographic hash
> > function that allows the construction of different messages with the same
> > MD5 hash. This is known as an MD5 "collision". Previous work on MD5
> > collisions between 2004 and 2007 showed that the use of this hash
> > function in digital signatures can lead to theoretical attack scenarios.
> > Our current work proves that at least one attack scenario can be
> > exploited in practice, thus exposing the security infrastructure of the
> > web to realistic threats.
>
>
> This is a practical application of an approach that I remember being
> brought up during discussions about MD5 at a saag meeting some time ago. I
> also recall someone mentioning at the time that many/most CA's were already
> issuing certificates with random rather than sequential serial numbers,
> which would have thwarted this particular attack.

Yep. Would that they all were.

FWIW, here is my writeup of this issue, targeted towards a broader
community:

http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html

-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 mBUIY5Y4027106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 11:34:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUIY5A2027103; Tue, 30 Dec 2008 11:34:05 -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 mBUIXrB8027081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 11:34:04 -0700 (MST) (envelope-from [email-masked])
Received: from atlantis-home.pc.cs.cmu.edu (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 mBUIXkTS014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:33:47 -0500 (EST)
Date: Tue, 30 Dec 2008 13:33:46 -0500
From: Jeffrey Hutzelman
To: Russ Housley , [email-masked], [email-masked], [email-masked], [email-masked]
cc: [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]>
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 Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley
wrote:

> http://www.win.tue.nl/hashclash/rogue-ca/
>
> MD5 considered harmful today
> Creating a rogue CA certificate
>
> December 30, 2008
>
> Alexander Sotirov, Marc Stevens,
> Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de
> Weger
>
> We have identified a vulnerability in the Internet Public Key
> Infrastructure (PKI) used to issue digital certificates for secure
> websites. As a proof of concept we executed a practical attack scenario
> and successfully created a rogue Certification Authority (CA) certificate
> trusted by all common web browsers. This certificate allows us to
> impersonate any website on the Internet, including banking and e-commerce
> sites secured using the HTTPS protocol.
>
> Our attack takes advantage of a weakness in the MD5 cryptographic hash
> function that allows the construction of different messages with the same
> MD5 hash. This is known as an MD5 "collision". Previous work on MD5
> collisions between 2004 and 2007 showed that the use of this hash
> function in digital signatures can lead to theoretical attack scenarios.
> Our current work proves that at least one attack scenario can be
> exploited in practice, thus exposing the security infrastructure of the
> web to realistic threats.

This is a practical application of an approach that I remember being
brought up during discussions about MD5 at a saag meeting some time ago. I
also recall someone mentioning at the time that many/most CA's were already
issuing certificates with random rather than sequential serial numbers,
which would have thwarted this particular attack.

-- 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 mBUG5jOV018629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 09:05:46 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUG5jGD018619; Tue, 30 Dec 2008 09:05:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUG5Ybp018579 for ; Tue, 30 Dec 2008 09:05:44 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 4826 invoked by uid 0); 30 Dec 2008 16:05:29 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 16:05:29 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2008 11:05:28 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Russ Housley
Subject: Further MD5 breaks: Creating a rogue CA certificate
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

http://www.win.tue.nl/hashclash/rogue-ca/

MD5 considered harmful today
Creating a rogue CA certificate

December 30, 2008

Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key
Infrastructure (PKI) used to issue digital certificates for secure
websites. As a proof of concept we executed a practical attack
scenario and successfully created a rogue Certification Authority
(CA) certificate trusted by all common web browsers. This certificate
allows us to impersonate any website on the Internet, including
banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic
hash function that allows the construction of different messages with
the same MD5 hash. This is known as an MD5 "collision". Previous work
on MD5 collisions between 2004 and 2007 showed that the use of this
hash function in digital signatures can lead to theoretical attack
scenarios. Our current work proves that at least one attack scenario
can be exploited in practice, thus exposing the security
infrastructure of the web to realistic threats.

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 mBSA6GLQ020551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 03:06:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSA6G5p020545; Sun, 28 Dec 2008 03:06:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp812.mail.ird.yahoo.com (smtp812.mail.ird.yahoo.com [217.146.188.72]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBSA5tKX020339 for ; Sun, 28 Dec 2008 03:06:13 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 82718 invoked from network); 28 Dec 2008 10:05:54 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=H1hf/YBxnVdvsuhHfSDvf2GAbZlm4/WkF/SI/9WiPWKca7LOP0Qyhdb2VSe7i0CM4OJp3AdgsxsC0FYF/n+Q7ePDjLdeNzC7qW4kCrT0jjh6i+sLbbMq1mnrTCB+l5P40JUvYJUc29fbGiiyhWqIZJ2PUheymAhxCslw4XAe5Yo= ;
Received: from unknown (HELO ?192.168.1.67?) ([email-masked] with plain) by smtp812.mail.ird.yahoo.com with SMTP; 28 Dec 2008 10:05:54 -0000
X-YMail-OSG: kc7VFaEVM1nlVjqlZ7Cid.ujlJyL78D6T6.eF28dxzVps_NNxOT.RXIyRnxY5wmAM_6.DkCgBm_Pvkn_1G8BSprCsTk60nX6nPvOx6wiRSQUzD0oYsgjXX_6t52x1Sz3Up9mX8QW6VNrg8YtmCBFYgfa1D0mJjTsovT6FdYeYc_QdBSoKuX7ATaZ1XUzzKSXB7DhXrjCFUrH5REbVOq19eFZETY-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Sun, 28 Dec 2008 10:05:54 +0000
From: John Larmouth
Reply-To: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Tom Gindin
CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , [email-masked], [email-masked], [email-masked], asn1dev
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
References:
In-Reply-To:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Tom,

There are several comments to be made. Forgive me for being verbose, but I
think that in this area, brief replies can so easily be misunderstood.

1) First, forget the old stuff with identifiers (that is the old and
correct term) for names on arcs of the OID tree. They were always (and
still are) ASCII text, with an initial lower-case letter. Originally,
they were expected to be unique (but were never carried in protocol,
only in human value notation). Then later, it was recognised that
company names changed (due to take-over, merger, etc, and that they wanted to
use a different name for their arc (but not to change the numerical value). It
was then (circa 1992) that they should NOT be regarded as unique, and that
variants would be allowed (this brought the Standard into line with existing
practice). About the same time, CCITT changed its name, and synonyms were
formally assigned for some top-level arcs - but still
restricted to ASCII characters, starting with a lower case letter.
**Forget that stuff - it is historical! But, of course, still in use.**

2) Formally, an arc now has an always unique and unambiguous numerical value
(as before); the old not-necessarily-unique-or-unambiguous identifiers (as
before); but also has one or more Unicode labels (any - more-or-less - Unicode
characters) that is required to be unambiguous from the superior node, but not
necessarily unique (multiple Unicode labels are allowed on an arc to allow for
different language variants). This was much discussed and fought over, but was
eventually agreed as the best solution, but with some people still dissenting,
and wanting only one (unique) Unicode label on an arc.

3) As part of this extension, it was recognised that the limitation to three
top-level arcs (itu-t(0), iso(1), and joint-iso-itu-t(2)) was too limiting.
Fortunately, arc 2 had already been used to provide allocations for other SDOs,
and provided the x is less than 47, the OID {2, x} encodes into a single octet.
We now restrict the allocation of arcs {2, x} to organisations that need the
single octet encoding, but there are still quite a few x values left for future
allocation. For encoding purposes, the top two levels are effectively a single
set of top-level arcs, encoding into a single octet, provided x is less than 47
for arc 2, with similar restrictions on the arcs beneath arcs 0 and 1.

4) When Unicode labels were introduced, the concept of "long arcs" were included
specifically for use at the top level. So it is now possible for long arcs to
be allocated, with Unicode labels (but no numeric identifier) directly from the
root to an arc beneath arc 2, and it is now common practice to allocate a long
arc whenever an arc is allocated beneath arc 2 for any major organisation or SDO.

5) Finally, there was recognition of the problem of mapping a sequence of
Unicode labels (representing a set of arcs) into a canonical list of integers
for the numerical values of those arcs (in the case of a long arc, a Unicode
label would map into - typically - two integers, for example 2.13). This gave
rise to "work in progress" on an "OID resolution process". You will recognise
that this is very much what the ubiquitous DNS service provides - a mapping from
a set of names (domain names, little-endian order in the set) to a set of
numbers (IP addresses, big-endian order in the set). DNS look-up is
universally supported, and well-established, and the current hope/intent is to
be able to do OID resolution using the DNS service, but discussions are still in
progress on this. The alternative of an X.500 base for OID resolution has also
been much discussed, and not abandonned. But deployment of X.500 look-up
software is not as ubiquitous as DNS resolution software and databases. It may
be that at the stardardisation level, we will see two resolution services
documented - DNS-based and X.500-based. But it is too early to comment on that.

6) Now we come to IRI registration of the "oid" scheme, which is what the
Internet Draft is concerned with. This is not essential to support these
developments, but was a target from the start of the work. The sequence of
Unicode labels on a path from the root to a node is undoubtedly, in plain
English language terms, an internationalised resource identifier. So
registration of an IRI "oid" scheme with IANA was always a target for the work.
It was felt that the Standard should be in place before the registration was
attempted. So we now have an Internet Draft under review with uri-review, in
the hope that this can be "massaged" into a form that would allow us to proceed
with the formal IANA registration of the "oid" IRI scheme in the not too distant
future.

I hope this has gone some way towards answering your questions.

John L

Tom Gindin wrote:

> John:
>
> This draft is interesting and useful for some purposes, but I
>don't see how it addresses the case where a high-level arc (beyond the
>control of the development organization) is renamed. Since that's
>precisely the case we are discussing here (although the change took place
>quite a while ago and it's reasonable to expect people to adjust), it
>doesn't actually seem to help us. Am I missing something?
> Also, unless I have missed something, there are only three
>top-level arcs defined for OID's and they all now have names.
>
> Tom Gindin
>
>
>
>
>John Larmouth
>Sent by: [email-masked]
>12/22/2008 10:48 AM
>Please respond to
>[email-masked]
>
>
>To
>Alfred �
>cc
>[email-masked], [email-masked], [email-masked]
>Subject
>Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
>
>
>
>
>
>
>Alfred,
>
>The synonyms were introduced some time ago, and, indeed, the names are
>non-normative, and may not even be unambiguous. Only the numbers matter
>in an OID in an encoding.
>
>However, the recent introduction of Unicode labels, as normative and
>unambigous names gives a new naming scheme to the (same) OID tree that
>enables names (Unicode labels) to be used in machine communication if
>desired. The ASN.1 type is called OID_IRI and provides for node
>identification using Unicode labels. Unicode labels with names similar to
>the old ASCII names have been assigned for many of the top-level arcs, and
>more will be added over time.
>
>The OID_IRI type is related to (but not dependent on) the application for
>an "oid" IRI scheme, but for consistency this is desired. See I-D
>draft-larmouth-oid-iri-00.
>
>John L
>
>Alfred � wrote:
>Folks / to whom it concerns,
>
>during recent reviews of active I-Ds containing ASN.1 related
>to the X.500 framework, I found that a couple of these do not
>consistently employ the revised name of the top-level OID branch
>
> joint-iso-itu-t(2) ,
>
>but instead use the outdated/legacy name
>
> joint-iso-ccitt(2) .
>
>Some drafts use a mix of both names.
>
>I suggest that the modern version joint-iso-itu-t(2) be used
>consistently within all new drafts / draft versions, unless
>intentionally and explicitely for historical evidence reference
>has to be made to the old name.
>
>Kind regards,
> Alfred.
>
>
>
>
>

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

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 mBOJFZTK016888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2008 12:15:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBOJFZic016885; Wed, 24 Dec 2008 12:15:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBOJFMd1016857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Dec 2008 12:15:33 -0700 (MST) (envelope-from [email-masked])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBOJFARG009894; Wed, 24 Dec 2008 14:15:10 -0500
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBOJFJlC197854; Wed, 24 Dec 2008 14:15:19 -0500
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id mBOJFJPr026105; Wed, 24 Dec 2008 14:15:19 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id mBOJFIoj026095; Wed, 24 Dec 2008 14:15:18 -0500
In-Reply-To: <[email-masked]>
To: [email-masked]
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , [email-masked], [email-masked], [email-masked]
MIME-Version: 1.0
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin
Message-ID:
Date: Wed, 24 Dec 2008 14:15:17 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/24/2008 14:15:18, Serialize complete at 12/24/2008 14:15:18
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

ICAgICAgICBKb2huOg0KDQogICAgICAgIFRoaXMgZHJhZnQgaXMgaW50ZXJlc3RpbmcgYW5kIHVz
ZWZ1bCBmb3Igc29tZSBwdXJwb3NlcywgYnV0IEkgDQpkb24ndCBzZWUgaG93IGl0IGFkZHJlc3Nl
cyB0aGUgY2FzZSB3aGVyZSBhIGhpZ2gtbGV2ZWwgYXJjIChiZXlvbmQgdGhlIA0KY29udHJvbCBv
ZiB0aGUgZGV2ZWxvcG1lbnQgb3JnYW5pemF0aW9uKSBpcyByZW5hbWVkLiAgU2luY2UgdGhhdCdz
IA0KcHJlY2lzZWx5IHRoZSBjYXNlIHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgKGFsdGhvdWdoIHRo
ZSBjaGFuZ2UgdG9vayBwbGFjZSANCnF1aXRlIGEgd2hpbGUgYWdvIGFuZCBpdCdzIHJlYXNvbmFi
bGUgdG8gZXhwZWN0IHBlb3BsZSB0byBhZGp1c3QpLCBpdCANCmRvZXNuJ3QgYWN0dWFsbHkgc2Vl
bSB0byBoZWxwIHVzLiAgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCiAgICAgICAgQWxzbywgdW5s
ZXNzIEkgaGF2ZSBtaXNzZWQgc29tZXRoaW5nLCB0aGVyZSBhcmUgb25seSB0aHJlZSANCnRvcC1s
ZXZlbCBhcmNzIGRlZmluZWQgZm9yIE9JRCdzIGFuZCB0aGV5IGFsbCBub3cgaGF2ZSBuYW1lcy4N
Cg0KICAgICAgICAgICAgICAgIFRvbSBHaW5kaW4NCg0KDQoNCg0KSm9obiBMYXJtb3V0aCA8ai5s
YXJtb3V0aEBidGludGVybmV0LmNvbT4gDQpTZW50IGJ5OiBvd25lci1pZXRmLXBraXhAbWFpbC5p
bWMub3JnDQoxMi8yMi8yMDA4IDEwOjQ4IEFNDQpQbGVhc2UgcmVzcG9uZCB0bw0Kai5sYXJtb3V0
aEBidGludGVybmV0LmNvbQ0KDQoNClRvDQpBbGZyZWQg77+9IDxhaEB0ci1zeXMuZGU+DQpjYw0K
dHVybmVyc0BpZWNhLmNvbSwgaWV0Zi1wa2l4QGltYy5vcmcsIGlldGYtc21pbWVAaW1jLm9yZw0K
U3ViamVjdA0KUmU6IGNvbnNpc3RlbiB1c2Ugb2YgdG9wLWxldmVsIG9pZCBicmFuY2ggbmFtZSBq
b2ludC1pc28taXR1LXQoMikNCg0KDQoNCg0KDQoNCkFsZnJlZCwNCg0KVGhlIHN5bm9ueW1zIHdl
cmUgaW50cm9kdWNlZCBzb21lIHRpbWUgYWdvLCBhbmQsIGluZGVlZCwgdGhlIG5hbWVzIGFyZSAN
Cm5vbi1ub3JtYXRpdmUsIGFuZCBtYXkgbm90IGV2ZW4gYmUgdW5hbWJpZ3VvdXMuICBPbmx5IHRo
ZSBudW1iZXJzIG1hdHRlciANCmluIGFuIE9JRCBpbiBhbiBlbmNvZGluZy4NCg0KSG93ZXZlciwg
dGhlIHJlY2VudCBpbnRyb2R1Y3Rpb24gb2YgVW5pY29kZSBsYWJlbHMsIGFzIG5vcm1hdGl2ZSBh
bmQgDQp1bmFtYmlnb3VzIG5hbWVzIGdpdmVzIGEgbmV3IG5hbWluZyBzY2hlbWUgdG8gdGhlIChz
YW1lKSBPSUQgdHJlZSB0aGF0IA0KZW5hYmxlcyBuYW1lcyAoVW5pY29kZSBsYWJlbHMpIHRvIGJl
IHVzZWQgaW4gbWFjaGluZSBjb21tdW5pY2F0aW9uIGlmIA0KZGVzaXJlZC4gIFRoZSBBU04uMSB0
eXBlIGlzIGNhbGxlZCBPSURfSVJJIGFuZCBwcm92aWRlcyBmb3Igbm9kZSANCmlkZW50aWZpY2F0
aW9uIHVzaW5nIFVuaWNvZGUgbGFiZWxzLiAgVW5pY29kZSBsYWJlbHMgd2l0aCBuYW1lcyBzaW1p
bGFyIHRvIA0KdGhlIG9sZCBBU0NJSSBuYW1lcyBoYXZlIGJlZW4gYXNzaWduZWQgZm9yIG1hbnkg
b2YgdGhlIHRvcC1sZXZlbCBhcmNzLCBhbmQgDQptb3JlIHdpbGwgYmUgYWRkZWQgb3ZlciB0aW1l
Lg0KDQpUaGUgT0lEX0lSSSB0eXBlICBpcyByZWxhdGVkIHRvIChidXQgbm90IGRlcGVuZGVudCBv
bikgdGhlIGFwcGxpY2F0aW9uIGZvciANCmFuICJvaWQiIElSSSBzY2hlbWUsICBidXQgZm9yIGNv
bnNpc3RlbmN5IHRoaXMgaXMgZGVzaXJlZC4gIFNlZSBJLUQgDQpkcmFmdC1sYXJtb3V0aC1vaWQt
aXJpLTAwLg0KDQpKb2huIEwNCg0KQWxmcmVkIO+/vSB3cm90ZTogDQpGb2xrcyAvIHRvIHdob20g
aXQgY29uY2VybnMsDQoNCmR1cmluZyByZWNlbnQgcmV2aWV3cyBvZiBhY3RpdmUgSS1EcyBjb250
YWluaW5nIEFTTi4xIHJlbGF0ZWQNCnRvIHRoZSBYLjUwMCBmcmFtZXdvcmssIEkgZm91bmQgdGhh
dCBhIGNvdXBsZSBvZiB0aGVzZSBkbyBub3QNCmNvbnNpc3RlbnRseSBlbXBsb3kgdGhlIHJldmlz
ZWQgbmFtZSBvZiB0aGUgdG9wLWxldmVsIE9JRCBicmFuY2gNCg0KICAgIGpvaW50LWlzby1pdHUt
dCgyKSAsDQoNCmJ1dCBpbnN0ZWFkIHVzZSB0aGUgb3V0ZGF0ZWQvbGVnYWN5IG5hbWUNCg0KICAg
IGpvaW50LWlzby1jY2l0dCgyKSAuDQoNClNvbWUgZHJhZnRzIHVzZSBhIG1peCBvZiBib3RoIG5h
bWVzLg0KDQpJIHN1Z2dlc3QgdGhhdCB0aGUgbW9kZXJuIHZlcnNpb24gIGpvaW50LWlzby1pdHUt
dCgyKSAgYmUgdXNlZA0KY29uc2lzdGVudGx5IHdpdGhpbiBhbGwgbmV3IGRyYWZ0cyAvIGRyYWZ0
IHZlcnNpb25zLCB1bmxlc3MNCmludGVudGlvbmFsbHkgYW5kIGV4cGxpY2l0ZWx5IGZvciBoaXN0
b3JpY2FsIGV2aWRlbmNlIHJlZmVyZW5jZQ0KaGFzIHRvIGJlIG1hZGUgdG8gdGhlIG9sZCBuYW1l
Lg0KDQpLaW5kIHJlZ2FyZHMsDQogIEFsZnJlZC4NCg0KIA0KDQotLSANCiAgIFByb2YgSm9obiBM
YXJtb3V0aA0KICAgTGFybW91dGggVCZQRFMgTHRkDQogICAoVHJhaW5pbmcgYW5kIFByb3RvY29s
IERlc2lnbiBTZXJ2aWNlcyBMdGQpDQogICAxIEJsdWViZXJyeSBSb2FkIA0KICAgQm93ZG9uICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGoubGFybW91dGhAYnRpbnRlcm5ldC5jb20NCiAg
IEFsdHJpbmNoYW0NCiAgIENoZXNoaXJlDQogICBXQTE0IDNMUyANCiAgIEVuZ2xhbmQNCiAgIFRl
bDogKzQ0IDE2MSA5MjggMTYwNQ0KDQoNCg==

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 mBNBCPh5081224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 04:12:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBNBCPwk081222; Tue, 23 Dec 2008 04:12:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp811.mail.ird.yahoo.com (smtp811.mail.ird.yahoo.com [217.146.188.71]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBNBCDX2081187 for ; Tue, 23 Dec 2008 04:12:23 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 19382 invoked from network); 23 Dec 2008 11:12:12 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=ZgjNwUWwaAPfQyogg8vHfLojoDj2f6PPl6jLyMT1LX+GOZgYVsd+zYVe1pstplrU7roUTsoWhQU7rM+hxAxtO3KVP5DSctcXkIPh3CNNymNj4/TAan4LVlRGK07rc8liEWhvwMooVHIdWKw5LD8yHCu2xqLJhg7WxlFKcO54JdA= ;
Received: from unknown (HELO ?192.168.1.67?) ([email-masked] with plain) by smtp811.mail.ird.yahoo.com with SMTP; 23 Dec 2008 11:12:12 -0000
X-YMail-OSG: vrgTfU8VM1mhkBOfr2CSHGEqUVui2P3Vnd3ljSE7EVqJa89BjIvhiI93Btn7MNC9fVMoUaSwuOrYO4OSMY882lno3YQrlrLp5P8jEjFTpTp_wFt6VP8hPxnFtyPN_Lx5ksOKw39eNumGWr57Q0Sw3cKgBLS2H37M3bNaMaCviyfwvDRRD0xxU_Y5r.Abk3_Lxf2L8VqTfMACOHM4ip3OB39LJI6k_diIJGQh
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Tue, 23 Dec 2008 11:12:12 +0000
From: John Larmouth
Reply-To: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Paul Hoffman
CC: Alfred ? , [email-masked], [email-masked], [email-masked]
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------050009060805000700080909"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.
--------------050009060805000700080909
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Please note my use of "if desired" below. This presents an opportunity,
not a requirement.

Nothing has been removed from the old OID capability.

I agree that the use of Unicode labels has not been adopted by PKIX or
S/MIME (and may well never be), nor presented to them. However, unless
or until the "oid" IRI format is accepted by URI-review, it would be
premature for PKIX or SMIME to even consider it.

John L

Paul Hoffman wrote:

>At 3:48 PM +0000 12/22/08, John Larmouth wrote:
>
>
>>However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.
>>
>>
>
>Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.
>
>
>
>>The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.
>>
>>
>
>Paging Peter Gutmann....
>
>--Paul Hoffman, Director
>--VPN Consortium
>
>
>

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------050009060805000700080909
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Please note my use of "if desired" below.  This presents an
opportunity, not a requirement.

Nothing has been removed from the old OID capability.

I agree that the use of Unicode labels has not been adopted by PKIX or
S/MIME (and may well never be), nor presented to them.  However, unless
or until the "oid" IRI format is accepted by URI-review, it would be
premature for PKIX or SMIME to even consider it.

John L

Paul Hoffman wrote:

At 3:48 PM +0000 12/22/08, John Larmouth wrote:

However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.

Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.

The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.

Paging Peter Gutmann....

--Paul Hoffman, Director
--VPN Consortium

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------050009060805000700080909--

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 mBMHirdt036808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 10:44:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMHirCR036807; Mon, 22 Dec 2008 10:44: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMHirrV036801 for ; Mon, 22 Dec 2008 10:44:53 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 3A12A28C124; Mon, 22 Dec 2008 09:45:00 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-sha2-10.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 22 Dec 2008 09:45: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-10.txt
Pages : 11
Date : 2008-12-22

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-10.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-10.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 mBMGowES034239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 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 mBMGowTQ034238; Mon, 22 Dec 2008 09:50:58 -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 mBMGon8p034216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 09:50:50 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 22 Dec 2008 08:50:47 -0800
To: [email-masked], Alfred ?
From: Paul Hoffman
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
Cc: [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:48 PM +0000 12/22/08, John Larmouth wrote:
>However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.

Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.

>The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.

Paging Peter Gutmann....

--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 mBMFmO0E029596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 08:48:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMFmOrM029595; Mon, 22 Dec 2008 08:48:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp816.mail.ird.yahoo.com (smtp816.mail.ird.yahoo.com [77.238.189.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBMFmBA2029574 for ; Mon, 22 Dec 2008 08:48:23 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 20008 invoked from network); 22 Dec 2008 15:48:10 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=tQkoL9owhPwHWzOzbPimY2Dt9JLv9nU5CWYe5StO2PIWznWDtp9LPE29yxgnkSh5p8FCRwMbeYsCDH0gIdW6yYtovDwrpS3BpGS1jCw403OGtrbrc9pUWokxAf3jy0SmO3OIR/qUTkI8GHgcJXuL/In61WOVFOZ+PzzhYby+X1U= ;
Received: from unknown (HELO ?192.168.1.67?) ([email-masked] with plain) by smtp816.mail.ird.yahoo.com with SMTP; 22 Dec 2008 15:48:10 -0000
X-YMail-OSG: Rhsm3igVM1nRvqWJciSouoY2o6CT9wZveZw3YFTc9fQIuZHvz7kL1MGbOApNbshcIfLe78WzVfRaVJspyziFxx2Xc10jC7vH5WxKe_96btpwxv4OEbQEtxiUo5SZVvvIcA.aMYmWsReum7fstMynnnCtCoEmr.C8ANenOiYBqSp.Hy2stujeRFiUsQ1X61Yo
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Mon, 22 Dec 2008 15:48:10 +0000
From: John Larmouth
Reply-To: [email-masked]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?=
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2)
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: multipart/alternative; boundary="------------060306020603010708080909"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.
--------------060306020603010708080909
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Alfred,

The synonyms were introduced some time ago, and, indeed, the names are
non-normative, and may not even be unambiguous. Only the numbers matter
in an OID in an encoding.

However, the recent introduction of Unicode labels, as normative and
unambigous names gives a new naming scheme to the (same) OID tree that
enables names (Unicode labels) to be used in machine communication if
desired. The ASN.1 type is called OID_IRI and provides for node
identification using Unicode labels. Unicode labels with names similar
to the old ASCII names have been assigned for many of the top-level
arcs, and more will be added over time.

The OID_IRI type is related to (but not dependent on) the application
for an "oid" IRI scheme, but for consistency this is desired. See I-D
draft-larmouth-oid-iri-00.

John L

Alfred � wrote:

>Folks / to whom it concerns,
>
>during recent reviews of active I-Ds containing ASN.1 related
>to the X.500 framework, I found that a couple of these do not
>consistently employ the revised name of the top-level OID branch
>
> joint-iso-itu-t(2) ,
>
>but instead use the outdated/legacy name
>
> joint-iso-ccitt(2) .
>
>Some drafts use a mix of both names.
>
>I suggest that the modern version joint-iso-itu-t(2) be used
>consistently within all new drafts / draft versions, unless
>intentionally and explicitely for historical evidence reference
>has to be made to the old name.
>
>Kind regards,
> Alfred.
>
>
>

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------060306020603010708080909
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

Alfred,

The synonyms were introduced some time ago, and, indeed, the names are
non-normative, and may not even be unambiguous.  Only the numbers
matter in an OID in an encoding.

However, the recent introduction of Unicode labels, as normative and
unambigous names gives a new naming scheme to the (same) OID tree that
enables names (Unicode labels) to be used in machine communication if
desired.  The ASN.1 type is called OID_IRI and provides for node
identification using Unicode labels.  Unicode labels with names similar
to the old ASCII names have been assigned for many of the top-level
arcs, and more will be added over time.

The OID_IRI type  is related to (but not dependent on) the application
for an "oid" IRI scheme,  but for consistency this is desired.  See I-D
draft-larmouth-oid-iri-00.

John L

Alfred � wrote:

Folks / to whom it concerns,

during recent reviews of active I-Ds containing ASN.1 related
to the X.500 framework, I found that a couple of these do not
consistently employ the revised name of the top-level OID branch

joint-iso-itu-t(2) ,

but instead use the outdated/legacy name

joint-iso-ccitt(2) .

Some drafts use a mix of both names.

I suggest that the modern version joint-iso-itu-t(2) be used
consistently within all new drafts / draft versions, unless
intentionally and explicitely for historical evidence reference
has to be made to the old name.

Kind regards,
Alfred.

--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Design Services Ltd)
1 Blueberry Road
Bowdon [email-masked]
Altrincham
Cheshire
WA14 3LS
England
Tel: +44 161 928 1605

--------------060306020603010708080909--

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 mBMEalHl024584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07:36:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMEalpG024582; Mon, 22 Dec 2008 07:36:47 -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 mBMEagXw024570; Mon, 22 Dec 2008 07:36:44 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080886501; Mon, 22 Dec 2008 15:35:01 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA13232; Mon, 22 Dec 2008 15:34:56 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2)
To: [email-masked]
Date: Mon, 22 Dec 2008 15:34:56 +0100 (MEZ)
Cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: <200812221358.AA080714339@w.> from Russ Housley at Dec "22," 2008 "08:33:51" am
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:

Russ,
thanks for your response.

> Alfred:
>
> This is a result of the name change from CCITT to ITU-T. So,
> different documents use different names depending on when they were
> published. The bits on the wire are not impacted, so I have never
> worried about it.
>
> Russ

I am fully aware of the history, but that change is back quite
a couple of years now. IIRC, that must have been more than 15 years
ago; in particular, the X.680 1994 Edition (== ISO/IEC 8824-1:1995)
already specified the new name(s) as the primary identifier(s).

My arguments are primarily:

o avoiding possible confusion;

o making new documents easier to read for newcomers not aware
of the history of the ITU-T;

o self-consistency within new documents (a major goal of RFC Editor
policy);

o consistency within the set of related document revisions
currently in progress;

o using current terminology and names in new documents;

o referring to the new name when making citations of the X.680
series of IUT-T Recommendations (and that's the way SMIME and
PKIX are moving forward).

Kind regards,
Alfred.

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 mBME0eTA022580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07: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 mBME0eRr022578; Mon, 22 Dec 2008 07: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBME0Sgr022565 for ; Mon, 22 Dec 2008 07:00:38 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 3615 invoked from network); 22 Dec 2008 14:00:25 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 22 Dec 2008 14:00:25 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 22 Dec 2008 08:33:51 -0500
To: Alfred =?hp-roman8?B?SM5uZXM=?=
From: Russ Housley
Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2)
Cc: [email-masked], [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
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:

Alfred:

This is a result of the name change from CCITT to ITU-T. So,
different documents use different names depending on when they were
published. The bits on the wire are not impacted, so I have never
worried about it.

Russ

At 07:56 AM 12/22/2008, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:

>Folks / to whom it concerns,
>
>during recent reviews of active I-Ds containing ASN.1 related
>to the X.500 framework, I found that a couple of these do not
>consistently employ the revised name of the top-level OID branch
>
> joint-iso-itu-t(2) ,
>
>but instead use the outdated/legacy name
>
> joint-iso-ccitt(2) .
>
>Some drafts use a mix of both names.
>
>I suggest that the modern version joint-iso-itu-t(2) be used
>consistently within all new drafts / draft versions, unless
>intentionally and explicitely for historical evidence reference
>has to be made to the old name.
>
>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 mBMCvvTC018747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 05:57:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMCvvJ5018745; Mon, 22 Dec 2008 05:57:57 -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 mBMCvhUl018724; Mon, 22 Dec 2008 05:57:55 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080420566; Mon, 22 Dec 2008 13:56:06 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA13071; Mon, 22 Dec 2008 13:56:05 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: consisten use of top-level oid branch name joint-iso-itu-t(2)
To: [email-masked], [email-masked], [email-masked]
Date: Mon, 22 Dec 2008 13:56:04 +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 / to whom it concerns,

during recent reviews of active I-Ds containing ASN.1 related
to the X.500 framework, I found that a couple of these do not
consistently employ the revised name of the top-level OID branch

joint-iso-itu-t(2) ,

but instead use the outdated/legacy name

joint-iso-ccitt(2) .

Some drafts use a mix of both names.

I suggest that the modern version joint-iso-itu-t(2) be used
consistently within all new drafts / draft versions, unless
intentionally and explicitely for historical evidence reference
has to be made to the old name.

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 mBIKXPov094280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 13:33:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIKXPmF094279; Thu, 18 Dec 2008 13:33:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIKXDpk094266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Dec 2008 13:33:24 -0700 (MST) (envelope-from [email-masked])
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 36D7794A6E; Thu, 18 Dec 2008 21:33:08 +0100 (CET)
Received: by mail.sources.org (Postfix, from userid 1000) id 005C01907CC; Thu, 18 Dec 2008 21:30:02 +0100 (CET)
Date: Thu, 18 Dec 2008 21:30:02 +0100
From: Stephane Bortzmeyer
To: [email-masked]
Cc: Stephane Bortzmeyer
Subject: Re: XML Schema for draft-ietf-smime-ibearch-09
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux lenny/sid
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

[I'm not a member of the S/MIME working group. Please copy me the
messages you send.]

On Thu, Dec 18, 2008 at 11:23:03AM -0800,
Blake Ramsdell wrote
a message of 12 lines which said:

> During AUTH48, a comment was sent by Stephane Bortzmeyer to the RFC
> editor asking that we create and include an XML schema in
> draft-ietf-smime-ibearch-09.

A small note to explain my point: it seemed strange to me that a RFC
defines a XML language, whatever its simplicity, without a formal
schema (whether in W3C Schema, in RelaxNG or in DTD).

BCP 70 "Guidelines for the Use of Extensible Markup Language (XML)
within IETF Protocol" says:

4.7 Validity and Extensibility

One important value of XML is that there are formal mechanisms for
defining structural and data content constraints; these constrain the
identity of elements or attributes or the values contained within
them. There is more than one such formalism:

...

This document makes the following recommendations for the definition
of protocols using XML:

o Protocols should use an appropriate formalism for defining
validity of XML protocol elements.

...

This is not just a matter of taste. It also has practical
consequences. In the version approved by IESG, there was no way
(natural language or formal schema) to say if is
mandatory or not inside a .

Now, I understand it is AUTH48 and this is certainly a substantial
change, not just a spelling fix. Returning to the WG is certainly not
an appealing idea for most WG participants. But I am surprised that
the IESG did not catch this issue.

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 mBIJachd092024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 12:36:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIJacu3092023; Thu, 18 Dec 2008 12:36:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIJaRX1092014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Dec 2008 12:36:37 -0700 (MST) (envelope-from [email-masked])
Received: from GALATIONS (unknown [207.202.179.27]) by smtp4.pacifier.net (Postfix) with ESMTP id 953276A4D4; Thu, 18 Dec 2008 11:36:26 -0800 (PST)
From: "Jim Schaad"
To: "'Blake Ramsdell'" , , "'Stephane Bortzmeyer'"
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: XML Schema for draft-ietf-smime-ibearch-09
Date: Thu, 18 Dec 2008 11:36:19 -0800
Message-ID: <030c01c96147$e733be30$b59b3a90$@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: AclhRkpdEeTe1R5XT5e/jpXwYgnrVwAAYjkQ
Content-Language: en-us
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

While I might be generally in favor of making an XML schema - I am violently
oppose to doing this during Auth48.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Blake Ramsdell
> Sent: Thursday, December 18, 2008 11:23 AM
> To: [email-masked]; Stephane Bortzmeyer
> Subject: XML Schema for draft-ietf-smime-ibearch-09
>
>
> During AUTH48, a comment was sent by Stephane Bortzmeyer to the RFC
> editor asking that we create and include an XML schema in
> draft-ietf-smime-ibearch-09.
>
> If anyone in the S/MIME working group feels strongly in favor of this
> proposal, please reply to the list by 5p.m. GMT-0800, December 22,
> 2008. If the general consensus is not in favor of this proposal, then
> the draft will proceed without it.
>
> 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 mBIJNF8F091468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 12:23:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIJNFkp091467; Thu, 18 Dec 2008 12:23:15 -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 mBIJN4sG091454 for ; Thu, 18 Dec 2008 12:23:15 -0700 (MST) (envelope-from [email-masked])
Received: by rv-out-0708.google.com with SMTP id c5so564644rvf.34 for ; Thu, 18 Dec 2008 11:23:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=zw753LL5FcNEfq2KBVh0tA7IAf3SfhmZXoBw19PUyuk=; b=OGqucd31Rx0DT9SE+DN3hixn64t5BMPIV2ZrwW5D6jtPc2xzF2yTqvka070lyKjQMw sn568AJ478KSazv8usMnViwYqg9v7/+z66TTh9d/EKqvtT/x/Fbblie0uR3Y4wdPl7EI lDLwQ0AG+UdleAv50wgfAM77+YHYU5HHnxAYA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=mX9UVweY2z99m+THQ6INvQd8Oia4LEXhvSyPIVqij8RROXtV+rimtbmedWAIpr70pI L/45odqxedJ4BkJnoS0EAemShTiBLYC0jGJ8UotXDEPEszeeQsFVxzDyrcZTk3dmjnoX c+oOYPt5GBLgDHliN3XZs3pYT7By3rlQaErjA=
Received: by 10.141.48.6 with SMTP id a6mr1135358rvk.161.1229628183951; Thu, 18 Dec 2008 11:23:03 -0800 (PST)
Received: by 10.141.169.13 with HTTP; Thu, 18 Dec 2008 11:23:03 -0800 (PST)
Message-ID: <[email-masked]>
Date: Thu, 18 Dec 2008 11:23:03 -0800
From: "Blake Ramsdell"
To: [email-masked], "Stephane Bortzmeyer"
Subject: XML Schema for draft-ietf-smime-ibearch-09
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

During AUTH48, a comment was sent by Stephane Bortzmeyer to the RFC
editor asking that we create and include an XML schema in
draft-ietf-smime-ibearch-09.

If anyone in the S/MIME working group feels strongly in favor of this
proposal, please reply to the list by 5p.m. GMT-0800, December 22,
2008. If the general consensus is not in favor of this proposal, then
the draft will proceed without it.

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 mBCIiulW099004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCIiua4099002; Fri, 12 Dec 2008 11:44: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 mBCIiukC098990 for ; Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id C707C3A68C5; Fri, 12 Dec 2008 10:45:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3278bis-04.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 12 Dec 2008 10:45: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 : Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
Author(s) : S. Turner, D. Brown
Filename : draft-ietf-smime-3278bis-04.txt
Pages : 57
Date : 2008-12-12

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-04.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-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

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

--NextPart--