From nobody Mon Feb 1 02:24:02 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6F21B301B for ; Mon, 1 Feb 2016 02:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U599RWcnoGT for ; Mon, 1 Feb 2016 02:24:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7F91B3015 for ; Mon, 1 Feb 2016 02:24:00 -0800 (PST) Received: from localhost ([::1]:36262 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQBeG-00069B-Ih; Mon, 01 Feb 2016 02:23:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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: Mon, 01 Feb 2016 10:23:56 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/97#comment:1 Message-ID: <080.6a83e16be95e70d20aae59adf2497f0a@tools.ietf.org> References: <065.543a100087070dd152bde158ebf8bcd5@tools.ietf.org> X-Trac-Ticket-ID: 97 In-Reply-To: <065.543a100087070dd152bde158ebf8bcd5@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 10:24:02 -0000 #97: Allocate an OID for CMS precertificates Changes (by rob.stradling@comodo.com): * owner: benl@google.com => rob.stradling@comodo.com Comment: Cancel that request. Symantec have agreed to donate some OIDs under the thawte 1.3.101 OID arc. Let's use one of them here. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 1 02:25:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7174A1B301F for ; Mon, 1 Feb 2016 02:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYbuCIdvUcFe for ; Mon, 1 Feb 2016 02:25:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573801B3015 for ; Mon, 1 Feb 2016 02:25:29 -0800 (PST) Received: from localhost ([::1]:36303 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQBfe-00037f-A2; Mon, 01 Feb 2016 02:25:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hadfieldp@google.com, rob.stradling@comodo.com, paul@nohats.ca X-Trac-Project: trans Date: Mon, 01 Feb 2016 10:25:22 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/87#comment:3 Message-ID: <071.d48f15484bd0b372a0bf45d920f7022f@tools.ietf.org> References: <056.bd3f7d75e177baac5a41da407f8d0a60@tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <056.bd3f7d75e177baac5a41da407f8d0a60@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hadfieldp@google.com, 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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #87 (rfc6962-bis): Add reference to threat analysis document X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 10:25:30 -0000 #87: Add reference to threat analysis document Changes (by hadfieldp@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => hadfieldp@google.com * status: new => assigned -- -----------------------------+----------------------------------- Reporter: benl@google.com | Owner: hadfieldp@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+----------------------------------- Ticket URL: trans From nobody Mon Feb 1 02:39:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DC61B3043 for ; Mon, 1 Feb 2016 02:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iks4uAUDo4fo for ; Mon, 1 Feb 2016 02:39:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05941B301A for ; Mon, 1 Feb 2016 02:39:25 -0800 (PST) Received: from localhost ([::1]:36752 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQBtB-0002Gb-9o; Mon, 01 Feb 2016 02:39:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, benl@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 10:39:21 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/94#comment:5 Message-ID: <072.e751ed9e639e1cb20aa36698d61a4c0d@tools.ietf.org> References: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, benl@google.com, rob.stradling@comodo.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 10:39:27 -0000 #94: Fetching of inclusion proofs: Why and when are clients expected to do this? Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 02:55:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058F71B3088 for ; Mon, 1 Feb 2016 02:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 zO3-_1oQYoWT for ; Mon, 1 Feb 2016 02:55:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0694B1B307E for ; Mon, 1 Feb 2016 02:55:40 -0800 (PST) Received: from localhost ([::1]:37195 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQC8x-0006tZ-Eg; Mon, 01 Feb 2016 02:55:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, mhs@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 10:55:39 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/138#comment:1 Message-ID: <068.8d0d0e83e2ac127c924c973cd410005f@tools.ietf.org> References: <053.8f7a6c4f44f8a37e28a8e378e222bb45@tools.ietf.org> X-Trac-Ticket-ID: 138 In-Reply-To: <053.8f7a6c4f44f8a37e28a8e378e222bb45@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, mhs@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201105540.0694B1B307E@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 02:55:40 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #138 (rfc6962-bis): use of term before defining it X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 10:55:41 -0000 #138: use of term before defining it Comment (by mhs@google.com): Pull request is https://github.com/google/certificate-transparency- rfcs/pull/105 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@bbn.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 Mon Feb 1 02:56:16 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8875F1B308D for ; Mon, 1 Feb 2016 02:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSiKqJLU_fPh for ; Mon, 1 Feb 2016 02:56:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98941B3086 for ; Mon, 1 Feb 2016 02:56:13 -0800 (PST) Received: from localhost ([::1]:37222 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQC9V-0006wy-KQ; Mon, 01 Feb 2016 02:56:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 10:56:13 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/50#comment:3 Message-ID: <080.838992b95548f813d746ab4c266d2fb1@tools.ietf.org> References: <065.24ee65ca0b49a0d2612054e06e01d6c3@tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <065.24ee65ca0b49a0d2612054e06e01d6c3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #50 (client-behavior): Ordering of revocation checking and SCT processing by TLS Clients X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 10:56:15 -0000 #50: Ordering of revocation checking and SCT processing by TLS Clients Changes (by katjoyce@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => katjoyce@google.com -- --------------------------------------+---------------------------------- Reporter: rob.stradling@comodo.com | Owner: katjoyce@google.com Type: defect | Status: new Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | --------------------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 02:57:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742301B308D for ; Mon, 1 Feb 2016 02:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpfLfuCHE2je for ; Mon, 1 Feb 2016 02:57:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD981B3064 for ; Mon, 1 Feb 2016 02:57:03 -0800 (PST) Received: from localhost ([::1]:37235 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCAB-0006yl-Qw; Mon, 01 Feb 2016 02:56:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, benl@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 10:56:55 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/94#comment:6 Message-ID: <072.8baeb834f2520a53511250e3434746e2@tools.ietf.org> References: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, benl@google.com, rob.stradling@comodo.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 10:57:04 -0000 #94: Fetching of inclusion proofs: Why and when are clients expected to do this? Comment (by eranm@google.com): From the mailing list (Quoting Steve Kent): "I think the text in draft-dseomn-trans-browsers-00.txt addresses the topic of what a browser can/should do re SCTs more clearly that 6962-bis, although the browser I-D not been updated to reflect the possibility of an inclusion proof being sent as part of an SCT. Also, the topic of when a server should send an inclusion proof, or when a CA should embed a proof in an SCT in a cert, should be addressed in I-Ds that thoroughly describe server and CA behaviors, e.g., draft-kseo-trans-ca-subject-00.txt." -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:03:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40CD1B3093 for ; Mon, 1 Feb 2016 03:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lL6u1SamK5a for ; Mon, 1 Feb 2016 03:03:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EB01B3067 for ; Mon, 1 Feb 2016 03:03:22 -0800 (PST) Received: from localhost ([::1]:37422 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCGM-0007mK-E0; Mon, 01 Feb 2016 03:03:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, benl@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:03:18 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/94#comment:7 Message-ID: <072.568952821fc2c962243c9f1858a9427c@tools.ietf.org> References: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, benl@google.com, rob.stradling@comodo.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:03:23 -0000 #94: Fetching of inclusion proofs: Why and when are clients expected to do this? Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/106 The text is more terse than originally suggested, but should capture the original intent. -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:09:02 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CA41B3064 for ; Mon, 1 Feb 2016 03:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbrTNcIjQErH for ; Mon, 1 Feb 2016 03:08:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA661B309A for ; Mon, 1 Feb 2016 03:08:57 -0800 (PST) Received: from localhost ([::1]:37634 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCLn-0001oc-Q0; Mon, 01 Feb 2016 03:08:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, mhs@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:08:55 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/138#comment:2 Message-ID: <068.627ea0179449f138e06cee6bd6f353d6@tools.ietf.org> References: <053.8f7a6c4f44f8a37e28a8e378e222bb45@tools.ietf.org> X-Trac-Ticket-ID: 138 In-Reply-To: <053.8f7a6c4f44f8a37e28a8e378e222bb45@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, mhs@google.com, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201110857.AEA661B309A@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 03:08:57 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #138 (rfc6962-bis): use of term before defining it X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:09:01 -0000 #138: use of term before defining it Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/ccd799087273e053cc41743838168d463616967f -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:12:56 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822281B30A3 for ; Mon, 1 Feb 2016 03:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qAV_z9c2Jan for ; Mon, 1 Feb 2016 03:12:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E701A8ACD for ; Mon, 1 Feb 2016 03:12:53 -0800 (PST) Received: from localhost ([::1]:37889 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCPd-0003jr-Cb; Mon, 01 Feb 2016 03:12:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hadfieldp@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:12:53 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/118#comment:1 Message-ID: <068.04a7ae0488c6261e40f44e3f2bdba128@tools.ietf.org> References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-Trac-Ticket-ID: 118 In-Reply-To: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:12:54 -0000 #118: Monitor function description problem Changes (by hadfieldp@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => hadfieldp@google.com * status: new => assigned -- --------------------------+----------------------------------- Reporter: kent@bbn.com | Owner: hadfieldp@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+----------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:15:23 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2AC1B30AC for ; Mon, 1 Feb 2016 03:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 UBa30CfOdeJx for ; Mon, 1 Feb 2016 03:15:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB3E1B30A6 for ; Mon, 1 Feb 2016 03:15:21 -0800 (PST) Received: from localhost ([::1]:37959 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCS0-0007T7-CE; Mon, 01 Feb 2016 03:15:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:15:20 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:6 Message-ID: <072.323cfff54ad7001d8ca2fba2ba5d557a@tools.ietf.org> References: <057.0e214459f63470fffd09b6c24291b4b3@tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <057.0e214459f63470fffd09b6c24291b4b3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201111521.0FB3E1B30A6@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 03:15:21 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #95 (rfc6962-bis): Should the response size to get-entries be a part of the log metadata? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:15:22 -0000 #95: Should the response size to get-entries be a part of the log metadata? Changes (by eranm@google.com): * milestone: => review Comment: There's a consensus among the authors that adding text suggesting a response size for get-entries is not very useful ultimately and so is not essential to the document. Rob explains: "For crt.sh's, I currently fetch (up to) 1,024 entries per get-entries request. I arrived at this strategy by trial and error. It would be nice to have more determinism here, but simply suggesting a limit in the doc wouldn't actually help with that, because I'd still have to figure out what the logs are actually doing by trial and error. So I agree with Ben: let's close ticket 95 as a WONTFIX." From an implementation perspective a suggestion will not help. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:23:42 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DECC1B30CA for ; Mon, 1 Feb 2016 03:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm_0qQWLwEQY for ; Mon, 1 Feb 2016 03:23:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518091B30C9 for ; Mon, 1 Feb 2016 03:23:39 -0800 (PST) Received: from localhost ([::1]:38295 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCa2-0000Bl-7d; Mon, 01 Feb 2016 03:23:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:23:38 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/119#comment:1 Message-ID: <068.3fb24693630f000777b92fbb03f2e6d6@tools.ietf.org> References: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #119 (rfc6962-bis): confusing wording about log checking in Introduction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:23:40 -0000 #119: confusing wording about log checking in Introduction Changes (by katjoyce@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => katjoyce@google.com -- --------------------------+---------------------------------- Reporter: kent@bbn.com | Owner: katjoyce@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:29:59 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D851B30E0 for ; Mon, 1 Feb 2016 03:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 e5b98HVa-VNz for ; Mon, 1 Feb 2016 03:29:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435CB1B30DD for ; Mon, 1 Feb 2016 03:29:57 -0800 (PST) Received: from localhost ([::1]:38424 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCg8-0006Cf-0n; Mon, 01 Feb 2016 03:29:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, mhs@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:29:55 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/132#comment:1 Message-ID: <076.aee34bf0940d84be14e5d98ee0378ed2@tools.ietf.org> References: <061.3cb1275ccf9a2813644b1e30ff83a68f@tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <061.3cb1275ccf9a2813644b1e30ff83a68f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, mhs@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201112957.435CB1B30DD@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 03:29:57 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #132 (rfc6962-bis): unclear motivation for and handling of re-logging entries from a frozen log X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:29:58 -0000 #132: unclear motivation for and handling of re-logging entries from a frozen log Comment (by mhs@google.com): Reviewed in https://github.com/google/certificate-transparency- rfcs/pull/107 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- david@mandelberg.org | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:42:04 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D61B310D for ; Mon, 1 Feb 2016 03:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQGn5ShEDxAY for ; Mon, 1 Feb 2016 03:42:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE1B1B3109 for ; Mon, 1 Feb 2016 03:42:02 -0800 (PST) Received: from localhost ([::1]:38843 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCrq-0005gl-8V; Mon, 01 Feb 2016 03:42:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:42:02 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/119#comment:2 Message-ID: <068.a945a78610b31ba5e86dafe7a917a5ce@tools.ietf.org> References: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #119 (rfc6962-bis): confusing wording about log checking in Introduction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:42:04 -0000 #119: confusing wording about log checking in Introduction Comment (by katjoyce@google.com): Pull request: https://github.com/google/certificate-transparency- rfcs/pull/108 -- --------------------------+---------------------------------- Reporter: kent@bbn.com | Owner: katjoyce@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:42:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285221B3108 for ; Mon, 1 Feb 2016 03:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT-NA2H8I59M for ; Mon, 1 Feb 2016 03:42:32 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BA41B3112 for ; Mon, 1 Feb 2016 03:42:32 -0800 (PST) Received: from localhost ([::1]:38850 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCsI-0005iK-7d; Mon, 01 Feb 2016 03:42:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, linus@nordu.net X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:42:30 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/109#comment:2 Message-ID: <077.2b8657946d03e62c3d30b9dc15fcf5a1@tools.ietf.org> References: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #109 (rfc6962-bis): log shutdown timeline and behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:42:34 -0000 #109: log shutdown timeline and behavior Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com -- -----------------------------------+------------------------------- Reporter: dkg@fifthhorseman.net | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 03:48:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254C81B3125 for ; Mon, 1 Feb 2016 03:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 bRueogRSgMzG for ; Mon, 1 Feb 2016 03:48:35 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF1A1B3126 for ; Mon, 1 Feb 2016 03:48:35 -0800 (PST) Received: from localhost ([::1]:39012 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQCy9-0005PX-SC; Mon, 01 Feb 2016 03:48:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, paul@nohats.ca X-Trac-Project: trans Date: Mon, 01 Feb 2016 11:48:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:7 Message-ID: <072.ca8e9079cf5a0e3f6c8baa6615aaf5a2@tools.ietf.org> References: <057.0e214459f63470fffd09b6c24291b4b3@tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <057.0e214459f63470fffd09b6c24291b4b3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, paul@nohats.ca, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201114835.4DF1A1B3126@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 03:48:35 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #95 (rfc6962-bis): Should the response size to get-entries be a part of the log metadata? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 11:48:36 -0000 #95: Should the response size to get-entries be a part of the log metadata? Changes (by paul@nohats.ca): * status: new => closed * resolution: => wontfix -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 04:02:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B6F1B316A for ; Mon, 1 Feb 2016 04:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q4wk30b778W for ; Mon, 1 Feb 2016 04:02:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52D41B3164 for ; Mon, 1 Feb 2016 04:02:04 -0800 (PST) Received: from localhost ([::1]:39337 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQDBE-0008GW-Gj; Mon, 01 Feb 2016 04:02:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 12:02:04 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:3 Message-ID: <072.03d7bc246c466f207455d811038b51ed@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 12:02:06 -0000 #115: Verify that recommended consistency checking algorithm is correct Changes (by katjoyce@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => katjoyce@google.com Comment: Eran has fixed this for consistency proofs but has not yet checked inclusion proofs - I will do that. -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 04:08:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073781B3192 for ; Mon, 1 Feb 2016 04:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA7K7tPy3q3A for ; Mon, 1 Feb 2016 04:08:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3341B318F for ; Mon, 1 Feb 2016 04:08:50 -0800 (PST) Received: from localhost ([::1]:39459 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQDHd-0000co-JV; Mon, 01 Feb 2016 04:08:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hadfieldp@google.com, rob.stradling@comodo.com, paul@nohats.ca X-Trac-Project: trans Date: Mon, 01 Feb 2016 12:08:41 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/87#comment:4 Message-ID: <071.87b34b8b7a871c527aefab69722c5c2d@tools.ietf.org> References: <056.bd3f7d75e177baac5a41da407f8d0a60@tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <056.bd3f7d75e177baac5a41da407f8d0a60@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hadfieldp@google.com, 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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #87 (rfc6962-bis): Add reference to threat analysis document X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 12:08:52 -0000 #87: Add reference to threat analysis document Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/04998a33dd7d6008460b33c7b871efb77a4a66e3 -- -----------------------------+----------------------------------- Reporter: benl@google.com | Owner: hadfieldp@google.com Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+----------------------------------- Ticket URL: trans From nobody Mon Feb 1 04:11:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6DE1B31A4 for ; Mon, 1 Feb 2016 04:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDs8ygZkxPEZ for ; Mon, 1 Feb 2016 04:11:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179421B319D for ; Mon, 1 Feb 2016 04:11:36 -0800 (PST) Received: from localhost ([::1]:39552 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQDKS-00016o-08; Mon, 01 Feb 2016 04:11:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 12:11:35 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:4 Message-ID: <072.91066c242bf0287ea956cb8166e52df1@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 12:11:37 -0000 #115: Verify that recommended consistency checking algorithm is correct Comment (by katjoyce@google.com): Inclusion proof description exactly matches code, with no room for interpretation. -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 04:11:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF601B31AD for ; Mon, 1 Feb 2016 04:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9ch55D5G_F3 for ; Mon, 1 Feb 2016 04:11:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436F41B31AC for ; Mon, 1 Feb 2016 04:11:53 -0800 (PST) Received: from localhost ([::1]:39562 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQDKj-0001Br-3c; Mon, 01 Feb 2016 04:11:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 12:11:53 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:5 Message-ID: <072.2d06b910004435fa7856f2553d5d26d8@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 12:11:54 -0000 #115: Verify that recommended consistency checking algorithm is correct Changes (by katjoyce@google.com): * status: new => closed * resolution: => fixed -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 04:13:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109B1B31BB for ; Mon, 1 Feb 2016 04:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak12VHEUGFXE for ; Mon, 1 Feb 2016 04:13:31 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D1F1B31A4 for ; Mon, 1 Feb 2016 04:13:31 -0800 (PST) Received: from localhost ([::1]:39610 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQDMI-0002qf-Tc; Mon, 01 Feb 2016 04:13:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 12:13:30 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/119#comment:3 Message-ID: <068.8b87560f5c616f9ea820529d948e55a0@tools.ietf.org> References: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #119 (rfc6962-bis): confusing wording about log checking in Introduction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 12:13:32 -0000 #119: confusing wording about log checking in Introduction Changes (by katjoyce@google.com): * milestone: => review -- --------------------------+---------------------------------- Reporter: kent@bbn.com | Owner: katjoyce@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 05:22:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794CB1A8FD5 for ; Mon, 1 Feb 2016 05:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqGwPBA1lhm1 for ; Mon, 1 Feb 2016 05:22:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681B31A8FD4 for ; Mon, 1 Feb 2016 05:22:51 -0800 (PST) Received: from localhost ([::1]:42122 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQERP-0008Uu-1e; Mon, 01 Feb 2016 05:22:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hadfieldp@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 13:22:51 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/57#comment:1 Message-ID: <080.58e9f2bf654d84b1de614305e61bced0@tools.ietf.org> References: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #57 (client-behavior): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 13:22:52 -0000 #57: Clients MUST NOT match the redaction label with a "*" label Changes (by hadfieldp@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => hadfieldp@google.com * status: new => assigned -- --------------------------------------+----------------------------------- Reporter: rob.stradling@comodo.com | Owner: hadfieldp@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | --------------------------------------+----------------------------------- Ticket URL: trans From nobody Mon Feb 1 05:30:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8694D1A9032 for ; Mon, 1 Feb 2016 05:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 ZSuOir_RBC3d for ; Mon, 1 Feb 2016 05:30:35 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0CC1A8F3E for ; Mon, 1 Feb 2016 05:30:35 -0800 (PST) Received: from localhost ([::1]:42457 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQEYt-0000xa-1R; Mon, 01 Feb 2016 05:30:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, hadfieldp@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 13:30:34 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/57#comment:2 Message-ID: <080.bbe0247bb677fbbce4bd6d763642f2ba@tools.ietf.org> References: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201133035.AA0CC1A8F3E@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 05:30:35 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #57 (client-behavior): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 13:30:36 -0000 #57: Clients MUST NOT match the redaction label with a "*" label Changes (by hadfieldp@google.com): * owner: hadfieldp@google.com => draft-ietf-trans- rfc6962-bis@tools.ietf.org * status: assigned => new -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 1 05:31:07 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357B81A903C for ; Mon, 1 Feb 2016 05:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 O6tkAbeCEnDW for ; Mon, 1 Feb 2016 05:31:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BEA1A9036 for ; Mon, 1 Feb 2016 05:30:57 -0800 (PST) Received: from localhost ([::1]:42479 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQEZF-0002KL-N7; Mon, 01 Feb 2016 05:30:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, mhs@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 13:30:57 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/133#comment:1 Message-ID: <076.98f70666911b62c20480e3e411e0aed5@tools.ietf.org> References: <061.974bf9e97eb053e6226d9fcca2573e34@tools.ietf.org> X-Trac-Ticket-ID: 133 In-Reply-To: <061.974bf9e97eb053e6226d9fcca2573e34@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, mhs@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201133058.00BEA1A9036@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 05:30:57 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #133 (rfc6962-bis): incomplete Misbehaving Logs section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 13:31:01 -0000 #133: incomplete Misbehaving Logs section Comment (by mhs@google.com): It's a reasonable point that the wording implies the list of ways logs can misbehave is complete. Proposed fix and link to threat analysis in https://github.com/google/certificate-transparency-rfcs/pull/110 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- david@mandelberg.org | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 05:35:39 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C351A9042 for ; Mon, 1 Feb 2016 05:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0GXsIPqNmSt for ; Mon, 1 Feb 2016 05:35:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AA31A903D for ; Mon, 1 Feb 2016 05:35:37 -0800 (PST) Received: from localhost ([::1]:42587 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQEdj-00070J-QX; Mon, 01 Feb 2016 05:35:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, linus@nordu.net X-Trac-Project: trans Date: Mon, 01 Feb 2016 13:35:35 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/109#comment:3 Message-ID: <077.20f1d13a618ca2e1ae3cb1745c6782c8@tools.ietf.org> References: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #109 (rfc6962-bis): log shutdown timeline and behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 13:35:38 -0000 #109: log shutdown timeline and behavior Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/109 . -- -----------------------------------+------------------------------- Reporter: dkg@fifthhorseman.net | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:07:41 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2685C1A90FF for ; Mon, 1 Feb 2016 06:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjjWUToS58gb for ; Mon, 1 Feb 2016 06:07:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641BF1A9101 for ; Mon, 1 Feb 2016 06:07:34 -0800 (PST) Received: from localhost ([::1]:43274 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQF8b-0003YQ-4r; Mon, 01 Feb 2016 06:07:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com, david@mandelberg.org, benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:07:29 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/126#comment:5 Message-ID: <076.cc4cfb06b27029f7e206aff1cf588869@tools.ietf.org> References: <061.da6341e1ce9ff98f35f5de603a32600f@tools.ietf.org> X-Trac-Ticket-ID: 126 In-Reply-To: <061.da6341e1ce9ff98f35f5de603a32600f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, david@mandelberg.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #126 (rfc6962-bis): text leaves open the possibility that a submitter might not verify the returned SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:07:40 -0000 #126: text leaves open the possibility that a submitter might not verify the returned SCT Changes (by benl@google.com): * milestone: => review Comment: Addressed in https://github.com/google/certificate-transparency- rfcs/commit/ad41426d868446f73f5da6e62c08f21326f34476. -- ----------------------------------+--------------------------------------- Reporter: david@mandelberg.org | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:08:56 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D141A9108 for ; Mon, 1 Feb 2016 06:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 zNdMYk8qVDBh for ; Mon, 1 Feb 2016 06:08:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D1E1A9109 for ; Mon, 1 Feb 2016 06:08:50 -0800 (PST) Received: from localhost ([::1]:43319 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQF9t-00046v-My; Mon, 01 Feb 2016 06:08:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, hadfieldp@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:08:49 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/57#comment:3 Message-ID: <080.0fd946b21d98f58be867a88c37f59918@tools.ietf.org> References: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, hadfieldp@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201140850.02D1E1A9109@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 06:08:50 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #57 (rfc6962-bis): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:08:54 -0000 #57: Clients MUST NOT match the redaction label with a "*" label Changes (by eranm@google.com): * component: client-behavior => rfc6962-bis Comment: From offline discussion: Given 6962-bis already dis-allows redacting '*' domain labels, it makes sense to state that if a client encounters such a certificate it must not be considered compliant. Moving to the rfc6962-bis component. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:09:57 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5091A90D9 for ; Mon, 1 Feb 2016 06:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 vk3Gx2sXpc4U for ; Mon, 1 Feb 2016 06:09:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5957D1A9109 for ; Mon, 1 Feb 2016 06:09:53 -0800 (PST) Received: from localhost ([::1]:43349 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFAv-0004QX-0q; Mon, 01 Feb 2016 06:09:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, mhs@google.com, benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:09:52 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/133#comment:2 Message-ID: <076.98bdc6d5284eb27684126284b387bdae@tools.ietf.org> References: <061.974bf9e97eb053e6226d9fcca2573e34@tools.ietf.org> X-Trac-Ticket-ID: 133 In-Reply-To: <061.974bf9e97eb053e6226d9fcca2573e34@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, mhs@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201140953.5957D1A9109@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 06:09:53 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #133 (rfc6962-bis): incomplete Misbehaving Logs section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:09:55 -0000 #133: incomplete Misbehaving Logs section Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/2e1262f46cfc3ebfdd374cbcb261d646c61e4359 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- david@mandelberg.org | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:13:39 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E611A9119 for ; Mon, 1 Feb 2016 06:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 zJR-zGKJCFji for ; Mon, 1 Feb 2016 06:13:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540621A9116 for ; Mon, 1 Feb 2016 06:13:35 -0800 (PST) Received: from localhost ([::1]:43492 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFET-0006e6-Ty; Mon, 01 Feb 2016 06:13:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, eijdenberg@google.com, rob.stradling@comodo.com, pphaneuf@gmail.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:13:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/127#comment:3 Message-ID: <076.2e998282ce383eb6d5e66b2507bb1881@tools.ietf.org> References: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-Trac-Ticket-ID: 127 In-Reply-To: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eijdenberg@google.com, rob.stradling@comodo.com, pphaneuf@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201141335.540621A9116@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 06:13:35 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #127 (rfc6962-bis): confusing case is allowed: submission of pre-cert without embedding SCT in issued cert X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:13:38 -0000 #127: confusing case is allowed: submission of pre-cert without embedding SCT in issued cert Comment (by pphaneuf@gmail.com): Keeping the "MAY", because too many valid cases won't have the SCTs embedded, but adding some examples to clarify: https://github.com/google/certificate-transparency-rfcs/pull/113 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- david@mandelberg.org | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:14:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80A1A911D for ; Mon, 1 Feb 2016 06:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB66VYKcU_UO for ; Mon, 1 Feb 2016 06:14:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756D71A9119 for ; Mon, 1 Feb 2016 06:14:06 -0800 (PST) Received: from localhost ([::1]:43509 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFEt-0006ms-B9; Mon, 01 Feb 2016 06:13:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, benl@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:13:59 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/94#comment:8 Message-ID: <072.0db53898f3b9585a0ee0a5b8f5829074@tools.ietf.org> References: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, benl@google.com, rob.stradling@comodo.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:14:08 -0000 #94: Fetching of inclusion proofs: Why and when are clients expected to do this? Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/ba6743b1b2e41eea15be40da045509a2e0654bdd. -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:19:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98AC1A9141 for ; Mon, 1 Feb 2016 06:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 ozvBfBuGeh1k for ; Mon, 1 Feb 2016 06:19:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6ACA1A9152 for ; Mon, 1 Feb 2016 06:19:48 -0800 (PST) Received: from localhost ([::1]:43662 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFKW-0004FK-3N; Mon, 01 Feb 2016 06:19:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:19:48 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/120#comment:1 Message-ID: <068.09ac7c68f15c8f07a199109a4d1f1896@tools.ietf.org> References: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-Trac-Ticket-ID: 120 In-Reply-To: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201141948.B6ACA1A9152@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 06:19:48 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #120 (rfc6962-bis): public vs. private logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:19:51 -0000 #120: public vs. private logs? Comment (by eranm@google.com): To be clear, the meaning is that 'any entity participating in the protocol can submit certificates'. Whether the log accepts the submission or not is up to the log's policy. An amendment is out for review in https://github.com/google/certificate- transparency-rfcs/pull/114. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:20:01 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2E1A913F for ; Mon, 1 Feb 2016 06:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZfHQxBssiPJ for ; Mon, 1 Feb 2016 06:19:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB531A916A for ; Mon, 1 Feb 2016 06:19:58 -0800 (PST) Received: from localhost ([::1]:43667 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFKf-0004cG-UQ; Mon, 01 Feb 2016 06:19:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:19:57 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/120#comment:2 Message-ID: <068.a379664403956ca9ce634beddfb6d4bf@tools.ietf.org> References: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-Trac-Ticket-ID: 120 In-Reply-To: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #120 (rfc6962-bis): public vs. private logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:20:00 -0000 #120: public vs. private logs? Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:36:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C601A92BD for ; Mon, 1 Feb 2016 06:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmO-Ni1F6BmG for ; Mon, 1 Feb 2016 06:36:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AEA1A92B3 for ; Mon, 1 Feb 2016 06:36:34 -0800 (PST) Received: from localhost ([::1]:44850 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFad-0007Lo-Vj; Mon, 01 Feb 2016 06:36:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, kent@bbn.com X-Trac-Project: trans Date: Mon, 01 Feb 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/78#comment:10 Message-ID: <068.e13bc4969e00dd61e115878c237d0f77@tools.ietf.org> References: <053.21d5f5aa5787a7a10daa132c9e70dbef@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <053.21d5f5aa5787a7a10daa132c9e70dbef@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:36:35 -0000 #78: algorithm agility discussion is inadequate Changes (by eranm@google.com): * milestone: => review Comment: Merged in https://github.com/google/certificate-transparency- rfcs/commit/2c389f9240e95b8168b14f9e78afa633cf4b0ceb . -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:53:47 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100391A92F5 for ; Mon, 1 Feb 2016 06:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4pM6ub4A2JH for ; Mon, 1 Feb 2016 06:53:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5F31A92F3 for ; Mon, 1 Feb 2016 06:53:42 -0800 (PST) Received: from localhost ([::1]:45277 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFrK-0001fy-NO; Mon, 01 Feb 2016 06:53:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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: Mon, 01 Feb 2016 14:53:42 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/108#comment:3 Message-ID: <072.7b18ec5a24f1b5e7537458e4bedf18c7@tools.ietf.org> References: <057.8f17b4f83cbab8f69b04ee24db7840b5@tools.ietf.org> X-Trac-Ticket-ID: 108 In-Reply-To: <057.8f17b4f83cbab8f69b04ee24db7840b5@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #108 (rfc6962-bis): TLS session resumption: Server MUST NOT send SCTs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:53:45 -0000 #108: TLS session resumption: Server MUST NOT send SCTs Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed by https://github.com/robstradling/certificate-transparency- rfcs/commit/765a6eee0a878ef672090e0bcba4851f06c19909 and https://github.com/robstradling/certificate-transparency- rfcs/commit/4d594149f6c5f4ae5fc42f3e297462ee08534c1c -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:56:30 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78871ABD3E for ; Mon, 1 Feb 2016 06:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 FHZWCjrHO8Kf for ; Mon, 1 Feb 2016 06:56:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5601ABD3C for ; Mon, 1 Feb 2016 06:56:27 -0800 (PST) Received: from localhost ([::1]:45341 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFtx-0002Dq-G0; Mon, 01 Feb 2016 06:56:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, kent@bbn.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:56:25 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/121#comment:2 Message-ID: <068.25951b10ce71eb91a15348c0fbc8b8e8@tools.ietf.org> References: <053.2d6c03925075fce7d9903f2cd1b7e49a@tools.ietf.org> X-Trac-Ticket-ID: 121 In-Reply-To: <053.2d6c03925075fce7d9903f2cd1b7e49a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, kent@bbn.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201145627.7E5601ABD3C@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 06:56:27 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #121 (rfc6962-bis): log metadata dissemination X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:56:29 -0000 #121: log metadata dissemination Comment (by eranm@google.com): I agree that log metadata dissemination is a topic that should be more thoroughly discussed at some point. However, I do not think that 6962-bis is the right place for it. Steve has a very valid point about metadata not being specified in a machine-readable format, nor having a part of the protocol describing how it is disseminated. I believe these issues should be addressed separately of 6962-bis, because: - The topic of log metadata is one level "above" what 6962-bis discusses. - The requirements for metadata dissemination are very different for each type of client. - Disseminating metadata reliably is a protocol in itself, which (once the requirements are clear) deserve its own design. My suggestion is to punt the discussion until after 6962-bis is out. Presumably then there would be enough different clients implementing 6962-bis that disseminating metadata would justify more efforts from this workgroup. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 06:56:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451881AC39F for ; Mon, 1 Feb 2016 06:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 9dEde-BIntKm for ; Mon, 1 Feb 2016 06:56:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481D51ABD3E for ; Mon, 1 Feb 2016 06:56:38 -0800 (PST) Received: from localhost ([::1]:45350 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQFu9-0002ES-3B; Mon, 01 Feb 2016 06:56:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, kent@bbn.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 14:56:37 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/121#comment:3 Message-ID: <068.5848ed8b55fff7ededa73a602433ee4b@tools.ietf.org> References: <053.2d6c03925075fce7d9903f2cd1b7e49a@tools.ietf.org> X-Trac-Ticket-ID: 121 In-Reply-To: <053.2d6c03925075fce7d9903f2cd1b7e49a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, kent@bbn.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201145638.481D51ABD3E@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 06:56:38 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #121 (rfc6962-bis): log metadata dissemination X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:56:43 -0000 #121: log metadata dissemination Changes (by eranm@google.com): * milestone: => review -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:02:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0291ABD3D for ; Mon, 1 Feb 2016 07:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6ZIyEF8Vvf2 for ; Mon, 1 Feb 2016 07:02:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC091ABD3C for ; Mon, 1 Feb 2016 07:02:50 -0800 (PST) Received: from localhost ([::1]:45479 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQG09-0003qG-El; Mon, 01 Feb 2016 07:02:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com, katjoyce@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:02:49 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/50#comment:4 Message-ID: <080.4265aa9afd0200ed62ca956878622b18@tools.ietf.org> References: <065.24ee65ca0b49a0d2612054e06e01d6c3@tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <065.24ee65ca0b49a0d2612054e06e01d6c3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, katjoyce@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201150250.3EC091ABD3C@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 07:02:50 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #50 (client-behavior): Ordering of revocation checking and SCT processing by TLS Clients X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:02:51 -0000 #50: Ordering of revocation checking and SCT processing by TLS Clients Changes (by katjoyce@google.com): * owner: katjoyce@google.com => draft-ietf-trans- rfc6962-bis@tools.ietf.org -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:03:11 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018161ABD3C for ; Mon, 1 Feb 2016 07:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKprWBSLR4B6 for ; Mon, 1 Feb 2016 07:03:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E811ABB19 for ; Mon, 1 Feb 2016 07:03:07 -0800 (PST) Received: from localhost ([::1]:45487 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQG0P-0003rz-0t; Mon, 01 Feb 2016 07:03:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:03:04 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/140#comment:2 Message-ID: <068.99ef34473d40167307314e28dda7aaea@tools.ietf.org> References: <053.78d7c5ba597b70394bf4a637fe45004b@tools.ietf.org> X-Trac-Ticket-ID: 140 In-Reply-To: <053.78d7c5ba597b70394bf4a637fe45004b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #140 (rfc6962-bis): move section 8 to CA specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:03:10 -0000 #140: move section 8 to CA specification Comment (by benl@google.com): 2119 issues fixed at https://github.com/google/certificate-transparency- rfcs/commit/ba6743b1b2e41eea15be40da045509a2e0654bdd -- --------------------------+--------------------------------------- Reporter: kseo@bbn.com | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:04:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC5A1AC3E5 for ; Mon, 1 Feb 2016 07:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqpPwS-ygB8M for ; Mon, 1 Feb 2016 07:04:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBAF1AC3E3 for ; Mon, 1 Feb 2016 07:04:43 -0800 (PST) Received: from localhost ([::1]:45519 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQG1y-00043Q-AZ; Mon, 01 Feb 2016 07:04:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pphaneuf@gmail.com, eijdenberg@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:04:42 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/127#comment:4 Message-ID: <076.a8bb3c2d6e9d7854686cd7301a67047e@tools.ietf.org> References: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-Trac-Ticket-ID: 127 In-Reply-To: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pphaneuf@gmail.com, eijdenberg@google.com, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #127 (rfc6962-bis): confusing case is allowed: submission of pre-cert without embedding SCT in issued cert X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:04:51 -0000 #127: confusing case is allowed: submission of pre-cert without embedding SCT in issued cert Changes (by pphaneuf@gmail.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => pphaneuf@gmail.com * status: new => assigned -- ----------------------------------+--------------------------------- Reporter: david@mandelberg.org | Owner: pphaneuf@gmail.com Type: enhancement | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:05:41 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0251AC408 for ; Mon, 1 Feb 2016 07:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZA9xuubkeNA for ; Mon, 1 Feb 2016 07:05:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF301ABB19 for ; Mon, 1 Feb 2016 07:05:39 -0800 (PST) Received: from localhost ([::1]:45560 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQG2t-0004TW-4q; Mon, 01 Feb 2016 07:05:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:05:39 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/140#comment:3 Message-ID: <068.321a0a48d5628793f676b674c4c7bcd0@tools.ietf.org> References: <053.78d7c5ba597b70394bf4a637fe45004b@tools.ietf.org> X-Trac-Ticket-ID: 140 In-Reply-To: <053.78d7c5ba597b70394bf4a637fe45004b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #140 (rfc6962-bis): move section 8 to CA specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:05:41 -0000 #140: move section 8 to CA specification Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Moving to review. As agreed with the chairs, we've only addressed the 2119 issues. Punting on the rest. -- --------------------------+--------------------------------------- Reporter: kseo@bbn.com | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:13:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22361ACD16 for ; Mon, 1 Feb 2016 07:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiPg20Cx5MGh for ; Mon, 1 Feb 2016 07:13:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4607E1A00E0 for ; Mon, 1 Feb 2016 07:13:06 -0800 (PST) Received: from localhost ([::1]:45719 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGA4-0008W2-D1; Mon, 01 Feb 2016 07:13:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:13:04 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/81#comment:6 Message-ID: <080.eff2cf3507031f061cdc952ddadc2e83@tools.ietf.org> References: <065.7e2aed9eafe145755b95ef51d9921722@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <065.7e2aed9eafe145755b95ef51d9921722@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:13:08 -0000 #81: OIDs and IANA Considerations Comment (by rob.stradling@comodo.com): Symantec have offered to donate some OIDs under the thawte 1.3.101 OID arc. I'm working with Rick Andrews to get some actual OIDs allocated. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:14:45 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66F31ACD18 for ; Mon, 1 Feb 2016 07:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvjCAf0ejVhe for ; Mon, 1 Feb 2016 07:14:41 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13DE1ACD16 for ; Mon, 1 Feb 2016 07:14:41 -0800 (PST) Received: from localhost ([::1]:45751 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGBd-0000v8-Oh; Mon, 01 Feb 2016 07:14:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pphaneuf@gmail.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:14:41 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/112#comment:1 Message-ID: <080.5a1254b409fef1b3e8226c12734de50d@tools.ietf.org> References: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pphaneuf@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #112 (rfc6962-bis): Consider permitting the status_request_v2 TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:14:43 -0000 #112: Consider permitting the status_request_v2 TLS extension Changes (by pphaneuf@gmail.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => pphaneuf@gmail.com * status: new => assigned -- --------------------------------------+--------------------------------- Reporter: rob.stradling@comodo.com | Owner: pphaneuf@gmail.com Type: enhancement | Status: assigned Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+--------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:15:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936D1ACD0F for ; Mon, 1 Feb 2016 07:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmcz5na6HKt1 for ; Mon, 1 Feb 2016 07:15:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CDB1ACD0E for ; Mon, 1 Feb 2016 07:15:18 -0800 (PST) Received: from localhost ([::1]:45779 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGCE-00043M-F3; Mon, 01 Feb 2016 07:15:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:15:18 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/120#comment:3 Message-ID: <068.a4c2b7f8864675d0ae7496b53176efbf@tools.ietf.org> References: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-Trac-Ticket-ID: 120 In-Reply-To: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #120 (rfc6962-bis): public vs. private logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:15:21 -0000 #120: public vs. private logs? Changes (by eranm@google.com): * milestone: => review Comment: This was addressed in https://github.com/google/certificate-transparency- rfcs/commit/01a0c75555ba11ac87259e3eb7f0d1a6e50addb5 . -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:16:42 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F671ACD3A for ; Mon, 1 Feb 2016 07:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV5Z5CqGlJQG for ; Mon, 1 Feb 2016 07:16:35 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410381ACD0F for ; Mon, 1 Feb 2016 07:16:35 -0800 (PST) Received: from localhost ([::1]:45820 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGDR-000267-OV; Mon, 01 Feb 2016 07:16:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pphaneuf@gmail.com, eijdenberg@google.com, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:16:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/127#comment:5 Message-ID: <076.77c94d5a31afdeb0ade181295860a565@tools.ietf.org> References: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-Trac-Ticket-ID: 127 In-Reply-To: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pphaneuf@gmail.com, eijdenberg@google.com, rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #127 (rfc6962-bis): confusing case is allowed: submission of pre-cert without embedding SCT in issued cert X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:16:40 -0000 #127: confusing case is allowed: submission of pre-cert without embedding SCT in issued cert Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/de8df75f283f5d7295008642e6d0c8838b1e4029 -- ----------------------------------+--------------------------------- Reporter: david@mandelberg.org | Owner: pphaneuf@gmail.com Type: enhancement | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:19:03 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4D21ACD83 for ; Mon, 1 Feb 2016 07:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 wVrgCOhq3U_y for ; Mon, 1 Feb 2016 07:19:01 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0461ACD70 for ; Mon, 1 Feb 2016 07:19:01 -0800 (PST) Received: from localhost ([::1]:45862 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGFp-0001Zh-6y; Mon, 01 Feb 2016 07:19:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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: Mon, 01 Feb 2016 15:19:01 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/153 Message-ID: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org> X-Trac-Ticket-ID: 153 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201151901.6F0461ACD70@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 07:19:01 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #153 (rfc6962-bis): Finish documenting support for RFC6962 (v1) structures in TransInfo X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:19:02 -0000 #153: Finish documenting support for RFC6962 (v1) structures in TransInfo "Appendix A. TransItemV1 TODO: Finish writing this section. Or should it be in a separate document?" -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:22:45 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4A1ACDBD for ; Mon, 1 Feb 2016 07:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLOAr6n8QVPf for ; Mon, 1 Feb 2016 07:22:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178631ACDB7 for ; Mon, 1 Feb 2016 07:22:43 -0800 (PST) Received: from localhost ([::1]:46008 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGJO-00040T-M7; Mon, 01 Feb 2016 07:22:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:22:42 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/113#comment:1 Message-ID: <080.73002a15de53dcc65d9d77fb4fe5dbd1@tools.ietf.org> References: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #113 (rfc6962-bis): Add advice about the tls-feature TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:22:44 -0000 #113: Add advice about the tls-feature TLS extension Changes (by benl@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => benl@google.com -- --------------------------------------+------------------------------ Reporter: rob.stradling@comodo.com | Owner: benl@google.com Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------ Ticket URL: trans From nobody Mon Feb 1 07:24:54 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C061ACDE4 for ; Mon, 1 Feb 2016 07:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39esAynUgPCS for ; Mon, 1 Feb 2016 07:24:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386CE1ACDE8 for ; Mon, 1 Feb 2016 07:24:45 -0800 (PST) Received: from localhost ([::1]:46109 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGLN-0001AH-0W; Mon, 01 Feb 2016 07:24:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:24:44 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:6 Message-ID: <072.e85daeb85de4f25a2b311293f215c012@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:24:53 -0000 #115: Verify that recommended consistency checking algorithm is correct Changes (by katjoyce@google.com): * status: closed => reopened * resolution: fixed => -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: reopened Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 07:25:44 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2D51ACE2F for ; Mon, 1 Feb 2016 07:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoSq89QvD8Xa for ; Mon, 1 Feb 2016 07:25:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DE01ACE09 for ; Mon, 1 Feb 2016 07:25:40 -0800 (PST) Received: from localhost ([::1]:46150 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGMF-0004vy-Rd; Mon, 01 Feb 2016 07:25:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 15:25:39 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:7 Message-ID: <072.27455ebacad84f3b9a4bba1a4f3816d3@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:25:43 -0000 #115: Verify that recommended consistency checking algorithm is correct Changes (by eranm@google.com): * milestone: => review -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 08:04:03 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D221D1B2A72 for ; Mon, 1 Feb 2016 08:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRkB0mFc_qZ5 for ; Mon, 1 Feb 2016 08:03:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31BF1B2A6B for ; Mon, 1 Feb 2016 08:03:59 -0800 (PST) Received: from localhost ([::1]:47451 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQGxL-0000na-9r; Mon, 01 Feb 2016 08:03:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:03:59 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/142#comment:1 Message-ID: <080.6565ae54014b64bc5a17d57067758634@tools.ietf.org> References: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org> X-Trac-Ticket-ID: 142 In-Reply-To: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #142 (rfc6962-bis): Specify what TLS clients should send in the extension_data of the transparency_info TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:04:02 -0000 #142: Specify what TLS clients should send in the extension_data of the transparency_info TLS extension Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com Comment: Other things the client can send: - List of Log IDs. -- --------------------------------------+------------------------------- Reporter: rob.stradling@comodo.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 08:29:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E841B3225 for ; Mon, 1 Feb 2016 08:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyBHffmBErSg for ; Mon, 1 Feb 2016 08:29:35 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72111B321F for ; Mon, 1 Feb 2016 08:29:35 -0800 (PST) Received: from localhost ([::1]:49584 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQHM7-0001Zx-L5; Mon, 01 Feb 2016 08:29:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: benl@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:29:35 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/113#comment:2 Message-ID: <080.3c2e6fbf446dad191bd1a06d7498cd70@tools.ietf.org> References: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #113 (rfc6962-bis): Add advice about the tls-feature TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:29:38 -0000 #113: Add advice about the tls-feature TLS extension Comment (by benl@google.com): I think it is unclear that EE certs should _never_ have this extension, and saying anything weaker seems pointless. -- --------------------------------------+------------------------------ Reporter: rob.stradling@comodo.com | Owner: benl@google.com Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------ Ticket URL: trans From nobody Mon Feb 1 08:39:01 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1881B3232 for ; Mon, 1 Feb 2016 08:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wau7Lfk3ifz for ; Mon, 1 Feb 2016 08:38:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D34F1B3228 for ; Mon, 1 Feb 2016 08:38:58 -0800 (PST) Received: from localhost ([::1]:50142 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQHV8-0000NZ-1f; Mon, 01 Feb 2016 08:38:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:38:54 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:6 Message-ID: <072.e6c684c9050792f318a39555838eba2b@tools.ietf.org> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:38:59 -0000 #23: How can TLS clients match an SCT to a certificate? Comment (by eranm@google.com): Capturing offline discussion with Rob: * The ItemExtension field may be redundant given new TransItems can be defined that refer to other TransItems to provide metadata. * Given that name-constrained intermediates that are logged instead of leaf certificates are easily identifiable by a non-critical extension, providing the metadata indicating which certificate the SCT refers to may be an overkill: A client can try to verify the SCT on the leaf certificate, if the signature does not validate it should traverse the cert chain until it finds such an intermediate, then validate the SCT over that intermediate. * An intermediate MAY be logged instead of the leaf, so to allow for the case where both the intermediate and leaf are logged, the client has to validate the SCT against the leaf first. -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 08:43:49 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576671B3249 for ; Mon, 1 Feb 2016 08:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XUgqKMY85hK for ; Mon, 1 Feb 2016 08:43:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119A31B3241 for ; Mon, 1 Feb 2016 08:43:47 -0800 (PST) Received: from localhost ([::1]:51175 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQHZj-0001jp-LS; Mon, 01 Feb 2016 08:43:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, kent@bbn.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:43:39 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/78#comment:11 Message-ID: <068.f733a5baaba026e728c5f4b906c93666@tools.ietf.org> References: <053.21d5f5aa5787a7a10daa132c9e70dbef@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <053.21d5f5aa5787a7a10daa132c9e70dbef@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:43:48 -0000 #78: algorithm agility discussion is inadequate Comment (by eranm@google.com): Text supplied by Steve Kent, in case the current changes are not enough: " The term "algorithm agility" refers to mechanism and procedures that enable use of different sets of algorithms within a protocol or system. It also often encompasses the transition from one set of cryptographic algorithms to another, in a fashion that avoids service disruption. All of the cryptographic algorithms defined for use with CT are represented as log metadata. None of these algorithms can be changed for an extant log. When a new log is created the log operator MUST specify all of the cryptographic algorithms as part of the metadata for that log. This metadata MUST be made available to all log clients. For TLS clients that are web browsers, CT relies on browser vendors to convey this metadata to the clients. For all other log clients, the means of disseminating log metadata is undefined. The set of cryptographic algorithms initially specified for CT (in RFC XXXX) will change over time. New, standard algorithms will be published as (standards track) RFCs. Log operators and clients will be required to support these algorithms (for new logs) during a time frame specified by these RFCs. " -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Mon Feb 1 08:52:57 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0D1B3294 for ; Mon, 1 Feb 2016 08:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrkPQF1PuFaT for ; Mon, 1 Feb 2016 08:52:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E9F1B3291 for ; Mon, 1 Feb 2016 08:52:55 -0800 (PST) Received: from localhost ([::1]:51465 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQHih-0003h9-BO; Mon, 01 Feb 2016 08:52:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:52:55 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:8 Message-ID: <072.b54d0bedc738b22e9537138c6c073f71@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:52:57 -0000 #115: Verify that recommended consistency checking algorithm is correct Changes (by eranm@google.com): * milestone: review => Comment: Removing review milestone. Per offline clarification, we should make sure that the test cases in test_rfc_algorithms.py cover positive and negative cases (by copying the concepts from https://github.com/google/certificate- transparency/blob/master/cpp/merkletree/merkle_tree_test.cc) then make sure the algorithm identifies both success and failure correctly. -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: reopened Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Mon Feb 1 08:54:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3D81B32A0 for ; Mon, 1 Feb 2016 08:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 kEkqy_txVSdT for ; Mon, 1 Feb 2016 08:54:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BB31B3277 for ; Mon, 1 Feb 2016 08:54:11 -0800 (PST) Received: from localhost ([::1]:51477 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQHju-0003mt-Jj; Mon, 01 Feb 2016 08:54:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, kent@bbn.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:54:10 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/152#comment:2 Message-ID: <072.5ea3409da2bf8be4ceea3854a4aac318@tools.ietf.org> References: <057.e6a9d1f924e8f658292ddf2fa9759daa@tools.ietf.org> X-Trac-Ticket-ID: 152 In-Reply-To: <057.e6a9d1f924e8f658292ddf2fa9759daa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, kent@bbn.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201165411.C3BB31B3277@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 08:54:11 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #152 (client-behavior): Architecture document: CT-aware TLS clients may require SCTs for all certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:54:18 -0000 #152: Architecture document: CT-aware TLS clients may require SCTs for all certs Comment (by eranm@google.com): Sounds good to me. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: client- | Version: behavior | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 08:54:58 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0215D1B3293 for ; Mon, 1 Feb 2016 08:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 Nr72Tw8Bl38M for ; Mon, 1 Feb 2016 08:54:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112B11B328A for ; Mon, 1 Feb 2016 08:54:57 -0800 (PST) Received: from localhost ([::1]:51496 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQHke-0003rw-0I; Mon, 01 Feb 2016 08:54:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, kent@bbn.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:54:55 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/151#comment:2 Message-ID: <072.92318d5cad88609b2ac9837fbd246c22@tools.ietf.org> References: <057.929b9b011a08641c287fd6d7eb25bb95@tools.ietf.org> X-Trac-Ticket-ID: 151 In-Reply-To: <057.929b9b011a08641c287fd6d7eb25bb95@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, kent@bbn.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20160201165457.112B11B328A@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 08:54:57 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #151 (threat-analysis): Architecture document: Only the leaf cert + timestamp are in the SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:54:58 -0000 #151: Architecture document: Only the leaf cert + timestamp are in the SCT Comment (by eranm@google.com): SGTM, with the extra benefit of not repeating information that's already in another document. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: threat- | Version: analysis | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 08:56:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4633E1B326E for ; Mon, 1 Feb 2016 08:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 k5HRbnO3HQw8 for ; Mon, 1 Feb 2016 08:56:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314B11B3277 for ; Mon, 1 Feb 2016 08:56:17 -0800 (PST) Received: from localhost ([::1]:51543 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQHlw-0004Cv-Dy; Mon, 01 Feb 2016 08:56:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, kent@bbn.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 16:56:16 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/150#comment:2 Message-ID: <072.629af3d43997c37ef406e87104e0b93a@tools.ietf.org> References: <057.e2278dd0c4496e2388036e05a7927262@tools.ietf.org> X-Trac-Ticket-ID: 150 In-Reply-To: <057.e2278dd0c4496e2388036e05a7927262@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, kent@bbn.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20160201165617.314B11B3277@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 08:56:17 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #150 (threat-analysis): Architecture document: Indicate missing SCT is equivalent to invalid one X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:56:18 -0000 #150: Architecture document: Indicate missing SCT is equivalent to invalid one Changes (by eranm@google.com): * status: new => closed * resolution: => invalid Comment: Fair enough. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: Component: threat- | Version: analysis | Resolution: invalid Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 1 09:19:59 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039B51B32CD for ; Mon, 1 Feb 2016 09:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHUzPHfr9fNH for ; Mon, 1 Feb 2016 09:19:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB371B32CB for ; Mon, 1 Feb 2016 09:19:56 -0800 (PST) Received: from localhost ([::1]:52326 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQI8l-00064J-He; Mon, 01 Feb 2016 09:19:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 17:19:51 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:7 Message-ID: <072.dedc4d7daa577a17bc74cf45b78d2e8e@tools.ietf.org> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:19:58 -0000 #23: How can TLS clients match an SCT to a certificate? Comment (by rob.stradling@comodo.com): Also discussed with Eran just now: In comment:1 I suggested that it might be useful to define an !ItemExtension for gossip (i.e. "This SCT (or SCT inclusion proof) isn't relevant to any of the certificates you're currently interested in, but nonetheless please keep a copy of it and send it to some other TLS servers you communicate with.") However, we could define a different mechanism for signalling this: two ideas... - Define a new range of !TransType values that mirror the existing set. The log would produce SCTs, inclusion proofs, etc, using the existing set of !TransType values; the TLS server would modify the !TransType of an object it's gossiping; then the (gossip-supporting) TLS client would spot that this object is being gossiped, then restore the original !TransType if it wants to verify the !TransItem's signature. (Clients that don't support gossip via this mechanism would simply ignore the !TransItem objects with !TransType values they don't recognize). - As per comment:6, an additional !TransItem could be added by the TLS server (using a not-yet-defined !TransType value) that contains additional metadata about other !TransItems in the list. One drawback of this approach is that if the TLS client doesn't recognize this not-yet-defined !TransType value, it would try to verify the gossiped SCTs / inclusion proofs against the TLS server's certificate/chain. The second of these approaches would need to be documented in 6962-bis to ensure that the described drawback does not occur. The first of these approaches could be implemented entirely in the gossip draft. 6962-bis need not know anything about it. -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 09:26:56 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9DB1B32E5 for ; Mon, 1 Feb 2016 09:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti8SEAC0Sd9O for ; Mon, 1 Feb 2016 09:26:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7C31B32E4 for ; Mon, 1 Feb 2016 09:26:54 -0800 (PST) Received: from localhost ([::1]:52626 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQIFa-0005Q8-0o; Mon, 01 Feb 2016 09:26:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hadfieldp@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 17:26:53 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/143#comment:1 Message-ID: <068.bc407746b5b43465f7168821b81d8737@tools.ietf.org> References: <053.dda9576385fcf4615156c78a473241af@tools.ietf.org> X-Trac-Ticket-ID: 143 In-Reply-To: <053.dda9576385fcf4615156c78a473241af@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #143 (rfc6962-bis): Putting TLS server guidance in one place X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:26:55 -0000 #143: Putting TLS server guidance in one place Changes (by hadfieldp@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => hadfieldp@google.com * status: new => assigned -- --------------------------+----------------------------------- Reporter: kseo@bbn.com | Owner: hadfieldp@google.com Type: defect | Status: assigned Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+----------------------------------- Ticket URL: trans From nobody Mon Feb 1 09:33:21 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 D86A41B32FF; Mon, 1 Feb 2016 09:33:18 -0800 (PST) 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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160201173318.14122.4331.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 09:33:18 -0800 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-04.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:33:19 -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 Working Group of the IETF. Title : Attack Model and Threat for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-04.txt Pages : 25 Date : 2016-01-30 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-04 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 Feb 1 09:44:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA9A1B3349 for ; Mon, 1 Feb 2016 09:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcn-m1-NrtJg for ; Mon, 1 Feb 2016 09:44:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A4F1B3345 for ; Mon, 1 Feb 2016 09:44:49 -0800 (PST) Received: from localhost ([::1]:53372 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQIWt-0008Sb-JH; Mon, 01 Feb 2016 09:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 17:44:47 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:8 Message-ID: <072.80d7588d25133c8dd2e47ee84650648d@tools.ietf.org> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:44:50 -0000 #23: How can TLS clients match an SCT to a certificate? Comment (by rob.stradling@comodo.com): One further thing discussed with Eran just now: it could be useful to define an SCT extension to self-identify that SCT as belonging to a name- constrained intermediate certificate rather than an end-entity certificate. Requiring this SCT extension to be present in such SCTs would reduce the amount of guesswork that clients need to do in order to determine which certificate the SCT belongs to. If we do this, we would need a corresponding extension for inclusion proofs, although there's currently no extensions field in InclusionProofDataV2. -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 09:48:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888AF1B3350 for ; Mon, 1 Feb 2016 09:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM7orE1MSLcZ for ; Mon, 1 Feb 2016 09:48:41 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C14A1B334F for ; Mon, 1 Feb 2016 09:48:41 -0800 (PST) Received: from localhost ([::1]:53476 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQIae-00010n-1N; Mon, 01 Feb 2016 09:48:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 17:48:40 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:9 Message-ID: <072.c08a43821e968e311ed3343ab9f4ffee@tools.ietf.org> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 17:48:42 -0000 #23: How can TLS clients match an SCT to a certificate? Comment (by rob.stradling@comodo.com): At the moment I am fairly inclined to get rid of the !ItemExtension field. It complicates things (especially for servers, since they would need to manipulate log-signed !TransItem objects in order to insert !ItemExtensions), and it seems (from the last few comments) that we can manage without it. -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Feb 1 10:20:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D511B33BE for ; Mon, 1 Feb 2016 10:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6sQe8ialOXi for ; Mon, 1 Feb 2016 10:20:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2736C1B33BD for ; Mon, 1 Feb 2016 10:20:11 -0800 (PST) Received: from localhost ([::1]:54957 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQJ58-000309-8u; Mon, 01 Feb 2016 10:20:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, hadfieldp@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 01 Feb 2016 18:20:09 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/57#comment:4 Message-ID: <080.326ed26cf54b5134222f64358c5588c3@tools.ietf.org> References: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, hadfieldp@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160201182011.2736C1B33BD@ietfa.amsl.com> Resent-Date: Mon, 1 Feb 2016 10:20:11 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #57 (rfc6962-bis): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 18:20:12 -0000 #57: Clients MUST NOT match the redaction label with a "*" label Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/120 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 1 11:06:18 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4381B3499 for ; Mon, 1 Feb 2016 11:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSPKVfTwpBA7 for ; Mon, 1 Feb 2016 11:06:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AEB1B349E for ; Mon, 1 Feb 2016 11:06:15 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:59932 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aQJnc-000BBV-7o for trans@ietf.org; Mon, 01 Feb 2016 14:06:08 -0500 From: Stephen Kent To: trans@ietf.org References: <065.543a100087070dd152bde158ebf8bcd5@tools.ietf.org> <080.6a83e16be95e70d20aae59adf2497f0a@tools.ietf.org> Message-ID: <56AFAC9F.1000408@bbn.com> Date: Mon, 1 Feb 2016 14:06:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <080.6a83e16be95e70d20aae59adf2497f0a@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:06:17 -0000 Rob, Why not use an IETF arc for the OIDs? That's more consistent with IETF standards practice. Steve > #97: Allocate an OID for CMS precertificates > > Changes (by rob.stradling@comodo.com): > > * owner: benl@google.com => rob.stradling@comodo.com > > > Comment: > > Cancel that request. > > Symantec have agreed to donate some OIDs under the thawte 1.3.101 OID arc. > Let's use one of them here. > From nobody Mon Feb 1 16:55:00 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AC81A1AA8 for ; Mon, 1 Feb 2016 16:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dMCvdSRnNGP for ; Mon, 1 Feb 2016 16:54:58 -0800 (PST) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DE01A1AA7 for ; Mon, 1 Feb 2016 16:54:57 -0800 (PST) X-AuditID: d80ac3f2-f79f96d000005ee7-d1-56affe60a6a0 Received: from ecl1mtahubpin02.ges.symantec.com (ustu-zone.relay.symantec.com [10.48.69.202]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 04.10.24295.06EFFA65; Tue, 2 Feb 2016 00:54:57 +0000 (GMT) Received: from [155.64.220.192] (helo=TUS1XCHEPFPIN40.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1aQPFA-00020A-3T; Mon, 01 Feb 2016 19:54:56 -0500 Received: from TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM ([155.64.221.74]) by TUS1XCHEPFPIN40.SYMC.SYMANTEC.COM ([155.64.220.192]) with mapi; Mon, 1 Feb 2016 16:54:55 -0800 From: Rick Andrews To: Stephen Kent , "trans@ietf.org" Date: Mon, 1 Feb 2016 16:54:54 -0800 Thread-Topic: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates Thread-Index: AdFdI6YITe/QNDSzQRS5Z82tFr3nSgAMJj9w Message-ID: References: <065.543a100087070dd152bde158ebf8bcd5@tools.ietf.org> <080.6a83e16be95e70d20aae59adf2497f0a@tools.ietf.org> <56AFAC9F.1000408@bbn.com> In-Reply-To: <56AFAC9F.1000408@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03C2_01D15D11.45AA2220" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsXCZeB6Sjfx3/owg33HuSw2zma0WPv4IosD k8fU86EeS5b8ZApgiuKySUnNySxLLdK3S+DKaL37ib3gqXvF7Q+bGBsYD7l0MXJySAiYSKw9 eJgRwhaTuHBvPVsXIxeHkMArRonnN/YwwTmPdlxlA6kSEljBKLGjWRfEZhPQk9jy+Ao7iC0i 4CRxv/sNE4jNIqAisX//SbB6YYFIiZsb10LVRElMfXOdFcI2kmieepm5i5GDgxcovmaeOsT4 aYwSkzbFgNicAuoSFx5/ARvDCHTc91NrwMYzC4hL3HoynwniaBGJhxdPs0HYohIvH/9jhagX lbjTvp4R5H5mgV5GiZcnf4N9ySsgKHFy5hOWCYyis5DMmoWsbhaSullA9zED/dm2kRGiXl5i +9s5zBC2tcSMXwfZIGxFiSndD9khbFOJ10c/Mi5g5FjFKFNSWmxYnFuSX1pSkFphYKRXXJmb CIzHZL3k/NxNjMCYvMF1+NMOxpl7HQ8xCnAwKvHwsnxYHybEmlgGVHmIUQVo3KMNqy8wSrHk 5eelKonwrnwPlOZNSaysSi3Kjy8qzUktPsQozcGiJM6rUxEcJiSQnliSmp2aWpBaBJNl4uCU amD0nPVyb6xnNPukzLqQBubDLC/zr33+YdtvuyAnVarrXPEzBu39quz3rzuvmlvqcmJe/pqz N0ofNx2/0lQYNj9uBdv92eJnohOO6Bef2K5/dl7yFrF1z/g+7nU7xyCmKH79wuNXvbvVi58V +y59I3TXPz3jTsklSe61/O/zuf5f7bWwU1nr3HFdiaU4I9FQi7moOBEAqR7+aNECAAA= Archived-At: Subject: Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 00:55:00 -0000 ------=_NextPart_000_03C2_01D15D11.45AA2220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephen, Rob was looking to shave off a few bytes from each OID by starting with a small arc, which Thawte has. -Rick -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Monday, February 01, 2016 11:06 AM To: trans@ietf.org Subject: Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates Rob, Why not use an IETF arc for the OIDs? That's more consistent with IETF standards practice. Steve > #97: Allocate an OID for CMS precertificates > > Changes (by rob.stradling@comodo.com): > > * owner: benl@google.com => rob.stradling@comodo.com > > > Comment: > > Cancel that request. > > Symantec have agreed to donate some OIDs under the thawte 1.3.101 OID arc. > Let's use one of them here. > _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ------=_NextPart_000_03C2_01D15D11.45AA2220 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRhzCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBkwwggU0oAMCAQICEBw3Lcu5cD5rtz7z+tELQgYwDQYJ KoZIhvcNAQELBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTE1MDEwNjAw MDAwMFoXDTI1MDEwNTIzNTk1OVowgbAxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFu dGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALbX9Fd7nt9wUT7ISGRoQMGJbj8EkkrtHHQnINo4z1KTPLnRWscXLT5oTmFpC7JuaHn0AnYK +NJutht+e0vGtU/avfhJDgLP7K1qZ+vOBHm9hMzzmiME1s9CP0nOlifrJK5h2TS5Znq8g4kfGJTA asB5zmfjNVCJomx17jhf8fuZrvMXSBsWDxl6NGohZloUgxFAwrCe0NuDzt8E8jJCgw5lewsqjlll eBvJbCxOXhcuMvjK6/ilNC1WjkaIlTWXyaraGQAMPm2nsZED4+aBNRMX855Amtk5zAoKh1oeIiN7 2YaPVmiIIOeGKqY0B3RYTY7cmxgU4RA5xgKA3LeMIP0CAwEAAaOCAkQwggJAMBIGA1UdEwEB/wQI MAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8v d3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t L3JwYTAOBgNVHQ8BAf8EBAMCAQYwNwYIKwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8v cGtpLW9jc3Auc3ltYXV0aC5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2NybC53cy5zeW1h bnRlYy5jb20vcGNhMi1nMy5jcmwwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFN5bWFudGVjUEtJ LTItMjMwHQYDVR0OBBYEFKQzr7DDRoer5XhJsrTiRp/qCfwVMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqG SIb3DQEBCwUAA4IBAQChthp96rPOdkvEEfo4yk4Q8auHf5LqUJUlwDdoAvuCrYDLM9TMQzCwRWf7 IpiGPMAVnddFj2ohiX3bYd0tkaqyjfDJDtZQK9YgN5GD0RTO2gHS0PHOOyJBSDJ5G0um4NLofhkB h9RqEE3mBF68RGe4Te7Z5ST+pvgqGzC8v/2xDEZcClXhch8gNU7muFl18YdX9gWV54BcTj0lo9E9 9/2HVCPB5QAzFhHqgHjDnETpw5S3JlpKTEMXyqaWd/5+Vo+ID+jd51HS+BS1u2Dguv+FvgINTVrr IO1ymEh5L3XM4gQrCgD7yajPRf/BIjyF/xzL/ONUoxd8e1gR/E1N98oyMIIHFjCCBf6gAwIBAgIQ OVrt7EotOiYavftZTf7D7jANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMCVVMxHTAbBgNVBAoT FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUw MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgG A1UEAxMhU3ltYW50ZWMgQ2xhc3MgMiBFbXBsb3llZSBDQSAtIEczMB4XDTE1MDYwNTAwMDAwMFoX DTE2MDYwNDIzNTk1OVowWDEdMBsGA1UECgwUU3ltYW50ZWMgQ29ycG9yYXRpb24xIDAeBgNVBAsM F1N5bWFudGVjIEVtcGxveWVlIEVtYWlsMRUwEwYDVQQDDAxSaWNrIEFuZHJld3MwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMkzz3/cxC5IPK1PgEVnb2v6HNo5VaRHC5nKGTtKfmdl58 yBdBK4SJwGSIHiQsIgItAQc4mmd7MUIQOxt5RN7dCFMDFzxbSF0nIl1GR52WzN8mgVE9+6oMxDKN 5LOckMEKNH13NF7Ebjz/p0v0JaRHEuzG4w12ah3B8GkBKJn0XDRJjZNq1R/fJJxklUWsQcimw7S5 bb9bGQwCipDGDn1WLaXP1UWDqyP/ja6OYyKY3QFlk1olDk5iZ5XipSiX57euk9FigV4Ddu6gsVaE hQR/mZNcNag1rH/RjcVoox7iTgvKxyBh3VVT2dEX4vebLdt2/rwIgz626XDSTeUmJQ+ZAgMBAAGj ggOBMIIDfTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEF BQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwJAYDVR0RBB0wG4EZUmlja19BbmRy ZXdzQHN5bWFudGVjLmNvbTAfBgNVHSMEGDAWgBSkM6+ww0aHq+V4SbK04kaf6gn8FTCCAWQGCCsG AQUFBwEBBIIBVjCCAVIwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTCC ASUGCCsGAQUFBzAChoIBF2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIw U3ltYW50ZWMlMjBDbGFzcyUyMDIlMjBFbXBsb3llZSUyMENBJTIwLSUyMEczJTJDJTIwT1UlMjAl M0QlMjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIl MjBDQSUyQyUyME9VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkMlMjBPJTIw JTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3JhdGlvbiUyQyUyMEMlMjAlM0QlMjBVUz9jQUNlcnRpZmlj YXRlO2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9j YV8yYzc5ZDVmMGM0NTZlMGUzZTJmYjNlMjM2OTAzZGExNS9MYXRlc3RDUkwuY3JsMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkP BDUwMzAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAr BgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICAQGdpPp0FgUxNjc0ODA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEB CwUAA4IBAQAXM1lZbwfKyY8FFxOxBuM1zaVaoRHcKD6EjwhcTlIeFQSGl/n24G+1xpy6NIe7Mwzp EAwVUwzb3wKFyKnDMdDvPIedes3QyC1yIjA3ZViOLNpIhWmalth1ohXYFGjjLx7eAq6GJ7oorcJH ZCWOMNr4Nm82UlZ4WoOw1W9mU2ll9R4rfDxsWOImko7O0E9fvozhf4B224DA6cin71gk5rFzzzKC Knjv2lUSpjNuOmlcY2LFOIKPyFzpGKRikO/LwfWVsefhppBSRGKaxfbKS9QP8ex1IcZgGbdCTBzW t9u/tgGv8+qMCn347fdIwO3qFAFgGfJULuFLOvdwqtkJZ8CxMYIEsDCCBKwCAQEwgcUwgbAxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFudGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MwIQOVrt7EotOiYavftZTf7D7jAJBgUrDgMCGgUAoIICvzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMDIwMDU0NTNaMCMGCSqGSIb3DQEJBDEWBBRJBpmT5JeY tVP1Mo0/xik55r/RZjCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQME ARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAsGCWCGSAFlAwQCATCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEdMBsG A1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MSowKAYDVQQDEyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37 WU3+w+4wgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNV BAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMSowKAYDVQQD EyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37WU3+w+4wDQYJ KoZIhvcNAQEBBQAEggEAZh62g0ko4/ffajtWQ8E49UyaSfsqRB7HxvjsOfAZxBhxe6z0MPi4++yA ks+9wkhzx5iADG0B0CxyRG/mfP9tnTM/wFlPeXBIrfM5mks6le9pFn6dyiGw7MHz/iMr9m29ykOi UXmpmM3m4T9NaZdvM67Plu5SKXjqqk/Fkjdm/+RPJKmwem+8peTFWGG8gjbrs9ZBdV4E2WaXsRsk ZgyiFbJEO+qWmKT4yxKDyLNxO259b4AAluQLCAPyUqq2hvnIxUXRJgfwP33yHaJ8ESSl35CTltg+ 0RQ8VX4Vb5jabfqbnLEbAxPyE942XvWLFedNJ7xeudJLVt/ytQPeGgbF/gAAAAAAAA== ------=_NextPart_000_03C2_01D15D11.45AA2220-- From nobody Tue Feb 2 05:07:30 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73DD1B2A92 for ; Tue, 2 Feb 2016 05:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtHEdIoW3LRO for ; Tue, 2 Feb 2016 05:07:25 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D519B1B2A90 for ; Tue, 2 Feb 2016 05:07:25 -0800 (PST) Received: from localhost ([::1]:41282 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQag1-0008Fa-Gf; Tue, 02 Feb 2016 05:07:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: benl@google.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 13:07:25 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/113#comment:3 Message-ID: <080.fbae805a2a9ecfb2f09d988fe872d892@tools.ietf.org> References: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #113 (rfc6962-bis): Add advice about the tls-feature TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 13:07:29 -0000 #113: Add advice about the tls-feature TLS extension Comment (by benl@google.com): Partially fixed at https://github.com/google/certificate-transparency- rfcs/commit/2db89658eda02bf97c6b6bf71f8c99df4cbbd664 -- --------------------------------------+------------------------------ Reporter: rob.stradling@comodo.com | Owner: benl@google.com Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------ Ticket URL: trans From nobody Tue Feb 2 09:15:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5661AC3A1 for ; Tue, 2 Feb 2016 09:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u2RQb3qjHZO for ; Tue, 2 Feb 2016 09:15:04 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94D31B2D76 for ; Tue, 2 Feb 2016 09:15:04 -0800 (PST) Received: from localhost ([::1]:50560 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQeXg-0006yZ-KI; Tue, 02 Feb 2016 09:15:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pphaneuf@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 17:15:04 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/112#comment:2 Message-ID: <080.af8e0b39cca3db755103ce154d626465@tools.ietf.org> References: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pphaneuf@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #112 (rfc6962-bis): Consider permitting the status_request_v2 TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:15:06 -0000 #112: Consider permitting the status_request_v2 TLS extension Comment (by pphaneuf@gmail.com): PR sent to address this issue: https://github.com/google/certificate-transparency-rfcs/pull/124/files -- --------------------------------------+--------------------------------- Reporter: rob.stradling@comodo.com | Owner: pphaneuf@gmail.com Type: enhancement | Status: assigned Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+--------------------------------- Ticket URL: trans From nobody Tue Feb 2 12:55:47 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103011B3103 for ; Tue, 2 Feb 2016 12:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQC84Rkcm5QC for ; Tue, 2 Feb 2016 12:55:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8931B3102 for ; Tue, 2 Feb 2016 12:55:44 -0800 (PST) Received: from localhost ([::1]:40538 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQhzA-0001k4-I4; Tue, 02 Feb 2016 12:55:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 20:55:40 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/140#comment:4 Message-ID: <068.e923a401c30c39f339475ea000b340c3@tools.ietf.org> References: <053.78d7c5ba597b70394bf4a637fe45004b@tools.ietf.org> X-Trac-Ticket-ID: 140 In-Reply-To: <053.78d7c5ba597b70394bf4a637fe45004b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #140 (rfc6962-bis): move section 8 to CA specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:55:46 -0000 #140: move section 8 to CA specification Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed Comment: Agreed that the additional material should be in a different document. -- --------------------------+--------------------------------------- Reporter: kseo@bbn.com | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Feb 2 12:56:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB5B1B3103 for ; Tue, 2 Feb 2016 12:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdVwTVj3ATaP for ; Tue, 2 Feb 2016 12:56:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F591B3107 for ; Tue, 2 Feb 2016 12:56:16 -0800 (PST) Received: from localhost ([::1]:40584 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQhzd-00025v-AO; Tue, 02 Feb 2016 12:56:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, kent@bbn.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 20:56:09 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/78#comment:12 Message-ID: <068.4dbc2514af513c018e59eeabb05bbfdf@tools.ietf.org> References: <053.21d5f5aa5787a7a10daa132c9e70dbef@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <053.21d5f5aa5787a7a10daa132c9e70dbef@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, kent@bbn.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:56:18 -0000 #78: algorithm agility discussion is inadequate Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Tue Feb 2 12:56:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716E51B3106 for ; Tue, 2 Feb 2016 12:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsXjFoOLH_pe for ; Tue, 2 Feb 2016 12:56:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6728E1B3103 for ; Tue, 2 Feb 2016 12:56:40 -0800 (PST) Received: from localhost ([::1]:40620 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi01-0003DT-DO; Tue, 02 Feb 2016 12:56:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hadfieldp@google.com, rob.stradling@comodo.com, paul@nohats.ca, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 20:56:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/87#comment:5 Message-ID: <071.64ce2d9e712f431ec44e308990013fe2@tools.ietf.org> References: <056.bd3f7d75e177baac5a41da407f8d0a60@tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <056.bd3f7d75e177baac5a41da407f8d0a60@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hadfieldp@google.com, 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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #87 (rfc6962-bis): Add reference to threat analysis document X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:56:41 -0000 #87: Add reference to threat analysis document Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -----------------------------+----------------------------------- Reporter: benl@google.com | Owner: hadfieldp@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+----------------------------------- Ticket URL: trans From nobody Tue Feb 2 12:57:06 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895811B3107 for ; Tue, 2 Feb 2016 12:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DIfpgcDFZTR for ; Tue, 2 Feb 2016 12:57:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1E91B3106 for ; Tue, 2 Feb 2016 12:57:03 -0800 (PST) Received: from localhost ([::1]:40647 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi0R-0004UI-Iz; Tue, 02 Feb 2016 12:56:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, benl@google.com, rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 20:56:59 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/94#comment:9 Message-ID: <072.3eec9163467931a92e159cc6af143d31@tools.ietf.org> References: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.6f8fe4b62debfa6614f5c143e08cacaf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, benl@google.com, rob.stradling@comodo.com, melinda.shore@gmail.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:57:04 -0000 #94: Fetching of inclusion proofs: Why and when are clients expected to do this? Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Tue Feb 2 12:57:46 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2255B1B3113 for ; Tue, 2 Feb 2016 12:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKO4c0f41xvV for ; Tue, 2 Feb 2016 12:57:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DE51B3112 for ; Tue, 2 Feb 2016 12:57:44 -0800 (PST) Received: from localhost ([::1]:40694 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi19-00017m-Nl; Tue, 02 Feb 2016 12:57:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 20:57:43 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/97#comment:2 Message-ID: <080.0cc502c7fdcc1e1ab74110fdd46f4036@tools.ietf.org> References: <065.543a100087070dd152bde158ebf8bcd5@tools.ietf.org> X-Trac-Ticket-ID: 97 In-Reply-To: <065.543a100087070dd152bde158ebf8bcd5@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:57:45 -0000 #97: Allocate an OID for CMS precertificates Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: closed Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Feb 2 12:58:31 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69DA1B311A for ; Tue, 2 Feb 2016 12:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj0z9NBCzPR4 for ; Tue, 2 Feb 2016 12:58:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDD31B3119 for ; Tue, 2 Feb 2016 12:58:28 -0800 (PST) Received: from localhost ([::1]:40740 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi1s-0003sU-G1; Tue, 02 Feb 2016 12:58:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 20:58:28 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/108#comment:4 Message-ID: <072.35e672d6b100c81c59d74f0f0eb0b1e0@tools.ietf.org> References: <057.8f17b4f83cbab8f69b04ee24db7840b5@tools.ietf.org> X-Trac-Ticket-ID: 108 In-Reply-To: <057.8f17b4f83cbab8f69b04ee24db7840b5@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #108 (rfc6962-bis): TLS session resumption: Server MUST NOT send SCTs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:58:30 -0000 #108: TLS session resumption: Server MUST NOT send SCTs Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Feb 2 12:59:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DA01B3121 for ; Tue, 2 Feb 2016 12:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjPyXon_Ok_c for ; Tue, 2 Feb 2016 12:59:32 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD59A1B311A for ; Tue, 2 Feb 2016 12:59:32 -0800 (PST) Received: from localhost ([::1]:40818 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi2u-0005W5-Gw; Tue, 02 Feb 2016 12:59:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 20:59:32 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/119#comment:4 Message-ID: <068.b05084ac7acf2bd45c292875a3df3c1e@tools.ietf.org> References: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-Trac-Ticket-ID: 119 In-Reply-To: <053.cde297cb92c78068428ffb6acabae547@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #119 (rfc6962-bis): confusing wording about log checking in Introduction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:59:34 -0000 #119: confusing wording about log checking in Introduction Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- --------------------------+---------------------------------- Reporter: kent@bbn.com | Owner: katjoyce@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------+---------------------------------- Ticket URL: trans From nobody Tue Feb 2 13:00:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03471B3124 for ; Tue, 2 Feb 2016 13:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyvN1ISaCMod for ; Tue, 2 Feb 2016 13:00:09 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657C01B3125 for ; Tue, 2 Feb 2016 13:00:09 -0800 (PST) Received: from localhost ([::1]:40886 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi3U-0006p5-VD; Tue, 02 Feb 2016 13:00:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 21:00:08 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/120#comment:4 Message-ID: <068.e83bf8cddc6f6a2a26b8a8c7ffd15054@tools.ietf.org> References: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-Trac-Ticket-ID: 120 In-Reply-To: <053.c3d3e5b6e8a68041db650c761b676a09@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #120 (rfc6962-bis): public vs. private logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:00:11 -0000 #120: public vs. private logs? Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Tue Feb 2 13:03:58 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187D31B3125 for ; Tue, 2 Feb 2016 13:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwq1AHnesWmr for ; Tue, 2 Feb 2016 13:03:53 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 792161B2E57 for ; Tue, 2 Feb 2016 13:03:53 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id cy9so439266pac.0 for ; Tue, 02 Feb 2016 13:03:53 -0800 (PST) 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 :content-type:content-transfer-encoding; bh=oMhThQ3V6LoKXzzhJXZur7HUZLHBBFb5pNP/kuDhi+c=; b=0ltgK2W34wbPAns+lXokcn51gY5jvsbUeNTf2pR/aytsISqw1cW9b3jWskYGez3NZ2 IWkksFE5BWafGlr7EWePSuqD/sbWv/UMnAUyD3+3tDXwGxz0oYJFSzJEhdqA6Q+uVCyp jjjyz1ny/lqrIHHJv65nJNJdkIHOHxdozMOvbtrvumxRUDjZylIqxeCh5CUzX4SM6qOT JM5dzEGBboIIu2/rsXMwOHRESR3V05vvOiVFdmkCurLx/sourQCwT8nKx5TcQ6vjeSA1 QSNGgnfinzZgSrhwR1rF+v7DCKZR4Y2xXcLWqF/JO7kVYs0ID1ANpJKgIUVvd96hC7nD 7fjQ== 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:content-type:content-transfer-encoding; bh=oMhThQ3V6LoKXzzhJXZur7HUZLHBBFb5pNP/kuDhi+c=; b=SRRvrhrtAgF5FA1A9SoO9HiUeNCE8a03Km9JRL1LC3j6VqF/KttK8qLpP14COHLsyQ R597n8knEmy8c9tBt9y+Wun3EJmug+u4L7KYhu0do5juF4AO1EcPZEwm1Tk87oT82OG4 mwF6blsc0Y3eImiWdA3fPHqQBu8JVxfeV7PrseIfj5A5uTxo5lNxEV21swqGTpwQuMQ4 YCJmmABdG3/V3nxvrtfTDKkcKh5+gKhDPEC6juQSdRumv6elzAPkYrB3PpJGuDq1P9vu L2BNgExZh0ZiXPNdHGerPAzAFY1C0hc+CqBcbQhXg5bvKRArpyqXDzmmd6YZvltkPGMa v0wA== X-Gm-Message-State: AG10YOToG2jLfjL3c5OILsUoZyIqnc5QOUbDRlRLQXfVOs/HCYps+sc5qCjfkACpKephsw== X-Received: by 10.66.255.39 with SMTP id an7mr50544926pad.101.1454447033139; Tue, 02 Feb 2016 13:03:53 -0800 (PST) Received: from Melindas-MacBook-Pro.local (216-67-35-7-radius.dynamic.acsalaska.net. [216.67.35.7]) by smtp.googlemail.com with ESMTPSA id r77sm4703944pfa.47.2016.02.02.13.03.52 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 13:03:52 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: <56B1192D.4020102@gmail.com> Date: Tue, 2 Feb 2016 12:01:33 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Looking for feedback on open issue X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:03:55 -0000 Hi, all: We're looking for feedback on ticket 121 (https://trac.tools.ietf.org/wg/trans/trac/ticket/121). The issue is this (from Steve Kent): "After Prague I agreed that log metadata can be supplied by browser vendors for TLS clients hat are browsers. However, max chain length, which was just discussed on the list (11/16-17/15), is an example of metadata that needs to be acquired by CAs, just like the public key for a log. The text in Section 9 needs to say more about how non-browser log clients are expected to acquire this data, or maybe it should say that separate docs defining requirements for each of these types of log clients will discuss this issue." and where it currently stands is this (from Eran Messeri): I agree that log metadata dissemination is a topic that should be more thoroughly discussed at some point. However, I do not think that 6962-bis is the right place for it. Steve has a very valid point about metadata not being specified in a machine-readable format, nor having a part of the protocol describing how it is disseminated. I believe these issues should be addressed separately of 6962-bis, because: The topic of log metadata is one level "above" what 6962-bis discusses. The requirements for metadata dissemination are very different for each type of client. Disseminating metadata reliably is a protocol in itself, which (once the requirements are clear) deserve its own design. My suggestion is to punt the discussion until after 6962-bis is out. Presumably then there would be enough different clients implementing 6962-bis that disseminating metadata would justify more efforts from this workgroup. This needs further discussion - should this go into a separate document? Melinda From nobody Tue Feb 2 13:04:30 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAED1B312E for ; Tue, 2 Feb 2016 13:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSyPvsku0VH9 for ; Tue, 2 Feb 2016 13:04:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B461B312A for ; Tue, 2 Feb 2016 13:04:27 -0800 (PST) Received: from localhost ([::1]:41217 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi7c-0005tK-QR; Tue, 02 Feb 2016 13:04:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com, david@mandelberg.org, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 21:04:24 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/126#comment:6 Message-ID: <076.bd93f384025d6f9265ad5d6fbb5b6860@tools.ietf.org> References: <061.da6341e1ce9ff98f35f5de603a32600f@tools.ietf.org> X-Trac-Ticket-ID: 126 In-Reply-To: <061.da6341e1ce9ff98f35f5de603a32600f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, david@mandelberg.org, benl@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #126 (rfc6962-bis): text leaves open the possibility that a submitter might not verify the returned SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:04:28 -0000 #126: text leaves open the possibility that a submitter might not verify the returned SCT Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- ----------------------------------+--------------------------------------- Reporter: david@mandelberg.org | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Feb 2 13:04:46 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495171B2E97 for ; Tue, 2 Feb 2016 13:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 KuPTUu6JDEmz for ; Tue, 2 Feb 2016 13:04:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F26F1B312D for ; Tue, 2 Feb 2016 13:04:44 -0800 (PST) Received: from localhost ([::1]:41243 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi7w-0006VA-4b; Tue, 02 Feb 2016 13:04:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, mhs@google.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 21:04:44 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/133#comment:3 Message-ID: <076.def12cbffdca8f56379b3fc37327f576@tools.ietf.org> References: <061.974bf9e97eb053e6226d9fcca2573e34@tools.ietf.org> X-Trac-Ticket-ID: 133 In-Reply-To: <061.974bf9e97eb053e6226d9fcca2573e34@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, mhs@google.com, benl@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160202210444.9F26F1B312D@ietfa.amsl.com> Resent-Date: Tue, 2 Feb 2016 13:04:44 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #133 (rfc6962-bis): incomplete Misbehaving Logs section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:04:46 -0000 #133: incomplete Misbehaving Logs section Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- david@mandelberg.org | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Feb 2 13:05:06 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E41B312A for ; Tue, 2 Feb 2016 13:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q_a8J-lhP0o for ; Tue, 2 Feb 2016 13:05:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C651B2E97 for ; Tue, 2 Feb 2016 13:05:03 -0800 (PST) Received: from localhost ([::1]:41277 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi8E-0006tg-Oa; Tue, 02 Feb 2016 13:05:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pphaneuf@gmail.com, eijdenberg@google.com, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 21:05:02 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/127#comment:6 Message-ID: <076.4295b35ec7eeb1cf6a104bb9a64063d4@tools.ietf.org> References: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-Trac-Ticket-ID: 127 In-Reply-To: <061.22bb8a92c66ca31760471d9f2838a139@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pphaneuf@gmail.com, eijdenberg@google.com, rob.stradling@comodo.com, benl@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #127 (rfc6962-bis): confusing case is allowed: submission of pre-cert without embedding SCT in issued cert X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:05:05 -0000 #127: confusing case is allowed: submission of pre-cert without embedding SCT in issued cert Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- ----------------------------------+--------------------------------- Reporter: david@mandelberg.org | Owner: pphaneuf@gmail.com Type: enhancement | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------------------- Ticket URL: trans From nobody Tue Feb 2 13:05:23 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6FD1B3136 for ; Tue, 2 Feb 2016 13:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 SwFr5Y8cktFA for ; Tue, 2 Feb 2016 13:05:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8824F1B3125 for ; Tue, 2 Feb 2016 13:05:21 -0800 (PST) Received: from localhost ([::1]:41312 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQi8W-00078w-Hq; Tue, 02 Feb 2016 13:05:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, mhs@google.com, rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 02 Feb 2016 21:05:20 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/138#comment:3 Message-ID: <068.6ebb021e3688cc85b703be7b648304b6@tools.ietf.org> References: <053.8f7a6c4f44f8a37e28a8e378e222bb45@tools.ietf.org> X-Trac-Ticket-ID: 138 In-Reply-To: <053.8f7a6c4f44f8a37e28a8e378e222bb45@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, mhs@google.com, rob.stradling@comodo.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160202210521.8824F1B3125@ietfa.amsl.com> Resent-Date: Tue, 2 Feb 2016 13:05:21 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #138 (rfc6962-bis): use of term before defining it X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:05:22 -0000 #138: use of term before defining it Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 3 03:03:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74C91AC3B0 for ; Wed, 3 Feb 2016 03:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy7tCJTejke7 for ; Wed, 3 Feb 2016 03:03:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371971AC3AF for ; Wed, 3 Feb 2016 03:03:50 -0800 (PST) Received: from localhost ([::1]:58590 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQvDu-00047m-KQ; Wed, 03 Feb 2016 03:03:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, linus@nordu.net X-Trac-Project: trans Date: Wed, 03 Feb 2016 11:03:46 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/109#comment:4 Message-ID: <077.c9933032f8a758039676c8fb24aafc48@tools.ietf.org> References: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #109 (rfc6962-bis): log shutdown timeline and behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 11:03:52 -0000 #109: log shutdown timeline and behavior Changes (by eranm@google.com): * milestone: => review Comment: Committed in https://github.com/eranmes/certificate-transparency- rfcs/commit/aff27bb64072c95072b9c9ce4fd874c0920fd6bd . dkg / linus, please let me know if the added text still doesn't address the Gossip protocol's needs. -- -----------------------------------+------------------------------- Reporter: dkg@fifthhorseman.net | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------------+------------------------------- Ticket URL: trans From nobody Wed Feb 3 05:18:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB791A8AAC for ; Wed, 3 Feb 2016 05:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 W3580kZ3oj8j for ; Wed, 3 Feb 2016 05:18:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE561A8AAF for ; Wed, 3 Feb 2016 05:18:10 -0800 (PST) Received: from localhost ([::1]:34031 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aQxJy-0004Cb-AR; Wed, 03 Feb 2016 05:18:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, hadfieldp@google.com X-Trac-Project: trans Date: Wed, 03 Feb 2016 13:18:10 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/118#comment:2 Message-ID: <068.eb167aef4cdb4e99ea6916993131e35f@tools.ietf.org> References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-Trac-Ticket-ID: 118 In-Reply-To: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160203131811.0DE561A8AAF@ietfa.amsl.com> Resent-Date: Wed, 3 Feb 2016 05:18:10 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:18:13 -0000 #118: Monitor function description problem Changes (by hadfieldp@google.com): * owner: hadfieldp@google.com => draft-ietf-trans- rfc6962-bis@tools.ietf.org * status: assigned => new -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 3 05:37:14 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E41AC3D9 for ; Wed, 3 Feb 2016 05:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BqNFi7lTBVM for ; Wed, 3 Feb 2016 05:37:09 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454F31A8A04 for ; Wed, 3 Feb 2016 05:37:09 -0800 (PST) Received: (qmail 5248 invoked by uid 1004); 3 Feb 2016 13:37:06 -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; Wed, 03 Feb 2016 13:37:06 +0000 Received: (qmail 23398 invoked by uid 1000); 3 Feb 2016 13:37:06 -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; Wed, 03 Feb 2016 13:37:06 +0000 To: Rick Andrews , Stephen Kent , "trans@ietf.org" References: <065.543a100087070dd152bde158ebf8bcd5@tools.ietf.org> <080.6a83e16be95e70d20aae59adf2497f0a@tools.ietf.org> <56AFAC9F.1000408@bbn.com> From: Rob Stradling Message-ID: <56B20282.1030204@comodo.com> Date: Wed, 3 Feb 2016 13:37:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:37:12 -0000 On 02/02/16 00:54, Rick Andrews wrote: > Stephen, Rob was looking to shave off a few bytes from each OID by starting > with a small arc, which Thawte has. Rick, Thanks (and thanks for the OIDs too :-) ). Yes, that is indeed the case. Short OIDs for the various X.509v3 extensions and LogIDs will avoid unnecessary bloat in certificates, SCTs, etc. Steve, I know the chairs are happy to use short OIDs from thawte's OID arc, so that's how we're proceeding. > -Rick > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent > Sent: Monday, February 01, 2016 11:06 AM > To: trans@ietf.org > Subject: Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS > precertificates > > Rob, > > Why not use an IETF arc for the OIDs? That's more consistent with IETF > standards practice. > > Steve >> #97: Allocate an OID for CMS precertificates >> >> Changes (by rob.stradling@comodo.com): >> >> * owner: benl@google.com => rob.stradling@comodo.com >> >> >> Comment: >> >> Cancel that request. >> >> Symantec have agreed to donate some OIDs under the thawte 1.3.101 OID > arc. >> Let's use one of them here. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Wed Feb 3 05:43:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B26F1AC3F8 for ; Wed, 3 Feb 2016 05:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgUYPD7i6BgA for ; Wed, 3 Feb 2016 05:43:33 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D501AC3F5 for ; Wed, 3 Feb 2016 05:43:32 -0800 (PST) Received: (qmail 5589 invoked by uid 1004); 3 Feb 2016 13:43:30 -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; Wed, 03 Feb 2016 13:43:30 +0000 Received: (qmail 25886 invoked by uid 1000); 3 Feb 2016 13:43:30 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 03 Feb 2016 13:43:30 +0000 To: trans@ietf.org From: Rob Stradling Message-ID: <56B20401.3020606@comodo.com> Date: Wed, 3 Feb 2016 13:43:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Trans] Oh... X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:43:34 -0000 http://trac.tools.ietf.org/wg/trans/trac/report/1 currently returns... "Oops… Trac detected an internal error: OperationalError: database or disk is full" Who can fix this? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Feb 3 05:47:06 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B641AC3F9 for ; Wed, 3 Feb 2016 05:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6RHSVWQoJ0Q for ; Wed, 3 Feb 2016 05:47:02 -0800 (PST) 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 965C81AC3F8 for ; Wed, 3 Feb 2016 05:47:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 48E6CBE75; Wed, 3 Feb 2016 13:47:00 +0000 (GMT) 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 SNMKalE2cDWu; Wed, 3 Feb 2016 13:47:00 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CAD63BE58; Wed, 3 Feb 2016 13:46:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454507220; bh=FMeZhpi15EHX34huc19aj3X5e4LHgf9HTzjBiAL/Xd4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=l82vtqf8pQvMq7/mjy+3ZTG4dw17+oOjbVzyVgjx6mzOJ2LFNVypgeD2GnjuofyMG CFq3D2sxx+oOR6mJIuN3lNe1vOLGD8q/aj/RtJeGsofnYgVIurpWTS4WOK+A5NkFXi OpdfoMYO4DxGknvafGFi4faCmHpRR4DwXZzoavIo= To: Rob Stradling , trans@ietf.org References: <56B20401.3020606@comodo.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56B204D3.3040100@cs.tcd.ie> Date: Wed, 3 Feb 2016 13:46:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B20401.3020606@comodo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Trans] Oh... X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:47:05 -0000 On 03/02/16 13:43, Rob Stradling wrote: > http://trac.tools.ietf.org/wg/trans/trac/report/1 currently returns... > > "Oops… > > Trac detected an internal error: > OperationalError: database or disk is full" > > Who can fix this? I'm not seeing that here FWIW, it looks fine. I'd say report to ietf-action@ietf.org so a ticket is opened, Cheers, S. > From nobody Wed Feb 3 05:53:02 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130D01AC42F for ; Wed, 3 Feb 2016 05:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1izfp5a6FDcI for ; Wed, 3 Feb 2016 05:52:59 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7B81AC432 for ; Wed, 3 Feb 2016 05:52:59 -0800 (PST) Received: (qmail 6232 invoked by uid 1004); 3 Feb 2016 13:52: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; Wed, 03 Feb 2016 13:52:57 +0000 Received: (qmail 4813 invoked by uid 1000); 3 Feb 2016 13:52: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; Wed, 03 Feb 2016 13:52:57 +0000 To: Stephen Farrell , trans@ietf.org References: <56B20401.3020606@comodo.com> <56B204D3.3040100@cs.tcd.ie> From: Rob Stradling Message-ID: <56B20638.7060405@comodo.com> Date: Wed, 3 Feb 2016 13:52:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56B204D3.3040100@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Trans] Oh... X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:53:01 -0000 On 03/02/16 13:46, Stephen Farrell wrote: > > > On 03/02/16 13:43, Rob Stradling wrote: >> http://trac.tools.ietf.org/wg/trans/trac/report/1 currently returns... >> >> "Oops… >> >> Trac detected an internal error: >> OperationalError: database or disk is full" >> >> Who can fix this? > > I'm not seeing that here FWIW, it looks fine. > > I'd say report to ietf-action@ietf.org > so a ticket is opened, Thanks Stephen. I was half way through composing that message, but somebody seems to have fixed it already. :-) > Cheers, > S. > > >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Wed Feb 3 06:03:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A8E1ACC7F for ; Wed, 3 Feb 2016 06:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weA0gXv8s_ki for ; Wed, 3 Feb 2016 06:03:13 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 D7DFA1ACC72 for ; Wed, 3 Feb 2016 06:03:11 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id xg9so2133930igb.1 for ; Wed, 03 Feb 2016 06:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pjhrusupe2pzuxoHOyfHANm39Ikn/4UOILM7AhhS0pg=; b=W5uHcBcw1NAQ5F9C7+jG05JDVbWIdiCyHuErYxsZPODuMqRt3Zls26kCHJO6REhGUL SOHvlFZPQHIH3pQ/u+8rNIQNG7bgH2xxQXXHtkU+n/QFaJSz/nV8KiS9QbFS4J1/ijD/ BAJEv3uCZ51SKSojMu+XbA0nmIrcqSQWqAi+/4MGOahgvebz94zwQdWLqRetAbLmAyVF Q6DpE7Zjx+9ukewnmMKB8MftlGoEQ4rCVnUmwP/z/8amW/pUQm3Csuh/9Oxpck5tG9fZ EmzOQqCow8NuFOkaUOGZRMMv8VfQ2Ai36Z0cIjN57xiUDX/H13lunw55UgCBGg6PEIp8 y+Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Pjhrusupe2pzuxoHOyfHANm39Ikn/4UOILM7AhhS0pg=; b=kSsm2jkLB7UF7dOgOSGkmRyQHpNgQP8pVIUKAjqDUiC6NTYd9LOb31jGJcQXsWrVVF 5vMPhZaF1LStfQgeGM90Qvv2NLbAYLdDdXJcmzaknf9Z2R9QkdWVXblgFzu3cHZyZ0IN biZJnrIM3AwDPmqXORg7hcCsaQaU3a8AVgl63ipGTjN6amvuIH1QX9Ax4rE7hFwCf1Hl bnWBoE2ArVuivKWiBZQHmInLlJI18niUlOba+HQnss+aAquBa45THtjV9ZaYHovxSUdg VRUI7xyC+Zar28BDWK5yEwjAeHr8Bk4PGLYL1lmyq19xP7jiYv+W7qk5srdouottW9fn stKw== X-Gm-Message-State: AG10YOTwJ/0DO596icGqM2aOVtkTLIUWXMqYZvaZ1Wdwh2QNnrHE0Ky+i6jD12yJIxJp8xg/QMBdIkyvJF8yOly+ MIME-Version: 1.0 X-Received: by 10.50.33.80 with SMTP id p16mr22594281igi.23.1454508191183; Wed, 03 Feb 2016 06:03:11 -0800 (PST) Received: by 10.64.26.98 with HTTP; Wed, 3 Feb 2016 06:03:11 -0800 (PST) In-Reply-To: <56B1192D.4020102@gmail.com> References: <56B1192D.4020102@gmail.com> Date: Wed, 3 Feb 2016 14:03:11 +0000 Message-ID: From: Ben Laurie To: Melinda Shore Content-Type: multipart/alternative; boundary=089e01538d8c0f9a91052ade1407 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Looking for feedback on open issue X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 14:03:19 -0000 --089e01538d8c0f9a91052ade1407 Content-Type: text/plain; charset=UTF-8 On 2 February 2016 at 21:01, Melinda Shore wrote: > Hi, all: > > We're looking for feedback on ticket 121 > (https://trac.tools.ietf.org/wg/trans/trac/ticket/121). > > The issue is this (from Steve Kent): > > "After Prague I agreed that log metadata can be supplied by browser > vendors for TLS clients hat are browsers. However, max chain length, which > was just discussed on the list (11/16-17/15), is an example of metadata > that needs to be acquired by CAs, just like the public key for a log. The > text in Section 9 needs to say more about how non-browser log clients are > expected to acquire this data, or maybe it should say that separate docs > defining requirements for each of these types of log clients will discuss > this issue." > > > and where it currently stands is this (from Eran Messeri): > > I agree that log metadata dissemination is a topic that should be more > thoroughly discussed at some point. However, I do not think that 6962-bis > is the right place for it. > Steve has a very valid point about metadata not being specified in a > machine-readable format, nor having a part of the protocol describing how > it is disseminated. > I believe these issues should be addressed separately of 6962-bis, because: > The topic of log metadata is one level "above" what 6962-bis discusses. > The requirements for metadata dissemination are very different for each > type of client. > Disseminating metadata reliably is a protocol in itself, which (once the > requirements are clear) deserve its own design. > My suggestion is to punt the discussion until after 6962-bis is out. > Presumably then there would be enough different clients implementing > 6962-bis that disseminating metadata would justify more efforts from this > workgroup. > > This needs further discussion - should this go into a separate > document? > If it needs documenting at all, then yes. > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --089e01538d8c0f9a91052ade1407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 February 2016 at 21:01, Melinda Shore <melinda.shore@gmail.= com> wrote:
Hi, all:

We're looking for feedback on ticket 121
(https://trac.tools.ietf.org/wg/trans/trac/ticke= t/121).

The issue is this (from Steve Kent):

"After Prague I agreed that log metadata can be supplied by browser ve= ndors for TLS clients hat are browsers. However, max chain length, which wa= s just discussed on the list (11/16-17/15), is an example of metadata that = needs to be acquired by CAs, just like the public key for a log. The text i= n Section 9 needs to say more about how non-browser log clients are expecte= d to acquire this data, or maybe it should say that separate docs defining = requirements for each of these types of log clients will discuss this issue= ."


and where it currently stands is this (from Eran Messeri):

I agree that log metadata dissemination is a topic that should be more thor= oughly discussed at some point. However, I do not think that 6962-bis is th= e right place for it.
Steve has a very valid point about metadata not being specified in a machin= e-readable format, nor having a part of the protocol describing how it is d= isseminated.
I believe these issues should be addressed separately of 6962-bis, because:=
The topic of log metadata is one level "above" what 6962-bis disc= usses.
The requirements for metadata dissemination are very different for each typ= e of client.
Disseminating metadata reliably is a protocol in itself, which (once the re= quirements are clear) deserve its own design.
My suggestion is to punt the discussion until after 6962-bis is out. Presum= ably then there would be enough different clients implementing 6962-bis tha= t disseminating metadata would justify more efforts from this workgroup.
This needs further discussion - should this go into a separate
document?

If it needs documenting at al= l, then yes.
=C2=A0

Melinda

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

--089e01538d8c0f9a91052ade1407-- From nobody Wed Feb 3 07:22:47 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD791ACE24 for ; Wed, 3 Feb 2016 07:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwL21kZjTcTi for ; Wed, 3 Feb 2016 07:22:44 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 078F01ACE23 for ; Wed, 3 Feb 2016 07:22:44 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 7CAF09A553A for ; Wed, 3 Feb 2016 10:22:42 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id S67XBW22fiK1 for ; Wed, 3 Feb 2016 10:21:34 -0500 (EST) Received: from [10.129.227.73] (unknown [141.161.133.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 33AEF9A5519 for ; Wed, 3 Feb 2016 10:22:42 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <56B204D3.3040100@cs.tcd.ie> Date: Wed, 3 Feb 2016 10:22:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1152B8E8-1A16-4AEC-944F-807ACBDF3AC5@vigilsec.com> References: <56B20401.3020606@comodo.com> <56B204D3.3040100@cs.tcd.ie> To: trans@ietf.org X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [Trans] Oh... X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 15:22:46 -0000 The tools.ietf.org disk was indeed full. I reported it to the admin, = and he promptly cleared some space. I'm glad all is now well. The tools team is working to move the issue trackers to ietf.org. This = should resolve this problem going forward. Russ On Feb 3, 2016, at 8:46 AM, Stephen Farrell wrote: > On 03/02/16 13:43, Rob Stradling wrote: >> http://trac.tools.ietf.org/wg/trans/trac/report/1 currently = returns... >>=20 >> "Oops=85 >>=20 >> Trac detected an internal error: >> OperationalError: database or disk is full" >>=20 >> Who can fix this? >=20 > I'm not seeing that here FWIW, it looks fine. >=20 > I'd say report to ietf-action@ietf.org > so a ticket is opened, >=20 > Cheers, > S. From nobody Wed Feb 3 08:11:02 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF251AD2A9 for ; Wed, 3 Feb 2016 08:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbFX3BR5SdAS for ; Wed, 3 Feb 2016 08:11:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE6F1AD289 for ; Wed, 3 Feb 2016 08:11:00 -0800 (PST) Received: from localhost ([::1]:39898 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aR01E-0002ma-D5; Wed, 03 Feb 2016 08:11:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Wed, 03 Feb 2016 16:11:00 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:9 Message-ID: <072.3b53e9e0d491e1029418761cc26beaf6@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:11:02 -0000 #115: Verify that recommended consistency checking algorithm is correct Comment (by katjoyce@google.com): Changes being reviewed in https://github.com/google/certificate- transparency-rfcs/pull/125 -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: reopened Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Wed Feb 3 08:11:58 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7711AD28D for ; Wed, 3 Feb 2016 08:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuZeTwSYMPNT for ; Wed, 3 Feb 2016 08:11:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DD41AD2B2 for ; Wed, 3 Feb 2016 08:11:55 -0800 (PST) Received: from localhost ([::1]:39926 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aR027-0004oW-IU; Wed, 03 Feb 2016 08:11:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pphaneuf@gmail.com X-Trac-Project: trans Date: Wed, 03 Feb 2016 16:11:55 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/112#comment:3 Message-ID: <080.050d9a3d2f51126afc91c3b2e3532013@tools.ietf.org> References: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pphaneuf@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #112 (rfc6962-bis): Consider permitting the status_request_v2 TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:11:57 -0000 #112: Consider permitting the status_request_v2 TLS extension Changes (by pphaneuf@gmail.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/9c921489a544a9538da05328f5f51fc772774fb9 -- --------------------------------------+--------------------------------- Reporter: rob.stradling@comodo.com | Owner: pphaneuf@gmail.com Type: enhancement | Status: assigned Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+--------------------------------- Ticket URL: trans From nobody Wed Feb 3 08:12:23 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894EA1AD305 for ; Wed, 3 Feb 2016 08:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csutNY7wAxpD for ; Wed, 3 Feb 2016 08:12:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6041AD2F2 for ; Wed, 3 Feb 2016 08:12:21 -0800 (PST) Received: from localhost ([::1]:39936 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aR02V-0005ew-UM; Wed, 03 Feb 2016 08:12:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, linus@nordu.net, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 03 Feb 2016 16:12:19 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/109#comment:5 Message-ID: <077.732c3d0aa2ae54915c38e6ccb18d83c8@tools.ietf.org> References: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <062.8a15bd7ae88012b6b5059ac3eec8d52c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, linus@nordu.net, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #109 (rfc6962-bis): log shutdown timeline and behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:12:22 -0000 #109: log shutdown timeline and behavior Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -----------------------------------+------------------------------- Reporter: dkg@fifthhorseman.net | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+------------------------------- Ticket URL: trans From nobody Wed Feb 3 08:13:57 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258211A870D for ; Wed, 3 Feb 2016 08:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 fiTo_i_sWhEH for ; Wed, 3 Feb 2016 08:13:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549351AD244 for ; Wed, 3 Feb 2016 08:13:56 -0800 (PST) Received: from localhost ([::1]:39958 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aR042-0007us-Ei; Wed, 03 Feb 2016 08:13:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, kent@bbn.com, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 03 Feb 2016 16:13:54 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/121#comment:4 Message-ID: <068.9588c046fdcaf2a3a5c9ddb439485f2d@tools.ietf.org> References: <053.2d6c03925075fce7d9903f2cd1b7e49a@tools.ietf.org> X-Trac-Ticket-ID: 121 In-Reply-To: <053.2d6c03925075fce7d9903f2cd1b7e49a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, kent@bbn.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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160203161356.549351AD244@ietfa.amsl.com> Resent-Date: Wed, 3 Feb 2016 08:13:56 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #121 (rfc6962-bis): log metadata dissemination X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:13:57 -0000 #121: log metadata dissemination Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => wontfix Comment: This will need to be revisited in a different document. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 3 08:14:26 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C8F1AD2EE for ; Wed, 3 Feb 2016 08:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D47Tv0oQE8_O for ; Wed, 3 Feb 2016 08:14:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D671AD2D5 for ; Wed, 3 Feb 2016 08:14:23 -0800 (PST) Received: from localhost ([::1]:39968 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aR04V-0008Ug-HH; Wed, 03 Feb 2016 08:14:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: pphaneuf@gmail.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 03 Feb 2016 16:14:23 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/112#comment:4 Message-ID: <080.41d4a605e3b60b90832c04ee95c97457@tools.ietf.org> References: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <065.b01f21df0d7399c64bdd6ff0713592b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pphaneuf@gmail.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #112 (rfc6962-bis): Consider permitting the status_request_v2 TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:14:25 -0000 #112: Consider permitting the status_request_v2 TLS extension Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- --------------------------------------+--------------------------------- Reporter: rob.stradling@comodo.com | Owner: pphaneuf@gmail.com Type: enhancement | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------+--------------------------------- Ticket URL: trans From nobody Wed Feb 3 08:14:41 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B770E1AD2AF for ; Wed, 3 Feb 2016 08:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d0qO4rZltoe for ; Wed, 3 Feb 2016 08:14:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F8A1A870D for ; Wed, 3 Feb 2016 08:14:36 -0800 (PST) Received: from localhost ([::1]:39972 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aR04h-0000Kw-Dj; Wed, 03 Feb 2016 08:14:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Wed, 03 Feb 2016 16:14:35 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:10 Message-ID: <072.be8dfbb702c249c446fb03daea68a5c6@tools.ietf.org> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 16:14:40 -0000 #23: How can TLS clients match an SCT to a certificate? Comment (by eranm@google.com): Strongly support removing the ItemExtension field. -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Wed Feb 3 09:14:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03661B32D2 for ; Wed, 3 Feb 2016 09:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgdZHlq7tUiE for ; Wed, 3 Feb 2016 09:14:40 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 E1D0F1B2CD2 for ; Wed, 3 Feb 2016 09:14:39 -0800 (PST) Received: by mail-yk0-x22a.google.com with SMTP id z7so24514620yka.3 for ; Wed, 03 Feb 2016 09:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+v6ZIpgB3+jb/AG8LuoW05V9XpW0EPvcSoPODJrc6m4=; b=AJKKWtwSNMynvvyWqCl2akKYoy2SJhE+OO8dym19WJA5Xit6xzMLm9w19NqjI9dHtu GMD8xFG2VDl5tpZexSmYAdjZeBBbBdQy8ArTPtpqCjRc/1ToZ5rkxIVsa3UhZ66U4Cvw a9yTQ64LN8oXGmefW/TueQ4kQZddDNJ9IqV+UVOD4uoERWa7dnme1CbH3d8sdl9txH+O WxIOYS3XxowLKNhBlca8Z4A4fmJAb1xxJbyIVINeMrexW7x6HoSeFongYLtf2qoi+hyI v+nqGEjayWIgLKHcAP5K25T45LUs44p/byvudUSmHyVx4WIOoz+Yk4ZlmzwRRRSXWMmc TuaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+v6ZIpgB3+jb/AG8LuoW05V9XpW0EPvcSoPODJrc6m4=; b=fFoK9CeWeZIein4EwGBEv5qU1BCIRLeTmuytmHIQqDSLnNISkhpKcJeHjeWzQS46sr +HVqk1io6heW2API+jztxbyRcGMiQHCoJSocpP71fTiIOnIcvDXaw87TwfmVk90dFImV LCRubHrIycN+LltChqhsiXoE5cWrplARTCehOgQ/jwWS1y3oeC6rn3bt0mxp+EOav4th 0v2jUYYRxIJXDEpTPwZ9200LRIf5GG2lIJ8nxo44I27DWuYB660PiSmoeDFBCQPgM7eI KiFfWzhFYxrOFdoWu5IxBU3NcPQzIPnHG7d6LHX+t/23G/8++7YeFg1/dOD+EHH5jthI bxHA== X-Gm-Message-State: AG10YORibNrouzlChYwDiqJRM1Gp2uR6OYDw0yngwa4EX2DrkMeSAChW/5xuITPWDVYdkjZ1BurNFxjpwvbAqaIF MIME-Version: 1.0 X-Received: by 10.37.70.134 with SMTP id t128mr1725846yba.90.1454519678968; Wed, 03 Feb 2016 09:14:38 -0800 (PST) Received: by 10.37.210.71 with HTTP; Wed, 3 Feb 2016 09:14:38 -0800 (PST) In-Reply-To: <5696885E.1020905@bbn.com> References: <5696885E.1020905@bbn.com> Date: Wed, 3 Feb 2016 17:14:38 +0000 Message-ID: From: Eran Messeri To: Stephen Kent Content-Type: multipart/alternative; boundary=001a1138f95ac8ded6052ae0c0e6 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Review of the architecture document (draft 1) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 17:14:42 -0000 --001a1138f95ac8ded6052ae0c0e6 Content-Type: text/plain; charset=UTF-8 Thanks for addressing all of my comments. On Wed, Jan 13, 2016 at 5:24 PM, Stephen Kent wrote: > Eran, > > Thanks for the careful reading of the architecture doc, and the comments. > Response below, in-line. > > > Overall the relationships between the different entities that participate >> in CT are well described in this document. The diagrams and concise >> description of the roles of each entity make it easy to read and >> understand. It should serve well to establish common terminology around CT. >> > thanks. > >> >> Most comments I have are nitpicks - I realize there's a trade-off between >> accuracy and conciseness and tried only pointing out where (I think) it's >> significant. >> >> Issues filed: >> Ticket #148 - Architecture document: Spelling/improvements to Introduction >> Ticket #149 - Architecture document: Figure 1: Finer-grained distinction >> between entities >> Ticket #150 - Architecture document: Indicate missing SCT is equivalent >> to invalid one. >> Ticket #151 - Architecture document: Only the leaf cert + timestamp are >> in the SCT. >> Ticket #152 - Architecture document: CT-aware TLS clients may require >> SCTs for all certs. >> > I have responded to each ticket, using the issue tracker, so I won't > repeat those responses here. > >> Other comments and suggestions: >> >> On section 3, The elements of CT architecture: >> Figure 2: >> - Browsers also need to get fresh STHs and consistency proofs between >> STHs to use the output of get-proof-by-hash. >> > I would say that somewhat differently; browsers may choose to get this > info so that > they can have higher confidence that an SCT really corresponds to a log > entry. But saying > that browsers "nee" to get this info seems a bit too stringent, at this > time. This is a topic > for the browser spec, an initial version of which was posted by David > Mandleberg late last year. > >> - Suggesting to drop the "Browser Vendor" component as it's arguably >> redundant - a browser vendor would care about the output of the auditor. >> > We included BV as a separate component because of its role in providing > log metadata to browsers > and as a source of revocation status data. I agree that a BV cares about > Auditor info. I think > we said that explicitly > >> - Suggest adding a footnote that "An auditor can actively verify MMD >> compliance by submitting new entries to the log and checking when they're >> appended to the tree.". >> > good point. We might mention that here, but it's primarily a topic for the > Auditor spec. > >> >> Figure 3: >> - Nitpick, but subjects may request revocation from CAs - Is it more >> common for browsers to accept revocation requests from subjects or base >> their blacklists on CRLs issued by CAs? if the latter, than the figure may >> be less surprising if that's the path stated there. >> > yes, in general, a Subject requests a CA to revoke its own cert, or one > issued in the name of > the Subject. Sorry that we omitted that line. We'll add it. the Figure > does not show a browser > requesting revocation of a cert, just getting revocation status data from > ether a CA or a BV, > > >> Figure 4, repeating later in section 3.3 Monitors: >> - The acceptable public keys may be optional - a monitor may simply >> notify a Subject of each new certificate it observes. While I don't think >> this option should be mentioned everywhere monitors are mentioned, it's >> worth noting there may be other operation modes for monitors. >> > I agree that a Monitor could do that, but such behavior is not mentioned > in 6962-bis, nor in the > Monitor/Auditor spec we posted. This is a good example of why we need to > have more discussion > in the WG about what behavior we expect for all elements of CT, not just > the log. I agree that we should have more discussion in the WG about the behaviour expected for all elements of CT - I don't think it should hold up 6962-bis, though, which describes the protocol these elements use to exchange information they have about certificates and logs. I very much like to see CT evolve and there are definitely areas for clarification on what monitors / clients should do with observations about certificates / CT logs they obtain. I just think that without implementing and deploying the basic protocol described in 6962-bis it will be very hard to gain the insight on what clients and monitors should do. I find the documents you and your team produce explore very well the actions each entity can take and 6962-bis is (IMHO) designed in an extensible way to enable exchanging more information, should we discover the original specification lacked it. > > >> 3.5. CT-aware TLS clients: >> - One paragraphe before the end, mentioning feedback to log operators via >> subjects - suggest adding an explicit reference to the section in the >> Gossip draft that describes this reporting mechanism (or at least >> explicitly state the Gossip document describes such a mechanism). >> > The architecture doc is focused on what CT standards call for, and the > Gossip doc is currently > designated as Experimental. So I am reluctant to cite it. However, if you > propose a sentence > or two to add to this section, we can see if it fits. My proposal is along the lines of "The Gossip protocol described in is one of the mechanisms that may be used to feed the information back to log operators." > > >> 3.6. Auditors: >> - For MMD monitoring, I suggest indicating that an auditor can check MMD >> actively by submitting new entries to the log (either by issuing them or by >> gathering them from the internet and feeding them to the log). That's what >> Google's monitor does, for example. >> > As I said above, this is primarily a topic for the Auditor spec, but I > will add the following text after the first sentence in the paragraph: For > example, an Auditor might submit an certificate to a log and request an STH > after the indicated MMD, to verify that the log is meeting its advertised > MMD. > >> >> Regarding the TBD parts (Monitor-auditor, CA-subject, browser-vendor), >> what prevents writing them? Shall I have a go at contributing text? >> > The architecture doc was posted on 12/17, before we posted the I-Ds for > each of TBD references you noted above. Those I-Ds were posted on 12/19, > 12/23, and 12/24. Comments/contributions are welcome for these documents > too. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1138f95ac8ded6052ae0c0e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for addressing all of my comments.

On Wed, Jan 13, 2016 at 5:24 PM, S= tephen Kent <kent@bbn.com> wrote:
Eran,

Thanks for the careful reading of the architecture doc, and the comments.= =C2=A0 Response below, in-line.


Overall the relationships between the different entities that participate i= n CT are well described in this document. The diagrams and concise descript= ion of the roles of each entity make it easy to read and understand. It sho= uld serve well to establish common terminology around CT.
 thanks.

Most comments I have are nitpicks - I realize there's a trade-off betwe= en accuracy and conciseness and tried only pointing out where (I think) it&= #39;s significant.

Issues filed:
Ticket #148 - Architecture document: Spelling/improvements to Introduction<= br> Ticket #149 - Architecture document: Figure 1: Finer-grained distinction be= tween entities
Ticket #150 - Architecture document: Indicate missing SCT is equivalent to = invalid one.
Ticket #151 - Architecture document: Only the leaf cert + timestamp are in = the SCT.
Ticket #152 - Architecture document: CT-aware TLS clients may require SCTs = for all certs.
 I have responded to each ticket, using the issue tracker, so I won't re= peat those responses here.
Other comments and suggestions:

On section 3, The elements of CT architecture:
Figure 2:
- Browsers also need to get fresh STHs and consistency proofs between STHs = to use the output of get-proof-by-hash.
 I would say that somewhat differently; browsers may choose to get this info= so that
they can have higher confidence that an SCT really corresponds to a log ent= ry. But saying
that browsers "nee" to get this info seems a bit too stringent, a= t this time. This is a topic
for the browser spec, an initial version of which was posted by David Mandl= eberg late last year.
- Suggesting to drop the "Browser Vendor" component as it's a= rguably redundant - a browser vendor would care about the output of the aud= itor.
 We included BV as a separate component because of its role in providing log= metadata to browsers
and as a source of revocation status data. I agree that a BV cares about Au= ditor info. I think
we said that explicitly
- Suggest adding a footnote that "An auditor can actively verify MMD c= ompliance by submitting new entries to the log and checking when they'r= e appended to the tree.".
 good point. We might mention that here, but it's primarily a topic for = the Auditor spec.

Figure 3:
- Nitpick, but subjects may request revocation from CAs - Is it more common= for browsers to accept revocation requests from subjects or base their bla= cklists on CRLs issued by CAs? if the latter, than the figure may be less s= urprising if that's the path stated there.
 yes, in general, a Subject requests a CA to revoke its own cert, or one iss= ued in the name of
the Subject. Sorry that we omitted that line. We'll add it. the Figure = does not show a browser
requesting revocation of a cert, just getting revocation status data from e= ther a CA or a BV,


Figure 4, repeating later in section 3.3 Monitors:
- The acceptable public keys may be optional - a monitor may simply notify = a Subject of each new certificate it observes. While I don't think this= option should be mentioned everywhere monitors are mentioned, it's wor= th noting there may be other operation modes for monitors.
 I agree that a Monitor could do that, but such behavior is not mentioned in= 6962-bis, nor in the
Monitor/Auditor spec we posted. This is a good example of why we need to ha= ve more discussion
in the WG about what behavior we expect for all elements of CT, not just th= e log.
I agree that we should have more discussion in the = WG about the behaviour expected for all elements of CT - I don't think = it should hold up 6962-bis, though, which describes the protocol these elem= ents use to exchange information they have about certificates and logs.
I very much like to see CT evolve and there are definitely areas for= clarification on what monitors / clients =C2=A0should do with observations= about certificates / CT logs they obtain. I just think that without implem= enting and deploying the basic protocol described in 6962-bis it will be ve= ry hard to gain the insight on what clients and monitors should do. I find = the documents you and your team produce explore very well the actions each = entity can take and 6962-bis is (IMHO) designed in an extensible way to ena= ble exchanging more information, should we discover the original specificat= ion lacked it.


3.5. CT-aware TLS clients:
- One paragraphe before the end, mentioning feedback to log operators via s= ubjects - suggest adding an explicit reference to the section in the Gossip= draft that describes this reporting mechanism (or at least explicitly stat= e the Gossip document describes such a mechanism).
 The architecture doc is focused on what CT standards call for, and the Goss= ip doc is currently
designated as Experimental. So I am reluctant to cite it. However, if you p= ropose a sentence
or two to add to this section, we can see if it fits.
My p= roposal is along the lines of "The Gossip protocol described in <re= ference to Gossip I-D> is one of the mechanisms that may be used to feed= the information back to log operators."=C2=A0


3.6. Auditors:
- For MMD monitoring, I suggest indicating that an auditor can check MMD ac= tively by submitting new entries to the log (either by issuing them or by g= athering them from the internet and feeding them to the log). That's wh= at Google's monitor does, for example.
 As I said above, this is primarily a topic for the Auditor spec, but I will= add the following text after the first sentence in the paragraph:=C2=A0 Fo= r example, an Auditor might submit an certificate to a log and request an S= TH after the indicated MMD, to verify that the log is meeting its advertise= d MMD.

Regarding the TBD parts=C2=A0 (Monitor-auditor, CA-subject, browser-vendor)= , what prevents writing them? Shall I have a go at contributing text?
 The architecture doc was posted on 12/17, before we posted the I-Ds for eac= h of TBD references you noted above. Those I-Ds were posted on 12/19, 12/23= , and 12/24. Comments/contributions are welcome for these documents too.
Steve


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

--001a1138f95ac8ded6052ae0c0e6-- From nobody Wed Feb 3 09:21:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FA51B3544 for ; Wed, 3 Feb 2016 09:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpHVi9GxNKAy for ; Wed, 3 Feb 2016 09:21:29 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A58E1B3540 for ; Wed, 3 Feb 2016 09:21:28 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id r207so24885244ykd.2 for ; Wed, 03 Feb 2016 09:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mZSwUyyxXeVc0xJRA6NWFEv64Cf4w28JExCJrocnyA0=; b=ML5nssegNLyCRE8sC5SgP/+itC1VB7xRt+z/qQARGOoQWCMEXxbW0ANUpZqndWlCAc ZLG/0QtRNcfUWGt6ab9XWhrUf9Cd9JAa3p6hX7le1NGLYWds9F4ylo+1JY/Flo+Cz+G3 xH8Wv9H5uQCHSpW/SXJJCAtTsQiSJ8ppyjhJUuz2mwPmkL5RLxzm6K6QkDQ2VtEhUKXq 9y7Y/ncTZFgNwyrCwRMW0dL04IjIbIGdbnT6uJsNv6ilMwKFZ6Nk87mBSbPsxTdk/CBd FXMQDULK1gV0TqnqC+ZKdYEbrbQtsm4kOTBAdslkWaRZKBZvXvUJXtEtw1OObR1puM3y /Mpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mZSwUyyxXeVc0xJRA6NWFEv64Cf4w28JExCJrocnyA0=; b=BWSkdRyBvvXNgA1lFVZ5yHXl+/UDJxaMtsKMkWet9/hdHJCtURC1lBuKwlTL50ltnU n4udk2WhkVlIUvatdYUY2ekq13Jlr9yXYoXC1APRgIOS45HtEbr2XrUkrGfznB7X7+AV VN1s0wBkZ/sRz46c06WF6AMuvCvBz+MR8NkJJ6wIHxQoQiRVMJExirSnt7B4ycqv03Z3 z7cqFJE+chntxrRojLZAsiwa9sSZkzuUQfCVTx3GcEXZPRb7Gadc/Fy1ZKaV2vCZ9Hc6 FVwQpeugny4j6QwICIfRAGllh/491MRRggr5PMXDT9lFxqK184lQcx7QsOJKmx8ShzUn sH0A== X-Gm-Message-State: AG10YORh17a7P0Lgs7NhyRwUGB0pQqCP2eki1JfbEkVDjRdnYlOsOSWmGYeh+sBEEcts8M/98m7H1zqs4ARFicJr MIME-Version: 1.0 X-Received: by 10.129.41.197 with SMTP id p188mr1683952ywp.83.1454520087524; Wed, 03 Feb 2016 09:21:27 -0800 (PST) Received: by 10.37.210.71 with HTTP; Wed, 3 Feb 2016 09:21:27 -0800 (PST) In-Reply-To: <568D7AC3.2000301@bbn.com> References: <057.35eb1e87b6861f551e4f028e2b93c3f4@tools.ietf.org> <072.7f4522d84e6f746100b591d7f670bc35@tools.ietf.org> <5672E115.1010701@bbn.com> <568D7AC3.2000301@bbn.com> Date: Wed, 3 Feb 2016 17:21:27 +0000 Message-ID: From: Eran Messeri To: Stephen Kent Content-Type: multipart/alternative; boundary=001a1142218622f145052ae0d97b Archived-At: Cc: Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] [trans] #93 (rfc6962-bis): Monitor description: Inconsistency between intro and section 5.4 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 17:21:31 -0000 --001a1142218622f145052ae0d97b Content-Type: text/plain; charset=UTF-8 Risking resurrection of an old thread, I'll point out that when addressing ticket 141 more text was added about auditing, which should clarify what a monitor can do if it's interested in auditing. Ticket 118 seems to repeat the concern originally raised in ticket 93, but we couldn't come up with text that would be meaningful and address the concern raised in that ticket. On Wed, Jan 6, 2016 at 8:36 PM, Stephen Kent wrote: > Paul, > > On Thu, 17 Dec 2015, Stephen Kent wrote: >> >> I also agree that the architecture document provides a more in-depth >>> description of the Monitor function, but it is also at odds with the >>> description in the -11 draft. So, I disagree with the proposal to >>> leave the current text in place. >>> >> >> Then please provide improved text (not scaffolding) for the bis document. >> >> Paul >> > I have done so, via the issue tracker. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1142218622f145052ae0d97b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Risking resurrection of an old thread, I'll point out = that when addressing ticket 141 more text was added about audit= ing, which should clarify what a monitor can do if it's interested in a= uditing.
Ticket 118=C2=A0seems to repeat the concern originally raised in tick= et 93, but we couldn't come up with text that would be meaningful and a= ddress the concern raised in that ticket.=C2=A0

On Wed, Jan 6, 2016 at 8:36= PM, Stephen Kent <kent@bbn.com> wrote:
Paul,

On Thu, 17 Dec 2015, Stephen Kent wrote:

I also agree that the architecture document provides a more in-depth
description of the Monitor function, but it is also at odds with the
description in the -11 draft. So, I disagree with the proposal to
leave the current text in place.

Then please provide improved text (not scaffolding) for the bis document.
Paul
 I have done so, via the issue tracker.

Steve


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

--001a1142218622f145052ae0d97b-- From nobody Thu Feb 4 06:02:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD72F1B2FC0 for ; Thu, 4 Feb 2016 06:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BM8DmpFkGl4 for ; Thu, 4 Feb 2016 06:02:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBFD1B2FBF for ; Thu, 4 Feb 2016 06:02:27 -0800 (PST) Received: from localhost ([::1]:60926 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aRKUN-0002H8-4y; Thu, 04 Feb 2016 06:02:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Thu, 04 Feb 2016 14:02:27 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:10 Message-ID: <072.83e601bd76ce0d18c5bebb4b905c17ac@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.com, benl@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 14:02:32 -0000 #115: Verify that recommended consistency checking algorithm is correct Changes (by katjoyce@google.com): * milestone: => review -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Thu Feb 4 14:55:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ED11B302C for ; Thu, 4 Feb 2016 14:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni9uPGbT84Fz for ; Thu, 4 Feb 2016 14:55:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB991ACDF6 for ; Thu, 4 Feb 2016 14:55:46 -0800 (PST) Received: from localhost ([::1]:54646 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aRSoS-0004VD-SA; Thu, 04 Feb 2016 14:55:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: katjoyce@google.com, benl@google.com, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Thu, 04 Feb 2016 22:55:44 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/115#comment:11 Message-ID: <072.2b86bf8f4bf42d40a702e99e3c0c11c8@tools.ietf.org> References: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-Trac-Ticket-ID: 115 In-Reply-To: <057.76cacca68508c20f86951a4bd3efc5d4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: katjoyce@google.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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #115 (rfc6962-bis): Verify that recommended consistency checking algorithm is correct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 22:55:47 -0000 #115: Verify that recommended consistency checking algorithm is correct Changes (by melinda.shore@gmail.com): * status: reopened => closed * resolution: => fixed -- ------------------------------+---------------------------------- Reporter: eranm@google.com | Owner: katjoyce@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+---------------------------------- Ticket URL: trans From nobody Wed Feb 10 05:54:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E50F1B2AD1 for ; Wed, 10 Feb 2016 05:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO8B-VB3AGtU for ; Wed, 10 Feb 2016 05:54:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914B71B2ACE for ; Wed, 10 Feb 2016 05:54:34 -0800 (PST) Received: from localhost ([::1]:44937 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aTVDx-000359-PH; Wed, 10 Feb 2016 05:54:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: benl@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 10 Feb 2016 13:54:29 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/113#comment:4 Message-ID: <080.cf0c27f7788c425ab9a719fa7cc7bbef@tools.ietf.org> References: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #113 (rfc6962-bis): Add advice about the tls-feature TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:54:36 -0000 #113: Add advice about the tls-feature TLS extension Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fully fixed at https://github.com/google/certificate-transparency- rfcs/commit/a24fca772c3b95198cc909fd5aceb04003063ae4 -- --------------------------------------+------------------------------ Reporter: rob.stradling@comodo.com | Owner: benl@google.com Type: enhancement | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------ Ticket URL: trans From nobody Wed Feb 10 10:47:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37CB1B2EA7 for ; Wed, 10 Feb 2016 10:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igfKqJwACoEl for ; Wed, 10 Feb 2016 10:46:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D401B2EA2 for ; Wed, 10 Feb 2016 10:46:51 -0800 (PST) Received: from localhost ([::1]:51557 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aTZmo-0004Mz-VD; Wed, 10 Feb 2016 10:46:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: benl@google.com, rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 10 Feb 2016 18:46:46 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/113#comment:5 Message-ID: <080.37f786a57725f69793989554f2507c59@tools.ietf.org> References: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-Trac-Ticket-ID: 113 In-Reply-To: <065.8f41cde794fd67bf6002a6d73a817caf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, rob.stradling@comodo.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #113 (rfc6962-bis): Add advice about the tls-feature TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:47:02 -0000 #113: Add advice about the tls-feature TLS extension Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- --------------------------------------+------------------------------ Reporter: rob.stradling@comodo.com | Owner: benl@google.com Type: enhancement | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------+------------------------------ Ticket URL: trans From nobody Fri Feb 12 02:57:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4980E1B4354 for ; Fri, 12 Feb 2016 02:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4iMzvuapwnI for ; Fri, 12 Feb 2016 02:57:25 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B28B1B4353 for ; Fri, 12 Feb 2016 02:57:25 -0800 (PST) Received: from localhost ([::1]:35680 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aUBPd-0005Du-Gt; Fri, 12 Feb 2016 02:57:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, 12 Feb 2016 10:57:21 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/154 Message-ID: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org> X-Trac-Ticket-ID: 154 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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #154 (rfc6962-bis): CSR extension to convey a certificate subscriber's CT preferences to the CA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 10:57:27 -0000 #154: CSR extension to convey a certificate subscriber's CT preferences to the CA Some certificate subscribers might want to communicate various CT-related things to the CA. For example... - Please generate a Precertificate and then embed SCTs in the certificate. - I'm using OCSP Stapling; please embed SCTs in OCSP Responses for this certificate. - Please embed inclusion proofs (rather than SCTs) in the certificate; I accept that this will delay issuance of the certificate. - Please embed SCTs from as many logs as possible. - Please embed SCTs from logs X, Y and Z, and not from logs A, B or C. - Please do _not_ log this certificate to any logs; I accept that some TLS clients may reject the certificate due to CT non-compliance. Some CAs might permit these sorts of details to be specified in a
on a webpage when the subscriber requests the certificate. That's great, but it probably won't work for everyone. In particular, putting this information in a CSR extension would make it possible to tunnel it through ACME or via a certificate reseller. (I'm assigning this ticket to the rfc6962-bis component for now, but I see no particular reason why it couldn't be punted to some other document. I don't want this ticket to delay WGLC for 6962-bis). -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Feb 12 03:25:10 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE521B43B4 for ; Fri, 12 Feb 2016 03:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY1XBDNeq4UU for ; Fri, 12 Feb 2016 03:25:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A921B43AA for ; Fri, 12 Feb 2016 03:25:06 -0800 (PST) Received: from localhost ([::1]:36623 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aUBqR-0005bq-SB; Fri, 12 Feb 2016 03:25:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, hadfieldp@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 12 Feb 2016 11:25:03 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/57#comment:5 Message-ID: <080.f875f5cd7784718a262b89052db38f88@tools.ietf.org> References: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, hadfieldp@google.com, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #57 (rfc6962-bis): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 11:25:07 -0000 #57: Clients MUST NOT match the redaction label with a "*" label Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com -- --------------------------------------+------------------------------- Reporter: rob.stradling@comodo.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------- Ticket URL: trans From nobody Fri Feb 12 04:31:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF921B44C1 for ; Fri, 12 Feb 2016 04:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv8QDTYOJTI5 for ; Fri, 12 Feb 2016 04:31:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C288E1B44BE for ; Fri, 12 Feb 2016 04:31:10 -0800 (PST) Received: from localhost ([::1]:38233 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aUCsM-00008s-V4; Fri, 12 Feb 2016 04:31:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, 12 Feb 2016 12:31:06 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/53#comment:2 Message-ID: <080.2e188deb8d5938ae6d54629a35e84dfe@tools.ietf.org> References: <065.91c71031616569cc5fc58c5bf85dfc5e@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <065.91c71031616569cc5fc58c5bf85dfc5e@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #53 (rfc6962-bis): Clarify log entry ordering requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 12:31:12 -0000 #53: Clarify log entry ordering requirements Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/5187c60fea03f4910e15bcd71c430d920f28308b -- -------------------------------------+------------------------------------- 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 Feb 12 12:38:27 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9E41A89AA for ; Fri, 12 Feb 2016 12:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdThHBIbYjRe for ; Fri, 12 Feb 2016 12:38:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FC91A899C for ; Fri, 12 Feb 2016 12:38:23 -0800 (PST) Received: from localhost ([::1]:40250 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aUKTq-0005CE-TT; Fri, 12 Feb 2016 12:38:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Fri, 12 Feb 2016 20:38:18 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/53#comment:3 Message-ID: <080.7ae0aca03789c3c9b98e0e2fda442dd5@tools.ietf.org> References: <065.91c71031616569cc5fc58c5bf85dfc5e@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <065.91c71031616569cc5fc58c5bf85dfc5e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #53 (rfc6962-bis): Clarify log entry ordering requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 20:38:24 -0000 #53: Clarify log entry ordering requirements 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 Tue Feb 16 06:03:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37261B36B5 for ; Tue, 16 Feb 2016 06:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VtrWk78uhlj for ; Tue, 16 Feb 2016 06:03:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FF11B3697 for ; Tue, 16 Feb 2016 06:03:19 -0800 (PST) Received: from localhost ([::1]:33506 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aVgDi-0007sJ-EB; Tue, 16 Feb 2016 06:03:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Tue, 16 Feb 2016 14:03:14 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:11 Message-ID: <072.ee7a69299880709258377930de8c1a93@tools.ietf.org> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 14:03:23 -0000 #23: How can TLS clients match an SCT to a certificate? Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/d71d7707a3eeb5707cf5048c3849b068e477038c The !ItemExtension field is gone. When there's a suitably name- constrained intermediate in the certificate chain, TLS clients may need to use trial and error to determine which of the certificates in the chain an SCT or inclusion proof corresponds to. -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Feb 16 09:36:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5171ACD7D for ; Tue, 16 Feb 2016 09:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQWWsLJrRxVb for ; Tue, 16 Feb 2016 09:36:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FEB41A88B3 for ; Tue, 16 Feb 2016 09:36:23 -0800 (PST) Received: from localhost ([::1]:35500 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aVjXu-00035o-AA; Tue, 16 Feb 2016 09:36:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 16 Feb 2016 17:36:18 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/23#comment:12 Message-ID: <072.fe9112c12efc869ec9147dc77904932a@tools.ietf.org> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 17:36:25 -0000 #23: How can TLS clients match an SCT to a certificate? Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Wed Feb 17 04:50:31 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C062A1B392A for ; Wed, 17 Feb 2016 04:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WANT=2.3, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHT56dw6E3NH for ; Wed, 17 Feb 2016 04:50:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AC31B391E for ; Wed, 17 Feb 2016 04:50:28 -0800 (PST) Received: from localhost ([::1]:52657 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aW1Yp-0001zh-Re; Wed, 17 Feb 2016 04:50:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hadfieldp@google.com X-Trac-Project: trans Date: Wed, 17 Feb 2016 12:50:27 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/143#comment:2 Message-ID: <068.804c99a71fc1944e90000f7c227e0b3a@tools.ietf.org> References: <053.dda9576385fcf4615156c78a473241af@tools.ietf.org> X-Trac-Ticket-ID: 143 In-Reply-To: <053.dda9576385fcf4615156c78a473241af@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #143 (rfc6962-bis): Putting TLS server guidance in one place X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 12:50:29 -0000 #143: Putting TLS server guidance in one place Changes (by hadfieldp@google.com): * status: assigned => closed * resolution: => fixed Comment: This was fixed a while ago in https://github.com/google/certificate- transparency-rfcs/commit/e3d53bbd748878f4a641e572c5a42b1c3e3e5383 but wan't marked as fixed here -- doing so now. -- --------------------------+----------------------------------- Reporter: kseo@bbn.com | Owner: hadfieldp@google.com Type: defect | Status: closed Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------+----------------------------------- Ticket URL: trans From nobody Thu Feb 18 09:34:31 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0000E1B2C3E for ; Thu, 18 Feb 2016 09:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 beaJ_iYsBZRh for ; Thu, 18 Feb 2016 09:34:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510BC1B2C98 for ; Thu, 18 Feb 2016 09:34:25 -0800 (PST) Received: from localhost ([::1]:49690 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWSTA-0001Od-PG; Thu, 18 Feb 2016 09:34:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com X-Trac-Project: trans Date: Thu, 18 Feb 2016 17:34:24 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/122#comment:1 Message-ID: <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> X-Trac-Ticket-ID: 122 In-Reply-To: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160218173425.510BC1B2C98@ietfa.amsl.com> Resent-Date: Thu, 18 Feb 2016 09:34:25 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:34:30 -0000 #122: TLS server requirements Changes (by benl@google.com): * milestone: => review Comment: That makes no sense to me - without defining how CT data is communicated, CT can't be used at all. Suggest resolve as wontfix. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Feb 18 09:38:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1011A8F43 for ; Thu, 18 Feb 2016 09:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppC93fxzYIBr for ; Thu, 18 Feb 2016 09:38:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839281A8A87 for ; Thu, 18 Feb 2016 09:38:12 -0800 (PST) Received: from localhost ([::1]:49975 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWSWq-0005Kl-99; Thu, 18 Feb 2016 09:38:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com X-Trac-Project: trans Date: Thu, 18 Feb 2016 17:38:12 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/123#comment:1 Message-ID: <068.d19af4a885287eecc4596e837195df4b@tools.ietf.org> References: <053.1c580d171592bb2acabeaa241fef51ff@tools.ietf.org> X-Trac-Ticket-ID: 123 In-Reply-To: <053.1c580d171592bb2acabeaa241fef51ff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160218173812.839281A8A87@ietfa.amsl.com> Resent-Date: Thu, 18 Feb 2016 09:38:12 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #123 (rfc6962-bis): log clients description too informal, incomplete X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:38:14 -0000 #123: log clients description too informal, incomplete Changes (by benl@google.com): * milestone: => review Comment: The point is that CT provides data you might choose to act on. This section describes some ways in which you can reliably get hold of the data you might choose to act on. It is intended to be informative and without it would make it substantially difficult for implementers to implement CT. Suggest resolve wontfix. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Feb 18 09:39:45 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEDC1A8F4A for ; Thu, 18 Feb 2016 09:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 KmqebeoKaNac for ; Thu, 18 Feb 2016 09:39:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A081ACEFE for ; Thu, 18 Feb 2016 09:39:42 -0800 (PST) Received: from localhost ([::1]:50055 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWSYH-0005hq-O2; Thu, 18 Feb 2016 09:39:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com X-Trac-Project: trans Date: Thu, 18 Feb 2016 17:39:41 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/139#comment:1 Message-ID: <068.f6d8cfb35c1bd9e2deedfb8e5098fa39@tools.ietf.org> References: <053.3e65853a87a6fd2b6925890c73673cd7@tools.ietf.org> X-Trac-Ticket-ID: 139 In-Reply-To: <053.3e65853a87a6fd2b6925890c73673cd7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160218173942.39A081ACEFE@ietfa.amsl.com> Resent-Date: Thu, 18 Feb 2016 09:39:42 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #139 (rfc6962-bis): move text re: domain labels to CA specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:39:43 -0000 #139: move text re: domain labels to CA specification Changes (by benl@google.com): * milestone: => review Comment: I don't believe the WG has agreed this doc should focus on log operation. Suggest resolve as wontfix. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Feb 18 09:52:51 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430AB1B2CD1 for ; Thu, 18 Feb 2016 09:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 XbljQSMs1XkX for ; Thu, 18 Feb 2016 09:52:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6B31B2D12 for ; Thu, 18 Feb 2016 09:52:49 -0800 (PST) Received: from localhost ([::1]:50986 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWSkx-0001lv-U3; Thu, 18 Feb 2016 09:52:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com, paul@nohats.ca X-Trac-Project: trans Date: Thu, 18 Feb 2016 17:52:47 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/139#comment:2 Message-ID: <068.02b0521449b3a5a5f5d3db47f89e7449@tools.ietf.org> References: <053.3e65853a87a6fd2b6925890c73673cd7@tools.ietf.org> X-Trac-Ticket-ID: 139 In-Reply-To: <053.3e65853a87a6fd2b6925890c73673cd7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, paul@nohats.ca, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160218175249.6D6B31B2D12@ietfa.amsl.com> Resent-Date: Thu, 18 Feb 2016 09:52:49 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #139 (rfc6962-bis): move text re: domain labels to CA specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:52:50 -0000 #139: move text re: domain labels to CA specification Changes (by paul@nohats.ca): * status: new => closed * resolution: => wontfix -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Feb 18 09:53:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A991B2D61 for ; Thu, 18 Feb 2016 09:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 COZ0q6gs0XFP for ; Thu, 18 Feb 2016 09:53:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A15F1B2E4B for ; Thu, 18 Feb 2016 09:53:34 -0800 (PST) Received: from localhost ([::1]:51041 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWSlh-0002A9-Uc; Thu, 18 Feb 2016 09:53:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com, paul@nohats.ca X-Trac-Project: trans Date: Thu, 18 Feb 2016 17:53:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/123#comment:2 Message-ID: <068.2cd084d80fd4fbf79689936d46944eb1@tools.ietf.org> References: <053.1c580d171592bb2acabeaa241fef51ff@tools.ietf.org> X-Trac-Ticket-ID: 123 In-Reply-To: <053.1c580d171592bb2acabeaa241fef51ff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, paul@nohats.ca, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160218175334.7A15F1B2E4B@ietfa.amsl.com> Resent-Date: Thu, 18 Feb 2016 09:53:34 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #123 (rfc6962-bis): log clients description too informal, incomplete X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:53:35 -0000 #123: log clients description too informal, incomplete Changes (by paul@nohats.ca): * status: new => closed * resolution: => wontfix -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Feb 18 09:54:16 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B50F1B2D12 for ; Thu, 18 Feb 2016 09:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable 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 TdUrTIdYHFJI for ; Thu, 18 Feb 2016 09:54:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C461B2DC9 for ; Thu, 18 Feb 2016 09:54:13 -0800 (PST) Received: from localhost ([::1]:51094 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWSmK-0002Qq-QO; Thu, 18 Feb 2016 09:54:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com, paul@nohats.ca X-Trac-Project: trans Date: Thu, 18 Feb 2016 17:54:12 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/122#comment:2 Message-ID: <068.d7de7a57b69cab1577c8f2252c6c2d9c@tools.ietf.org> References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> X-Trac-Ticket-ID: 122 In-Reply-To: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, paul@nohats.ca, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160218175413.C5C461B2DC9@ietfa.amsl.com> Resent-Date: Thu, 18 Feb 2016 09:54:13 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:54:14 -0000 #122: TLS server requirements Changes (by paul@nohats.ca): * status: new => closed * resolution: => wontfix -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Feb 18 09:56:21 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499461A909C for ; Thu, 18 Feb 2016 09:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoC_Y3pORB92 for ; Thu, 18 Feb 2016 09:56:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6501A7000 for ; Thu, 18 Feb 2016 09:56:19 -0800 (PST) Received: from localhost ([::1]:51260 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWSoM-0003FM-2I; Thu, 18 Feb 2016 09:56:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Thu, 18 Feb 2016 17:56:18 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/154#comment:1 Message-ID: <080.b2cdac4764b2c3ea5199d2a1353948f1@tools.ietf.org> References: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org> X-Trac-Ticket-ID: 154 In-Reply-To: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #154 (rfc6962-bis): CSR extension to convey a certificate subscriber's CT preferences to the CA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:56:20 -0000 #154: CSR extension to convey a certificate subscriber's CT preferences to the CA Comment (by benl@google.com): Agree this should probably be a different doc. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Sat Feb 20 23:26:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1021B30C3 for ; Sat, 20 Feb 2016 23:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziqHjrvO3kkL for ; Sat, 20 Feb 2016 23:26:50 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E66ED1B3058 for ; Sat, 20 Feb 2016 23:26:49 -0800 (PST) Received: from fifthhorseman.net (ip174-65-1-125.sd.sd.cox.net [174.65.1.125]) by che.mayfirst.org (Postfix) with ESMTPSA id 406E1F997 for ; Sun, 21 Feb 2016 02:26:46 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 00CE62002A; Sat, 20 Feb 2016 22:05:30 -0500 (EST) From: Daniel Kahn Gillmor To: trans@ietf.org User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sat, 20 Feb 2016 22:05:27 -0500 Message-ID: <87io1i3gqw.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 07:26:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable CT currently focuses on logging end-entity (leaf) certs; as a result, i think that an attacker who can compromise two CAs can keep one of those compromises secret from the CT ecosystem. Consider an attacker who has compromised two widely-accepted root CAs, A and B, and wants to mint usable credentials for host Z. The root CAs each control multiple intermediate authorities: A controls A_1, A_2, etc; B controls B_1, B_2, etc. The attacker creates a new secret key X and using A and B creates two new intermediate authorities A_X and B_X, which both have the same Subject, the same public key, and the same Subject Key Identifier extension. The intermediate authority certs themselves differ, however, because of their issuers. The attacker generates a new end entity secret key Y and produces a cert C (Subject =3D Z, Public Key =3D Y), issued by X. Now we have two possible chains: A -> A_X -> C B -> B_X -> C The attacker logs one of those chains and gets an SCT for cert C. For this example, let's say the A chain gets logged. If C is discovered and exposed as a forgery, then root CA A takes the heat. Either they disavow/revoke their sub-CA A_X or they are rejected From=20TLS client root stores. However, the attacker can still use C in the wild, by supplying the B chain. Note that in this scenario, it's unlikely that space-constrained blacklist-style client updates (e.g. CRLset) will include every leaf certificate that chains to A after A is known-compromised. So TLS clients won't necessarily be warned off of C directly. The B chain (and B_X in particular) won't ever surface in the logs' audit trails, though, because C has already been logged; this looks to me like CT will fail at its goal of detecting misissuance by B. Consider this scenario over time, as well. Once A is publicly-known to be compromised, the attacker can impersonate new targets with the same approach: mint a new leaf cert using X (perhaps fiddling with the validity dates), submit to the logs (and get the SCT) with the A chain, and then deploy with the B chain. How to fix this? A few ideas come to mind, but i'm not convinced of either of them yet: * recommend that clients who care about transparency should expect that all intermediate certs themselves are logged -- 6962bis already permits this, though it seems to be mainly in contemplation of name-constrained intermediate authorities. This expands the number of SCTs or inclusion proofs that need to accompany a chain, and makes verification logic slightly more complicated. * logs could refuse to log any certs that chain back to a known-failed CA (or through a known-bad intermediate CA). This would constrain a dual-compromise attacker from minting new certs after the first CA is known to be compromised. This seems like a useful mitigation, but it's also complictated and delicate. What does "known-failed" mean? What if there is a dispute over the validity of a cert, with one party claiming that it was misissued, and the CA claiming its legitimacy? What if some browser vendors have dropped the CA, and others have not? This puts the logs in a position of being some kind of arbiter of the root store, with very subtle knock-on effects to security of the whole ecosystem if they decide to not drop a CA. Even more subtly, if the public narrative of the compromise ends up being "A_X is bad" (include the intermediate cert in client blacklists and refuse to log things that chain through it) instead of "A is bad" (include the root cert in client blacklists and refuse to log things that chain to it), then the attacker can simply mint multiple intermediate keys (X_0, X_1, etc) and corresponding intermediate certificates at the time of the compromise, and burn/expose them one spoofing attack at a time. Any other ideas? Any holes in the reasoning here? I'd love for this analysis to be mistaken. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWySl3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKBcoP/0Bfa2EO8bhaOjDuZokXgBcA jHnRjuqotTCUqCFJ73dUawdalFMnRi9fEF9A8L8r8lCYC2/dDWFjkXlOWtEqchrv ul/LXVvBmLgk6VJlxrS4h/iBkclNHoKcUPzm26KgbwcmgmJZLnvoso4rER1dAiiO Lz5BH4WUCZvkcDkIxMr4gJF/Ns8AfOQ7zXUqy+Jthb1gtzCc3Pxw1WyilWhdqujL BypbQVRuB9d1VM0C/ddEbOAJHdqKCrUX/g6fkvso70odUWlPJvmZ0Yl9UhqITxzZ cOnWY9Bei54hQfOrqAjaBF6Ekq6oRLsoSEPtTstzWmwo1dPCZbHRmqYpytPPd1co oqtf4A8l0gsysToozlXAWWA8PuSMfLvgzL3N4p3jmSWT6hmMxueDPtSwtysZOM0T WTcFaStvXHslBbbxC7KicDpZjN+NgE/2X/MBocUUUm2rnSczMtE5X6iJvp321tDw bGYy4gfbdgZjwau/Qo0IsKX+P+7M99Bn9/+Kl9Aip5iFk1NFg2a7Y3Bm6JVw9/k2 lnSW4z1TuzgLyiBiDOdmwS4RJyWBd2j2fnqvwyvD5W2lPdCmfH/fLFTkbQwSx1rr 6JhtupGWEdnygFwntwSsjVrc0eIrhCUQ+zaIV9ArArczFQkat8AbYQt2uuE7g6ca QwNNTSL+A+qhP+Gg0rKd =owsk -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 22 03:01:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61F61B3090 for ; Mon, 22 Feb 2016 03:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTqQE0zuT14u for ; Mon, 22 Feb 2016 03:01:28 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B73E1B307F for ; Mon, 22 Feb 2016 03:01:28 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id l127so172532527iof.3 for ; Mon, 22 Feb 2016 03:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3WdTaPK82jM6mrsYXPZ3BxrCHVVHuR97aWBj/UBqy54=; b=FYOrT3cQ1wt/VBxfQHW1gbLxuBIZHjLflJCPci/L0ssJmVr1MxCGXQ2+MoZJE8+YIl oEd21ZLmhsvmVWOo5PqrHV5ASIBAk3pWNCr0X6dtSRiKAmMXpfLqHwuTowDcagKhn4Gw T2U2Wh/hlElAXnzJId7CZYGG70PxwxidW+FRaKrQxuD70E3+NDtUys0tdwWP/rvNopsg wWeZm3PgQd6CJtXppEZ3pRZUCQ0cBGkWN4zWIVw06gI/VBpRkIEwRqpeibUHjI8cHrJ+ 8mvJkA7Sm5+BlWep6kl5ulnUUVeVawUO11OtCp5+QcTnZFAq6TznRyir1bTtFOhxt+/n iNiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3WdTaPK82jM6mrsYXPZ3BxrCHVVHuR97aWBj/UBqy54=; b=OhW/L4lgXGTxnFe/W7MtOiQLBs/F1gleZQpuzvc+xTIhEz9MhqN8FXJ20e/E8EYR2Y Xmpkdbnk+8jbwJgFUP+GooQ+RG2UP+1WsTwY+eZAXgVsLGSyM+AKAm5vExXMoXwZ0ZAv A/hUs9Q+ZLexEWS/SMFbCQFeE7cBD+qqruvVd8dAM6ZCUwuGT+BlJbdEiChuWsAEVEf0 Y3u4uINRr8NHQFFtBqq6WwH7Id1MKefu21v9xkOpZqFET0EhVc5dtbfWiq177MN1qJK8 MpSN/he314q7ZhAPAZ/IUYNC4m2qad6fRCoRwG8nCfMq0UTHPc7NH0ZXUu+SjGqql2gs rscw== X-Gm-Message-State: AG10YORgyqYvhfVLR5AdzJmgzLlqxRGgJ8/yjHOnSFqKx/Vg39y6xRp9zfiEcbCMwsYWXe1xwhIfwMLhJ+wXTdyA MIME-Version: 1.0 X-Received: by 10.107.16.17 with SMTP id y17mr32682757ioi.119.1456138887802; Mon, 22 Feb 2016 03:01:27 -0800 (PST) Received: by 10.64.26.98 with HTTP; Mon, 22 Feb 2016 03:01:27 -0800 (PST) In-Reply-To: <87io1i3gqw.fsf@alice.fifthhorseman.net> References: <87io1i3gqw.fsf@alice.fifthhorseman.net> Date: Mon, 22 Feb 2016 11:01:27 +0000 Message-ID: From: Ben Laurie To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a113ff32827a807052c59c198 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 11:01:30 -0000 --001a113ff32827a807052c59c198 Content-Type: text/plain; charset=UTF-8 On 21 February 2016 at 03:05, Daniel Kahn Gillmor wrote: > CT currently focuses on logging end-entity (leaf) certs; as a result, i > think that an attacker who can compromise two CAs can keep one of those > compromises secret from the CT ecosystem. > > Consider an attacker who has compromised two widely-accepted root CAs, A > and B, and wants to mint usable credentials for host Z. > > The root CAs each control multiple intermediate authorities: A controls > A_1, > A_2, etc; B controls B_1, B_2, etc. > > The attacker creates a new secret key X and using A and B creates two > new intermediate authorities A_X and B_X, which both have the same > Subject, the same public key, and the same Subject Key Identifier > extension. The intermediate authority certs themselves differ, however, > because of their issuers. > > The attacker generates a new end entity secret key Y and produces a cert > C (Subject = Z, Public Key = Y), issued by X. > > Now we have two possible chains: > > A -> A_X -> C > > B -> B_X -> C > > The attacker logs one of those chains and gets an SCT for cert C. For > this example, let's say the A chain gets logged. > > If C is discovered and exposed as a forgery, then root CA A takes the > heat. Either they disavow/revoke their sub-CA A_X or they are rejected > From TLS client root stores. > > However, the attacker can still use C in the wild, by supplying the B > chain. > Up to here, I agree. > Note that in this scenario, it's unlikely that space-constrained > blacklist-style client updates (e.g. CRLset) will include every leaf > certificate that chains to A after A is known-compromised. So TLS > clients won't necessarily be warned off of C directly. It seems to me there are multiple solutions here. The easiest is to not blacklist A_X, but instead to blacklists A_X's subject, which will also blacklist B_X. To be more selective, blacklist the individual certs that were mis-issued (we have a complete list, of course, in the logs) and stop accepting new certs signed by X. > > The B chain (and B_X in particular) won't ever surface in the logs' > audit trails, though, because C has already been logged; this looks to > me like CT will fail at its goal of detecting misissuance by B. > > Consider this scenario over time, as well. Once A is publicly-known to > be compromised, the attacker can impersonate new targets with the same > approach: mint a new leaf cert using X (perhaps fiddling with the > validity dates), submit to the logs (and get the SCT) with the A chain, > and then deploy with the B chain. > > How to fix this? A few ideas come to mind, but i'm not convinced of > either of them yet: > > * recommend that clients who care about transparency should expect that > all intermediate certs themselves are logged -- 6962bis already > permits this, though it seems to be mainly in contemplation of > name-constrained intermediate authorities. This expands the number > of SCTs or inclusion proofs that need to accompany a chain, and makes > verification logic slightly more complicated. > Regardless of the argument above and mitigation thereof, I think this would be a good idea. > > * logs could refuse to log any certs that chain back to a known-failed > CA (or through a known-bad intermediate CA). This would constrain a > dual-compromise attacker from minting new certs after the first CA is > known to be compromised. This seems like a useful mitigation, but > it's also complictated and delicate. What does "known-failed" mean? > What if there is a dispute over the validity of a cert, with one > party claiming that it was misissued, and the CA claiming its > legitimacy? What if some browser vendors have dropped the CA, and > others have not? This puts the logs in a position of being some kind > of arbiter of the root store, with very subtle knock-on effects to > security of the whole ecosystem if they decide to not drop a CA. > Not all that subtle, surely, and completely visible so we can see its going on... > > Even more subtly, if the public narrative of the compromise ends up > being "A_X is bad" (include the intermediate cert in client > blacklists and refuse to log things that chain through it) instead of > "A is bad" (include the root cert in client blacklists and refuse to > log things that chain to it), then the attacker can simply mint > multiple intermediate keys (X_0, X_1, etc) and corresponding > intermediate certificates at the time of the compromise, and > burn/expose them one spoofing attack at a time. > After a while, we would clearly decide that A is bad. :-) > > Any other ideas? Any holes in the reasoning here? I'd love for this > analysis to be mistaken. > As I say, I think the problem is real, unfortunately. However, the consequences don't seem quite as terrible as you think. I hope! --001a113ff32827a807052c59c198 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 21 February 2016 at 03:05, Daniel Kahn Gillmor <= ;dkg@fifthhorsem= an.net> wrote:
CT currently= focuses on logging end-entity (leaf) certs; as a result, i
think that an attacker who can compromise two CAs can keep one of those
compromises secret from the CT ecosystem.

Consider an attacker who has compromised two widely-accepted root CAs, A and B, and wants to mint usable credentials for host Z.

The root CAs each control multiple intermediate authorities: A controls A_1= ,
A_2, etc; B controls B_1, B_2, etc.

The attacker creates a new secret key X and using A and B creates two
new intermediate authorities A_X and B_X, which both have the same
Subject, the same public key, and the same Subject Key Identifier
extension.=C2=A0 The intermediate authority certs themselves differ, howeve= r,
because of their issuers.

The attacker generates a new end entity secret key Y and produces a cert C (Subject =3D Z, Public Key =3D Y), issued by X.

Now we have two possible chains:

=C2=A0 A -> A_X -> C

=C2=A0 B -> B_X -> C

The attacker logs one of those chains and gets an SCT for cert C.=C2=A0 For=
this example, let's say the A chain gets logged.

If C is discovered and exposed as a forgery, then root CA A takes the
heat.=C2=A0 Either they disavow/revoke their sub-CA A_X or they are rejecte= d
>From TLS client root stores.

However, the attacker can still use C in the wild, by supplying the B
chain.

Up to here, I agree.
= =C2=A0
Note that in this scenario, it's unlikely that space-constrained
blacklist-style client updates (e.g. CRLset) will include every leaf
certificate that chains to A after A is known-compromised.=C2=A0 So TLS
clients won't necessarily be warned off of C directly.

It seems to me there are multiple solutions here. The easie= st is to not blacklist A_X, but instead to blacklists A_X's subject, wh= ich will also blacklist B_X.

To be more selective,= blacklist the individual certs that were mis-issued (we have a complete li= st, of course, in the logs) and stop accepting new certs signed by X.
=

=C2=A0

The B chain (and B_X in particular) won't ever surface in the logs'=
audit trails, though, because C has already been logged; this looks to
me like CT will fail at its goal of detecting misissuance by B.

Consider this scenario over time, as well.=C2=A0 Once A is publicly-known t= o
be compromised, the attacker can impersonate new targets with the same
approach: mint a new leaf cert using X (perhaps fiddling with the
validity dates), submit to the logs (and get the SCT) with the A chain,
and then deploy with the B chain.

How to fix this?=C2=A0 A few ideas come to mind, but i'm not convinced = of
either of them yet:

=C2=A0* recommend that clients who care about transparency should expect th= at
=C2=A0 =C2=A0all intermediate certs themselves are logged -- 6962bis alread= y
=C2=A0 =C2=A0permits this, though it seems to be mainly in contemplation of=
=C2=A0 =C2=A0name-constrained intermediate authorities.=C2=A0 This expands = the number
=C2=A0 =C2=A0of SCTs or inclusion proofs that need to accompany a chain, an= d makes
=C2=A0 =C2=A0verification logic slightly more complicated.
=

Regardless of the argument above and mitigation thereof= , I think this would be a good idea.
=C2=A0

=C2=A0* logs could refuse to log any certs that chain back to a known-faile= d
=C2=A0 =C2=A0CA (or through a known-bad intermediate CA).=C2=A0 This would = constrain a
=C2=A0 =C2=A0dual-compromise attacker from minting new certs after the firs= t CA is
=C2=A0 =C2=A0known to be compromised.=C2=A0 This seems like a useful mitiga= tion, but
=C2=A0 =C2=A0it's also complictated and delicate.=C2=A0 What does "= ;known-failed" mean?
=C2=A0 =C2=A0What if there is a dispute over the validity of a cert, with o= ne
=C2=A0 =C2=A0party claiming that it was misissued, and the CA claiming its<= br> =C2=A0 =C2=A0legitimacy?=C2=A0 What if some browser vendors have dropped th= e CA, and
=C2=A0 =C2=A0others have not?=C2=A0 This puts the logs in a position of bei= ng some kind
=C2=A0 =C2=A0of arbiter of the root store, with very subtle knock-on effect= s to
=C2=A0 =C2=A0security of the whole ecosystem if they decide to not drop a C= A.

Not all that subtle, surely, and com= pletely visible so we can see its going on...
=C2=A0

=C2=A0 =C2=A0Even more subtly, if the public narrative of the compromise en= ds up
=C2=A0 =C2=A0being "A_X is bad" (include the intermediate cert in= client
=C2=A0 =C2=A0blacklists and refuse to log things that chain through it) ins= tead of
=C2=A0 =C2=A0"A is bad" (include the root cert in client blacklis= ts and refuse to
=C2=A0 =C2=A0log things that chain to it), then the attacker can simply min= t
=C2=A0 =C2=A0multiple intermediate keys (X_0, X_1, etc) and corresponding =C2=A0 =C2=A0intermediate certificates at the time of the compromise, and =C2=A0 =C2=A0burn/expose them one spoofing attack at a time.

After a while, we would clearly decide that A is bad.= :-)
=C2=A0

Any other ideas?=C2=A0 Any holes in the reasoning here?=C2=A0 I'd love = for this
analysis to be mistaken.

As I say, I th= ink the problem is real, unfortunately. However, the consequences don't= seem quite as terrible as you think. I hope!

--001a113ff32827a807052c59c198-- From nobody Mon Feb 22 03:49:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DFB1B3151 for ; Mon, 22 Feb 2016 03:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87OVBfxSbZMZ for ; Mon, 22 Feb 2016 03:49:10 -0800 (PST) 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 D22E71B2E67 for ; Mon, 22 Feb 2016 03:49:08 -0800 (PST) Received: (qmail 16344 invoked by uid 1004); 22 Feb 2016 11:49:06 -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; Mon, 22 Feb 2016 11:49:06 +0000 Received: (qmail 27653 invoked by uid 1000); 22 Feb 2016 11:49:06 -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, 22 Feb 2016 11:49:06 +0000 To: Ben Laurie , Daniel Kahn Gillmor References: <87io1i3gqw.fsf@alice.fifthhorseman.net> From: Rob Stradling Message-ID: <56CAF5B2.30207@comodo.com> Date: Mon, 22 Feb 2016 11:49:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 11:49:12 -0000 On 22/02/16 11:01, Ben Laurie wrote: > Note that in this scenario, it's unlikely that space-constrained > blacklist-style client updates (e.g. CRLset) will include every leaf > certificate that chains to A after A is known-compromised. So TLS > clients won't necessarily be warned off of C directly. > > It seems to me there are multiple solutions here. The easiest is to not > blacklist A_X, but instead to blacklists A_X's subject, which will also > blacklist B_X. I think that blacklisting the shared issuer public key would be better than blacklisting the shared issuer name. AIUI, MS CryptoAPI prefers to build certificate chains using the Authority/Subject Key Identifiers, and it only cares about whether or not the Issuer/Subject Names match if AKI/SKI are absent. > How to fix this? A few ideas come to mind, but i'm not convinced of > either of them yet: > > * recommend that clients who care about transparency should expect > that > all intermediate certs themselves are logged -- 6962bis already > permits this, though it seems to be mainly in contemplation of > name-constrained intermediate authorities. This expands the number > of SCTs or inclusion proofs that need to accompany a chain, and > makes > verification logic slightly more complicated. > > Regardless of the argument above and mitigation thereof, I think this > would be a good idea. If we expect to (eventually) have an effective revocation mechanism (e.g. blacklisting the issuer public key), then why would we need to increase the TLS handshake size (by sending additional SCTs/proofs) just so that we can solve the same problem twice? If we do want CT to handle this though, then I suggest that we: - require intermediate certs to be logged in the same logs as the end-entity certs they issue. - don't require SCTs or inclusion proofs for intermediates to be sent by TLS servers (except for the name-constrained case). - say that TLS clients SHOULD fetch and verify inclusion proofs for all intermediate certs that they rely on. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Feb 22 22:03:26 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5051AC407 for ; Mon, 22 Feb 2016 22:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ00Fm9kokM6 for ; Mon, 22 Feb 2016 22:03:24 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 455B91AC3DB for ; Mon, 22 Feb 2016 22:03:24 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id h129so138767113ywb.1 for ; Mon, 22 Feb 2016 22:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1Xl6VmtrjvIMJIjkwkcDBLY2/hKDHezX6//tR4Qzfv8=; b=crc/Df1sKCDA71OiMxpJ1TLU1sfOByXLC2ueQsQAkUQK017OUS0GsqEGdDqUS52KnH hboIourcRm9MgOKUwV1HDI/Sk/y7Ea3mIh7n+to4a8y7JI/mHbsanZE9IAZAPA3Fldcq 6CYKFIpzvqW+uPPGA0aEW7dmYDtGXKBJCHdtM= 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:content-type; bh=1Xl6VmtrjvIMJIjkwkcDBLY2/hKDHezX6//tR4Qzfv8=; b=bqgdE8vB9ANuuSwJzzBHvG4k2p/Q5aDq9OP8TtO7PWoskSzOCi9/rCXIirHQWGSLzs SberluovlsNzvdyo95Nb86CGLIpRadbdw46PbChnnccy2v5hcSlYK3GLU8qzFngor51G RNO+bERe6CTbnAzm/w9dlnajTugDUTu0DS6V4igeaYaxPzA4vYCR+7O8cY1pwRK5l0ob gmaCPos77vpis1ZgDaz0yBkqYY6XOZbh4TxnCd083ZQQg4EKTsPfKcZSQAvu9lrJI7Wu z0El4HlsFjvz+MIjcfQJZsZTugRP4sn3q/7ZSx/Ql+p8vty3E7T7PUy+xa5sq9zTlGTA GJDw== X-Gm-Message-State: AG10YOSqS3I5BHmJv4g67Emw+LRQ7H6hlrCAVIHs0FPj0jkU50l6T08fgpvBJP5eJVhNpR9sINsNp+mJFSVua+Mm X-Received: by 10.13.229.66 with SMTP id o63mr15282850ywe.208.1456207403537; Mon, 22 Feb 2016 22:03:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.48.214 with HTTP; Mon, 22 Feb 2016 22:03:04 -0800 (PST) In-Reply-To: <56CAF5B2.30207@comodo.com> References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> From: Tom Ritter Date: Tue, 23 Feb 2016 00:03:04 -0600 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Ben Laurie , Daniel Kahn Gillmor Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:03:25 -0000 I'm interleving Ben's and Rob's responses here: >> Note that in this scenario, it's unlikely that space-constrained >> blacklist-style client updates (e.g. CRLset) will include every leaf >> certificate that chains to A after A is known-compromised. So TLS >> clients won't necessarily be warned off of C directly. > > [Ben] > It seems to me there are multiple solutions here. The easiest is to not > blacklist A_X, but instead to blacklists A_X's subject, which will also > blacklist B_X. Perhaps. > [Rob] > I think that blacklisting the shared issuer public key would be better than > blacklisting the shared issuer name. At first glance, I agree - but there is that annoying trick where you can generate multiple (or at least two) public keys that all certify the same signature. So I'm not sure this would actually work. > [Rob] > AIUI, MS CryptoAPI prefers to build certificate chains using the > Authority/Subject Key Identifiers, and it only cares about whether or not > the Issuer/Subject Names match if AKI/SKI are absent. AKI would _not_ match on these trick public keys, but presumably the algorithm would fall back to the Issuer name...? > [Ben] > To be more selective, blacklist the individual certs that were mis-issued > (we have a complete list, of course, in the logs) and stop accepting new > certs signed by X. The "stop accepting new certs" thing might trip us up. We would like a mechanism to track the misissued certs of a compromised CA. Trust Stores have age. We don't distrust X all at once, and it'd be good to know what X is doing so we can understand our risk on the older devices. >> * logs could refuse to log any certs that chain back to a known-failed >> CA (or through a known-bad intermediate CA). This would constrain a >> dual-compromise attacker from minting new certs after the first CA is >> known to be compromised. This seems like a useful mitigation, but >> it's also complictated and delicate. What does "known-failed" mean? >> What if there is a dispute over the validity of a cert, with one >> party claiming that it was misissued, and the CA claiming its >> legitimacy? What if some browser vendors have dropped the CA, and >> others have not? This puts the logs in a position of being some kind >> of arbiter of the root store, with very subtle knock-on effects to >> security of the whole ecosystem if they decide to not drop a CA. > > [Ben] > Not all that subtle, surely, and completely visible so we can see its going > on... As I said above - up until here the CT logs have been a good viewpoint on the CA ecosyetem. Aggressively removing CAs seems dangerous from a "track the ecosystem and ensure accountability" perspective. > [Rob] > - say that TLS clients SHOULD fetch and verify inclusion proofs for all > intermediate certs that they rely on. I'm nervous about this. -tom From nobody Tue Feb 23 02:44:12 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281051B3E99 for ; Tue, 23 Feb 2016 02:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sepuBOOIiM58 for ; Tue, 23 Feb 2016 02:44:08 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229B11B3E89 for ; Tue, 23 Feb 2016 02:44:07 -0800 (PST) Received: (qmail 543 invoked by uid 1004); 23 Feb 2016 10:44:05 -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, 23 Feb 2016 10:44:05 +0000 Received: (qmail 6999 invoked by uid 1000); 23 Feb 2016 10:44:05 -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, 23 Feb 2016 10:44:05 +0000 To: Tom Ritter References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> From: Rob Stradling Message-ID: <56CC373C.30201@comodo.com> Date: Tue, 23 Feb 2016 10:41:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ben Laurie , "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 10:44:11 -0000 On 23/02/16 06:03, Tom Ritter wrote: >> [Rob] >> I think that blacklisting the shared issuer public key would be better than >> blacklisting the shared issuer name. > > At first glance, I agree - but there is that annoying trick where you > can generate multiple (or at least two) public keys that all certify > the same signature. So I'm not sure this would actually work. SCTs in 6962-bis already contain the issuer_key_hash (which is the DER encoding of the issuer's SubjectPublicKeyInfo). Is that enough to defeat your trick key attack? Hmmm, I wonder if we need to add issuer_key_hash to inclusion proofs as well (i.e. the InclusionProofDataV2 struct) ? >> [Rob] >> AIUI, MS CryptoAPI prefers to build certificate chains using the >> Authority/Subject Key Identifiers, and it only cares about whether or not >> the Issuer/Subject Names match if AKI/SKI are absent. > > AKI would _not_ match on these trick public keys, but presumably the > algorithm would fall back to the Issuer name...? For Win2K and WinXP, it appears that it only attempts name matching if the AKI extension is absent. "If there is no information in the AKI, or the AKI does not exist in the certificate being evaluated, a certificate whose subject name matches the evaluated certificate's issuer name will be chosen. This selection method is known as a name match." https://technet.microsoft.com/en-us/library/cc700843.aspx I can't find any more recent documentation. :-( >> [Rob] >> - say that TLS clients SHOULD fetch and verify inclusion proofs for all >> intermediate certs that they rely on. > > I'm nervous about this. Why so? I wasn't suggesting a "MUST". ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Feb 23 03:06:29 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD21AC3B0 for ; Tue, 23 Feb 2016 03:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ct-YAg_d2cE for ; Tue, 23 Feb 2016 03:06:26 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 0E3CB1A9074 for ; Tue, 23 Feb 2016 03:06:26 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id y8so108516427igp.0 for ; Tue, 23 Feb 2016 03:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AWGqw16v5ZJxcm4uaXNlME21bi3I4Y9ZkhU8GhKyb8Q=; b=JA/b5lrFO3Wux3tzQyNiXT/LbVmudESnxuXEHP79pjwuEXaIabtmliBvOBOA9KDwBf YLq4izAyLw/8HnpN/KYqwnvN8PZh6e0alkZ2/MrBigYwhnAUhfPo6XcxjUobBeH0NKHR rr2QplBBDAI0G8XfBiIG7+aOqzJgEGzNnKVQl65MIy/zSXXfaj98kKpKQjrE9Okh5Zee Xtzmde0UVTMjNqcU6Ofz1xI8rAmsCyYje7ifLNI21ipNyE2TCqHdNeqd6FcHn76q/K6e TeIRCnWLuTuOyPNkuXmFx3xROsCXq7NgicS9mStRpQPTukPvVIp7v/ZlzsnvKLifRMK7 wlMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AWGqw16v5ZJxcm4uaXNlME21bi3I4Y9ZkhU8GhKyb8Q=; b=Rz80mITcf4db26cohls9h3nFEblNo9ZZRd0+7v9ogEA3VNxEqyiyz4xFd9L/hLNRom 0vs468fs8CbDqJeDFf0IcsfhREqwf1Wmtr1gu7rzF9xMLD7eJrjSqQQyq5Vb+GWkRuQV cfzJujvXgHgJONIctH+QwLGW4PFEpQzqo6u1hcjq5h85IqdoMDUBTDtK6ts0R6c8IWNx LPhsXatDj2V4bByzvgsFSIDCNpZ+QjoVzag625tBCAHAQ0w7VXxyuLE8j+2dSjd6YMsZ 5qYHtSYCGcmrV4uZ3r9xNGV2b54exnouUS+QaOQxUkId4YROufe6/qjAa1MK6H2R84of e//g== X-Gm-Message-State: AG10YOSVGXaHMRsT6f+5hTaogh/wZHzefef7B6v7c7j0ZpudJ0DKBKHW5bjucXBQpp1YNjfCPbsmF96CS++iGaBQ MIME-Version: 1.0 X-Received: by 10.50.33.80 with SMTP id p16mr15737528igi.23.1456225585299; Tue, 23 Feb 2016 03:06:25 -0800 (PST) Received: by 10.64.26.98 with HTTP; Tue, 23 Feb 2016 03:06:25 -0800 (PST) In-Reply-To: References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> Date: Tue, 23 Feb 2016 11:06:25 +0000 Message-ID: From: Ben Laurie To: Tom Ritter Content-Type: multipart/alternative; boundary=089e01538d8cb9fd3d052c6df03f Archived-At: Cc: Rob Stradling , "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 11:06:28 -0000 --089e01538d8cb9fd3d052c6df03f Content-Type: text/plain; charset=UTF-8 On 23 February 2016 at 06:03, Tom Ritter wrote: > I'm interleving Ben's and Rob's responses here: > > >> Note that in this scenario, it's unlikely that space-constrained > >> blacklist-style client updates (e.g. CRLset) will include every leaf > >> certificate that chains to A after A is known-compromised. So TLS > >> clients won't necessarily be warned off of C directly. > > > > [Ben] > > It seems to me there are multiple solutions here. The easiest is to not > > blacklist A_X, but instead to blacklists A_X's subject, which will also > > blacklist B_X. > > Perhaps. > > > [Rob] > > I think that blacklisting the shared issuer public key would be better > than > > blacklisting the shared issuer name. > > At first glance, I agree - but there is that annoying trick where you > can generate multiple (or at least two) public keys that all certify > the same signature. So I'm not sure this would actually work. > Hmm. That would be e and e + phi(n), I guess? > > > [Rob] > > AIUI, MS CryptoAPI prefers to build certificate chains using the > > Authority/Subject Key Identifiers, and it only cares about whether or not > > the Issuer/Subject Names match if AKI/SKI are absent. > > AKI would _not_ match on these trick public keys, but presumably the > algorithm would fall back to the Issuer name...? > > > [Ben] > > To be more selective, blacklist the individual certs that were mis-issued > > (we have a complete list, of course, in the logs) and stop accepting new > > certs signed by X. > > The "stop accepting new certs" thing might trip us up. We would like a > mechanism to track the misissued certs of a compromised CA. Trust > Stores have age. We don't distrust X all at once, and it'd be good to > know what X is doing so we can understand our risk on the older > devices. > Fair point. At least two ways of doing this: a) Run a log that is not trusted for HTTPS connections. b) Continue to accept certs from X, but don't allow SCTs after the last good timestamp for X. > > > >> * logs could refuse to log any certs that chain back to a known-failed > >> CA (or through a known-bad intermediate CA). This would constrain a > >> dual-compromise attacker from minting new certs after the first CA is > >> known to be compromised. This seems like a useful mitigation, but > >> it's also complictated and delicate. What does "known-failed" mean? > >> What if there is a dispute over the validity of a cert, with one > >> party claiming that it was misissued, and the CA claiming its > >> legitimacy? What if some browser vendors have dropped the CA, and > >> others have not? This puts the logs in a position of being some kind > >> of arbiter of the root store, with very subtle knock-on effects to > >> security of the whole ecosystem if they decide to not drop a CA. > > > > [Ben] > > Not all that subtle, surely, and completely visible so we can see its > going > > on... > > As I said above - up until here the CT logs have been a good viewpoint > on the CA ecosyetem. Aggressively removing CAs seems dangerous from a > "track the ecosystem and ensure accountability" perspective. > > > > [Rob] > > - say that TLS clients SHOULD fetch and verify inclusion proofs for all > > intermediate certs that they rely on. > > I'm nervous about this. > > -tom > --089e01538d8cb9fd3d052c6df03f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 February 2016 at 06:03, Tom Ritter <tom@ritter.vg> wr= ote:
I'm interleving Ben's and Ro= b's responses here:

>> Note that in this scenario, it's unlikely that space-constrain= ed
>> blacklist-style client updates (e.g. CRLset) will include every le= af
>> certificate that chains to A after A is known-compromised.=C2=A0 S= o TLS
>> clients won't necessarily be warned off of C directly.
>
> [Ben]
> It seems to me there are multiple solutions here. The= easiest is to not
> blacklist A_X, but instead to blacklists A_X's subject, which will= also
> blacklist B_X.

Perhaps.

> [Rob]
> I think that blacklisting the shared issuer public ke= y would be better than
> blacklisting the shared issuer name.

At first glance, I agree - but there is that annoying trick where yo= u
can generate multiple (or at least two) public keys that all certify
the same signature. So I'm not sure this would actually work.

Hmm. That would be e and e + phi(n), I guess?
=C2=A0

> [Rob]
> AIUI, MS CryptoAPI prefers to build certificate chain= s using the
> Authority/Subject Key Identifiers, and it only cares about whether or = not
> the Issuer/Subject Names match if AKI/SKI are absent.

AKI would _not_ match on these trick public keys, but presumably the=
algorithm would fall back to the Issuer name...?

> [Ben]
> To be more selective, blacklist the individual certs = that were mis-issued
> (we have a complete list, of course, in the logs) and stop accepting n= ew
> certs signed by X.

The "stop accepting new certs" thing might trip us up. We = would like a
mechanism to track the misissued certs of a compromised CA. Trust
Stores have age. We don't distrust X all at once, and it'd be good = to
know what X is doing so we can understand our risk on the older
devices.

Fair point. At least two ways = of doing this:

a) Run a log that is not trusted fo= r HTTPS connections.

b) Continue to accept certs f= rom X, but don't allow SCTs after the last good timestamp for X.
<= div>=C2=A0


>>=C2=A0 * logs could refuse to log any certs that chain back to a kn= own-failed
>>=C2=A0 =C2=A0 CA (or through a known-bad intermediate CA).=C2=A0 Th= is would constrain a
>>=C2=A0 =C2=A0 dual-compromise attacker from minting new certs after= the first CA is
>>=C2=A0 =C2=A0 known to be compromised.=C2=A0 This seems like a usef= ul mitigation, but
>>=C2=A0 =C2=A0 it's also complictated and delicate.=C2=A0 What d= oes "known-failed" mean?
>>=C2=A0 =C2=A0 What if there is a dispute over the validity of a cer= t, with one
>>=C2=A0 =C2=A0 party claiming that it was misissued, and the CA clai= ming its
>>=C2=A0 =C2=A0 legitimacy?=C2=A0 What if some browser vendors have d= ropped the CA, and
>>=C2=A0 =C2=A0 others have not?=C2=A0 This puts the logs in a positi= on of being some kind
>>=C2=A0 =C2=A0 of arbiter of the root store, with very subtle knock-= on effects to
>>=C2=A0 =C2=A0 security of the whole ecosystem if they decide to not= drop a CA.
>
> [Ben]
> Not all that subtle, surely, and completely visible s= o we can see its going
> on...

As I said above - up until here the CT logs have been a good viewpoi= nt
on the CA ecosyetem. Aggressively removing CAs seems dangerous from a
"track the ecosystem and ensure accountability" perspective.


> [Rob]
>=C2=A0 =C2=A0- say that TLS clients SHOULD fetch and v= erify inclusion proofs for all
> intermediate certs that they rely on.

I'm nervous about this.

-tom

--089e01538d8cb9fd3d052c6df03f-- From nobody Tue Feb 23 08:00:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644561B3362 for ; Tue, 23 Feb 2016 08:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw5_cFycKk7C for ; Tue, 23 Feb 2016 08:00:45 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AB31A8AF8 for ; Tue, 23 Feb 2016 08:00:43 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id y8so114263321igp.0 for ; Tue, 23 Feb 2016 08:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MUFLfI20FiiwtZjglenpkEBlAGdD5i7WVroqFxd1Mmw=; b=X7cJ/1maekpIiLgUtoI+CnB7lBrbz1HeAvOC5ZGH7RWo6dNT1FlScaO0dD8+ITixDM 3PjOUwY9WxDhvwwqni2HYEDZCYPT0nrw2aLl6B0pCjP+1YuhpsiaI+AEWOHgD3didxm2 lsvy4KNKOBr++xpkssPfXMFfkT1KOJm/jVkJBZfrgNxFRiZtKM3gT8DZhfe6OESQifct EmpFzqTkkDp9QXS76jsitJQ9JY4fGp64Jt/GD3jrHslYw5jNsToFv7XDDjE81LDnwWbQ 4d20o3Dm4FJ1yKI/WMGz/FHYl2YVY76Yg8EQKdZV7fMw5nqraH/2l84cG5e57+ELW5W1 pntw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=MUFLfI20FiiwtZjglenpkEBlAGdD5i7WVroqFxd1Mmw=; b=RGdiuyNgFjZ/2loDRUhmuGLhMyTyGXYMRwoEjVvYv1jaiGrwKHsrqP116TrKN4JNoY vTIX4UIbnIJgC+QyD64x/sNtd6JqHi+HcFOR9Xs7ZENfwlUUyZedRmbRwiEDmykXwBPb dmUl3EB1l2TrErE3NMBtZdUszVjmi8tF/2Y5BNL3tU7hTWhhZ1r0c3/VdK23Z4eUb9Rx 3Ek2KIKukKCwIXGN4ThbslKbLPKCWvIdUmHbJ0WdNOcaFBBmvjb+wZRiDhtYl7mLj5rz dxw41cb/miVeEtPtWcw0Z1DYccRV+RqTl+U/U+SMNPe0oF7vHRSomvRe3GYXxH/41uSE wTpA== X-Gm-Message-State: AG10YORaaVYhC2OLCcNrDN1/7Kiyl5P7NWnY6kWZnEU8MUvUxG962k0frqJAUFFzttEYLWgGybdNZaUfj/7Nuw0E MIME-Version: 1.0 X-Received: by 10.50.132.6 with SMTP id oq6mr18681419igb.32.1456243242305; Tue, 23 Feb 2016 08:00:42 -0800 (PST) Received: by 10.64.26.98 with HTTP; Tue, 23 Feb 2016 08:00:42 -0800 (PST) Date: Tue, 23 Feb 2016 16:00:42 +0000 Message-ID: From: Ben Laurie To: "trans@ietf.org" , "certificate-transparency@googlegroups.com" , Pierre Phaneuf Content-Type: multipart/alternative; boundary=047d7b3a9b5c2a6ca4052c720dea Archived-At: Subject: [Trans] DNS for CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 16:00:49 -0000 --047d7b3a9b5c2a6ca4052c720dea Content-Type: text/plain; charset=UTF-8 As we've mentioned several times, we've been working on a way to retrieve CT data over DNS to improve the privacy properties of inclusion proofs. So, I'm pleased to announce that we now have a test DNS service up for some of our logs. The documentation for the protocol can be found here: https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md The base domains for the supported logs are: aviator.ct.googleapis.com pilot.ct.googleapis.com testtube.ct.googleapis.com and a demo showing use of the DNS records is here: https://github.com/google/certificate-transparency/blob/master/python/utilities/dnslookup/dnslookup.py The demo is pretty primitive, but does show all the things you can get from the DNS. Comments and improvements welcome. --047d7b3a9b5c2a6ca4052c720dea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As we've mentioned several times, we've been worki= ng on a way to retrieve CT data over DNS to improve the privacy properties = of inclusion proofs.

So, I'm pleased to announce tha= t we now have a test DNS service up for some of our logs.
The base domains for the supported logs are:

and a d= emo showing use of the DNS records is here:

=

The demo is pretty primitive, but does show all the thi= ngs you can get from the DNS.

Comments and improve= ments welcome.

--047d7b3a9b5c2a6ca4052c720dea-- From nobody Tue Feb 23 16:45:41 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EE61B39E0 for ; Tue, 23 Feb 2016 16:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTCQ5-Iq-yuy for ; Tue, 23 Feb 2016 16:12:17 -0800 (PST) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 569D31B2E6A for ; Tue, 23 Feb 2016 16:12:17 -0800 (PST) Received: from [10.32.60.83] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u1O0CAnv027835 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2016 17:12:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.83] From: "Paul Hoffman" To: "Ben Laurie" Date: Tue, 23 Feb 2016 16:12:09 -0800 Message-ID: <34C51BE8-D9CF-4455-A89E-BCCD29DCDEB6@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.3r5187) Archived-At: X-Mailman-Approved-At: Tue, 23 Feb 2016 16:45:39 -0800 Cc: Pierre Phaneuf , "trans@ietf.org" , "certificate-transparency@googlegroups.com" Subject: Re: [Trans] DNS for CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 00:12:18 -0000 On 23 Feb 2016, at 8:00, Ben Laurie wrote: > As we've mentioned several times, we've been working on a way to = > retrieve > CT data over DNS to improve the privacy properties of inclusion = > proofs. This is a good idea, and the motivation mentioned in the not-yet-a-draft = is good. However, I have some questions about the protocol that you = show. > https://github.com/google/certificate-transparency-rfcs/blob/master/dns= /draft-ct-over-dns.md 1) Why do you create a new Opcode for the header? These are kind of = precious values. You are already using prefixes on the QNAME for STH = queries; you could easily do so for the others as well. 2) Standard practice these days is to have prefixed labels start with an = underscore (_). 3) In the STH Query example, the Question section in the response is = different than the Question section in the request. I hope this is a = typo, given that RFC 1034 says that the two must be the same. 4) If you sure that the RData values for the responses are less than 256 = characters, that's fine; if they can be longer than that, you should = probably add a note about the TXT records having more than one = character-data string. --Paul Hoffman From nobody Tue Feb 23 17:59:16 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31781B41AC for ; Tue, 23 Feb 2016 17:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3fsnuqyYUql for ; Tue, 23 Feb 2016 17:59:13 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 475D11B41A9 for ; Tue, 23 Feb 2016 17:59:13 -0800 (PST) Received: from fifthhorseman.net (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by che.mayfirst.org (Postfix) with ESMTPSA id 73673F991; Tue, 23 Feb 2016 20:59:08 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 90F3420580; Tue, 23 Feb 2016 17:59:08 -0800 (PST) From: Daniel Kahn Gillmor To: Ben Laurie , Tom Ritter In-Reply-To: References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 23 Feb 2016 17:59:05 -0800 Message-ID: <87povm27iu.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 01:59:14 -0000 --=-=-= Content-Type: text/plain On Tue 2016-02-23 03:06:25 -0800, Ben Laurie wrote: > Fair point. At least two ways of doing this: > > a) Run a log that is not trusted for HTTPS connections. (trolling: i thought logs didn't have to be trusted...) what encourages any party in the ecosystem to log in this untrutsed log? > b) Continue to accept certs from X, but don't allow SCTs after the last > good timestamp for X. What does this buy us? Can't an inclusion proof (post-MMD) from this log perform the same role as the SCT? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWzQ5pXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKeb8P/3DEzVzXNH3oEF+UXv9U2Zy4 gxvTTmFLdeWDgNEL+d9nJuPkx47OPNRUKL3ITEe+emZdYk2vWXAn7TKq3f2cxkwh hqE+2FnegPpkB8R3tujihYymejJ6x8E/hTOfo8pGpL9+48c1GPcx1ZfEzuP1F8aB j3wXEkxs4mjSfqeHTZFmNB+bL2u2kU+UpT64mMqSiYLuzIAuin4tK2d54Qt8Y0qA VKUezGQM3BIkYyRqpoX393++gXTmQdJ8yfzctqeX3r2nABpENRxVNiREqa+gScqC MsnWB/+xvd0TAsWRO20AMRYLoJxG9GFsrZkpOIZlgPm1cH74D/Z9RSjxymUS0Hej pfmV1A/TzyGdJFcjs2fJfnHbjN5rgTN8OldGsNdhaiIru/Akwu9Z/L3qsc17COiD 7OUjqa6miYxvMMsOk9pMDclyz88cqCFYXFC9rnwT6Y+pDhJqhI94fg579SXFc4R5 ZfJZU+/pCd8Ebq/WhWeEy+/c3fWXujQxG+bRgTznYaN7QsbMSxMPpAGo5ceBUHet rHmqh8XEE2h+fKM6p0eL4/ziY0Pm7oUj1SNAodwrS/4M3yRF6TV4+ATIr/PPFkmw NDBIwVBOfNQY4Eheqb85sm0dHaEtFskRhDVOJlsqpuR/1ZQXTBi6WI0x3lsQWIyM PIlYafc9tKkkk1VVUwfM =UdwL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 23 21:06:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6AA1A88B8 for ; Tue, 23 Feb 2016 21:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5PAVPjLbhOI for ; Tue, 23 Feb 2016 21:06:18 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EA11B452E for ; Tue, 23 Feb 2016 21:06:16 -0800 (PST) Received: by mail-ob0-x230.google.com with SMTP id dm2so7585815obb.2 for ; Tue, 23 Feb 2016 21:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i9UPGurwJiVvUoT+u2v8zZMbFlyj6W5JuD5ClSB55Go=; b=PfwFDTlEs23g/hnzspXbUFAUV+/08TNZ7huYrG/9Ty11mHx8V3NbcY34bzGqP8VBtt Qz8WViFeYAqEOnnLTVY2K3hYMZN9Tnur7mlMYoxJDLfMr4t6zpM0dcIJ3qmNecDzLOAT o3SQWs0pK6hBdAzwdVdQ7bJ9fE87voREmWvIzD5D4/9y8kmrMBY+hSIMZV5/zmD5U+B9 kNTJ1A3hWhXvnAQaX9OBRFUUSG8C9W8MjWqaXYYKpOchfyI6xFpntm9ZMHYS5kijPcn3 e8sVe/b9SCRmf9aqwxAuneAmX78FqZIsLw7iTS6FsPuv9WSPROS17ng6Oi1LXInvablx HW6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i9UPGurwJiVvUoT+u2v8zZMbFlyj6W5JuD5ClSB55Go=; b=TlzZCeDNFxPC8Kh08hc4UDCq3KgbGKHqTEYqEfFp++FJt9S/nvkp6RC22IgzSfsafT pHyjV/q9kkpHiBJQyT4fq8KNZPckOgDfA3v30KmrwpMNT2bJ9QvKWDd85H07bMatwQey 7v+tl61+uq6QFRU9HqKsR8NfI9lcAYCKnxMMkFWmdgIHnh7/K1af+ybO137iKn5m+IyG QhQSAIpoLubVVT5nIFiLug3Ux5pUo5B1Z1L8kGlAdgUZXNefreEw2Dd7WtdxyVfdkuOr dVzrF4XWgU4aAMii6mjfVcQwJEJjmRHxuNUYIp3F5dbGusv9iGOo4Bja5qbPiZtIDD3Z wugg== X-Gm-Message-State: AG10YOSrTgWcOK3A8nbnVXHV+fBIlbiT/2V9QUZQiefFRTQnMNlZ9uSumiH+7SVpk/cqQTMxElTWmpl/6Jsgoj4G MIME-Version: 1.0 X-Received: by 10.107.137.142 with SMTP id t14mr40756750ioi.172.1456290375938; Tue, 23 Feb 2016 21:06:15 -0800 (PST) Received: by 10.64.26.98 with HTTP; Tue, 23 Feb 2016 21:06:15 -0800 (PST) In-Reply-To: <34C51BE8-D9CF-4455-A89E-BCCD29DCDEB6@vpnc.org> References: <34C51BE8-D9CF-4455-A89E-BCCD29DCDEB6@vpnc.org> Date: Wed, 24 Feb 2016 05:06:15 +0000 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a113f8f2c8c9a05052c7d06ea Archived-At: Cc: Pierre Phaneuf , "trans@ietf.org" , "certificate-transparency@googlegroups.com" Subject: Re: [Trans] DNS for CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 05:06:19 -0000 --001a113f8f2c8c9a05052c7d06ea Content-Type: text/plain; charset=UTF-8 On 24 February 2016 at 00:12, Paul Hoffman wrote: > On 23 Feb 2016, at 8:00, Ben Laurie wrote: > > As we've mentioned several times, we've been working on a way to retrieve >> CT data over DNS to improve the privacy properties of inclusion proofs. >> > > This is a good idea, and the motivation mentioned in the not-yet-a-draft > is good. However, I have some questions about the protocol that you show. > > >> https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md >> > > 1) Why do you create a new Opcode for the header? These are kind of > precious values. You are already using prefixes on the QNAME for STH > queries; you could easily do so for the others as well. > I don't think that was intentional - we're not actually using a different opcode! > > 2) Standard practice these days is to have prefixed labels start with an > underscore (_). > You mean like in SRV records? It wasn't particularly intended that these would be on a domain used for anything other than CT... but no particular objection, either. > > 3) In the STH Query example, the Question section in the response is > different than the Question section in the request. I hope this is a typo, > given that RFC 1034 says that the two must be the same. > It is. > > 4) If you sure that the RData values for the responses are less than 256 > characters, that's fine; if they can be longer than that, you should > probably add a note about the TXT records having more than one > character-data string. We were trying to avoid that happening... --001a113f8f2c8c9a05052c7d06ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 February 2016 at 00:12, Paul Hoffman <paul.hoffman@vpnc.org<= /a>> wrote:
On= 23 Feb 2016, at 8:00, Ben Laurie wrote:

As we've mentioned several times, we've been working on a way to re= trieve
CT data over DNS to improve the privacy properties of inclusion proofs.

 This is a good idea, and the motivation mentioned in the not-yet-a-draft is= good. However, I have some questions about the protocol that you show.

https://= github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-ov= er-dns.md

1) Why do you create a new Opcode for the header? These are kind of preciou= s values. You are already using prefixes on the QNAME for STH queries; you = could easily do so for the others as well.

<= div>I don't think that was intentional - we're not actually using a= different opcode!
=C2=A0

2) Standard practice these days is to have prefixed labels start with an un= derscore (_).

You mean like in SRV reco= rds? It wasn't particularly intended that these would be on a domain us= ed for anything other than CT... but no particular objection, either.
=
=C2=A0

3) In the STH Query example, the Question section in the response is differ= ent than the Question section in the request. I hope this is a typo, given = that RFC 1034 says that the two must be the same.

=
It is.
=C2=A0

4) If you sure that the RData values for the responses are less than 256 ch= aracters, that's fine; if they can be longer than that, you should prob= ably add a note about the TXT records having more than one character-data s= tring.

We were trying to avoid that happeni= ng...

--001a113f8f2c8c9a05052c7d06ea-- From nobody Wed Feb 24 03:20:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7171A88B6 for ; Wed, 24 Feb 2016 03:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoE-G9rU-pvm for ; Wed, 24 Feb 2016 03:20:20 -0800 (PST) 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 260C31A88BA for ; Wed, 24 Feb 2016 03:20:19 -0800 (PST) Received: (qmail 31956 invoked by uid 1004); 24 Feb 2016 11:20:16 -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; Wed, 24 Feb 2016 11:20:16 +0000 Received: (qmail 6917 invoked by uid 1000); 24 Feb 2016 11:20:16 -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; Wed, 24 Feb 2016 11:20:16 +0000 To: Tom Ritter References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> <56CC373C.30201@comodo.com> From: Rob Stradling Message-ID: <56CD91F0.2090705@comodo.com> Date: Wed, 24 Feb 2016 11:20:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CC373C.30201@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Ben Laurie , Daniel Kahn Gillmor Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:20:23 -0000 On 23/02/16 10:41, Rob Stradling wrote: > On 23/02/16 06:03, Tom Ritter wrote: > >>> [Rob] >>> I think that blacklisting the shared issuer public key would be >>> better than >>> blacklisting the shared issuer name. >> >> At first glance, I agree - but there is that annoying trick where you >> can generate multiple (or at least two) public keys that all certify >> the same signature. So I'm not sure this would actually work. > > SCTs in 6962-bis already contain the issuer_key_hash (which is the DER > encoding of the issuer's SubjectPublicKeyInfo). Is that enough to > defeat your trick key attack? > > Hmmm, I wonder if we need to add issuer_key_hash to inclusion proofs as > well (i.e. the InclusionProofDataV2 struct) ? Actually, issuer_key_hash is already included in the TimestampedCertificateEntryDataV2 structure from which leaf hashes are calculated. I think that's sufficient to guard against inclusion proofs being considered valid in conjunction with a trick issuer public key (but please correct me if I'm wrong!) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Feb 24 06:10:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4E31B2F3F for ; Wed, 24 Feb 2016 06:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx1wT-4liq0E for ; Wed, 24 Feb 2016 06:10:27 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 D5A281B2F5B for ; Wed, 24 Feb 2016 06:10:25 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id z135so41052607iof.0 for ; Wed, 24 Feb 2016 06:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7DcnV/Rj9N/l2p6k2INX87G+73KtoQoKuYWnqmZWgC0=; b=Oz15ZwXWDnLkhbbcO6TP/TxGZh8TGmHUvGgBpymvYggl0/cB2IWEDgo+Yl3mcdW9iW 6nW3tTidnJJpSxXHCg0+Nb6c0IddMcvdMe0MzNcPXcHgjMdW8bsLzyA0Cf9vQjGkJSFZ 98fdtrdu2DKAaOGL1I9op69qLD5uGL4aV9vrDw/9CSmENoKwq/kU8ARlpG/bt3jgjM2K wEXhzRbSIQndx09uWrGoKnS/qqO03aMJNwxLgSf7iZC/6zoD8vrlF16wNIcbq4w0ROeq C7YdV3JR6/TnaGfM0EZVQcYF39a1/NzMKP/cAaJa1EodDPZMm38dWl2k+pL9UTlDt9m3 XaZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7DcnV/Rj9N/l2p6k2INX87G+73KtoQoKuYWnqmZWgC0=; b=jA6Vn3A9+SaBP1o5a9hlrg2/shs7KH0UOzQnghO99sfx0e5oAFE5id93xX/SU4p/5i D2fJZKQOZHx/670pgc15q+m4o/fgs5Vact1pfa2nUzjVJ9fVX/gS1tnOADIWxDo7bgPA jfoaBkvOBRwdp8IRAv5IlQLZVLtt3E7q57S4n5aAT9WHoB1wENWMi0U5uq2EoWfjrkZ+ niHLpFpvy3FAWKRPTC7P19tdFOI3X6nqg8Gs95utU6lftg+4j51JNz17I2/Rj2sIB2VI 1yag5MC4c7FyXJylRzFDJuRPe7Qy5QxIMrele6hG0yXmBEpc/FOKs7zk/THtfA+yDdEH 9xKg== X-Gm-Message-State: AG10YOQRduER5tnUHfiFGnpDx0sjhGsMaeJkSjg0Crc57Gp3rYYhF/EddLQ5B9s3JlLhzw52kflTgTsfQeC4Dy+Z MIME-Version: 1.0 X-Received: by 10.107.16.17 with SMTP id y17mr45636105ioi.119.1456323025057; Wed, 24 Feb 2016 06:10:25 -0800 (PST) Received: by 10.64.26.98 with HTTP; Wed, 24 Feb 2016 06:10:24 -0800 (PST) In-Reply-To: References: <34C51BE8-D9CF-4455-A89E-BCCD29DCDEB6@vpnc.org> Date: Wed, 24 Feb 2016 14:10:24 +0000 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a113ff3289692cc052c84a086 Archived-At: Cc: Pierre Phaneuf , "trans@ietf.org" , "certificate-transparency@googlegroups.com" Subject: Re: [Trans] DNS for CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 14:10:33 -0000 --001a113ff3289692cc052c84a086 Content-Type: text/plain; charset=UTF-8 All these should be fixed now. On 24 February 2016 at 05:06, Ben Laurie wrote: > > > On 24 February 2016 at 00:12, Paul Hoffman wrote: > >> On 23 Feb 2016, at 8:00, Ben Laurie wrote: >> >> As we've mentioned several times, we've been working on a way to retrieve >>> CT data over DNS to improve the privacy properties of inclusion proofs. >>> >> >> This is a good idea, and the motivation mentioned in the not-yet-a-draft >> is good. However, I have some questions about the protocol that you show. >> >> >>> https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md >>> >> >> 1) Why do you create a new Opcode for the header? These are kind of >> precious values. You are already using prefixes on the QNAME for STH >> queries; you could easily do so for the others as well. >> > > I don't think that was intentional - we're not actually using a different > opcode! > > >> >> 2) Standard practice these days is to have prefixed labels start with an >> underscore (_). >> > > You mean like in SRV records? It wasn't particularly intended that these > would be on a domain used for anything other than CT... but no particular > objection, either. > > >> >> 3) In the STH Query example, the Question section in the response is >> different than the Question section in the request. I hope this is a typo, >> given that RFC 1034 says that the two must be the same. >> > > It is. > > >> >> 4) If you sure that the RData values for the responses are less than 256 >> characters, that's fine; if they can be longer than that, you should >> probably add a note about the TXT records having more than one >> character-data string. > > > We were trying to avoid that happening... > > --001a113ff3289692cc052c84a086 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All these should be fixed now.

On 24 February 2016 at 05:06, Ben Lauri= e <benl@google.com> wrote:
<= div dir=3D"ltr">

On 24 February 2016 at 00:12, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
On 23 Feb 2016, at 8:00, Ben Laurie wrote:

As we've mentioned several times, we've been working on a way to re= trieve
CT data over DNS to improve the privacy properties of inclusion proofs.

This is a good idea, and the motivation mentioned in the not-yet-a-draft is= good. However, I have some questions about the protocol that you show.

https://= github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-ov= er-dns.md

1) Why do you create a new Opcode for the header? These are kind of preciou= s values. You are already using prefixes on the QNAME for STH queries; you = could easily do so for the others as well.

<= /span>
I don't think that was intentional - we're not actually = using a different opcode!
=C2=A0

2) Standard practice these days is to have prefixed labels start with an un= derscore (_).

You mean like in S= RV records? It wasn't particularly intended that these would be on a do= main used for anything other than CT... but no particular objection, either= .
=C2=A0

3) In the STH Query example, the Question section in the response is differ= ent than the Question section in the request. I hope this is a typo, given = that RFC 1034 says that the two must be the same.

=
It is.
=C2=A0

4) If you sure that the RData values for the responses are less than 256 ch= aracters, that's fine; if they can be longer than that, you should prob= ably add a note about the TXT records having more than one character-data s= tring.

We were trying to avoid that = happening...


--001a113ff3289692cc052c84a086-- From nobody Wed Feb 24 06:15:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CD81B2D9F for ; Wed, 24 Feb 2016 06:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mp0C7_Pp4Z2 for ; Wed, 24 Feb 2016 06:15:45 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467BA1B2CEA for ; Wed, 24 Feb 2016 06:15:45 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 9so40656277iom.1 for ; Wed, 24 Feb 2016 06:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/VAv6X0BXvIYUg0pnHsF6E09f4f9Kbche+mfHot/+7Y=; b=NJ1w8q58Omc0RGpcFZCETS9Ahgqkfg2gW+bE9GJu6602VkT5B9C0EAqdSjdQWsRUgH Kjb8EXvMNtwcuGPNDSuiiv19OB4RMN6ljp69vVf0MMxswzpCuvQkFwsJoB+EV67hBV08 l9tnDHTbfly5EG2Afk+5/dktLqdlTA7GC9Q9SaXaYvUwpmY67BVsZZZLfIrXut2ArRcM Go4FzI7mm/CxQj7q0vtHTfD9OS/YhSrRFShLl1OdowqrtBlIvBJ41lQDSfP5aFpca4x/ 1+fZJYRcMEERmAdWCJN1alk/qN1iZG86g5IDE3jMdD1mv0kSNnhe8tGMFnfJ1OJVon32 tuwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/VAv6X0BXvIYUg0pnHsF6E09f4f9Kbche+mfHot/+7Y=; b=f3BLUg4F47oRr5umofLAzfpS1SAPu7WNRTTIWyOimrs/QW5yFcFHHnvvoIUCeoDmoE dKXF5MIHqb6oufb7cqyaW+/7IwBn1EwtDq/KPw/apq3WWskmR0+Nxx3VP8IkXvHNs9VW LWCnm7SY/WwOOVdJUWNhSOM+0Wn/NrU5yk5atLk71X5BGS5WKFyIL0IPInn5zXh3Fn8i CHPz6ArINfZFS/U3s79dq+mdS+yUg6uU4MGWbWCU95EmXp9Trp1R+UY539kJfSNKOCab BHm1uMJ90qbazg6raF8edl4xu3dikXmgwGwbl5ihsj7tN/tG6t7d6d/jKjBLF/thsmuO atAA== X-Gm-Message-State: AG10YORFyl5o8IeQQOu+pRX1LIcloDFjsv61/4CKQ7DPwFYegAIat/4BfgTsSoXqFykK6EIzoz66CObTftc7QiIJ MIME-Version: 1.0 X-Received: by 10.50.142.37 with SMTP id rt5mr5717139igb.37.1456323340654; Wed, 24 Feb 2016 06:15:40 -0800 (PST) Received: by 10.64.26.98 with HTTP; Wed, 24 Feb 2016 06:15:40 -0800 (PST) In-Reply-To: <87povm27iu.fsf@alice.fifthhorseman.net> References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> <87povm27iu.fsf@alice.fifthhorseman.net> Date: Wed, 24 Feb 2016 14:15:40 +0000 Message-ID: From: Ben Laurie To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a11c3b5426654be052c84b3d2 Archived-At: Cc: "trans@ietf.org" , Rob Stradling , Tom Ritter Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 14:15:47 -0000 --001a11c3b5426654be052c84b3d2 Content-Type: text/plain; charset=UTF-8 On 24 February 2016 at 01:59, Daniel Kahn Gillmor wrote: > On Tue 2016-02-23 03:06:25 -0800, Ben Laurie wrote: > > Fair point. At least two ways of doing this: > > > > a) Run a log that is not trusted for HTTPS connections. > > (trolling: i thought logs didn't have to be trusted...) > :-) It is a fair point, though - perhaps a better way to express it would be "not used by browsers for transparency". > > what encourages any party in the ecosystem to log in this untrutsed log? > We log all the certs we see. I think we are not the only ones. But agreed, this is not as robust as a system which requires logging in order for certs to be accepted. Given that the whole point is not to accept further certs, this seems tricky to solve! > b) Continue to accept certs from X, but don't allow SCTs after the last > > good timestamp for X. > > What does this buy us? Can't an inclusion proof (post-MMD) from this > log perform the same role as the SCT? > Not sure I understand what you mean by this? --001a11c3b5426654be052c84b3d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 February 2016 at 01:59, Daniel Kahn Gillmor <= ;dkg@fifthhorsem= an.net> wrote:
On Tue 2016-02-23 03:06:25 -0800, Ben Laurie wrote:
> Fair point. At least two ways of doing this:
>
> a) Run a log that is not trusted for HTTPS connections.

(trolling: i thought logs didn't have to be trusted...)

:-)

It is a fair point= , though - perhaps a better way to express it would be "not used by br= owsers for transparency".
=C2=A0

what encourages any party in the ecosystem to log in this untrutsed log?

We log all the certs we see. I think we a= re not the only ones. But agreed, this is not as robust as a system which r= equires logging in order for certs to be accepted. Given that the whole poi= nt is not to accept further certs, this seems tricky to solve!
> b) Continue to accept certs from X, but don't allow SCTs after the= last
> good timestamp for X.

What does this buy us?=C2=A0 Can't an inclusion proof (post-MMD)= from this
log perform the same role as the SCT?

N= ot sure I understand what you mean by this?

--001a11c3b5426654be052c84b3d2-- From nobody Wed Feb 24 06:17:10 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925221AD350 for ; Wed, 24 Feb 2016 06:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9iz0zt_NpuW for ; Wed, 24 Feb 2016 06:17:06 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 D4AB21ACD5D for ; Wed, 24 Feb 2016 06:17:05 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id u200so15875450ywf.0 for ; Wed, 24 Feb 2016 06:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=x5Lhy3HMU/SHWQo1WHZSqyHu91OGey7/et4CxipfA+k=; b=e9OtLlbWOAuuOLv/4TV+EveyYCKlRL/pzwvBhtMJxZeyUFeXd/ItG6Kixqfe6FgxSk 1xIvh8+BdjzjZ7wzE43LsTeBNFxBEbaFnaX8ObVGfolGExW/H2bppBiiqllkVW73jDPS K7SDcSC1fDpKa8BTXOoUGVCTZsVpeGa0co+g4= 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:content-type; bh=x5Lhy3HMU/SHWQo1WHZSqyHu91OGey7/et4CxipfA+k=; b=Ik/4ncs77x+4s0B14/zkr7PSOWjdiBl53SbmrpKO3nf8KQp7hIwykOUG2vmhtxycjL w1Ml9JzVh/ghklXMy8GJfuCKMK01XiA2nVaDAY/4BZawukGrewzG+J90O6oQ0A8UXheT Gm8QtBKo9AO2tbvbg5Iy8/EMQ15d2ZJL8mGyMaA+KcsnSs9uUKQEp777dP2eZlXDe9QF 7Z4h7Druooe9cwCkn90zovUTxs7gOKZMPA5WK1+ujROabzEkiB7Sj3u1FNky6w7dYsAS Rfd1JBfOIanVgB437SiWUegcNJH3QsTfspjx+rQF7R3PRXANVFKOOOtlqZ6J+s2Lszov Al6Q== X-Gm-Message-State: AG10YOQZTwmzjnFlxjMudpaxLCwsy9UeBH2PhkUVSxX+c5KG22VS3YpCM9avC3QMRb2x6SEx4Gftylr9Y3qoliwt X-Received: by 10.129.72.18 with SMTP id v18mr23307464ywa.228.1456323425128; Wed, 24 Feb 2016 06:17:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.48.214 with HTTP; Wed, 24 Feb 2016 06:16:45 -0800 (PST) In-Reply-To: <56CD91F0.2090705@comodo.com> References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> <56CC373C.30201@comodo.com> <56CD91F0.2090705@comodo.com> From: Tom Ritter Date: Wed, 24 Feb 2016 08:16:45 -0600 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Ben Laurie , Daniel Kahn Gillmor Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 14:17:08 -0000 Not interleaving this time, but batch-replying: On 23 February 2016 at 04:41, Rob Stradling wrote: > On 23/02/16 06:03, Tom Ritter wrote: > >>> >>> [Rob] >>> I think that blacklisting the shared issuer public key would be better >>> than >>> blacklisting the shared issuer name. >> >> >> At first glance, I agree - but there is that annoying trick where you >> can generate multiple (or at least two) public keys that all certify >> the same signature. So I'm not sure this would actually work. > > > SCTs in 6962-bis already contain the issuer_key_hash (which is the DER > encoding of the issuer's SubjectPublicKeyInfo). Is that enough to defeat > your trick key attack? Yes. >>> [Rob] >>> AIUI, MS CryptoAPI prefers to build certificate chains using the >>> Authority/Subject Key Identifiers, and it only cares about whether or not >>> the Issuer/Subject Names match if AKI/SKI are absent. >> >> >> AKI would _not_ match on these trick public keys, but presumably the >> algorithm would fall back to the Issuer name...? > > > For Win2K and WinXP, it appears that it only attempts name matching if the > AKI extension is absent. > > "If there is no information in the AKI, or the AKI does not exist in the > certificate being evaluated, a certificate whose subject name matches the > evaluated certificate's issuer name will be chosen. This selection method is > known as a name match." > https://technet.microsoft.com/en-us/library/cc700843.aspx That's beneficial for our purposes though. > >>> >>> [Rob] >>> - say that TLS clients SHOULD fetch and verify inclusion proofs for >>> all >>> intermediate certs that they rely on. >> >> I'm nervous about this. > > Why so? I wasn't suggesting a "MUST". ;-) What's the risk to clients who don't? Currently, in gossip clients who don't want to fetch proofs (because it's unacceptable to them privacy-wise or whatever) can use SCT Feedback. (If they talk to a site that doesn't use SCT Feedback, then they're sunk, but we hope this and other incentives will encourage uptake of SCT Feedback.) Because the say the client MUST submit the full chain in SCT Feedback... I think SCT Feedback does actually cover the clients who don't get the inclusion proof for the intermediate. And it would be simple enough to add the SHOULD to STH Pollination to grab a STH for the intermediate cert and pollinate that. So now I'm less worried. On 23 February 2016 at 05:06, Ben Laurie wrote: > On 23 February 2016 at 06:03, Tom Ritter wrote: >> At first glance, I agree - but there is that annoying trick where you >> can generate multiple (or at least two) public keys that all certify >> the same signature. So I'm not sure this would actually work. > > Hmm. That would be e and e + phi(n), I guess? This is a good walkthrough: http://crypto.stackexchange.com/q/8902 On 23 February 2016 at 19:59, Daniel Kahn Gillmor wrote: > On Tue 2016-02-23 03:06:25 -0800, Ben Laurie wrote: >> Fair point. At least two ways of doing this: >> >> a) Run a log that is not trusted for HTTPS connections. > > (trolling: i thought logs didn't have to be trusted...) > > what encourages any party in the ecosystem to log in this untrutsed log? Technically we don't need CAs to log to that log, the community can log to it. Google Crawler, the EFF's Distributed HTTPS Observatory, Firefox plugins, replication from other logs... On 24 February 2016 at 05:20, Rob Stradling wrote: > Actually, issuer_key_hash is already included in the > TimestampedCertificateEntryDataV2 structure from which leaf hashes are > calculated. I think that's sufficient to guard against inclusion proofs > being considered valid in conjunction with a trick issuer public key (but > please correct me if I'm wrong!) To be 100% honest I have not tracked -bis as closely as I should have. So I need to take a pass through gossip and make sure that the types of things I expect 'intuitively' from bis align with what it provides. From nobody Wed Feb 24 07:36:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1A71B3565 for ; Wed, 24 Feb 2016 07:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv7mHbZ8qbca for ; Wed, 24 Feb 2016 07:36:02 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 A92F61B3555 for ; Wed, 24 Feb 2016 07:36:01 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id h129so17868522ywb.1 for ; Wed, 24 Feb 2016 07:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XTB+S/qmgV29koMoh8eOzlxzus1aukZH2M/+DNKtMg8=; b=t6jMahNfhbAvLaMy9/oYS7dE5LhfuabQt9WglwifmSIrBH7A0HDbxcVi8wdcs6Gp+k kC+S+UXELYyxifvn+0Zuy2chy0aJs6rwCliJj1N4QlpBMh2+2mAjV78yH9AsN0QVnZcl uRtxMLd/K0mEv440EUIT+MSRqZm7k98yGg6eM= 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:content-type; bh=XTB+S/qmgV29koMoh8eOzlxzus1aukZH2M/+DNKtMg8=; b=mVtyxFalLolnscXTeMCGzInpkgjEQ/WGzVtfT6xa7+J13eMnELlYMkmVq21whJnTEb Xwtuj3BjATKTmH7PpwlVNs33JuFKXCwvKDZwyLoWOfnW6XOyoHLlTRrnpvctH8kC3mwH rGGpPG0cqfHeKLHp5sfFJEZxP+jfC1/NqmYoLBH70YFLNOfNVW8cJE50o/3KHiqiX2Df rXYTi4RtWpuweSJ4iyqXSNSFkEP4HzOlJ+JnWyQ/ubDKzMBBKlZ8p0GiJp4PyLQqMFEK jVXW9cJX6jbGKksJteMCHcDb0CIVFQ40uNH9CerVQhzDq0368fHhZoegOnH2oxrjzhF0 x75w== X-Gm-Message-State: AG10YOTKIaIMjhxJXs7j0sTC+qCuIMase/5zJIvhdQdGVRnU6wOHIzgIPm3JfazVzAkJ7WcCN9ma2+1tg5/qFqLw X-Received: by 10.13.207.195 with SMTP id r186mr19902732ywd.178.1456328160966; Wed, 24 Feb 2016 07:36:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.48.214 with HTTP; Wed, 24 Feb 2016 07:35:41 -0800 (PST) In-Reply-To: References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> <87povm27iu.fsf@alice.fifthhorseman.net> From: Tom Ritter Date: Wed, 24 Feb 2016 09:35:41 -0600 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Rob Stradling , "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:36:03 -0000 On 24 February 2016 at 08:15, Ben Laurie wrote: Sorry, this is complicated. I type a lot when it's complicated. Thinking about the public key trick more... I don't think it would work. R -> I -> L Goal is to match a signature on L by making a new I' and then getting a client to accept the chain. Changing the public key in I' will invalidate the signature by R. So while I can mint a new certificate I' that makes a valid subchain - it won't chain all the way up. The public key of the fraudulent Intermediate should be blacklisted. Blacklisting the Subject of the intermediate is a poor choice for the same reason that using serial number in CRLs/OCSP is a poor choice. The smart attacker will collide the serial/Subject with an existing Intermediate that is nigh-unrevokable (because it breaks the internet). We need to use something that asserts cryptographic uniqueness for practical purposes - but it can't be _too_ unique or an attacker uses a trick to get around it.[0] SPKI seems like the mechanic of choice... Do crlsets and OneCRL have the ability to blacklist on SPKI? Or do they use serials or fingerprints? =) So a software update blacklists the SPKI of the fradulent intermediate, which will block A_X and B_X. (We only know about A_X though, so A gets the heat while B is still unknown-compromised.) The problem isn't that an attacker can continue to issue certs off A_X and log them - the problem is the attacker may be able to continue to issue *Intermediates* off of A (and B silently & simultaneously) and log certificates off the new intermediate A_Y (of which the SCT would be valid for B_Y also.) The community sees A_Y and doesn't really flinch/understand the implications w.r.t a future world where SCTs are required for all connections. In that world, we would need to blacklist all new SPKIs (in software) issued by A as they pop up on the offchance they've also been minted under B. This seems less than ideal because the smart attacker would issue so many intermediates that Browsers could not realistically blacklist them all. (And blacklisting A doesn't help.) More engineering would be needed to accomodate all the intermediates, it would delay the deployment... meanwhile the attacker uses B_746385 to attack users. This is a failing of CT, in that it puts us back in the days of "If someone is owned, we don't know." Ben gave two ways of fixing this, I'll reword/expand: a) Run a log that tracks everything (including a new A_Y and A_Y-issued certs) but isn't used in browsers. I'll expand this: Do not issue SCTs from any other log used by browsers if the issuer_key_hash matches an intermediate issued by A. In browser software, blacklist the SPKI of A_X at least, perhaps also A (one would hope). I think this would work - but it introduces a complicated new function for log operators. They need to be able to look at an issuing_key_hash and reject submissions if that matches a blacklist but fulfills the root store whitelist (as opposed to currently only checking roots on a whitelist.) If they omit this, or fail to update the blacklist, AND an auditor remembers this attack and implements a check for it (is anyone adding this to any long-term storage? the Threat Analysis doc?) - we can retroactively detect the attack again (after some users could be attacked.) If they implement this check the log SHOULD raise giant alarms if it gets a submission that fulfills the root store whitelist but matches the blacklist. b) Continue to accept certs from A_X and A in the main logs, but don't allow SCTs for certs chaining to either A_X (or A depending on the investigation - but definetly A as soon as a new A_Y pops up). Ben said something involving timestamps - but I don't think that could work because we have to assume the attacker can backdate anything they want... So in this case the certs issued by A_X and A are in the log, and can have inclusion proofs but they were never given a SCT. This seems strange to me (and dkg.) But at the moment I'm not sure if an inclusion proof is equiavlent to a SCT and would enable an attacker to do anything. I guess it depends on how we require future validation in client software and if we were ever to say "An inclusion proof is acceptable in place of an SCT". I'm not sure if we want to commit ourselves to rejecting that equivalence for all time... There's got to be more solutions.... c) Log signs the exact chain. Client must build this same chain and match it. This would fix everything, but it requires strict path building by the client, which won't happen. d) Log signs the chain but the client uses this as a _hint_. If it builds a path that it deems is 'wrong' based on the hint (e.g. the hint says Federal PKI but the chain I built uses CNNIC) then reject it. This would require complicated logic that's probably impossible to get right more than 80% of the time. e) The issuer_key_hash is not over the SPKI but the certificate - including the signature by that issuer's issuer. This would... also break path building? Because of cross signatures? I guess I'm still confused about those. If R is cross-signed by another CA, C. There are two R's right? R-self-signed and R-signed-by-C. Or in Let's Encrypt's case there are two intermediate certs I: I-signed-by-Lets-Encrypt and I-signed-by-Identrust? I guess I know there's more solutions, but isn't there another that's workable? -tom [0] What do I mean by this? Say you used a cert fingerprint. Using BER tricks, you has, in the past, been able to change the fingerprint without invalidating the signature: https://git.openssl.org/?p=openssl.git;a=commitdiff;h=684400ce192dac51df3d3e92b61830a6ef90be3e From nobody Wed Feb 24 14:27:39 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5C61A002A for ; Wed, 24 Feb 2016 14:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYeXV65JiPEl for ; Wed, 24 Feb 2016 14:27:35 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 B48F41A002C for ; Wed, 24 Feb 2016 14:27:35 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id xg9so1194435igb.1 for ; Wed, 24 Feb 2016 14:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DhqTf6EionUMH/Ij57zq/nByeIVfXyuySibcIt2hAhA=; b=mzbEgISsIs/hLXWdzQCFWp/RDwankN1t5m4Nc90+eIqkKU5G+PJa0LbRYRD/VCuQjF 8QENHFLLdxW8QvoOqSvFI/TOPrYgESnu27aHWM+zNksAQDwv88nZTTpdphrx95UGevRR suFdh3W1E74IU2VkcDExag2yt4w9rr8JiPjdcVvMpXV8P9X2lhCfur795xyRBaXTUyMP tWKqJS5992TvV0j8rZYwG+CliPQV/MZZ+3yQpjKP9bC+py4yTCSYQ2qpjL05/ENj7j3a Am0hIr18R0+V/pnu5bAEEF9i31BGmiw5+V94nZScUMSMpGWA9KRvO8vxeltP/Q3X8Pq2 eW2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DhqTf6EionUMH/Ij57zq/nByeIVfXyuySibcIt2hAhA=; b=hXoxiq0Lid8Y9xrkH8YwQYYJQKfR5vY4zNDEGZK5rRIKfvfGdvP38hL1nJfu7Qz23C ZkqWk0MwJLowS+BIqWlAJslX0SiwBy6zNB12nT+T0uRIp14OCT46YS8C/awVrWet5PK7 XhbmLIjgrfLqdTWpLMrQjZKKi1jk3jQVnCA4FaF5O3NdSF/nJwoDUwh894YQIsf6ROLh I0zWDEpc7q+nZRjEMMI9l9raB+wfDnEDP9pXFFLd9OZ7Wljugn9NSDZxq68QVCveEi9G hobnqBbkLQ5nhdHIsTlHvEg1iEJ2Sl5l2N0akAStkawLZkX0layMzRTyGMKQ2a1txeO1 AU7A== X-Gm-Message-State: AG10YOT16V8HtVGhpa7icIEbfL28s2z5L2OYeWDRErKeVwBLLx1fLcI5wRKjCrnDBuxkGd/0mxhpXBkSdH3sMJXO MIME-Version: 1.0 X-Received: by 10.50.171.162 with SMTP id av2mr174649igc.32.1456352854972; Wed, 24 Feb 2016 14:27:34 -0800 (PST) Received: by 10.64.26.98 with HTTP; Wed, 24 Feb 2016 14:27:34 -0800 (PST) In-Reply-To: References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> <87povm27iu.fsf@alice.fifthhorseman.net> Date: Wed, 24 Feb 2016 22:27:34 +0000 Message-ID: From: Ben Laurie To: Tom Ritter Content-Type: multipart/alternative; boundary=089e0118429e96ec55052c8b9291 Archived-At: Cc: Rob Stradling , "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 22:27:38 -0000 --089e0118429e96ec55052c8b9291 Content-Type: text/plain; charset=UTF-8 On 24 February 2016 at 15:35, Tom Ritter wrote: > On 24 February 2016 at 08:15, Ben Laurie wrote: > > Sorry, this is complicated. I type a lot when it's complicated. > > > > Thinking about the public key trick more... I don't think it would work. > R -> I -> L > > Goal is to match a signature on L by making a new I' and then getting > a client to accept the chain. Changing the public key in I' will > invalidate the signature by R. So while I can mint a new certificate > I' that makes a valid subchain - it won't chain all the way up. > > > > > The public key of the fraudulent Intermediate should be blacklisted. > Blacklisting the Subject of the intermediate is a poor choice for the > same reason that using serial number in CRLs/OCSP is a poor choice. > The smart attacker will collide the serial/Subject with an existing > Intermediate that is nigh-unrevokable (because it breaks the > internet). > > We need to use something that asserts cryptographic uniqueness for > practical purposes - but it can't be _too_ unique or an attacker uses > a trick to get around it.[0] SPKI seems like the mechanic of choice... > > Do crlsets and OneCRL have the ability to blacklist on SPKI? Or do > they use serials or fingerprints? =) > https://github.com/agl/crlset-tools (answer: yes, crlsets can blacklist on SPKI). > So a software update blacklists the SPKI of the fradulent > intermediate, which will block A_X and B_X. (We only know about A_X > though, so A gets the heat while B is still unknown-compromised.) > > The problem isn't that an attacker can continue to issue certs off A_X > and log them - the problem is the attacker may be able to continue to > issue *Intermediates* off of A (and B silently & simultaneously) and > log certificates off the new intermediate A_Y (of which the SCT would > be valid for B_Y also.) The community sees A_Y and doesn't really > flinch/understand the implications w.r.t a future world where SCTs are > required for all connections. > > In that world, we would need to blacklist all new SPKIs (in software) > issued by A as they pop up on the offchance they've also been minted > under B. This seems less than ideal because the smart attacker would > issue so many intermediates that Browsers could not realistically > blacklist them all. (And blacklisting A doesn't help.) More > engineering would be needed to accomodate all the intermediates, it > would delay the deployment... meanwhile the attacker uses B_746385 to > attack users. This is a failing of CT, in that it puts us back in the > days of "If someone is owned, we don't know." > > > > > Ben gave two ways of fixing this, I'll reword/expand: > > a) Run a log that tracks everything (including a new A_Y and > A_Y-issued certs) but isn't used in browsers. I'll expand this: > > Do not issue SCTs from any other log used by browsers if the > issuer_key_hash matches an intermediate issued by A. In browser > software, blacklist the SPKI of A_X at least, perhaps also A (one > would hope). > > I think this would work - but it introduces a complicated new function > for log operators. They need to be able to look at an issuing_key_hash > and reject submissions if that matches a blacklist but fulfills the > root store whitelist (as opposed to currently only checking roots on a > whitelist.) > > If they omit this, or fail to update the blacklist, AND an auditor > remembers this attack and implements a check for it (is anyone adding > this to any long-term storage? the Threat Analysis doc?) - we can > retroactively detect the attack again (after some users could be > attacked.) > Surely no-one has to remember anything ... if a browser-used log logs a cert that is for a domain that wasn't expecting that cert to be issued, then action needs to be taken. Eventually, presumably, everyone will get bored of taking action on every cert issued by the compromised CA and deal with the problem in a more fundamental way. Such as blacklisting the SPKI. > > If they implement this check the log SHOULD raise giant alarms if it > gets a submission that fulfills the root store whitelist but matches > the blacklist. > > > b) Continue to accept certs from A_X and A in the main logs, but don't > allow SCTs for certs chaining to either A_X (or A depending on the > investigation - but definetly A as soon as a new A_Y pops up). Ben > said something involving timestamps - but I don't think that could > work because we have to assume the attacker can backdate anything they > want... > > So in this case the certs issued by A_X and A are in the log, and can > have inclusion proofs but they were never given a SCT. This seems > strange to me (and dkg.) But at the moment I'm not sure if an > inclusion proof is equiavlent to a SCT and would enable an attacker to > do anything. I guess it depends on how we require future validation in > client software and if we were ever to say "An inclusion proof is > acceptable in place of an SCT". I'm not sure if we want to commit > ourselves to rejecting that equivalence for all time... > > > > There's got to be more solutions.... > > c) Log signs the exact chain. Client must build this same chain and > match it. This would fix everything, but it requires strict path > building by the client, which won't happen. > > d) Log signs the chain but the client uses this as a _hint_. If it > builds a path that it deems is 'wrong' based on the hint (e.g. the > hint says Federal PKI but the chain I built uses CNNIC) then reject > it. This would require complicated logic that's probably impossible to > get right more than 80% of the time. > > e) The issuer_key_hash is not over the SPKI but the certificate - > including the signature by that issuer's issuer. This would... also > break path building? Because of cross signatures? I guess I'm still > confused about those. If R is cross-signed by another CA, C. There are > two R's right? R-self-signed and R-signed-by-C. Or in Let's Encrypt's > case there are two intermediate certs I: I-signed-by-Lets-Encrypt and > I-signed-by-Identrust? > > > I guess I know there's more solutions, but isn't there another that's > workable? > > -tom > > > > [0] What do I mean by this? Say you used a cert fingerprint. Using BER > tricks, you has, in the past, been able to change the fingerprint > without invalidating the signature: > > https://git.openssl.org/?p=openssl.git;a=commitdiff;h=684400ce192dac51df3d3e92b61830a6ef90be3e > --089e0118429e96ec55052c8b9291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 February 2016 at 15:35, Tom Ritter <tom@ritter.vg> wr= ote:
On 24 February 2016 at 08:15, Ben Laurie <benl@google.com> wrote:

Sorry, this is complicated. I type a lot when it's complicated.



Thinking about the public key trick more... I don't think it would work= .
R -> I -> L

Goal is to match a signature on L by making a new I' and then getting a client to accept the chain. Changing the public key in I' will
invalidate the signature by R. So while I can mint a new certificate
I' that makes a valid subchain - it won't chain all the way up.




The public key of the fraudulent Intermediate should be blacklisted.
Blacklisting the Subject of the intermediate is a poor choice for the
same reason that using serial number in CRLs/OCSP is a poor choice.
The smart attacker will collide the serial/Subject with an existing
Intermediate that is nigh-unrevokable (because it breaks the
internet).

We need to use something that asserts cryptographic uniqueness for
practical purposes - but it can't be _too_ unique or an attacker uses a trick to get around it.[0] SPKI seems like the mechanic of choice...

Do crlsets and OneCRL have the ability to blacklist on SPKI? Or do
they use serials or fingerprints?=C2=A0 =3D)

https://github.com/ag= l/crlset-tools (answer: yes, crlsets can blacklist on SPKI).
<= div>
=C2=A0
So a software update blackl= ists the SPKI of the fradulent
intermediate, which will block A_X and B_X.=C2=A0 (We only know about A_X though, so A gets the heat while B is still unknown-compromised.)

The problem isn't that an attacker can continue to issue certs off A_X<= br> and log them - the problem is the attacker may be able to continue to
issue *Intermediates* off of A (and B silently & simultaneously) and log certificates off the new intermediate A_Y (of which the SCT would
be valid for B_Y also.)=C2=A0 The community sees A_Y and doesn't really=
flinch/understand the implications w.r.t a future world where SCTs are
required for all connections.

In that world, we would need to blacklist all new SPKIs (in software)
issued by A as they pop up on the offchance they've also been minted under B.=C2=A0 This seems less than ideal because the smart attacker would<= br> issue so many intermediates that Browsers could not realistically
blacklist them all.=C2=A0 (And blacklisting A doesn't help.) More
engineering would be needed to accomodate all the intermediates, it
would delay the deployment... meanwhile the attacker uses B_746385 to
attack users. This is a failing of CT, in that it puts us back in the
days of "If someone is owned, we don't know."




Ben gave two ways of fixing this, I'll reword/expand:

a) Run a log that tracks everything (including a new A_Y and
A_Y-issued certs) but isn't used in browsers. I'll expand this:

Do not issue SCTs from any other log used by browsers if the
issuer_key_hash matches an intermediate issued by A. In browser
software, blacklist the SPKI of A_X at least, perhaps also A (one
would hope).

I think this would work - but it introduces a complicated new function
for log operators. They need to be able to look at an issuing_key_hash
and reject submissions if that matches a blacklist but fulfills the
root store whitelist (as opposed to currently only checking roots on a
whitelist.)

If they omit this, or fail to update the blacklist, AND an auditor
remembers this attack and implements a check for it (is anyone adding
this to any long-term storage? the Threat Analysis doc?) - we can
retroactively detect the attack again (after some users could be
attacked.)

Surely no-one has to remembe= r anything ... if a browser-used log logs a cert that is for a domain that = wasn't expecting that cert to be issued, then action needs to be taken.=

Eventually, presumably, everyone will get bored o= f taking action on every cert issued by the compromised CA and deal with th= e problem in a more fundamental way. Such as blacklisting the SPKI.

=C2=A0

If they implement this check the log SHOULD raise giant alarms if it
gets a submission that fulfills the root store whitelist but matches
the blacklist.


b) Continue to accept certs from A_X and A in the main logs, but don't<= br> allow SCTs for certs chaining to either A_X (or A depending on the
investigation - but definetly A as soon as a new A_Y pops up).=C2=A0 Ben said something involving timestamps - but I don't think that could
work because we have to assume the attacker can backdate anything they
want...

So in this case the certs issued by A_X and A are in the log, and can
have inclusion proofs but they were never given a SCT.=C2=A0 This seems
strange to me (and dkg.) But at the moment I'm not sure if an
inclusion proof is equiavlent to a SCT and would enable an attacker to
do anything. I guess it depends on how we require future validation in
client software and if we were ever to say "An inclusion proof is
acceptable in place of an SCT".=C2=A0 I'm not sure if we want to c= ommit
ourselves to rejecting that equivalence for all time...



There's got to be more solutions....

c) Log signs the exact chain. Client must build this same chain and
match it. This would fix everything, but it requires strict path
building by the client, which won't happen.

d) Log signs the chain but the client uses this as a _hint_. If it
builds a path that it deems is 'wrong' based on the hint (e.g. the<= br> hint says Federal PKI but the chain I built uses CNNIC) then reject
it. This would require complicated logic that's probably impossible to<= br> get right more than 80% of the time.

e) The issuer_key_hash is not over the SPKI but the certificate -
including the signature by that issuer's issuer.=C2=A0 This would... al= so
break path building? Because of cross signatures?=C2=A0 I guess I'm sti= ll
confused about those. If R is cross-signed by another CA, C. There are
two R's right? R-self-signed and R-signed-by-C.=C2=A0 Or in Let's E= ncrypt's
case there are two intermediate certs I: I-signed-by-Lets-Encrypt and
I-signed-by-Identrust?


I guess I know there's more solutions, but isn't there another that= 's workable?

-tom



[0] What do I mean by this? Say you used a cert fingerprint. Using BER
tricks, you has, in the past, been able to change the fingerprint
without invalidating the signature:
= https://git.openssl.org/?p=3Dopenssl.git;a=3Dcommitdiff;h=3D684400ce192dac5= 1df3d3e92b61830a6ef90be3e

--089e0118429e96ec55052c8b9291-- From nobody Thu Feb 25 23:38:06 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556B71ACE0F for ; Thu, 25 Feb 2016 23:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRU-4S4yfNWl for ; Thu, 25 Feb 2016 23:38:03 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CA45D1ACE09 for ; Thu, 25 Feb 2016 23:38:02 -0800 (PST) Received: from fifthhorseman.net (unknown [195.76.232.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 14B4DF999; Fri, 26 Feb 2016 02:37:57 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9406121138; Fri, 26 Feb 2016 06:02:00 +0100 (CET) From: Daniel Kahn Gillmor To: Ben Laurie , Tom Ritter In-Reply-To: References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <56CAF5B2.30207@comodo.com> <87povm27iu.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 26 Feb 2016 06:02:00 +0100 Message-ID: <8760xccbef.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] can CT defend against dual CA compromise? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 07:38:05 -0000 On Wed 2016-02-24 23:27:34 +0100, Ben Laurie wrote: > https://github.com/agl/crlset-tools (answer: yes, crlsets can blacklist on > SPKI). good, i'm glad to hear it. > Surely no-one has to remember anything ... if a browser-used log logs > a cert that is for a domain that wasn't expecting that cert to be > issued, then action needs to be taken. Sure, but if that action is nothing because "meh, this particular browser-used log just hasn't rejected certs that chain back to A yet, and we know that A is bad, so we can just ignore this leaf cert", then we're in the situation that CT is supposed to prevent. OTOH, If we expect all browser-used logs to immediately refuse to serve SCTs that chain to a given root (A) whenever any of A's intermediates (A_X) is shown to have misissued anything (how do we prove a misissuance, as opposed to compromise or organizational failure of the end entity itself again?), then we get to try to coordinate a new set of multiple parties during an apparent CA compromise (logs this time, in addition to browser vendors), and log operators themselves need to make potentially-political decisions about which roots or intermediates to blacklist and which to continue logging. More generally, I'm quite concerned that we seem to be adding a second category of log to the CT ecosystem in an attempt to have an analysis that doesn't have this dual-CA-compromise issue. The CT ecosystem is complicated and hard to analyze with only one kind of log, and now it seems that we have: * browser-used logs * non-browser-used logs What are the different requirements of each kind of log? What kinds of decisions do the different kinds of log operators need to make? What additional data structures do they need to maintain for correct operation? How does the ecosystem as a whole depend on them doing their specific work? what happens if they fail? what incentives do people have to offer one kind of log or another? Do auditors need to look at both kinds of logs, or only one? > Eventually, presumably, everyone will get bored of taking action on > every cert issued by the compromised CA and deal with the problem in a > more fundamental way. Such as blacklisting the SPKI. Who blacklists the SPKI? All browser vendors? browser-used logs? non-browser-used logs? which SPKI gets blacklisted? blacklisting the SPKI of the intermediate cert doesn't work if the root CA is compromised -- the attacker can just issue a new intermediate. how many compromised intermediates does a log need to see before it decides to blacklist the root CA itself? Does it need to coordinate such a blacklist with the browser vendors? with all of them, or just some of them? sorry for being all questions and no answers, but this still doesn't seem resolved to me. --dkg From nobody Mon Feb 29 11:24:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB21B3A61 for ; Mon, 29 Feb 2016 11:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xs4Xs4LRium for ; Mon, 29 Feb 2016 11:24:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211071B3A60 for ; Mon, 29 Feb 2016 11:24:16 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:42570 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aaTQS-0009zZ-DX; Mon, 29 Feb 2016 14:24:12 -0500 To: Eran Messeri References: <057.35eb1e87b6861f551e4f028e2b93c3f4@tools.ietf.org> <072.7f4522d84e6f746100b591d7f670bc35@tools.ietf.org> <5672E115.1010701@bbn.com> <568D7AC3.2000301@bbn.com> From: Stephen Kent Message-ID: <56D49ADB.1000708@bbn.com> Date: Mon, 29 Feb 2016 14:24:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010109080702020107000902" Archived-At: Cc: Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] [trans] #93 (rfc6962-bis): Monitor description: Inconsistency between intro and section 5.4 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:24:18 -0000 This is a multi-part message in MIME format. --------------010109080702020107000902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Eran, I would like to see auditing described as a separate function, independent of a Monitor. My recollection (after being on vacation for 3 weeks) was that this distinction was OK in the intro, then muddled in the discussion of the Monitor, which was described in a way that made it an auditor. I provided text to try to fix this. I'm not sure if you are saying that the text I provided does not address the problem, or that you and your co-authors have rejected that text and are unable to generate alternative text to address the concern I cited. Steve > Risking resurrection of an old thread, I'll point out that when > addressing ticket 141 > > more text was added about auditing, which should clarify what a > monitor can do if it's interested in auditing. > Ticket 118 seems > to repeat the concern originally raised in ticket 93, but we couldn't > come up with text that would be meaningful and address the concern > raised in that ticket. > > On Wed, Jan 6, 2016 at 8:36 PM, Stephen Kent > wrote: > > Paul, > > On Thu, 17 Dec 2015, Stephen Kent wrote: > > I also agree that the architecture document provides a > more in-depth > description of the Monitor function, but it is also at > odds with the > description in the -11 draft. So, I disagree with the > proposal to > leave the current text in place. > > > Then please provide improved text (not scaffolding) for the > bis document. > > Paul > > I have done so, via the issue tracker. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --------------010109080702020107000902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Eran,

I would like to see auditing described as a separate function, independent of a Monitor.
My recollection (after being on vacation for 3 weeks) was that this distinction was
OK in the intro, then muddled in the discussion of the Monitor, which was described in
a way that made it an auditor. I provided text to try to fix this. I'm not sure if you
are saying that the text I provided does not address the problem, or that you and your
co-authors have rejected that text and are unable to generate alternative text to address
the concern I cited.

Steve

Risking resurrection of an old thread, I'll point out that when addressing ticket 141 more text was added about auditing, which should clarify what a monitor can do if it's interested in auditing.
Ticket 118 seems to repeat the concern originally raised in ticket 93, but we couldn't come up with text that would be meaningful and address the concern raised in that ticket. 

On Wed, Jan 6, 2016 at 8:36 PM, Stephen Kent <kent@bbn.com> wrote:
Paul,

On Thu, 17 Dec 2015, Stephen Kent wrote:

I also agree that the architecture document provides a more in-depth
description of the Monitor function, but it is also at odds with the
description in the -11 draft. So, I disagree with the proposal to
leave the current text in place.

Then please provide improved text (not scaffolding) for the bis document.

Paul
 I have done so, via the issue tracker.

Steve


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


--------------010109080702020107000902-- From nobody Mon Feb 29 11:30:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDB01B3A70 for ; Mon, 29 Feb 2016 11:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5Yka3bhkkpc for ; Mon, 29 Feb 2016 11:30:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A311B3A74 for ; Mon, 29 Feb 2016 11:30:20 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:42584 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aaTWL-000A1u-UO; Mon, 29 Feb 2016 14:30:18 -0500 To: trans issue tracker , rob.stradling@comodo.com, eranm@google.com References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> <072.ee7a69299880709258377930de8c1a93@tools.ietf.org> From: Stephen Kent Message-ID: <56D49C49.6050207@bbn.com> Date: Mon, 29 Feb 2016 14:30:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <072.ee7a69299880709258377930de8c1a93@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:30:23 -0000 Rob, I'm not sure what your proposed resolution for this issue means. Phases like "a suitably name-constrained intermediate cert" and "clients may need to used trial and error" are not really appropriate for a standard. I'll await publication of the next rev of 6962-bis to see if there is an algorithmic description of how the matching is to be performed. Steve > #23: How can TLS clients match an SCT to a certificate? > > Changes (by rob.stradling@comodo.com): > > * milestone: => review > > > Comment: > > Fixed by https://github.com/google/certificate-transparency- > rfcs/commit/d71d7707a3eeb5707cf5048c3849b068e477038c > > The !ItemExtension field is gone. When there's a suitably name- > constrained intermediate in the certificate chain, TLS clients may need to > use trial and error to determine which of the certificates in the chain an > SCT or inclusion proof corresponds to. > From nobody Mon Feb 29 11:34:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1541B3A7D for ; Mon, 29 Feb 2016 11:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RriPTxDAicvG for ; Mon, 29 Feb 2016 11:34:12 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7369A1B3A71 for ; Mon, 29 Feb 2016 11:34:11 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:42595 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aaTa5-000A3Y-8I; Mon, 29 Feb 2016 14:34:09 -0500 To: trans issue tracker , draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> From: Stephen Kent Message-ID: <56D49D30.5070506@bbn.com> Date: Mon, 29 Feb 2016 14:34:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:34:13 -0000 Ben, The issue was that 6962-bis does a partial job of describing TLS server behavior, and that one way to fix this is to remove that description and provide a more complete description in a separate doc. Your comment does not address this concern, and I disagree with Paul's decision to accept your proposed wontfix resolution. Steve > #122: TLS server requirements > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > That makes no sense to me - without defining how CT data is communicated, > CT can't be used at all. > > Suggest resolve as wontfix. > From nobody Mon Feb 29 11:37:00 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471791B3704 for ; Mon, 29 Feb 2016 11:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE1LN0UyoMYz for ; Mon, 29 Feb 2016 11:36:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAFB1B2EC4 for ; Mon, 29 Feb 2016 11:36:56 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:51010 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aaTcl-0006xZ-5G; Mon, 29 Feb 2016 14:36:55 -0500 To: trans issue tracker , draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com References: <053.1c580d171592bb2acabeaa241fef51ff@tools.ietf.org> <068.d19af4a885287eecc4596e837195df4b@tools.ietf.org> From: Stephen Kent Message-ID: <56D49DD6.9090906@bbn.com> Date: Mon, 29 Feb 2016 14:36:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <068.d19af4a885287eecc4596e837195df4b@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #123 (rfc6962-bis): log clients description too informal, incomplete X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:36:57 -0000 Ben, > #123: log clients description too informal, incomplete > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > The point is that CT provides data you might choose to act on. This > section describes some ways in which you can reliably get hold of the data > you might choose to act on. It is intended to be informative and without > it would make it substantially difficult for implementers to implement CT. > > Suggest resolve wontfix. > My point is that a squishy discussion of what a log client might do isn't appropriate for a standard. If one cannot be precise in describing how each element of a system is supposed to work, then readers have no confidence that there is a consistent, comprehensive system design. Different readers can come away with different notions of how the system works, which leads to confusion. Steve From nobody Mon Feb 29 11:38:10 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2F81B3A71 for ; Mon, 29 Feb 2016 11:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkasche7xOHW for ; Mon, 29 Feb 2016 11:38:07 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA06C1B3A83 for ; Mon, 29 Feb 2016 11:38:07 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:51013 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aaTdu-0006zF-Ob for trans@ietf.org; Mon, 29 Feb 2016 14:38:06 -0500 To: trans@ietf.org References: <053.3e65853a87a6fd2b6925890c73673cd7@tools.ietf.org> <068.f6d8cfb35c1bd9e2deedfb8e5098fa39@tools.ietf.org> From: Stephen Kent Message-ID: <56D49E1E.6000303@bbn.com> Date: Mon, 29 Feb 2016 14:38:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <068.f6d8cfb35c1bd9e2deedfb8e5098fa39@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #139 (rfc6962-bis): move text re: domain labels to CA specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:38:08 -0000 Ben > #139: move text re: domain labels to CA specification > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > I don't believe the WG has agreed this doc should focus on log operation. > > Suggest resolve as wontfix. > I don't believe that any significant fraction of the WG has expressed an opinion about this matter on the list, despite requests from Melinda. Steve From nobody Mon Feb 29 11:40:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7641B3A75 for ; Mon, 29 Feb 2016 11:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZnqHSX3ENlC for ; Mon, 29 Feb 2016 11:40:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E3A1B34DB for ; Mon, 29 Feb 2016 11:40:49 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:42611 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aaTgW-000A6a-Iy for trans@ietf.org; Mon, 29 Feb 2016 14:40:48 -0500 To: trans@ietf.org References: <56B1192D.4020102@gmail.com> From: Stephen Kent Message-ID: <56D49EC0.7030709@bbn.com> Date: Mon, 29 Feb 2016 14:40:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010801090303030902000307" Archived-At: Subject: Re: [Trans] Looking for feedback on open issue X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:40:51 -0000 This is a multi-part message in MIME format. --------------010801090303030902000307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ben, > > > On 2 February 2016 at 21:01, Melinda Shore > wrote: > > Hi, all: > > We're looking for feedback on ticket 121 > (https://trac.tools.ietf.org/wg/trans/trac/ticket/121). > > The issue is this (from Steve Kent): > > "After Prague I agreed that log metadata can be supplied by > browser vendors for TLS clients hat are browsers. However, max > chain length, which was just discussed on the list (11/16-17/15), > is an example of metadata that needs to be acquired by CAs, just > like the public key for a log. The text in Section 9 needs to say > more about how non-browser log clients are expected to acquire > this data, or maybe it should say that separate docs defining > requirements for each of these types of log clients will discuss > this issue."We continue > > > and where it currently stands is this (from Eran Messeri): > > I agree that log metadata dissemination is a topic that should be > more thoroughly discussed at some point. However, I do not think > that 6962-bis is the right place for it. > Steve has a very valid point about metadata not being specified in > a machine-readable format, nor having a part of the protocol > describing how it is disseminated. > I believe these issues should be addressed separately of 6962-bis, > because: > The topic of log metadata is one level "above" what 6962-bis > discusses. > The requirements for metadata dissemination are very different for > each type of client. > Disseminating metadata reliably is a protocol in itself, which > (once the requirements are clear) deserve its own design. > My suggestion is to punt the discussion until after 6962-bis is > out. Presumably then there would be enough different clients > implementing 6962-bis that disseminating metadata would justify > more efforts from this workgroup. > > This needs further discussion - should this go into a separate > document? > > > If it needs documenting at all, then yes. > We continue to have dramatically different views on what needs to be specified in one or more RFCs so that a standard is well-specified. This is yet another example of our different views. If 6962-bis wants to be viewed as a spec for CT, not just for the CT log, then this is another example of a gap in the spec. Steve --------------010801090303030902000307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Ben,



On 2 February 2016 at 21:01, Melinda Shore <melinda.shore@gmail.com> wrote:
Hi, all:

We're looking for feedback on ticket 121
(https://trac.tools.ietf.org/wg/trans/trac/ticket/121).

The issue is this (from Steve Kent):

"After Prague I agreed that log metadata can be supplied by browser vendors for TLS clients hat are browsers. However, max chain length, which was just discussed on the list (11/16-17/15), is an example of metadata that needs to be acquired by CAs, just like the public key for a log. The text in Section 9 needs to say more about how non-browser log clients are expected to acquire this data, or maybe it should say that separate docs defining requirements for each of these types of log clients will discuss this issue."We continue


and where it currently stands is this (from Eran Messeri):

I agree that log metadata dissemination is a topic that should be more thoroughly discussed at some point. However, I do not think that 6962-bis is the right place for it.
Steve has a very valid point about metadata not being specified in a machine-readable format, nor having a part of the protocol describing how it is disseminated.
I believe these issues should be addressed separately of 6962-bis, because:
The topic of log metadata is one level "above" what 6962-bis discusses.
The requirements for metadata dissemination are very different for each type of client.
Disseminating metadata reliably is a protocol in itself, which (once the requirements are clear) deserve its own design.
My suggestion is to punt the discussion until after 6962-bis is out. Presumably then there would be enough different clients implementing 6962-bis that disseminating metadata would justify more efforts from this workgroup.

This needs further discussion - should this go into a separate
document?

If it needs documenting at all, then yes.

We continue to have dramatically different views on what needs to be specified in
one or more RFCs so that a standard is well-specified. This is yet another example
of our different views. If 6962-bis wants to be viewed as a spec for CT, not just for
the CT log, then this is another example of a gap in the spec.

Steve
--------------010801090303030902000307-- From nobody Mon Feb 29 12:24:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527381B3B8B for ; Mon, 29 Feb 2016 12:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88uGQkLNxgi0 for ; Mon, 29 Feb 2016 12:24:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 4F4C61B3B87 for ; Mon, 29 Feb 2016 12:24:50 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qDY3g5jXmzJvf; Mon, 29 Feb 2016 21:24:47 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id mihvT2NpE5Gn; Mon, 29 Feb 2016 21:24:46 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 29 Feb 2016 21:24:46 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CA7646066262; Mon, 29 Feb 2016 15:24:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CA7646066262 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C818DDA533; Mon, 29 Feb 2016 15:24:45 -0500 (EST) Date: Mon, 29 Feb 2016 15:24:45 -0500 (EST) From: Paul Wouters To: Stephen Kent In-Reply-To: <56D49D30.5070506@bbn.com> Message-ID: References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> <56D49D30.5070506@bbn.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: trans@ietf.org, benl@google.com, draft-ietf-trans-rfc6962-bis@tools.ietf.org, trans issue tracker Subject: Re: [Trans] [trans] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 20:24:51 -0000 On Mon, 29 Feb 2016, Stephen Kent wrote: > The issue was that 6962-bis does a partial job of describing TLS server behavior, > and that one way to fix this is to remove that description and provide a more > complete description in a separate doc. Your comment does not address this concern, > and I disagree with Paul's decision to accept your proposed wontfix > resolution. Writing a separate document is fine, but out of scope for the bis document. Removing text in the bis document and moving it all to a separate document that becomes a blocking normative reference to the bis document is not. If you have proposed text that improves this section of the bis document, please share so we can discuss that. Paul > Steve > >> #122: TLS server requirements >> >> Changes (by benl@google.com): >> >> * milestone: => review >> >> >> Comment: >> >> That makes no sense to me - without defining how CT data is >> communicated, >> CT can't be used at all. >> >> Suggest resolve as wontfix. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > >