Re: [Trans] Question about PRIVATE option (Ticket #1)

Rob Stradling <> Tue, 11 March 2014 10:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7DFA71A066D for <>; Tue, 11 Mar 2014 03:34:26 -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 oYB_v0X_dpEb for <>; Tue, 11 Mar 2014 03:34:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ACB7E1A066C for <>; Tue, 11 Mar 2014 03:34:21 -0700 (PDT)
Received: (qmail 28563 invoked by uid 1000); 11 Mar 2014 10:34:14 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 11 Mar 2014 10:34:14 +0000
Message-ID: <>
Date: Tue, 11 Mar 2014 10:34:14 +0000
From: Rob Stradling <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Rick Andrews <>, "" <>
References: <544B0DD62A64C1448B2DA253C011414607C70EAF9E@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C70EAF9E@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [Trans] Question about PRIVATE option (Ticket #1)
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, 11 Mar 2014 10:34:26 -0000

Rick, thanks for raising this.  I agree that we need to make the PRIVATE 
option work in these scenarios.  As it happens, I mentioned this to Ben 
just before the trans meeting last week.

My suggestion is that we should permit both Certificate SCTs _and 
Precertificate SCTs_ to be delivered via OCSP Stapling and the TLS 

There's no reason why a Precertificate couldn't be issued _after_ the 
corresponding Certificate has been issued!  :-)

Would this work for you?

Slight complication...
In the SCT v1 format, entry_type is "implicit from the context in which 
the SCT is presented."
So, for the above idea to work, we would need to either:
   i) Define SCT v2, in which entry_type is expressed explicitly.
   ii) Define a CtExtensions extension to carry the entry_type 
explicitly in a v1 SCT.
   iii) Expect TLS Clients to attempt to verify v1 SCTs sent via OCSP 
Stapling or the TLS Extension twice (first time, assume entry_type is 
"x509_entry"; if the SCT signature doesn't verify, try again, this time 
assuming entry_type is "precert_entry").

On 10/03/14 18:58, Rick Andrews wrote:
> Regarding Issue #1: _
> “Need options for avoiding logging private subdomains”, I think the
> design is not yet complete.
> I understand how this works when my customer has chosen the precert
> delivery option (I mask the second level domain in the precert that I
> send with the add-pre-chain command).
> But if my customer has chosen to deliver SCTs via OCSP staple or TLS
> extension, and they want to keep their subdomain private, what do I do?
> I’m going to sign the cert without SCTs in it, but if I log it via an
> add-chain command, the subdomains will be visible in the log.
> -Rick

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