Re: [Trans] Precertificate format

Stephen Kent <kent@bbn.com> Mon, 08 September 2014 20:16 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 8CE7C1A032E for <trans@ietfa.amsl.com>; Mon, 8 Sep 2014 13:16:30 -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 YEXx9fEP8ocA for <trans@ietfa.amsl.com>; Mon, 8 Sep 2014 13:16:23 -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 D421D1A02F2 for <trans@ietf.org>; Mon, 8 Sep 2014 13:16:20 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:38051 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XR5MJ-000A93-Sd for trans@ietf.org; Mon, 08 Sep 2014 16:16:19 -0400
Message-ID: <540E0E90.1070208@bbn.com>
Date: Mon, 08 Sep 2014 16:16:16 -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>
In-Reply-To: <540DFA75.2040000@gmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Zq3q5SWZq37tNuapyub_vCKyrt0
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: Mon, 08 Sep 2014 20:16:30 -0000

Melinda,

The problem is bigger than just the choice of format for the SCT response.

The current pre-cert model requires a CA to be able to issue two certs with
the same serial number. This would, in general, be a very bad thing for a CA
to do. So, mandating this behavior is very worrisome. And, as you noted, it
clearly violates 4.1.2.2 of 5280. (Thanks, I should have noted that.)
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.

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 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.

Steve