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

Rob Stradling <rob.stradling@comodo.com> Wed, 12 March 2014 12:14 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21651A0969 for <trans@ietfa.amsl.com>; Wed, 12 Mar 2014 05:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU0uSjAQDjaB for <trans@ietfa.amsl.com>; Wed, 12 Mar 2014 05:14:31 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6B1A0968 for <trans@ietf.org>; Wed, 12 Mar 2014 05:14:30 -0700 (PDT)
Received: (qmail 19482 invoked by uid 1000); 12 Mar 2014 12:14:22 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 12 Mar 2014 12:14:22 +0000
Message-ID: <53204F9E.7000507@comodo.com>
Date: Wed, 12 Mar 2014 12:14:22 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Rick Andrews <Rick_Andrews@symantec.com>, "trans@ietf.org" <trans@ietf.org>
References: <544B0DD62A64C1448B2DA253C011414607C70EAF9E@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <531EE6A6.7000007@comodo.com> <544B0DD62A64C1448B2DA253C011414607C77BCCBE@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C77BCCBE@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/HoN4ZZpzZdFaQI1rmhBuucTLPpg
Subject: Re: [Trans] Question about PRIVATE option (Ticket #1)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 12:14:35 -0000

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

> -Rick
>
>> -----Original Message-----
>> From: Rob Stradling [mailto:rob.stradling@comodo.com]
>> Sent: Tuesday, March 11, 2014 3:34 AM
>> To: Rick Andrews; trans@ietf.org
>> 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#_
>>> "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
> Trans@ietf.org
> 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.