[Trans] Where do things stand with the precertificate format discussion?

Melinda Shore <melinda.shore@gmail.com> Wed, 17 September 2014 21:45 UTC

Return-Path: <melinda.shore@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 6973D1A6F66 for <trans@ietfa.amsl.com>; Wed, 17 Sep 2014 14:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id w-X8RNXmY51R for <trans@ietfa.amsl.com>; Wed, 17 Sep 2014 14:45:53 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5795F1A6F56 for <trans@ietf.org>; Wed, 17 Sep 2014 14:45:53 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id rd3so2995050pab.18 for <trans@ietf.org>; Wed, 17 Sep 2014 14:45:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=g81MJIGVVykpxpima4cIZrNQJOpyiVlTTm5rOT6ipaQ=; b=tkrKBOuq4hK1XeI9k33dyI9rjTIEGZFN+VAp2IoDFqY6OLQGsR23zDvShNpUVnxV7u BGD4CbIpDHOtu/caHcbu3EGWFr4yIdfBpbzwDRZC0AjGWhzjSD4QY6q0OIDTeKlOlU6Q e7fRQ2xCEbbjAB3GinZRGdracCKdw6sk40UssATN8q1tTmU0/r0VrVvlbVdK668KRzkH JSohgSCUrYeGDdaBcPaWTQIpwew/xs8Xs6UWHyw+f/AhGyGw99saBbreCLUEEBQlA7nZ oGQl+2Qwrap+9d+EcmTuD7vSUyBiujWxhs5sp17+NoTUyVXfv2OQHUSMITgL7iF5yGsN p+Bw==
X-Received: by with SMTP id kd6mr607403pbc.74.1410990352782; Wed, 17 Sep 2014 14:45:52 -0700 (PDT)
Received: from spandex.local (209-193-52-59-rb2.nwc.dsl.dynamic.acsalaska.net. []) by mx.google.com with ESMTPSA id ns9sm549027pbb.70.2014. for <trans@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Sep 2014 14:45:52 -0700 (PDT)
Message-ID: <541A010E.8050402@gmail.com>
Date: Wed, 17 Sep 2014 13:45:50 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ftg0FyeRoqCgtaWsPblmBaOwTLs
Subject: [Trans] Where do things stand with the precertificate format discussion?
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: Wed, 17 Sep 2014 21:45:55 -0000

It looks like we've got two closely-related discussions:

1) precertificate format (representation), and
2) precertificate contents

There've been a couple of proposals for alternative representation,
including TBS (alternatively, the CertTemplate format from 4211) and
CRMF, and there seems to be some agreement congealing around Erwann's

>IIUC, what you propose is that the PreCert is a CMS (RFC5652) with a
>signedData content-type, for which the data is the TBSCertificate
>(name-redacted or not, no necessary poison extension). The SignerInfo
>refers to the PreCert issuer (CA or dedicated issuer, same as now).

>It can only work if the log signs the content (=TBSCertificate) and not
>the whole CMS, thus ignoring the PreCert issuer signature. Leaving that
>signature aside isn't more risky than it is now because it's already
> the case (the log removes the poison extension before signing the
> resulting certificate, right?).

with an open question around serial numbers.

Related, there's a proposal on the table to walk through cert data and
justify SCT contents.

Does this sound about right?