Re: [Trans] Precertificate format

Kyle Hamilton <> Tue, 09 September 2014 23:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C65701A02BD for <>; Tue, 9 Sep 2014 16:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UVWrbBZkoxJB for <>; Tue, 9 Sep 2014 16:41:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 333371A00EB for <>; Tue, 9 Sep 2014 16:41:48 -0700 (PDT)
Received: by with SMTP id bj1so5149591pad.28 for <>; Tue, 09 Sep 2014 16:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=Y1OUgFUOooBc0wHBkn9Mqtg09kigMp7sDEURIDnLYK4=; b=IvJtPKH8mp5OoSUHE5pZ1xXQne5FfrN8wsHMODh+b68g9V7bQGXYIZlX0CY3o6Xy0q 4Edmj7G3fk1DywLQSY/z6SXbRjDu/fVgEjD5WooFeez5VjSki2vPBgg04LbIzWKkrqA8 eeIfa3ZMfuNrI+zVrIZV4rnyNhrYYtJM4syA7QuITHTHVtwNP954P0T+LhyCX6kw/tu3 4M8NH62A9eUg3dDiUPbqR7B/hZC+KpLhYEy+Ljf5ug6yGUifhvt0iy2OzpV4qJ6TZm8Z PLXCfVZcEreRU/k72IFcX7NPBcO+sRNivgi+BN/95OMyOUb8C041wAFCBnznOfOpQqlz Xojw==
X-Received: by with SMTP id z2mr61112748pdk.119.1410306107873; Tue, 09 Sep 2014 16:41:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ez8sm12765223pdb.63.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 16:41:46 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <> <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----QO6BFN5293JWNRJ3M68GYW183DZM0X"
Content-Transfer-Encoding: 8bit
From: Kyle Hamilton <>
Date: Tue, 09 Sep 2014 16:40:35 -0700
To: Brian Smith <>, Rick Andrews <>
Message-ID: <>
Cc: "" <>, Stephen Kent <>
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: Tue, 09 Sep 2014 23:41:49 -0000

I think the best way to change a Certificate into a Precertificate would be to alter the first field of the tbsCertificate to be non-optional and explicitly tagged as something other than tag [0].  Then, reconstruct the actual tbsCertificate by changing the first field to tag [0], perform any other necessary edits (like, for name redaction), re-encode the validly-tagged tbsCertificate to DER, and digest the encoded data.

But, I also proposed (a few years ago) a way to include an issued certificate list in a CRL extension to mitigate the Diginotar-style "we didn't know it had been issued" problem, and to be able to feed CRL-based OCSP responders with a minimum of code changes. That didn't go anywhere, and I expect this suggestion to go nowhere as well.

-Kyle H

On September 9, 2014 12:56:11 PM PST, Brian Smith <> wrote:
>On Mon, Sep 8, 2014 at 4:24 PM, Rick Andrews
><> wrote:
>>> The CA may use a Precertificate Signing Certificate to sign the
>Precertificate, and then sign the final certificate with the production
>CA certificate. Then, there would be no duplicate serial number issues.
>> Brian, even if the CA uses a Precert signing cert, the precert's
>issuer name has to be that of the ultimate issuer, and the serial
>number has to be that of the ultimate certificate, so I don't think
>that solves the problem.
>Thanks for pointing that out. Basically, the cause of that problem is
>that a Precertificate is a syntactically-valid X.509 certificate, and
>so it could be considered a duplicate of the final certificate. If the
>Precertificate weren't a syntactically-valid X.509 certificate, then
>there would be no way it could be considered a duplicate. So, why not
>make this simple change to the syntax:
>enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;
>  struct {
>    LogEntryType entry_type;
>    select (entry_type) {
>      case x509_entry: ASN.1Cert;
>      case precert_entry: ASN.1Precert;
>    } entry;
>    ASN.1Cert certificate_chain<0..2^24-1>;
>  } LogEntry;
>  opaque ASN.1Cert<1..2^24-1>;
>  opaque ASN.1Precert<1..2^24-1>;
>where the internal syntax of ASN.1Precert is (in ASN.1):
>  ASN1Precert ::=  SEQUENCE  {
>    precertSigningCert [0] EXPLICIT OptionalCertificate,
>    tbsCertificate       TBSCertificate,
>    signatureAlgorithm   AlgorithmIdentifier,
>    signatureValue BIT STRING }
>  OptionalCertificate ::= certificate Certificate OPTIONAL;
>In other words, ASN1Precert is exactly an X.509 Certificate except
>that it starts with an explicitly-tagged, possibly-empty
>precertSigningCert field. Thus, no X.509 certificate parser would
>parse a precert as though it were a real certificate, and so the
>precert could never be considered a duplicate of the final cert.
>Additionally, there would be no need for the "poison extension"
>because the added precertSigningCert field serves the same purpose.
>This strawman only attempts to solve the "duplicate certificate"
>problem, not the "must reserve the serial number in advance" problem.
>However, I suspect that this change would make it more difficult for
>some CAs to create precertificates.
>Trans mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.