Re: [Trans] Precertificate format

Rob Stradling <> Wed, 10 September 2014 09:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 162B81A06C2 for <>; Wed, 10 Sep 2014 02:23:47 -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 JYz2cF3x7q0j for <>; Wed, 10 Sep 2014 02:23:44 -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 6283D1A06B8 for <>; Wed, 10 Sep 2014 02:23:44 -0700 (PDT)
Received: (qmail 4148 invoked by uid 1000); 10 Sep 2014 09:23:42 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 10 Sep 2014 10:23:42 +0100
Message-ID: <>
Date: Wed, 10 Sep 2014 10:23:42 +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: Stephen Kent <>,
References: <> <><><544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><><> <>
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: Wed, 10 Sep 2014 09:23:47 -0000

Hi Stephen.  That's an interesting idea, but I see a few issues.

Step 4 requires the final cert to be logged, so it's incompatible with 
the name redaction mechanism.

Monitors want to detect misissuance (i.e. certs that have been issued 
incorrectly).  I'm not sure that it's reasonable to expect Monitors to 
also take responsibility for detecting non-issuance of certs that should 
have been issued.

On 09/09/14 19:23, Stephen Kent wrote:
> Eran,
>> I see two issues:
>> * What should the precertificate contain.
>> * What should be the format of the precertificate.
>> First I'd like to point out that there already is a way to issue
>> precertificates without violating section in 5280:
>> As Matt correctly pointed out, when a Precertificate  is signed by a
>> Precertificate Signing Certificate, then the log produces a signature
>> over a TBSCertificate that _uses the final issuer's identity_, not the
>> one in the Precertificate Signing Certificate (hence the requirement
>> that the Precertificate Signing Certificate will be signed directly by
>> the certificate that will ultimately sign the end-entity certificate
>> the Precertificate represents).
> Well, since certs are NOT used to sign anything, I can't agree with the
> phrase "As Matt correctly pointed out" ;-).
>> That is explained in section 3.2 of RFC6962 ("Structure of the Signed
>> Certificate Timestamp") or in compliant code
>> <>.
>>  We could do a better job of explaining this in RFC6962-bis (I
>> personally found it confusing when implementing the Java CT API).
> 6962-bis is what needs to be clear. Also, code is not generally viewed
> as a spec, for IETF purposes.
>> On what precertificates should contain:
>> Seems like there's a consensus that it should be all data in the final
>> certificate, except for the serial number, for which there's no agreement.
>> The argument against including the serial number, raised
> Count me as not part of the consensus. I still want to see an analysis
> of why selected
> cert data needs to be part of the SCT.
>> mostly by Stephen, is that it may be difficult for CAs who use HSMs to
>> determine/generate the serial number in advance. I don't recall any CA
>> strongly supporting this position (and, given precertificates from
>> several CAs have already hit CT Logs, that's definitely not an issue
>> for several CAs).
> On this list, very few CAs seem to be participating. I seem to recall
> one CA commenting that
> they had concerns about the per-cert model. I see that one CA, a
> co-author of the doc, says
> it was easy to implement. When I was in Beijing last week I spoke with
> folks who deal
> with cert issuance there (under CNNIC) and they were completely unaware
> of the TRANS WG.
> I wonder how many other CAs outside of the CABF are tracking this activity?
>> The argument for including the serial number is its necessity for
>> revoking a certificate - Somebody has mentioned alternative revocation
>> mechanisms that do not require it but have not provided any
>> references, and all current mechanisms I know of require the serial
>> number.
>> We all realize the requirement for pre-generating the serial number is
>> a disruptive one for the certificate issuance process - Given the
>> authors of RFC6962 have tried hard not to introduce disruptive
>> changes, I think this is a reasonable given the necessity of the
>> serial number.
> here's an off-the-cuff idea on how to have our cake and eat it too.
> 1. A CA submits a cert template ala CRMF.
> 2. A log operator generates an SCT* based on this data, and returns it.
> 3. The SCT* is embedded in a cert by the CA.
> 4. The CA submits the SCT*, plus the issued cert plus to the same log
> operator, and
> a new data item is created, the SCT. It links the serial number to the
> previously-issued
> SCT*. If there is a mismatch between the SCT* and the final cert, the
> Monitor will
> refuse to issue an SCT.
> (A Subject who submits its cert gets an SCT. The serial number is not a
> problem here.)
> A TLS client that checks for the presence of an SCT acts as before, but
> with slightly
> different processing to match the SCT against the received cert. This
> seems to offer
> equivalent (analogous) guarantees to the client, but without a threat
> model I can't be
> sure if there is a gap here.
> A Monitor will examine a log to determine when an SCT* was issued and no
> SCT was issued subsequently. That is a red flag. An SCT without a
> preceding SCT* is not a problem, as this
> is what would occur if a Subject (or OCPS server?) requested an SCT.
> Steve
> _______________________________________________
> Trans mailing list

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.