From nobody Wed Jan 6 12:36: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 B8CA01A038F for ; Wed, 6 Jan 2016 12:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmqeUEGFyGIT for ; Wed, 6 Jan 2016 12:36:21 -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 36E3C1A0389 for ; Wed, 6 Jan 2016 12:36:21 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:51779 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aGuod-000LHK-Od; Wed, 06 Jan 2016 15:36:19 -0500 From: Stephen Kent To: Paul Wouters References: <057.35eb1e87b6861f551e4f028e2b93c3f4@tools.ietf.org> <072.7f4522d84e6f746100b591d7f670bc35@tools.ietf.org> <5672E115.1010701@bbn.com> Message-ID: <568D7AC3.2000301@bbn.com> Date: Wed, 6 Jan 2016 15:36:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; 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: Cc: 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, 06 Jan 2016 20:36:22 -0000 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 From nobody Fri Jan 8 08:55: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 037421B2A4D for ; Fri, 8 Jan 2016 08:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBi-AlYHDnlM for ; Fri, 8 Jan 2016 08: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 E5B491B2A4C for ; Fri, 8 Jan 2016 08:55:44 -0800 (PST) Received: from localhost ([::1]:43755 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aHaKF-0008Rd-Gx; Fri, 08 Jan 2016 08:55: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: draft-ietf-trans-threat-analysis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Fri, 08 Jan 2016 16:55:43 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/148 Message-ID: <057.14ea9462e1415a11c04a0824f51a2d37@tools.ietf.org> X-Trac-Ticket-ID: 148 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@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-threat-analysis@ietf.org Resent-Message-Id: <20160108165544.E5B491B2A4C@ietfa.amsl.com> Resent-Date: Fri, 8 Jan 2016 08:55:44 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #148 (threat-analysis): Architecture document: Spelling/improvements to 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: Fri, 08 Jan 2016 16:55:46 -0000 #148: Architecture document: Spelling/improvements to Introduction In section 1: onlogs -> on logs repeatedlymisbehave -> repeatedly misbehave. I also propose changing 'repeatedly misbehave' to 'grossly misbehave' (or something else to indicate particularly bad misbehaviour). A log may misbehave multiple times (multiple, minor infractions, e.g. by missing it's MMD by a bit) but still be used by browsers. On the contrary, a log may be disqualified after grossly misbehaving once (e.g. by not including an entry). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: threat- | Version: analysis | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jan 8 08:59: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 CB0A61B2A58 for ; Fri, 8 Jan 2016 08:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 MyCp8RU0ESoL for ; Fri, 8 Jan 2016 08:59: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 D3EA21B2A5D for ; Fri, 8 Jan 2016 08:59:33 -0800 (PST) Received: from localhost ([::1]:43825 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aHaNx-0000FN-KS; Fri, 08 Jan 2016 08:59: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-threat-analysis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Fri, 08 Jan 2016 16:59:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/149 Message-ID: <057.78037b3cf94497f431f6adbc1f7cb594@tools.ietf.org> X-Trac-Ticket-ID: 149 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@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-threat-analysis@ietf.org Resent-Message-Id: <20160108165933.D3EA21B2A5D@ietfa.amsl.com> Resent-Date: Fri, 8 Jan 2016 08:59:33 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #149 (threat-analysis): Architecture document: Figure 1: Finer-grained distinction between entities 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, 08 Jan 2016 16:59:36 -0000 #149: Architecture document: Figure 1: Finer-grained distinction between entities In Figure 1, there's a very good distinction between "defined by CT" / "out of scope for CT" interface. However I suggest the distinction should be finer-grained to indicate which interfaces are specified in RFC6962-bis, which ones in the gossip protocol and which ones entirely out of CT. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: threat- | Version: analysis | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jan 8 09: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 E0D7F1B2A6B for ; Fri, 8 Jan 2016 09:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFczEjxBnGGF for ; Fri, 8 Jan 2016 09:02: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 AD6291B2A69 for ; Fri, 8 Jan 2016 09:02:29 -0800 (PST) Received: from localhost ([::1]:43969 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aHaQn-0001BM-8S; Fri, 08 Jan 2016 09:02: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: draft-ietf-trans-threat-analysis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Fri, 08 Jan 2016 17:02:29 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/150 Message-ID: <057.e2278dd0c4496e2388036e05a7927262@tools.ietf.org> X-Trac-Ticket-ID: 150 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@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-threat-analysis@ietf.org Resent-Message-Id: <20160108170229.AD6291B2A69@ietfa.amsl.com> Resent-Date: Fri, 8 Jan 2016 09:02:29 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [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: Fri, 08 Jan 2016 17:02:31 -0000 #150: Architecture document: Indicate missing SCT is equivalent to invalid one In section 2, in the part about TLS clients (browsers), append "or missing" to the last section so it reads "if the SCT is invalid or missing" - a CT-aware TLS client should treat both cases as equal. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: threat- | Version: analysis | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jan 8 09:07: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 E2FF01B2A54 for ; Fri, 8 Jan 2016 09:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ZaVkiwwj8fRW for ; Fri, 8 Jan 2016 09:07: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 EA6C41A908D for ; Fri, 8 Jan 2016 09:07:19 -0800 (PST) Received: from localhost ([::1]:44172 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aHaVT-00022a-OH; Fri, 08 Jan 2016 09:07: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: draft-ietf-trans-threat-analysis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Fri, 08 Jan 2016 17:07:19 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/151 Message-ID: <057.929b9b011a08641c287fd6d7eb25bb95@tools.ietf.org> X-Trac-Ticket-ID: 151 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@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-threat-analysis@ietf.org Resent-Message-Id: <20160108170719.EA6C41A908D@ietfa.amsl.com> Resent-Date: Fri, 8 Jan 2016 09:07:19 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [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: Fri, 08 Jan 2016 17:07:21 -0000 #151: Architecture document: Only the leaf cert + timestamp are in the SCT In section 3.1: The sentence saying "hashing it with information from other log submissions." is incorrect. The SCT only covers the the end-entity certificate and timestamp, not the entire chain nor other entries in the log. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: threat- | Version: analysis | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jan 8 09:11: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 1805D1B2A78 for ; Fri, 8 Jan 2016 09:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 afde5-RETL8h for ; Fri, 8 Jan 2016 09:11:24 -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 CCA051B2A74 for ; Fri, 8 Jan 2016 09:11:16 -0800 (PST) Received: from localhost ([::1]:44323 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aHaZI-0002px-8G; Fri, 08 Jan 2016 09:11: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-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Fri, 08 Jan 2016 17:11:15 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/152 Message-ID: <057.e6a9d1f924e8f658292ddf2fa9759daa@tools.ietf.org> X-Trac-Ticket-ID: 152 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: <20160108171116.CCA051B2A74@ietfa.amsl.com> Resent-Date: Fri, 8 Jan 2016 09:11:16 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [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: Fri, 08 Jan 2016 17:11:27 -0000 #152: Architecture document: CT-aware TLS clients may require SCTs for all certs (Towards the end of Page 14) Concludes that because real-time inclusion proof requests are infeasible, TLS clients are not expected to reject a certificate that has no associated SCTs. I find that conclusion surprising. I would expect the conclusion to be that TLS clients are not expected to fetch an inclusion proof in real-time during SSL connection establishment. As I understand it, it is CT's end-goal that at least some TLS clients would require presence of SCTs for all certificates. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: client- | Version: behavior | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jan 8 09:15: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 4A1311B2A8E for ; Fri, 8 Jan 2016 09:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 V17w0hLo1n-Q for ; Fri, 8 Jan 2016 09:15:22 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 C6C2B1B2A5D for ; Fri, 8 Jan 2016 09:15:21 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id a85so291499992ykb.1 for ; Fri, 08 Jan 2016 09:15:21 -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=IjaJ8Tga2LyvQuxBG2OvvxqVmW1+Yf9jlI7GFqsAhk4=; b=AscEUNyc0mYy7XVQtyDo/X6QM+k1YEnbdGY6sUQCgmgO+EmrOD7ZcJTo0Y6oKBqhTK jgGbvPFtiao/Lv+f5HHA0yU5jhczBg03VxK2kfTWHlzRzflz8plGSCOWk3Okr8wbCjZ+ FzEAqJgS1MvWzzmONebfAU3AaGJ6ro3MxNgaUvIefNCzGxi3T645mn+koqaOW03Fz8GA 6MauX77HG/NbJQHvnRENK0QSdMKLLwOdLU/46TAM/Z27A7pgtQy0pVcKBPa3C/B3+O4j iD6qjtGAanVpO67M4DL+I+5Ejs8gN3IrCli4+7MHKgr87BAG5w43ezf2Pb2C/JcKo9EQ aHkQ== 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=IjaJ8Tga2LyvQuxBG2OvvxqVmW1+Yf9jlI7GFqsAhk4=; b=WHTMVhfht6bRP1f+OLY48v97jR1Fm+soV4IstrQ5Uu4B5CrN5YHfGZe115NNc71CMW 9BTXcXHR42CIaJfVn2xqy+hGCXXLYzTzc04H9ha/5xraW83eguhlJKmz4TovlrYeNUcK gGgFIuWo+mPcT1KvFLIVMOjF6XnmTY1/HSnn/WAkq16XwyUpQXxGepYbpfkIniGqiqOh kKqddV44YC83LCqEC2jgqxn8vTWPZZjlB2WQs6IQT3p7ggOBaNamWTuByUYYmLKwllyv fbhsF+xBIDhaXx16Xha1B1owE2vvSFGy3Tfs50TFtBgeVJkyvAcf8UhcuCz8Q0Aq3iKb DFgQ== X-Gm-Message-State: ALoCoQncFUUGTiWjnbuhuNjwdHMFdhHTdDJwbLNr4eh6/kxlgOmURE33xBhnzI04fwb9P7WJaB6lG4P5YJtKBMAQ+WJWA8fW7vKVrNzpjLzCPQNhFyMXZU4= MIME-Version: 1.0 X-Received: by 10.129.85.88 with SMTP id j85mr84350326ywb.194.1452273321091; Fri, 08 Jan 2016 09:15:21 -0800 (PST) Received: by 10.37.210.71 with HTTP; Fri, 8 Jan 2016 09:15:21 -0800 (PST) Date: Fri, 8 Jan 2016 09:15:21 -0800 Message-ID: From: Eran Messeri To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113f27e66c00020528d5bb90 Archived-At: Subject: [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: Fri, 08 Jan 2016 17:15:24 -0000 --001a113f27e66c00020528d5bb90 Content-Type: text/plain; charset=UTF-8 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. 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. 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. - Suggesting to drop the "Browser Vendor" component as it's arguably redundant - a browser vendor would care about the output of the auditor. - 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.". 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. 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. 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). 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. Regarding the TBD parts (Monitor-auditor, CA-subject, browser-vendor), what prevents writing them? Shall I have a go at contributing text? Again thanks for putting this document together, it's very thorough. Eran --001a113f27e66c00020528d5bb90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Overall the relationships between the different entit= ies that participate in CT are well described in this document. The diagram= s 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.

Most comments I have are nitpicks - I rea= lize there's a trade-off between accuracy and conciseness and tried onl= y pointing out where (I think) it's significant.

Issues filed:
Ticket #148 - Architecture document: Spelling/im= provements to Introduction
Ticket #149 - Architecture documen= t: Figure 1: Finer-grained distinction between entities
Ticket #1= 50 -=C2=A0Architecture document: Indicate missing SCT is equivalent to inva= lid 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.

Other comments and suggestions:

On section 3, T= he elements of CT architecture:
Figure 2:
- Browsers al= so need to get fresh STHs and consistency proofs between STHs to use the ou= tput of get-proof-by-hash.
- Suggesting to drop the "Browser= Vendor" component as it's arguably redundant - a browser vendor w= ould care about the output of the auditor.
- Suggest adding a foo= tnote that "An auditor can actively verify MMD compliance by submittin= g new entries to the log and checking when they're appended to the tree= .".

Figure 3:
- Nitpick, but subjec= ts may request revocation from CAs - Is it more common for browsers to acce= pt revocation requests from subjects or base their blacklists on CRLs issue= d by CAs? if the latter, than the figure may be less surprising if that'= ;s the path stated there.

Figure 4, repeating late= r in section 3.3 Monitors:
- The acceptable public keys may be op= tional - a monitor may simply notify a Subject of each new certificate it o= bserves. 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.

3.5. CT-aware TLS clients:
- One paragraphe before the end, mentioning feedback to log operato= rs via subjects - suggest adding an explicit reference to the section in th= e Gossip draft that describes this reporting mechanism (or at least explici= tly state the Gossip document describes such a mechanism).

3.6. Auditors:
- For MMD monitoring, I suggest indicatin= g that an auditor can check MMD actively by submitting new entries to the l= og (either by issuing them or by gathering them from the internet and feedi= ng them to the log). That's what Google's monitor does, for example= .

Regarding the TBD parts =C2=A0(Monitor-auditor, = CA-subject, browser-vendor), what prevents writing them? Shall I have a go = at contributing text?

Again thanks for putting thi= s document together, it's very thorough.

Eran<= /div>
--001a113f27e66c00020528d5bb90-- From nobody Fri Jan 8 10:28: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 D9C6D1B2AD8 for ; Fri, 8 Jan 2016 10:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ef_Ly4YHP02Z for ; Fri, 8 Jan 2016 10:28:47 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67DA1B2AD7 for ; Fri, 8 Jan 2016 10:28:46 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id h5so39749650igh.0 for ; Fri, 08 Jan 2016 10:28:46 -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=khDnJlBrQ7xtbNBdHbzFKmJLZPSGL0PiVMDg7lqPh4Q=; b=il7TicQXZKM2FP08PATAiVaF3AI9jYzg20gLeUogTt3IlFzIGjJO9XJquI+L4LW/gG 1NebemeY81bspE9Kh8T16TudcYkyiGolbI3YrG3xEY7UlginK3wigmPbBJZ+9GBr0oUo bmwoGIiRToRX9e2sJ3RvB/ChEqQogj7kVaFhm3Ca8L0jsnS4GpagKJsbHBA/YQ89Xspf oEzpB+XbF9T6D1vXCzhv8AetD/G6K7O0Tmwv46ti3YB6pHIjY2RMZjMRXetcaE6OBKwC E2d2PMi7DdLjJbt2yl+ZdahbAtfsL87ppkPiyJAe8//vQCrKhTC+aQun5TCZ+NqR5fE1 S+fw== 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=khDnJlBrQ7xtbNBdHbzFKmJLZPSGL0PiVMDg7lqPh4Q=; b=kLqSjimNcTqwSpPReeNA2oJnU4+XaVb+YWSzVwef/fzqsl+BJDwIZSPWAQXPKuFOzd TNVYoL/eFNyvpDESXEKGbDcrlJ3flhoyWv+d4Bh+rkTdbFF4c86jc+FY4MOYciQYh4Sr uiccrNW5cAOPGYr54ep4oFkr2PhXyOb+sTNqzTILinfNMmrt8/Uv2hr3fLFG9cun1wqa EvFQAcp99XCxT/S8kgJFy++tOBlFg2pue0XxzM0rFZNVTUmpg3T9l9QwMx/Zs9BFDHC+ 7r9Lvj5FVYPgEQh0YbtofoOuCbV28Fc4k8Q+c2J/eyv6uiOilCaTaSdcsz/oPWA9bsIh h0Iw== X-Gm-Message-State: ALoCoQnYW3Er8m8eP2/cUkHMZYR71pfZ89TBrQt/mLnoOzVwH6P0zX8VaTJaKbEa3APtmJD8S+2Ul876NqXzgN3M6B25Dhzl5F5PSe/PRI18B7AdHXhIaCg= MIME-Version: 1.0 X-Received: by 10.50.62.75 with SMTP id w11mr380064igr.32.1452277725983; Fri, 08 Jan 2016 10:28:45 -0800 (PST) Received: by 10.64.107.135 with HTTP; Fri, 8 Jan 2016 10:28:45 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Jan 2016 10:28:45 -0800 Message-ID: From: Ben Laurie To: Eran Messeri Content-Type: multipart/alternative; boundary=047d7bdc10e4f957e90528d6c1a8 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: Fri, 08 Jan 2016 18:28:48 -0000 --047d7bdc10e4f957e90528d6c1a8 Content-Type: text/plain; charset=UTF-8 On 8 January 2016 at 09:15, Eran Messeri wrote: > 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. > This is why we added get-all-by-hash. --047d7bdc10e4f957e90528d6c1a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 8 January 2016 at 09:15, Eran Messeri <eranm@google.com> wrote:
On secti= on 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.

This is why we added get-all-by-hash.

--047d7bdc10e4f957e90528d6c1a8-- From nobody Mon Jan 11 09:16: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 0FFAD1A8ADE for ; Mon, 11 Jan 2016 09:16:33 -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 rZh9Z3cMiagQ for ; Mon, 11 Jan 2016 09:16:30 -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 041151A8AE7 for ; Mon, 11 Jan 2016 09:16:30 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:34274 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aIg4v-0007B1-CP; Mon, 11 Jan 2016 12:16:25 -0500 To: trans issue tracker , draft-ietf-trans-threat-analysis@tools.ietf.org, eranm@google.com References: <057.14ea9462e1415a11c04a0824f51a2d37@tools.ietf.org> From: Stephen Kent Message-ID: <5693E368.7060308@bbn.com> Date: Mon, 11 Jan 2016 12:16:24 -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: <057.14ea9462e1415a11c04a0824f51a2d37@tools.ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #148 (threat-analysis): Architecture document: Spelling/improvements to Introduction 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, 11 Jan 2016 17:16:33 -0000 Eran, Thanks for reading the architecture doc. I agree with your proposed change and will modify the doc accordingly. Steve > #148: Architecture document: Spelling/improvements to Introduction > > In section 1: > onlogs -> on logs > repeatedlymisbehave -> repeatedly misbehave. > > I also propose changing 'repeatedly misbehave' to 'grossly misbehave' (or > something else to indicate particularly bad misbehaviour). > A log may misbehave multiple times (multiple, minor infractions, e.g. by > missing it's MMD by a bit) but still be used by browsers. On the contrary, > a log may be disqualified after grossly misbehaving once (e.g. by not > including an entry). > From nobody Mon Jan 11 09:31: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 DF7E61A8BBD for ; Mon, 11 Jan 2016 09:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AC_HTML_NONSENSE_TAGS=1, BAYES_20=-0.001, HTML_MESSAGE=0.001, 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 8-BWrr0giOtc for ; Mon, 11 Jan 2016 09:31:39 -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 89FAA1A8BB5 for ; Mon, 11 Jan 2016 09:31:39 -0800 (PST) Received: from dhcp89-089-173.bbn.com ([128.89.89.173]:56262) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aIgJe-0007al-0o for trans@ietf.org; Mon, 11 Jan 2016 12:31:38 -0500 From: Karen Seo To: "trans@ietf.org" References: <567C23EE.1040808@bbn.com> Message-ID: <5693E6F9.2090101@bbn.com> Date: Mon, 11 Jan 2016 12:31:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <567C23EE.1040808@bbn.com> Content-Type: multipart/alternative; boundary="------------020300020509070007050205" Archived-At: Subject: [Trans] proposed CA/Subject changes 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, 11 Jan 2016 17:31:43 -0000 This is a multi-part message in MIME format. --------------020300020509070007050205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Folks, I agree with the approach discussed on the list of simplifying 6962-bis to focus only on specifications for the CT log by moving the detailed specifications for other components of the CT system to other documents. This is in line with a message from Melinda on July 2 re: client behavior, and amessage from Rich Saltz on July 6 re: the Auditor function. To facilitate moving requirements for the CA/Subject part of the system, I propose that we make the changes below with regard to statements about CT requirements for CA and Subject behavior. These changes will also help to address some of the concerns that have been cited elsewhere aboutthe text of 6962-bis (e.g., issues 139, 140, 144). Karen *_Changes to 6962-bis_* _/**/_/*Section 3. Submitters*/ *_From: _*Submitters submit certificates or pre-certificates to logs for public auditing, as described below. In order to enable attribution of each logged certificate or pre-certificate to its issuer, each submission MUST be accompanied by all additional certificates required to verify the chain up to an accepted root certificate. The root certificate itself MAY be omitted from the submission. If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the returned SCT as described in Section 9.2 if they understand its format and they intend to use it directly in a TLS handshake or to construct a certificate. *_To:_* A Submitter sends a certificate or pre-certificate (see Section 3.1 below) to one or more logs. This enables public monitoring of certificates to facilitate detection of certificate mis-issuance. If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT) (see Section 5.6). This document specifies the interface to a log that a Submitter uses to log a certificate or pre-certificate (see Section 3). A detailed specification of how a Submitter should choose to submit a certificate vs. a pre-certificate and how it should process the SCT that is returned, will be described in a separate specification to be published later. /*Sections 3.1 and 3.2*/ *_From:_* 3.1. Certificates Anyone can submit a certificate (Section 6.1) to a log. Since certificates may not be accepted by TLS clients unless logged, it is expected that certificate owners or their CAs will usually submit them. 3.2. Precertificates Alternatively, (root as well as intermediate) CAs may pre-announce a certificate prior to issuance by submitting a pre-certificate (Section 6.2) that the log can use to create an entry that will be valid against the issued certificate. The CA MAY incorporate the returned SCT in the issued certificate. *_To: _* 3.1 Certificates and Pre-certificates Anyone can submit a certificate to a log (see Section 6.1). It is expected that certificate owners (Subjects) or their CAs will usually submit certificates. Alternatively, (root as well as intermediate) CAs may log a certificate prior to issuance by submitting a pre-certificate. The log will use this to create an entry and return an SCT that can be used to verify that the issued certificate was logged (see Section 6.2). The CA may incorporate the returned SCT in the issued certificate. /[The rest of 3.2 defines both what the log should accept for a pre-certificate and what the CA must do. So it should remain here but also be duplicated in a requirements document for CAs. ]/** /*Section 4 Private Domain Names*/ /**/ _*From: *_ Some regard some DNS domain name labels within their registered domain space as private and security sensitive. Even though these domains are often only accessible within the domain owner's private network, it's common for them to be secured using publicly trusted TLS server certificates. We define a mechanism to allow these private labels to not appear in public logs. _*To: *_ Some organizations regard some of the DNS domain name labels within their registered domain space as private and security sensitive. Even though these domains are often only accessible within the domain owner's private network, it's common for them to be secured using publicly trusted TLS server certificates. A detailed description of mechanisms that a CA could use to support this will be described in a separate specification to be published later. /*Sections 4.1 Wildcard Certificates, 4.2 */***/Redacting Domain Name Labels in Precertificates, and /*/*4.3 Using a Name-Constrained Intermediate CA*/** ** /[The text in these sections applies only to CAs and should be moved to a requirements specification for CAs]/ ***/Possible new section/* ** If the log checks the syntax of a pre-certificate, then that should be described in a new section called something like "Checking Certificate Syntax ." Any syntax checking done by the CA should be put in a requirememts specificatio/n/ for CAs. /*Section 7 TLS Servers*/ /**/ *_From:_* TLS servers MUST use at least one of the three mechanisms listed below to present one or more SCTs or inclusion proofs from one or more logs to each TLS client during TLS handshakes, where each SCT or inclusion proof corresponds to the server certificate or to a name- constrained intermediate the server certificate chains to. Three mechanisms are provided because they have different tradeoffs. *_To:_* A CT-aware TLS server (certificate Subject) can present one or more SCTs or inclusion proofs from one or more logs to each TLS client during a TLS handshake. (A TLS server is considered to be CT-aware if it is configured to send certificates with embedded SCTs or inclusion proofs during a TLS handshake, or to convey SCTs separately during the handshake.) Each SCT or inclusion proof corresponds to the server certificate or to a name-constrained intermediate CA certificate to which the server certificate chains. The mechanisms by which the TLS server presents the SCTs or inclusion proofs to a TLS client will be described in a TLS server requirements specification that will be published later. /[The rest of 7 and all of 7.1 should be moved to the//above mentioned TLS server requirements specification.//]/ /*Section 8 (Certification Authorities), 8.1. (Transparency Information X.509v3 Extension), 8.1.1. OCSP Response Extension, 8.1.2. Certificate Extension*/** /[These sections defines only CA actions/behavior. They should be moved to a requirements specification for CAs./*] * /*Section 12.3 (Redaction of Public Domain Name Labels*/ /[This subsection applies only to CAs. It //should be moved to a requirements specification for CAs.]//* */ /**//**//*Section 12.5 Multiple SCTs*/ /**/ /[This//subsection applies only to CAs and clients. The text should be moved to a requirements specification for CAs and a specification for browsers.]/********************** --------------020300020509070007050205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

I agree with the approach discussed on the list of simplifying 6962-bis to focus only on specifications for the CT log by moving the detailed specifications for other components of the CT system to other documents. This is in line with a message from Melinda on July 2 re: client behavior, and a message from Rich Saltz on July 6 re: the Auditor function. To facilitate moving requirements for the CA/Subject part of the system, I propose that we make the changes below with regard to statements about CT requirements for CA and Subject behavior.  These changes will also help to address some of the concerns that have been cited elsewhere about the text of 6962-bis (e.g., issues 139, 140, 144).
 
Karen

Changes to 6962-bis

Section 3. Submitters
From: Submitters submit certificates or pre-certificates to logs for public auditing, as described below. In order to enable attribution of each logged certificate or pre-certificate to its issuer, each submission MUST be accompanied by all additional certificates required to verify the chain up to an accepted root certificate. The root certificate itself MAY be omitted from the submission.
If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the returned SCT as described in Section 9.2 if they understand its format and they intend to use it directly in a TLS handshake or to construct a certificate.

To:
A Submitter sends a certificate or pre-certificate (see Section 3.1 below) to one or more logs. This enables public monitoring of certificates to facilitate detection of certificate mis-issuance. If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT) (see Section 5.6). This document specifies the interface to a log that a Submitter uses to log a certificate or pre-certificate (see Section 3). A detailed specification of how a Submitter should choose to submit a certificate vs. a pre-certificate and how it should process the SCT that is returned, will be described in a separate specification to be published later. 
Sections 3.1 and 3.2
From:
3.1. Certificates
Anyone can submit a certificate (Section 6.1) to a log. Since certificates may not be accepted by TLS clients unless logged, it is expected that certificate owners or their CAs will usually submit them.
 
3.2. Precertificates
Alternatively, (root as well as intermediate) CAs may pre-announce a certificate prior to issuance by submitting a pre-certificate (Section 6.2) that the log can use to create an entry that will be valid against the issued certificate. The CA MAY incorporate the returned SCT in the issued certificate.

To:
3.1 Certificates and Pre-certificates
Anyone can submit a certificate to a log (see Section 6.1). It is expected that certificate owners (Subjects) or their CAs will usually submit certificates. Alternatively, (root as well as intermediate) CAs may log a certificate prior to issuance by submitting a pre-certificate.  The log will use this to create an entry and return an SCT that can be used to verify that the issued certificate was logged (see Section 6.2).  The CA may incorporate the returned SCT in the issued certificate.
[The rest of 3.2 defines both what the log should accept for a pre-certificate and what the CA must do. So it should remain here but also be duplicated in a requirements document for CAs. ]
Section 4 Private Domain Names
From:
Some regard some DNS domain name labels within their registered domain space as private and security sensitive. Even though these domains are often only accessible within the domain owner's private network, it's common for them to be secured using publicly trusted TLS server certificates. We define a mechanism to allow these private labels to not appear in public logs.

To:
Some organizations regard some of the DNS domain name labels within their registered domain space as private and security sensitive. Even though these domains are often only accessible within the domain owner's private network, it's common for them to be secured using publicly trusted TLS server certificates.  A detailed description of mechanisms that a CA could use to support this will be described in a separate specification to be published later.
Sections 4.1 Wildcard Certificates, 4.2 Redacting Domain Name Labels in Precertificates, and 4.3 Using a Name-Constrained Intermediate CA
[The text in these sections applies only to CAs and should be moved to a requirements specification for CAs]
Possible new section
If the log checks the syntax of a pre-certificate, then that should be described in a new section called something like  "Checking Certificate Syntax ."  Any syntax checking done by the CA should be put in a requirememts specification for CAs.
Section 7 TLS Servers
From:
TLS servers MUST use at least one of the three mechanisms listed below to present one or more SCTs or inclusion proofs from one or more logs to each TLS client during TLS handshakes, where each SCT or inclusion proof corresponds to the server certificate or to a name- constrained intermediate the server certificate chains to. Three mechanisms are provided because they have different tradeoffs.
To:
A CT-aware TLS server (certificate Subject) can present one or more SCTs or inclusion proofs from one or more logs to each TLS client during a TLS handshake. (A TLS server is considered to be CT-aware if it is configured to send certificates with embedded SCTs or inclusion proofs during a TLS handshake, or to convey SCTs separately during the handshake.) Each SCT or inclusion proof corresponds to the server certificate or to a name-constrained intermediate CA certificate to which the server certificate chains. The mechanisms by which the TLS server presents the SCTs or inclusion proofs to a TLS client will be described in a TLS server requirements specification that will be published later.

[The rest of 7 and all of 7.1 should be moved to the above mentioned TLS server requirements specification.]
Section 8 (Certification Authorities), 8.1. (Transparency Information X.509v3 Extension), 8.1.1. OCSP Response Extension, 8.1.2. Certificate Extension
[These sections defines only CA actions/behavior. They should be moved to a requirements specification for CAs.]
Section 12.3 (Redaction of Public Domain Name Labels
[This subsection applies only to CAs.  It should be moved to a requirements specification for CAs.]
Section 12.5 Multiple SCTs
[This subsection applies only to CAs and clients. The text should be moved to a requirements specification for CAs and a specification for browsers.]




--------------020300020509070007050205-- From nobody Mon Jan 11 09:49: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 7B6111A87A6 for ; Mon, 11 Jan 2016 09:49:22 -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 kYbXL8ROBH_q for ; Mon, 11 Jan 2016 09:49:21 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966861A87AB for ; Mon, 11 Jan 2016 09:49:21 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id a85so361708293ykb.1 for ; Mon, 11 Jan 2016 09:49:21 -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=Awwk6YujeYSV0vr4YyWLPHbyoZcQtoY53o1ZjgAPAh4=; b=LzQGTfWfbRJDhKamzMsn22LoKINxnKCQ5pFJj/uKoXeuUB8ncPfp75//Gy+F3slUtL Df5p2ip5iYvS+5q6lWDR3ZzfOnRoBwap670kiMuE/CIB/SSXC8RUXkspQxH6TLwDb9W6 2TFy5Oa07CqANIbvuqJd04MPZ2eYmnkn/TquQdkkTT9ECk0/XgH5BDR71jdCcNkTdcZ7 HTpJn6Vtv83x9BTC3Uh9h66MNtAVKfZjxGfmBFYPPNVcRgR1IjR73nW4UGgrXbu3bDB8 WNoRQnFlE0QNm0Yvtu0d7teodYJayiCmfp/FBqeC1FVlU50osEJW8Whj1wuRbkZknjCl Coag== 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=Awwk6YujeYSV0vr4YyWLPHbyoZcQtoY53o1ZjgAPAh4=; b=ISmh4EQmX6Fif6kYGRdinramcCKRbamONA33YYhRHufL/2CclzehogfieE9o+uiTis 1qX0nd+D/D3nIrtCGI1vCeWrBep9+P/uP3FmA+IDvZoFN+lDy6fX1jdGKou4UDLLWPHr cuHlto5/GH733EgR4dyZhDJa/DyD1Ph0S2i9a4k8yaA7mumJziV1KfYroZOuURF/Lmw0 ptVImidybPyMwzFKcrMrcFkK8VNFMgiOOhHEe1aHW02oh3avlsg6c3xmKaSmVy0VXLoV YG0T2H5hkZP05egfmnMvLMvdx0arTgsVHYYARPyj0JURhaR3PexeaDkjKlumSb1Z49xS YynA== X-Gm-Message-State: ALoCoQlmTDDyhEg3dkmFz6bGd+FbZw2h+rOoTfh6eVnJEpOX8eCqfJTpJqJnR0Lw0+kUadnfu2Yf4D0L2uKfPbGTCDRzQLRsgS15qborA12CjDTtXBRqHwY= MIME-Version: 1.0 X-Received: by 10.129.72.84 with SMTP id v81mr92947005ywa.101.1452534560796; Mon, 11 Jan 2016 09:49:20 -0800 (PST) Received: by 10.37.210.71 with HTTP; Mon, 11 Jan 2016 09:49:20 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Jan 2016 09:49:20 -0800 Message-ID: From: Eran Messeri To: Ben Laurie Content-Type: multipart/alternative; boundary=001a114db3208575d40529128e9f 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: Mon, 11 Jan 2016 17:49:22 -0000 --001a114db3208575d40529128e9f Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 10:28 AM, Ben Laurie wrote: > > > On 8 January 2016 at 09:15, Eran Messeri wrote: > >> 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. >> > > This is why we added get-all-by-hash. > You're right. If the Architecture document documents RFC6962-bis (rather than the existing RFC6962), it should be changed to mention get-all-by-hash. --001a114db3208575d40529128e9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 8, 2016 at 10:28 AM, Ben Laurie <benl@google.com> wrote:


On 8 Janu= ary 2016 at 09:15, Eran Messeri <eranm@google.com> wrote:
=
On section 3, The elem= ents of CT architecture:
Figure 2:
- Browsers also = need to get fresh STHs and consistency proofs between STHs to use the outpu= t of get-proof-by-hash.

= This is why we added get-all-by-hash.
<= div>You're right.
If the Architecture document documents RFC6= 962-bis (rather than the existing RFC6962), =C2=A0it should be changed to m= ention get-all-by-hash.

--001a114db3208575d40529128e9f-- From nobody Mon Jan 11 11:03: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 692141A9054 for ; Mon, 11 Jan 2016 11:03:07 -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 H9I14-l011eK for ; Mon, 11 Jan 2016 11:03:05 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 253C81A9055 for ; Mon, 11 Jan 2016 11:03:05 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id e65so49045150pfe.0 for ; Mon, 11 Jan 2016 11:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=gX4L1sILNAVLENd7ju8r0D3Wk0V3QXG/o6k+G9sDgb0=; b=Su+1ikXXVXrPby47qbKQlEVNMyLlLbQh4Xp/F85c1icMgy0PMhMsmnn6zsCASCGfwB H0eI798/+mWCT7Y0wYRg2qAnNsx6tLEy0xZjLUjVaIlMu57Jx/6RuogqtD8wvbv/vKiO RV+UJkuS9RyElttJqFFzycoDVZSbcU3K5RxcYg/0KJXigp9GlMoSdZeEjidfloS1v5lo bbWxSQcenW1dJnGLw91hqTGcJMdgM9StATPzOuh/aN8ii/OzvKrbq51dR3UpY8b6tuzE jyyvYeHyddQfGAL4rH4MXAkS9u8Xe2oHJ+9lQMByaG6LJfonh+5I5HQYOI7sKQ+NqO76 pwhg== X-Received: by 10.98.42.83 with SMTP id q80mr3221256pfq.1.1452538984637; Mon, 11 Jan 2016 11:03:04 -0800 (PST) Received: from Melindas-MacBook-Pro.local (216-67-51-21-radius.dynamic.acsalaska.net. [216.67.51.21]) by smtp.googlemail.com with ESMTPSA id f27sm24956519pfj.0.2016.01.11.11.03.02 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jan 2016 11:03:03 -0800 (PST) To: trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> From: Melinda Shore Message-ID: <5693FC01.3020501@gmail.com> Date: Mon, 11 Jan 2016 10:01:21 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5693E6F9.2090101@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] proposed CA/Subject changes 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, 11 Jan 2016 19:03:07 -0000 We'd be very grateful for some discussion of this so that we can close it (one way or the other) and move forward. Thanks, Melinda On 1/11/16 8:31 AM, Karen Seo wrote: > Folks, > > I agree with the approach discussed on the list of simplifying 6962-bis > to focus only on specifications for the CT log by moving the detailed > specifications for other components of the CT system to other documents. > This is in line with a message from Melinda on July 2 re: client > behavior, and amessage from Rich Saltz on July 6 re: the Auditor > function. To facilitate moving requirements for the CA/Subject part of > the system, I propose that we make the changes below with regard to > statements about CT requirements for CA and Subject behavior. These > changes will also help to address some of the concerns that have been > cited elsewhere aboutthe text of 6962-bis (e.g., issues 139, 140, 144). > > Karen > > *_Changes to 6962-bis_* > > _/**/_/*Section 3. Submitters*/ > > *_From: _*Submitters submit certificates or pre-certificates to logs > for public auditing, as described below. In order to enable > attribution of each logged certificate or pre-certificate to its > issuer, each submission MUST be accompanied by all additional > certificates required to verify the chain up to an accepted root > certificate. The root certificate itself MAY be omitted from the > submission. > > If a log accepts a submission, it will return a Signed Certificate > Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the > returned SCT as described in Section 9.2 if they understand its > format and they intend to use it directly in a TLS handshake or to > construct a certificate. > > *_To:_* > A Submitter sends a certificate or pre-certificate (see Section 3.1 > below) to one or more logs. This enables public monitoring of > certificates to facilitate detection of certificate mis-issuance. If > a log accepts a submission, it will return a Signed Certificate > Timestamp (SCT) (see Section 5.6). This document specifies the > interface to a log that a Submitter uses to log a certificate or > pre-certificate (see Section 3). A detailed specification of how a > Submitter should choose to submit a certificate vs. a > pre-certificate and how it should process the SCT that is returned, > will be described in a separate specification to be published later. > > /*Sections 3.1 and 3.2*/ > > *_From:_* > 3.1. Certificates > Anyone can submit a certificate (Section 6.1) to a log. Since > certificates may not be accepted by TLS clients unless logged, it is > expected that certificate owners or their CAs will usually submit them. > > 3.2. Precertificates > Alternatively, (root as well as intermediate) CAs may pre-announce a > certificate prior to issuance by submitting a pre-certificate > (Section 6.2) that the log can use to create an entry that will be > valid against the issued certificate. The CA MAY incorporate the > returned SCT in the issued certificate. > > *_To: _* > 3.1 Certificates and Pre-certificates > Anyone can submit a certificate to a log (see Section 6.1). It is > expected that certificate owners (Subjects) or their CAs will > usually submit certificates. Alternatively, (root as well as > intermediate) CAs may log a certificate prior to issuance by > submitting a pre-certificate. The log will use this to create an > entry and return an SCT that can be used to verify that the issued > certificate was logged (see Section 6.2). The CA may incorporate the > returned SCT in the issued certificate. > > /[The rest of 3.2 defines both what the log should accept for a > pre-certificate and what the CA must do. So it should remain here > but also be duplicated in a requirements document for CAs. ]/** > > /*Section 4 Private Domain Names*/ > /**/ > > _*From: *_ > Some regard some DNS domain name labels within their registered > domain space as private and security sensitive. Even though these > domains are often only accessible within the domain owner's private > network, it's common for them to be secured using publicly trusted > TLS server certificates. We define a mechanism to allow these > private labels to not appear in public logs. > > _*To: *_ > Some organizations regard some of the DNS domain name labels within > their registered domain space as private and security sensitive. > Even though these domains are often only accessible within the > domain owner's private network, it's common for them to be secured > using publicly trusted TLS server certificates. A detailed > description of mechanisms that a CA could use to support this will > be described in a separate specification to be published later. > > /*Sections 4.1 Wildcard Certificates, 4.2 */***/Redacting Domain Name > Labels in Precertificates, and /*/*4.3 Using a Name-Constrained > Intermediate CA*/** > ** > > /[The text in these sections applies only to CAs and should be moved > to a requirements specification for CAs]/ > > ***/Possible new section/* > ** > > If the log checks the syntax of a pre-certificate, then that should > be described in a new section called something like "Checking > Certificate Syntax ." Any syntax checking done by the CA should be > put in a requirememts specificatio/n/ for CAs. > > /*Section 7 TLS Servers*/ > /**/ > > *_From:_* > TLS servers MUST use at least one of the three mechanisms listed > below to present one or more SCTs or inclusion proofs from one or > more logs to each TLS client during TLS handshakes, where each SCT > or inclusion proof corresponds to the server certificate or to a > name- constrained intermediate the server certificate chains to. > Three mechanisms are provided because they have different tradeoffs. > > *_To:_* > A CT-aware TLS server (certificate Subject) can present one or more > SCTs or inclusion proofs from one or more logs to each TLS client > during a TLS handshake. (A TLS server is considered to be CT-aware > if it is configured to send certificates with embedded SCTs or > inclusion proofs during a TLS handshake, or to convey SCTs > separately during the handshake.) Each SCT or inclusion proof > corresponds to the server certificate or to a name-constrained > intermediate CA certificate to which the server certificate chains. > The mechanisms by which the TLS server presents the SCTs or > inclusion proofs to a TLS client will be described in a TLS server > requirements specification that will be published later. > > /[The rest of 7 and all of 7.1 should be moved to the//above > mentioned TLS server requirements specification.//]/ > > /*Section 8 (Certification Authorities), 8.1. (Transparency Information > X.509v3 Extension), 8.1.1. OCSP Response Extension, 8.1.2. Certificate > Extension*/** > > /[These sections defines only CA actions/behavior. They should be > moved to a requirements specification for CAs./*] > * > > /*Section 12.3 (Redaction of Public Domain Name Labels*/ > > /[This subsection applies only to CAs. It //should be moved to a > requirements specification for CAs.]//* > */ > > /**//**//*Section 12.5 Multiple SCTs*/ > /**/ > > /[This//subsection applies only to CAs and clients. The text should > be moved to a requirements specification for CAs and a specification > for browsers.]/********************** > > > > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Mon Jan 11 11:15: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 95C711A905F for ; Mon, 11 Jan 2016 11:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.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 B1zYp-MEwYPq for ; Mon, 11 Jan 2016 11:14:57 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0452F1A905E for ; Mon, 11 Jan 2016 11:14:56 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 406D34237EB; Mon, 11 Jan 2016 19:14:56 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 28CCC42372C; Mon, 11 Jan 2016 19:14:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452539696; bh=5vJHhTkE/WGmcwTd1qLq6+pl3qQPmRZXydbzIocLohw=; l=141; h=From:To:Date:References:In-Reply-To:From; b=hw6qfjyG4/JsxbOt9D8mrUTGhjGBt30ycV1QxtZ6aFltzYsv+fXJdgXc9lFm8OTu4 +S51tTkeYIdenuZYcoda/j0voUhSLyVpWHgFMEudwfNB5+NPJoCdgg9L07iXbbxOm5 b1ny+Q3O6t6TQyEjKQGaHZYSoLeimhPAZh6Twqgw= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2679A2027; Mon, 11 Jan 2016 19:14:56 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 11 Jan 2016 14:14:55 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Mon, 11 Jan 2016 14:14:55 -0500 From: "Salz, Rich" To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] proposed CA/Subject changes Thread-Index: AQHRTJX0tsc7VU5NIEW6SHxKktXHbZ72/5CA//+v6uA= Date: Mon, 11 Jan 2016 19:14:54 +0000 Message-ID: References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5693FC01.3020501@gmail.com> In-Reply-To: <5693FC01.3020501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.233] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] proposed CA/Subject changes 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, 11 Jan 2016 19:14:58 -0000 > We'd be very grateful for some discussion of this so that we can close it= (one > way or the other) and move forward. I'm in favor. From nobody Tue Jan 12 09:25:42 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 E0AA21B2BF2; Fri, 8 Jan 2016 13:35:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160108213517.7773.19718.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 13:35:17 -0800 Archived-At: X-Mailman-Approved-At: Tue, 12 Jan 2016 09:25:41 -0800 Cc: trans-chairs@ietf.org, pwouters@redhat.com, trans@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Trans] trans - New Meeting Session Request for IETF 95 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, 08 Jan 2016 21:35:18 -0000 A new meeting session request has just been submitted by Paul Wouters, a Chair of the trans working group. --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Paul Wouters Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: dane curdle dnsop tls Second Priority: ipsecme saag Special Requests: --------------------------------------------------------- From nobody Tue Jan 12 11:06: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 EFDC31A8032 for ; Tue, 12 Jan 2016 11:06: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=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 cumbZz8HUlGR for ; Tue, 12 Jan 2016 11:06: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 CF56E1A8025 for ; Tue, 12 Jan 2016 11:06:39 -0800 (PST) Received: from localhost ([::1]:34716 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aJ4H9-0002Ub-0f; Tue, 12 Jan 2016 11:06: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-threat-analysis@tools.ietf.org, kent@bbn.com X-Trac-Project: trans Date: Tue, 12 Jan 2016 19:06:38 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/148#comment:1 Message-ID: <072.9e3836e407bab58a18ac7da1655cb689@tools.ietf.org> References: <057.14ea9462e1415a11c04a0824f51a2d37@tools.ietf.org> X-Trac-Ticket-ID: 148 In-Reply-To: <057.14ea9462e1415a11c04a0824f51a2d37@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, 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: <20160112190639.CF56E1A8025@ietfa.amsl.com> Resent-Date: Tue, 12 Jan 2016 11:06:39 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #148 (threat-analysis): Architecture document: Spelling/improvements to 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, 12 Jan 2016 19:06:41 -0000 #148: Architecture document: Spelling/improvements to Introduction Comment (by kent@bbn.com): I have revised the text to be: In turn, the Monitors and Browser Vendors are expected to cease relying on logs that repeatedly misbehave in a fashion indicative of malice. (Ultimately, what constitutes malicious misbehavior will be determined by Monitors and Browser Vendors, and thus is outside the scope of this 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 Tue Jan 12 11:09:33 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 BBC661A8028 for ; Tue, 12 Jan 2016 11:09: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=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 aRC4qGtDNQua for ; Tue, 12 Jan 2016 11:09:30 -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 7FDA41A7D81 for ; Tue, 12 Jan 2016 11:09:30 -0800 (PST) Received: from localhost ([::1]:34764 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aJ4Ju-0002kU-8k; Tue, 12 Jan 2016 11:09: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: draft-ietf-trans-threat-analysis@tools.ietf.org, kent@bbn.com X-Trac-Project: trans Date: Tue, 12 Jan 2016 19:09:30 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/149#comment:1 Message-ID: <072.214a37bdda8cb1863f298fa2f47d646d@tools.ietf.org> References: <057.78037b3cf94497f431f6adbc1f7cb594@tools.ietf.org> X-Trac-Ticket-ID: 149 In-Reply-To: <057.78037b3cf94497f431f6adbc1f7cb594@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, 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: <20160112190930.7FDA41A7D81@ietfa.amsl.com> Resent-Date: Tue, 12 Jan 2016 11:09:30 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #149 (threat-analysis): Architecture document: Figure 1: Finer-grained distinction between entities 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, 12 Jan 2016 19:09:31 -0000 #149: Architecture document: Figure 1: Finer-grained distinction between entities Comment (by kent@bbn.com): We will make a finer-grained distinction in this diagram, i.e., defined by CT requirements specs, vs. the Gossip experimental spec, vs. completely out of scope. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: threat- | Version: analysis | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 12 11:15: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 B783C1A7D82 for ; Tue, 12 Jan 2016 11:15: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 YMUhpnVZcDjV for ; Tue, 12 Jan 2016 11:15: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 2D6471A870F for ; Tue, 12 Jan 2016 11:15:02 -0800 (PST) Received: from localhost ([::1]:34881 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aJ4PF-0003tS-Ge; Tue, 12 Jan 2016 11:15: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-threat-analysis@tools.ietf.org, kent@bbn.com X-Trac-Project: trans Date: Tue, 12 Jan 2016 19:15:01 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/150#comment:1 Message-ID: <072.44278665fae32e230b86498cd0670f3f@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, 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: <20160112191502.2D6471A870F@ietfa.amsl.com> Resent-Date: Tue, 12 Jan 2016 11:15:02 -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: Tue, 12 Jan 2016 19:15:03 -0000 #150: Architecture document: Indicate missing SCT is equivalent to invalid one Comment (by kent@bbn.com): I don't think it appropriate to treat missing and invalid SCTs as equivalent. An invalid SCT violates the spec for SCT syntax or has a bad signature, and thus is a justification for rejecting a cert. We do not have a proposal for how to be backwards compatible and yet mandate SCTs for all web server sites, so we ought not treat a missing SCT as equivalent. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- eranm@google.com | analysis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: threat- | Version: analysis | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 12 11:17: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 CA9151A8712 for ; Tue, 12 Jan 2016 11:17: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=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 sJwPiyIy_eaX for ; Tue, 12 Jan 2016 11:17: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 A1FFE1A870F for ; Tue, 12 Jan 2016 11:17:40 -0800 (PST) Received: from localhost ([::1]:34969 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aJ4Ro-0003dA-3z; Tue, 12 Jan 2016 11:17: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: draft-ietf-trans-threat-analysis@tools.ietf.org, kent@bbn.com X-Trac-Project: trans Date: Tue, 12 Jan 2016 19:17:40 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/151#comment:1 Message-ID: <072.cba0ccd1040b8aeb7cf26e2c8b556126@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, 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: <20160112191740.A1FFE1A870F@ietfa.amsl.com> Resent-Date: Tue, 12 Jan 2016 11:17:40 -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: Tue, 12 Jan 2016 19:17:43 -0000 #151: Architecture document: Only the leaf cert + timestamp are in the SCT Comment (by kent@bbn.com): Proposed text change: The log creates an entry for the terminal certificate in the chain, and returns this Signed Certificate Timestamp (SCT) to the submitter. -- -------------------------+------------------------------------------------- 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 Tue Jan 12 11:27: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 A11371A8738 for ; Tue, 12 Jan 2016 11:27: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=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 iF-5jK_ao355 for ; Tue, 12 Jan 2016 11:27:52 -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 F28761A874E for ; Tue, 12 Jan 2016 11:27:51 -0800 (PST) Received: from localhost ([::1]:35511 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aJ4bf-0003YU-HE; Tue, 12 Jan 2016 11:27: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: draft-ietf-trans-rfc6962-bis@tools.ietf.org, kent@bbn.com X-Trac-Project: trans Date: Tue, 12 Jan 2016 19:27:51 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/152#comment:1 Message-ID: <072.d28a99625e8bf50b415c83e2bfc85747@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, 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: <20160112192751.F28761A874E@ietfa.amsl.com> Resent-Date: Tue, 12 Jan 2016 11:27:51 -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: Tue, 12 Jan 2016 19:27:53 -0000 #152: Architecture document: CT-aware TLS clients may require SCTs for all certs Comment (by kent@bbn.com): The architecture document is not written in the future optimistic tense ;-). While I agree that there is a goal for every server cert to be accompanied by (or to contain) an SCT, it seems inappropriate fort this document to state that browsers are expected to reject any cert that fails this criteria. I plan to revise the text as follows: Thus CT-aware TLS clients are not expected to fetch an inclusion proof in realtime, e.g., during TLS connection establishment. Such clients also are not expected to reject a certificate that has no associated SCT, because there is no plan for incremental deployment of CT that accommodates such rejection in a backwards compatible fashion. -- -------------------------+------------------------------------------------- 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 Tue Jan 12 11:31: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 C12871A875C for ; Tue, 12 Jan 2016 11:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ZVi0dIKKAc3G for ; Tue, 12 Jan 2016 11:31:44 -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 5996B1A8759 for ; Tue, 12 Jan 2016 11:31:44 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:53787 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aJ4fO-0009zU-OJ; Tue, 12 Jan 2016 14:31:42 -0500 To: Eran Messeri , "trans@ietf.org" From: Stephen Kent Message-ID: <5695549D.7070207@bbn.com> Date: Tue, 12 Jan 2016 14:31:41 -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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] awaiting threat doc editorial comments 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, 12 Jan 2016 19:31:45 -0000 Earn, I have mad changes to the threat analysis doc based on comments from you and from Rich. Your message indicated that you would also provide editorial comments, separately. Please send those as soon as possible so that I can complete revisions and publish a new version of that doc. Thanks, Steve From nobody Tue Jan 12 11:32: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 CE6F41A8758 for ; Tue, 12 Jan 2016 11:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uWPF76U1YDxv for ; Tue, 12 Jan 2016 11:32:44 -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 177CE1A8766 for ; Tue, 12 Jan 2016 11:32:42 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:45385 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aJ4gK-000CVd-UU; Tue, 12 Jan 2016 14:32:41 -0500 To: Eran Messeri , "trans@ietf.org" References: From: Stephen Kent Message-ID: <569554D8.5000002@bbn.com> Date: Tue, 12 Jan 2016 14:32:40 -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="------------020304030101090505020406" Archived-At: 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: Tue, 12 Jan 2016 19:32:46 -0000 This is a multi-part message in MIME format. --------------020304030101090505020406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit yes, the arch doc is focused on the standards track CT design. > > > On Fri, Jan 8, 2016 at 10:28 AM, Ben Laurie > wrote: > > > > On 8 January 2016 at 09:15, Eran Messeri > wrote: > > 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. > > > This is why we added get-all-by-hash. > > You're right. > If the Architecture document documents RFC6962-bis (rather than the > existing RFC6962), it should be changed to mention get-all-by-hash. > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --------------020304030101090505020406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit yes, the arch doc is focused on the standards track CT design.



On Fri, Jan 8, 2016 at 10:28 AM, Ben Laurie <benl@google.com> wrote:


On 8 January 2016 at 09:15, Eran Messeri <eranm@google.com> wrote:
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.
This is why we added get-all-by-hash.
You're right.
If the Architecture document documents RFC6962-bis (rather than the existing RFC6962),  it should be changed to mention get-all-by-hash.



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

--------------020304030101090505020406-- From nobody Wed Jan 13 09:24: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 1D82C1B2F8D for ; Wed, 13 Jan 2016 09:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 BPfQmHGUNnWi for ; Wed, 13 Jan 2016 09:24:49 -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 B808C1B2F8F for ; Wed, 13 Jan 2016 09:24:48 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:34109 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aJPA7-0003ip-6s for trans@ietf.org; Wed, 13 Jan 2016 12:24:47 -0500 From: Stephen Kent To: trans@ietf.org References: Message-ID: <5696885E.1020905@bbn.com> Date: Wed, 13 Jan 2016 12:24:46 -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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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, 13 Jan 2016 17:24:51 -0000 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. > > 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. > > 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 From nobody Thu Jan 14 07:11: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 5FFD61B3556 for ; Thu, 14 Jan 2016 07:11:03 -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 ZraT8_n5Q_ME for ; Thu, 14 Jan 2016 07:11:00 -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 7D21B1B3554 for ; Thu, 14 Jan 2016 07:11:00 -0800 (PST) Received: (qmail 18876 invoked by uid 1004); 14 Jan 2016 15:10:58 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 14 Jan 2016 15:10:58 +0000 Received: (qmail 2069 invoked by uid 1000); 14 Jan 2016 15:10:58 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 14 Jan 2016 15:10:58 +0000 To: Karen Seo , "trans@ietf.org" References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> From: Rob Stradling Message-ID: <5697BA81.4090001@comodo.com> Date: Thu, 14 Jan 2016 15:10:57 +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: <5693E6F9.2090101@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] proposed CA/Subject changes X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:11:03 -0000 On 11/01/16 17:31, Karen Seo wrote: > Folks, > > I agree with the approach discussed on the list of simplifying 6962-bis to focus only on specifications for the CT log by moving the detailed specifications for other components of the CT system to other documents. > /[The rest of 3.2 defines both what the log should accept for a > pre-certificate and what the CA must do. So it should remain here > but also be duplicated in a requirements document for CAs. ]/** I don't see how duplicating text in multiple documents helps the goal of "simplifying". BTW, keeping "the rest of 3.2" would mean keeping section 3.2's reference to section 4.2, but... > /*Sections 4.1 Wildcard Certificates, 4.2 */***/Redacting Domain Name > Labels in Precertificates, and /*/*4.3 Using a Name-Constrained > Intermediate CA*/** > ** > > /[The text in these sections applies only to CAs and should be moved > to a requirements specification for CAs]/ ...you're proposing to move section 4.2 to another document, which would be written later. For -10 of 6962-bis, I spent many hours moving text around so that each component of the CT system has its own section in that document, rather than all of the requirements for all of the components being mixed up. I think that had the effect of "simplifying 6962-bis", and I don't think that any further "simplifying" work is necessary. IMHO, the idea of splitting 6962-bis into a separate doc for each component just seems like unnecessary editorial work. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jan 15 05:27: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 69ADF1B2CDD for ; Fri, 15 Jan 2016 05:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 cLDvW9-FfEnp for ; Fri, 15 Jan 2016 05:27:48 -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 CAC281B2CDC for ; Fri, 15 Jan 2016 05:27:48 -0800 (PST) Received: from [128.89.254.203] (port=52131 helo=Johns-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aK4Pr-000EfX-9R; Fri, 15 Jan 2016 08:27:47 -0500 From: Karen Seo To: Rob Stradling , "trans@ietf.org" References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5697BA81.4090001@comodo.com> Message-ID: <5698F3D2.1090606@bbn.com> Date: Fri, 15 Jan 2016 08:27:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5697BA81.4090001@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] proposed CA/Subject changes 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, 15 Jan 2016 13:27:50 -0000 Hi, Rob, [The rest of 3.2 defines both what the log should accept for a >> pre-certificate and what the CA must do. So it should remain here >> but also be duplicated in a requirements document for CAs. ]/** > > I don't see how duplicating text in multiple documents helps the goal > of "simplifying". This is the one place where I felt the text pertained to both the log and the CA. How about if we put the text in the CA document and put a pointer in 6962-bis to the CA document? > BTW, keeping "the rest of 3.2" would mean keeping section 3.2's > reference to section 4.2, but... Good point. The above would address this. > For -10 of 6962-bis, I spent many hours moving text around so that > each component of the CT system has its own section in that document, > rather than all of the requirements for all of the components being > mixed up. I think that had the effect of "simplifying 6962-bis", and I > don't think that any further "simplifying" work is necessary. I appreciate the effort you've made to separate the text by component. It does clarify the specification and makes it easier to comprehend. It also makes splitting out the text for each component pretty straightforward. > IMHO, the idea of splitting 6962-bis into a separate doc for each > component just seems like unnecessary editorial work. There are a number of issues (for the non-log components) that WG members have asked be addressed that the existing 6962-bis text doesn't cover. To address these issues we could add text to 6962-bis; but that would make a 40+ page document much longer and add to the time it's going to take to get 6962-bis out the door. The individual IDs submitted so far for the non-log components (CA/Subject , Browser , Monitors/Auditors) attempt to cover these issues and average about 10 pages each, for a total of 30 pages, so far, that would need to be added to 6962-bis (assuming that the WG approved the text or something similar.) Karen From nobody Fri Jan 15 11:58: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 183351B31E8 for ; Fri, 15 Jan 2016 11:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 b7dIkHMpcWmD for ; Fri, 15 Jan 2016 11:58:50 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9ECB1B31E6 for ; Fri, 15 Jan 2016 11:58:50 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id 65so122483306pff.2 for ; Fri, 15 Jan 2016 11:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=uo1BlE6Dm8bwvTVm9KMMhjzoRFYMdk2ZX7vO1voLbNI=; b=Na2WznAqxDM9610XV8Qt1vIRPKhvPiw3Jd8uu2IiJwHObqfnVVkiLAIBFEpbq5CrsQ qkfLsDbPW99FD/Ed+5DZhmpCxqp4pSgpRhpGR+/ZS713J4P4FnD37XsVMwAwHsuQhtv1 ckL+IXNmyP9qg9QtBs9I1eViwtxRW0bv4R8gb8PN89gXSQYLfSLwtZOOCTWR9jzSmYG5 4Kt4PCsBmYiRA96yoWqKIm+pzINnhebg7adpBZYc8XXZznxuRN8aff6t23pfmBHrnKyT 5R19QVu5vpCWsZ/LC+oG3Tl/kXzCpUMkuhhwH63Mvfdpk4tNBXx64O6sAz0s1neKiMSU ttEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=uo1BlE6Dm8bwvTVm9KMMhjzoRFYMdk2ZX7vO1voLbNI=; b=SeSU1uA5czSHGrVcMZiUlJ6rK5zkJuFbyYVlaeW2rkF+9nFA07vjouZ19sWbBsuTRJ EJDiDNHLyTYjSF+cTBZFftmcgRuRHmxr6hokLRLBvALfh2nKrk4F+4X83Fq2BSFdHj59 26i7UfslDpVMQ7NwIfZBjQBl4LkJFhEcRN8x+6wAi9w98wk1LXHbLEyO9EKXBAZVmEnt dEoSBiahtyHYnra04sjbZmIO80se+LqhXPdeGLmexG0BLxNWrXcaNQG/OwXCP9QACAFW oqq6ryr3w4SEotwXixyZLgf5n6UzTmMxSm2A+acMqX5IJihrl6VIlsn3o57dQY3sd6vF nbbA== X-Gm-Message-State: ALoCoQlqxc5TcCue9PijfEjE7aaUDb2PJvCSncXIPfamYQC7k8hs+gfadbJDbWerQOXF4K36kPjZfCWBkCDNDjv8+FeYiz/Tbw== X-Received: by 10.98.17.79 with SMTP id z76mr17659716pfi.16.1452887930299; Fri, 15 Jan 2016 11:58:50 -0800 (PST) Received: from Melindas-MacBook-Pro.local (66-230-100-131-radius.dynamic.acsalaska.net. [66.230.100.131]) by smtp.googlemail.com with ESMTPSA id 191sm17256455pfa.23.2016.01.15.11.58.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 11:58:49 -0800 (PST) To: trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5697BA81.4090001@comodo.com> <5698F3D2.1090606@bbn.com> From: Melinda Shore Message-ID: <56994F38.7010608@gmail.com> Date: Fri, 15 Jan 2016 10:57:44 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5698F3D2.1090606@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters , Stephen Farrell Subject: Re: [Trans] proposed CA/Subject changes 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, 15 Jan 2016 19:58:52 -0000 On 1/15/16 4:27 AM, Karen Seo wrote: > There are a number of issues (for the non-log components) that WG > members have asked be addressed that the existing 6962-bis text doesn't > cover. It's becoming extremely difficult to gauge consensus because we're getting so few comments on these proposals, and I think we're getting so few comments because it probably seems to many participants that we (the working group) are being pecked to death by ducks. I'm particularly concerned that we're being asked to do work that is technically correct but unlikely to be actually helpful to implementers (who, it should be pointed out, have implementations underway without these documents). I am generally skeptical of the value of non-specification documents, particularly given that we're living in a time where working group charter proposals are getting scrupulous, detailed review. My actual concern, however, is that this is precisely the sort of thing that is slowing down the production of implementable specifications and causing palpable harm to the IETF and to individual working groups. We have said on some number of occasions that our plan is to get the -bis document through working group last call and backfill any parts that are missing. I'm not seeing a compelling reason to revisit that decision. Changes to the -bis draft should be ones that address problems with the technical correctness of the existing contents. Asking the authors to restructure the -bis draft so that you can produce some other document does not fall within this framework. Also, to be clear, we are not going to treat silence as support. We need review and comments from working group participants. Melinda From nobody Fri Jan 15 13:08: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 825561B3291 for ; Fri, 15 Jan 2016 13:08:56 -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 r8hJajhBrkcs for ; Fri, 15 Jan 2016 13:08:54 -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 474281B3293 for ; Fri, 15 Jan 2016 13:08:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A2253BEDB; Fri, 15 Jan 2016 21:08:50 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN73IQKNvpKg; Fri, 15 Jan 2016 21:08:48 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.41.53.98]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3417BBEB5; Fri, 15 Jan 2016 21:08:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452892128; bh=/BjQld0P6xO+XojYVUoPt7LG3kqSAVgTfXorm7jnaGo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=xM2G8pyS7UBoNusJx5qy2oeMBjWTp7Uq/bjR0QpMBZt+wWUbjkFfL06uM5iXaRzWI EVe0fckAovJRHu2DCn/hacbLv5xq1q+NH3iQT/FXnvTRn6yqRVUH9g+kvoDDaySsoU UZDIEH9kKea+H+gFaS3D/qpNAdnAKBkGRWQzOncw= To: Melinda Shore , trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5697BA81.4090001@comodo.com> <5698F3D2.1090606@bbn.com> <56994F38.7010608@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56995FD7.3050005@cs.tcd.ie> Date: Fri, 15 Jan 2016 21:08:39 +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: <56994F38.7010608@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters Subject: Re: [Trans] proposed CA/Subject changes 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, 15 Jan 2016 21:08:56 -0000 Hi Melinda, On 15/01/16 19:57, Melinda Shore wrote: > On 1/15/16 4:27 AM, Karen Seo wrote: >> There are a number of issues (for the non-log components) that WG >> members have asked be addressed that the existing 6962-bis text doesn't >> cover. > > It's becoming extremely difficult to gauge consensus because > we're getting so few comments on these proposals, and I > think we're getting so few comments because it probably seems > to many participants that we (the working group) are being > pecked to death by ducks. I'm particularly concerned that > we're being asked to do work that is technically correct but > unlikely to be actually helpful to implementers (who, it > should be pointed out, have implementations underway without > these documents). > > I am generally skeptical of the value of non-specification > documents, particularly given that we're living in a time > where working group charter proposals are getting scrupulous, > detailed review. My actual concern, however, is that this is > precisely the sort of thing that is slowing down the production > of implementable specifications and causing palpable harm to the > IETF and to individual working groups. > > We have said on some number of occasions that our plan is to > get the -bis document through working group last call and backfill > any parts that are missing. I'm not seeing a compelling reason > to revisit that decision. Changes to the -bis draft should > be ones that address problems with the technical correctness > of the existing contents. Asking the authors to restructure > the -bis draft so that you can produce some other document > does not fall within this framework. > > Also, to be clear, we are not going to treat silence as support. > We need review and comments from working group participants. Speaking as AD for this wg, I completely agree with you and with the plan to get the -bis document done soon. S. > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Mon Jan 18 21:03: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 734501A9087 for ; Mon, 18 Jan 2016 21:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, 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 KwdGkBgVYlBH for ; Mon, 18 Jan 2016 21:03:24 -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 91DD01A9086 for ; Mon, 18 Jan 2016 21:03:24 -0800 (PST) Received: from [128.89.255.1] (port=56227 helo=Johns-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aLORj-000H1U-De; Tue, 19 Jan 2016 00:03:11 -0500 From: Karen Seo To: Melinda Shore , trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5697BA81.4090001@comodo.com> <5698F3D2.1090606@bbn.com> <56994F38.7010608@gmail.com> Message-ID: <569DC38E.9040708@bbn.com> Date: Tue, 19 Jan 2016 00:03:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56994F38.7010608@gmail.com> Content-Type: multipart/alternative; boundary="------------070300040800060304050407" Archived-At: Cc: Paul Wouters , Stephen Farrell Subject: Re: [Trans] proposed CA/Subject changes 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, 19 Jan 2016 05:03:27 -0000 This is a multi-part message in MIME format. --------------070300040800060304050407 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Folks, > We have said on some number of occasions that our plan is to > get the -bis document through working group last call and backfill > any parts that are missing. I'm not seeing a compelling reason > to revisit that decision. Changes to the -bis draft should > be ones that address problems with the technical correctness > of the existing contents. Asking the authors to restructure > the -bis draft so that you can produce some other document > does not fall within this framework. I agree that getting the -bis document out soon is desirable/important; but I'm concerned by this paragraph. 1. I did not submit the proposed changes with the goal of producing other documents. Re-moving the non-log text from the -bis draft is aimed at helping speed the -bis along by removing the topics/text where many of "the problems with the technical correctness of the existing contents" reside and where more work/review is needed. The idea is to leave in the -bis only the log part of the system because this is the part that the WG seems to be the most concerned with getting out quickly to the implementers and this is the furthest along in terms of completeness/correctness. Irrespective of how the "backfill"ing is done -- aonother -bis? other documents? -- removing the non-log parts will simplify the -bis and speed its progress. 2. IMHO, the suggested edits for the CA/Subject text have been pretty clearly described and could be done in a short time. I did not intend to make a lot of work for the authors and would be happy to make these changes if the authors/WG wanted me to do so. 3. Could the WG please review/consider the drafts on CA/Subject, Browsers, and Monitor/Auditor? These "backfill" many of the missing pieces. Also, putting all the text on a given topic in one place should make things easier for the reviewer and eventually for the implementer. 4. IMHO, pushing the -bis document through with "missing parts" and/or sections/text that are present but incomplete will be confusing/misleading. It would be better to explicitly note where the additional work is needed and to say that the issue will be addressed later. Thank you, Karen --------------070300040800060304050407 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Folks,
We have said on some number of occasions that our plan is to
get the -bis document through working group last call and backfill
any parts that are missing. I'm not seeing a compelling reason
to revisit that decision. Changes to the -bis draft should
be ones that address problems with the technical correctness
of the existing contents. Asking the authors to restructure
the -bis draft so that you can produce some other document
does not fall within this framework.
I agree that getting the -bis document out soon is desirable/important; but I'm concerned by this paragraph.
  1. I did not submit the proposed changes with the goal of producing other documents. Re-moving the non-log text from the -bis draft is aimed at helping speed the -bis along by removing the topics/text where many of "the problems with the technical correctness of the existing contents" reside and where more work/review is needed. The idea is to leave in the -bis only the log part of the system because this is the part that the WG seems to be the most concerned with getting out quickly to the implementers and this is the furthest along in terms of completeness/correctness. Irrespective of how the "backfill"ing is done -- aonother -bis? other documents? -- removing the non-log parts will simplify the -bis and speed its progress.
  2. IMHO, the suggested edits for the CA/Subject text have been pretty clearly described and could be done in a short time. I did not intend to make a lot of work for the authors and would be happy to make these changes if the authors/WG wanted me to do so.
  3. Could the WG please review/consider the drafts on CA/Subject, Browsers, and Monitor/Auditor? These "backfill" many of the missing pieces. Also, putting all the text on a given topic in one place should make things easier for the reviewer and eventually for the implementer.
  4. IMHO, pushing the -bis document through with "missing parts" and/or sections/text that are present but incomplete will be confusing/misleading. It would be better to explicitly note where the additional work is needed and to say that the issue will be addressed later.
Thank you,
Karen
--------------070300040800060304050407-- From nobody Mon Jan 18 21:52: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 482DD1A9239 for ; Mon, 18 Jan 2016 21:52:27 -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 rbIrowlKdCjF for ; Mon, 18 Jan 2016 21:52:26 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 2AEBD1A9238 for ; Mon, 18 Jan 2016 21:52:26 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id 65so169422812pff.2 for ; Mon, 18 Jan 2016 21:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=TIOVehDCK+CVbOhuGIe0/9d1UQM2t0jRhaCjDMuyuas=; b=HAe3sZCYc4Nt5GDzf7UgJ56OuybfxLe2NNGQFZxUsc6TwD2FWvd+rXHv1Hl5l8vFmX 9/BhNyfnbFpzQTFbg8Blc3/8ExYz5LFr7X9tkevOPflmIUK9EPxxZ/hQIz9EPpIVv+O3 hTdV+AryhHsNRPTl8aoaD0h8zHPw0mgrV7Oc8Zgl3aM17gFdr17baPnJu8IuRxLZUlFi bnfqB7gCeUmBtOywnrl4vYs2Ed0mjoKxxu2T8wwgVjP9I8Rz27LRRdWAahnDUG8iBuow 5cfqO89DCvSuy7YnQ7cTKQNihq4e545Fsc99oPCM2qQS0/5b62E0U1wlpmiBLPRlh245 EYZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=TIOVehDCK+CVbOhuGIe0/9d1UQM2t0jRhaCjDMuyuas=; b=Y7f+aTW+/PLbWkO+oG025fnbqcJuDilqylgdYqBjuOaf8+WYxwq4SnTY1roCbGszls 7bGALaHRzN1BhAVvDqbtjsgT9QMEIczRErFojqu9KI/bjHOOk6pHL1D/6RCn7XwgZzve LRa4JRpPQ50mgW4CgtYgfkuZvdRFKJoLveBUiXcBtMYM6JQw7Dn/fNsmPw9FHKnDSDeN D3jItTcX4jVFgLTXAVbu1W3wkcamOUyQKrSlVxf5vmZYxTWKn6siNGU/mhkVbxHm/qBu 5tEW8mPpT8Qyxr6q8nj6VSKfH9a2eIBBJpHtwB6ZZ8HUQrY4uZsXgnpgIqcOCxZUrjPx b0Zw== X-Gm-Message-State: ALoCoQmRzNDesYT2Mwga98QwpKdUA5JnQv6pm8xbJ4XtBzkeSoT2nboOnUc2SBiH/FQkscPRFR8hch0ftLiHxlVn2R0Xes2Xnw== X-Received: by 10.98.44.66 with SMTP id s63mr41933718pfs.2.1453182745861; Mon, 18 Jan 2016 21:52:25 -0800 (PST) Received: from Melindas-MacBook-Pro.local (66-230-88-217-radius.dynamic.acsalaska.net. [66.230.88.217]) by smtp.googlemail.com with ESMTPSA id f16sm38081987pff.18.2016.01.18.21.52.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 21:52:24 -0800 (PST) To: Karen Seo , trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5697BA81.4090001@comodo.com> <5698F3D2.1090606@bbn.com> <56994F38.7010608@gmail.com> <569DC38E.9040708@bbn.com> From: Melinda Shore Message-ID: <569DCF15.9020803@gmail.com> Date: Mon, 18 Jan 2016 20:52:21 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <569DC38E.9040708@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Paul Wouters , Stephen Farrell Subject: Re: [Trans] proposed CA/Subject changes 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, 19 Jan 2016 05:52:27 -0000 On 1/18/16 8:03 PM, Karen Seo wrote: > 3. Could the WG please review/consider the drafts on CA/Subject, > Browsers, and Monitor/Auditor? These "backfill" many of the missing > pieces. Also, putting all the text on a given topic in one place > should make things easier for the reviewer and eventually for the > implementer. If people who've got implementations underway could weigh in on this, we'd be grateful. That would include BBN, if you've got one in development. Thanks, Melinda From nobody Tue Jan 19 12:38: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 9D6661B35F6 for ; Tue, 19 Jan 2016 12:38: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 v15L5dYd40Pe for ; Tue, 19 Jan 2016 12:38: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 411C91B35EE for ; Tue, 19 Jan 2016 12:38:49 -0800 (PST) Received: from localhost ([::1]:40329 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLd3A-00014x-MF; Tue, 19 Jan 2016 12:38: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: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 19 Jan 2016 20:38:48 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/102#comment:2 Message-ID: <071.331bf34825ceec0b9ff47e3d5af255d3@tools.ietf.org> References: <056.46e844da749e3e5ff56d7d32edea06ed@tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <056.46e844da749e3e5ff56d7d32edea06ed@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] #102 (rfc6962-bis): "root" should be "trust anchor" 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, 19 Jan 2016 20:38:50 -0000 #102: "root" should be "trust anchor" Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/c3f1c250e9cd3f836a808aec6e74840872b7850b -- -----------------------------+--------------------------------------- Reporter: benl@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 Tue Jan 19 12:41: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 A3B6F1B35CB for ; Tue, 19 Jan 2016 12:41: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 Wa4buMuaEbOI for ; Tue, 19 Jan 2016 12:41: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 7590D1B35FB for ; Tue, 19 Jan 2016 12:41:40 -0800 (PST) Received: from localhost ([::1]:40415 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLd5v-0001v9-IZ; Tue, 19 Jan 2016 12:41: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, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 19 Jan 2016 20:41:39 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/102#comment:3 Message-ID: <071.f215008aebd9099d032122a1cc321868@tools.ietf.org> References: <056.46e844da749e3e5ff56d7d32edea06ed@tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <056.46e844da749e3e5ff56d7d32edea06ed@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] #102 (rfc6962-bis): "root" should be "trust anchor" 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, 19 Jan 2016 20:41:41 -0000 #102: "root" should be "trust anchor" Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -----------------------------+--------------------------------------- Reporter: benl@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 Jan 19 22: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 BE18C1A86E0 for ; Tue, 19 Jan 2016 22: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 q60o6AW5ap2o for ; Tue, 19 Jan 2016 22: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 C8A1F1A854D for ; Tue, 19 Jan 2016 22:54:57 -0800 (PST) Received: from localhost ([::1]:38242 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLmfR-0000T3-6Q; Tue, 19 Jan 2016 22:54: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, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 20 Jan 2016 06:54:57 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/147#comment:1 Message-ID: <068.1b159286b3964ba16a8c5a1265f9d6cd@tools.ietf.org> References: <053.a0538f74b6d2a41fb9ab8db2aba1dccb@tools.ietf.org> X-Trac-Ticket-ID: 147 In-Reply-To: <053.a0538f74b6d2a41fb9ab8db2aba1dccb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, 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: <20160120065457.C8A1F1A854D@ietfa.amsl.com> Resent-Date: Tue, 19 Jan 2016 22:54:57 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #147 (rfc6962-bis): definition of mis-issuance, still! 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, 20 Jan 2016 06:54:58 -0000 #147: definition of mis-issuance, still! Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => duplicate Comment: Duplicate of ticket:71 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: duplicate Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 19 22:57: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 33D491A86E4 for ; Tue, 19 Jan 2016 22:57: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=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 kzVfQ9MJJaHd for ; Tue, 19 Jan 2016 22:57: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 6B2581A854D for ; Tue, 19 Jan 2016 22:57:58 -0800 (PST) Received: from localhost ([::1]:38517 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLmiK-0002BB-Oo; Tue, 19 Jan 2016 22:57: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, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 20 Jan 2016 06:57:56 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/71#comment:3 Message-ID: <068.0b29779c92d9a88f897a2caea7e4f0bf@tools.ietf.org> References: <053.426ee689532c3072eea3b77c248c3505@tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <053.426ee689532c3072eea3b77c248c3505@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, 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 Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20160120065758.6B2581A854D@ietfa.amsl.com> Resent-Date: Tue, 19 Jan 2016 22:57:58 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #71 (threat-analysis): Section 1 does not define mis-issuance 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, 20 Jan 2016 06:57:59 -0000 #71: Section 1 does not define mis-issuance Comment (by melinda.shore@gmail.com): My mistake - this is for the threat analysis, not the -bis draft. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- kent@bbn.com | analysis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: threat- | Version: analysis | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Jan 20 00:57: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 C7C091B393B for ; Wed, 20 Jan 2016 00:57: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 86af2jUNgH8q for ; Wed, 20 Jan 2016 00:57: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 BB18B1B393A for ; Wed, 20 Jan 2016 00:57:27 -0800 (PST) Received: from localhost ([::1]:42827 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLoZx-0006gI-OJ; Wed, 20 Jan 2016 00:57: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: rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 20 Jan 2016 08:57:25 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/102#comment:4 Message-ID: <071.73fb7303f9c3c4d39f43440d90fe5ca5@tools.ietf.org> References: <056.46e844da749e3e5ff56d7d32edea06ed@tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <056.46e844da749e3e5ff56d7d32edea06ed@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] #102 (rfc6962-bis): "root" should be "trust anchor" 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, 20 Jan 2016 08:57:28 -0000 #102: "root" should be "trust anchor" Changes (by rob.stradling@comodo.com): * status: closed => reopened * resolution: fixed => Comment: Sorry, I referenced the wrong commit. This ticket was actually fixed by https://github.com/google/certificate-transparency- rfcs/commit/56f42d9c48526798beb848af5c0e7cf1c528f470 -- -----------------------------+--------------------------------------- Reporter: benl@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+--------------------------------------- Ticket URL: trans From nobody Wed Jan 20 00:59: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 090AB1B3948 for ; Wed, 20 Jan 2016 00:59: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 iPi7ztSl9vGE for ; Wed, 20 Jan 2016 00:59: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 9BCA91B3956 for ; Wed, 20 Jan 2016 00:58:37 -0800 (PST) Received: from localhost ([::1]:42844 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLob7-0006qI-I6; Wed, 20 Jan 2016 00:58: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: rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 20 Jan 2016 08:58:37 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/114#comment:1 Message-ID: <080.d42130feb18139d93d9c8871f6ba5d2f@tools.ietf.org> References: <065.65476b495967bce5c43b02b4fb12677e@tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <065.65476b495967bce5c43b02b4fb12677e@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] #114 (rfc6962-bis): Name the OCSP Stapling TLS extension correctly 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, 20 Jan 2016 08:59:12 -0000 #114: Name the OCSP Stapling TLS extension correctly Changes (by rob.stradling@comodo.com): * status: new => assigned * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/c3f1c250e9cd3f836a808aec6e74840872b7850b -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Jan 20 06:59:17 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 008741A8A8E for ; Wed, 20 Jan 2016 06:59:16 -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 D-MeHWNfVDmO for ; Wed, 20 Jan 2016 06:59: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 E0DF31A8A89 for ; Wed, 20 Jan 2016 06:59:14 -0800 (PST) Received: from localhost ([::1]:59424 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLuE5-0007lq-7W; Wed, 20 Jan 2016 06:59: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: rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 20 Jan 2016 14:59:13 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/114#comment:2 Message-ID: <080.97459e85ef9adf054d8241301dcd4a4a@tools.ietf.org> References: <065.65476b495967bce5c43b02b4fb12677e@tools.ietf.org> X-Trac-Ticket-ID: 114 In-Reply-To: <065.65476b495967bce5c43b02b4fb12677e@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] #114 (rfc6962-bis): Name the OCSP Stapling TLS extension correctly 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, 20 Jan 2016 14:59:16 -0000 #114: Name the OCSP Stapling TLS extension correctly Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Jan 20 07: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 8FDCA1A8A99 for ; Wed, 20 Jan 2016 07:03: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 THCaNyKX2kLi for ; Wed, 20 Jan 2016 07:03: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 19AA41A8A96 for ; Wed, 20 Jan 2016 07:03:55 -0800 (PST) Received: from localhost ([::1]:59614 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aLuIc-0001HE-HZ; Wed, 20 Jan 2016 07:03: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, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 20 Jan 2016 15:03:54 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/102#comment:5 Message-ID: <071.d10662313d99520a3fdf56d108fba504@tools.ietf.org> References: <056.46e844da749e3e5ff56d7d32edea06ed@tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <056.46e844da749e3e5ff56d7d32edea06ed@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] #102 (rfc6962-bis): "root" should be "trust anchor" 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, 20 Jan 2016 15:03:57 -0000 #102: "root" should be "trust anchor" Changes (by melinda.shore@gmail.com): * status: reopened => closed * resolution: => fixed -- -----------------------------+--------------------------------------- Reporter: benl@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 Fri Jan 22 03:20: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 A681E1A0423 for ; Fri, 22 Jan 2016 03:20:26 -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 UXwocl0dOz-z for ; Fri, 22 Jan 2016 03:20:23 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 45DDA1A0405 for ; Fri, 22 Jan 2016 03:20:23 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id v14so82447319ykd.3 for ; Fri, 22 Jan 2016 03:20:23 -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=A054nYCFvzeVf6CxmVqVyWfka/4aPAuz3dC4NieF3WY=; b=gS7k4VmQHxJxX2f3owW7JFStrVhlKrK7s1CJsk+uV5KH+sKQxMwLEw4kAZcJnxYKex qqP12vCWL1+oWl5fS08LCNsWuMLtVhTkQXn8tvMr0Y5wl2QtKKsTnVl5NEMSuOvzDHna zMvEMUtDpQLWuDSV2Pi2lmFp7WJTGs4rLXg4uZrUI3c5wcqGIQyE8hAAeycZSncEaKLc 4MYexjG6yCkZJuYEkq+qo9r+XUaJ63KLY2UQkLGyn67kHpbeEgHyuoa7Z7U42OzhP33F 3r6WSuuV5Ab70jtlzmXr2N0qNmv2bwbg1Lsd9HkVMysH+56gBq6PoEFq6g4amUZBiE9/ YCYw== 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=A054nYCFvzeVf6CxmVqVyWfka/4aPAuz3dC4NieF3WY=; b=RrFk7z32EiqleIb7kjK/0smBHDulMQkW33uz/lBtrrNuYgkEVuDUG++wP9qUo8O8V4 5UXyf+hCCF4qLchtxSPOGoWHSkvNv+DlNSR+eN1qnY/iYsmw9SH83VIw778Lm3oDM922 q6vKkpktAyHG1AMc/3LFgm/U8XiSUeTDNlLbKTiHtGX3R5Im89c5cS16lw5aecQUBRQ0 WflS22LS02VDAndeIc0Smze/k3rqpeNxaQ5Ktq5kuO+Ey72e+hLe9DSChwn8EGnCgA08 rbryi4TOrZzcMbV6lhVS9cpSmC9/onVF/8x6BJSREa7ZV4dYnNtpRSDwchGvic3EKbB+ 1wxw== X-Gm-Message-State: AG10YOQIUrsqvCEh3rzhzSJuYxEcHamgIDM0FcvCPNwZ5ID343KGRUXqIJvQZa0xJUi1Jv8XnCqGGP6V6UMDTGae MIME-Version: 1.0 X-Received: by 10.37.96.65 with SMTP id u62mr1089283ybb.78.1453461622520; Fri, 22 Jan 2016 03:20:22 -0800 (PST) Received: by 10.37.210.71 with HTTP; Fri, 22 Jan 2016 03:20:22 -0800 (PST) In-Reply-To: <569DCF15.9020803@gmail.com> References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5697BA81.4090001@comodo.com> <5698F3D2.1090606@bbn.com> <56994F38.7010608@gmail.com> <569DC38E.9040708@bbn.com> <569DCF15.9020803@gmail.com> Date: Fri, 22 Jan 2016 11:20:22 +0000 Message-ID: From: Eran Messeri To: Melinda Shore Content-Type: multipart/alternative; boundary=001a1143ecbeb4fe170529ea6786 Archived-At: Cc: Karen Seo , Paul Wouters , "trans@ietf.org" , Stephen Farrell Subject: Re: [Trans] proposed CA/Subject changes 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, 22 Jan 2016 11:20:26 -0000 --001a1143ecbeb4fe170529ea6786 Content-Type: text/plain; charset=UTF-8 Having reviewed Rob's changes that moved the text relevant to each component to a separate section, I can attest it makes 6962-bis much simpler to read. 6962-bis is long, but my opinion it is due to features added to the protocol we've found necessary when deploying RFC6962. There's also mention of issues (for non-log components) that 6962-bis doesn't cover. Can these issues be explicitly stated? The only issue I can think of is the methods TLS clients, monitors and auditors exchange information gleaned from the log, and that is addressed by the Gossip draft. The threat analysis document does an excellent job of describing the dependency between gossiping mechanisms and the overall security properties of the protocol, and it is all properly separated from 6962-bis. >From an implementation perspective, based on a colleague's experience, having the specification for all components in one place is handy as the same data structures are used in the TLS client, log and on the CA side (e.g. both logs and CA client software have to process precertificates).In particular, moving the name redaction mechanism to a separate document means it won't be tested as a part of 6962-bis implementation, which is a bad idea, given it's a completely new functionality in 6962-bis that pertains to CAs, logs and TLS clients. I strongly support Melinda's request for comments from people who've got implementations - at this stage I believe insights from implementations of 6962-bis should guide further changes (aside from the issues already captured in the issue tracker). On Tue, Jan 19, 2016 at 5:52 AM, Melinda Shore wrote: > On 1/18/16 8:03 PM, Karen Seo wrote: > >> 3. Could the WG please review/consider the drafts on CA/Subject, >> Browsers, and Monitor/Auditor? These "backfill" many of the missing >> pieces. Also, putting all the text on a given topic in one place >> should make things easier for the reviewer and eventually for the >> implementer. >> > > If people who've got implementations underway could weigh in > on this, we'd be grateful. That would include BBN, if you've > got one in development. > > Thanks, > > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1143ecbeb4fe170529ea6786 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Having reviewed Rob's changes that moved the text rele= vant to each component to a separate section, I can attest it makes 6962-bi= s much simpler to read. 6962-bis is long, but my opinion it is due to featu= res added to the protocol we've found necessary when deploying RFC6962.=

There's also mention of issues (for non-log compone= nts) that 6962-bis doesn't cover. Can these issues be explicitly stated= ? The only issue I can think of is the methods TLS clients, monitors and au= ditors exchange information gleaned from the log, and that is addressed by = the Gossip draft. The threat analysis document does an excellent job of des= cribing the dependency between gossiping mechanisms and the overall securit= y properties of the protocol, and it is all properly separated from 6962-bi= s.

From an implementation perspective, based on a collea= gue's experience, having the specification for all components in one pl= ace is handy as the same data structures are used in the TLS client, log an= d on the CA side (e.g. both logs and CA client software have to process pre= certificates).In particular, moving the name redaction mechanism to a separ= ate document means it won't be tested as a part of 6962-bis implementat= ion, which is a bad idea, given it's a completely new functionality in = 6962-bis that pertains to CAs, logs and TLS clients.=C2=A0
=
I strongly support Melinda's request for comments from p= eople who've got implementations - at this stage I believe insights fro= m implementations of 6962-bis should guide further changes (aside from the = issues already captured in the issue tracker).

On Tue, Jan 19, 2016 at 5:52 AM, M= elinda Shore <melinda.shore@gmail.com> wrote:
On 1/18/16 8:03 PM, Karen Seo wrote:
=C2=A03. Could the WG please review/consider the drafts on CA/Subject,
=C2=A0 =C2=A0 Browsers, and Monitor/Auditor?=C2=A0 These "backfill&quo= t; many of the missing
=C2=A0 =C2=A0 pieces.=C2=A0 Also, putting all the text on a given topic in = one place
=C2=A0 =C2=A0 should make things easier for the reviewer and eventually for= the
=C2=A0 =C2=A0 implementer.

If people who've got implementations underway could weigh in
on this, we'd be grateful.=C2=A0 That would include BBN, if you've<= br> got one in development.

Thanks,


Melinda

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

--001a1143ecbeb4fe170529ea6786-- From nobody Fri Jan 22 08:17: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 1EA661AD362 for ; Fri, 22 Jan 2016 08:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 TdD-QcDtFJQ6 for ; Fri, 22 Jan 2016 08:17:40 -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 5AA561AD356 for ; Fri, 22 Jan 2016 08:17:40 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:44010 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aMeP5-0008Bv-0s for trans@ietf.org; Fri, 22 Jan 2016 11:17:39 -0500 To: trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <5697BA81.4090001@comodo.com> <5698F3D2.1090606@bbn.com> <56994F38.7010608@gmail.com> From: Stephen Kent Message-ID: <56A25622.50001@bbn.com> Date: Fri, 22 Jan 2016 11:17:38 -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: <56994F38.7010608@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] proposed CA/Subject changes 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, 22 Jan 2016 16:17:42 -0000 Melinda, > On 1/15/16 4:27 AM, Karen Seo wrote: >> There are a number of issues (for the non-log components) that WG >> members have asked be addressed that the existing 6962-bis text doesn't >> cover. > > It's becoming extremely difficult to gauge consensus because > we're getting so few comments on these proposals, and I > think we're getting so few comments because it probably seems > to many participants that we (the working group) are being > pecked to death by ducks. I'm particularly concerned that > we're being asked to do work that is technically correct but > unlikely to be actually helpful to implementers (who, it > should be pointed out, have implementations underway without > these documents). > > I am generally skeptical of the value of non-specification > documents, particularly given that we're living in a time > where working group charter proposals are getting scrupulous, > detailed review. My actual concern, however, is that this is > precisely the sort of thing that is slowing down the production > of implementable specifications and causing palpable harm to the > IETF and to individual working groups. Not sure to which documents you are referring in the paragraphs above. The threat analysis is not a requirements spec, but it is an already-accepted WG doc and I will post changes to it base on the feedback from Rich and Eran. The architecture doc also is not a requirements spec and it has not been adopted by the WG. However, the comments from Rich and Eran were mostly very positive and a new version of it also will be posted next week, with changes based on their comments. The three docs that Karen, David, and I wrote and posted at the end of last year are requirements specification docs, addressing the CT system elements that we feel are not well-addressed in 6962-bis. They are companions to the architecture doc. We have provided specific, suggested edits for 6962-bis so that its discussions of non-log components do not use requirements language, leaving that to the three docs that we posted. We have yet to receive comments on these docs; Eran, at the end of his comments on the architecture doc even asked what was preventing us from writing them! Finally, in response to your query about who is implementing what: BBN has explored design aspects of the Monitor and Auditor functions, as well as browser behavior. In my role as a member of the technical advisory board for Let's Encrypt I have discussed these CT system element design issues with some of the Let's Encrypt folks. They are planning to implement Monitor and Auditor functions. The Mozilla folks with whom I communicate are interested in the browser behavior topics that we have described in our browser/browser-vendor spec. Steve From nobody Mon Jan 25 04:01: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 55CD31A8AF3 for ; Mon, 25 Jan 2016 04:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.021 X-Spam-Level: * X-Spam-Status: No, score=1.021 tagged_above=-999 required=5 tests=[AC_HTML_NONSENSE_TAGS=1, 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.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 lEPQAZCaJgAY for ; Mon, 25 Jan 2016 04:00:58 -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 01F2E1A8AEB for ; Mon, 25 Jan 2016 04:00:57 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id t15so33668598igr.0 for ; Mon, 25 Jan 2016 04:00:57 -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=2BX6zw36x6ky8o1nR5pTRDCCaZ6Gk09YMKNjEInleEA=; b=bVWd/amP3VwRzAAmpESFSCSyuvyINWq1vrGojPIHuhjnwQs9JCdFkd1pzMZVo9QG6Y hxqTt6LRoS0pqOK5WjJkRsgsgs0gfGeFy8niMQfbjRSN/qtqf2PUrsUPIAO6McCEun6v vitO9kqCtWLPWu62tm5WNPWCxtDBAP17/aJYgD9ZpRJg0edF4s58LdPt/rALc5Urmco6 X6AxMntDCLKCD7N+fw4ZXuNk3p9YoChBBBgJJWCoB2eU+AWgfTZyD5/yxPkoJNzPmjiQ 87gxxLcTDKFPArOFubJFF9OK0VaPaygPxSPYppZXbTLsFARkJtuEcpPqOic7JBLn5N4O Av4w== 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=2BX6zw36x6ky8o1nR5pTRDCCaZ6Gk09YMKNjEInleEA=; b=W4f5yzdn1/MA0Y7Wsd7fR0LO/paRSLXPJffOVzizW9SExTZP/JrCNSrUv8P8/eGsHz lHyOr/gTcNDXpAE2jzxPNobvTi/maaDnWoxMWGcMUJIX7vazxbn6OWqr9PIv3tWyDPQv I7iVT5164Fu0D2AScpvJIH2JlvNVDOpoNAPZv1fztbgFaIoPeZOhIrjHGbtLcnAwYTp8 oyoDvX217Di/tYL/FnHUhzf2dOzoqY2indwAcdC9Pw2ypDyfwnrRYuP2G5tkfFz5hI3w c9ukbQjpXdyM1/wPyfh77C5ZinWrhUcIgW4aNuozfEYxill4FvcPjpFuHUrjPjvDl2XF lywQ== X-Gm-Message-State: AG10YOSFl4ZgT8IvgGCEvbqarltLledaFj3un4ZwLgp7rW1gHHMqNPm7VaKhGt0Tr4Z1iX1tH9HlqlqugEpBqCFP MIME-Version: 1.0 X-Received: by 10.50.171.162 with SMTP id av2mr17725233igc.32.1453723257106; Mon, 25 Jan 2016 04:00:57 -0800 (PST) Received: by 10.64.26.98 with HTTP; Mon, 25 Jan 2016 04:00:56 -0800 (PST) In-Reply-To: <5693E6F9.2090101@bbn.com> References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> Date: Mon, 25 Jan 2016 12:00:56 +0000 Message-ID: From: Ben Laurie To: Karen Seo Content-Type: multipart/alternative; boundary=089e0118429e57ce0c052a2752df Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] proposed CA/Subject changes 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, 25 Jan 2016 12:01:01 -0000 --089e0118429e57ce0c052a2752df Content-Type: text/plain; charset=UTF-8 On 11 January 2016 at 17:31, Karen Seo wrote: > Folks, > > I agree with the approach discussed on the list of simplifying 6962-bis to > focus only on specifications for the CT log by moving the detailed > specifications for other components of the CT system to other documents. This > is in line with a message from Melinda on July 2 re: client behavior, and a > message from Rich Saltz on July 6 re: the Auditor function. To facilitate > moving requirements for the CA/Subject part of the system, I propose that > we make the changes below with regard to statements about CT requirements > for CA and Subject behavior. These changes will also help to address > some of the concerns that have been cited elsewhere about the text of > 6962-bis (e.g., issues 139, 140, 144). > The tag "client behaviour" is an unfortunate choice, because it mixes up various different concerns. The particular concern that was intended to be separated was what clients do UI-wise in response to the presence of lack of transparency information. Other client behaviour, such as following the protocol, is _not_ out of scope for 6962-bis. Indeed, it seems counter-productive to remove it, since that's the document implementers have to actually read in order to implement CT. It makes no sense to define one side of a protocol in one document and the other in another. > > > Karen > > *Changes to 6962-bis* > > *Section 3. Submitters* > > *From: *Submitters submit certificates or pre-certificates to logs for > public auditing, as described below. In order to enable attribution of each > logged certificate or pre-certificate to its issuer, each submission MUST > be accompanied by all additional certificates required to verify the chain > up to an accepted root certificate. The root certificate itself MAY be > omitted from the submission. > > If a log accepts a submission, it will return a Signed Certificate > Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the > returned SCT as described in Section 9.2 if they understand its format and > they intend to use it directly in a TLS handshake or to construct a > certificate. > > *To:* > A Submitter sends a certificate or pre-certificate (see Section 3.1 below) > to one or more logs. This enables public monitoring of certificates to > facilitate detection of certificate mis-issuance. If a log accepts a > submission, it will return a Signed Certificate Timestamp (SCT) (see > Section 5.6). This document specifies the interface to a log that a > Submitter uses to log a certificate or pre-certificate (see Section 3). A > detailed specification of how a Submitter should choose to submit a > certificate vs. a pre-certificate and how it should process the SCT that is > returned, will be described in a separate specification to be published > later. > > Clearly this does not pertain to UI and so is in scope. > *Sections 3.1 and 3.2* > > *From:* > 3.1. Certificates > Anyone can submit a certificate (Section 6.1) to a log. Since certificates > may not be accepted by TLS clients unless logged, it is expected that > certificate owners or their CAs will usually submit them. > > 3.2. Precertificates > Alternatively, (root as well as intermediate) CAs may pre-announce a > certificate prior to issuance by submitting a pre-certificate (Section 6.2) > that the log can use to create an entry that will be valid against the > issued certificate. The CA MAY incorporate the returned SCT in the issued > certificate. > > *To: * > 3.1 Certificates and Pre-certificates > Anyone can submit a certificate to a log (see Section 6.1). It is expected > that certificate owners (Subjects) or their CAs will usually submit > certificates. Alternatively, (root as well as intermediate) CAs may log a > certificate prior to issuance by submitting a pre-certificate. The log > will use this to create an entry and return an SCT that can be used to > verify that the issued certificate was logged (see Section 6.2). The CA > may incorporate the returned SCT in the issued certificate. > > *[The rest of 3.2 defines both what the log should accept for a > pre-certificate and what the CA must do. So it should remain here but also > be duplicated in a requirements document for CAs. ]* > > This change seems fine. > > *Section 4 Private Domain Names* > > *From: * > Some regard some DNS domain name labels within their registered domain > space as private and security sensitive. Even though these domains are > often only accessible within the domain owner's private network, it's > common for them to be secured using publicly trusted TLS server > certificates. We define a mechanism to allow these private labels to not > appear in public logs. > > *To: * > Some organizations regard some of the DNS domain name labels within their > registered domain space as private and security sensitive. Even though > these domains are often only accessible within the domain owner's private > network, it's common for them to be secured using publicly trusted TLS > server certificates. A detailed description of mechanisms that a CA > could use to support this will be described in a separate specification to > be published later. > > *Sections 4.1 Wildcard Certificates, 4.2 **Redacting Domain Name Labels > in Precertificates, and **4.3 Using a Name-Constrained Intermediate CA* > > *[The text in these sections applies only to CAs and should be moved to a > requirements specification for CAs]* > > Disagree. Clients need to know how to validate such certificates/SCTs. > > *Possible new section* > > If the log checks the syntax of a pre-certificate, then that should be > described in a new section called something like "Checking Certificate > Syntax ." Any syntax checking done by the CA should be put in a > requirememts specificatio*n* for CAs. > > > *Section 7 TLS Servers* > > *From:* > TLS servers MUST use at least one of the three mechanisms listed below to > present one or more SCTs or inclusion proofs from one or more logs to each > TLS client during TLS handshakes, where each SCT or inclusion proof > corresponds to the server certificate or to a name- constrained > intermediate the server certificate chains to. Three mechanisms are > provided because they have different tradeoffs. > > *To:* > A CT-aware TLS server (certificate Subject) can present one or more SCTs > or inclusion proofs from one or more logs to each TLS client during a TLS > handshake. (A TLS server is considered to be CT-aware if it is configured > to send certificates with embedded SCTs or inclusion proofs during a TLS > handshake, or to convey SCTs separately during the handshake.) Each SCT or > inclusion proof corresponds to the server certificate or to a > name-constrained intermediate CA certificate to which the server > certificate chains. The mechanisms by which the TLS server presents the > SCTs or inclusion proofs to a TLS client will be described in a TLS server > requirements specification that will be published later. > > *[The rest of 7 and all of 7.1 should be moved to the** above mentioned > TLS server requirements specification.**]* > > *Section 8 (Certification Authorities), 8.1. (Transparency Information > X.509v3 Extension), 8.1.1. OCSP Response Extension, 8.1.2. Certificate > Extension* > > *[These sections defines only CA actions/behavior. They should be moved to > a requirements specification for CAs.* > *] * > > *Section 12.3 (Redaction of Public Domain Name Labels* > > *[This subsection applies only to CAs. It **should be moved to a > requirements specification for CAs.]* > > *Section 12.5 Multiple SCTs* > > *[This** subsection applies only to CAs and clients. The text should be > moved to a requirements specification for CAs and a specification for > browsers.]* > > Disagree with all of these for the reasons mentioned above. > > > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --089e0118429e57ce0c052a2752df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 11 January 2016 at 17:31, Karen Seo <kseo@bbn.com> wrote:<= br>
=20 =20 =20
Folks,

I agree with the approach discussed on the list of simplifying 6962-bis to focus only on specifications for the CT log by moving the detailed specifications for other components of the CT system to other documents. This is in line with a message from Melinda on July 2 re: client behavior, and a<= /u> message from Rich Saltz on July 6 re: the Auditor function. To facilitate moving requirements for the CA/Subject part of the system, <= span>I propose that we make the changes below with regard to statements about CT requirements for CA and Subject behavior.=C2=A0 These changes wi= ll also help to address some of the concerns that have been cited elsewhere about the text of 6962-bis (e.g., issues 139, 140, 144).

The tag "client behaviour" is an unfo= rtunate choice, because it mixes up various different concerns. The particu= lar concern that was intended to be separated was what clients do UI-wise i= n response to the presence of lack of transparency information.
<= br>
Other client behaviour, such as following the protocol, is _n= ot_ out of scope for 6962-bis. Indeed, it seems counter-productive to remov= e it, since that's the document implementers have to actually read in o= rder to implement CT. It makes no sense to define one side of a protocol in= one document and the other in another.

=C2=A0
=
=C2=A0
Karen

Changes to 6962-bis

Section 3. Submitters
From: Submitters submit certificates or pre-certificates to logs for public auditing, as described below. In order to enable attribution of each logged certificate or pre-certificate to its issuer, each submission MUST be accompanied by all additional certificates required to verify the chain up to an accepted root certificate. The root certificate itself MAY be omitted from the submission.
If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the returned SCT as described in Section 9.2 if they understand its format and they intend to use it directly in a TLS handshake or to construct a certificate.
To:
A Submitter sends a certificate or pre-certificate (see Section 3.1 below) to one or more logs. This enables public monitoring of certificates to facilitate detection of certificate mis-issuance. If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT) (see Section 5.6). This document spe= cifies the interface to a log that a Submitter uses to log a certificate or pre-certificate (see Section 3). A detailed specification of how a Submitter should choose to submit a certificate vs. a pre-certificate and how it should process the SCT that is returned, will be described in a separate specification to be published later.=C2=A0

Clearly this does not pertain to UI and so is in scope.= =C2=A0
Sections 3.1 and 3.2
From:=
3.1. Certificates
Anyone can submit a certificate (Section 6.1) to a log. Since certificates may not be accepted by TLS clients unless logged, it is expected that certificate owners or their CAs will usually submit them.
=C2=A0
3.2. Precertificates
Alternatively, (root as well as intermediate) CAs may pre-announce a certificate prior to issuance by submitting a pre-certificate (Section 6.2) that the log can use to create an entry that will be valid against the issued certificate. The CA MAY incorporate the returned SCT in the issued certificate.

To:
3.1 Certificates and Pre-certificates
Anyone can submit a certificate to a log (see Section 6.1). It is expected that certificate owners (Subjects) or their CAs will usually submit certificates. Alternatively, (root as well as intermediate) CAs may log a certificate prior to issuance by submitting a pre-certificate.=C2=A0 The log will use this to create an entry a= nd return an SCT that can be used to verify that the issued certificate was logged (see Section 6.2).=C2=A0 The CA may incorporate the returned SCT in the issued certificate.
[The rest of 3.2 defines both what the log should accept for a pre-certificate and what the CA must do. So it should remain here but also be duplicated in a requirements document for CAs. ]<= b>

This change seems fine.=C2=A0
=
Section 4 Private Domain Names
From:
Some regard some DNS domain name labels within their registered domain space as private and security sensitive. Even though these domains are often only accessible within the domain owner's private network, it's common for them to be secured using publicly trusted TLS server certificates. We define a mechanism to allow these private labels to not appear in public logs.

To:
Some organizations regard some of the DNS domain name labels within their registered domain space as private and security sensitive. Even though these domains are often only accessible within the domain owner's private network, it's common for = them to be secured using publicly trusted TLS server certificates.=C2=A0= A detailed description of mechanisms that a CA could use to support this will be described in a separate specification to be published later.
<= small>= Sections 4.1 Wildcard Certificates, 4.2 = <= /small><= small>= Redacting Domain Name Labels in Precertificates, and <= /small><= small>4.3 Using a Name-Constrained Intermediate CA<= /span>=
=
[The text in these sections applies only to CAs and should be moved to a requirements specification for CAs]

Disagree. Clients need to know how= to validate such certificates/SCTs.
=C2=A0
<= br>
Possible new section
If the log checks the syntax of a pre-certificate, then that should be described in a new section called something like=C2=A0 "Checking Certificate Sy= ntax ."=C2=A0 Any syntax checking done by the CA should be put in= a requirememts specification for CAs.=C2=A0

Section 7 TLS Servers
From:=
TLS servers MUST use at least one of the three mechanisms listed below to present one or more SCTs or inclusion proofs from one or more logs to each TLS client during TLS handshakes, where each SCT or inclusion proof corresponds to the server certificate or to a name- constrained intermediate the server certificate chains to. Three mechanisms are provided because they have different tradeoffs.
To:
A CT-aware TLS server (certificate Subject) can present one or more SCTs or inclusion proofs from one or more logs to each TLS client during a TLS handshake. (A TLS server is considered to be CT-aware if it is configured to send certificates with embedded SCTs or inclusion proofs during a TLS handshake, or to convey SCTs separately during the handshake.) Each SCT or inclusion proof corresponds to the server certificate or to a name-constrained intermediate CA certificate to which the server certificate chains. The mechanisms by which the TLS server presents the SCTs or inclusion proofs to a TLS client will be described in a TLS server requirements specification that will be published later.

[The rest of 7 and all of 7.1 should be moved to the above mentioned TLS server requirements specification.]
Section 8 (Certification Authorities), 8.1. (Transparency Information X.509v3 Extension), 8.1.1. OCSP Response Extension, 8.1.2. Certificate Extension
[These sections defines only CA actions/behavior. They should be moved to a requirements specification for CAs.]
Section 12.3 (Redaction of Public Domain Name Labels
[This subsection applies only to CAs.=C2=A0 It should be moved to a requirements specification for CAs.]
Section 12.5 Multiple SCTs
[This subsection applies only to CAs and clients. The text should be moved to a requirements specification for CAs and a specification for browsers.]=

Disagree with all of = these for the reasons mentioned above.
=C2=A0

=20 =20 =20 =20 =20 =20 =20 =20 =20




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


--089e0118429e57ce0c052a2752df-- From nobody Mon Jan 25 05:29:33 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 12C241A90D1 for ; Mon, 25 Jan 2016 05:29:32 -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 FNB4Bdl-eJgA for ; Mon, 25 Jan 2016 05:29:30 -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 986CC1A90D5 for ; Mon, 25 Jan 2016 05:29:29 -0800 (PST) Received: (qmail 26477 invoked by uid 1004); 25 Jan 2016 13:29:26 -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, 25 Jan 2016 13:29:26 +0000 Received: (qmail 8608 invoked by uid 1000); 25 Jan 2016 13:29:26 -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, 25 Jan 2016 13:29:26 +0000 To: Ben Laurie , Karen Seo References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> From: Rob Stradling Message-ID: <56A62335.6080106@comodo.com> Date: Mon, 25 Jan 2016 13:29:25 +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: Cc: "trans@ietf.org" Subject: Re: [Trans] proposed CA/Subject changes 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, 25 Jan 2016 13:29:32 -0000 On 25/01/16 12:00, Ben Laurie wrote: > /*Sections 3.1 and 3.2*/ > > *_From:_* > 3.1. Certificates > Anyone can submit a certificate (Section 6.1) to a log. Since > certificates may not be accepted by TLS clients unless logged, > it is expected that certificate owners or their CAs will usually > submit them. > > 3.2. Precertificates > Alternatively, (root as well as intermediate) CAs may > pre-announce a certificate prior to issuance by submitting a > pre-certificate (Section 6.2) that the log can use to create an > entry that will be valid against the issued certificate. The CA > MAY incorporate the returned SCT in the issued certificate. > > *_To: _* > 3.1 Certificates and Pre-certificates > Anyone can submit a certificate to a log (see Section 6.1). It > is expected that certificate owners (Subjects) or their CAs will > usually submit certificates. Alternatively, (root as well as > intermediate) CAs may log a certificate prior to issuance by > submitting a pre-certificate. The log will use this to create > an entry and return an SCT that can be used to verify that the > issued certificate was logged (see Section 6.2). The CA may > incorporate the returned SCT in the issued certificate. > > ____/[The rest of 3.2 defines both what the log should accept > for a pre-certificate and what the CA must do. So it should > remain here but also be duplicated in a requirements document > for CAs. ]/** > > This change seems fine. I don't see any advantages to conflating sections 3.1 and 3.2. Are there any? In -10, I deliberately moved the certificate requirements and precertificate requirements into two separate sections. It's likely that some implementers will have no interest in implementing precertificates. I think that conflating sections 3.1 and 3.2 would make it harder for those implementers to figure out which paragraphs they don't need to read. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jan 25 05:33: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 CF52E1A90F1 for ; Mon, 25 Jan 2016 05:33:34 -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 oY_XwZwLCb2M for ; Mon, 25 Jan 2016 05:33:33 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141751A90EA for ; Mon, 25 Jan 2016 05:33:33 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id q21so151599416iod.0 for ; Mon, 25 Jan 2016 05:33:33 -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=CL7Tfxl8ChmpBHjeFwllKhCa3s5VMfgZxFGCrDfrBpc=; b=Qo5IPW8ppgrFDVXF1Dorf0/WPwx6G9Q6lVbrQMeaJTQOAk+o4W22NcP3iICTeVZJM9 +38c39B8MD18o+umbhiDR1YUMf0HjBZygth0mCLUPEPz2v3nyYvbEopuZt3g8FZVNXhL do45x0tG1sKEiUwJanjRHgJr4xnqNcJa00gexVkp41ZgwTZ7iX1M02OoPG5W4e0KVS2K 3sOoWxeRn+hLpfAad2QSa5uK3ymuUeDeT0L9VMjvD9ks3zP0U8ulpjPoklC/ZTRdOY0E TZQ9jzcOOUzYEf7rVdkcFhBBU1pzsXlSrMVUv4i0P59EwpmFGKpkSARJRwvpIa+cI4cm NE2w== 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=CL7Tfxl8ChmpBHjeFwllKhCa3s5VMfgZxFGCrDfrBpc=; b=MbsFw8NOFXkj7cgmUuicLYxhlvdibGB6qotwyDfrId1Tq0uIjPW70avwpOKxUvPGJL ifIt+J+7GPvK+HtD1RvM+VFVXGF8N6ImtCRXLLk2xFL90arAvHDINhMR3XBXAmCdNlzZ ehj+8we8cmuMHlRqE2dzq1KRcvBUqgBSvyTQ00bLJmuNpTt7AW9zzINqwcZ4D2MdFQqR HPv0gdUPk7/3FlarhkVa14SH89a6VkU6hJrrkYAnx07b8ubvh9O/idPFCeh19fXH3rub agGllbDFUBdyBTbtSumxGWNeYDMi/n74UW/igjMj3muxvN0fBHyrJf5NAucb6cDXdbVh DrXw== X-Gm-Message-State: AG10YOQctUGsMctljd8tcGIzLDZ2DHACD6AwTDCMiPdCF5oJ6PNm2cu/QGAXVhKZX53F4utXOWLBGHcHYDRK3HBQ MIME-Version: 1.0 X-Received: by 10.107.132.162 with SMTP id o34mr17404352ioi.13.1453728812330; Mon, 25 Jan 2016 05:33:32 -0800 (PST) Received: by 10.64.26.98 with HTTP; Mon, 25 Jan 2016 05:33:32 -0800 (PST) In-Reply-To: <56A62335.6080106@comodo.com> References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <56A62335.6080106@comodo.com> Date: Mon, 25 Jan 2016 13:33:32 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: multipart/alternative; boundary=001a113f33e875c516052a289d0f Archived-At: Cc: Karen Seo , "trans@ietf.org" Subject: Re: [Trans] proposed CA/Subject changes 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, 25 Jan 2016 13:33:35 -0000 --001a113f33e875c516052a289d0f Content-Type: text/plain; charset=UTF-8 On 25 January 2016 at 13:29, Rob Stradling wrote: > On 25/01/16 12:00, Ben Laurie wrote: > > >> /*Sections 3.1 and 3.2*/ >> >> *_From:_* >> 3.1. Certificates >> Anyone can submit a certificate (Section 6.1) to a log. Since >> certificates may not be accepted by TLS clients unless logged, >> it is expected that certificate owners or their CAs will usually >> submit them. >> >> 3.2. Precertificates >> Alternatively, (root as well as intermediate) CAs may >> pre-announce a certificate prior to issuance by submitting a >> pre-certificate (Section 6.2) that the log can use to create an >> entry that will be valid against the issued certificate. The CA >> MAY incorporate the returned SCT in the issued certificate. >> >> *_To: _* >> 3.1 Certificates and Pre-certificates >> Anyone can submit a certificate to a log (see Section 6.1). It >> is expected that certificate owners (Subjects) or their CAs will >> usually submit certificates. Alternatively, (root as well as >> intermediate) CAs may log a certificate prior to issuance by >> submitting a pre-certificate. The log will use this to create >> an entry and return an SCT that can be used to verify that the >> issued certificate was logged (see Section 6.2). The CA may >> incorporate the returned SCT in the issued certificate. >> >> ____/[The rest of 3.2 defines both what the log should accept >> for a pre-certificate and what the CA must do. So it should >> remain here but also be duplicated in a requirements document >> for CAs. ]/** >> >> This change seems fine. >> > > I don't see any advantages to conflating sections 3.1 and 3.2. Are there > any? > > In -10, I deliberately moved the certificate requirements and > precertificate requirements into two separate sections. > It's likely that some implementers will have no interest in implementing > precertificates. I think that conflating sections 3.1 and 3.2 would make > it harder for those implementers to figure out which paragraphs they don't > need to read. Fair point, it was the wording I was OK with (not that I particularly think it is needed, though, so I'd also be OK with not making any change). --001a113f33e875c516052a289d0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 25 January 2016 at 13:29, Rob Stradling <rob.stradling@comod= o.com> wrote:
On 25/01/16 1= 2:00, Ben Laurie wrote:
<snip>
=C2=A0 =C2=A0 /*Sections 3.1 and 3.2*/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *_From:_*
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3.1. Certificates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Anyone can submit a certificate (Section 6.1) t= o a log. Since
=C2=A0 =C2=A0 =C2=A0 =C2=A0 certificates may not be accepted by TLS clients= unless logged,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it is expected that certificate owners or their= CAs will usually
=C2=A0 =C2=A0 =C2=A0 =C2=A0 submit them.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.2. Precertificates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alternatively, (root as well as intermediate) C= As may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pre-announce a certificate prior to issuance by= submitting a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pre-certificate (Section 6.2) that the log can = use to create an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 entry that will be valid against the issued cer= tificate. The CA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAY incorporate the returned SCT in the issued = certificate.

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *_To: _*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.1 Certificates and Pre-certificates
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Anyone can submit a certificate to a log (see S= ection 6.1). It
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is expected that certificate owners (Subjects) = or their CAs will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 usually submit certificates. Alternatively, (ro= ot as well as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 intermediate) CAs may log a certificate prior t= o issuance by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 submitting a pre-certificate.=C2=A0 The log wil= l use this to create
=C2=A0 =C2=A0 =C2=A0 =C2=A0 an entry and return an SCT that can be used to = verify that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 issued certificate was logged (see Section 6.2)= . The CA may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 incorporate the returned SCT in the issued cert= ificate.

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ____/[The rest of 3.2 defines both what the log= should accept
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for a pre-certificate and what the CA must do. = So it should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 remain here but also be duplicated in a require= ments document
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for CAs. ]/**

This change seems fine.

I don't see any advantages to conflating sections 3.1 and 3.2.=C2=A0 Ar= e there any?

In -10, I deliberately moved the certificate requirements and precertificat= e requirements into two separate sections.
It's likely that some implementers will have no interest in implementin= g precertificates.=C2=A0 I think that conflating sections 3.1 and 3.2 would= make it harder for those implementers to figure out which paragraphs they = don't need to read.

Fair point, it was = the wording I was OK with (not that I particularly think it is needed, thou= gh, so I'd also be OK with not making any change).

--001a113f33e875c516052a289d0f-- From nobody Tue Jan 26 08:09: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 8468B1B305A for ; Tue, 26 Jan 2016 08:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, 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 9Xq7x54Rvo_k for ; Tue, 26 Jan 2016 08:09:05 -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 954F01B305B for ; Tue, 26 Jan 2016 08:09:05 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:40725 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aO6Aw-000NLJ-6Y for trans@ietf.org; Tue, 26 Jan 2016 11:09:02 -0500 To: trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> From: Stephen Kent Message-ID: <56A79A1D.5080402@bbn.com> Date: Tue, 26 Jan 2016 11:09:01 -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="------------060705040007040202090806" Archived-At: Subject: Re: [Trans] proposed CA/Subject changes 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, 26 Jan 2016 16:09:08 -0000 This is a multi-part message in MIME format. --------------060705040007040202090806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ben, > > On 11 January 2016 at 17:31, Karen Seo > wrote: > > Folks, > > I agree with the approach discussed on the list of simplifying > 6962-bis to focus only on specifications for the CT log by moving > the detailed specifications for other components of the CT system > to other documents. This is in line with a message from Melinda on > July 2 re: client behavior, and a message from Rich Saltz on July > 6 re: the Auditor function. To facilitate moving requirements for > the CA/Subject part of the system, I propose that we make the > changes below with regard to statements about CT requirements for > CA and Subject behavior. These changes will also help to address > some of the concerns that have been cited elsewhere aboutthe text > of 6962-bis (e.g., issues 139, 140, 144). > > > The tag "client behaviour" is an unfortunate choice, because it mixes > up various different concerns. The particular concern that was > intended to be separated was what clients do UI-wise in response to > the presence of lack of transparency information. I agree that the phrase "client behavior" is too broad. But, I also think that not all of what a client does in the lack of valid CT info is strictly a UI issue. For example, Eran noted that the architecture doc distinguishes between what a client does in the absence of an SCT vs. what it does if there is an SCT but the sig fails. This, IMHO, is a legitimate protocol issue that the WG has not addressed. David took a position on this in his browser spec, but that's just an initial proposal that needs to be reviewed and discussed by the WG. However, at least the issue is clearly stated in that doc and thus provides a basis for discussion. > Other client behaviour, such as following the protocol, is _not_ out > of scope for 6962-bis. Indeed, it seems counter-productive to remove > it, since that's the document implementers have to actually read in > order to implement CT. It makes no sense to define one side of a > protocol in one document and the other in another. The text in 6269-bis is still rather odd in discussing client behavior in the protocol context. It makes comments (not using standards language) about clients requiring all connections to be accompanied by SCTs: TLS clients can thus require that all certificates they accept as valid are accompanied by signed timestamps. If I were implementing a client this would sound like a requirement, especially in the absence of any RFC that purports to be a client spec. The text above is an example of why I feel we need an separate client spec that is clear about requirements. Similarly vague text appears elsewhere, e.g., Since certificates may not be accepted by TLS clients unless logged, ... The question of whether a (TLS) client is expected to contact a log directly to acquire an STH is also not clearly described with text like: When a client requests a log's latest STH ... Since the next sentence refers to "marking clients" a reader may infer that TLS clients are required to acquire STHs. This is a more subtle issue than suggested by this text. In general, 6962-bis uses the term "client" to refer to all log clients, but usage is sometimes inconsistent, leading to ambiguity wrt TLS client (aka bowser) requirements. Steve --------------060705040007040202090806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,


On 11 January 2016 at 17:31, Karen Seo <kseo@bbn.com> wrote:
Folks,

I agree with the approach discussed on the list of simplifying 6962-bis to focus only on specifications for the CT log by moving the detailed specifications for other components of the CT system to other documents. This is in line with a message from Melinda on July 2 re: client behavior, and a message from Rich Saltz on July 6 re: the Auditor function. To facilitate moving requirements for the CA/Subject part of the system, I propose that we make the changes below with regard to statements about CT requirements for CA and Subject behavior.  These changes will also help to address some of the concerns that have been cited elsewhere about the text of 6962-bis (e.g., issues 139, 140, 144).

The tag "client behaviour" is an unfortunate choice, because it mixes up various different concerns. The particular concern that was intended to be separated was what clients do UI-wise in response to the presence of lack of transparency information.
I agree that the phrase "client behavior" is too broad. But, I also think that not all of what
a client does in the lack of valid CT info is strictly a UI issue. For example, Eran noted that the architecture doc distinguishes between what a client does in the absence of an SCT vs. what
it does if there is an SCT but the sig fails. This, IMHO, is a legitimate protocol issue that the
WG has not addressed.  David took a position on this in his browser spec, but that's just an
initial proposal that needs to be reviewed and discussed by the WG. However, at least the issue is
clearly stated in that doc and thus provides a basis for discussion.
Other client behaviour, such as following the protocol, is _not_ out of scope for 6962-bis. Indeed, it seems counter-productive to remove it, since that's the document implementers have to actually read in order to implement CT. It makes no sense to define one side of a protocol in one document and the other in another.
The text in 6269-bis is still rather odd in discussing client behavior in the protocol context.
It makes comments (not using standards language) about clients requiring all connections to
be accompanied by SCTs:
TLS clients can thus require that all certificates they accept as valid are accompanied
by signed timestamps.

If I were implementing a client this would sound like a requirement, especially in the absence
of any RFC that purports to be a client spec. The text above is an example of why I feel we
need an separate client spec that is clear about requirements.

Similarly vague text appears elsewhere, e.g.,

Since certificates may not be accepted by TLS clients unless logged, ...

The question of whether a (TLS) client is expected to contact a log directly to acquire an STH is also
not clearly described with text like:

When a client requests a log's latest STH ...
Since the next sentence refers to "marking clients" a reader may infer that TLS clients
are required to acquire STHs.  This is a more subtle issue than suggested by this text.

In general, 6962-bis uses the term "client" to refer to all log clients, but usage is
sometimes inconsistent, leading to ambiguity wrt TLS client (aka bowser) requirements.

Steve

--------------060705040007040202090806-- From nobody Wed Jan 27 05:50: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 A149A1B2E1F for ; Wed, 27 Jan 2016 05:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 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_FONT_FACE_BAD=0.981, 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 KzCvd0iri_rc for ; Wed, 27 Jan 2016 05:50:38 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CA21B2DFB for ; Wed, 27 Jan 2016 05:50:38 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id g73so19473401ioe.3 for ; Wed, 27 Jan 2016 05:50:38 -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=2gr9uQhmoic0JjKylvYgk0DQ7wBQwsufvFLwknClJPE=; b=TxMR5BmdpnKc/CJm1+4mMwpfn1tz1Jn+WHK+Ms5TWXxinCqq+dJg6aF7A3tZGb8hBO h689FyvO3DkXgaI2UNOeVfVRHZgcqbkdC93NZmrP4NMgjH80mT0x7gaFBE3K/kqCrQCx 5BfaFwFJwSECsm+Os6fsrwfqJvY7nmWqHOIyq5ndKIMAwEG44K5AkffBH3yBXUx1OQRQ Cvdhr8yHMT8eVgb1own6gj78sDEdQi4PezHRXlW8pzM7ln8Fnz1rhpMXCmGRRUw4upEJ T6be/HDDSkSb49F6o85e47VGQUuVVdu6WC6nWPhqAGvo2GFzemya49nQqFdxZ6ut0ast h/Nw== 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=2gr9uQhmoic0JjKylvYgk0DQ7wBQwsufvFLwknClJPE=; b=UCd4kZBzS7+IMhaYZAu52062IrK8kOhrHdaeFvYUWgY/4IYyvhXgktu2He/ZU44b6w 2LjMFlTaYxm2a2rLyt7i6ZBxUmd+R7GmTekeAX89/eyZE1VVdaHHJRWqN2xyKBOXBWrS D4k/oqyoHQZK5neYeg48JHOyNYOBjIXPg12YkeOuBxdVPa2S4A/6PGPIWfi+XMqQy7JL Un2g4jkbc25s6uvTC0OevLkYqm6j2NufXpBjCVwD1vFhGcfCM3lSjiIMiZvlIF2VZhU0 BzenZ1pYB6YUefCwUaNRofYlLsTAqTzsqj8Jhw7P5QjU+tbEHYqCwZjg1b46OV3DCq7P LCjQ== X-Gm-Message-State: AG10YOTovxPcIFkRXOS1pxd+GhbnbBoOXXY0yUZ5ugb7iuEmIc3EW7qZDkzd91C3Shl/Cy2LiPyuWHu1zgReE/Al MIME-Version: 1.0 X-Received: by 10.107.132.162 with SMTP id o34mr29138656ioi.13.1453902637406; Wed, 27 Jan 2016 05:50:37 -0800 (PST) Received: by 10.64.26.98 with HTTP; Wed, 27 Jan 2016 05:50:37 -0800 (PST) In-Reply-To: <56A79A1D.5080402@bbn.com> References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <56A79A1D.5080402@bbn.com> Date: Wed, 27 Jan 2016 13:50:37 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: multipart/alternative; boundary=001a113f33e83de684052a511611 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] proposed CA/Subject changes 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, 27 Jan 2016 13:50:40 -0000 --001a113f33e83de684052a511611 Content-Type: text/plain; charset=UTF-8 On 26 January 2016 at 16:09, Stephen Kent wrote: > Ben, > > > On 11 January 2016 at 17:31, Karen Seo wrote: > >> Folks, >> >> I agree with the approach discussed on the list of simplifying 6962-bis >> to focus only on specifications for the CT log by moving the detailed >> specifications for other components of the CT system to other documents. This >> is in line with a message from Melinda on July 2 re: client behavior, and a >> message from Rich Saltz on July 6 re: the Auditor function. To >> facilitate moving requirements for the CA/Subject part of the system, I >> propose that we make the changes below with regard to statements about CT >> requirements for CA and Subject behavior. These changes will also help to address >> some of the concerns that have been cited elsewhere about the text of >> 6962-bis (e.g., issues 139, 140, 144). >> > > The tag "client behaviour" is an unfortunate choice, because it mixes up > various different concerns. The particular concern that was intended to be > separated was what clients do UI-wise in response to the presence of lack > of transparency information. > > I agree that the phrase "client behavior" is too broad. But, I also think > that not all of what > a client does in the lack of valid CT info is strictly a UI issue. For > example, Eran noted that the architecture doc distinguishes between what a > client does in the absence of an SCT vs. what > it does if there is an SCT but the sig fails. This, IMHO, is a legitimate > protocol issue that the > WG has not addressed. David took a position on this in his browser spec, > but that's just an > initial proposal that needs to be reviewed and discussed by the WG. > However, at least the issue is > clearly stated in that doc and thus provides a basis for discussion. > > Other client behaviour, such as following the protocol, is _not_ out of > scope for 6962-bis. Indeed, it seems counter-productive to remove it, since > that's the document implementers have to actually read in order to > implement CT. It makes no sense to define one side of a protocol in one > document and the other in another. > > The text in 6269-bis is still rather odd in discussing client behavior in > the protocol context. > It makes comments (not using standards language) about clients requiring > all connections to > be accompanied by SCTs: > > TLS clients can thus require that all certificates they accept as valid > are accompanied > by signed timestamps. > > If I were implementing a client this would sound like a requirement, > especially in the absence > of any RFC that purports to be a client spec. The text above is an example > of why I feel we > need an separate client spec that is clear about requirements. > Well, the reason this whole conversation started is because I don't believe the IETF is in a position to say what clients should do, which is why the language above is not normative (and appears in the introduction, so it seems pretty obvious to me it is explanatory in nature), and why I have very little interest in a client spec that says more than how to process CT information and what it means - which should be specified in 6962-bis. > > Similarly vague text appears elsewhere, e.g., > > Since certificates may not be accepted by TLS clients unless logged, ... > > How could that be less vague? That is the reality of the situation... > > The question of whether a (TLS) client is expected to contact a log > directly to acquire an STH is also > not clearly described with text like: > > When a client requests a log's latest STH ... > > Whether you need an STH depends on what you are trying to do. TLS clients may or may not need STHs, depending whether they care about verifying proofs... the I-D does explain when STHs are needed... > Since the next sentence refers to "marking clients" a reader may infer > that TLS clients > are required to acquire STHs. This is a more subtle issue than suggested > by this text. > A reader would be wrong to infer that, the point is that STHs could be used to mark individual clients, TLS or otherwise. Which is what the text says. > > In general, 6962-bis uses the term "client" to refer to all log clients, > but usage is > sometimes inconsistent, leading to ambiguity wrt TLS client (aka bowser) > requirements. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a113f33e83de684052a511611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 26 January 2016 at 16:09, Stephen Kent <kent@bbn.com> wrote:
=20 =20 =20
Ben,


On 11 January 2016 at 17:31, Karen Seo <kseo@bbn.com> wrote:
Folks,

I agree with the approach discussed on the list of simplifying 6962-bis to focus only on specifications for the CT log by moving the detailed specifications for other components of the CT system to other documents. This is in line with a message from Melinda on July 2 re: client behavior, and a message from Rich Saltz on July 6 re: the Auditor function. To facilitate moving requirements for the CA/Subject part of the system, I propose that we make the changes below with regard to statements about CT requirements for CA and Subject behavior.=C2=A0 These changes will also help to addr= ess some of the concerns that have been cited elsewhere about the text of 6962-bis (e.g., issues 139, 140, 144).

The tag "client behaviour" is an unfortunate cho= ice, because it mixes up various different concerns. The particular concern that was intended to be separated was what clients do UI-wise in response to the presence of lack of transparency information.
 I agree that the phrase "client behavior" is too broad. But, = I also think that not all of what
a client does in the lack of valid CT info is strictly a UI issue. For example, Eran noted that the architecture doc distinguishes between what a client does in the absence of an SCT vs. what
it does if there is an SCT but the sig fails. This, IMHO, is a legitimate protocol issue that the
WG has not addressed.=C2=A0 David took a position on this in his browse= r spec, but that's just an
initial proposal that needs to be reviewed and discussed by the WG. However, at least the issue is
clearly stated in that doc and thus provides a basis for discussion.
Other client behaviour, such as following the protocol, is _not_ out of scope for 6962-bis. Indeed, it seems counter-productive to remove it, since that's the documen= t implementers have to actually read in order to implement CT. It makes no sense to define one side of a protocol in one document and the other in another.
The text in 6269-bis is still rather odd in discussing client behavior in the protocol context.
It makes comments (not using standards language) about clients requiring all connections to
be accompanied by SCTs:
TLS clients can thus require that all certificates they accept as valid are accompanied
by signed timestamps.

If I were implementing a client this would sound like a requirement, especially in the absence
of any RFC that purports to be a client spec. The text above is an example of why I feel we
need an separate client spec that is clear about requirements.

Well, the reason this whole conversation = started is because I don't believe the IETF is in a position to say wha= t clients should do, which is why the language above is not normative (and = appears in the introduction, so it seems pretty obvious to me it is explana= tory in nature), and why I have very little interest in a client spec that = says more than how to process CT information and what it means - which shou= ld be specified in 6962-bis.
=C2=A0

Similarly vague text appears elsewhere, e.g.,

Since certificates may not be accepted by TLS clients unless logged, ...

=
How could that be less vague? That is the reality of the situation...= =C2=A0

The question of whether a (TLS) client is expected to contact a log directly to acquire an STH is also
not clearly described with text like:

When a client requests a log's latest STH ...

Whether you need an STH depen= ds on what you are trying to do. TLS clients may or may not need STHs, depe= nding whether they care about verifying proofs... the I-D does explain when= STHs are needed...
=C2=A0
Since the next sentence refers to "marking clients" a reader = may infer that TLS clients
are required to acquire STHs.=C2=A0 This is a more subtle issue than suggested by this text.

A rea= der would be wrong to infer that, the point is that STHs could be used to m= ark individual clients, TLS or otherwise. Which is what the text says.
=C2=A0

In general, 6962-bis uses the term "client" to refer to all l= og clients, but usage is
sometimes inconsistent, leading to ambiguity wrt TLS client (aka bowser) requirements.

Steve


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


--001a113f33e83de684052a511611-- From nobody Thu Jan 28 03:17:29 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 4E5611B3BA8; Thu, 28 Jan 2016 03:17:26 -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: <20160128111726.15030.48703.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 03:17:26 -0800 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-12.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: Thu, 28 Jan 2016 11:17:26 -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 : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-12.txt Pages : 47 Date : 2016-01-28 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 28 07:07: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 C096C1A88A3 for ; Thu, 28 Jan 2016 07:07: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 qg_NF1pJSfyX for ; Thu, 28 Jan 2016 07:07: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 559581A88B2 for ; Thu, 28 Jan 2016 07:07:44 -0800 (PST) Received: from localhost ([::1]:34355 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aOoAf-0001F5-1L; Thu, 28 Jan 2016 07:07: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, rob.stradling@comodo.com X-Trac-Project: trans Date: Thu, 28 Jan 2016 15:07:41 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/129#comment:2 Message-ID: <076.804c71a1d7a0e9349752bf00c8c24ae4@tools.ietf.org> References: <061.6a7a4081467b5b56cba1fe88f07de1a1@tools.ietf.org> X-Trac-Ticket-ID: 129 In-Reply-To: <061.6a7a4081467b5b56cba1fe88f07de1a1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20160128150744.559581A88B2@ietfa.amsl.com> Resent-Date: Thu, 28 Jan 2016 07:07:44 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #129 (rfc6962-bis): how do submitters determine what a log will accept? 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, 28 Jan 2016 15:07:46 -0000 #129: how do submitters determine what a log will accept? Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Moving to "review". Suggest to resolve as "duplicate". -- -------------------------+------------------------------------------------- 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 Thu Jan 28 07:19: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 2105D1A88B8 for ; Thu, 28 Jan 2016 07:19: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 WofpswGlO1gs for ; Thu, 28 Jan 2016 07:19:24 -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 50D8D1A88E1 for ; Thu, 28 Jan 2016 07:19:24 -0800 (PST) Received: from localhost ([::1]:34700 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aOoLz-0000vE-Sz; Thu, 28 Jan 2016 07:19: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: rob.stradling@comodo.com X-Trac-Project: trans Date: Thu, 28 Jan 2016 15:19:23 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/108#comment:2 Message-ID: <072.8701627aaeec702e12f444d1f1bef33e@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: Thu, 28 Jan 2016 15:19:30 -0000 #108: TLS session resumption: Server MUST NOT send SCTs Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Thu Jan 28 07:19: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 6C01E1A88E6 for ; Thu, 28 Jan 2016 07:19: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 Kspj_iYCk4fA for ; Thu, 28 Jan 2016 07:19: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 D8C031A88B8 for ; Thu, 28 Jan 2016 07:19:40 -0800 (PST) Received: from localhost ([::1]:34708 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aOoMD-0001ac-WF; Thu, 28 Jan 2016 07:19: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: rob.stradling@comodo.com, eranm@google.com, david@mandelberg.org X-Trac-Project: trans Date: Thu, 28 Jan 2016 15:19:37 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/126#comment:4 Message-ID: <076.76ff893ae9f99ff02ab9df321a226171@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, 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: Thu, 28 Jan 2016 15:19:48 -0000 #126: text leaves open the possibility that a submitter might not verify the returned SCT Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned -- ----------------------------------+--------------------------------------- Reporter: david@mandelberg.org | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------------------------- Ticket URL: trans From nobody Thu Jan 28 07:20: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 9EE3A1A88E9 for ; Thu, 28 Jan 2016 07:20:25 -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 hGjEf0NH9p4N for ; Thu, 28 Jan 2016 07:20:24 -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 2E7851A88E6 for ; Thu, 28 Jan 2016 07:20:24 -0800 (PST) Received: from localhost ([::1]:34761 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aOoMy-0004TL-1P; Thu, 28 Jan 2016 07:20: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 X-Trac-Project: trans Date: Thu, 28 Jan 2016 15:20:24 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/140#comment:1 Message-ID: <068.f638c1e3dfbb56b438d4da52cb23f940@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, 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: Thu, 28 Jan 2016 15:20:25 -0000 #140: move section 8 to CA specification Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned -- --------------------------+--------------------------------------- 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 Thu Jan 28 07:20: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 2E1C01A88EC for ; Thu, 28 Jan 2016 07:20: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 F7oj3a7Y5emm for ; Thu, 28 Jan 2016 07:20: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 206611A88EB for ; Thu, 28 Jan 2016 07:20:45 -0800 (PST) Received: from localhost ([::1]:34786 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aOoNI-0005rf-VQ; Thu, 28 Jan 2016 07:20: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: rob.stradling@comodo.com X-Trac-Project: trans Date: Thu, 28 Jan 2016 15:20:44 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/53#comment:1 Message-ID: <080.3f0eee2e0210c407c00525a086273aa7@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: Thu, 28 Jan 2016 15:20:46 -0000 #53: Clarify log entry ordering requirements Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: assigned Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Jan 28 10:22: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 BBD6B1B2F07 for ; Thu, 28 Jan 2016 10:22: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=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 d_0l8SERc9_u for ; Thu, 28 Jan 2016 10:22:30 -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 EAD481B2F03 for ; Thu, 28 Jan 2016 10:22:29 -0800 (PST) Received: from localhost ([::1]:47888 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aOrD6-0006Ob-3h; Thu, 28 Jan 2016 10:22: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, rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Thu, 28 Jan 2016 18:22:24 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/129#comment:3 Message-ID: <076.1ad4698646b4f97c3e20d506c5e937ba@tools.ietf.org> References: <061.6a7a4081467b5b56cba1fe88f07de1a1@tools.ietf.org> X-Trac-Ticket-ID: 129 In-Reply-To: <061.6a7a4081467b5b56cba1fe88f07de1a1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, 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: <20160128182229.EAD481B2F03@ietfa.amsl.com> Resent-Date: Thu, 28 Jan 2016 10:22:29 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #129 (rfc6962-bis): how do submitters determine what a log will accept? 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, 28 Jan 2016 18:22:30 -0000 #129: how do submitters determine what a log will accept? Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => duplicate -- -------------------------+------------------------------------------------- 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: duplicate Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jan 29 13:57: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 D6D6C1A88AD for ; Fri, 29 Jan 2016 13:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Iva4qRNqkGRn for ; Fri, 29 Jan 2016 13:57:18 -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 0C3B71A888C for ; Fri, 29 Jan 2016 13:57:17 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:33999 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aPH2a-000Ml1-A6 for trans@ietf.org; Fri, 29 Jan 2016 16:57:16 -0500 From: Stephen Kent To: trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <56A79A1D.5080402@bbn.com> Message-ID: <56ABE03C.2090807@bbn.com> Date: Fri, 29 Jan 2016 16:57:16 -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="------------000103080305090803050400" Archived-At: Subject: Re: [Trans] proposed CA/Subject changes 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, 29 Jan 2016 21:57:22 -0000 This is a multi-part message in MIME format. --------------000103080305090803050400 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ben, > > I agree that the phrase "client behavior" is too broad. But, I also > think that not all of what > > a client does in the lack of valid CT info is strictly a UI issue. > For example, Eran noted that the architecture doc distinguishes > between what a client does in the absence of an SCT vs. what > it does if there is an SCT but the sig fails. This, IMHO, is a > legitimate protocol issue that the > WG has not addressed. David took a position on this in his > browser spec, but that's just an > initial proposal that needs to be reviewed and discussed by the > WG. However, at least the issue is > clearly stated in that doc and thus provides a basis for discussion. >> Other client behaviour, such as following the protocol, is _not_ >> out of scope for 6962-bis. Indeed, it seems counter-productive to >> remove it, since that's the document implementers have to >> actually read in order to implement CT. It makes no sense to >> define one side of a protocol in one document and the other in >> another. > If 6962-bis were a complete spec for CT, then I would agree that it should specify all protocol aspects of behavior for clients, CAs, Web Servers, Monitors, and Auditors. But, the architecture document and the companion requirement specs for the CA/Subject, Monitor/Auditor and Browser/vendor illustrate that 6962-bis is far from a comprehensive requirements spec. > > ... > > > Well, the reason this whole conversation started is because I don't > believe the IETF is in a position to say what clients should do, which > is why the language above is not normative (and appears in the > introduction, so it seems pretty obvious to me it is explanatory in > nature), and why I have very little interest in a client spec that > says more than how to process CT information and what it means - which > should be specified in 6962-bis. I have a problem deciding what is in and out of scope when you use phrases like "what clients should do." I believe an well-written spec for CT should make clear exactly what is mandated and what is a local policy decision for a TLS client (as well as for other CT system elements). I find the text in 6962-bis to be inadequate in this regard. If you read draft-dseomn-trans-browsers-00.txt you'd see what I view as an appropriate level of specification for an IETF standard. The example I cited about differences in how a browser should react to a missing SCT vs. an invalid SCT is a good example of what I view as within scope when specifying a protocol. Note that I have not said anything about the ability of a browser to discriminate against a cert with no accompanying SCT in terms of the UI. The browser spec I mentioned specifically says that is a local matter. > > > Similarly vague text appears elsewhere, e.g., > > Since certificates may not be accepted by TLS clients unless > logged, ... > > > How could that be less vague? That is the reality of the situation... This is a good example of where we seem to disagree about what constitutes appropriate language for a standards track RFC. I have long argued that it is unacceptable for browsers to reject a cert because it is not accompanied by an SCT, until there is a backwards compatible transition mechanism codified in an RFC. Your stance appears to be that what a browser does in this regard (which I consider a basic protocol issue that should be in scope) is not subject to IETF standardization, and hence it's OK to use deliberately vague phrases. We have a fundamental disagreement here. > > > ... > > > Whether you need an STH depends on what you are trying to do. TLS > clients may or may not need STHs, depending whether they care about > verifying proofs... the I-D does explain when STHs are needed... I still view the text as needlessly ambiguous. Again, please look at the requirements specs we posted in late December as examples of how to be clear in this regard. > > Since the next sentence refers to "marking clients" a reader may > infer that TLS clients > are required to acquire STHs. This is a more subtle issue than > suggested by this text. > > > A reader would be wrong to infer that, the point is that STHs could be > used to mark individual clients, TLS or otherwise. Which is what the > text says. The text also strikes me as needlessly vague. I have authored about 25 RFCs, 18 of which are standards track, and 3 or 4 of which are BCPs. I think my experience in this regard makes me a good judge of what constitutes a well-written, standards track security area RFC. I'm sorry to say that 6962-bis (v-11) is not. Steve --------------000103080305090803050400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,



I agree that the phrase "client behavior" is too broad. But, I also think that not all of what
a client does in the lack of valid CT info is strictly a UI issue. For example, Eran noted that the architecture doc distinguishes between what a client does in the absence of an SCT vs. what
it does if there is an SCT but the sig fails. This, IMHO, is a legitimate protocol issue that the
WG has not addressed.  David took a position on this in his browser spec, but that's just an
initial proposal that needs to be reviewed and discussed by the WG. However, at least the issue is
clearly stated in that doc and thus provides a basis for discussion.
Other client behaviour, such as following the protocol, is _not_ out of scope for 6962-bis. Indeed, it seems counter-productive to remove it, since that's the document implementers have to actually read in order to implement CT. It makes no sense to define one side of a protocol in one document and the other in another.
If 6962-bis were a complete spec for CT, then I would agree that it should specify all
protocol aspects of behavior for clients, CAs, Web Servers, Monitors, and Auditors. But, the
architecture document and the companion requirement specs for the CA/Subject, Monitor/Auditor
and Browser/vendor illustrate that 6962-bis is far from a comprehensive requirements spec.
...

Well, the reason this whole conversation started is because I don't believe the IETF is in a position to say what clients should do, which is why the language above is not normative (and appears in the introduction, so it seems pretty obvious to me it is explanatory in nature), and why I have very little interest in a client spec that says more than how to process CT information and what it means - which should be specified in 6962-bis.
I have a problem deciding what is in and out of scope when you use phrases like "what clients should do."
I believe an well-written spec for CT should make clear exactly what is mandated and what is a local
policy decision for a TLS client (as well as for other CT system elements). I find the text in 6962-bis
to be inadequate in this regard. If you read draft-dseomn-trans-browsers-00.txt you'd see what I view
as an appropriate level of specification for an IETF standard. The example I cited about differences
in how a browser should react to a missing SCT vs. an invalid SCT is a good example of what I view
as within scope when specifying a protocol. Note that I have not said anything about the ability
of a browser to discriminate against a cert with no accompanying SCT in terms of the UI. The browser
spec I mentioned specifically says that is a local matter.
 

Similarly vague text appears elsewhere, e.g.,

Since certificates may not be accepted by TLS clients unless logged, ...

How could that be less vague? That is the reality of the situation...
This is a good example of where we seem to disagree about what constitutes appropriate language for a standards track RFC. I have long argued that it is unacceptable for browsers to reject a cert because
it is not accompanied by an SCT, until there is a backwards compatible transition mechanism codified
in an RFC. Your stance appears to be that what a browser does in this regard (which I consider a
basic protocol issue that should be in scope) is not subject to IETF standardization, and hence it's
OK to use deliberately vague phrases. We have a fundamental disagreement here.

...

Whether you need an STH depends on what you are trying to do. TLS clients may or may not need STHs, depending whether they care about verifying proofs... the I-D does explain when STHs are needed...
I still view the text as needlessly ambiguous. Again, please look at the requirements specs we posted
in late December as examples of how to be clear in this regard.
 
Since the next sentence refers to "marking clients" a reader may infer that TLS clients
are required to acquire STHs.  This is a more subtle issue than suggested by this text.

A reader would be wrong to infer that, the point is that STHs could be used to mark individual clients, TLS or otherwise. Which is what the text says.
The text also strikes me as needlessly vague.

I have authored about 25 RFCs, 18 of which are standards track, and 3 or 4 of which are BCPs.
I think my experience in this regard makes  me a good judge of what constitutes a well-written,
standards track security area RFC. I'm sorry to say that 6962-bis (v-11) is not.

Steve


--------------000103080305090803050400-- From nobody Fri Jan 29 14:05: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 8CEE31A89F1 for ; Fri, 29 Jan 2016 14:05:29 -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 RI_JesPOavXW for ; Fri, 29 Jan 2016 14:05:28 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 6A1A51A89F0 for ; Fri, 29 Jan 2016 14:05:28 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id x125so48857744pfb.0 for ; Fri, 29 Jan 2016 14:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=nBSbe36oLeJe3AFoyVDrSdQHTEGn9hpSdxQPhtZzVUA=; b=YisjK8YcpxXAkcVkH2ji6j7A9nvoBPXG83I+yZV54Hqm/h3kyWFDOBmYfVIF24VANd 8YFO/yCDxXjrGyPhZS9I0r9gNe5AbxcJkkARR+2LzPZlkhymiSAucK0m00bEmvWxb/Y8 mlKnV4hDf0Ox5g79m6X72f/IRtseTqzph36/Rn5estWXym6ieYKzeyfcaMa5r4x0AwO7 HJkBJwmWm7aESX5meTUSxCRpYmnulEqSJpyUCkKRqTv263KaiiiDcUImSd5DLaS0+bbK +bWkTGqs/GEabb2uOisybHSkca8187M+PA+/p+VYthwfwYih/gABGrbpI9zFnbWK7QJa cCug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nBSbe36oLeJe3AFoyVDrSdQHTEGn9hpSdxQPhtZzVUA=; b=gsA+EnS5/pM3uwEeGe5IWymKldJWboSGiL6bo2tKIAR3ltRDUh//PuEOAUGH0lUMbY Q+Po47c2mYnkTfhVkCAn+i45TLPv85lVaTDNq+V7BJigdpjpWTV7JiimwjBzV9pxeSxT uxkwuayAm76I50DwdrD2QOGOcHEPBAKLRKrvvMOihiR5nTlKx3JLBhmSVZYC/sPYylMc zxQqQyKyVCLhzPua7RquWkIeOCGYKEpbYUCUCuHMXaYsyggthXtMs5nhmv88A2WXCxWo U+AdS9xiM8G1tt4Gu5E/0Oo2ac0wOgukOjIIsnFMUTY0Dr23YJSNa8VwJpShMAH9YPov ha1g== X-Gm-Message-State: AG10YOQWN2RHVe83eIXmqtVClzdgXBX7ahrXvf7zSeM8tgNFWGnIkFKA3jjz6gsxgQL0VQ== X-Received: by 10.98.74.71 with SMTP id x68mr16901722pfa.80.1454105127991; Fri, 29 Jan 2016 14:05:27 -0800 (PST) Received: from Melindas-MacBook-Pro.local (216-67-7-60-radius.dynamic.acsalaska.net. [216.67.7.60]) by smtp.googlemail.com with ESMTPSA id f12sm25730453pat.20.2016.01.29.14.05.26 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 14:05:27 -0800 (PST) To: trans@ietf.org References: <567C23EE.1040808@bbn.com> <5693E6F9.2090101@bbn.com> <56A79A1D.5080402@bbn.com> <56ABE03C.2090807@bbn.com> From: Melinda Shore Message-ID: <56ABE205.5010503@gmail.com> Date: Fri, 29 Jan 2016 13:04:53 -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 In-Reply-To: <56ABE03C.2090807@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] proposed CA/Subject changes 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, 29 Jan 2016 22:05:29 -0000 On 1/29/16 12:57 PM, Stephen Kent wrote: > I have authored about 25 RFCs, 18 of which are standards track, and 3 > or 4 of which are BCPs. I think my experience in this regard makes > me a good judge of what constitutes a well-written, standards track > security area RFC. I'm sorry to say that 6962-bis (v-11) is not. Please stick to technical discussion. Thanks. Melinda