On 12/03/14 14:23, Eran Messeri wrote:
IMHO Option (ii) is the most straightforward solution. Option (iii)
exposes the client to further complication (supporting private
subdomains already complicates the client code).
I agree.
For SCT v2 (should we decide to have one) the entry_type could be an
optional field outside the extensions.
How would you do "optional" in TLS encoding?
I think it would have to be a required 1-byte field.
On Wed, Mar 12, 2014 at 12:14 PM, Rob Stradling
<[email protected] <mailto:[email protected]>> wrote:
On 11/03/14 20:35, Rick Andrews wrote:
Rob,
What you're suggesting is that the add-pre-chain command can be
used to log a cert that ultimately will not include the SCTs in
the final cert?
Yes.
That seems like a path forward.
Great.
For the slight complication you describe, I suppose that needs
to be added to the issue tracker.
Yes. I just wanted to check that it would work for you before I did
that.
I've just added http://trac.tools.ietf.org/wg/__trans/trac/ticket/10
<http://trac.tools.ietf.org/wg/trans/trac/ticket/10>
-Rick
-----Original Message-----
From: Rob Stradling [mailto:rob.stradling@comodo.__com
<mailto:[email protected]>]
Sent: Tuesday, March 11, 2014 3:34 AM
To: Rick Andrews; [email protected] <mailto:[email protected]>
Subject: Re: [Trans] Question about PRIVATE option (Ticket #1)
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#_
<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] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/trans
<https://www.ietf.org/mailman/listinfo/trans>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505 <tel:%2B44.%280%291274.730505>
Office Fax: +44.(0)1274.730909 <tel:%2B44.%280%291274.730909>
www.comodo.com <http://www.comodo.com>
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.
_________________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/trans
<https://www.ietf.org/mailman/listinfo/trans>
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
