[Trans] Fwd: Precertificate format

Erwann Abalea <eabalea@gmail.com> Mon, 20 October 2014 13:43 UTC

Return-Path: <eabalea@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id AA4291A876B for <trans@ietfa.amsl.com>; Mon, 20 Oct 2014 06:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xTMVGlv_mgqL for <trans@ietfa.amsl.com>; Mon, 20 Oct 2014 06:43:51 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731051A877E for <trans@ietf.org>; Mon, 20 Oct 2014 06:42:35 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id la4so3577057vcb.27 for <trans@ietf.org>; Mon, 20 Oct 2014 06:42:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=e8Zx0HsGOl2N64uruf88FZfvLOOwHCkIKQ4JMQtfvtg=; b=jaTdorD18Txb7Jk5DHeXMB+V3UDmLC+p1hm1iAg4vcoo70+tBloAiYaywSX/Mzd1JK QyKMir1RobGBmU8idWFHLMnHW5jDecMk+bZrW7PjiQAvqjl4XXM7PEVnrTWtkpPEX8pQ 9xMqyMdFLDzsnTlotmXRjsQYNK2W/VuF2XHrtziTzNdREtH1xOLDukwbW7r6zI2jqKeC VzYYYCUnLCPCzOdbhJYh5E/Ugtro3/uUkqrtPI25yKE+fwe6+VEvB3vSwLCM56aoGG8L mQAWtfWbRe0KJwx9462IxYpCo0yQwnTHXCI45tkdQVef/FQ2DS5fWQbPtSXDXiFbH6x0 PYJA==
MIME-Version: 1.0
X-Received: by with SMTP id c7mr828158vcl.61.1413812554378; Mon, 20 Oct 2014 06:42:34 -0700 (PDT)
Received: by with HTTP; Mon, 20 Oct 2014 06:42:34 -0700 (PDT)
In-Reply-To: <CABrd9ST-a64kDK82a-ATDW2JkuHZWbGfO0-Rmtgv5mbYrnwZPQ@mail.gmail.com>
References: <CABrd9ST-a64kDK82a-ATDW2JkuHZWbGfO0-Rmtgv5mbYrnwZPQ@mail.gmail.com>
Date: Mon, 20 Oct 2014 15:42:34 +0200
Message-ID: <CA+i=0E6v7-1zvs4XcbqE2pSGg7814=p2NbbPUaWjKT9BBBYeVA@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary=089e016340381569580505dae344
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/UK21kAWvI6f0tt_JHA-AuBXKa54
Subject: [Trans] Fwd: 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, 20 Oct 2014 13:43:53 -0000

Discussion around the format happened in mid/late september, the idea of a
CMS/PKCS#7 structure to hold the signature seems fine.
Additional questions come in: is the new format intended to *replace* or
*complement* the current one? If it's a replacement, what timeframe? CAs
are already doing software modifications and deployment, please be nice :)

The same question remains on the knowledge of the serial number before
generating the final certificate, with no objection so far, even with
arguments raised by Stephen Kent (valid ones, I used such HSMs in the past
for SET certs, the BBN SafeKeyper Signer).
It seems that no public CA concerned by CT is using such HSM, I guess they
all use a HSM for its key handling job and do certificate generation at a
software level.

2014-10-16 17:09 GMT+02:00 Ben Laurie <benl@google.com>om>:

> We (the 6962-bis editors) would like to propose that we replace the
> existing precertificate formats with a TBSCertificate wrapped in PKCS#7.
> This lays to rest, we think, any possible confusion with X509v3 certs,
> whilst allowing a simple mapping between the final cert and the pre-cert.
> Obviously there are details to be nailed down, but before we do so, we'd
> like to hear any discussion on the general idea.