Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

"Santosh Chokhani" <SChokhani@cygnacom.com> Wed, 31 December 2008 19:03 UTC

Return-Path: <saag-bounces@ietf.org>
X-Original-To: saag-archive@ietf.org
Delivered-To: ietfarch-saag-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679443A6A8C; Wed, 31 Dec 2008 11:03:22 -0800 (PST)
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CDE28C10F for <saag@core3.amsl.com>; Wed, 31 Dec 2008 11:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Level:
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaUj5FUiEivE for <saag@core3.amsl.com>; Wed, 31 Dec 2008 11:03:20 -0800 (PST)
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 885B728C110 for <saag@ietf.org>; Wed, 31 Dec 2008 11:03:20 -0800 (PST)
Received: (qmail 4657 invoked from network); 31 Dec 2008 18:56:51 -0000
Received: from SChokhani@cygnacom.com 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
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 31 Dec 2008 13:56:27 -0500
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D489365D6@scygexch1.cygnacom.com>
In-Reply-To: <495BBFC7.4070405@mitre.org>
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> <E1LHplH-0006Xw-V6@wintermute01.cs.auckland.ac.nz> <FAD1CF17F2A45B43ADE04E140BA83D4893658D@scygexch1.cygnacom.com> <495B8D28.6070601@mitre.org> <FAD1CF17F2A45B43ADE04E140BA83D489365A4@scygexch1.cygnacom.com> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <FAD1CF17F2A45B43ADE04E140BA83D489365CC@scygexch1.cygnacom.com> <495BBB5D.40507@mitre.org> <FAD1CF17F2A45B43ADE04E140BA83D489365D3@scygexch1.cygnacom.com> <495BBFC7.4070405@mitre.org>
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: "Timothy J. Miller" <tmiller@mitre.org>
Cc: ietf-pkix@imc.org, Dr Stephen Henson <lists@drh-consultancy.demon.co.uk>, cfrg@irtf.org, saag@ietf.org, ietf-smime@imc.org
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: saag-bounces@ietf.org
Errors-To: saag-bounces@ietf.org

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:tmiller@mitre.org] 
Sent: Wednesday, December 31, 2008 1:54 PM
To: Santosh Chokhani
Cc: Dr Stephen Henson; ietf-pkix@imc.org; ietf-smime@imc.org;
cfrg@irtf.org; saag@ietf.org
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 
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

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag