From nobody Wed Oct 5 16:47:12 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 70284129424 for ; Wed, 5 Oct 2016 16:47:10 -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 Lp7yHL5etzen for ; Wed, 5 Oct 2016 16:47:09 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8422129442 for ; Wed, 5 Oct 2016 16:47:08 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id cd13so1442288pac.0 for ; Wed, 05 Oct 2016 16:47:08 -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=xHQHdGIZP5uQ762Hb9mytTfRB5Nz9uYyC+WNeNMywE0=; b=asU8C6tdn3ZW4aft9lZXsvI+cNMdbnWdReo07H7omrQDr2D71lpOz3BevmGvB70GPa K/d+Tfw8lAJ6NUgFaaEJW2fBqGZ5BY2/Y2gomr/cGRYb1lGS+PklMtIWH7MnKZ4sydqH o4Kd7Ai+Ee8FrEUBwUb5kEwX6s+AkceEKuw9gAucIcns568csphfO9dkVC+ZkRTM/6DA L1u4WaXMh9y/fAMnmvMKoIUMk3PoWUhV0AW8nsQWarDyWWi5VHN15Mt3vNu5nr5ig+3r pc4GP/paGTpNRW/K1kZW24/jAKBZTG5v/wqJtohEOAtXPmTM9YPwsXUq2onKBHxBeod6 sAkg== 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=xHQHdGIZP5uQ762Hb9mytTfRB5Nz9uYyC+WNeNMywE0=; b=M9Ka+B6LXprTt24V3uK3oXz2Ba1Rnd1zc+0eqVeTJZ8vwwsfQTSUg6QPvsKJ+0bPjg 4yucbhxpOQ+2yhwZS8AU0+xHhTi/ofZ9GlINl7PhF0PGvXutOXLFhUMrlSSJzhUdld2v theSNXO2qpkrVb8xsZ7AlBVrOTH6hA+IorwLTkp+uumSPCFbIBwCBTeminCfLrvLpsxP exCOwfIihS5ZXY1rHw2Yd/C5Uq3RVAjRTkXtJlMcix+vJDQnBf+51JUnma+lDHxks/V/ YF1B/cu1VB7bjH6bDifFzjWGcAmYOgMMLDT8UejuCZkCG8nMLIoNQBInbKGge8dFRp4F WkHw== X-Gm-Message-State: AA6/9Rn4NeZGQtrMzdz687Fri0z4FeO/fjUn8XbBj4g9YfBfXNGB3cl4FEUFdfUzIqn1ng== X-Received: by 10.66.232.106 with SMTP id tn10mr17736598pac.17.1475711228284; Wed, 05 Oct 2016 16:47:08 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (63-140-87-187-radius.dynamic.acsalaska.net. [63.140.87.187]) by smtp.googlemail.com with ESMTPSA id w63sm66249528pfk.43.2016.10.05.16.47.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:47:07 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Wed, 5 Oct 2016 15:46:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="66vNKBcuQcQH5VagVoAXNDWctkQBpPTvj" Archived-At: Subject: [Trans] We need feedback/threat analysis document 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, 05 Oct 2016 23:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --66vNKBcuQcQH5VagVoAXNDWctkQBpPTvj Content-Type: multipart/mixed; boundary="14SSQIBg2IcIh51PC2O0T6kDvnBmA00Pv"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: Subject: We need feedback/threat analysis document --14SSQIBg2IcIh51PC2O0T6kDvnBmA00Pv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: There have been no responses to David Cooper's post regarding the most recent revision of the threat analysis document (https://mailarchive.ietf.org/arch/msg/trans/Y1_-4fnoWrZFJ0uuI12np59a3KY)= =2E We really need to close this out, and that means we need input from working group participants. Many thanks, Melinda --14SSQIBg2IcIh51PC2O0T6kDvnBmA00Pv-- --66vNKBcuQcQH5VagVoAXNDWctkQBpPTvj 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 iQIcBAEBCgAGBQJX9ZDyAAoJELiGRpM6HoEugVYP/iLmRB8O11nWtvcvXKTB/YJN 3wK/EDY7DmcJzwV3Wzn+xX423jd7NLbLK6WytC7g8n9XiouWCiyjx5iqImkxoTxY JQJuoz0iGHA9MLCkKs1T4jDRjAaM150sdZJ2isBgxS27j3shYVlbI7xRfd4Xqd8e SSm3oxKPx09naxGfeJ5ZM2jFT+HJbwfHahJr25mx+y0Fg7POLAMNNamxaNdj1+Fs wza/OMos836McLcngQtrHgde4E5vmwpHc3FTJD05j/wswavMsHueJGJrocq4ChFo It4SGMU+xLIGTaYdC2CepnTG7Pt8u3ob/b5+YkhG2une0KOTYSEJrrKNlEQQPpK8 q7MkG9eBCd3mzryZj1FCJ4p5jgtohaYQGCg2+E0dIV5WTjh8ZxxXlzUAyFNJnKkA W/2pH1KAlfxIMQPF4LE97BIp7+B4AxvFNtP04ycjqTP6QXHpysCBw+O7x3la9WWL iZe13kZqEz24xtTGC5lpIwACwhuDes218tPpIiFs7OPHKQuOQW8vLAo75hy/9kAH Tuuo7evhM79cq1uvojquB20kcDcYRTCCOt7fM0VhYBzqh4/Ux6ELcONpFyZ0FPOC iwK6JFY0d8JmsHUtqnpkdMfUQE4DOr6Gqpj0imLN1lqaTauMb2Yll+X+2oBfYFum pjSFMRRze93LGthYg59V =tSY/ -----END PGP SIGNATURE----- --66vNKBcuQcQH5VagVoAXNDWctkQBpPTvj-- From nobody Thu Oct 6 08:22: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 AA52B1296CD for ; Thu, 6 Oct 2016 08:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 iiOKzqFHb_1k for ; Thu, 6 Oct 2016 08:22:02 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC331296C8 for ; Thu, 6 Oct 2016 08:22:01 -0700 (PDT) Received: (qmail 7795 invoked by uid 1004); 6 Oct 2016 15:21:59 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 06 Oct 2016 16:21:59 +0100 Received: (qmail 15195 invoked by uid 1000); 6 Oct 2016 15:21:59 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 06 Oct 2016 16:21:59 +0100 To: trans@ietf.org References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> <557B1834.8040706@bbn.com> From: Rob Stradling Message-ID: Date: Thu, 6 Oct 2016 16:21:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <557B1834.8040706@bbn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Trans] Log Monitoring API 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, 06 Oct 2016 15:22:05 -0000 Now we've completed WGLC for 6962-bis, I'd like to pick this thread back up again. Several different public CT monitoring services now exist (crt.sh, Cert Spotter, Censys.io, etc). ISTM that it would be useful to define a common API that could be implemented by each monitor, so that end-users don't have to implement multiple APIs in order to talk to multiple monitors. Matt Palmer and I made a start on a (very drafty) draft a while ago: https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palmer-ct-monitor-api.md Who's interested in working on this? On 12/06/15 18:34, Stephen Kent wrote: > Rob, > >> On 11/06/15 22:40, Stephen Kent wrote: >>> Rob, >>> >>>> 6962-bis notes that: >>>> "Those who are concerned about misissue can monitor the logs, asking >>>> them regularly for all new entries, and can thus check whether >>>> domains they are responsible for have had certificates issued that >>>> they did not expect." >>>> >>>> If you act as a monitor yourself, you can be sure that the logs you're >>>> monitoring aren't misbehaving. You don't have to trust the logs. >>> >>> I'm not sure I follow your argument above. >> >> >> Hi Steve. I was aiming for a quick summary rather than a >> fully-specified problem statement. You're correct that the audit role >> is vital too. >> >> If the CT ecosystem is functioning as intended, then a monitor can be >> sure that they've seen every logged cert, without having to trust the >> log. > yes. >> >> But a client of a monitor has to trust the monitor. > agreed. >> >> Is that any clearer? > yes. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Oct 14 12:35: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 4ED3D12969D for ; Fri, 14 Oct 2016 12:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 co2Oe2GaGg8L for ; Fri, 14 Oct 2016 12:34:59 -0700 (PDT) Received: from dfw-mailout2.raytheon.com (dfw-mailout2.raytheon.com [199.46.199.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644671293F2 for ; Fri, 14 Oct 2016 12:34:59 -0700 (PDT) Received: from ca-mailout10.rtnmail.ray.com (ca-mailout10.rtnmail.ray.com [147.25.146.12]) by dfw-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u9EJYwH2002511 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2016 19:34:58 GMT Received: from smtp.bbn.com ([128.33.1.81]) by ca-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id u9EJYunE007189 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Oct 2016 19:34:57 GMT Received: from ssh.bbn.com ([192.1.122.15]:53550 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bv8Fs-000M1D-Az for trans@ietf.org; Fri, 14 Oct 2016 15:34:56 -0400 To: trans@ietf.org References: <1ef7fcce-0689-284f-8c7f-8e9bb1d4a9a5@nist.gov> <320a8e5c-068e-35e8-42ed-7778f9524c79@bbn.com> <8229fc28-52fa-c570-d09b-a3424e15a62c@nist.gov> From: Stephen Kent Message-ID: <71bde9eb-1178-0907-b1af-6c8bf736907a@bbn.com> Date: Fri, 14 Oct 2016 15:34:56 -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: <8229fc28-52fa-c570-d09b-a3424e15a62c@nist.gov> Content-Type: multipart/alternative; boundary="------------A2488EAC0A3EB4D2C292FF95" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-14_09:, , signatures=0 Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-09.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, 14 Oct 2016 19:35:01 -0000 This is a multi-part message in MIME format. --------------A2488EAC0A3EB4D2C292FF95 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit David, I agree with your assessment that the later paragraphs of 3.4 deal with revocation status attacks that are independent from the dual cert chain attack that is the focus of that section. I should not have placed that text in 3.4/ While one could add text about revocation status attacks to the sections you cited (where it is not already present), I think it is useful to put this discussion in one place. I have added section 3.5 and moved the later paragraphs from 3.4 there, along with some minor edits to make it an independent section ("Attacks Related to Distribution of Revocation Status"). I disagree with you interpretation of the final sentence of the third (not fourth) paragraph. It does not imply that the two parent CAs know of each other's cert issuance behavior. It merely states that each parent may have issued a cert to a malicious CA in good faith, despite the name & key collision. We've had the discussion about whether 5280 prohibits duplicate names, and the on-list consensus was that it does not. Version 10 will be posted next week, with the changes noted above. Steve --------------A2488EAC0A3EB4D2C292FF95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

David,

I agree with your assessment that the later paragraphs of 3.4 deal with revocation status attacks that are independent from the dual cert chain attack that is the focus of that section. I should not have placed that text in 3.4/

While one could add text about revocation status attacks to the sections you cited (where it is not already present), I think it is useful to put this discussion in one place. I have added section 3.5 and moved the later paragraphs from 3.4 there, along with some minor edits to make it an independent section ("Attacks Related to Distribution of Revocation Status").

I disagree with you interpretation of the final sentence of the third (not fourth) paragraph. It does not imply that the two parent CAs know of each other's cert issuance behavior. It merely states that each parent may have issued a cert to a malicious CA in good faith, despite the name & key collision. We've had the discussion about whether 5280 prohibits duplicate names, and the on-list consensus was that it does not.

Version 10 will be posted next week, with the changes noted above.

Steve
--------------A2488EAC0A3EB4D2C292FF95-- From nobody Wed Oct 19 10:01: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 C14271294D4 for ; Wed, 19 Oct 2016 10:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.369 X-Spam-Level: X-Spam-Status: No, score=0.369 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.431] 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 wlNEB1UIJaUX for ; Wed, 19 Oct 2016 10:01:02 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE0C12958C for ; Wed, 19 Oct 2016 10:01:02 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 14316A8A1585 for ; Wed, 19 Oct 2016 17:00:59 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id C438C1FE023E; Wed, 19 Oct 2016 19:00:58 +0200 (CEST) Date: Wed, 19 Oct 2016 19:00:58 +0200 From: Kurt Roeckx To: trans@ietf.org Message-ID: <20161019170057.s74mniw7jsxrnvse@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20160916 (1.7.0) Archived-At: Subject: [Trans] Gossip protocol 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, 19 Oct 2016 17:01:05 -0000 Hi, I was reading the latest draft of the gossip protocol and I have some concerns. I've started monitoring the CT logs. I think that under the latest draft I became an "auditor", but the graph also still mentions a monitor. But I don't believe I'm a "trusted auditor". There at least seems to be confusion about the terms. I'm mostly interested in checking that the CT logs behave like they should, and the draft doesn't seem to be covering this, or I'm not understanding it. How can I find all the SCTs and STHs that the log did send to someone but didn't send to me? It seems that as auditor I would only talk to the CT logs and "participating HTTPS servers". It's not clear to me how I would disover those HTTPS servers. Is this related to the "trusted auditor"? Would an auditor work for an HTTPS site? Or would both clients and auditors have a list of those participating HTTPS servers, and those HTTPS servers act like some lightweight auditor? An older draft had a way for monitors to talk to each other, but that all seems to have been removed. Kurt From nobody Wed Oct 19 12:33:55 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 EFD7612967E for ; Wed, 19 Oct 2016 12:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZh3JbUVpolu for ; Wed, 19 Oct 2016 12:33:52 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BCC129662 for ; Wed, 19 Oct 2016 12:33:52 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id 2so41237821vkb.3 for ; Wed, 19 Oct 2016 12:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CGcPJfXOPVQZtFeCbPICe/btL7ZimMEH60Sxzyb1qr0=; b=RMdD3sBq+uoORFWrsfkXIJ2fwCxAzSVzaK5Gdh46M/ScrFxj+1jyGIwQ1xkF65D82r 1J+6cwTtIg+f6y+HzqxpYTVYw5xdwU/GLvoVOiu7z2wlXKLe9mMJcnyBjmVFLSlLvpzv ZfC4ueoXNXQxJjJHUFS89a+prFHgsizuWdK9A= 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=CGcPJfXOPVQZtFeCbPICe/btL7ZimMEH60Sxzyb1qr0=; b=Bvm+d2EDXGVyiQdzoKtF4wdBOao7cojMmrasNfJqcNHdzt1eRkyA2pIc5wPE9rz6gn KY6Omp9Vz+RPNedYkgGSVkBvbfBuAboH8fLSmQfFpl0vRDaPm//gvl7WU+7ak/gtBCav BUVc2C4NcHgPKBTOCy/AEPVrbMxqrcHoqwqVr10gg3mjtwSeG0BaP9APuC+sfiD1o6fy MGt2tyQJIs1qkF89comlLa3ieaHimPaho1BQNvg3Rku7kyaRRu33tQ1bMlgT/15o3jdz 7/vTMlRNbcfPVK82aBvAbOd76EHwnM8FK8LT7T0xmacU20lnrKYqt3YdC1Qs/vBxv2fF zhqg== X-Gm-Message-State: AA6/9RlrX1E+CsdIs+3E+sCDBxd+85cvtoGqj9eRp4ogRavN5IfhnBIB6EH3AhT4jVZnM5GBEDww2dTomOxkL1tH X-Received: by 10.31.99.197 with SMTP id x188mr6914626vkb.125.1476905631457; Wed, 19 Oct 2016 12:33:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.201 with HTTP; Wed, 19 Oct 2016 12:33:30 -0700 (PDT) In-Reply-To: <20161019170057.s74mniw7jsxrnvse@roeckx.be> References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> From: Tom Ritter Date: Wed, 19 Oct 2016 14:33:30 -0500 Message-ID: To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol 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, 19 Oct 2016 19:33:54 -0000 On 19 October 2016 at 12:00, Kurt Roeckx wrote: > Hi, > > I was reading the latest draft of the gossip protocol and I have > some concerns. > > I've started monitoring the CT logs. I think that under the latest > draft I became an "auditor", but the graph also still mentions a > monitor. But I don't believe I'm a "trusted auditor". There at > least seems to be confusion about the terms. You're correct. In our draft we refer to a 'Trusted Auditor' as some third party who gets input from clients and then uses it to facilitate log auditing. Whereas in the CT draft, an Auditor is someone who observes the logs and attempts to detect misbehavior. Technically, our 'Trusted Auditor' does not have to do auditing! It could collect, mix, and then release users' input to an 'Auditor' who actually performs the auditing. Perhaps we should rename our 'Trusted Auditor' to something different. > I'm mostly interested in checking that the CT logs behave like > they should, and the draft doesn't seem to be covering this, or > I'm not understanding it. You're right - this draft doesn't proscribe actions for an 'Auditor', it only attempts to answer the question "How does an auditor get data from HTTPS Clients?" > How can I find all the SCTs and STHs that > the log did send to someone but didn't send to me? > > It seems that as auditor I would only talk to the CT logs and > "participating HTTPS servers". It's not clear to me how I would > disover those HTTPS servers. That's fair, we don't really say I don't think. I expect practically speaking, that web crawling will occur and people will circulate lists of participating HTTPS servers. If an Auditor misses some servers that do STH Pollination, it's not a big deal as that data will be pollinated across HTTPS servers. In contrast, servers who do SCT Feedback will be more likely to announce to auditors "Hey, I enabled this, start polling me." (In both instances, HTTPS servers can also push to an Auditor if they choose.) > Is this related to the "trusted > auditor"? Would an auditor work for an HTTPS site? Or would both > clients and auditors have a list of those participating HTTPS > servers, and those HTTPS servers act like some lightweight > auditor? It's possible for HTTPS Servers to implement some amount of auditor functionality, but we don't expect most to. Actions for an auditor to take is a good thing to try and document somewhere. We _could_ put it into Gossip, but it seems like a separate draft to me. Off the top of my head I think the main things it would be checking are: - Has the log always issued a STH within the MMD - Can I resolve all inputs (SCTs, STHs) into a single STH via inclusion/consistency proofs (to prevent split views) -tom From nobody Wed Oct 19 13:31:23 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 08A7B1293E3 for ; Wed, 19 Oct 2016 13:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 eehj27izQaAR for ; Wed, 19 Oct 2016 13:31:21 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674BA129476 for ; Wed, 19 Oct 2016 13:31:21 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 91D10A8A16DA; Wed, 19 Oct 2016 20:31:19 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 413551FE023E; Wed, 19 Oct 2016 22:31:18 +0200 (CEST) Date: Wed, 19 Oct 2016 22:31:18 +0200 From: Kurt Roeckx To: Tom Ritter Message-ID: <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20160916 (1.7.0) Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol 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, 19 Oct 2016 20:31:23 -0000 On Wed, Oct 19, 2016 at 02:33:30PM -0500, Tom Ritter wrote: > Actions for an auditor to take is a good thing to try and document > somewhere. We _could_ put it into Gossip, but it seems like a separate > draft to me. Off the top of my head I think the main things it would > be checking are: > - Has the log always issued a STH within the MMD I didn't look up what the real definition of the MMD is, but what I expect is that the time from the SCT being generated until that STH being visible is important, not the time the STH is generated. For instance I only see Digicert's STHs 12 hour later. With Google it depends on the log, for Pilot and Aviator it averages around 25 minutes, for Rocketeer around 100 minutes. > - Can I resolve all inputs (SCTs, STHs) into a single STH via > inclusion/consistency proofs (to prevent split views) Which is why I started to collect all that I can see myself. But I'm not sure yet if this proposal will let me find all of them, or at least all that have been send to someone. Kurt From nobody Wed Oct 19 15:41:44 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 CFE791297C1 for ; Wed, 19 Oct 2016 15:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7AT1mTrm-md for ; Wed, 19 Oct 2016 15:41:41 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 E913912949F for ; Wed, 19 Oct 2016 15:41:40 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id q126so47633241vkd.2 for ; Wed, 19 Oct 2016 15:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c47zgEbjgHN5vOzbsRE6gYTV4scNSFWKM9T46Ok5XNM=; b=TIMJb22krD3H6hT6RGiP4nWJ0tNN99mi8QNXX/V0+m6ib3jXQgfISjiEdLhXn3HO3a FDH3wx/NkYlJx5ViZ7LMcKGXqiRfw3QOWV2+S3+uGqVFiO66yaWqTo3lpfMVkZ5F99SK NORKho85aGwlsyTjwoP+xGln0g342ad9HlndY= 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=c47zgEbjgHN5vOzbsRE6gYTV4scNSFWKM9T46Ok5XNM=; b=Ty1o+hArFQExUDvu6bR5m8+U/MID2f7ma/MVkAMsxWNuXrlAmpMHQpluup4cnNA4G2 elVIzo8YzVPbcFKE0fRRO2FOuB1ZvWVF+kUIMpzFGNQi9n0A4DxD+vFsKrcYSg9k/daA RCMkwQPk+QYPjWzlLso3jFTbg+n0fHIINFpt+zo55S8+sDeZL52QWCbFWbiJq+n/SHZg VrqZw8E7ENUNYcqJRLu8RecCN5hV6xtAPBX52L1rYtgO+0RCqGEIaZHJ+3pIdI5MSFpg 0OIPL1cShq2+plDAHMl9OSxA1w0r7MffKilhsqdFKffSrEfcuRNRQOd8eGUBbHEubEla 62Pw== X-Gm-Message-State: AA6/9RloYy8OyKhCDBKWbslamiTsRg+yGbJ5p8EvLOOyTxbBl0BN+mQQCuxucpTGyehD1nnGk5D8s1txCT2GhFWQ X-Received: by 10.31.84.130 with SMTP id i124mr6861070vkb.66.1476916899884; Wed, 19 Oct 2016 15:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.201 with HTTP; Wed, 19 Oct 2016 15:41:19 -0700 (PDT) In-Reply-To: <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> From: Tom Ritter Date: Wed, 19 Oct 2016 17:41:19 -0500 Message-ID: To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol 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, 19 Oct 2016 22:41:43 -0000 On 19 October 2016 at 15:31, Kurt Roeckx wrote: > On Wed, Oct 19, 2016 at 02:33:30PM -0500, Tom Ritter wrote: >> Actions for an auditor to take is a good thing to try and document >> somewhere. We _could_ put it into Gossip, but it seems like a separate >> draft to me. Off the top of my head I think the main things it would >> be checking are: >> - Has the log always issued a STH within the MMD > > I didn't look up what the real definition of the MMD is, but what > I expect is that the time from the SCT being generated until that > STH being visible is important, not the time the STH is generated. > > For instance I only see Digicert's STHs 12 hour later. With Google > it depends on the log, for Pilot and Aviator it averages around 25 > minutes, for Rocketeer around 100 minutes. Yes, you're right. It's time to get data included (merged) into the tree after a promise (SCT) had been made. I was thinking about it in terms of "Has the log not issued at least one STH in an X-hour period" which is related to MDD, but not the exact same. >> - Can I resolve all inputs (SCTs, STHs) into a single STH via >> inclusion/consistency proofs (to prevent split views) > > Which is why I started to collect all that I can see myself. But > I'm not sure yet if this proposal will let me find all of them, or > at least all that have been send to someone. As an auditor you would want to find all the servers who deploy STH Pollination or SCT Feedback. [0] Once you do that, and start polling from them, you'll be doing the best anyone can. I'm not sure if there's a non-centralized, scalable way to make such a list available to people like yourself. I mean obviously someone could operate a public service and just collect sites that are found via scanning or self-submitted - and I expect this will happen - but it's not the sort of thing we'd put in a draft I don't think. But we're open to suggestions if you have any particular ideas! -tom [0] You could also operate a user-facing 'Trusted Auditor' and feed your own browsing history into it or convince others to do the same. From nobody Thu Oct 20 05:10:16 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 ED067129626; Thu, 20 Oct 2016 05:10:09 -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.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147696540996.18110.13453101771442161116.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2016 05:10:09 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-10.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: Thu, 20 Oct 2016 12:10:10 -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-10.txt Pages : 30 Date : 2016-10-20 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-10 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 Thu Oct 20 06:32:27 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 D43CA1295E4 for ; Thu, 20 Oct 2016 06:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 Za7jZ8kIaI6j for ; Thu, 20 Oct 2016 06:32:22 -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 47D7A1295E1 for ; Thu, 20 Oct 2016 06:32:22 -0700 (PDT) Received: from localhost ([::1]:52186 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bxDSH-000200-Bo; Thu, 20 Oct 2016 06:32:21 -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, robpercival@google.com X-Trac-Project: trans Date: Thu, 20 Oct 2016 13:32:21 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/159 Message-ID: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-Trac-Ticket-ID: 159 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, robpercival@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: <20161020133222.47D7A1295E1@ietfa.amsl.com> Resent-Date: Thu, 20 Oct 2016 06:32:22 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #159 (rfc6962-bis): Missing step in "Verifying an inclusion proof" 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: Thu, 20 Oct 2016 13:32:27 -0000 #159: Missing step in "Verifying an inclusion proof" In section 10.4.1, the described algorithm is missing a step. Immediately under '4. For each value "p" in the "inclusion_path" array:', it should say 'If "sn" is 0, stop the iteration and fail the proof verification.'. Otherwise, inclusion proofs containing more nodes than necessary (i.e. not "the shortest list of additional nodes") will pass verification. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- robpercival@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Oct 20 09:38:12 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 65C7A129554 for ; Thu, 20 Oct 2016 09:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 5E7BWuN_U6Ft for ; Thu, 20 Oct 2016 09:38:10 -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 653A812964F for ; Thu, 20 Oct 2016 09:38:10 -0700 (PDT) Received: from localhost ([::1]:58239 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bxGM5-0003lh-L8; Thu, 20 Oct 2016 09:38:09 -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, rob.stradling@comodo.com X-Trac-Project: trans Date: Thu, 20 Oct 2016 16:38:09 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/159#comment:1 Message-ID: <078.4618dbd362b1c5f4382ed45ca5988526@tools.ietf.org> References: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20161020163810.653A812964F@ietfa.amsl.com> Resent-Date: Thu, 20 Oct 2016 09:38:10 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #159 (rfc6962-bis): Missing step in "Verifying an inclusion proof" 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: Thu, 20 Oct 2016 16:38:12 -0000 #159: Missing step in "Verifying an inclusion proof" Comment (by rob.stradling@comodo.com): Here's a PR to address this defect report: https://github.com/google/certificate-transparency-rfcs/pull/199 Chairs, 6962-bis has completed WGLC, so how do we handle this? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- robpercival@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Oct 21 16:27:49 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 9BAD6129431; Fri, 21 Oct 2016 16:21:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208163.28214.5167460582608701930.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:21 -0700 Archived-At: Cc: trans@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Trans] trans - Requested session has been scheduled for IETF 97 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, 21 Oct 2016 23:21:26 -0000 Dear Paul Wouters, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (0:30:00) Tuesday, Morning Session I 0930-1200 Room Name: Studio 4 size: 100 --------------------------------------------- Special Note: 11:30-12:00 Request Information: --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Paul Wouters Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 25 Conflicts to Avoid: First Priority: mtgvenue dnsop ipsecme httpbis Second Priority: curdle tls Third Priority: sacm Special Requests: --------------------------------------------------------- From nobody Sun Oct 23 14:42:01 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 D3D581294D1 for ; Sun, 23 Oct 2016 14:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMPD76sobdGt for ; Sun, 23 Oct 2016 14:41:59 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE04B129411 for ; Sun, 23 Oct 2016 14:41:59 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id EBF331406B0B for ; Sun, 23 Oct 2016 14:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sleevi.com; bh=j90l5fK/8VPk6lMYQQKUXj00iaA=; b=JBDpjNyvJ9h1+UEOLB3MZTjX7qYg X1hwpUjZTSPjg76imFwFqeNFw7xWw2SNJmxyRZrZsOzwd6Ydov90bVTiJG6yQWvZ PP0QND+dCkH/94enOcE1tTFp/uZHM9ni27kRW71SYqXmjzJbtnxPmpvlE5alTivL ytqa1A/k8mTavTM= Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id D24F91406B0A for ; Sun, 23 Oct 2016 14:41:58 -0700 (PDT) Received: by mail-yw0-f171.google.com with SMTP id w3so148761006ywg.1 for ; Sun, 23 Oct 2016 14:41:58 -0700 (PDT) X-Gm-Message-State: ABUngvd3lnuztIKkLjViyzx/B7Te6rAvUriNS1jdEa6741ZdSbrWgxn5wsFnCWIfoz3XFeuOAkQXLNMhenqixA== X-Received: by 10.129.84.4 with SMTP id i4mr11425692ywb.83.1477258917978; Sun, 23 Oct 2016 14:41:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.245.193 with HTTP; Sun, 23 Oct 2016 14:41:57 -0700 (PDT) From: Ryan Sleevi Date: Sun, 23 Oct 2016 14:41:57 -0700 X-Gmail-Original-Message-ID: Message-ID: To: trans@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Rob Stradling , eranm@google.com Subject: [Trans] Question about Draft 19 - Section 4.2 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: Sun, 23 Oct 2016 21:42:01 -0000 I'm curious to understand the interpretation of Section 4.2, and it's presumed implications for CT clients. At present, Section 4.2 ( https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-19#section-4.2 ) states: An intermediate CA certificate or intermediate CA precertificate that contains the Name Constraints [RFC5280] extension MAY be logged in place of end-entity certificates issued by that intermediate CA, as long as all of the following conditions are met As I read this, this implies that this is not an obligation upon clients to recognize this extension, or this approach to logging. That is, a client (such as Google Chrome) may consider rejecting such certificates as part of its Certificate Transparency policy. At present, this is where the thinking of Chrome is, but if it's perceived to obligate clients to recognize such events, then I'd like to try to see how to tweak the text to make it clearer that this is optional - for logs and for clients. >From discussing with some of the authors, and from those in the CA and log operator space, it doesn't seem that there's a clear agreement about the implication of the text, and whether or not it belongs in https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ (as a technical means for redaction). However, if there's WG consensus that it is merely descriptive about how such a mechanism would work (via MAY), rather than prescriptive upon a client implementation, then perhaps it's worth noting more explicitly as such, without meaningfully altering the text that has passed WG consensus. From nobody Sun Oct 23 16:07:28 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 10AAE12949E for ; Sun, 23 Oct 2016 16:07:27 -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 3gqWTFTkhSA1 for ; Sun, 23 Oct 2016 16:07:25 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 834B8126CD8 for ; Sun, 23 Oct 2016 16:07:25 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id t192so154243435ywf.0 for ; Sun, 23 Oct 2016 16:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4T7xFKRuyb8mToLQyjp4KADzg3loqOUy2hY0qpnteY4=; b=KLFrJ2DSD6mb8ymxZEEfa2rL82/DPzLNJmu7PTdqJOA5HPiBzrb94opTnLUrTiSbO1 g/1SB/6WDI2hHgzqbemlY/5wWIvYQQBYrNTBvkNOXH12Abr/f9huJnN7oHJVNQn1ZRnI hFov4ro+TgDaNVSW8lntqtg66djTETanH48CVb9d9nMGhL3sz9w4j0rPra1j4wPJ4Cj6 g8a1uK6hn9YdCjPw46Oqt/kzbLPIQmSS/yIMSjk5mpNBGPrbjivBqYhDrph2RRDwZ9Du tV4P4tkh8DWS+9GjEMbU+wPcyDom4FU9Rwedexujk7aLwjbRk69D9MWRyBxB7M/FF7te BqQg== 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=4T7xFKRuyb8mToLQyjp4KADzg3loqOUy2hY0qpnteY4=; b=jxApnritpmAcg6EWhfQ62bfM9z6JGwTgy3Q/xlq/7P0T843DfDV0Y5YHykWtZ75IT/ QVfQS3+yO3VRVnnQO/dG2thllBKL3RHTq6K1Gw9YyuxCNboEpHLknM1zrr7tGn+jwofR GT9oFjKZvsNde4xbpatCxkt9lw+Sn0CPM4VqDqWnUfE00hu1AaWtzCCQh/wxVQxpTt8N Sr65w/PO/3Qf5Qvcvyy0RKGvYPLy+Mjp+0MWTQoYrSalNs0rpjZ4x6jTFA7xUOeKAIWj wa/lhn7OKa2UVHjf7WMjhcHEwHcebO5I0mkySfUGV49Wdr1w//MYh7QufXFuSOs2avcR 3zBw== X-Gm-Message-State: ABUngvdtEnueD/69etaihZU6oW9opBlf348ccDK6WfHfba1yGRQ2lsMnXxmquxBdWIcJVd1cQ1KOw+BEdjs4ag== X-Received: by 10.36.38.137 with SMTP id v131mr469535itv.76.1477264044691; Sun, 23 Oct 2016 16:07:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Sun, 23 Oct 2016 16:07:24 -0700 (PDT) In-Reply-To: References: From: Peter Bowen Date: Sun, 23 Oct 2016 16:07:24 -0700 Message-ID: To: Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Rob Stradling , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Question about Draft 19 - Section 4.2 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: Sun, 23 Oct 2016 23:07:27 -0000 On Sun, Oct 23, 2016 at 2:41 PM, Ryan Sleevi wrote: > I'm curious to understand the interpretation of Section 4.2, and it's > presumed implications for CT clients. > > At present, Section 4.2 ( > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-19#section-4.2 > ) states: > > An intermediate CA certificate or intermediate CA precertificate that > contains the Name Constraints [RFC5280] extension MAY be logged in > place of end-entity certificates issued by that intermediate CA, as > long as all of the following conditions are met > > As I read this, this implies that this is not an obligation upon > clients to recognize this extension, or this approach to logging. That > is, a client (such as Google Chrome) may consider rejecting such > certificates as part of its Certificate Transparency policy. At > present, this is where the thinking of Chrome is, but if it's > perceived to obligate clients to recognize such events, then I'd like > to try to see how to tweak the text to make it clearer that this is > optional - for logs and for clients. The draft clearly calls for TLS clients to accept this. See section 8: TLS servers MUST use at least one of the three mechanisms listed below to present one or more SCTs from one or more logs to each TLS client during full TLS handshakes, where each SCT corresponds to the server certificate or to a name-constrained intermediate the server certificate chains to. Section 10.2.6 makes it clear that section 8 defines compliance: If any certificate in a chain includes the transparency_info (Section 8.5) TLS extension identifier in the TLS Feature [RFC7633] certificate extension, then CT compliance (using any of the mechanisms from Section 8) is required. It appears that the methiod in 4.2 is explicitly called out in other sections and does not appear to be optional for clients. > >From discussing with some of the authors, and from those in the CA and > log operator space, it doesn't seem that there's a clear agreement > about the implication of the text, and whether or not it belongs in > https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ (as a > technical means for redaction). However, if there's WG consensus that > it is merely descriptive about how such a mechanism would work (via > MAY), rather than prescriptive upon a client implementation, then > perhaps it's worth noting more explicitly as such, without > meaningfully altering the text that has passed WG consensus. I don't think it needs moving. The objective to allow named subjects of certificates to detect mis-issuance is met by using Name Constrained CAs. Just as a subject monitors for end-entity certificates she did not authorize, she should also monitor for subordinate CAs she did not authorize. The effect is the same -- ensuring that there is proper authorization for the issuance of certificates. The key difference between an unconstrained CA and name constrained CA is pre-notification of intent to issue. With an unconstrained CA, any name can show up at any time. However with a NC CA, there is clear notice of what names are to be issued. This is even better than a standard end-entity certificate checking, as the subject can preemptively take action rather than waiting for the first EE certificate to be issued. Thanks, Peter From nobody Sun Oct 23 16:28:47 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 8194D126FDC for ; Sun, 23 Oct 2016 16:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTQzU8xPmDVP for ; Sun, 23 Oct 2016 16:28:44 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C3E126CD8 for ; Sun, 23 Oct 2016 16:28:44 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id B96891406B0D for ; Sun, 23 Oct 2016 16:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=ZBSqMmwbYObuQJfxEzrPicrvarI=; b= m0wqsZFzjNyPt0Gb2TQ50jm98jn6JDjO5uHbh3RbizqWO2ye0CGN+48kN5zxnlwP MP0G/UzJwKTSzMFlocD3izcgig4OvFvkdNmzBMWQRFEqp1woNMbGH0BgNJhn6+sT 9cpA6vRbSPdTQOl6K/edeBR6Fp7oJiOd7QIUEQB+phY= Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 9BF5C1406B0B for ; Sun, 23 Oct 2016 16:28:43 -0700 (PDT) Received: by mail-yw0-f171.google.com with SMTP id u124so154298477ywg.3 for ; Sun, 23 Oct 2016 16:28:43 -0700 (PDT) X-Gm-Message-State: ABUngvePeQ8bvLJEoSZM8Kngz4VnFk6vpgQK8K497y5pcqRYVi49a9yljkQN5pqOTLQd1CjmrtpKyUDiOU15vw== X-Received: by 10.129.84.4 with SMTP id i4mr11761292ywb.83.1477265322854; Sun, 23 Oct 2016 16:28:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.245.193 with HTTP; Sun, 23 Oct 2016 16:28:42 -0700 (PDT) In-Reply-To: References: From: Ryan Sleevi Date: Sun, 23 Oct 2016 16:28:42 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a114d8584ced986053f90a2b2 Archived-At: Cc: Ryan Sleevi , Rob Stradling , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Question about Draft 19 - Section 4.2 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: Sun, 23 Oct 2016 23:28:45 -0000 --001a114d8584ced986053f90a2b2 Content-Type: text/plain; charset=UTF-8 On Sunday, October 23, 2016, Peter Bowen wrote: > On Sun, Oct 23, 2016 at 2:41 PM, Ryan Sleevi > wrote: > > I'm curious to understand the interpretation of Section 4.2, and it's > > presumed implications for CT clients. > > > > At present, Section 4.2 ( > > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-19#section-4.2 > > ) states: > > > > An intermediate CA certificate or intermediate CA precertificate that > > contains the Name Constraints [RFC5280] extension MAY be logged in > > place of end-entity certificates issued by that intermediate CA, as > > long as all of the following conditions are met > > > > As I read this, this implies that this is not an obligation upon > > clients to recognize this extension, or this approach to logging. That > > is, a client (such as Google Chrome) may consider rejecting such > > certificates as part of its Certificate Transparency policy. At > > present, this is where the thinking of Chrome is, but if it's > > perceived to obligate clients to recognize such events, then I'd like > > to try to see how to tweak the text to make it clearer that this is > > optional - for logs and for clients. > > The draft clearly calls for TLS clients to accept this. See section 8: > > TLS servers MUST use at least one of the three mechanisms listed > below to present one or more SCTs from one or more logs to each TLS > client during full TLS handshakes, where each SCT corresponds to the > server certificate or to a name-constrained intermediate the server > certificate chains to. > > Section 10.2.6 makes it clear that section 8 defines compliance: > > If any certificate in a chain includes the transparency_info > (Section 8.5) TLS extension identifier in the TLS Feature [RFC7633] > certificate extension, then CT compliance (using any of the > mechanisms from Section 8) is required. > > It appears that the methiod in 4.2 is explicitly called out in other > sections and does not appear to be optional for clients. It is precisely these sections that I have heard disagreeing interpretations, precisely because it implies dictating policy about what a client accepts. As a counter-interpretation, what about clients that impose policy on the SCTs delivered - such as Chrome does. Either we accept CT compliance is locally defined - which suggests optionality - or it's an unnessecary constraint on policy inconsistent with existing 6962 implementations. > I don't think it needs moving. The objective to allow named subjects > of certificates to detect mis-issuance is met by using Name > Constrained CAs. Just as a subject monitors for end-entity > certificates she did not authorize, she should also monitor for > subordinate CAs she did not authorize. The effect is the same -- > ensuring that there is proper authorization for the issuance of > certificates. While this is true, as you know, this is not the only objective of CT from existing implementations. For example, it prevents detection of misissuance as defined by the CA/Browser Forum's Baseline Requirements, as name constrained sub-CAs still have obligations of issuance practice imposed on them. Your interpretation suggests the only value of CT is for specific domain holders, but I don't believe that's a correct or shared interpretation. --001a114d8584ced986053f90a2b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, October 23, 2016, Peter Bowen <pzbowen@gmail.com> wrote:
On Sun, Oct 23, 2016 at 2:41 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> I'm curious to understand the interpretation of Section 4.2, and i= t's
> presumed implications for CT clients.
>
> At present, Section 4.2 (
> https://tools.ietf.org/html/draft-ietf= -trans-rfc6962-bis-19#section-4.2
> )=C2=A0 states:
>
>=C2=A0 =C2=A0 An intermediate CA certificate or intermediate CA precert= ificate that
>=C2=A0 =C2=A0 contains the Name Constraints [RFC5280] extension MAY be = logged in
>=C2=A0 =C2=A0 place of end-entity certificates issued by that intermedi= ate CA, as
>=C2=A0 =C2=A0 long as all of the following conditions are met
>
> As I read this, this implies that this is not an obligation upon
> clients to recognize this extension, or this approach to logging. That=
> is, a client (such as Google Chrome) may consider rejecting such
> certificates as part of its Certificate Transparency policy. At
> present, this is where the thinking of Chrome is, but if it's
> perceived to obligate clients to recognize such events, then I'd l= ike
> to try to see how to tweak the text to make it clearer that this is > optional - for logs and for clients.

The draft clearly calls for TLS clients to accept this.=C2=A0 See section 8= :

=C2=A0 =C2=A0TLS servers MUST use at least one of the three mechanisms list= ed
=C2=A0 =C2=A0below to present one or more SCTs from one or more logs to eac= h TLS
=C2=A0 =C2=A0client during full TLS handshakes, where each SCT corresponds = to the
=C2=A0 =C2=A0server certificate or to a name-constrained intermediate the s= erver
=C2=A0 =C2=A0certificate chains to.

Section 10.2.6 makes it clear that section 8 defines compliance:

=C2=A0 =C2=A0If any certificate in a chain includes the transparency_info =C2=A0 =C2=A0(Section 8.5) TLS extension identifier in the TLS Feature [RFC= 7633]
=C2=A0 =C2=A0certificate extension, then CT compliance (using any of the =C2=A0 =C2=A0mechanisms from Section 8) is required.

It appears that the methiod in 4.2 is explicitly called out in other
sections and does not appear to be optional for clients.
<= br>
It is precisely these sections that I have heard disagreeing = interpretations, precisely because it implies dictating policy about what a= client accepts.

As a counter-interpretation, what= about clients that impose policy on the SCTs delivered - such as Chrome do= es.

Either we accept CT compliance is locally defi= ned - which suggests optionality - or it's an unnessecary constraint on= policy inconsistent with existing 6962 implementations.
=C2=A0
I don't think it needs moving.=C2=A0 The objective to allow named subje= cts
of certificates to detect mis-issuance is met by using Name
Constrained CAs.=C2=A0 Just as a subject monitors for end-entity
certificates she did not authorize, she should also monitor for
subordinate CAs she did not authorize.=C2=A0 The effect is the same --
ensuring that there is proper authorization for the issuance of
certificates.

While this is true, as you kn= ow, this is not the only objective of CT from existing implementations.

For example, it prevents detection of misissuance as = defined by the CA/Browser Forum's Baseline Requirements, as name constr= ained sub-CAs still have obligations of issuance practice imposed on them.<= /div>

Your interpretation suggests the only value of CT is fo= r specific domain holders, but I don't believe that's a correct or = shared interpretation.

--001a114d8584ced986053f90a2b2-- From nobody Mon Oct 24 05:04: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 DAC0E129511 for ; Mon, 24 Oct 2016 05:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 eVlIfGykQKQ4 for ; Mon, 24 Oct 2016 05:04:01 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EF11296A6 for ; Mon, 24 Oct 2016 05:03:59 -0700 (PDT) Received: (qmail 20860 invoked by uid 1004); 24 Oct 2016 12:03:57 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 24 Oct 2016 13:03:57 +0100 Received: (qmail 15389 invoked by uid 1000); 24 Oct 2016 12:03:57 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 24 Oct 2016 13:03:57 +0100 To: Ryan Sleevi References: From: Rob Stradling Message-ID: <1a0daffa-7719-75a2-71d6-1b76e71992dd@comodo.com> Date: Mon, 24 Oct 2016 13:03:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Question about Draft 19 - Section 4.2 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, 24 Oct 2016 12:04:07 -0000 On 24/10/16 00:28, Ryan Sleevi wrote: > Either we accept CT compliance is locally defined - which suggests > optionality - or it's an unnessecary constraint on policy inconsistent > with existing 6962 implementations. RFC6962 and 6962-bis specify the technical mechanisms of CT. Therefore, it seems entirely appropriate for these documents to define what constitutes basic CT compliance. This doesn't prevent TLS Clients from adding extra/stricter requirements via their own CT Policies though. For example, 6962-bis draft 19 section 10.2.5 says... "To be considered compliant, a certificate MUST be accompanied by at least one valid SCT." ...but section 8.1 recognizes that... "TLS clients may have policies related to the above risks requiring servers to present multiple SCTs. For example, at the time of writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to be presented with EV certificates in order for the EV indicator to be shown." Similarly, I think a future Chrome CT Policy could conceivably state that Chrome will only accept SCTs that correspond to end-entity certs, even though 6962-bis specifies the option of SCTs for name-constrained intermediates. That said, if you're certain that Chrome won't accept SCTs for name-constrained intermediates as currently defined in 6962-bis, then I'd be in favour of moving this feature to the Redaction draft. Since we've completed WGLC for 6962-bis, I presume this possible course of action would be a matter for the WG chairs and/or Area Directors to consider. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Oct 24 09:07: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 B87A012956D for ; Mon, 24 Oct 2016 09:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJPjcf4HueM4 for ; Mon, 24 Oct 2016 09:07:18 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6AB6129557 for ; Mon, 24 Oct 2016 09:07:18 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 4C9FE30002925 for ; Mon, 24 Oct 2016 09:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=/F7wLsF0VyRO1zMn6LB6Frmw5tA=; b= EmTr4j6tMatAQRjDF6HiVmNC3z1TuHl6ihSIRBn+ThgNtpOeqoX7AH4evx4+nWrm Q2soabvlbHFUAuzYRCinoSlAv/oI4+cYa4f+LI7Wox4Be2hanTOzNu8TqjHRbkmh +s/oh5PdxVdQ2ZUGKZP9sI6GIyubaVmDGHcAgKUwvAo= Received: from mail-yb0-f182.google.com (mail-yb0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 2B66F30002924 for ; Mon, 24 Oct 2016 09:07:18 -0700 (PDT) Received: by mail-yb0-f182.google.com with SMTP id f133so14586194ybc.3 for ; Mon, 24 Oct 2016 09:07:18 -0700 (PDT) X-Gm-Message-State: ABUngveRqXfDU+SPqJIXMcpFyXgqtM4bVjQed6AD7gL+OxhMbNZbmGb/UVGLT6crZdDbiYqwsJDw1DnVFdcpFA== X-Received: by 10.37.92.7 with SMTP id q7mr14168793ybb.185.1477325236353; Mon, 24 Oct 2016 09:07:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.245.193 with HTTP; Mon, 24 Oct 2016 09:07:15 -0700 (PDT) In-Reply-To: <1a0daffa-7719-75a2-71d6-1b76e71992dd@comodo.com> References: <1a0daffa-7719-75a2-71d6-1b76e71992dd@comodo.com> From: Ryan Sleevi Date: Mon, 24 Oct 2016 09:07:15 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ryan Sleevi , "trans@ietf.org" Subject: Re: [Trans] Question about Draft 19 - Section 4.2 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, 24 Oct 2016 16:07:21 -0000 On Mon, Oct 24, 2016 at 5:03 AM, Rob Stradling wrote: > That said, if you're certain that Chrome won't accept SCTs for > name-constrained intermediates as currently defined in 6962-bis, then > I'd be in favour of moving this feature to the Redaction draft. Since > we've completed WGLC for 6962-bis, I presume this possible course of > action would be a matter for the WG chairs and/or Area Directors to > consider. I can't say with certainty, because I think it touches back on the issues previously discussed in the CA/Browser Forum and in Chromium CT Policy list - which is that a variety of solutions exist, some technical and some policy, and the appropriate solution will likely sit somewhere between the both. My goal in sending this was to check to see whether there was consensus, say, for a client rejecting EE certs that were accompanied by SCTs from name-redacted CAs, because in talking with various people involved in the space, I was seeing conflicting answers about "what the spec said". Your interpretation is aligned with how I saw it - that client policy dictates the acceptable form of SCTs - which, to me, also implies that a client that only wishes to recognize EE SCTs does not even need to parse/recognize such SCTs. That is, the spec describes the technical means for it, but it's not mandatory for clients to accept/recognize it as complying with policy. That's why I hoped that, if there's consensus on that interpretation, it might be seen as a an opportunity wording tweak that doesn't undermine consensus, rather than a more significant action (like moving to a redaction spec) From nobody Mon Oct 24 18:06:47 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 A083B1294B3 for ; Mon, 24 Oct 2016 18:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3P1C69HuUrX for ; Mon, 24 Oct 2016 18:06:44 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909B1126CD8 for ; Mon, 24 Oct 2016 18:06:44 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 8A21730002B25 for ; Mon, 24 Oct 2016 18:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sleevi.com; bh= IzRSgEgSJGupHm+LMbNBFQXF+AE=; b=beW4wLST623cYh18Dv62mo7Q5q4TAIIQ aUF6XPnkyMAy5a5NRMlk4rEC9PgnGrlLgq8/7XltLHUboahiDXW6TGwzGl86ZKa1 lWHiQs0C8yHMI38TPyAkhLUrjtmmMbudrHsGfYk8OuYoVNUCpYNIDxEauUL9chAn 9Mpzg33Tf7o= Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 7B3F930002B24 for ; Mon, 24 Oct 2016 18:06:43 -0700 (PDT) Received: by mail-yw0-f179.google.com with SMTP id w3so211278879ywg.1 for ; Mon, 24 Oct 2016 18:06:43 -0700 (PDT) X-Gm-Message-State: ABUngveMagWXCcxZb+3mXFjPLEzMZ/HbektkQBmwuI91vUFmdW5AUYnXeloj3Fuh2gS0Fko62tElELrI5Lj56w== X-Received: by 10.129.88.84 with SMTP id m81mr17965828ywb.147.1477357602766; Mon, 24 Oct 2016 18:06:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.245.193 with HTTP; Mon, 24 Oct 2016 18:06:42 -0700 (PDT) From: Ryan Sleevi Date: Mon, 24 Oct 2016 18:06:42 -0700 X-Gmail-Original-Message-ID: Message-ID: To: trans@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Chrome requiring Certificate Transparency in 2017 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, 25 Oct 2016 01:06:45 -0000 While not wanting to spam this list, I did just want to let participants know that the Chrome team has announced plans to that website certificates issued in October 2017 or later must comply with Chrome's Certificate Transparency Policy in order to be trusted in Chrome. The full text of this announcement is at https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/78N3SMcqUGw As noted in that thread, we've encouraged CAs and sites to bring use cases to the IETF for discussion, particularly around redaction, to ensure that needs are being understood. However, we fully recognize that not everything has a technical solution - some of it may require policy action within either the CA/Browser Forum or browsers' root store requirements, rather than addressing within CT itself. However, we wanted to make sure that the technical venue of discussion was brought to the IETF, rather than the disparate groups it might otherwise occur (the CA/Browser Forum, browsers' security lists, private discussions) I'll be at IETF 97 as well, and happy to discuss any questions - on-list if it's not seen as off-topic, otherwise off-list, on the ct-policy@ list, or in-person in the next few IETFs. At present, the Chrome CT Policy requires RFC 6962. Support for 6962-bis, let alone requiring it, will be gated on the IETF process and industry adoption. Speaking solely with a "Chrome hat" (not quite individual hat), we're interested in making sure CT addresses' real world needs, rather than rushing through process. To be more explicit: This should neither be seen as a request to rush or to delay 6962-bis' progression, or of any of the other supporting documents :) We're hugely appreciative of all of the effort that the IETF participants have spent working on Certificate Transparency, both as 6962 and 6962-bis, and hopefully this counts as a ringing endorsement to the progress that both has been made and continues to be made within this space. On the topic of redaction, and for which new use cases continue to emerge, we're committed to engaging the community and finding the best solutions for the problems raised here in the IETF. Hopefully, this announcement will lead to even greater involvement and activity in this WG about both the problem space, and the possible solutions, around redaction. From nobody Mon Oct 24 21:38:04 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 91C8012940E for ; Mon, 24 Oct 2016 21:38:02 -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 KfbVuOsyAHFz for ; Mon, 24 Oct 2016 21:38:01 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 17969127735 for ; Mon, 24 Oct 2016 21:38:00 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id r16so111491494pfg.1 for ; Mon, 24 Oct 2016 21:38:00 -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=oHsppAh65Fl9Zr8JMOLcXZ8pjjYlHGrtB/+eArM3qGY=; b=HLgJ9W02odMlx1DD/jOvyXt7QeMBhg4AvAL1350/slk1z3Ee0cCSaH7xw1+7SPtkwS ZjACTHoM8icTiQ6+C3qh56SoJp4uiDKPitQLvfCFnyTLrt0h8CQliDtI1n+nYcVCQ0qk FhXMXNzkGhdjRI9hQMlQbZk6s7nEDACv2HG1U18gi0eYf3hcMskoDPYpUgLYUmvGqkdb UPWllP7LmwdvlVtVn6fcwR8ckFgKPXLqZQ0py2mv2Bfhzsu+Nxk/z49rMYzslBz30xRH shev9s79UwLU7sPm7I40DlhraRJa5huiyX6PTox6VW44/Jb39H1WpJXM3dIWymtVxkEE KGVQ== 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=oHsppAh65Fl9Zr8JMOLcXZ8pjjYlHGrtB/+eArM3qGY=; b=hFX2eHCc2j+PZgVG826XR/2F2VAU3gUluYr5svXNW1IvYzNXTCUp9QIUspeu1DEMND QnMQ4o5sAKphnfyJT9+JDkCN4Jvdho3raChah/PwLR6xoQR5fu7ifuSFoQsjA8wjDOZD 2PDQ4vkZyiQ9ppyvxkCBOLg+vNRNc2pjAtyEMVttSDhVqfAi6bVmawAM1Ux8isR/3hJe 3y6FPCeQFWWmayqZYCM1KT1GKNY0zPGJah3j5EWFBkmL3feID15YZ1BKooSfp0MoChhS 4fhAWCZZaRrH8ZOBb4GdWjZzoxerxfwp2VT1F9bOVWpzJUVid2/B11Btbtqpt+8Ux+er +DdQ== X-Gm-Message-State: ABUngvd5JgNCv0Nritcl6kwY2BO3mCO2CnGzm4AbqWtIQmPofxHUQG8ItqhxVHq8B5LtQA== X-Received: by 10.99.151.17 with SMTP id n17mr4487584pge.150.1477370280359; Mon, 24 Oct 2016 21:38:00 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (209-112-218-190-radius.dynamic.acsalaska.net. [209.112.218.190]) by smtp.googlemail.com with ESMTPSA id qy2sm14959677pab.27.2016.10.24.21.37.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 21:37:59 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> Date: Mon, 24 Oct 2016 20:37:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A0OQ1bxglC6SeWHIltwilIA6xFTPAhd8b" Archived-At: Subject: [Trans] Topicality 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, 25 Oct 2016 04:38:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A0OQ1bxglC6SeWHIltwilIA6xFTPAhd8b Content-Type: multipart/mixed; boundary="vtPXxGGf42NNPTeffPTimf0LDrPVVXVs9"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> Subject: Topicality --vtPXxGGf42NNPTeffPTimf0LDrPVVXVs9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: You may have seen the recent announcement from the Chrome team that as of October 2017 certificates will need to comply with Chrome's CT policy in order to be trusted. There was also an invitation to discuss that on the trans mailing list. This is a reminder that mailing list discussions need to remain focused on the specifications being produced by the working group - that is to say, policies related to individual implementations are out of scope for the working group except to the extent that they bear on decisions related to our working group drafts. Many thanks, Paul and Melinda --vtPXxGGf42NNPTeffPTimf0LDrPVVXVs9-- --A0OQ1bxglC6SeWHIltwilIA6xFTPAhd8b 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 iQIcBAEBCgAGBQJYDuGkAAoJELiGRpM6HoEuSgAP/j7OD48yDNaYT41flgEamciV 6BQNzF0aPGEHh+Qw1Hw0UAbu2oP7Sf50+pkpSvBqo9CsM0Y6YdXq9M5O/Fi+7FwQ ctgCVOI0ZOJUFLIdG1B2IOR32SxfWNI1ojFY+LZTZ3WzRBLd91xikPBnWaJ8+Fas abE6hBXeHyqfEhzQ6ptVYXG9+8wZ6ewcE9leKLk/VB8PdtVyoJWBE3yV8CQwPln2 FkAijqCjioltQEWHgKgp6f6UpSHymlyFY1iky3gduS4bEKhEQn75w+Gwcren/OBp kPwBjrcPuy7E5tTovdAtWsRHGOG+42yXJ6zvpFB7Y4uAyhUpTSjTI5CboAJdkSqv 4vsHxwB5Hy1VLPwOajPN2JwZxFmy0FWqSLyDxsp6XTW6N9w591GPBN7a4v5pjnGf /HIPqBa0Wu2rQPRAZgXIhKnJouZ001yOSKhxnk7n0nU+qICW4MslswqRW9phoq4e VOS1jgezd/bsNo4BKKoqOoz15mvqS/6WMkm3//DMavpGlZuA01Ah8UUAY+Vg20Tz o7nWPYmJi+z0VJOwv08bM0CgeVdx66+fJITE7cLlxqV48EunC+2OfBlzlzi3i4We BkvbeUdeo+BJRDt1NT4VcvNcKNnwwgylKR/NeYzhTi/24xFet9iA3ifaiI671UZr 2fsE7PBCzI7RWPaVTh6k =MPaW -----END PGP SIGNATURE----- --A0OQ1bxglC6SeWHIltwilIA6xFTPAhd8b-- From nobody Tue Oct 25 02:57:05 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 DD963129471 for ; Tue, 25 Oct 2016 02:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 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.431, 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 s4TIEefJ4SeW for ; Tue, 25 Oct 2016 02:57:02 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1621512943C for ; Tue, 25 Oct 2016 02:57:01 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id b80so153493805wme.1 for ; Tue, 25 Oct 2016 02:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ie8DoGQkj6LE8YcYMWoJU1U+PbRcbj8XcfQ9JsbCmQA=; b=k/uJs+xqBwHU34sETS3dVwqHBpK5aRcTnWRk25I3Wl8pWrm1b58EnTjTJrx6yWj6fK pYDHGTFBacyN0wUNopAyn+SKr42VcH/FZEyCtvEZ5yeuyfab7UcBcRB3IN72xskOg/Id cIXAE3NEIjTjEnkls4FjR7hnbgb9Vg0T2WQY9+qVKDHFqocIP8U6Yi2XLI1PGERwhzKx eSYVYCQ0OEEg8wCuAK3VXCLDopFsQ87AM167wGy1a4Lf7mvEuRb8YR6353trgKH87DQ6 ipicsgDM1rgy4vjmNcAjK3Df7efZYlzwcFtn2YpkVTP5TsJ+9zG2a5i51vCL/upj8uh7 7RDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ie8DoGQkj6LE8YcYMWoJU1U+PbRcbj8XcfQ9JsbCmQA=; b=A1x3q6lbnKKre3xuyXAY2EJMqf89EyA3bDc8YA2t4rc00X9axdIvTMlroF7v3ocHJU Q7DiFaX3flfHEc1/67VHd3LKN3WTZncnvPasfsUbc6QABa9EwfLGLjl2PSl9Cbxa0ZmF c7FvLmz05STaT5WjBpc4eU4FCXFtWr97BSnN+6K92EkH1n9s5WFwCdy9oFfHJmNT5ke9 mjwC+Uu6d5KaWPUA2thue74xccQoc/iuY3pCnFF1hdMsuewDskYziDZcJjZvMUv+C5oi SyOWxQcxmHmW2OjY8O+2v/1YueJ5ki19IIWvBi/A4DHU60Z86ejY2Ask7hGx8nu3iB0I rnPg== X-Gm-Message-State: ABUngvdIGI0b2Vtsng5tL3so/JJzeZI2gOAYpay74yom0BVs5Tl3g3qhOJv4tMVhz5WOk8q1 X-Received: by 10.194.96.211 with SMTP id du19mr15518585wjb.62.1477389420199; Tue, 25 Oct 2016 02:57:00 -0700 (PDT) Received: from 3.6.7.8.3.d.6.0.7.a.4.2.7.8.0.5.a.a.2.e.e.7.a.f.0.b.8.0.1.0.0.2.ip6.arpa (3.6.7.8.3.d.6.0.7.a.4.2.7.8.0.5.a.a.2.e.e.7.a.f.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:fa7e:e2aa:5087:24a7:6d3:8763]) by smtp.gmail.com with ESMTPSA id pe5sm24179101wjb.15.2016.10.25.02.56.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 25 Oct 2016 02:56:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Paul Hadfield In-Reply-To: Date: Tue, 25 Oct 2016 10:56:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> <557B1834.8040706@bbn.com> To: Rob Stradling X-Mailer: Apple Mail (2.3124) Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Log Monitoring API 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, 25 Oct 2016 09:57:04 -0000 > On Oct 6, 2016, at 4:21 PM, Rob Stradling = wrote: >=20 > Now we've completed WGLC for 6962-bis, I'd like to pick this thread = back > up again. >=20 > Several different public CT monitoring services now exist (crt.sh, = Cert > Spotter, Censys.io, etc). ISTM that it would be useful to define a > common API that could be implemented by each monitor, so that = end-users > don't have to implement multiple APIs in order to talk to multiple = monitors. >=20 > Matt Palmer and I made a start on a (very drafty) draft a while ago: > = https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palm= er-ct-monitor-api.md >=20 > Who's interested in working on this? >=20 I=92d like to be involved. I work on Google=92s CT Monitor, auditing = and misissuance detection tools, and the CT search backend used by the Google Transparency = Report=92s HTTPS page. Paul > On 12/06/15 18:34, Stephen Kent wrote: >> Rob, >>=20 >>> On 11/06/15 22:40, Stephen Kent wrote: >>>> Rob, >>>>=20 >>>>> 6962-bis notes that: >>>>> "Those who are concerned about misissue can monitor the logs, = asking >>>>> them regularly for all new entries, and can thus check whether >>>>> domains they are responsible for have had certificates issued = that >>>>> they did not expect." >>>>>=20 >>>>> If you act as a monitor yourself, you can be sure that the logs = you're >>>>> monitoring aren't misbehaving. You don't have to trust the logs. >>>>=20 >>>> I'm not sure I follow your argument above. >>> >>>=20 >>> Hi Steve. I was aiming for a quick summary rather than a >>> fully-specified problem statement. You're correct that the audit = role >>> is vital too. >>>=20 >>> If the CT ecosystem is functioning as intended, then a monitor can = be >>> sure that they've seen every logged cert, without having to trust = the >>> log. >> yes. >>>=20 >>> But a client of a monitor has to trust the monitor. >> agreed. >>>=20 >>> Is that any clearer? >> yes. >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online >=20 From nobody Tue Oct 25 03:26:33 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 9561A1294AD for ; Tue, 25 Oct 2016 03:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 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.431, 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 UGlfz1kTQkQY for ; Tue, 25 Oct 2016 03:26:27 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58ECB12945B for ; Tue, 25 Oct 2016 03:26:27 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id c78so15493069wme.0 for ; Tue, 25 Oct 2016 03:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4V3QO29lMuI2t1Uj8Pepjl9Aoqmp0fR/JOfTRzJfCRk=; b=nAtKO6ImHOuwHDrnh6qDXXVswdN23eaAyXymmPcY3XUkdjsqFTDA+EJFQ1isCJG/mT /SOsWKNDidXBB8JAtA++leEpSCZ2QampkNLSFXGlys4u6gm3mGFW0Y2FIGzEc0GI21A1 +HodbMkH427MSDb+FDTDWOvYyPPqenLhUswmlKQX8hcUhKhiOxuWomKXZVjQ6aElB2OA eX+ftuw7r7Taj1VBuCGcOhQ03J0ynPWsncEJTNb9KRaPjuVPP/lc98GboYaDdSlduOU+ +bPG5ObDbD7aaLCz56ZkRoH7/1wZZnbifnTT2aHufcAh3uRHRK/p+2AeOZnOcjlfb29B kf2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4V3QO29lMuI2t1Uj8Pepjl9Aoqmp0fR/JOfTRzJfCRk=; b=XEPZNWsOL0wwgcow+MenoBw9Xau23AbTTWDPqZs2ArJ2QCUphVHrjsdqDbx6cp5rnu ZBc84ZrVg1zGmseAlspotMVFMY0epeCTdV6Dsh8ho3oBD/QpUHNNXM+6LV2l/xpJxFBH v2PoMOOunhDbfynjAcjRtbSIUA3em+5LB9OSGbMH1bn2nGjsKgAXRY74nJSoNAnMI2iS FcceMj66D1jT8G4/ULCOGAu4Zly8bgPhyPnZdOxpHckqH7Fmg8hNfnn0zWmkfFXzmLRq UGKZfhTKBsxXSbQjkudDFiU3MkcJFW9N9BbmuQlxXiXGuwIxrYuppR3DY2VEImYUAdNT 43og== X-Gm-Message-State: ABUngvcYnW5IUnKjAadiAwK1mbC0pcneYnXQiYckiHkpW/qx2PEJ+VgVqmhfYyPx61SRn/s6 X-Received: by 10.28.181.65 with SMTP id e62mr2348989wmf.126.1477391185525; Tue, 25 Oct 2016 03:26:25 -0700 (PDT) Received: from 3.6.7.8.3.d.6.0.7.a.4.2.7.8.0.5.a.a.2.e.e.7.a.f.0.b.8.0.1.0.0.2.ip6.arpa (3.6.7.8.3.d.6.0.7.a.4.2.7.8.0.5.a.a.2.e.e.7.a.f.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:fa7e:e2aa:5087:24a7:6d3:8763]) by smtp.gmail.com with ESMTPSA id g142sm2857078wmd.2.2016.10.25.03.26.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 25 Oct 2016 03:26:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Paul Hadfield In-Reply-To: Date: Tue, 25 Oct 2016 11:26:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> To: Tom Ritter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "trans@ietf.org" , Kurt Roeckx Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 10:26:31 -0000 On Oct 19, 2016, at 11:41 PM, Tom Ritter wrote: >=20 > On 19 October 2016 at 15:31, Kurt Roeckx wrote: >> On Wed, Oct 19, 2016 at 02:33:30PM -0500, Tom Ritter wrote: >>> Actions for an auditor to take is a good thing to try and document >>> somewhere. We _could_ put it into Gossip, but it seems like a = separate >>> draft to me. Off the top of my head I think the main things it = would >>> be checking are: >>> - Has the log always issued a STH within the MMD >>=20 >> I didn't look up what the real definition of the MMD is, but what >> I expect is that the time from the SCT being generated until that >> STH being visible is important, not the time the STH is generated. >>=20 >> For instance I only see Digicert's STHs 12 hour later. With Google >> it depends on the log, for Pilot and Aviator it averages around 25 >> minutes, for Rocketeer around 100 minutes. >=20 > Yes, you're right. It's time to get data included (merged) into the > tree after a promise (SCT) had been made. >=20 > I was thinking about it in terms of "Has the log not issued at least > one STH in an X-hour period" which is related to MDD, but not the > exact same. This is an important distinction. For example, during the period where Google=E2=80=99s Aviator log exceeded its MMD, it was still happily = signing its tree so new STHs were being produced =E2=80=A6 but it had got behind = with assigning unique sequence numbers to recently submitted certs, so those certs were not present in the trees that had been signed, and therefore were not reflected by the corresponding STHs. Eventually sequencing caught up and the full backlog of certs was integrated.=20 >=20 >>> - Can I resolve all inputs (SCTs, STHs) into a single STH via >>> inclusion/consistency proofs (to prevent split views) >>=20 >> Which is why I started to collect all that I can see myself. But >> I'm not sure yet if this proposal will let me find all of them, or >> at least all that have been send to someone. >=20 > As an auditor you would want to find all the servers who deploy STH > Pollination or SCT Feedback. [0] Once you do that, and start polling > from them, you'll be doing the best anyone can. >=20 > I'm not sure if there's a non-centralized, scalable way to make such a > list available to people like yourself. I mean obviously someone could > operate a public service and just collect sites that are found via > scanning or self-submitted - and I expect this will happen - but it's > not the sort of thing we'd put in a draft I don't think. >=20 > But we're open to suggestions if you have any particular ideas! This may be too late for 6962-bis: I have been thinking about how an auditor=E2=80=99s task might be easier if Logs were required to retain = their historic STHs and provide them on request. It could be done by adding an API along the lines of =E2=80=98get-sth-at-time=E2=80=99 or = =E2=80=98get-sths-between-times=E2=80=99. (where the first returns the STH with largest timestamp <=3D the = timestamp requested, and the second returns a list of STHs with timestamps in the range requested). Auditors could then retrieve the full STH history of a log without = having to have collected them over an extended period of time or having to exchange them with other auditors - although verifying STHs gathered by other parties is still worthwhile to detect split views. >=20 > -tom >=20 > [0] You could also operate a user-facing 'Trusted Auditor' and feed > your own browsing history into it or convince others to do the same. >=20 From nobody Tue Oct 25 05:30: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 E260C129496 for ; Tue, 25 Oct 2016 05:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 PGm3uH9FWQhs for ; Tue, 25 Oct 2016 05:30:16 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C69E129532 for ; Tue, 25 Oct 2016 05:30:11 -0700 (PDT) Received: (qmail 21460 invoked by uid 1004); 25 Oct 2016 12:30:08 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 25 Oct 2016 13:30:08 +0100 Received: (qmail 23685 invoked by uid 1000); 25 Oct 2016 12:30:08 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 25 Oct 2016 13:30:08 +0100 To: Paul Hadfield , Tom Ritter References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> From: Rob Stradling Message-ID: <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> Date: Tue, 25 Oct 2016 13:30:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "trans@ietf.org" , Kurt Roeckx Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 12:30:20 -0000 On 25/10/16 11:26, Paul Hadfield wrote: > This may be too late for 6962-bis: Maybe. Maybe not. Let's discuss it anyway. :-) I have been thinking about how an > auditor’s task might be easier if Logs were required to retain their > historic STHs and provide them on request. It could be done by adding > an API along the lines of ‘get-sth-at-time’ or ‘get-sths-between-times’. > (where the first returns the STH with largest timestamp <= the timestamp > requested, and the second returns a list of STHs with timestamps in > the range requested). Alternatively, historic STHs could be looked up by historic tree sizes. My suggestion... - add an optional "tree_size" input to get-sth. - if the "tree_size" input is not specified, get-sth behaves as per the current specification (i.e., it returns the very latest STH). - if the "tree_size" input is specified: - the "sth" output contains the latest STH that existed back when the tree was that size. - a "next_tree_size" output is also returned, which an auditor could then specify as the "tree_size" input to a further get-sth call. (The auditor would then call get-sth repeatedly until the "next_tree_size" output is omitted, which would indicate that the very latest STH was just returned). > Auditors could then retrieve the full STH history of a log without having > to have collected them over an extended period of time or having to > exchange them with other auditors Indeed. I think this would be a useful feature. > - although verifying STHs gathered > by other parties is still worthwhile to detect split views. Definitely. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Oct 25 05:58: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 5EFBA129644 for ; Tue, 25 Oct 2016 05:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 cqm5oJFr2j4M for ; Tue, 25 Oct 2016 05:58:00 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986A7129532 for ; Tue, 25 Oct 2016 05:58:00 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id B4813A8A034B; Tue, 25 Oct 2016 12:57:58 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 811AF1FE023E; Tue, 25 Oct 2016 14:57:58 +0200 (CEST) Date: Tue, 25 Oct 2016 14:57:57 +0200 From: Kurt Roeckx To: Rob Stradling Message-ID: <20161025125757.6n5jgfxfx25arocz@roeckx.be> References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> User-Agent: NeoMutt/20160916 (1.7.0) Archived-At: Cc: "trans@ietf.org" , Tom Ritter , Paul Hadfield Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 12:58:02 -0000 On Tue, Oct 25, 2016 at 01:30:08PM +0100, Rob Stradling wrote: > On 25/10/16 11:26, Paul Hadfield wrote: > > > This may be too late for 6962-bis: > > Maybe. Maybe not. Let's discuss it anyway. :-) > > I have been thinking about how an > > auditor’s task might be easier if Logs were required to retain their > > historic STHs and provide them on request. It could be done by adding > > an API along the lines of ‘get-sth-at-time’ or ‘get-sths-between-times’. > > (where the first returns the STH with largest timestamp <= the timestamp > > requested, and the second returns a list of STHs with timestamps in > > the range requested). > > Alternatively, historic STHs could be looked up by historic tree sizes. > My suggestion... You can get multiple signatures for the same tree size / hash currently. Do you want the first. the last, or some random STH in that case? > - if the "tree_size" input is specified: > - the "sth" output contains the latest STH that existed back when > the tree was that size. > - a "next_tree_size" output is also returned, which an auditor could > then specify as the "tree_size" input to a further get-sth call. (The > auditor would then call get-sth repeatedly until the "next_tree_size" > output is omitted, which would indicate that the very latest STH was > just returned). You can already ask for the latest one, not for the size of a previous one. What if there was no STH of that size? Give the larger? The smaller? just the next / prev size? Kurt From nobody Tue Oct 25 06:24: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 6CB2F128B44 for ; Tue, 25 Oct 2016 06:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 04WrYxDZP9B6 for ; Tue, 25 Oct 2016 06:24:02 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2051126D74 for ; Tue, 25 Oct 2016 06:24:01 -0700 (PDT) Received: (qmail 9763 invoked by uid 1004); 25 Oct 2016 13:23:59 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 25 Oct 2016 14:23:59 +0100 Received: (qmail 14172 invoked by uid 1000); 25 Oct 2016 13:23:59 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 25 Oct 2016 14:23:59 +0100 To: Kurt Roeckx References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> <20161025125757.6n5jgfxfx25arocz@roeckx.be> From: Rob Stradling Message-ID: <18ec0b44-446e-bf4b-a94f-1780a40decf0@comodo.com> Date: Tue, 25 Oct 2016 14:23:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161025125757.6n5jgfxfx25arocz@roeckx.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Tom Ritter , "trans@ietf.org" , Paul Hadfield Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 13:24:07 -0000 On 25/10/16 13:57, Kurt Roeckx wrote: > On Tue, Oct 25, 2016 at 01:30:08PM +0100, Rob Stradling wrote: >> On 25/10/16 11:26, Paul Hadfield wrote: >> >>> This may be too late for 6962-bis: >> >> Maybe. Maybe not. Let's discuss it anyway. :-) >> >> I have been thinking about how an >>> auditor’s task might be easier if Logs were required to retain their >>> historic STHs and provide them on request. It could be done by adding >>> an API along the lines of ‘get-sth-at-time’ or ‘get-sths-between-times’. >>> (where the first returns the STH with largest timestamp <= the timestamp >>> requested, and the second returns a list of STHs with timestamps in >>> the range requested). >> >> Alternatively, historic STHs could be looked up by historic tree sizes. >> My suggestion... > > You can get multiple signatures for the same tree size / hash > currently. Do you want the first. the last, or some random STH in > that case? Ah, good point. "In general, there is no need to produce a new STH unless there are new entries in the log; however, in the unlikely event that it receives no new submissions during an MMD period, the log SHALL sign the same Merkle Tree Hash with a fresh timestamp. Please execute "s/tree_size/timestamp/" on my previous post (which makes it functionally equivalent to Paul's get-sth-at-time proposal, except that my proposal merges that API into get-sth). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Tue Oct 25 07:04:25 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 E0C2612966E for ; Tue, 25 Oct 2016 07:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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=-0.431, 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 0Yl_yY3NIIvC for ; Tue, 25 Oct 2016 07:04:19 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66034129541 for ; Tue, 25 Oct 2016 07:03:59 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id f134so48333633lfg.2 for ; Tue, 25 Oct 2016 07:03:59 -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=GJ/GEFSSvTERQO+b7kNoEyJv0KOGnJQ6l3E1ULk6ZEE=; b=aelSkytr4XxH9z3LrnmPpITzrRkJ3PVnguMdFmE7sUvSoIEEJYJoyzwh+G//KFkTrS RYJ3WbLtLyCgAaxRXscHfNoc0SYjAR7HY+i6Xh1yZ5Q+zXtLagyG/jgp2BfjlncoAzkz owV5WmJ8PVCTKhdiPvg6JrUNnW9S0s3kD4OHApeHuygPjtPY2cOw0bIgoQ+k9oZgtFmZ CI4JFJp4Ont24Z/I+7qyCiHxsNQIUJo0CCBYlA9Sk6cn4Pp4CM8odqboyoHeKDnXhxm3 YrA9vorx+h8d9IgMGut2nFZEXT4AqBZg49yf7FMbv8wc2Yaqstr4oxG1rp7+sVS4UCeI JTLA== 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=GJ/GEFSSvTERQO+b7kNoEyJv0KOGnJQ6l3E1ULk6ZEE=; b=WipxxiXit/NtAKiQFtGj0uWis1QNJbzAgR/CSAmrr7SE6wO4qqlyV1CQ2VeMoNeZXk PzOjh5XKw7LAhKrWemnNoofIKV8yRAXdOvgr8UswiM0miU+wtTtuqgJKJ01Kp0dKhRfq rG2r4ym2j6Dbl8M2OcFyW9zlXwZf1EHOZ5ql4+zJHuLY1F916t2nQGIkR+m0wmrJvIoP KqGaUx+vwFZnmRG/CsvusF08c0pgF4lVOqZcJ8qORoKg/RugywuR4Pqmlz3hyHUbjK+d /gWKsGs/XdFLlgfWgxifFvyJjkPqVZVVnXv77ly8E1L0ZTqUP7utn9l69ntsZjTv615V apzQ== X-Gm-Message-State: ABUngvdYWIKjroySCnwqOG//PdA2yQsW/j5jwjMnk/GD37C4weIOJVYv5AhMg/YgREjmXFy/8+zWylZkgDvib221 X-Received: by 10.25.150.15 with SMTP id y15mr10776417lfd.58.1477404237360; Tue, 25 Oct 2016 07:03:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.221.8 with HTTP; Tue, 25 Oct 2016 07:03:56 -0700 (PDT) In-Reply-To: <18ec0b44-446e-bf4b-a94f-1780a40decf0@comodo.com> References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> <20161025125757.6n5jgfxfx25arocz@roeckx.be> <18ec0b44-446e-bf4b-a94f-1780a40decf0@comodo.com> From: Paul Hadfield Date: Tue, 25 Oct 2016 15:03:56 +0100 Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=001a11402478c24e2c053fb0fa42 Archived-At: Cc: Tom Ritter , "trans@ietf.org" , Kurt Roeckx Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 14:04:24 -0000 --001a11402478c24e2c053fb0fa42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2016 at 2:23 PM, Rob Stradling wrote: > > > On 25/10/16 13:57, Kurt Roeckx wrote: > > On Tue, Oct 25, 2016 at 01:30:08PM +0100, Rob Stradling wrote: > >> On 25/10/16 11:26, Paul Hadfield wrote: > >> > >>> This may be too late for 6962-bis: > >> > >> Maybe. Maybe not. Let's discuss it anyway. :-) > >> > >> I have been thinking about how an > >>> auditor=E2=80=99s task might be easier if Logs were required to retai= n their > >>> historic STHs and provide them on request. It could be done by addin= g > >>> an API along the lines of =E2=80=98get-sth-at-time=E2=80=99 or > =E2=80=98get-sths-between-times=E2=80=99. > >>> (where the first returns the STH with largest timestamp <=3D the > timestamp > >>> requested, and the second returns a list of STHs with timestamps in > >>> the range requested). > >> > >> Alternatively, historic STHs could be looked up by historic tree sizes= . > >> My suggestion... > > > > You can get multiple signatures for the same tree size / hash > > currently. Do you want the first. the last, or some random STH in > > that case? > > Ah, good point. > > "In general, there is no need to produce a new STH unless > there are new entries in the log; however, in the unlikely event that > it receives no new submissions during an MMD period, the log SHALL > sign the same Merkle Tree Hash with a fresh timestamp. > > Please execute "s/tree_size/timestamp/" on my previous post (which makes > it functionally equivalent to Paul's get-sth-at-time proposal, except > that my proposal merges that API into get-sth). > > Yes, I suggested get-sth-by-timestamp for that reason. It's not at all uncommon for some of the smaller logs, or logs which are quite new and not widely used, to go through one or more signings with no tree growth. Merging get-sth-at-timestamp into get-sth, with an optional parameter, makes sense. What about get-sths-between-times? It's not just an optimisation: without it. a client wanting to ingest all a log's historic STHs has to pick some time interval and then issue a range of probing calls. They cannot be sure not to have missed an STH somewhere. (Although the optimisation is worthwhile: Aviator for example has O(45k) historic STHs) > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > sender by replying to the e-mail containing this attachment. Replies to > this email may be monitored by COMODO for operational or business > reasons. Whilst every endeavour is taken to ensure that e-mails are free > from viruses, no liability can be accepted and the recipient is > requested to use their own virus checking software. > --001a11402478c24e2c053fb0fa42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 25, 2016 at 2:23 PM, Rob Stradling <rob.stradling@comodo.co= m> wrote:


On 25/10/16 13:57, Kurt Roeckx wrote:
> On Tue, Oct 25, 2016 at 01:30:08PM +0100, Rob Stradling wrote:
>> On 25/10/16 11:26, Paul Hadfield wrote:
>> <snip>
>>> This may be too late for 6962-bis:
>>
>> Maybe.=C2=A0 Maybe not.=C2=A0 Let's discuss it anyway.=C2=A0 := -)
>>
>>=C2=A0 =C2=A0I have been thinking about how an
>>> auditor=E2=80=99s task might be easier if Logs were required t= o retain their
>>> historic STHs and provide them on request.=C2=A0 It could be d= one by adding
>>> an API along the lines of =E2=80=98get-sth-at-time=E2=80=99 or= =E2=80=98get-sths-between-times=E2=80=99.
>>> (where the first returns the STH with largest timestamp <= =3D the timestamp
>>> requested, and the second returns a list of STHs with timestam= ps in
>>> the range requested).
>>
>> Alternatively, historic STHs could be looked up by historic tree s= izes.
>> My suggestion...
>
> You can get multiple signatures for the same tree size / hash
> currently. Do you want the first. the last, or some random STH in
> that case?

Ah, good point.

=C2=A0 "In general, there is no need to produce a new STH unless
=C2=A0 =C2=A0there are new entries in the log; however, in the unlikely eve= nt that
=C2=A0 =C2=A0it receives no new submissions during an MMD period, the log S= HALL
=C2=A0 =C2=A0sign the same Merkle Tree Hash with a fresh timestamp.

Please execute "s/tree_size/timestamp/" on my previous post (whic= h makes
it functionally equivalent to Paul's get-sth-at-time proposal, except that my proposal merges that API into get-sth).

Yes, I suggested get-sth-by-timestamp for that reason= .=C2=A0 It's not at all uncommon
for some of the smaller logs= , or logs which are quite new and not widely used, to
go through = one or more signings with no tree growth.

Merging = get-sth-at-timestamp into get-sth, with an optional parameter, makes sense.=

What about get-sths-between-times?=C2=A0 It's= not just an optimisation: without it. a client
wanting to ingest= all a log's historic STHs has to pick some time interval and then
issue a range of probing calls.=C2=A0 They cannot be sure not to have= missed an STH
somewhere.

(Although the = optimisation is worthwhile: Aviator for example has O(45k) historic STHs)

=C2=A0
<snip>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.= comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
=C2=A0 3rd Floor, 26 Office Village, Exchange Quay,
=C2=A0 Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are addressed.=C2=A0 If you have received this email in error please notify the=
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

--001a11402478c24e2c053fb0fa42-- From nobody Tue Oct 25 07:11:26 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 2EECC1294EE for ; Tue, 25 Oct 2016 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 oisj18MFnVWY for ; Tue, 25 Oct 2016 07:11:22 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE72E129579 for ; Tue, 25 Oct 2016 07:10:59 -0700 (PDT) Received: (qmail 683 invoked by uid 1004); 25 Oct 2016 14:10:57 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 25 Oct 2016 15:10:57 +0100 Received: (qmail 7235 invoked by uid 1000); 25 Oct 2016 14:10:57 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 25 Oct 2016 15:10:57 +0100 To: Paul Hadfield References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> <20161025125757.6n5jgfxfx25arocz@roeckx.be> <18ec0b44-446e-bf4b-a94f-1780a40decf0@comodo.com> From: Rob Stradling Message-ID: <9f52bcdf-2812-c98f-1560-ffeca93249e3@comodo.com> Date: Tue, 25 Oct 2016 15:10:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Tom Ritter , "trans@ietf.org" , Kurt Roeckx Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 14:11:25 -0000 On 25/10/16 15:03, Paul Hadfield wrote: > What about get-sths-between-times? It's not just an optimisation: > without it. a client wanting to ingest all a log's historic STHs has to > pick some time interval and then issue a range of probing calls. > They cannot be sure not to have missed an STH somewhere. > > (Although the optimisation is worthwhile: Aviator for example has O(45k) > historic STHs) Hmmm, good point. I agree that it would be useful to have an API that returns all STHs within a specified time range. I think it could be called simply "get-sths", with the "-between-times" aspect made obvious by the names of the inputs to the API. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Oct 25 07:12: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 0D6E012962C for ; Tue, 25 Oct 2016 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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=-0.431, 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 L0KfMDNz6ZLQ for ; Tue, 25 Oct 2016 07:12:15 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 926111294EE for ; Tue, 25 Oct 2016 07:12:14 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id b81so204390675lfe.1 for ; Tue, 25 Oct 2016 07:12:14 -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=KvE7/9iEx4gmrY6J0YtjMr5k+YxEs2Ka79I0DKJNPnk=; b=DshIyi+KniVwJgEi0StWq/AK6q9OLRXmYuGtWk6+FL4VxYoY+2RSgiesAfE8WdjGjC Pd7bi+wyBIczR/5Z+g2LDiN8kSL+uxtdkFm0LkI9fFAM6kUeHhvs8brG2/unMuJkL1F8 IQMyw27CkY0H7iyt05mZSh3Y8sSSwNaP1hCVkw6IIm0FF0CGxaZugbnLcyRIw2anM8pW doLH2d4fzzhUWrZS0NZDWqE3ifSkwv/iLVAOOtbHfZpDvkoD7Eb7bl63/TGdN4G4HtBZ 0k5Xug5VQQIua0n11TGcwQuQZQ5/f3cHGRVx5IB9tUomwyWPsgzmaYyjXznE3fXnOQ3G Q1UA== 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=KvE7/9iEx4gmrY6J0YtjMr5k+YxEs2Ka79I0DKJNPnk=; b=A79c/r5SHU3A9Mq1P5CjMYbPFHZ3zVOLn6cjngmCoiFQsEktHZMzJKUykmkqvoDttr BwEylOZUknLJvNjwSDkPPTDH59yMlDsbq/wYfpdPxoTzxapk5Rpn/qRs/dw0iZzNz3nG lnquXP04i8STjrUVbSWSxttaibACFBdcZ+kH6I53hzL90jp0RCx2JSnA9kWerIU87V+t 8N2ZmIyM++ir0lR4NRbKDND1RleLl0oiWkCLma5BKvox3CwFZIfy8Iw9GxW8Qdk4AU9P FcUwUYRGu3RjoPW0BSZUbD+bDP/Z1TAsNc0yvPAs1pTNVwrgPWpOOHu4/tsN5LdXY+Ea Y6GA== X-Gm-Message-State: ABUngvdFQdvbmUATV/HlL1icuGmP4gK9Of9FuDrLAx5r/mK15e7KgQHUukhPXsZG0jtvTBvu91SvhXKgdI+IRaw+ X-Received: by 10.25.150.15 with SMTP id y15mr10803943lfd.58.1477404732508; Tue, 25 Oct 2016 07:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.221.8 with HTTP; Tue, 25 Oct 2016 07:12:11 -0700 (PDT) In-Reply-To: <9f52bcdf-2812-c98f-1560-ffeca93249e3@comodo.com> References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> <20161025125757.6n5jgfxfx25arocz@roeckx.be> <18ec0b44-446e-bf4b-a94f-1780a40decf0@comodo.com> <9f52bcdf-2812-c98f-1560-ffeca93249e3@comodo.com> From: Paul Hadfield Date: Tue, 25 Oct 2016 15:12:11 +0100 Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=001a1140247845a79d053fb118f6 Archived-At: Cc: Tom Ritter , "trans@ietf.org" , Kurt Roeckx Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 14:12:19 -0000 --001a1140247845a79d053fb118f6 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 25, 2016 at 3:10 PM, Rob Stradling wrote: > On 25/10/16 15:03, Paul Hadfield wrote: > > > What about get-sths-between-times? It's not just an optimisation: > > without it. a client wanting to ingest all a log's historic STHs has to > > pick some time interval and then issue a range of probing calls. > > They cannot be sure not to have missed an STH somewhere. > > > > (Although the optimisation is worthwhile: Aviator for example has O(45k) > > historic STHs) > > Hmmm, good point. I agree that it would be useful to have an API that > returns all STHs within a specified time range. I think it could be > called simply "get-sths", with the "-between-times" aspect made obvious > by the names of the inputs to the API. > > Sounds fair enough. Naming things is hard :) Implementations may want to limit the number of STHs they return, similarly to get-entries. > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > --001a1140247845a79d053fb118f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 25, 2016 at 3:10 PM, Rob Stradling <rob.stradling@comodo.co= m> wrote:
On 25/10/16 15:03= , Paul Hadfield wrote:
<snip>
> What about get-sths-between-times?=C2=A0 It's not= just an optimisation:
> without it. a client wanting to ingest all a log's historic STHs h= as to
> pick some time interval and then issue a range of probing calls.
> They cannot be sure not to have missed an STH somewhere.
>
> (Although the optimisation is worthwhile: Aviator for example has O(45= k)
> historic STHs)

Hmmm, good point.=C2=A0 I agree that it would be useful to have an A= PI that
returns all STHs within a specified time range.=C2=A0 I think it could be called simply "get-sths", with the "-between-times" asp= ect made obvious
by the names of the inputs to the API.

S= ounds fair enough.=C2=A0 Naming things is hard :)
Implementations= may want to limit the number of STHs they return, similarly
to g= et-entries.=C2=A0
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


--001a1140247845a79d053fb118f6-- From nobody Tue Oct 25 07:53:16 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 8733312968B for ; Tue, 25 Oct 2016 07:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvGXyOaYQgWA for ; Tue, 25 Oct 2016 07:53:14 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885261295EA for ; Tue, 25 Oct 2016 07:53:14 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 2A988C008644 for ; Tue, 25 Oct 2016 07:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=QkriXkBIPmAr6PVlYVUtgHYsW+k=; b= Z43ovg3gEdzABsL2UQfM5fx97r7kROCwkNKwwGYoa3p+LevYbJp7Cjgp8jTwg8RS Pj9CzAVPauCZk1mYgKhJQz7nWmkpL3HQSuOtLK5fZKYwgosoGUvavbiGYFanp+P8 GXfYRkB3nlVEc7ryltIc0D2wdSSHGIXkj4SMcHJbmdE= Received: from mail-yb0-f176.google.com (mail-yb0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 0FC5FC008640 for ; Tue, 25 Oct 2016 07:53:14 -0700 (PDT) Received: by mail-yb0-f176.google.com with SMTP id f133so868616ybc.3 for ; Tue, 25 Oct 2016 07:53:14 -0700 (PDT) X-Gm-Message-State: ABUngvdzDFsTCZjaEs1RXE2CTQ0CJvYgJIUzMr6DWGzLn0UVFLJDcLKHGd1KJj6NNnLWOoKEfuxIpTpNGGiaBg== X-Received: by 10.37.92.7 with SMTP id q7mr19538512ybb.185.1477407193265; Tue, 25 Oct 2016 07:53:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.245.193 with HTTP; Tue, 25 Oct 2016 07:53:12 -0700 (PDT) In-Reply-To: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> From: Ryan Sleevi Date: Tue, 25 Oct 2016 07:53:12 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Melinda Shore Content-Type: multipart/alternative; boundary=001a1140f838f18435053fb1aa2c Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality 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, 25 Oct 2016 14:53:15 -0000 --001a1140f838f18435053fb1aa2c Content-Type: text/plain; charset=UTF-8 On Monday, October 24, 2016, Melinda Shore wrote: > Hi, all: > > You may have seen the recent announcement from the Chrome > team that as of October 2017 certificates will need to comply > with Chrome's CT policy in order to be trusted. There was > also an invitation to discuss that on the trans mailing list. > This is a reminder that mailing list discussions need to > remain focused on the specifications being produced by the > working group - that is to say, policies related to > individual implementations are out of scope for the working > group except to the extent that they bear on decisions related > to our working group drafts. > > Many thanks, > > Paul and Melinda > > Apologies for that - in every message but the one posted here, I encouraged people to discuss the policies on ct-policy@chromium.org, but that any use cases or concerns with the technical means should be brought to IETF. To that end, there was some discussion in person during the CA/Browser Forum's F2F (scheduled before we made the announcement) that attempted to explore various use cases for forms of redaction within certificates; information that CAs and site operators felt that transparency would be harmful, rather than helpful. As soon as the minutes become public, my hope is that further conversation about use cases for redaction will be channeled here, so that it may be used to assist in the production and work on a redaction draft that tries to capture these, as well as explore possible technical solutions. In the event the WG cannot find consensus on technical solutions, or for which the tradeoffs are seen as too large, or too specific to the Web PKI, then I think it is something to explore addressing via policy solutions, and the conversation migrates to either via ct-policy@chromium.org if they're specific to Chrome's plans, or public@cabforum.org if there are specific solutions to explore. I mention all of this to echo support for avoiding a discussion of browser policy, or CA policy, on this list, except to the extent it affects the technical discussions being noted here. --001a1140f838f18435053fb1aa2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, October 24, 2016, Melinda Shore <melinda.shore@gmail.com> wrote:
Hi, all:

You may have seen the recent announcement from the Chrome
team that as of October 2017 certificates will need to comply
with Chrome's CT policy in order to be trusted.=C2=A0 There was
also an invitation to discuss that on the trans mailing list.
This is a reminder that mailing list discussions need to
remain focused on the specifications being produced by the
working group - that is to say, policies related to
individual implementations are out of scope for the working
group except to the extent that they bear on decisions related
to our working group drafts.

Many thanks,

Paul and Melinda


Apologies for that - in every message but = the one posted here, I encouraged people to discuss the policies=C2=A0on ct-policy@chromium.org, but tha= t any use cases or concerns with the technical means should be brought to I= ETF.

To that end, there was some discussion in person d= uring the CA/Browser Forum's F2F (scheduled before we made the announce= ment) that attempted to explore various use cases for forms of redaction wi= thin certificates;=C2=A0information that CAs and site operators felt that t= ransparency would be harmful, rather than helpful. As soon as the minutes b= ecome public, my hope is that further conversation about use cases for reda= ction will be channeled here, so that it may be used to assist in the produ= ction and work on a redaction draft that tries to capture these, as well as= explore possible technical solutions. In the event the WG cannot find cons= ensus on technical solutions, or for which the tradeoffs are seen as=C2=A0t= oo large, or too specific to the Web PKI,=C2=A0then I think it is something= to explore addressing via policy solutions, and the conversation migrates = to=C2=A0either via ct-policy@chro= mium.org if they're specific to Chrome's plans, or public@cabforum.org if there are specific so= lutions to explore.

I mention all of this to echo suppor= t for avoiding a discussion of browser policy, or CA policy, on this list, = except to the extent it affects the technical discussions being noted here.=
--001a1140f838f18435053fb1aa2c-- From nobody Tue Oct 25 08:28:26 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 EE8EE12969A for ; Tue, 25 Oct 2016 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 n0lUyiqZnAE0 for ; Tue, 25 Oct 2016 08:28:23 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 3573A12968C for ; Tue, 25 Oct 2016 08:28:23 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id h65so1560568ybb.7 for ; Tue, 25 Oct 2016 08:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=WYW3198cqVupGF7LUIsoDs7l2iJ5lumbWR6zglpB0mU=; b=lZyfcT0kvDqgoZpUKcD7MVYimkOq0x6ku7BG2lIaI+DvxW3FQZmB6UbzKQtQLdugmY PKsms2pHp6/5ESPuPvLGXL9/UtbP43hocNYV/zhQVCmw4iHtBuFLIUDzBIUQ/mdnw+mg 4WDXSQrPriqLB8s7uUL/VTMxi7X9/zIzE4pFYT/9/2ayIjo2gTBrEexNUX8f/OT9pHa5 zJ0f82kRQ/tNjjeqriGCd5GhsRSGzeOXQF9tZlRjgIy7RthRAe2xVHXYhfy0zvawkQPq ZSuXxJWIO+E3HtUvmafqET+I9qMZvukK4HCRh7usKCHkMNVCi94EmycODN6wj7bchzZ/ Yvig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=WYW3198cqVupGF7LUIsoDs7l2iJ5lumbWR6zglpB0mU=; b=eMiSPJVn2eUFp9hT3UfVejEHzyzKNsuEiZMtYawhpTMv++7rM79K2Ap5KJ86ZwBSy9 oJc8VoVWDMXkLhJytknIa1jKEVdh4311UjGGOaN4VNQPKkFtqTlOqTxeGunUwwp8dj28 KzooP14JiYqcf2TfGCgLJvUxFt5o5f+5gOfhs61sRc9ajYlwe/hHpJKer3j7ZzrUaU3s gVsFJh4EwPVCN6zBLTLAUpGFRGmex3c1ovrUPpIgi+l+7ZVAv/J31COLUqi2LC+E2Nf4 Im/MtZ5IlI2r8aMk8Y5gVgkKXGdbvQ/Fj2t/XOW1N3buYoo94SQdpHDpGzKlEaG1KTPd T11Q== X-Gm-Message-State: ABUngvcnZWxvvWUAqvSl6ojlmxHCeRMq8a7WeMyDJwp/d49Ostvx4TxDN6pIvKAbWSbXHcG4niWhu43oguKT4Q== X-Received: by 10.107.184.137 with SMTP id i131mr16493859iof.167.1477409302145; Tue, 25 Oct 2016 08:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Tue, 25 Oct 2016 08:28:21 -0700 (PDT) From: Peter Bowen Date: Tue, 25 Oct 2016 08:28:21 -0700 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Trans] Privacy and Transparency 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, 25 Oct 2016 15:28:25 -0000 Ryan Sleevi mentioned there was a discussion about CT at the CA/Browser Forum meeting last week. While the minutes are not yet published, I have posted the a set of slides based on the ones I presented at the Forum. They are available at http://www.slideshare.net/pzb/balancing-customer-privacy-with-transparency The original set of slides was intended to kick off a discussion; the version I posted has some updates based on the discussion. The most notable parts, in my opinion, are related to reasons people want privacy instead of full transparency: * Binding of domain name to corporate entity (domain name uses proxy registration) * PII in certain certificate types (Qualified?) * Overly descriptive labels in FQDNs (provides a blueprint of network topol= ogy) * Disclosure of confidential projects (e.g. newthing.example.com or fordacquisition.gm.com) =E2=80=93 may become public at a future point From nobody Tue Oct 25 10:39: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 2D768129880 for ; Tue, 25 Oct 2016 10:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 1vxBktRadGqb for ; Tue, 25 Oct 2016 10:39:36 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C47F129883 for ; Tue, 25 Oct 2016 10:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1477417175; bh=3EbC0M9ZhI5phYiiEJs59PpM4BHTIwotIIWRmxRDnV4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=F60/7ftxhNlWap8L6XUmgQFVPbcobyb7e+2nygrht6vcOHKJbTm6gjA9nldX2QKkl utpe+Agt7q49YopOjIKBjpzTQknPLbkDpcF6CpBsJVHoZXuvoyGQ4e7se0rVmVEMGB NwrCiyl+37/vI5bAPz8X03eNHTYuk7B8Uc0paaZ3LA/aW61vLeSdkbIl5ld1yVRYgR TxItHnQfT8Qwd0PICemzMg9ReXiKqulFhd61nrK6Jqgz1e7lkBhz/6t23kHDGHLaIf my9uyOKWtday16riQC/iHpwUkiamOA7AVby3LTmoU2muJjo5D6XkX3YoYBfWjjwVYE tWMRVoscP96WQ== Date: Tue, 25 Oct 2016 10:34:56 -0700 From: Andrew Ayer To: Rob Stradling Message-Id: <20161025103456.8165da789055e2d32b153689@andrewayer.name> In-Reply-To: <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 17:39:37 -0000 On Tue, 25 Oct 2016 13:30:08 +0100 Rob Stradling wrote: > > Auditors could then retrieve the full STH history of a log without > > having to have collected them over an extended period of time or > > having to exchange them with other auditors > > Indeed. I think this would be a useful feature. +1 Regards, Andrew From nobody Tue Oct 25 10:39:46 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 6579F129880 for ; Tue, 25 Oct 2016 10:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 pQghBiA4bSFq for ; Tue, 25 Oct 2016 10:39:36 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E94129888 for ; Tue, 25 Oct 2016 10:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1477417176; bh=R+LYM5R596E9O0DJOuqDhs7V665Qi2DAEjMYnfUDLBg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=jarmwBmiFaiiur/bx0Hz8kAg33tmwxYada05mnkvXcLR+zAFbkh/zH4atC9AbjIuQ DNSRrk2Zv8ry6O90gtjX5Dktrpydgb5P6FhFeaGhP+Y8OV0p8apVUHPoA35SjJ7me1 Qb6TTGlBeOVeQ+SDSkv7uILTjhQHTTAejlKwqMgcFiJ4G9O3G2OOXAYoEVA6pUk6VN 7aw9sOnAGE6+QTpppZFWZqIq0sTjDzKGYIWZoEVmX0W7TIu/JFGzxjlnaYJxHor+00 2wXHut1doVuVfCWXRuRVf/faKfbXIAArF3VvZg+pSAWl7IDBWQECu6KSLkjg71DuTb Ns6mNxA31Ib8w== Date: Tue, 25 Oct 2016 10:36:52 -0700 From: Andrew Ayer To: Rob Stradling Message-Id: <20161025103652.da027f9a7ebeb06eb42c358b@andrewayer.name> In-Reply-To: References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> <557B1834.8040706@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Log Monitoring API 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, 25 Oct 2016 17:39:38 -0000 On Thu, 6 Oct 2016 16:21:59 +0100 Rob Stradling wrote: > Now we've completed WGLC for 6962-bis, I'd like to pick this thread > back up again. > > Several different public CT monitoring services now exist (crt.sh, > Cert Spotter, Censys.io, etc). ISTM that it would be useful to > define a common API that could be implemented by each monitor, so > that end-users don't have to implement multiple APIs in order to talk > to multiple monitors. > > Matt Palmer and I made a start on a (very drafty) draft a while ago: > https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palmer-ct-monitor-api.md > > Who's interested in working on this? Count me in. Regards, Andrew From nobody Tue Oct 25 14:22:42 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 850B212988A for ; Tue, 25 Oct 2016 14:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 oh1MpS9kXmWj for ; Tue, 25 Oct 2016 14:22:38 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D271296B4 for ; Tue, 25 Oct 2016 14:22:38 -0700 (PDT) Received: (qmail 25227 invoked by uid 1004); 25 Oct 2016 21:22:35 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 25 Oct 2016 22:22:35 +0100 Received: (qmail 5954 invoked by uid 1000); 25 Oct 2016 21:22:35 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 25 Oct 2016 22:22:35 +0100 To: Tarah Wheeler References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> From: Rob Stradling Message-ID: <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> Date: Tue, 25 Oct 2016 22:22:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 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, 25 Oct 2016 21:22:41 -0000 On 23/09/16 20:04, Tarah Wheeler wrote: > I will co-author the redaction RFC. Hi Tarah. Have you had any further thoughts on this since the call for adoption a month ago? After the discussion at the CABForum F2F last week, it seems that redaction is going to be a hot topic in Seoul. So I'm just wondering if there are any updates worth doing to draft-strad-trans-redaction before the draft cut-off date (Monday 31st Oct) that might facilitate the discussions. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Oct 25 16:44:14 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 17EAC129673 for ; Tue, 25 Oct 2016 16:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, 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 MZ-DIEBfeR4l for ; Tue, 25 Oct 2016 16:44:12 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D1D12956B for ; Tue, 25 Oct 2016 16:44:11 -0700 (PDT) X-AuditID: 1209190f-effff7000000048a-ae-580fee492353 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6D.43.01162.94EEF085; Tue, 25 Oct 2016 19:44:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u9PNi8dl024117; Tue, 25 Oct 2016 19:44:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u9PNi4S0020784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2016 19:44:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u9PNi44F010547; Tue, 25 Oct 2016 19:44:04 -0400 (EDT) Date: Tue, 25 Oct 2016 19:44:04 -0400 (EDT) From: Benjamin Kaduk To: Rob Stradling In-Reply-To: <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> Message-ID: References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrOv1jj/C4MJOPou/K+QtFjUuZrVY +/giiwOzx6Ulsxk9liz5yeTx96NAAHMUl01Kak5mWWqRvl0CV8axi3YFn1gq1m76wd7A+JK5 i5GTQ0LAROLpiVNMXYxcHEICbUwS99d0MkI4Gxkl1q0+wwbhHGKSmNpwjRnCaWCU+DBzOitI P4uAtsTCo9uZQGw2ARWJmW82AnVwcIgI6Ejsus0GEmYWcJbYtu0cC4gtDFSy58lbdhCbU8BO 4uDPS2DlvAIOEtvfyUOMv8wksfDhfLCRokBjVu+fAtbLKyAocXLmExaImVoSy6dvY5nAKDAL SWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFuiZ6uZkleqkppZsYwQEqyb+DcU6D9yFG AQ5GJR7eHen8EUKsiWXFlbmHGCU5mJREeY/fBwrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4e17 A5TjTUmsrEotyodJSXOwKInz/nf7Gi4kkJ5YkpqdmlqQWgSTleHgUJLglX4L1ChYlJqeWpGW mVOCkGbi4AQZzgM0nAukhre4IDG3ODMdIn+KUZdjwY/ba5mEWPLy81KlxHnDQS4QACnKKM2D mwNOLLuZVF8xigO9JcxbCTKKB5iU4Ca9AlrCBLREMJ4HZElJIkJKqoFR43PL18efit68ZprC mbR7ps6EinUqPbJi6wovNW65uvSDRWxag1h1tEXQ0Ql7ZHPWP021s6zxrJm9a9Lc1hvz0rZJ 2fLP7F/59f6zv4snJbzS1PnOLm+9NGBSolGVto/vp4gqhgvWpxOWfk9ftffLtirxPeJLfviI yLZ/XqN3lqPq6sOyTxEXlFiKMxINtZiLihMBPa433AcDAAA= Archived-At: Cc: "trans@ietf.org" , Kurt Roeckx Subject: Re: [Trans] Gossip protocol 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, 25 Oct 2016 23:44:13 -0000 On Tue, 25 Oct 2016, Rob Stradling wrote: > > > Auditors could then retrieve the full STH history of a log without having > > to have collected them over an extended period of time or having to > > exchange them with other auditors > > Indeed. I think this would be a useful feature. It does seem like a useful feature, yes. But that utility should probably be weighed against the added cost for the log operator, which now has to retain STH history and provide code to service the new requests. That extra cost is probably not very large, but it would nice to have other opinions confirming that. -Ben From nobody Wed Oct 26 07:36:36 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 3F52F129436 for ; Wed, 26 Oct 2016 07:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 Mkws6Qb0K0Jp for ; Wed, 26 Oct 2016 07:36:31 -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 9B79F1293FF for ; Wed, 26 Oct 2016 07:36:31 -0700 (PDT) Received: from localhost ([::1]:55325 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bzPJb-0007bD-So; Wed, 26 Oct 2016 07:36:27 -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, rob.stradling@comodo.com, paul@nohats.ca X-Trac-Project: trans Date: Wed, 26 Oct 2016 14:36:27 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/159#comment:2 Message-ID: <078.55d847e7ec3c822a4cbea44a9879396c@tools.ietf.org> References: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, paul@nohats.ca, 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: <20161026143631.9B79F1293FF@ietfa.amsl.com> Resent-Date: Wed, 26 Oct 2016 07:36:31 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #159 (rfc6962-bis): Missing step in "Verifying an inclusion proof" 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, 26 Oct 2016 14:36:35 -0000 #159: Missing step in "Verifying an inclusion proof" Comment (by paul@nohats.ca): Please resolve the issue and put a new version of the document out, -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- robpercival@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Oct 26 09:07:49 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 E157A1296AD for ; Wed, 26 Oct 2016 09:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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=-0.431, 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 i7gzo_Ejnj0e for ; Wed, 26 Oct 2016 09:07:42 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5BD129600 for ; Wed, 26 Oct 2016 09:07:42 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id m193so9393117lfm.4 for ; Wed, 26 Oct 2016 09:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=puEiYG6Hjd8sACe36z+XXNhR2kQstUFkCIxRPwQObRk=; b=WNRY+rFngvtsIShEZPiC89YPnndtjQ8mfP9/GZa2GYqX9TXgWik/TQwk94c2xp4l/E vZU+lUTaUs4Bj+iGni1DYJO4QwMeDHCo2JgbDy3XtacpuT7xBIYuEZtD3URzcApWkp5y L8Z4Med5AoaEgVTkCNDJf5MMc7Wub0+Sf6SbNB1hEpsFmhg+LWSS0aPU+CpkjMfN4i+l xeAya2qBW70dm8E4txGz9eaeCOTFvRrg7S1TBhWtREc1Ywz78oYy68qWpOJ2NoHi118q LgELYVwSOyu9QS9AbXzl/hP2T3LGBsi90LpMJmRav/RwV5qYuXuOj7alk4QEaai0R0sx zA0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=puEiYG6Hjd8sACe36z+XXNhR2kQstUFkCIxRPwQObRk=; b=h6NFUJmVU9pRxqSr+QaV7AbQzKdxX5IczOn0+SFT1n7D2kJw7bEX3Mm26K26A4/nLp cVGzG+rYPVBCHT5OwfM06iBY1sA7jxyMG1jn1E4HmH7h8NN5p4CS6SnE1klZW80Qy2eJ 0PBGI4WwoOjypctMWc4GX+0XwSTCoc2jGjSGSfXud8a/KbzidSJTeQKf4UPONtjJ/XEi 5p5HxPWf30vpnTHwxns876mJNL9tn0q/ieIqcNJOvqzADu0x1tWoZplBys7DsFx3flJS cTCx9qgmEWoESCoFInsWx7btrdtJrb3lYmPM4kWHrVucz2XAOao6J/3fGsIRUMRIxxqB YkIw== X-Gm-Message-State: ABUngvctrblKsRMl+pdFTY00GPuXF4WEhhKwmc+IeCeCxgL7sXBFd7adikNBnHOGmLJbRzzKn5H8wCuEpNlT01Us X-Received: by 10.25.125.84 with SMTP id y81mr2166539lfc.37.1477498059916; Wed, 26 Oct 2016 09:07:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.221.8 with HTTP; Wed, 26 Oct 2016 09:07:39 -0700 (PDT) From: Paul Hadfield Date: Wed, 26 Oct 2016 17:07:39 +0100 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary=001a114b1a4404e247053fc6d3d2 Archived-At: Subject: [Trans] Improving get-entries 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, 26 Oct 2016 16:07:49 -0000 --001a114b1a4404e247053fc6d3d2 Content-Type: text/plain; charset=UTF-8 Hi trans, I'd like to put forward ideas I've had about the /ct/v1/get-entries API. These are based on experiences we've had running Google's CT Monitor. The current API looks something like: req: GET /ct/v1/get-entries?start=10&end=14 resp: { "entries":[ {"leaf_input: "...", "extra_data": "..."}, {"leaf_input: "...", "extra_data": "..."}, {"leaf_input: "...", "extra_data": "..."}, {"leaf_input: "...", "extra_data": "..."}, {"leaf_input: "...", "extra_data": "..."} ] } When the log being audited functions compliantly, this is fine. The client assumes that the 5 entries returned are [10..14] as requested, and this is borne out by eventually computing a tree root-hash that matches the log's STH. The shortcomings become apparent when monitoring a log that misbehaves. Assuming the client receives valid, well-formed JSON, there's one class of bad response that immediately looks wrong: where the number of entries returned exceeds the number requested. Logs are at liberty to return fewer entries than requested. So any other invalid get-entries response is only apparent when the tree's root hash doesn't match that in the STH. The client is unable to determine anything more about what fault was present in the log's response, until after retrying it notices the response change (perhaps the log operator has fixed a bug in the log software). A monitor that is fetching the range of entries from STHn-1 to STHn often must paginate over the range; if STH validation fails in that case there are then multiple responses to consider when trying to work out where a log returned invalid data. My proposal is to modify the response structure to include entry indices. I can think of two ways to do so: req: GET /ct/v2/get-entries?start=10&end=14 resp: { "entries":[ {"index": 10, "leaf_input: "...", "extra_data": "...", "sct": "..."}, {"index": 11, "leaf_input: "...", "extra_data": "...", "sct": "..."}, {"index": 12, "leaf_input: "...", "extra_data": "...", "sct": "..."}, {"index": 13, "leaf_input: "...", "extra_data": "...", "sct": "..."}, {"index": 14, "leaf_input: "...", "extra_data": "...", "sct": "..."} ], "sth": ... } or the more concise: resp: { "entries":{ "10": {"leaf_input: "...", "extra_data": "...", "sct": "..."}, "11": {"leaf_input: "...", "extra_data": "...", "sct": "..."}, "12": {"leaf_input: "...", "extra_data": "...", "sct": "..."}, "13": {"leaf_input: "...", "extra_data": "...", "sct": "..."}, "14": {"leaf_input: "...", "extra_data": "...", "sct": "..."} }, "sth": ... } Some classes of bug in log implementations would be more apparent this way: eg. an inadvertent duplication of an entry in the response, or an entry missing within the range returned. Out-of-order entries would be apparent too; but a side-benefit of this could be that the requirement to return log entries in strict order can be relaxed. Any thoughts? thanks, Paul --001a114b1a4404e247053fc6d3d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi trans,

I'd like to put forward i= deas I've had about the /ct/v1/get-entries API. These are
bas= ed on experiences we've had running Google's CT Monitor.
=
The current API looks something like:

req:
=C2=A0=C2=A0GET /ct/v1/get-entries?start=3D10&end=3D14<= /div>

resp:
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"entries":[
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0{"leaf_input: "...", "extra_data&qu= ot;: "..."},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"l= eaf_input: "...", "extra_data": "..."},
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"leaf_input: "...", = "extra_data": "..."},
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0{"leaf_input: "...", "extra_data": &q= uot;..."},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"leaf_inp= ut: "...", "extra_data": "..."}
=C2= =A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0}
<= br>
When the log being audited functions compliantly, this is fin= e.=C2=A0 The client
assumes that the 5 entries returned are [10..= 14] as requested, and this is
borne out by eventually computing a= tree root-hash that matches the log's
STH.

The shortcomings become apparent when monitoring a log that misbeha= ves.

Assuming the client receives valid, well-form= ed JSON, there's one class of
bad response that immediately l= ooks wrong: where the number of entries
returned exceeds the numb= er requested.

Logs are at liberty to return fewer = entries than requested.

So any other invalid get-e= ntries response is only apparent when the tree's
root hash do= esn't match that in the STH.=C2=A0 The client is unable to determine
anything more about what fault was present in the log's respons= e, until
after retrying it notices the response change (perhaps t= he log operator has
fixed a bug in the log software).
<= br>
A monitor that is fetching the range of entries from STHn-1 t= o STHn often
must paginate over the range; if STH validation fail= s=C2=A0in that case there are
then multiple responses to consider= when trying to work out where a log
returned invalid data.
=

My proposal is to modify the response structure to incl= ude entry indices. I
can think of two ways to do so:

req:
=C2=A0=C2=A0GET /ct/v2/get-entries?sta= rt=3D10&end=3D14

resp:
=C2=A0 =C2=A0= =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0"entries":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"index": 10, "leaf= _input: "...", "extra_data": "...", "sct= ": "..."},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{&quo= t;index": 11,=C2=A0"leaf_input: "...", "extra_data= ": "...", "sct": "..."},
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"index": 12,=C2=A0"leaf_inpu= t: "...", "extra_data": "...", "sct"= ;: "..."},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{"ind= ex": 13,=C2=A0"leaf_input: "...", "extra_data"= ;: "...", "sct": "..."},
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0{"index": 14,=C2=A0"leaf_input: &quo= t;...", "extra_data": "...", "sct": &quo= t;..."}
=C2=A0 =C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2= =A0 =C2=A0 =C2=A0"sth": ...
=C2=A0 =C2=A0 =C2=A0}

or the more concise:

resp:
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2= =A0 =C2=A0"entries":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"10": {"leaf_input: "...", "extra_data&quo= t;: "...", "sct": "..."},
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"11": {"leaf_input: "...&quo= t;, "extra_data": "...", "sct": "...&quo= t;},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"12": {"lea= f_input: "...", "extra_data": "...", "sc= t": "..."},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quo= t;13": {"leaf_input: "...", "extra_data": &qu= ot;...", "sct": "..."},
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"14": {"leaf_input: "...", &qu= ot;extra_data": "...", "sct": "..."}
=C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;sth": ...
=C2=A0 =C2=A0 =C2=A0}


Some classes of bug in log implementations would be mo= re apparent
this way: =C2=A0eg. an inadvertent duplication of an = entry in the response, or
an entry missing within the range retur= ned.=C2=A0 Out-of-order entries would
be apparent too; but a side= -benefit of this could be that the requirement
to return log entr= ies in strict order can be relaxed.

Any thoughts?<= /div>

thanks,
Paul

<= /div> --001a114b1a4404e247053fc6d3d2-- From zakird@gmail.com Thu Oct 27 07:50: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 8373F129481 for ; Thu, 27 Oct 2016 07:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 6OCmr4z_l83i for ; Thu, 27 Oct 2016 07:50:15 -0700 (PDT) Received: from mail-yb0-f179.google.com (mail-yb0-f179.google.com [209.85.213.179]) (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 E35CD129AAC for ; Thu, 27 Oct 2016 07:49:16 -0700 (PDT) Received: by mail-yb0-f179.google.com with SMTP id g68so19629936ybi.0 for ; Thu, 27 Oct 2016 07:49:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hOh3MFWM8z5aRsD8kafji2q3XxdJPH86XkkImk77SqI=; b=EVZK6X+wz/A+Le0Ejtj8FWFcdeHPKFHbcpfPZK/KFMFQpNamYBD0dPzPHHAR/qL29V GyyeRVqkaW5kqyiBVQrvp2KRo3wJapAPFJ4cSiB+poV3DiLY7T00xU8aPsAy2A7A3H18 GqFfbnEavwI3++CIAhsr4HowtM+a6gg9EzACkTRIXLWJxBmr3uc56hlnNzjE3OKOBYps l0nvpGhL2XnYfnVDRgfLIUI44aQrTguxkufzAIQx5bP4AW04hC8K24wSYti0vvehnbF5 IegGCPzTpAo1OAhDUBpbSW5QcNz0gyZrHNPzJRI4gNqgOlycwy+ZxEJQr+C112m9LSfH fdSA== X-Gm-Message-State: ABUngvc1fVhtpKVjSdwXAanB9uoHTKUxG8gLEjAy8ByLSV20DI+9s5sAwtJ7lVHNKYg72Q== X-Received: by 10.36.102.2 with SMTP id k2mr10612262itc.114.1477579755764; Thu, 27 Oct 2016 07:49:15 -0700 (PDT) Received: from [192.168.106.96] (node-18-237.flex.volo.net. [76.191.18.237]) by smtp.gmail.com with ESMTPSA id 202sm1119721ith.1.2016.10.27.07.49.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Oct 2016 07:49:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Zakir Durumeric In-Reply-To: <20161025103652.da027f9a7ebeb06eb42c358b@andrewayer.name> Date: Thu, 27 Oct 2016 09:49:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <618E8DBD-7C62-458B-9DD3-847029A26F38@umich.edu> References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> <557B1834.8040706@bbn.com> <20161025103652.da027f9a7ebeb06eb42c358b@andrewayer.name> To: Andrew Ayer X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Rob Stradling , trans@ietf.org Subject: Re: [Trans] Log Monitoring API 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, 27 Oct 2016 14:54:01 -0000 I would be happy to be involved, and the Censys Project would be = interested in implementing an agreed API as part of its CT monitoring. Zakir > On Oct 25, 2016, at 12:36 PM, Andrew Ayer = wrote: >=20 > On Thu, 6 Oct 2016 16:21:59 +0100 > Rob Stradling wrote: >=20 >> Now we've completed WGLC for 6962-bis, I'd like to pick this thread >> back up again. >>=20 >> Several different public CT monitoring services now exist (crt.sh, >> Cert Spotter, Censys.io, etc). ISTM that it would be useful to >> define a common API that could be implemented by each monitor, so >> that end-users don't have to implement multiple APIs in order to talk >> to multiple monitors. >>=20 >> Matt Palmer and I made a start on a (very drafty) draft a while ago: >> = https://github.com/tobermorytech/ct-monitor-api-rfc/blob/master/draft-palm= er-ct-monitor-api.md >>=20 >> Who's interested in working on this? >=20 > Count me in. >=20 > Regards, > Andrew >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 From nobody Fri Oct 28 04:03:59 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 8E44D129A8D for ; Fri, 28 Oct 2016 04:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 HXI2OiNDuy2u for ; Fri, 28 Oct 2016 04:03:56 -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 45C37129A8F for ; Fri, 28 Oct 2016 04:03:56 -0700 (PDT) Received: from localhost ([::1]:51592 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c04ww-00070e-N0; Fri, 28 Oct 2016 04:03:50 -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: rob.stradling@comodo.com, paul@nohats.ca X-Trac-Project: trans Date: Fri, 28 Oct 2016 11:03:50 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/159#comment:3 Message-ID: <078.bc9b08ef3c614f310523bdb3248ecc11@tools.ietf.org> References: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, paul@nohats.ca, 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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #159 (rfc6962-bis): Missing step in "Verifying an inclusion proof" 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, 28 Oct 2016 11:03:57 -0000 #159: Missing step in "Verifying an inclusion proof" Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/a4c56002ed587337df002cd70377a40b4f214359 We'll submit an updated draft before the next submission deadline (2016-10-31 UTC 23:59). -- -----------------------------------+--------------------------------------- Reporter: | Owner: rob.stradling@comodo.com robpercival@google.com | Status: assigned Type: defect | Milestone: review Priority: minor | Version: Component: rfc6962-bis | Resolution: Severity: - | Keywords: | -----------------------------------+--------------------------------------- Ticket URL: trans From nobody Fri Oct 28 04:07:43 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 6CAA7129A94 for ; Fri, 28 Oct 2016 04:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 x5WMqGuxanYS for ; Fri, 28 Oct 2016 04:07:41 -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 39245129A92 for ; Fri, 28 Oct 2016 04:07:41 -0700 (PDT) Received: from localhost ([::1]:51635 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c050c-0007Dl-KG; Fri, 28 Oct 2016 04:07:38 -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: rob.stradling@comodo.com, benl@google.com, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 11:07:38 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/111#comment:8 Message-ID: <080.a1006e2777df89b3a2a913f6cb6cf19c@tools.ietf.org> References: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, 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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #111 (rfc6962-bis): Consider using the cached-info TLS extension 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, 28 Oct 2016 11:07:42 -0000 #111: Consider using the cached-info TLS extension Changes (by rob.stradling@comodo.com): * status: new => assigned * component: to-be-decided => rfc6962-bis * milestone: => review Comment: The proposed text was adopted in 6962-bis draft 19. Just tidying up the issue tracker. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: assigned Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Oct 28 05:56:48 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 0990B1294FC for ; Fri, 28 Oct 2016 05:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 qUGSaCRIXzDy for ; Fri, 28 Oct 2016 05:56:45 -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 317DF129499 for ; Fri, 28 Oct 2016 05:56:45 -0700 (PDT) Received: from localhost ([::1]:54627 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c06iC-0006rz-KO; Fri, 28 Oct 2016 05:56:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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, rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 12:56:44 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/160 Message-ID: <065.66fe4cb7f7c8d1c49d186d7befbcb0fb@tools.ietf.org> X-Trac-Ticket-ID: 160 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20161028125645.317DF129499@ietfa.amsl.com> Resent-Date: Fri, 28 Oct 2016 05:56:45 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #160 (rfc6962-bis): New get-sths API for fetching all STHs in a given time range 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, 28 Oct 2016 12:56:47 -0000 #160: New get-sths API for fetching all STHs in a given time range Paul Hadfield wrote: "I have been thinking about how an auditor’s task might be easier if Logs were required to retain their historic STHs and provide them on request. It could be done by adding an API along the lines of ‘get-sth-at-time’ or ‘get-sths-between-times’. (where the first returns the STH with largest timestamp <= the timestamp requested, and the second returns a list of STHs with timestamps in the range requested). Auditors could then retrieve the full STH history of a log without having to have collected them over an extended period of time or having to exchange them with other auditors - although verifying STHs gathered by other parties is still worthwhile to detect split views." Benjamin Kaduk wrote: "It does seem like a useful feature, yes. But that utility should probably be weighed against the added cost for the log operator, which now has to retain STH history and provide code to service the new requests. That extra cost is probably not very large, but it would nice to have other opinions confirming that." Eran wrote (off list) that he would want this proposed API to be optional for logs to implement. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Oct 28 07:05:33 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 1D2881294EB for ; Fri, 28 Oct 2016 07:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 xKQxfjhYSbhL for ; Fri, 28 Oct 2016 07:05: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 7091F12948A for ; Fri, 28 Oct 2016 07:05:30 -0700 (PDT) Received: from localhost ([::1]:58555 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c07mj-00026I-UW; Fri, 28 Oct 2016 07:05:29 -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: rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 14:05:29 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/160#comment:1 Message-ID: <080.74c63a79967e416e030383587679e578@tools.ietf.org> References: <065.66fe4cb7f7c8d1c49d186d7befbcb0fb@tools.ietf.org> X-Trac-Ticket-ID: 160 In-Reply-To: <065.66fe4cb7f7c8d1c49d186d7befbcb0fb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #160 (rfc6962-bis): New get-sths API for fetching all STHs in a given time range 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, 28 Oct 2016 14:05:32 -0000 #160: New get-sths API for fetching all STHs in a given time range Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned Comment: I don't yet know if this'll make it into 6962-bis, but I've prepared a PR: https://github.com/google/certificate-transparency-rfcs/pull/200 -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: assigned Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Oct 28 07:06:01 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 0028E129465 for ; Fri, 28 Oct 2016 07:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ssoZyvK_x0me for ; Fri, 28 Oct 2016 07:05:57 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2710B12948A for ; Fri, 28 Oct 2016 07:05:57 -0700 (PDT) Received: (qmail 17056 invoked by uid 1004); 28 Oct 2016 14:05:55 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 28 Oct 2016 15:05:55 +0100 Received: (qmail 28562 invoked by uid 1000); 28 Oct 2016 14:05:55 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 28 Oct 2016 15:05:55 +0100 To: Benjamin Kaduk , Paul Hadfield References: <20161019170057.s74mniw7jsxrnvse@roeckx.be> <20161019203117.rqa3paaz5hkvtxtk@roeckx.be> <73602aba-43a3-d850-b86d-c3277cb54353@comodo.com> From: Rob Stradling Message-ID: <0ae15a8e-54ea-24a5-96e6-6841006938e9@comodo.com> Date: Fri, 28 Oct 2016 15:05:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "trans@ietf.org" , Kurt Roeckx Subject: Re: [Trans] Gossip protocol 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, 28 Oct 2016 14:06:00 -0000 On 26/10/16 00:44, Benjamin Kaduk wrote: > On Tue, 25 Oct 2016, Rob Stradling wrote: > >> >>> Auditors could then retrieve the full STH history of a log without having >>> to have collected them over an extended period of time or having to >>> exchange them with other auditors >> >> Indeed. I think this would be a useful feature. > > It does seem like a useful feature, yes. But that utility should probably > be weighed against the added cost for the log operator, which now has to > retain STH history and provide code to service the new requests. > > That extra cost is probably not very large, but it would nice to have > other opinions confirming that. I don't yet know if this can be considered for 6962-bis, but I've gone ahead and created an issue and proposed a PR: https://trac.tools.ietf.org/wg/trans/trac/ticket/160 https://github.com/google/certificate-transparency-rfcs/pull/200 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Oct 28 07:47:33 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 7C039129B16 for ; Fri, 28 Oct 2016 07:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 SR2c6_e74s3B for ; Fri, 28 Oct 2016 07:47:29 -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 D7F03129B0F for ; Fri, 28 Oct 2016 07:47:29 -0700 (PDT) Received: from localhost ([::1]:59432 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c08RN-0008Pg-BL; Fri, 28 Oct 2016 07:47:29 -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, rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 14:47:29 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/161 Message-ID: <065.c3c096459dba5020e67b3a73bb8d193c@tools.ietf.org> X-Trac-Ticket-ID: 161 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20161028144729.D7F03129B0F@ietfa.amsl.com> Resent-Date: Fri, 28 Oct 2016 07:47:29 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #161 (rfc6962-bis): Handling high-volume submissions 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, 28 Oct 2016 14:47:31 -0000 #161: Handling high-volume submissions Google's Aviator log recently exceeded its MMD slightly. This was: "caused by the (non-malicious) actions of some high-volume clients. Aviator's signer could not sequence the submitted certificate chains quickly enough to clear the backlog, exacerbated by the fact our protection against flooding did not activate when expected." https://groups.google.com/a/chromium.org/d/msg/ct-policy/ZZf3iryLgCo/mi- 4ViMiCAAJ Inspired by OCSP, I think we should add a "tryLater" error code to add- chain and add-pre-chain, so that logs can explicitly communicate the fact that they're currently too busy to accept submissions. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Oct 28 08:01: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 7EE7812944E for ; Fri, 28 Oct 2016 08:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 6FQ11m5zrjPh for ; Fri, 28 Oct 2016 08:01:28 -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 57372124281 for ; Fri, 28 Oct 2016 08:01:28 -0700 (PDT) Received: from localhost ([::1]:59601 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c08eu-0000fI-A4; Fri, 28 Oct 2016 08:01:28 -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: rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 15:01:28 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/161#comment:1 Message-ID: <080.afaad1d8ae45b90cee644de0dd82931f@tools.ietf.org> References: <065.c3c096459dba5020e67b3a73bb8d193c@tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <065.c3c096459dba5020e67b3a73bb8d193c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #161 (rfc6962-bis): Handling high-volume submissions 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, 28 Oct 2016 15:01:30 -0000 #161: Handling high-volume submissions Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned Comment: Proposed PR: https://github.com/google/certificate-transparency-rfcs/pull/201 -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: assigned Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Oct 28 09:30:23 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 A8006129A8C for ; Fri, 28 Oct 2016 09:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 SmP9bAbeHltI for ; Fri, 28 Oct 2016 09:30:18 -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 1D45F129AB8 for ; Fri, 28 Oct 2016 09:30:15 -0700 (PDT) Received: from localhost ([::1]:33011 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c0A2o-0005EJ-PH; Fri, 28 Oct 2016 09:30:14 -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: rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 16:30:14 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/161#comment:2 Message-ID: <080.1af66ab3c6b594f6d0417240b34a7240@tools.ietf.org> References: <065.c3c096459dba5020e67b3a73bb8d193c@tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <065.c3c096459dba5020e67b3a73bb8d193c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #161 (rfc6962-bis): Handling high-volume submissions 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, 28 Oct 2016 16:30:21 -0000 #161: Handling high-volume submissions Changes (by rob.stradling@comodo.com): * status: assigned => closed * resolution: => wontfix Comment: Ryan and Jacob commented on the PR that "tryLater" is unnecessary, because we already specify that log servers can return 503 Service Unavailable with (optionally) a Retry-After header (see https://github.com/google /certificate-transparency-rfcs/blob/master/draft-ietf-trans- rfc6962-bis-19.txt#L1281-L1294). -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: closed Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Oct 28 10:47: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 65F5A129469 for ; Fri, 28 Oct 2016 06:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] 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 d7cqa9DOKFTh for ; Fri, 28 Oct 2016 06:49:08 -0700 (PDT) Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8D9129AD8 for ; Fri, 28 Oct 2016 06:49:05 -0700 (PDT) Received: from asbsmtmtaapi01.symc.symantec.com (asb1-f5-symc-ext-prd-snat10.net.symantec.com [10.90.75.10]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 8D.55.04894.15753185; Fri, 28 Oct 2016 13:49:05 +0000 (GMT) X-AuditID: 0a5af819-8bcdb9a00000131e-96-58135751d623 Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat9.net.symantec.com [10.90.75.9]) by asbsmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 73.D4.04936.05753185; Fri, 28 Oct 2016 13:49:05 +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; Fri, 28 Oct 2016 06:49:03 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.128.4) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Fri, 28 Oct 2016 06:49:03 -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=/DGWZ9uCycNhzynRpY7RhsINeL+U4euyCYU8EOd3vrk=; b=eKT9GyHL+edVHHHGZj9pj+Fe5cioLwDGbyxt2K1Xz/psATb5DHJHpxXJUotNQLSyUPltt3TSemMw8zMRwkmRMQ3xW1txFDEU9E2W32ipCQsQiU6a4TcDr9z2uurpU9DfpqqO/3QB7BNjy0pnjpbJhRW4UhdvOq1XzZGW7vv+YqE= Received: from BN3PR16MB0899.namprd16.prod.outlook.com (10.165.81.153) by BN3PR16MB0900.namprd16.prod.outlook.com (10.165.81.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Fri, 28 Oct 2016 13:49:00 +0000 Received: from BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) by BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) with mapi id 15.01.0679.015; Fri, 28 Oct 2016 13:49:00 +0000 From: Tarah Wheeler To: Rob Stradling Thread-Topic: [Trans] Call for adoption: draft-strad-trans-redaction-00 Thread-Index: AQHSFAtO9b8G7W896UCn2f4/+t5ECqCEQECAgALsJICAMrdUgIAEOEMX Date: Fri, 28 Oct 2016 13:49:00 +0000 Message-ID: <2775E6CC-A288-4681-A14F-19A775EDFF15@symantec.com> References: <5b357047-d412-70de-4aa6-9499fa8837b5@comodo.com> , <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> In-Reply-To: <5290c544-97b1-7530-eb0c-e9b62d8ebc71@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tarah_Wheeler@symantec.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2600:1003:b12d:5ad6:ac2c:a39f:3e6d:f9a4] x-ms-office365-filtering-correlation-id: 4abf7159-1ed3-4078-68b7-08d3ff392be9 x-microsoft-exchange-diagnostics: 1; BN3PR16MB0900; 7:wQ9WoQZPQUroCdaNKfqz52bsUK+jQBO85AiU2S1//LBxf/CB9vTmokJ/K6Sy/XVwPH5xCAtL11TBW2PhmYt70nwokLLCBAZYMPDgvXk2Z+gPP1U454fytPs8lozST2GdEUljPqMpmb/7O8p3vgqz36MZojSK3EvEWT47D7+9q59SJkjdghUg/jKFkywJpTn7pBrQb35Aj7hf1bnblxsISJY8YJt1WKaADctrEOqNDuCsIHW85PmOR47fhUnFJsLpyBa7exzlJeGojZnzpeCyYOjKwLw+XDoF0bAHTF+CydyA+WyMODtPslYc7+79HFjz/VzFfie6lL9Je9zZYO+WqNsV2CWQOoTIp9CPrydYXiA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR16MB0900; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6042046)(6043046); SRVR:BN3PR16MB0900; BCL:0; PCL:0; RULEID:; SRVR:BN3PR16MB0900; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377454003)(199003)(51414003)(24454002)(33656002)(86362001)(6116002)(586003)(2900100001)(97736004)(68736007)(87936001)(83716003)(2950100002)(5660300001)(110136003)(4326007)(80792005)(106356001)(7846002)(82746002)(77096005)(2906002)(93886004)(305945005)(6916009)(99286002)(105586002)(106116001)(92566002)(7736002)(230783001)(3280700002)(19580395003)(3660700001)(19580405001)(50986999)(54356999)(11100500001)(76176999)(102836003)(5002640100001)(101416001)(81166006)(81156014)(189998001)(8936002)(36756003)(122556002)(10290500002)(8676002)(10400500002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR16MB0900; H:BN3PR16MB0899.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2016 13:49:00.2125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR16MB0900 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42LhivLm0g0MF44w+DOZ3WJR42JWi7WPL7I4 MHlcWjKb0WPJkp9MAUxRXDYpqTmZZalF+nYJXBmT+nvZCnayV3yYK9vA+J21i5GTQ0LARKLr yRf2LkYuDiGBz4wSRxvfsMEkdj2YzwaR+MYo0TLjNwuEc4RRomfRCmYI5wWjxLWWbrAyFoFO ZoldF7pYITLTmCT+7P7FBDJMSOAYo8TLUxJdjBwcbAIGEh9vRIGYIgI6Ertug61jFlCV2Hb0 KTuILSzgJrH5eTvYfSIC7hJTfr1lhrDdJFZ+ugFWwwJU/2LmVLDpvAL2Erv73kAdtJJZYtGs XrAEp4CdxMO5s8EWMAqISXw/tYYJYpm4xK0n85kg/hSQWLLnPDOELSrx8vE/Voj6WImTuzcx QsR1JM5efwJlW0v83HWFHcL2lZi55zojyGIJgQXMEmeugHzAAeS4Sbxst4KoyZZYd3U3VK+P xPK+PjaI+lOMEh2XPrNPYNSfheQmCFtHYsHuT2wQtrbEsoWvmWeBPSoocXLmE5YFjCyrGBUS i5OKc0vyS0sSC1INDPWKK3OTQUQiMJEk6yXn525iBCeTH5I7GI+c8DnEKMDBqMTDK+UtHCHE mlgGVHmIUYKDWUmEd08wUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvttcMEUIC6YklqdmpqQWp RTBZJg5OqQbGszX5mr96JAVS52+bbmQ6Yc0X06UXQjl+LtvQIFbjyzVP8EvMVJvDXiLrTya/ XbVpbZvy0uQzleU3Q6em3Y9Tv/szbkvBvok5RrYdsxfdae3XOPBijsoh7sS/k6fOkrOoq+3l 9Vy29fadXZLGe50eJzOu0jzqm3iqZvlD375SuX627QcLv1mJKbEUZyQaajEXFScCAIZKEc4i AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42LhivLm1A0MF44weHaZ0WJR42JWi7WPL7I4 MHlcWjKb0WPJkp9MAUxRXDYpqTmZZalF+nYJXBmT+nvZCnayV3yYK9vA+J21i5GTQ0LARGLX g/lsXYxcHEIC3xglWmb8ZoFwjjBK9CxawQzhvGCUuNbSDVbGItDJLLHrQhcrRGYak8Sf3b+Y QIYJCRxjlHh5SqKLkYODTcBA4uONKBBTREBHYtdtNpAKZgFViW1Hn7KD2MICbhKbn7eDnSEi 4C4x5ddbZgjbTWLlpxtgNSxA9S9mTgWbzitgL7G77w3UQSuZJRbN6gVLcArYSTycOxtsAaOA mMT3U2uYIJaJS9x6Mp8J4k8BiSV7zjND2KISLx//Y4Woj5U4uXsTI0RcR+Ls9SdQtrXEz11X 2CFsX4mZe64zgiyWEFjALHHmCsgHHECOm8TLdiuImmyJdVd3Q/X6SCzv62ODqD/FKNFx6TPU IBmJeS/nsEAkWtgkZlxsYZ7AqDMLybEQto7Egt2f2CBsbYllC18zzwKHgKDEyZlPWBYwsqxi VEgsTirOLcktSUwsyDQw1CuuzE0GEYnARJKsl5yfu4kRnEx+i+1gPPDH5xCjAAejEg8vh5Fw hBBrYhlQ5SFGCQ5mJRHePcFAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzCG/+HCwmkJ5akZqem FqQWwWSZODilGhgd05bWuP+W73S743Zt6mK+kw35nrPyMv8Y67Eec67d3Kak0yARd+n+lQOr ym2+volk2lH5MEh4qcLpkhYu0Yr9C1yeKfsW2nAUOq/+yTQ52OgXt0vd56D7tZe43+rIqH9e todxsYSjSOzcy5HMcaoLE11mGYos/KPT01Lfl6Zodmzb7V1Lq5VYijMSDbWYi4oTAeVnQOQi AwAA Archived-At: X-Mailman-Approved-At: Fri, 28 Oct 2016 10:47:18 -0700 Cc: "trans@ietf.org" Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 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, 28 Oct 2016 13:49:09 -0000 I've had one or two :) I'll look forward to your thoughts on them. I'll hav= e some work for you all to look at soon.=20 Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec tarah@symantec.com > On Oct 25, 2016, at 5:23 PM, Rob Stradling wro= te: >=20 >> On 23/09/16 20:04, Tarah Wheeler wrote: >> I will co-author the redaction RFC. >=20 > Hi Tarah. Have you had any further thoughts on this since the call for > adoption a month ago? >=20 > After the discussion at the CABForum F2F last week, it seems that > redaction is going to be a hot topic in Seoul. So I'm just wondering if > there are any updates worth doing to draft-strad-trans-redaction before > the draft cut-off date (Monday 31st Oct) that might facilitate the > discussions. >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online From nobody Fri Oct 28 12:08:51 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 948F612957F for ; Fri, 28 Oct 2016 12:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 e1hzkmKYzcRu for ; Fri, 28 Oct 2016 12:08:48 -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 6321E129573 for ; Fri, 28 Oct 2016 12:08:48 -0700 (PDT) Received: from localhost ([::1]:35893 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c0CW8-0007c4-7O; Fri, 28 Oct 2016 12:08:40 -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: rob.stradling@comodo.com, paul@nohats.ca, melinda.shore@gmail.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 19:08:40 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/159#comment:4 Message-ID: <078.01289a6e98f2f6c7d7b59962949f857e@tools.ietf.org> References: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, paul@nohats.ca, 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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #159 (rfc6962-bis): Missing step in "Verifying an inclusion proof" 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, 28 Oct 2016 19:08:49 -0000 #159: Missing step in "Verifying an inclusion proof" Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -----------------------------------+--------------------------------------- Reporter: | Owner: rob.stradling@comodo.com robpercival@google.com | Status: closed Type: defect | Milestone: review Priority: minor | Version: Component: rfc6962-bis | Resolution: fixed Severity: - | Keywords: | -----------------------------------+--------------------------------------- Ticket URL: trans From nobody Fri Oct 28 12:09:09 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 B3247129619 for ; Fri, 28 Oct 2016 12:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 Z3hNuyVAM54d for ; Fri, 28 Oct 2016 12:09:06 -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 85608129609 for ; Fri, 28 Oct 2016 12:09:06 -0700 (PDT) Received: from localhost ([::1]:35898 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c0CWX-0007cg-4T; Fri, 28 Oct 2016 12:09:05 -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: rob.stradling@comodo.com, benl@google.com, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Fri, 28 Oct 2016 19:09:05 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/111#comment:9 Message-ID: <080.1ec80e1723f2a8281cc3bc80ac9e89aa@tools.ietf.org> References: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, 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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #111 (rfc6962-bis): Consider using the cached-info TLS extension 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, 28 Oct 2016 19:09:07 -0000 #111: Consider using the cached-info TLS extension Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Oct 31 12:02:44 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 F017C129A4B for ; Mon, 31 Oct 2016 12:02: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 B0J1SfBFhIqB for ; Mon, 31 Oct 2016 12:02:15 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94709129A6D for ; Mon, 31 Oct 2016 12:01:35 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id v84so85799124oie.3 for ; Mon, 31 Oct 2016 12:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/oZVgnXMVo7WfDMfRpkdLdpD/gdpm0I856NFvaVlJLQ=; b=WFQX4ftW82lQ88Xf2an80Eat+r//LlhEvoBXUuQV3fFHsfUWjXNTUNclDVZtmDwMvn VnR74O3Kou7NiRlGy1HW5EqJwUJKksGAYxitFXlzUJ0aTJak+K9T1FqRVK51T7Usiiy+ H1ym/Lzg9HqM0nbiVvZCnBG9+NXfzBcfhJ6n0MdXH+L5TcYKeRMsrnYEw+PVGuwRzd8B 1RiasdvdfgvMIyR/JaOUGXYatEUiYzhp66HipP92tJaKxS7bmeY3tsW/u1O/7mCmeFj0 QEEDKvUUvDnR4Ew/AkrNmINXxHJZhfDYWRcIiOLxZqCbSeBumuqT6byw/moNDL3In2oL oZ9A== 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=/oZVgnXMVo7WfDMfRpkdLdpD/gdpm0I856NFvaVlJLQ=; b=nLSlBZIhclVJ5uBbFkIlWfqE2/FjQg0EWTI2AS+MtmD5CmUXdogmYM2AdYx9mwmJkm eDeqlNdkh3sdeYYOn8SP0Ca1kdvbuRrTBSMFBPerjgZv/mKlUCIWCgFlqb37RXm1gw0V 0iittzZ6IeVqZBiCNVfO6k31NzV5IWPeVX21Adc7o56hZagTu5Dmk1TbShAyeUfYlLgq 8/FhlRe1KhToqGZBUFdB38aF3Dc6JearaqHBlLapfrUdkFNcFWO3Ip3nytkULyUnq1LK zWTvmdztvcHV3puG3BSt3w/i80eAEuT94/PmIl6pEF6/JR5BvoIdQ/VChmeQz9wmMmIa lbww== X-Gm-Message-State: ABUngve14BTT/TQAYB7O04PeA3Lp9CvU0pWoc4pY6ArkinYBRrkTvhD/8+4I+UxCxto7fSBr7ynQt5fATwD2Qw== X-Received: by 10.107.184.214 with SMTP id i205mr5718915iof.167.1477940494871; Mon, 31 Oct 2016 12:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Mon, 31 Oct 2016 12:01:34 -0700 (PDT) In-Reply-To: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> From: Peter Bowen Date: Mon, 31 Oct 2016 12:01:34 -0700 Message-ID: To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality 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, 31 Oct 2016 19:02:17 -0000 On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore wrote: > You may have seen the recent announcement from the Chrome > team that as of October 2017 certificates will need to comply > with Chrome's CT policy in order to be trusted. There was > also an invitation to discuss that on the trans mailing list. > This is a reminder that mailing list discussions need to > remain focused on the specifications being produced by the > working group - that is to say, policies related to > individual implementations are out of scope for the working > group except to the extent that they bear on decisions related > to our working group drafts. Paul and Melinda, Do you consider discussion of use cases for privacy to be in-scope for this group or do you consider only the technical implementation of privacy (e.g. section 4 of 6962-bis and the redaction draft) to be in-scope? Thanks, Peter From nobody Mon Oct 31 14:55:56 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 AEFEA129B67; Mon, 31 Oct 2016 14:55:51 -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.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795095171.23154.9008489783890192631.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 14:55:51 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-20.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: Mon, 31 Oct 2016 21:55:51 -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-20.txt Pages : 53 Date : 2016-10-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-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-20 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 Mon Oct 31 15:04:36 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 85927129428 for ; Mon, 31 Oct 2016 15:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 n-1DP0hgLR6l for ; Mon, 31 Oct 2016 15:04:34 -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 53F5C1293F8 for ; Mon, 31 Oct 2016 15:04:34 -0700 (PDT) Received: from localhost ([::1]:46327 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c1Kgt-0004RB-9R; Mon, 31 Oct 2016 15:04:27 -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: rob.stradling@comodo.com, paul@nohats.ca, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 31 Oct 2016 22:04:27 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/159#comment:5 Message-ID: <078.c23007ff765760cfcccda12b0beb021d@tools.ietf.org> References: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-Trac-Ticket-ID: 159 In-Reply-To: <063.75684500c5404010bb3ecc4b3a3646bf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, paul@nohats.ca, 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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #159 (rfc6962-bis): Missing step in "Verifying an inclusion proof" 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, 31 Oct 2016 22:04:35 -0000 #159: Missing step in "Verifying an inclusion proof" Comment (by rob.stradling@comodo.com): Draft -20 submitted. -- -----------------------------------+--------------------------------------- Reporter: | Owner: rob.stradling@comodo.com robpercival@google.com | Status: closed Type: defect | Milestone: review Priority: minor | Version: Component: rfc6962-bis | Resolution: fixed Severity: - | Keywords: | -----------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Oct 31 15:13: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 23812129B6E for ; Mon, 31 Oct 2016 15:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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.497, SPF_PASS=-0.001] autolearn=unavailable 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 XPzmB8hjKibQ for ; Mon, 31 Oct 2016 15:13:01 -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 B6E7C129979 for ; Mon, 31 Oct 2016 15:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08172BE56; Mon, 31 Oct 2016 22:02:52 +0000 (GMT) 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 RYSrvugRVklN; Mon, 31 Oct 2016 22:02:50 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 32E76BE58; Mon, 31 Oct 2016 22:02:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477951370; bh=ONr6b+41YfuRrfgTj730KlTKoCwM/y+aVWqzsnlHAxE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=mYq7sBSrdMcvr87v2ZG+1WZ3k7+fVhPrAMS66Vh7PXWx0O70VLpI21dZX2CMZdFkm jF0Dw8u1j/pEg/AHXdYiEQfEjRhulSxn6I6ISaf2qy+CD3/t9a+hlJ9ftIn4DzQOar SDU3LkNfS70JQXtPGqEveZ09A7c2lFDOcZIpMoLM= To: Peter Bowen , Melinda Shore References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> Date: Mon, 31 Oct 2016 22:02:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000705040001000605040301" Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Topicality 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, 31 Oct 2016 22:13:02 -0000 This is a cryptographically signed message in MIME format. --------------ms000705040001000605040301 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Peter, On 31/10/16 19:01, Peter Bowen wrote: > On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore wrote: >> You may have seen the recent announcement from the Chrome >> team that as of October 2017 certificates will need to comply >> with Chrome's CT policy in order to be trusted. There was >> also an invitation to discuss that on the trans mailing list. >> This is a reminder that mailing list discussions need to >> remain focused on the specifications being produced by the >> working group - that is to say, policies related to >> individual implementations are out of scope for the working >> group except to the extent that they bear on decisions related >> to our working group drafts. >=20 > Paul and Melinda, >=20 > Do you consider discussion of use cases for privacy to be in-scope for > this group or do you consider only the technical implementation of > privacy (e.g. section 4 of 6962-bis and the redaction draft) to be > in-scope? (Wearing no IETF hat, but perhaps the hat of someone interested in privacy...) I do not believe that it makes sense for us to talk as if privacy was a concept that applies to corporate entities. I do believe that your text above conflates privacy (a human concept) with corporate secrecy (a useful but different thing) in ways that are in the end damaging to both. (I further and even moreso believe that such conflation would be damaging to the IETF were we to slip into the bad practice of not calling out that terminological sloppiness.) I totally get that redaction has utility for folks who need corporate secrecy on a temporary basis. I absolutely do not accept that that has any privacy aspect. Can you call out the privacy aspect that applies to humans and that is a real part of the question related to support for redaction in CT? Thanks, S. >=20 > Thanks, > Peter >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 --------------ms000705040001000605040301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMzEy MjAyNTBaMC8GCSqGSIb3DQEJBDEiBCBAqAPDlaSWc32cEr7itXmoQ9FnxhSPz9FjINxnIxF5 UDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCa3FAvYdeqHds1GycL62XvtviVc5HVX+3tHwgOvIXdyd3Wo1+qUjXC uqeDcjcyKzAo9YsOnOxblOhsaL/WyZVAOFe9UYN6MArreZrKjcOlxFSmN3ngyvfojamgUE91 kw7jUxLD1qLyXJWVE5cDMVX9TWngM5DYlSjO9ydyFTp4ARm7j9XSHTDMvixhvcBDczHuS28U DKA3OZhoj6uiYTgbHI9+6g3hgbu7OOj6hhyn1Q3h+R66fg3cDjG4hR4NhqltDLMT7QabWSh7 7UlM0IV6aBRug3nA/6Ed9dEX+2uH0MHRo5aez5pbHJs4l4fYAn/3dba7QoWIS9+80fs6AI3w AAAAAAAA --------------ms000705040001000605040301-- From nobody Mon Oct 31 18:04:35 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 2C78D129AED for ; Mon, 31 Oct 2016 18:04:33 -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 a86uf7iKjgnr for ; Mon, 31 Oct 2016 18:04:31 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7350912945E for ; Mon, 31 Oct 2016 18:04:31 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id l124so21840795ywb.3 for ; Mon, 31 Oct 2016 18:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lQ8znYayEPQRvRzIRXJskOMNBA+bHH/TxjoYAOe6Yv8=; b=O/BCy7dSwNRGntVduUNk7JXOqQFti6yS5fCzo+niJfLtAqva20GsPWIYANphM9jUBj wlaSxCuDwM3tKN9Mr7zAv0USzQ9gIMacAqYwEl4GPb1OSAHO87OnMEY8IYIEpXrOGxFg qa7k/EWDf17g8VfpoYKBjwPu/8KV8YEw8NKcIFYee92OR2hG9Yne/SKXtyTZyzmg8LVW WPBJbzrFL3++QUlfEe0binUGWPOxtvDBQaxQzP9MYXamcfiZQMNAOVrKVOBO/5+M1J4f rLfYsGhonnj6Sb4ziEF1gqKs9IIzOmNyTvrIqU6nnAJGNWHUNhaiM7Q3mDt+7IyK5lCW LsWw== 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=lQ8znYayEPQRvRzIRXJskOMNBA+bHH/TxjoYAOe6Yv8=; b=FnYMXJsl7/0XYVi5DggzSoK8Bxt7WHKLICtNHk0RJszNrQMdB0NwpDS5Ips1ejro1I x47E4XU3DerOgHFNKlI762p7FAVpMb4DGP7Up3wq2CwNumj8SIhRth3DZhE5iJHOjlxO h95Lk+wjnp+wo2z/+j5hopUn0EJzs75TUoOETUtOuAHypHM9YpsHRzWV3PYINwy5jA2b cwChFwjBfJYYfwn7ahQ3DSAwMn66uPU9+acv3M/QWKYsN6qwxfqhKK5yrah+MV4Z4MaA 82yiFIj1aVI5/0wFY2Ikzufzi5z2hhrg34B9hMtG1xgILwEqeULQjAxj2iy4KDvp6PCJ /ftQ== X-Gm-Message-State: ABUngvd4Py5EwEEBleyCK37cT2xrpy7iQnXSi7OrFUh68noTC6cCLNeScKe6AaHzmiUFN4xlVjFPEHjXeUvb5g== X-Received: by 10.36.22.67 with SMTP id a64mr9320907ita.58.1477962270603; Mon, 31 Oct 2016 18:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Mon, 31 Oct 2016 18:04:29 -0700 (PDT) In-Reply-To: <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Peter Bowen Date: Mon, 31 Oct 2016 18:04:29 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Topicality 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, 01 Nov 2016 01:04:33 -0000 On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell wrote: > On 31/10/16 19:01, Peter Bowen wrote: >> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore wrote: >>> You may have seen the recent announcement from the Chrome >>> team that as of October 2017 certificates will need to comply >>> with Chrome's CT policy in order to be trusted. There was >>> also an invitation to discuss that on the trans mailing list. >>> This is a reminder that mailing list discussions need to >>> remain focused on the specifications being produced by the >>> working group - that is to say, policies related to >>> individual implementations are out of scope for the working >>> group except to the extent that they bear on decisions related >>> to our working group drafts. >> >> Paul and Melinda, >> >> Do you consider discussion of use cases for privacy to be in-scope for >> this group or do you consider only the technical implementation of >> privacy (e.g. section 4 of 6962-bis and the redaction draft) to be >> in-scope? > > (Wearing no IETF hat, but perhaps the hat of someone interested > in privacy...) > > I do not believe that it makes sense for us to talk as if > privacy was a concept that applies to corporate entities. > > I do believe that your text above conflates privacy (a human > concept) with corporate secrecy (a useful but different thing) > in ways that are in the end damaging to both. (I further and > even moreso believe that such conflation would be damaging > to the IETF were we to slip into the bad practice of not > calling out that terminological sloppiness.) > > I totally get that redaction has utility for folks who need > corporate secrecy on a temporary basis. I absolutely do not > accept that that has any privacy aspect. > > Can you call out the privacy aspect that applies to humans > and that is a real part of the question related to support for > redaction in CT? There are certificates that have personal information (e.g. given name, surname, and physical location) in the subject distinguished name or the subject alternative names. It is very possible that there may be a desire to redact this information (in fact it could even be required in some jurisdictions as CT could be considered a database). We already see this with domains in many countries where the full registrant details are not publicly available. Additionally, while 6962-bis does focus on certificates used for TLS server authentication, there are other types of certificates that could be logged. For example a certificate that is used with email and contains both the email address and given/surname. It might be that the owner of the certificate only wishes to disclose this binding to people receiving email from them rather than publicly disclosing it. We have also seen requests for certificates that cover phone numbers. A similar situation would apply -- having an "unlisted" number should be possible, where the subject details (other than phone number) are only known to a group of people who communicate with the number. So I think there is a privacy aspect here in addition to any corporate secrecy aspect. Thanks, Peter From nobody Mon Oct 31 18:33:26 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 A5A29129477 for ; Mon, 31 Oct 2016 18:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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.497, 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 mU0kV_cSP6H8 for ; Mon, 31 Oct 2016 18:33:15 -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 7D800129ACF for ; Mon, 31 Oct 2016 18:33:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A5898BE58; Tue, 1 Nov 2016 01:33:12 +0000 (GMT) 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 wuIuTUpA8YmD; Tue, 1 Nov 2016 01:33:11 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BCFC5BE4C; Tue, 1 Nov 2016 01:33:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477963991; bh=U7X3OaKvl80h+SqqrWxQe9oUVVW4plrUHPSiJ7GESws=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=XCz2gnQm+8I3FeQwIr2O0UKxr1GNJTK2aGCfE4YlQIyCD1kd/GQm/3EEfzg6199D3 H+RaHBqkbYxTSYQbVDLSF4X+WtIk5Iag9kR9q5Vm/Q0dSJyxd0uMsZ0HyV3XnGNakr eVtMgnAaIrezK2XXMTfqJEsww+8gsbn24b72d2Ng= To: Peter Bowen References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 1 Nov 2016 01:33:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040407060709050003010105" Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Topicality 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, 01 Nov 2016 01:33:24 -0000 This is a cryptographically signed message in MIME format. --------------ms040407060709050003010105 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/11/16 01:04, Peter Bowen wrote: > On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell > wrote: >> On 31/10/16 19:01, Peter Bowen wrote: >>> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore wrote: >>>> You may have seen the recent announcement from the Chrome >>>> team that as of October 2017 certificates will need to comply >>>> with Chrome's CT policy in order to be trusted. There was >>>> also an invitation to discuss that on the trans mailing list. >>>> This is a reminder that mailing list discussions need to >>>> remain focused on the specifications being produced by the >>>> working group - that is to say, policies related to >>>> individual implementations are out of scope for the working >>>> group except to the extent that they bear on decisions related >>>> to our working group drafts. >>> >>> Paul and Melinda, >>> >>> Do you consider discussion of use cases for privacy to be in-scope fo= r >>> this group or do you consider only the technical implementation of >>> privacy (e.g. section 4 of 6962-bis and the redaction draft) to be >>> in-scope? >> >> (Wearing no IETF hat, but perhaps the hat of someone interested >> in privacy...) >> >> I do not believe that it makes sense for us to talk as if >> privacy was a concept that applies to corporate entities. >> >> I do believe that your text above conflates privacy (a human >> concept) with corporate secrecy (a useful but different thing) >> in ways that are in the end damaging to both. (I further and >> even moreso believe that such conflation would be damaging >> to the IETF were we to slip into the bad practice of not >> calling out that terminological sloppiness.) >> >> I totally get that redaction has utility for folks who need >> corporate secrecy on a temporary basis. I absolutely do not >> accept that that has any privacy aspect. >> >> Can you call out the privacy aspect that applies to humans >> and that is a real part of the question related to support for >> redaction in CT? >=20 > There are=20 "Are" or "could be"? Serious question. The (non)existence of those in 6962 logs seems to me to be a) highly pertinent and b) demonstrable. > certificates that have personal information (e.g. given > name, surname, and physical location) in the subject distinguished > name or the subject alternative names.=20 I can well imagine certs for web servers with some PII embedded for no good reason. "Don't do that by accident" would be as good a bit of advice as we could offer in CT I think as it's really much more an issue for acme in terms of current IETF work. (Or at least arguably.) > It is very possible that there > may be a desire to redact this information (in fact it could even be > required in some jurisdictions as CT could be considered a database). The above has "possible," "may be a desire," "could even be" and "could be considered" all in one sentence. That is not a template for a winning argument is it? :-) > We already see this with domains in many countries where the full > registrant details are not publicly available. DNS registration policies are not in scope here though. >=20 > Additionally, while 6962-bis does focus on certificates used for TLS > server authentication, there are other types of certificates that > could be logged.=20 How many have been logged? Serious question. If there is a real problem here, I'm interested. If there is not, then I, for one, am not. Finding the evidence either way should not be hard. > For example a certificate that is used with email > and contains both the email address and given/surname. It might be > that the owner of the certificate only wishes to disclose this binding > to people receiving email from them rather than publicly disclosing > it. We have also seen requests for certificates that cover phone > numbers. A similar situation would apply -- having an "unlisted" > number should be possible, where the subject details (other than phone > number) are only known to a group of people who communicate with the > number. Again, please show us evidence from the public logs. That'd be compelling where speculation is not. But please note that redaction in CT is not the only possible mitigation - it may be better to say to CAs: "Hey, don't issue certs with PII unless the EE wants that really" since after all certs that end up in logs are mostly TLS server certs and hence will be picked up via zmap anyway if they are on the public Internet. (And those that are not on the public Internet because of corporate secrecy requirements are not relevant for privacy.) >=20 > So I think there is a privacy aspect here in addition to any corporate > secrecy aspect. And you also agree that separating those concepts is important? I hope so. If not, please do argue that. If so, let's see if there are really any important privacy cases here or if the only interesting ones relate to corporate secrecy. (Which, again is IMO a totally valid concept in many, but not all, guises.) Actually, my meta-suggestion is to start a new thread that does not have the failing of fatally mixing corporate secrecy and privacy. (Or even two threads if you think both concepts need discussion for CT.) S. >=20 > Thanks, > Peter >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 --------------ms040407060709050003010105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDEw MTMzMTBaMC8GCSqGSIb3DQEJBDEiBCDEoIa6XfRkZE/vR2s5v6VqO+3LTpJLRpD4kRh1V5zX yTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAB0u1wdkK5erfwvftszYaYxdJufdAU/aJS9MRto0Hyvwfbec7ObSga DnSellau/xTUPoran8onvnfcOx68BI1+UZ3cRI44qS21c+4gcb2b2rLyd1AkS4asA6Lh/AIK LZjIvGYpndvN9xbo16W6qR7ZstOTcEGu7X3ve0AcRekCuL/dCU7mkvylFIMTS4mFgHUwDYb6 WU8rfTdaAA2ILeICn8AgrZQnkkJzR/D5qAN71FDkZpjzvss3Zwt2bJGDffs47l5ROdORGbeh WEHps9sMxfldYR9JiM5yWQHs0nRMR6tsstqDlxeaArJyAmx42Eu/buIaIwA4vu3grKblybp+ AAAAAAAA --------------ms040407060709050003010105-- From nobody Mon Oct 31 19:18: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 28E17129417 for ; Mon, 31 Oct 2016 19:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqwUfNCyO61V for ; Mon, 31 Oct 2016 19:18:08 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409DE129A46 for ; Mon, 31 Oct 2016 19:18:08 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id C49CEC002927 for ; Mon, 31 Oct 2016 19:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=HIK+dzSJ3zNjxldnaUzmD082t2Q=; b= DlO9BPwfi4RIuqbixr7jcFofLsS/dJoznQllUNf/4pqzA1ItGW9cvw3R5lXJu45M qx7JcCpt2sxVtZy8yGVDGkn9t1BWEGgNTqtg/6pob63HlIjTjDp5c2pV99DcbKVb 25HWgRiGKcQsopBfTqX3O7YvIol5MITbaXr8n1bRVUc= Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id A68CCC002906 for ; Mon, 31 Oct 2016 19:18:07 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id 128so69599305oih.0 for ; Mon, 31 Oct 2016 19:18:07 -0700 (PDT) X-Gm-Message-State: ABUngvePxWDCc7Hc1uimuGmfPOhQrG55pGbhk+i90dEH7D0pswvOMp84ybxdyJrpgyjVvvqkNfZp+5pDwJga1g== X-Received: by 10.36.69.155 with SMTP id c27mr8458553itd.1.1477966687053; Mon, 31 Oct 2016 19:18:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.130 with HTTP; Mon, 31 Oct 2016 19:18:06 -0700 (PDT) In-Reply-To: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Ryan Sleevi Date: Mon, 31 Oct 2016 19:18:06 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c151965f2faf054033ef5f Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Topicality 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, 01 Nov 2016 02:18:09 -0000 --001a11c151965f2faf054033ef5f Content-Type: text/plain; charset=UTF-8 On Monday, October 31, 2016, Stephen Farrell wrote: > > Hiya, > > "Are" or "could be"? > > Serious question. The (non)existence of those in 6962 logs > seems to me to be a) highly pertinent and b) demonstrable. Isn't that an element of log policies - and what clients are logging? These certs definitely exist - but the combination of client behavior and log policies have, so far, prevented them from being logged, and only incidentally so. > > > certificates that have personal information (e.g. given > > name, surname, and physical location) in the subject distinguished > > name or the subject alternative names. > > I can well imagine certs for web servers with some PII > embedded for no good reason. "Don't do that by accident" > would be as good a bit of advice as we could offer in > CT I think as it's really much more an issue for acme > in terms of current IETF work. (Or at least arguably.) > > I fail to see how ACME relates. This is a question of PKI: does TRANS exist solely for elements of browser-mediated Web PKI, or is it for more? In either case, they extend beyond issuance via ACME, and speak to policy, so I don't feel we can be so easily dismissive. > > It is very possible that there > > may be a desire to redact this information (in fact it could even be > > required in some jurisdictions as CT could be considered a database). > > The above has "possible," "may be a desire," "could even > be" and "could be considered" all in one sentence. That > is not a template for a winning argument is it? :-) Are you suggesting these cases are not valid? Because Peter is far from the only one to bring them forward, as we've heard it in the past in relation to ETSI profiles and the EU Trust List from a number of CAs. Are you suggesting this isn't the venue to discuss technical solutions, as it relates to CT, to those problems? > > We already see this with domains in many countries where the full > > registrant details are not publicly available. > > DNS registration policies are not in scope here though. Are you suggesting that CT does not need to be aware of what is possible, either through other WGs actions (such as NSEC/NSEC3) or through other bodies, such as IANA/ICANN? It so, can you articulate what you view as the appropriate scope of function and discussion here? I mean that as an honest question. > > For example a certificate that is used with email > > and contains both the email address and given/surname. It might be > > that the owner of the certificate only wishes to disclose this binding > > to people receiving email from them rather than publicly disclosing > > it. We have also seen requests for certificates that cover phone > > numbers. A similar situation would apply -- having an "unlisted" > > number should be possible, where the subject details (other than phone > > number) are only known to a group of people who communicate with the > > number. > > Again, please show us evidence from the public logs. I am sorry, but I find this argument going against the seeming IETF principles of not favoring a particular vendors policies. What is a public log, in your view? What policies do you believe logs must have for acceptance? How do you respond, given that some CAs and log operators have explicitly stated they want to log email and code signing certificates? Concretely, WoSign is such an example of a CA doing that. It seems the core of your objections are simply "Chromium policies have prevented this" - but as the person responsible for those policies, I don't find that argument particularly compelling or convincing, and certainly not in line with the feedback we've received at Google, nor necessarily how I think Chrome would like to see CT grow. Perhaps it's easier to just ask - do you view CT as only valid for a limited subset of Internet-facing, "publicly trusted," id-kp-serverAuth EKU bearing certificates? If so, could we see if there's consensus with that view? Because at present, the tech neither requires nor states that, and perhaps that's core to determining whether your dichotomy of privacy and confidentiality is accurate and reflected in both the tech and the running code. --001a11c151965f2faf054033ef5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, October 31, 2016, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

"Are" or "could be"?

Serious question. The (non)existence of those in 6962 logs
seems to me to be a) highly pertinent and b) demonstrable.
Isn't that an element of log policies - and what client= s are logging? These certs definitely exist - but the combination of client= behavior and log policies have, so far, prevented them from being logged, = and only incidentally so.
=C2=A0

> certificates that have personal information (e.g. given
> name, surname, and physical location) in the subject distinguished
> name or the subject alternative names.

I can well imagine certs for web servers with some PII
embedded for no good reason. "Don't do that by accident"
would be as good a bit of advice as we could offer in
CT I think as it's really much more an issue for acme
in terms of current IETF work. (Or at least arguably.)


I fail to see how ACME relates. This i= s a question of PKI: does TRANS exist solely for elements of browser-mediat= ed Web PKI, or is it for more? In either case, they extend beyond issuance = via ACME, and speak to policy, so I don't feel we can be so easily dism= issive.
=C2=A0
> It is very possible that there
> may be a desire to redact this information (in fact it could even be > required in some jurisdictions as CT could be considered a database).<= br>
The above has "possible," "may be a desire," "coul= d even
be" and "could be considered" all in one sentence. That
is not a template for a winning argument is it? :-)

Are you suggesting these cases are not valid? Because Peter is far from= the only one to bring them forward, as we've heard it in the past in r= elation to ETSI profiles and the EU Trust List from a number of CAs. Are yo= u suggesting this isn't the venue to discuss technical solutions, as it= relates to CT,=C2=A0to those problems?

=C2=A0
> We already see this with domains in many countries where the full
> registrant details are not publicly available.

DNS registration policies are not in scope here though.
Are you suggesting that CT does not need to be aware of what i= s possible, either through other WGs actions (such as NSEC/NSEC3) or throug= h other bodies, such as IANA/ICANN?

It so, can you= articulate what you view as the appropriate scope of function and discussi= on here? I mean that as an honest question.
=C2=A0
> For example a certificate that is used with email
> and contains both the email address and given/surname.=C2=A0 It might = be
> that the owner of the certificate only wishes to disclose this binding=
> to people receiving email from them rather than publicly disclosing > it.=C2=A0 We have also seen requests for certificates that cover phone=
> numbers.=C2=A0 A similar situation would apply -- having an "unli= sted"
> number should be possible, where the subject details (other than phone=
> number) are only known to a group of people who communicate with the > number.

Again, please show us evidence from the public logs.

<= /div>
I am sorry, but I find this argument going against the seeming IE= TF principles of not favoring a particular vendors policies.

=
What is a public log, in your view? What policies do you believe= logs must have for acceptance? How do you respond, given that some CAs and= log operators have explicitly stated they want to log email and code signi= ng certificates? Concretely, WoSign is such an example of a CA doing that.<= /div>

It seems the core of your objections are simply &q= uot;Chromium policies have prevented this" - but as the person respons= ible for those policies, I don't find that argument particularly compel= ling or convincing, and certainly not in line with the feedback we've r= eceived at Google, nor necessarily how I think Chrome would like to see CT = grow.

Perhaps it's easier to just ask - do you view= CT as only valid for a limited subset of Internet-facing, "publicly t= rusted," id-kp-serverAuth EKU bearing certificates? If so, could we se= e if there's consensus with that view? Because at present, the tech nei= ther requires nor states that, and perhaps that's core to determining w= hether your dichotomy of privacy and confidentiality is accurate and reflec= ted in both the tech and the running code.

--001a11c151965f2faf054033ef5f-- From nobody Mon Oct 31 19:46:01 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 D012F1298CC for ; Mon, 31 Oct 2016 19:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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.497, 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 hDeSU76FWeDv for ; Mon, 31 Oct 2016 19:45:55 -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 76B0B129849 for ; Mon, 31 Oct 2016 19:45:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A6837BE4C; Tue, 1 Nov 2016 02:45:52 +0000 (GMT) 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 HbkTs-tGwmXC; Tue, 1 Nov 2016 02:45:50 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06E0EBE38; Tue, 1 Nov 2016 02:45:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477968350; bh=dbDwJHphvi4d/WghaZ1wPE7Um5JP7QHnVqQf85JFy98=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=rTOWyBsReHSTrmyIAiYeFLWH9bN4F88AVZXsWCs4dOtQ0UQXwwq8l2NDBxe4/zjGB 18X8AszbvaPEqico48IDQ5MNGxq09tV3bO6xjOh9C5A2MtdQaNZ9ibSyo6h9dcN1L4 v10iLcCc9pSBBfac2QpXLXcw9Obbmu9zTkRvURQY= To: Ryan Sleevi References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5ae04a85-f39a-c2f8-d206-7d6d70370fee@cs.tcd.ie> Date: Tue, 1 Nov 2016 02:45:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010705010909070006030208" Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Topicality 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, 01 Nov 2016 02:45:59 -0000 This is a cryptographically signed message in MIME format. --------------ms010705010909070006030208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/11/16 02:18, Ryan Sleevi wrote: > On Monday, October 31, 2016, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> "Are" or "could be"? >> >> Serious question. The (non)existence of those in 6962 logs >> seems to me to be a) highly pertinent and b) demonstrable. >=20 >=20 > Isn't that an element of log policies=20 No, that's an empirical question, to rephrase it: Show me the certs:-) Really, it is a serious question when considering the difference between corporate secrecy and privacy. I totally accept that there are issues with the former (e.g. with .example.com) but I'd like to see evidence if someone claims that the latter is an issue. ("The latter" being the privacy of humans, not the secrecy of organisations.) > - and what clients are logging? These > certs definitely exist - but the combination of client behavior and log= > policies have, so far, prevented them from being logged, and only > incidentally so. I don't follow that, can you elaborate? >=20 >=20 >> >>> certificates that have personal information (e.g. given >>> name, surname, and physical location) in the subject distinguished >>> name or the subject alternative names. >> >> I can well imagine certs for web servers with some PII >> embedded for no good reason. "Don't do that by accident" >> would be as good a bit of advice as we could offer in >> CT I think as it's really much more an issue for acme >> in terms of current IETF work. (Or at least arguably.) >> >> > I fail to see how ACME relates. This is a question of PKI: does TRANS e= xist > solely for elements of browser-mediated Web PKI, or is it for more?=20 The WG charter calls out web site cert misissuance as thing#1 and http/tls as the same (in the deliverable bit). Acme relates as follows: if there are certs containing PII, instead of trying to handle those via redaction during the act of CT logging, one could recommend not including the PII in the certs. (It is arguable that that is a sufficient answer, but nonetheless it could be argued to be one, in the context of the IETF.) > In > either case, they extend beyond issuance via ACME, and speak to policy,= so > I don't feel we can be so easily dismissive. >=20 I was not dismissive. I asked for evidence. I did not use the word policy at all. >=20 >>> It is very possible that there >>> may be a desire to redact this information (in fact it could even be >>> required in some jurisdictions as CT could be considered a database).= >> >> The above has "possible," "may be a desire," "could even >> be" and "could be considered" all in one sentence. That >> is not a template for a winning argument is it? :-) >=20 >=20 > Are you suggesting these cases are not valid?=20 No. I'm claiming that his argument is unconvincing. I'm very very happy to continue to pick at that one sentence if it helps the overall argument, but I doubt that it will;-) I said more than once in my mail that corporate secrecy can be a valid requirement to posit. Feel free to ignore that as often as you wish. > Because Peter is far from the > only one to bring them forward, as we've heard it in the past in relati= on > to ETSI profiles and the EU Trust List from a number of CAs. Are you > suggesting this isn't the venue to discuss technical solutions, as it > relates to CT, to those problems? That last is not great rhetoric. Do you really expect me to say "yes, this is not the place to talk technical solutions"? Hrmpf;-) ETSI profiles and EU trust lists are all fine and good things (in theory at least). I do regard a lot of argument about those are purely theoretic having seen 20+ years of such theory not resolving into reality. And again I did more than once ack that corporate secrecy is a valid requirement to posit in some forms. >=20 >=20 >=20 >>> We already see this with domains in many countries where the full >>> registrant details are not publicly available. >> >> DNS registration policies are not in scope here though. >=20 >=20 > Are you suggesting that CT does not need to be aware of what is possibl= e, > either through other WGs actions (such as NSEC/NSEC3) or through other > bodies, such as IANA/ICANN? I've no clue what the above means, sorry. Guessing though, as to what might constitute an answer: I do not think that CT needs to try to address problematic things like ICANN registrar policies that call for PII to be generally visible. To the extent one has a problem with that, (and I do as it happens) the trans WG is the wrong venue, was my point. >=20 > It so, can you articulate what you view as the appropriate scope of > function and discussion here? I mean that as an honest question. As with the above, I'm too confused to answer. (And figure there's some underlying miscommunication going on here.) >=20 >=20 >>> For example a certificate that is used with email >>> and contains both the email address and given/surname. It might be >>> that the owner of the certificate only wishes to disclose this bindin= g >>> to people receiving email from them rather than publicly disclosing >>> it. We have also seen requests for certificates that cover phone >>> numbers. A similar situation would apply -- having an "unlisted" >>> number should be possible, where the subject details (other than phon= e >>> number) are only known to a group of people who communicate with the >>> number. >> >> Again, please show us evidence from the public logs. >=20 >=20 > I am sorry, but I find this argument going against the seeming IETF > principles of not favoring a particular vendors policies. Huh? Asking for evidence of the existence of a claimed problem goes against what? I'm very confused tbh. >=20 > What is a public log, in your view? What policies do you believe logs m= ust > have for acceptance? How do you respond, given that some CAs and log > operators have explicitly stated they want to log email and code signin= g > certificates? Concretely, WoSign is such an example of a CA doing that.= >=20 > It seems the core of your objections are simply "Chromium policies have= > prevented this" -=20 Eh, no. That's entirely and utterly incorrect to the point where I wonder if you got mixed up by the indenting in the mail thread or something. (Or perhaps you are reading between the lines and finding things that are not really there, at least between the lines as I write 'em;-) > but as the person responsible for those policies, I don't > find that argument particularly compelling or convincing, and certainly= not > in line with the feedback we've received at Google, nor necessarily how= I > think Chrome would like to see CT grow. >=20 > Perhaps it's easier to just ask - do you view CT as only valid for a > limited subset of Internet-facing, "publicly trusted," id-kp-serverAuth= EKU > bearing certificates? If so, could we see if there's consensus with tha= t > view? Because at present, the tech neither requires nor states that, an= d > perhaps that's core to determining whether your dichotomy of privacy an= d > confidentiality is accurate and reflected in both the tech and the runn= ing > code. I remain as confused as I was a minute ago;-) S. >=20 >=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 --------------ms010705010909070006030208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDEw MjQ1NTBaMC8GCSqGSIb3DQEJBDEiBCB7xrbItX9o0DbaAqCR4ZvKKpzZ6ee3imOZN4RfzBOi wDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCZXqRJDcw1zuHrWBW9AKQyWrEq+0UKkQOnNYNATruxSIKMeU8dT25c HBP643hKVmSJv9YE46KuiWSddrJ+UQg1iVgPGoXCp4kwHDmqHCf2/HN75Tf/IntoMO5pACHe Mo1khQdRB2aByg+WTr/6jcN9ziNmz3ZwC4jcCmrwxMFP2nDmiSiNsXfk2KHtVEzmAyDN/KD/ U1Yi0OYr506dJshoEEJsuFNPwdWc9eaDA+tZg4dnE+ZN/HejE7usNE02RGK3y8QfaGcL6IdX tNjwc1TKvCrmuB1nFDk7ePAvgg3KT1YHwfdHRn+kgbBLPK5I6Ab069+NAG7QYWAs0qadJ62H AAAAAAAA --------------ms010705010909070006030208-- From nobody Mon Oct 31 20:35: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 C42E6129849 for ; Mon, 31 Oct 2016 20:35:01 -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 XlcwqHTy-NUa for ; Mon, 31 Oct 2016 20:34:59 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C141412967D for ; Mon, 31 Oct 2016 20:34:59 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id i127so267448193oia.2 for ; Mon, 31 Oct 2016 20:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ie9P8Af3FGNkQLkA7HLrsXgHZHPPtKGeu+0WFIfAaFQ=; b=r6OHtVv3YdLNwL7IHQT5sqc5o6u84m5FmzzC5MpGNMhqEltUwpg4ed8zGovRV+wnp0 Fr3IcO0hsQ6wq7cjJeV2qn3ZGtH80gRRLVlz24/ycups68ZSxMltE1AyyfIN9xvSRH5x cymeKy3IyaNuWpbv3/GvKbpYcAVSmA89WXZegrPOAHFlS/at8FhiKOu1Pld6MItYrp5C 1RlvcsyujP9VLVIxiaJlwKb9l07vH1W7boLw+ABFOvc49Yu0DOIa19RDwKVPnmktQlas hrJdyoSyAN8OBJgYC75cMnb53GH43i/QJxTUWD+XJ4lBQnK6k2cBbpD6wBSFJuWDAQkG VWPQ== 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=Ie9P8Af3FGNkQLkA7HLrsXgHZHPPtKGeu+0WFIfAaFQ=; b=Jm4JvI1CaLHtHngNUq5YbFe3i26lNtAtDBz9xBKAW6Eeu/CVIVPdk6gKXOr2wpIUaH N99XRrL7m2Bl2bXNI5igmPJEA0akdECPcZ90TiNZITKWT6OXxwva1RW8uhzjr8FHBZPr k4QI7TUBuZRDRV/77TGU/GMY1z5xKN2iYKATfOPJ2NBCdy+BsMAGo9orKzQQMSuMFtbq jZJLsAm8MrIWyHQ9ztppU3jyRZt0eREUIo8LJC0PIZ3yC4+Mk+O0x9OZlm3B8coAHZoN 6Z+106+TefZ98ylb94Hl2rxCTdfaw60FEHP1we6P37o2R0EYUGeU9b1FLdlO35S/qBRz HuFA== X-Gm-Message-State: ABUngvf9Pm8RXKSi401zVOeZ4xLisiWISgpnEetEhjmGWD5ii/FllBbtEWwuTToLcIGSgX5dmKCSZJtXG1zwlQ== X-Received: by 10.107.146.67 with SMTP id u64mr21655103iod.34.1477971298481; Mon, 31 Oct 2016 20:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.39.68 with HTTP; Mon, 31 Oct 2016 20:34:57 -0700 (PDT) In-Reply-To: References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> From: Peter Bowen Date: Mon, 31 Oct 2016 20:34:57 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Topicality 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, 01 Nov 2016 03:35:02 -0000 On Mon, Oct 31, 2016 at 6:33 PM, Stephen Farrell wrote: > On 01/11/16 01:04, Peter Bowen wrote: >> On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell wrote: >>> >>> Can you call out the privacy aspect that applies to humans >>> and that is a real part of the question related to support for >>> redaction in CT? >> >> There are > > "Are" or "could be"? > > Serious question. The (non)existence of those in 6962 logs > seems to me to be a) highly pertinent and b) demonstrable. I'm not sure how you get that these don't exist. Using the given name and surname attribute types as indications of PII, and removing one issuer's apparently confusion between surname and serial number, I see thousands. A few examples: https://crt.sh/?id=9031476 https://crt.sh/?id=8997821 https://crt.sh/?id=45107003 https://crt.sh/?id=31130948 >> certificates that have personal information (e.g. given >> name, surname, and physical location) in the subject distinguished >> name or the subject alternative names. > > I can well imagine certs for web servers with some PII > embedded for no good reason. "Don't do that by accident" > would be as good a bit of advice as we could offer in > CT I think as it's really much more an issue for acme > in terms of current IETF work. (Or at least arguably.) I wouldn't call this by accident. Microsoft's root program requirements (http://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx) explicitly call out Individual Validation (IV) is section 4(a)(15). IV, by definition, puts Personal Information in the subject of the certificate. >> It is very possible that there >> may be a desire to redact this information (in fact it could even be >> required in some jurisdictions as CT could be considered a database). > > The above has "possible," "may be a desire," "could even > be" and "could be considered" all in one sentence. That > is not a template for a winning argument is it? :-) I'm not a lawyer, so I'm not going to make any legal conclusions. So I'm going to continue to qualify anything related to legislation that may exist in certain jurisdictions in which CT logs may exist. Yes, that is heavily caveated again, so feel free to ignore, but it is a real concern. >> We already see this with domains in many countries where the full >> registrant details are not publicly available. > > DNS registration policies are not in scope here though. I wasn't suggesting that they were. I was using it to demonstrate a related case where it was judged that restriction of information was beneficial. >> >> Additionally, while 6962-bis does focus on certificates used for TLS >> server authentication, there are other types of certificates that >> could be logged. > > How many have been logged? Serious question. If there is a > real problem here, I'm interested. If there is not, then I, > for one, am not. Finding the evidence either way should not > be hard. Why does it matter how many have currently been logged? Isn't the point of this WG to create tech spec for a certificate log that can log any kind of certificate? Is it possible emailProtection certs aren't being logged because of privacy concerns? Thanks, Peter From nobody Mon Oct 31 20:38:36 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 62E1412967D for ; Mon, 31 Oct 2016 20:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tvs1mnnIOFt2 for ; Mon, 31 Oct 2016 20:38:33 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDB01294B2 for ; Mon, 31 Oct 2016 20:38:33 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 3E60530002825 for ; Mon, 31 Oct 2016 20:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=N/MJp/HpAoz8Xr1fsFn1E9IGlOc=; b= MbnM/LD2w22gI7q7gdamLXyQu3IehgcK6jZwxeKofeEDRnc7mI5ZJ6wOiXQyT9qQ z2Eokd5wJefX/yzs3+Bi/iliGoUJzlZ8x702Hq6y5l7sKZ7hX4Z3vINroBm81Dkv AVaBrdqascfqCUwFnfGBi/fW7vEIHpz2HHMD1TuYJQk= Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPSA id 1CD863000281E for ; Mon, 31 Oct 2016 20:38:33 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id v84so111652219oie.3 for ; Mon, 31 Oct 2016 20:38:33 -0700 (PDT) X-Gm-Message-State: ABUngvd0KMROjvBvc7+uroE1d08rtE2Q562KVqFkcYEVCPlaUnso3H/BGjSzwGmFnyCqzSX7vq1Dg+YRhCeQMw== X-Received: by 10.107.14.65 with SMTP id 62mr21551005ioo.142.1477971512469; Mon, 31 Oct 2016 20:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.130 with HTTP; Mon, 31 Oct 2016 20:38:31 -0700 (PDT) In-Reply-To: <5ae04a85-f39a-c2f8-d206-7d6d70370fee@cs.tcd.ie> References: <34b58ff9-a2ba-3e6b-c065-36ed9cc0aaac@gmail.com> <41379c61-a1db-8a3d-f3f0-63507abb59b0@cs.tcd.ie> <5ae04a85-f39a-c2f8-d206-7d6d70370fee@cs.tcd.ie> From: Ryan Sleevi Date: Mon, 31 Oct 2016 20:38:31 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ryan Sleevi , Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Topicality 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, 01 Nov 2016 03:38:34 -0000 On Mon, Oct 31, 2016 at 7:45 PM, Stephen Farrell wrote: > > No, that's an empirical question, to rephrase it: Show me the > certs:-) > > Really, it is a serious question when considering the difference > between corporate secrecy and privacy. I totally accept that there > are issues with the former (e.g. with .example.com) > but I'd like to see evidence if someone claims that the latter > is an issue. ("The latter" being the privacy of humans, not the > secrecy of organisations.) "Show me the certs with PII" is a somewhat problematic stance, isn't it? To what end will it help you or the community evaluate? I'm not sure I accept at all your line of questioning, so perhaps, before needlessly dropping PII, you can suggest how that would change your response, if at all. >> - and what clients are logging? These >> certs definitely exist - but the combination of client behavior and log >> policies have, so far, prevented them from being logged, and only >> incidentally so. > > I don't follow that, can you elaborate? The extant logs all generally have policies that restrict the roots from which they log, or even more narrowly, restrict the purposes for certs which they log. Similarly, the majority of log clients - those submitting to logs - restrict what they log to a subset of what they see. Similarly, these log clients only see particular types of certs, rather than the broader corpus out there. For concrete example: It's certainly be technically possible that Google could decide to log every S/MIME certificate it saw. But would it be wise? Of course not. > The WG charter calls out web site cert misissuance as thing#1 > and http/tls as the same (in the deliverable bit). > > Acme relates as follows: if there are certs containing PII, > instead of trying to handle those via redaction during the > act of CT logging, one could recommend not including the PII > in the certs. (It is arguable that that is a sufficient > answer, but nonetheless it could be argued to be one, in the > context of the IETF.) Of course, that doesn't address the issue pointed out earlier by Peter - that certificates are in use for more than just TLS, and issued by means more than ACME. It sounds like your suggestion is only certs issued by ACME should be logged via CT. Naturally, I reject that conclusion. You're directly proposing policy solutions, right now ("Don't log"), and rejecting even exploring or entertaining the technical discussion. Is that intentional, or simply a misunderstanding? >> Are you suggesting that CT does not need to be aware of what is possible, >> either through other WGs actions (such as NSEC/NSEC3) or through other >> bodies, such as IANA/ICANN? > > I've no clue what the above means, sorry. > > Guessing though, as to what might constitute an answer: I do > not think that CT needs to try to address problematic things > like ICANN registrar policies that call for PII to be generally > visible. To the extent one has a problem with that, (and I do > as it happens) the trans WG is the wrong venue, was my point. I'm suggesting that CT needs to at least be aware of other privacy preserving efforts - such as NSEC3 or DPRIVE - and as such, cannot unconditionally say "Don't do that", when other IETF technologies support "do that" - at least, not without a reasonable discussion of why. I don't believe you've posed why, other than you don't like it, or don't feel the use case exists, but if that's the level of discussion, then I fear we will make no progress, especially given that even the original message contained such evidence. My hope was that here in the IETF we could try to find solutions for problems, and only punt them when we believe they are better served elsewhere - but I feel like your line of reasoning is to try to punt anything you don't like. >> It so, can you articulate what you view as the appropriate scope of >> function and discussion here? I mean that as an honest question. > > As with the above, I'm too confused to answer. (And figure > there's some underlying miscommunication going on here.) Are the only certificates CT cares about TLS server certificates? If not, then you already have ample evidence in the form of S/MIME certificates, or in digital signature certificates, that privacy is an aspect of the discussion. If you don't agree with that, let's find out why. If you do, then can we accept there's a privacy argument, and not just a corporate secrecy requirement, and move on to the technological discussion?