Re: [Trans] Precertificate format

Stephen Kent <kent@bbn.com> Tue, 09 September 2014 18:20 UTC

Return-Path: <kent@bbn.com>
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 5139C1A8860 for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 11:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level:
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 N4cMrfTIXe6u for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 11:20:49 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE951A885F for <trans@ietf.org>; Tue, 9 Sep 2014 11:20:49 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:38040 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XRQ24-0002sI-DN for trans@ietf.org; Tue, 09 Sep 2014 14:20:48 -0400
Message-ID: <540F44FE.5020300@bbn.com>
Date: Tue, 09 Sep 2014 14:20:46 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <20140909002747.GP5645@hezmatt.org>
In-Reply-To: <20140909002747.GP5645@hezmatt.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-jhMoazABp_QN-z5ODkVzXBUzps
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 18:20:54 -0000

Matt,

>> 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.
Sorry if I was unclear. I intended to say that if the attackers had not
been able to erase evidence of the issuance of bogus certs, then the attack
might have been discovered quickly. Using an HSM that assigns serial 
numbers,
helps with this concern, but such a design is precluded if one is 
required to
issue two certs with the same serial number.
>> 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.
I don't recall seeing the goal you described above in the I-D. More 
importantly
your statement is a description of a mechanism, not a security goal per se.
one would have to follow your statement of transparency with one that says,
then ....

I have suggested we need is a clear statement of the threat and a mapping
of CT to that threat model. I still think this is needed, and that it 
may help
us decide what needs to be covered by the SCT.

Steve