Re: [Trans] Precertificate format

Matt Palmer <mpalmer@hezmatt.org> Tue, 09 September 2014 00:27 UTC

Return-Path: <mpalmer@hezmatt.org>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440791A0301 for <trans@ietfa.amsl.com>; Mon, 8 Sep 2014 17:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQhOYlDLaPUY for <trans@ietfa.amsl.com>; Mon, 8 Sep 2014 17:27:50 -0700 (PDT)
Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 07D3F1A0327 for <trans@ietf.org>; Mon, 8 Sep 2014 17:27:50 -0700 (PDT)
Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 5CEE4282E0B for <trans@ietf.org>; Tue, 9 Sep 2014 10:27:49 +1000 (EST)
Received: by mistress.home.hezmatt.org (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 <mpalmer@hezmatt.org>
To: trans@ietf.org
Message-ID: <20140909002747.GP5645@hezmatt.org>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <540E0E90.1070208@bbn.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/quEjRgdaVcnVNrDMj7zwI5vRwD8
Subject: Re: [Trans] Precertificate format
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=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