Re: [Trans] Precertificate format

Matt Palmer <> Tue, 09 September 2014 00:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 440791A0301 for <>; Mon, 8 Sep 2014 17:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.721
X-Spam-Level: *
X-Spam-Status: No, score=1.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qQhOYlDLaPUY for <>; Mon, 8 Sep 2014 17:27:50 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f0e:9e6::2]) by (Postfix) with ESMTP id 07D3F1A0327 for <>; Mon, 8 Sep 2014 17:27:50 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 5CEE4282E0B for <>; Tue, 9 Sep 2014 10:27:49 +1000 (EST)
Received: by (Postfix, from userid 1000) id 514D9A01A5; Tue, 9 Sep 2014 10:27:47 +1000 (EST)
Date: Tue, 9 Sep 2014 10:27:47 +1000
From: Matt Palmer <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 00:27:52 -0000

Hi Stephen,

On Mon, Sep 08, 2014 at 04:16:16PM -0400, Stephen Kent wrote:
> Thus, I suggest we use a different format. I suggest sticking with ASN.1,
> since the data used to compute the SCT will come from a cert, and ASN.1 is
> the native cert format description language. DER encoding is also good for
> creating a canonical representation for signature generation.

I'm in agreement that ASN.1/DER should be used wherever we're dealing with
"certificate-like" data.  I know of the concerns regarding the, uh,
"elevated potential", shall we say, for security bugs in DER-handling code,
but that's got to be weighed against the potential for bugs in whatever code
has to be custom-written to deal with whatever *other* encoding format is
used for the data.

> However, Ben has noted that even if we use a different format for the
> pre-cert data, the data MUST contain the serial number of the cert that is
> eventually issued.  This is almost as much of a problem for CAs, at least
> in principle.  Remember that the DigiNotar breach (which is a major
> motivation for CT) was especially bad because the attackers were able
> erase all evidence of the bogus certs that they issued.  Countermeasures
> to such attacks might preclude a CA from knowing what serial number will
> appear in a cert until it is issued.  (I mentioned one such counter-
> measure in a FIPS level 3 HSM from long ago, in a prior post.)

I don't know all the specifics of the Diginotar breach, but I'm not
conceiving of a situation in which knowing the serial number of a
certificate in advance helps an attacker erase the evidence of a bogus cert
having been issued.  Knowing a serial number in advance, or being able to
specify a serial (rather than having one auto-generated) shouldn't have any
impact on the tamper-proof log of CA operations which I would expect to be a
fundamental part of any CA.  Also, it'll be awfully hard for a future
attacker to erase proof of issuance if the CA is logging all their certs to
a variety of CT servers.

On the other hand, I can certainly empathise with the sentiment that
removing/modifying reasonable safety checks that prevent a given CA from
issuing two certificates with the same serial is a scary proposition. 
The CT spec has a way to avoid that, though, by issuing pre-certs from a
separate CA to that of the CA issuing the eventual certificate.  That avoids
the need for duplicate serials.

> I suggest that the CT designers list which data items from a cert that is
> being logged need to be in the SCT request, and why each item has to be
> present.  Maybe that will show us how to avoid the concern that I and
> others have raised.  It would also provide us with a starting point for
> the format of a new data structure for the SCT request, and the set of
> data that is input to the SCT hash computation.

I can't speak for Ben, Adam, or the others with significant input into the
CT spec, but for myself I would want to see *everything* that goes into the
final certificate.  The goal of CT is to provide a publically available
database of the data which is being attested to by CAs.  I wouldn't want to
limit what the public is capable of auditing because of a lack of
imagination at the time the specification was codified.

- Matt

New Yankee Workshop isn't a "how to" for home hobbyists, it's "Baywatch" for
powertool fetishists.
		-- Geoff Kinnel, ASR