From nobody Mon Aug 1 05:54:00 2016 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 20B2E12DBFC for ; Mon, 1 Aug 2016 05:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 GujPxkiApBVt for ; Mon, 1 Aug 2016 05:53:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279CF12DBBD for ; Mon, 1 Aug 2016 05:48:31 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:60908 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bUCdy-000AOR-7b for trans@ietf.org; Mon, 01 Aug 2016 08:48:30 -0400 To: trans@ietf.org References: <87poroap4u.fsf@alice.fifthhorseman.net> <4826e966-de00-3d8d-1079-d9d21bdc16c8@bbn.com> <6c1e8d74-3aa9-8990-25e8-37da4bc6c648@gmail.com> <15088a12-8846-ff72-49fd-684ab2ea225f@bbn.com> <594a99fb-fc64-905d-92f0-aa10457645f8@nist.gov> From: Stephen Kent Message-ID: <6c268147-f1aa-1a43-a70c-67e90db710ed@bbn.com> Date: Mon, 1 Aug 2016 08:48:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <594a99fb-fc64-905d-92f0-aa10457645f8@nist.gov> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] threat analysis v06 review X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 12:54:00 -0000 David, I'm not sensing any love in your reply :-(. I had hoped that you would respond to my message by citing text from 5280 that justifies your assertion that a CA is defined, exclusively, by its name and key, but you have not. I was hoping that you would comment on my analogies, noting why you don't believe they are valid, but you did not. Color me sad. Nonetheless, I will revise the text inspired by DKG's initial message, to see if I can do better. Steve From nobody Wed Aug 3 07:13:57 2016 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 271E112DC16 for ; Wed, 3 Aug 2016 07:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 yXZPhsTmilt8 for ; Wed, 3 Aug 2016 07:13:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76E512D5AF for ; Wed, 3 Aug 2016 07:07:15 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:36867 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bUwpG-0005iz-Gc; Wed, 03 Aug 2016 10:07:14 -0400 To: Melinda Shore , trans@ietf.org References: <20160727133959.10509.23419.idtracker@ietfa.amsl.com> From: Stephen Kent Message-ID: <1f27a760-d9b1-7b73-eac7-e7ddcc1a8424@bbn.com> Date: Wed, 3 Aug 2016 10:07:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-18.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 03 Aug 2016 14:13:56 -0000 I looked at the diff from 16-17 and from 17-18. A few of the issues I raised in my message on 6/16 have not been addressed. Most of the issues I discussed with Earn in my message of 6/22 do not seem to have been addressed. Steve > Hi, all: > > Please take a look at the draft and let us know if > your concerns have been addressed, as we'll be restarting > working group last call soon. > > Thanks, > > Melinda From nobody Thu Aug 11 12:43:40 2016 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 BD8FE12D09C for ; Thu, 11 Aug 2016 12:43:38 -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, FREEMAIL_FROM=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=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 gdqnxLBvF7QU for ; Thu, 11 Aug 2016 12:43:37 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::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 54E7D126579 for ; Thu, 11 Aug 2016 12:43:37 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id ez1so233533pab.3 for ; Thu, 11 Aug 2016 12:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=Ue7parnpdtph1ULljtBKNS5IlkYVMDLvFba2sU7qxgc=; b=dAret9sH8SdBHK3RhjpqVSlMcr9sXotkQmfeLE+a8deLouCO3RxpPCvwZfSb/kVmYm xKFW7sw8h+j+1TGJDm25LrbUwR8Jkci/bU2Pg4jm0ZOM2BQRN6Eg1q03nHCjomURWeA1 6PNkrdGl2eQomwmwjuPwn1ZYaHQ8u0zoR84tt7CsbhX3xBGjuK/fVeEg7RbRep40sxwC sqNia1obQIrLQw2CNn4H2wkwAzQWsU3VtABdYGPNXuXA+vHM/E3EJpY3X4/ZoDEapehn zvOHdriUKUkpzvhR1EvFldnyAzXVAdXIsNXNUbVXs/neksCuWwpZiOY9vyeYz6/r+BdP RTYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=Ue7parnpdtph1ULljtBKNS5IlkYVMDLvFba2sU7qxgc=; b=I3kNo3slYF4vzuh8+drkd4OvEd4BQH9ch5EdX9HBrqDMxYFcBlli+dYZCeSiZkVKUA 5v42MQmn8n0Lr8CtWxW6ayhIQcUpf5K0PSbFJ0e+DIxhwU8GZhQURyJFvC8i6efDx7rr UjodzJbPT5onqsqHG3kt479EpE7EThOBSr7ncakzXD8X1mS6NYbx30Xdmk+xecUAMmR8 4sVfZTDi05D9F3xh7R6JQxqznMrv56eHSmMDzt6zUfaulIm59SRgONUXMKtQYMdcVhGM 74hjqDN2NkUpBfJ6DDNpcysxOfDNpMYwkXwIKoPvbjDpx38+JuO9cPQQJtYVS835XCG1 BsIQ== X-Gm-Message-State: AEkoouvUtVDpy3ev9tXF8MqZnCTF9h+UjH9Wxxsukf99BW6jFgd8WSefKVYBVtL7H2QMqw== X-Received: by 10.66.249.201 with SMTP id yw9mr20406506pac.130.1470944616587; Thu, 11 Aug 2016 12:43:36 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (209-112-184-92-radius.dynamic.acsalaska.net. [209.112.184.92]) by smtp.googlemail.com with ESMTPSA id g13sm7239465pfb.7.2016.08.11.12.43.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 12:43:35 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <6747ae49-9fa3-87ce-eb26-66410d4a3be6@gmail.com> Date: Thu, 11 Aug 2016 11:43:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="I1fHxPNCksIEOAg8WRshcWMKF2LopxrSX" Archived-At: Subject: [Trans] New cached_info text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 11 Aug 2016 19:43:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I1fHxPNCksIEOAg8WRshcWMKF2LopxrSX Content-Type: multipart/mixed; boundary="6jclDiwQmI48tRhdA6Frdp0mk7Mj9f4MT" From: Melinda Shore To: "trans@ietf.org" Message-ID: <6747ae49-9fa3-87ce-eb26-66410d4a3be6@gmail.com> Subject: New cached_info text --6jclDiwQmI48tRhdA6Frdp0mk7Mj9f4MT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: One of the substantive -bis document changes since starting the wglc process is the addition of text treating the cached_info extension. The proposed text is posted here: https://github.com/google/certificate-transparency-rfcs/pull/186/files Please give it a read and post any comments you've got to the mailing list. Melinda --6jclDiwQmI48tRhdA6Frdp0mk7Mj9f4MT-- --I1fHxPNCksIEOAg8WRshcWMKF2LopxrSX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXrNVmAAoJELiGRpM6HoEuPaoQALpXAGoV3Q3zl64NgijLKKJY akQSVoss69BMFPY4Y0cPgx70vLwq4I8fpkPli39BuRT5VYqLvBlpNWyRFB0s54z+ AaTOrV/hmaNmTabk3rUzR4mZGYvkQFkg3IjzxLdkHMjqmzr5C79FWnWbaGLEdMFl VyY9I1mxB52xZUAKapZrVNfOToYuBxiY6ts/83JZXeSZojvih5I5SAUZrCWt4Jla 6gNPzPLv0iymBVm+HxWW4XTd0+kN3+oiRB8sCaNMZungFx6qkWRy1YvSglSjeU6s DvDnZNbQU65mI4TXk0r4rI59if2gs4ihqp13zD6OBwchXso79/pMtqoC6OL2hl7P zmHbyEkXc1I4PKCBP7IStMRx1N4t8kUG4zdsyI87g/qntxygcebLUEj1KUxe/5X7 nNvAHjab36Cyd9V8jDUctj0jTIqpufZx15gtEH3w3W4REQvezd3Ip7OCbT7rM/Q2 mwacqKknYuTWFSIyQE8qnU5jnGWMlMAslxaNxvZlNEEvQEWQcaRqazFgQVt5+muG UCDuczl/s/0IoRsnMlbnDIimxE5TreoRCoE+U60kH8MWUN5Abl3U2q5BGDYgO7mE DIAGMTOG1Cfvkz60J5qBKF62NehheNnHNsA1WowPU+7fR/dU3WeOr/BWqHn3gkPX UbWIheebxkueFeh67VaP =nf/k -----END PGP SIGNATURE----- --I1fHxPNCksIEOAg8WRshcWMKF2LopxrSX-- From nobody Fri Aug 12 08:05:38 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B140B12D768; Fri, 12 Aug 2016 08:05:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147101433170.13957.3238109889410124732.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2016 08:05:31 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-07.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 15:05:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Attack Model and Threat for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-07.txt Pages : 31 Date : 2016-08-12 Abstract: This document describes an attack model and discusses threats for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates are being developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-07 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/ From nobody Fri Aug 12 08:27:07 2016 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 1C8BD12D59F for ; Fri, 12 Aug 2016 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable 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 6dKcskgg6WZ8 for ; Fri, 12 Aug 2016 08:27:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D8C12D556 for ; Fri, 12 Aug 2016 08:17:49 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:56625 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bYEDT-000PrU-Oj for trans@ietf.org; Fri, 12 Aug 2016 11:17:47 -0400 To: "trans@ietf.org" From: Stephen Kent Message-ID: Date: Fri, 12 Aug 2016 11:17:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] draft-ietf-trans-threat-analysis-07.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 12 Aug 2016 15:27:06 -0000 This version incorporates several changes: - I swapped the order of 3.3 and 3.4, since the old 3.4 seems more consistent with the taxonomic approach used in 3.1 and 3.2 - In the new 3.4 I now refer to CA-1 and CA-2 as CA instances, vs. two distinct CAs, but note that in some contexts they might appear to be different CAs to their parents. - I note that the revocation problem that may arise in the class of attacks described here is not the fault of CT. - I revised the text to discuss the class of attacks more generally, and provide some examples rather than trying to describe all possible ways the attacks may be effected. I'm off on vacation now. See you after Labor Day. Steve From nobody Fri Aug 12 09:04:43 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93A12D7AA; Fri, 12 Aug 2016 09:04:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147101787850.14007.5496299292984612731.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2016 09:04:38 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-08.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 16:04:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Attack and Threat Model for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-08.txt Pages : 31 Date : 2016-08-12 Abstract: This document describes an attack model and discusses threats for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates are being developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-08 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/ From nobody Fri Aug 12 09:06:03 2016 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 C8E6A12D7B4 for ; Fri, 12 Aug 2016 09:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 c-MLNxwsmwM8 for ; Fri, 12 Aug 2016 09:06:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9B212D7AF for ; Fri, 12 Aug 2016 09:06:00 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:56685 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bYEy7-0000Ik-Hg for trans@ietf.org; Fri, 12 Aug 2016 12:05:59 -0400 From: Stephen Kent To: "trans@ietf.org" Message-ID: <8a5f5ef5-3d73-91df-ffa3-a7d4fc0d08d4@bbn.com> Date: Fri, 12 Aug 2016 12:05:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] draft-ietf-trans-threat-analysis-08 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 12 Aug 2016 16:06:01 -0000 updated the submission to fix a typo in the title that has hung around for several versions. From nobody Fri Aug 12 17:17:22 2016 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 B46D712D7EF for ; Fri, 12 Aug 2016 17:17:20 -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, FREEMAIL_FROM=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=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 dcQBOxwG7cwv for ; Fri, 12 Aug 2016 17:17:19 -0700 (PDT) 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 EE7D612D79C for ; Fri, 12 Aug 2016 17:17:18 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id p64so599575pfb.1 for ; Fri, 12 Aug 2016 17:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=LMF+Y59Fg2uhIcZJxC2tZN3zlGKmy2rD2W1H0V4aTrA=; b=Sik5y4BKfp/YyZ0fkyjzm/9TXzMLx9p7o2rmvmaZXWrESmAWKQYDTtZkuoiiRmWcdc kkQpJGq0Fd3UR5L7F/xIhMOg0pJhF5Os93Z7i7IjhjXwNCIBcVRFBlduRGcojXZUc5mT 8AUkgqbprVK2Z8ub6mbJzMvfXKR6SXeBmlwhSP7FfbHHtePURTCmL1XlRusemZmjqs7i QJsfda9wBqOrkfeJfWUXO3NeRDeE0U1HclQ1wbuqoCDe+Sz2ly7ufGos7+A2JqH+lQRw QDw2onz02DPbfkc1x9ZeRTdTBpEWZZPlWja4hxQrGOrkcfRMi+8LdzMmITrDaOEGDHgH R5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=LMF+Y59Fg2uhIcZJxC2tZN3zlGKmy2rD2W1H0V4aTrA=; b=b6ucy7wO1QZl6MAXIRMPr62PdXpq6lHPJAE1ie0+hQ+lxCP0T9DPCaEWMcDyM7SfSo 7zzDFr1Q9LvpRlBqMhm519OeY99EtTIuL64WUzoiQnQL1q913LDPlLWHT3hFvpUueg0x 2lcI9AxVO/mfpLgpknWwQruOu2v0qgJKAusQN+0syIbacnp9FOHB1z4RWUH+mbPIakTp 0TbN6MnZ/dWLC/tIDKdhm6/X9tJG4VZ79o+x2NqfqKmoRpMW17aofd8aTGNXdK0gHTDR SEfCCnS48dcqwdvB1ZBftck+iB3dGzoNnndXPm2fWtx/CBS7e4CjnbbauBmjxx48HrXI tmiw== X-Gm-Message-State: AEkoout26w0YTC+W6JoK/Ihxalrjk9VCJE3azZY7bx6HhQoGfLsGFiios+hY3DLyOoaHhg== X-Received: by 10.98.16.193 with SMTP id 62mr31763830pfq.132.1471047438445; Fri, 12 Aug 2016 17:17:18 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-79-200-radius.dynamic.acsalaska.net. [216.67.79.200]) by smtp.googlemail.com with ESMTPSA id bx9sm15679491pab.17.2016.08.12.17.17.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 17:17:17 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> Date: Fri, 12 Aug 2016 16:17:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t8vlO5kckTo8FkketJqBxrgmToU6T9JcJ" Archived-At: Subject: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 13 Aug 2016 00:17:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t8vlO5kckTo8FkketJqBxrgmToU6T9JcJ Content-Type: multipart/mixed; boundary="7JfcJRdviAfrlXN3AImpMQIFNm1jQa178" From: Melinda Shore To: "trans@ietf.org" Message-ID: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> Subject: Name redaction consensus call --7JfcJRdviAfrlXN3AImpMQIFNm1jQa178 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: Since there was no comment at all on the proposal to retain name redaction, we appear to have complete agreement that it should go. We'll go back into wglc when a new version is submitted. Melinda --7JfcJRdviAfrlXN3AImpMQIFNm1jQa178-- --t8vlO5kckTo8FkketJqBxrgmToU6T9JcJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXrmcMAAoJELiGRpM6HoEukgMQAJQLkq3B91z+W+gS77KMzhW9 VElM92wPdIRFeQdDpVNZNToHc11r/h6KQph9ivOgS2t+rKT/X9GrRU6bQhI4/mtM KmHRzOZeKBc/NM/+2PS4e4twWZ6eoTpmquRufSwCJcEBGRVczWclDAsrhob2vn/5 IhieffQjWEYKZhKPxcPsk7/tBTg1AsjQqvWUcwEJxSUX/5V9zmb4gLoAxgkkQDbD GA8pgsCxtFCt+G+b4ABNNVXCAv8EXObspRJSDimoM6GTOOSuKKw+Zee8Kl2aeGn+ anEOKDzZk79MuTDcc8w2EmpTLSIBwADl0OEthFVdMkrugrpT9ZVlBxjdLtpFekfj 2W0ZUhQxaWRBnF2qoi4ZzPgKbUS0U3Tau4U6wpPBJoiEH9V8C9146WyBvJ3F1Tzq MtT4CZCGrI2ki/0yD4hhiRFsT3yG66gW2jtvkiekZMlT3FsCyXrULqBcixtWRDZO Fo7WiJBf931aGvUsAgHgOkBawxKphIoPdOQJ3jI+Rpje+tiumm8mn1Yz6ZbJGp3S HzCNRQeEvVD/YVlMdKkMeWLufbT09LfpfFxRNB1hWD/Kreicwr2goLQSAW0rs+UY OmF7s6HvX7sJsqVqf+xZoRwZoW3JqM7IEkLnhCKu4AFL4efkQivzqFC62X030BHY vF2LSUkfiT4Gy5KSaYLD =VrVN -----END PGP SIGNATURE----- --t8vlO5kckTo8FkketJqBxrgmToU6T9JcJ-- From nobody Fri Aug 12 17:36:08 2016 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 B21B512D94D for ; Fri, 12 Aug 2016 17:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.968 X-Spam-Level: X-Spam-Status: No, score=-3.968 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 F6elpHC2n6TB for ; Fri, 12 Aug 2016 17:36:05 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 36CBE12D92F for ; Fri, 12 Aug 2016 17:36:04 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C646F433492; Sat, 13 Aug 2016 00:36:03 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AC698433404; Sat, 13 Aug 2016 00:36:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471048563; bh=0FmoIwmrLgZ36Svr5B8KgECC86fhKZ8KIQhKl1+2zNM=; l=518; h=From:To:Date:References:In-Reply-To:From; b=f1fIX9KPzQoKvU/Qxg8DCcVDFxy1/kRfXj8UkOEekOtwcY0ZWJNL/2f3OeSbY4mLz mFWUH6U7TZzucY0vEdWIVwQxET5ajFoZhxVCnfoffPFZbJ1sp4taiArxCat8TiGIe3 100JENCH3BQ2mLAC5wvu4A6yWs/1gcscphlRmnrY= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A81C61FC8E; Sat, 13 Aug 2016 00:36:03 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 12 Aug 2016 17:36:03 -0700 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.1178.000; Fri, 12 Aug 2016 20:36:03 -0400 From: "Salz, Rich" To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Name redaction consensus call Thread-Index: AQHR9Pg2SNrkyOdk30eREhSJubYRyqBGCxzQ Date: Sat, 13 Aug 2016 00:36:03 +0000 Message-ID: <62b7bda9d4974a32a79d435d4b625f49@usma1ex-dag1mb1.msg.corp.akamai.com> References: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> In-Reply-To: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 13 Aug 2016 00:36:07 -0000 PiBTaW5jZSB0aGVyZSB3YXMgbm8gY29tbWVudCBhdCBhbGwgb24gdGhlIHByb3Bvc2FsIHRvIHJl dGFpbiBuYW1lIHJlZGFjdGlvbiwNCj4gd2UgYXBwZWFyIHRvIGhhdmUgY29tcGxldGUgYWdyZWVt ZW50IHRoYXQgaXQgc2hvdWxkIGdvLiAgV2UnbGwgZ28gYmFjayBpbnRvDQo+IHdnbGMgd2hlbiBh IG5ldyB2ZXJzaW9uIGlzIHN1Ym1pdHRlZC4NCg0KSSBkaWQgcmVwbHkgdGhhdCBJIHdhbnRlZCB0 byBrZWVwIHJlZGFjdGlvbiwgYnV0IGFncmVlIHRoYXQgY29uc2Vuc3VzIGlzIGFnYWluc3QgaXQu DQoNCi0tICANClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCklNOiByaWNo c2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg== From nobody Fri Aug 12 22:11:10 2016 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 4FB9212D0DB for ; Fri, 12 Aug 2016 22:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, 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 2YLS-Il5GOuo for ; Fri, 12 Aug 2016 22:11:08 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C0512D0D8 for ; Fri, 12 Aug 2016 22:11:08 -0700 (PDT) Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id 2E8727FA750; Sat, 13 Aug 2016 05:11:07 +0000 (GMT) From: Jeremy Rowley To: "Salz, Rich" , Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Name redaction consensus call Thread-Index: AQHR9PgSm0pRAAPNiUWWymxOEUawIaBGb/yA///oLcA= Date: Sat, 13 Aug 2016 05:11:05 +0000 Message-ID: References: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> <62b7bda9d4974a32a79d435d4b625f49@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <62b7bda9d4974a32a79d435d4b625f49@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.207.47.202] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0297_01D1F4EE.CD05D3C0" MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 13 Aug 2016 05:11:09 -0000 ------=_NextPart_000_0297_01D1F4EE.CD05D3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I also objected to removing name redaction, but I think it was just Rich and I. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Friday, August 12, 2016 6:36 PM To: Melinda Shore ; trans@ietf.org Subject: Re: [Trans] Name redaction consensus call > Since there was no comment at all on the proposal to retain name > redaction, we appear to have complete agreement that it should go. > We'll go back into wglc when a new version is submitted. I did reply that I wanted to keep redaction, but agree that consensus is against it. -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ------=_NextPart_000_0297_01D1F4EE.CD05D3C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODEzMDUxMTA0WjAj BgkqhkiG9w0BCQQxFgQUin2DK91ZUyjPsdMHs7/oNecF+A4wgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAL4PG+FCs7lSORxEd8mmpMCS367VsvS+qvQ69mgR +x9CyIiRNY9hvnkrOHvUzuP+7iccoopti5voCWIQ4BsKz0LEnZKXdD+a4hmNnvCuzLPlIJwBSExt Qcx758LU6GEI5j7izZdkTuXzYOzsVo5VH0wheGqJ3x7to4swKtFpGM/NO9leCNXWErBXHeHzYQBS vb0Ipmqb5sgyouxmeHknPYkxITVMTqrEDnOv9EvvKCiaTWAvjmmj6HG+X6VrQjsp7uVBbWqiy/yY 1N+iaI0xba+FX9aNLNWLiwvNK1tI6XUzgk3I7WIeW98gpvcwC34hHtLK5Ctbr69mLBwLsfpRF8wA AAAAAAA= ------=_NextPart_000_0297_01D1F4EE.CD05D3C0-- From nobody Sat Aug 13 14:44:31 2016 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 DE52E12D5D0 for ; Sat, 13 Aug 2016 14:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 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, RP_MATCHES_RCVD=-1.247, 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 ICkQmBN8sifz for ; Sat, 13 Aug 2016 14:44:28 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 D822B12D556 for ; Sat, 13 Aug 2016 14:44:27 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id q128so32963154wma.1 for ; Sat, 13 Aug 2016 14:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GpZEwN3MO6mQqq7o95W+4Qkobx1Caf0x2I8BXgnQF1Q=; b=XVhZtbh5uCfc3RH8UhQ7PFROURa+PhS9gZLkUjXkyQKgRGXAuKndCZlrqFubGE0Ect PEoutsFIdgZ1995V4ysoB8TsBIHPyGgeZHFYJ64QiOKs7EaKbP7+821NvYpf998tR0pC tMfg2irKAiHu1hwYDjJ8RFWzoilcRD7ra7VqUoNfPgH7zFVNy5xWm16xlXwMPdTsGY0H hRzPe47Zn6psWBk+2LQtoQq2M+BwCa38nBsFRr502iiR890D78b6/fXfsHQWNANPsjmY hhOnhaMn523bjqihQqWDtSR7cj/cM5jQSeczFRh9UQCaB1w1dwkzpzRpLUUszP6KGkzR nrOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GpZEwN3MO6mQqq7o95W+4Qkobx1Caf0x2I8BXgnQF1Q=; b=MfbD0nCyp+KIJLMFl6mpPok93LR6l6MvDtV5NzhYrauhHTTzG5gU9/08B5oDfcMx22 /IqK0TcHFirVBbXww41OXLwVVLPBUFtF4tb/a8CBi5/tBu1vquJKkZ417ZU1ekdZR5K2 aIVv7ykit6Mfrk2i8xAhTk08ozW+UvvU5YHttcyhOHOelotRf8Vv4WbfB2xtDuS+MXQb y3u+R8vjcgHdHkh5po58SIeuNkEo38r/VQqucBispVWT9eBA76ONhlf73/qU7L+MaFoC dHhtZUGC/z9oKxipYuIV4lbhIP0J0NRn+U1aMZLYcODPs6s++lrKKAR1f4n5IV2sgSXi wAMg== X-Gm-Message-State: AEkoouuIKjyHg1QpIkXSf4VOJuGPcevobKFpJAhbKEiO6HXMAr0mvJ4QGARrmIQb8HLIECBgoNDmEFY+rDozxNso X-Received: by 10.28.65.84 with SMTP id o81mr5252553wma.83.1471124666040; Sat, 13 Aug 2016 14:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.168.216 with HTTP; Sat, 13 Aug 2016 14:44:25 -0700 (PDT) In-Reply-To: References: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> <62b7bda9d4974a32a79d435d4b625f49@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eran Messeri Date: Sat, 13 Aug 2016 14:44:25 -0700 Message-ID: To: Jeremy Rowley Content-Type: multipart/alternative; boundary=001a1148e4942407d90539fae7f7 Archived-At: Cc: "Salz, Rich" , Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 13 Aug 2016 21:44:30 -0000 --001a1148e4942407d90539fae7f7 Content-Type: text/plain; charset=UTF-8 It would help a lot if those objecting to name redaction would provide their arguments against it (maybe as a link to another thread / document, as to not derail this thread). FWIW, my intention (and, to be clear, that's just me, before consulting the other authors of 6962-bis) is to move name redaction to a draft of its own rather than get rid of the concept, if the decision will be to move it out of 6962-bis. That is so we can continue discussing/refining it to suit the threats/concerns it intends to address. Eran On Fri, Aug 12, 2016 at 10:11 PM, Jeremy Rowley wrote: > I also objected to removing name redaction, but I think it was just Rich > and > I. > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Salz, Rich > Sent: Friday, August 12, 2016 6:36 PM > To: Melinda Shore ; trans@ietf.org > Subject: Re: [Trans] Name redaction consensus call > > > Since there was no comment at all on the proposal to retain name > > redaction, we appear to have complete agreement that it should go. > > We'll go back into wglc when a new version is submitted. > > I did reply that I wanted to keep redaction, but agree that consensus is > against it. > > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz > _______________________________________________ > 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 > > --001a1148e4942407d90539fae7f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would help a lot if those objecting to name redaction w= ould provide their arguments against it (maybe as a link to another thread = / document, as to not derail this thread).

FWIW, my inte= ntion (and, to be clear, that's just me, before consulting the other au= thors of 6962-bis) is to move name redaction to a draft of its own rather t= han get rid of the concept, if the decision will be to move it out of 6962-= bis. That is so we can continue discussing/refining it to suit the threats/= concerns it intends to address.

Eran

On Fri, Aug 12, 201= 6 at 10:11 PM, Jeremy Rowley <jeremy.rowley@digicert.com><= /span> wrote:
I also objected to removing= name redaction, but I think it was just Rich and
I.

-----Original Message-----
From: Trans [mailto:trans-bounces= @ietf.org] On Behalf Of Salz, Rich
Sent: Friday, August 12, 2016 6:36 PM
To: Melinda Shore <melinda.sh= ore@gmail.com>; trans@ietf.org=
Subject: Re: [Trans] Name redaction consensus call

> Since there was no comment at all on the proposal to retain name
> redaction, we appear to have complete agreement that it should go.
> We'll go back into wglc when a new version is submitted.

I did reply that I wanted to keep redaction, but agree that consensus is against it.

--
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: R= ichSalz
_______________________________________________
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


--001a1148e4942407d90539fae7f7-- From nobody Sat Aug 13 15:19:30 2016 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 DA92C12D572 for ; Sat, 13 Aug 2016 15:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 KnWYMhfAFJGw for ; Sat, 13 Aug 2016 15:19:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFD612D111 for ; Sat, 13 Aug 2016 15:19:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A4BCEBE25; Sat, 13 Aug 2016 23:19:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtksMhpc5TCy; Sat, 13 Aug 2016 23:19:21 +0100 (IST) Received: from [127.0.0.1] (unknown [95.39.226.90]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9DD78BDF9; Sat, 13 Aug 2016 23:19:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1471126761; bh=RJyjh1JBVMM1w/W+F5VOX4gVeYRinxN8Keyb6Pe2VZs=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=gFoIamuIM++IjB5liqBtng+aDLMQFkYkCvmA7NoF4GZD7ubmhyrv4x6bjK4VTzNjn eOsmW4oYP61Z0/ptCT4Q7WmjrL9+vHcal7/SKQgHJj7cNWdbdjOAbBmnvxqNAF6Dh+ ViwF3VTMkfmK8BIk1a9K89SZyDMk6bYZVfqh63xs= X-Priority: 3 To: eranm@google.com From: stephen.farrell@cs.tcd.ie In-Reply-To: References: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> <62b7bda9d4974a32a79d435d4b625f49@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Sat, 13 Aug 2016 22:19:16 +0000 Message-ID: MIME-Version: 1.0 Archived-At: Cc: rsalz@akamai.com, melinda.shore@gmail.com, trans@ietf.org, jeremy.rowley@digicert.com Subject: Re: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 13 Aug 2016 22:19:29 -0000 DQoNCk9uIFNhdCBBdWcgMTMgMjM6NDQ6MjUgMjAxNiBHTVQrMDIwMCwgRXJhbiBNZXNzZXJpIHdy b3RlOg0KPiBJdCB3b3VsZCBoZWxwIGEgbG90IGlmIHRob3NlIG9iamVjdGluZyB0byBuYW1lIHJl ZGFjdGlvbiB3b3VsZCBwcm92aWRlDQo+IHRoZWlyIGFyZ3VtZW50cyBhZ2FpbnN0IGl0IChtYXli ZSBhcyBhIGxpbmsgdG8gYW5vdGhlciB0aHJlYWQgLyBkb2N1bWVudCwNCj4gYXMgdG8gbm90IGRl cmFpbCB0aGlzIHRocmVhZCkuDQo+IA0KPiBGV0lXLCBteSBpbnRlbnRpb24gKGFuZCwgdG8gYmUg Y2xlYXIsIHRoYXQncyBqdXN0IG1lLCBiZWZvcmUgY29uc3VsdGluZyB0aGUNCj4gb3RoZXIgYXV0 aG9ycyBvZiA2OTYyLWJpcykgaXMgdG8gbW92ZSBuYW1lIHJlZGFjdGlvbiB0byBhIGRyYWZ0IG9m IGl0cyBvd24NCj4gcmF0aGVyIHRoYW4gZ2V0IHJpZCBvZiB0aGUgY29uY2VwdCwgaWYgdGhlIGRl Y2lzaW9uIHdpbGwgYmUgdG8gbW92ZSBpdCBvdXQNCj4gb2YgNjk2Mi1iaXMuIFRoYXQgaXMgc28g d2UgY2FuIGNvbnRpbnVlIGRpc2N1c3NpbmcvcmVmaW5pbmcgaXQgdG8gc3VpdCB0aGUNCj4gdGhy ZWF0cy9jb25jZXJucyBpdCBpbnRlbmRzIHRvIGFkZHJlc3MuDQoNCkZXSVcsICJmaWd1cmUgaXQg b3V0IGxhdGVyIiBzZWVtcyBsaWtlIGVudGlyZWx5IHRoZSByaWdodCBwbGFuIHRvIG1lLCBlc3Ag aWYgdGhhdCBkb2Vzbid0IHNsb3cgZG93biB0aGUgV0cuDQoNClMuIA0KDQoNCj4gDQo+IEVyYW4N Cj4gDQo+IE9uIEZyaSwgQXVnIDEyLCAyMDE2IGF0IDEwOjExIFBNLCBKZXJlbXkgUm93bGV5IDxq ZXJlbXkucm93bGV5QGRpZ2ljZXJ0LmNvbT4NCj4gd3JvdGU6DQo+IA0KPiA+IEkgYWxzbyBvYmpl Y3RlZCB0byByZW1vdmluZyBuYW1lIHJlZGFjdGlvbiwgYnV0IEkgdGhpbmsgaXQgd2FzIGp1c3Qg UmljaA0KPiA+IGFuZA0KPiA+IEkuDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IFRyYW5zIFttYWlsdG86dHJhbnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFNhbHosIFJpY2gNCj4gPiBTZW50OiBGcmlkYXksIEF1Z3VzdCAxMiwgMjAxNiA2OjM2 IFBNDQo+ID4gVG86IE1lbGluZGEgU2hvcmUgPG1lbGluZGEuc2hvcmVAZ21haWwuY29tPjsgdHJh bnNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW1RyYW5zXSBOYW1lIHJlZGFjdGlvbiBjb25z ZW5zdXMgY2FsbA0KPiA+DQo+ID4gPiBTaW5jZSB0aGVyZSB3YXMgbm8gY29tbWVudCBhdCBhbGwg b24gdGhlIHByb3Bvc2FsIHRvIHJldGFpbiBuYW1lDQo+ID4gPiByZWRhY3Rpb24sIHdlIGFwcGVh ciB0byBoYXZlIGNvbXBsZXRlIGFncmVlbWVudCB0aGF0IGl0IHNob3VsZCBnby4NCj4gPiA+IFdl J2xsIGdvIGJhY2sgaW50byB3Z2xjIHdoZW4gYSBuZXcgdmVyc2lvbiBpcyBzdWJtaXR0ZWQuDQo+ ID4NCj4gPiBJIGRpZCByZXBseSB0aGF0IEkgd2FudGVkIHRvIGtlZXAgcmVkYWN0aW9uLCBidXQg YWdyZWUgdGhhdCBjb25zZW5zdXMgaXMNCj4gPiBhZ2FpbnN0IGl0Lg0KPiA+DQo+ID4gLS0NCj4g PiBTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQo+ID4gSU06IHJpY2hzYWx6 QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gVHJhbnMgbWFpbGluZyBsaXN0DQo+ID4gVHJh bnNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry YW5zDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IFRyYW5zIG1haWxpbmcgbGlzdA0KPiA+IFRyYW5zQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFucw0KPiA+DQo+ID4NCj4= From nobody Mon Aug 15 06:21:39 2016 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 1051312D96A for ; Mon, 15 Aug 2016 06:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 ek5D-UBIrZA2 for ; Mon, 15 Aug 2016 06:21:35 -0700 (PDT) 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 72A5B12D8B9 for ; Mon, 15 Aug 2016 06:21:35 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f65so89263350wmi.0 for ; Mon, 15 Aug 2016 06:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eWfAv0KTScfdERpYjifXmZwM8Fp/L1ijNzK9EMa9ysQ=; b=iJQPxePALK8UngzknIr+fKNr3Wj0udG37wRzugaK49T8LCVBW983J9ym529ooLlgKk cTPwHfZgwsoHBgXhlk4Zp+qUcK4Au+FpEnwUZG5Op4kAUSKykx9oGLIPgHXLCdkyvh/3 IZt2Su4/zbEXM/SyPEhRt3TGCX8JvwY5jbgTucqJSIzVGyCxfKw8OvQ0u+e7+ssUlF4Y IdQnTlih3o+zRFW0CXrfhB4ux+Oy8A52PIrZlU7+yvr5H2s8Er9pYIx2QsfT10inonDd 63dYgnfMK4JXIBKgUux7zvUDe4MsWmZuBfs3sUgcNKX21Op+pcptK+EKsuBmpPV8FDSn +W4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eWfAv0KTScfdERpYjifXmZwM8Fp/L1ijNzK9EMa9ysQ=; b=Q8xze2E8oHvs835pg44QGjSJpfoR9B8qY9ZoA0d40/CskZjFRCDcilthCbjPcOB9Pp 1JO9u9A6ml4DrzD8ZcoApJH6iOSrcHZNn/394JfSMJBHAgbARGWGDaRgtRHTAhMaFq3A Uj2wsrtahvQL4q1SjOr+6iZTFnNd5fWChzxfWShT2/C374z17HdoR7IVpnlKZFTc+3Ud 3l8Hk5fRBePcZ2RIObtSCWwbH2yqSFx7DqyNEanzstG2xCOTAnFwIE60xWtjIlR9PtKZ uLRlRgm/2k9hhW0AW/nHcuGJwgwX27WEjiSR+8oMJek1J3y8jViodWTSJYySFCzFcJ7J 9eLA== X-Gm-Message-State: AEkooutsdcm328N9cikUSbM2cmE6llGafTc/E7h2gOFV9aaPc3syTYIbpBg1s2/R2XAceCZaoKhdhOGFTXKvbQ9Q X-Received: by 10.28.203.134 with SMTP id b128mr15926703wmg.36.1471267293450; Mon, 15 Aug 2016 06:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.168.216 with HTTP; Mon, 15 Aug 2016 06:21:32 -0700 (PDT) In-Reply-To: <6747ae49-9fa3-87ce-eb26-66410d4a3be6@gmail.com> References: <6747ae49-9fa3-87ce-eb26-66410d4a3be6@gmail.com> From: Eran Messeri Date: Mon, 15 Aug 2016 14:21:32 +0100 Message-ID: To: Melinda Shore Content-Type: multipart/alternative; boundary=94eb2c13013265d60f053a1c1cb8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] New cached_info text X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 15 Aug 2016 13:21:37 -0000 --94eb2c13013265d60f053a1c1cb8 Content-Type: text/plain; charset=UTF-8 My opinion is that this change is useful as it could save ~hundreds of bytes during the TLS handshake (TLS clients may require multiple SCTs to determine CT compliance of a certificate). Also, that makes the two cases of serving SCTs in the TLS handshake and embedded in the certificate equal (in terms of bandwidth consumption): Without this change, there would be a disadvantage to serving SCTs in the TLS handshake as it means the server always has to send SCTs, even if it can avoid sending the certificate (due to the information in the cached_info extension). On Thu, Aug 11, 2016 at 8:43 PM, Melinda Shore wrote: > Hi, all: > > One of the substantive -bis document changes since starting the wglc > process is the addition of text treating the cached_info extension. > The proposed text is posted here: > https://github.com/google/certificate-transparency-rfcs/pull/186/files > > Please give it a read and post any comments you've got to the mailing > list. > > Melinda > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --94eb2c13013265d60f053a1c1cb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My opinion is that this change is useful as it could save = ~hundreds of bytes during the TLS handshake (TLS clients may require multip= le SCTs to determine CT compliance of a certificate).=C2=A0

Al= so, that makes the two cases of serving SCTs in the TLS handshake and embed= ded in the certificate equal (in terms of bandwidth consumption): Without t= his change, there would be a disadvantage to serving SCTs in the TLS handsh= ake as it means the server always has to send SCTs, even if it can avoid se= nding the certificate (due to the information in the cached_info extension)= .



On Thu, Aug 11, 2016 at 8:43 PM, Melinda Sh= ore <melinda.shore@gmail.com> wrote:
Hi, all:

One of the substantive -bis document changes since starting the wglc
process is the addition of text treating the cached_info extension.
The proposed text is posted here:
https://github.com/google/certificate-transparency-rfcs/pull/186/files

Please give it a read and post any comments you've got to the mailing list.

Melinda


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


--94eb2c13013265d60f053a1c1cb8-- From nobody Mon Aug 15 07:49:30 2016 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 3994712D636 for ; Mon, 15 Aug 2016 07:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=unavailable 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 a9MpVjRmGV2Y for ; Mon, 15 Aug 2016 07:49:27 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 4633E12D1D1 for ; Mon, 15 Aug 2016 07:49:27 -0700 (PDT) Received: from localhost ([::1]:33885 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bZJCg-0007t1-PB; Mon, 15 Aug 2016 07:49:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Mon, 15 Aug 2016 14:49:26 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/158 Message-ID: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-Trac-Ticket-ID: 158 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160815144927.4633E12D1D1@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 07:49:27 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #158 (rfc6962-bis): Hash algorithm agility is hard to implement, as specified X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 14:49:29 -0000 #158: Hash algorithm agility is hard to implement, as specified The problem: Currently (draft 18) 6962-bis refers to the output size of the hash function chosen by a log (denoted HASH_SIZE) as a fixed value: opaque NodeHash[HASH_SIZE]; Further structs (TreeHeadDataV2, SignedTreeHeadDataV2, ConsistencyProofDataV2, InclusionProofDataV2) then use this definition, which means parsers expect a vector of bytes of fixed length. The difficulty lies in having to know which log the data structure is parsed for before finishing parsing, as it requires parsing just the LogID, looking up the log's metadata by that LogID and continuing parsing according to the size of the NODE_HASH of that log. That is impossible in the case of TreeHeadDataV2 which doesn't even include the LogID (and is not encapsulated in anything that does). Ideally parsing code for parsing all log data would be independent of the hash algorithm chosen for the code (which would extremely simplify implementation in any language I've witnessed, as the TLS deserialization code is in a completely different layer to the signature validation code). Two options: * Force a fixed HASH_SIZE for all logs, say 32 bytes. That may not be silly if that space is deemed sufficient to implement secure hashes with (even if a particular hash function is found to be weak). * Use a variable-length vector for storing hashes. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Aug 15 11:51:13 2016 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 C06DD12D0C1 for ; Mon, 15 Aug 2016 11:51:09 -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, FREEMAIL_FROM=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=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 6P9coLW-ZnSJ for ; Mon, 15 Aug 2016 11:51:05 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 B430512D08F for ; Mon, 15 Aug 2016 11:51:05 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id ti13so18374282pac.0 for ; Mon, 15 Aug 2016 11:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:from:subject:message-id:date:user-agent:mime-version; bh=9N2sFlXl7v+NqKf+BL/1cb7NfB1fOjt5Kfv2XbKhvFg=; b=nyR9gLbCKFMyfhePuJiLauhUsU10zx9UpRgu2PkFt5/VrYTtGMDP2LOhspPfr9YMfD x3C2wKFMt/ZiOLsP4vNnudJV/MDfojcHMzAVIldZDyAQhlf49KqQGKGsef2N0LAUbJxO WJBs28IeeAQlueGho2LHnwdAFpUdn86bgYDK/zh4Tu3L2SvXjPq8wPodDHKcKOQPk/m4 NTy2rrPj15PSPPuAQczYPCSLhgO7NldwNMgngD7JXWbCEpWGOrmEK2i3d6QwmsAcOvgR 1T1VBWgYyAURglEVkU/jluI91lpfZhIROF9kYASFuRxCZNRAHnJIQJfX2/vXuOT5QeqM 8MyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version; bh=9N2sFlXl7v+NqKf+BL/1cb7NfB1fOjt5Kfv2XbKhvFg=; b=P9+uionXXwlw/3jzTmwgettuzhLH05lGp/6C3GyS9I1OuS2RvQaH5IW4pvoKiOSaeQ CbcONoMUcRWypjGZtjzLwiAeTLl3sQgilHuC04nYT6sn68RwfRobcPOiZfeB/dvKX+Nn S45ovhBxpQWCkeYCiIsoIdPWh9idYSG5o36Wy80SqugC3NEGsoMjj6/l2jqEC8ruI+fS N0mZ2LhzEWprSLaFQUafZsZorfgjAFq1mdt+E3ipF8jGeCZRvG+irsTJCUxsSWbmHvG7 wpVhYSi3P9iQyvvOQHAr5oL5AR8Z2WNWHbu1Vvxo87Ai7M8fnbuVsawCIssdFDRkpH4h YUFw== X-Gm-Message-State: AEkooutTM6oNz78U/KHNdR38IwRiElnPREUCVUBAcvhK+WjrADAtM+nJ+jgtn81ZLwHkww== X-Received: by 10.66.159.170 with SMTP id xd10mr57169384pab.41.1471287065268; Mon, 15 Aug 2016 11:51:05 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (74-124-101-28-radius.dynamic.acsalaska.net. [74.124.101.28]) by smtp.googlemail.com with ESMTPSA id q26sm33188133pfj.53.2016.08.15.11.51.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Aug 2016 11:51:04 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <9f9605db-45f8-775b-ac61-788bf127134d@gmail.com> Date: Mon, 15 Aug 2016 10:51:02 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kJgTkNMxVTN2OuQ8XWfc1GWSRTJ0o4oFs" Archived-At: Cc: Paul Wouters Subject: [Trans] What to do with name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 15 Aug 2016 18:51:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kJgTkNMxVTN2OuQ8XWfc1GWSRTJ0o4oFs Content-Type: multipart/mixed; boundary="6RFUjpR2sEJdWEXtOhwFBXpBX6eVjx8KE" From: Melinda Shore To: "trans@ietf.org" Cc: Paul Wouters Message-ID: <9f9605db-45f8-775b-ac61-788bf127134d@gmail.com> Subject: What to do with name redaction --6RFUjpR2sEJdWEXtOhwFBXpBX6eVjx8KE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: As you've probably seen, we've got agreement to strip name redaction out of 6962-bis. However, since there's interest in seeing work on it continue, we'd like to propose splitting the existing text out into a separate working group document. (Redaction is going to be dropped from 6962-bis regardless). We'd be especially grateful if someone who's been advocating for the inclusion of name redaction in the deliverable would be willing to step forward as a co-author, or at least contribute significant text. Drop Paul and me a note if you'd like to volunteer. We'll close discussion on splitting it out on Monday, Aug 22. Thanks, Melinda --6RFUjpR2sEJdWEXtOhwFBXpBX6eVjx8KE-- --kJgTkNMxVTN2OuQ8XWfc1GWSRTJ0o4oFs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXsg8XAAoJELiGRpM6HoEuAh8P/jPzm5rAL8l6tiuZLbswRy1f L2Oq0klXFCa4W7P4WUAs72PEFxJD9MdEYfUwturs1IOf40RqWEq4GU937WFIlhCT MstdOGRDfm+0wcWu3AjzLuUxDpldnDa5wi3eFjplh4v/YW8kxulZvrHcFYvcet9V MkwFnXrAQw/S0oN6rvOuTL369veXndui2rDJTwmN/r3ZNPKhcpivxDursChgvurv LlJuWO77D0joZI8I3+mMKKtEBNN0+7Ny7ncm6nYNW0kyjOvhwZgwnOc6jCRAdzrL lHM/g9B4hVo7dzZosNuKwzujZFb2M3JnsbHoKS6BY3X8VnHutwA/6BXkINmcDifX Pk1KCSavlcCPYnYBHyHf1D7ByazZnyEK6N4T9SRz5sO/IVjF8u7MEmXk5ai/yRjV SxdtZ5MkVA5PnGxKWgEUkuiFLGvQA7pIUbsyqUCmRE/h0/4zS8MSVjUS5ApXLBb3 LLA5Ye/jQaqE5QbOGG7FPgqoBJpDr8ptYnwrElsANwWfjvrAyghjC7/lyJ2h14Ls 36obxlzi9z3nmpOqKNttPHlNm/2VQUA2pTT0PueGkul3iphvSjxGKZJ3IJHvx8CM AAIwVwTmlUPY/73hHJ8gEvYmo3h1RS/Rll6c5tf5U74rD/d0bGhWeVo8VpAZkdkV KMvcqfanSoqf9JtVsgqP =lPq/ -----END PGP SIGNATURE----- --kJgTkNMxVTN2OuQ8XWfc1GWSRTJ0o4oFs-- From nobody Mon Aug 15 11:52:53 2016 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 0F92112B01D for ; Mon, 15 Aug 2016 11:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.167 X-Spam-Level: X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.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 BhOKNlhAvXDP for ; Mon, 15 Aug 2016 11:52:50 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0DF128E18 for ; Mon, 15 Aug 2016 11:52:50 -0700 (PDT) Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symc.symantec.com [10.90.248.26]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id A7.AB.10709.18F02B75; Mon, 15 Aug 2016 19:52:49 +0100 (BST) Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat1.net.symantec.com [10.90.75.1]) by (Symantec Messaging Gateway) with SMTP id 46.9F.51154.18F02B75; Mon, 15 Aug 2016 18:52:49 +0000 (GMT) X-AuditID: d80ac3f2-f79236d0000029d5-1a-57b20f813d83 Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat5.net.symantec.com [10.90.75.5]) by (Symantec Messaging Gateway) with SMTP id 16.7D.12852.E7F02B75; Mon, 15 Aug 2016 18:52:49 +0000 (GMT) Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 15 Aug 2016 11:52:45 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.128.3) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Mon, 15 Aug 2016 11:52:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/wNHYd/6xNmYX4dz5qblBkA2TboHujMnyw715EkgZ8Y=; b=Pux/QixOoDhP2FvYFAss8FD2tJ8AxjF6cO2n11jUcwtT5qZ4HkgR3D00Ez3Is8eTrStq7uZRCGUiFlQh+qVoAbxpheTBHr+QpWBzqBw6vT2AaYS3F2xLxTspd7cWZM4L6vGVJiIDJvaABGy3i6IPvaprJVkYdMEcIbw2vvvVbq8= Received: from CY1PR16MB0522.namprd16.prod.outlook.com (10.163.253.140) by CY1PR16MB0523.namprd16.prod.outlook.com (10.163.253.141) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Mon, 15 Aug 2016 18:52:43 +0000 Received: from CY1PR16MB0522.namprd16.prod.outlook.com ([10.163.253.140]) by CY1PR16MB0522.namprd16.prod.outlook.com ([10.163.253.140]) with mapi id 15.01.0557.021; Mon, 15 Aug 2016 18:52:42 +0000 From: Sanjay Modi To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Name redaction consensus call Thread-Index: AQHR9yYzJH4Ixoh3AE2I3jnWVvUWqA== Date: Mon, 15 Aug 2016 18:52:42 +0000 Message-ID: References: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> In-Reply-To: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Sanjay_Modi@symantec.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [198.6.50.15] x-ms-office365-filtering-correlation-id: 9a5fbe1a-ee50-479a-a379-08d3c53d56b9 x-microsoft-exchange-diagnostics: 1; CY1PR16MB0523; 6:8VOhlQn78o3PKRFr6jmFSUwLII8IRhSkwyAMQPbk4+Ht8PaoKxpMpbN+HjrXpQfwCeAiZqPWs6Bqlx7RZaR4/s/J8eKjX60X+/8Bu5vNeT/h0zmkpZUbqNjVrUxuGH/+Z0voz+Ch1UigLlZ3m4IubHfcyYNlq1Et9/AHKVYQJLJIZnoIyJr9G/++Oj/GLpv+0e3NwPrAToV1bJAKn0vunJHav0uauS/YVqhq6IzOJMb6P0sJhTsCQx+rFUFR6oPM+B4YRZV0Ncy1S0+ee4HFiBLk4fYjm75ewQkQrEKTs8LD4zwoM/1PcJp+Lo0mDg+i; 5:YJa3mVMrRRbeqnspBkiMsTdNcY0DcmnspQMlA5aq80C8ES3oNiXj2m0GA3xmtFgGbS6JYxUs8GA+9rwMLejd0CYzxjrM7gPcMFhzwbHW5+kZHfn6HOJpM84HoVw23jfyL6TEfJMfQVMwCRBw4ip5gg==; 24:qK2k5RTgcmor/vhcc2iD54fTF8zFcGPagE6djdKc5LtekASwxT66PnIIo/5ocav00KgA156Ne+e0ouaEfPAdpJYNVBh/WP2wfZZsJbDSsmc=; 7:TtaYXxq1iOow/BIALXhfHfTi0zDCMSIL8QZ5OB06e7HX/kRQjDYFY4tKE8bKjw7rgwKbvx6727Th7ocKFGCB66eAx9UZOInJxipvtk5d3VNL3V/CJvNOKTFFVMMJpYyeFZR2NXz7NApHwfWJl83Q6U5Q6/9UZIWGSpuYLHct0YkAFJ6f1TTIKV5It+m/1M5X6ReoCV2dDPbaxEvYjOtF9Or+KiySQzjxx/L0zDdkaGxwofK9IVu5xW/IBDPGSQqr x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR16MB0523; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6042046)(6043046); SRVR:CY1PR16MB0523; BCL:0; PCL:0; RULEID:; SRVR:CY1PR16MB0523; x-forefront-prvs: 0035B15214 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(40224003)(199003)(377454003)(189002)(122556002)(5002640100001)(8936002)(106116001)(2501003)(102836003)(19580405001)(3660700001)(2906002)(92566002)(36756003)(586003)(3846002)(107886002)(77096005)(2900100001)(3280700002)(10290500002)(2950100001)(86362001)(101416001)(10400500002)(54356999)(105586002)(189998001)(99286002)(106356001)(97736004)(561944003)(5001770100001)(4001350100001)(6116002)(76176999)(19580395003)(87936001)(66066001)(50986999)(7736002)(80792005)(7846002)(305945005)(83506001)(31430400001)(81166006)(68736007)(8676002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR16MB0523; H:CY1PR16MB0522.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <101EFC3E78F7884288B60660383D3C55@namprd16.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2016 18:52:42.5983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR16MB0523 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsXCFfVDSreRf1O4wc61+hZtbbNYLNY+vsji wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGWs2p1RcF+i4v/Od2wNjHNFuhg5OSQETCT+ rb3NDmGLSVy4t56ti5GLQ0jgJaPEz0cfoZxrjBLTTv5ihel40z2BES7RdWA1lHOEUeLYkgOs EM4LRomtX1czgzgsAp3MEu92/IPKTGWSaNu0Bco5wSix73AD2GQ2AR2JTZNeMoLYIgJ+Et2X HzGD2MICRhKtU6axQMSNJfY9vMoEYetJnHi4CsxmEVCV6N/6AqyXV8BUYuP3U2A/CQnYSPxq 6GEDsTkFbCUefNgIVsMI9Ov3U2vAepkFxCVuPZnPBPGdgMSSPeeZIWxRiZeP/4HdJgq0696j uSwQvdESyz5MgqrRkTh7/QkjhC0vsbVvEwuE7StxfNJCcMBICDSxS3y4ewEayG4Sr9ueQxVl Szz9u5d1AqPxLCR3QNg6Egt2f2KDsD0k7n29AmVrSyxb+Jp5FtifghInZz5hWcDIuopRpqS0 2LA4tyS/tKQgtcLASK+4MjcRmF6S9ZLzczcxAlPMDa7Dn3YwztzreIhRgINRiYd3EfumcCHW xDKgykOMEhzMSiK8r3mBQrwpiZVVqUX58UWlOanFhxilOViUxHnnu5WECwmkJ5akZqemFqQW wWSZODilGhjjdu21XjPvdKeuqYHJQq/P3fvYkqfv7ym+ciGAo8fr7aKkhW15U6V2zlFOdqkX 35PYs2jVpC1tol9cHCrMJ9/5k/c0b5/HOqv0GtMZp+/fzXtd+/D/f4/lDV1fp9+fwnS1+nsb y8KZa3t6Jz5g2dKaoPzSddnhG3zOAd+MpzBfqNMMl58dZv5QiaU4I9FQi7moOBEAsMFGnC0D AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXCFeXNqNvIvync4MkyaYu2tlksFmsfX2Rx YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJW7c4ouC9R8X/nO7YGxrkiXYycHBICJhJv uicwdjFycQgJXGOUmHbyFytMYuWki6xwia4Dq6GqjjBKHFtyACrzglFi69fVzCAOi0Ans8S7 Hf+gMlOZJNo2bYFyTjBK7DvcADaZTUBHYtOkl4wgtoiAn0T35UfMILawgJFE65RpLBBxY4l9 D68yQdh6EicergKzWQRUJfq3vgDr5RUwldj4/RQ7iC0kYCPxq6GHDcTmFLCVePBhI1gNo4CY xPdTa8B6mQXEJW49mc8E8Z2AxJI955khbFGJl4//gd0mCrTr3qO5LBC90RLLPkyCqtGROHv9 CSOELS+xtW8TC4TtK3F80kJwwEgINLFLfLh7gR0i4Sbxuu05VFG2xNO/e6HBai3RfPkyE0TD KUaJ3gVrWCYwGsxCciCErSOxYPcnNgjbQ+Le1ytQtrbEsoWvmWeBA0BQ4uTMJywLGFlXMSok FicV55bkl5YkFqQaGOkVV+Ymg4hEYJpJ1kvOz93ECE41P6R2MD6543OIUYCDUYmHdxf3pnAh 1sQyoMpDjBIczEoivK95gUK8KYmVValF+fFFpTmpxYcYpTlYlMR519nODBcSSE8sSc1OTS1I LYLJMnFwSjUwLtZ6Zywma8C9YNJtqRCjhceXzdRb/Nfh9kNehbT23Lp1BQp/k8XTT4bXt579 t3BKXKhUwy8pnbpVn39p/H0wI9Nu14KP/VeUGadZnP474fTOD0bPfI91uDV8lVCc+djY6Pwn mf57VU0u/f+kIniMAv/xHMwuWu7om1m3+OLCHqmXL8ULVkxfrcRSnJFoqMVcVJwIAFbEjtQx AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsXCFeXNqtvIvyncYOUrRou2tlksFmsfX2Rx YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJW7c4ouC9R8X/nO7YGxrkiXYycHBICJhIr J11k7WLk4hASuMYo0XVgNSOEc4RR4tiSA1CZF4wSW7+uZgZxWAQ6mSXe7fgHlZnKJNG2aQuU c4JRYt/hBlaQyWwCOhKbJr1kBLFFBPwkui8/YgaxhQWMJFqnTGOBiBtL7Ht4lQnC1pM48XAV mM0ioCrRv/UFWC+vgKnExu+n2EFsIQEbiV8NPWwgNqeArcSDDxvBahgFxCS+n1oD1sssIC5x 68l8JojvBCSW7DnPDGGLSrx8/A/sNlGgXfcezWWB6I2WWPZhElSNjsTZ608YIWx5ia19m1gg bF+J45MWggNGQqCJXeLD3QvsEAk3iddtz6GKsiWe/t3LCmFbSzRfvswE0XCKUaJ3wRqgIg4g R0Zi5ck8iPh3VomLUy+xTmDUnYXkcAhbR2LB7k9sELaHxL2vV6BsbYllC18zzwIHjKDEyZlP WBYwsq5iVEgsTirOLcktSUwsyDQw0iuuzE0GEYnAJJOsl5yfu4kRnGh+i+9gPPfH5xCjAAej Eg/vCYZN4UKsiWVAlYcYJTiYlUR4X/MChXhTEiurUovy44tKc1KLDzFKc7AoifOGnl0SLiSQ nliSmp2aWpBaBJNl4uCUamCMaRI+en6mjQ1nYeNt68DLrxf25j+4W7JC8KRb8/xrrnJCpS72 r+5P33hAgtmnXtz6uO+WJLH+zfbXU8yevot6tqZqdYyU9fuTAjsuvJc3ePjt5t84bvEQptuf TRYfWaiTyrDQcP75WZ88PW5FXbw4KTU26qiQoWJGvuzSrOx9jF3JOj48bf5KLMUZiYZazEXF iQDUjkg2MAMAAA== Archived-At: Subject: Re: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 15 Aug 2016 18:52:52 -0000 Melinda, We have provided feedback on redaction earlier on this forum and also on some other public forums. We've heard loud and clear from customers in many product segments that they need redaction for publicly-trusted certificates because they value privacy. We don't think redaction as currently specified in RFC 6962-BIS makes much sense; it's too complicated and doesn't protect the privacy of domain owners. If un-redaction is possible by just throwing some cycles at it, then nothing has really been redacted. =20 To summarize the position we've already stated: we feel that the issuing CA must be approached by the domain owner to achieve disclosure of the full contents of a redacted pre-certificate. Policies and procedures should be crafted to standardize that, but they shouldn't be tied to a discussion on redaction because they are needed even when a pre-certificate is not redacted. =20 A redacted pre-certificate contains 95% of the information in the certificate, and fully demonstrates CA compliance to policies and requirements. A redacted pre-certificate contains 100% of the information needed for a harmed party to take recourse (issuer, serial number, notBefore, owned domains in the redacted CN and DNS SANs). The recourse for a redacted pre-certificate is exactly the same as the recourse for an un-redacted pre-certificate: approach the CA, within the terms of its Relying Party Agreement, CP, and/or CPS and state a claim that a certificate has been issued in error and it encroaches on the rights and property of the complainant. The only action that can be taken by the issuer is to revoke the certificate. Whether a browser can or cannot consume certificate status information in a timely manner is out of the scope of this RFC. =20 We favor the full redaction as originally proposed in earlier versions of 6962-bis. Redaction blocks FQDN components that provide intelligence about internal networks that was designed to be parsed and understood only by employees and peer-to-peer systems privy to internal DNS. Redaction blocks geographical data embedded in FQDNs; it blocks harvesting of high value targets prior to attack. Some of our largest customers have had structured naming conventions for many years; forcing them to use wildcards or redesign their DNS hierarchy to preserve privacy in an eTLD+2 policy world requires massive network renaming far beyond the staffing levels of current day IT organizations. The type of very large organization that has a long and vastly deployed legacy of intelligent naming and needs redaction also has strict IT policies that require certificates to be signed by public audited CAs. =20 If redaction is completely removed from 6962-bis, we believe that it should be moved to another RFC so that work can proceed. - Sanjay On 8/12/16, 5:17 PM, "Melinda Shore" wrote: >Hi, all: > >Since there was no comment at all on the proposal to retain >name redaction, we appear to have complete agreement that >it should go. We'll go back into wglc when a new version >is submitted. > >Melinda > From nobody Mon Aug 15 12:45:02 2016 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 19BB012D575 for ; Mon, 15 Aug 2016 12:45:01 -0700 (PDT) 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 (1024-bit key) header.d=pobox.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 bQSYikFxTqvF for ; Mon, 15 Aug 2016 12:44:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D28412D647 for ; Mon, 15 Aug 2016 12:44:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B38BB34D29 for ; Mon, 15 Aug 2016 15:44:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=GBS/1lz6hmDZhygtDLzlh+JTOL0=; b=ybywqc HP+cdeHte6UTx+4tbD3TABl2cdWztcanwsJa1ILYspiLWnzJSd+qGI6xdeBEyyW2 IQpZq5RAwXhk4gbYj+kSV9PHxEZKufaRrYp+sD1H9OVPfnAROjWJGtGbOhj1EADy C2G9DbEtyCY0BTDTW6dSGUR01t3DahOStvC50= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AA19634D28 for ; Mon, 15 Aug 2016 15:44:55 -0400 (EDT) Received: from mail-qk0-f181.google.com (unknown [209.85.220.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 5D40034D27 for ; Mon, 15 Aug 2016 15:44:55 -0400 (EDT) Received: by mail-qk0-f181.google.com with SMTP id f123so51938433qkd.1 for ; Mon, 15 Aug 2016 12:44:55 -0700 (PDT) X-Gm-Message-State: AEkoouuEEgf7YBr/2/954U27a0kRZ2p/CIy3UwX1fxs7iuJ3i++KSlzHiutOIDtRZRmROd2fFEVmIzclMNrHBw== X-Received: by 10.233.237.75 with SMTP id c72mr33870376qkg.170.1471290294807; Mon, 15 Aug 2016 12:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.187 with HTTP; Mon, 15 Aug 2016 12:44:14 -0700 (PDT) In-Reply-To: References: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> From: Eric Mill Date: Mon, 15 Aug 2016 15:44:14 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sanjay Modi Content-Type: multipart/alternative; boundary=94eb2c0c1272623a1e053a217725 X-Pobox-Relay-ID: BDAFDECA-6320-11E6-8482-89D312518317-82875391!pb-smtp1.pobox.com Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 15 Aug 2016 19:45:01 -0000 --94eb2c0c1272623a1e053a217725 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 15, 2016 at 2:52 PM, Sanjay Modi wrote: > > A redacted pre-certificate contains 95% of the information in the > certificate, and fully demonstrates CA compliance to policies and > requirements. A redacted > pre-certificate contains 100% of the information needed for a harmed party > to take recourse (issuer, serial number, notBefore, owned domains in the > redacted > CN and DNS SANs). The recourse for a redacted pre-certificate is exactly > the > same as the recourse for an un-redacted pre-certificate: approach the CA, > within the > terms of its Relying Party Agreement, CP, and/or CPS and state a claim > that a > certificate has been issued in error and it encroaches on the rights and > property of > the complainant. The only action that can be taken by the issuer is to > revoke > the certificate. Whether a browser can or cannot consume certificate status > information in a timely manner is out of the scope of this RFC. > If whether browsers can consume certificate status information in a timely manner is out of the scope of this RFC, I would think that whether "approach the CA" is sufficient recourse for a misissued redacted pre-certificate would also be out of scope for this RFC. > > We favor the full redaction as originally proposed in earlier versions of > 6962-bis. Redaction blocks FQDN components that provide intelligence about > internal networks that was designed to be parsed and understood only by > employees and peer-to-peer systems privy to internal DNS. Redaction blocks > geographical data embedded in FQDNs; it blocks harvesting of high value > targets prior to attack. Some of our largest customers have had structured > naming conventions for many years; forcing them to use wildcards or > redesign their DNS hierarchy to preserve privacy in an eTLD+2 policy world > requires > massive network renaming far beyond the staffing levels of current day IT > organizations. > Two inconsistencies here: * "network renaming", massive or not, would only be required for redesigning their DNS hierarchy for eTLD+2, and would not be required for use of wildcards. * If redaction is for your "largest customers", enterprises that large should be far more likely to have the resources to rename their internal network names. -- Eric > > > > - Sanjay > > On 8/12/16, 5:17 PM, "Melinda Shore" wrote: > > >Hi, all: > > > >Since there was no comment at all on the proposal to retain > >name redaction, we appear to have complete agreement that > >it should go. We'll go back into wglc when a new version > >is submitted. > > > >Melinda > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- konklone.com | @konklone --94eb2c0c1272623a1e053a217725 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 15, 2016 at 2:52 PM, Sanjay Modi <Sanjay_Modi@syman= tec.com> wrote:

A redacted pre-certificate contains 95% of the information in the
certificate, and=C2=A0fully demonstrates CA compliance to policies and requ= irements. A redacted
pre-certificate contains 100% of the information needed for a harmed party<= br> to take=C2=A0recourse (issuer, serial number, notBefore, owned domains in t= he redacted
CN=C2=A0and DNS SANs). The recourse for a redacted pre-certificate is exact= ly the
same as the=C2=A0recourse for an un-redacted pre-certificate: approach the = CA, within the
terms of its=C2=A0Relying Party Agreement, CP, and/or CPS and state a claim= that a
certificate=C2=A0has been issued in error and it encroaches on the rights a= nd property of
the=C2=A0complainant. The only action that can be taken by the issuer is to= revoke
the certificate. Whether a browser can or cannot consume certificate status=
information in a timely manner is out of the scope of this RFC.

If whether browsers can consume certificate status= information in a timely manner is out of the scope of this RFC, I would th= ink that whether "approach the CA" is sufficient recourse for a m= isissued redacted pre-certificate would also be out of scope for this RFC.<= /div>
=C2=A0

We favor the full redaction as originally proposed in earlier versions of 6962-bis. Redaction blocks FQDN components that provide intelligence about<= br> internal networks that was designed to be parsed and understood only by
employees and peer-to-peer systems privy to internal DNS. Redaction blocks<= br> geographical data embedded in FQDNs; it blocks harvesting of high value
targets prior to attack. Some of our largest customers have had structured<= br> naming conventions for many years; forcing them to use wildcards or
redesign=C2=A0their DNS hierarchy to preserve privacy in an eTLD+2 policy w= orld requires
massive network renaming far beyond the staffing levels of current day IT organizations.=C2=A0

Two inconsistencie= s here:=C2=A0

* "network renaming", mass= ive or not, would only be required for redesigning their DNS hierarchy for = eTLD+2, and would not be required for use of wildcards.

* If redaction is for your "largest customers", enterprises= that large should be far more likely to have the resources to rename their= internal network names.

-- Eric
=C2=A0<= /div>



- Sanjay

On 8/12/16, 5:17 PM, "Melinda Shore" <melinda.shore@gmail.com> wrote:

>Hi, all:
>
>Since there was no comment at all on the proposal to retain
>name redaction, we appear to have complete agreement that
>it should go.=C2=A0 We'll go back into wglc when a new version
>is submitted.
>
>Melinda
>

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



--
=
--94eb2c0c1272623a1e053a217725-- From nobody Mon Aug 15 16:25:38 2016 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 1C4A712D79D for ; Mon, 15 Aug 2016 16:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_SOFTFAIL=0.665] 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 D4J9YcjBYO1M for ; Mon, 15 Aug 2016 16:25:34 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id C6AEC12D791 for ; Mon, 15 Aug 2016 16:25:33 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-4593-39aa-9968-9a8b.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:4593:39aa:9968:9a8b]) by mail.hezmatt.org (Postfix) with ESMTPSA id 36C3B9A5D4 for ; Mon, 15 Aug 2016 23:25:31 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 3B4D59FDC6; Tue, 16 Aug 2016 09:25:28 +1000 (AEST) Date: Tue, 16 Aug 2016 09:25:28 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20160815232528.GU23395@hezmatt.org> References: <82181984-43ef-ce41-849f-54946fb867da@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Name redaction consensus call X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 15 Aug 2016 23:25:37 -0000 On Mon, Aug 15, 2016 at 06:52:42PM +0000, Sanjay Modi wrote: > If redaction is completely removed from 6962-bis, we believe that it should > be moved to another RFC so that work can proceed. Sounds an awful lot like you're volunteering to co-author a separate redaction RFC. - Matt From nobody Wed Aug 17 07:38:06 2016 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 21B8112DE4F for ; Wed, 17 Aug 2016 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 MkPZBSk974d9 for ; Wed, 17 Aug 2016 07:38:04 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 1BD3312DE56 for ; Wed, 17 Aug 2016 07:38:01 -0700 (PDT) Received: from localhost ([::1]:51621 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba1yi-0005XL-HP; Wed, 17 Aug 2016 07:38:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Wed, 17 Aug 2016 14:38:00 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:1 Message-ID: <072.0651beda33ae8e2e6d4b1e57cbd95ac2@tools.ietf.org> References: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160817143801.1BD3312DE56@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 07:38:01 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #158 (rfc6962-bis): Hash algorithm agility is hard to implement, as specified X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:38:05 -0000 #158: Hash algorithm agility is hard to implement, as specified Comment (by eranm@google.com): Andrew Ayer on the idea of forcing a fixed HASH_SIZE: "a 32 byte long hash can provide collision resistance of 128 bits (i.e. 2^128 operations required to find a collision). However, with quantum attacks it's only ~85 bits, so fixing HASH_SIZE at 32 bytes would be short-sighted." So I'll go with a variable-length vector for hashes. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Aug 17 07:38:21 2016 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 70C8212DE5E for ; Wed, 17 Aug 2016 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=unavailable 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 S2r2aXqNRBLV for ; Wed, 17 Aug 2016 07:38:19 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 E910C12DE5C for ; Wed, 17 Aug 2016 07:38:17 -0700 (PDT) Received: from localhost ([::1]:51629 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba1yz-0006JZ-Nn; Wed, 17 Aug 2016 07:38:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Wed, 17 Aug 2016 14:38:17 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:2 Message-ID: <072.3b703c0f2233153be17459364075c6eb@tools.ietf.org> References: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160817143817.E910C12DE5C@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 07:38:17 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #158 (rfc6962-bis): Hash algorithm agility is hard to implement, as specified X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:38:20 -0000 #158: Hash algorithm agility is hard to implement, as specified Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/189 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Aug 17 09:18:34 2016 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 B1D1512DEA9 for ; Wed, 17 Aug 2016 09:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=unavailable 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 qFTzmFQrn7OY for ; Wed, 17 Aug 2016 09:18:30 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 DFEFE12DE9F for ; Wed, 17 Aug 2016 09:18:30 -0700 (PDT) Received: from localhost ([::1]:53256 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba3Xy-00027s-Dk; Wed, 17 Aug 2016 09:18:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Wed, 17 Aug 2016 16:18:30 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:3 Message-ID: <072.69fe31b75125c3a3453317eabddf4b97@tools.ietf.org> References: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160817161830.DFEFE12DE9F@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 09:18:30 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #158 (rfc6962-bis): Hash algorithm agility is hard to implement, as specified X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 16:18:33 -0000 #158: Hash algorithm agility is hard to implement, as specified Changes (by eranm@google.com): * milestone: => review Comment: Fixed in https://github.com/google/certificate-transparency- rfcs/commit/9cbeb0a6715f85f0fb1282be4804642a39ecfd47 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Aug 17 09:54:57 2016 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 B24A912DA08 for ; Wed, 17 Aug 2016 09:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=unavailable 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 LJ2nqCK8pNmU for ; Wed, 17 Aug 2016 09:54:54 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 4FC9F12D9F6 for ; Wed, 17 Aug 2016 09:54:54 -0700 (PDT) Received: from localhost ([::1]:53803 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ba479-0005jK-RJ; Wed, 17 Aug 2016 09:54:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 17 Aug 2016 16:54:51 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:4 Message-ID: <072.e17e7d187b2f7cc35b3652e846c37af9@tools.ietf.org> References: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-Trac-Ticket-ID: 158 In-Reply-To: <057.951f28c38e456c42d09f67da4d943429@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160817165454.4FC9F12D9F6@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 09:54:54 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #158 (rfc6962-bis): Hash algorithm agility is hard to implement, as specified X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 16:54:56 -0000 #158: Hash algorithm agility is hard to implement, as specified Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Aug 18 12:24:20 2016 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 7E71112DA3F for ; Thu, 18 Aug 2016 12:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 bKcZ7HgKIG0z for ; Thu, 18 Aug 2016 12:24:16 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B84912D9E0 for ; Thu, 18 Aug 2016 12:24:10 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 18 Aug 2016 15:27:28 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.465.0; Thu, 18 Aug 2016 15:24:08 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u7IJO1ub004813 for ; Thu, 18 Aug 2016 15:24:02 -0400 References: <1ef7fcce-0689-284f-8c7f-8e9bb1d4a9a5@nist.gov> From: "David A. Cooper" To: "trans@ietf.org" X-Forwarded-Message-Id: <1ef7fcce-0689-284f-8c7f-8e9bb1d4a9a5@nist.gov> Message-ID: Date: Thu, 18 Aug 2016 15:24:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1ef7fcce-0689-284f-8c7f-8e9bb1d4a9a5@nist.gov> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: [Trans] draft-ietf-trans-threat-analysis and DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 18 Aug 2016 19:24:19 -0000 Section 3.4 of draft-ietf-trans-threat-analysis is supposed to describe the attack presented by DKG in https://www.ietf.org/mail-archive/web/trans/current/msg01984.html. However, the text that is currently in the document does not accurately describe the attack, contains technical errors, and is difficult to read.

So, I have written some text that I propose should replace the text that is currently in Section 3.4 of draft-ietf-trans-threat-analysis. This text would replace all of Sections 3.4, 3.4.1, and 3.4.2.

Please review this text and comment if you agree that it better describes the attack in https://www.ietf.org/mail-archive/web/trans/current/msg01984.html than the text that is currently in the document does.

Thanks,

David


3.4.  Multiple Certificate Chains

Section 3.2 examined attacks in which a malicious CA issued a bogus certificate and either tried to prevent the Subject from detecting the bogus certificate (Sections 3.2.1.2, 3.2.1.3, and 3.2.2) or continued to present the bogus certificate, to at least some relying parties, as "good" even if the Subject requested revocation (Section 3.2.1.1.1).  These attacks are limited in that if the bogus certificate is not submitted to a log, then it may not be accepted by CT-aware browsers, and submitting the bogus certificate to a log increases the chances that the CA's malicious behavior will be detected.

In general, if a CA is discovered to be acting maliciously, its certificates will no longer be accepted, either because its parent will revoke its CA certificate, its CA certificate will be added to browsers' blacklists, or both.  However, a malicious CA may be able to obtain SCTs for the bogus certificates that it issues and continue to have those certificates accepted by relying parties even after its malicious behavior has been detected by creating more than one chain for the certificates, as shown in Figure 2.

       +-----------------+    +-----------------+
       |       CA A      |    |      CA B       |
       +-----------------+    +-----------------+
                      \          /
                       \        /
       CA certificate 1 \      / CA certificate 2
                         \    /
                    +----------------+
                    |  malicious CA  |
                    +----------------+
                            |
                            | bogus EE certificate
                            |
                   +------------------+
                   | targeted Subject |
                   +------------------+

   Figure 2: Multiple Certificate Chains for a Bogus Certificate

In Figure 2, the malicious CA has been issued CA certificates by two different parent CAs.  The parent CAs may be two different trust anchors, or one or both of them may be an intermediate CA that is subordinate to a trust anchor.  If both parent CAs are intermediate CAs, they may be subordinate to the same trust anchor or to different trust anchors.  The malicious CA may have obtained certificates from the two parents by applying to them for the certificates, or by compromising the parent CAs and creating the certificates without the CAs' knowledge.

By having two chains the malicious CA could provide the chain that includes CA A when submitting certificates to logs, but then provide the chain that includes CA B to targeted browsers.  If the CA's malicious behavior is detected, then CA A and browser vendors may be alerted and revoke/blacklist CA certificate 1.  However, since CA certificate 2 does not appear in any logs, those who detected the malicious behavior may not discover the second chain and so may not alert CA B or browser vendors of the need to revoke/blacklist CA certificate 2.  In this case, targeted browsers would continue to accept the bogus certificates issued by the malicious CA, since the certificate chain they are provided is remains valid.

[Editor's note: A number of possible countermeasures have been discussed, but it is not clear whether they should be discussed here or in Section 5.  Examples that browsers could implement include: requiring that all intermediate certificates be logged; blacklisting all certificates issued by a malicious CA (not just the CA certificate issued to the malicious CA); and blacklisting the malicious CA's public key rather than just a particular certificate containing that public key.  In order for the blacklisting of the EE certificates to help, logs would need to check the status of intermediate certificates in chains submitted to them prior to issuing an SCT.]

From nobody Thu Aug 18 12:52:19 2016 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 CB50D12B009 for ; Thu, 18 Aug 2016 12:52:16 -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, FREEMAIL_FROM=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=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 6EyPF4rGUbzL for ; Thu, 18 Aug 2016 12:52:10 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 1F6F812B04F for ; Thu, 18 Aug 2016 12:52:06 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id h186so1251829pfg.3 for ; Thu, 18 Aug 2016 12:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=mpOjzzRksK16xcE5OaLbeVfGV1pMyYBDrOHg/wGeIBw=; b=nmILlRHeRcOjrJLpwb+JsLsLnAJzvQ5J9OIx+IKqqn7GKZsEGGC/1XHZSwKTmX9OOZ 4R9PoHCmgqYehyF0UpyufRto0tFAlgP4GijAFOYDN6W3OVAfeutEhtq9a7HNTVpymDrt uqrtKVJ6WVF7zGCREdu6OYjUEgzYaUvS6LrMlwh+4h01LY+V1WWe+vTrZs7CspJ4dpbJ eEllCWJW7RVyNPUzmGpHZ+ZfWbTJgXZWehSp4UhyCAyS0b0IA5tDmjl4sGiwafw9QkxX 37U2UZ9EdsNxQBhWVTNS12KNhvWvBmkyvAON7UYsgy/dFjjR/MvKiKObaEwzahUiysIZ PiYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=mpOjzzRksK16xcE5OaLbeVfGV1pMyYBDrOHg/wGeIBw=; b=D4us6TwNJDfY85uWC1dj0rDOIa9VKUr+i2/Aqx4/Sc4Q2uDKhe6mmJKDjvk/iOScGW Ryd4tMHVZb+3dbYJu0gGWFAt62Hi8VSO/eZlIc7fe7Z3N+fgBZqgZHs7ZDRR5bF8UjD0 oLy/V9MNgJ4MCFwSQgKoSW8YaZ467Fu9lv+7Ijufdz8QfuATXQSd0tTKlUz6iSWyjaU0 ew5NEmQ/8FZIP6cYlXvEmAaGLciXYQPgXXhkQn2nJ+1NH/Ps+/zGBbU4c35J6NSHsr88 FN9VxsYh4rfWVPUZ8PdYC6MtUBlR4m5Squt3fQ8ryXLIdP2nPPMS+OocGLGMAwQirfwT xX6w== X-Gm-Message-State: AEkooutZiul9i59pD2SeL9AWA4jK+tILPMHDolZc7re9IhrexWwfFkaIgp2XqBqlbIZ00w== X-Received: by 10.98.62.144 with SMTP id y16mr7134364pfj.9.1471549925315; Thu, 18 Aug 2016 12:52:05 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-51-155-radius.dynamic.acsalaska.net. [216.67.51.155]) by smtp.googlemail.com with ESMTPSA id r21sm725637pfi.52.2016.08.18.12.52.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 12:52:04 -0700 (PDT) To: trans@ietf.org References: <1ef7fcce-0689-284f-8c7f-8e9bb1d4a9a5@nist.gov> From: Melinda Shore Message-ID: <8d3be19d-7a94-d5ed-9851-f0b29be4178d@gmail.com> Date: Thu, 18 Aug 2016 11:52:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UA15DdPhwG92uoAkvNkUWtH2ApX1DuWAm" Archived-At: Subject: Re: [Trans] draft-ietf-trans-threat-analysis and DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 18 Aug 2016 19:52:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UA15DdPhwG92uoAkvNkUWtH2ApX1DuWAm Content-Type: multipart/mixed; boundary="0NB5pesIR1oKxA50oAssRGn4ipFAKs3HT" From: Melinda Shore To: trans@ietf.org Message-ID: <8d3be19d-7a94-d5ed-9851-f0b29be4178d@gmail.com> Subject: Re: [Trans] draft-ietf-trans-threat-analysis and DKG's conspiring CAs attack References: <1ef7fcce-0689-284f-8c7f-8e9bb1d4a9a5@nist.gov> In-Reply-To: --0NB5pesIR1oKxA50oAssRGn4ipFAKs3HT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Please give this a serious, thoughtful review. We'd like to get this document wrapped up and cannot do that until we've got general agreement on the attack description. Melinda On 8/18/16 11:24 AM, David A. Cooper wrote: > Section 3.4 of draft-ietf-trans-threat-analysis is supposed to describe= > the attack presented by DKG in > https://www.ietf.org/mail-archive/web/trans/current/msg01984.html. > However, the text that is currently in the document does not accurately= > describe the attack, contains technical errors, and is difficult to rea= d. >=20 > So, I have written some text that I propose should replace the text tha= t > is currently in Section 3.4 of draft-ietf-trans-threat-analysis. This > text would replace all of Sections 3.4, 3.4.1, and 3.4.2. >=20 > Please review this text and comment if you agree that it better > describes the attack in > https://www.ietf.org/mail-archive/web/trans/current/msg01984.html than > the text that is currently in the document does. >=20 > Thanks, >=20 > David >=20 > -----------------------------------------------------------------------= - >=20 > 3.4. Multiple Certificate Chains >=20 > Section 3.2 examined attacks in which a malicious CA issued a bogus > certificate and either tried to prevent the Subject from detecting the > bogus certificate (Sections 3.2.1.2, 3.2.1.3, and 3.2.2) or continued t= o > present the bogus certificate, to at least some relying parties, as > "good" even if the Subject requested revocation (Section 3.2.1.1.1).=20 > These attacks are limited in that if the bogus certificate is not > submitted to a log, then it may not be accepted by CT-aware browsers, > and submitting the bogus certificate to a log increases the chances tha= t > the CA's malicious behavior will be detected. >=20 > In general, if a CA is discovered to be acting maliciously, its > certificates will no longer be accepted, either because its parent will= > revoke its CA certificate, its CA certificate will be added to browsers= ' > blacklists, or both. However, a malicious CA may be able to obtain SCT= s > for the bogus certificates that it issues and continue to have those > certificates accepted by relying parties even after its malicious > behavior has been detected by creating more than one chain for the > certificates, as shown in Figure 2. >=20 > +-----------------+ +-----------------+ > | CA A | | CA B | > +-----------------+ +-----------------+ > \ / > \ / > CA certificate 1 \ / CA certificate 2 > \ / > +----------------+ > | malicious CA | > +----------------+ > | > | bogus EE certificate > | > +------------------+ > | targeted Subject | > +------------------+ >=20 > Figure 2: Multiple Certificate Chains for a Bogus Certificate >=20 > In Figure 2, the malicious CA has been issued CA certificates by two > different parent CAs. The parent CAs may be two different trust > anchors, or one or both of them may be an intermediate CA that is > subordinate to a trust anchor. If both parent CAs are intermediate CAs= , > they may be subordinate to the same trust anchor or to different trust > anchors. The malicious CA may have obtained certificates from the two > parents by applying to them for the certificates, or by compromising th= e > parent CAs and creating the certificates without the CAs' knowledge. >=20 > By having two chains the malicious CA could provide the chain that > includes CA A when submitting certificates to logs, but then provide th= e > chain that includes CA B to targeted browsers. If the CA's malicious > behavior is detected, then CA A and browser vendors may be alerted and > revoke/blacklist CA certificate 1. However, since CA certificate 2 doe= s > not appear in any logs, those who detected the malicious behavior may > not discover the second chain and so may not alert CA B or browser > vendors of the need to revoke/blacklist CA certificate 2. In this case= , > targeted browsers would continue to accept the bogus certificates issue= d > by the malicious CA, since the certificate chain they are provided is > remains valid. >=20 > [Editor's note: A number of possible countermeasures have been > discussed, but it is not clear whether they should be discussed here or= > in Section 5. Examples that browsers could implement include: requirin= g > that all intermediate certificates be logged; blacklisting all > certificates issued by a malicious CA (not just the CA certificate > issued to the malicious CA); and blacklisting the malicious CA's public= > key rather than just a particular certificate containing that public > key. In order for the blacklisting of the EE certificates to help, log= s > would need to check the status of intermediate certificates in chains > submitted to them prior to issuing an SCT.] >=20 >=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 --0NB5pesIR1oKxA50oAssRGn4ipFAKs3HT-- --UA15DdPhwG92uoAkvNkUWtH2ApX1DuWAm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXthHiAAoJELiGRpM6HoEu+ukP/0z9VJ+HRO//mrS885h47smy io3g3NItg4CCNB5jjtCTdiQN4dCxySA2/14U3ke6Z4b6/SNo/FdQREbAdIl5mODy /U2u4+KnugiL4WsyCMYPqvfa+YO75vLOxiuMWSSKwHBEp5I9HcHC1GUomMg2mxja LxEVe/jDNSes+lQWwooEiwHvBxRfUNGLTKBKK1G9bpeUihXoK0+aWGCZ2oQ1fzqm CCrRgZZV0zrp4v2guWi5DQ2R9f7bVkzpmaDJUDR4D7fHHdJKMNvn9HN8qCCmsO68 dUROv2TxscVFNgwhnmM+mm/9lOs8hxmNzzaer9jqmpVupVfNHbDb1njhWyeDZSdI y3kZ0mZJPZFHqGwvnO6BpIRD1QxvDviNlM1GTTTyZVNEgyKLpgQ07wwRaW/+I4qg bKW+RKKo7nhWbgoGcaUDsH7n4lAyBLsPLBlNHlSE63KbnLK1Pq7Po0uaqi+36lp4 3WjC0dWUwvKvFADac+JkcgSSXqj+KWijmTAnF3rOkJX7rmu6Z+WSomjLgUH7MH6J exye2iLwVTBIaM789y9sSWdaag+0p9VjTJmcMfnPve92Of5Q5qup3IUvMjSUD69I 90LnD8Jk4R+SCFFUr5CqG+WxSdB6biHQwgdw1/YKqGZLCzlPdoMJp9dhZMrHOLTT Ismu4cKYYaFcv0CzY23v =za1u -----END PGP SIGNATURE----- --UA15DdPhwG92uoAkvNkUWtH2ApX1DuWAm-- From nobody Tue Aug 23 08:42:52 2016 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 3147112D0E6 for ; Tue, 23 Aug 2016 08:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 9Lz6-JHx4Gx1 for ; Tue, 23 Aug 2016 08:42:48 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 34FAD12D5E3 for ; Tue, 23 Aug 2016 08:41:22 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BA80B433413; Tue, 23 Aug 2016 15:41:21 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A420C4F02D; Tue, 23 Aug 2016 15:41:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471966881; bh=4VpRwgQvSqvzmOW0RTDxbTmUarPeOFk+h8Ow1FqdewI=; l=535; h=From:To:Date:References:In-Reply-To:From; b=sEhdlytIM1K6x2qLKxc7Jn+TNwjWjDlDtmToxQAaXID2xS+Gr8Aux+MfRjTwTy316 CJO6KdLNFf72PBCUrREIsWZXuTL5GItfdq5brjHNkorI7MCnFngXQuWDHR9fYEEkAL ZgwAaJca996oDG/Hy9ML54Txy+SS15BhhuQKuK5U= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A06AF1FC8C; Tue, 23 Aug 2016 15:41:21 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 11:41:21 -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.1178.000; Tue, 23 Aug 2016 11:41:21 -0400 From: "Salz, Rich" To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] draft-ietf-trans-threat-analysis and DKG's conspiring CAs attack Thread-Index: AQHR+Yotx0vxXYn72kS74xVq9dyunKBWtJsQ Date: Tue, 23 Aug 2016 15:41:20 +0000 Message-ID: <554cef3f3d3c4bffb013cb29daa4530c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1ef7fcce-0689-284f-8c7f-8e9bb1d4a9a5@nist.gov> <8d3be19d-7a94-d5ed-9851-f0b29be4178d@gmail.com> In-Reply-To: <8d3be19d-7a94-d5ed-9851-f0b29be4178d@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.23] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] draft-ietf-trans-threat-analysis and DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 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, 23 Aug 2016 15:42:50 -0000 I read the text in the mail message. I find it clear and understandable.=20 I don't find the existing text as clear. I am not sure that they are talki= ng about the same thing. If I had more cycles available, I could convince = myself that they are. But open reading the mail text, my response is "yup, it can't, and that's o= kay ." Which leads me to a propose simpler text. "CT cannot protect against multiple CA's signing the same TBSCertificate[ke= ypair, if you prefer] unless both CA's are logging what they sign." From nobody Wed Aug 31 13:39:47 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A8812D0E6; Wed, 31 Aug 2016 13:39:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147267598191.31911.15051123857190133028.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 13:39:41 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-19.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:39:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-19.txt Pages : 53 Date : 2016-08-31 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-19 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/