Re: [Trans] Precertificate format

Ben Laurie <> Thu, 11 September 2014 15:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 098731A0410 for <>; Thu, 11 Sep 2014 08:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.031
X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B8SH5VLAOzsW for <>; Thu, 11 Sep 2014 08:53:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63EF81A02F5 for <>; Thu, 11 Sep 2014 08:53:08 -0700 (PDT)
Received: by with SMTP id l6so3104457qcy.15 for <>; Thu, 11 Sep 2014 08:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nxlFw0MLp4ccD4+W8rUV01dCYdPGlbPVZbSbqqtogbI=; b=Wx9Q91TfaR26SLK5M0HRkjpCOHxuals9xZcbMJdGBUpvy7q6mp4GkOPLvb6RFyC5oA lKRCvO/EuUHYcwsuKYkLMmertYfp2G+JXoe8u+PMCZ5aEutLACu20dsYeqTPkn0PKBuq ZGQbH/FcHyUyazieiAfHuCcKqZ6mdyEwGStQETxlRJRvCT9ExyEXfTurBb7o78I7QNf3 vY54AVNgXHzo45I8D+Dd0sHx6VXL6HBkKU9dCnTXJ9UbvSMB/JptjgWyHtPvclVzEGpN uqP2VtaX26OL6GREYQVTa1Oc8rfmDx6DNsLCcou+c4Qr2h7k/8K5awrMYbo8f2QaSwPo WjNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nxlFw0MLp4ccD4+W8rUV01dCYdPGlbPVZbSbqqtogbI=; b=Ql42U+zv5ShIPbYehB99USF1MAvriI2h60Tgiz1S2p3j+Oa4AdI8doXlU0UTTFafDL koNaXhG2gm7PTRlQ+ZZ2JfcMZgtnlYS2YvmGI+ZpE1VjK21GL8cdTt7tcMMgxoR4Ckxo z5Qgrn/LynDVfPRhBwLdL4DR+f3HLsI0vO3badPu45yrDXC6CPbLJ7DCdCkS2sXAkDFn RyxG9qzqIS14W/L95Eu3ydKU2GNAUdZ/1QZanvvlAdQpyWZBtIT0UHYtlwCBZyQ5WYlC NqT86rd5XlzIUJGoQc/+rWPPgoGsLACl+RvcngNI1E5lelZbSfb1CdhvYmY1TuvvUZEt KUqw==
X-Gm-Message-State: ALoCoQkl4Z9quqKqEug4pgwfMu3gE5Ohyik3zrHwidoO4PzHMSwkm44nySZwh7KZvhlo6AHU8vsO
MIME-Version: 1.0
X-Received: by with SMTP id a3mr2755048qaj.59.1410450787199; Thu, 11 Sep 2014 08:53:07 -0700 (PDT)
Received: by with HTTP; Thu, 11 Sep 2014 08:53:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 11 Sep 2014 16:53:06 +0100
Message-ID: <>
From: Ben Laurie <>
To: Stephen Kent <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Trans] Precertificate format
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Sep 2014 15:53:10 -0000

On 11 September 2014 16:21, Stephen Kent <> wrote:
> Ben,
>> Until there is such a mechanism, omitting serial numbers makes it hard
>> (or impossible?) for anyone to take effective action on violations
>> discovered via CT. So, CT has to require serial numbers until then.
>> This language allows that to happen.
> I think we're in agreement, which I why I proposed an alternative
> mechanism to log serial numbers, without requiring a CA to have
> to assign them prior to final cert issuance.

I managed to miss that proposal. I've found it now.

There seems to be a flaw: if I'm an evil CA wishing to issue an evil
certificate, I simply log a precert, minus serial, get an SCT*, log a
certificate containing that SCT*, which I then revoke when requested
to do so,

In order to attack a user with the evil certificate, I simply issue a
second copy with a different serial, containing the original SCT*, and
the certificate works. Yes, the discrepancy should be discovered in
audit, but that is a significantly weaker protection than we get if
the serial is included in the pre-certificate.

Also this adds quite a lot of complexity in order to allow what
appears to be, so far, an entirely theoretical use case.