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

"Santosh Chokhani" <SChokhani@cygnacom.com> Sun, 04 January 2009 22:34 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 677C43A6AB7; Sun, 4 Jan 2009 14:34:38 -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 A34FA3A6AB7 for <saag@core3.amsl.com>; Sun, 4 Jan 2009 14:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.441
X-Spam-Level:
X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=0.028, 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 7J7ShheQLO9q for <saag@core3.amsl.com>; Sun, 4 Jan 2009 14:34:36 -0800 (PST)
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id 86AC93A6885 for <saag@ietf.org>; Sun, 4 Jan 2009 14:34:36 -0800 (PST)
Received: (qmail 6928 invoked from network); 4 Jan 2009 22:34:40 -0000
Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 04 Jan 2009 22:34:40 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 4 Jan 2009 22:34:40 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 04 Jan 2009 17:34:21 -0500
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D4893664F@scygexch1.cygnacom.com>
In-Reply-To: <p06240819c586cdf1dc38@[10.20.30.158]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate
Thread-Index: AclurKoRqf7W7I+NT92pGLSCmb5SbAAD7uUg
References: <495BA5E9.8040305@pobox.com> <495E3446.4070606@htt-consult.com><230CAA22-D118-4F29-9DC8-32FDCD7D771E@checkpoint.com><p06240804c586b9520715@[10.20.30.158]><C178CD90-F101-4E52-9C6F-055510471654@checkpoint.com> <p06240819c586cdf1dc38@[10.20.30.158]>
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Yoav Nir <ynir@checkpoint.com>
Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.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

I agree with Paul.

Unless the Length of TBD certificate as part of DER is made
unpredictable, any values on extensions just go in the tumor.

-----Original Message-----
From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
Paul Hoffman
Sent: Sunday, January 04, 2009 3:40 PM
To: Yoav Nir
Cc: 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

At 10:23 PM +0200 1/4/09, Yoav Nir wrote:
>On Jan 4, 2009, at 9:11 PM, Paul Hoffman wrote:
>
>>At 9:02 AM +0200 1/4/09, Yoav Nir wrote:
>>>Best we can do is to get the CAs to
>>>
>>>(1) not issue MD5 certs anymore and
>>>(2) randomize the serial number and/or
>>>(3) and a random fluff extension that people are talking about
>>
>>Just to repeat it one more time: #3 does not prevent the published
attack.
>
>It does if the random fluff is inserted by the CA. The attack depends
on their ability to predict the entire TBS part.

I may have misunderstood the paper, but I think that changes after the
subjectPublicKeyInfo do not affect the attack.

>>>But still, I don't see Microsoft removing a root CA because one of
their sub-CAs is issuing non-compliant certificates.
>>
>>It is hard to see Microsoft removing or adding CAs. If anyone knows of
a public interface (mailing list, web site, whatever) for when this
happens, by all means please the world know.
>
>I managed to find a page with their policy on adding new root CAs.
Nothing there about removing old root CAs.

I'm not talking about the policy: I'm talking about the actual trust
anchors themselves.

>>>And if Microsoft don't, nobody else will. The
Firefox/Opera/Safari/Chrome people don't want any sites that "only work
with Explorer".
>>
>>At least with respect to Firefox, I think that statement is false.
>
>They've done quite a bit to render broken sites that were made for IE.

That is irrelevant for this thread. There are active discussions in the
Firefox community about adding and removing trust anchors that are and
are not already in the IE trust anchor pile.

>Also, I've updated today and all the "bad" CAs with MD5 signatures are
still in the TAS.

As was pointed out to me earlier: it does not matter if the CA has its
cert signed with MD5, only whether that CA *signs* with MD5. RapidSSL,
for example, is still signed with MD5 but is now signing with SHA-1.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag