Re: [Trans] Precertificate format

Carl Wallace <> Tue, 09 September 2014 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3C6961A6FF6 for <>; Tue, 9 Sep 2014 09:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gE29D_PR_Trp for <>; Tue, 9 Sep 2014 09:20:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2E661A6FE9 for <>; Tue, 9 Sep 2014 09:20:26 -0700 (PDT)
Received: by with SMTP id z60so2191318qgd.23 for <>; Tue, 09 Sep 2014 09:20:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=S1cGrg/WyjgDktogrVZ61pQQAVKcVg5ZaKVXRzW+d2E=; b=R2rcEfnveVYo8JZLhRJ+hB2YQB26mVvK9TE5U1eCl/0erfP7g0Tl1sZwiWMMCBixA6 D2cR/bJRY2vz6sQO9mbrvXYi/Lb78ZP3PB1wz1M1Ur7pulWa5CSdu3PHw0PWb9XmdnU8 RVB/Keotegh8Ork/BbeoxGrj4hrtvh2Ccd6HwYz96H0t56vofRvbEVHn6Waxgv9Bv5iR yMLRSNA41GVPDERaPUli7NLlDWYV/Hoj7dKO9G8eQuBTUQAwHxIeZFnUFGunFc4Offjs PZHBNQDmz0vu37R0TVuEJ/aqfWcH2YbxIOUa1ObPuycU1BtmAJ6aNVifIL29H+A6d3Ul Id4Q==
X-Gm-Message-State: ALoCoQl8w5AJ83GVBvm4V2bLOAKEwS6h/likIkA2duXkFUgNhxBqgnYiS5xaTatnwatw106lajHH
X-Received: by with SMTP id j7mr8357622qci.22.1410279624136; Tue, 09 Sep 2014 09:20:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t67sm10175442qge.13.2014. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Sep 2014 09:20:23 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Tue, 09 Sep 2014 12:18:57 -0400
From: Carl Wallace <>
To: Ben Laurie <>
Message-ID: <>
Thread-Topic: [Trans] Precertificate format
References: <> <> <> <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
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: Tue, 09 Sep 2014 16:20:29 -0000

On 9/9/14, 8:07 AM, "Ben Laurie" <> wrote:

>On 9 September 2014 00:24, 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
>Surely it does, since it is actually signed by the precert signing

I think the point above is that the issuerName/serialNumber is what is
required to be unique, not issuer’s public key/serial number.

>Changing the issuer name just means its even less of a conflict,
>since it then shouldn't even validate according to normal rules.

It may be worth requiring the pre-certificate signing certificate to omit
the basicConstraints extension to further reduce conflict.

Different question, why must the SKID in the pre signing certificate match
the AKID in the TBSCertificate (as noted in 3.3)?  Seems like a bad idea
to have the same SKID in both the pre-certificate signing certificate and
in the real CA certificate.  Allowing the SKID be calculated as per normal
and placing the SKID of the final issuer in a SAN may be a better