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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
