Re: [Trans] Precertificate format

Rob Stradling <> Tue, 09 September 2014 10:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C55771A6FB3 for <>; Tue, 9 Sep 2014 03:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fhkN_wMr13Fq for <>; Tue, 9 Sep 2014 03:17:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8942A1A6FEA for <>; Tue, 9 Sep 2014 03:17:02 -0700 (PDT)
Received: (qmail 24447 invoked by uid 1000); 9 Sep 2014 10:17:00 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 09 Sep 2014 11:17:00 +0100
Message-ID: <>
Date: Tue, 09 Sep 2014 11:17:00 +0100
From: Rob Stradling <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Melinda Shore <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; 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 10:17:05 -0000

On 08/09/14 19:50, Melinda Shore wrote:
> It seems as if we've been talking about precertificate format for
> quite some time, without coming to resolution.  Let's try to find
> agreement on how to handle it and close issue 26.
> The ticket, with description, is here:
> The fundamental problem is that because precertificates are currently
> encoded as X.509 structures we have the potential for two certificates
> to exist with the same issuer and same serial number.  Because the
> precertificate is not usable as a TLS certificate in practice, this
> may not be an issue.  However, it's a clear violation of section
> in 5280 (and to be honest I'm a little fuzzy on its implications for
> CRL processing).
> So, are you all comfortable with letting the X.509 representation
> stand, or do you have an alternative proposal?

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?

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

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online