From nobody Tue Nov 4 19:18: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 251151A1BB9 for ; Tue, 4 Nov 2014 19:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 zqZcIYbHAYyf for ; Tue, 4 Nov 2014 19:18:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A8C1A1B82 for ; Tue, 4 Nov 2014 19:18:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLH34016; Wed, 05 Nov 2014 03:18:01 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Nov 2014 03:17:59 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 5 Nov 2014 11:17:54 +0800 From: "Zhangdacheng (Dacheng)" To: "trans@ietf.org" Thread-Topic: New Version Notification for draft-zhang-trans-ct-binary-codes-00.txt Thread-Index: AQHP8ZHCq45sL5mQgk6XgKvF+eQNs5xRahyg Date: Wed, 5 Nov 2014 03:17:53 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3zvgEVLwCR0QQIOFcPNtiFqManQ Subject: [Trans] FW: New Version Notification for draft-zhang-trans-ct-binary-codes-00.txt 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, 05 Nov 2014 03:18:04 -0000 SGksIGEgcHJlbGltaW5hcnkgZG9jdW1lbnQgb2YgQ1QgZm9yIGJpbmFyaWVzIGlzIHB1Ymxpc2hl ZC4gQW55IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIHdpbGwgYmUgcmVhbGx5IGFwcHJlY2lhdGVk LiAgDQoNCkNoZWVycw0KDQpEYWNoZW5nDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMjcsIDIwMTQgMTA6NTcgQU0NCj4g VG86IFpoYW5nZGFjaGVuZyAoRGFjaGVuZyk7IFpoYW5nZGFjaGVuZyAoRGFjaGVuZykNCj4gU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGFuZy10cmFucy1jdC1i aW5hcnktY29kZXMtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXpoYW5nLXRyYW5zLWN0LWJpbmFyeS1jb2Rlcy0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBEYWNoZW5nIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4g cmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC16aGFuZy10cmFucy1jdC1iaW5hcnktY29k ZXMNCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJQ1QgZm9yIEJpbmFyeSBDb2Rlcw0KPiBEb2N1 bWVudCBkYXRlOgkyMDE0LTEwLTI3DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ IFBhZ2VzOgkJOA0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXpoYW5nLXRyYW5zLWN0LWJpbmFyeS1jb2Rlcy0wMC50eHQNCj4gU3RhdHVzOg0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy10cmFucy1jdC1iaW5h cnktY29kZXMvDQo+IEh0bWxpemVkOg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy10cmFucy1jdC1iaW5hcnktY29kZXMtMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4g ICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIHNvbHV0aW9uIHRvIHVzZSBDVCBmb3IgcHVibGlz aGluZyBzb2Z0d2FyZXMvDQo+ICAgIGJpbmFyeSBjb2RlcyBhbmQgdGhlaXIgc2lnbmF0dWVycy4N Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Nov 4 19:20: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 2213F1A1BCC for ; Tue, 4 Nov 2014 19:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 Q__frRfcZqBe for ; Tue, 4 Nov 2014 19:20:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CE11A1BB9 for ; Tue, 4 Nov 2014 19:20:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOK69933; Wed, 05 Nov 2014 03:20:17 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Nov 2014 03:20:16 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 5 Nov 2014 11:20:09 +0800 From: "Zhangdacheng (Dacheng)" To: "trans@ietf.org" Thread-Topic: New Version Notification for draft-zhang-trans-ct-dnssec-00.txt Thread-Index: AQHP8BIYecMgp5jj9E+bv+tjKn8Od5xRbnJw Date: Wed, 5 Nov 2014 03:20:08 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uKj9y85fkC45NILYCr6vBFalz08 Subject: [Trans] FW: New Version Notification for draft-zhang-trans-ct-dnssec-00.txt 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, 05 Nov 2014 03:20:20 -0000 VGhlIGRvY3VtZW50IG9mIENUIGZvciBETlNTRUMgaXMgYXR0YWNoZWQuIExvb2sgZm9yd2FyZCB0 byBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuIF5fXg0KDQpDaGVlcnMNCg0KRGFjaGVuZw0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogU2F0dXJkYXks IE9jdG9iZXIgMjUsIDIwMTQgMToxMSBQTQ0KPiBUbzogWmhhbmdkYWNoZW5nIChEYWNoZW5nKTsg WmhhbmdkYWNoZW5nIChEYWNoZW5nKQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXpoYW5nLXRyYW5zLWN0LWRuc3NlYy0wMC50eHQNCj4gDQo+IA0KPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemhhbmctdHJhbnMtY3QtZG5zc2VjLTAwLnR4dA0KPiBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhY2hlbmcgWmhhbmcgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXpoYW5nLXRy YW5zLWN0LWRuc3NlYw0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlDZXJ0aWZpY2F0ZSBUcmFu c3BhcmVuY3kgZm9yIERvbWFpbiBOYW1lIFN5c3RlbSBTZWN1cml0eQ0KPiBFeHRlbnNpb25zDQo+ IERvY3VtZW50IGRhdGU6CTIwMTQtMTAtMjUNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4gUGFnZXM6CQkxMw0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXpoYW5nLXRyYW5zLWN0LWRuc3NlYy0wMC50eHQNCj4gU3RhdHVzOg0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy10cmFucy1jdC1kbnNz ZWMvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy10cmFucy1jdC1kbnNzZWMtMDANCj4gDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgSW4gZHJh ZnQtaWV0Zi10cmFucy1yZmM2OTYyLWJpcywgYSBzb2x1dGlvbiBpcyBwcm9wb3NlZCBmb3IgcHVi bGljbHkNCj4gICAgbG9nZ2luZyB0aGUgZXhpc3RlbmNlIG9mIFRyYW5zcG9ydCBMYXllciBTZWN1 cml0eSAoVExTKSBjZXJ0aWZpY2F0ZXMNCj4gICAgdXNpbmcgTWVya2xlIEhhc2ggVHJlZXMuICBU aGlzIGRvY3VtZW50IHRyaWVzIHRvIHVzZSB0aGlzIGlkZWEgaW4NCj4gICAgRE5TU0VDIGFuZCBw dWJsaWNseSBsb2dnaW5nIHRoZSBEUyBSUnMgaW4gb3JkZXIgdG8gbm90aWNlIHRoZQ0KPiAgICBp c3N1YW5jZSBvZiBzdXNwZWN0IGtleSBzaWduaW5nIGtleXMuDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Wed Nov 5 19:19: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 55BEF1A036D for ; Wed, 5 Nov 2014 19:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 WAbmaeC075nN for ; Wed, 5 Nov 2014 19:19:37 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8661E1A0389 for ; Wed, 5 Nov 2014 19:19:37 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 81A5D47617 for ; Thu, 6 Nov 2014 03:19:36 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7543D47616 for ; Thu, 6 Nov 2014 03:19:36 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 699282039 for ; Thu, 6 Nov 2014 03:19:36 +0000 (GMT) Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 5 Nov 2014 22:19:17 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 5 Nov 2014 22:19:17 -0500 From: "Salz, Rich" To: "trans@ietf.org" Date: Wed, 5 Nov 2014 22:19:16 -0500 Thread-Topic: Log servers by Feb 2015? Thread-Index: Ac/5b/ZhEdoboZfRS1WHIEd2ptBViw== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232@USMBX1.msg.corp.akamai.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_2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/HeQeF6TVglgj0_jkhXnEWDbhRMo Subject: [Trans] Log servers by Feb 2015? 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, 06 Nov 2014 03:19:39 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are any (other) log servers planning on being up and ready in production by= Feb 2015, to meet the schedule requirements described by Google? (See the PDF file attached here: http://www.certificate-transparency.org/ev= -ct-plan) -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are any (other) = log servers planning on being up and ready in production by Feb 2015, to me= et the schedule requirements described by Google?

(See the PDF file attached here: http://www.certificate-transparency.org/ev-c= t-plan)

 

 

-- 

Principal Security Engineer, Akamai Technologies<= o:p>

IM: r= salz@jabber.me Twitter: RichSalz

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232USMBX1msgcorp_-- From nobody Wed Nov 5 23:49: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 DDB131A19ED for ; Wed, 5 Nov 2014 23:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.721 X-Spam-Level: * X-Spam-Status: No, score=1.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, 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 XqhNLbeIVlHP for ; Wed, 5 Nov 2014 23:49:06 -0800 (PST) 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 CF8741A06FD for ; Wed, 5 Nov 2014 23:49:06 -0800 (PST) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id F1C5B282E37 for ; Thu, 6 Nov 2014 18:49:05 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 05495A0A25; Thu, 6 Nov 2014 18:49:04 +1100 (EST) Date: Thu, 6 Nov 2014 18:49:04 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20141106074904.GA9751@hezmatt.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/vbxmrwrBTG9WbbTpRZHIOLOu4f0 Subject: Re: [Trans] Log servers by Feb 2015? 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, 06 Nov 2014 07:49:10 -0000 On Wed, Nov 05, 2014 at 10:19:16PM -0500, Salz, Rich wrote: > Are any (other) log servers planning on being up and ready in production > by Feb 2015, to meet the schedule requirements described by Google? Define "other". I've had alpha.ctlogs.org up since August, if I'm not counted in your initial set. Code behind it is released, too: https://github.com/sslwatcher/ct-log-server. - Matt -- "Left to themselves, [marketers] would butt-tag us like polar bears to track our buying habits and bombard our phones and emails and computer screens with ads benefitting them and their clients." --- Tsu Dho Nimh, NANAE From nobody Thu Nov 6 05:06: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 8C5451A1B48 for ; Thu, 6 Nov 2014 05:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594] 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 Dha5I1WEbNwU for ; Thu, 6 Nov 2014 05:05:56 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6511A19EA for ; Thu, 6 Nov 2014 05:05:38 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6742C475FC; Thu, 6 Nov 2014 13:05:37 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8330B475EC; Thu, 6 Nov 2014 13:05:36 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 79DF62035; Thu, 6 Nov 2014 13:05:36 +0000 (GMT) Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 6 Nov 2014 08:05:18 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 6 Nov 2014 08:05:17 -0500 From: "Salz, Rich" To: Matt Palmer , "trans@ietf.org" Date: Thu, 6 Nov 2014 08:05:17 -0500 Thread-Topic: [Trans] Log servers by Feb 2015? Thread-Index: Ac/5ljqlljxgOC8BROOg8PpWiYr/UgAK6MAw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC2BD@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232@USMBX1.msg.corp.akamai.com> <20141106074904.GA9751@hezmatt.org> In-Reply-To: <20141106074904.GA9751@hezmatt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/H6uMEBWSSvi1VismN7dxQqn-phQ Subject: Re: [Trans] Log servers by Feb 2015? 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, 06 Nov 2014 13:06:33 -0000 Thanks Matt (and another private reply I got). My concern is this: what can Akamai do when we get a new EV cert for a cust= omer on February 2? If the SCT's (two) are in the certificate, great. If n= ot, where and how can I get them, to present them to Chrome when asked via = the s_c_t TLS extension? There's probably a better list to ask this question; pointers appreciated. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Thu Nov 6 05:13: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 36A6B1A19EA for ; Thu, 6 Nov 2014 05:13:00 -0800 (PST) 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 0ZVxKXABxc5D for ; Thu, 6 Nov 2014 05:12:56 -0800 (PST) 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 2CFE91A0075 for ; Thu, 6 Nov 2014 05:12:56 -0800 (PST) Received: (qmail 28049 invoked by uid 1000); 6 Nov 2014 13:12:54 -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; Thu, 06 Nov 2014 13:12:54 +0000 Message-ID: <545B73D6.8080304@comodo.com> Date: Thu, 06 Nov 2014 13:12:54 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Salz, Rich" References: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232@USMBX1.msg.corp.akamai.com><20141106074904.GA9751@hezmatt.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC2BD@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC2BD@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ruOUWcaY22pnRcxSkYvpiKEKcTQ Cc: "trans@ietf.org" Subject: Re: [Trans] Log servers by Feb 2015? 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, 06 Nov 2014 13:13:00 -0000 On 06/11/14 13:05, Salz, Rich wrote: > Thanks Matt (and another private reply I got). > > My concern is this: what can Akamai do when we get a new EV cert for a customer on February 2? If the SCT's (two) are in the certificate, great. If not, where and how can I get them, to present them to Chrome when asked via the s_c_t TLS extension? > > There's probably a better list to ask this question; pointers appreciated. Rich, see this list... https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy ...and this page... http://www.chromium.org/Home/chromium-security/certificate-transparency -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Nov 6 07:05:31 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 0DD421A8ACB for ; Thu, 6 Nov 2014 07:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 NWorAg7wWAs9 for ; Thu, 6 Nov 2014 07:05:26 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAA71A8AA8 for ; Thu, 6 Nov 2014 07:05:26 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9F994284CF; Thu, 6 Nov 2014 15:05:25 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 8A73A284C4; Thu, 6 Nov 2014 15:05:25 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 85BED202F; Thu, 6 Nov 2014 15:05:25 +0000 (GMT) Received: from USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 6 Nov 2014 10:05:24 -0500 Received: from USMBX1.msg.corp.akamai.com ([169.254.1.216]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 6 Nov 2014 10:05:24 -0500 From: "Salz, Rich" To: Rob Stradling Date: Thu, 6 Nov 2014 10:05:24 -0500 Thread-Topic: [Trans] Log servers by Feb 2015? Thread-Index: Ac/5w2TjIIM6m+/3R2GqBtI74lirLQADi/9Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC35F@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232@USMBX1.msg.corp.akamai.com><20141106074904.GA9751@hezmatt.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC2BD@USMBX1.msg.corp.akamai.com> <545B73D6.8080304@comodo.com> In-Reply-To: <545B73D6.8080304@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/M-1ZRAd6gdUcMMsuVpEDJdYGnJc Cc: "trans@ietf.org" Subject: Re: [Trans] Log servers by Feb 2015? 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, 06 Nov 2014 15:05:29 -0000 Thanks for the links. The web page, and the PDF policy it contains, is the= main source of my concern. Neither it, nor the email list discussion, has= any info to alleviate that concern. I'll join the list and post there; thanks. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Thu Nov 6 11:48: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 2139A1A1B8F for ; Thu, 6 Nov 2014 11:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.92 X-Spam-Level: X-Spam-Status: No, score=0.92 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, 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 1kEE1U38u1kJ for ; Thu, 6 Nov 2014 11:48:01 -0800 (PST) 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 C913F1A1ACF for ; Thu, 6 Nov 2014 11:48:01 -0800 (PST) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id A1904282E37 for ; Fri, 7 Nov 2014 06:48:00 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 274C9A3F51; Fri, 7 Nov 2014 06:47:59 +1100 (EST) Date: Fri, 7 Nov 2014 06:47:59 +1100 From: Matt Palmer To: "trans@ietf.org" Message-ID: <20141106194759.GB9751@hezmatt.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC232@USMBX1.msg.corp.akamai.com> <20141106074904.GA9751@hezmatt.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC2BD@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D4FFFC2BD@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/pMRqAHntRy7b_6_nzd0c3b62sG0 Subject: Re: [Trans] Log servers by Feb 2015? 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, 06 Nov 2014 19:48:04 -0000 On Thu, Nov 06, 2014 at 08:05:17AM -0500, Salz, Rich wrote: > My concern is this: what can Akamai do when we get a new EV cert for a > customer on February 2? If the SCT's (two) are in the certificate, great. > If not, where and how can I get them, to present them to Chrome when asked > via the s_c_t TLS extension? You can submit the certificate to alpha.ctlogs.org via the /add-cert-chain endpoint, and place the resulting SCT in the TLS extension. Alpha will have passed its three month probationary period in five days time; it will (presumably) be included in Chrome as a trusted log in the next release. > There's probably a better list to ask this question; pointers appreciated. The main certificate-transparency.org list is probably the best place to ask these sorts of questions, being of a more implementation-oriented flavour, but not being particular Chromium-specific (for which ct-policy@chromium.org would be most appropriate). - Matt From nobody Mon Nov 10 07:26:01 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 CCDBA1A9039 for ; Mon, 10 Nov 2014 07:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 oA1ACG9Et1wR for ; Mon, 10 Nov 2014 07:25:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE601A909A for ; Mon, 10 Nov 2014 07:25:57 -0800 (PST) Received: from localhost ([::1]:52721 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xnqqn-0007WX-IP; Mon, 10 Nov 2014 07:25:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Mon, 10 Nov 2014 15:25:53 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/30#comment:1 Message-ID: <067.7eede95d3840aa3bf7c7b8a3657afb64@tools.ietf.org> References: <052.c546d9e078ebdc8abfcfe2d8f6bacd7e@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <052.c546d9e078ebdc8abfcfe2d8f6bacd7e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/chDIpcflMBPN9rnceOtWZnNA0Tg Cc: trans@ietf.org Subject: Re: [Trans] [trans] #30 (rfc6962-bis): Publish MMD as log metadata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 15:25:59 -0000 #30: Publish MMD as log metadata Changes (by eranm@google.com): * status: new => closed * resolution: => duplicate Comment: Good point, I'll do it as a part of issue 24. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: duplicate Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Nov 10 07:41: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 1699D1A90BC for ; Mon, 10 Nov 2014 07:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 hRb3RlvWNiji for ; Mon, 10 Nov 2014 07:41:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E031B1A90C8 for ; Mon, 10 Nov 2014 07:41:42 -0800 (PST) Received: from localhost ([::1]:53249 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xnr66-0005MO-HM; Mon, 10 Nov 2014 07:41:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Mon, 10 Nov 2014 15:41:42 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/24#comment:3 Message-ID: <071.2c34437faa159161150535f6eb3848c7@tools.ietf.org> References: <056.ec296f99c4f067c1c72c883b77925a17@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <056.ec296f99c4f067c1c72c883b77925a17@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/v8nKWznZTY9LM7YWwCRPEQU5DAk Cc: trans@ietf.org Subject: Re: [Trans] [trans] #24 (rfc6962-bis): Add a section about log metadata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 15:41:48 -0000 #24: Add a section about log metadata Comment (by eranm@google.com): MMD should be included in the metadata. Ben also suggested: which browsers is the log included in, start date, whether the log has been turned down or not. -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Fri Nov 14 14:05:28 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 81DAB1ACF08 for ; Fri, 14 Nov 2014 14:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 dZGBBJyfQcGg for ; Fri, 14 Nov 2014 14:04:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7441A1ACF00 for ; Fri, 14 Nov 2014 14:04:57 -0800 (PST) Received: from localhost ([::1]:49307 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XpOz9-00073M-0r; Fri, 14 Nov 2014 14:04:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 14 Nov 2014 22:04:54 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/53 Message-ID: <064.83ec2697decc4b969eea5938a29cce62@tools.ietf.org> X-Trac-Ticket-ID: 53 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hcF6vDrcorawUJ5PXXBtmDnhPsg Cc: trans@ietf.org Subject: [Trans] [trans] #53 (rfc6962-bis): Clarify log entry ordering requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:05:25 -0000 #53: Clarify log entry ordering requirements All but one of the RFC6962 logs that have so far requested inclusion in Chromium seem to list the entries in chronological order. Strict chronological order is nice, but it's not a requirement. As long as each new entry gets included within the log's MMD, all is well. I think it could be worth stating explicitly that strict chronological ordering is not required (for logs) and must not be expected (by clients). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Nov 24 05:54:55 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 96EC21A6F6F for ; Mon, 24 Nov 2014 05:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gNa2ICKy_Fv8 for ; Mon, 24 Nov 2014 05:54:53 -0800 (PST) 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 E17CD1A6F6E for ; Mon, 24 Nov 2014 05:54:52 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:55402 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Xsu6d-0001Kp-NP for trans@ietf.org; Mon, 24 Nov 2014 08:55:07 -0500 Message-ID: <547338AF.6010903@bbn.com> Date: Mon, 24 Nov 2014 08:54:55 -0500 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: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> In-Reply-To: <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> Content-Type: multipart/alternative; boundary="------------070408080103020704020308" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/PidkGFsboE1QCir1GJKf4KhE2Sc Subject: Re: [Trans] Goals and generic mis-issuance fgramework 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, 24 Nov 2014 13:54:54 -0000 This is a multi-part message in MIME format. --------------070408080103020704020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ, Sorry I didn't get to this sooner, vacation, etc. I see that Rick already replied, but for completeness ... > ... > > Can't anyone build the certificate chain? Since the logs are posting > the supported trust anchors, anyone can build a chain for the end > entity certificate. Anyone can build a cert chain that should be accepted by a log, if the chain is "valid" relative to one of the CAs for which the log says it will accept certs. I think this is why Rick suggested that I make the fist sentence of the second paragraph more general, which I have. > ... > > Alternatively, a log could check to see if the reported certificate is > already present, and if so, return the older entry to the party that > reports the certificate. I seem to recall reading this idea at some > point, buy I admit I did not look into the current I-D to see if that > was where i read it. I believe you're correct, i.e., a log may, at its discretion, return the SCT it generated previouslythen if a duplicate cert is submitted. > >> ... > > If the log performs some validation checks, are you suggesting that a > relying party can leverage the work already done by the log? If so, > it puts the log checking at a different place in the certificate > validation than I was imagining. That's not what I meant to imply. I was saying that if an entity submitting a cert to a log asserted the type of cert, then a Monitor and/or a client knows what additional checks it ought to perform, based on the assertion. So, for example, if a client gets a cert that the log entry and SCT say is an S/MIME cert, but the cert has been submitted in a Web PKI context, this might raise an alarm. Also if a log states that it performed syntax checks for the indicated type of cert, and a Monitor or client performs the same checks and gets a different outcome, this should raise doubts about the log. Nonetheless, I guess a client might choose to rely on cert validation by a log, although one should do so only if one has confidence that the log (or a set of logs that all agree the cert was valid) can do a better job than the client. Given experience with some browsers, that might not be a bad idea ;-). Steve --------------070408080103020704020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Russ,

Sorry I didn't get to this sooner, vacation, etc. I see that Rick already replied, but for
completeness ...


...

Can't anyone build the certificate chain?  Since the logs are posting the supported trust anchors, anyone can build a chain for the end entity certificate.
Anyone can build a cert chain that should be accepted by a log, if the chain is "valid" relative to
one of the CAs for which the log says it will accept certs. I think this is why Rick suggested that I
make the fist sentence of the second paragraph more general, which I have.
...

Alternatively, a log could check to see if the reported certificate is already present, and if so, return the older entry to the party that reports the certificate.  I seem to recall reading this idea at some point, buy I admit I did not look into the current I-D to see if that was where i read it.
I believe you're correct, i.e., a log may, at its discretion, return the SCT it generated previouslythen
if a duplicate cert is submitted.

 
...

If the log performs some validation checks, are you suggesting that a relying party can leverage the work already done by the log?  If so, it puts the log checking at a different place in the certificate validation than I was imagining.
That's not what I meant to imply. I was saying that if an entity submitting a cert to a log asserted
the type of cert, then  a Monitor and/or a client knows what additional checks it ought to perform,
based on the assertion. So, for example, if a client gets a cert that the log entry and SCT say is
an S/MIME cert, but the cert has been submitted in a Web PKI context, this might raise an alarm. Also if
a log states that it performed syntax checks for the indicated type of cert, and a Monitor or client
performs the same checks and gets a different outcome, this should raise doubts about the log.

Nonetheless, I guess a client might choose to rely on cert validation by a log, although
one should do so only if one has confidence that the log (or a set of logs that all agree the
cert was valid) can do a better job than the client. Given experience with some browsers, that
might not be a bad idea ;-).

Steve

--------------070408080103020704020308-- From nobody Mon Nov 24 06:03:10 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 510CC1A02BE for ; Mon, 24 Nov 2014 06:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 9BZ13lk0SaNM for ; Mon, 24 Nov 2014 06:03:03 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8341A0222 for ; Mon, 24 Nov 2014 06:03:03 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so6435079lbv.0 for ; Mon, 24 Nov 2014 06:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nxxhKIUCq9BKzHRPSa2gZLJJ3nLII+BFXcvHgT2kDcc=; b=AVmd67MTq88DmP8EoUCtZJh7e7fx2BwrGcT6ASqIdkxqM8had56NezslkuxTX6zW3p KsWBxRvcCi46rp0uF+TzwAcx0xFEVU6tEfRCTTU0heQIUvMWK5UDN+KAcN3b1cp7k1RY eD1jCKKtHgX7JQ+T+4gMEYDfkyR3L6YcEoU9oZ59Jn6TTRBdeatuylQkyhN2Dptp3XAW eFbWm3PpywwvU0wT78mJ7X3T9hEkLycqcomwLW0xmtGHCHt/5kryvqusuiHVLVIkoOyT GxRBkiu8nLBgjW6cBgzayt7sXcSaRIz3E3rB/uao5pcgo9lhhgD9aRlCZrt7Hl9VH4D1 gT9g== MIME-Version: 1.0 X-Received: by 10.112.162.101 with SMTP id xz5mr20306923lbb.49.1416837781725; Mon, 24 Nov 2014 06:03:01 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.34.212 with HTTP; Mon, 24 Nov 2014 06:03:01 -0800 (PST) In-Reply-To: <547338AF.6010903@bbn.com> References: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> <547338AF.6010903@bbn.com> Date: Mon, 24 Nov 2014 09:03:01 -0500 X-Google-Sender-Auth: 7RCoLfhat-pCCLPVWCMXxbmr3T0 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/aXsWwTPkrGI-1igYcTcLIu2jJ24 Cc: "trans@ietf.org" Subject: Re: [Trans] Goals and generic mis-issuance fgramework 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, 24 Nov 2014 14:03:09 -0000 On Mon, Nov 24, 2014 at 8:54 AM, Stephen Kent wrote: > Russ, > Nonetheless, I guess a client might choose to rely on cert validation by a > log, although > one should do so only if one has confidence that the log (or a set of logs > that all agree the > cert was valid) can do a better job than the client. Given experience with > some browsers, that > might not be a bad idea ;-). And so the TRANS notary becomes a trusted critical component rather than a transparent notary whose actions are completely constrained by the Harber-Stornetta block chain... From nobody Mon Nov 24 06:07:13 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 9FE781A024E for ; Mon, 24 Nov 2014 06:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BaKDShj3UmjR for ; Mon, 24 Nov 2014 06:07:05 -0800 (PST) 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 913D31A02BE for ; Mon, 24 Nov 2014 06:07:05 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:49756 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XsuIR-0001ur-Kx for trans@ietf.org; Mon, 24 Nov 2014 09:07:19 -0500 Message-ID: <54733B8B.8030505@bbn.com> Date: Mon, 24 Nov 2014 09:07:07 -0500 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: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> <544B0DD62A64C1448B2DA253C011414607D375BE52@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E81139243728@scygexch10.cygnacom.com> <4262AC0DB9856847A2D00EF817E81139243DF5@scygexch10.cygnacom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/33T6hrJXwjImU6Fr6A4SAKLzpyo Subject: Re: [Trans] Goals and generic mis-issuance fgramework 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, 24 Nov 2014 14:07:11 -0000 Eran, > In that case, how about including the CCID and the results of the > checks the log performed in the get-sth response, but not in the SCT > itself? The SCT will be available to the client (in the cert or as part of a handshake), so the CCID needs to be there for the client to take advantage of it. > The log could still sign the complete get-sth reply so submitters get > a confirmation it is indeed the log which performed the checks, and > TLS clients will not be burdened with handling another field in the > SCT there's no immediate use for. If, as Ben has recently suggested, there are few or no client mandated client checks, then all of the SCT data has no immediate use :-). More to the point, it behooves us to decide on an SCT format that need not change for a while, so as to minimize the impact on clients and Monitors. > As I said, I see the value in getting an "independent opinion" on the > validity of a chain submitted to the log (both in syntactic and > semantic compliance perspectives) and is much more useful than the > current error handling approach (where the log returns a vague error). > I just like to exclude this information from being embedded in the SCT > if it's not useful for TLS clients. I think I've provided a few examples of how it might be used by clients. Steve From nobody Tue Nov 25 11:56:54 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 4C8351A87D5 for ; Tue, 25 Nov 2014 11:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Dda3zyLYfB3C for ; Tue, 25 Nov 2014 11:55:37 -0800 (PST) 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 E5A2F1A6EED for ; Tue, 25 Nov 2014 11:55:36 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:47949 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XtMDH-000DmX-CG; Tue, 25 Nov 2014 14:55:51 -0500 Message-ID: <5474DEB8.6040307@bbn.com> Date: Tue, 25 Nov 2014 14:55:36 -0500 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: Phillip Hallam-Baker References: <5436FC38.1070201@bbn.com> <544B0DD62A64C1448B2DA253C011414607D2BA8687@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <93CB5AEA-4672-48D1-8477-DF5DE3D143CE@vigilsec.com> <547338AF.6010903@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040008080305020209090002" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/lFEYT1hQ_xz4IIM6vOW0rR3ra5s Cc: "trans@ietf.org" Subject: Re: [Trans] Goals and generic mis-issuance fgramework 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, 25 Nov 2014 19:55:39 -0000 This is a multi-part message in MIME format. --------------040008080305020209090002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit PHB, > On Mon, Nov 24, 2014 at 8:54 AM, Stephen Kent wrote: >> Russ, >> Nonetheless, I guess a client might choose to rely on cert validation by a >> log, although >> one should do so only if one has confidence that the log (or a set of logs >> that all agree the >> cert was valid) can do a better job than the client. Given experience with >> some browsers, that >> might not be a bad idea ;-). > And so the TRANS notary becomes a trusted critical component rather > than a transparent notary whose actions are completely constrained by > the Harber-Stornetta block chain... trusted by a client IF it elects to do so. as I said, given the performance of _some_ browsers, this is not necessarily a bad idea, and it would be up to the user to make this decision. Steve --------------040008080305020209090002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit PHB,
On Mon, Nov 24, 2014 at 8:54 AM, Stephen Kent <kent@bbn.com> wrote:

Russ,

Nonetheless, I guess a client might choose to rely on cert validation by a
log, although
one should do so only if one has confidence that the log (or a set of logs
that all agree the
cert was valid) can do a better job than the client. Given experience with
some browsers, that
might not be a bad idea ;-).

And so the TRANS notary becomes a trusted critical component rather
than a transparent notary whose actions are completely constrained by
the Harber-Stornetta block chain...
trusted by a client IF it elects to do so. as I said, given the performance of some browsers, this is not necessarily a bad idea, and it would be up to the user to make this decision.

Steve

--------------040008080305020209090002--