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

Ben Laurie <benl@google.com> Thu, 01 January 2009 15:37 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 44B643A6981; Thu, 1 Jan 2009 07:37:49 -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 789AE3A6981 for <saag@core3.amsl.com>; Thu, 1 Jan 2009 07:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.607
X-Spam-Level:
X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 eseLMnVWbZBy for <saag@core3.amsl.com>; Thu, 1 Jan 2009 07:37:47 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C85393A67E9 for <saag@ietf.org>; Thu, 1 Jan 2009 07:37:46 -0800 (PST)
Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n01F6Oow000976 for <saag@ietf.org>; Thu, 1 Jan 2009 07:06:24 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1230822384; bh=tg074PHvAieD9nLWnxuDNpZtK/w=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-GMailtapped-By:X-GMailtapped; b=ld8Q1x 2Qe8nmZpqx28goLItJY5Rkmd4OUzgxG3cjxdlOw9RB9CL+4wA7YqIs2Lu1xPn90BMcD yG1XqZ2ETG/iA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding: x-gmailtapped-by:x-gmailtapped; b=SDP1VJVvxF7AdY8Sn2Sajro/oqwFNciLHzHZ5IjeUyksU/pyZNeVEluRi6i/GVk7S lFifwJheHTCjD2Etawdeg==
Received: from fg-out-1718.google.com (fge13.prod.google.com [10.86.5.13]) by zps37.corp.google.com with ESMTP id n01F6ILr011266 for <saag@ietf.org>; Thu, 1 Jan 2009 07:06:19 -0800
Received: by fg-out-1718.google.com with SMTP id 13so533295fge.41 for <saag@ietf.org>; Thu, 01 Jan 2009 07:06:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.86.59.18 with SMTP id h18mr8480886fga.45.1230822377800; Thu, 01 Jan 2009 07:06:17 -0800 (PST)
In-Reply-To: <E1LILYj-00066V-WE@wintermute01.cs.auckland.ac.nz>
References: <495BA5E9.8040305@pobox.com> <E1LILYj-00066V-WE@wintermute01.cs.auckland.ac.nz>
Date: Thu, 01 Jan 2009 15:06:17 +0000
Message-ID: <1b587cab0901010706j6e8cd2f8pf23345660a4825a5@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
X-GMailtapped-By: 172.25.146.37
X-GMailtapped: benl
Cc: ietf-pkix@imc.org, mike-list@pobox.com, 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

On Thu, Jan 1, 2009 at 11:17 AM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
>
> Mike <mike-list@pobox.com> writes:
> >There is a simple fix -- a CA can just reorder the extensions prior to
> >issuing a certificate.
>
> That's actually a nice fix, but unfortunately not universally applicable: for
> some types of signed data (e.g. S/MIME attributes) the DER rules require
> sorting the encoded extensions, so there's only one valid order for them (and
> some applications actually check for this, so you have to do it or sig checks
> will start failing).

Surely the whole point of DER is that there's only one correct way to
encode any particular certificate?

So, either extensions must be sorted, or changing their order changes
their meaning. Either way, nothing can be reordered.
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag