From tadahiko.ito.public@gmail.com Thu Nov 2 05:03:43 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFB713F619 for ; Thu, 2 Nov 2017 05:03:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DpLH_n_uUpLS for ; Thu, 2 Nov 2017 05:03:42 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 7D03C13968C for ; Thu, 2 Nov 2017 05:03:40 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id r196so10577414wmf.2 for ; Thu, 02 Nov 2017 05:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Z5Y3tGCPYKhTPpN2/pnIdTkXQXVI8Q5pmH2ZfaucgYU=; b=SWBbxWq7BKfkCCO27O92zLfMEQBApGf18aK3FcZ8RnlvcqdxL3H3H+zAojJY0DxsUH j/56Psy1VEBgXZ9gbw1m2q80FKjvxG1bshVOdH4lv7gR0tHLBAUf4mUrWxqpIyKGBTkw 53dEuOSuzdHP//WGfhwrdiZIbxqC0LJGe/JcOF6Bjjn5cFZqXN4zd9UBXiDkEMZFb6FI b+R3ann6IeBP1DnhnRbXLCAwAqK9K2x5cWYC9u6gmY+TeqBVF9U9Z8Swo2Fr4doeDIZx HZbrYrmYOB6QTCq2FNTPyamdxWgVGwa7akwedzxD/avVWXGxb5Hq8w7GvihRimg9VDCz tQyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Z5Y3tGCPYKhTPpN2/pnIdTkXQXVI8Q5pmH2ZfaucgYU=; b=VQHgkB1bNBh+fTOYQc67YVkMTilT2+KsEyEAXpUK4yXSz+EOsbgk22EGrTVLMqd+Xh STDNMbl01Zuv0U5F10A6jnstNkTE5UCrBajE09QG2szx2RxLYhA81WEGXLFaULwG/47G BlBfc7YnYWD6zrtsLDvgfq6XEH9HsgZohXYjb1bhlU+3NnuCVnHd9lbp6u/GmVeuL3li yluIzd4WYv/OBm9KzwabQhZt7/AvJLRjlzjs5mSSBVOO3e7GmswUBL5jtWknolSWuX1n 02f0hYtqpxAq/eOCTQ0CwqihxLL4F8ExRgZ4585dHeDLJDFd9N2BsMVFEZc9CGZJcNVg pfPQ== X-Gm-Message-State: AMCzsaV393s2vRqitk5uwmFS6IJ0raT9TGwILmg74pU83cQaeh4E9kZ/ hLv29H94kltuBxuLuJ2bAJ5nw/RwZl3KUwBHu4GWOGIh X-Google-Smtp-Source: ABhQp+RF9cwpFaIZa4JMZ92+CqhFKqlGPUZ1wcbCCvCUB/4mWcQ8THqMUDAWCLiLJNOdcQElSp+7KKOLWAZSmDOJ6pk= X-Received: by 10.80.163.215 with SMTP id t23mr4178669edb.244.1509624218993; Thu, 02 Nov 2017 05:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.152.198 with HTTP; Thu, 2 Nov 2017 05:03:38 -0700 (PDT) From: Tadahiko Ito Date: Thu, 2 Nov 2017 21:03:38 +0900 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary="f403045c2e4c514b0e055cfec739" Archived-At: Subject: [Trans] Request for feedback X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 02 Nov 2017 12:05:35 -0000 --f403045c2e4c514b0e055cfec739 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I am Tadahiko Ito. I wrote my first I-D. < https://www.ietf.org/internet-drafts/draft-ito-yet-another-name-redaction-0= 0.txt > Any feedback is welcome. draft-strad-trans-redaction-01 is discussing about end-user security and raise 3 mechanism for name redaction. On the other hand, I would like to discuss need for =E2=80=9Cuse of technic= ally constrained intermediate=E2=80=9D with aspects of security and scaleability (especially use of technically constrained intermediate with IoT devices). Regards Tadahiko --f403045c2e4c514b0e055cfec739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi

I am Tadahiko Ito.
I wrote my fir= st I-D.
<https://www.ietf.org/internet-drafts/draf= t-ito-yet-another-name-redaction-00.txt>
=C2=A0
Any feedback i= s welcome.

draft-strad-trans-redaction-01 is discussing about e= nd-user security and raise 3 mechanism for name redaction.
On the other = hand, I would like to discuss need for =E2=80=9Cuse of technically constrai= ned intermediate=E2=80=9D with aspects of security and scaleability (especi= ally use of technically constrained intermediate with IoT devices).
Regards Tadahiko

--f403045c2e4c514b0e055cfec739-- From nobody Sat Nov 4 09:30:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BBC13FB71 for ; Sat, 4 Nov 2017 09:30:18 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 p9liSClSyShZ for ; Sat, 4 Nov 2017 09:30:17 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 3DC2A13FB6C for ; Sat, 4 Nov 2017 09:30:17 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA4GSKsK029550; Sat, 4 Nov 2017 16:30:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=W1417V2eZdvo455ZWQis6JPocLripmQ0APx4g90xGxE=; b=gPjJPWjdFfGc6M7oBUxwEkfZKoDtLOYbJsO+UDcvZDJr7ZmB8j3NkcaAbtMTBMn2g6Px 0/dzw5eCZ3rDudj8bz1mF0kAKq2uioQJaYHwuoWoaieb0E++O741ogCTNEQIVEcgxzM0 yf06F1cGu+GqsGHxWiwENgCWomkpVz4k2aq+8J9IQkWiNMKEbhHZHOIUNXwDTxBYIWhb gJq1NTwfwmKR/F0n+E1irrhMN4ht1T3OqsFqPT34+AV3wySG6DNgjso8ocRD3reGDmoj VkUk3bapnY8F9QPbNK1BJxOr7N06X6HtGDhsT20id5F/4ru9z34CSRmLd1nKs8yfMUN8 4g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2e13gg9t1a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 04 Nov 2017 16:30:13 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA4GQ4IR029056; Sat, 4 Nov 2017 12:30:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e18vu0r1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 04 Nov 2017 12:30:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 4 Nov 2017 12:30:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 4 Nov 2017 12:30:11 -0400 From: "Salz, Rich" To: "trans@ietf.org" CC: Harshal Sheth , "Erb, Samuel" , "Houman, Tom" Thread-Topic: A paper on CT Thread-Index: AQHTVYovXWpgOSbUAE+3soY4MT/2eg== Date: Sat, 4 Nov 2017 16:30:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.22] Content-Type: multipart/alternative; boundary="_000_E7E90F8C9C1A43F092D500C33F77F8D6akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711040235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711040236 Archived-At: Subject: [Trans] A paper on CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 04 Nov 2017 16:30:18 -0000 --_000_E7E90F8C9C1A43F092D500C33F77F8D6akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFyc2hhbCBTaGV0aCwgYSBzdHVkZW50IGF0IE1JVCBSZXNlYXJjaCBTY2llbmNlIEluc3RpdHV0 ZSAoaHR0cHM6Ly93d3cuY2VlLm9yZy9yZXNlYXJjaC1zY2llbmNlLWluc3RpdHV0ZSksIHVuZGVy IHRoZSBzcG9uc29yc2hpcCBvZiBTYW0gYW5kIFRvbSBhdCBBa2FtYWksIHdyb3RlIGEgcGFwZXIg b24gY2VydGlmaWNhdGUgdHJhbnNwYXJlbmN5LiAgUXVvdGluZyBmcm9tIHRoZSBzdW1tYXJ5OiDi gJxUaGlzIHBhcGVyIHVzZXMgQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5IHRvIGNvbmR1Y3QgYW4g b3ZlcmFsbCBzdXJ2ZXkgb2YgdGhlIFNTTCBjZXJ0aWZpY2F0ZSBlY29zeXN0ZW0sIGFzIHdlbGwg YXMgaWRlbnRpZmllcyBhIG51bWJlciBvZiBjZXJ0aWZpY2F0ZXMgdGhhdCBhcmUgZWl0aGVyIGNy eXB0b2dyYXBoaWNhbGx5IHdlYWsgb3IgaW4gdmlvbGF0aW9uIG9mIENBIHN0YW5kYXJkcy7igJ0N Cg0KVGhlIHBhcGVyIGlzIGhlcmU6IGh0dHBzOi8vaGFyc2hhbHNoZXRoLmNvbS9jdC5wZGYNCg0K DQo= --_000_E7E90F8C9C1A43F092D500C33F77F8D6akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1D554902BFD3E646AB4062EF79247EFE@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IYXJzaGFsIFNoZXRoLCBhIHN0dWRlbnQg YXQgTUlUIFJlc2VhcmNoIFNjaWVuY2UgSW5zdGl0dXRlICg8YSBocmVmPSJodHRwczovL3d3dy5j ZWUub3JnL3Jlc2VhcmNoLXNjaWVuY2UtaW5zdGl0dXRlKSI+aHR0cHM6Ly93d3cuY2VlLm9yZy9y ZXNlYXJjaC1zY2llbmNlLWluc3RpdHV0ZSk8L2E+LCB1bmRlciB0aGUgc3BvbnNvcnNoaXAgb2Yg U2FtIGFuZCBUb20NCiBhdCBBa2FtYWksIHdyb3RlIGEgcGFwZXIgb24gY2VydGlmaWNhdGUgdHJh bnNwYXJlbmN5LiZuYnNwOyBRdW90aW5nIGZyb20gdGhlIHN1bW1hcnk6IOKAnFRoaXMgcGFwZXIg dXNlcyBDZXJ0aWZpY2F0ZSBUcmFuc3BhcmVuY3kgdG8gY29uZHVjdCBhbiBvdmVyYWxsIHN1cnZl eSBvZiB0aGUgU1NMIGNlcnRpZmljYXRlIGVjb3N5c3RlbSwgYXMgd2VsbCBhcyBpZGVudGlmaWVz IGEgbnVtYmVyIG9mIGNlcnRpZmljYXRlcyB0aGF0IGFyZSBlaXRoZXIgY3J5cHRvZ3JhcGhpY2Fs bHkNCiB3ZWFrIG9yIGluIHZpb2xhdGlvbiBvZiBDQSBzdGFuZGFyZHMu4oCdPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgcGFwZXIgaXMgaGVyZTogPGEgaHJl Zj0iaHR0cHM6Ly9oYXJzaGFsc2hldGguY29tL2N0LnBkZiI+DQpodHRwczovL2hhcnNoYWxzaGV0 aC5jb20vY3QucGRmPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_E7E90F8C9C1A43F092D500C33F77F8D6akamaicom_-- From nobody Sat Nov 4 13:45:31 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DEB13FBDE for ; Sat, 4 Nov 2017 13:45:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1DtsnzJDUR_v for ; Sat, 4 Nov 2017 13:45:28 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 9B9E113FBC5 for ; Sat, 4 Nov 2017 13:45:28 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id a8so4807546pfc.0 for ; Sat, 04 Nov 2017 13:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=xzv1d7Jr5Hunc+pmiD2Tf2yKb1lwSaTucGi43QxzAgo=; b=iLO2kYN8WynUMHQRHawl5mgOMhG2uQcQWuxe89Trh5zqmrSbhhnsJW5xM3/Ti0yJB1 a0jKefP7zn0RswyrO1PlJmcN+kkI1h7jGWhnrkNw0NixypyEEQ0WUxYJyaNQBqUtQQrn xtqO6AmXUrE5o9sbG6Eodzi1wmFLKi7hShZtLe2X7Y53LrEIGsHDZR96UC58bmDpPqIz KRq8Oy0gVGb6tUc2JGhLzOWBBQ9LhFPlU/FQUn8kEros3fbwbJm3xRFMAYNCyupTSuWw 0GxIi1IUVJ8+1R7rQ9JHJdrs/rLCE+sDR6UwpqQx+r27qW9WAXlbhOzyibTctRqz17rY I4bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xzv1d7Jr5Hunc+pmiD2Tf2yKb1lwSaTucGi43QxzAgo=; b=RoAGUckDP8zPVCz/S2D2RK4ZUT1nzOYxy0EvCULU7HBZKqc9dnbo2TotYCCrjRMrk2 UZQxtIhZbTz77R/t5uDTqKiR233iVK+f8R0Uk8SozWj7pBU1akbZWcZBGAZeu27TA0mD 1oU8lx5oLV6ptFlTMODxZoqbTXDGLsYAbRmoVeBuI23OJpNjijmhbI9QbsLe2DbwW4eJ PDw2ae/OymqyWIoL57oOicXF/JGTczvlWxf6T2TVFWD4bTZv02eX0k0QCwCMhkvQ18A5 B8iptdqSE+/U5m3fCLHro7f16UXhw525iZg8CsYXbwgoYEi/H2qVdKtYIhOpe3Koad5q jjLw== X-Gm-Message-State: AMCzsaX7noXtfRvifHrAZEeVx6OkBoXVbNCRG9MZk6/ZLs/pmd6tGKbY F+PvR1ASBKCYsld1AF3/1w/fXw== X-Google-Smtp-Source: ABhQp+QCRQN8fR+vWaNXCtCfmFFwHPAEcqCNYCApk1bo+mtOwCMf6xEksn1nUxmCToJFgWPrfyWCmg== X-Received: by 10.159.240.136 with SMTP id p8mr10424521plr.360.1509828327429; Sat, 04 Nov 2017 13:45:27 -0700 (PDT) Received: from aspen.local (209-112-147-75-radius.dynamic.acsalaska.net. [209.112.147.75]) by smtp.gmail.com with ESMTPSA id c83sm17659278pfk.114.2017.11.04.13.45.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Nov 2017 13:45:26 -0700 (PDT) To: trans@ietf.org References: From: Melinda Shore Message-ID: <93246de3-1081-73e3-2703-8336566caf28@gmail.com> Date: Sat, 4 Nov 2017 12:45:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6gFFo3IjQkfcPOg5etldKRGqip3S84CP0" Archived-At: Subject: Re: [Trans] Request for feedback X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 04 Nov 2017 20:45:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6gFFo3IjQkfcPOg5etldKRGqip3S84CP0 Content-Type: multipart/mixed; boundary="fnXMW3XV4jh79k8ggT4sNT9Ux0XkIPCLJ"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <93246de3-1081-73e3-2703-8336566caf28@gmail.com> Subject: Re: [Trans] Request for feedback References: In-Reply-To: --fnXMW3XV4jh79k8ggT4sNT9Ux0XkIPCLJ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/2/17 4:03 AM, Tadahiko Ito wrote: > draft-strad-trans-redaction-01 is discussing about end-user security an= d > raise 3 mechanism for name redaction. > On the other hand, I would like to discuss need for =E2=80=9Cuse of tec= hnically > constrained intermediate=E2=80=9D with aspects of security and scaleabi= lity > (especially use of technically constrained intermediate with IoT device= s). Hi, all: I'll be getting an agenda out this weekend but note that we'll be allocating time on the agenda at IETF 100 for a redaction discussion, based on https://www.ietf.org/internet-drafts/draft-ito-yet-another-name-redaction= -00.txt. We'd like to get the redaction question resolved (the trans working group will/will not be working on this), so please give the draft a read and post comments to the mailing list. If you'll be in Singapore, please come to the session prepared for a redaction discussion. Many thanks, Melinda --fnXMW3XV4jh79k8ggT4sNT9Ux0XkIPCLJ-- --6gFFo3IjQkfcPOg5etldKRGqip3S84CP0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ/ibkAAoJELiGRpM6HoEucKAQAJEPvSh0BRzuClu7rbPbubcx Iv9NGxuyaOZXrSQJOUE1PTQKZ6IH7wlXHaJGRbqE2CtnXoRf6v2GQfM32PeYuHun 8ka8noY7WDmZX/+R8sVdEQTRgcTRe39t/lAqK00Eb+XpURdFsb9yamlhigAhTFrl eqpQ4U+2wqfoAsVZuEcxtb3sdkX1qTybzypSUVyxn5MtHj4rRZuisT22THIThHaJ 3voYydH2vhtzoisL0l8Y2DCwQEiSwSZcjUDao90cGPBYpA+UVXxlBxm8NOY7g9UH Yhc/S6lIwbndTpSfOYExoZLF8cga7Ms1XLh5JZBdG3vAZihIpVZ2RlGwii9rcEO1 6LFnLHoTJNFCx20ZEb6l2f+PiU/kA9C/tGFTlF4w7/5v1hfOsYPSuUyX83424YP1 hdMSklb2YnHEbSQdGFv62gl4ZQOfCTiUXtiLDo01T71MACP07/e1I9iSJy08omYD pgx7ZavOXGuAw4nap3XNRGeSqpHukT0RKbQCL6TnXdH+bt41adB+NP8EfXzjdQ41 ZksDsCxPObH0U+oiaQ6wDe27rhL4Geh41D0/QDFCxNaRKlPQN+CzbuMR/GeWENWF hGZzXgtYF7RyJn06ijLSEGhdc+ziI3HH/SmztCWfnLf6zOLXbA2L5ZMXIl4dwHwD vqSGOs5KLJvqxdtU+2PK =Gtp8 -----END PGP SIGNATURE----- --6gFFo3IjQkfcPOg5etldKRGqip3S84CP0-- From nobody Sat Nov 4 22:18:53 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9313FB10 for ; Sat, 4 Nov 2017 22:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 sn9ERxxWNPn5 for ; Sat, 4 Nov 2017 22:18:49 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 4097C13FB2E for ; Sat, 4 Nov 2017 22:18:49 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x195so1905095qkb.12 for ; Sat, 04 Nov 2017 22:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3CYQMvaEGXVmQ7DulgXRe69pTjVG6KC03vK1oNJPhlw=; b=2krHju2+sGlYsbJj1WxspD1f0COoqAE3ZeJyMuBI3aihWGMgYrgQ9ZAhsnvgZ5z98r rf9W433OwnrbbI/H0VuC240ejl47BjUWofu+A5cAaVSZV5S8i0AClj6zwP7HSk2m17yF SkJH3z+6ESveDOWNIUSlJIHx4hP/+BBfX8vUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3CYQMvaEGXVmQ7DulgXRe69pTjVG6KC03vK1oNJPhlw=; b=jyMgV7nTcPO/7ptqQvFIj9Oks+B+Y88vpSpopafBFw8ZJc2txa7HkR5bJKqcv3LLqQ 55oJ3kHj29PsrCvdURAhFCkMZMt3ND+0YAiYYJV56J4mFREIRH2QKnBshR7f/aqSRJIO NvIUZq6XDElrodQbZc9CfNz7+H8Qu/ZuWLm2NRkChmmOavYPuPkRNxpmtuHm4ciw2NHS Rj6857UWjNK/Rs/Mp+cc+V9c/r6xY/74y+uKD6wHewHqxgP58nofAYan8D+s6wVIhstI 1njlxvIWBvXFwHoL2dgeAf7NrAG1vNS8IOiDFP8Vw5W7SEtshhQFowT89V9TuCbyRepd WKpQ== X-Gm-Message-State: AJaThX6Mg7FwejT0Kw4PAHxqB1qaCR5J1zoICyXJ4MI0fp22lyquDk6e hmhJ5qXwcfDeULjt26Ke38YERxH3qoDGP763zSBWYMbY X-Google-Smtp-Source: ABhQp+SU3JaCyyK3/fOOl8BhxdIacjEBtiGYOAxbLfGlH46luUGBcjhZdxYXaYVeb2Rt+vqh4zr6YTMFl5y6eyoeP8A= X-Received: by 10.55.65.22 with SMTP id o22mr10505918qka.272.1509859128115; Sat, 04 Nov 2017 22:18:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.53 with HTTP; Sat, 4 Nov 2017 22:18:27 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Sun, 5 Nov 2017 00:18:27 -0500 Message-ID: To: Richard Barnes Cc: Eric Rescorla , Trans , draft-ietf-trans-gossip@tools.ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 05 Nov 2017 05:18:52 -0000 I'm going to cherry pick a single thing to ask about before we try to address everything. On 16 October 2017 at 16:41, Richard Barnes wrote: > As far as SCT feedback, note that the > privacy issues here (around server tracking) are unnecessary to meet the > need here -- only the auditor needs to see the SCTs, not the server. If you > had a way for clients to encrypt SCTs to specific auditors, you would no > longer have an issue with server tracking. > > ... > > 2. Add a through-encryption modality for SCT feedback This is an interesting idea. However, I'm worried it's infeasible because of abuse concerns. A client needs to pass the (encrypted) SCT through a third party to prevent the auditor from knowing who visited a particular site. But the third party has no assurance that the payload is a valid SCT and not garbage, so there's DOS concerns. Even if we waved the crypto magic wand (I would be surprised if there wasn't a crypto primitive for this problem, I didn't search), the third party is essentially opening itself to being given every SCT in the log. Attempts at putting a cap on the data received open the doors to flooding attacks that would fill up any cap before the client can provide its data. Am I thinking about the design the same way you were? Do you think this is a problem, and if so, know how you'd work around it? -tom From nobody Sun Nov 5 17:02:40 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F2313FBFE for ; Sun, 5 Nov 2017 17:02:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xm0-IKTkysll for ; Sun, 5 Nov 2017 17:02:37 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 4B64A13FBF1 for ; Sun, 5 Nov 2017 17:02:37 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id t188so6479001pfd.10 for ; Sun, 05 Nov 2017 17:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=asdwu8ibAYWz2bEmM/nukSayEkBjoejA82xZbdsUIbk=; b=LMVvpFNMZDTKpxZWnoHTnmkzxcU7QQucix3b5A72cCHaBtPhya74oYQO6nCn5jjVS0 /PqsM7CEsvrSrxwiAeciuj6cNvqkUjvBiv6lJx57itlNCqDSJfpoCZHBwZnWfbTCGkC1 v/Lmeo4BsfV6rY5gELLiSHmLwTyQs3qssWH0Npfwk74m6YPDRaQa5EPGtrQN/fsvdDny yZXLKmU/4Fdec93WNTRtR9ieaHagEPABW6x7/5c38+2kTQNgN6lWcUUbhWtUuHWp3uKk LPwwddIdo2YRMcSaV6vKH/CUY6DeDAu8iCpc12ZZxTDQR75dCuni5ZgY5xexRoKf6iwC oV5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=asdwu8ibAYWz2bEmM/nukSayEkBjoejA82xZbdsUIbk=; b=L7tGufHdZq47poWXqTbcFmW4UdIFPuoCVfw2BhMaGhSw1qWTtCavn+UnZSiX75gDDC JkK1VeYrh44IDdFn2jn8X5ThxmXgauNboF17xeuROIJmjUJ4g1o5wPoFejJaj0WhITTO URPHaYkxxGbZEIhtbiGBSnZLnC3ez9EoWutpsNHX32U+REO9eQ/Cc926KB5t2hFbUiIL a1FfCF1KHjfKyZkrJcB4H+3yRZN8rSUmhS7BShdr+L+IK8fdrOz50UIQRUmZ6ntPvQar rQ/G/2U8HmKR9W77QQTs2yOEpKmtg5mcd7UWAOjgCB4Pmz9lACzcTWiS82SjKNX4o11D ULQQ== X-Gm-Message-State: AMCzsaXDP4slGsdvravQikZWFjahK7yVVtLc4WHTdSbO3C/kHQWUXgKL qcsulS19OvCS1k5tWaZGQdUocg== X-Google-Smtp-Source: ABhQp+Q7MO23LyesEa2cTZ/KUb9ClpZ8dUVvHsIhWykVBA9T7d9M7iSmvc2L5kOcYkMT2bSmRD2F3Q== X-Received: by 10.99.127.93 with SMTP id p29mr13664840pgn.15.1509930156143; Sun, 05 Nov 2017 17:02:36 -0800 (PST) Received: from aspen.local (209-112-147-75-radius.dynamic.acsalaska.net. [209.112.147.75]) by smtp.gmail.com with ESMTPSA id u7sm18331553pfh.142.2017.11.05.17.02.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 17:02:35 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: <47889d3e-3e01-83b7-532c-985fd91cce8b@gmail.com> Date: Sun, 5 Nov 2017 16:02:32 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FmUMMr456lmRq6F7OMnHPfu5Fp1dJ43NE" Archived-At: Subject: [Trans] Agenda uploaded X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 01:02:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FmUMMr456lmRq6F7OMnHPfu5Fp1dJ43NE Content-Type: multipart/mixed; boundary="a3iXcfjHrd04DABlgmUqRhEGIC2OOLpOs"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <47889d3e-3e01-83b7-532c-985fd91cce8b@gmail.com> Subject: Agenda uploaded --a3iXcfjHrd04DABlgmUqRhEGIC2OOLpOs Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, all: I've uploaded a first draft of the agenda for our session at IETF 100 - please give it a look and let me know if anything is missing, etc. It's also time to get your slides to me, if you'll have a slot during the session. Many thanks, Melinda --a3iXcfjHrd04DABlgmUqRhEGIC2OOLpOs-- --FmUMMr456lmRq6F7OMnHPfu5Fp1dJ43NE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ/7SpAAoJELiGRpM6HoEuGtcP/1zYO3dIlFQVPOXKoQ6KUjJL ER6gXA156HJ1Opw3QgL8Lg1dnz6VfYLNjG0B5ebI37YO911CF+3kpKPh6ymJ34r0 x1lFu4X3eME7bDGMhsupEv945ynmOaJwtAxL2oMWI5F3Qugkgb6hawTyVG4CLIkn lv9HBwbSiq1ICngNf/fR4i1Zu9i+zjEIa47dbRhTh6IdMD3HfKih8Kt98QIoL0o9 2zD/AIP2MsCEl9uojbqCTwFNcXB44FPga0VRG2/mkm2DI9NrL+BJwNGmTXymokfj mxjIFwCch41BZwARw8CUx9sIwOkc203p8fWr8Z/ArhGvpXQrNN54R7EnBEnmBMSe YqteSGLEyq8e8drZZowGZnQ9025qPNWD/WMlaIS5K99VIKheg71IDjrdI2bh5H13 nGhLCKyI72H2N2KXosMRji6qQ9iT0hNrVpY7MjbWSoWLRsDZBNLStGcXUR6gEd9s cRoBzP4VyxSt3SbtxyHmhzIe3D70r9rmV4Z6TNmToO38lOsYCvk/UuA3JIXxziYO LOWZyJt8RzW1U9XF37wYsN9E3ATzQZ2FB/YdaiQdsFvfogSLnsiVmoH7sAeeekEm ZRoeONVI6QRLtG19p+Wtx3UZtTakwjCbqMnod3f5536vupm2cLCwi/3cYOuqShby jW7/muRWaVhFsy3jHnV+ =qndI -----END PGP SIGNATURE----- --FmUMMr456lmRq6F7OMnHPfu5Fp1dJ43NE-- From nobody Sun Nov 5 19:52:51 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1D113FAE7 for ; Sun, 5 Nov 2017 19:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 iJnsHHObCVER for ; Sun, 5 Nov 2017 19:52:48 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 684E913FAE2 for ; Sun, 5 Nov 2017 19:52:48 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id y9so7304632wrb.2 for ; Sun, 05 Nov 2017 19:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o4jBtmX14MAZf35y/Wjy+3ZT5QNHbwfLCvfE1pqbfWg=; b=MR3alwzMFppE4F7hPES80Ypb9ogkigB4vlLVxrnROAqVAYpNMmkNtOR04+K9I7F24x iizDbMRCssNt9C3+5ZJyn20T2X77d0Xus/4Gi66eVvs5OJz1RRMTc3NgMsHXKA/NBGqF j/VWKzPEQyl6hB8XlzR7T0yfMbDMwEt57wzIzeZ1IbiehvfWgrlWHnFIa/z5bZQ8mxxl u7G+M8xh49aSCBIzGDiqJm8UjFcdQsglc+2hB8YyXpLEMxed6LtuHBd9BSrLF7h1zLOG 4Basf7A+laLry89LuLxnrKkzlNA4dkdooi5xfV3YEOX/PdWhMcBIWNfit7ONrI3Yoq5A uRqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o4jBtmX14MAZf35y/Wjy+3ZT5QNHbwfLCvfE1pqbfWg=; b=JCCPW7ezLew4gUa94vOLHcLQSsdolc6QyIVjIc9vIWeU6YV5YEc0+FNChGQijlDxo2 p/RO2TApuj5AOWlifp05BlWdVJE8GHhNlQM+NzRrT7scPAl5uQpUQ3R95zTwDuiNk27g jk3EkToYtrZ92Vgi420WZJ6OdCJ24mDOGQC9IuQl65zS+BplgVrpp/U1VVUIn22RY3N+ nPR9pHdY4T9lh0ErtIphLoGbih525ONKIX50oNMOHutsZaGTLAtrCHnK7WHZ1DRaVSry J2olBWotcNYqgTcardpQFkaukH8tJTpYUO6dNCmZpHJSt2Z+pB23awfk3Ca9LYfRqO5/ A74A== X-Gm-Message-State: AMCzsaU6KKrqLYaqJINS34LckXMnq99fu3fqXxoDeToXJcvzDiIQwwHv nAJtLu1qe3r63u605ncBD3Zj2GwLbBcWZo/GE+Y5PA== X-Google-Smtp-Source: ABhQp+TzIxCW7PJBWrJXe5BuJnlbjZWvnTKEpUOZ5W2Xo5Oaj5ucCOqXj2sZ9TMn37U8/E9gkHWB2V5szusD/k8H9ZU= X-Received: by 10.223.196.156 with SMTP id m28mr12334939wrf.67.1509940366782; Sun, 05 Nov 2017 19:52:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Sun, 5 Nov 2017 19:52:46 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Sun, 5 Nov 2017 22:52:46 -0500 Message-ID: To: Tom Ritter Cc: Eric Rescorla , Trans , draft-ietf-trans-gossip@tools.ietf.org Content-Type: multipart/alternative; boundary="f403045f548631c669055d48630d" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 03:52:50 -0000 --f403045f548631c669055d48630d Content-Type: text/plain; charset="UTF-8" On Sun, Nov 5, 2017 at 1:18 AM, Tom Ritter wrote: > I'm going to cherry pick a single thing to ask about before we try to > address everything. > > On 16 October 2017 at 16:41, Richard Barnes wrote: > > As far as SCT feedback, note that the > > privacy issues here (around server tracking) are unnecessary to meet the > > need here -- only the auditor needs to see the SCTs, not the server. If > you > > had a way for clients to encrypt SCTs to specific auditors, you would no > > longer have an issue with server tracking. > > > > ... > > > > 2. Add a through-encryption modality for SCT feedback > > This is an interesting idea. However, I'm worried it's infeasible > because of abuse concerns. > > A client needs to pass the (encrypted) SCT through a third party to > prevent the auditor from knowing who visited a particular site. But > the third party has no assurance that the payload is a valid SCT and > not garbage, so there's DOS concerns. Even if we waved the crypto > magic wand (I would be surprised if there wasn't a crypto primitive > for this problem, I didn't search), the third party is essentially > opening itself to being given every SCT in the log. > > Attempts at putting a cap on the data received open the doors to > flooding attacks that would fill up any cap before the client can > provide its data. > > Am I thinking about the design the same way you were? Do you think > this is a problem, and if so, know how you'd work around it? > TBH, I don't think I had considered the DoS issues. Now that you mention it, I'm not sure I really buy the premises of the operational model the document presumes for servers. If I were building a server, why would I not just ship off a batch to the auditor whenever my storage fills up? Assuming that's in the realm of plausible server architectures, now you're relying on the server's altruism to protect the log from DoS, and altruism rarely scales. And even if all the servers are well-behaved, a malefactor can spam the auditor's SCT feedback endpoint directly if he wants to. In other words, the auditor has a DoS problem here regardless of through-encryption. The only question is whether it has to just check signatures or also decrypt; one public-key operation or two. --Richard --f403045f548631c669055d48630d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Nov 5, 2017 at 1:18 AM, Tom Ritter <tom@ritter.vg> w= rote:
I'm going to= cherry pick a single thing to ask about before we try to
address everything.

On 16 October 2017 at 16:41, Richard Barnes <rlb@ipv.sx> wrote:
> As far as SCT feedback, note that the
> privacy issues here (around server tracking) are unnecessary to meet t= he
> need here -- only the auditor needs to see the SCTs, not the server.= =C2=A0 If you
> had a way for clients to encrypt SCTs to specific auditors, you would = no
> longer have an issue with server tracking.
>
> ...
>
> 2. Add a through-encryption modality for SCT feedback

This is an interesting idea. However, I'm worried it's infea= sible
because of abuse concerns.

A client needs to pass the (encrypted) SCT through a third party to
prevent the auditor from knowing who visited a particular site. But
the third party has no assurance that the payload is a valid SCT and
not garbage, so there's DOS concerns. Even if we waved the crypto
magic wand (I would be surprised if there wasn't a crypto primitive
for this problem, I didn't search), the third party is essentially
opening itself to being given every SCT in the log.

Attempts at putting a cap on the data received open the doors to
flooding attacks that would fill up any cap before the client can
provide its data.

Am I thinking about the design the same way you were? Do you think
this is a problem, and if so, know how you'd work around it?

TBH, I don't think I had considered the DoS issues.= =C2=A0 Now that you mention it, I'm not sure I really buy the premises = of the operational model the document presumes for servers.=C2=A0 If I were= building a server, why would I not just ship off a batch to the auditor wh= enever my storage fills up?=C2=A0 Assuming that's in the realm of plaus= ible server architectures, now you're relying on the server's altru= ism to protect the log from DoS, and altruism rarely scales.=C2=A0 And even= if all the servers are well-behaved, a malefactor can spam the auditor'= ;s SCT feedback endpoint directly if he wants to.

<= div>In other words, the auditor has a DoS problem here regardless of throug= h-encryption.=C2=A0 The only question is whether it has to just check signa= tures or also decrypt; one public-key operation or two.

--Richard
=C2=A0

--f403045f548631c669055d48630d-- From nobody Sun Nov 5 21:07:54 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F81313FC0F for ; Sun, 5 Nov 2017 21:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 l13v1hJTZLvG for ; Sun, 5 Nov 2017 21:07:51 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 5681513FAFE for ; Sun, 5 Nov 2017 21:07:51 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id m189so9554907qke.4 for ; Sun, 05 Nov 2017 21:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A7pdouwaJjqxqdh5f9IF50A7ubnM3LUhgtjEul6pOdM=; b=g6lQYedw5gQ3ePizxd05o6kWj/I2T5Ft3di7fb5gMoxH7zfJAR4oY9q4T2aFor813/ TjS/5Rp8bkaPSpFYFx0+4lqmTPONobAyZhjbGeUzSrMjU2/qOlO/UXJUVlNkf/8/gXKu 95c7EbejL/7In0Dnr7jtSGCllQPf2gTEzUfWM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A7pdouwaJjqxqdh5f9IF50A7ubnM3LUhgtjEul6pOdM=; b=fcdOtPvvEbaTv/eLCuHxbMJm8UUEGJhIRL2G9JIa4tvENNk6jukrrxOBZvjCddJ+/Y bFoaexVI3UUGElStAoS2FudYo0ze2N7svZFbKL5zs+VaDJj/9lpXYOgAMxUO4s0Gao6i 7D4WXukZjP0Xlnbn3MmlesTU8iObSzvmaCLD94FJEIk9HkycPix2Ywk+LikTDoJgK45J Ao4Aa9fwmhVBjUyqTqJJp1jzghw2UC8FQOTLBuda1+37X0YPTAVwv/oNLEITuy/3yAfU 3SgIP1Hb2okZdTR1CAREaTXkcrwpxBzGZeDQEta/AA9ndrLyaLs3LQl6eDAd9Io6WNYF Ny9A== X-Gm-Message-State: AMCzsaVQvCJQMMNJ/kiT1b+A4nO1lmuCr6/jIzRu6J9BPtIEHvY+ySQO SdY5jxWLEUV44H34PkaIX30m1NlQe82sGMsgjlBfhQEF X-Google-Smtp-Source: ABhQp+Sg/2Ox9xghYqT2jQfiT/8qjRlEFCFQC6CLaOkCrMomScloPnFyXHsOqdaws92T7RDsBzryAya1IqGj42/Vwl4= X-Received: by 10.55.107.3 with SMTP id g3mr20044381qkc.24.1509944869787; Sun, 05 Nov 2017 21:07:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.108.53 with HTTP; Sun, 5 Nov 2017 21:07:29 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Sun, 5 Nov 2017 23:07:29 -0600 Message-ID: To: Richard Barnes Cc: Eric Rescorla , Trans , draft-ietf-trans-gossip@tools.ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 05:07:53 -0000 On 5 November 2017 at 21:52, Richard Barnes wrote: > > > On Sun, Nov 5, 2017 at 1:18 AM, Tom Ritter wrote: >> >> I'm going to cherry pick a single thing to ask about before we try to >> address everything. >> >> On 16 October 2017 at 16:41, Richard Barnes wrote: >> > As far as SCT feedback, note that the >> > privacy issues here (around server tracking) are unnecessary to meet the >> > need here -- only the auditor needs to see the SCTs, not the server. If >> > you >> > had a way for clients to encrypt SCTs to specific auditors, you would no >> > longer have an issue with server tracking. >> > >> > ... >> > >> > 2. Add a through-encryption modality for SCT feedback >> >> This is an interesting idea. However, I'm worried it's infeasible >> because of abuse concerns. >> >> A client needs to pass the (encrypted) SCT through a third party to >> prevent the auditor from knowing who visited a particular site. But >> the third party has no assurance that the payload is a valid SCT and >> not garbage, so there's DOS concerns. Even if we waved the crypto >> magic wand (I would be surprised if there wasn't a crypto primitive >> for this problem, I didn't search), the third party is essentially >> opening itself to being given every SCT in the log. >> >> Attempts at putting a cap on the data received open the doors to >> flooding attacks that would fill up any cap before the client can >> provide its data. >> >> Am I thinking about the design the same way you were? Do you think >> this is a problem, and if so, know how you'd work around it? > > > TBH, I don't think I had considered the DoS issues. Now that you mention > it, I'm not sure I really buy the premises of the operational model the > document presumes for servers. If I were building a server, why would I not > just ship off a batch to the auditor whenever my storage fills up? You could do that. > Assuming > that's in the realm of plausible server architectures, now you're relying on > the server's altruism to protect the log from DoS, and altruism rarely > scales. The *log* from DOS? Or the auditor? I confess I hadn't really considered DOSing auditors. I think when I was actively working on this doc, auditors hadn't really been implemented yet, and in my mind internet-scale auditors keep a copy of the tree indexable, and immediately discard data they have already seen, so it's 'hard' to DOS them. But that's not how they work today and I don't even know if that's feasible. > And even if all the servers are well-behaved, a malefactor can spam > the auditor's SCT feedback endpoint directly if he wants to. Yes. > In other words, the auditor has a DoS problem here regardless of > through-encryption. The only question is whether it has to just check > signatures or also decrypt; one public-key operation or two. Yes. My point about DOS was not that one could DOS the auditor (you can with or without as you note), but that one could DOS the SCT Feedback server. Without encryption, example.com rejects all cert+SCTs that aren't for example.com and doesn't store them. With encryption, it accepts data for any address on the internet. (And if it sets a storage limit, that's where you run into flooding attacks.) -tom From nobody Mon Nov 6 13:30:53 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FD213FC70 for ; Mon, 6 Nov 2017 13:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 qc4HUOA8zA53 for ; Mon, 6 Nov 2017 13:30:49 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0116.outbound.protection.outlook.com [104.47.0.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343C213FB39 for ; Mon, 6 Nov 2017 13:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xHh96KQpi0+wEtFp1Ul3alrGPIX4ZQqcTo7ImtYsrps=; b=AavAiBW4pGTi8TS+TMSbz15VEz+rh8VJtRRZg5Pjin3mtCWM2mls16+PzBNGBXqbqBkOx9bCbL+RgVpLLO5TVSzhqxaXn9vTn5erz6loJopeKdGtzmAREghLwnVEhwLQ3nO+gRENW54lRTYcvWxtuTtO6EQyaT0AtpaC2L2Hv1c= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1101.eurprd07.prod.outlook.com (10.163.168.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Mon, 6 Nov 2017 21:30:45 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0218.005; Mon, 6 Nov 2017 21:30:44 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "trans@ietf.org" CC: Yaron Sheffer , "antonio.pastorperales@telefonica.com" , Diego Lopez , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: STAR & CT coexistence Thread-Index: AQHTV0aAV7AjheL8ZUOOBIUqQvLNtA== Date: Mon, 6 Nov 2017 21:30:44 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [88.109.161.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1101; 6:2I1JDtDyfDptbkn/RSk9sxaaN3/Hd9NQP8Z5EkxDmux89UxPWGlLbRXt2jAkLMKx9ZKHGZtUNrWSyxZAeiYoCvq800SsibYTbLudexPoFzZZudOf0dbCSw/936vfInvvTBKqWG4fQsZvb15zjIs5WZ3alY6pft6FaSJnzNssPjQKmmSzvh/jcFo1KYnpcQKZxjbutamKJPYL18ehuybzVLFO4wkd9gUwkdbtqHSYKeZJfKUbqmfeRQtV81hoWNT6i7ci7l6CCof3lRo6svkcDk3P3RAOYxG9guDFk/yDWmHWoVZxKShHhp+9i1+pqf4QaqPA8Ej4SrNN2TmpKOQv2RuBRHUpd7e1afSwQVeLoDk=; 5:U9+yNDO0Veq7mGXaoifMc40oKXg21+4RGfczlLkBP5q5urPOujemMa4z2IePqs/HNPhpVcmwXV9WPX4jTC9vJo6JAn1hSuNDQs0xcQGUvttWmmlMwH9JiEeWJoebLJc9qMerD2ZSXoqIQiShPHg6TNeWq9miLnX/SUvA5BEuCm0=; 24:itarguQGWSJoZAoQbKZLA+SLZBiTwdg7UJtmCE9cbRio3TB2azJvK2fUbNhE0pMw2p3yI/pe0OCO7LL4YhtuhSnGaoGZf+XQ7ZuyXO7d7hE=; 7:8hNrk9sIpnIr77BrfyqSVaks+1zjikzRU/enj9vppH8qzNeHtbZ2p9hBtsmO284E+3BvhZIF/gqfYAABr2za0h5EF7i88J4D9GrXpW5nz+bDg8/WaW50anC1ph3iI38eUyjrFXw/kAOUiGj2tnULYIxUobQGUlo/l73mAUrWslChLqXUZ3n4NUByI+S32AvTNzqlYfJ7TO6cg2gcDF/aHnZFwtamOBZ14osDI4g8vVLcdSJBFXUOtdOw2R5JeTu7 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(199003)(189002)(53754006)(50986999)(58126008)(66066001)(6436002)(478600001)(68736007)(6506006)(25786009)(316002)(2900100001)(101416001)(54906003)(54356999)(966005)(561944003)(5640700003)(2501003)(81156014)(8676002)(97736004)(1730700003)(14454004)(33656002)(106356001)(81166006)(606006)(102836003)(189998001)(105586002)(4326008)(8936002)(36756003)(83506002)(2351001)(83716003)(107886003)(99286004)(7736002)(5660300001)(82746002)(53936002)(5250100002)(54896002)(2906002)(3660700001)(86362001)(3280700002)(6306002)(3846002)(39060400002)(6512007)(6486002)(6116002)(236005)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1101; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 644f3835-d5eb-469b-dca8-08d5255da375 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603249); SRVR:VI1PR07MB1101; x-ms-traffictypediagnostic: VI1PR07MB1101: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-exchange-antispam-report-test: UriScan:(72170088055959)(120809045254105)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231021)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1101; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1101; x-forefront-prvs: 048396AFA0 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A265D8AB88A04E5D96F7DCD2E39D7063nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 644f3835-d5eb-469b-dca8-08d5255da375 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 21:30:44.5358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1101 Archived-At: Subject: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 21:30:51 -0000 --_000_A265D8AB88A04E5D96F7DCD2E39D7063nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZXZlcnlib2R5LA0KDQoNCg0KQ29udGV4dA0KDQpXZSBhcmUgd29ya2luZyBvbiBTVEFSIFsx XSwgYW4gQUNNRSBleHRlbnNpb24gdG8gYWxsb3cgYSBuYW1lIG93bmVyIHRvIG9idGFpbiBhIHN0 cmluZyBvZiBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgdGhhdCBhcmUgYXV0b21hdGljYWxseSBy ZW5ld2VkIGJ5IHRoZSBpc3N1aW5nIENBLg0KDQpVc2luZyBTVEFSLCB0aGUgbmFtZSBvd25lciBj b250cm9scyB0aGUgbGlmZXRpbWUgb2YgdGhlIHJlbmV3YWwgcHJvY2Vzcywgd2hpY2ggY2FuIGNv bnRpbnVlIGZvciBhcyBsb25nIGFzIGluaXRpYWxseSBhZ3JlZWQsIG9yIHByZW1hdHVyZWx5IGNv bWUgdG8gYSBoYWx0IGR1ZSB0bywgZS5nLiwgYSBrZXkgY29tcHJvbWlzZS4NCg0KU1RBUiByZW1v dmVzIHRoZSBkZXBlbmRlbmN5IG9uIHRoZSByZXZvY2F0aW9uIGluZnJhc3RydWN0dXJlLCB3aGls ZSBhdCB0aGUgc2FtZSB0aW1lIGF1dG9tYXRpbmcgKGFuZCBtaW5pbWl6aW5nKSB0aGUgaW50ZXJh Y3Rpb24gb2YgdGhlIGNlcnRpZmljYXRlIG93bmVyIHdpdGggaGVyIFJBL0NBLg0KDQpTbyBmYXIg c28gZ29vZC4NCg0KDQoNClNUQVIgKyBDVA0KDQpPYnZpb3VzbHksIHdl4oCZZCB3YW50IFNUQVIg dG8gd29yayB3ZWxsIHdpdGggQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5Lg0KDQpIb3dldmVyLCBp dCBsb29rcyBsaWtlIHRoaXMgbWlnaHQgbm90IGJlIGFzIGVhc3kgYXMgd2Ugd2FudCBpdCB0byBi ZSBiZWNhdXNlIG9mIHRoZSBpbmNyZWFzZSBvZiB0aGUgaW5nZXN0aW9uIHJhdGUgYW5kIGNvbnNl cXVlbnQgaW1wbGljYXRpb25zIG9uIGxvZyBzdHJ1Y3R1cmUsIGltcGxlbWVudGF0aW9uLCByb3Rh dGlvbiwgbW9uaXRvcmluZywgZXRjLg0KDQpXaGF0IHdlIHdlcmUgdGhpbmtpbmcsIHRob3VnaCDi gJMgYW5kIHRoaXMgaXMgd2hlcmUgd2XigJlkIG5lZWQgeW91ciBoZWxwLCBzaW5jZSBub25lIG9m IHVzIGlzIGEgQ1QgZXhwZXJ0IOKAkyBpcyB0aGF0IGEgU1RBUiBjZXJ0aWZpY2F0ZSwgZXhjZXB0 IGluIHRoZSBkZWdlbmVyYXRlIGNhc2Ugd2hlcmUgdXNlcnMgcmVxdWVzdHMgYSB2ZXJ5IGxvdyBu dW1iZXIgb2YgcmVuZXdhbHMsIGNhbiBiZSB0aG91Z2h0IG9mIGFzIGEgc2luZ2xlIOKAnHVzdWFs 4oCdIGNlcnRpZmljYXRlIHRoYXQgaXMgbWFkZSBvZiBhIGNvbGxlY3Rpb24gb2Ygc2FtZSBzaG9y dC1saXZlZCBjZXJ0aWZpY2F0ZXMgdGhhdCBkaWZmZXIgb25seSBmb3IgdGhlaXIgKHNsaWRpbmcp IHZhbGlkaXR5IHdpbmRvd3MuDQoNCklmIHNvLCBpdCBzZWVtcyAoYXQgbGVhc3QgdGhlb3JldGlj YWxseSkgcG9zc2libGUgdG8gdHJlYXQgYWxsIG9mIHRoZW0gYXMgYSBzaW5nbGUgZW50aXR5IGZy b20gYSBDVCBsb2cgcGVyc3BlY3RpdmU/DQoNCg0KDQpBIGZhbGwgYmFjazogdGhlIOKAnENlcnRp ZmljYXRlIFRyYW5zcGFyZW5jeSB3aXRoIFByaXZhY3nigJ0gcHJvcG9zYWwNCg0KSW4gY2FzZSB0 aGUgYWJvdmUgaHlwb3RoZXNpcyBkb2VzbuKAmXQgaG9sZCB0cnVlOg0KDQpBIGZldyB3ZWVrcyBh Z28sIHdlIGdvdCBpbiB0b3VjaCB3aXRoIEVyYW4gYmVjYXVzZSBvZiBoaXMgcmVjZW50IFBFVFMg cGFwZXIgaW4gd2hpY2ggaGUgc2tldGNoZXMgYSBtZWNoYW5pc20gZm9yIGRlYWxpbmcgd2l0aCBz aG9ydC1saXZlZCBjZXJ0cyBpbiB0aGUgY29udGV4dCBvZiBDVCAoc2VjdGlvbiA0IG9mIFsyXSku DQoNClVuZm9ydHVuYXRlbHksIGhlIHRvbGQgdXMgdGhhdCBoZSB3YXNu4oCZdCB3b3JraW5nIG9u IENUIGFueW1vcmUgYW5kIHRoZXJlZm9yZSBoZSB3b3VsZCBub3QgcHJvZ3Jlc3MgdGhvc2UgaWRl YXMgZnVydGhlci4gIFdvdWxkIGFueSBvZiB5b3UgYmUgaW50ZXJlc3RlZCBpbiB0YWtpbmcgb3Zl ciBmcm9tIGhpbSBhbmQgbWF5YmUgYnJpbmcgaXQgdG8gc3RhbmRhcmRpemF0aW9uPw0KDQoNCg0K Q2hlZXJzLCB0aGFua3MgdmVyeSBtdWNoLA0KDQoNCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNtZS1zdGFyLw0KDQpbMl0gaHR0cHM6Ly9wZXRzeW1w b3NpdW0ub3JnLzIwMTcvcGFwZXJzL2lzc3VlNC9wYXBlcjY5LTIwMTctNC1zb3VyY2UucGRmDQoN Cg0KDQpQUzogQXQgbGVhc3QgdHdvIG9mIHVzIHdpbGwgYmUgaW4gU2luZ2Fwb3JlOiBpZiBhbnkg b2YgeW91IHdvdWxkIGxpa2UgdG8gaGF2ZSBhIGYyZiBkaXNjdXNzaW9uLCB3ZeKAmWQgYmUgbW9y ZSB0aGFuIGhhcHB5IHRvLg0K --_000_A265D8AB88A04E5D96F7DCD2E39D7063nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <79FF4ECAA4567B4B9BC54AE5510FDF1E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBs aS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q29u c29sYXM7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0I7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0 eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj5IaSBldmVyeWJvZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Q29udGV4dDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSI+V2UgYXJlIHdvcmtpbmcgb24gU1RBUiBbMV0sIGFuIEFDTUUg ZXh0ZW5zaW9uIHRvIGFsbG93IGEgbmFtZSBvd25lciB0byBvYnRhaW4gYSBzdHJpbmcgb2Ygc2hv cnQtbGl2ZWQgY2VydGlmaWNhdGVzIHRoYXQgYXJlIGF1dG9tYXRpY2FsbHkgcmVuZXdlZCBieSB0 aGUgaXNzdWluZyBDQS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VXNpbmcgU1RBUiwgdGhlIG5hbWUg b3duZXIgY29udHJvbHMgdGhlIGxpZmV0aW1lIG9mIHRoZSByZW5ld2FsIHByb2Nlc3MsIHdoaWNo IGNhbiBjb250aW51ZSBmb3IgYXMgbG9uZyBhcyBpbml0aWFsbHkgYWdyZWVkLCBvciBwcmVtYXR1 cmVseSBjb21lIHRvIGEgaGFsdCBkdWUgdG8sIGUuZy4sIGEga2V5IGNvbXByb21pc2UuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPlNUQVIgcmVtb3ZlcyB0aGUgZGVwZW5kZW5jeSBvbiB0aGUgcmV2b2Nh dGlvbiBpbmZyYXN0cnVjdHVyZSwgd2hpbGUgYXQgdGhlIHNhbWUgdGltZSBhdXRvbWF0aW5nIChh bmQgbWluaW1pemluZykgdGhlIGludGVyYWN0aW9uIG9mIHRoZSBjZXJ0aWZpY2F0ZSBvd25lciB3 aXRoIGhlciBSQS9DQS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+U28gZmFyIHNvIGdvb2QuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5TVEFSICYjNDM7 IENUPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5PYnZpb3VzbHksIHdl4oCZZCB3YW50IFNUQVIg dG8gd29yayB3ZWxsIHdpdGggQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5Ljwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj5Ib3dldmVyLCBpdCBsb29rcyBsaWtlIHRoaXMgbWlnaHQgbm90IGJlIGFzIGVhc3kg YXMgd2Ugd2FudCBpdCB0byBiZSBiZWNhdXNlIG9mIHRoZSBpbmNyZWFzZSBvZiB0aGUgaW5nZXN0 aW9uIHJhdGUgYW5kIGNvbnNlcXVlbnQgaW1wbGljYXRpb25zIG9uIGxvZyBzdHJ1Y3R1cmUsIGlt cGxlbWVudGF0aW9uLCByb3RhdGlvbiwNCiBtb25pdG9yaW5nLCBldGMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPldoYXQgd2Ugd2VyZSB0aGlua2luZywgdGhvdWdoIOKAkyBhbmQgdGhpcyBpcyB3aGVy ZSB3ZeKAmWQgbmVlZCB5b3VyIGhlbHAsIHNpbmNlIG5vbmUgb2YgdXMgaXMgYSBDVCBleHBlcnQg 4oCTIGlzIHRoYXQgYSBTVEFSIGNlcnRpZmljYXRlLCBleGNlcHQgaW4gdGhlIGRlZ2VuZXJhdGUg Y2FzZSB3aGVyZSB1c2VycyByZXF1ZXN0cyBhDQogdmVyeSBsb3cgbnVtYmVyIG9mIHJlbmV3YWxz LCBjYW4gYmUgdGhvdWdodCBvZiBhcyBhIHNpbmdsZSDigJx1c3VhbOKAnSBjZXJ0aWZpY2F0ZSB0 aGF0IGlzIG1hZGUgb2YgYSBjb2xsZWN0aW9uIG9mJm5ic3A7PGk+c2FtZTwvaT4mbmJzcDtzaG9y dC1saXZlZCBjZXJ0aWZpY2F0ZXMgdGhhdCBkaWZmZXIgb25seSBmb3IgdGhlaXIgKHNsaWRpbmcp IHZhbGlkaXR5IHdpbmRvd3MuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPklmIHNvLCBpdCBzZWVtcyAo YXQgbGVhc3QgdGhlb3JldGljYWxseSkgcG9zc2libGUgdG8gdHJlYXQgYWxsIG9mIHRoZW0gYXMg YSBzaW5nbGUgZW50aXR5IGZyb20gYSBDVCBsb2cgcGVyc3BlY3RpdmU/PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5BIGZhbGwgYmFjazogdGhlIOKA nENlcnRpZmljYXRlIFRyYW5zcGFyZW5jeSB3aXRoIFByaXZhY3nigJ0gcHJvcG9zYWw8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmkiPkluIGNhc2UgdGhlIGFib3ZlIGh5cG90aGVzaXMgZG9lc27igJl0 IGhvbGQgdHJ1ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+QSBmZXcgd2Vla3MgYWdvLCB3ZSBnb3Qg aW4gdG91Y2ggd2l0aCBFcmFuIGJlY2F1c2Ugb2YgaGlzIHJlY2VudCBQRVRTIHBhcGVyIGluIHdo aWNoIGhlIHNrZXRjaGVzIGEgbWVjaGFuaXNtIGZvciBkZWFsaW5nIHdpdGggc2hvcnQtbGl2ZWQg Y2VydHMgaW4gdGhlIGNvbnRleHQgb2YgQ1QgKHNlY3Rpb24gNCBvZiBbMl0pLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpIj5VbmZvcnR1bmF0ZWx5LCBoZSB0b2xkIHVzIHRoYXQgaGUgd2FzbuKAmXQgd29y a2luZyBvbiBDVCBhbnltb3JlIGFuZCB0aGVyZWZvcmUgaGUgd291bGQgbm90IHByb2dyZXNzIHRo b3NlIGlkZWFzIGZ1cnRoZXIuJm5ic3A7IFdvdWxkIGFueSBvZiB5b3UgYmUgaW50ZXJlc3RlZCBp biB0YWtpbmcgb3ZlciBmcm9tIGhpbSBhbmQgbWF5YmUNCiBicmluZyBpdCB0byBzdGFuZGFyZGl6 YXRpb24/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSI+Q2hlZXJzLCB0aGFua3MgdmVyeSBtdWNoLDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hY21lLXN0YXIvIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjbWUtc3Rhci88L2E+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPlsyXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vcGV0c3ltcG9zaXVtLm9y Zy8yMDE3L3BhcGVycy9pc3N1ZTQvcGFwZXI2OS0yMDE3LTQtc291cmNlLnBkZiI+aHR0cHM6Ly9w ZXRzeW1wb3NpdW0ub3JnLzIwMTcvcGFwZXJzL2lzc3VlNC9wYXBlcjY5LTIwMTctNC1zb3VyY2Uu cGRmPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ UFM6IEF0IGxlYXN0IHR3byBvZiB1cyB3aWxsIGJlIGluIFNpbmdhcG9yZTogaWYgYW55IG9mIHlv dSB3b3VsZCBsaWtlIHRvIGhhdmUgYSBmMmYgZGlzY3Vzc2lvbiwgd2XigJlkIGJlIG1vcmUgdGhh biBoYXBweSB0by48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A265D8AB88A04E5D96F7DCD2E39D7063nokiacom_-- From nobody Mon Nov 6 14:36:37 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB5E13FBDE for ; Mon, 6 Nov 2017 14:36:35 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UIKMeA1VzWeI for ; Mon, 6 Nov 2017 14:36:34 -0800 (PST) Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::241]) (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 64B2713FC75 for ; Mon, 6 Nov 2017 14:36:34 -0800 (PST) Received: by mail-ua0-x241.google.com with SMTP id w45so7566555uac.3 for ; Mon, 06 Nov 2017 14:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UF0dhZHosD9KUgOfczUMC3K8/nEAHHY6SLkqMh1QWNk=; b=NoXUZI20SokZYRrqZkb30JbcS07QXF6SWsntmEMw2l1Zg/x6P2lPDU72lnR9DT+yBB 0ms61Uq60B7RnaM7nbd9FQqlCKDhtEtm4Z7hhGQUvKQ52KzyyhezrRwbMB01LC3v1vlI 2GfUGGGAXcrlRoCAK2SP4y3YVkaQjJTJjSZSfShOgk4c4/aoQD7rqZAjapPH9ir7hkg+ WhlT4M2PlO14KWqI+8q1ZfaMTw530AB/UsO90+OqmLO5LrjHbeFYw0Gj55y4uPkiR2Yf p0nVjl4IWNH7CghQWiUk0D8JpBWtMaPbX2RgT3ehaxKWkSeRJt22hVM6R7jZ9FYvYLS1 LaAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UF0dhZHosD9KUgOfczUMC3K8/nEAHHY6SLkqMh1QWNk=; b=BJOB96cMAexNG4Wz/yxuJjrCyVOjxV0mEZ4VWbfajife/snKoV+Tgq3YDNUcBfEwHr oPOx+tRUMM2llQmdeRu8R4Ae3SM/l+dzza7whN3AghsmHGVINtjOh3Q4u9xBBfS+za+I wb/T1m69BOIihXqnH/O7YsMreJnTXWmWQGOT34W/EP8iMde2ThYUSAwjKRCmFgE9JdN8 ek4swjGCUXEaZZa4RtqVcew6xbyTc/w50wZ6sXrqGhIAEIVL/3O83HJ/RpnYqyfwCN9R ThC9NQdJmT7taZIPTdU/7IaNCf2T1XaCL90KDFuEsoBRMZMWmDhIM6qpEv8cslHy1Eum cTzA== X-Gm-Message-State: AMCzsaV/RzmkqWM/LrLEvnVfn5Z67RZYPtUVmn8BYNh9wzPYaiuEKHmo aeQGPca9H9HXwwHf0qpnOVEVRrLuMqprYDQD7U4= X-Google-Smtp-Source: ABhQp+RI3vZryZjGnz++lFdelFTlrzCQIouGy0k8bEDilDXDArhtfqdFsXArlWXD57tdl20dAg5xZ0YdXXXlPiOYiz8= X-Received: by 10.176.89.205 with SMTP id k13mr13501013uad.5.1510007793242; Mon, 06 Nov 2017 14:36:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.11.132 with HTTP; Mon, 6 Nov 2017 14:36:32 -0800 (PST) In-Reply-To: References: From: Watson Ladd Date: Mon, 6 Nov 2017 14:36:32 -0800 Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: "trans@ietf.org" , "antonio.pastorperales@telefonica.com" , Yaron Sheffer , Diego Lopez Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 06 Nov 2017 22:36:36 -0000 On Mon, Nov 6, 2017 at 1:30 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Hi everybody, > > > > Context > > We are working on STAR [1], an ACME extension to allow a name owner to > obtain a string of short-lived certificates that are automatically renewe= d > by the issuing CA. > > Using STAR, the name owner controls the lifetime of the renewal process, > which can continue for as long as initially agreed, or prematurely come t= o a > halt due to, e.g., a key compromise. > > STAR removes the dependency on the revocation infrastructure, while at th= e > same time automating (and minimizing) the interaction of the certificate > owner with her RA/CA. > > So far so good. > > > > STAR + CT > > Obviously, we=E2=80=99d want STAR to work well with Certificate Transpare= ncy. > > However, it looks like this might not be as easy as we want it to be beca= use > of the increase of the ingestion rate and consequent implications on log > structure, implementation, rotation, monitoring, etc. > > What we were thinking, though =E2=80=93 and this is where we=E2=80=99d ne= ed your help, since > none of us is a CT expert =E2=80=93 is that a STAR certificate, except in= the > degenerate case where users requests a very low number of renewals, can b= e > thought of as a single =E2=80=9Cusual=E2=80=9D certificate that is made o= f a collection of > same short-lived certificates that differ only for their (sliding) validi= ty > windows. We also have work in TLS on short term credentials that can be issued by people with the private keys of certificates. Could this be shoehorned to solve the problems STAR solves without requiring lots of CT entries? --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Nov 6 21:10:05 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58BA13FB2A for ; Mon, 6 Nov 2017 21:10:03 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xli1hRHeL-kh for ; Mon, 6 Nov 2017 21:10:01 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 BE78513FAFC for ; Mon, 6 Nov 2017 21:10:01 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id s2so10104023pge.10 for ; Mon, 06 Nov 2017 21:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to; bh=3c8zWV636G5YRYcgHKGTmY7jmCXkqxkmsvNBw49ZNs8=; b=W0ALv12tqiW2QkYiogZfEXVE//QggT3ksP7+ADw+2Tblp45vzI0a4jw+x4dNuqa/Ci 4fPQr170dUlnf1nAuRXb9B+hhQQWrWUAA88wgGFvy/ARnpp1V/9k3j5tbDQvTUbn1VgA ugdiAPDeahGzwgkgkQRMa2bOhl6OsQhILtQASo4f38p1wMwbcdVLQFuy2PF6s9ppHs0P bEd7aah7vk1ldLo7XKjPmiCbF8lyIzvMahy+Fr/CfOM17WevZ4x+D/4WfKQHsSeV5s1k to15HjoKEd+/rxlVxX4G3QH83knApWyuUf97YK+Cs4TwrCw8w2KBdTGfqrxcxA8uYCY/ A6Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to; bh=3c8zWV636G5YRYcgHKGTmY7jmCXkqxkmsvNBw49ZNs8=; b=Cgj8h+aVFV+vE+M5xEDZx2lDQBefpzUDQVrXwPDL9xCzZbwx5Sv9+eeoHlT5xrEqKt iAtSz9QuTYUilQVDZ7vg/SVpOsz/56kmyxU33wMWau+7GPTDqINgT1kLQ24qOVg83/w3 kEm5IRvUI19TFgqs1mdsCiPAo5F6g5YrnFbdphICOzG3o8LSUxW7L37kIf/vYLJFVjW6 69W/48Ul6YiZylyzV944k8nu010z7MWOGaGbV6QICkuQBbeI0BRZ8krvTgF76yClB9Nr awT7QXLxOxjZfMs4JIw6/jun/myCkzYl/tu98mWVJbo593G8+r2ML8hEy0GEZ+4j81db bmnQ== X-Gm-Message-State: AMCzsaU6I/RGyJtXFB68bZMBTIziPqEciioCP1qH7hM7eoF3bhHg2VqT j5wYUXmet4odcUdkdbQtDyQ= X-Google-Smtp-Source: ABhQp+RD8R8LnnyO1OI06V2X9XleR/Ry/sgeDEz7v3PFuVfJ/CPwxj8YS1m1JiFQMdvqVf8tz3Jmvw== X-Received: by 10.98.213.194 with SMTP id d185mr19473292pfg.107.1510031401118; Mon, 06 Nov 2017 21:10:01 -0800 (PST) Received: from aspen.local (209-112-147-75-radius.dynamic.acsalaska.net. [209.112.147.75]) by smtp.gmail.com with ESMTPSA id m17sm699342pfh.28.2017.11.06.21.09.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 21:10:00 -0800 (PST) To: trans@ietf.org References: From: Melinda Shore Cc: thomas.fossati@nokia.com, watsonbladd@gmail.com Message-ID: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> Date: Mon, 6 Nov 2017 20:09:54 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="llaA8jKljp9FF5e6KGQW7qNT3ToMQ8Q3b" Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 07 Nov 2017 05:10:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --llaA8jKljp9FF5e6KGQW7qNT3ToMQ8Q3b Content-Type: multipart/mixed; boundary="D0MTnx034jMcHBkwpL2wk8eAMCnjlFWut"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Cc: thomas.fossati@nokia.com, watsonbladd@gmail.com Message-ID: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> Subject: Re: [Trans] STAR & CT coexistence References: In-Reply-To: --D0MTnx034jMcHBkwpL2wk8eAMCnjlFWut Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable The question of how to log short-lived certificates is something that's been coming up more frequently recently, and it's independent (mostly) of the issuance mechanism. I think we've got time to discuss it during the session at IETF 100, and it would be helpful if there's a specific proposal to use as a starting point. Will the folks working on this be at the meeting? Melinda --D0MTnx034jMcHBkwpL2wk8eAMCnjlFWut-- --llaA8jKljp9FF5e6KGQW7qNT3ToMQ8Q3b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaAUAjAAoJELiGRpM6HoEuHWgP+wWF4/5cpix4YcXEkUU3PdmY 2WKC1AoJnWZkhGcIPo89MaKXltEg//LKRibm4R+MzxVezGIvoODHz6avLxq8F+xb uvNr8we/Pw6tNK64IrBqBZLWS6u9QzXZRZe++N2dXwT46CMgb+5e+scrJNj4qn9F ZDgy0VxpVLWzlJQIn2sT+sctzio2ADbMNuDOE++QchDOm4aCa/NuEhkzBlSazCHT nlzbtniopw421iblOwXdxuDfkIe4JM692+JH2CNJzAxsRELynSN+kb3mlnMVc4Nu qWD8ovzk9pIcc+u76632V7rsz00aPyTQGFSny/xPE+IGdM+h518Dk1yq66zcvB55 Ywx5glVbZUnaoGy6KYWpMKgyoBzKRLyAL5UnEY6cblAtJ1BLxqKtccIIhs//bJYc RSjxS/HUUnN7WIgIG8JSeYnxF8sHRLs5FcPndSDnNQcEMrx3+oydo9n1okTIxRsT z3ZIgJMuK38qqinWRR3IY4oTZ+04riDb0Nj6Ui3Ds1UrRibYZSQozwBVK3gzProW 2Wz/mnWt/dMUAQBICXKfEmoI6l5dp43UDfYklQJUiV2AkQIhqV/wvopGtA86RYSK 1nLeiP7zBD685XVvy8iA/Rrl/WGGuiKkFl9QANoCottudvRl9HVYhwcNnSaOBkBj URkj38HR0VmK1f8RtSyg =EB5X -----END PGP SIGNATURE----- --llaA8jKljp9FF5e6KGQW7qNT3ToMQ8Q3b-- From nobody Tue Nov 7 16:54:39 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135B3129BF8 for ; Tue, 7 Nov 2017 16:54:39 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 jtUa5OIY5Cd8 for ; Tue, 7 Nov 2017 16:54:36 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 52B6B129B08 for ; Tue, 7 Nov 2017 16:54:36 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id b186so4163498iof.8 for ; Tue, 07 Nov 2017 16:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=adlb4Euvin+lG92B+kSoCAzQ8P2dn+o6RzUX2lk7mQg=; b=PA1RCwaW24qn+o3oDBltq4ZtJ4QmVaAV1eNge++iphD7FWJKA2xZocEybA6jfAWOoB orGUfo9QjOdYvBR1S+X4Ob3m9hgZ4LOk6knEccuyBjZZJVHaihm15Vvgwafm/pU5JsU8 mf7YckJkZQ7a2ko6B258jG+gli9ZPVn19F3CTikiEzF3ERgEhdoClQZUUq6vKyWfFS9h mknocg5Fu3SxKaihGfQHmBIItizfYFPbCagwbw70RVxMWLfrhpgqai6QNzSUwdgt6dW+ ORjrq5Mafm6x5zkfi6NkQvvOj+oGf/4NzxSOw/3m1oc8Ndftsqhd7bUzcQ5zSqmA2NUd h8sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=adlb4Euvin+lG92B+kSoCAzQ8P2dn+o6RzUX2lk7mQg=; b=pLDgprtBSwrEX9SUnqrkCEYagpfoO2ie11T/olvU0ZS+LJUOnTxM0kpky92p6gvLhq 96E43eaBHRmnCS+oJl0AbF2Kfya/tZWdNVrVf1M4Kh2ygF/opvOakjd9K6k/shr+1vlR Mzt5uWBd3cDTuo0v9GVfha6JTMk2swizPoLU6/SGm23VUlTUPRsJYXKNHTQfPXYg/mNx slIbgtqPFkU5n8AgimPOTAah4Gb4iEpjNOAy9iDavRbyR3qcd3yS5aZYebtPIee+XeJs 62j5/eZ40s6eQWVumSywezMyABNxxwVIWc/wIubxH48QOtgj/q4DjVhcvL9dVk+k+h06 hNUg== X-Gm-Message-State: AJaThX6dOcLwCkL2kZmfR4pelaeg6t8QyuQArAVtF+5NylamRGUJbOBT YOcZXrYS1Y9GZdpR55TVqz6mrauhtmVKbxsectQK8w== X-Google-Smtp-Source: AGs4zMaXVz03G1rPRxd+/01KrkbZzAT94viCLw3YNvJ/rVGbI5daKaaKipPrjJjJ202LF/vQIxjkUreRUWHQEjmF9bo= X-Received: by 10.107.84.3 with SMTP id i3mr811754iob.148.1510102475001; Tue, 07 Nov 2017 16:54:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.69.18 with HTTP; Tue, 7 Nov 2017 16:54:04 -0800 (PST) In-Reply-To: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> From: Eran Messeri Date: Tue, 7 Nov 2017 16:54:04 -0800 Message-ID: To: Melinda Shore Cc: "trans@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , watsonbladd@gmail.com Content-Type: multipart/alternative; boundary="94eb2c1b7600996595055d6e21f4" Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 00:54:39 -0000 --94eb2c1b7600996595055d6e21f4 Content-Type: text/plain; charset="UTF-8" One way for a single SCT to be valid for multiple certificates is to omit the fields that change from the data covered by the SCT's signature. For short-lived certificates this would (likely) be the serial number, notBefore and notAfter dates. This means there's no need to re-request an SCT each time a new short-lived certificate is minted, and the SCT covers all key fields in the certificate's TBSCertificate structure (Subject Alternative Names, key, etc). The drawback is that without a serial number (1) it is not possible to verify CAs don't violate the unique serial number requirement (effectively reducing auditing capabilities) (2) mis-issued certificates can't be revoked using the usual means. Note that such a mechanism cannot be implemented either using 6962 or 6962-bis: Both documents mandate that the SCT covers all fields in the TBSCertificate (at least). But, if the design was changed to exclude some fields, it seems to me that this solution would otherwise be compatible with the rest of the CT protocol. On Mon, Nov 6, 2017 at 9:09 PM, Melinda Shore wrote: > The question of how to log short-lived certificates is something > that's been coming up more frequently recently, and it's > independent (mostly) of the issuance mechanism. I think we've > got time to discuss it during the session at IETF 100, and > it would be helpful if there's a specific proposal to use as > a starting point. Will the folks working on this be > at the meeting? > > Melinda > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --94eb2c1b7600996595055d6e21f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One way for a single SCT to be valid for multiple certific= ates is to omit the fields that change from the data covered by the SCT'= ;s signature.
For short-lived certificates this would (likely) be the s= erial number, notBefore and notAfter dates.

This m= eans there's no need to re-request an SCT each time a new short-lived c= ertificate is minted, and the SCT covers all key fields in the certificate&= #39;s TBSCertificate structure (Subject Alternative Names, key,=C2=A0 etc).=
The drawback is that without a serial number (1) it is not possi= ble to verify CAs don't violate the unique serial number requirement (e= ffectively reducing auditing capabilities) (2) mis-issued certificates can&= #39;t be revoked using the usual means.

Note that = such a mechanism cannot be implemented either using 6962 or 6962-bis: Both = documents mandate that the SCT covers all fields in the TBSCertificate (at = least). But, if the design was changed to exclude some fields, it seems to = me that this solution would otherwise be compatible with the rest of the CT= protocol.

On Mon, Nov 6, 2017 at 9:09 PM, Melinda Shore <melinda.shore@gm= ail.com> wrote:
The questio= n of how to log short-lived certificates is something
that's been coming up more frequently recently, and it's
independent (mostly) of the issuance mechanism.=C2=A0 I think we've
got time to discuss it during the session at IETF 100, and
it would be helpful if there's a specific proposal to use as
a starting point.=C2=A0 Will the folks working on this be
at the meeting?

Melinda


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


--94eb2c1b7600996595055d6e21f4-- From nobody Tue Nov 7 17:24:16 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606FE12E03A for ; Tue, 7 Nov 2017 17:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com 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 bXDejBFN8Xxd for ; Tue, 7 Nov 2017 17:24:12 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.9]) (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 5ACC9129C4B for ; Tue, 7 Nov 2017 17:24:12 -0800 (PST) Received: from [216.82.249.212] by server-9.bemta-12.messagelabs.com id E4/4A-02035-BBC520A5; Wed, 08 Nov 2017 01:24:11 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGe2em7YituZQixwpRGyNapAG1ShC j0RjRBKOJLxZcpji2DW0hnSIlPoiKKIJREzSlIrjgRjQ0RuIWINa4gFFjcUWrIq4gGvGh4N7p xe3tO/f/z3ZzWFr1XKZhebeLdzo4m1YWxTwc2+RLvphDGVPelVBpZWVeJq30c78s7VT3HSats rxNNofJPO8NyjPr6wepzGBngFpCG6VWhynfvVpq6a4bXjAwy111fC9VgjZlbEdRLIM/UvCgvV EuBiq8h4KWjtBQcAXB0ebScDCMleEUCNUEGJHVeDFUdLygRaZxHrT0n5BuRywbg3Vw78MMEdU 4CQ6d0RL3XKh9+iySyeDx0FBTKRNZiXMgGPREWIXPIBi8ZhR5GJ4FR7uCkeoIj4RQ+0mKdIqD zpd1EQashq47N2SEY+Fd9w8p8efAzc5KOXkfAzcfb2QIJ0CgrgKJawH2y8G3pW8oWQ9Nu/sQ4 Sz4fvoIRUz7EOxoqaWJoIOt3oCUcDr4Ww8OVc2DC+eO0CQhJIWPnutycXvA8bDzrYm890thc3 8zQ9ZcA1UN/kjnGKyB4N1ytAtN8v6znTecQ+M6BAP3NyJv5Juioa36JUNMOqjf9FNOeAyc7au hCc8Ez5dLMsLjoKqia8hjgN4rn9ABxDagiQLvXMc7k6el6k1Oq9nisnNWW3Jq6hS9nRcEzszb OJOgz823n0bhO9sgkaBz6H1rth+NYiltrHJkCBlVI0z5a4otnGBZ5Sy08YIfxbOsFpTF2ZRRF e3kzbx7rdUWPtbfMrAKrVq5XJSVQgFnF6xmIrWjqWxNc+c3in1d3VtCqxhHvoPXxCnNohWLVk uh40+h34cfQAmaGCWSSCQqRQHvtFtd/+s9KI5F2hjlXrGKwupw/enXEx6FCo/SukwijuLi/kq aEmQ431Nu6Gj1zG+m0v23py+b5FvgyCi6qs8pbks5psvI7XrUmD3NIJQKi74e2nZ5lJCXaLj0 JEryZsPUlReSbs9+tSL988JPvqbece5c7S21IisvkX9RVNR3eH/svtG0b93g9+qHZfcSFE87J rjilz4pzNKn6APzzAPrkyQHGos9k3doGcHCpepop8D9AhsbyLTzAwAA X-Env-Sender: jeremy.rowley@digicert.com X-Msg-Ref: server-16.tower-219.messagelabs.com!1510104250!170642424!1 X-Originating-IP: [216.32.181.176] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14361 invoked from network); 8 Nov 2017 01:24:10 -0000 Received: from mail-by2nam01lp0176.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.176) by server-16.tower-219.messagelabs.com with AES256-SHA256 encrypted SMTP; 8 Nov 2017 01:24:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cYnkNfyneL2n2TqQogePpbUUd/qvLc1i9/QrZkxs+xQ=; b=QFNJxpqlZHXDmvFA1iXPakQFZnCreU45LFNna0C8UtNkeHqirdynT4p+WuDnjNgcrT2OPmXLhO/sWFkS/byElEm/2IN1HA7t1LAtWDUVvHqvgJsy7rBq0ISCGe0OxYrwbkUA+MORrANYExqrE1K0qxX7cqQscICgf7Ru/voIkLM= Received: from BLUPR14MB0339.namprd14.prod.outlook.com (10.163.213.145) by BLUPR14MB0338.namprd14.prod.outlook.com (10.163.213.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Wed, 8 Nov 2017 01:24:08 +0000 Received: from BLUPR14MB0339.namprd14.prod.outlook.com ([10.163.213.145]) by BLUPR14MB0339.namprd14.prod.outlook.com ([10.163.213.145]) with mapi id 15.20.0197.020; Wed, 8 Nov 2017 01:24:08 +0000 From: Jeremy Rowley To: Melinda Shore , "trans@ietf.org" CC: "thomas.fossati@nokia.com" , "watsonbladd@gmail.com" Thread-Topic: [Trans] STAR & CT coexistence Thread-Index: AQHTV0aAV7AjheL8ZUOOBIUqQvLNtKMH8NYAgABt6ACAAVLPYA== Date: Wed, 8 Nov 2017 01:24:08 +0000 Message-ID: References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> In-Reply-To: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [155.64.23.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR14MB0338; 6:xAq4Ql/50gqKYb76iuBUTkjzzaP1f86+PznVbly5tUNaqqivDmyVRo1PYdy2jxG0XI9UG4zZGSlrWxzv0MPKgBcxKPd1Ax70jgU25KCDsAMuvzhwIorJUwZalNMVHvpUsnbk8/ZUBZ+MUCbF9q8BJLCHfb4Z8CQEVvKYG4qIEYjsCaLyyajHMP/V2KGUGvJvphi+NLpZ/agLBJyBmeo1HET+Pworf95/+W4N44AQYhOoBcEKvabjWs2tDrUVIB5Wy69yxSiyryAgG1fFBqWsaeNDN0OqfCNZ+yc/GbeyLuZSlxAYPheLNwM0eN+HPq4RxM84LfGk+YSjQFTDgCXE7lDhJSjZI2s5LqoPnNj5z4E=; 5:N0plcuhJrDSyqllhK+EzBl2zgeipB9EG2kiD6iUqlgGNnf539q4or4z12WamzITC5QU0eY/uGL2PllKR3MDwWSywYhien48LeaEeKmAXqsgmcJffx5iwfl1duDd3Tmr46Hl1a0H4WelsJvbvuarpbPab72UFhdRDVVhhyCsrBtQ=; 24:XBklGVGMaJR7rnnlM2uvhBcykj1k0+SPW6XMkC5maAykOaf8lMc8Zkzd6mCIGAUsCOf8vTyOYYIDpIoV1+1hctKTlZoWhpcGEJZxr1TI0+U=; 7:naoUncJpZstJa5VomLjiGIE+HjJzmItzl+u3iKL042TBg9MuGj8zGCfoMoXHjGEeOv8ojb8vI3Ks56kCHDkXGBLof0fH+E+xjCGAkwY1LH/8qfZYEjzdjLMfdOjBGtfn1Df6xVO0qSzGsa64aF9PPXeCCfo4UT2SaBlXYYTJBxzlNwsRRG2eFjT3ijS5wq+hLko+UBPR2Ji1EZeV1GA+LMdTi4JNd9dW2fotDvi5PRF/fSY6IBorrxbNXGkG0NFc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 84d9d514-f5f1-4bf5-3276-08d5264768b1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR14MB0338; x-ms-traffictypediagnostic: BLUPR14MB0338: x-exchange-antispam-report-test: UriScan:(82608151540597); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231021)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(2016111802025)(20161123562025)(20161123560025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR14MB0338; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR14MB0338; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(13464003)(199003)(86362001)(68736007)(53936002)(110136005)(77096006)(14454004)(101416001)(39060400002)(54356999)(50986999)(76176999)(478600001)(561944003)(54906003)(6506006)(4326008)(229853002)(25786009)(53546010)(6436002)(99936001)(33656002)(66066001)(55016002)(9686003)(316002)(3660700001)(8936002)(3280700002)(5660300001)(2906002)(2501003)(8676002)(7696004)(81166006)(8656006)(2900100001)(81156014)(97736004)(2950100002)(189998001)(74316002)(105586002)(106356001)(3846002)(7736002)(6116002)(102836003)(305945005)(6246003)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR14MB0338; H:BLUPR14MB0339.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_04CD_01D357F5.95F87B10" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84d9d514-f5f1-4bf5-3276-08d5264768b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 01:24:08.2051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR14MB0338 Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 01:24:14 -0000 ------=_NextPart_000_04CD_01D357F5.95F87B10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit We are interested in this. Clint Wilson will be there and happy to help on both sides (as a log operator interested in logging certs through STAR and as a CA interested in implementing STAR). -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Monday, November 6, 2017 10:10 PM To: trans@ietf.org Cc: thomas.fossati@nokia.com; watsonbladd@gmail.com Subject: Re: [Trans] STAR & CT coexistence The question of how to log short-lived certificates is something that's been coming up more frequently recently, and it's independent (mostly) of the issuance mechanism. I think we've got time to discuss it during the session at IETF 100, and it would be helpful if there's a specific proposal to use as a starting point. Will the folks working on this be at the meeting? Melinda ------=_NextPart_000_04CD_01D357F5.95F87B10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD3cw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFZjCCBE6gAwIBAgIQ C4B3By87NWBjv2prStoEyDANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTUxMDEzMDAwMDAwWhcNMTkwMTEwMTIwMDAwWjCBgTEL MAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxDTALBgNVBAcTBExlaGkxETAPBgNVBAoTCERpZ2lD ZXJ0MRYwFAYDVQQDEw1KZXJlbXkgUm93bGV5MSkwJwYJKoZIhvcNAQkBFhpqZXJlbXkucm93bGV5 QGRpZ2ljZXJ0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPJD3aoxfpY1uYfF u5kKTI2hpWfWAy2E7VM3EI5e9b0SODOlkomYlH27ngILqbEJ8b5fActAXcFZl5ziAFL6qRas2YTS HPAxhzPrr14E+PmqEL5/aj5bdOAjeYcxPxhVb6rN53loBn5M6dWeR+kYqjaEzs3Q1sq9PUPBs5tY 1vZU6rF9HMaqKGLZNvaKKtdgb21c9CY4LbeBK3adu207YddQmrpSVA0U9/WCywMIkdG8N3jLvAws rlwMFQ+vFMd91G4GFPbr8hcQYSfN0k/tWsNK+BOomE5UJyrWIxKDcJYn4ZMJuMUvpUB7k4q6SRkR VeNoXZfQLVkCkRrglAS+RHcCAwEAAaOCAfMwggHvMB8GA1UdIwQYMBaAFOcCI4AAT9jXvJQL2T90 OUkyPIp5MB0GA1UdDgQWBBTxLS35I9rcAKGmBG/IIsVlfEFvBzAMBgNVHRMBAf8EAjAAMCUGA1Ud EQQeMByBGmplcmVteS5yb3dsZXlAZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCsuDvp30eNIwYCBZWqJl+9t67A7Jz/zE+8 QPcGn/yvyUqpH4ve9/Pax9CF8cHBBv53uuuMA5quLWfRHxZE9nBr9PorW3AgxE3nrvW6jo+vy214 mI/RAc8kRU3GYoeDQSFRKUxHBCGXxXzVp98g6HGOivcGRWjOFCiwKrJzdMWBCgjZEhbFr9Tpf/Cd 6d+twH/j67MMas3ozImL7ItJxWDxVDG8vdNQq5nv5+MaSCee5i1stvGLITRYqfLCDpgnVSXCfSlO uWJYxeQ9HFshZOMbJSoR8+sdyysKkJqXncVht82CVXGqi7k8mUqmnsMyeavKh/rrJ5pJm/rXBf0g xQ+wMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/ vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG 2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9 CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh 7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCA78wggO7AgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMA0GCWCGSAFlAwQC AQUAoIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDgw MTI0MDFaMC8GCSqGSIb3DQEJBDEiBCC7isqlMn/mLlMlauE35evL2g5VNhP5tKLdb7QAAzGtKTCB iAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkw FwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQg SUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwgYoGCyqGSIb3DQEJEAILMXugeTBlMQswCQYDVQQGEwJV UzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD VQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwgZMGCSqG SIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCG SAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwCwYJYIZIAWUDBAIBMAsGCWCG SAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEAUV0CP1qV3+eW ofNgw9XrMSVQ8mmKFbmWq/xK6vbDU9JUxHAhf5dHLrZhOzjUAErdRZK+oCwM18iPHXguc8xRz3QW 5vwMwlAHEMF0hpKxvriAxcEdglOu6tcwlx/ztX8UDofyAJH53qSBLc+JrjisIjEDb90PHM0Kx17K Wh9KOnQ7IP2e3zFPTjkswSLh3kq8aqxiEADvCPKVpkKCdE9P192eIHSEVNJ7MO27BEJ7xzRIiZOa R2V6ywe3h44hyL5oMsZZZe4V5uhNdq3WlQCI8T+kbdp/mbyDKIGza3yYujxK+s/U5btKNZ3+BMqP F8N5wA1Q/ynzn6FRHH0nC2GF1wAAAAAAAA== ------=_NextPart_000_04CD_01D357F5.95F87B10-- From nobody Wed Nov 8 02:00:17 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7C1318CC for ; Wed, 8 Nov 2017 02:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 Sh_By8o-o2Wb for ; Wed, 8 Nov 2017 02:00:14 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20129.outbound.protection.outlook.com [40.107.2.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2DD131945 for ; Wed, 8 Nov 2017 02:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kDkfyCbkKekfgF6Q6mbDbHnj+R10CZeZ05BxTTPjRyw=; b=FW8xBtYqEdHtfqwMaSEEnAYNEnrHtYtDIvvTfCtXOZvd3ZoROcDXcxKlW0P56YGCjPTFT/bx7nbVMETrrAleTorLHM+PXzpK0JJ8lEVtD45xxJl2M1ccVm7jUVPklhkAUGPOhy3Z90bqqH9JyvqOup0/d3G14AxkTaWV+9P6rvw= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Wed, 8 Nov 2017 10:00:09 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0218.005; Wed, 8 Nov 2017 10:00:09 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Melinda Shore , "trans@ietf.org" CC: "watsonbladd@gmail.com" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Diego Lopez , Yaron Sheffer , "antonio.pastorperales@telefonica.com" Thread-Topic: [Trans] STAR & CT coexistence Thread-Index: AQHTV0aAV7AjheL8ZUOOBIUqQvLNtKMH8NYAgABt6ACAAeNtgA== Date: Wed, 8 Nov 2017 10:00:08 +0000 Message-ID: References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> In-Reply-To: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 6:VsfvA8PUS5K66kTZE/1OJfWb9jPImVmNMqz8Lk2Gc9C1tfVSTyz3Apm0ce+iTMTtlsqb55XVp77auO85Kj1KJwiIq8JabRl/iK1DEEPjiTUDns98ZpysEtAiT4HI4ZyERaJHpSA/TF1eYGos0hu1y5aal1X11Jh3BmZQ6xh12KZlPP1gFAUz6nzPixkvMZzKsoXrw6z6V6dObiXnmDgQ3ztTBFvnrkmjAi46qgAERDH1A3d4PsJJpdVr9nQyK8MoILDGpeDPpxM1gbPK5f1FU/dfzWDFKbnvvx1VywGT0QwUakKjFf3vLIJnMBhQjNCfBfQaiQv2x08NrmRgdy7hmCQap2WEKdwxMuNHNb1UgZE=; 5:BU+xbyo5J/k0VlTTyFd+gRsgQj95dtqWvOkw3kj+UzLKsRfOIJ1F/Ei5vuGXtyEIVmU4Ky03vUBgGBUIdVsnFEgR7XwmTNAD/KlRQ0x9p+c9I3Or7BUsQ0xTZ5Wk/4e3p7NLsy+vLeNxt+dlxtqqqLFj3SNJ8M4vriGFihIUBGs=; 24:wBqgSZCMO8DwvtMPR5l/+V0ZFYNKOSHKaGUDEzzOu2+9D7jsFkLMKbhXltscL054pXCP88SNNUtl1nIcarY5C24pWzsenUyYvEAi6/8hfgM=; 7:lZTKtjifYs3SYwtlHx69wW4yyBmWtmuQkWSiF4zI4orCW0fr1ypUjzLYqXQ+3gi8tF3iUnY2CnYC5a3fbAPZZH/viL/zr8yOX0SPnVtK91j9ebdDg0K1ndXBVZy+pXZuBWHbdQxJnriRSb2j29rxKYaFmpJFwZNhO3dmG7F3O9JqXCFLuLEiCBLhnIMBtUCE5hSVjG5DhzQagQ0Pv8M+98MfvkXq49pxjrPjXziEPgzXb7Sgzq4hvW8HxUcPmW9t x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(199003)(24454002)(189002)(6116002)(3846002)(102836003)(8936002)(33656002)(3280700002)(25786009)(3660700001)(7736002)(2906002)(305945005)(50986999)(76176999)(229853002)(54356999)(6436002)(561944003)(53546010)(189998001)(14454004)(106356001)(105586002)(101416001)(2900100001)(478600001)(6506006)(6486002)(82746002)(97736004)(4326008)(81156014)(2501003)(81166006)(8676002)(68736007)(2950100002)(83716003)(5660300001)(66066001)(53936002)(6246003)(58126008)(110136005)(54906003)(83506002)(5250100002)(316002)(36756003)(39060400002)(99286004)(6512007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: accab2bb-d4d0-45a2-4cf7-08d5268f7ebc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:VI1PR07MB1102; x-ms-traffictypediagnostic: VI1PR07MB1102: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(3231021)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1102; x-forefront-prvs: 0485417665 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <881FA6A5FCCE6D4C9D5659CBB6A37E77@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: accab2bb-d4d0-45a2-4cf7-08d5268f7ebc X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 10:00:09.0147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102 Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 10:00:16 -0000 SGkgTWVsaW5kYSwNCg0KT24gMDcvMTEvMjAxNywgMDU6MDksICJNZWxpbmRhIFNob3JlIiA8bWVs aW5kYS5zaG9yZUBnbWFpbC5jb20+IHdyb3RlOg0KPiBUaGUgcXVlc3Rpb24gb2YgaG93IHRvIGxv ZyBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgaXMgc29tZXRoaW5nDQo+IHRoYXQncyBiZWVuIGNv bWluZyB1cCBtb3JlIGZyZXF1ZW50bHkgcmVjZW50bHksIGFuZCBpdCdzIGluZGVwZW5kZW50DQo+ IChtb3N0bHkpIG9mIHRoZSBpc3N1YW5jZSBtZWNoYW5pc20uICBJIHRoaW5rIHdlJ3ZlIGdvdCB0 aW1lIHRvIGRpc2N1c3MNCj4gaXQgZHVyaW5nIHRoZSBzZXNzaW9uIGF0IElFVEYgMTAwLCBhbmQg aXQgd291bGQgYmUgaGVscGZ1bCBpZiB0aGVyZSdzDQo+IGEgc3BlY2lmaWMgcHJvcG9zYWwgdG8g dXNlIGFzIGEgc3RhcnRpbmcgcG9pbnQuICBXaWxsIHRoZSBmb2xrcw0KPiB3b3JraW5nIG9uIHRo aXMgYmUgYXQgdGhlIG1lZXRpbmc/DQoNCkdyZWF0LCB0aGFua3MuDQoNCldlIGRvbid0IGhhdmUg YW55IHNwZWNpZmljIHByb3Bvc2FsIGF0IHRoaXMgcG9pbnQgaW4gdGltZSwgYnV0IGlmIHdlIGNh bg0KaGF2ZSBhIHNtYWxsIHNsb3QgaW4gdGhlIGFnZW5kYSAoc2F5IDEwbSkgd2UgY291bGQgcHJl c2VudCB0aGUgZ2VuZXJhbA0KcHJvYmxlbSBhbmQgb3VyIGN1cnJlbnQgdGhpbmtpbmcgV1JUIHRo ZSBTVEFSIGFuZCBDVCBjb2V4aXN0ZW5jZT8NCg0KSWRlYWxseSwgdGhhdCB3b3VsZCB0cmlnZ2Vy IHRoZSByZWxldmFudCBjb252ZXJzYXRpb24gd2hlcmUgeW91IGZvbGtzDQp0ZWxsIHVzIGlmIGFu ZCBob3cgdGhpcyBjYW4gYmUgc29sdmVkIDotKQ0KDQpDaGVlcnMNCg0K From nobody Wed Nov 8 02:04:41 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B269B131936 for ; Wed, 8 Nov 2017 02:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 z_f6SdOIBsYl for ; Wed, 8 Nov 2017 02:04:33 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20112.outbound.protection.outlook.com [40.107.2.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEFD13192E for ; Wed, 8 Nov 2017 02:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2spyg4kiWe6O4cOfVrpztrJfjQLY50/g6I4x1UU1Pr4=; b=RTITNHvE/2nfBjBXd1xTnzlX9E8GqvVb+vKH6mix/tK+5vjgpFuoMUMXolawRZtKctIvSnniGCiXnQ4ld9uz5gptJKN27FgTeSkvz3vWCFyKV11bYtltPnRoNwC8/n7lv4/diM009R88BI87bcZCeIKwN9j6HFfahC32FuqpGKc= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Wed, 8 Nov 2017 10:04:29 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0218.005; Wed, 8 Nov 2017 10:04:29 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Eran Messeri , Melinda Shore CC: "trans@ietf.org" , "watsonbladd@gmail.com" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Trans] STAR & CT coexistence Thread-Index: AQHTV0aAV7AjheL8ZUOOBIUqQvLNtKMH8NYAgABt6ACAAUraAIAAmcmA Date: Wed, 8 Nov 2017 10:04:28 +0000 Message-ID: References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 6:cS0E8BIxagQqDvqpWuqfoyC56USiCp+fxk66k3QBkThoDxRNr5AlCpMoUdFwxaZgwcm0KVAeKI6cS5fzQ9V8OEXkN7+RTS0iTmmAxLhP9umpN7+6LIjOlA2og4mlZV+R4Hkh7NyhTQjgfxi5DiZkKZt01pK9NYmKznYjJPq+D+VSbRhE1F4cEMJSQzt1xlPi0HSD25MYxQH1ciiMeyGff0nH/yLChu7J9DtazWgkVzC81cSOtA5x8X2DWyDmbIlItUJ9kl4Q81YgS/Aprm7UwjN2evfFlVWAP9p/LPvITGg8h2iOv/l9C2FqWmcKOC6s1VVKl53BCj7TpZcr2rHZWCSVQ1L2jUjxAKqBPSJ6jYg=; 5:V7k1RK4UF155LfbSN3Q6hHRQuWDe7P6DplXXqWhl1mrv7p10I5lJZJmaDZt6osiOMBsIaWwuV3TspDLv2vm/RHx47qYFDJiYq1d8V69U37v+sGe9JJbxwiuIQDaG1WLziMo6TOvqMydwx3C0eqAoXQPWlX5TJtV3W6oUjtFvKoA=; 24:5aAWwWlNPxaULJXwTD0wCX/ZyBMOLiIWfMchS+TZJLHGb0ikZuK7zOoTAP9zSQVzprdb0lLZMR/6kDICVF6PgG56ckrdx9f7bTHNjXMPkYs=; 7:L3GBGHV4JWgXy7g+QFqJpeNV68NEq55n/hfleP939Wjs+WjP7J3Tkk7UBrFuF1lECXV40apQEgIl8PVFdqEk/muRg75lFQ/3BdHmHtglI/Nnp6nQ20zYqiNeFj3hDOVLdGllybuNy6JT0zPllib00AFb93p4g3tNcYzZV4els5cJSERVr1yvArJxGM5aqvQiqeoFyvb+OpDsj+83zkQYiA0qxQiBBkP9G9WkUEC7fq16U0Yi9t7b+HvYv7bDtaCt x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(199003)(24454002)(40224003)(189002)(6116002)(34040400001)(3846002)(102836003)(8936002)(33656002)(3280700002)(25786009)(3660700001)(7736002)(2906002)(50986999)(76176999)(229853002)(54356999)(6436002)(561944003)(53546010)(189998001)(93886005)(14454004)(106356001)(966005)(105586002)(101416001)(2900100001)(478600001)(6506006)(606006)(6486002)(82746002)(97736004)(4326008)(81156014)(81166006)(8676002)(68736007)(2950100002)(83716003)(5660300001)(9326002)(66066001)(53936002)(6246003)(107886003)(58126008)(110136005)(54906003)(83506002)(6306002)(54896002)(5250100002)(316002)(36756003)(39060400002)(236005)(99286004)(6512007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 69b2e520-113b-4068-a5da-08d5269019d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:VI1PR07MB1102; x-ms-traffictypediagnostic: VI1PR07MB1102: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(3231021)(920507027)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1102; x-forefront-prvs: 0485417665 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E559BF63DF6D448A90F873325DA6B5BBnokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69b2e520-113b-4068-a5da-08d5269019d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 10:04:28.8981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102 Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 10:04:40 -0000 --_000_E559BF63DF6D448A90F873325DA6B5BBnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJhbiwNCg0KVGhhbmtzIChhZ2FpbikgZm9yIHlvdXIgaW5zaWdodC4NCg0KRG8geW91IHRo aW5rIHdl4oCZZCBuZWVkIGEgNjk2Mi10ZXIgdG8gYWNjb21tb2RhdGUgU1RBUj8gIE9yIGNvdWxk IHdlIHNwZWNpZnkgYSBkaWZmZXJlbnQgU0NUIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBydWxlcyBm b3IgU1RBUi1saWtlIGNlcnRpZmljYXRlcyBpbiB0aGUgZnJhbWV3b3JrIGRlZmluZWQgYnkgNjk2 Mi1iaXM/DQoNCkNoZWVycw0KDQpPbiAwOC8xMS8yMDE3LCAwMDo1NCwgIkVyYW4gTWVzc2VyaSIg PGVyYW5tQGdvb2dsZS5jb208bWFpbHRvOmVyYW5tQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KT25l IHdheSBmb3IgYSBzaW5nbGUgU0NUIHRvIGJlIHZhbGlkIGZvciBtdWx0aXBsZSBjZXJ0aWZpY2F0 ZXMgaXMgdG8gb21pdCB0aGUgZmllbGRzIHRoYXQgY2hhbmdlIGZyb20gdGhlIGRhdGEgY292ZXJl ZCBieSB0aGUgU0NUJ3Mgc2lnbmF0dXJlLg0KRm9yIHNob3J0LWxpdmVkIGNlcnRpZmljYXRlcyB0 aGlzIHdvdWxkIChsaWtlbHkpIGJlIHRoZSBzZXJpYWwgbnVtYmVyLCBub3RCZWZvcmUgYW5kIG5v dEFmdGVyIGRhdGVzLg0KDQpUaGlzIG1lYW5zIHRoZXJlJ3Mgbm8gbmVlZCB0byByZS1yZXF1ZXN0 IGFuIFNDVCBlYWNoIHRpbWUgYSBuZXcgc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGUgaXMgbWludGVk LCBhbmQgdGhlIFNDVCBjb3ZlcnMgYWxsIGtleSBmaWVsZHMgaW4gdGhlIGNlcnRpZmljYXRlJ3Mg VEJTQ2VydGlmaWNhdGUgc3RydWN0dXJlIChTdWJqZWN0IEFsdGVybmF0aXZlIE5hbWVzLCBrZXks ICBldGMpLg0KVGhlIGRyYXdiYWNrIGlzIHRoYXQgd2l0aG91dCBhIHNlcmlhbCBudW1iZXIgKDEp IGl0IGlzIG5vdCBwb3NzaWJsZSB0byB2ZXJpZnkgQ0FzIGRvbid0IHZpb2xhdGUgdGhlIHVuaXF1 ZSBzZXJpYWwgbnVtYmVyIHJlcXVpcmVtZW50IChlZmZlY3RpdmVseSByZWR1Y2luZyBhdWRpdGlu ZyBjYXBhYmlsaXRpZXMpICgyKSBtaXMtaXNzdWVkIGNlcnRpZmljYXRlcyBjYW4ndCBiZSByZXZv a2VkIHVzaW5nIHRoZSB1c3VhbCBtZWFucy4NCg0KTm90ZSB0aGF0IHN1Y2ggYSBtZWNoYW5pc20g Y2Fubm90IGJlIGltcGxlbWVudGVkIGVpdGhlciB1c2luZyA2OTYyIG9yIDY5NjItYmlzOiBCb3Ro IGRvY3VtZW50cyBtYW5kYXRlIHRoYXQgdGhlIFNDVCBjb3ZlcnMgYWxsIGZpZWxkcyBpbiB0aGUg VEJTQ2VydGlmaWNhdGUgKGF0IGxlYXN0KS4gQnV0LCBpZiB0aGUgZGVzaWduIHdhcyBjaGFuZ2Vk IHRvIGV4Y2x1ZGUgc29tZSBmaWVsZHMsIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBzb2x1dGlv biB3b3VsZCBvdGhlcndpc2UgYmUgY29tcGF0aWJsZSB3aXRoIHRoZSByZXN0IG9mIHRoZSBDVCBw cm90b2NvbC4NCg0KT24gTW9uLCBOb3YgNiwgMjAxNyBhdCA5OjA5IFBNLCBNZWxpbmRhIFNob3Jl IDxtZWxpbmRhLnNob3JlQGdtYWlsLmNvbTxtYWlsdG86bWVsaW5kYS5zaG9yZUBnbWFpbC5jb20+ PiB3cm90ZToNClRoZSBxdWVzdGlvbiBvZiBob3cgdG8gbG9nIHNob3J0LWxpdmVkIGNlcnRpZmlj YXRlcyBpcyBzb21ldGhpbmcNCnRoYXQncyBiZWVuIGNvbWluZyB1cCBtb3JlIGZyZXF1ZW50bHkg cmVjZW50bHksIGFuZCBpdCdzDQppbmRlcGVuZGVudCAobW9zdGx5KSBvZiB0aGUgaXNzdWFuY2Ug bWVjaGFuaXNtLiAgSSB0aGluayB3ZSd2ZQ0KZ290IHRpbWUgdG8gZGlzY3VzcyBpdCBkdXJpbmcg dGhlIHNlc3Npb24gYXQgSUVURiAxMDAsIGFuZA0KaXQgd291bGQgYmUgaGVscGZ1bCBpZiB0aGVy ZSdzIGEgc3BlY2lmaWMgcHJvcG9zYWwgdG8gdXNlIGFzDQphIHN0YXJ0aW5nIHBvaW50LiAgV2ls bCB0aGUgZm9sa3Mgd29ya2luZyBvbiB0aGlzIGJlDQphdCB0aGUgbWVldGluZz8NCg0KTWVsaW5k YQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpU cmFucyBtYWlsaW5nIGxpc3QNClRyYW5zQGlldGYub3JnPG1haWx0bzpUcmFuc0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMNCg0K --_000_E559BF63DF6D448A90F873325DA6B5BBnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgRXJhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGFua3MgKGFnYWluKSBmb3IgeW91ciBpbnNpZ2h0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkRvIHlvdSB0aGluayB3ZeKAmWQgbmVlZCBhIDY5NjItdGVyIHRvIGFjY29tbW9kYXRlIFNUQVI/ ICZuYnNwO09yIGNvdWxkIHdlIHNwZWNpZnkgYSBkaWZmZXJlbnQgU0NUIGZvcm1hdCBhbmQgcHJv Y2Vzc2luZyBydWxlcyBmb3IgU1RBUi1saWtlIGNlcnRpZmljYXRlcyBpbiB0aGUgZnJhbWV3b3Jr DQogZGVmaW5lZCBieSA2OTYyLWJpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDA4LzExLzIwMTcsIDAw OjU0LCAmcXVvdDtFcmFuIE1lc3NlcmkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFubUBn b29nbGUuY29tIj5lcmFubUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T25lIHdheSBmb3Ig YSBzaW5nbGUgU0NUIHRvIGJlIHZhbGlkIGZvciBtdWx0aXBsZSBjZXJ0aWZpY2F0ZXMgaXMgdG8g b21pdCB0aGUgZmllbGRzIHRoYXQgY2hhbmdlIGZyb20gdGhlIGRhdGEgY292ZXJlZCBieSB0aGUg U0NUJ3Mgc2lnbmF0dXJlLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Rm9yIHNob3J0LWxpdmVkIGNlcnRpZmlj YXRlcyB0aGlzIHdvdWxkIChsaWtlbHkpIGJlIHRoZSBzZXJpYWwgbnVtYmVyLCBub3RCZWZvcmUg YW5kIG5vdEFmdGVyIGRhdGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5UaGlzIG1lYW5zIHRoZXJlJ3Mgbm8gbmVlZCB0byByZS1yZXF1ZXN0IGFu IFNDVCBlYWNoIHRpbWUgYSBuZXcgc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGUgaXMgbWludGVkLCBh bmQgdGhlIFNDVCBjb3ZlcnMgYWxsIGtleSBmaWVsZHMgaW4gdGhlIGNlcnRpZmljYXRlJ3MgVEJT Q2VydGlmaWNhdGUgc3RydWN0dXJlIChTdWJqZWN0IEFsdGVybmF0aXZlIE5hbWVzLCBrZXksJm5i c3A7DQogZXRjKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZSBkcmF3YmFjayBpcyB0aGF0IHdp dGhvdXQgYSBzZXJpYWwgbnVtYmVyICgxKSBpdCBpcyBub3QgcG9zc2libGUgdG8gdmVyaWZ5IENB cyBkb24ndCB2aW9sYXRlIHRoZSB1bmlxdWUgc2VyaWFsIG51bWJlciByZXF1aXJlbWVudCAoZWZm ZWN0aXZlbHkgcmVkdWNpbmcgYXVkaXRpbmcgY2FwYWJpbGl0aWVzKSAoMikgbWlzLWlzc3VlZCBj ZXJ0aWZpY2F0ZXMgY2FuJ3QNCiBiZSByZXZva2VkIHVzaW5nIHRoZSB1c3VhbCBtZWFucy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Tm90ZSB0aGF0 IHN1Y2ggYSBtZWNoYW5pc20gY2Fubm90IGJlIGltcGxlbWVudGVkIGVpdGhlciB1c2luZyA2OTYy IG9yIDY5NjItYmlzOiBCb3RoIGRvY3VtZW50cyBtYW5kYXRlIHRoYXQgdGhlIFNDVCBjb3ZlcnMg YWxsIGZpZWxkcyBpbiB0aGUgVEJTQ2VydGlmaWNhdGUgKGF0IGxlYXN0KS4gQnV0LCBpZiB0aGUg ZGVzaWduIHdhcyBjaGFuZ2VkIHRvIGV4Y2x1ZGUNCiBzb21lIGZpZWxkcywgaXQgc2VlbXMgdG8g bWUgdGhhdCB0aGlzIHNvbHV0aW9uIHdvdWxkIG90aGVyd2lzZSBiZSBjb21wYXRpYmxlIHdpdGgg dGhlIHJlc3Qgb2YgdGhlIENUIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBNb24sIE5vdiA2LCAyMDE3IGF0IDk6MDkgUE0sIE1l bGluZGEgU2hvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzptZWxpbmRhLnNob3JlQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1lbGluZGEuc2hvcmVAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBw dDttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhlIHF1ZXN0aW9uIG9mIGhvdyB0byBsb2cgc2hvcnQt bGl2ZWQgY2VydGlmaWNhdGVzIGlzIHNvbWV0aGluZzxicj4NCnRoYXQncyBiZWVuIGNvbWluZyB1 cCBtb3JlIGZyZXF1ZW50bHkgcmVjZW50bHksIGFuZCBpdCdzPGJyPg0KaW5kZXBlbmRlbnQgKG1v c3RseSkgb2YgdGhlIGlzc3VhbmNlIG1lY2hhbmlzbS4mbmJzcDsgSSB0aGluayB3ZSd2ZTxicj4N CmdvdCB0aW1lIHRvIGRpc2N1c3MgaXQgZHVyaW5nIHRoZSBzZXNzaW9uIGF0IElFVEYgMTAwLCBh bmQ8YnI+DQppdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHRoZXJlJ3MgYSBzcGVjaWZpYyBwcm9wb3Nh bCB0byB1c2UgYXM8YnI+DQphIHN0YXJ0aW5nIHBvaW50LiZuYnNwOyBXaWxsIHRoZSBmb2xrcyB3 b3JraW5nIG9uIHRoaXMgYmU8YnI+DQphdCB0aGUgbWVldGluZz88YnI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+TWVsaW5kYTwvc3Bhbj48 YnI+DQo8YnI+DQo8L3NwYW4+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpUcmFucyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86VHJhbnNAaWV0Zi5vcmciPlRyYW5zQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW5zPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E559BF63DF6D448A90F873325DA6B5BBnokiacom_-- From nobody Wed Nov 8 06:59:50 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A578A12706D for ; Wed, 8 Nov 2017 06:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 0oXLPNjyeAWP for ; Wed, 8 Nov 2017 06:59:47 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 E61A9126557 for ; Wed, 8 Nov 2017 06:59:46 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id r68so11069929wmr.1 for ; Wed, 08 Nov 2017 06:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e+s1jnkmdOBYNxuBRhb1trqWSFbudVxD+MIakYBkGa0=; b=DsRi4gQcsEwg8u7Ugu+1HMitQjjENEA3ZuRrltYSvIWQ85139ENEo6vNNvDpWlxx4w eudWmUkorbsBS9R56VkmiLkXXHe03V9n5DF1MRlZcUh5fddl/0wvQPBeHJLsah1Ow5co ovd3jNasbKuMh/ew3aniZ8xIDw0ZrtYcYxrs2YxNYmw/3Nllq9eJM/8iBGUCMiCbsSJ7 ONcsCijZn9/QHx4E918OGCSVBIc6KTEJN0AxF4WqOp2RHmljus6J9PU0EJYlPcTa7VEu CW+RQSHaGSHwhqUXl66i66M0T3bqLMZtHlUtWjCUKlKud2SnTfBKC1KEF5xB8eJSmyR4 Z9SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e+s1jnkmdOBYNxuBRhb1trqWSFbudVxD+MIakYBkGa0=; b=Hl6/QYu/A6uvVKgKhXhZVMARMpLEHXMOX1CNARSbe0vGmZNWCUQMmTA5W7Wo0TDwwO xJP99UMLOhDHe20Hpmg672gwVzBBMGWazleq6XgLBG7MYp8YGBAAd7rdi5KwPb0p/Q2E Xkk+Ctrk8hUK1NXQ56IhnpaniIaXh1SiDP+CTbgG0O+SQt9au/xQKynG3cZQfrFTwX7y +LP/tavrSXZ5nBbBzVJRvnWpl5LeLnjpwjXqtob1sVn8pQvt6f4l+lZvtXk5sbkNTjoe +eu2+cv4BfP9842anRAr3GeyKjeDx6+VY31rQbmhMRs9TP3kcpKrKLHNjumn9GWJQQNT fdqQ== X-Gm-Message-State: AJaThX6J4uTHlXXlnGVhpxGdVCnRtyfpjORLzw/AuTHOO1To7isIia3n uxdHUonoSUSZFiiTV/zeQzQcvGPazXV1CrK1C8VPtQ== X-Google-Smtp-Source: ABhQp+RH6xPE4AsDuqzP/G1F89azqk9sJpVZrULQYdcWlp217K5bAWqg1WmYyo2IovO61i+2BqpmGZILognB6cYc+d0= X-Received: by 10.80.142.79 with SMTP id 15mr1034960edx.153.1510153185155; Wed, 08 Nov 2017 06:59:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.162.197 with HTTP; Wed, 8 Nov 2017 06:59:43 -0800 (PST) In-Reply-To: References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> From: Al Cutter Date: Wed, 8 Nov 2017 14:59:43 +0000 Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Eran Messeri , Melinda Shore , "watsonbladd@gmail.com" , "trans@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c199e56293a6a055d79f0f3" Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 14:59:50 -0000 --94eb2c199e56293a6a055d79f0f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I'm a fan of short-lived certs, but I'm not particularly keen on the idea of not logging publicly rooted certs - the point of CT is the discoverability of misissuance after all, and it does seem that having an SCT which could refer to a whole set of "similar" yet unlogged certs is not a great idea, e.g. a scenario where the key is compromised by an entity which can coerce the CA into issuing more "non-logged" certs to cover any period the proud new owner of the key material would like. I'll point out that there does seem to be an underlying premise here that it's simply not possible to log all these short-lived certs, have we considered whether that's actually the case? Back of the envelope: currently, the global issuance rate of certs is < 10 per second on average [90d average growth of Pilot is actually < 5/s]. The overwhelming majority of certificates come from Let's Encrypt, and currently all have a lifetime of 90 days. If we're talking about reducing that cert lifetime to 24h then we're looking at 90x increase, so let's call it 1k/s. Even if we're assuming that every cert must be logged to every Log I think that's achievable by the Trillian-based logs, and I'll coyly mention that I'm aware of one other Log implementation which I'm led to believe is more than capable of sustaining that level of throughput. Were that not the case, it's also not hard to imagine schemes for spreading this load around if need be (e.g. sharding by modulo of cert hash etc., "smart" load-balancing CT proxies, etc. etc.) Log growth to very large sizes can be already be addressed by schemes such as Chrome's Temporal Log Policy which allow Operators to define their Log life-cycle, and CAs, UAs, Monitors, and any other interested entity to build-in support for that life-cycle ahead of time. There might be other concerns of scale elsewhere, but I'm not sure that it's in the logging. Cheers, Al. On Wed, Nov 8, 2017 at 10:04 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Hi Eran, > > > > Thanks (again) for your insight. > > > > Do you think we=E2=80=99d need a 6962-ter to accommodate STAR? Or could = we > specify a different SCT format and processing rules for STAR-like > certificates in the framework defined by 6962-bis? > > > > Cheers > > > > On 08/11/2017, 00:54, "Eran Messeri" wrote: > > > > One way for a single SCT to be valid for multiple certificates is to omit > the fields that change from the data covered by the SCT's signature. > > For short-lived certificates this would (likely) be the serial number, > notBefore and notAfter dates. > > > > This means there's no need to re-request an SCT each time a new > short-lived certificate is minted, and the SCT covers all key fields in t= he > certificate's TBSCertificate structure (Subject Alternative Names, key, > etc). > > The drawback is that without a serial number (1) it is not possible to > verify CAs don't violate the unique serial number requirement (effectivel= y > reducing auditing capabilities) (2) mis-issued certificates can't be > revoked using the usual means. > > > > Note that such a mechanism cannot be implemented either using 6962 or > 6962-bis: Both documents mandate that the SCT covers all fields in the > TBSCertificate (at least). But, if the design was changed to exclude some > fields, it seems to me that this solution would otherwise be compatible > with the rest of the CT protocol. > > > > On Mon, Nov 6, 2017 at 9:09 PM, Melinda Shore > wrote: > > The question of how to log short-lived certificates is something > that's been coming up more frequently recently, and it's > independent (mostly) of the issuance mechanism. I think we've > got time to discuss it during the session at IETF 100, and > it would be helpful if there's a specific proposal to use as > a starting point. Will the folks working on this be > at the meeting? > > 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 > > --94eb2c199e56293a6a055d79f0f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm a fan of short-lived certs,= but I'm not particularly keen on the idea of not logging publicly root= ed certs - the point of CT is the discoverability of misissuance after all,= and it does seem that having an SCT which could refer to a whole set of &q= uot;similar" yet unlogged certs is not a great idea, e.g. a scenario w= here the key is compromised by an entity which can coerce the CA into issui= ng more "non-logged" certs to cover any period the proud new owne= r of the key material would like.

I'll point o= ut that there does seem to be an underlying premise here that it's simp= ly not possible to log all these short-lived certs, have we considered whet= her that's actually the case?
Back of the envelope: currently= , the global issuance rate of certs is < 10 per second on average [90d a= verage growth of Pilot is actually < 5/s]. The overwhelming majority of = certificates come from Let's Encrypt, and currently all have a lifetime= of 90 days.=C2=A0 If we're talking about reducing that cert lifetime t= o 24h then we're looking at 90x increase, so let's call it 1k/s.

Even if we're assuming that every cert must be l= ogged to every Log I think that's achievable by the Trillian-based logs= , and I'll coyly mention that I'm aware of one other Log implementa= tion which I'm led to believe is more than capable of sustaining that l= evel of throughput.=C2=A0 Were that not the case, it's also not hard to= imagine schemes for spreading this load around if need be (e.g. sharding b= y modulo of cert hash etc., "smart" load-balancing CT proxies, et= c. etc.)

Log growth to very large sizes can be alr= eady be addressed by schemes such as Chrome's Temporal Log Policy which= allow Operators to define their Log life-cycle, and CAs, UAs, Monitors, an= d any other interested entity to build-in support for that life-cycle ahead= of time.

There might be other=C2=A0concerns = of scale elsewhere, but I'm not sure that it's in the logging.

Cheers,
Al.

<= div class=3D"gmail_extra">
On Wed, Nov 8, 2017 at= 10:04 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <= ;thomas.fossa= ti@nokia.com> wrote:

H= i Eran,

<= u>=C2=A0

T= hanks (again) for your insight.

<= u>=C2=A0

D= o you think we=E2=80=99d need a 6962-ter to accommodate STAR?=C2=A0 Or coul= d we specify a different SCT format and processing rules for STAR-like cert= ificates in the framework defined by 6962-bis?

<= u>=C2=A0

C= heers

<= u>=C2=A0

On 08/11/2017, 00:54, &qu= ot;Eran Messeri" <eranm@google.com> wrote:

=C2=A0

One way for a single SCT = to be valid for multiple certificates is to omit the fields that change fro= m the data covered by the SCT's signature.

For short-lived certifica= tes this would (likely) be the serial number, notBefore and notAfter dates.=

=C2=A0

This means there's no= need to re-request an SCT each time a new short-lived certificate is minte= d, and the SCT covers all key fields in the certificate's TBSCertificat= e structure (Subject Alternative Names, key,=C2=A0 etc).

The drawback is that with= out a serial number (1) it is not possible to verify CAs don't violate = the unique serial number requirement (effectively reducing auditing capabil= ities) (2) mis-issued certificates can't be revoked using the usual means.

=C2=A0

Note that such a mechanis= m cannot be implemented either using 6962 or 6962-bis: Both documents manda= te that the SCT covers all fields in the TBSCertificate (at least). But, if= the design was changed to exclude some fields, it seems to me that this solution would otherwise be compatib= le with the rest of the CT protocol.

=C2=A0

On Mon, Nov 6, 2017 at 9:= 09 PM, Melinda Shore <melinda.shore@gmail.com> wrote:

The question of how to log short-lived certificates is something
that's been coming up more frequently recently, and it's
independent (mostly) of the issuance mechanism.=C2=A0 I think we've
got time to discuss it during the session at IETF 100, and
it would be helpful if there's a specific proposal to use as
a starting point.=C2=A0 Will the folks working on this be
at the meeting?

Melinda


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

=C2=A0


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


--94eb2c199e56293a6a055d79f0f3-- From nobody Wed Nov 8 13:24:53 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1B124BFA for ; Wed, 8 Nov 2017 13:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 UOo2PhzQdVdK for ; Wed, 8 Nov 2017 13:24:50 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 3D528126DEE for ; Wed, 8 Nov 2017 13:24:50 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id f8so5217136qta.5 for ; Wed, 08 Nov 2017 13:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HoDAFZSFV8audVn0p7hN280JnNEOLm98zCXFn2pB4FY=; b=u6G5Xq5Wu/Iw2EVbnJMhyTMj+uUlUcc/mX/6G68ec0qdqJrVXZLPItXDlSXiliGoq2 bOoqcesdRMV7tfiHmkQ3+l07GA+7EetWYqPUxR753DpZcrO6EES0L/PBJIgKldAV6JQM ExHiD3mKaYiY0QS7LDWetrif9IPMyHgOl9rdo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HoDAFZSFV8audVn0p7hN280JnNEOLm98zCXFn2pB4FY=; b=bFqm2aw79LYWr5vjTHY+SlHgP/viTCJgck5Q/WgaiQDxX6gXb6diMGf4gYxBwO46AB VwYUXvLoDoqKev8/z7ly4n4e4DnooXQZVopfNoyH75PRIVcqYk3jsbxyGvY3e4Wwl3xy h2FdSZDGxt2daQMBZGQ5/2W7uMN57A0NOjcFTS2IxOyJhqACaO+kG3SPIUR424moiQBI RJHxrSvAWCfx61ICFkJJz/n8leaXgtIOPEdl//Q65m0iAnWtaJITDXtFgqQs3OCyD4eg ZCvoq6Sh34LayqdtyuckqGvvopIhwvaQyFpZ8HAess4IgMvn/41XvP/4v8LlpfXeaYb6 I0Og== X-Gm-Message-State: AJaThX6ipnoAPWieaGasJ+SQLmYgFy+tUmw44aYTZg3JfjYVq1uYbfrI BoxgqZcm4BUQclOVu0BhmqLu4OJ9vn2MspiKTU82uQ== X-Google-Smtp-Source: AGs4zMYCVR5H0VXaFYT/Wvpby7XSLEj+huoz6FrWTXQlpd6pFmJwz6ftzqx3ta5KNyh9azbY1we98ifOPF19aTBV71k= X-Received: by 10.200.22.168 with SMTP id r37mr2983443qtj.21.1510176289093; Wed, 08 Nov 2017 13:24:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.108.53 with HTTP; Wed, 8 Nov 2017 13:24:28 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Wed, 8 Nov 2017 15:24:28 -0600 Message-ID: To: Richard Barnes Cc: Eric Rescorla , Trans , draft-ietf-trans-gossip@tools.ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 21:24:52 -0000 We reviewed ekr's and Richard's feedback; thanks for the detailed review. For all (or nearly all) of the non-important issues we believe we can make appropriate changes or address the concerns adequately. We're not sending those right now, just to avoid a deluge of words and things to review on the list. For the important items: IMPORTANT: I don't understand what this means from an HTTP perspective... We believe we can explain this adequately along with the non-important items. IMPORTANT: Neither of these mechanisms is generally usable, so I don't think this SHOULD is reasonable... This is a fair point. We suggest the following changes and hope they will address this concern Change from 'A client SHOULD perform proof fetching' to 'A client SHOULD attempt proof fetching' Additionally, we would integrate two new points regarding DNS: 1) The UA should first probe and learn if the network supports these DNS queries 2) If the network does not support these DNS queries then periodically re-probe and if it does eventually support it, you can go through your backlog. We'd also mention the Tor option further up as it is a simple solution from the POV of this draft, although most browsers haven't deployed it for being a more difficult solution technically. IMPORTANT: This seems like kind of a dealbreaker... Yes. We think our wording is incorrect and that leads to your comment. We would like to suggest how we would change the wording and see if you have the same assessment. If SCT Feedback is not deployed by a webserver, malicious logs will be able to attack all users of the webserver (who do not have a Trusted Auditor relationship) with impunity. This is not true. It assumes an auditor cannot recognize a log partition that is perpetuated by an actively malicious log. In actuality, an auditor can (and should) be able to recognize that it has recent STHs that can't be resolved via a consistency proof and recognize that situation is perpetuating and is bad. If an auditor can do that, malicious logs _can_ be detected via STH Pollination (assuming Proof Fetching occurs) - making the document incorrect. What is true: If SCT Feedback is not deployed by a webserver, the webserver may never learn that it was the target of an attack. The auditors would learn that the log was malicious but not what domain names it attacked. We would change the document to reflect the true statement, and update various mentions and phrases to adequately convey that SCT Feedback is necessary to learn _who_ is attacked by a malicious log, but not necessary to learn that a particular log _is_ malicious and has performed an attack so long as STH Pollination and Proof Fetching occurs. IMPORTANT: This algorithm does not terminate... IMPORTANT: state that rand() has to be a CSPRNG. You're correct, we can fix these easily enough. IMPORTANT: This algorithm has terrible performance... Also correct. We'd be happy to review a suggestion that improves performance, but I'm nervous about shuffling algorithms. In general, we can add a note about more carefully considering these cases during implementation when MAX_XXX_RECORDS_TO_GOSSIP is large. With regards to Richard's suggestions: we intend to rev the doc to address all of the minor and major issues as adequately as we can. We aren't very excited about refactoring the document entirely though. If the group thinks it's valuable mostly as-is, we'd be happy to see it published. If the WG thinks it would be better to refactor it, strip out major components and so on - we think that'd be a valuable effort and would be happy to comment and provide feedback. -tom From nobody Wed Nov 8 13:35:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D825B126DEE for ; Wed, 8 Nov 2017 13:35:51 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iLN-XXmhMamE for ; Wed, 8 Nov 2017 13:35:50 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 73AE012940E for ; Wed, 8 Nov 2017 13:35:07 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id a192so2933118pge.9 for ; Wed, 08 Nov 2017 13:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ecox6v8t4GwY+vtxLyNYiYJH4toemPoiVP4tdix34jc=; b=Mx+AbNyi5gRPHXRoasrEDC3QtYTL/hF0hx8FOS8urghW5wcQeq5ok8xzaNKyN8krjk fN64HjlNx+hNCZDg6C8haXNIgJgtUqsC2wgjMFA5OAz8OxQ7OVHRUWVwuSj6+uGKIvrz wctYi399ltBXDOyxfLUT49FPNX4TEa0OxpkOrsWrK+k3p1wQL8Aq02uKn+yUvmSQ9ION NlcWmKKuW1ujmYuINEXdSJj3FMxboj/K0n9HKVMR8lcLr2sLH5KhORU+ooyxEv3ZCubD mWR/LuczaJqNLdVd78Cfl8tlooCTsRt/PFsYKuQ4/KLzsVfdJRxkZk8m9tqeBSqvtj77 kKSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ecox6v8t4GwY+vtxLyNYiYJH4toemPoiVP4tdix34jc=; b=mdm15CDQs9WNbobLgDJqFpb3y9Q3+K76bPuhgVv0Ig1B2xE9hFgl/goy3wJs6oB+0+ +2DNzsZawZXRlyXyfUsGTG+Vlw74THt4AnOqCd14AUaX3qo1fe8H9GVmSN5TiSWJDSgp 98nAVy5z1yprkyipu6aM49bm3B1V8WWst2//VWKkiOWoZlZHqZJ2tjVXvFvmXHNVZotL I7+sHAN85N2vKC9xHG9wUfkW0WTpNMePS2TCJYbCE8hKmpSTyCs6WzcUlry44K9qD1ts 5jDn0HCxby5FYyosAqWx40wXcZNZTsG2VEgt3H/IdLnlBIhLUMkK+e1RoaXV0cdL2y7d wl+g== X-Gm-Message-State: AJaThX4cjuwuoh+JouCmnx3Tlls0GjqM0sPEDnPDJHQ9BRLJxYGRPStZ SQIav65PWo439Dpmy+DBdf3Pug== X-Google-Smtp-Source: ABhQp+T2WSf2KD2P4jMqIbdBPWtERoPt6ANAft9JuxYkXBai9W6EmgKu3OhQ5FtF3ZkEFsF61RwHpQ== X-Received: by 10.101.93.140 with SMTP id f12mr1755194pgt.60.1510176906556; Wed, 08 Nov 2017 13:35:06 -0800 (PST) Received: from aspen.local (209-112-147-75-radius.dynamic.acsalaska.net. [209.112.147.75]) by smtp.gmail.com with ESMTPSA id r67sm254855pfi.56.2017.11.08.13.35.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 13:35:05 -0800 (PST) To: trans@ietf.org References: From: Melinda Shore Message-ID: Date: Wed, 8 Nov 2017 12:35:00 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Lrm1Suq8pWnjaF6PGClLs2HuDI9rFcrQ7" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 21:35:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Lrm1Suq8pWnjaF6PGClLs2HuDI9rFcrQ7 Content-Type: multipart/mixed; boundary="7TdAG8pKkVAr4E1aDVrndTHMWef2oexQR"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: Subject: Re: [Trans] AD Review: draft-ietf-trans-gossip-04 References: In-Reply-To: --7TdAG8pKkVAr4E1aDVrndTHMWef2oexQR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/8/17 12:24 PM, Tom Ritter wrote: > With regards to Richard's suggestions: we intend to rev the doc to > address all of the minor and major issues as adequately as we can. We > aren't very excited about refactoring the document entirely though. If > the group thinks it's valuable mostly as-is, we'd be happy to see it > published. If the WG thinks it would be better to refactor it, strip > out major components and so on - we think that'd be a valuable effort > and would be happy to comment and provide feedback. Thanks, Tom. We'll spend some time during the meeting discussing this and take the results of that discussion to the mailing list. Melinda --7TdAG8pKkVAr4E1aDVrndTHMWef2oexQR-- --Lrm1Suq8pWnjaF6PGClLs2HuDI9rFcrQ7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaA3iEAAoJELiGRpM6HoEuF5sQAJxU7DZFaaMEs1nlLg4U8i5h I6v/RFCnwciZKCUt0hG5z7On4dYxdz/l75BhGKLMlC1qJmnhO6Gh1X5wj5wILZSc fVyqp0pgZmVWauASTad7glxptI95j2tL4d1/LFjvFVwPmyPkDQsbcd6wr8HzPLo4 p7A83IDoWu/oCWsLzAZsjE4akMCsXzXBSNwj6q+Sb3dTpxI5uz4TTKfOycdrfmbb TuVeFP4fdpL/qOh66tgPxQNrAbaF3/M9TxP+UHQT50hKTHod81vRZOTXhREx9WpM zXyrw81bvtADanvU7IKZdxi/VUJJ/mk6LQWi8HpJS7QN/CRa5uFNeNZ+ikii0foy A5SpcVnoJaW11in0ypwu2CXmf1a5gdrYZAg6h9iBTCWgO7xaBCQXfVfs0T/vfNIk RBEtKUH3xIzZ5C1Uz/abuR7fdcRAt5cklZ9HD67ZUoYYOlNpR1L1C7V6qiXZWB/c tDxbZ3GZcuVmxKfAAzwf8jffRBLy0e22+tYyv3mTanxTZtduOcpGt0cz2gjnwtbv h+sr/40u/lDooQYSRmcs+UNjrzrUhlriwQ+GQ+lYI0sLGtlY6KI02YiLn7G8DyHH pThS8qz+wFPYZ8eOBkfpvc19XBoTv7QeKA5ndFV6CvFsg5anTnQlpE55+laTwUcq qu9qzdAHFR5PeK91MRci =8zXX -----END PGP SIGNATURE----- --Lrm1Suq8pWnjaF6PGClLs2HuDI9rFcrQ7-- From nobody Wed Nov 8 15:28:15 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615A6127076 for ; Wed, 8 Nov 2017 15:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 UhReRP9o4gpT for ; Wed, 8 Nov 2017 15:28:12 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0110.outbound.protection.outlook.com [104.47.0.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44B2127010 for ; Wed, 8 Nov 2017 15:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ikbWts6y9fNiFVBERfG/jhtw9A/jQDy0AjJPSMjLx9E=; b=k67CLSb1qAlGJgFjO4hsuJvhopXvlJHWXCt8dPq/lNIts8h5D+CaPpPIYcG8gJcARoSXKiR0pQ1nuocNUROlGEmvkvkqwd6jEUSkNgPvQ6X78mZiFmeL9LwRh16/BPh0ZsnA/GXq8OEyFoNhbaIkCLUr/Ubbj/FjeqfTMH284zM= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Wed, 8 Nov 2017 23:28:09 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0218.005; Wed, 8 Nov 2017 23:28:08 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Al Cutter CC: Eran Messeri , Melinda Shore , "watsonbladd@gmail.com" , "trans@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Trans] STAR & CT coexistence Thread-Index: AQHTV0aAV7AjheL8ZUOOBIUqQvLNtKMH8NYAgABt6ACAAUraAIAAmcmAgABSfYCAAI4LgA== Date: Wed, 8 Nov 2017 23:28:08 +0000 Message-ID: <69CBF2FE-6AA3-4A6C-B381-A7D83827FBF5@nokia.com> References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.109.191.103] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 6:RHopJZ+fCstRoCAZm9IOqd1VeS7E3Df3LTf1ZO0l4MFdYTKkqtlaQ7KrrWa4wVmULfgqEqr9Xq+1iOwMKXBXUxScp7/ejagDulW3iCWP4ePXHvDVgrkt5X64af86HaBRsQskRcxLwmmIBZDFXDv277TWxAnkvmlTE1qqrlx+qDO+DzCqLEgEiFTpR9aELWKRGmdgSdrKe+Tx6QU8NNxK4h0hsWT0XS8Ky/wLe9ZBFJx1m8nm2QvvxRGbGMrsgUClHuVat5fj/DA6IdRgtCPXziwf/sbqfT8x6PbyqkM+ht4NlPJx9EHsKDSb37yFfb4JwhoINAw7iUNi88ol/xlmPiu4vFxTgptQFzEnqGuCifQ=; 5:cfWQOMXJXqZimLhW7XD4tM+FI1MU49h7LE6a0Ym9MX9/7rfbW1AdKAqR4JuZALcoyj2XVvhihCOv+Tf+PmI7b/cdR+PUn3QHKImq10g1AzDvEJJr9O2zUB7WG5uZpo2zUzUfRrClWHKMtYKeT4/QUKkn2l+CHmTBszZEpNzLLaU=; 24:4+qcujHx3ybCVJpBdvd/NfOlprC8VMBSQ9p+UwDa6Mg2J/b6yijUAADZbik7QG0fxGCFGnWAGqgewfpfJr7USUp4roqR7ZEP5q5q5D87Z6s=; 7:obstH/X2g/jIW6abTSA7atsCblKK9rO3iesLPJckkw7A337666a+UiFox9Xfoi+orsfC7sZXD/mxOdWR0GldkbyGo8MtRRP2qaEM+vEMWMCqOLosd74YmI7ZJBQgAP5mlMyWbP48mTXR4hYiIrHLyRJzqMyz0Y7wx10RpPY1aBJKZ50q3/Pav2WMlH3igYBgu5Eb7d/f4mTG1neXrhewl3uIBPE50i/jzFT+DHSwKTofV0gXL5PNBa7Q3aumZlP0 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(199003)(24454002)(189002)(6116002)(34040400001)(3846002)(33656002)(8936002)(25786009)(3660700001)(3280700002)(7736002)(2906002)(305945005)(50986999)(229853002)(76176999)(6436002)(14454004)(54356999)(53546010)(189998001)(93886005)(105586002)(2900100001)(101416001)(478600001)(6506006)(106356001)(102836003)(6486002)(82746002)(97736004)(4326008)(81156014)(81166006)(68736007)(8676002)(2950100002)(6916009)(83716003)(5660300001)(66066001)(107886003)(53936002)(54906003)(58126008)(83506002)(316002)(5250100002)(36756003)(39060400002)(6512007)(99286004)(6246003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 84df049c-b725-4608-da33-08d527005ea1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:VI1PR07MB1102; x-ms-traffictypediagnostic: VI1PR07MB1102: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231021)(920507027)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1102; x-forefront-prvs: 0485417665 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <666E5DD7673B734BA518D4E1B6EF0091@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84df049c-b725-4608-da33-08d527005ea1 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 23:28:08.3160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102 Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 23:28:14 -0000 SGkgQWwsDQoNCk9uIDA4LzExLzIwMTcsIDE0OjU5LCAiQWwgQ3V0dGVyIiA8YWxAZ29vZ2xlLmNv bT4gd3JvdGU6DQo+IEknbSBhIGZhbiBvZiBzaG9ydC1saXZlZCBjZXJ0cywgYnV0IEknbSBub3Qg cGFydGljdWxhcmx5IGtlZW4gb24gdGhlDQo+IGlkZWEgb2Ygbm90IGxvZ2dpbmcgcHVibGljbHkg cm9vdGVkIGNlcnRzIC0gdGhlIHBvaW50IG9mIENUIGlzIHRoZQ0KPiBkaXNjb3ZlcmFiaWxpdHkg b2YgbWlzaXNzdWFuY2UgYWZ0ZXIgYWxsLCBhbmQgaXQgZG9lcyBzZWVtIHRoYXQgaGF2aW5nDQo+ IGFuIFNDVCB3aGljaCBjb3VsZCByZWZlciB0byBhIHdob2xlIHNldCBvZiAic2ltaWxhciIgeWV0 IHVubG9nZ2VkDQo+IGNlcnRzIGlzIG5vdCBhIGdyZWF0IGlkZWEsIGUuZy4gYSBzY2VuYXJpbyB3 aGVyZSB0aGUga2V5IGlzDQo+IGNvbXByb21pc2VkIGJ5IGFuIGVudGl0eSB3aGljaCBjYW4gY29l cmNlIHRoZSBDQSBpbnRvIGlzc3VpbmcgbW9yZQ0KPiAibm9uLWxvZ2dlZCIgY2VydHMgdG8gY292 ZXIgYW55IHBlcmlvZCB0aGUgcHJvdWQgbmV3IG93bmVyIG9mIHRoZSBrZXkNCj4gbWF0ZXJpYWwg d291bGQgbGlrZS4NCg0KQSBTVEFSIGNlcnRpZmljYXRlIGlzIG5vdCBvcGVuIGVuZGVkLiAgSXRz IG92ZXJhbGwgdmFsaWRpdHkgaXMgYm91bmRlZA0KYnkgdGhlIHJlY3VycmVudC1zdGFydC1kYXRl IGFuZCByZWN1cnJlbnQtZW5kLWRhdGUgYXR0cmlidXRlcyB0aGF0IGFyZQ0KbmVnb3RpYXRlZCBh dCB0aGUgdGltZSB0aGUgQUNNRSBvcmRlciBpcyBtYWRlLg0KDQpJdCBpcyBteSBpbXByZXNzaW9u IHRoYXQgYm90aCByZWN1cnJlbnQtc3RhcnQtZGF0ZSBhbmQNCnJlY3VycmVudC1lbmQtZGF0ZSBz aG91bGQgZ28gaW4gdGhlIFNDVCB0byBwcm92aWRlIHNlbWFudGljcyBlcXVpdmFsZW50DQp0byB0 aGUgbm90QmVmb3JlL25vdEFmdGVyIGF0dHJpYnV0ZXMgb2YgInJlZ3VsYXIiIGNlcnRpZmljYXRl cy4NCg0KSWYgc28sIGluIHRoZSBrZXkgY29tcHJvbWlzZSAmIENBIGNvZXJjaW9uIHNjZW5hcmlv IHRoYXQgeW91IGFyZQ0KZGVzY3JpYmluZywgdGhlIGF0dGFja2VyIHdvdWxkIG5vdCBiZSBhYmxl IHRvIGNvbnZpbmNlIHRoZSBDQSB0byBpc3N1ZQ0Kb3RoZXIgc2hvcnQtdGVybSBjZXJ0aWZpY2F0 ZXMgdGhhbiB0aG9zZSB3aGljaCBhcmUgYWxyZWFkeSBsaW5lZCB1cA0KLSB1cCB0byByZWN1cnJl bnQtZW5kLWRhdGUgLSB3aGlsZSBhbHNvIGNvbmZ1c2luZyBDVC4NCg0KQ29lcmNpb24gd291bGQg b25seSByZXN1bHQgaW4gaWdub3JpbmcgYW55IGF0dGVtcHQgZnJvbSB0aGUgdXNlciB0bw0KdGVy bWluYXRlIHRoZSBTVEFSIG9yZGVyLCBzaW1pbGFybHkgdG8gdGhlIENBIGNvZXJjZWQgdG8gYXZv aWQgdXBkYXRpbmcNCnJldm9jYXRpb24gaW5mb3JtYXRpb24gb24ga2V5IGNvbXByb21pc2Ugd2l0 aCBhICJyZWd1bGFyIiBjZXJ0aWZpY2F0ZS4NCg0KQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8gKFBy b2JhYmx5IHNvLi4uKQ0KDQo+IEknbGwgcG9pbnQgb3V0IHRoYXQgdGhlcmUgZG9lcyBzZWVtIHRv IGJlIGFuIHVuZGVybHlpbmcgcHJlbWlzZSBoZXJlDQo+IHRoYXQgaXQncyBzaW1wbHkgbm90IHBv c3NpYmxlIHRvIGxvZyBhbGwgdGhlc2Ugc2hvcnQtbGl2ZWQgY2VydHMsIGhhdmUNCj4gd2UgY29u c2lkZXJlZCB3aGV0aGVyIHRoYXQncyBhY3R1YWxseSB0aGUgY2FzZT8gIEJhY2sgb2YgdGhlIGVu dmVsb3BlOg0KPiBjdXJyZW50bHksIHRoZSBnbG9iYWwgaXNzdWFuY2UgcmF0ZSBvZiBjZXJ0cyBp cyA8IDEwIHBlciBzZWNvbmQgb24NCj4gYXZlcmFnZSBbOTBkIGF2ZXJhZ2UgZ3Jvd3RoIG9mIFBp bG90IGlzIGFjdHVhbGx5IDwgNS9zXS4gVGhlDQo+IG92ZXJ3aGVsbWluZyBtYWpvcml0eSBvZiBj ZXJ0aWZpY2F0ZXMgY29tZSBmcm9tIExldCdzIEVuY3J5cHQsIGFuZA0KPiBjdXJyZW50bHkgYWxs IGhhdmUgYSBsaWZldGltZSBvZiA5MCBkYXlzLsKgIElmIHdlJ3JlIHRhbGtpbmcgYWJvdXQNCj4g cmVkdWNpbmcgdGhhdCBjZXJ0IGxpZmV0aW1lIHRvIDI0aCB0aGVuIHdlJ3JlIGxvb2tpbmcgYXQg OTB4IGluY3JlYXNlLA0KPiBzbyBsZXQncyBjYWxsIGl0IDFrL3MuDQo+IA0KPiBFdmVuIGlmIHdl J3JlIGFzc3VtaW5nIHRoYXQgZXZlcnkgY2VydCBtdXN0IGJlIGxvZ2dlZCB0byBldmVyeSBMb2cg SQ0KPiB0aGluayB0aGF0J3MgYWNoaWV2YWJsZSBieSB0aGUgVHJpbGxpYW4tYmFzZWQgbG9ncywg YW5kIEknbGwgY295bHkNCj4gbWVudGlvbiB0aGF0IEknbSBhd2FyZSBvZiBvbmUgb3RoZXIgTG9n IGltcGxlbWVudGF0aW9uIHdoaWNoIEknbSBsZWQNCj4gdG8gYmVsaWV2ZSBpcyBtb3JlIHRoYW4g Y2FwYWJsZSBvZiBzdXN0YWluaW5nIHRoYXQgbGV2ZWwgb2YNCj4gdGhyb3VnaHB1dC7CoCBXZXJl IHRoYXQgbm90IHRoZSBjYXNlLCBpdCdzIGFsc28gbm90IGhhcmQgdG8gaW1hZ2luZQ0KPiBzY2hl bWVzIGZvciBzcHJlYWRpbmcgdGhpcyBsb2FkIGFyb3VuZCBpZiBuZWVkIGJlIChlLmcuIHNoYXJk aW5nIGJ5DQo+IG1vZHVsbyBvZiBjZXJ0IGhhc2ggZXRjLiwgInNtYXJ0IiBsb2FkLWJhbGFuY2lu ZyBDVCBwcm94aWVzLCBldGMuDQo+IGV0Yy4pDQo+IA0KPiBMb2cgZ3Jvd3RoIHRvIHZlcnkgbGFy Z2Ugc2l6ZXMgY2FuIGJlIGFscmVhZHkgYmUgYWRkcmVzc2VkIGJ5IHNjaGVtZXMNCj4gc3VjaCBh cyBDaHJvbWUncyBUZW1wb3JhbCBMb2cgUG9saWN5IHdoaWNoIGFsbG93IE9wZXJhdG9ycyB0byBk ZWZpbmUNCj4gdGhlaXIgTG9nIGxpZmUtY3ljbGUsIGFuZCBDQXMsIFVBcywgTW9uaXRvcnMsIGFu ZCBhbnkgb3RoZXIgaW50ZXJlc3RlZA0KPiBlbnRpdHkgdG8gYnVpbGQtaW4gc3VwcG9ydCBmb3Ig dGhhdCBsaWZlLWN5Y2xlIGFoZWFkIG9mIHRpbWUuDQo+IA0KPiBUaGVyZSBtaWdodCBiZSBvdGhl csKgY29uY2VybnMgb2Ygc2NhbGUgZWxzZXdoZXJlLCBidXQgSSdtIG5vdCBzdXJlDQo+IHRoYXQg aXQncyBpbiB0aGUgbG9nZ2luZy4NCg0KVmVyeSBpbnRlcmVzdGluZy4NCg0KQ2hlZXJzDQoNCg0K From nobody Thu Nov 9 10:07:14 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A19128C84 for ; Thu, 9 Nov 2017 10:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com 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 2nUSzdTHZ40n for ; Thu, 9 Nov 2017 10:07:11 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCBB128D40 for ; Thu, 9 Nov 2017 10:07:10 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id BDA9520047613 for ; Thu, 9 Nov 2017 10:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=6VarX4SpO7Wv+PLh2KgSSXwzMYw=; b= LS3XcOdRdUnB3M+SrjPuO3LJ/7NZXbhM14Q3/CXM7luhUcrKX6ux3/nhe0/rSnZi 587lcclff7xc3iDF4K9bEkTvT9ODCUYVmxWh9iM5HXsrH6Pv6/oqyfyICbUq8K/y KbZDLGLpfbLI5YWS5PBrYEuwdGEckuj5FxPq/JAKhME= Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 9A43C2004760D for ; Thu, 9 Nov 2017 10:07:09 -0800 (PST) Received: by mail-io0-f171.google.com with SMTP id b186so10778557iof.8 for ; Thu, 09 Nov 2017 10:07:09 -0800 (PST) X-Gm-Message-State: AJaThX7IpQFMz0ntLyu6aj6krhlGdlscT+lVIEuJf09cLSZiPgG0XuQm XXqzG8HMnZoDr2N1NbJMOsXAkIuD6EMQrRGOBRw= X-Google-Smtp-Source: ABhQp+S1nu9XGj+/s7MpfEYVWgi8Ix8vbqxWYpbIgq7Bg2Wc3M0SY4aK8WTCKkVcPv5w3BS0JXuRxpXJP7OkqITnLts= X-Received: by 10.107.163.15 with SMTP id m15mr1678738ioe.61.1510250828531; Thu, 09 Nov 2017 10:07:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.167.140 with HTTP; Thu, 9 Nov 2017 10:07:07 -0800 (PST) In-Reply-To: <93246de3-1081-73e3-2703-8336566caf28@gmail.com> References: <93246de3-1081-73e3-2703-8336566caf28@gmail.com> From: Ryan Sleevi Date: Thu, 9 Nov 2017 13:07:07 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Melinda Shore Cc: Trans Content-Type: multipart/alternative; boundary="001a11402f14280ea0055d90ac7d" Archived-At: Subject: Re: [Trans] Request for feedback X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 09 Nov 2017 18:07:13 -0000 --001a11402f14280ea0055d90ac7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 4, 2017 at 4:45 PM, Melinda Shore wrote: > On 11/2/17 4:03 AM, Tadahiko Ito wrote: > > draft-strad-trans-redaction-01 is discussing about end-user security an= d > > raise 3 mechanism for name redaction. > > On the other hand, I would like to discuss need for =E2=80=9Cuse of tec= hnically > > constrained intermediate=E2=80=9D with aspects of security and scaleabi= lity > > (especially use of technically constrained intermediate with IoT > devices). > > Hi, all: > > I'll be getting an agenda out this weekend but note that > we'll be allocating time on the agenda at IETF 100 for > a redaction discussion, based on > https://www.ietf.org/internet-drafts/draft-ito-yet-another- > name-redaction-00.txt. > > We'd like to get the redaction question resolved (the trans working > group will/will not be working on this), so please give the draft > a read and post comments to the mailing list. If you'll be in > Singapore, please come to the session prepared for a redaction > discussion. > > Many thanks, > > Melinda > [Document Review] As noted in and throughout the document, the majority of the document is borrowed from https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ , particularly around the discussion of the technical means and methods. Perhaps easiest to view is the diff here - https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.ietf= .org/id/draft-strad-trans-redaction-01.txt&url2=3Dhttps://www.ietf.org/id/d= raft-ito-yet-another-name-redaction-00.txt The main differences, in reviewing this document, appear to be: - The difference in discussion about use cases - The removal of security and privacy considerations draft-strad-trans-redaction-01 attempted to pose the space as one of privacy and compliance. draft-ito-yet-another-name-redaction-00 attempts to pose the space as one of scalability and security (through obscurity). This position seems consistent with the authors' work within the CA/Browser Forum to discuss the policy-based mechanisms for this, as captured in this thread https://cabforum.org/pipermail/public/2017-November/012458.html , which also establishes and further develops the use cases. Given that this does not introduce any new technical mechanisms to address the policy concerns that resulted in a lack of interest for adoption of the previous draft, it seems that adoption or rejection is best based on the fitness for the use cases established and the interest of those adopting. >From the point of view of log operation, this draft does not seem to meaningfully change how a CT Log Operator behaves - that is, the same API endpoints function. The impact or support for such changes rests upon CAs (during issuance), clients (during the matching of SCTs to the associated certificate), and auditor/monitors (in evaluating the logs contents against certificates). We know that some CAs are supportive, as captured both in past on-list discussions, from deployment of ad-hoc redaction schemes in the wild (as evidenced by the contents of the Deneb Log operated by Symantec - https://knowledge.symantec.com/support/ssl-certificates-support/index?page= =3Dcontent&id=3DAR2177 ). However, the decision to trust or not trust such CAs and validate such certificates is fundamentally a policy question, and one answered by individual vendors in assessing the security risks of their products. If there are no products interested in consuming such certificates, or trust stores interested in supporting such mechanisms, it seems to suggest that it is not something that will be implemented or have consensus, and thus there may be limited value to standardizing. [Position] Given that this document does not provide any new technical insight to address the policy concerns (raised outside the IETF) with respect to redaction, it does not seem to introduce anything new to the conversation. With respect to the use cases in the Introduction, they are presumably informative rather than normative, but they appear to be "security through obscurity" and "scalability". I don't know if the IETF has guidance on whether "security through obscurity" is a valid case, compared with the previous document's approach from privacy, but at least with respect to scalability, it seems that there are both alternative technical solutions (c.f. STAR) and perhaps incorrect baseline assumptions (see https://mailarchive.ietf.org/arch/msg/trans/a8uErKaGFGZf7kucNFoglwFpskk ) that may offer more viable, less harmful approaches. With respect to its use within the set of CAs and PKI trusted within Chromium-based products, there has been zero interest in adoption of a technical solution in the absence of addressing the policy concerns. These policy concerns were not addressed nor mitigated in sufficient time to inform Chromium's product decisions and implementation regarding CT support, and as such, there are no present or future plans to support redaction within Chromium-based products. The introduction of redaction, which poses great risk, to an ecosystem and product which does not support redaction, as currently implemented, is gated not on the technical means, but providing a holistic means of addressing the policy concerns about redaction's attempts to maximize site operator's wishes against the harms caused to the ecosystem of relying parties and monitors, and the demonstration that providing less transparency is more beneficial to the ecosystem at large. Before considering adopting, it would be useful to know if there are other consumers of CT outside that "Web PKI" use case, how such ecosystems function, and whether or not the maintainers of such PKIs have interest in this case. As it applies to the Web PKI trusted within Chromium, we believe such technical solutions are counter-productive to the goals of Certificate Transparency for that PKI, and that CAs that issue such certificates should be (and have been) treated as actively misissuing certificates and undermining trust and security. Similarly, it seems useful to evaluate whether the introduction of redaction is one which provides an optional, if not widely supported addition to the ecosystem, much like RFC 6170, or whether it would serve as a net-negative to the stability and interoperability of the Certificate Transparency ecosystem, much like altering the preferred name syntax of DNS could allow new powerful features, but also undermine interoperability, stability, and security. --001a11402f14280ea0055d90ac7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 4, 2017 at 4:45 PM, Melinda Shore <melinda.shore@gma= il.com> wrote:
On 11/2/17 4:03 AM, Tadahiko Ito wrote:
> draft-strad-trans-redaction-01 is discussing about end-user security a= nd
> raise 3 mechanism for name redaction.
> On the other hand, I would like to discuss need for =E2=80=9Cuse of te= chnically
> constrained intermediate=E2=80=9D with aspects of security and scaleab= ility
> (especially use of technically constrained intermediate with IoT devic= es).

Hi, all:

I'll be getting an agenda out this weekend but note that
we'll be allocating time on the agenda at IETF 100 for
a redaction discussion, based on
https://www.ietf.org= /internet-drafts/draft-ito-yet-another-name-redaction-00.txt.=

We'd like to get the redaction question resolved (the trans working
group will/will not be working on this), so please give the draft
a read and post comments to the mailing list.=C2=A0 If you'll be in
Singapore, please come to the session prepared for a redaction
discussion.

Many thanks,

Melinda

[Document Review]

The main differences, in reviewing this = document, appear to be:
- The difference in discussion about use = cases
- The removal of security and privacy considerations
<= div>
draft-strad-trans-redaction-01 attempted to pose the spa= ce as one of privacy and compliance.
draft-ito-yet-another-name-r= edaction-00 attempts to pose the space as one of scalability and security (= through obscurity).

This position seems consistent= with the authors' work within the CA/Browser Forum to discuss the poli= cy-based mechanisms for this, as captured in this thread=C2=A0https://cabf= orum.org/pipermail/public/2017-November/012458.html , which also establ= ishes and further develops the use cases.

Given th= at this does not introduce any new technical mechanisms to address the poli= cy concerns that resulted in a lack of interest for adoption of the previou= s draft, it seems that adoption or rejection is best based on the fitness f= or the use cases established and the interest of those adopting.
=
From the point of view of log operation, this draft does not= seem to meaningfully change how a CT Log Operator behaves - that is, the s= ame API endpoints function. The impact or support for such changes rests up= on CAs (during issuance), clients (during the matching of SCTs to the assoc= iated certificate), and auditor/monitors (in evaluating the logs contents a= gainst certificates).

We know that some CAs are su= pportive, as captured both in past on-list discussions, from deployment of = ad-hoc redaction schemes in the wild (as evidenced by the contents of the D= eneb Log operated by Symantec -=C2=A0= https://knowledge.symantec.com/support/ssl-certificates-support/index?page= =3Dcontent&id=3DAR2177 ). However, the decision to trust or not tru= st such CAs and validate such certificates is fundamentally a policy questi= on, and one answered by individual vendors in assessing the security risks = of their products.

If there are no products intere= sted in consuming such certificates, or trust stores interested in supporti= ng such mechanisms, it seems to suggest that it is not something that will = be implemented or have consensus, and thus there may be limited value to st= andardizing.

[Position]
Given that this = document does not provide any new technical insight to address the policy c= oncerns (raised outside the IETF) with respect to redaction, it does not se= em to introduce anything new to the conversation. With respect to the use c= ases in the Introduction, they are presumably informative rather than norma= tive, but they appear to be "security through obscurity" and &quo= t;scalability". I don't know if the IETF has guidance on whether &= quot;security through obscurity" is a valid case, compared with the pr= evious document's approach from privacy, but at least with respect to s= calability, it seems that there are both alternative technical solutions (c= .f. STAR) and perhaps incorrect baseline assumptions (see=C2=A0htt= ps://mailarchive.ietf.org/arch/msg/trans/a8uErKaGFGZf7kucNFoglwFpskk ) = that may offer more viable, less harmful approaches.

With respect to its use within the set of CAs and PKI trusted within Chr= omium-based products, there has been zero interest in adoption of a technic= al solution in the absence of addressing the policy concerns. These policy = concerns were not addressed nor mitigated in sufficient time to inform Chro= mium's product decisions and implementation regarding CT support, and a= s such, there are no present or future plans to support redaction within Ch= romium-based products. The introduction of redaction, which poses great ris= k, to an ecosystem and product which does not support redaction, as current= ly implemented, is gated not on the technical means, but providing a holist= ic means of addressing the policy concerns about redaction's attempts t= o maximize site operator's wishes against the harms caused to the ecosy= stem of relying parties and monitors, and the demonstration that providing = less transparency is more beneficial to the ecosystem at large.
<= br>
Before considering adopting, it would be useful to know if th= ere are other consumers of CT outside that "Web PKI" use case, ho= w such ecosystems function, and whether or not the maintainers of such PKIs= have interest in this case. As it applies to the Web PKI trusted within Ch= romium, we believe such technical solutions are counter-productive to the g= oals of Certificate Transparency for that PKI, and that CAs that issue such= certificates should be (and have been) treated as actively misissuing cert= ificates and undermining trust and security.

Simil= arly, it seems useful to evaluate whether the introduction of redaction is = one which provides an optional, if not widely supported addition to the eco= system, much like RFC 6170, or whether it would serve as a net-negative to = the stability and interoperability of the Certificate Transparency ecosyste= m, much like altering the preferred name syntax of DNS could allow new powe= rful features, but also undermine interoperability, stability, and security= .
--001a11402f14280ea0055d90ac7d-- From nobody Thu Nov 9 13:56:29 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A81128B91 for ; Thu, 9 Nov 2017 13:56:27 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bA97whIJcWsC for ; Thu, 9 Nov 2017 13:56:25 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 CAEEE126579 for ; Thu, 9 Nov 2017 13:56:24 -0800 (PST) Received: (qmail 27073 invoked by uid 1004); 9 Nov 2017 21:56:22 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 09 Nov 2017 21:56:22 +0000 Received: from [192.168.1.81] ([80.189.35.24]) by maileu.comodo.net (IceWarp 11.4.6.0 DEB8 x64) with ASMTP (SSL) id 201711092156225476; Thu, 09 Nov 2017 21:56:22 +0000 To: Eran Messeri Cc: Melinda Shore , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , watsonbladd@gmail.com, "trans@ietf.org" References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> From: Rob Stradling Message-ID: <474c464d-74ea-5db5-8390-30edc3b45669@comodo.com> Date: Thu, 9 Nov 2017 21:56:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 09 Nov 2017 21:56:28 -0000 On 08/11/17 00:54, Eran Messeri wrote: > One way for a single SCT to be valid for multiple certificates is to > omit the fields that change from the data covered by the SCT's signature. > For short-lived certificates this would (likely) be the serial number, > notBefore and notAfter dates. > > This means there's no need to re-request an SCT each time a new > short-lived certificate is minted, and the SCT covers all key fields in > the certificate's TBSCertificate structure (Subject Alternative Names, > key,  etc). > > The drawback is that without a serial number Hi Eran. Just thinking about the problem space here... > (1) it is not possible to > verify CAs don't violate the unique serial number requirement > (effectively reducing auditing capabilities) One way to mitigate this would be to require the use of a deterministic serial number scheme (i.e., where the serial number is calculated from the rest of the TBSCertificate just before the cert is signed). > (2) mis-issued certificates can't be revoked using the usual means. The "usual means" of revocation (CRL and OCSP) "don't work" anyway. That is, many of today's TLS clients no longer use these mechanisms. Alternative revocation mechanisms could be invented that revoke groups of certs (e.g., perhaps by SHA-256(SubjectPublicKeyInfo), or by SHA-256(SharedSCT), etc, instead of by serial number). > Note that such a mechanism cannot be implemented either using 6962 or > 6962-bis: Both documents mandate that the SCT covers all fields in the > TBSCertificate (at least). But, if the design was changed to exclude > some fields, it seems to me that this solution would otherwise be > compatible with the rest of the CT protocol. How about defining an SCT extension that, when present, indicates that the SCT's signature doesn't cover serial number, notBefore and notAfter? > On Mon, Nov 6, 2017 at 9:09 PM, Melinda Shore > wrote: > > The question of how to log short-lived certificates is something > that's been coming up more frequently recently, and it's > independent (mostly) of the issuance mechanism.  I think we've > got time to discuss it during the session at IETF 100, and > it would be helpful if there's a specific proposal to use as > a starting point.  Will the folks working on this be > at the meeting? > > 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 > -- 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 Sat Nov 11 02:43:19 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7B1294E6 for ; Sat, 11 Nov 2017 02:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9idTy7GTx3os for ; Sat, 11 Nov 2017 02:43:17 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 A4FE11294EE for ; Sat, 11 Nov 2017 02:43:16 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id 9so1483389wme.4 for ; Sat, 11 Nov 2017 02:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=yVHP4eQ0rlrTNu765MIf65jxZjzWHTY97C7qU733nt4=; b=CJn3Iket3u7oDOg13RkxqMVoc4QX1jTeAxS2kKnoj8QCzw+UfuVetl3V3BGb22XbAJ K6ZacEArFvg7JHHGoTwQSz8yoCDcwClTIdr4OXRAQ84WDPHAf1sNlMGKx7ZsQCf35uXD pKqV08UDGNSp4B8Wco5vvdWAMifAITO8qck38Dk6OiSaVkJQw2HKz2Id1NjKY6QIKReT vVN1dSsxm/M4bMnropY17lcRzVEyWnYXr+J3MPMd067WmJKMFTO3Y6sXbKBxocYeQqIf IA1EuxrE/4nPhci6HGV0A+OkeeBCcAqW5JBq1WgvlSd4bhA9GJlW4Z/Pb/eShx1u8f5s BtXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=yVHP4eQ0rlrTNu765MIf65jxZjzWHTY97C7qU733nt4=; b=SHT3VFIHqAck/TWIOx8OCwGxC0ONxIZYg8XS3n/DGRqEZL9d4nNXMCUG/hjRGKiFXJ Eq6IcoqEkgEWDjFuGhRggrL29CMFcBiRtpkHNaNM9xxPgu+HiTpyp5TMBPjlkiw4tyv4 tTvdRBPeEPKTBwP7fHvWAamDhyGQkqXTVtf5hRy2u8KmcP/bXDzD7v8ncBZJrRntcNbw I+9pB8LuSqVawYIn2KYhSus0EEzrUTNWUe8uPtOAEzx+v2XUtP6gBxSx8YBLxsZeKzDV 1nyrUfq5TPWtLpfPmf4re3pNfWq4dhLRc1MUmnsRfJ8KnWndnnnkIAOcdwTy11odgBne XqQg== X-Gm-Message-State: AJaThX4rMitB3R5uCQAF70gPiSZjOZK/qRyuYdvKSRIounARPexJ2dm+ wKOd69VQnzwUTMLQEF5BtX3FU88/ X-Google-Smtp-Source: AGs4zMZbL/vqPsJXvBsr2bR4OVG2rVzNELHR6MUc1Xs/Fmjzp1Mc94cks0IZNoScwt9u5xQp42woTw== X-Received: by 10.80.157.141 with SMTP id w13mr4581175ede.151.1510396994685; Sat, 11 Nov 2017 02:43:14 -0800 (PST) Received: from [192.168.0.26] (85-218-6-197.dclient.lsne.ch. [85.218.6.197]) by smtp.gmail.com with ESMTPSA id b36sm10253675edd.67.2017.11.11.02.43.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 02:43:14 -0800 (PST) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_4575EFFF-C93E-4E5C-93B6-A16D9C57C3B4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sat, 11 Nov 2017 11:43:17 +0100 To: "trans@ietf.org" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Trans] Chainiac software update transparency work, presentations at CFRG and HRPC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 11 Nov 2017 10:43:18 -0000 --Apple-Mail=_4575EFFF-C93E-4E5C-93B6-A16D9C57C3B4 Content-Type: multipart/alternative; boundary="Apple-Mail=_434255F5-9E11-4337-A3EA-2525B432162E" --Apple-Mail=_434255F5-9E11-4337-A3EA-2525B432162E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear CT folks, I just wanted to let you know about some recent transparency work from = my lab at EPFL, which we presented at USENIX Security =E2=80=9917 and = may be of interest to this group: CHAINIAC: Proactive Software-Update Transparency via Collectively Signed = Skipchains and Verified Builds = https://www.usenix.org/conference/usenixsecurity17/technical-sessions/pres= entation/nikitin = Abstract: Software-update mechanisms are critical to the security of = modern systems, but their typically centralized design presents a = lucrative and frequently attacked target. In this work, we propose = CHAINIAC, a decentralized software-update framework that eliminates = single points of failure, enforces transparency, and provides efficient = verifiability of integrity and authenticity for software-release = processes. Independent witness servers collectively verify conformance = of software updates to release policies, build verifiers validate the = source-to-binary correspondence, and a tamper-proof release log stores = collectively signed updates, thus ensuring that no release is accepted = by clients before being widely disclosed and validated. The release log = embodies a skipchain, a novel data structure, enabling arbitrarily = out-of-date clients to efficiently validate updates and signing keys. = Evaluation of our CHAINIAC prototype on reproducible Debian packages = shows that the automated update process takes the average of 5 minutes = per release for individual packages, and only 20 seconds for the = aggregate timeline. We further evaluate the framework using real-world = data from the PyPI package repository and show that it offers clients = security comparable to verifying every single update themselves while = consuming only one-fifth of the bandwidth and having a minimal = computational overhead. I=E2=80=99ll be at IETF 100 but unfortunately can=E2=80=99t make it = until after the trans meeting. But I will be doing two brief = Chainiac-related presentations in two IRTF meetings later in the week: - In the CFRG meeting on Wednesday I=E2=80=99ll talk about SkipChains, = the cryptographically traversable blockchain structure enabling offline = and peer-to-peer verification of updates. - In the HRPC meeting on Friday I=E2=80=99ll talk about the end-to-end = software supply chain security and transparency issues that the Chainiac = architecture addresses. Thanks Bryan --Apple-Mail=_434255F5-9E11-4337-A3EA-2525B432162E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear CT folks,

I just wanted to let you know about some recent transparency = work from my lab at EPFL, which we presented at USENIX Security =E2=80=991= 7 and may be of interest to this group:

CHAINIAC: Proactive = Software-Update Transparency via Collectively = Signed Skipchains and Verified Builds
https://www.usenix.org/conference/usenixsecurity17/technical-se= ssions/presentation/nikitin

Abstract: Software-update mechanisms = are critical to the security of modern systems, but their typically = centralized design presents a lucrative and frequently attacked = target. In this work, we propose CHAINIAC, a decentralized = software-update framework that eliminates single points of failure, = enforces transparency, and provides efficient verifiability of integrity = and authenticity for software-release processes. = Independent witness servers collectively verify conformance of = software updates to release policies, build verifiers validate = the source-to-binary correspondence, and a tamper-proof release log = stores collectively signed updates, thus ensuring that no release is = accepted by clients before being widely disclosed and validated. = The release log embodies a skipchain, a novel data structure, = enabling arbitrarily out-of-date clients to efficiently validate = updates and signing keys. Evaluation of our CHAINIAC prototype on = reproducible Debian packages shows that the automated update = process takes the average of 5 minutes per release for individual = packages, and only 20 seconds for the aggregate timeline. We = further evaluate the framework using real-world data from the PyPI = package repository and show that it offers clients = security comparable to verifying every single update themselves = while consuming only one-fifth of the bandwidth and having a = minimal computational overhead.

I=E2=80=99ll be = at IETF 100 but unfortunately can=E2=80=99t make it until after the = trans meeting.  But I will be doing two brief Chainiac-related = presentations in two IRTF meetings later in the week:

- In the CFRG meeting on Wednesday = I=E2=80=99ll talk about SkipChains, the cryptographically traversable = blockchain structure enabling offline and peer-to-peer verification of = updates.
- In the HRPC meeting on Friday I=E2=80=99ll= talk about the end-to-end software supply chain security and = transparency issues that the Chainiac architecture addresses.

Thanks
Bryan

= --Apple-Mail=_434255F5-9E11-4337-A3EA-2525B432162E-- --Apple-Mail=_4575EFFF-C93E-4E5C-93B6-A16D9C57C3B4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaBtRFAAoJEGt1rlrP7+d/ERIP/3aBQRnwTOeH3WJ6HNwbXyHG 239AITrfVzMuLJu4iFnuYFyYD3kTN7u3FFCf43QTjS/DYYHSsBIidtrvzw6pJJj9 amQXJHjXwUF4Ww0KDoyG/09ND1NCx+/ztIOOUPqKtqqFOiw0RXqhKPA6cXyqkWlk LzcpwJ98ZI+DiaO1jsGtBeJVYUFIRbYDyEoCHbxLKQybQiIPmG/aDGB4FPNwBJ0N z09oanlDX5uQpuonNMUGpbx4SEg34MEEZp6DgQRGAcKnjIoNuhoOfSFUeoi8b7pX gI4ou5KeKb4pJ6ytJ2/SewaXZCy3q59Xl0YbtYVdgT+sDG4vQcYoHsGfGK+36qpW RS+On7vmPqEejjnv3D5JnKJ8Q2ljU94Cp6OPoXqX+WXFa9gvs0BgnJAJUvc4c4R5 0igekJvEm2I39BD7RIL3zs4Q3HYYBNX/DxRSwsj3+Wqh2FD+RBSxrldBLl4fKBv0 mjDVMYcwIZaLeBotGSYrAhs1ylxh8PqGq0y2TzsY3kuGxE+aI0kQk/sTNdjks7q/ x+VInnuDDm9YLDnzHnghDCpvcudMw0GhHWZksGLmTVdn/F5rVdcgGV7ADXVtMRLU 0G/Yli/lMRXtktmIZ/utJ2fTHf4+7t6Dbq8qu3Xpzpfc6+fOMYhRHSqlq9HCM7f3 LZ4U9mNvOawB8wQIkRX2 =KAc2 -----END PGP SIGNATURE----- --Apple-Mail=_4575EFFF-C93E-4E5C-93B6-A16D9C57C3B4-- From nobody Sat Nov 11 03:44:37 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885B1129483 for ; Sat, 11 Nov 2017 03:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PbdUU15wPX2f for ; Sat, 11 Nov 2017 03:44:34 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 F15401242EA for ; Sat, 11 Nov 2017 03:44:33 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id t139so7169797wmt.1 for ; Sat, 11 Nov 2017 03:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4gAPCyNCvyzdH8Allj6juDNFlpKxQJCCUN3NFBc2CUk=; b=AoBIQtBViN91BqJBYReeWrCq19kQ0ol3pt6lCZLHIpYgtTMyiwZEg5AbIYZzvVTJVz 1T1IfJ8rL7FOkOMrjLcBmTioXtkRMIHnH9nQ0o6QezCEmWQPJwtpklb3dO3VivBVnO38 2PEwjdOnqEmLjHKNff+xDmR7ovasYafWN9iBJfRylTMbPu+ggzi9kAPEmYxsbFurZHzV FzqoXV+ZBH3c2wdc9xtYVDpIwY0cBO+u9XQJrqF1OP1Ap1Nz1chi+0cW7iz3FxB9zdIP paVFRaZ7HENHxGyijTo6hQ2EDkH0L1C+4pNO12ZzmKIwU+DBWI8Lt1dtpPS2YySDCd0Q Zq+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4gAPCyNCvyzdH8Allj6juDNFlpKxQJCCUN3NFBc2CUk=; b=V+pGlC2Tx/GVWOBv4853f8aaPSUavm/phcmM0AQuYu7/8ynW6pKrepeY4trCoCVi1T BcvqvRopPsUCvqxr7HDPpgrMerRagzeE5R/MwEBn/LCCDpr2ZAo7615zniUWALmXFFWE N1TMP/W/0+v393aScSo7RQo+oLhDbKnVF8cdvRjLyCPp7AV/E7VIkFUKZA2ZwtOHRl6A DE5ufoojSN+IzOhsXR6LLrc/W4QoTSApYGxTx4H855wsWC/Fz4YgFFbdYF0YHEcSnQ15 0VdUnPfofCiq4pMJ5WEuOTwmwhsHk2XpBPblvO5Y9oVNzFLUNY1C2FA59tmiwYiGb7Fe q7Cw== X-Gm-Message-State: AJaThX7bt6aasmkDyMPsBjWJBOa0eddhgclxgC50P+diRfIlMf2PBAs1 u3W6Mk2Wrc2WJ4F+I0FhMrMNs2iuzoM= X-Google-Smtp-Source: AGs4zMaATUzkFu9QZklK1BXVSw7bxu22wGaRW95lmXbHohQUVw4WFdU2mqedPPDGQL1zyZgEAr6PKg== X-Received: by 10.80.158.108 with SMTP id z99mr4491953ede.262.1510400672426; Sat, 11 Nov 2017 03:44:32 -0800 (PST) Received: from [192.168.0.26] (85-218-6-197.dclient.lsne.ch. [85.218.6.197]) by smtp.gmail.com with ESMTPSA id y3sm9340660edd.73.2017.11.11.03.44.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 03:44:31 -0800 (PST) From: Bryan Ford Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1FBF5185-0171-4393-A96B-410817E8E944"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 11 Nov 2017 12:44:29 +0100 In-Reply-To: Cc: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "watsonbladd@gmail.com" , Eran Messeri , "trans@ietf.org" , Melinda Shore To: Al Cutter References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 11 Nov 2017 11:44:36 -0000 --Apple-Mail=_1FBF5185-0171-4393-A96B-410817E8E944 Content-Type: multipart/alternative; boundary="Apple-Mail=_7E4C1877-54D8-49D7-91CE-7E07B7BFBD59" --Apple-Mail=_7E4C1877-54D8-49D7-91CE-7E07B7BFBD59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 8, 2017, at 3:59 PM, Al Cutter wrote: > I'm a fan of short-lived certs, but I'm not particularly keen on the = idea of not logging publicly rooted certs - the point of CT is the = discoverability of misissuance after all, and it does seem that having = an SCT which could refer to a whole set of "similar" yet unlogged certs = is not a great idea, e.g. a scenario where the key is compromised by an = entity which can coerce the CA into issuing more "non-logged" certs to = cover any period the proud new owner of the key material would like. 100% agreed on this point. Short-term certs are good, and they all = should - and can - be publicly logged to ensure transparency. To = whatever extent this capacity issue is a problem in the current CT = design, this is a problem with CT that needs to be fixed. The SkipChain structure for cryptographically-traversable, = collectively-signed blockchains, detailed in our CHAINIAC work that I = just mentioned = (https://www.usenix.org/conference/usenixsecurity17/technical-sessions/pre= sentation/nikitin = ), may be of use here. The SkipChain structure is = designed to support groups of collective signers whose public keys may = change quite rapidly, while ensuring that any client or validator can = =E2=80=9Ccatch up=E2=80=9D with its peers=E2=80=99 state quickly and = efficiently no matter how far behind in time they may be. For example, SkipChains were designed to support permissionless = blockchains such as Bitcoin or ByzCoin = (https://www.usenix.org/conference/usenixsecurity16/technical-sessions/pre= sentation/kogias = ), where the the collective signing group is defined by = a window of recent proof-of-work miners that may change very 10 minutes. = The SkipChain structure enables new or long-offline light clients or = full nodes to catch up with the state of the blockchain from any recent = collectively-signed snapshot, without everyone having to store the = entire blockchain history. In practice we expect some subset of = validators well-provisioned with storage would still store the entire = history, but that becomes optional rather than mandatory. Note that I=E2=80=99m definitely not suggesting that CT would want = proof-of-work; just bringing this up as an example =E2=80=9Ctorture = test=E2=80=9D for frequently-changing keys/certificates that the = SkipChain structure is designed and already demonstrated to support = efficiently. The property that SkipChains allow nodes (e.g., log = servers, CAs, and/or clients) to prune their storage of rapidly-changing = logs more aggressively seems like the property most likely of potential = valid here. But in any case, how exactly SkipChains would best fit into CT and/or = STAR is of course an open question for discussion, which I=E2=80=99m = happy to participate in if there=E2=80=99s interest. Bryan --Apple-Mail=_7E4C1877-54D8-49D7-91CE-7E07B7BFBD59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Nov 8, 2017, at 3:59 PM, Al Cutter <al@google.com> wrote:
I'm a fan of = short-lived certs, but I'm not particularly keen on the idea of not = logging publicly rooted certs - the point of CT is the discoverability = of misissuance after all, and it does seem that having an SCT which = could refer to a whole set of "similar" yet unlogged certs is not a = great idea, e.g. a scenario where the key is compromised by an entity = which can coerce the CA into issuing more "non-logged" certs to cover = any period the proud new owner of the key material would like.

100% agreed on = this point.  Short-term certs are good, and they all should - and = can - be publicly logged to ensure transparency.  To whatever = extent this capacity issue is a problem in the current CT design, this = is a problem with CT that needs to be fixed.

The SkipChain structure for = cryptographically-traversable, collectively-signed blockchains, detailed = in our CHAINIAC work that I just mentioned (https://www.usenix.org/conference/usenixsecurity17/technical-se= ssions/presentation/nikitin), may be of use here.  The = SkipChain structure is designed to support groups of collective signers = whose public keys may change quite rapidly, while ensuring that any = client or validator can =E2=80=9Ccatch up=E2=80=9D with its peers=E2=80=99= state quickly and efficiently no matter how far behind in time they may = be.  

For example, SkipChains = were designed to support permissionless blockchains such as Bitcoin or = ByzCoin (https://www.usenix.org/conference/usenixsecurity16/technical-se= ssions/presentation/kogias), where the the collective signing group = is defined by a window of recent proof-of-work miners that may change = very 10 minutes.  The SkipChain structure enables new or = long-offline light clients or full nodes to catch up with the state of = the blockchain from any recent collectively-signed snapshot, without = everyone having to store the entire blockchain history.  In = practice we expect some subset of validators well-provisioned with = storage would still store the entire history, but that becomes optional = rather than mandatory.

Note that = I=E2=80=99m definitely not suggesting that CT would want proof-of-work; = just bringing this up as an example =E2=80=9Ctorture test=E2=80=9D for = frequently-changing keys/certificates that the SkipChain structure is = designed and already demonstrated to support efficiently.  The = property that SkipChains allow nodes (e.g., log servers, CAs, and/or = clients) to prune their storage of rapidly-changing logs more = aggressively seems like the property most likely of potential valid = here.

But in any case, how exactly = SkipChains would best fit into CT and/or STAR is of course an open = question for discussion, which I=E2=80=99m happy to participate in if = there=E2=80=99s interest.

Bryan

= --Apple-Mail=_7E4C1877-54D8-49D7-91CE-7E07B7BFBD59-- --Apple-Mail=_1FBF5185-0171-4393-A96B-410817E8E944 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaBuKeAAoJEGt1rlrP7+d/dCEQAK7iDSfojIXO3076rziMlEuE cF10lZFrzLnHTG6n7Uol7mNlNLIiYqp0SRwCjPFJwnTvFBAFiu9QKp+0qFRDbsH7 oub1PPmzSwUInVT2qMSlOCR5jaXuHQ6mPdyzRqrxv61mwGLIfmOejDh4+Qxe/xkk eLVfa2KH+mRkfc3CEkJI31soXMf062s/9TNl3y4RUizLjJckO6WoeKW2vpVdnJA2 0UEde9WgO6zqMnfTKH0QgSbTimGIMcAyn25V8P1TJXCydtCg6i770oN14kNOagjs rYcB25A3VLF4P+uyORni3O3oFo4mYZfiEmA27Xk2wrSoUXVLoxrZHUjTd1AZofie QG4LAXTn/erpCXruU+6y/j4P4jI84c/aIapKiZYij4XYbFuLY3uunypXbqaBufby 0VOHzope1r9WvqhZnRCVhgQenJ5V6X/UNmboI32esAzVVifN8YG8D8OXRhrAc9TN 25pzs3l7zciQaOX/oFrlb41Cwr1sHD1TRWi0oJL5H/9CKeFPqpG7AgJAHpZhCPP9 j9LuQujEr2idAhKYAxvvZVVGTXgPJG0SDh1i+vP2KstNdV8y+5maCaOV6MGsIfbf 4fZ/vY2ADBwjTyOf1WQVQ7/8v776mjt3u7q+JAGSIgndxLQv/mOESv+6gnAOtPpo leXOmjPcTDdyZhRAZipr =z12M -----END PGP SIGNATURE----- --Apple-Mail=_1FBF5185-0171-4393-A96B-410817E8E944-- From nobody Sat Nov 11 17:40:54 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A210129438 for ; Sat, 11 Nov 2017 17:40:52 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Vu0xosmi9M9M for ; Sat, 11 Nov 2017 17:40:50 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 A47E2129415 for ; Sat, 11 Nov 2017 17:40:50 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id x65so8209987vkx.1 for ; Sat, 11 Nov 2017 17:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VqFO4bTchkth3O5703kv7SNRuQ1VDW2o4KCQ9BjoWnU=; b=MSvNbjOyXHIoU746rW5Ncv4BwQluTg9JW6Uj8J+17DPqvDQGwMCwc1n/+E+5Zd/GHM iKSdu3xiI2PuhrxtvoFxZpsDJr/Q/ShtJRVBBb0j7xKOWRoXp2Py34eu4hTe7ceqlZZn FXSd1YoFBYKTsox8YwKtbmX4a2KgjRUg5p3762smUma4C7Azx0HtK6MrSD5HqpbDUCfs CmZ/5PyLxu78LbBn3JwC/ULq94M5gtV8EKif9Ly1LHCWr6iR5rVsJssF5+eP42XAv3nt TRwassebxXsmMKzs/OflSDcnUI2Ffryh070sehtmJRarMErqPdjZyzFZ/gj+JEAQ3F9y m3NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VqFO4bTchkth3O5703kv7SNRuQ1VDW2o4KCQ9BjoWnU=; b=jPI/eFaUkh9/bXkjXy5etD4i5pzSodV8i+x0dZ8tq7SqdcyrDZKzTqQH6iI+6nhprI W2r67SzgCNtvlDJEqtqFApjCQvzuUA4PLPY7P/s8Rbsvrv2PNteLVxBPkRvNxQVUDVSn CAFdwfqD/cbPVyoC2n2OSXTVNtD/sIMof42IRdkHCmyWbV4gRnSkpPFGkL10dTm9NPV8 FcAwnEmdaBrErDtFrADw9klAc76gV9fZpgBT2MDi6MR0EOSEIIBYiaoEhM3U0un4Nt7Y WKJst3Tf5sSjtYfo8GX2rzGPxg3TmaPPSGv3lQg2qhV+ThaaWn/NvvPBZS2WMaPmzzy5 eFcQ== X-Gm-Message-State: AJaThX7w0vF0ho6o0HVs+g5+tK+Fz56m0I3LUIXyWv2OocTwiTBHLtTF uAjQZMx8y46tDtxqnWg0Hxn2x+Dr3hnaUn/JBuM= X-Google-Smtp-Source: AGs4zMZKcMU7SaxbcS9mdSQfwmWjyC1eHZ8f3dxEuBm+mqiXRsfffvpi69e+Ei/Q958N0mOp8oYbrxVDt6QzEcGYmZk= X-Received: by 10.31.32.70 with SMTP id g67mr3119684vkg.9.1510450849592; Sat, 11 Nov 2017 17:40:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.11.132 with HTTP; Sat, 11 Nov 2017 17:40:49 -0800 (PST) In-Reply-To: References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> From: Watson Ladd Date: Sat, 11 Nov 2017 17:40:49 -0800 Message-ID: To: Bryan Ford Cc: Al Cutter , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Eran Messeri , "trans@ietf.org" , Melinda Shore Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Nov 2017 01:40:52 -0000 On Sat, Nov 11, 2017 at 3:44 AM, Bryan Ford wrote: > On Nov 8, 2017, at 3:59 PM, Al Cutter wrote: > > I'm a fan of short-lived certs, but I'm not particularly keen on the idea of > not logging publicly rooted certs - the point of CT is the discoverability > of misissuance after all, and it does seem that having an SCT which could > refer to a whole set of "similar" yet unlogged certs is not a great idea, > e.g. a scenario where the key is compromised by an entity which can coerce > the CA into issuing more "non-logged" certs to cover any period the proud > new owner of the key material would like. > > > 100% agreed on this point. Short-term certs are good, and they all should - > and can - be publicly logged to ensure transparency. To whatever extent > this capacity issue is a problem in the current CT design, this is a problem > with CT that needs to be fixed. What are the problems we are trying to solve with short-term certs and can we come up with a way to solve them that doesn't have the implications for CT of the current proposal? TLS delegated credentials seem to do what we want, but maybe I don't understand the problem well enough. Pruning chains of expired certs has implications for misbehavior detection. Sincerely, Watson From nobody Sat Nov 11 18:22:53 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE5128796 for ; Sat, 11 Nov 2017 18:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 55BC9Jk_5hqT for ; Sat, 11 Nov 2017 18:22:49 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40112.outbound.protection.outlook.com [40.107.4.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222E1124BFA for ; Sat, 11 Nov 2017 18:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3K06y09NJdx6pfCMBv/hZK7etRiCJj6hFJFmJFNGlaw=; b=VDQn0uVTujtu9nYcuelo1E99g/p6FD1uMX4RnRV2mzkzI94b2qDiN/kvo3fO6AZNZsrCMlYNhVBPjqE2nV5F0+JTV71g/oTPx2JDYDaYFnbYcqzeuAEOxTwGLMmMnkzyuBrEkOocQjreNuU+0HU5OGx+pB+0zfFkjv3mBeozF5c= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Sun, 12 Nov 2017 02:22:46 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0218.011; Sun, 12 Nov 2017 02:22:45 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Watson Ladd , Bryan Ford CC: Al Cutter , Eran Messeri , "trans@ietf.org" , Melinda Shore , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Trans] STAR & CT coexistence Thread-Index: AQHTV0aAV7AjheL8ZUOOBIUqQvLNtKMH8NYAgABt6ACAAUraAIAAmcmAgABSfYCABIBygIAA6auAgACR0gA= Date: Sun, 12 Nov 2017 02:22:45 +0000 Message-ID: References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [31.133.136.127] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 6:/ohLJFR3YJUUVBAl5hvwU4F82eUi8Qjp9/EVrPYtasHUS7aM8hyL5jW3GPlL+lsOg+2DNvT7mAjvTAexjPc+q1hzR0C97lunfhkr2ENWfuX8t4xEAoh+CS8sF/u5OYU9Ga5QMhrWXWQ5dnzdKuTiApuJXRvLLnNrE6ItULQA9ThAolHzQA0U1tBg0Vv21yeTH0TePg3/pCnH/z/n0LMdmaoKwt2HcQbelIdZHGB/4Bd486bi2LvBKGrHhmmta4JPUu1mNsbbBBd99EuS3qmP7u6mwC4zgIv2KOhaTe2N+hRkRKLnEfk8+q9TocKadEgCdi+EaFg06MI6oJbX460HaghcfSmulHLeRd+PU30SC74=; 5:8eXmsJTprCB2D9xxakCTpSpCPvFl+mcWihX2mHumSp/eK6sRBPUxp2TaIOezbGBuJTm/EPR7wZ70S/w2t2EEP12BOLmLxocghTe44ucby7bCFQfIYsdH8UAAMRMIabzh2IFDpkjkvyAXVQYy5v1cxJywfouoff2Xc2DYxwjP3es=; 24:a47BGbLurmjCcuvI0jpntigp2xPIkijnGBiQn8vIGblzwI6cQA+M+Otv79DZv38JS3DMWpQdSTcDleCGDyoqiYaKgDGaK+hk5ol6uhGNfSI=; 7:yogqnUboduPfFnYfyeWW7T26uO0X+W8SF4MnxNuYqXZXhXIpnJ+g8+4Ykn5iAejhq/zEtGcYAlsgK8GMZkJBp7Z7ljJXEJI2BlHagKTM/WWeySkj8zy4Cqk+cxhJvnjkc606VfIf6ZE1VaH7Ph9/+X5oYyL8tr568xInb5UfWSmKD7RIFBcZeor4ysVtN06guRlqKd3aCP7aXXSbPebau7q8T8zgnpEqx1w2JkEGAY2+SoIpL0UwP+eG3cW1yTYO x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(24454002)(189002)(199003)(6486002)(53936002)(6512007)(229853002)(2900100001)(6506006)(54906003)(4326008)(33656002)(6436002)(6246003)(110136005)(66066001)(316002)(58126008)(102836003)(83506002)(6306002)(97736004)(68736007)(6116002)(86362001)(99286004)(83716003)(107886003)(39060400002)(93886005)(36756003)(3846002)(2950100002)(561944003)(76176999)(966005)(8676002)(50986999)(478600001)(5250100002)(81156014)(3280700002)(5660300001)(101416001)(3660700001)(14454004)(105586002)(7736002)(189998001)(106356001)(8936002)(305945005)(25786009)(81166006)(34040400001)(53546010)(2906002)(82746002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: bfa5cf71-e230-4588-7a5f-08d5297442c8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:VI1PR07MB1102; x-ms-traffictypediagnostic: VI1PR07MB1102: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231022)(920507027)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1102; x-forefront-prvs: 0489CFBAC9 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: bfa5cf71-e230-4588-7a5f-08d5297442c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 02:22:45.5548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102 Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Nov 2017 02:22:51 -0000 SGkgV2F0c29uLA0KDQpPbiAxMi8xMS8yMDE3LCAwOTo0MCwgIldhdHNvbiBMYWRkIiA8d2F0c29u YmxhZGRAZ21haWwuY29tPiB3cm90ZToNCj4gT24gU2F0LCBOb3YgMTEsIDIwMTcgYXQgMzo0NCBB TSwgQnJ5YW4gRm9yZCA8YnJ5bm9zYXVydXNAZ21haWwuY29tPg0KPiB3cm90ZToNCj4gPiBPbiBO b3YgOCwgMjAxNywgYXQgMzo1OSBQTSwgQWwgQ3V0dGVyIDxhbEBnb29nbGUuY29tPiB3cm90ZToN Cj4gPiA+IEknbSBhIGZhbiBvZiBzaG9ydC1saXZlZCBjZXJ0cywgYnV0IEknbSBub3QgcGFydGlj dWxhcmx5IGtlZW4gb24NCj4gPiA+IHRoZSBpZGVhIG9mIG5vdCBsb2dnaW5nIHB1YmxpY2x5IHJv b3RlZCBjZXJ0cyAtIHRoZSBwb2ludCBvZiBDVCBpcw0KPiA+ID4gdGhlIGRpc2NvdmVyYWJpbGl0 eSBvZiBtaXNpc3N1YW5jZSBhZnRlciBhbGwsIGFuZCBpdCBkb2VzIHNlZW0NCj4gPiA+IHRoYXQg aGF2aW5nIGFuIFNDVCB3aGljaCBjb3VsZCByZWZlciB0byBhIHdob2xlIHNldCBvZiAic2ltaWxh ciINCj4gPiA+IHlldCB1bmxvZ2dlZCBjZXJ0cyBpcyBub3QgYSBncmVhdCBpZGVhLCBlLmcuIGEg c2NlbmFyaW8gd2hlcmUgdGhlDQo+ID4gPiBrZXkgaXMgY29tcHJvbWlzZWQgYnkgYW4gZW50aXR5 IHdoaWNoIGNhbiBjb2VyY2UgdGhlIENBIGludG8NCj4gPiA+IGlzc3VpbmcgbW9yZSAibm9uLWxv Z2dlZCIgY2VydHMgdG8gY292ZXIgYW55IHBlcmlvZCB0aGUgcHJvdWQgbmV3DQo+ID4gPiBvd25l ciBvZiB0aGUga2V5IG1hdGVyaWFsIHdvdWxkIGxpa2UuDQo+ID4NCj4gPiAxMDAlIGFncmVlZCBv biB0aGlzIHBvaW50LiAgU2hvcnQtdGVybSBjZXJ0cyBhcmUgZ29vZCwgYW5kIHRoZXkgYWxsDQo+ ID4gc2hvdWxkIC0gYW5kIGNhbiAtIGJlIHB1YmxpY2x5IGxvZ2dlZCB0byBlbnN1cmUgdHJhbnNw YXJlbmN5LiAgVG8NCj4gPiB3aGF0ZXZlciBleHRlbnQgdGhpcyBjYXBhY2l0eSBpc3N1ZSBpcyBh IHByb2JsZW0gaW4gdGhlIGN1cnJlbnQgQ1QNCj4gPiBkZXNpZ24sIHRoaXMgaXMgYSBwcm9ibGVt IHdpdGggQ1QgdGhhdCBuZWVkcyB0byBiZSBmaXhlZC4NCj4gDQo+IFdoYXQgYXJlIHRoZSBwcm9i bGVtcyB3ZSBhcmUgdHJ5aW5nIHRvIHNvbHZlIHdpdGggc2hvcnQtdGVybSBjZXJ0cyBhbmQNCj4g Y2FuIHdlIGNvbWUgdXAgd2l0aCBhIHdheSB0byBzb2x2ZSB0aGVtIHRoYXQgZG9lc24ndCBoYXZl IHRoZQ0KPiBpbXBsaWNhdGlvbnMgZm9yIENUIG9mIHRoZSBjdXJyZW50IHByb3Bvc2FsPw0KDQpB bCB3YXMgcG9pbnRpbmcgb3V0IHRoYXQgbWF5YmUgdGhlIDEwMHggaW5jcmVhc2UgaW4gaW5nZXN0 aW9uICh3b3JzdA0KY2FzZSwgYXNzdW1pbmcgZXZlcnkgY2VydCBiZWNvbWVzIGEgU1RBUiBjZXJ0 KSB3b3VsZCBub3QgYmUgdGhlIGVuZCBvZg0KdGhlIHdvcmxkLiAgQW5kIGV2ZW4gaWYgaXQgd2Vy ZSwgdGhlcmUgbWlnaHQgYmUgc2NhbGFiaWxpdHkgc3RyYXRlZ2llcw0KdGhhdCBtaWdodCBtaXRp Z2F0ZS9maXggaXQ/DQoNCj4gVExTIGRlbGVnYXRlZCBjcmVkZW50aWFscyBzZWVtIHRvIGRvIHdo YXQgd2Ugd2FudCwgYnV0IG1heWJlIEkgZG9uJ3QNCj4gdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB3 ZWxsIGVub3VnaC4NCg0KVGhlIG1haW4gaXNzdWUgd2l0aCBEQyBpcyB0aGF0IHVudGlsIGFsbCB0 aGUgY2xpZW50cyBoYXZlIHVwZ3JhZGVkIHRoZWlyDQpUTFMgc3RhY2sgKGFuZCBldmVuIHRoZW4s IHRoZXkgbXVzdCBkZWNpZGUgdG8gb3B0LWluIERDKSwgc2VydmVyIHNpZGUNCnlvdSBuZWVkIHRv IG1haW50YWluIGEgTFVSSy1ib3ggZmFsbC1iYWNrLCB3aGljaCBpcyBuZWl0aGVyIGNoZWFwIG5v cg0Kc2NhbGFibGUuICBTYWRseSwgdGhlIHVwZ3JhZGUgY3ljbGVzIG9mIGEgU1RCIG9yIGEgQ1BF IGlzIGNvbXBsZXRlbHkNCmRpZmZlcmVudCBmcm9tIHRoYXQgb2YgbW9kZXJuIGJyb3dzZXJzLiAg U2hvcnQtdGVybSBjZXJ0cyBmcm9tIHRoYXQNCnBvaW50IG9mIHZpZXcsIGp1c3Qgd29yayBvdXQg b2YgdGhlIGJveC4NCg0KKFNlZSBhbHNvIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBUTFMgbWFpbGlu ZyBsaXN0IGF0IHRoZSB0aW1lIHRoZSBjYWxsIGZvcg0KYWRvcHRpb24gb2YgREMgd2FzIG1hZGUg WzFdLikNCg0KQ2hlZXJzDQoNClsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3Rscy9jdXJyZW50L21zZzI0MDk4Lmh0bWwNCg0K From nobody Sat Nov 11 20:06:50 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7476A1279EB for ; Sat, 11 Nov 2017 20:06:47 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OY-AVQkDwbtZ for ; Sat, 11 Nov 2017 20:06:46 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 83ED01201FA for ; Sat, 11 Nov 2017 20:06:46 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id b6so9249814pff.10 for ; Sat, 11 Nov 2017 20:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=oZM3QI+mTT9tdSIPkBzxNsQw7VZmJ2MvxCzKyFEdXOs=; b=NCOD4QtU81+SyU2evyKuHeEUU6El7QP4yXiQI1x2Z9FsrWHFOso7mnDwnRIVvHWTis 5W/u4hc2gNrpzlJYHtXe57w5g8R+VQjMdoT/gWldRWVsETyAUtzn66tX3E3ZVdSLcvOm +cfvhCJ+UAu4Cbkta3305OHWX4HkKDUrRELQLIkJWVHgIc/eTkTK2J3pAHiDplkwwlh9 3kPkQ2i2cUOefdMimRu1WjPI2lYS0QQKXJd4mVszbxV3dGJBj+l02EN4QOKmHbnb2FnI i3+nBIM1pFXYsE00i7/YzjhLlM4hpNn/q7KSCZa+fSq/DkUJ4/J9udhO/6l9z3NvxO7/ HS+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=oZM3QI+mTT9tdSIPkBzxNsQw7VZmJ2MvxCzKyFEdXOs=; b=sZXY0iD23ngsJDfGuKYqrfmotw7EgVzXQP7ILWKSgh2ElQCMvj2PN5CCoB3PAhabNP HvUpSfYWolZYxSetDXEqLseu5TckrbUXU58/69bX5Keq94U7fqDw65V1Ch08eU/cJEj0 98tOnTdKGEkH/mNI8TwMknwZUt8U0128BhVU/q3cnMx5NwonOfFo90cscuHPfiHfZmoR 2ZNBbiHuak5cVkiEcuNF47JFrCUhaEhU/SS2T6oMKUgGyoS83bdoiKPDaI3lCtd0e9uO K1URza3mGKaoXEE29wmEdfoI3HMUHMIIwFC9PZR1AY9JkgbyIQQJd1J4uroL3Y/qR5im eUCQ== X-Gm-Message-State: AJaThX5fze9xszzLCHmZ14IiFKlE7a2oMZTlUldd1rtynn32t1Rmj1c5 91zAme3kiyiRAFhL+3l5Bt+Dun+Q X-Google-Smtp-Source: AGs4zMbErUvMT3LiUmQi2+K2tZYzzX6jgeb8XvsRtlN5XqLR23gVguwlue4NkaRcckdxvBocPZ2pyw== X-Received: by 10.98.153.74 with SMTP id d71mr5583766pfe.145.1510459605644; Sat, 11 Nov 2017 20:06:45 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([202.55.67.146]) by smtp.gmail.com with ESMTPSA id v14sm26977536pfd.153.2017.11.11.20.06.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 20:06:44 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: <6b83b90d-0466-1299-d56e-9dfac6d441aa@gmail.com> Date: Sun, 12 Nov 2017 12:06:43 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VmiAIkbWVa1R9nPm6ls41N8RgalTwIsxu" Archived-At: Subject: [Trans] Slides, please X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Nov 2017 04:06:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VmiAIkbWVa1R9nPm6ls41N8RgalTwIsxu Content-Type: multipart/mixed; boundary="ANLaNOrV3rqhT85bicDGoVRnIebrcKdtu"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <6b83b90d-0466-1299-d56e-9dfac6d441aa@gmail.com> Subject: Slides, please --ANLaNOrV3rqhT85bicDGoVRnIebrcKdtu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, all: This is a friendly reminder to send me your slides for tomorrow's session (many thanks to Linus for getting his slides to us early). Melinda --ANLaNOrV3rqhT85bicDGoVRnIebrcKdtu-- --VmiAIkbWVa1R9nPm6ls41N8RgalTwIsxu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloHyNMACgkQuIZGkzoe gS66LhAAkR8SfaX1hO4ith06CzlLI6HmEaY8KXWb/rtmkQT+yTAMbBfKlC4Nw06p wpM96X7W2HYTd3HVFjgQCiRv4aJWEk7fxuVhdMu5nPu2ESG5EyDQdIdMIXy9tAgz +weuHm/NGNFhSB7ycIx0BiYoZB/ii0msfrcGIpFU42b+ahXugT+JBdxauTueVil3 BZIVUJy1udZ2HdNORMPojX7L2JqSCGc6sDSptXdRi1T4Z7Ol8tAOmbgxoPxT4Vt/ EQP++DvQieI4wBOOcAeVcfEY+amy835koWCF/XgprlJxY4MmvKEOKcsW5aAAhBmC UyX5RgAlhpeTXVLfuKfqqtkwERgfDL4PM9rVLEv5UKP1PxpKaLahJ4xqphYK/ro0 +lKkC8skFjrQiu3xkiZ1dUO06nmqPsCQRhOwMhC995PyFoD0rZYnZ4YtxYXD0+VZ TTJ7IudK2So3eY0vpDEPZkadN+x3Wk/Je8Wb+g0MllRiTgW6swUYO0MWnBxeA8lz HvG00Ex6UDGl5s0MJQgAAW1WsyD8xo+2IADMvmhU+ZPknrdaDhjzN/N/60KJXItL I0mnlh7KimSMrh0QUXgRA8iZsIv+nfm5SiPZ7B02+u+cZfNX8PaLa+ZPiVgJah+X eNMofThJ3Jmzcg4BmWjMHVK0G8fOKWqPU3CzGEEcJIPWFkOklIQ= =rRUm -----END PGP SIGNATURE----- --VmiAIkbWVa1R9nPm6ls41N8RgalTwIsxu-- From nobody Sat Nov 11 20:25:32 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1701275F4 for ; Sat, 11 Nov 2017 20:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 pHVTan3F-M5a for ; Sat, 11 Nov 2017 20:25:28 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 A8816126C0F for ; Sat, 11 Nov 2017 20:25:28 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id r186so2591141ywe.13 for ; Sat, 11 Nov 2017 20:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UXtpgNpvn7wSGd87Z/29KKeCWHZ4AT0bndVkXZ5acVc=; b=JecFPn5qqk7HCi4IlNryrrhLUC9fW/DUCKneGtCz6ymvXGcMmVsjlSLmXBBU267TNv UeawmGUr/xHKBR9z73KWd1BmTM7FDDDEkHTYnqXjD9f2XMeW3VViyvvS233TxOTfmPkU gGp7KWr6o61qrHjt8o8J+EwNPBWMX5h1fsTCt4BMowZ3T63ZcNtHLYm/+VyM+kBm+eqd zCHxBDVKB88ZVOZqsoaCp0yuO4GY+5IZtFqODRUGupRUpNLpPFPoj+nj7iTAMC7598o6 YQrGdLv1uak/rP1IhVAaeTtXX7WeR3dBRmIj5SWaOLVtm1PzLEemdiOujPmyAnwv6aXT Bllg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UXtpgNpvn7wSGd87Z/29KKeCWHZ4AT0bndVkXZ5acVc=; b=MBQQio5y0LtdSlGYCW6oXRzapAICtu8JMUSvumPllzswgiwnyr44YhN4PfVmrKCWlM ViFIcIg8+O9ZLmV8UluE1nsVvKrMJhfPygR0QeMyRH+hLGc1ypJmoKOT/MyFeYhQdhon 4tammp3FreIjfli/3SNJMueXYocrjWq4G7Jzx7XYctQDV4EzFT0zavQFC+sE24Q26Pgg wxhmUPlmtTBbuhvs9XhU4E24BMy+q0hAG3lEQ/gyDFiqmgF0i7COmsEcdWMoWbjQ+dO1 I1Fw71iaKjFA8vVDnDU2oVrX6vgv33EdQM9AwzKYr2AAz5Axgw59VtTMv73G9gtTye7M TG8A== X-Gm-Message-State: AJaThX6/zt1JprFhYyk225JMV82xRMxvRolVTByWzUoy3Zj2WIcC6xS8 AG25moqjq7GyjDD4XpbYvEZPM1O0Jp5FN64GqRpvur/8FC8= X-Google-Smtp-Source: AGs4zMbxDL7PHeOMWx6CtbAA6qSm3ybElzTZsnUzltPpO+wCXXfF9v8qyysTKG+fN2aq/4scJ2/gFqUu/4seF/m+wwo= X-Received: by 10.13.192.196 with SMTP id b187mr3584607ywd.416.1510460727616; Sat, 11 Nov 2017 20:25:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Sat, 11 Nov 2017 20:24:47 -0800 (PST) From: Eric Rescorla Date: Sun, 12 Nov 2017 04:24:47 +0000 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary="001a114edd481dfaf5055dc18bec" Archived-At: Subject: [Trans] Comments on draft-ietf-trans-threat-analysis-12.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 12 Nov 2017 04:25:30 -0000 --001a114edd481dfaf5055dc18bec Content-Type: text/plain; charset="UTF-8" This document appears to be in pretty good shape. I noted a few minor areas for improvement, mostly editorial. S 1. A relying party (e.g., browser) benefits from CT if it rejects a bogus certificate, i.e., treats it as invalid. An RP is protected from accepting a bogus certificate if that certificate is revoked, and if the RP checks the revocation status of the certificate. (An I would add "directly" after benefits, because, as you note later in this section, it also benefits of CT leads to revocation of a bogus cert. Figure 1: In this diagram, all the left
This document appears to be in pretty good shape. I n= oted a few minor
areas for improvement, mostly editorial.


S 1.
=C2=A0 =C2=A0A relying = party (e.g., browser) benefits from CT if it rejects a
=C2=A0 =C2= =A0bogus certificate, i.e., treats it as invalid.=C2=A0 An RP is protected<= /div>
=C2=A0 =C2=A0from accepting a bogus certificate if that certifica= te is revoked,
=C2=A0 =C2=A0and if the RP checks the revocation s= tatus of the certificate.=C2=A0 (An

I would add &q= uot;directly" after benefits, because, as you note later
in = this section, it also benefits of CT leads to revocation of
a bog= us cert.


Figure 1:
In thi= s diagram, all the left <s are missing. I expect you have
a fa= ilure to escape.

S 2.
=C2=A0 =C2=A0To ma= ke use of forged web site certificates, an adversary must be
=C2= =A0 =C2=A0able to direct a TLS client to a spoofed web site, so that it can=
=C2=A0 =C2=A0present the forged certificate during a TLS handsha= ke.=C2=A0 An adversary
=C2=A0 =C2=A0may achieve this in various w= ays, e.g., by manipulation of the DNS
=C2=A0 =C2=A0response sent = to a TLS client or via a man-in-the-middle attack.=C2=A0 The

=
I'm not sure I would characterize this as a MITM attack, but= rather
as an active attack on the TLS connection itself. Maybe
"by manipulation of the DNS response... or, in the case of an=
on-path attacker, directly intercepting the TLS connection"=


=C2=A0 =C2=A0"malicious"= CA.=C2=A0 A nation state also might compromise a CA in another
= =C2=A0 =C2=A0country, to effect issuance of bogus certificates.=C2=A0 In th= is case the

Why limit this to "in another cou= ntry"? This form of attack is also
available in the same cou= ntry.


S 3.2.1.1.1.
The fa= ct that CT doesn't ensure revocation is a really good point.
= I think it would be worthwhile to make this point earlier, perhaps
in Section 1 where you discuss the basic theory of CT. I'd also
=
expand on this in two ways:

- A CA can use OC= SP stapling to indefinitely extend the lifetime
=C2=A0 of a revok= ed certificate (you observe this in S 3.5)

- If a = CA is able to pass off deliberate missisuance as accidental
=C2= =A0 misissuance, it can in effect issue a completely bogus cert
= =C2=A0 and keep it live permanently without consequence.


S 3.2.2.1.
Although there is nothing in IET= F, Chrome has announced plans to
require CT for certificates with= issuance dates after a certain
flag day, thus resulting in a gra= dual phase in, so it's probably
worth noting that at least in= some cases people are working on
this.

= S 3.3.
=C2=A0 =C2=A0discussions in Section 3.2 are applicable.=C2= =A0 Section 3.3 explored the
=C2=A0 =C2=A0undetected compromise o= f a CA in the context of attacks designed to
=C2=A0 =C2=A0issue a= bogus certificate that might avoid revocation (because the
=C2= =A0 =C2=A0certificate would appear on distinct certificate paths).

As this phrase appears in S 3.3, I think you have a mistak= e here of
some kind.


S 4.= 1.1.1.
You seem to have some sort of rendering error where you re= peatedly
have "(pre )certificate" rather than "(pr= e-)certificate")


S 4.2.1.1.
Please expand CCID on first user here.

-Ekr



--001a114edd481dfaf5055dc18bec-- From nobody Sun Nov 12 21:55:59 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316681287A5 for ; Sun, 12 Nov 2017 21:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 y-zcrX4mzuGA for ; Sun, 12 Nov 2017 21:55:52 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 16876127977 for ; Sun, 12 Nov 2017 21:55:52 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id i198so12545029ywe.7 for ; Sun, 12 Nov 2017 21:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=U323m8CgoM5XE/vVaVhCb+is06o4GCLiQUK914aayL8=; b=ker8p5lNHD8YxaMM4/3yWXtkgnl/1qWJ4I9m3CShLVtIV9tfIXUMPX3qg32PWjSFdw X/aBfhNYxUADnsJENJTEBIyB7tEvHcPbIbHrE5cg76i9u9ZYw0ryQGs2WCSHPCKngBME h0+sbpUIK+1b6c2C9xpCHJF1oCej/hHLUelia4159LI9NTRFiQkkT38n3jjUdTLAmU4A UMk/ON4Gy0utTkD98SgHzjvkYPACHdMBpw/u5OJ0J2pVnHdejT2KAPDLhUunrJOA7YSM Zq9yShGPdVRfz/ixq0nlHClpEG698aO54IVbkOJgsvvEsZjsrkBjHuaHSMr14YrhAUaP r3Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U323m8CgoM5XE/vVaVhCb+is06o4GCLiQUK914aayL8=; b=mHLLFuiNSHz3n94jfQ5EH4s20xCTkn0tDOjmhKCN1tYAaeq8Nz5Hrlea9eGnGj7x7w L6MvlGcTPhtpnnJVPkRmf5k/l6eypli/xFFhuzaluprMnWflHfLVOwHpFoRDmjLlyE4e OzGzhfajuOBs4ywGnvdW91fH96UVkiTXUGX3bg/J7G5Zmp9W10esmnvOcuO5gNtKWN/s pRurdXoSPlqudYeM6mGrfIFzP8fiT+YcCWVs9zWwaebpoOcoCAsq90TrpDdncMeVNiyJ 4wPPfXMFB9cLmov2ZK30Czk1diu4+2S0OQQRHRIlXSqqXtoCe+mqDpe8wLxWin9I/e3u +3IQ== X-Gm-Message-State: AJaThX7D8I+UlfTjVMqtbgwgj4Of9mG0DRs6/qEwctMyezT6FCRU9UyX zuij9MJtOzKlqKA1+DfJDp3ks+ZbqBpcZGTgqStr7ERB X-Google-Smtp-Source: AGs4zMbg4ElaWl9Dl3dw5R2PnnLxBcvlmNo3hsMrcbSEE8hYLSaLOfiX7msZmVo5fc7LkK/ma/6jNXrKIHI8tNRdSmA= X-Received: by 10.37.130.77 with SMTP id d13mr4718910ybn.397.1510552551061; Sun, 12 Nov 2017 21:55:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Sun, 12 Nov 2017 21:55:10 -0800 (PST) From: Eric Rescorla Date: Mon, 13 Nov 2017 05:55:10 +0000 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary="089e0828e4f8388d33055dd6ecd3" Archived-At: Subject: [Trans] Followup on draft-ietf-trans-rfc6962-bis-26.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 05:55:56 -0000 --089e0828e4f8388d33055dd6ecd3 Content-Type: text/plain; charset="UTF-8" Responses to author comments and the changes in the new version. ---------- Forwarded message ---------- From: ekr (Eric Rescorla) Date: Mon, Nov 13, 2017 at 5:34 AM Subject: [Differential] [Requested Changes] D13: draft-ietf-trans-rfc6962-bis-26.txt: 2017-08-18 16:09:04.815339 To: ekr@rtfm.com ekr requested changes to this revision. ekr added a comment. This revision now requires changes to proceed. View Revision This looks pretty good, but I have a few notes below on things that I still think need to be addressed. *INLINE COMMENTS* View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:157 Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/274 LGTM. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:336 The blank line between "history tree" and "[CrosbyWallach] proposal"? I've no idea. I only see it here on Phabricator. It's not in the source .md file. kramdown-rfc2629 doesn't add it. "xml2rfc --raw" doesn't add it. "xml2rfc --text" does have a page break at this point though. Could it be a strange artefact of importing the .txt doc into Phabricator? Yeah, probably. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:625 Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/275 "see Section 5.7 might help here", but this is OK View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:763 Noting that EKR and Ben disagreed on "chose to limit it" versus "chooses to limit it", I propose "imposes any limit", which sidesteps the question of precisely when the log operator made the choice and instead simply refers to the expected current behaviour. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/277 LGTM View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:785 How else could we achieve our goal (i.e., "To avoid being overloaded by invalid submissions")? Permitting submitters to submit partial chains would require logs to do path construction. This would add complexity to log implementations and would result in the submission process becoming significantly less deterministic: not all logs would have prior knowledge of all existing intermediates; fetching missing intermediates can be unreliable (e.g., AIA->caIssuers URLs absent, or returning HTTP 404, etc). The submitter probably possesses the complete chain already; and if they don't, they might be better placed (than the log) to obtain any missing intermediates (i.e., the submitter might be the CA or a customer of the CA). Therefore, it seems reasonable to require the submitter to provide the complete chain; operational experience with RFC6962 has not found this to be a problem in practice. BTW, note that there are tools available to assist submitters with the task of constructing a chain. e.g., https://crt.sh/gen-add-chain You might avoid being overloaded by charging people to log stuff with your log. I'm not arguing that you shouldn't require submission of complete chains, I'm saying I don't understand why MUST verify is a conformance requirement. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:816 Superfluous certificates are not allowed. The "chain" input to the submit-entry API (section 5.2) is defined as follows: "An array of zero or more base64 encoded CA certificates. The first element is the certifier of the submission; the second certifies the first; etc. The last element of chain (or, if chain is an empty array, the submission) is certified by an accepted trust anchor." Given the extensive use of cross-certification in the Web PKI, there may be multiple possible chains for a given certificate that a log would accept. In this case, the submitter may submit any one of those chains. >From the TRANS list: EKR: Hmm... So your theory is that the submitter does path construction Ben: Yep - and that's borne out by practice. EKR: OK, well, then it would help if the document were clearer on this point. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/278 (which clarifies that the submitter does path construction). OK. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:837 >From earlier in the document... "1.2. Data Structures Data structures are defined and encoded according to the conventions laid out in Section 4 of [RFC5246]." However, I suppose we should revise this TLS 1.2 reference to refer to TLS 1.3 instead... Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/279 OK. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:926 That's true, but what's the most logical and sensible lower bound to put in the document? This PKIX thread concluded that the smallest well-formed certificate is 66 octets: https://mailarchive.ietf.org/arch/search/?q=World%27s+smallest+well-formed+ certificate I could change our definition from... opaque TBSCertificate<1..2^24-1>; ...to... opaque TBSCertificate<66..2^24-1>; ...but wouldn't this just cause readers to waste time scratching their heads and wondering "why 66?" ? BTW, TLS 1.3 -21 section 4.4.2 says... case X509: opaque cert_data<1..2^24-1>; So I'm minded to leave our definition as it is. OK. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:948 Andrew Ayer wrote: "That's not a problem, since the name of the CA is included in the Issuer field of the TBSCertificate, which is part of the Merkle leaf input along with the CA's public key hash." OK, so it seems like it's safe, but it also seems like the claim about what the hash does may not be correct. Or am I confused? View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:970 It's daft, but might a log's parameters ever declare a signature algorithm of "null" for testing purposes? BTW, "opaque signature<0..2^16-1>;" appears twice in TLS 1.3 -21. PR wanted for TLS 1.3 :) Anyway, I am OK with leaving it as is, I suppose View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1163 Ben wrote "The normative requirements are in the various messages below." OK. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1432 https://github.com/google/certificate-transparency-rfcs/pull/281 puts these into a table. LGTM View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1435 Ben wrote "union would probably be a better word." Also being addressed by https://github.com/google/ certificate-transparency-rfcs/pull/281 LGTM View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1522 Ben wrote "The response includes an STH, which says how big the tree is. Probably should be the latest one known to that server." Also, note that section 8.2 (Monitor) expects monitor clients to fetch and verify the latest STH using get-sth before fetching entries using get-entries. OK. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1599 Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 Thanks View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1627 There's another place in the document where we concatenate TransItems, and that also uses TransItemList - see section 7.1 (Transparency Information X.509v3 Extension). Why wouldn't our approach suffice in any other places you might want to concatenate TransItems? We've been trying to make SCTs and other TransItems as small as possible, so that they add as little bloat as possible to certificates, OCSP responses and TLS handshakes. The theory is: less bloat == less resistance to adoption. I wouldn't do this this way, but it's a WG decision. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1649 Section 6 of the document says (emphasis mine): "TLS servers MUST use at least one of the three mechanisms listed below to present one or more SCTs from one or more logs to each TLS client during full TLS handshakes, **where each SCT corresponds to the server certificate**." So yes, there is no explicit support for CT entries for intermediate certs. Should there arise a need for this, note that the extension is extensible (i.e., further VersionedTransType values could be defined by future documents). IIRC, TLS1.3 will have per-certificate TLS extensions, so it may be simple to accommodate CT entries for intermediates for TLS1.3. Thanks. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1651 This section defines requirements for CT-using TLS Servers, so it's not the appropriate section in which to require that clients send an empty extension. Section 8.1 defines the requirements for TLS Clients; subsection 8.1.1 (Receiving SCTs and inclusion proofs) already says: 'TLS clients that support the "transparency_info" TLS extension SHOULD include it in ClientHello messages, with empty "extension_data".' Requiring "the server to validate that it is in fact empty" is being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 OK. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1654 I think part of the reason we wrote this "SHOULD" is that we want to encourage the use of the "transparency_info" TLS extension, because it offers more agility than embedding TransItems in certs / OCSP responses. But yes, we want to avoid duplicating the same information, and I agree that the current text needs some improvement in that regard. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 LGTM. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1722 I'm not yet sufficiently familiar with the TLS 1.3 draft to be able to do that. I guess I can live without it. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1823 Isn't this already covered by "CT-using TLS servers MUST use at least one of the three mechanisms listed below to present one or more SCTs from one or more logs to each TLS client during full TLS handshakes..." ? i.e., If a TLS server elects to not use "transparency_info", then it follows that it "MUST use" at least one of the other two mechanisms (SCTs embedded in the cert or stapled OCSP response)! "Trying to reconstruct the reasoning here" We could be more explicit about the reasoning. Being addressed by https://github.com/google/certificate-transparency-rfcs/pull/283 LGTM. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1912 That's covered by the paragraph below: A TLS client (Section 8.1) can audit by verifying an SCT against any STH dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle inclusion proof (Section 5.4). OK. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2009 That was the outcome of this thread: https://mailarchive.ietf.org/ arch/search/?q=The+RFC6979+requirement+in+RFC6962-bis+is+bad OK View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2150 Fair enough. I propose to switch to First Come First Served then. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/287 LGTM. View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2163 I think you're referring to the "or that the log has misbehaved, which will be discovered when the SCT is audited" clause, which I'll therefore propose to drop. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/288 LGTM View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2237 The risk is against "Clients that gossip STHs or report back SCTs can be tracked or traced if..." Not sure about incentives. Maybe we should change it to a MUST, so that violating this requirement becomes a clear case of log misbehaviour? I think "tracked or traced" by who. As far as a deterministic scheme, that seems like a wg decision, but what would be the implication for RSA-PSS? View Inline robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2243 I'll propose to rephrase this as "By requiring...TLS clients reduce..." Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 LGTM. View Inline draft-ietf-trans-rfc6962-bis.txt:2006 the "transparency_info" extension in the ServerHello with the "extension_data" set to this "TransItemList". I think this last point needs to be a MUST if you want to ensure the client gets the data. View Inline draft-ietf-trans-rfc6962-bis.txt:2304 6. Repeat from step 6. This doesn't seem right, because this is step 6. *REPOSITORY* rIETFREVIEW ietf-review *REVISION DETAIL* https://mozphab-ietf.devsvcdev.mozaws.net/D13 *EMAIL PREFERENCES* https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/ *To: *ekr-moz, ekr *Cc: *robstradling --089e0828e4f8388d33055dd6ecd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responses to author comments and=C2=A0 the changes in the = new version.

---------- Forwarded messag= e ----------
From: ekr (Eric Rescorla)= <mozphab-= ietf@mozilla.com>
Date: Mon, Nov 13, 2017 at 5:34 AM
Su= bject: [Differential] [Requested Changes] D13: draft-ietf-trans-rfc6962-bis= -26.txt: 2017-08-18 16:09:04.815339
To: = ekr@rtfm.com


ekr requ= ested changes to this revision.
ekr added a comment.
This revision no= w requires changes to proceed. 		View Re= vision

This looks pret= ty good, but I have a few notes below on things that I still think need to = be addressed.


INLINE COMMENTS
=

View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:336

The blank line between "history tree" and "[= CrosbyWallach] proposal"? I've no idea. I only see it here on Ph= abricator.

It's not in the source .md file. kra= mdown-rfc2629 doesn't add it. "xml2rfc --raw" doesn't ad= d it. "xml2rfc --text" does have a page break at this point thou= gh. Could it be a strange artefact of importing the .txt doc into Phabrica= tor?

Yeah, probably.


View Inli= nerobstradling wr= ote in draft-ietf-trans-rfc6= 962-bis.txt:625

"see Section 5.7 might help here", but this is OK


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:763

Noting that EKR and Ben disagreed on "chose to limit i= t" versus "chooses to limit it", I propose "imposes any= limit", which sidesteps the question of precisely when the log operat= or made the choice and instead simply refers to the expected current behavi= our.

Being addressed by https://githu= b.com/google/certificate-transparency-rfcs/pull/277

=

LGTM


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:785

How else could we achieve our goal (i.e., "To avoid be= ing overloaded by invalid submissions")?

Permitting submitters to submit partial c= hains would require logs to do path construction. This would add complexit= y to log implementations and would result in the submission process becomin= g significantly less deterministic: not all logs would have prior knowledge= of all existing intermediates; fetching missing intermediates can be unrel= iable (e.g., AIA->caIssuers URLs absent, or returning HTTP 404, etc).

The submitter probably possesses the comp= lete chain already; and if they don't, they might be better placed (tha= n the log) to obtain any missing intermediates (i.e., the submitter might b= e the CA or a customer of the CA). Therefore, it seems reasonable to requi= re the submitter to provide the complete chain; operational experience with= RFC6962 has not found this to be a problem in practice.

BTW, note that there are tools available = to assist submitters with the task of constructing a chain. e.g., https://crt.sh/gen-add-chain

You might avoid being overloaded by charging people to log stuff with you= r log.

I'm not arguing that you shouldn'= t require submission of complete chains, I'm saying I don't underst= and why MUST verify is a conformance requirement.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:816

Superfluous certificates are not allowed. The "chain&= quot; input to the submit-entry API (section 5.2) is defined as follows: 

"An array of zero =
or more base64 encoded CA certificates. The first element is the certifier =
of the submission; the second certifies the first; etc. The last element of=
 chain (or, if chain is an empty array, the submission) is certified by an =
accepted trust anchor."

Given the extensive use of cross-certific= ation in the Web PKI, there may be multiple possible chains for a given cer= tificate that a log would accept.
In this case, the submitter may submit any one of those chains.

From the TRANS list:
EKR: Hmm... So your theory is that the submitter does path construction Ben: Yep - and that's borne out by practice.
EKR: OK, well, then it would help if the document were clearer on this poin= t.

Being addressed by https://githu= b.com/google/certificate-transparency-rfcs/pull/278 (which cl= arifies that the submitter does path construction).

OK.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.= txt:837

From earlier in the document...

"1.2. Data Structures

Data structures are def=
ined and encoded according to the conventions
laid out in Section 4 of [RFC5246]."

However, I suppose we should revise this = TLS 1.2 reference to refer to TLS 1.3 instead...

Being addressed by https://githu= b.com/google/certificate-transparency-rfcs/pull/279

=

OK.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.= txt:926

That's true, but what's the most logical and sensib= le lower bound to put in the document?

This PKIX thread concluded that the small= est well-formed certificate is 66 octets:
https://mailarchive.ietf.org/arch/se= arch/?q=3DWorld%27s+smallest+well-formed+certificate

I could change our definition from...
opaque TBSCertificate<1..2^24-1>;
...to...
opaque TBSCertificate<66..2^24-1>;
...but wouldn't this just cause readers to waste time scratching their = heads and wondering "why 66?" ?

BTW, TLS 1.3 -21 section 4.4.2 says... 

case X509:
  opaque cert_data<1..2^24-1>;

So I'm minded to leave our definition= as it is.

OK.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.= txt:948

Andrew Ayer wrote:
"That's not a problem, since the name of the CA is included in the= Issuer field of the TBSCertificate, which is part of the Merkle leaf input= along with the CA's public key hash."

OK, so it seems like it's safe, but it also seems like the claim abou= t what the hash does may not be correct. Or am I confused?

<= br>
View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:970

It's daft, but might a log's parameters ever declar= e a signature algorithm of "null" for testing purposes?

BTW, "opaque signature<0..2^16-1&= gt;;" appears twice in TLS 1.3 -21.

PR wanted for TLS 1.3 :) Anyway, I am OK with leaving it as is, I suppose=


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:= 1163

Ben wrote "The normative requirements are in the vario= us messages below."

OK.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.= txt:1432

LGTM


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1435

Ben wrote "union would probably be a better word."= ;

Also being addressed by https://= github.com/google/certificate-transparency-rfcs/pull/281

<= /div>

LGTM


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1522

Ben wrote "The response includes an STH, which says ho= w big the tree is. Probably should be the latest one known to that server.&= quot;

Also, note that section 8.2 (Monitor) exp= ects monitor clients to fetch and verify the latest STH using get-sth befor= e fetching entries using get-entries.

OK.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.= txt:1599

Thanks


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1627

There's another place in the document where we concaten= ate TransItems, and that also uses TransItemList - see section 7.1 (Transpa= rency Information X.509v3 Extension). Why wouldn't our approach suffic= e in any other places you might want to concatenate TransItems?

We've been trying to make SCTs and ot= her TransItems as small as possible, so that they add as little bloat as po= ssible to certificates, OCSP responses and TLS handshakes. The theory is: = less bloat =3D=3D less resistance to adoption.

I wouldn't do this this way, but it's a WG decision.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1649

Section 6 of the document says (emphasis mine):

"TLS servers MUST =
use at least one of the three mechanisms listed
 below to present one or more SCTs from one or more logs to each TLS
 client during full TLS handshakes, **where each SCT corresponds to the
 server certificate**."

So yes, there is no explicit support for = CT entries for intermediate certs. Should there arise a need for this, not= e that the extension is extensible (i.e., further VersionedTransType values= could be defined by future documents).

IIRC, TLS1.3 will have per-certificate TL= S extensions, so it may be simple to accommodate CT entries for intermediat= es for TLS1.3.

Thanks.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.<= wbr>txt:1651

This section defines requirements for CT-using TLS Servers,= so it's not the appropriate section in which to require that clients s= end an empty extension. Section 8.1 defines the requirements for TLS Clien= ts; subsection 8.1.1 (Receiving SCTs and inclusion proofs) already says: 

'TLS clients that
support the "transparency_info" TLS extension SHOULD include it i=
n
ClientHello messages, with empty "extension_data".'

Requiring "the server to validate th= at it is in fact empty" is being addressed by https://github.= com/google/certificate-transparency-rfcs/pull/282

OK.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.= txt:1654

I think part of the reason we wrote this "SHOULD"= is that we want to encourage the use of the "transparency_info" = TLS extension, because it offers more agility than embedding TransItems in = certs / OCSP responses. But yes, we want to avoid duplicating the same inf= ormation, and I agree that the current text needs some improvement in that = regard.

Being addressed by https://githu= b.com/google/certificate-transparency-rfcs/pull/282

=

LGTM.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1722

I'm not yet sufficiently familiar with the TLS 1.3 draf= t to be able to do that.

I guess I can live without it.


View Inlinerobstrad= ling wrote in draft-i= etf-trans-rfc6962-bis.txt:1823

Isn't this already covered by "CT-using TLS server= s MUST use at least one of the three mechanisms listed below to present one= or more SCTs from one or more logs to each TLS client during full TLS hand= shakes..." ?
i.e., If a TLS server elects to not use "transparency_info", then= it follows that it "MUST use" at least one of the other two mech= anisms (SCTs embedded in the cert or stapled OCSP response)!

"Trying to reconstruct the reasoning= here"
We could be more explicit about the reasoning. Being addressed by https://github.com/google/certificate-transparency-rfcs/pull/28= 3

LGTM.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1912

That's covered by the paragraph below:

A TLS client (Section 8=
.1) can audit by verifying an SCT against any
STH dated after the SCT timestamp + the Maximum Merge Delay by
requesting a Merkle inclusion proof (Section 5.4).
=

OK.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.= txt:2009

OK


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.t= xt:2150

Fair enough. I propose to switch to First Come First Serve= d then.

Being addressed by https://githu= b.com/google/certificate-transparency-rfcs/pull/287

=

LGTM.


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2163

I think you're referring to the "or that the log h= as misbehaved, which will be discovered when the SCT is audited" claus= e, which I'll therefore propose to drop.

Being addressed by https://githu= b.com/google/certificate-transparency-rfcs/pull/288

=

LGTM


View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2237

The risk is against "Clients that gossip STHs or repor= t back SCTs can be tracked or traced if..."

Not sure about incentives. Maybe we shou= ld change it to a MUST, so that violating this requirement becomes a clear = case of log misbehaviour?

I think "tracked or traced" by who.

As far as a deterministic scheme, that se= ems like a wg decision, but what would be the implication for RSA-PSS?

<= /div>

View Inlinerobstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2243

I'll propose to rephrase this as "By requiring...T= LS clients reduce..."

Being addressed by https://githu= b.com/google/certificate-transparency-rfcs/pull/282

=

LGTM.


View Inlinedraft-ietf-trans-rfc6962-bi= s.txt:2006
the "transparency_info" extension in the ServerHello wit= h the
"extension_data" set to this "TransItemList"= ;.

I think this last point needs to be a MUST if you want to ensure the clie= nt gets the data.


View Inl= inedraft-ietf-trans-rfc6962-bis.txt:2304
6. Repeat from step 6.

This doesn't seem right, because this is step 6.


REPOSITORY=
rIETFREVIEW ietf-review



--089e0828e4f8388d33055dd6ecd3-- From nobody Mon Nov 13 00:58:01 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D49F129510 for ; Mon, 13 Nov 2017 00:57:59 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fQX_a8VKzsWl for ; Mon, 13 Nov 2017 00:57:57 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 519111294F7 for ; Mon, 13 Nov 2017 00:57:57 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id o7so12197286pgc.4 for ; Mon, 13 Nov 2017 00:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=3Zo0GmJR4ZDcLjK3lJyunumY2hKZTRmq6zJHw9Rqtgs=; b=qSzOFDoqPJkUbaZjEziSuWUO3oqD2xrvC6MottfPDnjYekf5Mx9dkzGO9IGTidYpqN 7tzGePs8Ex7lLW6j1ZmwOTYa8ufIbygvA5zbXlsdG0I7eXK+aWruUo1sn8aapefJL+ur FpA9BUIB2xgwEH7sRnPktc6uWPg68WjqsxZOv1xIqu+yME1D9Ckm3SqfXgd4a3nyFvd3 G0w9Yyuj3YL7RtjfgbHTg9YdI46P01+MRhF6JxeFYgK6bFpGw4oLO3B4exSJecyGqDIs BdvOf6hb8zxAei4UlmA5XkBW3Jvau6CX885UdXudJRBAVyvhTfLVQejTlW9hUl6Vxyjg tj7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=3Zo0GmJR4ZDcLjK3lJyunumY2hKZTRmq6zJHw9Rqtgs=; b=qgO+3qcKRYGA6NVVNu8M2uXFhq10R+xwuB6QX3W696v7hVrhFurO3MIKQ0+VVvUcEG gi7el1IeXvb5Cbz8uPQWC4kvam31vNckm2hFG2RgxH6INjdmzuNw6UgDQVjvwW6HvwDm pdlD+poaMbO5TepliT2t7cQuPokv4TPX4i3ZFOAl7+6hd5Hq7tRzBQ05tfNFaEdm3rzP QBKoIiaMLoiZ0ak6WrVmiMhG6Yf+DtDPylJc/rWd1xn4gY18Ck0+r3U9EdOGu4LvQq/M tg6ieWtolHpfnw+ZAZEQhmxdz5/+R2eJ7zb8XL/TDxb7P7RsPo8B0SG2pY5R0gz4RJrQ fx4Q== X-Gm-Message-State: AJaThX5YiOKXVMqxgDlS03Icop82mJY5h5R/wxu/iDtJaMXwfGU0OaNn 9bX9etnFxRGr0vTQ0386NE2lYoFe X-Google-Smtp-Source: AGs4zMZP46lwtJlENS1ph4KUZTkjNUBJ91F7VG70ti1D8ylT2hKOX3lJxbD4AXWXZEm/ZXQD05OpOg== X-Received: by 10.101.86.9 with SMTP id l9mr7734488pgs.297.1510563476719; Mon, 13 Nov 2017 00:57:56 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:51c1:8a20:5b16:d50? ([2001:67c:370:128:51c1:8a20:5b16:d50]) by smtp.gmail.com with ESMTPSA id v25sm4318906pgc.78.2017.11.13.00.57.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 00:57:56 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_89942DC5-52AF-4313-8D42-547FECA608FC" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <7A75414D-EB7A-46D5-9A80-8963306E8E51@gmail.com> Date: Mon, 13 Nov 2017 16:58:56 +0800 To: trans@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Trans] Short-term certificates side meeint X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 08:57:59 -0000 --Apple-Mail=_89942DC5-52AF-4313-8D42-547FECA608FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi As mentioned in the meeting, we=E2=80=99re going to have a side meeting = on Thursday evening at 6 PM in the Hullet room. (Very) rough draft: https://tools.ietf.org/html/draft-nir-saag-star-00 Slides for the side meeting: = https://www.dropbox.com/s/yi9cn35dk8h14te/starcons.pdf See you there. Yoav --Apple-Mail=_89942DC5-52AF-4313-8D42-547FECA608FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

As = mentioned in the meeting, we=E2=80=99re going to have a side meeting on = Thursday evening at 6 PM in the Hullet room.

(Very) rough draft: https://tools.ietf.org/html/draft-nir-saag-star-00

Slides for the side = meeting: https://www.dropbox.com/s/yi9cn35dk8h14te/starcons.pdf

See you there.

Yoav


= --Apple-Mail=_89942DC5-52AF-4313-8D42-547FECA608FC-- From nobody Mon Nov 13 02:14:32 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AC8129478 for ; Mon, 13 Nov 2017 02:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sSrzrfRcY13g for ; Mon, 13 Nov 2017 02:14:30 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 4D576124BE8 for ; Mon, 13 Nov 2017 02:14:30 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id w127so2641943iow.11 for ; Mon, 13 Nov 2017 02:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=58H+IeJNlR1rsAuSRs4biPXA05N4Sody0U7Mt69HGKw=; b=qBmMM71iFWiX9Wk63Kk/HtCUt6/2ogOIql2k6257o6WtxEzERY5ysMtM+IpsH6IcVA kV3KILd8tTQOP0XvDcFEpbclQGzE0pAPdO+I26iXEkvyICNdSB5v03PMVEJANQRlY9VY dpG4DG6M6XmFxav02iy0T4vv65bjOvWsNVfD4XilRXnVI6Dkt6vHYJditQm0VZmddQL/ T9rWL8I3xVvXHQktY0KqiHtKrd4uFsARdvKgK8GGbclUtizlJ52xBx+2KHk5/wQyOcBF DfbnX+nMO0TXVZAUto+KfH7Aj54NyOHqYnjvfHgrzzChvetmdfIj0NK8SXKCoDtS5Uae XwCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=58H+IeJNlR1rsAuSRs4biPXA05N4Sody0U7Mt69HGKw=; b=Wybf7uZmNxXCZouPiwF1oAxVKWEzwZQKyRRePFK6PMg4ei4sG350oYgb6PhU6CRJqi gpTSlfA0fM/crLih3SqkgjZ20/6cLEijOjuWo1uZ7ITo0/eDsgE9fdPHF9aULOdB4nM6 PtEZYjNUJvC4KUQOM3MNZKpXaAk2O9+f2MjAiRopFZ83ajLX39ffQB61Sa7H+zPqBoxW L1ElscaWL3it5qJ/ZC79ty68dtIAjgGOA5fF00yEOJzSZM2fxApZm6sCg2CzUU3AT5CD Z9zIQPVrbs2jN+LRG+E4C9Eh5np9uu6daEiIvVVCrD03BlYcmvPx3Qr/vOTWEZe2knxi 0eWw== X-Gm-Message-State: AJaThX7e398tLdec6ag8IQTHH5/0k/45f1b3r1IdWxJ/SGarcyLgsAmP V5pckEOADVzdMbKYCeDQcQ7kCEFI X-Google-Smtp-Source: AGs4zMZcRxawBQNyfemU8F8L++dYJm0CWEC1050zfjEiUm0FMtmPNFwT/uadB2RW2jgT8+63cMP1hg== X-Received: by 10.107.111.14 with SMTP id k14mr8546263ioc.282.1510568069377; Mon, 13 Nov 2017 02:14:29 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([202.55.67.146]) by smtp.gmail.com with ESMTPSA id e203sm4167147itb.32.2017.11.13.02.14.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 02:14:28 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Mon, 13 Nov 2017 18:14:26 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FPTu2AcUi1gmcNVR1tubOpgGf7HiTOMgi" Archived-At: Subject: [Trans] Minutes uploaded X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 10:14:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FPTu2AcUi1gmcNVR1tubOpgGf7HiTOMgi Content-Type: multipart/mixed; boundary="3MBGJ3BiRUrDqO6PWbHQAGvdfNga503Tx"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: Subject: Minutes uploaded --3MBGJ3BiRUrDqO6PWbHQAGvdfNga503Tx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Minutes from this afternoon's session have been uploaded to: https://datatracker.ietf.org/doc/minutes-100-trans/ Please take a moment to review them and send any updates/ corrections to the mailing list. You'll note that there are several issues requiring discussion, and we'll be bringing them to the mailing list individually. Many thanks to DKG for taking minutes and to Rich Salz for Jabber scribing. Melinda --3MBGJ3BiRUrDqO6PWbHQAGvdfNga503Tx-- --FPTu2AcUi1gmcNVR1tubOpgGf7HiTOMgi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloJcIIACgkQuIZGkzoe gS6RUw/9Ge8MyOi/v+QldbcSVqxKpDNCOCzJMFEPelAzQdDW3DtbzYn591DdfCl3 3sNus7RFkAlrctgs9UuQa4AhmBwkyn9IM2pZ3cHJkHYoF4HIcAYH+cyIh9JPa3O0 e/S4SE3CA9raWW4fIB0Giabyaxzd0nxMiNvtnm06pEwieVuRB5vyPnjmxHn4fDBK yS6lp0URIZQiwQLIGx2Bv5RPAkto6yJdaQV0XbnZX9Gbcd4xZOQCT4a9CQPwglQU EDUup5iIPuS7wBbxpek5SFYJvuzXHLTtZNvxA4pdQW58krXTcDBtCz/zeps33gL0 3aM9fq6jeDzuYoEe3XUKbuPjApRN4LjUk79/v28M/CaALekqUxIUuN2nRdvx7QNw yc7AtWbcG3RUcsvpIxM7Uet0eFlQJA8DA2hRIJ6A6CvuQNaRUPlqZBjIFC/1qOW8 rEUGe/domf8MRYPPsrvR3O9JiJvmMXPFIGE8IYCUp7MNh7mCkBoXmfCiViF0AIpC oDJK+pYYPvQluR8S98zWu9V9PLHDeAjNB36vxJzeM9Zi1nGDGQNlr/oYoNtB5I0o N2oJ31vicwMRsyFPHnbauWjS9k2pPskLhOH8tQlO1xounxMbwaKZh8THvUmleuXH vnlfyzpxZS2ozU2go6RX9S3wEf9BaR9dtdIVdBCABEmhEzftYfw= =hKUf -----END PGP SIGNATURE----- --FPTu2AcUi1gmcNVR1tubOpgGf7HiTOMgi-- From nobody Mon Nov 13 03:04:57 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEA7129535 for ; Mon, 13 Nov 2017 03:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2YvThHFV2RtT for ; Mon, 13 Nov 2017 03:04:54 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 387A3129485 for ; Mon, 13 Nov 2017 03:04:54 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id d66so20200990ioe.5 for ; Mon, 13 Nov 2017 03:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=uDb6IQNBJNZrNVB3VfrQWA3tWO6JvVMa/xu6dkMShbQ=; b=rVhJHEBRD7YaUx9UXvvV8x98KMaFpIiMAZ4jwiDlGtidoN3AEInOeRJVUa0xVjV0cU QBtd4JG+YeJEXdDzL23SM2v5lr499OidXXxuUGnhtY+bu5xla6eAG4G8gDGw6mLCRVPD HtsTSzuyCPUj5n/7Jxr5kON62wshQH5J1nCVWhV/1e/2srySBffRIP50wMz3J6hbpVRA mxdylaoRQXyWfTifcVWC30L4NFH7QmUQBThaKZ9lgelRZWHzDjHlVnG2B+jJYZT9OOgf 2AohlXnuNiCGywE+4p5OPBlganF/qhRvIfDyZHaBF2+0B4oS3bET3DChG26B4nq84aqN lUmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=uDb6IQNBJNZrNVB3VfrQWA3tWO6JvVMa/xu6dkMShbQ=; b=YSPnt1jDlzLv52rC+3148SImvRx3x7m5J+k6h96FWKo7V50/l7IQJofY6pXJcReUpz gUzdE2o2nyEbuZnlpSATLlyFUMQlJV6s6dHekdXsyGUQRIRNKDZ3fJ2Wed8I+DHZsGOw WqCtQLIFyXRUqVoayf4IT7d4/NUphBSba1BpMQdu57yJ0aAQjfes+bS9f7JZqgzxbHVR JrZzcWrrCulAPeELNoCjXozpiXkrITvH87F+GyOcSUTDozwSQUYobFfGAMeBQ/zd99I1 mzUf6qziZhQBsPhmvGN4yfBXMj5TcZDfvniz95mU4DYWo7toTmT1mbgCZUcuFAAl7On9 xphw== X-Gm-Message-State: AJaThX5FjXJ/cVGlgGDXcliy7eG7klyUXKnUT6NvpDFd71A1SGlxiu8W 3qhgQ4Vs1Mew68Nk/PzjOrftC0Xz X-Google-Smtp-Source: AGs4zMbu9oJbR99dtGUmIioNNRPXK44GlvuxgS3FaR2E1aizLW16R1mu0DH46f1TCp0e8U8YZ+y6pg== X-Received: by 10.107.132.19 with SMTP id g19mr6627372iod.47.1510571093192; Mon, 13 Nov 2017 03:04:53 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([202.55.67.146]) by smtp.gmail.com with ESMTPSA id n68sm1653062ion.57.2017.11.13.03.04.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 03:04:52 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Mon, 13 Nov 2017 19:04:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ioilqS1cHj6f9OTFv6mLgKTGL4N4B5iRd" Archived-At: Subject: [Trans] Threat document update X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 11:04:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ioilqS1cHj6f9OTFv6mLgKTGL4N4B5iRd Content-Type: multipart/mixed; boundary="0l1XuPg4OlrAKV0WofPluo5h6BTdkRUok"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: Subject: Threat document update --0l1XuPg4OlrAKV0WofPluo5h6BTdkRUok Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, all: One of the things we discussed at this afternoon's meeting was the status and disposition of the threat document. (https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/) The authors have put considerable work into it and it's a useful document that we'd like to push through to publication, but we've been deadlocked for some time on getting some text changed. The proposal to go forward is: 1) Paul and I will get a new version updated and uploaded; 2) the current authorship as listed on the document will remain unchanged; 3) changes will be brought to the mailing list for discussion and consensus. Are there objections to this process? Thanks, Melinda --0l1XuPg4OlrAKV0WofPluo5h6BTdkRUok-- --ioilqS1cHj6f9OTFv6mLgKTGL4N4B5iRd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloJfFAACgkQuIZGkzoe gS4jIA/+NropKluFK76yjzOsutUDDUAJUi6jCqLOG3azprSdp8455ZKfMfLE6qXb 19o+fY1ig505vOuGB7Xa50DJOwEovzNssyYuJffQufzdoBVd4Ac3Q6/4+hSa5X1W LzdoBR3d2olI592/JfYug+j9n4VGI1Rhj8cpWCSdcG9n11tmLvCIp/f7uwt0KpvF X8llvYEPUVw2Rxu9eKgoQSeWbQdD79AFv/u7zfkEzTDAi5e9yBJqMNagIghesZkb zU9RT8hzs1QqpBFPXYxn/cJ5cEeDBcQiCb0uAVumdVb4R9Ik1EKARNtY5hdUU398 K1d8MaQPEFnrXpAvTaFfSTweJhNGs8Q9PlyOsIEDZ3sU5hDbRdGCE2BxvWkN6HAY D15OevX8+H1M2jwGjaVwOOO68vE91KIQ8I0s1X2ZOrQ9y/pEuRdjfTfUAjSZ4IrX Jd+FUllNFvcH3+Hc6L0+i80PrjCU5OB7Xwy90pEnDjC7GN96DeN+QVxa578xXpz0 fxo6MEZNTy72S/zTp6F7qHoH0fEujdpzGuNnuGfifs+Z48N34+u+RQKEZjz9d8w7 u1f46RMzcm5iotk5I+i5yINqZGbVJEphk6t4pJOQXOpm7IBZT4RpYb3HXoDqBp0l GPAYm6Xj5k4yjSgHMdFrK/uOU2Fz6OX/IGn8uJqTUZHB4z4NbCs= =ommd -----END PGP SIGNATURE----- --ioilqS1cHj6f9OTFv6mLgKTGL4N4B5iRd-- From nobody Mon Nov 13 06:22:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D0F129744 for ; Mon, 13 Nov 2017 06:22:50 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Gq3RFYmczSyf for ; Mon, 13 Nov 2017 06:22:47 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 7A02F129AC6 for ; Mon, 13 Nov 2017 06:21:22 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id q18so10458334uaa.0 for ; Mon, 13 Nov 2017 06:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jJc1mZCp1KkuszDsQtNuGHE0eG06BUE6EX66bkghdb4=; b=LrXMYVMuPL5QMkFwg4SUmr3KDC2dKhlFiSyLE1NHt4AhvRvSRcWZaZB6N0kFu8623T N1DXXKI/0F77iel5+hdkAu8paxsMV1m6Q8hP/VkWz9ja71WkrsjDachKutQ8Y7JK3CHI j0A2iw4X/wvx4lyeZvXz7jMOSao0kwTepZpyC9wtjTewNkNaHG/vdH7ttly+jAyuwGzv veR1mUwRo1VAjslm+yInQ9KcePIOcTlFAnOXzIEb/pbS81t+3NwT6JKmpuCJzZqMiu7X 92SuvLSUjHb4qmOqG7oU2Tmrzt/k/9OMJuQCQEfxlx8L1bvru6vkFKR2juUR8lsbUgVp iLmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jJc1mZCp1KkuszDsQtNuGHE0eG06BUE6EX66bkghdb4=; b=NxV9xXosk0ukNRb+N+APrCJ5mr3Van7he3JqAb4AQLHS1pPfBixuWyBWaxl+AQQTg/ CnK1ZxgJTRt3kZgHCSV9EVqMK5aDefwpZKMtNn06nZyca5gnJVx4Pm8LNGtel5QhsSQT UIfN34EV8zEMT39LF2RNDtaA1iKhLibY6F+C3xt14JFQKTa3urvOJ58n4wu1u4d3sDfc hLcJcyrS25ym1T2unHunNcDnD18N8i/bnpHhWLu3Mv9BFEzUps0x2gfveYxrzbo/IspT XKIF2EkESN+jVHRsoxUQkYD5wslutz6gL6sEy9nXM9SSTZp9mMPc8ii3HOaKxx6nIEvi zQeA== X-Gm-Message-State: AJaThX6xgq1t5k/MMcIUDVz+EIwBm+flJSpoB6+gJABa8GxxkWUius5F JsOou23+qUHwl9HWTQAHs/RCyP99d1uiUtCmStwFBA== X-Google-Smtp-Source: AGs4zMaWsizQ7IAsHf2U3HFRJ+eP/YEEJ8ctTcYphPPfz5osCHhmkSthLmyYDZuUqhi1Z5h1RV6r5Lil0ZXbMq0gE80= X-Received: by 10.176.80.2 with SMTP id b2mr4656284uaa.198.1510582881290; Mon, 13 Nov 2017 06:21:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.152.82 with HTTP; Mon, 13 Nov 2017 06:21:20 -0800 (PST) In-Reply-To: References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> From: Ben Laurie Date: Mon, 13 Nov 2017 14:21:20 +0000 Message-ID: To: Watson Ladd Cc: Bryan Ford , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "trans@ietf.org" , Eran Messeri , Al Cutter , Melinda Shore Content-Type: multipart/alternative; boundary="94eb2c18ee440bd2be055dddfcb5" Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 13 Nov 2017 14:22:50 -0000 --94eb2c18ee440bd2be055dddfcb5 Content-Type: text/plain; charset="UTF-8" On 12 November 2017 at 01:40, Watson Ladd wrote: > On Sat, Nov 11, 2017 at 3:44 AM, Bryan Ford wrote: > > On Nov 8, 2017, at 3:59 PM, Al Cutter wrote: > > > > I'm a fan of short-lived certs, but I'm not particularly keen on the > idea of > > not logging publicly rooted certs - the point of CT is the > discoverability > > of misissuance after all, and it does seem that having an SCT which could > > refer to a whole set of "similar" yet unlogged certs is not a great idea, > > e.g. a scenario where the key is compromised by an entity which can > coerce > > the CA into issuing more "non-logged" certs to cover any period the proud > > new owner of the key material would like. > > > > > > 100% agreed on this point. Short-term certs are good, and they all > should - > > and can - be publicly logged to ensure transparency. To whatever extent > > this capacity issue is a problem in the current CT design, this is a > problem > > with CT that needs to be fixed. > > What are the problems we are trying to solve with short-term certs and > can we come up with a way to solve them that doesn't have the > implications for CT of the current proposal? > The problem is revocation (or the lack of it). We actually know how to solve transparency for revocation, and what's more Trillian provides the necessary infrastructure, so I'm not entirely sure why we'd want to make the job of checking for misissued certs 100x more expensive rather than just making revocation work properly (which presumably could use the same underlying mechanism to determine revocation status). > TLS delegated credentials seem to do what we want, but maybe I don't > understand the problem well enough. Pruning chains of expired certs > has implications for misbehavior detection. > > Sincerely, > Watson > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c18ee440bd2be055dddfcb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 12 November 2017 at 01:40, Watson Ladd <watsonbladd@gmail.com> wrote:
On = Sat, Nov 11, 2017 at 3:44 AM, Bryan Ford <brynosaurus@gmail.com> wrote:
> On Nov 8, 2017, at 3:59 PM, Al Cutter <al@google.com> wrote:
>
> I'm a fan of short-lived certs, but I'm not particularly keen = on the idea of
> not logging publicly rooted certs - the point of CT is the discoverabi= lity
> of misissuance after all, and it does seem that having an SCT which co= uld
> refer to a whole set of "similar" yet unlogged certs is not = a great idea,
> e.g. a scenario where the key is compromised by an entity which can co= erce
> the CA into issuing more "non-logged" certs to cover any per= iod the proud
> new owner of the key material would like.
>
>
> 100% agreed on this point.=C2=A0 Short-term certs are good, and they a= ll should -
> and can - be publicly logged to ensure transparency.=C2=A0 To whatever= extent
> this capacity issue is a problem in the current CT design, this is a p= roblem
> with CT that needs to be fixed.

What are the problems we are trying to solve with short-term certs a= nd
can we come up with a way to solve them that doesn't have the
implications for CT of the current proposal?

The problem is revocation (or the lack of it).

We actually know how to solve transparency for revocation, and what'= s more Trillian provides the necessary infrastructure, so I'm not entir= ely sure why we'd want to make the job of checking for misissued certs = 100x more expensive rather than just making revocation work properly (which= presumably could use the same underlying mechanism to determine revocation= status).

=C2=A0
TLS delegated credentials seem to do what we want, but maybe I don't understand the problem well enough. Pruning chains of expired certs
has implications for misbehavior detection.

Sincerely,
Watson

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

--94eb2c18ee440bd2be055dddfcb5-- From nobody Mon Nov 13 17:17:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496B51270B4 for ; Mon, 13 Nov 2017 17:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no autolearn_force=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 jKwGSwiX8_ur for ; Mon, 13 Nov 2017 17:17:18 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 20EAB126D73 for ; Mon, 13 Nov 2017 17:17:18 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id E5B2B37412FE for ; Tue, 14 Nov 2017 01:17:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DM3KFqMLgbMF for ; Mon, 13 Nov 2017 20:17:17 -0500 (EST) Received: from dhcp-98fb.meeting.ietf.org (dhcp-98fb.meeting.ietf.org [31.133.152.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 3314C3740FDE for ; Mon, 13 Nov 2017 20:17:16 -0500 (EST) To: trans@ietf.org References: <607fce3e-be48-fe65-32ff-5dbff19f7ade@gmail.com> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <890159f2-e8f3-8ec6-3f07-263f9f84c7d8@openca.org> Date: Tue, 14 Nov 2017 09:17:13 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060607000505000301010009" Archived-At: Subject: Re: [Trans] STAR & CT coexistence X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 14 Nov 2017 01:17:19 -0000 This is a cryptographically signed message in MIME format. --------------ms060607000505000301010009 Content-Type: multipart/alternative; boundary="------------06FFDBA33E8F61FC46C9789B" Content-Language: en-US This is a multi-part message in MIME format. --------------06FFDBA33E8F61FC46C9789B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/13/17 10:21 PM, Ben Laurie wrote: > [...] > The problem is revocation (or the lack of it). > > We actually know how to solve transparency for revocation, and what's=20 > more Trillian provides the necessary infrastructure, so I'm not=20 > entirely sure why we'd want to make the job of checking for misissued=20 > certs 100x more expensive rather than just making revocation work=20 > properly (which presumably could use the same underlying mechanism to=20 > determine revocation status). +1 Cheers, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------06FFDBA33E8F61FC46C9789B Content-Type: multipart/related; boundary="------------B52FD2116A282AC950F5D080" --------------B52FD2116A282AC950F5D080 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 11/13/17 10:21 PM, Ben Laurie wrote= :
[...]
The problem is revocation (or the lack of it).

We actually know how to solve transparency for revocation, and what's more Trillian provides the necessary infrastructure, so I'm not entirely sure why we'd want to make the job of checking for misissued certs 100x more expensive rather than just making revocation work properly (which presumably could use the same underlying mechanism to determine revocation status).
=
+1

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------B52FD2116A282AC950F5D080 Content-Type: image/png; name="ffkmcfnjobcapnfe.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ffkmcfnjobcapnfe.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------B52FD2116A282AC950F5D080-- --------------06FFDBA33E8F61FC46C9789B-- --------------ms060607000505000301010009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEx MTQwMTE3MTNaMC8GCSqGSIb3DQEJBDEiBCDK+c+BCLTWMJN3fo5rYjVtI7iFvPVcc7HIlMfO c1wTOTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBACO48mKzAdYXpLNI AsSVqABr66pAMHQqEN+ktIhbIspM+M3zvoxuekbFszFz6wb0EKTIZoLtSAJFi2PhIvQdcM8g B20xad/BuqrRPwnOlMCyYmr0Ft/2dMBzG8+FBKehAjU+jfhRf7sqTdV/e/M4QtklIXxONC6q P7rmhrvR7LUAteEzrVeeeUZS6rIwTgBGm9FVyHXa8cloN3zQQxP2Q/V6D3x8W2EQHS5SIH08 /d3fD3Cs5B70tbBYfLYryH+x27RXIn9enVP+IOYJJB0xB8eTPHT0yD5H60msd4oc9DQPfmep EotFG9Xu8TUHU8lCE3Grd1Pt3kJkyktkcuYMIpoAAAAAAAA= --------------ms060607000505000301010009-- From nobody Fri Nov 17 08:28:53 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C212896F for ; Fri, 17 Nov 2017 08:28:51 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hrwxM9e06grv for ; Fri, 17 Nov 2017 08:28:49 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566381243FE for ; Fri, 17 Nov 2017 08:28:49 -0800 (PST) Received: by mail.in.tum.de (Postfix, from userid 107) id 57B9B1C2A44; Fri, 17 Nov 2017 17:28:47 +0100 (CET) Received: (Authenticated sender: hof) by mail.in.tum.de (Postfix) with ESMTPSA id 55C901C2A3B for ; Fri, 17 Nov 2017 17:28:45 +0100 (CET) (Extended-Queue-bit tech_fgzzi@fff.in.tum.de) Date: Fri, 17 Nov 2017 17:28:45 +0100 From: Benjamin Hof To: trans@ietf.org Message-ID: <20171117162845.xv2zlctxifppq4dj@quantified.net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Trans] FW: I-D Action: draft-hof-trans-cross-00.txt (internet-drafts@ietf.org) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 17 Nov 2017 16:28:51 -0000 I appreciate any comments. ----- Forwarded message from internet-drafts@ietf.org ----- >... > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : STH Cross Logging > Author : Benjamin Hof > Filename : draft-hof-trans-cross-00.txt > Pages : 6 > Date : 2017-11-15 > > Abstract: > A malicious Certificate Transparency (CT) log can offer a modified > tree to a client in a "split view" attack. This document proposes to > extend CT by submitting Signed Tree Heads (STH) into another log, run > by a different operator. Auditors and monitors can use these cross > logged STHs to detect split view attacks by the log. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hof-trans-cross/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-hof-trans-cross-00 > https://datatracker.ietf.org/doc/html/draft-hof-trans-cross-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >... ----- End forwarded message ----- From nobody Fri Nov 17 09:28:59 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23189128C9C for ; Fri, 17 Nov 2017 09:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 gs9fnkIbFbLB for ; Fri, 17 Nov 2017 09:28:54 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 892961242F5 for ; Fri, 17 Nov 2017 09:28:54 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id r68so7941007wmr.1 for ; Fri, 17 Nov 2017 09:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M4+oYK0fjGdMUqN3RzF2zCw/64Q+14trrxR3NAm7eTg=; b=d/y/mtpNd0UJ1F0rAfjsioDnUwGndHClK4gujb4u0BKuwqVwEzy3hhzxYFNe+soU0i mXbGHz+uNBGbUVc/U6gsjlqwwDly5o/U5JAiFG5g8m92jMnDpLWP4A4iqXwv0uz/uqBO WBYLvIDiE4J42sFti2oI6El+YXD3Er5qA9/MoDRWmuxh1rOThQGTM9cX39N9Wvo++twG C6Dbl+gX+Kq3zCieEYZXmzDblNPS5oQjn2bX5jCnUp7z1VUQXo6tQHoubG37VwRmZGOk McSn0n+RYfmg45zzJSjvXxwl/GFL7G3Y4LHIczpYEOjoit+nIzYq/mlbx+mPh9Bz2GXI QkhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M4+oYK0fjGdMUqN3RzF2zCw/64Q+14trrxR3NAm7eTg=; b=nS4z6JZXFUl7saalDEc1a+7kImEOSNvm0AF/oss/InKhu2fjIlgkJpvVNO3ua6IIIQ 3PzPB1QPrr5HUa+gwE3sz8ZhHEJ+2msi9NZgFsXv9T0QduY5yssduMtjhttuW64YaZVm 8yXDKZGAz2/kfzCx4iAddKLzMaPUMhbbLdnYjm+318uRmMaZ3OdW/3KVyPCNyCsjzYid Mkku8hweCdKll/JVmahpkHiDmStoehV2Xzug3dpeHwtoTDI4BRUwb+pHe+g8Or3sX9xm XcsSIg9E/k1tI9KeG3xiJJTHhKv1r/XnwD7xnohnL3cSPC9DcpPCZ19Ddgn5wd5BMGeP UamQ== X-Gm-Message-State: AJaThX5Qp0V+xN1q1zRBpxjXhd93TW3b4HzfY+7fW1JfiA/Y/6t9ElCk UO2Fv40GJ+/Ct/ACJW6llPrGVDAWfCHLuCaQ8oXpJw== X-Google-Smtp-Source: AGs4zMbvXGHPRBLk8RQAVGDOgQ4b6+hqzUOcUg76fQzXtH3kBAW7u2RaESIu70IqUzVsz/rNb5IxC9asD/OImgZngm0= X-Received: by 10.80.173.56 with SMTP id y53mr8383565edc.202.1510939732961; Fri, 17 Nov 2017 09:28:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.162.197 with HTTP; Fri, 17 Nov 2017 09:28:51 -0800 (PST) In-Reply-To: <20171117162845.xv2zlctxifppq4dj@quantified.net.in.tum.de> References: <20171117162845.xv2zlctxifppq4dj@quantified.net.in.tum.de> From: Al Cutter Date: Fri, 17 Nov 2017 17:28:51 +0000 Message-ID: To: Benjamin Hof Cc: Trans Content-Type: multipart/alternative; boundary="f403045c18a60fd357055e3112e6" Archived-At: Subject: Re: [Trans] FW: I-D Action: draft-hof-trans-cross-00.txt (internet-drafts@ietf.org) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 17 Nov 2017 17:28:57 -0000 --f403045c18a60fd357055e3112e6 Content-Type: text/plain; charset="UTF-8" Hi Benjamin, I've only quickly skimmed through, but on the surface this seems quite similar to something we've been musing on internally for a while - I'd be very happy to work with you on developing it further if you're interested? Cheers, Al. On Fri, Nov 17, 2017 at 4:28 PM, Benjamin Hof wrote: > I appreciate any comments. > > ----- Forwarded message from internet-drafts@ietf.org ----- > > >... > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : STH Cross Logging > > Author : Benjamin Hof > > Filename : draft-hof-trans-cross-00.txt > > Pages : 6 > > Date : 2017-11-15 > > > > Abstract: > > A malicious Certificate Transparency (CT) log can offer a modified > > tree to a client in a "split view" attack. This document proposes to > > extend CT by submitting Signed Tree Heads (STH) into another log, run > > by a different operator. Auditors and monitors can use these cross > > logged STHs to detect split view attacks by the log. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-hof-trans-cross/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-hof-trans-cross-00 > > https://datatracker.ietf.org/doc/html/draft-hof-trans-cross-00 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >... > > ----- End forwarded message ----- > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --f403045c18a60fd357055e3112e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

I've only quickly skim= med through, but on the surface this seems quite similar to something we= 9;ve been musing on internally for a while - I'd be very happy to work = with you on developing it further if you're interested?

<= /div>
Cheers,
Al.

<= div class=3D"gmail_quote">On Fri, Nov 17, 2017 at 4:28 PM, Benjamin Hof <hof@i= n.tum.de> wrote:
I apprec= iate any comments.

----- Forwarded message from in= ternet-drafts@ietf.org -----

>...
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: STH Cross Logging
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Benjamin Hof
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= hof-trans-cross-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-11-15
>
> Abstract:
>=C2=A0 =C2=A0 A malicious Certificate Transparency (CT) log can offer a= modified
>=C2=A0 =C2=A0 tree to a client in a "split view" attack.=C2= =A0 This document proposes to
>=C2=A0 =C2=A0 extend CT by submitting Signed Tree Heads (STH) into anot= her log, run
>=C2=A0 =C2=A0 by a different operator.=C2=A0 Auditors and monitors can = use these cross
>=C2=A0 =C2=A0 logged STHs to detect split view attacks by the log.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dr= aft-hof-trans-cross/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ho= f-trans-cross-00
> https://datatracker.ietf.org/doc/html/draft-hof-trans-cross-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>...

----- End forwarded message -----

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

--f403045c18a60fd357055e3112e6-- From nobody Mon Nov 20 01:41:38 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C9D129501 for ; Mon, 20 Nov 2017 01:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 PkpOJaPM312M for ; Mon, 20 Nov 2017 01:41:33 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 891A112948D for ; Mon, 20 Nov 2017 01:41:31 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAK9fRYF115018 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 20 Nov 2017 10:41:27 +0100 Received: from datan ([IPv6:2001:6b0:7:1:f68c:50ff:fe1e:a490]) (authenticated bits=0) by smtp1.sunet.se (8.15.2/8.14.9) with ESMTPSA id vAK9fNfp003281 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Nov 2017 09:41:26 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1511170887; bh=zuyhbhc97+4wxV5VKFVIwIfeW2d80wL16CmH4Q4Ucl0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=IsSl4sgKbjmJZm5Zk58SgQ2LrlqrUJixYsIv1PxzcORIEvDm5B1XVVfJ8A1wxpof4 s5Vap7tuc6NDhf/NQLvakvJkZR3TYHI4keR8Gq9Oy/q9NlPQ7MlXu21kB4CnfWaofc yTGiJznCRMyvjKJDvci4g+UsKKeMZCrkbNbbvOWw= From: Linus Nordberg To: Melinda Shore Cc: "trans\@ietf.org" Organization: Sunet References: Date: Mon, 20 Nov 2017 10:41:19 +0100 In-Reply-To: (Melinda Shore's message of "Mon, 13 Nov 2017 18:14:26 +0800") Message-ID: <87r2st70e8.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=2001:6b0:7:1:f68c:50ff:fe1e:a490; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09UA9FrHJ - c80544c34e3c - 20171120 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 2001:6b0:7:1:f68c:50ff:fe1e:a490 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=2001:6b0:7:1:f68c:50ff:fe1e:a490; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [Trans] Minutes uploaded X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 20 Nov 2017 09:41:37 -0000 Melinda Shore wrote Mon, 13 Nov 2017 18:14:26 +0800: > Minutes from this afternoon's session have been uploaded to: > https://datatracker.ietf.org/doc/minutes-100-trans/ --8<---------------cut here---------------start------------->8--- Linus Nordberg presents about Gossip open question about whether we should refactor it. Not many people have read the gossip draft. --8<---------------cut here---------------end--------------->8--- If the working group would rather see refactoring than publishing of the current document (after addressing issues identified by ED review), please identify author(s). The current authors will resume work at the end of this week. From nobody Mon Nov 20 11:22:48 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5112EA55 for ; Mon, 20 Nov 2017 11:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 JcEYw6f13Qh6 for ; Mon, 20 Nov 2017 11:22:45 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 B3B1F12E957 for ; Mon, 20 Nov 2017 11:22:44 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id b189so20808288wmd.5 for ; Mon, 20 Nov 2017 11:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZvGE0L/DFMoITAOxv/9IRfXt7pyq/Ql1Nb6w2owj7qY=; b=ZRUK0HgDjUnoJapmL25H7wEIwRumNPu4aKtd8LRfj6T3WRvZ1UfH0gj1X8TJDGaTRx tA3qvR8cx73mN8TtCScxIUK4iONBGLfTCU2AgNiUfrzFdgLr4hmpO7Qpdfl5VYXhfe/T 0Xf1pRqNJ5JnmnVFl3l1Foy0CMWlwFZDcQh/wRmLgrk0yF2yikQVuFuobAdGC3Hdg7MC 3uGVIL+p5h0hdZwglcsgDQy/Ab54WkvAKO+8nR5CrLSeYUggnVcWEPVCgxBDkQHYlX46 Pyh0JEj/CjpMBnQsGMV/g79jlvfPWOd133jtMlOHiddjf5bzV1F76uFc23GwvKxJPpmR 68ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZvGE0L/DFMoITAOxv/9IRfXt7pyq/Ql1Nb6w2owj7qY=; b=m7IDBM79T0MlnqKdfG0NYAKRrOMVBREw17jfeyOjmHWKneE++XOBvqDm+JvNopGZsw 5hMxbi68WdZjBXDKa7+8q9++UaXXEJql0Dgb/ID09At1QXjCkDPn81khLjgLpp7IFHMB UYO9Y10gRFyKcCveLBacTdf0Sl05qw+8zVh+tbnadFW+ku9ktE4/sGuzi6G3CbT42fbN XAUobXX+CnNvbkp+ecgjEvBkcS/7w/H8Z9W+d5mEq6kuFWoSRY3E5LEXCFYbBgN4GPoE NRw7Y6VXwHQH7NLVTb44vLLpcKqhaibSpQ7sxP9rKTzTR5BpVen9g20O0e995jz/Eu7h VTPQ== X-Gm-Message-State: AJaThX5zc7fhoJkFCUEGa2i+Uf2CR5npps/PPt9IRYPsHQPeRuppsphY Q6pgfVIrSzP0SO7U4kDoScBQxS71/Aqk1TZqEs7XMpPWqWs= X-Google-Smtp-Source: AGs4zMZ8LjsGt6BKT8WFw8lgFyP4DWP+Fz66DJy6CSBVFNUlU+M1VdhhDmXxGivizrGDHDT4JOh03wlWgTB4mMN+0Dk= X-Received: by 10.80.163.101 with SMTP id 92mr21123930edn.100.1511205762787; Mon, 20 Nov 2017 11:22:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.162.197 with HTTP; Mon, 20 Nov 2017 11:22:41 -0800 (PST) From: Al Cutter Date: Mon, 20 Nov 2017 19:22:41 +0000 Message-ID: To: Trans Content-Type: multipart/alternative; boundary="94eb2c0da3aaad221f055e6f02eb" Archived-At: Subject: [Trans] I'm sorry to do this to you all, but: section 4.2, again. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 20 Nov 2017 19:22:47 -0000 --94eb2c0da3aaad221f055e6f02eb Content-Type: text/plain; charset="UTF-8" Hi all, I was trying to help (honest!) Rob Stradling with the outstanding AD comments from ekr on -bis27, and so we took an easy starter for 10: [ekr] *"Why is this a 2119 MUST? It seems wise, but not necessarily a conformance requirement"* in regards to Section 4.2: > "To avoid being overloaded by invalid submissions, the log MUST NOT accept > any submission until it has verified that the certificate or precertificate > was submitted with a valid signature chain to an accepted trust anchor. FWIW I agree with ekr on this (it's a policy statement, and, I believe, a potentially dangerous one to encode as an RFC MUST) and managed to persuade Rob of the same (at least that's what he said at the time), so he kindly put together a PR to change that MUST NOT to a SHOULD NOT: https://github.com/google/certificate-transparency-rfcs/pull/289 Apparently not everyone sees it quite so clearly, and there's been a bit of a discussion on the PR, so in the interests of Transparency I wanted to call it out here too in case there's anybody who was not already aware of the PR and wants to get involved, again, on this well worn and comfy topic. Cheers, Al. --94eb2c0da3aaad221f055e6f02eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I was trying to help (honest!) = Rob Stradling with the outstanding AD comments from ekr on -bis27, and so w= e took an easy starter for 10:=C2=A0
=C2=A0 =C2=A0 [ekr]=C2=A0= "Why is this a 2119 MUST? It seems wise, but not necessarily a conform= ance requirement"=C2=A0
in regards to Section 4.2:
=
"To avoid being over= loaded by invalid submissions, the log MUST NOT accept any submission until= it has verified that the certificate or precertificate was submitted with = a valid signature chain to an accepted trust anchor.

<= /div>
FWIW I agree with ekr on this (it's a policy statement, and, = I believe, a potentially dangerous one to encode as an RFC MUST) and manage= d to persuade Rob of the same (at least that's what he said at the time= ), so he kindly put together a PR to change that MUST NOT to a SHOULD NOT:= =C2=A0https://github.com/google/certificate-transparency-rfcs/pull/289


Al.


--94eb2c0da3aaad221f055e6f02eb-- From nobody Tue Nov 21 11:20:47 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168DB129B9C for ; Tue, 21 Nov 2017 11:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Lc_92YjDLNUc for ; Tue, 21 Nov 2017 11:20:42 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 F26AE12025C for ; Tue, 21 Nov 2017 11:20:41 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id u42so20606693ioi.9 for ; Tue, 21 Nov 2017 11:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=poLgGhDSjSfLXqD7Omm6S/mMaGLk4LsCG86xZY6F99E=; b=nUkATeHpSppSComjDtdryE3P3NMuIQMd0xa9/oFzjbcbm1aq4cG1cTv//n+Gvnsh+h aTRZFcW2O5rUdtAHKGwnl0R9erz4Ew3Q6jHLugwQ5+cRtkOquVx8Rurr7KEynmAuPUdb 0GOK7Hi7SlmHu7l64xjjl/XvIQnxHvFaGTStA97jg5ZlTZBlqtUoJcgM5IYpYD2NaKAg MZaD2qDPzVjULC1QFnTXrXOaPxCGV1YnL+1uhNwpT75GOJytpZvaAOooNnNAvfVuUuwZ au5yH/c/oAF45SuHkHkw6jNx6qSv5JOEv891fjcHcul2QcYpMGiRCj23pRofP+AeJX11 RX5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=poLgGhDSjSfLXqD7Omm6S/mMaGLk4LsCG86xZY6F99E=; b=GK3sH1a3DB/mVNSp65x4jAUDszRSTHxROO3f4XeWaAIHN0NhXcoRPSPmv+ujqG/5ap FeGIIynHsn3/qZXC/IwueSHnxw18qLzI0MoG6z/GgCe59/kBdq7+Z9MqTHAn80+svVrm HhYGeHyFOP6t0xV8FgzpoGCpZp7SXsx6pOufJq0CCgyk0twZjl0kOOU49Dku4Hk3qkju f9VyysD38vVwozL/8qbZYY2xU6rSB1CzScWBC4jpjgXtwL4J8aklE3V2W8MtXKWYf4l6 kOLvbtj3EfvEyQZv7lhkNa32PQJH7RJf4OyKWOp+prQnnuOk7bSJmJg+V69QzADaDKgv VCCQ== X-Gm-Message-State: AJaThX6+/SZ/z+R2J0QQkjeeCdQXiRXx7CrGeL8PeoXZSjJOLOxDeHhK 311A80f2OScudQWSkyZOWIYCZfEHuUtMEu68rM0Ylpk3spM= X-Google-Smtp-Source: AGs4zMYBX0+paefJ3HQWaRtgMr3FBIZXZvL2CI54x86ew4R5Cw9m+Kp01fsYXvCoj1FX7nMTKBqedeIw7HnqSErt0/k= X-Received: by 10.107.183.76 with SMTP id h73mr19788206iof.154.1511292040755; Tue, 21 Nov 2017 11:20:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Tue, 21 Nov 2017 11:20:09 -0800 (PST) From: Eran Messeri Date: Tue, 21 Nov 2017 19:20:09 +0000 Message-ID: To: Trans Content-Type: multipart/alternative; boundary="94eb2c0b9e3a3e3a9f055e831965" Archived-At: Subject: [Trans] Section 4.2 follow-up X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 21 Nov 2017 19:20:46 -0000 --94eb2c0b9e3a3e3a9f055e831965 Content-Type: text/plain; charset="UTF-8" [shortening subject] Two MUSTs are being discussed: (1) "the log MUST NOT accept any submission until it has verified ..." (2) "The log MUST NOT use other sources of intermediate CA certificates" These MUSTs are to do with security (as Andrew Ayer pointed out ) as well as protocol correctness and determinism of the logs, not in order to restrict what logs should accept. A consensus has already been established in the group that logs need to be allowed to accept certificates that are not fully compliant with RFC5280 validation rules (hence the SHOULD in the second paragraph of said section and MAY on the third paragraph). Another consensus was established that logs should be allowed to drop valid submissions under load (to protect against DoS attacks) - which again is allowed by the SHOULD on the 2nd paragraph. The MUSTs that have remained, have remained there to guarantee that a submission has made it into the log if, and only if, it has been validated according to the log's implementation (which, again, may deviate from RFC5280). These MUSTs are in place to guide the implementation, even if there's no technical way to validate, from an external POV, that a log adhered to them at all times. To present from a different angle, if the MUSTs are changed to SHOULDs then (according to my understanding of RFC2119) logs will be able to claim that any accepted submission was not validated because the it wasn't checked. That would make monitoring difficult and submission non-deterministic (because a log would then be allowed to use other sources of intermediate CA certificates to complete a partially-submitted chain). RFC2119 says about SHOULD that "there may exist valid reasons in particular circumstances to ignore a particular item [...]" but I do not see a valid reason to ignore validation for some entries or allow acceptance of partial chains, where the 6962-bis goes to great length to ensure the submitted, valid chain is always presented to monitors. >From what I can tell, the arguments in the GitHub PR mentioned below either fall into the "non-RFC5280-compliant submission" (which is already covered) or involve the implications of a particular log not being 6962-bis compliant, which fall into the Client Behaviour category (implications of the protocol on clients and servers' behaviour, not the protocol specification itself). This part of section 4.2. has been discussed on the list a year ago ( https://www.ietf.org/mail-archive/web/trans/current/msg02484.html) and earlier (https://trac.ietf.org/trac/trans/ticket/73, https://trac.ietf.org/trac/trans/ticket/21). On Mon, Nov 20, 2017 at 7:22 PM, Al Cutter wrote: > Hi all, > > I was trying to help (honest!) Rob Stradling with the outstanding AD > comments from ekr on -bis27, and so we took an easy starter for 10: > [ekr] *"Why is this a 2119 MUST? It seems wise, but not necessarily a > conformance requirement"* > in regards to Section 4.2: > >> "To avoid being overloaded by invalid submissions, the log MUST NOT >> accept any submission until it has verified that the certificate or >> precertificate was submitted with a valid signature chain to an accepted >> trust anchor. > > > FWIW I agree with ekr on this (it's a policy statement, and, I believe, a > potentially dangerous one to encode as an RFC MUST) and managed to persuade > Rob of the same (at least that's what he said at the time), so he kindly > put together a PR to change that MUST NOT to a SHOULD NOT: > https://github.com/google/certificate-transparency-rfcs/pull/289 > > Apparently not everyone sees it quite so clearly, and there's been a bit > of a discussion on the PR, so in the interests of Transparency I wanted to > call it out here too in case there's anybody who was not already aware of > the PR and wants to get involved, again, on this well worn and comfy topic. > > Cheers, > Al. > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --94eb2c0b9e3a3e3a9f055e831965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[shortening subject]

Two MUSTs are bein= g discussed:
(1) "the log MUST NOT accept any submission unt= il it has verified ..."
(2) "The log MUST NOT use other= sources of intermediate CA certificates"

The= se MUSTs are to do with security (as Andrew Ayer p= ointed out) as well as protocol correctness and determinism of the logs= , not in order to restrict what logs should accept.

A consensus has already been established in the group that logs need to b= e allowed to accept certificates that are not fully compliant with RFC5280 = validation rules (hence the SHOULD in the second paragraph of said section = and MAY on the third paragraph).

Another consensus= was established that logs should be allowed to drop valid submissions unde= r load (to protect against DoS attacks) - which again is allowed by the SHO= ULD on the 2nd paragraph.

The MUSTs that have rema= ined, have remained there to guarantee that a submission has made it into t= he log if, and only if, it has been validated according to the log's im= plementation (which, again, may deviate from RFC5280). These MUSTs are in p= lace to guide the implementation, even if there's no technical way to v= alidate, from an external POV, that a log adhered to them at all times.

To present from a different angle, if the MUSTs are c= hanged to SHOULDs then (according to my understanding of RFC2119) logs will= be able to claim that any accepted submission was not validated because th= e it wasn't checked. That would make monitoring difficult and submissio= n non-deterministic (because a log would then be allowed to use other sourc= es of intermediate CA certificates to complete a partially-submitted chain)= .

RFC2119 says about SHOULD that "there may e= xist valid reasons in particular circumstances to ignore a particular item = [...]" but I do not see a valid reason to ignore validation for some e= ntries or allow acceptance of partial chains, where the 6962-bis goes to gr= eat length to ensure the submitted, valid chain is always presented to moni= tors.

From what I can tell, the arguments in the G= itHub PR mentioned below=C2=A0either fall into the "non-RFC5280-compli= ant submission" (which is already covered) or involve the implications= of a particular log not being 6962-bis compliant, which fall into the Clie= nt Behaviour category (implications of the protocol on clients and servers&= #39; behaviour, not the protocol specification itself).

This part of section 4.2. has been discussed on the list a year ago (= https://www.ietf.org/mail-archive/web/trans/current/msg02484.html) a= nd earlier (https://= trac.ietf.org/trac/trans/ticket/73, https://trac.ietf.org/trac/trans/ticket/21).

On Mon, Nov 20, 2017= at 7:22 PM, Al Cutter <al@google.com> wrote:
Hi all,

<= div>I was trying to help (honest!) Rob Stradling with the outstanding AD co= mments from ekr on -bis27, and so we took an easy starter for 10:=C2=A0
=C2=A0 =C2=A0 [ekr]=C2=A0"Why is this a 2119 MUST? It seems = wise, but not necessarily a conformance requirement"=C2=A0
in regards to Section 4.2:
"To avoid being overloaded by invalid submissions, the log = MUST NOT accept any submission until it has verified that the certificate o= r precertificate was submitted with a valid signature chain to an accepted = trust anchor.

FWIW I agree with ekr on this= (it's a policy statement, and, I believe, a potentially dangerous one = to encode as an RFC MUST) and managed to persuade Rob of the same (at least= that's what he said at the time), so he kindly put together a PR to ch= ange that MUST NOT to a SHOULD NOT:=C2=A0https://github= .com/google/certificate-transparency-rfcs/pull/289
=
Apparently not everyone sees it quite so clearly, and there&= #39;s been a bit of a discussion on the PR, so in the interests of Transpar= ency I wanted to call it out here too in case there's anybody who was n= ot already aware of the PR and wants to get involved, again, on this well w= orn and comfy topic.

Cheers,
Al.



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


--94eb2c0b9e3a3e3a9f055e831965-- From nobody Tue Nov 21 11:34:06 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94050129BAA for ; Tue, 21 Nov 2017 11:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 P8KyJdx-pDcT for ; Tue, 21 Nov 2017 11:34:02 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 E2642129BA8 for ; Tue, 21 Nov 2017 11:34:01 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id r68so5781527wmr.1 for ; Tue, 21 Nov 2017 11:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xyplM1nbN2ZHTQYSIqs05nHIjLUHiphZ+vWiWFoZWJw=; b=RKWII3nIpHxuOYukgIJDujQuty4nZAgiFWpT3levdnl/jDEbAnZ1iUFLRicTBx7S7o 0l3dVBZfaAutVA0sQqHk1Pj0tzM/aDN/7uIF3nmP7guCemnK/KyJRGabTKVST55AQfuA FrhOusASVn1d35UMR4HciwxupV6MtSLYAfzi2D8o/U/PUf7bVct9b693AVE9m55qvPX+ vU75Qe0gWfCSSNYyoVQQKaneG1z4LNSk8/u5FFKjlPlUx8SfYitayiORYwA5FYwe2PFA pqbr8MwLXGceKsW7+3zPVdQf+qWJtUpbeqcDRW6k0si25JnRHvEWNGPotDTn1Yshftiz 6jIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xyplM1nbN2ZHTQYSIqs05nHIjLUHiphZ+vWiWFoZWJw=; b=LsT9B5LYQ7gdyhnt0FlZoVUGMtMRBFARsIOt+L2jVQxsG570fiAsoOjfe1vFjaehU4 WImZZsfJckuUiFlSK+2A4ZQTI8VypWr/qFeDZB71HlA/YK1dGZq8hpWMskKFVT9DDRpf Gt/hNYul6SpjEHBZ7Nji9aopWEYj3HXwm4FuwBKBeZVCUxY5eJEorMgvSO/+XuxYyuTe 4mrubRIVa3+UDZypl7gfbGYiZh33IEn9u9sJb8YiAtRhtB4z0loP+xqVC1cAq3fp/INs qtWtGigGNVnPQLniuOoG3+cHcWekJfueE07aBMkaK2Xj7WYqK/+R6qX1GMmmQ9DsRVOJ eeAA== X-Gm-Message-State: AJaThX5zXQGHDwx/tihypFSiCjsf47tBuUyXu4s3MTbkw+AkxK97Uer9 ARbl04AWj4cPr/fUN6QUJsDB+gzM5j3DaOI/5kWmyjXp X-Google-Smtp-Source: AGs4zMZQmCs3ZfTQsmWyUKXtF4aPNNTyy0h7sR2RX+098QYTUxUAtncfX5wrrf/kKrmT/+thOhXajkdlnmlKckvP73U= X-Received: by 10.80.142.178 with SMTP id w47mr3099837edw.251.1511292840189; Tue, 21 Nov 2017 11:34:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.162.197 with HTTP; Tue, 21 Nov 2017 11:33:59 -0800 (PST) In-Reply-To: References: From: Al Cutter Date: Tue, 21 Nov 2017 19:33:59 +0000 Message-ID: To: Eran Messeri Cc: Trans Content-Type: multipart/alternative; boundary="f403045c0d50e4d4bf055e8348b9" Archived-At: Subject: Re: [Trans] Section 4.2 follow-up X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 21 Nov 2017 19:34:04 -0000 --f403045c0d50e4d4bf055e8348b9 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri wrote: > [shortening subject] > > Two MUSTs are being discussed: > (1) "the log MUST NOT accept any submission until it has verified ..." > Actually it's just this one, I think the one below was included possibly by mistake (I mentioned to that to Rob when I spotted it on the PR). > (2) "The log MUST NOT use other sources of intermediate CA certificates" > > These MUSTs are to do with security (as Andrew Ayer pointed out > ) > as well as protocol correctness and determinism of the logs, not in order > to restrict what logs should accept. > > A consensus has already been established in the group that logs need to be > allowed to accept certificates that are not fully compliant with RFC5280 > validation rules (hence the SHOULD in the second paragraph of said section > and MAY on the third paragraph). > > Another consensus was established that logs should be allowed to drop > valid submissions under load (to protect against DoS attacks) - which again > is allowed by the SHOULD on the 2nd paragraph. > > The MUSTs that have remained, have remained there to guarantee that a > submission has made it into the log if, and only if, it has been validated > according to the log's implementation (which, again, may deviate from > RFC5280). These MUSTs are in place to guide the implementation, even if > there's no technical way to validate, from an external POV, that a log > adhered to them at all times. > > To present from a different angle, if the MUSTs are changed to SHOULDs > then (according to my understanding of RFC2119) logs will be able to claim > that any accepted submission was not validated because the it wasn't > checked. That would make monitoring difficult and submission > non-deterministic (because a log would then be allowed to use other sources > of intermediate CA certificates to complete a partially-submitted chain). > > RFC2119 says about SHOULD that "there may exist valid reasons in > particular circumstances to ignore a particular item [...]" but I do not > see a valid reason to ignore validation for some entries or allow > acceptance of partial chains, where the 6962-bis goes to great length to > ensure the submitted, valid chain is always presented to monitors. > > From what I can tell, the arguments in the GitHub PR mentioned > below either fall into the "non-RFC5280-compliant submission" (which is > already covered) or involve the implications of a particular log not being > 6962-bis compliant, which fall into the Client Behaviour category > (implications of the protocol on clients and servers' behaviour, not the > protocol specification itself). > > This part of section 4.2. has been discussed on the list a year ago ( > https://www.ietf.org/mail-archive/web/trans/current/msg02484.html) and > earlier (https://trac.ietf.org/trac/trans/ticket/73, > https://trac.ietf.org/trac/trans/ticket/21). > > On Mon, Nov 20, 2017 at 7:22 PM, Al Cutter wrote: > >> Hi all, >> >> I was trying to help (honest!) Rob Stradling with the outstanding AD >> comments from ekr on -bis27, and so we took an easy starter for 10: >> [ekr] *"Why is this a 2119 MUST? It seems wise, but not necessarily >> a conformance requirement"* >> in regards to Section 4.2: >> >>> "To avoid being overloaded by invalid submissions, the log MUST NOT >>> accept any submission until it has verified that the certificate or >>> precertificate was submitted with a valid signature chain to an accepted >>> trust anchor. >> >> >> FWIW I agree with ekr on this (it's a policy statement, and, I believe, a >> potentially dangerous one to encode as an RFC MUST) and managed to persuade >> Rob of the same (at least that's what he said at the time), so he kindly >> put together a PR to change that MUST NOT to a SHOULD NOT: >> https://github.com/google/certificate-transparency-rfcs/pull/289 >> >> Apparently not everyone sees it quite so clearly, and there's been a bit >> of a discussion on the PR, so in the interests of Transparency I wanted to >> call it out here too in case there's anybody who was not already aware of >> the PR and wants to get involved, again, on this well worn and comfy topic. >> >> Cheers, >> Al. >> >> >> >> _______________________________________________ >> 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 > > --f403045c0d50e4d4bf055e8348b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <eranm@google.com>= wrote:
[shorteni= ng subject]

Two MUSTs are being discussed:
(1)= "the log MUST NOT accept any submission until it has verified ...&quo= t;

Actually it's just this = one, I think the one below was included possibly by mistake (I mentioned to= that to Rob when I spotted it on the PR).
=C2=A0
(2) "The log MUST NOT use o= ther sources of intermediate CA certificates"

These MUSTs are to do with security (as Andrew Ayer pointed out) as well as protocol correctness and d= eterminism of the logs, not in order to restrict what logs should accept.

A consensus has already been established in the gro= up that logs need to be allowed to accept certificates that are not fully c= ompliant with RFC5280 validation rules (hence the SHOULD in the second para= graph of said section and MAY on the third paragraph).

=
Another consensus was established that logs should be allowed to drop = valid submissions under load (to protect against DoS attacks) - which again= is allowed by the SHOULD on the 2nd paragraph.

Th= e MUSTs that have remained, have remained there to guarantee that a submiss= ion has made it into the log if, and only if, it has been validated accordi= ng to the log's implementation (which, again, may deviate from RFC5280)= . These MUSTs are in place to guide the implementation, even if there's= no technical way to validate, from an external POV, that a log adhered to = them at all times.

To present from a different ang= le, if the MUSTs are changed to SHOULDs then (according to my understanding= of RFC2119) logs will be able to claim that any accepted submission was no= t validated because the it wasn't checked. That would make monitoring d= ifficult and submission non-deterministic (because a log would then be allo= wed to use other sources of intermediate CA certificates to complete a part= ially-submitted chain).

RFC2119 says about SHOULD = that "there may exist valid reasons in particular circumstances to ign= ore a particular item [...]" but I do not see a valid reason to ignore= validation for some entries or allow acceptance of partial chains, where t= he 6962-bis goes to great length to ensure the submitted, valid chain is al= ways presented to monitors.

From what I can tell, = the arguments in the GitHub PR mentioned below=C2=A0either fall into the &q= uot;non-RFC5280-compliant submission" (which is already covered) or in= volve the implications of a particular log not being 6962-bis compliant, wh= ich fall into the Client Behaviour category (implications of the protocol o= n clients and servers' behaviour, not the protocol specification itself= ).

This part of section 4.2. has been discussed on= the list a year ago (https://www.ietf.org/mail-a= rchive/web/trans/current/msg02484.html) and earlier (https://trac.ie= tf.org/trac/trans/ticket/73, https://trac.ietf.org/trac/trans/t= icket/21).

On Mon, Nov 20, 2017 at 7:22 PM, Al Cutter <al@google.com> wr= ote:
= Hi all,

I was trying to help (honest!) Rob Stradling wit= h the outstanding AD comments from ekr on -bis27, and so we took an easy st= arter for 10:=C2=A0
=C2=A0 =C2=A0 [ekr]=C2=A0"Why is this= a 2119 MUST? It seems wise, but not necessarily a conformance requirement&= quot;=C2=A0
in regards to Section 4.2:
"To avoid being overloaded by invalid= submissions, the log MUST NOT accept any submission until it has verified = that the certificate or precertificate was submitted with a valid signature= chain to an accepted trust anchor.

FWIW I = agree with ekr on this (it's a policy statement, and, I believe, a pote= ntially dangerous one to encode as an RFC MUST) and managed to persuade Rob= of the same (at least that's what he said at the time), so he kindly p= ut together a PR to change that MUST NOT to a SHOULD NOT:=C2=A0https://github.com/google/certificate-transparency-rfcs/p= ull/289

Apparently not everyone sees it quite = so clearly, and there's been a bit of a discussion on the PR, so in the= interests of Transparency I wanted to call it out here too in case there&#= 39;s anybody who was not already aware of the PR and wants to get involved,= again, on this well worn and comfy topic.

Cheers,=
Al.



_______________________________________________
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


--f403045c0d50e4d4bf055e8348b9-- From nobody Wed Nov 22 03:55:08 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07DD126CB6 for ; Wed, 22 Nov 2017 03:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 j-in4PB3eSYE for ; Wed, 22 Nov 2017 03:55:04 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 41EBA126BF0 for ; Wed, 22 Nov 2017 03:55:04 -0800 (PST) Received: (qmail 30577 invoked by uid 1004); 22 Nov 2017 11:55:01 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 22 Nov 2017 11:55:01 +0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.6.0 DEB8 x64) with ASMTP (SSL) id 201711221155011768; Wed, 22 Nov 2017 11:55:01 +0000 To: Al Cutter , Eran Messeri , Trans References: From: Rob Stradling Message-ID: Date: Wed, 22 Nov 2017 11:55:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Section 4.2 follow-up X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 22 Nov 2017 11:55:07 -0000 On 21/11/17 19:33, Al Cutter wrote: > > > On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri > wrote: > > [shortening subject] > > Two MUSTs are being discussed: > (1) "the log MUST NOT accept any submission until it has verified ..." > > > Actually it's just this one, I think the one below was included possibly > by mistake (I mentioned to that to Rob when I spotted it on the PR). Yeah, I misunderstood which MUSTs (in section 4.2) EKR (and Al) thought should be SHOULDs. I've updated the PR. This discussion is now only about whether or not that first "MUST NOT" should be changed to "SHOULD NOT". From the discussion on the PR, it seems that: - Eran and Andrew strongly prefer "MUST NOT". - EKR wrote "this is a WG decision" and so I presume he'll accept either "MUST NOT" or "SHOULD NOT". - Al is the sole proponent of changing it to "SHOULD NOT". Al, can you live with "MUST NOT"? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Nov 22 08:58:58 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73301127869 for ; Wed, 22 Nov 2017 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 WBeXHAgnOJo1 for ; Wed, 22 Nov 2017 08:58:55 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 B701F126D74 for ; Wed, 22 Nov 2017 08:58:55 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id c195so4563081ywh.10 for ; Wed, 22 Nov 2017 08:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xuIE9DBgwXar8rTUSAvKEBnvliXwFiObgNR3bOif6m8=; b=Kz+39XmTAANbrfoa4MHE/Img9ea/NPf7cLl+CQYt5Fpq6kgKTeIYf2rrjjzB0gis3r /rDtL+LpO/bwcpcTb2yswHrzJL4YVScka5Wu22OfFQu9szpDy7iVYIgGPoHgxDjvxPhp y9CBWOek8k+hgRomZyUCLK46jOWlcz8ghEFm1NSFWZt0URQIqTFizlH7+jDqdGlFVC7l 0jaxzA8fjDFcUHEe7cIrBUUGNT7HpFIxuAPHkIgx4XM/kGjVMbhjHOffFpItoNJ534Z/ UoVH0S88W8vf9gv2qPda+70xnSwFHZJ0hTDzFTBb5Va1OF58j10FGvdK0XWP+wq51N39 jg1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xuIE9DBgwXar8rTUSAvKEBnvliXwFiObgNR3bOif6m8=; b=MYLYvVi5IUnfJ4iL6vb7JGTR5kKQDPqTuU0M8lxRTBSoQhSSB3fiDUZ0vVdlmShXxa ea2EobNQFOqdbwIhU89NZmLex0ImstDuCeMPdhLMevQD6BSMsbOtzoiZEMVlD0NCpNZB aWUMD3rGYBhhXX6KuaQs/RI30rT1Rb1x4jDwt0NtTqtXEcw4dIft9+tHnIByfC5xNw12 uURXyrn4b16sAnl/ygugvYUIpWALCU+FdW8lwCLsRyg3Pe0TQs/JrZRtDnswQje4J4Co MORO52UmlF3NFV5Tl8I/EY/p0VquQaL9ZZljg/Ju4IYbwSI7r0dzIW8Jhm2orQS+G6Fb jddA== X-Gm-Message-State: AJaThX5FY9R8V6eB7Akafl4Jzkioisbuw85BWk15I9hRZXPFPG1DtKt5 wqpyFfuYolqjfpFgfAxoQrNSzxMgDTOvuEmYQa1rDw== X-Google-Smtp-Source: AGs4zMYLp/36xFsG5WdZTMPdvLbzoJEshq9BsIH5DlIgfcPebixtO9G+8dhQoHy9MUtHdF39Lmebr5fn1bA27fnLvfk= X-Received: by 10.129.87.210 with SMTP id l201mr14260402ywb.2.1511369932364; Wed, 22 Nov 2017 08:58:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 22 Nov 2017 08:58:11 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 22 Nov 2017 08:58:11 -0800 Message-ID: To: Rob Stradling Cc: Al Cutter , Eran Messeri , Trans Content-Type: multipart/alternative; boundary="001a11457576f186cb055e953b2f" Archived-At: Subject: Re: [Trans] Section 4.2 follow-up X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 22 Nov 2017 16:58:57 -0000 --001a11457576f186cb055e953b2f Content-Type: text/plain; charset="UTF-8" On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling wrote: > On 21/11/17 19:33, Al Cutter wrote: > >> >> >> On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri > eranm@google.com>> wrote: >> >> [shortening subject] >> >> Two MUSTs are being discussed: >> (1) "the log MUST NOT accept any submission until it has verified ..." >> >> >> Actually it's just this one, I think the one below was included possibly >> by mistake (I mentioned to that to Rob when I spotted it on the PR). >> > > Yeah, I misunderstood which MUSTs (in section 4.2) EKR (and Al) thought > should be SHOULDs. > > I've updated the PR. This discussion is now only about whether or not > that first "MUST NOT" should be changed to "SHOULD NOT". > > From the discussion on the PR, it seems that: > - Eran and Andrew strongly prefer "MUST NOT". > - EKR wrote "this is a WG decision" and so I presume he'll accept either > "MUST NOT" or "SHOULD NOT". > I'll accept MUST NOT as long as the MUST NOT is unambiguous. I thought it was but the discussion in the PR suggests that it's not because we don't know what the lax validation exception covers. As long as you have clarity on that point then SHOULD NOT/MUST NOT is totally up to the WG. -Ekr > - Al is the sole proponent of changing it to "SHOULD NOT". > > Al, can you live with "MUST NOT"? > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11457576f186cb055e953b2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling <rob.stradling@c= omodo.com> wrote:
On 21/11= /17 19:33, Al Cutter wrote:


On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <eranm@google.com <mailto:eranm@google.com>> wrote:=

=C2=A0 =C2=A0 [shortening subject]

=C2=A0 =C2=A0 Two MUSTs are being discussed:
=C2=A0 =C2=A0 (1) "the log MUST NOT accept any submission until it has= verified ..."


Actually it's just this one, I think the one below was included possibl= y by mistake (I mentioned to that to Rob when I spotted it on the PR).

 Yeah, I misunderstood which MUSTs (in section 4.2) EKR (and Al) thought sho= uld be SHOULDs.

I've updated the PR.=C2=A0 This discussion is now only about whether or= not that first "MUST NOT" should be changed to "SHOULD NOT&= quot;.

>From the discussion on the PR, it seems that:
=C2=A0 - Eran and Andrew strongly prefer "MUST NOT".
=C2=A0 - EKR wrote "this is a WG decision" and so I presume he= 9;ll accept either "MUST NOT" or "SHOULD NOT".

I'll accept MUST NOT as long as the MUST NO= T is unambiguous. I thought it was but the discussion in the PR suggests th= at it's not because we don't know what the lax validation exception= covers. As long as you have clarity on that point then SHOULD NOT/MUST NOT= is totally up to the WG.

-Ekr



=C2=A0
=C2=A0 - Al is the sole proponent of changing it to "SHOULD NOT".=

Al, can you live with "MUST NOT"?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


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

--001a11457576f186cb055e953b2f-- From nobody Mon Nov 27 00:49:53 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288C4127369 for ; Mon, 27 Nov 2017 00:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xvWElf30f06j for ; Mon, 27 Nov 2017 00:49:50 -0800 (PST) Received: from ns30.small-dns.com (ns31.small-dns.com [14.102.148.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3A36C1200F3 for ; Mon, 27 Nov 2017 00:49:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=webmail.internetworks.my) by ns30.small-dns.com with esmtpa (Exim 4.72) (envelope-from ) id 1eJF6r-0001Xr-1l for trans@ietf.org; Mon, 27 Nov 2017 16:49:49 +0800 Received: from 103.5.182.22 (SquirrelMail authenticated user shafiq_aiman@internetworks.my) by webmail.internetworks.my with HTTP; Mon, 27 Nov 2017 16:49:49 +0800 Message-ID: <39606685a33587204c04d49b14330a6e.squirrel@webmail.internetworks.my> Date: Mon, 27 Nov 2017 16:49:49 +0800 From: shafiq_aiman@internetworks.my To: trans@ietf.org Reply-To: shafiq_aiman@internetworks.my User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [Trans] Self Introduction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 27 Nov 2017 08:49:51 -0000 Hello everyone, My name is Shafiq Aiman. Im a researcher from InterNetWorks Research Lab located in Universiti Utara Malaysia. I just subscribed to this group mailing list. I hope I can learn something news in here. Regards, Shafiq Aiman