From nobody Mon Aug 4 10:55:42 2014 Return-Path: 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 39F391A00AB for ; Mon, 4 Aug 2014 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 bUeRpx-R3eLv for ; Mon, 4 Aug 2014 10:55:39 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7691A00A3 for ; Mon, 4 Aug 2014 10:55:39 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so8106117wev.41 for ; Mon, 04 Aug 2014 10:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gfLnfopqL+l5m/2IsuGXhzPT4X0f9gnlUF2Darg6Mn8=; b=TKWRU+Gd8G6vEpaSV5/CRcoyh71yb3sECCnGnJiUF34X46Aa8ZltR3ICjvZrpDLk10 oTq9EkTCEJ5hwOwAnvcaP3tYVhtl8nvcQaxrkI+q6ZTrNInI1R8Gp1fM8+K5SlQ2wp6S SuDbAAz9IGKfDYLqtMAQpRiX1WWR9jCA520PsmxUhkIake4f+4/s/Sxa7qDwMch8iGum LexwoXYucMDjfrdop0n2hFtzpflKEj6lCcoab5BkQCynzjg9IFffDlx7CAnI2Zl1ylBP W/zGFmiW7NybsnEj9QFjyOsqrOhRRpgvmYs1/Tfvrty0AKrH8NVJgaOMycJALhPZSv0f 9isg== X-Received: by 10.180.19.1 with SMTP id a1mr32663245wie.16.1407174935696; Mon, 04 Aug 2014 10:55:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.253.200 with HTTP; Mon, 4 Aug 2014 10:55:14 -0700 (PDT) In-Reply-To: References: <53D9600C.6040805@gmail.com> From: Fabrice Gautier Date: Mon, 4 Aug 2014 10:55:14 -0700 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/HCm1lqAFBS04gaB2A7B4nZ1KWag Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Tracking implementations X-BeenThere: trans@ietf.org 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: Mon, 04 Aug 2014 17:55:41 -0000 On Thu, Jul 31, 2014 at 6:36 AM, Ben Laurie wrote: > On 30 July 2014 17:13, Melinda Shore wrote: >> During the session last week I was a bit surprised by the number of >> people saying that they were doing implementations, and I think it >> might be useful to get a better handle on that. If nothing else, it >> helps quite a bit during the publication process if it's known >> that there are interoperable implementations and that we know a little >> bit about them. >> >> So, I'd be grateful if people who've are working on implementations >> and who can discuss them publicly could speak up, let us know the >> status and whether or not you'll be releasing source, and provide a >> pointer to a repo or other documentation if you're able. Also let >> me know whether or not you'd be willing to have your implementation >> mentioned on a wiki page listing implementations. > > Obviously(?) Google has an open source implementation here: > https://github.com/google/certificate-transparency. My understanding is that this is only an implementation of a CT log, am I correct ? > We also have two internal production implementations, both of which > share as much code as is feasible with the open source. No current > plan to release source that is not already released. > > Feel free to mention them on a wiki page. > >> >> Thanks again, >> >> Melinda >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Tue Aug 5 02:56:23 2014 Return-Path: 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 7FB971B28DD for ; Tue, 5 Aug 2014 02:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 IuMTLPsiAKxd for ; Tue, 5 Aug 2014 02:56:21 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7481B28D9 for ; Tue, 5 Aug 2014 02:56:20 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so1024550vcb.38 for ; Tue, 05 Aug 2014 02:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=quvpIof6TAGuuiHewKivghGnTJhGksbveCu6X9pKl1Y=; b=g//LjSbcxpCjARYXnI3jruKqcXfki/jPOS8KOa6FCDLV5MAcwxPLovAVLScuP76Lnu QfA7n4LmnhFQbYoUFQlIpH9v1XIbmQX/4+bl8rhkteOraE5VzG8dVZKTeLs38Q611/iJ S1M55aVE1piqMZrsonBAVjddF/Hf5NT2Fdlcr8utq4Us/66qSxcQ8vGJ0ZZoqNTYT3aH mQJpkfRre29a5vnflv4NAwoLPvBdgg+YCewDkVudRWr79163/Cc3syU4lXWiQbBmjlAt FjF7PxIwWC3iCbUZQgffDz8HOIuKwS3OCz8+39Y1xf5AIkqeozuAAASfopFiiC1yHtZA Srgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=quvpIof6TAGuuiHewKivghGnTJhGksbveCu6X9pKl1Y=; b=OgVVxefexScjn/csjL3ZxE544GAbTEJoLNlbyRXE8nLS9d0CJXu0hArXNFljaLIGVE qXXSuN7k8whYTIOE8hCrH8GVXNrKkUBKBO70JUEqxpOHrsWsDAWzLu1X4zBEYrcB83Rz PB9iNZZ9ZyVsNBFfBNv6lwyJO1Tt9R4enM0Vxe0r5IsURSMXbyY31GL//VwPyMqVP+jy r/4GyWM0fZaSb5pmqk/VDhTzMUVZomPuLxLnIgLNG1HY4LrkVHRX7Y3FZjFYnwmDdPTs 5La5cFPvEO827XDDk3QWbCshVGBrqKNOAGE/LHIabzWMZe5eKqRdeFXmi5pJjVhWUA5s 3YOA== X-Gm-Message-State: ALoCoQnHS2EEGXupWV69VD3fEFoE6wndS5DONqYivJ0+MSniQAn+ZeX6n8tyMKNgQeZf0ZAtU7DQ MIME-Version: 1.0 X-Received: by 10.220.68.140 with SMTP id v12mr2112506vci.13.1407232579864; Tue, 05 Aug 2014 02:56:19 -0700 (PDT) Received: by 10.52.24.82 with HTTP; Tue, 5 Aug 2014 02:56:19 -0700 (PDT) In-Reply-To: References: <53D9600C.6040805@gmail.com> Date: Tue, 5 Aug 2014 10:56:19 +0100 Message-ID: From: Eran Messeri To: Fabrice Gautier Content-Type: multipart/alternative; boundary=047d7b3a85060a267c04ffdede22 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/u4bkPAX4mRWfLwjslAv82F-Xn_w Cc: Ben Laurie , Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Tracking implementations X-BeenThere: trans@ietf.org 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, 05 Aug 2014 09:56:22 -0000 --047d7b3a85060a267c04ffdede22 Content-Type: text/plain; charset=UTF-8 No, there are also monitor implementations in C++ and (partially) python, log clients in C++, python and Java, as well as a TLS client in C++. There's also plenty of test data for rfc6962 implementations. While we're at it, there's another implementation in Chromium of SCT deserialization and validation, using NSS (vs. OpenSSL used in the open-source repository). On 4 Aug 2014 18:55, "Fabrice Gautier" wrote: > On Thu, Jul 31, 2014 at 6:36 AM, Ben Laurie wrote: > > On 30 July 2014 17:13, Melinda Shore wrote: > >> During the session last week I was a bit surprised by the number of > >> people saying that they were doing implementations, and I think it > >> might be useful to get a better handle on that. If nothing else, it > >> helps quite a bit during the publication process if it's known > >> that there are interoperable implementations and that we know a little > >> bit about them. > >> > >> So, I'd be grateful if people who've are working on implementations > >> and who can discuss them publicly could speak up, let us know the > >> status and whether or not you'll be releasing source, and provide a > >> pointer to a repo or other documentation if you're able. Also let > >> me know whether or not you'd be willing to have your implementation > >> mentioned on a wiki page listing implementations. > > > > Obviously(?) Google has an open source implementation here: > > https://github.com/google/certificate-transparency. > > My understanding is that this is only an implementation of a CT log, > am I correct ? > > > > We also have two internal production implementations, both of which > > share as much code as is feasible with the open source. No current > > plan to release source that is not already released. > > > > Feel free to mention them on a wiki page. > > > >> > >> Thanks again, > >> > >> Melinda > >> > >> _______________________________________________ > >> Trans mailing list > >> Trans@ietf.org > >> https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --047d7b3a85060a267c04ffdede22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

No, there are also monitor implementations = in C++ and (partially) python, log clients in C++, python and Java, as well= as a TLS client in C++.

There's also plenty of test data for rfc6962 implementat= ions.

While we're at it, there's another implementation in= Chromium of SCT deserialization and validation, using NSS (vs. OpenSSL use= d in the open-source repository).=C2=A0

On 4 Aug 2014 18:55, "Fabrice Gautier"= <fabrice= .gautier@gmail.com> wrote:
On Thu, Jul 31, 2014 at 6:36 AM, Ben Laurie <benl@google.com> wrote:
> On 30 July 2014 17:13, Melinda Shore <melinda.shore@gmail.com> wrote:
>> During the session last week I was a bit surprised by the number o= f
>> people saying that they were doing implementations, and I think it=
>> might be useful to get a better handle on that. =C2=A0If nothing e= lse, it
>> helps quite a bit during the publication process if it's known=
>> that there are interoperable implementations and that we know a li= ttle
>> bit about them.
>>
>> So, I'd be grateful if people who've are working on implem= entations
>> and who can discuss them publicly could speak up, let us know the<= br> >> status and whether or not you'll be releasing source, and prov= ide a
>> pointer to a repo or other documentation if you're able. =C2= =A0Also let
>> me know whether or not you'd be willing to have your implement= ation
>> mentioned on a wiki page listing implementations.
>
> Obviously(?) Google has an open source implementation here:
> https://github.com/google/certificate-transparency.

My understanding is that this is only an implementation of a CT log,
am I correct ?


> We also have two internal production implementations, both of which > share as much code as is feasible with the open source. No current
> plan to release source that is not already released.
>
> Feel free to mention them on a wiki page.
>
>>
>> Thanks again,
>>
>> Melinda
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org=
>> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org=
> https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans
--047d7b3a85060a267c04ffdede22-- From nobody Tue Aug 5 03:28:41 2014 Return-Path: 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 DBF6F1B2972 for ; Tue, 5 Aug 2014 03:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 CVGP0VqzhMlE for ; Tue, 5 Aug 2014 03:28:33 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136631B292B for ; Tue, 5 Aug 2014 03:28:32 -0700 (PDT) Received: (qmail 29725 invoked by uid 1000); 5 Aug 2014 10:28:30 -0000 Received: from and0004.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; Tue, 05 Aug 2014 11:28:30 +0100 Message-ID: <53E0B1CE.7080409@comodo.com> Date: Tue, 05 Aug 2014 11:28:30 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Eran Messeri , "trans@ietf.org" References: <53D9600C.6040805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/nFOYFmXF3Bcko4jRnTdohVIJWMU Cc: Fabrice Gautier , Melinda Shore , Ben Laurie Subject: Re: [Trans] Tracking implementations X-BeenThere: trans@ietf.org 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, 05 Aug 2014 10:28:37 -0000 On 05/08/14 10:56, Eran Messeri wrote: > No, there are also monitor implementations in C++ and (partially) > python, log clients in C++, python and Java, as well as a TLS client in C++. > > There's also plenty of test data for rfc6962 implementations. > > While we're at it, there's another implementation in Chromium of SCT > deserialization and validation, using NSS (vs. OpenSSL used in the > open-source repository). Talking of SCTs and OpenSSL... The OpenSSL_1_0_2-stable branch already has code to parse and view RFC6962 SCT Lists embedded in certificates and OCSP responses. Right now I'm frantically coding extra functionality, such as SCT signature validation, in the hope of getting this into the initial 1.0.2 release. Thanks for the "OpenSSL used in the open-source repository" tip, Eran. I'll check this out right now. It may save me some time. :-) > On 4 Aug 2014 18:55, "Fabrice Gautier" > wrote: > > On Thu, Jul 31, 2014 at 6:36 AM, Ben Laurie > wrote: > > On 30 July 2014 17:13, Melinda Shore > wrote: > >> During the session last week I was a bit surprised by the number of > >> people saying that they were doing implementations, and I think it > >> might be useful to get a better handle on that. If nothing else, it > >> helps quite a bit during the publication process if it's known > >> that there are interoperable implementations and that we know a > little > >> bit about them. > >> > >> So, I'd be grateful if people who've are working on implementations > >> and who can discuss them publicly could speak up, let us know the > >> status and whether or not you'll be releasing source, and provide a > >> pointer to a repo or other documentation if you're able. Also let > >> me know whether or not you'd be willing to have your implementation > >> mentioned on a wiki page listing implementations. > > > > Obviously(?) Google has an open source implementation here: > > https://github.com/google/certificate-transparency. > > My understanding is that this is only an implementation of a CT log, > am I correct ? > > > > We also have two internal production implementations, both of which > > share as much code as is feasible with the open source. No current > > plan to release source that is not already released. > > > > Feel free to mention them on a wiki page. > > > >> > >> Thanks again, > >> > >> Melinda > >> > >> _______________________________________________ > >> Trans mailing list > >> Trans@ietf.org > >> https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > 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. From nobody Tue Aug 5 14:11:12 2014 Return-Path: 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 118BE1B2BEB for ; Tue, 5 Aug 2014 14:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 wt4R1GZHdgOQ for ; Tue, 5 Aug 2014 14:11:04 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FC01B2BE7 for ; Tue, 5 Aug 2014 14:11:04 -0700 (PDT) X-AuditID: a66201d1-f795e6d000005a37-d2-53e14867cd65 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 96.FB.23095.76841E35; Tue, 5 Aug 2014 21:11:03 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1XEm0d-0007tP-8v for trans@ietf.org; Tue, 05 Aug 2014 17:11:03 -0400 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Tue, 5 Aug 2014 14:10:46 -0700 From: Rick Andrews To: "trans@ietf.org" Date: Tue, 5 Aug 2014 14:10:45 -0700 Thread-Topic: Clarification needed Thread-Index: Ac+w8Q6BDNq+SoPyQ4Cie8Jig6hMyA== Message-ID: <544B0DD62A64C1448B2DA253C011414607CE9B9971@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607CE9B9971TUS1XCHEVSPIN_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42LhMnA9pZvu8TDYYP5XJYu1jy+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr48uEN8wF09Uqnv5dx9bAeEa+i5GTQ0LARKLry31WCFtM4sK9 9WxdjFwcQgLvGCXOnLkP5fxnlDjePJUVwlnJKPFsZTszSAubgJ7ElsdX2EFsEQFVic/3W5hA bBYBFYkNU4+BxYUFZCVm9f4AauYAqlGSmDa9BKJcT2LW1U1gY3gFoiROLHrJBmIzAl3x/dQa sDHMAuISt57MZ4K4TkBiyZ7zzBC2qMTLx/9YIepFJe60r2eEqM+XuHr0CDvETEGJkzOfsExg FJ6FZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwyqck5hrklifmlJQWp FQaGesWVuYnAuEnWS87P3cQIjJ1lSYwXdzBeOKx7iFGAg1GJh7dB52GwEGtiGVDlIUYJDmYl EV722w+ChXhTEiurUovy44tKc1KLDzFKc7AoifN+tL0ZLCSQnliSmp2aWpBaBJNl4uCUamAU 1/nKHfmsnzuAS+P/idjPP5JFBDYLK76br3x9KVf41L4zZxQWGAevuCOTv7g8NZLDMd4qne+U +JLaA5F2L8M2d4rtq+jYtvlPZfEV5UXNeR1nrz7KfnSeR46trD9vwQaT/6fildi1hO8t+K41 xVFu+c2bl4Oy33eKpv1/ry6cJ/G48Vm3rKgSS3FGoqEWc1FxIgAMxT0imQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/trans/t6H5d_RxhtLS9JaElrBdtLe8GZE Subject: [Trans] Clarification needed X-BeenThere: trans@ietf.org 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, 05 Aug 2014 21:11:11 -0000 --_000_544B0DD62A64C1448B2DA253C011414607CE9B9971TUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In thinking about how log servers should behave, I came up with two cases t= hat should probably be addressed in the -bis so that all log servers behave= the same way. 1) Let's say I've issued a cert and embedded the SCTs in the cert. Now I (o= r someone else) send the cert to log servers using the add-chain command. W= hat happens? Should the log server see if one of the SCTs is from itself, a= nd if so just return that SCT? Or should it generate a new SCT? Rob Stradling helped me understand that the SCTs in the cert would have a "= entry_type" of "precert_entry", so the log server shouldn't just return tha= t. Instead, it seems that it should create a new SCT with an "entry_type" o= f "x509_entry". But it's worth clarifying that this new SCT would contain a= hash over the entire cert, including the existing SCTs, even if one of tho= se embedded SCTs originated from that same log server. 2) Finally, is it worth clarifying that while anyone can invoke the add-cha= in command, only CAs are expected to invoke the add-pre-chain command? Shou= ld log servers return an error if the pre-cert presented in the add-pre-cha= in command does not contain the poison extension? Finally, it might be worth clarifying Section 4.2, Add PreCertChain to Log,= where the input is described as "An array of base64-encoded Precertificate= s", which seems to imply that the CA can send multiple pre-certs and chains= in a single command. The rest of the description makes it clear that the l= og server expects only one chain, the first cert in the chain is the pre-ce= rt and the following certs are the (non-pre-cert) certs in the chain. It's not clear to me if I should create issues in the tracker for these. I = thought I would get some initial feedback first. -Rick --_000_544B0DD62A64C1448B2DA253C011414607CE9B9971TUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In thinking about how log servers should behave, I came up with two ca= ses that should probably be addressed in the –bis so that all log ser= vers behave the same way.
 
1) Let’s say I’ve issued a cert and embedded the SCTs in t= he cert. Now I (or someone else) send the cert to log servers using the add= -chain command. What happens? Should the log server see if one of the SCTs = is from itself, and if so just return that SCT? Or should it generate a new SCT?
 
Rob Stradling helped me understand that the SCTs in the cert would hav= e a "entry_type" of "precert_entry", so the log server = shouldn’t just return that. Instead, it seems that it should create a= new SCT with an "entry_type" of "x509_entry". But it&#= 8217;s worth clarifying that this new SCT would contain a hash over the entire cert, inc= luding the existing SCTs, even if one of those embedded SCTs originated fro= m that same log server.
 
2) Finally, is it worth clarifying that while anyone can invoke the ad= d-chain command, only CAs are expected to invoke the add-pre-chain command?= Should log servers return an error if the pre-cert presented in the add-pr= e-chain command does not contain the poison extension?
 
Finally, it might be worth clarifying Section 4.2, Add PreCertChain to= Log, where the input is described as “An array of base64-encoded Pre= certificates”, which seems to imply that the CA can send multiple pre= -certs and chains in a single command. The rest of the description makes it clear that the log server expects only one chai= n, the first cert in the chain is the pre-cert and the following certs are = the (non-pre-cert) certs in the chain.
 
 
 
It’s not clear to me if I should create issues in the tracker fo= r these. I thought I would get some initial feedback first.
 
-Rick
 
 
 
 
 --_000_544B0DD62A64C1448B2DA253C011414607CE9B9971TUS1XCHEVSPIN_-- From nobody Tue Aug 5 14:25:29 2014 Return-Path: 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 2DA611A0332 for ; Tue, 5 Aug 2014 14:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 Lo9eEUadgXXe for ; Tue, 5 Aug 2014 14:25:26 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236611A0316 for ; Tue, 5 Aug 2014 14:25:25 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so2679263vcb.28 for ; Tue, 05 Aug 2014 14:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1nWy/9b3FVIY86nfnsJeu5mGUNplYLE8QI00FAiDy2c=; b=fwfCxmYrb+VcwTu/TyEcRoxq2bipzpze00mN/j3U4mNm14/CVIBLaAp5LttbUFaZlR ptbvvNDYZiBPUtqA9n0Xa/fH2GYKrFZmFu1IO55lnNBRKWRpw0deGTW8AttFMKIQtQrB ptKnvE95FjbQvHEVJKVOHJoQNmFzbNQtRaGeVl6VOOm6oDHGnSbFtWCCn6O/UoM+HYG9 F2zVKjQkLXhykgurIjDGPctey/wi1WHW7vGbJl4ngnRon11DbwXWEa1mrGoG0qlI/ODV Bo48DDTJDc5lIUgXiLPU9VywTBu/2CzGyOMjUbmvYT5NnoBARmCbL1CP8lr7p2BrCy2n G14A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1nWy/9b3FVIY86nfnsJeu5mGUNplYLE8QI00FAiDy2c=; b=bV4jqIFb2UEMlf+CRq3mByfgVMQ/bfpkPn00yHRDrqBLBVjDosyxQTHrDF4Dm6h8bJ 4jCq6IgWXQAnpDP0Mpj3hXFfgnF2WFY3J/3zsa0giiMmoGDBddNDo4lOSfImIR01ZFNH TBCSAt3FXq7fttIS4uiyM8Jrc43P1mTrwboYaK8qUkxZWfErPlP/o7eRXsXqjbI+dFQY T6b6abH+tY/iU/PO+scdQ7Eq9kiyQyvfFXdxYd8wcEk+MybBSVq6bAYq9wRHv3qwwDf8 VrPCy0wA/W0CyUFmJibiejBx+eyoNKc5+mYaOiF6HCxmHlmdN/0UfE7stbQ7cU4mmrjQ gXuQ== X-Gm-Message-State: ALoCoQkZxPb9duiDZWE5z+tXCrDZVDWOR78tw4udPRjBjoZ7R7orfv+4jTSqr0A/Z1ChpODB15P9 MIME-Version: 1.0 X-Received: by 10.220.200.71 with SMTP id ev7mr6956259vcb.24.1407273925132; Tue, 05 Aug 2014 14:25:25 -0700 (PDT) Received: by 10.52.24.82 with HTTP; Tue, 5 Aug 2014 14:25:25 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CE9B9971@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C011414607CE9B9971@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Tue, 5 Aug 2014 22:25:25 +0100 Message-ID: From: Eran Messeri To: Rick Andrews Content-Type: multipart/alternative; boundary=089e011845ea68f1e104ffe87e88 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/oEgLngmmaRFipfGnJN4lgeMQhQg Cc: "trans@ietf.org" Subject: Re: [Trans] Clarification needed X-BeenThere: trans@ietf.org 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, 05 Aug 2014 21:25:28 -0000 --089e011845ea68f1e104ffe87e88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 5, 2014 at 10:10 PM, Rick Andrews wrote: > In thinking about how log servers should behave, I came up with two > cases that should probably be addressed in the =E2=80=93bis so that all l= og servers > behave the same way. > > 1) Let=E2=80=99s say I=E2=80=99ve issued a cert and embedded the SCTs in = the cert. Now I > (or someone else) send the cert to log servers using the add-chain comman= d. > What happens? Should the log server see if one of the SCTs is from itself= , > and if so just return that SCT? Or should it generate a new SCT? > > Rob Stradling helped me understand that the SCTs in the cert would have a > "entry_type" of "precert_entry", so the log server shouldn=E2=80=99t just= return > that. Instead, it seems that it should create a new SCT with an > "entry_type" of "x509_entry". But it=E2=80=99s worth clarifying that this= new SCT > would contain a hash over the entire cert, including the existing SCTs, > even if one of those embedded SCTs originated from that same log server. > Good point - it's completely valid to send a certificate with embedded SCT from one log as an x509_entry certificate to other logs to obtain additional SCTs. The RFC should be explicit about this situation. > > 2) Finally, is it worth clarifying that while anyone can invoke the > add-chain command, only CAs are expected to invoke the add-pre-chain > command? Should log servers return an error if the pre-cert presented in > the add-pre-chain command does not contain the poison extension? > Yes - and the reference open-source implementation already returns an error if the poison extension is not present: https://github.com/google/certificate-transparency/blob/master/cpp/log/cert= .cc#L879 (coincidentally, the open-source implementation will also return an error if the poison extension *is* present in a certificate added by add-chain rather than add-pre-chain). > > Finally, it might be worth clarifying Section 4.2, Add PreCertChain to > Log, where the input is described as =E2=80=9CAn array of base64-encoded > Precertificates=E2=80=9D, which seems to imply that the CA can send multi= ple > pre-certs and chains in a single command. The rest of the description mak= es > it clear that the log server expects only one chain, the first cert in th= e > chain is the pre-cert and the following certs are the (non-pre-cert) cert= s > in the chain. > > Excellent observation - there's an errata for RFC6962 exactly for this wording: http://www.rfc-editor.org/errata_search.php?rfc=3D6962 > > > It=E2=80=99s not clear to me if I should create issues in the tracker for= these. I > thought I would get some initial feedback first. > I suggest you do - definitely for (1), I've created one for (3)( as the errata should be incorporated into -bis). > > -Rick > > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --089e011845ea68f1e104ffe87e88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 5, 2014 at 10:10 PM, Rick Andrews <= ;Rick_Andrew= s@symantec.com> wrote:
In thinking about how log servers should behave, I came up with two ca= ses that should probably be addressed in the =E2=80=93bis so that all log s= ervers behave the same way.
=C2=A0
1) Let=E2=80=99s say I=E2=80=99ve issued a cert and embedded the SCTs = in the cert. Now I (or someone else) send the cert to log servers using the= add-chain command. What happens? Should the log server see if one of the S= CTs is from itself, and if so just return that SCT? Or should it generate a new SCT?
=C2=A0
Rob Stradling helped me understand that the SCTs in the cert would hav= e a "entry_type" of "precert_entry", so the log server = shouldn=E2=80=99t just return that. Instead, it seems that it should create= a new SCT with an "entry_type" of "x509_entry". But it= =E2=80=99s worth clarifying that this new SCT would contain a hash over the entire cert, inc= luding the existing SCTs, even if one of those embedded SCTs originated fro= m that same log server.
Good point - it= 's completely valid to send a certificate with embedded SCT from one lo= g as an x509_entry certificate to other logs to obtain additional SCTs. The= RFC should be explicit about this situation.
=C2=A0=C2=A0
=C2=A0
2) Finally, is it worth clarifying that while anyone can invoke the ad= d-chain command, only CAs are expected to invoke the add-pre-chain command?= Should log servers return an error if the pre-cert presented in the add-pr= e-chain command does not contain the poison extension?
Yes - and the ref= erence open-source implementation already returns an error if the poison ex= tension is not present:

(coincidentally, the open-source implementation w= ill also return an error if the poison extension *is* present in a certific= ate added by add-chain rather than add-pre-chain).
=C2=A0
=C2=A0
Finally, it might be worth clarifying Section 4.2, Add PreCertChain to= Log, where the input is described as =E2=80=9CAn array of base64-encoded P= recertificates=E2=80=9D, which seems to imply that the CA can send multiple= pre-certs and chains in a single command. The rest of the description makes it clear that the log server expects only one chai= n, the first cert in the chain is the pre-cert and the following certs are = the (non-pre-cert) certs in the chain.

Excellent observation - there= 's an errata for RFC6962 exactly for this wording:
=C2=A0
=C2=A0
It=E2=80=99s not clear to me if I should create issues in the tracker = for these. I thought I would get some initial feedback first.
<= /div>
I suggest you do - definitely for (1), I've created one = for (3)( as the errata should be incorporated into -bis).
<= font color=3D"#888888">

-Rick
=C2=A0
=C2=A0
=C2=A0
=C2=A0

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans


--089e011845ea68f1e104ffe87e88-- From nobody Wed Aug 6 09:16:16 2014 Return-Path: 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 022DF1A0009 for ; Wed, 6 Aug 2014 09:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 BIl2k0yhGlD3 for ; Wed, 6 Aug 2014 09:16:09 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B93E1A000A for ; Wed, 6 Aug 2014 09:16:08 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so2356964lam.0 for ; Wed, 06 Aug 2014 09:16:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aF7nSDq9sc0ftD7bdairbTvKAwg9jTs4Age4cLRl69c=; b=XRHU0jD13F/SWFwdDyw3oubpDU1Udyv3DiBQp9KUKkc5nZQEgWE/BGbl3AHVAxdOov 7uii1g26fOusyvj+lqHZeHZnCGd6yY3+KPsdLtpnp+jwgmxiU40uyHAQewIRyGHFqO26 6/Ovqv0dt/bn1B3hNxfkJdY2Wj90tFjoXz6H7EseZUK7k8GJigQmytve2O98PUrYEXrp Aqdckw3pbG1TU/5ZsRQQ4UuBo7Qp5lgTO2GCPXenVc36le8IhDGteM2DQE0qA5z2kdT0 WH22OFFL3nuo56FA/Kl6FLHEW46cSZ2W5ivigRDlkJT7OvNBFpmZc9TT9F6GDIzG+BGF 5/0g== X-Gm-Message-State: ALoCoQk6vqZ2yLKQWsrL457c1dSNDFJxu0lvFHKxJmv/uQKtVpU/8i3DjTMzCWl5/l8i6UNH0Lqp X-Received: by 10.112.50.230 with SMTP id f6mr11360226lbo.56.1407341767094; Wed, 06 Aug 2014 09:16:07 -0700 (PDT) Received: from [10.0.0.115] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id e5sm699004laf.3.2014.08.06.09.16.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Aug 2014 09:16:06 -0700 (PDT) Message-ID: <53E254C0.5020801@mnt.se> Date: Wed, 06 Aug 2014 18:16:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: trans@ietf.org References: <53D9600C.6040805@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Khmt3hU3mak2uq8a2tWqCCqTMEA Subject: Re: [Trans] Tracking implementations X-BeenThere: trans@ietf.org 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: Wed, 06 Aug 2014 16:16:15 -0000 On 2014-08-04 19:55, Fabrice Gautier wrote: > On Thu, Jul 31, 2014 at 6:36 AM, Ben Laurie wrote: >> On 30 July 2014 17:13, Melinda Shore wrote: >>> During the session last week I was a bit surprised by the number of >>> people saying that they were doing implementations, and I think it >>> might be useful to get a better handle on that. If nothing else, it >>> helps quite a bit during the publication process if it's known >>> that there are interoperable implementations and that we know a little >>> bit about them. >>> >>> So, I'd be grateful if people who've are working on implementations >>> and who can discuss them publicly could speak up, let us know the >>> status and whether or not you'll be releasing source, and provide a >>> pointer to a repo or other documentation if you're able. Also let >>> me know whether or not you'd be willing to have your implementation >>> mentioned on a wiki page listing implementations. >> >> Obviously(?) Google has an open source implementation here: >> https://github.com/google/certificate-transparency. > > My understanding is that this is only an implementation of a CT log, > am I correct ? > This is the other one - no shared code with the google impl: https://devp.ct.nordu.net/. Linus is the lead for this one. From nobody Wed Aug 6 12:57:20 2014 Return-Path: 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 A9C461A0163 for ; Wed, 6 Aug 2014 12:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZEEBEMxulIRi for ; Wed, 6 Aug 2014 12:57:15 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC4B1A0125 for ; Wed, 6 Aug 2014 12:57:15 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so3844483pdj.15 for ; Wed, 06 Aug 2014 12:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=UwIr30Mb73Mh3dF67WM86x8M5vDBC3+X/rc0AqtVOxA=; b=RzbXOaMBUvhj5gMnFy+psHpeoVb4zrOjD9cB3JW/SeNtNlWVMnc2EpPzWEgkmGy2gm xtGEQPS7Oh5+yjkrHXM8ss1sSET7l+3Xmgdwi8QrN0fwyhoDiBsJCodtpuHewvNU6dtI sL4PgLjApqG4BC4OsTOuU6P5yYz9DEUa9GExMMMi8yxIWf4/jrX7GzcQdJL+0ywO48VC jINbLlU298OkldkxD59yTMwzMq2bPBNOqpi+OBwHFORRUHQAfXWaySRqaXdlS5841Kzs e35zY9ZfkYocotafUZMoXX/C8svExTVPpzEDC+qDkk01N6X9X/FPtApvCHqxAl2Rf3YC 58ZQ== X-Received: by 10.70.108.164 with SMTP id hl4mr13354315pdb.70.1407355035349; Wed, 06 Aug 2014 12:57:15 -0700 (PDT) Received: from spandex.local (216-67-10-15-rb2.sol.dsl.dynamic.acsalaska.net. [216.67.10.15]) by mx.google.com with ESMTPSA id v1sm2147830pbs.1.2014.08.06.12.57.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 12:57:14 -0700 (PDT) Message-ID: <53E28898.5070604@gmail.com> Date: Wed, 06 Aug 2014 11:57:12 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/1Nlgq1Mlp1DtMrZKNrUQSpWhha4 Subject: [Trans] Minutes uploaded X-BeenThere: trans@ietf.org 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: Wed, 06 Aug 2014 19:57:17 -0000 I've uploaded an initial draft of meeting minutes from IETF 90 to: http://www.ietf.org/proceedings/90/minutes/minutes-90-trans Many thanks to Karen O'Donoghue for taking excellent meeting minutes. Melinda From nobody Tue Aug 12 18:18:19 2014 Return-Path: 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 07EAA1A6F7F for ; Tue, 12 Aug 2014 18:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 JGvApBElGZdr for ; Tue, 12 Aug 2014 18:18:14 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4D61A6F7E for ; Tue, 12 Aug 2014 18:18:14 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so9437675qap.37 for ; Tue, 12 Aug 2014 18:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DusnDju+G2Xbm9eccbMVmKG9GpRyHz554dMIFNpwh+M=; b=HJh0Bw97byy2C9hI7IBF88iOzx6i7hw7V5Zpgs5M+16MLFgn0u/TEz7D9MYjW99TwF AJDYVhPodIpuJtWTSdDoVCuDCWkAtqJCoeMJMK5ArrXYEz+D4dS59CnQuDKtt8HbPsVK ZtdbllzXbKBQ569PrOT2j9LjuNVCa6pr6ZrsCUx41yKvny/tIvhqS7Y4X/ptk4qZXonP RPOrRnBqcxy5FxWhD3Cfx/nGT8g4Qe69RBmV13a7uxqBzb1zdeAOuhV969tKKUUH7CuO VWdqign8OC8f/+5I7j4fk/4LFJYNHf2PghBawZRL1I7An9YXxdi730TmuhA1H/NAWoIY VYHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=DusnDju+G2Xbm9eccbMVmKG9GpRyHz554dMIFNpwh+M=; b=Vqf2t1GuqGk+zJ+ft6ONLzzXS+JS8h2OzrZM+u3AwmVAgvD94GxN42kxppYzThx3w1 1AzTNj+7Dl0xfRAeu0GZatB3hvSaCXD6a+sTNJv60SQMKz75Ij7F+RtLvzgFJirKSi91 18px5B1lPFKhRTzhROXaBxtFZauAfZFXiKCzz3/bso0hJgvHYOtet2hV8n7u8G7pewiH Occvlfs2wsQrENviPinZfNgG2KHk2g2ivDl3rk4K9ie61dFkORjBlHT6DAN37ND3K11e foauZtEL7qx+QTecgqCj5SRruVX7eGbbVCbukfEE4KHZHPQ1Sw5e0EMtmjSthcle0dY9 IT8w== X-Gm-Message-State: ALoCoQna2kwfY2uqPQXXYjSifsN1YqgQAcs8yn5twkzlgEN5gQVg/FLRCiEqzzfmLkSeyFxeW8jq MIME-Version: 1.0 X-Received: by 10.140.93.44 with SMTP id c41mr1796075qge.106.1407892693606; Tue, 12 Aug 2014 18:18:13 -0700 (PDT) Received: by 10.229.40.68 with HTTP; Tue, 12 Aug 2014 18:18:13 -0700 (PDT) Date: Tue, 12 Aug 2014 18:18:13 -0700 Message-ID: From: Ben Laurie To: "trans@ietf.org" , "certificate-transparency@googlegroups.com" , CABFPub Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/buo85QMmljblVroHFXxMGkV4Yfw Subject: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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: Wed, 13 Aug 2014 01:18:16 -0000 Some people may be interested in a discussion I have just initiated on the Chromium ct-policy mailing list on name redaction and EV certificates: https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s Since this is a relatively new and low-volume list, I thought it best to point it out... From nobody Mon Aug 18 12:55:35 2014 Return-Path: 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 0D89D1A6F22 for ; Mon, 18 Aug 2014 12:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 6SxGjyWP8byn for ; Mon, 18 Aug 2014 12:55:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601D21A6F21 for ; Mon, 18 Aug 2014 12:55:32 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55896 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJT1s-0006EE-G8; Mon, 18 Aug 2014 15:55:44 -0400 Message-ID: <53F25A33.5020405@bbn.com> Date: Mon, 18 Aug 2014 15:55:31 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/APrgubrPupI2su85i3mc_KSaWFg Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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: Mon, 18 Aug 2014 19:55:34 -0000 Ben, Thanks for the analysis you performed to start the discussion on https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s. However, I believe that this discussion should move to the TRANS list, since it addresses a topic that is squarely within the scope of the CT standard, right? Do you disagree? Steve From nobody Mon Aug 18 13:07:20 2014 Return-Path: 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 9C33A1A6F32 for ; Mon, 18 Aug 2014 13:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 0ORoO7lT6zGC for ; Mon, 18 Aug 2014 13:07:17 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC36A1A6F2A for ; Mon, 18 Aug 2014 13:07:16 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id i8so5418344qcq.3 for ; Mon, 18 Aug 2014 13:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4SAJuscroNnUNZNHa/RUs6gGjy7UDbzhyJHihscPXl8=; b=PMFaj+ePRgHnUL5ENK7zYF/2XYwLLKtYK6ipc6A4qLx9PTyK6jXXDFejRVbK8FfMe0 HxALCMA7khBwegeEpd3iniysT8cjaFx8hL5vrEFgeE5YqrLZM/1692gtsNv4XX4VOMbG k4q8BfZ23DcFqRzsqlFFZei3KILKb41BwBbYlAYhrlK7qBDTlrz8OZRUb8IAdgBExHf8 8NXy9cu/BmX443rZRC8Nyj3U4fR3cBnTh+SQg4J74VMJRbg/yqOc7RekkL8yNDCDEL1C A0aBBdAlQfAdl6mqLRiYbCpfw9wfef4h4EGIRle90dWEgf6AuNpBiAk0FhR9CqiYgPPL NOJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4SAJuscroNnUNZNHa/RUs6gGjy7UDbzhyJHihscPXl8=; b=fAZy16MkaucZ/YGRypoOLRyDGKPIfPO5zwCUPPmtgsZkgtOVv3E0VvIouM4dsmIEgB bqoXa8iuG7LMSMofGk4J0rj5I7qW4IXzHFI/wOHe+kNf43zDT105R8mpSbQJl4IApUpj 9QFdARIWm3Ult4/+0e7uj1+SKlu3rK8ruZuRR3g/SK+Tp61n76/A9kV1oEJ0ePNj2fm9 sUYxVAD0NKiqOphq2kFNa62t03I3G8ocNpXOJtkXIfSwC/+dJygLu03SquoWZC5M8Bv/ j0sAQlQCFRBSfkj3rDIrlwOnrINhlfWAP1l3HU0vASXdpXN7ZwTVDBxc8CGDFfPBj+wU pnMQ== X-Gm-Message-State: ALoCoQkbx9GYbDPriD+K+MQIQsZZ7tf6mB2wKQZlXsORfLKLpcdtrvp2+72DreX+7MKQ5/A8LMAH MIME-Version: 1.0 X-Received: by 10.224.160.83 with SMTP id m19mr58269364qax.95.1408392435841; Mon, 18 Aug 2014 13:07:15 -0700 (PDT) Received: by 10.229.40.68 with HTTP; Mon, 18 Aug 2014 13:07:15 -0700 (PDT) In-Reply-To: <53F25A33.5020405@bbn.com> References: <53F25A33.5020405@bbn.com> Date: Mon, 18 Aug 2014 13:07:15 -0700 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5OrBZ3wk31np84YHc7-MTtVo10w Cc: "trans@ietf.org" Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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: Mon, 18 Aug 2014 20:07:19 -0000 On 18 August 2014 12:55, Stephen Kent wrote: > Ben, > > Thanks for the analysis you performed to start the discussion on > https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s. > > However, I believe that this discussion should move to the > TRANS list, since it addresses a topic that is squarely within > the scope of the CT standard, right? > > Do you disagree? I am not against there being a discussion in TRANS, but I think there are two interlinked issues: 1. What signals CT provides for what kinds of certs. 2. What Chrome does in response to those signals. Each has its own appropriate venue. I am also mildly confused about how an RFC interacts with standards that are not controlled by the IETF (i.e. the Base Requirements and the Extended Validation requirements). From nobody Mon Aug 18 13:46:11 2014 Return-Path: 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 364D91A6F7A for ; Mon, 18 Aug 2014 13:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 m8G1SLSD5GVe for ; Mon, 18 Aug 2014 13:46:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E091A6F76 for ; Mon, 18 Aug 2014 13:46:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:54303 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJToq-0006er-Tw; Mon, 18 Aug 2014 16:46:21 -0400 Message-ID: <53F26610.8000608@bbn.com> Date: Mon, 18 Aug 2014 16:46:08 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Laurie References: <53F25A33.5020405@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5U6oRJncLKE886-E7SsR8uNtHN0 Cc: "trans@ietf.org" Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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: Mon, 18 Aug 2014 20:46:10 -0000 Ben, > On 18 August 2014 12:55, Stephen Kent wrote: >> Ben, >> >> Thanks for the analysis you performed to start the discussion on >> https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s. >> >> However, I believe that this discussion should move to the >> TRANS list, since it addresses a topic that is squarely within >> the scope of the CT standard, right? >> >> Do you disagree? > I am not against there being a discussion in TRANS, but I think there > are two interlinked issues: > > 1. What signals CT provides for what kinds of certs. > > 2. What Chrome does in response to those signals. > > Each has its own appropriate venue. I agree that these are separate topics. But the overall question of whether the proposal for redacted certs, as part of 6962-bis, is "safe" for both DV and EV certs, is appropriate for this list. (It's the subject of an issue tracker entry that I submitted.) The topic of how a CT-compliant TLS client deals with a redacted cert, of any type, is within scope for TRANS. What Chrome does is not a subject for TRANS, since you have already stated that Chrome will do whatever Google decides, irrespective of any TRANS RFCs :-). > I am also mildly confused about how an RFC interacts with standards > that are not controlled by the IETF (i.e. the Base Requirements and > the Extended Validation requirements). Well, RFC 6125 is an example of a standards track RFC that talks about EV certs in the TLS context, so there is a precedent. Steve From nobody Tue Aug 19 11:06:47 2014 Return-Path: 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 BABDA1A06A5 for ; Tue, 19 Aug 2014 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 SYiCy32Xdi8b for ; Tue, 19 Aug 2014 11:06:43 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A461A06A1 for ; Tue, 19 Aug 2014 11:06:36 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so2746370qgd.33 for ; Tue, 19 Aug 2014 11:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nzaf/uesCcZ0A1t4TU7AGKr1VP8QFwgcBnSVzJV5D90=; b=OEk7+JTym0w918uJorWoALTST6OSLU3uddtXHes5+hsLjQ2lvce/r8VgyvKrJT/IHi OPYjDh+hsru3qHV8zW89+gNsvo79BAwmMuyWsh2gYmZ1vdshfxETUbDdIBuRENvI2A0j WvoDHR1WEk1b1eHlINPehXNjzwZICqjHnfwkrVTYKyEU94Sr+hgTQSxVBWIH5bIQG7Di FYW020mLcQKUSLRJMHYczMPnCr89HVsq76CMmJeTjPZM/JwU7wde7P/Lg22rPMrNy4fZ 4zxBvpJEq7jNMbpFpcq/8jFS+DsbT7+ZOlizovtJSzH8waGd6HvQnR/UVKdkgubhcCqT r6hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Nzaf/uesCcZ0A1t4TU7AGKr1VP8QFwgcBnSVzJV5D90=; b=HW/T+kewTkwpeg9vE0DV1Kv/llgFg/C6ZL+wcIffLe0pCZ4OZD9UhQ2Wi3Vio8rW1q 3oak7LR+QChzcu6I0osCVYV5puqTSpO5HvDcpuvKdmWlIPASAl2EovCg2HTbTqKu/GIK DggwwYDVLTDygawa4lJxMAXb3aqQ2ylEno2fUZwQfbn+NAtEicmol/L6LnWzFEjQKd/9 LuMPv6N5rl6onmamHAu/d6uVQJ/k5S6aoGjttjPmKiSyWdvQez73CsgA1o+5C7NvFLQd o1tAvelfF6OH7U5xjO4GcnL9u+WjnBMk5wiAUwO7vS9lhPu1cLadrzrhfvKSdeYXhK8j AXgg== X-Gm-Message-State: ALoCoQm+IwUzycw5a9Q3sTyVGzN91viptqUzZmNyUVMb2oSoYwUixxZlM2iUa50sGpehqeScX3tm MIME-Version: 1.0 X-Received: by 10.140.91.229 with SMTP id z92mr6004163qgd.8.1408471591915; Tue, 19 Aug 2014 11:06:31 -0700 (PDT) Received: by 10.229.40.68 with HTTP; Tue, 19 Aug 2014 11:06:31 -0700 (PDT) In-Reply-To: <53F26610.8000608@bbn.com> References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> Date: Tue, 19 Aug 2014 11:06:31 -0700 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/q242qUr-bEPZJY5DUOgEX3xPoQY Cc: "trans@ietf.org" Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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, 19 Aug 2014 18:06:44 -0000 On 18 August 2014 13:46, Stephen Kent wrote: > Ben, > > >> On 18 August 2014 12:55, Stephen Kent wrote: >>> >>> Ben, >>> >>> Thanks for the analysis you performed to start the discussion on >>> >>> https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s. >>> >>> However, I believe that this discussion should move to the >>> TRANS list, since it addresses a topic that is squarely within >>> the scope of the CT standard, right? >>> >>> Do you disagree? >> >> I am not against there being a discussion in TRANS, but I think there >> are two interlinked issues: >> >> 1. What signals CT provides for what kinds of certs. >> >> 2. What Chrome does in response to those signals. >> >> Each has its own appropriate venue. > > I agree that these are separate topics. But the overall question of whether > the proposal for redacted certs, as part of 6962-bis, is "safe" for both > DV and EV certs, is appropriate for this list. (It's the subject of an > issue tracker entry that I submitted.) Sure, that makes sense to me. > The topic of how a CT-compliant TLS client deals with a redacted cert, of > any type, > is within scope for TRANS. > > What Chrome does is not a subject for TRANS, since you have already stated > that Chrome will do whatever Google decides, irrespective of any TRANS RFCs > :-). Google is obviously not unique in this regard - it's true of all software, right? >> I am also mildly confused about how an RFC interacts with standards >> that are not controlled by the IETF (i.e. the Base Requirements and >> the Extended Validation requirements). > > > Well, RFC 6125 is an example of a standards track RFC that talks about EV > certs in the TLS context, so there is a precedent. As far as I can see only to say its out of scope. > > Steve From nobody Tue Aug 19 11:36:42 2014 Return-Path: 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 99AB11A06AC for ; Tue, 19 Aug 2014 11:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 BS7Y6kPjPZLA for ; Tue, 19 Aug 2014 11:36:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3A51A06B5 for ; Tue, 19 Aug 2014 11:36:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52581 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJoGp-000Jb3-I3; Tue, 19 Aug 2014 14:36:35 -0400 Message-ID: <53F39933.8030706@bbn.com> Date: Tue, 19 Aug 2014 14:36:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Laurie References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Qdy8r0VWgM--6LnAzSN_1l0plTE Cc: "trans@ietf.org" Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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, 19 Aug 2014 18:36:40 -0000 Ben, > ... >> The topic of how a CT-compliant TLS client deals with a redacted cert, of >> any type, >> is within scope for TRANS. >> >> What Chrome does is not a subject for TRANS, since you have already stated >> that Chrome will do whatever Google decides, irrespective of any TRANS RFCs >> :-). > Google is obviously not unique in this regard - it's true of all > software, right? It's rather unusual for an author of an RFC to publicly state that he plans to ignore the RFC if it doesn't match his implementation plans. > >>> I am also mildly confused about how an RFC interacts with standards >>> that are not controlled by the IETF (i.e. the Base Requirements and >>> the Extended Validation requirements). >> >> Well, RFC 6125 is an example of a standards track RFC that talks about EV >> certs in the TLS context, so there is a precedent. > As far as I can see only to say its out of scope. Only the first mention of EV certs appears in the section "labelled "out of scope." The reference to EV certs in Section 2.3.1 says that the RFC prefers use of the Subject Alt Name over the Common name for representing certain classes of IDs, but acknowledges that use of the CN-ID construct is OK for backward compatibility with "deployed infrastructure", citing EV certs. In Section 7.2, there is another reference to EV certs, in the context of wildcard use. In that instance the RFC suggests that the guidelines published in 2009 allowed wildcards, whereas the RFC argued against their use except in one specific location. So, I see the RFC as an example of how an IETF standard can choose to accommodate, or reject, guidelines from outside the IETF. There are other RFCs that deal with this topic very directly, e.g., in the MPLS space. The bottom line is that the IETF can choose to view non-IETF standards as off limits, or can reinforce support for them, or reject them in the IETF context. I'm pretty sure we can find examples of all of these ways of dealing with other standards in the RFC collection. I suspect Russ Housely is especially well suited to cite examples based on his experience as IETF Chair. Steve From nobody Tue Aug 19 11:59:19 2014 Return-Path: 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 93E501A0706 for ; Tue, 19 Aug 2014 11:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 D1UrTZiiaTqo for ; Tue, 19 Aug 2014 11:59:11 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00421A06FB for ; Tue, 19 Aug 2014 11:59:10 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so6696400qcv.37 for ; Tue, 19 Aug 2014 11:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=symkfPBo8gxg7EFCsuduJnTpkk6lPQdg9PdL3JCJ3Vs=; b=llZxQXRDRBdUssYnxUySKqgbH1ab9tlMLiuzIPpeoxocCRxS8fSr5gwnSfx8HFH/EG 1ksFMfVjBxKYE7eieSMNd5NP8tjGP3PKBXG+BJLrn6n0J4NdRePv6SHA6PCrJdS+9TVU fsMjQg1Vl6IUn1TRTdQpW64egen0ZDX7+rZAKi5Euwisnos6nRjvQBPtGBuU84n5JQnD rehfCZHAmvfuKZn+JgSPCc31rU8onrpINLuGSvNCT0wd2ZOR0cJ+FcfhxClR+3JqH5NR o5imknoW+8c18iDzYkmpJWhcZ2lt2K7ybvoqRhBecwFU68txeBm4KaDEaYJN1mYWPBPV p+lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=symkfPBo8gxg7EFCsuduJnTpkk6lPQdg9PdL3JCJ3Vs=; b=AkBn2v2qodmDZw5DQa6wSjO+P/Km1+y2YlXhVt4TfwacAkyhjd0668AztWsNjdMr/R s+oQVvXPL5dN4uceHxMCHu5w3YH+ZglY8AWB12q/F1Zx/Z9mU+zbDzul0c0LCGD9PhCp rwkJiGytHvPqm8+8uha3H8+dT/OgNWLS4lPmj4d5OUVwotc5Ur9b6FyvgqRXFdzqf3/J nkkU6id/3FRu/P5dV7LWTFqIH8NT4MFsbHYgVUCn8MXKBJVPZ6056f2rg0eUwN1Qe/cz QcK2rfjABmuw7yniDhzYT95qnkef8kdG3l5j9osrRYem8Rd2WWN+GiUhSWe1apaSj0fG zDDQ== X-Gm-Message-State: ALoCoQnfCDGQQ9tdOvorCW82jnLrFP55x1vnq4fFO0V1CN1oYmrYFyPrVUUPgZyAKYfqFr6LQi06 MIME-Version: 1.0 X-Received: by 10.140.91.229 with SMTP id z92mr6479617qgd.8.1408474749807; Tue, 19 Aug 2014 11:59:09 -0700 (PDT) Received: by 10.229.40.68 with HTTP; Tue, 19 Aug 2014 11:59:09 -0700 (PDT) In-Reply-To: <53F39933.8030706@bbn.com> References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> <53F39933.8030706@bbn.com> Date: Tue, 19 Aug 2014 11:59:09 -0700 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/e3UUGlOOUWYZABUW9tGFulAYyTY Cc: "trans@ietf.org" Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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, 19 Aug 2014 18:59:17 -0000 On 19 August 2014 11:36, Stephen Kent wrote: > Ben, > >> ... >> >>> The topic of how a CT-compliant TLS client deals with a redacted cert, of >>> any type, >>> is within scope for TRANS. >>> >>> What Chrome does is not a subject for TRANS, since you have already >>> stated >>> that Chrome will do whatever Google decides, irrespective of any TRANS >>> RFCs >>> :-). >> >> Google is obviously not unique in this regard - it's true of all >> software, right? > > It's rather unusual for an author of an RFC to publicly state that he plans > to ignore the RFC if it doesn't match his implementation plans. As you are fond of pointing out, I am not the author, I am one of the editors. I am perhaps overly honest in stating up front that I will not unconditionally follow the consensus decisions of the WG, but surely this is far from being a unique stance. >>>> I am also mildly confused about how an RFC interacts with standards >>>> that are not controlled by the IETF (i.e. the Base Requirements and >>>> the Extended Validation requirements). >>> >>> >>> Well, RFC 6125 is an example of a standards track RFC that talks about EV >>> certs in the TLS context, so there is a precedent. >> >> As far as I can see only to say its out of scope. > > > Only the first mention of EV certs appears in the section "labelled "out of > scope." > The reference to EV certs in Section 2.3.1 says that the RFC prefers use of > the > Subject Alt Name over the Common name for representing certain classes of > IDs, but > acknowledges that use of the CN-ID construct is OK for backward > compatibility with > "deployed infrastructure", citing EV certs. In Section 7.2, there is > another reference > to EV certs, in the context of wildcard use. In that instance the RFC > suggests that > the guidelines published in 2009 allowed wildcards, whereas the RFC argued > against their > use except in one specific location. It would be interesting to know if this is why EV now disallows wildcards. > So, I see the RFC as an example of how an IETF standard can choose to > accommodate, or > reject, guidelines from outside the IETF. There are other RFCs that deal > with this topic > very directly, e.g., in the MPLS space. The bottom line is that the IETF can > choose to > view non-IETF standards as off limits, or can reinforce support for them, or > reject them > in the IETF context. I'm pretty sure we can find examples of all of these > ways of dealing > with other standards in the RFC collection. I suspect Russ Housely is > especially well suited > to cite examples based on his experience as IETF Chair. OK. From nobody Tue Aug 19 13:42:52 2014 Return-Path: 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 6EA111A06E8 for ; Tue, 19 Aug 2014 13:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 LPWE43iCIaMR for ; Tue, 19 Aug 2014 13:42:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9461A6EFA for ; Tue, 19 Aug 2014 13:42:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43875 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJqEv-000MB1-Ah for trans@ietf.org; Tue, 19 Aug 2014 16:42:45 -0400 Message-ID: <53F3B6C4.2000108@bbn.com> Date: Tue, 19 Aug 2014 16:42:44 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> <53F39933.8030706@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EcUvOUou42PUkMyBAxoc0nKlWAY Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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, 19 Aug 2014 20:42:49 -0000 Ben, > ... >> It's rather unusual for an author of an RFC to publicly state that he plans >> to ignore the RFC if it doesn't match his implementation plans. > As you are fond of pointing out, I am not the author, I am one of the > editors. I am perhaps overly honest in stating up front that I will > not unconditionally follow the consensus decisions of the WG, but > surely this is far from being a unique stance. I don't recall making that observation about your role in generating this doc. Can you point to a message from me that made that statement, i.e., that you are an editor, not a doc author? I just don't recall. I agree that it is common to speak of doc editors, especially when the content is derived from many sources, e.g., WG list discussions. In this case, the source for the initial doc material was very narrow, and I believe Eran said that you are the one responsible for making edits to address issues. So, forgive my choice of words to describe your role. As for a public statement wrt ignoring WG consensus (in an implementation) by a doc "editor" it strikes me as very unusual, if not unique, based on my 28 years of IETF participation. Steve From nobody Tue Aug 19 14:02:47 2014 Return-Path: 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 7216B1A04C5 for ; Tue, 19 Aug 2014 14:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 90O7rrAdLsc7 for ; Tue, 19 Aug 2014 14:02:44 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59981A013B for ; Tue, 19 Aug 2014 14:02:44 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id l6so6849116qcy.33 for ; Tue, 19 Aug 2014 14:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4dYvLph/xHoDtT0ngZP6JL5xm2hOffratyMFI5/uuFk=; b=K+213TU83jjBrYZm+MFeBvoA4L0qbQL9Ml49PuZwlX0TEdu4Thq9stzwGhX1efC5oo z36W8z6KRc6V5f/iB8n2IJDHMP/2Qm0tNb1UVKP0RX2Wv6mgmsNZM3MR4ey9DnI4cZFI gtQRSpqb6YW0d9Um6aaydLFn4J8mK6CK57sBXwY0VWJ14rqeT8tECVjk2R5Y6/gicNKC bs9s1j7q53UfvG4k+dg272EuA456bi2XqPGS2lhUyjk9QArQ3zYLRKQiDCn4sqQfT5RE P6ljzRpxq5PEZKF8SZSKVYMpltNdlOE+n2MtIwuwVjswSRwaYl1GVJ++AHbNfkHKyFfa paEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4dYvLph/xHoDtT0ngZP6JL5xm2hOffratyMFI5/uuFk=; b=LLrvQjZTFDxuMNfOM6DRLAeuYoHQ/B7OwX28tFVVpPYHzFW2Iz6vsRUBo3cGiGi9vY fboSAdP+16HL7QXzmYdnoU8CX4aoKY7XzfYJKGCHixMzvAeW5KA37CFrE2A+QMX7Zqef ZW0TFNe2iT1n206DhRzj3Ho5ABi5E+Jl+IPN+S4UpaN3Z496keXmV8kxkTH3iaC3rgHY 4kQ3MVxFowS2AwLJBrOFgPAIA6qTBlg+zh1pUX1L2Sn/fpL5WHW/8q6WVvL2G/orfgmL vcoIdHbkmCEdoRx11zzQsmuNkwlMfzWFDcnUOldL09cj8tD4Mwd5KkbcKU5AVbZ/fjva uIug== X-Gm-Message-State: ALoCoQnMew59lVmELAhLfIU51hfraGQN9lOPzS1RBN5w6lt1mxCtV2So7/VZUpboWUYMSxovVsOO MIME-Version: 1.0 X-Received: by 10.224.51.197 with SMTP id e5mr18985817qag.48.1408482162261; Tue, 19 Aug 2014 14:02:42 -0700 (PDT) Received: by 10.229.40.68 with HTTP; Tue, 19 Aug 2014 14:02:42 -0700 (PDT) In-Reply-To: <53F3B6C4.2000108@bbn.com> References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> <53F39933.8030706@bbn.com> <53F3B6C4.2000108@bbn.com> Date: Tue, 19 Aug 2014 14:02:42 -0700 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/59LeKHLR6zB-a6i0Uj5u7m5WDmk Cc: "trans@ietf.org" Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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, 19 Aug 2014 21:02:46 -0000 On 19 August 2014 13:42, Stephen Kent wrote: > Ben, > >> ... >> >>> It's rather unusual for an author of an RFC to publicly state that he >>> plans >>> to ignore the RFC if it doesn't match his implementation plans. >> >> As you are fond of pointing out, I am not the author, I am one of the >> editors. I am perhaps overly honest in stating up front that I will >> not unconditionally follow the consensus decisions of the WG, but >> surely this is far from being a unique stance. > > I don't recall making that observation about your role in generating > this doc. Can you point to a message from me that made that statement, > i.e., that you are an editor, not a doc author? I just don't recall. I thought that was the gist of several of your comments wrt to consensus in the last WG meeting, but I could be misrepresenting you. If so, my apologies. > I agree that it is common to speak of doc editors, especially when the > content is derived from many sources, e.g., WG list discussions. In this > case, > the source for the initial doc material was very narrow, and I believe > Eran said that you are the one responsible for making edits to address > issues. > So, forgive my choice of words to describe your role. > > As for a public statement wrt ignoring WG consensus (in an implementation) > by a doc "editor" it strikes me as very unusual, if not unique, based on > my 28 years of IETF participation. But that's not what I'm saying - what I'm saying is I can't say in advance that this standard is one I want to implement, given that I don't know what it says yet. I think it would be pretty crazy to say otherwise. I am not saying this is a _likely_ outcome, just that its a possible one. It doesn't seem like a point worth dwelling on. From nobody Tue Aug 19 14:47:49 2014 Return-Path: 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 BA10A1A6F28 for ; Tue, 19 Aug 2014 14:47:46 -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 K16WhJrGAm90 for ; Tue, 19 Aug 2014 14:47:44 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78091A0AD2 for ; Tue, 19 Aug 2014 14:47:43 -0700 (PDT) Received: (qmail 19513 invoked by uid 1000); 19 Aug 2014 21:47:41 -0000 Received: from and0004.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; Tue, 19 Aug 2014 22:47:41 +0100 Message-ID: <53F3C5FD.5000709@comodo.com> Date: Tue, 19 Aug 2014 22:47:41 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ben Laurie , Stephen Kent References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> <53F39933.8030706@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/9TLLQJT-vbsjgXZBav8y6-QySV0 Cc: "trans@ietf.org" Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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, 19 Aug 2014 21:47:46 -0000 On 19/08/14 19:59, Ben Laurie wrote: > On 19 August 2014 11:36, Stephen Kent wrote: >> In Section 7.2, there is another reference to EV certs, in the context of >> wildcard use. In that instance the RFC suggests that the guidelines >> published in 2009 allowed wildcards, whereas the RFC argued against their >> use except in one specific location. I agree that the last sentence of RFC6125 section 7.2 does seem to imply that EV Guidelines v1.2 permits wildcards. This implication is incorrect. > It would be interesting to know if this is why EV now disallows wildcards. It isn't. The EV Guidelines have never permitted wildcards. CABForum made that decision that all by itself. EV Guidelines v1.0, published 2007, says "Wildcard certificates are not allowed for EV certificates". v1.2, cited by RFC6125, says the same thing. The current version, v1.4.5, says it twice! EV Guidelines v1.0 predated the CERTID non-WG (which produced RFC6125) by several years. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Aug 19 21:46:29 2014 Return-Path: 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 44ABD1A8710 for ; Tue, 19 Aug 2014 21:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2C6JcQS5OYvQ for ; Tue, 19 Aug 2014 21:46:24 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173571A870F for ; Tue, 19 Aug 2014 21:46:24 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so11143525pdj.21 for ; Tue, 19 Aug 2014 21:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VwdYkSPyAW+4PU94QCzqZExerrl0pkdEVvWkpZbE4t4=; b=AndAbiFS/hi1TWHIDoabKNc+BdH6IZ/VnTTViHPlkLNJRzuCM/Lpj9sOZWLn8JY8oA RZRoK7m5mmQ3CwTi1sH1EC2HSkq/AZT52cOiqopIzttoeetcXbcGWJSdN6vpw0jZqPya sMUZqryUYNzOwMAAvnmzLhCIXT3DwmQ+92AotDDmn08o3eBmifeQ7s311OrkZD3ZhHAk uw8Z5jzN8iQcBbvUBvggZmGrBoopwElkrdHeCOB5jnFzcOb1CJ5o8+nUvmQWsOuemQ0b 9nEi6FCPK2fQPxeMYkPYo0Z83N/zR2a7h+oqwqSKxYunf+TcD3odEXrU3m/3PfLaTY2t vbDg== X-Received: by 10.70.96.193 with SMTP id du1mr45445203pdb.132.1408509981638; Tue, 19 Aug 2014 21:46:21 -0700 (PDT) Received: from spandex.local (63-140-77-66-rb3.nwc.dsl.dynamic.acsalaska.net. [63.140.77.66]) by mx.google.com with ESMTPSA id k3sm19291715pdb.18.2014.08.19.21.46.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 21:46:21 -0700 (PDT) Message-ID: <53F4281A.2010801@gmail.com> Date: Tue, 19 Aug 2014 20:46:18 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: trans@ietf.org References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> <53F39933.8030706@bbn.com> <53F3B6C4.2000108@bbn.com> In-Reply-To: <53F3B6C4.2000108@bbn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/teEB6dkxfS7xwsj0IZVRU3LfegI Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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: Wed, 20 Aug 2014 04:46:25 -0000 On 8/19/14 12:42 PM, Stephen Kent wrote: > As for a public statement wrt ignoring WG consensus (in an implementation) > by a doc "editor" it strikes me as very unusual, if not unique, based on > my 28 years of IETF participation. This has not been an issue yet, and to be honest I do not anticipate that it will become one. We will deal with should it come up, but I'd rather go forward with a minimum of antagonism and with a continued focus on moving the document along. Melinda From nobody Wed Aug 20 07:58:18 2014 Return-Path: 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 5895A1A0456 for ; Wed, 20 Aug 2014 07:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 l0Fuleuj9oiz for ; Wed, 20 Aug 2014 07:58:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2F51A040D for ; Wed, 20 Aug 2014 07:58:13 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49639) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XK7L2-0008Eu-E5 for trans@ietf.org; Wed, 20 Aug 2014 10:58:12 -0400 Message-ID: <53F4B785.3070202@bbn.com> Date: Wed, 20 Aug 2014 10:58:13 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: "trans@ietf.org" References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> <53F39933.8030706@bbn.com> <53F3B6C4.2000108@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/LFYuZMo673lwv6KhfO3CC7nDHqc Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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: Wed, 20 Aug 2014 14:58:16 -0000 Ben, > ... >> I agree that it is common to speak of doc editors, especially when the >> content is derived from many sources, e.g., WG list discussions. In this >> case, >> the source for the initial doc material was very narrow, and I believe >> Eran said that you are the one responsible for making edits to address >> issues. >> So, forgive my choice of words to describe your role. >> >> As for a public statement wrt ignoring WG consensus (in an implementation) >> by a doc "editor" it strikes me as very unusual, if not unique, based on >> my 28 years of IETF participation. > But that's not what I'm saying - what I'm saying is I can't say in > advance that this standard is one I want to implement, given that I > don't know what it says yet. I think it would be pretty crazy to say > otherwise. What you said above is fine. However, it is in contrast to what yo said at the TRANS meeting with regard to one of the suggested changes to the doc. > I am not saying this is a _likely_ outcome, just that its a possible one. > > It doesn't seem like a point worth dwelling on. OK, I'll stop. Steve From nobody Wed Aug 20 08:11:35 2014 Return-Path: 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 8814B1A0693 for ; Wed, 20 Aug 2014 08:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 QrrRlSgT7Eo8 for ; Wed, 20 Aug 2014 08:11:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EACB1A0503 for ; Wed, 20 Aug 2014 08:11:05 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49648) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XK7XU-0008Xv-J4 for trans@ietf.org; Wed, 20 Aug 2014 11:11:04 -0400 Message-ID: <53F4BA89.7050405@bbn.com> Date: Wed, 20 Aug 2014 11:11:05 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <53F25A33.5020405@bbn.com> <53F26610.8000608@bbn.com> <53F39933.8030706@bbn.com> <53F3C5FD.5000709@comodo.com> In-Reply-To: <53F3C5FD.5000709@comodo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rgS_aCZCti6T7_DH4utS3JlQM_U Subject: Re: [Trans] Compatibility of name redaction and EV X-BeenThere: trans@ietf.org 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: Wed, 20 Aug 2014 15:11:29 -0000 Rob, Thanks for the clarification. Perhaps you should submit an errata for 6125. Steve From nobody Wed Aug 20 15:10:07 2014 Return-Path: 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 768C11A6F01 for ; Wed, 20 Aug 2014 15:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 E1rERVyRzwkb for ; Wed, 20 Aug 2014 15:09:58 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3DB1A8902 for ; Wed, 20 Aug 2014 15:09:52 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so13186352pab.1 for ; Wed, 20 Aug 2014 15:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ufYGUlaxu1+3GFvGZsx+/yWVirX4KbjPbOJrSv8EKEY=; b=0mne89zdFWukJdacEbH49sncatinlR39aJv1y4JlXNBjGpDbEkud54VVJ8PT899jpZ LBG6deBfoO9ROuj3tabYjt/udQ8hzHHMWDsXBrHQkzl3OPZf1sPKFi3IzRDowXSTftA5 wWaAaWjTviKKVmel3WkqKoMDVFQ9amUNFJZbe1ZQgscuAiqYJSq5KHBxd3Oku8TuZyID Glt3z8+turvKKENLqfARjAmOGTWZ1rXOAl3qerrlQI8NU9PKWAxt6AuXY63Fh1WW6Xer DvigBDyym+jnfbX4E3GVAUJKOBhh9dQSJzZpPjXNfVqImMT3b9lpbsUKTYvY6vEnyNEE pcOg== X-Received: by 10.70.37.227 with SMTP id b3mr32941492pdk.147.1408572591829; Wed, 20 Aug 2014 15:09:51 -0700 (PDT) Received: from spandex.local (63-140-102-194.dynamic.dsl.acsalaska.net. [63.140.102.194]) by mx.google.com with ESMTPSA id da14sm84016699pac.24.2014.08.20.15.09.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 15:09:51 -0700 (PDT) Message-ID: <53F51CAD.9030802@gmail.com> Date: Wed, 20 Aug 2014 14:09:49 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/t40G3UnYhRXtFnQaLGZZIvdTEM0 Subject: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Wed, 20 Aug 2014 22:10:03 -0000 Hi, all: One of the issues that came up during the meeting in Toronto is how to handle the specification of a gossip protocol. Ben has a proposal included in the current draft. But, the sense of the room during the session was that this should probably be split off into a separate document, a gossip protocol specifically for CT, intended to be published as a working group product and as an experimental protocol. So, we're checking to see if there's mailing list agreement that this is how we'd like to handle specification of a gossip protocol. (At this time I'm less concerned about whether or not this would be an experimental RFC than I am about whether or not there's agreement to split this out). In terms of whether or not we'd have someone to take on producing the document, Linus Nordberg has volunteered, so we do have someone to take responsibility if there's agreement. Melinda From nobody Wed Aug 20 17:05:32 2014 Return-Path: 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 66F5B1A06C1 for ; Wed, 20 Aug 2014 17:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 TFm1sjbXWELR for ; Wed, 20 Aug 2014 17:05:26 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6491A06AB for ; Wed, 20 Aug 2014 17:05:26 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so8651176qcz.14 for ; Wed, 20 Aug 2014 17:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EYFJzQ4k4q3B/oKPHruyHxybmFkmp/4sx6mzHmmflgQ=; b=dhtP5kzTFeoHCFe6FnVLZugkAGjgL2BBw5PchrvwedwL98Kkn/9xl7B7k8LVDuyQXL awOzCqF9vC3BodClHEEWdTscfFfxobszrB5I4iMgd6LNWsm2vNUqCYxV2+H1KSZaW3WA 5DaCQczSaFyXZye6B0DzA6bH9kI1F6dSXPXV8vGBVTh9hWi+l0vhV3YZc4du8/qwfSlY ZVK/92rnZ/74aGmYbGk/jZ+wuPEcze2vuRhu8yBjrped+Wu6wK5bwZ35S5naARhaIqVg JoHWRU595DBfniaAb7SL/bUupPdzS2FyxBAgFvC5MhX50HoKOMUUCq1APlxON0qdqpbL 4UjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EYFJzQ4k4q3B/oKPHruyHxybmFkmp/4sx6mzHmmflgQ=; b=KlXZGGlYRIxgKCxgwfucvdx4Yg4radX1SlNNhYxKhlCA8htWV+M2jFrHajlcHKARlf bMyOdRGT+2L8PzmSkNhBR1unZSxG0gx1QJoASlAYzflS/8pRGY7ePFgm6ChJMc31ySr7 f1H3+74jXCDLGEzVAp4ba5X5LM2KrMNQwOuv+uvbXoHszK5EbthtMcZxP0T4fS9ZgRhJ SwIMnWWfgEH9WWaXR1TzAIQ4Y3S9CVuCyf13HUt4aAiozT0Pakye908vHvn9CjmDFgDG vpnVKpXFENUckGKJYDl9tbaHWkZVhwzay9FHxa7zKE2PscElopprLiIRT+TsrY0gl2x5 ANuQ== X-Gm-Message-State: ALoCoQl/2wG4Z3PczvhDeRGPUSLM7Jsz/5d4x5KCOg1CG3BaxMrQJgW9oNiFgSozWca/+HuSht5W MIME-Version: 1.0 X-Received: by 10.140.21.137 with SMTP id 9mr80647415qgl.37.1408579525634; Wed, 20 Aug 2014 17:05:25 -0700 (PDT) Received: by 10.229.40.68 with HTTP; Wed, 20 Aug 2014 17:05:25 -0700 (PDT) In-Reply-To: <53F51CAD.9030802@gmail.com> References: <53F51CAD.9030802@gmail.com> Date: Wed, 20 Aug 2014 17:05:25 -0700 Message-ID: From: Ben Laurie To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2kBkS7Co8bFER_2AC3_eZ4TxaDA Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Thu, 21 Aug 2014 00:05:28 -0000 On 20 August 2014 15:09, Melinda Shore wrote: > Hi, all: > > One of the issues that came up during the meeting in Toronto is how > to handle the specification of a gossip protocol. Ben has a proposal > included in the current draft. But, the sense of the room during the > session was that this should probably be split off into a separate > document, a gossip protocol specifically for CT, intended to be > published as a working group product and as an experimental protocol. > > So, we're checking to see if there's mailing list agreement that > this is how we'd like to handle specification of a gossip protocol. > (At this time I'm less concerned about whether or not this would be > an experimental RFC than I am about whether or not there's agreement > to split this out). I think it makes a certain amount of sense to split it out. > In terms of whether or not we'd have someone to take on producing > the document, Linus Nordberg has volunteered, so we do have > someone to take responsibility if there's agreement. > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Wed Aug 20 20:48:43 2014 Return-Path: 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 BF1701A7003 for ; Wed, 20 Aug 2014 20:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_SOFTFAIL=0.665] 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 KIclJuzSgOsk for ; Wed, 20 Aug 2014 20:48:39 -0700 (PDT) Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC131A7000 for ; Wed, 20 Aug 2014 20:48:39 -0700 (PDT) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 2A0FF282E0B for ; Thu, 21 Aug 2014 13:48:35 +1000 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 4C5DEA01A7; Thu, 21 Aug 2014 13:48:34 +1000 (EST) Date: Thu, 21 Aug 2014 13:48:34 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20140821034834.GE3306@hezmatt.org> References: <53F51CAD.9030802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F51CAD.9030802@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/oMmNNXKGEC8Ayl9Y4ESl9zvxbvs Subject: Re: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Thu, 21 Aug 2014 03:48:42 -0000 On Wed, Aug 20, 2014 at 02:09:49PM -0800, Melinda Shore wrote: > One of the issues that came up during the meeting in Toronto is how > to handle the specification of a gossip protocol. Ben has a proposal > included in the current draft. But, the sense of the room during the > session was that this should probably be split off into a separate > document, a gossip protocol specifically for CT, intended to be > published as a working group product and as an experimental protocol. > > So, we're checking to see if there's mailing list agreement that > this is how we'd like to handle specification of a gossip protocol. > (At this time I'm less concerned about whether or not this would be > an experimental RFC than I am about whether or not there's agreement > to split this out). I think it makes sense for the specification of the gossip protocol to be separate from the specification for the log protocol. - Matt From nobody Wed Aug 20 22:23:02 2014 Return-Path: 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 CAFED1A702B for ; Wed, 20 Aug 2014 22:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 f1dZTAJSJzBV for ; Wed, 20 Aug 2014 22:22:59 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102411A042D for ; Wed, 20 Aug 2014 22:22:58 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id q9so7323256ykb.41 for ; Wed, 20 Aug 2014 22:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OYGuRp8XvUfaIOKLilYzOMh0NWpdbn1XOb/EYLQiNhw=; b=Fsz+Uke+6rrvrVD+orE7V6yIPJa7vh0ygMS69mD07vtCtuwe+H/OJchno5o7OuQW1S xzNYM4K5er9nGKsRpX76w8M/lpPcVjBeYqjCTPJiEiEhLV84VKYzENMkjCCXqwwV85w5 XquCr0xB/ChacA0q2ey052ETdWcGkAvPnY3ooweNerFYw1IN3GV3wYLv2EUTxT5U5a5A nkHiYedobYGyejqUgSVO69379UdPimjwwpfvpzP+MIXcJhjVyYApGVhW6WNlXz5Nz5NP XMEq37aRMjtHKZ3QjUC3qQQFN5DvP9hmLVgIn6fzb61s5A8jkxQu47K02ZdxHsBRkAaD ZWmg== MIME-Version: 1.0 X-Received: by 10.236.128.176 with SMTP id f36mr51533102yhi.87.1408598578295; Wed, 20 Aug 2014 22:22:58 -0700 (PDT) Received: by 10.170.170.8 with HTTP; Wed, 20 Aug 2014 22:22:58 -0700 (PDT) In-Reply-To: <53F51CAD.9030802@gmail.com> References: <53F51CAD.9030802@gmail.com> Date: Thu, 21 Aug 2014 09:22:58 +0400 Message-ID: From: Dmitry Belyavsky To: Melinda Shore Content-Type: multipart/alternative; boundary=20cf3011df0de3fc5905011ce9c5 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hYMX08hxypt9S1AW2HYJFZWB1t8 Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Thu, 21 Aug 2014 05:23:00 -0000 --20cf3011df0de3fc5905011ce9c5 Content-Type: text/plain; charset=UTF-8 Hello Melinda, On Thu, Aug 21, 2014 at 2:09 AM, Melinda Shore wrote: > Hi, all: > > One of the issues that came up during the meeting in Toronto is how > to handle the specification of a gossip protocol. Ben has a proposal > included in the current draft. But, the sense of the room during the > session was that this should probably be split off into a separate > document, a gossip protocol specifically for CT, intended to be > published as a working group product and as an experimental protocol. > > So, we're checking to see if there's mailing list agreement that > this is how we'd like to handle specification of a gossip protocol. > (At this time I'm less concerned about whether or not this would be > an experimental RFC than I am about whether or not there's agreement > to split this out). > > In terms of whether or not we'd have someone to take on producing > the document, Linus Nordberg has volunteered, so we do have > someone to take responsibility if there's agreement. > > I think that specification of a gossip protocol should be a separate document. -- SY, Dmitry Belyavsky --20cf3011df0de3fc5905011ce9c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Melinda,=C2=A0


On Thu, Aug 21, 2014 at 2:09 AM, Melinda Shore <melinda.shore@gmail.co= m> wrote:
Hi, all:

One of the issues that came up during the meeting in Toronto is how
to handle the specification of a gossip protocol.=C2=A0 Ben has a proposal<= br> included in the current draft.=C2=A0 But, the sense of the room during the<= br> session was that this should probably be split off into a separate
document, a gossip protocol specifically for CT, intended to be
published as a working group product and as an experimental protocol.

So, we're checking to see if there's mailing list agreement that this is how we'd like to handle specification of a gossip protocol.
(At this time I'm less concerned about whether or not this would be
an experimental RFC than I am about whether or not there's agreement to split this out).

In terms of whether or not we'd have someone to take on producing
the document, Linus Nordberg has volunteered, so we do have
someone to take responsibility if there's agreement.


I think that specification of a gossip= protocol should be a separate document.=C2=A0


--
SY, Dmitry Belyavsky
--20cf3011df0de3fc5905011ce9c5-- From nobody Thu Aug 21 06:08:08 2014 Return-Path: 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 4C8941A02BB for ; Thu, 21 Aug 2014 06:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 eTQzQ7URCuEK for ; Thu, 21 Aug 2014 06:08:04 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8251A02AC for ; Thu, 21 Aug 2014 06:08:03 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7LD80Fo028909 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Aug 2014 15:08:00 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s7LD7vAc002331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2014 13:08:00 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1408626480; bh=NvDx7Mkz1R+Q4vuZ2DRw4AAbNAWMzujxcn61EwgmWeA=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=tZApzoJQ7jBCY222XGcFm/2Py5iLKz/LKgPJF3uZPl0Gstvw44jn13XCbL9i4S46a kOEOjO97EI6Mu9ba0BeSg9VUfPDowpZeeARUQaRpoH4FNE9pCxGEI+DVnWiKdWSkjj 0YIIWJZWtzrD+hmW1oYCvSbW+fbIbFBuO11v6JJI= X-Footer: bm9yZHUubmV0 Received: from flogsta.nordberg.se ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 21 Aug 2014 15:07:59 +0200 From: Linus Nordberg To: Melinda Shore Organization: NORDUnet A/S References: <53F51CAD.9030802@gmail.com> Date: Thu, 21 Aug 2014 15:08:27 +0200 In-Reply-To: <53F51CAD.9030802@gmail.com> (Melinda Shore's message of "Wed, 20 Aug 2014 14:09:49 -0800") Message-ID: <87iolmkn1w.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aMFp80Pm - 415fffa05cce - 20140821 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/UFaPOcMf8od8oE0E0QCFasiWg90 Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Thu, 21 Aug 2014 13:08:06 -0000 Melinda Shore wrote Wed, 20 Aug 2014 14:09:49 -0800: | One of the issues that came up during the meeting in Toronto is how | to handle the specification of a gossip protocol. Ben has a proposal | included in the current draft. [...] Which current draft is that? draft-ietf-trans-rfc6962-bis-04 does not describe a gossip protocol. Is there a proposed gossip protocol somewhere I haven't looked? From nobody Thu Aug 21 07:52:06 2014 Return-Path: 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 6B8C61A03AE for ; Thu, 21 Aug 2014 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 vUnttxwGkfg4 for ; Thu, 21 Aug 2014 07:52:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB8D1A0339 for ; Thu, 21 Aug 2014 07:52:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57597 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XKTia-0001xJ-AZ for trans@ietf.org; Thu, 21 Aug 2014 10:52:00 -0400 Message-ID: <53F6078F.70605@bbn.com> Date: Thu, 21 Aug 2014 10:51:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <53F51CAD.9030802@gmail.com> In-Reply-To: <53F51CAD.9030802@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2sIjVicK9I7PMselKy5WWnUZi0s Subject: Re: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Thu, 21 Aug 2014 14:52:03 -0000 Melinda, Your characterization of the discussion matches my recollection. There seemed to be a sense that a gossip protocol was going to be too new and untested to include in 6962-bis. That motivated the plan for it to appear in a separate doc, targeted for Experimental (initially). Steve From nobody Thu Aug 21 10:33:12 2014 Return-Path: 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 A88E51A04A7 for ; Thu, 21 Aug 2014 10:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 TWL0fSSWc1oO for ; Thu, 21 Aug 2014 10:33:04 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A831A048E for ; Thu, 21 Aug 2014 10:33:03 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so15122626pad.27 for ; Thu, 21 Aug 2014 10:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vmlHElUffXxnb1JCP36P0eJA6mStxKj0tVzZlBC/76c=; b=tqSkY1c1U84/fwPRJ/mOdMd0H2z0P8cWyN0nYDEU9NUO5PenWmhLKRHKS5b/S8FSAy BOw9kzAT75+JGFNRwFVQvSnXOq/BjRYXktTYFk6+wFT8H9xl3D2j5LllP600vsMVqSJ7 OrFouMhiPFT/YAQOKRvxbVW+QXyFVKFMZaK42IF1zkEYqO3Vbvw/0eSc5P4za6jbhIzY nz8QOSsdoDLmpAJsZUtmaDdj+YgtVs4SO1lOGexs8DkaN2Wyw+BZGCC1BV5sAmYlgP3C AxIYNvCEQJXF6Wi1KgOK29m+Spp/kLIEJVTd/WZow6aVzao2eAT5MsB+aTwtigpAsHbp 0vOQ== X-Received: by 10.70.103.204 with SMTP id fy12mr47462pdb.144.1408642383494; Thu, 21 Aug 2014 10:33:03 -0700 (PDT) Received: from spandex.local (63-140-102-194.dynamic.dsl.acsalaska.net. [63.140.102.194]) by mx.google.com with ESMTPSA id kb12sm26108709pbd.80.2014.08.21.10.33.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 10:33:02 -0700 (PDT) Message-ID: <53F62D4D.2030202@gmail.com> Date: Thu, 21 Aug 2014 09:33:01 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Linus Nordberg References: <53F51CAD.9030802@gmail.com> <87iolmkn1w.fsf@nordberg.se> In-Reply-To: <87iolmkn1w.fsf@nordberg.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7XpKv0A5LCWL8ZcnlMYKpvSekMM Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Thu, 21 Aug 2014 17:33:07 -0000 On 8/21/14 5:08 AM, Linus Nordberg wrote: > Which current draft is that? draft-ietf-trans-rfc6962-bis-04 does not > describe a gossip protocol. > > Is there a proposed gossip protocol somewhere I haven't looked? Apologies - it's not in the current draft, but the proposal is in his slides for the July meeting (http://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf). Melinda From nobody Thu Aug 21 11:26:37 2014 Return-Path: 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 73BA31A06AA for ; Thu, 21 Aug 2014 11:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 odyJXrDiwXVr for ; Thu, 21 Aug 2014 11:26:27 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9551A064C for ; Thu, 21 Aug 2014 11:26:26 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7LIQN1u015179 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Aug 2014 20:26:23 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s7LIQJ2N014480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2014 18:26:22 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1408645582; bh=SijMec+W2yv/WjQzjptHNyP+6F2frO59i80NJuwhgbc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=m3L+N3eIEhy7bfbIDSflR1WQxHtJPMIqWYP/Wlhxe0GfMzGZ+442zhVb9PWyp9zzi xnMbAIeSwxx1GFTlWSI3ciDyAgZIvlq+vYAZ9FwTZMf2Q+TuqMhGCAQiUsEOP5/hW0 8bYnf2JPryeCgIawHHgKftq0Vj1KR7+hnGShGdEE= X-Footer: bm9yZHUubmV0 Received: from flogsta.nordberg.se ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 21 Aug 2014 20:26:22 +0200 From: Linus Nordberg To: Melinda Shore Organization: NORDUnet A/S References: <53F51CAD.9030802@gmail.com> <87iolmkn1w.fsf@nordberg.se> <53F62D4D.2030202@gmail.com> Date: Thu, 21 Aug 2014 20:26:50 +0200 In-Reply-To: <53F62D4D.2030202@gmail.com> (Melinda Shore's message of "Thu, 21 Aug 2014 09:33:01 -0800") Message-ID: <87vbplhf6d.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aMFuqnos - 17243ed1209f - 20140821 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AazCXBcEPUMxoNAw9IOGTi-sOLA Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol text X-BeenThere: trans@ietf.org 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: Thu, 21 Aug 2014 18:26:28 -0000 Melinda Shore wrote Thu, 21 Aug 2014 09:33:01 -0800: | On 8/21/14 5:08 AM, Linus Nordberg wrote: | > Which current draft is that? draft-ietf-trans-rfc6962-bis-04 does not | > describe a gossip protocol. | > | > Is there a proposed gossip protocol somewhere I haven't looked? | | Apologies - it's not in the current draft, but the proposal is | in his slides for the July meeting | (http://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf). Oh right, thanks. Apologies for totally forgetting about those. From nobody Thu Aug 28 08:16:38 2014 Return-Path: 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 C52E81A7D84 for ; Thu, 28 Aug 2014 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 731IyK_lZOBu for ; Thu, 28 Aug 2014 08:16:29 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4649F1A8704 for ; Thu, 28 Aug 2014 08:16:02 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 90190813B2 for ; Thu, 28 Aug 2014 11:16:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1409238961; bh=SAChpxAPafNBddQzkurDym3AJDj/Gew4oc8BvIE4cLA=; h=Date:From:To:Subject; b=YTAO4+EvNuvQD3zScCKFwo9B0NBHGSdT2AyAgCbV/h/qdWkh1SaLh24Xr71wxyynf wKwfZS5wt/yL2vWjfD6PpuOamhWZcnAUzb30sROFbSUZRcV4U1SwGLvXml8AvIzNbo lLD5d6gbUGkYluioB4AGW5v7xq5Vti5I1WrWo3QQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7SFG11r019115 for ; Thu, 28 Aug 2014 11:16:01 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 28 Aug 2014 11:16:01 -0400 (EDT) From: Paul Wouters To: Trans Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IGv1YhBaR6-MPrZUWS4WnaK81PA Subject: [Trans] end to end email encryption using CT gossip protocol X-BeenThere: trans@ietf.org 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: Thu, 28 Aug 2014 15:16:34 -0000 ---------- Forwarded message ---------- Date: Thu, 28 Aug 2014 11:15:38 From: Paul Wouters To: Trans Subject: end to end email encryption using CT gossip protocol FYI https://code.google.com/p/end-to-end/wiki/KeyDistribution For End-To-End, our current approach to key distribution, is to use a model similar to Certificate Transparency, and use the email messages themselves as a gossip protocol, which allow the users themselves to keep the centralized authorities honest. This approach allows users to not have to know about keys, but at the same time, be able to make sure that the servers involved aren't doing anything malicious behind the users' back. To allow the system to be easily distributed (across multiple identity providers), key servers can authenticate the user via existing federated identity protocols (with OpenID Connect for example). The model of a key server with a transparency backend is based on the premise that a user is willing to trust the security of a centralized service, as long as it is subject to public scrutiny, and that can be easily discovered if it's compromised (so it is still possible to compromise the user's account, but the user will be able to know that as soon as possible). It's worth noting that End-to-End is still under active development, and we might change our approach to key distribution if we find weaknesses in this model, or if we find something else that is as easy to use, and as likely to work. Part of the reason we release this document is to seek early feedback from the community, and adapt as needed. We also want to point out we will do our very best to continue to support existing OpenPGP users who want to manually manage and verify keys and fingerprints manually, as we understand that system has been around for a long time, and has been more battle tested than what we are proposing. From nobody Thu Aug 28 09:14:22 2014 Return-Path: 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 BDBD31A875F for ; Thu, 28 Aug 2014 09:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 s-42fGRkgrlJ for ; Thu, 28 Aug 2014 09:14:17 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720BB1A875C for ; Thu, 28 Aug 2014 09:14:15 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so1001837wes.22 for ; Thu, 28 Aug 2014 09:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=qQbr/Gllp+gsrpQxz0cW9pkDy8CpgJnc9r6c9RJWJx0=; b=ZULXJyFcXbDcVd7QWxk/Cd+/7JLL83ymd/z8dQJWJ8Qfdw7uIUD94qZC04w4UC48q1 RwfC0KvzLs2OmK+ECG1CA1gxfAq5pe6N851Ph2aZ46Y5VCT7A4Sna92WqfbDbTAVsyc8 /mDj9juFAoALrH1mQeaqKen20FZlqvJw11oo1RpWFB+nY2R0W240wtx6yvQQQGa2ju9v 7KoEzQ4FeXhU90cqk0EOpkYdHvOUftA1O8vrtanlxZXchkDKqF3akFghfoRYqAeFcG2R hns6HWE/EDR1+OOfX6WuREwctKqZcvlYrMmBKWDnImw/j9xNYVzhFLbam31+X8bMLBz/ GCHQ== X-Received: by 10.180.208.111 with SMTP id md15mr7262980wic.3.1409242454136; Thu, 28 Aug 2014 09:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.253.200 with HTTP; Thu, 28 Aug 2014 09:13:54 -0700 (PDT) From: Fabrice Gautier Date: Thu, 28 Aug 2014 09:13:54 -0700 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/duinxMYKQe77qX9k4NhsoHE6XF4 Subject: [Trans] Clarification regarding SCTs and intermediates. X-BeenThere: trans@ietf.org 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: Thu, 28 Aug 2014 16:14:18 -0000 Hi all, Per my reading of rfc 6962, it seems that SCT (in that RFC) are only produced for Leaf certificates. 6962-bis introduce a possibility that intermediates certs are also logged and SCT produced for them. (Section 3.2.3. Using a Name-Constrained Intermediate CA) This raised a couple questions: - How are SCTs for intermediates provided to TLS clients ? Can they be provided through the TLS extension? Through the OCSP response? Embedded in the leaf cert ? Or only embedded in the intermediate cert ? - If intermediates SCTs can be provided by the same channel as SCTs for leaf certs, how is the TLS client supposed to know which cert correspond to a given SCT? Should the TLS client just try all the certs in the chain until the signature match ? - afaict, there is no data in the SCT that bind it to the cert, beside the signature. - If I, a TLS client, have SCTs for both leafs and certs, assuming I figure out which one is for which, what kind of policies are we expecting the TLS client to apply. I realize this is probably out of scope for the RFC, but I'm curious what the expectation are here. In both 6962, and 6962-bis, the TLS client behavior is very shortly described in section 5.2. TLS Clients. It basically boils down to one sentence "they (TLS clients) should validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature," In 6962-bis, section 3.2.3, there is some language about what kind of intermediate CA are acceptable to log. It seems that at least some logs clients should also check that intermediates CA with SCTs do obey those rules. I'm not sure if it's the role of TLS clients, Auditors, Monitors or all of them to do so. Thanks -- Fabrice From nobody Sat Aug 30 13:48:48 2014 Return-Path: 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 DD4E21A0686 for ; Sat, 30 Aug 2014 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 v2qB2zU_gfOp for ; Sat, 30 Aug 2014 13:48:46 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9463E1A0676 for ; Sat, 30 Aug 2014 13:48:46 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id kq14so9022556pab.36 for ; Sat, 30 Aug 2014 13:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:content-type:from:mime-version:subject :message-id:date:to; bh=E17YY94vKzg3WB06FqUXHeOKBF4DkVsyaeV+fIho82g=; b=bH2Juh66sYCkHk8uqZ3Z+eCbOhgVKuDcpkOWR4Cjc9ZsR9TdPSA2Wm+GJQekZVHH+B 1Pr/vvRepDVT/1avl72GA54oUz/dL5yCSOx4OeQQdvql+0DKrb34n7gkCA6cYL1//A3w HzEelaZUlSTpYWvycgha1BSTaesdLkmFsBLXZ8dvK91M0xyAKeYnC8vlsIISKqXg5505 Dw8RQ2fqkGJECb326ypRwc9OMslM07ArXGUkWS6SgAuhCa0v4nVLqxaRrHt66u1lLCPn 16+QuUI8ImXqL11wkukgJY1tUxzaLY6IcbXgGruiRSEpNZ8+u1M4PfEmNrPeUMvbTPWI KoIA== X-Received: by 10.70.102.175 with SMTP id fp15mr26466354pdb.52.1409431726241; Sat, 30 Aug 2014 13:48:46 -0700 (PDT) Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id ix8sm12288204pac.32.2014.08.30.13.48.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 13:48:44 -0700 (PDT) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii From: Fabrice Mime-Version: 1.0 (1.0) Message-Id: Date: Sat, 30 Aug 2014 13:48:44 -0700 To: "trans@ietf.org" X-Mailer: iPhone Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/sfbNsRXucwHTXgXBZbL_Q_SFkiM Subject: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Sat, 30 Aug 2014 20:48:48 -0000 Hi, Regarding the transport of SCTs as part of OCSP responses, the RFCs only tal= k about it in the context of OCSP stapling. Can SCTs also be provided in non= stapled OCSP responses to TLS clients? Also, should 6962-bis also reference rfc6961 (multiple OCSP responses extens= ion) in addition to rfc 6066? Or should the language be generalized to just talk about SCTs in OCSP respon= ses, no matter how those responses are provided to the TLS client? Thanks=20 -- Fabrice From nobody Sat Aug 30 14:16:35 2014 Return-Path: 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 9A1BD1A067F for ; Sat, 30 Aug 2014 14:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 DhipPGrXKGpI for ; Sat, 30 Aug 2014 14:16:31 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD90B1A0502 for ; Sat, 30 Aug 2014 14:16:30 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so3600128qaj.35 for ; Sat, 30 Aug 2014 14:16:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vdP9fC5eF/MkuUdYXls4Nbepezvhy2ivBcOKWYWrm0A=; b=Vw8NknrwuFQV0KgudYHN6q4HWatS5QiD3xf2ynq3Ksw0s8JJt/F4jjOv3wsY18SelN 0O881oCfgqeGzx/AVchb19MJM9omI0UHlMFoqEaNS1dpY3pJc12QoxpFv31p2C9acgmd OREBFtAO6AzAfRKV1VStEbg57jYJcolK54bhhKm2StEBX4B1SlXHxYC69STDMVfzIKBp gy5G1k09QpZ6ZVKtLjScLlw+DzFT3shTlaJLi8HE8lb7Quwrg7vIBnh5utVkjbvXfGud 2CBxgcYJeU9E53ocwADWza/H7vjzAY0vGVhHH/tOe794R5gtXR2zhDawulujSmd9iQHx Q0uQ== X-Gm-Message-State: ALoCoQlwJ+ni0JkfcX9PArtn1b1cCX65EgFcFgaVhAy+QEudvkU4z8WXD6Oo+b1waMms9MyqyOCc MIME-Version: 1.0 X-Received: by 10.224.151.143 with SMTP id c15mr21623409qaw.10.1409433389936; Sat, 30 Aug 2014 14:16:29 -0700 (PDT) Received: by 10.224.67.133 with HTTP; Sat, 30 Aug 2014 14:16:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 30 Aug 2014 14:16:29 -0700 Message-ID: From: Brian Smith To: Fabrice Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Ft4F_CiP38BARZYVV_nzp_PZT4I Cc: "trans@ietf.org" Subject: Re: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Sat, 30 Aug 2014 21:16:32 -0000 On Sat, Aug 30, 2014 at 1:48 PM, Fabrice wrote: > Regarding the transport of SCTs as part of OCSP responses, the RFCs only talk about it in the context of OCSP stapling. Can SCTs also be provided in non stapled OCSP responses to TLS clients? A client that requires SCTs cannot rely on an unreliable fetching mechanism like OCSP fetching to get the SCTs. Consequently, the web server must always give the client the SCTs so that the client doesn't have to fetch anything to get them. > Or should the language be generalized to just talk about SCTs in OCSP responses, no matter how those responses are provided to the TLS client? No. It is critical that the OCSP response be stapled if the SCTs are embedded in an OCSP response. Just one example why: Imagine a captive portal on a Wifi network that forces people to login at https://example.org/ and which blocks requests to the OCSP responder for its certificate. If the SCTs are not provided in the handshake (in the certificate, in the TLS extension, or in a stapled OCSP response), then there would be no way to get the SCTs. Cheers, Brian From nobody Sat Aug 30 15:22:06 2014 Return-Path: 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 A67A21A0BEB for ; Sat, 30 Aug 2014 15:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xtVIjI_Hykp0 for ; Sat, 30 Aug 2014 15:22:02 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFED61A1F04 for ; Sat, 30 Aug 2014 15:22:02 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id g10so3046331pdj.28 for ; Sat, 30 Aug 2014 15:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TswakxK7jIeJizwQKcclVAubAQWlhMiLmMMPNbWU1/E=; b=yP0aoARBxbvO3Q+9oO4aU+v7vfD5CF4cQQEHXGCqU2oW16NK+MS9XTsWpqil5qP66/ SVUp0imQBQeIxSOffjnt+VOcpBiD0G7wL5haFtjHCbYMU9DQgiYqS35SJjMY5Doa4awy bVaho8WJkg8PMWSvX19xkV+W4E3VmtB/NRYClo/ExDHYIjgxcU93FHnCJ4hK/UpTemTK y6gSsUJT9uoJKwamfqL9YMPQiixdo7ciHIIh5Q0qFlTchTYnL+X940RpAOXeo132fce6 1cJ5zbTx2tgX9msC9IFyj7eqeX+vjdUCn1RD87qxLRwna21dvpXwK8mcPjAcqLDACMJS UoCg== X-Received: by 10.70.49.2 with SMTP id q2mr24923222pdn.28.1409437322397; Sat, 30 Aug 2014 15:22:02 -0700 (PDT) Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id ny7sm12783811pab.38.2014.08.30.15.22.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 15:22:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sat, 30 Aug 2014 15:22:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com> References: To: Brian Smith Archived-At: http://mailarchive.ietf.org/arch/msg/trans/pf1nss9fsZZfHmYShMQTjdIP1Vo Cc: "trans@ietf.org" Subject: Re: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Sat, 30 Aug 2014 22:22:04 -0000 > On Aug 30, 2014, at 14:16, Brian Smith wrote: >=20 >> On Sat, Aug 30, 2014 at 1:48 PM, Fabrice wrot= e: >> Regarding the transport of SCTs as part of OCSP responses, the RFCs only t= alk about it in the context of OCSP stapling. Can SCTs also be provided in n= on stapled OCSP responses to TLS clients? >=20 > A client that requires SCTs cannot rely on an unreliable fetching > mechanism like OCSP fetching to get the SCTs. Consequently, the web > server must always give the client the SCTs so that the client doesn't > have to fetch anything to get them. >=20 >> Or should the language be generalized to just talk about SCTs in OCSP res= ponses, no matter how those responses are provided to the TLS client? >=20 > No. It is critical that the OCSP response be stapled if the SCTs are > embedded in an OCSP response. >=20 > Just one example why: Imagine a captive portal on a Wifi network that > forces people to login at https://example.org/ and which blocks > requests to the OCSP responder for its certificate. If the SCTs are > not provided in the handshake (in the certificate, in the TLS > extension, or in a stapled OCSP response), then there would be no way > to get the SCTs. I understand the issue you describe and how stapling has less opportunities f= or failures and is a MUST for TLS clients, but my question was really about w= hat should a TLS client do when it does not get an OCSP response through sta= pling (RFC6066) but get one directly from the OCSP responder or potentially o= ther means.=20 To me, it seems logical for the TLS clients to process SCTs found in those r= esponses, no matter how it got them. -- Fabrice >=20 > Cheers, > Brian From nobody Sat Aug 30 15:43:20 2014 Return-Path: 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 209ED1A212D for ; Sat, 30 Aug 2014 15:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 kYG5Nmuegewf for ; Sat, 30 Aug 2014 15:43:18 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE381A212A for ; Sat, 30 Aug 2014 15:43:17 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so3570658qac.26 for ; Sat, 30 Aug 2014 15:43:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iF2W63lXwC5yXd+yKe2MT9yvgkDw4Jz0uqEL6nDsH+w=; b=SLgsihQ3ChaA5r6BJQZ3NJJOrGXtKwN5JWqwBQeI4/QZP1IwNuoDr9ZzSug/lwdDLR AQnqBWdJTTFEM1McfdO8qYZp7jYnUSxnwAgLXhkaHeaulIk6ExiS8v9F1beOvHruNjly IApMQOHc7MssU9N9vHWbbYaJVhH+TgERyypglFhVXjTHleVmdzh16VViM2UvdSOXFQl8 a+sXb1oEn88ICisN2x7oSkarxAI2kv2QIL8tYOrAlvFGms4/CxJnFThgdzb3i+Sm/YOC QWDCaRiCEL+CN0TsStIjt37/OToqUINt2bdCyxCRv0CIRilPXiPhtt2yonh1VQe7z+iy 3rZg== X-Gm-Message-State: ALoCoQl1ucKMx+WAUet6AJd8RbTXjuWvSYb1OnE3P63RzTmwcNzEVSZbUif0gKCag0Q2n7gVrP2D MIME-Version: 1.0 X-Received: by 10.140.81.134 with SMTP id f6mr22501978qgd.60.1409438597273; Sat, 30 Aug 2014 15:43:17 -0700 (PDT) Received: by 10.224.67.133 with HTTP; Sat, 30 Aug 2014 15:43:17 -0700 (PDT) In-Reply-To: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com> References: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com> Date: Sat, 30 Aug 2014 15:43:17 -0700 Message-ID: From: Brian Smith To: Fabrice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DtFIMwivaVWEk2tl6FG0QqBHFsM Cc: "trans@ietf.org" Subject: Re: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Sat, 30 Aug 2014 22:43:19 -0000 On Sat, Aug 30, 2014 at 3:22 PM, Fabrice wrote: >> On Aug 30, 2014, at 14:16, Brian Smith wrote: > I understand the issue you describe and how stapling has less opportuniti= es for failures and is a MUST for TLS clients, but my question was really a= bout what should a TLS client do when it does not get an OCSP response thro= ugh stapling (RFC6066) but get one directly from the OCSP responder or pote= ntially other means. > > To me, it seems logical for the TLS clients to process SCTs found in thos= e responses, no matter how it got them. When the client is enforcing CT, it should reject the certificate due to the missing SCT before it even attempts revocation checking. Thus, it would never fetch the OCSP response and so it would never learn the SCT from a fetched response. Cheers, Brian From nobody Sat Aug 30 21:06:05 2014 Return-Path: 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 22A531A6F7E for ; Sat, 30 Aug 2014 21:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 lBAxI0k3lrH9 for ; Sat, 30 Aug 2014 21:05:57 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A94C1A6F7F for ; Sat, 30 Aug 2014 21:05:56 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fb1so9455107pad.27 for ; Sat, 30 Aug 2014 21:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=unDZ9awBFUzfIpWwiTimMQqZj0Qz48tlNzVrmDWrKec=; b=DIBAQRdZqAMOb6ciKpDYExFlsHBTqgctwBVVUYlycTvR7ei3n1ocrRO/ihvlj1qJ4C bnwc/R3GR4cnsgfBpdw3RxMgtjggqrAQiBGbakfys6q5lkdCJ0g9VV1YI6cjQkhoNjIy Gic8t/C8nQTwh657WzAWUsoykog9XlPpOWthFe6kAIDmjTCSDEweE6dl03uexxDIrIl7 xhOYLXDP/OnJde57IeyYfgp2AyXI1N82hI1DIgWGKKfIGhvyb/SrpSdBFzNsl9R2WY9y VtVQirRhXWXNkGCNpUMr5Cnf+6+LlkWQaybAre38wu6qc6N00z5hJI/IJ+CMnigarxeg aQkg== X-Received: by 10.66.65.130 with SMTP id x2mr28014030pas.79.1409457955623; Sat, 30 Aug 2014 21:05:55 -0700 (PDT) Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id ry9sm4117182pbc.94.2014.08.30.21.05.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 21:05:53 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9E9D4C9F-7002-4BBF-AF1C-9825D01DFC06 Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sat, 30 Aug 2014 21:05:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: <1929A47D-06A5-4550-A26E-902DE964F980@gmail.com> References: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com> To: Brian Smith Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_HCeTjLXVPnoTaGelylTzXOi83U Cc: "trans@ietf.org" Subject: Re: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Sun, 31 Aug 2014 04:06:03 -0000 --Apple-Mail-9E9D4C9F-7002-4BBF-AF1C-9825D01DFC06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Aug 30, 2014, at 15:43, Brian Smith wrote: >=20 > On Sat, Aug 30, 2014 at 3:22 PM, Fabrice wrote= : >>> On Aug 30, 2014, at 14:16, Brian Smith wrote: >> I understand the issue you describe and how stapling has less opportuniti= es for failures and is a MUST for TLS clients, but my question was really ab= out what should a TLS client do when it does not get an OCSP response throug= h stapling (RFC6066) but get one directly from the OCSP responder or potenti= ally other means. >>=20 >> To me, it seems logical for the TLS clients to process SCTs found in thos= e responses, no matter how it got them. >=20 > When the client is enforcing CT, it should reject the certificate due > to the missing SCT before it even attempts revocation checking. > Thus, > it would never fetch the OCSP response and so it would never learn the > SCT from a fetched response. I don't see any language in the RFC or draft that suggest there is an orderi= ng between revocation checking and CT validation, or any other parts of the c= ertificate validation. The only related language I found is rather succinct:= In addition to normal validation of the certificate and its chain, they shou= ld validate the SCT (...)=20 If there are good reasons to ignore SCTs in non-stapled OCSP responses, I'd l= ike to know about them, and it probably should be mentioned in the RFC. >=20 > Cheers, > Brian --Apple-Mail-9E9D4C9F-7002-4BBF-AF1C-9825D01DFC06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 30, 2= 014, at 15:43, Brian Smith <brian= @briansmith.org> wrote:

<= span>On Sat, Aug 30, 2014 at 3:22 PM, Fabrice <fabrice.gautier@gmail.com> wrote:
On Aug 30, 2014, at 14:1= 6, Brian Smith <brian@briansmith.= org> wrote:
I understand the issue you describe and how stapling has less opp= ortunities for failures and is a MUST for TLS clients, but my question was r= eally about what should a TLS client do when it does not get an OCSP respons= e through stapling (RFC6066) but get one directly from the OCSP responder or= potentially other means.
<= span>
To me, it seems= logical for the TLS clients to process SCTs found in those responses, no ma= tter how it got them.

When the= client is enforcing CT, it should reject the certificate due
to the missing SCT before it even attempts revocation checking.
Thus,
it= would never fetch the OCSP response and so it would never learn the<= br>SCT from a fetched response.

=

I don't see any language in the RFC or draft t= hat suggest there is an ordering between revocation checking and CT validati= on, or any other parts of the certificate validation. The only related langu= age I found is rather succinct:
In addition to normal validation of the certif=
icate and its chain, they should validate the SCT (...)
<= /div>

If there are good reasons to ign= ore SCTs in non-stapled OCSP responses, I'd like to know about them, and it p= robably should be mentioned in the RFC.


Cheers,
Brian
= --Apple-Mail-9E9D4C9F-7002-4BBF-AF1C-9825D01DFC06-- From nobody Sun Aug 31 11:44:20 2014 Return-Path: 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 5456B1A8AD8 for ; Sun, 31 Aug 2014 11:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 cDMWETJ14-xj for ; Sun, 31 Aug 2014 11:44:12 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D271A8AAC for ; Sun, 31 Aug 2014 11:44:11 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so4091718qaq.38 for ; Sun, 31 Aug 2014 11:44:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VCrTxtMEw4kMKsR0zlCln+tnEqeX4Ejlq2XtRTvy6S4=; b=bH4VvGiKDG59VuEmIjW5Lsp7t4wcFJSza/wiB5KEkaf0+PfV3FiBXGU+DXN4yYGoEO J1lkU4cQqHBwZnXzuuUO8E22PGv7QXWX5iG3VjqlKmMRcReaz3+mH7CPPsW6dm4XIXgW yjd0dyk1Yw8OG20UNU6ycJGdZiGezjrLAr4UVmELgNyqRJu9i+SkKmtxENMLUrVC8znY QtMX3aVfhTu6wMhweI6uwjElR2Qs2+QShQi3kUiZj0Ok+uKthKuvMl1nMmzBo2olT5kT MPztUAZ8+SUjSDVrAkaIMWQHmfBxk9S9rZKzdbL4cLg6pFwMPE+lW6hdvYbp6/PnYz0i 6Xvg== X-Gm-Message-State: ALoCoQmnaUtn+fqXFPlnYDcGxxBV0fQ4vZ/GZ7An89ExNOexDVeBneAgerKXcc00BnHD0kAMKPsR MIME-Version: 1.0 X-Received: by 10.140.81.134 with SMTP id f6mr29058473qgd.60.1409510651138; Sun, 31 Aug 2014 11:44:11 -0700 (PDT) Received: by 10.224.67.133 with HTTP; Sun, 31 Aug 2014 11:44:10 -0700 (PDT) In-Reply-To: <1929A47D-06A5-4550-A26E-902DE964F980@gmail.com> References: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com> <1929A47D-06A5-4550-A26E-902DE964F980@gmail.com> Date: Sun, 31 Aug 2014 11:44:10 -0700 Message-ID: From: Brian Smith To: Fabrice Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/NU_PNqPJTYZaBPOw9bphxAYPSHo Cc: "trans@ietf.org" Subject: Re: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Sun, 31 Aug 2014 18:44:13 -0000 On Sat, Aug 30, 2014 at 9:05 PM, Fabrice wrote: > On Aug 30, 2014, at 15:43, Brian Smith wrote: >> On Sat, Aug 30, 2014 at 3:22 PM, Fabrice wrote: >>> On Aug 30, 2014, at 14:16, Brian Smith wrote: >>> >>> I understand the issue you describe and how stapling has less opportunities >>> for failures and is a MUST for TLS clients, but my question was really about >>> what should a TLS client do when it does not get an OCSP response through >>> stapling (RFC6066) but get one directly from the OCSP responder or >>> potentially other means. >>> >>> To me, it seems logical for the TLS clients to process SCTs found in those >>> responses, no matter how it got them. >>> >> When the client is enforcing CT, it should reject the certificate due >> to the missing SCT before it even attempts revocation checking. >> >> Thus, it would never fetch the OCSP response and so it would never >> learn the SCT from a fetched response. > > I don't see any language in the RFC or draft that suggest there is an > ordering between revocation checking and CT validation, or any other parts > of the certificate validation. The only related language I found is rather > succinct: > > In addition to normal validation of the certificate and its chain, they > should validate the SCT (...) I understand that your question is "If I fetched an OCSP response, should I recognize the SCTs in the fetched response?" I don't have any opinion on that. You are right that the spec. doesn't talk about the ordering of doing revocation checking and SCT processing during certificate chain validation. I believe that the best ordering is to process SCTs, and reject certificates without SCTs, before doing revocation checking or path building, especially revocation checking and path building that requires doing any networking (OCSP fetching and/or AIA chasing), because this reduces the risks that are inherent in doing that networking and with doing path building in general. The draft should be changed to say that. However, you agree that the current draft allows a client to reject a certificate due to a missing SCT before it attempts any AIA chasing and/or OCSP fetching, right? If so, then the server must provide the SCT in the handshake--in the TLS extension, in the certificate, or in a stapled OCSP response--to interoperate with clients that work that way, regardless of whether some clients process SCTs in fetched OCSP responses. > If there are good reasons to ignore SCTs in non-stapled OCSP responses, I'd > like to know about them, and it probably should be mentioned in the RFC. A browser needs a reliable mechanism for getting SCTs in order for the browser to be able to make SCTs mandatory. Browsers that make SCT mandatory would ultimately be what would make CT effective. OCSP fetching is not reliable, in theory or on practice, so a client cannot rely on getting SCTs via OCSP fetching. A browser that processed SCTs in fetched OCSP responses would be encouraging websites to avoid the reliable mechanisms of SCT delivery in favor of an unreliable mechanism, causing CT to be unreliable and thus ineffective. Cheers, Brian From nobody Sun Aug 31 13:36:16 2014 Return-Path: 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 A270B1A9039 for ; Sun, 31 Aug 2014 13:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2zwfzg9eAvsx for ; Sun, 31 Aug 2014 13:36:13 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DABA1A9035 for ; Sun, 31 Aug 2014 13:36:13 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so10650207pab.31 for ; Sun, 31 Aug 2014 13:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=r/HYIYJZNiePXopUMCi4mdnCuREWPqGSiKcJ8xRulYM=; b=UAiupIfbA7PjvldEUfrlvN+7F+Jlb4gCM2P7ZVPVecnrDNCYTki5vBniBszsnW8C8U MBjvl7xJiuwUMifY4t2ifGx3KC/Ak6fWIOoJf7qz9v0HuClfcsYAsRYzaZzlYFcBD3my b7d0N+/gCBWxMVa/5h8XWodbjRoIDWViKKV3hx5stWJy3pGkN543F3R38fUFeUbCM2gm 6OYTZqkrNGmLln0yVv3cArrOrzQZX3l5IoI+wTrSV/ItSNTtQzYPZyHWYv5GKyF2tr+w 8Kry2JafpQaBuAxUey5T6BQ+i9ReACEO+DXnfO3fUPhbvhC2xwAdQdD4KYpFLi4igzWh R/+Q== X-Received: by 10.70.132.162 with SMTP id ov2mr17052376pdb.118.1409517372976; Sun, 31 Aug 2014 13:36:12 -0700 (PDT) Received: from [10.0.1.7] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id x7sm9062991pdj.36.2014.08.31.13.36.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Aug 2014 13:36:11 -0700 (PDT) References: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com> <1929A47D-06A5-4550-A26E-902DE964F980@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11D201) From: Fabrice Gautier Date: Sun, 31 Aug 2014 13:36:10 -0700 To: Brian Smith Archived-At: http://mailarchive.ietf.org/arch/msg/trans/cq_ydLRg9C0-0nw61L5o-X4KFlM Cc: "trans@ietf.org" Subject: Re: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Sun, 31 Aug 2014 20:36:14 -0000 > On Aug 31, 2014, at 11:44, Brian Smith wrote: >=20 >> On Sat, Aug 30, 2014 at 9:05 PM, Fabrice wrot= e: >>> On Aug 30, 2014, at 15:43, Brian Smith wrote: >>>> On Sat, Aug 30, 2014 at 3:22 PM, Fabrice wr= ote: >>>> On Aug 30, 2014, at 14:16, Brian Smith wrote: >>>>=20 >>>> I understand the issue you describe and how stapling has less opportuni= ties >>>> for failures and is a MUST for TLS clients, but my question was really a= bout >>>> what should a TLS client do when it does not get an OCSP response throu= gh >>>> stapling (RFC6066) but get one directly from the OCSP responder or >>>> potentially other means. >>>>=20 >>>> To me, it seems logical for the TLS clients to process SCTs found in th= ose >>>> responses, no matter how it got them. >>>>=20 >>> When the client is enforcing CT, it should reject the certificate due >>> to the missing SCT before it even attempts revocation checking. >>>=20 >>> Thus, it would never fetch the OCSP response and so it would never >>> learn the SCT from a fetched response. >>=20 >> I don't see any language in the RFC or draft that suggest there is an >> ordering between revocation checking and CT validation, or any other part= s >> of the certificate validation. The only related language I found is rathe= r >> succinct: >>=20 >> In addition to normal validation of the certificate and its chain, they >> should validate the SCT (...) >=20 > I understand that your question is "If I fetched an OCSP response, > should I recognize the SCTs in the fetched response?" I don't have any > opinion on that. >=20 > You are right that the spec. doesn't talk about the ordering of doing > revocation checking and SCT processing during certificate chain > validation. I believe that the best ordering is to process SCTs, and > reject certificates without SCTs, before doing revocation checking or > path building, especially revocation checking and path building that > requires doing any networking (OCSP fetching and/or AIA chasing), > because this reduces the risks that are inherent in doing that > networking and with doing path building in general. The draft should > be changed to say that. >=20 > However, you agree that the current draft allows a client to reject a > certificate due to a missing SCT before it attempts any AIA chasing > and/or OCSP fetching, right? Yes, but only because I don't think the draft says anything about rejecting c= ertificates without SCTs. It only says that the SCTs should be validated and= defines what a valid SCT is. The only document I know of that talk about how a TLS client would react to n= o SCTs (or not enough of them) is Chrome's published plans for tying togethe= r EV certs and CT. In that case, certificates are not rejected, just the UI w= ould look different. But I guess these are policy decisions that maybe out of the scope of the cu= rrent draft. > If so, then the server must provide the > SCT in the handshake--in the TLS extension, in the certificate, or in > a stapled OCSP response--to interoperate with clients that work that > way, regardless of whether some clients process SCTs in fetched OCSP > responses. >=20 >> If there are good reasons to ignore SCTs in non-stapled OCSP responses, I= 'd >> like to know about them, and it probably should be mentioned in the RFC. >=20 > A browser needs a reliable mechanism for getting SCTs in order for the > browser to be able to make SCTs mandatory. Browsers that make SCT > mandatory would ultimately be what would make CT effective. OCSP > fetching is not reliable, in theory or on practice, so a client cannot > rely on getting SCTs via OCSP fetching. A browser that processed SCTs > in fetched OCSP responses would be encouraging websites to avoid the > reliable mechanisms of SCT delivery in favor of an unreliable > mechanism, causing CT to be unreliable and thus ineffective. True, Maybe the draft should specify that clients should not consider SCTs coming f= rom unreliable mechanisms. I think this might be an important detail for implementations which may not a= lways know the origin of an ocsp response when processing it. > Cheers, > Brian From nobody Sun Aug 31 17:57:50 2014 Return-Path: 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 1B1931A90A8 for ; Sun, 31 Aug 2014 17:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 KPUmUmNmSExd for ; Sun, 31 Aug 2014 17:57:46 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668AF1A90A6 for ; Sun, 31 Aug 2014 17:57:46 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y13so4769884pdi.16 for ; Sun, 31 Aug 2014 17:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=QuXxJOUOrrxuWHS8QXBYMUTmYY4g37sTKhGcsTvAnmE=; b=qyWX6BJRI9kX1wBp24uL1UtOWLedihoHcHueTw/jm2RKpyZVvgun1Db6aiDAJe6N72 S8HEv1HshzuLTntBjZ4/ab+l9oHagLDp8gddMmI25+izBcnFO32DB54ltUuFkzfikb7O AYFnFWWiKKc9XOXglBzPEIc00RKpmWzDiawc6LY3CehAkdsbSu7cpgiXcD8P3OL8QmQI 0bnFT5TrE15b/wS6ML9S96GqwXF/48oWu9uMzmUzeg+IOO3xbYql6SVuVrwfNG9pslU/ nVHDantcqi8X2+3PjEUuzmYO5R0OVxI3+X+t5H18pwIreXYIZi+kI7grLIF7cOFeRJdi 5FMQ== X-Received: by 10.68.134.201 with SMTP id pm9mr217976pbb.143.1409533066064; Sun, 31 Aug 2014 17:57:46 -0700 (PDT) Received: from 34-188-5-21.pools.spcsdns.net (66-87-64-34.pools.spcsdns.net. [66.87.64.34]) by mx.google.com with ESMTPSA id ad10sm22536701pad.4.2014.08.31.17.57.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Aug 2014 17:57:44 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <239CAEF3-C77D-4E0B-B64D-D715D71AD1A8@gmail.com> <1929A47D-06A5-4550-A26E-902DE964F980@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----7VXLK5CIM3CBOM03R5V6QUW5SGWK32" Content-Transfer-Encoding: 8bit From: Kyle Hamilton Date: Sun, 31 Aug 2014 17:57:38 -0700 To: Brian Smith ,Fabrice Message-ID: <404f9e8c-6605-4482-92ec-5ad4c6adcde0@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2cWE5zdUG6vzO5h3xAGzckDBctk Cc: "trans@ietf.org" Subject: Re: [Trans] OCSP and SCTs X-BeenThere: trans@ietf.org 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: Mon, 01 Sep 2014 00:57:49 -0000 ------7VXLK5CIM3CBOM03R5V6QUW5SGWK32 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The more you apply your own "best idea" decision tree, the more you restrict perfectly valid options that would otherwise be legitimate by the spec, in the name of "interoperability". This is why, for example, Netscape's insistence on a "trustworthy" (which really devolves to "known, without judgment of trustworthiness") certifier managed to create a new and completely artificial cottage industry that suffered artificial stunted growth patterns... because it insisted on ITU-standard authentication before anyone knew what it was really good for. It also basically destroyed one of the use-cases explicitly permitted by the spec, that of the unauthenticated connection. Don't insist on a client-protocol stapling. Not everything uses TLS -- and even though TLS is the intended use case, leaving low hanging fruit for other protocols is probably better than binding it so tightly to TLS that no one can conceive of a use aside from that binding. -Kyle H On August 31, 2014 11:44:10 AM PST, Brian Smith wrote: >On Sat, Aug 30, 2014 at 9:05 PM, Fabrice >wrote: >> On Aug 30, 2014, at 15:43, Brian Smith wrote: >>> On Sat, Aug 30, 2014 at 3:22 PM, Fabrice >wrote: >>>> On Aug 30, 2014, at 14:16, Brian Smith >wrote: >>>> >>>> I understand the issue you describe and how stapling has less >opportunities >>>> for failures and is a MUST for TLS clients, but my question was >really about >>>> what should a TLS client do when it does not get an OCSP response >through >>>> stapling (RFC6066) but get one directly from the OCSP responder or >>>> potentially other means. >>>> >>>> To me, it seems logical for the TLS clients to process SCTs found >in those >>>> responses, no matter how it got them. >>>> >>> When the client is enforcing CT, it should reject the certificate >due >>> to the missing SCT before it even attempts revocation checking. >>> >>> Thus, it would never fetch the OCSP response and so it would never >>> learn the SCT from a fetched response. >> >> I don't see any language in the RFC or draft that suggest there is an >> ordering between revocation checking and CT validation, or any other >parts >> of the certificate validation. The only related language I found is >rather >> succinct: >> >> In addition to normal validation of the certificate and its chain, >they >> should validate the SCT (...) > >I understand that your question is "If I fetched an OCSP response, >should I recognize the SCTs in the fetched response?" I don't have any >opinion on that. > >You are right that the spec. doesn't talk about the ordering of doing >revocation checking and SCT processing during certificate chain >validation. I believe that the best ordering is to process SCTs, and >reject certificates without SCTs, before doing revocation checking or >path building, especially revocation checking and path building that >requires doing any networking (OCSP fetching and/or AIA chasing), >because this reduces the risks that are inherent in doing that >networking and with doing path building in general. The draft should >be changed to say that. > >However, you agree that the current draft allows a client to reject a >certificate due to a missing SCT before it attempts any AIA chasing >and/or OCSP fetching, right? If so, then the server must provide the >SCT in the handshake--in the TLS extension, in the certificate, or in >a stapled OCSP response--to interoperate with clients that work that >way, regardless of whether some clients process SCTs in fetched OCSP >responses. > >> If there are good reasons to ignore SCTs in non-stapled OCSP >responses, I'd >> like to know about them, and it probably should be mentioned in the >RFC. > >A browser needs a reliable mechanism for getting SCTs in order for the >browser to be able to make SCTs mandatory. Browsers that make SCT >mandatory would ultimately be what would make CT effective. OCSP >fetching is not reliable, in theory or on practice, so a client cannot >rely on getting SCTs via OCSP fetching. A browser that processed SCTs >in fetched OCSP responses would be encouraging websites to avoid the >reliable mechanisms of SCT delivery in favor of an unreliable >mechanism, causing CT to be unreliable and thus ineffective. > >Cheers, >Brian > >_______________________________________________ >Trans mailing list >Trans@ietf.org >https://www.ietf.org/mailman/listinfo/trans -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------7VXLK5CIM3CBOM03R5V6QUW5SGWK32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The more you apply your own "best idea" decision tree, the more you restrict perfectly valid options that would otherwise be legitimate by the spec, in the name of "interoperability". This is why, for example, Netscape's insistence on a "trustworthy" (which really devolves to "known, without judgment of trustworthiness") certifier managed to create a new and completely artificial cottage industry that suffered artificial stunted growth patterns... because it insisted on ITU-standard authentication before anyone knew what it was really good for. It also basically destroyed one of the use-cases explicitly permitted by the spec, that of the unauthenticated connection.

Don't insist on a client-protocol stapling. Not everything uses TLS -- and even though TLS is the intended use case, leaving low hanging fruit for other protocols is probably better than binding it so tightly to TLS that no one can conceive of a use aside from that binding.

-Kyle H

On August 31, 2014 11:44:10 AM PST, Brian Smith <brian@briansmith.org> wrote:
On Sat, Aug 30, 2014 at 9:05 PM, Fabrice <fabrice.gautier@gmail.com> wrote:
 On Aug 30, 2014, at 15:43, Brian Smith <brian@briansmith.org> wrote:
 On Sat, Aug 30, 2014 at 3:22 PM, Fabrice <fabrice.gautier@gmail.com> wrote:
 On Aug 30, 2014, at 14:16, Brian Smith <brian@briansmith.org> wrote:

 I understand the issue you describe and how stapling has less opportunities
 for failures and is a MUST for TLS clients, but my question was really about
 what should a TLS client do when it does not get an OCSP response through
 stapling (RFC6066) but get one
directly from the OCSP responder or
 potentially other means.

 To me, it seems logical for the TLS clients to process SCTs found in those
 responses, no matter how it got them.

 When the client is enforcing CT, it should reject the certificate due
 to the missing SCT before it even attempts revocation checking.

 Thus, it would never fetch the OCSP response and so it would never
 learn the SCT from a fetched response.

 I don't see any language in the RFC or draft that suggest there is an
 ordering between revocation checking and CT validation, or any other parts
 of the certificate validation. The only related language I found is rather
 succinct:

 In addition to normal validation of the certificate and its chain, they
 should validate the SCT (...)

I understand that your question is "If I fetched an OCSP response,
should I recognize the SCTs
in the fetched response?" I don't have any
opinion on that.

You are right that the spec. doesn't talk about the ordering of doing
revocation checking and SCT processing during certificate chain
validation. I believe that the best ordering is to process SCTs, and
reject certificates without SCTs, before doing revocation checking or
path building, especially revocation checking and path building that
requires doing any networking (OCSP fetching and/or AIA chasing),
because this reduces the risks that are inherent in doing that
networking and with doing path building in general. The draft should
be changed to say that.

However, you agree that the current draft allows a client to reject a
certificate due to a missing SCT before it attempts any AIA chasing
and/or OCSP fetching, right? If so, then the server must provide the
SCT in the handshake--in the TLS extension, in the certificate, or in
a stapled
OCSP response--to interoperate with clients that work that
way, regardless of whether some clients process SCTs in fetched OCSP
responses.

 If there are good reasons to ignore SCTs in non-stapled OCSP responses, I'd
 like to know about them, and it probably should be mentioned in the RFC.

A browser needs a reliable mechanism for getting SCTs in order for the
browser to be able to make SCTs mandatory. Browsers that make SCT
mandatory would ultimately be what would make CT effective. OCSP
fetching is not reliable, in theory or on practice, so a client cannot
rely on getting SCTs via OCSP fetching. A browser that processed SCTs
in fetched OCSP responses would be encouraging websites to avoid the
reliable mechanisms of SCT delivery in favor of an unreliable
mechanism, causing CT to be
unreliable and thus ineffective.

Cheers,
Brian


Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------7VXLK5CIM3CBOM03R5V6QUW5SGWK32--