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

Erwann Abalea <> Thu, 18 September 2014 21:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F4C01A6EEC for <>; Thu, 18 Sep 2014 14:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id omCGoX8vF5pe for <>; Thu, 18 Sep 2014 14:18:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40F941A6F47 for <>; Thu, 18 Sep 2014 14:18:24 -0700 (PDT)
Received: by with SMTP id id10so144957vcb.14 for <>; Thu, 18 Sep 2014 14:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u19Ls/wAfKDCpQP+AO4R/ogjPdpGrBluvufqwDc/MLU=; b=pUnHEADPWgGtNfMPH5yWulzVvFy/hbWhJWG9vetXK7A910s5MalPYbllmJrT2bVcp0 mT2jmqS6oiL/KbBnOjXh+BYAcHmqdGwUSyCF/M5GCZltqF4FcPLrNaZj6/HE4XIohLwr UlbWm51EBI07G2u8HCVhR2AsCxEyCIeVT5w0z58i5FhET82LuWQZigPwJleskeYgFs2h 0W59LauXVWuz8cEJKNfnXnntJASuLKHSkzw2wb6RlZGyjxbiPc5/f1D4BAXop9TfHFla QtpLPBt2GKU4+C32YmswSaeFGg92qH1A7DlkuU0GJqiTlHUa+8ENEOpr+wQihJnhIaoc HqXA==
MIME-Version: 1.0
X-Received: by with SMTP id vw2mr1396243vcb.29.1411075103168; Thu, 18 Sep 2014 14:18:23 -0700 (PDT)
Received: by with HTTP; Thu, 18 Sep 2014 14:18:23 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 18 Sep 2014 23:18:23 +0200
Message-ID: <>
From: Erwann Abalea <>
To: Brian Smith <>
Content-Type: multipart/alternative; boundary=001a1133a0fe469fb705035d86ad
Cc: Melinda Shore <>, "" <>
Subject: Re: [Trans] Where do things stand with the precertificate format discussion?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Sep 2014 21:18:26 -0000


2014-09-18 0:35 GMT+02:00 Brian Smith <>rg>:

> On Wed, Sep 17, 2014 at 2:45 PM, Melinda Shore <>
> wrote:
> > 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
> > summary:
> >
> >>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).
> CMS is not a good format for the PreCert, because CMS is highly
> complicated and unnecessarily complex for this purpose. And, in
> particular, CMS is specified as a BER-encoded format, not a
> DER-encoded format,

BER/DER doesn't concern the payload of the CMS (here, the TBSCertificate,
which will be DER encoded anyway).
CMS is complex and flexible, but this complexity is already known, and it
will be handled by logs+monitors+auditors only.
More important, CMS is already present in the bestiary of objects that
anyone involved in PKI knows.

and it isn't reasonable to require implementations
> to support a BER-encoded format for CT when all other things they
> process are DER-encoded. In particular, some implementations may have
> specialized DER decoders that cannot be practically adapted to deal
> with BER.

Fine. Let's say that for the purpose of CT, the CMS SHOULD be DER encoded.
Those CMS objects will still be RFC5652 compliant (DER is a subset of BER).

I previously suggested an alternative syntax that would be much easier
> to implement:

That's another solution, but it will force everyone to add this specific
object to their libraries. It will require more efforts.