Re: [Trans] Precertificate format

Stephen Kent <> Tue, 09 September 2014 18:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 82B461A8873 for <>; Tue, 9 Sep 2014 11:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.853
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mj0o9YH-9W8r for <>; Tue, 9 Sep 2014 11:23:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B2A61A8864 for <>; Tue, 9 Sep 2014 11:23:06 -0700 (PDT)
Received: from ([]:39368 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1XRQ4H-0002w7-Hz for; Tue, 09 Sep 2014 14:23:05 -0400
Message-ID: <>
Date: Tue, 09 Sep 2014 14:23:03 -0400
From: Stephen Kent <>
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
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Trans] Precertificate format
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: Tue, 09 Sep 2014 18:23:08 -0000

> ...
> I don't mind us adding an alternative Precertificate format to 
> 6962-bis (if we can agree on a suitable format!), but I'd also like to 
> retain the RFC6962 Precertificate format as an option.
> Several CAs have already deployed code to generate RFC6962 
> Precertificates. Why force these CAs to change to a different format 
> just because some other CAs find it hard to implement the RFC6962 format?
Commonly in the IETF, there is no preference given to folks who have 
implemented against
an experimental RFC when that RFC is being revised to become a standards 
track doc.

Another way to look at this is to ask why a standards track should have 
to adopt a
design element from an Experimental RFC that received little review?

So, saying that clients, logs, auditors, etc. MUST support both seems 
> Some CAs will actually find it _easier_ to implement the RFC6962 
> Precertificate format than to implement some new format that we 
> haven't defined yet. (My experience: When I wrote Comodo's code for 
> RFC6962 Precertificates, reusing the TBSCertificate format was 
> definitely a blessing rather than a curse).
I can't argue with your personal experience as a developer. I can argue 
that, on the
basis of 5280 (, and on my experience as a developer of an HSM, 
the pre-cert
model is very problematic.