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

[Rob Stradling <[e-mail]>]

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

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.
   or
   ii) Define a CtExtensions extension to carry the entry_type 
explicitly in a v1 SCT.
   or
   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: _http://tools.ietf.org/wg/trans/trac/ticket/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