From nobody Wed Jul 1 02:57:38 2015 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 0A2781A8BB6 for ; Wed, 1 Jul 2015 02:57:37 -0700 (PDT) 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 PSlnPBL6QAUD for ; Wed, 1 Jul 2015 02:57:35 -0700 (PDT) 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 CD3821B2D25 for ; Wed, 1 Jul 2015 02:56:51 -0700 (PDT) Received: from localhost ([::1]:34157 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAEl9-0004w2-23; Wed, 01 Jul 2015 02:56:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 01 Jul 2015 09:56:51 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/92 Message-ID: <064.d9fa313d805f15d47ba200812a5627d6@tools.ietf.org> X-Trac-Ticket-ID: 92 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #92 (rfc6962-bis): get-entries needs to return the whole X509ChainEntry 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, 01 Jul 2015 09:57:37 -0000 #92: get-entries needs to return the whole X509ChainEntry The "extra_data" returned by get-entries currently says: 'In the case of an X509ChainEntry, this is the "certificate_chain"' This is insufficient. A client that calls get-entries also needs the actual leaf certificate, so that they may verify that the leaf cert really was signed by the appropriate CA private key. (Without this, the client would have to trust that the log performed that verification, unless the client happens to stumble upon that particular leaf cert some other source). -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Jul 1 03:58:18 2015 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 7C23A1B2DEF for ; Wed, 1 Jul 2015 03:58:16 -0700 (PDT) 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 FU-q49RWOSJ5 for ; Wed, 1 Jul 2015 03:58:15 -0700 (PDT) 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 5DA001B2DD9 for ; Wed, 1 Jul 2015 03:58:15 -0700 (PDT) Received: from localhost ([::1]:38167 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAFiY-0005Kr-Dz; Wed, 01 Jul 2015 03:58:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Wed, 01 Jul 2015 10:58:14 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/86#comment:1 Message-ID: <070.f8fe6d4cace2ce11cab535cd6e2420d5@tools.ietf.org> References: <055.e79a51ea71a962f252e762da97b30a02@tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <055.e79a51ea71a962f252e762da97b30a02@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150701105815.5DA001B2DD9@ietfa.amsl.com> Resent-Date: Wed, 1 Jul 2015 03:58:15 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #86 (rfc6962-bis): SCTs should be returned in final format 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, 01 Jul 2015 10:58:16 -0000 #86: SCTs should be returned in final format Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/benlaurie/certificate-transparency- rfcs/commit/2cc206af1e4d1e29556ba6ab290845c2612f24be. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Jul 1 04:21:45 2015 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 C544B1A1EF5 for ; Wed, 1 Jul 2015 04:21:43 -0700 (PDT) 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 81EnCg2K8rqw for ; Wed, 1 Jul 2015 04:21:42 -0700 (PDT) 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 6BC651A1C04 for ; Wed, 1 Jul 2015 04:21:42 -0700 (PDT) Received: from localhost ([::1]:39939 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAG4w-0005jc-Nv; Wed, 01 Jul 2015 04:21:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 01 Jul 2015 11:21:21 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/92#comment:1 Message-ID: <079.6310ef4e44ba1a18e223968b60044154@tools.ietf.org> References: <064.d9fa313d805f15d47ba200812a5627d6@tools.ietf.org> X-Trac-Ticket-ID: 92 In-Reply-To: <064.d9fa313d805f15d47ba200812a5627d6@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] #92 (rfc6962-bis): get-entries needs to return the whole X509ChainEntry 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, 01 Jul 2015 11:21:43 -0000 #92: get-entries needs to return the whole X509ChainEntry Changes (by rob.stradling@comodo.com): * status: new => closed * resolution: => needs-review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/7793e62f8f7ec7d95fac308fbe800539b1749b4a -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: needs-review Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Jul 1 06:32:02 2015 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 DEE6C1A88C8 for ; Wed, 1 Jul 2015 06:31:58 -0700 (PDT) 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 cyTqtA5McsGM for ; Wed, 1 Jul 2015 06:31:53 -0700 (PDT) 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 509AD1A88BA for ; Wed, 1 Jul 2015 06:31:52 -0700 (PDT) Received: from localhost ([::1]:48311 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAI78-0004R6-2v; Wed, 01 Jul 2015 06:31:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Wed, 01 Jul 2015 13:31:46 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:2 Message-ID: <071.c81f364e44d1309a40428e9c5ce00b63@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the Precertificate 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, 01 Jul 2015 13:31:59 -0000 #80: Re-introduce the issuer key hash into the Precertificate Comment (by benl@google.com): I don't understand this problem. The I-D says "SignedData.signerInfos MUST contain a signature from the same (root or intermediate) CA that will ultimately issue the certificate." signerInfos includes "SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier }" Surely this is sufficient to identify the issuer? -- ------------------------------+--------------------------------------- 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 Wed Jul 1 06:44:13 2015 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 2915C1A7034 for ; Wed, 1 Jul 2015 06:44:12 -0700 (PDT) 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 2e_XZZ59Uoqc for ; Wed, 1 Jul 2015 06:44:11 -0700 (PDT) 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 D3E661A1A60 for ; Wed, 1 Jul 2015 06:44:10 -0700 (PDT) Received: from localhost ([::1]:48862 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAIJ6-0000ex-NG; Wed, 01 Jul 2015 06:44:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Wed, 01 Jul 2015 13:44:08 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:3 Message-ID: <071.0e33f7e0f64992400b08b54ac3d2e938@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the Precertificate 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, 01 Jul 2015 13:44:12 -0000 #80: Re-introduce the issuer key hash into the Precertificate Comment (by benl@google.com): On the analogous situation for X.509, the extra_data included with the entry includes the certificate itself and the chain of signers, so again, this seems unnecessary. -- ------------------------------+--------------------------------------- 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 Wed Jul 1 09:59:37 2015 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 33FD41A92FB for ; Wed, 1 Jul 2015 09:59:36 -0700 (PDT) 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 tXjZKZfy_hpB for ; Wed, 1 Jul 2015 09:59:34 -0700 (PDT) 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 D76561A92F8 for ; Wed, 1 Jul 2015 09:59:34 -0700 (PDT) Received: from localhost ([::1]:59802 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZALMA-0008Kn-Ob; Wed, 01 Jul 2015 09:59:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Wed, 01 Jul 2015 16:59:30 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:4 Message-ID: <071.ac1382a23021309632a3cfb2c9ac8ce0@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the Precertificate 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, 01 Jul 2015 16:59:36 -0000 #80: Re-introduce the issuer key hash into the Precertificate Comment (by rob.stradling@comodo.com): This problem affects browser clients and any other client that wants to verify that an SCT corresponds to a particular cert. A browser has the full cert chain (from the TLS handshake) and the corresponding SCTs, but it is _not_ expected to have the full log entries (i.e. extra_data, etc). In the current text, the SCT is bound to the Issuer Name (because that's in the TBSCertificate), but not to the Issuer Key (because that's not in the TBSCertificate). There could exist two or more publicly-trusted intermediate CA certs with the same Name but different Keys. One of those intermediates might be logged, while the other(s) are not logged. Each of them could issue leaf certs that have an identical TBSCertificate. Only one of those leaf certs needs to be logged for there to exist SCT(s) that are valid for all of those leaf certs. The logged leaf cert might get revoked, but the other(s) might not get revoked. However, the SCT(s) would still work for all of those certs, including the non-logged ones. Therefore, we need to fix SCTs so that they're bound to the Issuer Key Hash as well as the Issuer Name. -- ------------------------------+--------------------------------------- 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 Wed Jul 1 10:03:08 2015 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 CD5441A90E7 for ; Wed, 1 Jul 2015 10:03:06 -0700 (PDT) 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 aPQ9iQUZcX7e for ; Wed, 1 Jul 2015 10:03:04 -0700 (PDT) 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 5A7AF1AC39D for ; Wed, 1 Jul 2015 10:03:04 -0700 (PDT) Received: from localhost ([::1]:59962 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZALPa-0001ik-CF; Wed, 01 Jul 2015 10:03:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Wed, 01 Jul 2015 17:03:02 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:5 Message-ID: <071.6ac4cec67ee681ae48b4dc6ae7ab15e8@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the SCT (was: Re-introduce the issuer key hash into the Precertificate) 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, 01 Jul 2015 17:03:07 -0000 #80: Re-introduce the issuer key hash into the SCT Comment (by rob.stradling@comodo.com): Just noticed an error in the summary. Perhaps that was the cause of the confusion. -- ------------------------------+--------------------------------------- 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 Jul 2 07:00:27 2015 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 440C81A89FA for ; Thu, 2 Jul 2015 07:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4jIPXCihQtM8 for ; Thu, 2 Jul 2015 07:00:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A381AC39E for ; Thu, 2 Jul 2015 07:00:05 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:43691 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZAf22-000NZT-1N; Thu, 02 Jul 2015 10:00:02 -0400 Message-ID: <559543E1.6010501@bbn.com> Date: Thu, 02 Jul 2015 10:00:01 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans issue tracker , rob.stradling@comodo.com, benl@google.com References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> <071.ac1382a23021309632a3cfb2c9ac8ce0@tools.ietf.org> In-Reply-To: <071.ac1382a23021309632a3cfb2c9ac8ce0@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the Precertificate 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, 02 Jul 2015 14:00:19 -0000 Rob, I agree with your conclusoon that inclusion of the issuer public key hash will enable a browser to verify the correspondence between an SCT without interacting with a log. Even though we don't yet have a browser behavior spec, I agree that this is a good candidate behavior to enable. Do you propose this as an extension to the current SCT format, or a change to the format? If you propose a change, then I'll argue that my proposed cert type declaration and checks performed fields also should be included, since we'll be making a not backward compatible change to the SCT. If this is an (optional) extension, then I guess my proposed fields can be the second and third extensions defined. Steve > #80: Re-introduce the issuer key hash into the Precertificate > > > Comment (by rob.stradling@comodo.com): > > This problem affects browser clients and any other client that wants to > verify that an SCT corresponds to a particular cert. A browser has the > full cert chain (from the TLS handshake) and the corresponding SCTs, but > it is _not_ expected to have the full log entries (i.e. extra_data, etc). > > In the current text, the SCT is bound to the Issuer Name (because that's > in the TBSCertificate), but not to the Issuer Key (because that's not in > the TBSCertificate). > > There could exist two or more publicly-trusted intermediate CA certs with > the same Name but different Keys. One of those intermediates might be > logged, while the other(s) are not logged. Each of them could issue leaf > certs that have an identical TBSCertificate. Only one of those leaf certs > needs to be logged for there to exist SCT(s) that are valid for all of > those leaf certs. > > The logged leaf cert might get revoked, but the other(s) might not get > revoked. However, the SCT(s) would still work for all of those certs, > including the non-logged ones. > > Therefore, we need to fix SCTs so that they're bound to the Issuer Key > Hash as well as the Issuer Name. > From nobody Thu Jul 2 07:19:26 2015 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 DC8AB1A6FF5 for ; Thu, 2 Jul 2015 07:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 U_G3B8rUobeO for ; Thu, 2 Jul 2015 07:19:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D2C1A711A for ; Thu, 2 Jul 2015 07:19:22 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:35340 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZAfKj-0000M6-G7 for trans@ietf.org; Thu, 02 Jul 2015 10:19:21 -0400 Message-ID: <55954869.6020700@bbn.com> Date: Thu, 02 Jul 2015 10:19:21 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] clarification on scope of 6962-bis 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, 02 Jul 2015 14:19:25 -0000 Based on several issuer tracker comments from yesterday I believe there's an evolving agreement that 6962-bis is really just a description of log operation and interfaces, and that specs for browsers, Monitors and the Audit function will appear elsewhere. Is this interpretation correct? Steve From nobody Thu Jul 2 08:39:53 2015 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 F26D71AC436 for ; Thu, 2 Jul 2015 08:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZueAZ67zd2bh for ; Thu, 2 Jul 2015 08:39:51 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 DF4571AC427 for ; Thu, 2 Jul 2015 08:39:50 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so46986155pdb.2 for ; Thu, 02 Jul 2015 08:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VIO+XmOA7/pMcB7xebje9adagDodZ3e+KO5M5iw6qsM=; b=S+ncyfL5ukk61gz1C8SFn+RJC29sMz6EIUiZHstgPJ9rGJv7Hmyg/ANyg7oWmWagkj 0tHZzqjdX+5m3AGXKclLW8/zBN7+qL4jW/+JoFDUVJ25EBngjdqkhw2D8OAPAaj0Xup1 flG1QNVPQjCRx5xnnbM90zWYMnmIklF04zUvGzRX7SkaxXjGy8LN1zTsmL7QNvQN0d/9 9GPzg8xi8CtH6sk6/f+cNSr2C7HAswvbTCdyzUt/BYSA9u97riuoqpGigweDr6K9iCIV u7oguRltnugd/RV95a7eCbzKqPnodA3D+Y4ZRmt/5mxiEk8Np0neBuK4Tl4HgfkgnRH/ ZF/A== X-Received: by 10.68.225.97 with SMTP id rj1mr68183662pbc.108.1435851590497; Thu, 02 Jul 2015 08:39:50 -0700 (PDT) Received: from spandex.local ([216.67.56.233]) by mx.google.com with ESMTPSA id da2sm6074897pbb.57.2015.07.02.08.39.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2015 08:39:49 -0700 (PDT) Message-ID: <55955B43.2000103@gmail.com> Date: Thu, 02 Jul 2015 07:39:47 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <55954869.6020700@bbn.com> In-Reply-To: <55954869.6020700@bbn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] clarification on scope of 6962-bis 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, 02 Jul 2015 15:39:52 -0000 On 7/2/15 6:19 AM, Stephen Kent wrote: > Based on several issuer tracker comments from yesterday I believe there's > an evolving agreement that 6962-bis is really just a description of log > operation and interfaces, and that specs for browsers, Monitors and the > Audit function will appear elsewhere. > Is this interpretation correct? We've been talking over lo, these many months about the need for a separate document describing client behavior. Melinda From nobody Thu Jul 2 09:25:54 2015 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 8BD531ACEAF; Thu, 2 Jul 2015 09:25:52 -0700 (PDT) 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 blFa3plsSzQj; Thu, 2 Jul 2015 09:25:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 651091A90AE; Thu, 2 Jul 2015 09:25:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702162551.30258.91747.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 09:25:51 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-01.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, 02 Jul 2015 16:25:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Attack Model for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-01.txt Pages : 22 Date : 2015-06-30 Abstract: This document describes an attack model for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates will be developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-01 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 Jul 2 09:34:39 2015 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 724EA1AD182 for ; Thu, 2 Jul 2015 09:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEU6Mu_ZEMVo for ; Thu, 2 Jul 2015 09:34:35 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 A3D3A1AD1EC for ; Thu, 2 Jul 2015 09:34:19 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so43004960pab.1 for ; Thu, 02 Jul 2015 09:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UDt3Xf5lfY2MZ5aaHCZwtgfdscmemZvKm9Ix3Z5K5Xw=; b=zGhi8P8GpdTCpEEAjQ3swaHtb43KWD6Lpdybnfhv6rlfrS0gk55pLJry3LeIghedYa NFO0L2A2LKr0DqELrsu0S3iu9+E8pJSFvQlw8mSF2f0QVtqq8Vn2V9/zvdks1+pihrhE dVmFwxzvAeuYRzCpxQnNnuR1oiCFHsxl+gdbnYH7wjYvwz8DZa2Pcg5Sx88JJbUkpPKT /lTYYOxCaFBrAptewTBntgyfGv6ddA2aS3ydFGxwKjDyISsPRahpDs1voBZM5UZa9mrV 38KAGnBIdz7bljjQnrOWkLaKhGJE7Te0Kzf3ZmoVcK1e/E8y4aRXR+1/PS3DoCUmA/mw Sl0Q== X-Received: by 10.70.90.162 with SMTP id bx2mr61851312pdb.60.1435854859286; Thu, 02 Jul 2015 09:34:19 -0700 (PDT) Received: from spandex.local ([216.67.56.233]) by mx.google.com with ESMTPSA id kh6sm6200574pbc.50.2015.07.02.09.34.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2015 09:34:18 -0700 (PDT) Message-ID: <55956808.9030502@gmail.com> Date: Thu, 02 Jul 2015 08:34:16 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <20150702162551.30258.91747.idtracker@ietfa.amsl.com> In-Reply-To: <20150702162551.30258.91747.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150702162551.30258.91747.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-01.txt 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, 02 Jul 2015 16:34:37 -0000 Note that a revision of the threat analysis draft has been posted. Please give it a read and post comments to the mailing list. Thanks, Melinda -------- Forwarded Message -------- Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-01.txt Date: Thu, 02 Jul 2015 09:25:51 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: trans@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Attack Model for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-01.txt Pages : 22 Date : 2015-06-30 Abstract: This document describes an attack model for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates will be developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-01 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/ _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Thu Jul 2 10:36:22 2015 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 EB4C01A1A03 for ; Thu, 2 Jul 2015 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vbQPowtvnmnN for ; Thu, 2 Jul 2015 10:36:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BE21A0AF1 for ; Thu, 2 Jul 2015 10:36:10 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:46579 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZAiPB-0003Zu-6i for trans@ietf.org; Thu, 02 Jul 2015 13:36:09 -0400 Message-ID: <55957688.3070506@bbn.com> Date: Thu, 02 Jul 2015 13:36:08 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <20150702162551.30258.91747.idtracker@ietfa.amsl.com> <55956808.9030502@gmail.com> In-Reply-To: <55956808.9030502@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-01.txt 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, 02 Jul 2015 17:36:16 -0000 As Melinda noted, the threat analysis doc has been revised and posted. Two major classes of edits have been made: - changes based on feedback from folks on the list, consistent with my replies. The title was changed ("attack model"), several sections were revised, and the term "misbehaving" is now used instead of "malicious or conspiring." - an expanded intro that provides a high level background and description of the CT architecture, including a diagram derived from DKG's slides at a previous meeting I'm not sure if the intro text needs to be in this doc. It seems more appropriate for an architecture doc, but we don't have one (yet). Also, although I have included some text about browser behavior, the description is not complete. I believe there is work ongoing to generate a Monitor spec, and maybe a separate client spec plus an arch doc would be the best way to have a complete, modular set of CT docs. I suggest we re-cast 6962-bis as a spec only for the log, the nexus of CT. Comments welcome, as always. Steve From nobody Thu Jul 2 11:37:40 2015 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 C626C1A88AB for ; Thu, 2 Jul 2015 11:37:39 -0700 (PDT) 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 MF7w-KMNNSBN for ; Thu, 2 Jul 2015 11:37:38 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::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 1A6A61A88A5 for ; Thu, 2 Jul 2015 11:37:38 -0700 (PDT) Received: by ykfy125 with SMTP id y125so76401985ykf.1 for ; Thu, 02 Jul 2015 11:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=1nE8jqzp/AZTOk/s/++n4g1wtFxJDJyA1Dt1IKlo3Xo=; b=jcqXsRTXEuvY17VIxbZM8zkGPcTOWQANS8z8hrlmcTwGwPR1QVm4RSGHSqzTHHXyAE +tbvQZkwyf0Nu7b5IuVFKADvrgXXRgjgl1BOgZV43lBtx4WuQ22nzAvUYlQFcIOlwRTw wP6OtHxpTD2VYtKxmNINVO2BoiEToM39LG1Ie/ijJbnqZav+PxAaJKpD6MDb9nY7pBT2 94NuMQ9aL5yUoC5lYBSHCQ/ZYWKsw4Wi43qqk+KhEmL7YvNuiLY6F63dunMwNvnBfslo OdjAb8FrfqYzMQ3pUJJVy4DLhErp2svGratksbHpcfEubrZBZOLRSHxTeL5S0GN8yjMA JfRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=1nE8jqzp/AZTOk/s/++n4g1wtFxJDJyA1Dt1IKlo3Xo=; b=Ru4P+CKDt16MEZ4GNpQAXMWroZvRqJzRW9IpzeIRHszrnnmZ31rqWSiUIviEH4YK/t MCJAwzSqiYI04A8LK09wtsaQUlvb05gbZjIfhkFtt2NcDybukUcIXCDU0aDkXG2JTFuH pxNUwgr7U83qMMKblaFgsy3iqglHQaImhx489O1kpAYqTS/N2vm0oQMScswIArBcAOnu L2P/fKNDmSuoUIb0qYi8pGa2N/w7vfIBSbsu/g+9Qm0iCCWt/q/0Sh+dQrw6K8dHCMVW ITHjVjqccngUXZ3B8ZVycz2F0ENqq/kOG/JglDGqovx3HsGluW2kptrl5MJYrRkUNJph xmvw== X-Gm-Message-State: ALoCoQkEVDbv2aUmV2r6Ek/myxOpGUuaxsM653AJenDDcB1Lsic5fSB0ELaKmL6on7NG9F/YLBTG X-Received: by 10.13.203.83 with SMTP id n80mr40269976ywd.10.1435862257423; Thu, 02 Jul 2015 11:37:37 -0700 (PDT) MIME-Version: 1.0 References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> <20150629230458.GX30545@hezmatt.org> In-Reply-To: From: Adam Eijdenberg Date: Thu, 02 Jul 2015 18:37:26 +0000 Message-ID: To: Ben Laurie , Matt Palmer Content-Type: multipart/alternative; boundary=001a11481e0acd1d0e0519e8bbf1 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Verifying inclusion proof 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, 02 Jul 2015 18:37:39 -0000 --001a11481e0acd1d0e0519e8bbf1 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 5:30 AM Ben Laurie wrote: > > That document doesn't appear to be referenced in 6962bis, nor would it, I > > assume, answer the question "how is the inclusion proof represented in > the > > response to get-sth-consistency". > > Fair enough. Do you have proposed text? > While I think the RFC (section 2.1.2) is quite clear enough on how the inclusion proof is represented in the response to get-sth-consistency, what I found very difficult is how to actually apply it to verify consistency. I wrote the following description of an algorithm I adapted from the open-source code that I believe is correct. Would that be helpful? To verify the consistency of a Merkle tree given this output the following algorithm may be used: 1. If first is a power of 2, then prepend the consistency array with the Merkle tree hash from the existing STH for the first tree size. 2. Set "fn" to (first - 1) and "sn" to (second - 1). 3. If LSB(fn) is set, then right-shift both fn and sn equal times until LSB(fn) is not set. 4. Set "first_hash" and "second_hash" to the first value in the consistency array. 5. For each subsequent value in the consistency array: If the LSB(fn) is set, or if fn is equal to sn, then: a. Apply the current value of the consistency array to the left of both the first_hash and second_hash to compute a new first_hash and second_hash respectively. b. If LSB(fn) is not set, then right-shift both fn and fn equal times until LSB(fn) is set. Otherwise: c. Apply the current value of the consistency array to the right of just the second_hash to compute a new second_hash. Finally, right-shift both fn and sn one time. After completing iterating through the consistency array as described above first_hash and second_hash should be compared against the Merkle tree hashes for the existing STHs for first and second respectively. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11481e0acd1d0e0519e8bbf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 30= , 2015 at 5:30 AM Ben Laurie <benl@go= ogle.com> wrote:
> That document doesn't appear to be referenced in 6962bis, nor woul= d it, I
> assume, answer the question "how is the inclusion proof represent= ed in the
> response to get-sth-consistency".

Fair enough. Do you have proposed text?

While I think the RFC (section 2.1.2) is quite clear enough on how the inc= lusion proof is represented in the response to get-sth-consistency, what I = found very difficult is how to actually apply it to verify consistency.

I wrote the following description of an algorithm I a= dapted from the open-source code that I believe is correct.=C2=A0 Would tha= t be helpful?


To verify the co= nsistency of a Merkle tree given this output the following algorithm may be= used:

1. If first is a power of 2, then prepend t= he consistency array with the Merkle tree hash from the existing STH for th= e first tree size.

2. Set "fn" to (first= - 1) and "sn" to (second - 1).

3. If LS= B(fn) is set, then right-shift both fn and sn equal times until LSB(fn) is = not set.

4. Set "first_hash" and "s= econd_hash" to the first value in the consistency array.
5. For each subsequent value in the consistency array:

=C2=A0 =C2=A0If the LSB(fn) is set, or if fn is equal to s= n, then:
=C2=A0 =C2=A0
=C2=A0 =C2=A0a. Apply the curren= t value of the consistency array to the left of both the first_hash and sec= ond_hash to compute a new first_hash and second_hash respectively.
=C2=A0 =C2=A0b. If LSB(fn) is not set, then right-shift both fn and fn eq= ual times until LSB(fn) is set.
=C2=A0 =C2=A0
=C2=A0 = =C2=A0Otherwise:
=C2=A0 =C2=A0
=C2=A0 =C2=A0c. Apply th= e current value of the consistency array to the right of just the second_ha= sh to compute a new second_hash.
=C2=A0 =C2=A0
=C2=A0 = =C2=A0Finally, right-shift both fn and sn one time.

After completing iterating through the consistency array as described abo= ve first_hash and second_hash should be compared against the Merkle tree ha= shes for the existing STHs for first and second respectively.



=C2=A0

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a11481e0acd1d0e0519e8bbf1-- From nobody Fri Jul 3 07:32:35 2015 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 5E84B1A1A02 for ; Fri, 3 Jul 2015 07:32:33 -0700 (PDT) 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 gMdVjhT5DUKJ for ; Fri, 3 Jul 2015 07:32:29 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E681A03FF for ; Fri, 3 Jul 2015 07:32:25 -0700 (PDT) Received: (qmail 1902 invoked by uid 1004); 3 Jul 2015 14:32:23 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 03 Jul 2015 15:32:23 +0100 Received: (qmail 15053 invoked by uid 1000); 3 Jul 2015 14:32:23 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 03 Jul 2015 15:32:23 +0100 Message-ID: <55969CF7.9040305@comodo.com> Date: Fri, 03 Jul 2015 15:32:23 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans issue tracker , benl@google.com References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org><071.ac1382a23021309632a3cfb2c9ac8ce0@tools.ietf.org> <559543E1.6010501@bbn.com> In-Reply-To: <559543E1.6010501@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer keyhash into the Precertificate 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, 03 Jul 2015 14:32:33 -0000 On 02/07/15 15:00, Stephen Kent wrote: > Rob, Hi Steve. > I agree with your conclusoon that inclusion of the issuer public key hash > will enable a browser to verify the correspondence between an SCT without > interacting with a log. Even though we don't yet have a browser behavior > spec, I agree that this is a good candidate behavior to enable. > > Do you propose this as an extension to the current SCT format, or a change > to the format? A change to the format. Proposal here: https://github.com/google/certificate-transparency-rfcs/pull/58 > If you propose a change, then I'll argue that my proposed > cert type declaration and checks performed fields also should be included, > since we'll be making a not backward compatible change to the SCT. 6962-bis has already made backwards-incompatible changes to RFC6962 SCT v1. > If this is an (optional) extension, then I guess my proposed fields can be > the second and third extensions defined. I think that required fields should be in the main part of the SCT structure, whilst optional fields should be extensions. IINM, we agreed a while ago that your proposed fields (cert type declaration and checks performed) would be, at most, optional. (I still think that it makes more sense for monitors, not logs, to perform checks relating to the declared cert type). > Steve >> #80: Re-introduce the issuer key hash into the Precertificate >> >> >> Comment (by rob.stradling@comodo.com): >> >> This problem affects browser clients and any other client that wants to >> verify that an SCT corresponds to a particular cert. A browser has the >> full cert chain (from the TLS handshake) and the corresponding SCTs, >> but >> it is _not_ expected to have the full log entries (i.e. extra_data, >> etc). >> >> In the current text, the SCT is bound to the Issuer Name (because >> that's >> in the TBSCertificate), but not to the Issuer Key (because that's >> not in >> the TBSCertificate). >> >> There could exist two or more publicly-trusted intermediate CA certs >> with >> the same Name but different Keys. One of those intermediates might be >> logged, while the other(s) are not logged. Each of them could issue >> leaf >> certs that have an identical TBSCertificate. Only one of those leaf >> certs >> needs to be logged for there to exist SCT(s) that are valid for all of >> those leaf certs. >> >> The logged leaf cert might get revoked, but the other(s) might not get >> revoked. However, the SCT(s) would still work for all of those certs, >> including the non-logged ones. >> >> Therefore, we need to fix SCTs so that they're bound to the Issuer Key >> Hash as well as the Issuer Name. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Sat Jul 4 19:55:03 2015 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 7C98C1A90C7 for ; Sat, 4 Jul 2015 19:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOnXE3Ic76-Y for ; Sat, 4 Jul 2015 19:55:00 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 EBB411A90C2 for ; Sat, 4 Jul 2015 19:54:53 -0700 (PDT) Received: by pacgz10 with SMTP id gz10so2695787pac.3 for ; Sat, 04 Jul 2015 19:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=pRzHV7+JzEep1/DOhAMoyVrOkxPioDzoImKSdwr8FYw=; b=e8X2yWu3yObON32bM8PLJDGWHhETZQ0PmxLXcpbYwPYdVkc3i7xg2AeLw1ZBs7vWa2 3vQUTofB1PxHX6u8GgRcdkyTTT7S0adodPp9GG/MDSHd/kmtQQoQYkqvBJqwV7k3IAZf aYB/CyUTQhwzaf58EA1b8QUpqrDU4HiBSJp+q1N9zVQek4HbzXJOxFvQM8ih0XD0CrsC A7m0aQnQPs1vyDUK4vkgzcm383wNFMs1Jg4riZT66aU4l2nPtGByxaWIlMSo+QQIzRhN Vkv9zblPOnJow9txff3Xutjx0ikPrC1DW3+UzOAZgUKB+Bl1hZc7oUG1FL/mOX8b8SED l4Lw== X-Received: by 10.66.131.110 with SMTP id ol14mr91467963pab.0.1436064893541; Sat, 04 Jul 2015 19:54:53 -0700 (PDT) Received: from spandex.local (74-124-101-95-rb2.fai.dsl.dynamic.acsalaska.net. [74.124.101.95]) by mx.google.com with ESMTPSA id oo3sm13643911pac.31.2015.07.04.19.54.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jul 2015 19:54:52 -0700 (PDT) Message-ID: <55989C7B.7000908@gmail.com> Date: Sat, 04 Jul 2015 18:54:51 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Remote presentation at Prague meeting X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 02:55:01 -0000 Hi, all: As you may have noticed, we've been scheduled for our session on Thursday afternoon (23 July), 17:40 - 19:10. If you expect to have an agenda slot but will be presenting remotely (i.e. you will not be physically present in the room in Prague), please let us know so that we can request remote presentation support from Meetecho. Thanks, Melinda From nobody Mon Jul 6 03:50:59 2015 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 DECD31A0074 for ; Mon, 6 Jul 2015 03:50:57 -0700 (PDT) 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 bJEhV4IJdQwz for ; Mon, 6 Jul 2015 03:50:56 -0700 (PDT) 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 8BA671A0094 for ; Mon, 6 Jul 2015 03:50:56 -0700 (PDT) Received: from localhost ([::1]:40746 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC3z7-00084E-Pq; Mon, 06 Jul 2015 03:50:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 10:50:49 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:6 Message-ID: <071.213ae7c58a74a846fd77379dee1cd127@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 10:50:58 -0000 #80: Re-introduce the issuer key hash into the SCT Changes (by rob.stradling@comodo.com): * status: assigned => closed * resolution: => needs-review Comment: Fixed here: https://github.com/google/certificate-transparency- rfcs/commit/f2650ef2b776a05eb280614b967efe2fcc4cf44e -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: needs-review Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Mon Jul 6 04:26:38 2015 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 C5DE21A0277 for ; Mon, 6 Jul 2015 04:26:36 -0700 (PDT) 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 GJzDDaFEhVD7 for ; Mon, 6 Jul 2015 04:26:35 -0700 (PDT) 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 92DE31A0276 for ; Mon, 6 Jul 2015 04:26:35 -0700 (PDT) Received: from localhost ([::1]:43801 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC4Xf-0001qp-V7; Mon, 06 Jul 2015 04:26:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 11:26:31 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:7 Message-ID: <071.ad3d76a8a22779f3b706e9fe7afb7aa9@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:26:36 -0000 #80: Re-introduce the issuer key hash into the SCT Changes (by rob.stradling@comodo.com): * status: closed => reopened * resolution: needs-review => * milestone: => review Comment: I just realized that resolving as "needs-review" was the wrong thing to do. Reopening and setting milestone to "review" instead. -- ------------------------------+--------------------------------------- Reporter: eranm@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 Mon Jul 6 04:27:26 2015 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 E4C591A0094 for ; Mon, 6 Jul 2015 04:27:24 -0700 (PDT) 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 jyPQHAk7mdfE for ; Mon, 6 Jul 2015 04:27:23 -0700 (PDT) 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 085361A0277 for ; Mon, 6 Jul 2015 04:27:23 -0700 (PDT) Received: from localhost ([::1]:43833 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC4YU-000636-SO; Mon, 06 Jul 2015 04:27:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 11:27:22 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/92#comment:2 Message-ID: <079.12af63b9c4a964fa62dc2aa2ef54a9ec@tools.ietf.org> References: <064.d9fa313d805f15d47ba200812a5627d6@tools.ietf.org> X-Trac-Ticket-ID: 92 In-Reply-To: <064.d9fa313d805f15d47ba200812a5627d6@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] #92 (rfc6962-bis): get-entries needs to return the whole X509ChainEntry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:27:25 -0000 #92: get-entries needs to return the whole X509ChainEntry Changes (by rob.stradling@comodo.com): * status: closed => reopened * resolution: needs-review => * milestone: => review Comment: I just realized that resolving as "needs-review" was the wrong thing to do. Reopening and setting milestone to "review" instead. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Jul 6 04:33:45 2015 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 151BE1A0016 for ; Mon, 6 Jul 2015 04:33:44 -0700 (PDT) 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 4F2a75Fsi9iZ for ; Mon, 6 Jul 2015 04:33:42 -0700 (PDT) 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 671491A0006 for ; Mon, 6 Jul 2015 04:33:42 -0700 (PDT) Received: from localhost ([::1]:44367 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC4ea-0005mW-Ry; Mon, 06 Jul 2015 04:33:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 11:33:40 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/74#comment:2 Message-ID: <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <052.329e3339e14184dcd891ce5116d624c8@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706113342.671491A0006@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 04:33:42 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:33:44 -0000 #74: normative statement of TLS client behavior in Section 3 Comment (by benl@google.com): Describing how the protocol works from the client's POV is _not_ about client behaviour, it is about the client's understanding of the situation. How it behaves as a result of that understanding is behaviour. I propose this should be closed "wontfix". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 04:40:18 2015 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 0F6D61A036E for ; Mon, 6 Jul 2015 04:40:17 -0700 (PDT) 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 yUCu-Ng8cgYW for ; Mon, 6 Jul 2015 04:40:16 -0700 (PDT) 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 6DC1F1A036F for ; Mon, 6 Jul 2015 04:39:38 -0700 (PDT) Received: from localhost ([::1]:44654 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC4kK-0006pG-OG; Mon, 06 Jul 2015 04:39:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 11:39:36 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/74#comment:3 Message-ID: <067.16c5ce118cd3a1ea2a5b4d5ada5263ab@tools.ietf.org> References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <052.329e3339e14184dcd891ce5116d624c8@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706113938.6DC1F1A036F@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 04:39:38 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:40:17 -0000 #74: normative statement of TLS client behavior in Section 3 Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Thanks Ben. Good point. I agree that WONTFIX makes sense. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 04:40:39 2015 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 3EAF01A024C for ; Mon, 6 Jul 2015 04:40:35 -0700 (PDT) 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 tOswf2bVmTx9 for ; Mon, 6 Jul 2015 04:40:34 -0700 (PDT) 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 58C5C1A0338 for ; Mon, 6 Jul 2015 04:39:48 -0700 (PDT) Received: from localhost ([::1]:44666 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC4kU-0006qQ-Sx; Mon, 06 Jul 2015 04:39:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 11:39:46 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/65#comment:2 Message-ID: <067.528e3de31b55e9910d4948f71b874bf9@tools.ietf.org> References: <052.7b8731a1601d369a3b2ae85631ff646b@tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <052.7b8731a1601d369a3b2ae85631ff646b@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706113948.58C5C1A0338@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 04:39:48 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #65 (rfc6962-bis): remove section 5.4 and reference to "Auditor" in section 3 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:40:35 -0000 #65: remove section 5.4 and reference to "Auditor" in section 3 Changes (by benl@google.com): * milestone: => review Comment: The editors never believed that audit would necessarily be performed by a standalone entity, that doesn't seem relevant. In any case, this has been clarified by talking about "auditing" rather than "auditor". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 05:05:38 2015 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 DB7BE1ACE46 for ; Mon, 6 Jul 2015 05:05:37 -0700 (PDT) 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 i1kB0-CfBQZy for ; Mon, 6 Jul 2015 05:05:37 -0700 (PDT) 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 175541A00EA for ; Mon, 6 Jul 2015 05:05:37 -0700 (PDT) Received: from localhost ([::1]:46365 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC59P-0001Xe-SU; Mon, 06 Jul 2015 05:05:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 12:05:31 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/73#comment:2 Message-ID: <067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org> References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <052.b3ecc6ca8b28cc47e13443079611ce86@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706120537.175541A00EA@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 05:05:37 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:05:38 -0000 #73: Section 3 text re log cert validation is ambiguous Comment (by benl@google.com): On the issue of specifying deviations, I am not sure how that could realistically be done. For example, our logs will permit whatever deviations OpenSSL permits. I don't think anyone knows precisely what those are, and I'm prepared to bet they vary between versions. Even leaving that aside, experience suggests we have to permit deviations in order to admit incorrect certificates that are accepted by browsers. I don't think we can anticipate what all of those are. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 05:08:52 2015 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 7AFE51ACE6B for ; Mon, 6 Jul 2015 05:08:50 -0700 (PDT) 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 NN5d9T9wJ2fh for ; Mon, 6 Jul 2015 05:08:49 -0700 (PDT) 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 A2EFB1ACE67 for ; Mon, 6 Jul 2015 05:08:49 -0700 (PDT) Received: from localhost ([::1]:46558 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC5Ca-0002cr-84; Mon, 06 Jul 2015 05:08:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 12:08:48 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/63#comment:2 Message-ID: <067.37ec21df03cfcedf0bb6154508066ac2@tools.ietf.org> References: <052.2f8736daa2848e7838235c5604063f8e@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <052.2f8736daa2848e7838235c5604063f8e@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706120849.A2EFB1ACE67@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 05:08:49 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #63 (rfc6962-bis): remove all normative references to client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:08:50 -0000 #63: remove all normative references to client behavior Changes (by benl@google.com): * milestone: => review Comment: Not all normative statements about clients are about client behaviour. Suggest close "wontfix". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: Active WG | Resolution: Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 05:09:28 2015 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 E893C1ACE50 for ; Mon, 6 Jul 2015 05:09:27 -0700 (PDT) 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 omcKO6ynBZHp for ; Mon, 6 Jul 2015 05:09:27 -0700 (PDT) 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 E9C781ACE5F for ; Mon, 6 Jul 2015 05:09:26 -0700 (PDT) Received: from localhost ([::1]:46590 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC5DB-0002jk-Oy; Mon, 06 Jul 2015 05:09:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 12:09:25 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/63#comment:3 Message-ID: <067.4e7bb0cd9edea9ee32270220f31d199a@tools.ietf.org> References: <052.2f8736daa2848e7838235c5604063f8e@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <052.2f8736daa2848e7838235c5604063f8e@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706120926.E9C781ACE5F@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 05:09:26 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #63 (rfc6962-bis): remove all normative references to client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:09:28 -0000 #63: remove all normative references to client behavior Comment (by benl@google.com): In any case, this ticket is too vague to action. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: Active WG | Resolution: Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 05:10:47 2015 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 A63351ACE2C for ; Mon, 6 Jul 2015 05:10:46 -0700 (PDT) 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 4btWbaeuGyIw for ; Mon, 6 Jul 2015 05:10:45 -0700 (PDT) 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 CEE4C1ACE4D for ; Mon, 6 Jul 2015 05:10:45 -0700 (PDT) Received: from localhost ([::1]:46696 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC5ER-0003bC-VV; Mon, 06 Jul 2015 05:10:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 12:10:43 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/70#comment:2 Message-ID: <067.1d7ff2839592524f118803e277a8d6d6@tools.ietf.org> References: <052.ecfc9a319e455c61897ed3e82e509b78@tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <052.ecfc9a319e455c61897ed3e82e509b78@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706121045.CEE4C1ACE4D@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 05:10:45 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #70 (rfc6962-bis): STH spec needs to define top-level extension syntax X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:10:46 -0000 #70: STH spec needs to define top-level extension syntax Comment (by benl@google.com): It was our view that we did not need to specify the format until the first extension was defined. However, happy to consider proposed text. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 05:12:23 2015 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 E1B6D1ACE3C for ; Mon, 6 Jul 2015 05:12:21 -0700 (PDT) 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 XuWRxR6InTc0 for ; Mon, 6 Jul 2015 05:12:21 -0700 (PDT) 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 2EB711ACE50 for ; Mon, 6 Jul 2015 05:12:21 -0700 (PDT) Received: from localhost ([::1]:46797 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC5Fz-0004KP-S1; Mon, 06 Jul 2015 05:12:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 12:12:19 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:2 Message-ID: <067.fa9772ddba9eb1de2834861c2c9f897e@tools.ietf.org> References: <052.0789019d9e32c9233f0440891ac5bb94@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <052.0789019d9e32c9233f0440891ac5bb94@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706121221.2EB711ACE50@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 05:12:21 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:12:22 -0000 #76: Normative client behavior specified in Section 3.4 Changes (by benl@google.com): * milestone: => review Comment: I cannot find the referenced text, so I assume this is already fixed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 05:40:06 2015 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 7FEED1ACEBE for ; Mon, 6 Jul 2015 05:40:04 -0700 (PDT) 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 ghIPS0ptr2A6 for ; Mon, 6 Jul 2015 05:39:59 -0700 (PDT) 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 09B711ACEC7 for ; Mon, 6 Jul 2015 05:39:59 -0700 (PDT) Received: from localhost ([::1]:49202 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC5gg-0004hL-VF; Mon, 06 Jul 2015 05:39:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 12:39:54 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/77#comment:2 Message-ID: <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <052.9d9fc2bb25108f9681efa566967a94e3@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706123959.09B711ACEC7@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 05:39:59 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:40:04 -0000 #77: normative client behavior specified in Section 5 Changes (by benl@google.com): * milestone: => review Comment: What has been ruled out of scope is what action clients take, not how they conform to the protocol. Suggest close wontfix. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 05:48:46 2015 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 2B3A71B2A6D for ; Mon, 6 Jul 2015 05:48:45 -0700 (PDT) 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 xCX0bqq5cw5T for ; Mon, 6 Jul 2015 05:48:44 -0700 (PDT) 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 04FD31B2A74 for ; Mon, 6 Jul 2015 05:47:50 -0700 (PDT) Received: from localhost ([::1]:49711 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC5oK-0000Nd-AM; Mon, 06 Jul 2015 05:47:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 12:47:48 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/73#comment:3 Message-ID: <067.0a578d0b39ba6d40114fc596eba94db9@tools.ietf.org> References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <052.b3ecc6ca8b28cc47e13443079611ce86@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706124750.04FD31B2A74@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 05:47:50 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:48:45 -0000 #73: Section 3 text re log cert validation is ambiguous Changes (by benl@google.com): * milestone: => review Comment: X.509 issue fixed at https://github.com/google/certificate-transparency- rfcs/commit/716e7f5df4b465283f26d48bdf46e21c61d9c3d4 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 06:19:56 2015 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 4F7341A1B79 for ; Mon, 6 Jul 2015 06:19:50 -0700 (PDT) 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 95trGpHNK8iH for ; Mon, 6 Jul 2015 06:19:44 -0700 (PDT) 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 C583D1A1B72 for ; Mon, 6 Jul 2015 06:19:44 -0700 (PDT) Received: from localhost ([::1]:52440 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC6JB-0008HM-A8; Mon, 06 Jul 2015 06:19:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 13:19:41 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/72#comment:3 Message-ID: <067.c34aaf9ffae21f9fe4a12b20ef27984b@tools.ietf.org> References: <052.83a7720c272d768f705104c61dc38731@tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <052.83a7720c272d768f705104c61dc38731@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706131944.C583D1A1B72@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 06:19:44 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #72 (rfc6962-bis): Section 2.1.4 cites specific algorithms X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:19:50 -0000 #72: Section 2.1.4 cites specific algorithms Changes (by benl@google.com): * status: new => closed * resolution: => duplicate -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: duplicate Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 06:31:07 2015 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 4A3381A6FEF for ; Mon, 6 Jul 2015 06:31:05 -0700 (PDT) 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 alRdAf50B0qc for ; Mon, 6 Jul 2015 06:31:04 -0700 (PDT) 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 74F101A6EFE for ; Mon, 6 Jul 2015 06:31:02 -0700 (PDT) Received: from localhost ([::1]:53183 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC6U7-0007U2-1j; Mon, 06 Jul 2015 06:30:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 13:30:59 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/91#comment:2 Message-ID: <071.4a0d447b7da6d5f4e14f28602862a457@tools.ietf.org> References: <056.1a3a0b4df721b59933a4c32a232c7f3e@tools.ietf.org> X-Trac-Ticket-ID: 91 In-Reply-To: <056.1a3a0b4df721b59933a4c32a232c7f3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #91 (rfc6962-bis): Clarify encoding of fields in the log client messages X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:31:05 -0000 #91: Clarify encoding of fields in the log client messages Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/70ba7d17ad61c3d4360801ee0cfee1664b560acd. -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Mon Jul 6 06:37:04 2015 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 8D5F11A1BC2 for ; Mon, 6 Jul 2015 06:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iNfAuCBn8h3d for ; Mon, 6 Jul 2015 06:36:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AD51A1BF2 for ; Mon, 6 Jul 2015 06:36:54 -0700 (PDT) Received: from dhcp89-089-172.bbn.com ([128.89.89.172]:65049) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC6Zp-0007kL-9O for trans@ietf.org; Mon, 06 Jul 2015 09:36:53 -0400 To: trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> <067.0a578d0b39ba6d40114fc596eba94db9@tools.ietf.org> From: Karen Seo Message-ID: <559A8474.4070102@bbn.com> Date: Mon, 6 Jul 2015 09:36:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <067.0a578d0b39ba6d40114fc596eba94db9@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous 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, 06 Jul 2015 13:37:02 -0000 Ben, I get 404 error when I click on the link below. Karen On 7/6/15 8:47 AM, trans issue tracker wrote: > #73: Section 3 text re log cert validation is ambiguous > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > X.509 issue fixed at https://github.com/google/certificate-transparency- > rfcs/commit/716e7f5df4b465283f26d48bdf46e21c61d9c3d4 > From nobody Mon Jul 6 07:25:24 2015 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 CDF901A8848 for ; Mon, 6 Jul 2015 07:25:23 -0700 (PDT) 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 I86NdBRNN_it for ; Mon, 6 Jul 2015 07:25:23 -0700 (PDT) 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 153EF1A21B9 for ; Mon, 6 Jul 2015 07:25:23 -0700 (PDT) Received: from localhost ([::1]:58424 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC7Kg-0007mo-Cy; Mon, 06 Jul 2015 07:25:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 14:25:18 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/68#comment:2 Message-ID: <067.d204a9c123d01e076c09a530578d8792@tools.ietf.org> References: <052.b40b5491f0d964b6f2806f2262e10952@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <052.b40b5491f0d964b6f2806f2262e10952@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706142523.153EF1A21B9@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 07:25:23 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #68 (rfc6962-bis): specification of sha-256 for the SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:25:24 -0000 #68: specification of sha-256 for the SCT Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/d28ac2a93f54e05f1c3f6725136c7e2502eee0ed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 07:25:56 2015 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 D78021A88D0 for ; Mon, 6 Jul 2015 07:25:53 -0700 (PDT) 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 8qF8HgIF0A0Z for ; Mon, 6 Jul 2015 07:25:50 -0700 (PDT) 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 683451A21B9 for ; Mon, 6 Jul 2015 07:25:40 -0700 (PDT) Received: from localhost ([::1]:58456 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC7L1-0001dm-BQ; Mon, 06 Jul 2015 07:25:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 14:25:39 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/69#comment:2 Message-ID: <067.cfb87c076bdf2be24656e61bc7e2ed05@tools.ietf.org> References: <052.7e80f7bf1c6616fe0bce0b76bfc16561@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <052.7e80f7bf1c6616fe0bce0b76bfc16561@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706142540.683451A21B9@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 07:25:40 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #69 (rfc6962-bis): old data name (sha256_root_hash) in 3.6 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:25:54 -0000 #69: old data name (sha256_root_hash) in 3.6 Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/d28ac2a93f54e05f1c3f6725136c7e2502eee0ed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 07:27:11 2015 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 7D29B1A88E0 for ; Mon, 6 Jul 2015 07:27:09 -0700 (PDT) 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 TH78AJQs_k9K for ; Mon, 6 Jul 2015 07:27:08 -0700 (PDT) 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 F251B1A88C3 for ; Mon, 6 Jul 2015 07:27:06 -0700 (PDT) Received: from localhost ([::1]:58576 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC7MQ-0008Ot-B8; Mon, 06 Jul 2015 07:27:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 14:27:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/84#comment:1 Message-ID: <070.c75b23a2141dffdc1e2299c0b4186431@tools.ietf.org> References: <055.ea272dc06c58ca33b8cd9ebbf05ce7b3@tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <055.ea272dc06c58ca33b8cd9ebbf05ce7b3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706142706.F251B1A88C3@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 07:27:06 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #84 (rfc6962-bis): Clarify that root certs have empty certificate_chain X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:27:09 -0000 #84: Clarify that root certs have empty certificate_chain Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/d28ac2a93f54e05f1c3f6725136c7e2502eee0ed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- linus@nordu.net | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 07:29:58 2015 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 53D2E1A88B6 for ; Mon, 6 Jul 2015 07:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 dBtUmFvXUe1x for ; Mon, 6 Jul 2015 07:29:54 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A946E1A8898 for ; Mon, 6 Jul 2015 07:29:53 -0700 (PDT) Received: (qmail 6766 invoked by uid 1004); 6 Jul 2015 14:29:51 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 06 Jul 2015 15:29:51 +0100 Received: (qmail 11052 invoked by uid 1000); 6 Jul 2015 14:29:51 -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, 06 Jul 2015 15:29:51 +0100 Message-ID: <559A90DF.8060507@comodo.com> Date: Mon, 06 Jul 2015 15:29:51 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Karen Seo References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.0a578d0b39ba6d40114fc596eba94db9@tools.ietf.org> <559A8474.4070102@bbn.com> In-Reply-To: <559A8474.4070102@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log certvalidation is ambiguous 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, 06 Jul 2015 14:29:57 -0000 Hi Karen. Were you trying to access https://github.com/google/certificate-transparency- by any chance? That's only half the URL. The full URL gets wrapped onto two lines somewhere between TRAC and your inbox. On 06/07/15 14:36, Karen Seo wrote: > Ben, > > I get 404 error when I click on the link below. > > Karen > > On 7/6/15 8:47 AM, trans issue tracker wrote: >> #73: Section 3 text re log cert validation is ambiguous >> >> Changes (by benl@google.com): >> >> * milestone: => review >> >> >> Comment: >> >> X.509 issue fixed at >> https://github.com/google/certificate-transparency- >> rfcs/commit/716e7f5df4b465283f26d48bdf46e21c61d9c3d4 >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Mon Jul 6 07:45:29 2015 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 CADC81A1A5D for ; Mon, 6 Jul 2015 07:45:27 -0700 (PDT) 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 X7JPT6bMAxVr for ; Mon, 6 Jul 2015 07:45:23 -0700 (PDT) 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 01CB21A8A41 for ; Mon, 6 Jul 2015 07:45:23 -0700 (PDT) Received: from localhost ([::1]:59946 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC7e6-0001A8-8K; Mon, 06 Jul 2015 07:45:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 14:45:22 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/90#comment:1 Message-ID: <076.cca8a3770ce890cc5c257c949b0fd292@tools.ietf.org> References: <061.6c57439d9835c35d408ea3940c9d0efe@tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <061.6c57439d9835c35d408ea3940c9d0efe@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706144523.01CB21A8A41@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 07:45:23 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #90 (rfc6962-bis): Clarify how to turn a MerkleTreeLeaf into a leaf hash X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:45:28 -0000 #90: Clarify how to turn a MerkleTreeLeaf into a leaf hash Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/50f78c83a27c9e95180b5e3d349e0f4eda0423bd. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eijdenberg@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 07:50:51 2015 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 CE71A1B2A5F for ; Mon, 6 Jul 2015 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 HKg0CI02t2Mg for ; Mon, 6 Jul 2015 07:50:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7025E1A9252 for ; Mon, 6 Jul 2015 07:50:48 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50113 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC7jL-0008Z9-9M for trans@ietf.org; Mon, 06 Jul 2015 10:50:47 -0400 Message-ID: <559A95C7.3010107@bbn.com> Date: Mon, 06 Jul 2015 10:50:47 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> In-Reply-To: <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> Content-Type: multipart/alternative; boundary="------------000309010803000204050004" Archived-At: Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 06 Jul 2015 14:50:50 -0000 This is a multi-part message in MIME format. --------------000309010803000204050004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I note the following text from the -07 draft that appear to specify TLS client behavior: Section 1 TLS clients can thus require that all certificates they accept as valid have been logged. Section 3 A certificate not accompanied by an SCT (either for the end-entity certificate or for a name-constrained intermediate the end-entity certificate chains to) MUST NOT be considered compliant by TLS clients. Section 3.4 TLS clients MUST implement all three mechanisms. Section 3.4.1 TLS clients that support the extension SHOULD send a ClientHello extension with the appropriate type and empty "extension_data". TLS clients SHOULD include the extension type in the ClientHello, but if the session is resumed, the TLS server is not expected to process it or include the extension in the ServerHello. Section 5.3 In addition to normal validation of the certificate and its chain, *TLS** ** clients SHOULD validate* the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key. > #74: normative statement of TLS client behavior in Section 3 > > > Comment (by benl@google.com): > > Describing how the protocol works from the client's POV is _not_ about > client behaviour, it is about the client's understanding of the situation. > How it behaves as a result of that understanding is behaviour. > > I propose this should be closed "wontfix". > --------------000309010803000204050004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I note the following text from the -07 draft that appear to specify TLS client behavior:

Section 1

   TLS clients can thus require that all certificates they accept as valid have been logged.

Section 3

   A certificate not
   accompanied by an SCT (either for the end-entity certificate or for a
   name-constrained intermediate the end-entity certificate chains to)
   MUST NOT be considered compliant by TLS clients.


Section 3.4

   TLS clients MUST implement all three mechanisms.


Section 3.4.1

   TLS clients that support the extension SHOULD send a ClientHello
   extension with the appropriate type and empty "extension_data".

   TLS clients
   SHOULD include the extension type in the ClientHello, but if the
   session is resumed, the TLS server is not expected to process it or
   include the extension in the ServerHello.


Section 5.3

 
   In addition to normal validation of the certificate and its chain, TLS
   clients SHOULD validate the SCT by computing the signature input from
   the SCT data as well as the certificate and verifying the signature,
   using the corresponding log's public key.


#74: normative statement of TLS client behavior in Section 3


Comment (by benl@google.com):

 Describing how the protocol works from the client's POV is _not_ about
 client behaviour, it is about the client's understanding of the situation.
 How it behaves as a result of that understanding is behaviour.

 I propose this should be closed "wontfix".

--------------000309010803000204050004-- From nobody Mon Jul 6 07:58:57 2015 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 8C8CE1A88DB for ; Mon, 6 Jul 2015 07:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 zyM2s1QPoT4t for ; Mon, 6 Jul 2015 07:58:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D2A1A8934 for ; Mon, 6 Jul 2015 07:58:54 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:58540 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC7rB-000DG7-11 for trans@ietf.org; Mon, 06 Jul 2015 10:58:53 -0400 Message-ID: <559A97AC.6040305@bbn.com> Date: Mon, 06 Jul 2015 10:58:52 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> In-Reply-To: <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> Content-Type: multipart/alternative; boundary="------------060803070404080406050904" Archived-At: Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 06 Jul 2015 14:58:55 -0000 This is a multi-part message in MIME format. --------------060803070404080406050904 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I note the following text from the -07 i-D that seems to specify TLS client behavior: Section 1 TLS clients can thus require that all certificates they accept as valid have been logged. (doe not use 2918 reserved words, but ...) Section 3 A certificate not accompanied by an SCT (either for the end-entity certificate or for a name-constrained intermediate the end-entity certificate chains to) *MUST NOT be considered compliant by TLS clients*. Section 3.4 *TLS clients MUST implement all three mechanisms*. Section 3.4.1 *TLS clients that support the extension SHOULD *send a ClientHello extension with the appropriate type and empty "extension_data". *TLS clients SHOULD include *the extension type in the ClientHello, Section 5.3 in addition to normal validation of the certificate and its chain, *TLS** ** clients SHOULD validate the SCT *by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key. *A TLS client MAY audit the corresponding log *by requesting, and verifying, a Merkle audit proof for said certificate.* If the TLS** ** client holds an STH that predates the SCT, it MAY, *in the process of auditing, request a new STH from the log (Section 4.3), then verify it by requesting a consistency proof (Section 4.4). *TLS clients MUST reject SCTs whose timestamp* is in the future. Section 8.1 *Misissued certificates that have not been publicly logged, and thus** ** do not have a valid SCT, will be rejected by TLS clients.* > #74: normative statement of TLS client behavior in Section 3 > > > Comment (by benl@google.com): > > Describing how the protocol works from the client's POV is _not_ about > client behaviour, it is about the client's understanding of the situation. > How it behaves as a result of that understanding is behaviour. > > I propose this should be closed "wontfix". > --------------060803070404080406050904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I note the following text from the -07 i-D that seems to specify TLS client behavior:

Section 1

   TLS clients can thus require that all certificates they accept as valid have been logged.

(doe not use 2918 reserved words, but ...)


Section 3

   A certificate not
   accompanied by an SCT (either for the end-entity certificate or for a
   name-constrained intermediate the end-entity certificate chains to)
   MUST NOT be considered compliant by TLS clients.


Section 3.4

   TLS clients MUST implement all three mechanisms.


Section 3.4.1

   TLS clients that support the extension SHOULD send a ClientHello
   extension with the appropriate type and empty "extension_data".

   TLS clients SHOULD include the extension type in the ClientHello,


Section 5.3

   in addition to normal validation of the certificate and its chain, TLS
   clients SHOULD validate the SCT by computing the signature input from
   the SCT data as well as the certificate and verifying the signature,
   using the corresponding log's public key.

   A TLS client MAY audit the corresponding log by requesting, and
   verifying, a Merkle audit proof for said certificate.  If the TLS
   client holds an STH that predates the SCT, it MAY, in the process of
   auditing, request a new STH from the log (Section 4.3), then verify
   it by requesting a consistency proof (Section 4.4).

   TLS clients MUST reject SCTs whose timestamp is in the future.


Section 8.1

   Misissued certificates that have not been publicly logged, and thus
   do not have a valid SCT, will be rejected by TLS clients.
#74: normative statement of TLS client behavior in Section 3


Comment (by benl@google.com):

 Describing how the protocol works from the client's POV is _not_ about
 client behaviour, it is about the client's understanding of the situation.
 How it behaves as a result of that understanding is behaviour.

 I propose this should be closed "wontfix".

--------------060803070404080406050904-- From nobody Mon Jul 6 08:01:47 2015 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 6DF5F1A8983 for ; Mon, 6 Jul 2015 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, 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 Op0qW83PF7rF for ; Mon, 6 Jul 2015 08:01:43 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173F71A8A04 for ; Mon, 6 Jul 2015 08:01:12 -0700 (PDT) Received: by ykeo3 with SMTP id o3so29985351yke.0 for ; Mon, 06 Jul 2015 08:01:11 -0700 (PDT) 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=135ZxWHRomIBgQyhP2Gl+cQ406xsEF+OvLP7WjjTDLk=; b=O9QcQgvye43RMCjRndfYGCbz+Zcr5HP9Qzwmcp71OQCDpuhtFceZP4gr236XcLvWHi F+h0Ox7G4byowxadl12t5OIscntC6iSSL7JpW6JkwkNnuXgCHRZADkA0IDp9aCJFQ1ak e4AnZFaLZo55TP5uYquC6Ez7E0aTXAF82im1Qu9/n17KNNmKQxkVLOccF5LTnMZC42Io VL49zFL9Yv6vwZWDh+oq6e3HNQxMLARP7Ku1r8R9AsfYB3JVMiehcqqS8APyxbOFoS5R ZT7ut02Dthc8MIBwAxWNu5AmL+9lG7W3iufBxly/qHV9Tofbr0GKPN+JzIa+1QNNGqdA 1byQ== 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=135ZxWHRomIBgQyhP2Gl+cQ406xsEF+OvLP7WjjTDLk=; b=cfZInsMSh+TYdx4FJhHLKUn6izP1m/EZ9OXIPWBwp80p3NwunzC/mPAoFmiTfu+zv2 VK8m18hCohgXj+JnaLiCJyefqb3wT/TY0dlSFU0UpemsiCXW7KAtn0O1Exe52JfTn9Ma KUaxcMeqBco/UhzB2crjGrJc7r9Foqey6SHS09cu28NUFAtgKG04pPhhhBPYDOhkNhjJ 5+Qkw4Bco7TFjtlCuUvUXNID5RzxoivrHcJuBrFnsai/EK2a1pviMxZTy+K/u+Po1VKk rEOMdJRSykqug4cRBCxPkemTuzzh/MpkB/wlc1e7y9Zo8YpPrWl8PvLGzRtmSgA3/Cgy 1U7g== X-Gm-Message-State: ALoCoQmhcW85ZfSjHoAHuyMI39DlWaiyW/DwzIooY2hE37jwvNr5DA0b4mbAAPlyTJ/is3e8bTYU MIME-Version: 1.0 X-Received: by 10.129.108.12 with SMTP id h12mr59780611ywc.161.1436194871418; Mon, 06 Jul 2015 08:01:11 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Mon, 6 Jul 2015 08:01:11 -0700 (PDT) In-Reply-To: <559A95C7.3010107@bbn.com> References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> Date: Mon, 6 Jul 2015 16:01:11 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 06 Jul 2015 15:01:45 -0000 On 6 July 2015 at 15:50, Stephen Kent wrote: > I note the following text from the -07 draft that appear to specify TLS > client behavior: > > Section 1 > > TLS clients can thus require that all certificates they accept as valid > have been logged. This doesn't specify anything, just notes that clients can do it (if they want to, obviously). > > Section 3 > > A certificate not > accompanied by an SCT (either for the end-entity certificate or for a > name-constrained intermediate the end-entity certificate chains to) > MUST NOT be considered compliant by TLS clients. Again, no behaviour is specified. The client is required to understand that the cert is not in conformance with CT. It can do what it wants with that understanding. > > > Section 3.4 > > TLS clients MUST implement all three mechanisms. What we ruled out of scope is how clients behave in terms of user interface, et al. Clearly a protocol document has to describe how the protocol works. That is not the kind of behaviour we ruled out. > > > Section 3.4.1 > > TLS clients that support the extension SHOULD send a ClientHello > extension with the appropriate type and empty "extension_data". > > TLS clients > SHOULD include the extension type in the ClientHello, but if the > session is resumed, the TLS server is not expected to process it or > include the extension in the ServerHello. See above. > > > Section 5.3 > > > In addition to normal validation of the certificate and its chain, TLS > clients SHOULD validate the SCT by computing the signature input from > the SCT data as well as the certificate and verifying the signature, > using the corresponding log's public key. And again. > > > #74: normative statement of TLS client behavior in Section 3 > > > Comment (by benl@google.com): > > Describing how the protocol works from the client's POV is _not_ about > client behaviour, it is about the client's understanding of the situation. > How it behaves as a result of that understanding is behaviour. > > I propose this should be closed "wontfix". > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Mon Jul 6 08:03:39 2015 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 9FB971A8990 for ; Mon, 6 Jul 2015 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OKJxHpjk9V9w for ; Mon, 6 Jul 2015 08:03:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A6E1A89FC for ; Mon, 6 Jul 2015 08:03:36 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:58550 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC7vj-000DQL-9J for trans@ietf.org; Mon, 06 Jul 2015 11:03:35 -0400 Message-ID: <559A98C7.3000003@bbn.com> Date: Mon, 06 Jul 2015 11:03:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.7b8731a1601d369a3b2ae85631ff646b@tools.ietf.org> <067.528e3de31b55e9910d4948f71b874bf9@tools.ietf.org> In-Reply-To: <067.528e3de31b55e9910d4948f71b874bf9@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #65 (rfc6962-bis): remove section 5.4 and reference to "Auditor" in section 3 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, 06 Jul 2015 15:03:38 -0000 Irrespective of whether auditing is a function or a stand alone entity, there is a need for a complete description of how it works. The authors seem to have a different view from a proposal presented by DKG at the last meeting, in terms of the communication paths involved in auditing. That proposal emphasized privacy for TLS clients, and thus it merits further discussion. So, at this time, it seems premature to declare the design of auditing done. I suggest 6269-bis limit its discussion of auditing to noting which log interfaces are used to support the function, and assume that a separate doc will specify how auditing is performed. Steve > #65: remove section 5.4 and reference to "Auditor" in section 3 > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > The editors never believed that audit would necessarily be performed by a > standalone entity, that doesn't seem relevant. > > In any case, this has been clarified by talking about "auditing" rather > than "auditor". > From nobody Mon Jul 6 08:06:36 2015 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 CA73E1A893C for ; Mon, 6 Jul 2015 08:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FwqIfOMckGzu for ; Mon, 6 Jul 2015 08:06:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E691A8992 for ; Mon, 6 Jul 2015 08:06:32 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50147 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC7yZ-0008n2-Jl for trans@ietf.org; Mon, 06 Jul 2015 11:06:31 -0400 Message-ID: <559A9977.1040808@bbn.com> Date: Mon, 06 Jul 2015 11:06:31 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> <067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org> In-Reply-To: <067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous 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, 06 Jul 2015 15:06:35 -0000 If there is no standard for the validation checks logs perform, because of a desire to accept malformed certs from (sloppy) CAs, then a CA cannot know whether its submission will be rejected by a log. The alternative is to specify a way for each log to specify what checks it performs, and to publish that the same way other log info is advertised. Steve > #73: Section 3 text re log cert validation is ambiguous > > > Comment (by benl@google.com): > > On the issue of specifying deviations, I am not sure how that could > realistically be done. For example, our logs will permit whatever > deviations OpenSSL permits. I don't think anyone knows precisely what > those are, and I'm prepared to bet they vary between versions. > > Even leaving that aside, experience suggests we have to permit deviations > in order to admit incorrect certificates that are accepted by browsers. I > don't think we can anticipate what all of those are. > From nobody Mon Jul 6 08:08:00 2015 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 17AE41A8969 for ; Mon, 6 Jul 2015 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JT5ZGBDYOBeK for ; Mon, 6 Jul 2015 08:07:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC101A894F for ; Mon, 6 Jul 2015 08:07:59 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50151 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC7zy-0008nk-6t for trans@ietf.org; Mon, 06 Jul 2015 11:07:58 -0400 Message-ID: <559A99CE.80201@bbn.com> Date: Mon, 06 Jul 2015 11:07:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.2f8736daa2848e7838235c5604063f8e@tools.ietf.org> <067.37ec21df03cfcedf0bb6154508066ac2@tools.ietf.org> In-Reply-To: <067.37ec21df03cfcedf0bb6154508066ac2@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #63 (rfc6962-bis): remove all normative references to client behavior 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, 06 Jul 2015 15:08:00 -0000 In my previous message I cited what I believe are normative references about client behavior. Please indicate which ones you believe are not about client behavior, and why. Steve > #63: remove all normative references to client behavior > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > Not all normative statements about clients are about client behaviour. > > Suggest close "wontfix". > From nobody Mon Jul 6 08:08:31 2015 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 30FF81A89F9 for ; Mon, 6 Jul 2015 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] 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 Cug2gS_jA4tb for ; Mon, 6 Jul 2015 08:08:22 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA041A89F6 for ; Mon, 6 Jul 2015 08:08:22 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5C9A9486C8; Mon, 6 Jul 2015 15:08:29 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4645B484AD; Mon, 6 Jul 2015 15:08:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436195309; bh=f5aEptG1yshnz+zP5pfGrvANuRR3LO7Cig6HuSanTbU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=kHcxQUouIuo7nIc6URb7IOs9xMhivo37jIA+4tKCmte182ilkFl7FWSRAqQaokvCJ 3/ZiQ53yaFBYXZITkMEnysxgS/q2N+4Zl4p9mY6V3mzsA9d9Cn4UYTOQsAZnHBjmFW 2kA6ezWMSFGKNEX65jhOuHJEhpkvT+5q7LervUr0= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 0ED1180090; Mon, 6 Jul 2015 15:08:21 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 6 Jul 2015 10:08:20 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 6 Jul 2015 10:08:20 -0500 From: "Salz, Rich" To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] [trans] #65 (rfc6962-bis): remove section 5.4 and reference to "Auditor" in section 3 Thread-Index: AQHQt+CWcXnYi964I0yhC/jDoMgU/53O3eyA//+tWBA= Date: Mon, 6 Jul 2015 15:08:19 +0000 Message-ID: <04ba307743ed4fcc96ccb6af98f7eb11@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <052.7b8731a1601d369a3b2ae85631ff646b@tools.ietf.org> <067.528e3de31b55e9910d4948f71b874bf9@tools.ietf.org> <559A98C7.3000003@bbn.com> In-Reply-To: <559A98C7.3000003@bbn.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.45.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] [trans] #65 (rfc6962-bis): remove section 5.4 and reference to "Auditor" in section 3 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, 06 Jul 2015 15:08:23 -0000 DKG emphasizing privacy? Imagine that :) > Irrespective of whether auditing is a function or a stand alone entity, t= here is > a need for a complete description of how it works. The authors seem to ha= ve > a different view from a proposal presented by DKG at the last meeting, in > terms of the communication paths involved in auditing. That proposal > emphasized privacy for TLS clients, and thus it merits further discussion= . So, > at this time, it seems premature to declare the design of auditing done. = I > suggest 6269-bis limit its discussion of auditing to noting which log int= erfaces > are used to support the function, and assume that a separate doc will spe= cify > how auditing is performed. I agree with this! From nobody Mon Jul 6 08:08:41 2015 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 7B90B1A89F5 for ; Mon, 6 Jul 2015 08:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C0VEaBYdotdQ for ; Mon, 6 Jul 2015 08:08:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5760A1A89F6 for ; Mon, 6 Jul 2015 08:08:34 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:58563 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC80X-000DWy-Gd for trans@ietf.org; Mon, 06 Jul 2015 11:08:33 -0400 Message-ID: <559A99F1.3090100@bbn.com> Date: Mon, 06 Jul 2015 11:08:33 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.2f8736daa2848e7838235c5604063f8e@tools.ietf.org> <067.4e7bb0cd9edea9ee32270220f31d199a@tools.ietf.org> In-Reply-To: <067.4e7bb0cd9edea9ee32270220f31d199a@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #63 (rfc6962-bis): remove all normative references to client behavior 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, 06 Jul 2015 15:08:40 -0000 really? > #63: remove all normative references to client behavior > > > Comment (by benl@google.com): > > In any case, this ticket is too vague to action. > From nobody Mon Jul 6 08:10:06 2015 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 322AD1A8967 for ; Mon, 6 Jul 2015 08:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0KNNNnfu4QhH for ; Mon, 6 Jul 2015 08:10:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F21B1A0122 for ; Mon, 6 Jul 2015 08:10:04 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50157 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC81z-0008pK-2A for trans@ietf.org; Mon, 06 Jul 2015 11:10:03 -0400 Message-ID: <559A9A4A.40704@bbn.com> Date: Mon, 06 Jul 2015 11:10:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.0789019d9e32c9233f0440891ac5bb94@tools.ietf.org> <067.fa9772ddba9eb1de2834861c2c9f897e@tools.ietf.org> In-Reply-To: <067.fa9772ddba9eb1de2834861c2c9f897e@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:10:05 -0000 no. it is not fixed. See my message citing specific instances of normative client behavior in 3 and 3.4 Steve > #76: Normative client behavior specified in Section 3.4 > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > I cannot find the referenced text, so I assume this is already fixed. > From nobody Mon Jul 6 08:15:22 2015 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 531B11A8992 for ; Mon, 6 Jul 2015 08:15:20 -0700 (PDT) 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 Oszi6wzFuPz1 for ; Mon, 6 Jul 2015 08:15:18 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A5D1A8989 for ; Mon, 6 Jul 2015 08:15:17 -0700 (PDT) Received: (qmail 16141 invoked by uid 1004); 6 Jul 2015 15:15:15 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 06 Jul 2015 16:15:15 +0100 Received: (qmail 3646 invoked by uid 1000); 6 Jul 2015 15:15:15 -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, 06 Jul 2015 16:15:15 +0100 Message-ID: <559A9B83.6040000@comodo.com> Date: Mon, 06 Jul 2015 16:15:15 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org> <559A9977.1040808@bbn.com> In-Reply-To: <559A9977.1040808@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log certvalidation is ambiguous 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, 06 Jul 2015 15:15:20 -0000 On 06/07/15 16:06, Stephen Kent wrote: > If there is no standard for the validation checks logs perform, because > of a desire to accept malformed certs from (sloppy) CAs, then a CA cannot > know whether its submission will be rejected by a log. Huh? Why can't the (potentially sloppy) CA call add-chain (or add-pre-chain) and see what happens? Either the log will return an SCT (in which case it accepted the submission), or it won't (in which case it rejected the submission). > The alternative is to specify a way for > each log to specify what checks it performs, and to publish that the > same way other log info is advertised. > > Steve > > >> #73: Section 3 text re log cert validation is ambiguous >> >> >> Comment (by benl@google.com): >> >> On the issue of specifying deviations, I am not sure how that could >> realistically be done. For example, our logs will permit whatever >> deviations OpenSSL permits. I don't think anyone knows precisely what >> those are, and I'm prepared to bet they vary between versions. >> >> Even leaving that aside, experience suggests we have to permit >> deviations >> in order to admit incorrect certificates that are accepted by >> browsers. I >> don't think we can anticipate what all of those are. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Mon Jul 6 08:42:39 2015 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 702311B2D33 for ; Mon, 6 Jul 2015 08:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, 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 xTq5_mRVGneg for ; Mon, 6 Jul 2015 08:42:35 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EBE1B2D2B for ; Mon, 6 Jul 2015 08:42:35 -0700 (PDT) Received: by ykfy125 with SMTP id y125so152139955ykf.1 for ; Mon, 06 Jul 2015 08:42:34 -0700 (PDT) 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=SoohgTUVqz02ryv367P4g7/jX6AEZsmOSz55eaMupE8=; b=IY0JJZXPv70wP2a+H+jQNVwXtmLSh/gUxyMByaVOHnq6+pn6+KKmvWY65FBpkjFYbL XP33FSH3dl6uIAixmt3wtH9NIa1e6gVz6WoGreFqLNmjSYOeRwqU3NJJw2Ew8AWT3qaR eBWlKQDazi7PGu7UkT+/OV+eD9zWls5vvegoYWy9dn0x7Cy7L8izjXoYNNQqMumWKvxB p71dkXlurOxdx9/Pf1CQruFfA3ODpgL+raC7wNK3/+2PKd3wuuj0CupZknwSWU+Aa/HR bqcpcksSC8SDsYI0qD3fu7g84RNurFE38nd0MmQxtvY0pGGp+e6gRYz4w9yXF73fcU2o aXyA== 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=SoohgTUVqz02ryv367P4g7/jX6AEZsmOSz55eaMupE8=; b=jpTI6+QcoDbjeDg51jI/bXRq0dyndC/5nKat5lBdnpIpQxC2BEQ7MSWrHyILcHZhXX 0K3vDJdQOypFS3brPXRFg8qE/LfRrsBZaKswOya1rZb2uRQTc5maNRRf9Y7pmYTx/TtR uDCByUVK2ZiEwNVpdmebCEk3syS3xLoZ2jBOJ+wcbgEfRKGXb3AZ+hZgGR1VcmurGdPI pcmI3iZY4157lGa4b6O5RFWClvuIC9VDsh4mEBsbk7NW1id7gI/o4HBb7PDcvEXDrDO6 7Cn+D8/Lo/8l6n9ToPk1P/ORMUQUY6PFRBrupKg8bQmOyTxyqUXSMv/EXXXAcSS7K2jZ E2Ng== X-Gm-Message-State: ALoCoQmcfrKfloMQIgu3Z1/F3LiCR1RiuoLeVJxnp94NzziymOn4gKAo+og3c218cXRPT8M+a9vS MIME-Version: 1.0 X-Received: by 10.170.45.78 with SMTP id 75mr28289671ykn.53.1436197354472; Mon, 06 Jul 2015 08:42:34 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Mon, 6 Jul 2015 08:42:34 -0700 (PDT) In-Reply-To: <559A9977.1040808@bbn.com> References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> <067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org> <559A9977.1040808@bbn.com> Date: Mon, 6 Jul 2015 16:42:34 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous 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, 06 Jul 2015 15:42:36 -0000 On 6 July 2015 at 16:06, Stephen Kent wrote: > If there is no standard for the validation checks logs perform, because of a > desire to accept malformed certs from (sloppy) CAs, then a CA cannot know > whether > its submission will be rejected by a log. If a CA wants to be sure in advance (why?) that a log will accept its certs, then it should conform with the relevant standards. > The alternative is to specify a > way for > each log to specify what checks it performs, and to publish that the same > way other > log info is advertised. > > Steve > > >> #73: Section 3 text re log cert validation is ambiguous >> >> >> Comment (by benl@google.com): >> >> On the issue of specifying deviations, I am not sure how that could >> realistically be done. For example, our logs will permit whatever >> deviations OpenSSL permits. I don't think anyone knows precisely what >> those are, and I'm prepared to bet they vary between versions. >> >> Even leaving that aside, experience suggests we have to permit >> deviations >> in order to admit incorrect certificates that are accepted by browsers. >> I >> don't think we can anticipate what all of those are. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Mon Jul 6 09:00:16 2015 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 8D8931B2F38 for ; Mon, 6 Jul 2015 09:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WQJZS1mQl93A for ; Mon, 6 Jul 2015 09:00:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FFF1ACEC5 for ; Mon, 6 Jul 2015 09:00:12 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50276 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZC8oU-0009OE-H7; Mon, 06 Jul 2015 12:00:10 -0400 Message-ID: <559AA60A.1060501@bbn.com> Date: Mon, 06 Jul 2015 12:00:10 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rob Stradling , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org> <559A9977.1040808@bbn.com> <559A9B83.6040000@comodo.com> In-Reply-To: <559A9B83.6040000@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log certvalidation is ambiguous 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, 06 Jul 2015 16:00:15 -0000 Rob, Having a cert rejected does not tell the submitter (CA or otherwise) why, and thus the submitted doesn't know how to resolve the problem. Steve > On 06/07/15 16:06, Stephen Kent wrote: >> If there is no standard for the validation checks logs perform, because >> of a desire to accept malformed certs from (sloppy) CAs, then a CA >> cannot >> know whether its submission will be rejected by a log. > > Huh? Why can't the (potentially sloppy) CA call add-chain (or > add-pre-chain) and see what happens? > > Either the log will return an SCT (in which case it accepted the > submission), or it won't (in which case it rejected the submission). From nobody Mon Jul 6 09:05:05 2015 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 3B3C31B2B45 for ; Mon, 6 Jul 2015 09:05:03 -0700 (PDT) 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 kLeO7siW7uQK for ; Mon, 6 Jul 2015 09:04:59 -0700 (PDT) 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 6F2351B2ED4 for ; Mon, 6 Jul 2015 09:04:53 -0700 (PDT) Received: from localhost ([::1]:38627 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC8sw-0000Ac-NE; Mon, 06 Jul 2015 09:04:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 16:04:46 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/71#comment:2 Message-ID: <067.523ad48f4a879435300166b8be23b9f9@tools.ietf.org> References: <052.d0cb10aa97a9af9a9b3ba76fe9a2b363@tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <052.d0cb10aa97a9af9a9b3ba76fe9a2b363@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, 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: <20150706160453.6F2351B2ED4@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 09:04:53 -0700 (PDT) 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: Mon, 06 Jul 2015 16:05:03 -0000 #71: Section 1 does not define mis-issuance Changes (by benl@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => draft-ietf-trans- threat-analysis@tools.ietf.org * component: rfc6962-bis => threat-analysis -- -------------------------+------------------------------------------------- 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 Mon Jul 6 09:17:32 2015 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 B3E7C1B2F8E for ; Mon, 6 Jul 2015 09:17:31 -0700 (PDT) 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 d3Vsq7feMW60 for ; Mon, 6 Jul 2015 09:17:30 -0700 (PDT) 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 E9CBE1B2F8F for ; Mon, 6 Jul 2015 09:17:19 -0700 (PDT) Received: from localhost ([::1]:39979 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC953-0006up-O9; Mon, 06 Jul 2015 09:17:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 16:17:17 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/78#comment:2 Message-ID: <067.26cce79c448ae94087e82f3a71addea6@tools.ietf.org> References: <052.225d9e4c8d8c45e468832faf6102e815@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <052.225d9e4c8d8c45e468832faf6102e815@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706161719.E9CBE1B2F8F@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 09:17:19 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 16:17:31 -0000 #78: algorithm agility discussion is inadequate Comment (by benl@google.com): I am not clear what you are asking for. I cannot provide a long detailed plan for migrating from one log to another because the plan is as stated: freeze one log, start another one. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 10:02:24 2015 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 EBFB41B3001 for ; Mon, 6 Jul 2015 10:02:20 -0700 (PDT) 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 qhodU3hNc80S for ; Mon, 6 Jul 2015 10:02:19 -0700 (PDT) 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 D344B1B2FFE for ; Mon, 6 Jul 2015 10:02:19 -0700 (PDT) Received: from localhost ([::1]:44526 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC9md-0007RD-Gn; Mon, 06 Jul 2015 10:02:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 17:02:19 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:1 Message-ID: <076.193e17fbef67a1b94f8993c5280b3d0e@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706170219.D344B1B2FFE@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 10:02:19 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:02:21 -0000 #83: CT should mandate the use of deterministic ECDSA Comment (by benl@google.com): I am addressing this. But what about RSA? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 10:08:45 2015 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 4251D1ACD02 for ; Mon, 6 Jul 2015 10:08:44 -0700 (PDT) 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 LIjevYmW_jrE for ; Mon, 6 Jul 2015 10:08:43 -0700 (PDT) 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 B5F0D1B2FF5 for ; Mon, 6 Jul 2015 10:08:42 -0700 (PDT) Received: from localhost ([::1]:45059 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZC9so-00028y-2a; Mon, 06 Jul 2015 10:08:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 17:08:41 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:2 Message-ID: <076.84a70fd3bd23c870d40bc07578221da9@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706170842.B5F0D1B2FF5@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 10:08:42 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:08:44 -0000 #83: CT should mandate the use of deterministic ECDSA Comment (by benl@google.com): https://github.com/google/certificate-transparency- rfcs/commit/b5ac6c47af298ef8e74c084f1d654547c55c3010 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 10:42:06 2015 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 E091F1A1A19 for ; Mon, 6 Jul 2015 10:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yCOMYxt37Zub for ; Mon, 6 Jul 2015 10:42:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF551A07BD for ; Mon, 6 Jul 2015 10:42:03 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50506 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCAP4-000AQU-Bq for trans@ietf.org; Mon, 06 Jul 2015 13:42:02 -0400 Message-ID: <559ABDEA.5020905@bbn.com> Date: Mon, 06 Jul 2015 13:42:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> <067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org> <559A9977.1040808@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous 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, 06 Jul 2015 17:42:06 -0000 Ben, > On 6 July 2015 at 16:06, Stephen Kent wrote: >> If there is no standard for the validation checks logs perform, because of a >> desire to accept malformed certs from (sloppy) CAs, then a CA cannot know >> whether >> its submission will be rejected by a log. > If a CA wants to be sure in advance (why?) that a log will accept its > certs, then it should conform with the relevant standards. If we don't cite the "relevant standards" how does a submitter know what they are? Also, I thought your argument here was that there is no agreed upon set of standards to which all CAs adhere, so ... Steve From nobody Mon Jul 6 11:33:50 2015 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 525B51B2F5C for ; Mon, 6 Jul 2015 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7Xq-XesHOI1v for ; Mon, 6 Jul 2015 11:33:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7CB1B2F69 for ; Mon, 6 Jul 2015 11:33:46 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50733 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCBD6-000B2W-Oy for trans@ietf.org; Mon, 06 Jul 2015 14:33:44 -0400 Message-ID: <559ACA08.1090609@bbn.com> Date: Mon, 06 Jul 2015 14:33:44 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> In-Reply-To: <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 06 Jul 2015 18:33:47 -0000 I see your point. 6269-bis is mostly a document specifying the operation and interface to the log. Other parts of the document attempt to describe how clients interact with the log, but they do so only superficially. That's why I believe we need additional document specifying the behavior of the other elements of the CT system. You refer to "the protocol" but don't indicate which protocol you have in mind. I might agree that specs for TLS client behavior in the context of TLS exchanges are in scope. If so, 6269-bis needs to state that it updates TLS. Your interpretation of the WG's agreement to expunge client behavior from 6269-bis seems to encompass only the issue of whether a client rejects or accept a cert accompanied by a (valid) SCT. That strikes me as rather narrow. If a client that claims CT compliance MUST perform a series of checks to verify CT compliance of a cert, what does the client do if any of these tests fail? It's not useful to require a set of checks to be performed and yet not indicate what happens if they fail. If no action is required, then why bother performing the checks? If some action is required, or even recommended, then a spec needs to state what that behavior is. Steve > #77: normative client behavior specified in Section 5 > > Changes (bybenl@google.com): > > * milestone: => review > > > Comment: > > What has been ruled out of scope is what action clients take, not how they > conform to the protocol. > > Suggest close wontfix. > From nobody Mon Jul 6 11:34:11 2015 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 7D0181B2F84 for ; Mon, 6 Jul 2015 11:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sQCS0czgLMNT for ; Mon, 6 Jul 2015 11:34:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1371B2F26 for ; Mon, 6 Jul 2015 11:34:09 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:59144 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCBDU-000In9-LG for trans@ietf.org; Mon, 06 Jul 2015 14:34:08 -0400 Message-ID: <559ACA20.6000806@bbn.com> Date: Mon, 06 Jul 2015 14:34:08 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.ecfc9a319e455c61897ed3e82e509b78@tools.ietf.org> <067.1d7ff2839592524f118803e277a8d6d6@tools.ietf.org> In-Reply-To: <067.1d7ff2839592524f118803e277a8d6d6@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #70 (rfc6962-bis): STH spec needs to define top-level extension syntax 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, 06 Jul 2015 18:34:10 -0000 without a top-level format for SCT extensions, the current spec is incomplete, i.e., it includes a named data structure with no spec for the content of the structure. I'll send some suggested text. > #70: STH spec needs to define top-level extension syntax > > > Comment (bybenl@google.com): > > It was our view that we did not need to specify the format until the first > extension was defined. > > However, happy to consider proposed text. > From nobody Mon Jul 6 11:36:12 2015 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 51F511A898B for ; Mon, 6 Jul 2015 11:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HwUMQTczCNqB for ; Mon, 6 Jul 2015 11:36:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6431A1B1F for ; Mon, 6 Jul 2015 11:36:09 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:59148 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCBFQ-000Ipm-Ni; Mon, 06 Jul 2015 14:36:08 -0400 Message-ID: <559ACA98.2040509@bbn.com> Date: Mon, 06 Jul 2015 14:36:08 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Laurie References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 06 Jul 2015 18:36:11 -0000 Ben, > On 6 July 2015 at 15:50, Stephen Kent wrote: >> I note the following text from the -07 draft that appear to specify TLS >> client behavior: >> >> Section 1 >> >> TLS clients can thus require that all certificates they accept as valid >> have been logged. > This doesn't specify anything, just notes that clients can do it (if > they want to, obviously). the term disingenuous comes to mind here. >> Section 3 >> >> A certificate not >> accompanied by an SCT (either for the end-entity certificate or for a >> name-constrained intermediate the end-entity certificate chains to) >> MUST NOT be considered compliant by TLS clients. > Again, no behaviour is specified. The client is required to understand > that the cert is not in conformance with CT. It can do what it wants > with that understanding. This seems an attempt to have your cake and eat it too. We generally do not define "compliance" when there is no specified response to non-compliance. We do sometimes define compliance so that non-compliant data or behavior is ruled out of scope. But, that doesn't sem to be the intent here. But, in the spirit of compromise, how about: A certificate not accompanied by an SCT is not CT compliant. >> Section 3.4 >> >> TLS clients MUST implement all three mechanisms. > What we ruled out of scope is how clients behave in terms of user > interface, et al. Clearly a protocol document has to describe how the > protocol works. That is not the kind of behaviour we ruled out. OK. This is describing an extension of functionality for TLS to make use of CT. As such it updates (pick a version) of TLS. The headers for this doc need to state that the RFC(s) in question are updated by this doc. It also is customary to coordinate with the chairs of the WG responsible for the specs being updated. >> Section 3.4.1 >> >> TLS clients that support the extension SHOULD send a ClientHello >> extension with the appropriate type and empty "extension_data". >> >> TLS clients >> SHOULD include the extension type in the ClientHello, but if the >> session is resumed, the TLS server is not expected to process it or >> include the extension in the ServerHello. > See above. same as my response for 3.4 >> Section 5.3 >> >> >> In addition to normal validation of the certificate and its chain, TLS >> clients SHOULD validate the SCT by computing the signature input from >> the SCT data as well as the certificate and verifying the signature, >> using the corresponding log's public key. > And again. How about: A TLS client claiming conformance with CT MUST be capable of performing the following checks on a certificate accompanied by an SCT: - Matching the SCT to the certificate. This entails - Verifying the signature on the SCT. The signature on the SCT is verified using the public key for the log identified by the logID SCT. A TLS client claiming conformance with CT MUST be configurable (by the user or local administrator) to perform these checks, or not From nobody Mon Jul 6 11:46:29 2015 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 8027C1A92EB; Mon, 6 Jul 2015 11:46:24 -0700 (PDT) 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 HXRJ-Dv_n-0I; Mon, 6 Jul 2015 11:46:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C358E1B3015; Mon, 6 Jul 2015 11:46:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706184614.14496.16869.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 11:46:14 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-08.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:46:24 -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-08.txt Pages : 40 Date : 2015-07-06 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 12:15:12 2015 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 CEF221B3041 for ; Mon, 6 Jul 2015 12:15:11 -0700 (PDT) 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 KsSJeTjf8lC8 for ; Mon, 6 Jul 2015 12:15:11 -0700 (PDT) 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 1D0C71B302B for ; Mon, 6 Jul 2015 12:15:11 -0700 (PDT) Received: from localhost ([::1]:57141 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCBr6-00031A-DK; Mon, 06 Jul 2015 12:15:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:15:04 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/74#comment:4 Message-ID: <067.86008534ca25b0c3da003643c5ecbf5b@tools.ietf.org> References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <052.329e3339e14184dcd891ce5116d624c8@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, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706191511.1D0C71B302B@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:15:11 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:15:12 -0000 #74: normative statement of TLS client behavior in Section 3 Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => wontfix -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:22:40 2015 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 3591F1B3045 for ; Mon, 6 Jul 2015 12:22:32 -0700 (PDT) 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 yEwWU8wOSHHX for ; Mon, 6 Jul 2015 12:22:31 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C571ACE0C for ; Mon, 6 Jul 2015 12:22:30 -0700 (PDT) Received: by ykfs198 with SMTP id s198so52829293ykf.2 for ; Mon, 06 Jul 2015 12:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=yjn4A3AkEySoxbxOIA5F3mKib5biM0XvRzTXcb3ZYdo=; b=paX/+Q5kNyEL/paMfVNEjfFTtzyFcNky2JFTKfd7/fkKbIXCXdXAhULO6Eutpx7zBJ nle0MQHIQLoSoA/Cp04Ps6A+ZwZp7FgTO/Ym5o9Kq9OU7EmsMpDnQDg7o8NARRB0YpCk fSY/Ze0/Wccqk5yqv5gH43V28TQ8h2lzBVEEsQex1XAFFiREojssMyKAW5w4qzWUqAaL WPdHkHwHK+faAJy4VPftqP0PRiX5T/ylAxTdvGRfGaCxBzHlElERlATypplTneeIPwAu U39JYhrGKgVAOqgaTvoDiX612RPfMv5tsBqFSwooo78YVQ/gw7Tmbbu+cxTzobHOnaEa H5uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=yjn4A3AkEySoxbxOIA5F3mKib5biM0XvRzTXcb3ZYdo=; b=cWUdaaViWkRi1UA2ETaXtMkV6CEwY8VlP8JzIGczHCaQ6UlifhsGI8PvDjuAoHqq2f pQY/BGeo/2xxHX4H76Occpx7hz+rdBAg6YTRNtDztcriMXrRB99t1sShgWa5avpkX8cr tDtIYEOsilZBkaK2tz1VL2s46f2Y8M2zG0vb00GgZpaAhFDclQ6jfywZAGGdd1VnaLjz nanwvCMZ3O92S9jU+tOIqDFh3P2tfDyi8+EQuiImsYrvjxEdCSfSGNyPhqyLsW085UHg QkOG7DfI0qDvdVAmD+5eZGwKUleIa3+K+P9KrYsbwMC5Lfm4b7WV/TnlMUH9hR/Z3u1N jhaQ== X-Gm-Message-State: ALoCoQkicH4kYj8FyyvV95l6hUlbzSNEtQPU35rySxKWxUmBXDJC1F3wQRTFTMa+pp+Dv8Jbxb5S X-Received: by 10.129.110.70 with SMTP id j67mr534628ywc.86.1436210550184; Mon, 06 Jul 2015 12:22:30 -0700 (PDT) MIME-Version: 1.0 References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> <20150629230458.GX30545@hezmatt.org> In-Reply-To: From: Adam Eijdenberg Date: Mon, 06 Jul 2015 19:22:18 +0000 Message-ID: To: Ben Laurie , Matt Palmer Content-Type: multipart/alternative; boundary=001a11492528ab14f4051a39d3f3 Archived-At: Cc: "trans@ietf.org" , Ondrej Mikle Subject: Re: [Trans] Verifying inclusion proof 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, 06 Jul 2015 19:22:32 -0000 --001a11492528ab14f4051a39d3f3 Content-Type: text/plain; charset=UTF-8 To close this thread out, there were some errors in my previous code and algorithms in this thread. They have been corrected and added under section 5.5 in the new version of the Internet Draft published earlier today: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08#section-5.5 I hope the new section is helpful for client implementors. --001a11492528ab14f4051a39d3f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To close this thread out, there were some errors in my pre= vious code and algorithms in this thread.=C2=A0 They have been corrected an= d added under section 5.5 in the new version of the Internet Draft publishe= d earlier today:

I hope the new section is helpful for client implementors.
--001a11492528ab14f4051a39d3f3-- From nobody Mon Jul 6 12:25:31 2015 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 1F5F31AD2F2 for ; Mon, 6 Jul 2015 12:25:31 -0700 (PDT) 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 mrZRNAyKybzC for ; Mon, 6 Jul 2015 12:25:30 -0700 (PDT) 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 446381AC3D8 for ; Mon, 6 Jul 2015 12:25:30 -0700 (PDT) Received: from localhost ([::1]:59090 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC19-00055i-MT; Mon, 06 Jul 2015 12:25:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:25:27 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/65#comment:3 Message-ID: <067.67d15adf93d892780bfd63ec7bf00da0@tools.ietf.org> References: <052.7b8731a1601d369a3b2ae85631ff646b@tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <052.7b8731a1601d369a3b2ae85631ff646b@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, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706192530.446381AC3D8@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:25:30 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #65 (rfc6962-bis): remove section 5.4 and reference to "Auditor" in section 3 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:25:31 -0000 #65: remove section 5.4 and reference to "Auditor" in section 3 Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:26:45 2015 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 A63C51B3046 for ; Mon, 6 Jul 2015 12:26:44 -0700 (PDT) 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 G5GRvlU-KCnp for ; Mon, 6 Jul 2015 12:26:43 -0700 (PDT) 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 DD2D91B305E for ; Mon, 6 Jul 2015 12:26:42 -0700 (PDT) Received: from localhost ([::1]:59159 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC2K-00013i-GZ; Mon, 06 Jul 2015 12:26:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:26:40 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/73#comment:4 Message-ID: <067.f1b6abef7579999468826f17ad9e06b7@tools.ietf.org> References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <052.b3ecc6ca8b28cc47e13443079611ce86@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, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706192642.DD2D91B305E@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:26:42 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:26:44 -0000 #73: Section 3 text re log cert validation is ambiguous Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:28:09 2015 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 BB2401B305E for ; Mon, 6 Jul 2015 12:28:08 -0700 (PDT) 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 j8F1xpObi73S for ; Mon, 6 Jul 2015 12:28:08 -0700 (PDT) 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 EE41E1B304F for ; Mon, 6 Jul 2015 12:28:07 -0700 (PDT) Received: from localhost ([::1]:59242 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC3g-0006qS-Vh; Mon, 06 Jul 2015 12:28:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:28:04 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/63#comment:4 Message-ID: <067.f8a4649b505bb364b3c33557256f1013@tools.ietf.org> References: <052.2f8736daa2848e7838235c5604063f8e@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <052.2f8736daa2848e7838235c5604063f8e@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, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706192807.EE41E1B304F@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:28:07 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #63 (rfc6962-bis): remove all normative references to client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:28:08 -0000 #63: remove all normative references to client behavior Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => wontfix -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: Active WG | Resolution: wontfix Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:28:32 2015 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 B25D81B3069 for ; Mon, 6 Jul 2015 12:28:30 -0700 (PDT) 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 TjkLTCpHpile for ; Mon, 6 Jul 2015 12:28:28 -0700 (PDT) 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 836341B3053 for ; Mon, 6 Jul 2015 12:28:28 -0700 (PDT) Received: from localhost ([::1]:59259 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC42-0008GG-IP; Mon, 06 Jul 2015 12:28:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:28:26 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:3 Message-ID: <067.625e6e3da31253e290a00c75d83df77d@tools.ietf.org> References: <052.0789019d9e32c9233f0440891ac5bb94@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <052.0789019d9e32c9233f0440891ac5bb94@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, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706192828.836341B3053@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:28:28 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:28:30 -0000 #76: Normative client behavior specified in Section 3.4 Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:28:53 2015 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 308701B306C for ; Mon, 6 Jul 2015 12:28:51 -0700 (PDT) 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 4Y4KPkonE2Dh for ; Mon, 6 Jul 2015 12:28:50 -0700 (PDT) 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 E4DC81B307D for ; Mon, 6 Jul 2015 12:28:47 -0700 (PDT) Received: from localhost ([::1]:59276 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC4N-0000tj-3H; Mon, 06 Jul 2015 12:28:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:28:47 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/84#comment:2 Message-ID: <070.8709b74aebf60e75bafbe0e12e1370c2@tools.ietf.org> References: <055.ea272dc06c58ca33b8cd9ebbf05ce7b3@tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <055.ea272dc06c58ca33b8cd9ebbf05ce7b3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150706192847.E4DC81B307D@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:28:47 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #84 (rfc6962-bis): Clarify that root certs have empty certificate_chain X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:28:51 -0000 #84: Clarify that root certs have empty certificate_chain Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- linus@nordu.net | rfc6962-bis@tools.ietf.org Type: enhancement | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:29:09 2015 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 C8A9A1B306C for ; Mon, 6 Jul 2015 12:29:07 -0700 (PDT) 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 zH9XOXr9YoYF for ; Mon, 6 Jul 2015 12:29:06 -0700 (PDT) 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 54F8C1B3069 for ; Mon, 6 Jul 2015 12:29:06 -0700 (PDT) Received: from localhost ([::1]:59290 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC4f-0001oL-Hw; Mon, 06 Jul 2015 12:29:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:29:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/90#comment:2 Message-ID: <076.d9450a4dc5d0f38c954f5fa53d8a5008@tools.ietf.org> References: <061.6c57439d9835c35d408ea3940c9d0efe@tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <061.6c57439d9835c35d408ea3940c9d0efe@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150706192906.54F8C1B3069@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:29:06 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #90 (rfc6962-bis): Clarify how to turn a MerkleTreeLeaf into a leaf hash X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:29:07 -0000 #90: Clarify how to turn a MerkleTreeLeaf into a leaf hash Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eijdenberg@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:29:41 2015 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 577BE1B3069 for ; Mon, 6 Jul 2015 12:29:38 -0700 (PDT) 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 daan_XWnZFPj for ; Mon, 6 Jul 2015 12:29:37 -0700 (PDT) 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 17D581B304C for ; Mon, 6 Jul 2015 12:29:35 -0700 (PDT) Received: from localhost ([::1]:59306 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC57-00035o-C0; Mon, 06 Jul 2015 12:29:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:29:33 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/69#comment:3 Message-ID: <067.ea67a1cfd922f30ecad3a0ff51695988@tools.ietf.org> References: <052.7e80f7bf1c6616fe0bce0b76bfc16561@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <052.7e80f7bf1c6616fe0bce0b76bfc16561@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, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706192935.17D581B304C@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:29:35 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #69 (rfc6962-bis): old data name (sha256_root_hash) in 3.6 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:29:38 -0000 #69: old data name (sha256_root_hash) in 3.6 Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:30:19 2015 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 D52D11A9096 for ; Mon, 6 Jul 2015 12:30:17 -0700 (PDT) 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 rigmDYFTuJT1 for ; Mon, 6 Jul 2015 12:30:17 -0700 (PDT) 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 D3F5D1B3063 for ; Mon, 6 Jul 2015 12:30:07 -0700 (PDT) Received: from localhost ([::1]:59332 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC5e-00045C-5T; Mon, 06 Jul 2015 12:30:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:30:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/68#comment:3 Message-ID: <067.4397929085a5cac628bbe8475f6a8c0b@tools.ietf.org> References: <052.b40b5491f0d964b6f2806f2262e10952@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <052.b40b5491f0d964b6f2806f2262e10952@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, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150706193007.D3F5D1B3063@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:30:07 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #68 (rfc6962-bis): specification of sha-256 for the SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:30:18 -0000 #68: specification of sha-256 for the SCT Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:30:34 2015 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 E6FE81B309D for ; Mon, 6 Jul 2015 12:30:32 -0700 (PDT) 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 8Lv9gToAkjz8 for ; Mon, 6 Jul 2015 12:30:29 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35F71B309B for ; Mon, 6 Jul 2015 12:30:20 -0700 (PDT) Received: (qmail 10610 invoked by uid 1004); 6 Jul 2015 19:30:19 -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, 06 Jul 2015 20:30:19 +0100 Received: (qmail 24694 invoked by uid 1000); 6 Jul 2015 19:30:19 -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, 06 Jul 2015 20:30:19 +0100 Message-ID: <559AD74A.5030806@comodo.com> Date: Mon, 06 Jul 2015 20:30:18 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org><559A9977.1040808@bbn.com> <559A9B83.6040000@comodo.com> <559AA60A.1060501@bbn.com> In-Reply-To: <559AA60A.1060501@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re logcertvalidation is ambiguous 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, 06 Jul 2015 19:30:33 -0000 On 06/07/15 17:00, Stephen Kent wrote: > Rob, > > Having a cert rejected does not tell the submitter (CA or otherwise) > why, and thus the submitted doesn't know how to resolve the problem. Are the folks that work for (sloppy) CAs really incapable of reading RFC5280 for themselves, incapable of examining their rejected certs to discover the problem(s) for themselves, and incapable of finding a suitable mailing list on which to ask questions if they get stuck? I really don't see why we should over-complicate CT logs just to assist sloppy/lazy/incompetent CAs that are already expected (by the various web browser root cert inclusion programs) to be familiar with RFC5280. It's likely that CT logs will not implement their own RFC5280 certificate processing code. The certificate-transparency.org code, for example, uses OpenSSL. If OpenSSL rejects a blob of data that is allegedly a cert, the error stack doesn't always explain precisely why the blob of data was rejected. Sometimes you just have to resort to reviewing an ASN.1 dump or firing up a hex editor. So I think the implication of what you're requesting might be that CT logs cannot use third-party RFC5280 certificate processing libraries at all! Do any other IETF protocols that validate certs return a precise explanation for rejection if rejection occurs? I don't see a fully enumerated list of reasons for rejecting a "cert" in the TLS 1.2 spec, for example. So why should 6962-bis be required to do this? > Steve > >> On 06/07/15 16:06, Stephen Kent wrote: >>> If there is no standard for the validation checks logs perform, because >>> of a desire to accept malformed certs from (sloppy) CAs, then a CA >>> cannot >>> know whether its submission will be rejected by a log. >> >> Huh? Why can't the (potentially sloppy) CA call add-chain (or >> add-pre-chain) and see what happens? >> >> Either the log will return an SCT (in which case it accepted the >> submission), or it won't (in which case it rejected the submission). > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jul 6 12:30:53 2015 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 487A01B304F for ; Mon, 6 Jul 2015 12:30:52 -0700 (PDT) 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 Rm6-QMKgkjoA for ; Mon, 6 Jul 2015 12:30:51 -0700 (PDT) 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 033F21B30A6 for ; Mon, 6 Jul 2015 12:30:40 -0700 (PDT) Received: from localhost ([::1]:59364 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC67-0005rn-UY; Mon, 06 Jul 2015 12:30:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:30:35 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/92#comment:3 Message-ID: <079.aa258fed84f6384d556bc54f01e80f82@tools.ietf.org> References: <064.d9fa313d805f15d47ba200812a5627d6@tools.ietf.org> X-Trac-Ticket-ID: 92 In-Reply-To: <064.d9fa313d805f15d47ba200812a5627d6@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] #92 (rfc6962-bis): get-entries needs to return the whole X509ChainEntry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:30:52 -0000 #92: get-entries needs to return the whole X509ChainEntry Changes (by melinda.shore@gmail.com): * status: reopened => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | 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 Mon Jul 6 12:31:07 2015 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 4B5DE1B3018 for ; Mon, 6 Jul 2015 12:31:06 -0700 (PDT) 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 YPOVveNraF5V for ; Mon, 6 Jul 2015 12:31:05 -0700 (PDT) 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 E80EE1B30AC for ; Mon, 6 Jul 2015 12:30:58 -0700 (PDT) Received: from localhost ([::1]:59379 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC6R-00070z-DQ; Mon, 06 Jul 2015 12:30:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:30:55 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/91#comment:3 Message-ID: <071.a0bddd9f33fab22965e495b17431ec5b@tools.ietf.org> References: <056.1a3a0b4df721b59933a4c32a232c7f3e@tools.ietf.org> X-Trac-Ticket-ID: 91 In-Reply-To: <056.1a3a0b4df721b59933a4c32a232c7f3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #91 (rfc6962-bis): Clarify encoding of fields in the log client messages X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:31:06 -0000 #91: Clarify encoding of fields in the log client messages Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:31:18 2015 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 4EA4F1B3061 for ; Mon, 6 Jul 2015 12:31:16 -0700 (PDT) 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 wQp8XVULX3IA for ; Mon, 6 Jul 2015 12:31:15 -0700 (PDT) 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 3D1BE1B3036 for ; Mon, 6 Jul 2015 12:31:10 -0700 (PDT) Received: from localhost ([::1]:59393 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCC6f-00081w-Aa; Mon, 06 Jul 2015 12:31:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 06 Jul 2015 19:31:09 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/86#comment:2 Message-ID: <070.c43aeecb659711642ffa1cde82c08314@tools.ietf.org> References: <055.e79a51ea71a962f252e762da97b30a02@tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <055.e79a51ea71a962f252e762da97b30a02@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150706193110.3D1BE1B3036@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 12:31:10 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #86 (rfc6962-bis): SCTs should be returned in final format X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:31:16 -0000 #86: SCTs should be returned in final format Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 6 12:50:20 2015 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 8BD4D1B313D for ; Mon, 6 Jul 2015 12:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y8ebgyRDKG3v for ; Mon, 6 Jul 2015 12:50:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8061B309C for ; Mon, 6 Jul 2015 12:50:15 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:59307 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCCP7-000KVZ-Iw; Mon, 06 Jul 2015 15:50:13 -0400 Message-ID: <559ADBF5.7000807@bbn.com> Date: Mon, 06 Jul 2015 15:50:13 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rob Stradling , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org><559A9977.1040808@bbn.com> <559A9B83.6040000@comodo.com> <559AA60A.1060501@bbn.com> <559AD74A.5030806@comodo.com> In-Reply-To: <559AD74A.5030806@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re logcertvalidation is ambiguous 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, 06 Jul 2015 19:50:18 -0000 Rob, > On 06/07/15 17:00, Stephen Kent wrote: >> Rob, >> >> Having a cert rejected does not tell the submitter (CA or otherwise) >> why, and thus the submitted doesn't know how to resolve the problem. > > Are the folks that work for (sloppy) CAs really incapable of reading > RFC5280 for themselves, incapable of examining their rejected certs to > discover the problem(s) for themselves, and incapable of finding a > suitable mailing list on which to ask questions if they get stuck? I think may have misunderstood my point. I did not request that a log return an error indicating why a cert failed the logs checks. I asked that there be a deterministic way for a submitter to know whether a cert will pass. That can be accomplished in (at least) two ways: establish a standard set of checks that all logs perform, or establish a way to each log to state what set of checks it performs. Steve From nobody Mon Jul 6 13:04:01 2015 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 57B0C1ACE35 for ; Mon, 6 Jul 2015 13:04:00 -0700 (PDT) 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 8kgIdco2udFc for ; Mon, 6 Jul 2015 13:03:58 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116211ACDCE for ; Mon, 6 Jul 2015 13:03:58 -0700 (PDT) Received: (qmail 11904 invoked by uid 1004); 6 Jul 2015 20:03:56 -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, 06 Jul 2015 21:03:56 +0100 Received: (qmail 18886 invoked by uid 1000); 6 Jul 2015 20:03:56 -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, 06 Jul 2015 21:03:56 +0100 Message-ID: <559ADF2B.3050507@comodo.com> Date: Mon, 06 Jul 2015 21:03:55 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org><559A9977.1040808@bbn.com> <559A9B83.6040000@comodo.com> <559AA60A.1060501@bbn.com> <559AD74A.5030806@comodo.com> <559ADBF5.7000807@bbn.com> In-Reply-To: <559ADBF5.7000807@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re logcertvalidationis ambiguous 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, 06 Jul 2015 20:04:00 -0000 On 06/07/15 20:50, Stephen Kent wrote: > Rob, > >> On 06/07/15 17:00, Stephen Kent wrote: >>> Rob, >>> >>> Having a cert rejected does not tell the submitter (CA or otherwise) >>> why, and thus the submitted doesn't know how to resolve the problem. >> >> Are the folks that work for (sloppy) CAs really incapable of reading >> RFC5280 for themselves, incapable of examining their rejected certs to >> discover the problem(s) for themselves, and incapable of finding a >> suitable mailing list on which to ask questions if they get stuck? > > I think may have misunderstood my point. I did not request that a log > return an error indicating why a cert failed the logs checks. I asked > that there be a deterministic way for a submitter to know whether a > cert will pass. Ah, I see. > That can be accomplished in (at least) two ways: > establish a standard set of checks that all logs perform The I-D already says: "Logs MUST accept certificates that are fully valid according to RFC 5280 [RFC5280] verification rules and are submitted with such a chain." So the "deterministic way for a submitter to know whether a cert will pass" is for the submitter to ensure that the cert is fully compliant with RFC5280 verification rules and is supplied with a chain up to a root cert that the log accepts. We don't want to encourage submitter CAs to needlessly violate RFC5280, so I see no good reason why we should turn the following behaviour into something deterministic: "Logs MAY accept certificates and precertificates that have expired, are not yet valid, have been revoked, or are otherwise not fully valid according to RFC 5280 verification rules in order to accommodate quirks of CA certificate-issuing software." > , or establish a way to each log to state what set of checks it performs. > > Steve > > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jul 6 18:17:21 2015 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 353561A8837 for ; Mon, 6 Jul 2015 18:17:20 -0700 (PDT) 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 D_CWdkBGp0-i for ; Mon, 6 Jul 2015 18:17:19 -0700 (PDT) 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 553D51A8831 for ; Mon, 6 Jul 2015 18:17:19 -0700 (PDT) Received: from localhost ([::1]:59620 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCHVY-0007LR-4r; Mon, 06 Jul 2015 18:17:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, dkg@fifthhorseman.net X-Trac-Project: trans Date: Tue, 07 Jul 2015 01:17:12 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:4 Message-ID: <067.6729350be3a8e613c532093ddfa14c95@tools.ietf.org> References: <052.0789019d9e32c9233f0440891ac5bb94@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <052.0789019d9e32c9233f0440891ac5bb94@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, benl@google.com, melinda.shore@gmail.com, dkg@fifthhorseman.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150707011719.553D51A8831@ietfa.amsl.com> Resent-Date: Mon, 6 Jul 2015 18:17:19 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4 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, 07 Jul 2015 01:17:20 -0000 #76: Normative client behavior specified in Section 3.4 Changes (by dkg@fifthhorseman.net): * status: closed => reopened * resolution: fixed => Comment: [https://mailarchive.ietf.org/arch/msg/trans/DmYfE7Slx8DVCSrvyjS7nVfSc3w Steve Kent says]: > no. it is not fixed. See my message citing specific instances of > normative client behavior in 3 and 3.4 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jul 7 02:09:44 2015 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 71D541A86E4 for ; Tue, 7 Jul 2015 02:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 NBzljIDpsPDH for ; Tue, 7 Jul 2015 02:09:39 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 79FC91A7D82 for ; Tue, 7 Jul 2015 02:09:39 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6799aRx008198 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 7 Jul 2015 11:09:36 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t6799X5W006672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2015 09:09:36 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1436260176; bh=E0nq68WS1pxgM9MRo9clFsd/OxqO4OFWtUyJnryWIxU=; h=From:To:Subject:Date; b=aXxtfeHd4C0ixdj/7cNHuKzHGl6ksOoEEgx27M1kb0eKP6XGVeISYrjJgxNPtAEjs 4RvzwTmG9Dx9yvwKI9POpTD2y0FofPfFeCJ8of8qCjZV6Z/9nFN03g2q64rXcipyxU V+WKrOT6dWzXlBos7yp/6Pnin4Ex7DRKrQe+Ii6g= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) for trans@ietf.org; Tue, 7 Jul 2015 11:14:17 +0200 From: Linus Nordberg To: trans@ietf.org Organization: NORDUnet A/S Date: Tue, 07 Jul 2015 11:09:52 +0200 Message-ID: <87io9w1ggv.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aONl9AUH - d28603b125c4 - 20150707 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: [Trans] [internet-drafts@ietf.org] New Version Notification for draft-linus-trans-gossip-ct-02.txt 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, 07 Jul 2015 09:09:42 -0000 --=-=-= Content-Type: text/plain Hi, There's a -02 of the gossip draft. We will give a quick status update in Prague. In the meantime, comments and discussion on the list are of course more than welcome. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL: 0.000,BAYES_00: -1.665,TOTAL_SCORE: -1.665,autolearn=ham X-Spam-Level: Received: from smtp1.nordu.net ([109.105.111.32]) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) for linus@kerio.nordu.net; Tue, 7 Jul 2015 00:24:05 +0200 Received: from e-mailfilter03.sunet.se (e-mailfilter03.sunet.se [192.36.171.203]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t66MJHls021513 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 6 Jul 2015 22:19:20 GMT Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1900:3001:11::2c]) by e-mailfilter03.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t66MHwhw022441 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 7 Jul 2015 00:18:17 +0200 Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4301A1BD9; Mon, 6 Jul 2015 15:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO7L2Gc-fanI; Mon, 6 Jul 2015 15:17:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8BB1A1B65; Mon, 6 Jul 2015 15:17:54 -0700 (PDT) From: internet-drafts@ietf.org To: "Linus Nordberg" , "Linus Nordberg" , "Tom Ritter" , "Daniel Kahn Gillmor" , "Daniel Kahn Gillmor" , "Tom Ritter" Subject: New Version Notification for draft-linus-trans-gossip-ct-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706221754.28247.93545.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 15:17:54 -0700 X-Bayes-Prob: 0.0001 (Score 0, tokens from: linus@nordu.net, nordu-net:default, base:default, @@RPTN) X-Spam-Score: 0.00 () [Tag at 5.00] SPF(pass:0) X-p0f-Info: os=Linux 3.x, link=Ethernet or modem X-CanIt-Geo: ip=2001:1900:3001:11::2c; country=US; latitude=38.0000; longitude=-97.0000; http://maps.google.com/maps?q=38.0000,-97.0000&z=6 X-CanItPRO-Stream: nordu-net:linus@nordu.net (inherits from nordu-net:default,base:default) X-Canit-Stats-ID: 0bONai0jA - 04e4ce899bca - 20150707 (trained as not-spam) X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0bONai0jA&m=04e4ce899bca&t=20150707&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0bONai0jA&m=04e4ce899bca&t=20150707&c=n X-Antispam-Training-Phish: https://mailfilter.nordu.net/canit/b.php?i=0bONai0jA&m=04e4ce899bca&t=20150707&c=p X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0bONai0jA&m=04e4ce899bca&t=20150707&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: pass (e-mailfilter03.sunet.se: domain of internet-drafts@ietf.org designates 2001:1900:3001:11::2c as permitted sender) receiver=e-mailfilter03.sunet.se; client-ip=2001:1900:3001:11::2c; envelope-from=; helo=mail.ietf.org; identity=mailfrom X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-Scanned-By: CanIt (www . roaringpenguin . com) MIME-Version: 1.0 Content-Type: text/plain A new version of I-D, draft-linus-trans-gossip-ct-02.txt has been successfully submitted by Linus Nordberg and posted to the IETF repository. Name: draft-linus-trans-gossip-ct Revision: 02 Title: Gossiping in CT Document date: 2015-07-07 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-linus-trans-gossip-ct-02.txt Status: https://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ Htmlized: https://tools.ietf.org/html/draft-linus-trans-gossip-ct-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-linus-trans-gossip-ct-02 Abstract: This document describes three gossiping mechanisms for Certificate Transparency (CT) [RFC6962]: SCT Feedback, STH Pollination and Trusted Auditor Relationship. SCT Feedback enables HTTPS clients to share Signed Certificate Timestamps (SCTs) (Section 3.2 of [RFC6962]) with CT auditors in a privacy-preserving manner by sending SCTs to originating HTTPS servers which in turn share them with CT auditors. In STH Pollination, HTTPS clients use HTTPS servers as pools sharing Signed Tree Heads (STHs) (Section 3.5 of [RFC6962]) with other connecting clients in the hope that STHs will find their way to auditors and monitors. HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs with trusted auditors or monitors directly, with expectations of privacy sensitive data being handled according to whatever privacy policy is agreed on between client and trusted party. 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. The IETF Secretariat --=-=-=-- From nobody Tue Jul 7 06:09:22 2015 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 4F5B51A0390 for ; Tue, 7 Jul 2015 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, 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 7g3vPntQnCz5 for ; Tue, 7 Jul 2015 06:09:20 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3600A1A038F for ; Tue, 7 Jul 2015 06:09:20 -0700 (PDT) Received: by ykdr198 with SMTP id r198so176572530ykd.3 for ; Tue, 07 Jul 2015 06:09:19 -0700 (PDT) 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=fPfDIwXZ5ZVyBJRC3betuALjF+gKrg71b31lWShrjOM=; b=l/vzJWukS9mz10bWo5fGtHTfYTPSWcPxoQdCY3IVPvJCoplnMgSVVgesZHsDYfjIJY zDZeUJQAxw7SrNjBWAwprM77rzUl9INyaYthZUBCQ3BFGrdquhXSnB09JKXvbR4naGNV zZKqw4Go5j+tVxXlZUmhc8U/AYlomdPMOTFuYCU/BN27eeuH5TLLnx40aEbkcN72Zjan XgFPWFah0nwVS9PIFCzpma/VCXgrSQa1w4M0tZrcv1W47ggvc+q7MEDLXrrl9mqbbX/5 W4CG6BdVFI1P4n9HeN6YjxGCMH9q4I8eR7twZv7BTtXph7WakeuCdM7S0YwEEk2NqPmP 7DlQ== 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=fPfDIwXZ5ZVyBJRC3betuALjF+gKrg71b31lWShrjOM=; b=h31tj0DPEMpmr6TWPAVQLUuZyFHobggahgpP10/nSxFZitNepErQd+M4sIAZp/4tXX U3vWoQdYZDVkvrsjADlM0YIPrbMjYnW+X/+Ya+Qmn0vZp6Mcq83CZReUmShsKOODzo4w kiTtxeGRwtD9Inmx4crAUKuKw/j13KKd4yOzpJSW2ChIWPr46fahaCl5TmuUWA1sIwNR egCXVBIek4lCz42thuDenuHSaP6ajKoJcE1sid9uc3oEL+fxWj7wmIDE+56gh/Gz6cVH oE2hAtljpKN0TCys5iBY/LflTNeJ7YGst9Q8HjfaWRPwJyhRskeqGWRs68jJ9MExsZT+ A8jg== X-Gm-Message-State: ALoCoQng+W5tPkVgpgie1FUWJBOYj62Tr9QddubmmTg9ov1NrLTTw6amkEDAGC2PhgGNSIkC88Cx MIME-Version: 1.0 X-Received: by 10.170.212.130 with SMTP id d124mr4742108ykf.47.1436274559504; Tue, 07 Jul 2015 06:09:19 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Tue, 7 Jul 2015 06:09:19 -0700 (PDT) In-Reply-To: References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> <20150629230458.GX30545@hezmatt.org> Date: Tue, 7 Jul 2015 14:09:19 +0100 Message-ID: From: Ben Laurie To: Adam Eijdenberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Matt Palmer , "trans@ietf.org" , Ondrej Mikle Subject: Re: [Trans] Verifying inclusion proof 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, 07 Jul 2015 13:09:21 -0000 On 6 July 2015 at 20:22, Adam Eijdenberg wrote: > To close this thread out, there were some errors in my previous code and > algorithms in this thread. They have been corrected and added under section > 5.5 in the new version of the Internet Draft published earlier today: > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08#section-5.5 > > I hope the new section is helpful for client implementors. BTW, Adam also implemented the algorithms to test them, you can find them here: https://github.com/google/certificate-transparency-rfcs/blob/master/test_rfc_algorithms.py. From nobody Tue Jul 7 06:23:02 2015 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 2F32F1A8952 for ; Tue, 7 Jul 2015 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, 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 cxpTZu8ce67i for ; Tue, 7 Jul 2015 06:23:00 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DA11A8879 for ; Tue, 7 Jul 2015 06:22:59 -0700 (PDT) Received: by ykeo3 with SMTP id o3so56626587yke.0 for ; Tue, 07 Jul 2015 06:22:58 -0700 (PDT) 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=vh/vHGUYoupIDz4SXxbKIVMPPZP4gTzvKYR0BfkUIdc=; b=V/zQXoRSVrf0RfOnX1ZTH/4TXtT0b19C1Ca+ISMhMx/C/YLKgT8QlKwB07O5I7WoRF L85PAr+oJU4LEDKymEs8ZyjzdinDhgiNklkjRzrPfD4H3W+DFi5OyU8vrSB8pq1uBzH9 1ourADTN+myBRD7TDo4m4n1BqQa56Mq8IWDHtY81aywxPKt+jlitGcfA/vJyD1cX1CkK Vlf0yaHZfPhPuhfcIAeBcc50x6/XmhKs7WGTTrzywzw1HbW78kS3FN0I0chDtDphJbxE 4WBkMwLqc2SEsCELl2l/iTz+/LOV4wHWYipjXH3sFC5W4HHpO+mVpFx4mxLx1USSQEtA l2Sg== 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=vh/vHGUYoupIDz4SXxbKIVMPPZP4gTzvKYR0BfkUIdc=; b=g7TloakOeiHcc0/Cdmery5ebpTzWjUpecyPoUdEOLc5rrPO5kVpsHiwXyFQF/Uv09I b5k2vCyItrdR1+FIQR3mvXOnc4W5MUPngjSDyvvZxBMiNrhRbo2EC0QpFFznOl6i/xRQ 2Qx38ZeqIUC+GYINkWOY0yVSxTsB68XXIEF1AcpectO4Gir8bz0yq/Lab4qoZHnF0qzf 50lPu/0IzPDCChQpz1Den85Qu4km+3mjIpADJJB5b8B0uTWb4LMbNEy8vAa9AOcsHHJB 7ZMIn/20h/dEbJlUouWft0eJU8njhHdhWqAe7qOt9UecvEx6p/Ou6j9kRNt+fDnJPTtB HYRg== X-Gm-Message-State: ALoCoQlIUi6jneREktPC7h9+9OzvXfuuUo0qC6f9S7At/sA+JbRAPNgESHtGJ6gxv3p79lVinPaU MIME-Version: 1.0 X-Received: by 10.170.45.78 with SMTP id 75mr4894942ykn.53.1436275378390; Tue, 07 Jul 2015 06:22:58 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Tue, 7 Jul 2015 06:22:58 -0700 (PDT) In-Reply-To: <559ACA98.2040509@bbn.com> References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> <559ACA98.2040509@bbn.com> Date: Tue, 7 Jul 2015 14:22:58 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 07 Jul 2015 13:23:01 -0000 On 6 July 2015 at 19:36, Stephen Kent wrote: > Ben, > > >> On 6 July 2015 at 15:50, Stephen Kent wrote: >>> >>> I note the following text from the -07 draft that appear to specify TLS >>> client behavior: >>> >>> Section 1 >>> >>> TLS clients can thus require that all certificates they accept as >>> valid >>> have been logged. >> >> This doesn't specify anything, just notes that clients can do it (if >> they want to, obviously). > > the term disingenuous comes to mind here. >>> >>> Section 3 >>> >>> A certificate not >>> accompanied by an SCT (either for the end-entity certificate or for a >>> name-constrained intermediate the end-entity certificate chains to) >>> MUST NOT be considered compliant by TLS clients. >> >> Again, no behaviour is specified. The client is required to understand >> that the cert is not in conformance with CT. It can do what it wants >> with that understanding. > > This seems an attempt to have your cake and eat it too. We generally do not > define "compliance" when there is no specified response to non-compliance. > We do sometimes define compliance so that non-compliant data or behavior is > ruled out of scope. But, that doesn't sem to be the intent here. > > But, in the spirit of compromise, how about: > > A certificate not accompanied by an SCT is not CT compliant. This seems redundant: I would've thought that in general everything in an RFC only applies to things that are compliant with that RFC. But if the WG wants I don't really mind either way. >>> >>> Section 3.4 >>> >>> TLS clients MUST implement all three mechanisms. >> >> What we ruled out of scope is how clients behave in terms of user >> interface, et al. Clearly a protocol document has to describe how the >> protocol works. That is not the kind of behaviour we ruled out. > > OK. This is describing an extension of functionality for TLS to make use of > CT. As such it updates (pick a version) of TLS. The headers for this > doc need to state that the RFC(s) in question are updated by this doc. It > also is customary to coordinate with the chairs of the WG responsible for > the specs being updated. OK, I get your point here, and I am happy to go either way: a) Update TLS to require CT, or b) Update the I-D to say something like "CT compliant TLS clients" or as you use below "TLS clients claiming conformance with CT", which presumably does not update TLS? I guess it is not up to me to decide which. >>> Section 3.4.1 >>> >>> TLS clients that support the extension SHOULD send a ClientHello >>> extension with the appropriate type and empty "extension_data". >>> >>> TLS clients >>> SHOULD include the extension type in the ClientHello, but if the >>> session is resumed, the TLS server is not expected to process it or >>> include the extension in the ServerHello. >> >> See above. > > same as my response for 3.4 >>> >>> Section 5.3 >>> >>> >>> In addition to normal validation of the certificate and its chain, >>> TLS >>> clients SHOULD validate the SCT by computing the signature input from >>> the SCT data as well as the certificate and verifying the signature, >>> using the corresponding log's public key. >> >> And again. > > How about: > > A TLS client claiming conformance with CT MUST be capable of performing the > following > checks on a certificate accompanied by an SCT: > - Matching the SCT to the certificate. This entails the hash > that Rob is adding to the SCT> > - Verifying the signature on the SCT. The signature on the SCT is > verified using > the public key for the log identified by the logID SCT. > A TLS client claiming conformance with CT MUST be configurable (by the user > or local > administrator) to perform these checks, or not > > From nobody Tue Jul 7 06:27:02 2015 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 640CC1A895E for ; Tue, 7 Jul 2015 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RulQVOZV_FnE for ; Tue, 7 Jul 2015 06:26:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4241A8871 for ; Tue, 7 Jul 2015 06:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86DB8BDCF; Tue, 7 Jul 2015 14:26:47 +0100 (IST) 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 pbqgdiFqvxA3; Tue, 7 Jul 2015 14:26:47 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C8A2BE53; Tue, 7 Jul 2015 14:26:46 +0100 (IST) Message-ID: <559BD396.7050702@cs.tcd.ie> Date: Tue, 07 Jul 2015 14:26:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Laurie , Stephen Kent References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> <559ACA98.2040509@bbn.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 07 Jul 2015 13:27:01 -0000 On 07/07/15 14:22, Ben Laurie wrote: > a) Update TLS to require CT, That'd not be a good plan. TLS is used for lots more than just the web and there aren't logs for many things, e.g. corporate CAs are presumably much more of a deal for EAP-TLS. S. From nobody Tue Jul 7 06:45:13 2015 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 EE6FF1A020A for ; Tue, 7 Jul 2015 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, 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 NYkjanHTgsLh for ; Tue, 7 Jul 2015 06:45:10 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 A4CD51A8879 for ; Tue, 7 Jul 2015 06:45:10 -0700 (PDT) Received: by ykeo3 with SMTP id o3so57238562yke.0 for ; Tue, 07 Jul 2015 06:45:10 -0700 (PDT) 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=y6kiYG9xw8NiArHHQw0sqmaSG6oH6HwQNnv2FxFTS/4=; b=LOKhi6p5EMvowRnj6IUlcq4eaORBVbj5nmelvsJEKoi4c7GQEwBWgwMWfI0qgm8Aam Y4u3Ng12EWnG9CLR3angP5eZzlXAQvo6yfoQKCy0AZJg0sjmQHmgrwzNmA6V7b1KoYLu YlSOXY1u38850+aDZLRhjoVKmtgmK/Vo+Qa1CCzybK5Lv3Yq3QJETH4wacFe48xpqRVc UvdeTiROFUzx0GgraRrNdgUoW9F4wDw867iJ5AwS8O5y3vOxa64HYgLTXHPfOHsW0nyW eGhDAGd6vN58loDPVGuCpGM/RTRFUReS1diecyNsmcDmbrsn5HYAaFbXNQpZ+iYBYOMu vmEA== 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=y6kiYG9xw8NiArHHQw0sqmaSG6oH6HwQNnv2FxFTS/4=; b=SYKE5v3Fu99baa/FQ9qU8zgpVDsC4+QoE6Oo5akc98DkmdWjRzPnwK7FS93xV/bnn1 pb2eX7quwdJc+Gv6rWO3knJSmT5MkrKToJptzPv9a5cwNsP4+DWe7iclXryb1hvOCC29 oINREuvCmsqyVKzpc3rQYjQA3f/VJ9lw05cmcLmBXfrOTGp/V/M6sII2SK1A8Q4M4sXt 2+HO0a6z9eUky4fwnV3My6VyN3/BV117DrXDrS/V/Wbj/FXkoO7nl49BDBxk2xtYho9a hHNMtuu7Q2EA4hcA1/Ik1LboEhQIJlvrjVVqPZbOAgjkRAltT2yWbH9Qtmpv8rdI+9yY guAg== X-Gm-Message-State: ALoCoQl1jP0LkRkFmIL/692BExrPghXYVbK50yLYWc1v207iw05ScoNGQct6H4wTx6QgMcoEMUPM MIME-Version: 1.0 X-Received: by 10.13.247.3 with SMTP id h3mr5192476ywf.142.1436276710016; Tue, 07 Jul 2015 06:45:10 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Tue, 7 Jul 2015 06:45:09 -0700 (PDT) In-Reply-To: <559ACA08.1090609@bbn.com> References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> Date: Tue, 7 Jul 2015 14:45:09 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 07 Jul 2015 13:45:12 -0000 On 6 July 2015 at 19:33, Stephen Kent wrote: > I see your point. 6269-bis is mostly a document specifying the > operation and interface to the log. Other parts of the document attempt to > describe how clients interact with the log, but they do so only > superficially. > That's why I believe we need additional document specifying the behavior > of the other elements of the CT system. > > You refer to "the protocol" but don't indicate which protocol you have in > mind. > I might agree that specs for TLS client behavior in the context of TLS > exchanges > are in scope. If so, 6269-bis needs to state that it updates TLS. > > Your interpretation of the WG's agreement to expunge client behavior from > 6269-bis > seems to encompass only the issue of whether a client rejects or accept a > cert > accompanied by a (valid) SCT. That strikes me as rather narrow. > > If a client that claims CT compliance MUST perform a series of checks to > verify > CT compliance of a cert, what does the client do if any of these tests fail? > It's > not useful to require a set of checks to be performed and yet not indicate > what > happens if they fail. If no action is required, then why bother performing > the checks? > If some action is required, or even recommended, then a spec needs to state > what that > behavior is. To restate our position on this: we don't know what clients will do in response to failure to comply with CT, and nor are we in a position to mandate it. We feel it is helpful to provide a mechanism by which the issuance of certificates can be made open to public scrutiny. Clearly adoption of this mechanism does ultimately require that clients behave somehow differently for certificates that do not conform, but we can't dictate what that behaviour is. For example, right now, the only client I know of that reacts to CT is Chrome/Chromium, and the behaviour it (at least for Chrome - Chromium comes in multiple flavours) currently exhibits is that text in some dialogues is changed depending on whether CT is present and meets Chrome's policies or not, and in the display/non-display of the EV indicators for EV certificates. This behaviour has already been through several versions and policy changes, and will continue to evolve - and is not arrived at by IETF consensus, nor will it ever be. So, I don't see how it can be a part of the I-D. > > Steve > >> #77: normative client behavior specified in Section 5 >> >> Changes (bybenl@google.com): >> >> * milestone: => review >> >> >> Comment: >> >> What has been ruled out of scope is what action clients take, not how >> they >> conform to the protocol. >> >> Suggest close wontfix. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Tue Jul 7 08:38:28 2015 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 6834D1A8932 for ; Tue, 7 Jul 2015 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Buqa8Z3waFrk for ; Tue, 7 Jul 2015 08:38:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC08C1A88FD for ; Tue, 7 Jul 2015 08:38:24 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:36019 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCUwx-000C5H-Ht for trans@ietf.org; Tue, 07 Jul 2015 11:38:23 -0400 From: Stephen Kent To: trans@ietf.org References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> <559ACA98.2040509@bbn.com> Message-ID: <559BF26F.4010407@bbn.com> Date: Tue, 7 Jul 2015 11:38:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 07 Jul 2015 15:38:26 -0000 Ben, > A certificate not accompanied by an SCT is not CT compliant. > This seems redundant: I would've thought that in general everything in > an RFC only applies to things that are compliant with that RFC. But if > the WG wants I don't really mind either way. I prefer the wording I suggested because it emphasizes the status of the cert relative to this spec, rather than intimating any TLS client behavior. > > OK, I get your point here, and I am happy to go either way: > > a) Update TLS to require CT, or that's not what I meant to suggest. I don't think CT is destined to become a mandatory aspect of TLS; it's an optional feature. > b) Update the I-D to say something like "CT compliant TLS clients" or > as you use below "TLS clients claiming conformance with CT", which > presumably does not update TLS? TLS is the definitive spec for the messages exchanged during its handshake. So the specs in Section 3.4 represent an update to TLS (1.2). That does not make support for CT mandatory, but it informs implementers of the new TLS extensions defined here and the processing they imply. Steve From nobody Tue Jul 7 08:49:05 2015 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 DC8151A8A3E for ; Tue, 7 Jul 2015 08:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, 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 9MkMF_x25vZn for ; Tue, 7 Jul 2015 08:49:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E581A894F for ; Tue, 7 Jul 2015 08:49:01 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:a9b2:4a1c:52ad:2178] (unknown [IPv6:2001:1488:fffe:6:a9b2:4a1c:52ad:2178]) by mail.nic.cz (Postfix) with ESMTPSA id 0C21218144F; Tue, 7 Jul 2015 17:49:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1436284140; bh=BmDjDRW/4Jba0RZXfAkb7oBaSGzNadbk5/meaATclDA=; h=Date:From:To; b=KZ+T7PNR9RCqB4GPbc5bh2P95WN5iVW/v7NHSAZTvUWsOYKny564sITtoFpoLhgqx 0PSqw6/pikdolH7vsiUXeUi9mpFRVryoW3zT0OG3RMueBn2KhGvB4UMFvnecj3EvsE PQNDSN3Df95AQhCIs0eQKKoOBn6YWkSfT3Pv4Uh4= Message-ID: <559BF4EB.1080706@nic.cz> Date: Tue, 07 Jul 2015 17:48:59 +0200 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Laurie , Adam Eijdenberg References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> <20150629230458.GX30545@hezmatt.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Matt Palmer , "trans@ietf.org" Subject: Re: [Trans] Verifying inclusion proof 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, 07 Jul 2015 15:49:04 -0000 On 07/07/2015 03:09 PM, Ben Laurie wrote: > On 6 July 2015 at 20:22, Adam Eijdenberg wrote: >> To close this thread out, there were some errors in my previous code and >> algorithms in this thread. They have been corrected and added under section >> 5.5 in the new version of the Internet Draft published earlier today: >> https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08#section-5.5 >> >> I hope the new section is helpful for client implementors. > > BTW, Adam also implemented the algorithms to test them, you can find > them here: https://github.com/google/certificate-transparency-rfcs/blob/master/test_rfc_algorithms.py. Thank you all, the new text and code snippets mentioned in this thread do make the auditing much clearer. Ondrej From nobody Tue Jul 7 10:22:43 2015 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 E721C1ACED5 for ; Tue, 7 Jul 2015 10:22:41 -0700 (PDT) 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 QklIvZjqqYkt for ; Tue, 7 Jul 2015 10:22:40 -0700 (PDT) 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 B6D161ACED2 for ; Tue, 7 Jul 2015 10:22:40 -0700 (PDT) Received: from localhost ([::1]:48227 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZCWZp-00015o-St; Tue, 07 Jul 2015 10:22:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 07 Jul 2015 17:22:37 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:8 Message-ID: <071.4f0494131461fcad6d51696b83397e4d@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into 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, 07 Jul 2015 17:22:42 -0000 #80: Re-introduce the issuer key hash into the SCT Changes (by melinda.shore@gmail.com): * status: reopened => closed * resolution: => fixed -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Jul 7 12:23:37 2015 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 3F8091A8779 for ; Tue, 7 Jul 2015 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 twm3uLnf5igt for ; Tue, 7 Jul 2015 12:23:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0C01A1B1F for ; Tue, 7 Jul 2015 12:23:34 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:56748 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZCYSr-000MvO-4B for trans@ietf.org; Tue, 07 Jul 2015 15:23:33 -0400 From: Stephen Kent To: trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org><559A9977.1040808@bbn.com> <559A9B83.6040000@comodo.com> <559AA60A.1060501@bbn.com> <559AD74A.5030806@comodo.com> <559ADBF5.7000807@bbn.com> <559ADF2B.3050507@comodo.com> Message-ID: <559C2734.9090306@bbn.com> Date: Tue, 7 Jul 2015 15:23:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559ADF2B.3050507@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re logcertvalidationis ambiguous 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, 07 Jul 2015 19:23:36 -0000 Rob, > ... >> I think may have misunderstood my point. I did not request that a log >> return an error indicating why a cert failed the logs checks. I asked >> that there be a deterministic way for a submitter to know whether a >> cert will pass. > > Ah, I see. > Glad to see we're on the same page now. >> That can be accomplished in (at least) two ways: >> establish a standard set of checks that all logs perform > > The I-D already says: > "Logs MUST accept certificates that are fully valid according to RFC > 5280 [RFC5280] verification rules and are submitted with such a > chain." > > So the "deterministic way for a submitter to know whether a cert will > pass" is for the submitter to ensure that the cert is fully compliant > with RFC5280 verification rules and is supplied with a chain up to a > root cert that the log accepts. I agree. BUT, the argument is being made that some (many?) CAs issue certs that do not comply with 5280, and that CT logs cannot reject such certs because such sloppiness is too widespread. That appears to be the rationale for the text you cite below. So, we are saying is that logs MAY reject certs that do not comply with 5280, for any set of unspecified reasons, but there is no way for a submitter to know which logs do what checks, given the vast leeway accorded by the text below. That results in the non-determinism, which I see as bad. (Note that my proposal to create a set of IANA-registered profiles for types of certs, each describing syntax and other checks, might be applicable here. A log could enumerate the profiles against which it will perform validation checks and a submitter can indicate under which profile the cert was issued. Just a thought.) > We don't want to encourage submitter CAs to needlessly violate RFC5280, I agree! > so I see no good reason why we should turn the following behaviour > into something deterministic: > > "Logs MAY accept certificates and precertificates that have > expired, are not yet valid, have been revoked, or are otherwise not > fully valid according to RFC 5280 verification rules in order to > accommodate quirks of CA certificate-issuing software." Your argument seems to be that by introducing ambiguity and uncertainty into the log validation process we will encourage CAs to adhere to 5280. That strikes me as a questionable design strategy. Steve From nobody Fri Jul 10 04:01:39 2015 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 B87A51A902E for ; Fri, 10 Jul 2015 04:01:36 -0700 (PDT) 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 OfMxz2bonSlb for ; Fri, 10 Jul 2015 04:01:33 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1739C1A902B for ; Fri, 10 Jul 2015 04:01:33 -0700 (PDT) Received: (qmail 20363 invoked by uid 1004); 10 Jul 2015 11:01:29 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 10 Jul 2015 12:01:29 +0100 Received: (qmail 12997 invoked by uid 1000); 10 Jul 2015 11:01:29 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 10 Jul 2015 12:01:29 +0100 Message-ID: <559FA609.3050203@comodo.com> Date: Fri, 10 Jul 2015 12:01:29 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org><559A9977.1040808@bbn.com><559A9B83.6040000@comodo.com> <559AA60A.1060501@bbn.com><559AD74A.5030806@comodo.com> <559ADBF5.7000807@bbn.com><559ADF2B.3050507@comodo.com> <559C2734.9090306@bbn.com> In-Reply-To: <559C2734.9090306@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text relogcertvalidationis ambiguous 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, 10 Jul 2015 11:01:36 -0000 On 07/07/15 20:23, Stephen Kent wrote: > Rob, > > >> ... >>> I think may have misunderstood my point. I did not request that a log >>> return an error indicating why a cert failed the logs checks. I asked >>> that there be a deterministic way for a submitter to know whether a >>> cert will pass. >> >> Ah, I see. >> > Glad to see we're on the same page now. >>> That can be accomplished in (at least) two ways: >>> establish a standard set of checks that all logs perform >> >> The I-D already says: >> "Logs MUST accept certificates that are fully valid according to RFC >> 5280 [RFC5280] verification rules and are submitted with such a >> chain." >> >> So the "deterministic way for a submitter to know whether a cert will >> pass" is for the submitter to ensure that the cert is fully compliant >> with RFC5280 verification rules and is supplied with a chain up to a >> root cert that the log accepts. > I agree. BUT, the argument is being made that some (many?) CAs issue > certs that do not comply with 5280, and that CT logs cannot reject such > certs because such sloppiness is too widespread. Yes. Such sloppiness is too widespread for WebPKI browsers to enforce strict 5280 compliance. Since CT is concerned with protecting the WebPKI ecosystem, it must follow suit. Otherwise, it would be trivial for a bad CA to issue a cert that won't be logged by CT but will be accepted by browsers that don't require CT. > That appears to be the rationale for the text you cite below. > So, we are saying is that logs MAY reject certs that do not comply with > 5280, for any set of unspecified reasons, but there is no way for a > submitter to know which logs do what checks, given the vast leeway > accorded by the text below. That results in the non-determinism, which > I see as bad. I'll admit it's not ideal, but I think that we would get lost in a maze of ratholes if we tried to do it any differently. > (Note that my proposal to create a set of IANA-registered profiles for > types of certs, each describing syntax and other checks, might be > applicable here. The "profile" for Google's logs would be something like this: "We accept whatever OpenSSL accepts. Good luck!" > A log could enumerate the profiles against which it will perform > validation checks and a submitter can indicate under which profile the > cert was issued. Just a thought.) Do any other IETF protocols that validate certs do this? For example, when a TLS server sends its cert chain to a TLS client, can the TLS server know, deterministically, that the TLS client will either accept or reject the cert chain? Clearly the answer is no. So why should CT be expected to achieve a higher standard of determinism than TLS? >> We don't want to encourage submitter CAs to needlessly violate RFC5280, > > I agree! > >> so I see no good reason why we should turn the following behaviour >> into something deterministic: >> >> "Logs MAY accept certificates and precertificates that have >> expired, are not yet valid, have been revoked, or are otherwise not >> fully valid according to RFC 5280 verification rules in order to >> accommodate quirks of CA certificate-issuing software." > > Your argument seems to be that by introducing ambiguity and uncertainty > into the log validation process we will encourage CAs to adhere to 5280. > That strikes me as a questionable design strategy. Actually, I don't expect the level of CA adherence to 5280 to increase or decrease due to this strategy. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jul 10 07:24:04 2015 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 B6EF61B2C85 for ; Fri, 10 Jul 2015 07:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, 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 EeZqmwNIMe4v for ; Fri, 10 Jul 2015 07:24:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC34A1B2C45 for ; Fri, 10 Jul 2015 07:24:00 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:41470 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZDZDb-00039t-Cm for trans@ietf.org; Fri, 10 Jul 2015 10:23:59 -0400 From: Stephen Kent Cc: "trans@ietf.org" References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> Message-ID: <559FD57F.2060308@bbn.com> Date: Fri, 10 Jul 2015 10:23:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.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] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 10 Jul 2015 14:24:02 -0000 Ben, > ... > To restate our position first issue: does "our" = Google or just the authors of this document? > on this: we don't know what clients will do in > response to failure to comply with CT, and nor are we in a position to > mandate it. I agree with the last part of this statement, irrespective of the identity of the "our" above. > We feel it is helpful to provide a mechanism by which the > issuance of certificates can be made open to public scrutiny. that is clearly the premise of CT, yet absent a detailed analysis of how transparency improves security, the premise is unsubstantiated. > Clearly > adoption of this mechanism does ultimately require that clients behave > somehow differently for certificates that do not conform, but we can't > dictate what that behaviour is. maybe, maybe not. I'll await your comments on the new intro for the attack model. In that text I make some observations about the importance of browser behavior in the CT system. > For example, right now, the only client I know of that reacts to CT is > Chrome/Chromium, and the behaviour it (at least for Chrome - Chromium > comes in multiple flavours) currently exhibits is that text in some > dialogues is changed depending on whether CT is present and meets > Chrome's policies or not, and in the display/non-display of the EV > indicators for EV certificates. This behaviour has already been > through several versions and policy changes, and will continue to > evolve - and is not arrived at by IETF consensus, nor will it ever be. nice of you to reaffirm that Google doesn't care about IETF standards in this context. > So, I don't see how it can be a part of the I-D. I agree that client responses to the presence or absence of an SCT ought not be part of your document. Your document is really a spec for CT log behavior and it should be retitled as such. A CT architecture doc is needed, consistent with what has been done for many IETF security area systems of this scale. The attack model I've been working on is also a common element of an RFC suite for a security system with this many moving parts. Descriptions of how a Monitor works, including its relationship to logs and to Subjects, is needed. The audit function needs to be defined precisely if there is to be claim that CT can detect misbehavior by logs. Finally, the behavior of clients, in terms of what checks they perform on certs accompanied by SCTs, and whether they discriminate against certs w/o SCTs. also seems to be an essential element of a complete system description. You argue that CT "... does ultimately require that clients behave somehow differently for certificates that do not conform." Yet you note that Google has not yet figured out what thus discriminatory behavior should be. Maybe this means that the CT design is not yet adequately mature, and thus it ought not move from experimental, yet. Steve From nobody Fri Jul 10 07:38:24 2015 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 069FF1B2C87 for ; Fri, 10 Jul 2015 07:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, 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 K3204hjoibkG for ; Fri, 10 Jul 2015 07:38:22 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03BF1B2C86 for ; Fri, 10 Jul 2015 07:38:19 -0700 (PDT) Received: by ykey15 with SMTP id y15so68099019yke.3 for ; Fri, 10 Jul 2015 07:38:19 -0700 (PDT) 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=a4O6N1LyijDkQLomOOo4kpU56WprKB57bSFYnzn9VFY=; b=Z3K78KwivyEVcfTKb4nLHk3nzalVerIdTb8N0LNBWQlJbIDNG7dafQItc7X8KIqQ/h 7IDnjUy6rUU0Vr+PBrHKRt+IeS4TwyRfbddOS6r4kdoDWHHM/Raiptw4rL+U+BDbhkhC hHkSAC/0kolspqnF4EyD1IfC0JNvaIY5EdD+CPOTxz/18XqnxIpYyYh+kHk3xwD/c4ua xrdQHOmojbODWcaDr+LmPQDfwOP4S8EODoxbp6Glxk9TW0J0OY2Yt5yclsQGRPwHQiQ0 9Bwy/MLjmOtayJj4FdGGrbA71wIwj7YLQKUYHNXjnmeDBD4nMm1lJZPlhZdxXjuhwyRA 2f1A== 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=a4O6N1LyijDkQLomOOo4kpU56WprKB57bSFYnzn9VFY=; b=W2RoHII+8EnunbIIDjVRWqzLL4rb4shVI82RGaXpkTvsj7ua+hcmmPNRWLsbW1/hjM tcY0OwXxONzkOikZ/FRVhuy97SWZgyCJHBVXu0R/LEMQBiNQLTm2IU3q8AO4qAdoqJ0y KXu6rVP0ybslgLIk1dT+DNNSjDM2r0DtOquhOWywv9I6nQcrJC0Md2R2lA7DEiiW4PnB 6EUTevJOr2zzHSBRJ9M70lcD155+6OgxVovypCeNonnAkQpqQzEXnpVmn7JCuuyU+FZt p6T8Sfhw9Rn6V3vil3q3NRh7BUe+QxM0GQr+09c6h9DRuhzYQNjwBQct7Xao4bm14Gvj Fwtw== X-Gm-Message-State: ALoCoQk1Q6M+0vlVYyNMEqS42Ub8XjROo7f1cw6g5f2Vec2sjX6OT5COnN4Yz0gOoOQ7A6xOGvzF MIME-Version: 1.0 X-Received: by 10.129.138.2 with SMTP id a2mr23066892ywg.149.1436539099177; Fri, 10 Jul 2015 07:38:19 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Fri, 10 Jul 2015 07:38:19 -0700 (PDT) In-Reply-To: <559FD57F.2060308@bbn.com> References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> <559FD57F.2060308@bbn.com> Date: Fri, 10 Jul 2015 15:38:19 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 10 Jul 2015 14:38:24 -0000 On 10 July 2015 at 15:23, Stephen Kent wrote: > Ben, > >> ... >> To restate our position > > first issue: does "our" = Google or just the authors of this document? Google. >> >> on this: we don't know what clients will do in >> response to failure to comply with CT, and nor are we in a position to >> mandate it. > > I agree with the last part of this statement, irrespective of the identity > of the "our" above. >> >> We feel it is helpful to provide a mechanism by which the >> issuance of certificates can be made open to public scrutiny. > > that is clearly the premise of CT, yet absent a detailed analysis of how > transparency improves security, the premise is unsubstantiated. >> >> Clearly >> adoption of this mechanism does ultimately require that clients behave >> somehow differently for certificates that do not conform, but we can't >> dictate what that behaviour is. > > maybe, maybe not. I'll await your comments on the new intro for the > attack model. In that text I make some observations about the importance of > browser behavior in the CT system. >> >> For example, right now, the only client I know of that reacts to CT is >> Chrome/Chromium, and the behaviour it (at least for Chrome - Chromium >> comes in multiple flavours) currently exhibits is that text in some >> dialogues is changed depending on whether CT is present and meets >> Chrome's policies or not, and in the display/non-display of the EV >> indicators for EV certificates. This behaviour has already been >> through several versions and policy changes, and will continue to >> evolve - and is not arrived at by IETF consensus, nor will it ever be. > > nice of you to reaffirm that Google doesn't care about IETF standards > in this context. Does _anyone_ care about IETF standards when it comes to UI? >> >> So, I don't see how it can be a part of the I-D. > > I agree that client responses to the presence or absence of an SCT > ought not be part of your document. Your document is really a spec for > CT log behavior and it should be retitled as such. > > A CT architecture doc is needed, consistent with what has been done for > many IETF security area systems of this scale. The attack model I've been > working on is also a common element of an RFC suite for a security system > with this many moving parts. Descriptions of how a Monitor works, including > its relationship to logs and to Subjects, is needed. The audit function > needs > to be defined precisely if there is to be claim that CT can detect > misbehavior > by logs. Finally, the behavior of clients, in terms of what checks they > perform > on certs accompanied by SCTs, and whether they discriminate against certs > w/o SCTs. > also seems to be an essential element of a complete system description. > > You argue that CT "... does ultimately require that clients behave somehow > differently > for certificates that do not conform." Yet you note that Google has not yet > figured > out what thus discriminatory behavior should be. Maybe this means that the > CT design > is not yet adequately mature, and thus it ought not move from experimental, > yet. If you believe that, then we should move all TLS documents to experimental, since they are in exactly the same position. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Fri Jul 10 07:47:39 2015 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 A00FD1B2C93 for ; Fri, 10 Jul 2015 07:47:37 -0700 (PDT) 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 RpcHU3oV-KyR for ; Fri, 10 Jul 2015 07:47:35 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35C31A913E for ; Fri, 10 Jul 2015 07:47:34 -0700 (PDT) Received: (qmail 32034 invoked by uid 1004); 10 Jul 2015 14:47:33 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 10 Jul 2015 15:47:32 +0100 Received: (qmail 11611 invoked by uid 1000); 10 Jul 2015 14:47:32 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 10 Jul 2015 15:47:32 +0100 Message-ID: <559FDB04.7030801@comodo.com> Date: Fri, 10 Jul 2015 15:47:32 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org><067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org><559ACA08.1090609@bbn.com><559FD57F.2060308@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behaviorspecified in Section 5 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, 10 Jul 2015 14:47:37 -0000 On 10/07/15 15:38, Ben Laurie wrote: > On 10 July 2015 at 15:23, Stephen Kent wrote: >> Ben, >> >>> ... >>> To restate our position >> >> first issue: does "our" = Google or just the authors of this document? > > Google. FWIW, since I'm not a Googler but I am one of the authors of this document, let me just state that I also agree with this position. >>> For example, right now, the only client I know of that reacts to CT is >>> Chrome/Chromium, and the behaviour it (at least for Chrome - Chromium >>> comes in multiple flavours) currently exhibits is that text in some >>> dialogues is changed depending on whether CT is present and meets >>> Chrome's policies or not, and in the display/non-display of the EV >>> indicators for EV certificates. This behaviour has already been >>> through several versions and policy changes, and will continue to >>> evolve - and is not arrived at by IETF consensus, nor will it ever be. >> >> nice of you to reaffirm that Google doesn't care about IETF standards >> in this context. > > Does _anyone_ care about IETF standards when it comes to UI? Has IETF ever actually published any standards relating to web browser UI? Let me just note that CABForum has no influence over Chrome's UI either, so please don't feel that IETF is being ignored any more than any other standards organization. ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jul 10 08:50:33 2015 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 376621B2A05 for ; Fri, 10 Jul 2015 08:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3S4-QYbs9AZ for ; Fri, 10 Jul 2015 08:50:31 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 5F4B61B2A0C for ; Fri, 10 Jul 2015 08:50:30 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so170039106pab.1 for ; Fri, 10 Jul 2015 08:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eN3UkqFB30R+OaRMxROnzOwO3uRzNFtKlmS1RxFTyjI=; b=v52EPqY0XTiuUg9uxzBVM/ZmmftXLAhtTCikml3/bozJgA5hbZO/cLls2BlPtpJpSX U02IKRCvxGOTiqzFa9je1OcIt0HyV5T/F7AOhHQYQoG0iOgtI+ifSfxhEQGp9myDtV6+ 0MH/GTTkI68/vSQKM+aAjINKLY3vXyjBiaSbQ0v+6uJwqkfEfeL4+FiUw2Pzy2dpIkW7 ig+aPrnn27/Segs2CgI1E+PdKrt/V96G7ljJsbvgfZGtMucOhprgaVq8Itf1qDMTpb6W tNJUcE2eZranYbtvCYDC/CpXLgtNkn0znxSWVkWmxc59gbfA1TtVS/P3cQigpKgdirWu kvDw== X-Received: by 10.68.69.6 with SMTP id a6mr43514916pbu.132.1436543429979; Fri, 10 Jul 2015 08:50:29 -0700 (PDT) Received: from spandex.local (216-67-30-232-rb2.nwc.dsl.dynamic.acsalaska.net. [216.67.30.232]) by smtp.gmail.com with ESMTPSA id fz6sm7154415pdb.49.2015.07.10.08.50.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2015 08:50:29 -0700 (PDT) Message-ID: <559FE9C3.90409@gmail.com> Date: Fri, 10 Jul 2015 07:50:27 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Kent References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> <559FD57F.2060308@bbn.com> In-Reply-To: <559FD57F.2060308@bbn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 10 Jul 2015 15:50:32 -0000 On 7/10/15 6:23 AM, Stephen Kent wrote: > nice of you to reaffirm that Google doesn't care about IETF standards > in this context. Steve, this kind of commentary really needs to stop. Melinda From nobody Sun Jul 12 07:28:13 2015 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 BE3781A8900 for ; Sun, 12 Jul 2015 07:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 uejjNWBibLPW for ; Sun, 12 Jul 2015 07:28:11 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 B07E11ACECE for ; Sun, 12 Jul 2015 07:28:10 -0700 (PDT) Received: by qkdv3 with SMTP id v3so43439247qkd.3 for ; Sun, 12 Jul 2015 07:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=MbYV4NlfaASn9JjWsiGdHcxQnNkj7IvYoNYaSvp2wIk=; b=b0jClb9gGImB/JjpfXAWl3xG1LpddudgB6ZLqpY/m2TIsvxUYvsJvtqGh4L/Htb6Wa Dah/+s0ZzJN4d9/2DdhMKT06G5sfN2OSYQ/5h4/Jatvn5cbaza5QIBj3T3HwJ16r1PJx X9p9vcSE9WsAxaidudQgCJ2WXfPhiXIRSVFZTAWwUvKm960Cu/RjAQ9uZcUJcisQIq/M o5VRRZOc68QOOWwswqDtJXk4eO+hxIOpAyhlR7DnmmkSKtxTyiQVQFwZw0Ukvr9Qnho0 Wg8G6CCbPg/o1p2lvryBCQSM3MLFAPXSUr9q6NMchu/BY1J39kNh+Dqk7hGAHVz9uHQJ LN+g== X-Received: by 10.140.150.143 with SMTP id 137mr49777711qhw.0.1436711289924; Sun, 12 Jul 2015 07:28:09 -0700 (PDT) Received: from [10.0.0.182] (173-9-75-145-NewEngland.hfc.comcastbusiness.net. [173.9.75.145]) by smtp.gmail.com with ESMTPSA id e104sm9401200qgd.29.2015.07.12.07.28.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Jul 2015 07:28:08 -0700 (PDT) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_AECDA1D1-D67F-41E5-BCE2-2FCCC455C5C9"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <17C96998-E1FB-4B25-8DC4-EF177D13FCF3@gmail.com> Date: Sun, 12 Jul 2015 10:28:04 -0400 To: trans@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Trans] Long-term: scalable collective signing (of certs, log-heads, and/or SCTs) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 14:28:12 -0000 --Apple-Mail=_AECDA1D1-D67F-41E5-BCE2-2FCCC455C5C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi TRANS folks, My group at Yale (and shortly to be at EPFL) has been working on = techniques to make threshold/multi-signature techniques scale = efficiently, a goal partly motivated by the CA security problem, and = whose solution may be relevant and complementary to CT. Basically, our = protocol allows a =E2=80=9Cauthority server=E2=80=9D of any kind to = propose publicly a message to be signed, and any number of =E2=80=9Cwitnes= s=E2=80=9D nodes get the opportunity to inspect and approve or object, = in the former case contributing a share of the final signature, ensuring = that nothing gets signed without being widely witnessed and approved. = For example, in testbed experiments we=E2=80=99ve demonstrated ~4000 = participants collectively computing a single signature in 1.5-3 seconds = including wide-area-equivalent round-trip times. I envision this = capability might be useful to the TRANS group=E2=80=99s goals in various = ways: 1. In the long term - most ambitious but perhaps least realistically = deployable - security-conscious CAs could in the future move toward a = collective-signing model for issuing actual certs. For example, root = CAs could gradually deprecate the issuance of delegated authority to = sub-CAs, instead bringing these sub-CAs into a collective run by the = root, such that any CA in the group can propose certificates but all = have the opportunity to inspect before the cert receives a valid = (collective) signature. Of course there would be many practical = challenges here; I=E2=80=99m under no illusion that this approach would = be viable for the near-term but may be worth thinking about on a = =E2=80=9Clong-term roadmap.=E2=80=9D 2. A more near-term possibility is to consider collective signing for = SCTs in CT. This would be easier to deploy incrementally since CT = isn=E2=80=99t yet =E2=80=9Cset in stone=E2=80=9D, but it would still = present challenges, such as the possibility of delaying SCT signatures = (even if by only a few seconds), to which there may be objections. 3. A still more near-term possibility is to consider enhancing CT = log-servers to support collective signing of log-heads. Witness/monitor = servers would then be able to join the signing collective of log servers = they monitor, not just passively checking but actively contributing to = the signature of each log-head signature. Anyone (particularly clients) = could then check offline that a log-head was not only signed by the log = server operator but also witnessed and verified by any number of monitor = servers with a single signature check. Regardless of approach, I think the most important potential opportunity = here is to address the privacy problem that CT=E2=80=99s gossip = mechanism creates for clients. Currently clients have no way to check = the SCTs they see unless they=E2=80=99re willing to reveal their = browsing history to a =E2=80=9Ctrusted monitor=E2=80=9D, which is = unfortunate for users desiring privacy and reluctant to trust any single = =E2=80=9Ctrusted authority". With either options #2 or #3 above, a = client could verify that an SCT was signed (#2) or a cert was logged and = widely witnessed (#3) with a single signature-check requiring no = communication or browsing-history disclosure to any server. At the moment I just want to bring this information to the group and = solicit feedback or discussion for anyone interested; I=E2=80=99m not = making any particular proposal at the moment. If collective signing = support provides to be of interest at some point, it could certainly be = added as a later-stage CT extension. The main (and only that I know of = now) consideration I suggest the group might want to consider in the = near term is whether the CT spec should perhaps include support for at = least one Schnorr-type signature scheme (e.g., Ed25519) rather than just = RSA and ECDSA, since scalable multisignatures work readily in Schnorr = schemes but are not so easy or scalable in RSA or ECDSA. We did a short presentation recently at HotPETS on this topic, and I = would be happy to do a brief presentation on this at the TRANS meeting = if there=E2=80=99s time and interest. More details of this ongoing = work-in-progress are available in the following preprint and slide-deck: Decentralizing Authorities into Scalable Strongest-Link = Cothorities Preprint: http://arxiv.org/abs/1503.08768 Slides: = http://dedis.cs.yale.edu/dissent/pres/150610-nist-cothorities.pdf Our prototype code (in Go) is also online and I=E2=80=99d be happy to = share it, but it=E2=80=99s not yet in a particularly clean, = well-documented, or usable state yet. We=E2=80=99ll be working on that = over the coming months but am happy to work with anyone deeply = interested enough to want to dive into the code earlier. And in any = case, I=E2=80=99ll be at IETF 93 for the whole week and happy to discuss = further with anyone interested. Thanks Bryan --Apple-Mail=_AECDA1D1-D67F-41E5-BCE2-2FCCC455C5C9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA3MTIxNDI4MDVaMCMGCSqGSIb3DQEJBDEWBBQGNWKIXR+nm3AinK99GmAOZe8dGjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAbjVkZOfUiryZ/OqjJrDzJosyAeyE9gMIIUbD3J+XKhkXrw6DEgFs3k19iW/11tNB D+9fXAj15ZnhOVJjUURvr0ZqdHmmggZ4/r8eGMOhOg7XlizdkaDs5mJMUhteipeQUu/MneqszWt3 58+LsDJPn+u6zhWp6puysDuwQjLlr+j9l7qXISV7EIhfPfjl670y28pizrmnf/ZHw9Lygc3g3lUb pcyzyY6dwJAUzFKtighgcZBuUjdHMK5UaooxXxE+07M6yWIhMp6DmmrW4k4i7u4l8nmWzn+s4bIo ujR7tSHQdiqOrI+Uta3/NpS6ufbQCU8ZPIj6R5Nmgc7ZSAZ3ywAAAAAAAA== --Apple-Mail=_AECDA1D1-D67F-41E5-BCE2-2FCCC455C5C9-- From nobody Tue Jul 14 07:35:52 2015 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 EB74E1ACE0C for ; Tue, 14 Jul 2015 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 cu1PmVXz_r9m for ; Tue, 14 Jul 2015 07:35:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954891ACE1E for ; Tue, 14 Jul 2015 07:35:29 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:53717 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF1Iu-000FVB-7i; Tue, 14 Jul 2015 10:35:28 -0400 From: Stephen Kent To: Melinda Shore References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> <559FD57F.2060308@bbn.com> <559FE9C3.90409@gmail.com> Message-ID: <55A51E30.5070508@bbn.com> Date: Tue, 14 Jul 2015 10:35:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559FE9C3.90409@gmail.com> Content-Type: multipart/alternative; boundary="------------010109010609000903010204" Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 14 Jul 2015 14:35:51 -0000 This is a multi-part message in MIME format. --------------010109010609000903010204 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Melinda, Or, conversely, you could chastise Ben for making offensive statements about Google's "position" in his posting. I observe that Ben's reply to my question about the "our" in his message is that he was stating Google's position. Since the IETF ethos calls for us to participate as individuals, and since Ben appears to be trying use Google's stature in supporting a technical argument, where is the criticism of his statement? Also, I have never seen _any_ vendor make a statement on an IETF list in which they openly say that their development plans are not influenced by whatever IETF standards may arise. I don't doubt that many vendors feel and act this way, but they usually don't flaunt their intent. The issue here isn't whether browser UI details are appropriate fodder for IETF standards, but rather whether Google staff should make stark statements like this in the context of an IETF WG discussion. > On 7/10/15 6:23 AM, Stephen Kent wrote: >> nice of you to reaffirm that Google doesn't care about IETF standards >> in this context. > Steve, this kind of commentary really needs to stop. > > Melinda > > --------------010109010609000903010204 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Melinda,

Or, conversely, you could chastise Ben for making offensive statements about
Google's "position" in his posting.

I observe that Ben's reply to my question about the "our" in his message is that
he was stating Google's position.

Since the IETF ethos calls for us to participate as individuals, and since Ben
appears to be trying use Google's stature in supporting a technical argument,
where is the criticism of his statement?

Also, I have never seen any vendor make a statement on an IETF list in which they
openly say that their development plans are not influenced by whatever IETF
standards may arise.  I don't doubt that many vendors feel and act this
way, but they usually don't flaunt their intent. The issue here isn't whether
browser UI details are appropriate fodder for IETF standards, but rather whether
Google staff should make stark statements like this in the context of an IETF WG
discussion.
On 7/10/15 6:23 AM, Stephen Kent wrote:

nice of you to reaffirm that Google doesn't care about IETF standards
in this context.

Steve, this kind of commentary really needs to stop.

Melinda

--------------010109010609000903010204-- From nobody Tue Jul 14 07:36:02 2015 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 0A4C91ACE19 for ; Tue, 14 Jul 2015 07:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 w-ywurgmsRAX for ; Tue, 14 Jul 2015 07:35:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DFE1ACE15 for ; Tue, 14 Jul 2015 07:35:42 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33903 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF1J7-0002wI-1l for trans@ietf.org; Tue, 14 Jul 2015 10:35:41 -0400 From: Stephen Kent To: "trans@ietf.org" Message-ID: <55A51E3D.3070608@bbn.com> Date: Tue, 14 Jul 2015 10:35:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030309020301040507040703" Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs to define top-level extension syntax 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, 14 Jul 2015 14:35:54 -0000 This is a multi-part message in MIME format. --------------030309020301040507040703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As promised, here is some proposed text for the required additional syntax for SCT extensions. Add to Section 3.3: uint16 CtExtensionId; opaque CtExtensionValue<0..2^16-1>; struct { CtExtensionId id; CtExtensionValue value; } CtExtension; CtExtension CtExtensions<0..2^16-1>; The "id" field identifies a single extension from the IANA registry in Section 7.3. The interpretation of the "value" field is determined solely by the value of the id field, and each document that registers a new extension ID must describe how to interpret the corresponding extension value. The "CtExtensions" type is a vector of 0 or more extensions. This vector MUST NOT include more than one extension with the same ID. All of the extensions in the vector MUST appear in order of increasing IDs. Change the last paragraph of Section 3.3 to: "extensions" are future extensions to SignedCertificateTimestamp v2. Currently, no extensions are specified. If an implementation sees an extension that it does not understand, it SHOULD ignore that extension. Furthermore, an implementation MAY choose to ignore any extension(s) that it does understand. Add a new Section, "7.3. CT Extension IDs": IANA is asked to establish a registry of CT extension IDs, initially consisting of: +-------+-----------+ | ID | Extension | +-------+-----------+ | 65535 | reserved | +-------+-----------+ TBD: policy for adding to the registry --------------030309020301040507040703 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit As promised, here is some proposed text for the required additional syntax for SCT extensions.

Add to Section 3.3:

         uint16 CtExtensionId;

         opaque CtExtensionValue<0..2^16-1>;

         struct {
             CtExtensionId id;
             CtExtensionValue value;
         } CtExtension;

         CtExtension CtExtensions<0..2^16-1>;

   The "id" field identifies a single extension from the IANA registry in Section 7.3. The interpretation of the "value" field is determined solely by the value of the id field, and each document that registers a new extension ID must describe how to interpret the corresponding extension value.

   The "CtExtensions" type is a vector of 0 or more extensions.
This vector MUST NOT include more than one extension with the same ID. All of the extensions in the vector MUST appear in order of increasing IDs.

Change the last paragraph of Section 3.3 to:

   "extensions" are future extensions to SignedCertificateTimestamp v2. Currently, no extensions are specified. If an implementation sees an extension that it does not understand, it SHOULD ignore that extension. Furthermore, an implementation MAY choose to ignore any extension(s) that it does understand.


Add a new Section, "7.3.  CT Extension IDs":

   IANA is asked to establish a registry of CT extension IDs, initially
   consisting of:

         +-------+-----------+
         | ID    | Extension |
         +-------+-----------+
         | 65535 | reserved  |
         +-------+-----------+

   TBD: policy for adding to the registry --------------030309020301040507040703-- From nobody Tue Jul 14 07:38:05 2015 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 B64411ACE17 for ; Tue, 14 Jul 2015 07:38:03 -0700 (PDT) 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_20=-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 zdngETD1mcwH for ; Tue, 14 Jul 2015 07:38:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418F51ACE12 for ; Tue, 14 Jul 2015 07:38:02 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33918 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF1LN-0002zu-1d; Tue, 14 Jul 2015 10:38:01 -0400 From: Stephen Kent To: Rob Stradling , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org><559A9977.1040808@bbn.com><559A9B83.6040000@comodo.com> <559AA60A.1060501@bbn.com><559AD74A.5030806@comodo.com> <559ADBF5.7000807@bbn.com><559ADF2B.3050507@comodo.com> <559C2734.9090306@bbn.com> <559FA609.3050203@comodo.com> Message-ID: <55A51EC9.3050208@bbn.com> Date: Tue, 14 Jul 2015 10:38:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559FA609.3050203@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text relogcertvalidationis ambiguous 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, 14 Jul 2015 14:38:03 -0000 Rob, >> I agree. BUT, the argument is being made that some (many?) CAs issue >> certs that do not comply with 5280, and that CT logs cannot reject such >> certs because such sloppiness is too widespread. > > Yes. Such sloppiness is too widespread for WebPKI browsers to enforce > strict 5280 compliance. Since CT is concerned with protecting the > WebPKI ecosystem, it must follow suit. Otherwise, it would be trivial > for a bad CA to issue a cert that won't be logged by CT but will be > accepted by browsers that don't require CT. agreed. > >> That appears to be the rationale for the text you cite below. >> So, we are saying is that logs MAY reject certs that do not comply with >> 5280, for any set of unspecified reasons, but there is no way for a >> submitter to know which logs do what checks, given the vast leeway >> accorded by the text below. That results in the non-determinism, which >> I see as bad. > > I'll admit it's not ideal, but I think that we would get lost in a > maze of ratholes if we tried to do it any differently. > >> (Note that my proposal to create a set of IANA-registered profiles for >> types of certs, each describing syntax and other checks, might be >> applicable here. > > The "profile" for Google's logs would be something like this: > > "We accept whatever OpenSSL accepts. Good luck!" and is Google's log acceptance criteria the only one that counts? > >> A log could enumerate the profiles against which it will perform >> validation checks and a submitter can indicate under which profile the >> cert was issued. Just a thought.) > > Do any other IETF protocols that validate certs do this? Some IETF protocols call for certs to be validated as per 5280, even if, in practice, implementations often fail to do so. As a standards body we try to establish desirable behavior for implementations, knowing that we may not always succeed. > For example, when a TLS server sends its cert chain to a TLS client, > can the TLS server know, deterministically, that the TLS client will > either accept or reject the cert chain? in principle, only the lack of an agreed upon trust anchor should cause a compliant client to reject a cert from a server (ignoring local policy controls). Servers rely on the ubiquity of trust anchor stores to reduce the likelihood that validation will fail on that basis. So, for all practical purposes, a server can have high confidence that its cert will be accepted by browsers, if the cert is issued by a CA that is widely represented in the (almost uniform) trust store. > Clearly the answer is no. So why should CT be expected to achieve a > higher standard of determinism than TLS? two observations: first, I disagree that the TLS example above is a probative as you suggest. second, we have years of experience with what's wrong with TLS in terms of cert processing, and hopefully we can do better with this effort, when we create new ways to introduce non-determinism. > >> Your argument seems to be that by introducing ambiguity and uncertainty >> into the log validation process we will encourage CAs to adhere to 5280. >> That strikes me as a questionable design strategy. > > Actually, I don't expect the level of CA adherence to 5280 to increase > or decrease due to this strategy. I don't either, yet that seems to be a part of the argument you made. Steve From nobody Tue Jul 14 07:38:17 2015 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 7639F1ACE1A for ; Tue, 14 Jul 2015 07:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 bW23iDzKWuOE for ; Tue, 14 Jul 2015 07:38:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77F31ACE1B for ; Tue, 14 Jul 2015 07:38:10 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33920 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF1LV-00030A-Q0 for trans@ietf.org; Tue, 14 Jul 2015 10:38:09 -0400 From: Stephen Kent Cc: "trans@ietf.org" References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org><067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org><559ACA08.1090609@bbn.com><559FD57F.2060308@bbn.com> <559FDB04.7030801@comodo.com> Message-ID: <55A51ED1.5080801@bbn.com> Date: Tue, 14 Jul 2015 10:38:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559FDB04.7030801@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behaviorspecified in Section 5 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, 14 Jul 2015 14:38:15 -0000 Rob, > ... >> Does _anyone_ care about IETF standards when it comes to UI? > > Has IETF ever actually published any standards relating to web browser > UI? rejecting a cert, as the doc in question has previously mandated (as recently as the -05 version), is not just a UI issue, IMHO. It's protocol behavior and, as I noted last year, it's protocol behavior that requires a plan to deal with incremental deployment. Less severe forms of discrimination against certs not accompanied by an SCT may fall under the browser UI heading, and that they are not subject to IETF standardization. > Let me just note that CABForum has no influence over Chrome's UI > either, so please don't feel that IETF is being ignored any more than > any other standards organization. ;-) I'm quite willing to believe that Google believes it decisions are not subject to influence by any standards body, country, etc. ;-) Steve From nobody Tue Jul 14 07:38:32 2015 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 4EDD21ACE1F for ; Tue, 14 Jul 2015 07:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 22tCPsl--7et for ; Tue, 14 Jul 2015 07:38:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E290B1ACE1D for ; Tue, 14 Jul 2015 07:38:29 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33922 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZF1Lp-00030Y-1u for trans@ietf.org; Tue, 14 Jul 2015 10:38:29 -0400 From: Stephen Kent To: trans@ietf.org References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> <559FD57F.2060308@bbn.com> Message-ID: <55A51EE5.6000102@bbn.com> Date: Tue, 14 Jul 2015 10:38:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 14 Jul 2015 14:38:31 -0000 Ben, > On 10 July 2015 at 15:23, Stephen Kent wrote: >> Ben, >> >>> ... >>> To restate our position >> first issue: does "our" = Google or just the authors of this document? > Google. That's what I thought, but thanks for the clarification. > ... >>> For example, right now, the only client I know of that reacts to CT is >>> Chrome/Chromium, and the behaviour it (at least for Chrome - Chromium >>> comes in multiple flavours) currently exhibits is that text in some >>> dialogues is changed depending on whether CT is present and meets >>> Chrome's policies or not, and in the display/non-display of the EV >>> indicators for EV certificates. This behaviour has already been >>> through several versions and policy changes, and will continue to >>> evolve - and is not arrived at by IETF consensus, nor will it ever be. >> nice of you to reaffirm that Google doesn't care about IETF standards >> in this context. > Does _anyone_ care about IETF standards when it comes to UI? Previous versions of your doc (as recent as the -05 version) have called for a TLS client to reject a cert that was not accompanied by an SCT. Do we agree that such an action is not just UI behavior, since it would cause a session to (hard) fail? If a TCP spec dropped a connection because of a newly-specified, not backward compatible mandate would you assert that that too is a UI issue? >> ... >> I agree that client responses to the presence or absence of an SCT >> ought not be part of your document. Your document is really a spec for >> CT log behavior and it should be retitled as such. >> >> A CT architecture doc is needed, consistent with what has been done for >> many IETF security area systems of this scale. The attack model I've been >> working on is also a common element of an RFC suite for a security system >> with this many moving parts. Descriptions of how a Monitor works, including >> its relationship to logs and to Subjects, is needed. The audit function >> needs >> to be defined precisely if there is to be claim that CT can detect >> misbehavior >> by logs. Finally, the behavior of clients, in terms of what checks they >> perform >> on certs accompanied by SCTs, and whether they discriminate against certs >> w/o SCTs. >> also seems to be an essential element of a complete system description. >> >> You argue that CT "... does ultimately require that clients behave somehow >> differently >> for certificates that do not conform." Yet you note that Google has not yet >> figured >> out what thus discriminatory behavior should be. Maybe this means that the >> CT design >> is not yet adequately mature, and thus it ought not move from experimental, >> yet. > If you believe that, then we should move all TLS documents to > experimental, since they are in exactly the same position. I agree that most browser UI details are outside the scope of TLS standards. However, TLS 1.2 requires that a session be closed and not resumed in the face of fatal error alerts. Examples of fatal error alerts (Section 7.2.2) include certs of "unsupported type", any failure of cert validation processing, revoked certs, unknown CA, etc. So, TLS does mandate some aspects of browser behavior that will be visible to the user, and some of the triggers for mandated hard session failure are consistent with text previously proposed for missing SCT info (as recent as the -05 version of 6952-bis). Steve From nobody Tue Jul 14 07:57:22 2015 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 4C4D81ACE30 for ; Tue, 14 Jul 2015 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 IfPxRrq5GHlt for ; Tue, 14 Jul 2015 07:57:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703681ACE08 for ; Tue, 14 Jul 2015 07:57:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mW4gt5zL3z1Hl; Tue, 14 Jul 2015 16:57:14 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=TfcKO8s6 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id X_1wHBSfcf_9; Tue, 14 Jul 2015 16:57:14 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Jul 2015 16:57:13 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1C573800EF; Tue, 14 Jul 2015 10:57:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436885833; bh=YtUvEBntCwtYZmlCYMQohmRQc0qDyRZfeEXI5SIRzzw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TfcKO8s6LiC8jTiOqMCH1Qg7EqAnebHqmzlNl5At+OjUMg94ObgZfkl2GL44YJ3Le 2omRCnBCohcKcG9G1+64SwfvuOXmoOrLbt20Ai/sJSSx4SHJ0J4brf+928JSK6qakF upYTymBNbetnXuQeNzEu+yH2tLfNoYKymyWmT9XE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6EEvC3s027797; Tue, 14 Jul 2015 10:57:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 14 Jul 2015 10:57:12 -0400 (EDT) From: Paul Wouters To: Stephen Kent In-Reply-To: <55A51E30.5070508@bbn.com> Message-ID: References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> <559FD57F.2060308@bbn.com> <559FE9C3.90409@gmail.com> <55A51E30.5070508@bbn.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 14 Jul 2015 14:57:21 -0000 On Tue, 14 Jul 2015, Stephen Kent wrote: Steve, > Or, conversely, you could chastise Ben for making offensive statements about > Google's "position" in his posting. > > I observe that Ben's reply to my question about the "our" in his message is that > he was stating Google's position. > > Since the IETF ethos calls for us to participate as individuals, and since Ben > appears to be trying use Google's stature in supporting a technical argument, > where is the criticism of his statement? While Ben could have made it clearer that he was speaking without his RFC document author hat on, he did clarify that later on. It is perfectly reasonable for any participant to explain why their current $dayjob would or would not be happy or violate/not violate certain protocol bits under discussion. In fact, such information is useful and can lead to participants opening up to further discussion and reaching new compromises. In the end, we would end up with more interoperable implementations from different vendors. In my view, Ben's remark were not "offensive", "flaunting" or "stark". > Also, I have never seen any vendor make a statement on an IETF list in which they > openly say that their development plans are not influenced by whatever IETF > standards may arise.  I don't doubt that many vendors feel and act this > way, but they usually don't flaunt their intent. This is a very subjective view on your end. It is fine if Ben wants to clarify the position of his $dayjob vendor. > The issue here isn't whether > browser UI details are appropriate fodder for IETF standards, but rather whether > Google staff should make stark statements like this in the context of an IETF WG > discussion. I hope that Ben continues to explain the views of Google on various protocol bits. I am also confident that Ben can keep his document author hat and $dayjob hat apart. If the working group feels that Ben can no longer do this, we can think about adding another author/editor to this document, provided we can find a volunteer. > On 7/10/15 6:23 AM, Stephen Kent wrote: > > nice of you to reaffirm that Google doesn't care about IETF standards > in this context. > > Steve, this kind of commentary really needs to stop. > > Melinda I concur. Paul From nobody Tue Jul 14 08:14:40 2015 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 3F9421ACE9F for ; Tue, 14 Jul 2015 08:14:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 YD3ix0rzq-hK for ; Tue, 14 Jul 2015 08:14:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0680.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:680]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBC61ACEA0 for ; Tue, 14 Jul 2015 08:14:35 -0700 (PDT) Received: from SN1PR06MB1837.namprd06.prod.outlook.com (10.162.133.17) by SN1PR06MB1760.namprd06.prod.outlook.com (10.162.132.146) with Microsoft SMTP Server (TLS) id 15.1.213.14; Tue, 14 Jul 2015 15:14:16 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) by SN1PR06MB1837.namprd06.prod.outlook.com (10.162.133.17) with Microsoft SMTP Server (TLS) id 15.1.207.19; Tue, 14 Jul 2015 15:14:15 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) by SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) with mapi id 15.01.0213.000; Tue, 14 Jul 2015 15:14:14 +0000 From: Robin Wilton To: "trans@ietf.org" Thread-Topic: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 Thread-Index: AQHQuBpPGCG5C3Yjsk2gpiJwYJqjm53QBhKAgATB2ICAABgpgIAGNGAAgAAGEgCAAAWXAA== Date: Tue, 14 Jul 2015 15:14:14 +0000 Message-ID: <46DD6573-8DCF-4A0E-ACA5-44FEBEB4EFCE@isoc.org> References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> <067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org> <559ACA08.1090609@bbn.com> <559FD57F.2060308@bbn.com> <559FE9C3.90409@gmail.com> <55A51E30.5070508@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [94.174.34.240] x-microsoft-exchange-diagnostics: 1; SN1PR06MB1837; 5:9RKu6QpQNSVrdHPVK4e3bEpdStIxTLTEoM6o/K0Me2ee0nKyJfaN5xo3KXhMLIPg3wkKRjfZaioco75HWNNydQvxNl3aszKtJ/Zk4ZpV/wpcHxbr0+iKz/UT+wwUxV3wE9XyJ52m3xL5ECX5Sw0GtA==; 24:FeDwUbXLXJ+iGL6Z+pjT4fyj7TLfGUUrQxxEUYcu7TB+7zXxYudvvXfQcJ5ctHWd7D0uDtbbd3d/A04Y6Em6QEO0Z9f7iqqPjaBiPFvF+vk=; 20:yAwWbjwju8OPYbATqXYybk1KfD5YAHDwoXtJ2mxAnWPJiStgrMxXoZjOFVHCIRnsO/Frufr+TILVyIs+9hJsnw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1837; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1760; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR06MB1837; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1837; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(252514010)(377454003)(149574003)(24454002)(479174004)(19580395003)(2900100001)(99286002)(5001960100002)(66066001)(76176999)(2950100001)(15975445007)(110136002)(77096005)(102836002)(106116001)(19580405001)(92566002)(62966003)(50986999)(83716003)(189998001)(16236675004)(2351001)(82746002)(54356999)(5002640100001)(77156002)(46102003)(2656002)(93886004)(99936001)(40100003)(2501003)(33656002)(36756003)(122556002)(86362001)(87936001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1837; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_D1AC2C66-36D0-43DE-8108-FB2AE841761E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2015 15:14:14.5278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1837 X-Microsoft-Exchange-Diagnostics: 1; SN1PR06MB1760; 2:r5d0rbkvfWOidry+1/Z1I0+Etm0CtWXRIrG4HUY0gS4qo61m/bVfJbnzkr3eCH7U; 3:SiG9HzUwRmFEC94/w0mcB3I72mg88zFkgzYtPeVgJ2d3DsyIYlu3zxnJ5VzcM/58OhXuPQ3GCtdIPmWc29KTI3tR92g0IeRCRt+r5h263zvzATq/H6MIYcONRjuxJnoX9Pz+aY+ETqYkAIRqcbPFmQ==; 25:fBkKiCh0SVR5T6ekPjRvYnvwKEkaAohc+KenlApz9W2vi96rAKzHdIwozpc+dpuKZ9qNtusL+GXeuP6+fG2FWofUbpxudvxiZo7tBNporTHp10R8PSTJ3eSKGSq5hAGM8CWM8FnwqkbeXNnXOp5eNOZs9OLodeGis93i7C+TL1eSkGufVEd/wl9R0kTu8BklE666zSe81An39R6NUG18ELydn8eEBQrudYnwza2dOlGC55yFedYc2VCrQn+H3CG2; 23:uw9fZ9i3aTxFrxO61ZXQjOMNNdjW9pPY3Fyw49YGtnJ4yy0YaNIW/PtJzQOWOV9KSv8P8E5QPQPfaXar4zQELlML1er9HBVaPoyXd5BS9sdRUjV1eLbcSWDOMHv34tAsH8IF47YwwwFOCEaFy6D9fxLLY7kckkOMH3pYrpLc76LFZOORzEqmnGu7r0tZ88fd6GYoqM7KxX6WKmrH/QAuNVdjoAV7x/UgjhRZyKp2ZnR+I0H49y9wqCAhMZFFnkuc X-OriginatorOrg: isoc.org Archived-At: Cc: Melinda Shore , Paul Wouters , Stephen Kent Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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, 14 Jul 2015 15:14:38 -0000 --Apple-Mail=_D1AC2C66-36D0-43DE-8108-FB2AE841761E Content-Type: multipart/alternative; boundary="Apple-Mail=_D2ED491B-4F27-4DFD-8730-F81CD6C3EF7F" --Apple-Mail=_D2ED491B-4F27-4DFD-8730-F81CD6C3EF7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I hadn=92t meant to comment on this further, after Melinda intervened. = However, since the issue has come up again, I offer the following = observation: The number of people who follow/lurk on this list is, I am sure, much = larger than the number who are active on it. Those who are active should, I suggest, be conscious of the effect the = tone of the discussion can have on the wider audience. I would not be at = all surprised if there were potential contributors who have been = discouraged from taking part, because the to-and-fro can appear = adversarial beyond what is needed to express and test technical = hypotheses. Respectfully, Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 14 Jul 2015, at 15:57, Paul Wouters wrote: > On Tue, 14 Jul 2015, Stephen Kent wrote: >=20 > Steve, >=20 >> Or, conversely, you could chastise Ben for making offensive = statements about >> Google's "position" in his posting. >> I observe that Ben's reply to my question about the "our" in his = message is that >> he was stating Google's position. >> Since the IETF ethos calls for us to participate as individuals, and = since Ben >> appears to be trying use Google's stature in supporting a technical = argument, >> where is the criticism of his statement? >=20 > While Ben could have made it clearer that he was speaking without his = RFC > document author hat on, he did clarify that later on. It is perfectly > reasonable for any participant to explain why their current $dayjob > would or would not be happy or violate/not violate certain protocol = bits > under discussion. In fact, such information is useful and can lead to > participants opening up to further discussion and reaching new = compromises. > In the end, we would end up with more interoperable implementations = from > different vendors. >=20 > In my view, Ben's remark were not "offensive", "flaunting" or "stark". >=20 >> Also, I have never seen any vendor make a statement on an IETF list = in which they >> openly say that their development plans are not influenced by = whatever IETF >> standards may arise. I don't doubt that many vendors feel and act = this >> way, but they usually don't flaunt their intent. >=20 > This is a very subjective view on your end. It is fine if Ben wants to > clarify the position of his $dayjob vendor. >=20 >> The issue here isn't whether >> browser UI details are appropriate fodder for IETF standards, but = rather whether >> Google staff should make stark statements like this in the context of = an IETF WG >> discussion. >=20 > I hope that Ben continues to explain the views of Google on various > protocol bits. I am also confident that Ben can keep his document = author > hat and $dayjob hat apart. If the working group feels that Ben can no > longer do this, we can think about adding another author/editor to = this > document, provided we can find a volunteer. >=20 >> On 7/10/15 6:23 AM, Stephen Kent wrote: >> nice of you to reaffirm that Google doesn't care about IETF standards >> in this context. >> Steve, this kind of commentary really needs to stop. >> Melinda >=20 > I concur. >=20 > Paul >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_D2ED491B-4F27-4DFD-8730-F81CD6C3EF7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <top-posting intentional>

I = hadn=92t meant to comment on this further, after Melinda intervened. = However, since the issue has come up again, I offer the following = observation:

The number of people who = follow/lurk on this list is, I am sure, much larger than the number who = are active on it.

Those who are active should, = I suggest, be conscious of the effect the tone of the discussion can = have on the wider audience. I would not be at all surprised if there = were potential contributors who have been discouraged from taking part, = because the to-and-fro can appear adversarial beyond what is needed to = express and test technical = hypotheses.

Respectfully,
Robin

Robin Wilton
Technical = Outreach Director - Identity and Privacy
Internet = Society

email: wilton@isoc.org
Phone: +44 705 = 005 2931
Twitter: @futureidentity

On 14 Jul 2015, at 15:57, Paul Wouters <paul@nohats.ca> wrote:

On Tue, 14 = Jul 2015, Stephen Kent wrote:

Steve,

Or, conversely, you could chastise Ben for making = offensive statements about
Google's "position" in his posting.
I = observe that Ben's reply to my question about the "our" in his message = is that
he was stating Google's position.
Since the IETF ethos = calls for us to participate as individuals, and since Ben
appears to = be trying use Google's stature in supporting a technical = argument,
where is the criticism of his = statement?

While Ben could have made it clearer that = he was speaking without his RFC
document author hat on, he did = clarify that later on. It is perfectly
reasonable for any participant = to explain why their current $dayjob
would or would not be happy or = violate/not violate certain protocol bits
under discussion. In fact, = such information is useful and can lead to
participants opening up to = further discussion and reaching new compromises.
In the end, we would = end up with more interoperable implementations from
different = vendors.

In my view, Ben's remark were not "offensive", = "flaunting" or "stark".

Also, I have = never seen any vendor make a statement on an IETF list in which = they
openly say that their development plans are not influenced by = whatever IETF
standards may arise.  I don't doubt that many = vendors feel and act this
way, but they usually don't flaunt their = intent.

This is a very subjective view on your end. = It is fine if Ben wants to
clarify the position of his $dayjob = vendor.

The issue here isn't = whether
browser UI details are appropriate fodder for IETF standards, = but rather whether
Google staff should make stark statements like = this in the context of an IETF WG
discussion.

I = hope that Ben continues to explain the views of Google on = various
protocol bits. I am also confident that Ben can keep his = document author
hat and $dayjob hat apart. If the working group feels = that Ben can no
longer do this, we can think about adding another = author/editor to this
document, provided we can find a = volunteer.

On 7/10/15 6:23 AM, Stephen = Kent wrote:
nice of you to reaffirm that Google doesn't care about = IETF standards
in this context.
Steve, this kind of commentary = really needs to stop.
Melinda

I = concur.

Paul

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

= --Apple-Mail=_D2ED491B-4F27-4DFD-8730-F81CD6C3EF7F-- --Apple-Mail=_D1AC2C66-36D0-43DE-8108-FB2AE841761E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlWlJ/wACgkQx1kEWLxmyT12QQCgkbDDxGAjaWUzuqChZdM4kdnT qtsAn3+mVZKZjD3BesVRqm+XkkfQA96A =H+NV -----END PGP SIGNATURE----- --Apple-Mail=_D1AC2C66-36D0-43DE-8108-FB2AE841761E-- From nobody Tue Jul 14 09:28:52 2015 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 8A2F91A1BC8 for ; Tue, 14 Jul 2015 09:28:50 -0700 (PDT) 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 1Deac1NYWer5 for ; Tue, 14 Jul 2015 09:28:43 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7B41A6F20 for ; Tue, 14 Jul 2015 09:28:42 -0700 (PDT) Received: (qmail 8187 invoked by uid 1004); 14 Jul 2015 16:28:40 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 14 Jul 2015 17:28:40 +0100 Received: (qmail 2310 invoked by uid 1000); 14 Jul 2015 16:28:40 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 14 Jul 2015 17:28:40 +0100 Message-ID: <55A53857.7040208@comodo.com> Date: Tue, 14 Jul 2015 17:27:03 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Wouters , Melinda Shore References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org><067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org><559ACA08.1090609@bbn.com><559FD57F.2060308@bbn.com> <559FE9C3.90409@gmail.com><55A51E30.5070508@bbn.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behaviorspecified in Section 5 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, 14 Jul 2015 16:28:50 -0000 On 14/07/15 15:57, Paul Wouters wrote: > I hope that Ben continues to explain the views of Google on various > protocol bits. I am also confident that Ben can keep his document author > hat and $dayjob hat apart. +1 > If the working group feels that Ben can no > longer do this, we can think about adding another author/editor to this > document, provided we can find a volunteer. Is there an upper limit on the number of authors/editors that an I-D/RFC can have? 6962-bis currently has 5 authors/editors. I've heard it said that there's a rule (which is unofficial but which is enforced) that 5 is the maximum. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jul 14 14:05:34 2015 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 DC8611B2D45 for ; Tue, 14 Jul 2015 14:05:32 -0700 (PDT) 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 o8YboD6NU7gy for ; Tue, 14 Jul 2015 14:05:25 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B691B2D41 for ; Tue, 14 Jul 2015 14:05:25 -0700 (PDT) Received: (qmail 15377 invoked by uid 1004); 14 Jul 2015 21:05:22 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 14 Jul 2015 22:05:22 +0100 Received: (qmail 15406 invoked by uid 1000); 14 Jul 2015 21:05:22 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 14 Jul 2015 22:05:22 +0100 Message-ID: <55A57991.4040405@comodo.com> Date: Tue, 14 Jul 2015 22:05:21 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org><067.7becba46c4f8b854834f9bb0c27374ce@tools.ietf.org><559A9977.1040808@bbn.com><559A9B83.6040000@comodo.com><559AA60A.1060501@bbn.com><559AD74A.5030806@comodo.com><559ADBF5.7000807@bbn.com><559ADF2B.3050507@comodo.com><559C2734.9090306@bbn.com> <559FA609.3050203@comodo.com> <55A51EC9.3050208@bbn.com> In-Reply-To: <55A51EC9.3050208@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 textrelogcertvalidationis ambiguous 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, 14 Jul 2015 21:05:33 -0000 On 14/07/15 15:38, Stephen Kent wrote: >> The "profile" for Google's logs would be something like this: >> >> "We accept whatever OpenSSL accepts. Good luck!" > > and is Google's log acceptance criteria the only one that counts? No. >> For example, when a TLS server sends its cert chain to a TLS client, >> can the TLS server know, deterministically, that the TLS client will >> either accept or reject the cert chain? > > in principle, only the lack of an agreed upon trust anchor should cause > a compliant client to reject a cert from a server (ignoring local policy > controls). Ditto for CT. i.e. in principle, only the lack of an agreed upon trust anchor should cause a compliant log to reject a cert from a submitter. > Servers rely on the ubiquity of trust anchor stores to reduce the > likelihood that validation will fail on that basis. So, for all > practical purposes, a server can have high confidence that its cert will > be accepted by browsers, if the cert is issued by a CA that is > widely represented in the (almost uniform) trust store. I disagree. Only if the CA issues 5280-compliant certs can they have that high confidence. For example, recently one CA was found to be incorrectly encoding basicConstraints.CA=FALSE by explicitly including the FALSE value even though FALSE is the DEFAULT (and DEFAULT values must not be explicitly included). This was discovered when a popular browser maker tightened up their DER decoding code and the certs stopped being accepted. >> Clearly the answer is no. So why should CT be expected to achieve a >> higher standard of determinism than TLS? > > two observations: > first, I disagree that the TLS example above is a probative as you > suggest. TLS clients and CT logs both need to verify certificate chains that they receive, and it's very likely that they'll use existing certificate chain processing libraries rather than roll their own code. So there will be OpenSSL-based TLS clients that encounter 5280-non-compliant cert chains, and there will be OpenSSL-based CT logs that encounter 5280-non-compliant cert chains. In both cases, OpenSSL does the certificate chain verification. > second, we have years of experience with what's wrong with TLS in > terms of cert processing, and hopefully we can do better with this > effort, when we create new ways to introduce non-determinism. I agree that it would be nice to do better, but I just don't see how anyone could ever complete the task of enumerating all of the ways in which 5280 can be violated (including all of the ways that haven't even been thought of yet) such that there can be a list of profiles detailing which sets of violations are tolerated and which aren't. It would be a constantly moving target, entirely unsuited to being an IANA registry. I can recall a couple of bugs in Comodo's ASN.1 code over the years that have led to some certs being issued with "minor" ASN.1 encoding errors. In both cases, the affected certs seemed to "work" fine everywhere until a new version of OpenSSL was released that no longer tolerated those particular encoding errors. So what did I do? Did I blame OpenSSL for breaking my certs? No. Did I blame IETF for not enumerating all possible encoding errors? No, that didn't even occur to me! I blamed myself ('cos I wrote the code that had the bugs), and I fixed the bugs. If, in the future, any CT logs start to reject Comodo certs and this leads to the discovery of another bug in my ASN.1 code, I will blame myself and fix the bug. I don't want CT to be vastly overcomplicated just so that CA bug authors such as myself aren't required to put in some effort (reading 5280, reviewing the OpenSSL source code, asking questions on mailing lists, etc, etc) to diagnose and fix our mistakes. Assuming I've still not convinced you, then let's agree to disagree. You think achieving determinism is practical, and I really don't. >>> Your argument seems to be that by introducing ambiguity and uncertainty >>> into the log validation process we will encourage CAs to adhere to 5280. >>> That strikes me as a questionable design strategy. >> >> Actually, I don't expect the level of CA adherence to 5280 to increase >> or decrease due to this strategy. > > I don't either, yet that seems to be a part of the argument you made. It really isn't. > Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jul 14 14:32:05 2015 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 12D091B2BC0 for ; Tue, 14 Jul 2015 14:32:00 -0700 (PDT) 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 6iT3nxCorkr5 for ; Tue, 14 Jul 2015 14:31:54 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EEA1B2CE6 for ; Tue, 14 Jul 2015 14:31:54 -0700 (PDT) Received: (qmail 16473 invoked by uid 1004); 14 Jul 2015 21:31:52 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 14 Jul 2015 22:31:52 +0100 Received: (qmail 26511 invoked by uid 1000); 14 Jul 2015 21:31:52 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 14 Jul 2015 22:31:52 +0100 Message-ID: <55A57FC7.7040700@comodo.com> Date: Tue, 14 Jul 2015 22:31:51 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , "trans@ietf.org" References: <55A51E3D.3070608@bbn.com> In-Reply-To: <55A51E3D.3070608@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs to define top-levelextension syntax 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, 14 Jul 2015 21:32:00 -0000 Steve, though I disagree with the thing you want to use an extension for, I completely agree that we need to define the top-level extension syntax. Your proposed text mostly looks good to me. Just a few nits/questions... 'The "CtExtensions" type is a vector of 0 or more extensions' - Isn't that clear from the "CtExtension CtExtensions<0..2^16-1>;" definition? Why restate it? 'All of the extensions in the vector MUST appear in order of increasing IDs.' - Why? And what would a CT client do if it encountered a violation of this proposed MUST? 'If an implementation sees an extension that it does not understand, it SHOULD ignore that extension.' - Wouldn't it be better to include a "critical" flag that has the same semantics as the "critical" flag for X.509v3 extensions? Are you planning to submit a pull request on GitHub for your proposed text? Or shall I? On 14/07/15 15:35, Stephen Kent wrote: > As promised, here is some proposed text for the required additional > syntax for SCT extensions. > > Add to Section 3.3: > > uint16 CtExtensionId; > > opaque CtExtensionValue<0..2^16-1>; > > struct { > CtExtensionId id; > CtExtensionValue value; > } CtExtension; > > CtExtension CtExtensions<0..2^16-1>; > > The "id" field identifies a single extension from the IANA registry > in Section 7.3. The interpretation of the "value" field is determined > solely by the value of the id field, and each document that registers a > new extension ID must describe how to interpret the corresponding > extension value. > > The "CtExtensions" type is a vector of 0 or more extensions. > This vector MUST NOT include more than one extension with the same ID. > All of the extensions in the vector MUST appear in order of increasing IDs. > > Change the last paragraph of Section 3.3 to: > > "extensions" are future extensions to SignedCertificateTimestamp v2. > Currently, no extensions are specified. If an implementation sees an > extension that it does not understand, it SHOULD ignore that extension. > Furthermore, an implementation MAY choose to ignore any extension(s) > that it does understand. > > > Add a new Section, "7.3. CT Extension IDs": > > IANA is asked to establish a registry of CT extension IDs, initially > consisting of: > > +-------+-----------+ > | ID | Extension | > +-------+-----------+ > | 65535 | reserved | > +-------+-----------+ > > TBD: policy for adding to the registry > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jul 14 15:03:24 2015 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 5CF871B2E56 for ; Tue, 14 Jul 2015 15:03:23 -0700 (PDT) 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 td71WlsJTNEU for ; Tue, 14 Jul 2015 15:03:22 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE651B2E5D for ; Tue, 14 Jul 2015 15:03:15 -0700 (PDT) Received: (qmail 17639 invoked by uid 1004); 14 Jul 2015 22:03:13 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 14 Jul 2015 23:03:13 +0100 Received: (qmail 5254 invoked by uid 1000); 14 Jul 2015 22:03:13 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 14 Jul 2015 23:03:13 +0100 Message-ID: <55A58720.3080001@comodo.com> Date: Tue, 14 Jul 2015 23:03:12 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org><067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org><559ACA08.1090609@bbn.com><559FD57F.2060308@bbn.com><559FDB04.7030801@comodo.com> <55A51ED1.5080801@bbn.com> In-Reply-To: <55A51ED1.5080801@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative clientbehaviorspecified in Section 5 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, 14 Jul 2015 22:03:23 -0000 On 14/07/15 15:38, Stephen Kent wrote: > Rob, > >> ... >>> Does _anyone_ care about IETF standards when it comes to UI? >> >> Has IETF ever actually published any standards relating to web browser >> UI? > > rejecting a cert, as the doc in question has previously mandated (as > recently as the -05 version), is not just a UI issue, IMHO. It's protocol > behavior and, as I noted last year, it's protocol behavior that requires a > plan to deal with incremental deployment. > > Less severe forms of discrimination against certs not accompanied by an > SCT may fall under the browser UI heading, and that they are not subject to > IETF standardization. I agree that rejecting a cert is protocol behaviour. However, I'm expecting that the "incremental deployment" will only involve "less severe forms of discrimination". Only once the "incremental deployment" is complete are we likely to see web browsers starting to reject certs that are not accompanied by SCT(s), IMHO. And clearly there's no need for a plan that would only be needed once there's no longer any need for a plan. ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jul 16 08:32:02 2015 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 8D8481A86F7 for ; Thu, 16 Jul 2015 08:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ax0pLu71foTj for ; Thu, 16 Jul 2015 08:31:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9C51A88BA for ; Thu, 16 Jul 2015 08:31:07 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:45595 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZFl7p-000Dvx-Se for trans@ietf.org; Thu, 16 Jul 2015 11:31:06 -0400 To: trans@ietf.org References: <55A51E3D.3070608@bbn.com> <55A57FC7.7040700@comodo.com> From: Stephen Kent Message-ID: <55A7CE38.4080303@bbn.com> Date: Thu, 16 Jul 2015 11:31:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55A57FC7.7040700@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs to define top-levelextension syntax 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, 16 Jul 2015 15:32:00 -0000 Rob, Thanks for the feedback and questions. > Steve, though I disagree with the thing you want to use an extension > for, I completely agree that we need to define the top-level extension > syntax. Your proposed text mostly looks good to me. Just a few > nits/questions... > > 'The "CtExtensions" type is a vector of 0 or more extensions' > - Isn't that clear from the "CtExtension CtExtensions<0..2^16-1>;" > definition? Why restate it? I find the syntax here a bit confusing, which I why I included that text. > > 'All of the extensions in the vector MUST appear in order of > increasing IDs.' > - Why? And what would a CT client do if it encountered a violation > of this proposed MUST? I was looking for two things: a simple canonicalization to be applied at this level, and a way to make it easier for an RP to compare a set of extensions against a list it might have locally. > 'If an implementation sees an extension that it does not understand, > it SHOULD ignore that extension.' > - Wouldn't it be better to include a "critical" flag that has the > same semantics as the "critical" flag for X.509v3 extensions? I thought about adding a critical flag, ala X,509v3, but was worried that it might seem overkill. I defer to the judgement of others here. > Are you planning to submit a pull request on GitHub for your proposed > text? Or shall I? I'm a believe that details of IETF WG discussions belong on IETF WG lists, so I have no plans to push this to GitHub, but thanks for the offer. Steve From nobody Thu Jul 16 14:31:50 2015 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 8C4CC1A010E for ; Thu, 16 Jul 2015 14:31:49 -0700 (PDT) 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 y-Ua55C8G_X9 for ; Thu, 16 Jul 2015 14:31:44 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566761A0016 for ; Thu, 16 Jul 2015 14:31:44 -0700 (PDT) Received: (qmail 29367 invoked by uid 1004); 16 Jul 2015 21:31:42 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 16 Jul 2015 22:31:42 +0100 Received: (qmail 8448 invoked by uid 1000); 16 Jul 2015 21:31:41 -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, 16 Jul 2015 22:31:41 +0100 Message-ID: <55A822BD.5000701@comodo.com> Date: Thu, 16 Jul 2015 22:31:41 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <55A51E3D.3070608@bbn.com> <55A57FC7.7040700@comodo.com> <55A7CE38.4080303@bbn.com> In-Reply-To: <55A7CE38.4080303@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs to definetop-levelextension syntax 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, 16 Jul 2015 21:31:49 -0000 On 16/07/15 16:31, Stephen Kent wrote: > Rob, > > Thanks for the feedback and questions. Thanks Steve. Further comments inline. >> Steve, though I disagree with the thing you want to use an extension >> for, I completely agree that we need to define the top-level extension >> syntax. Your proposed text mostly looks good to me. Just a few >> nits/questions... >> >> 'The "CtExtensions" type is a vector of 0 or more extensions' >> - Isn't that clear from the "CtExtension CtExtensions<0..2^16-1>;" >> definition? Why restate it? > > I find the syntax here a bit confusing, which I why I included that text. OK. >> 'All of the extensions in the vector MUST appear in order of >> increasing IDs.' >> - Why? And what would a CT client do if it encountered a violation >> of this proposed MUST? > > I was looking for two things: a simple canonicalization to be applied at > this level, and a way to make it easier for an RP to compare a set of > extensions against a list it might have locally. OK, as long as the client-behavior doc considers what a client will do if the extensions are in the wrong order. >> 'If an implementation sees an extension that it does not understand, >> it SHOULD ignore that extension.' >> - Wouldn't it be better to include a "critical" flag that has the >> same semantics as the "critical" flag for X.509v3 extensions? > > I thought about adding a critical flag, ala X,509v3, but was worried > that it might seem overkill. I defer to the judgement of others here. OK, on reflection, I think you're right. If there's ever a need to define an SCT "extension" that clients MUST understand and process, we can accommodate that by bumping the SCT version and changing the SCT structure. So there's no need for a per-extension critical flag. >> Are you planning to submit a pull request on GitHub for your proposed >> text? Or shall I? > > I'm a believe that details of IETF WG discussions belong on IETF WG > lists, so I have no plans to push this to GitHub I don't follow. We are having this discussion on an IETF WG list. > but thanks for the offer. You're welcome. However, I'm not clear if you've declined or accepted my offer. Could you clarify? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jul 17 06:35:47 2015 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 313B71B33D8 for ; Fri, 17 Jul 2015 06:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z3x-sGR4MEqq for ; Fri, 17 Jul 2015 06:35:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8731B33C0 for ; Fri, 17 Jul 2015 06:35:40 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54699 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZG5ne-000OV1-HX for trans@ietf.org; Fri, 17 Jul 2015 09:35:38 -0400 To: trans@ietf.org References: <55A51E3D.3070608@bbn.com> <55A57FC7.7040700@comodo.com> <55A7CE38.4080303@bbn.com> <55A822BD.5000701@comodo.com> From: Stephen Kent Message-ID: <55A904AA.9050206@bbn.com> Date: Fri, 17 Jul 2015 09:35:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55A822BD.5000701@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs to definetop-levelextension syntax 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, 17 Jul 2015 13:35:45 -0000 Rob, > ... >> I was looking for two things: a simple canonicalization to be applied at >> this level, and a way to make it easier for an RP to compare a set of >> extensions against a list it might have locally. > > OK, as long as the client-behavior doc considers what a client will do > if the extensions are in the wrong order. good point. > >>> 'If an implementation sees an extension that it does not understand, >>> it SHOULD ignore that extension.' >>> - Wouldn't it be better to include a "critical" flag that has the >>> same semantics as the "critical" flag for X.509v3 extensions? >> >> I thought about adding a critical flag, ala X,509v3, but was worried >> that it might seem overkill. I defer to the judgement of others here. > > OK, on reflection, I think you're right. If there's ever a need to > define an SCT "extension" that clients MUST understand and process, we > can accommodate that by bumping the SCT version and changing the SCT > structure. So there's no need for a per-extension critical flag. agreed. > >>> Are you planning to submit a pull request on GitHub for your proposed >>> text? Or shall I? >> >> I'm a believe that details of IETF WG discussions belong on IETF WG >> lists, so I have no plans to push this to GitHub > > I don't follow. We are having this discussion on an IETF WG list. You wanted to know if I planned to post the proposed syntax to GitHub. My answer (perhaps not clearly stated) was no. > >> but thanks for the offer. > > You're welcome. However, I'm not clear if you've declined or accepted > my offer. Could you clarify? If you believe that there are folks who don't track this list and who rely on GitHub to track CT stuff, then feel free to post there. Steve From nobody Fri Jul 17 16:40:42 2015 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 D83751A92F2 for ; Fri, 17 Jul 2015 16:40:40 -0700 (PDT) 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 DphE-EL1Vuna for ; Fri, 17 Jul 2015 16:40:37 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04B41A92F1 for ; Fri, 17 Jul 2015 16:40:35 -0700 (PDT) Received: (qmail 5521 invoked by uid 1004); 17 Jul 2015 23:40:33 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Sat, 18 Jul 2015 00:40:33 +0100 Received: (qmail 16547 invoked by uid 1000); 17 Jul 2015 23:40:33 -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; Sat, 18 Jul 2015 00:40:33 +0100 To: Stephen Kent , trans@ietf.org References: <55A51E3D.3070608@bbn.com> <55A57FC7.7040700@comodo.com><55A7CE38.4080303@bbn.com> <55A822BD.5000701@comodo.com> <55A904AA.9050206@bbn.com> From: Rob Stradling Message-ID: <55A9926E.708@comodo.com> Date: Sat, 18 Jul 2015 00:40:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55A904AA.9050206@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs todefinetop-levelextension syntax 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, 17 Jul 2015 23:40:41 -0000 On 17/07/15 14:35, Stephen Kent wrote: > If you believe that there are folks who don't track this list and who > rely on GitHub to track CT stuff, then feel free to post there. GitHub is what the 6962-bis authors are using to collaboratively edit the document. A GitHub pull request must be created for any proposed text before that proposed text is reviewed and incorporated into the document. We welcome pull requests from anyone (it's the most convenient way for us to accept proposed text), but posting proposed text to this WG mailing list is also fine. I've created a pull request and kicked off the review here: https://github.com/google/certificate-transparency-rfcs/pull/70 (BTW, the fact that the TRAC ticket and the pull request are both numbered 70 is purely coincidental). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jul 17 16:55:24 2015 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 F098A1A92EE for ; Fri, 17 Jul 2015 16:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tikP8pEW-6i8 for ; Fri, 17 Jul 2015 16:55:23 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03D41A1A66 for ; Fri, 17 Jul 2015 16:55:22 -0700 (PDT) Received: by pdjr16 with SMTP id r16so69894091pdj.3 for ; Fri, 17 Jul 2015 16:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=B9PX4i0uqCaNrT42Xxw/dz+375RHrMuWIdLAuKXEnY8=; b=mRSF4GaM37Azlrm1R+qR9LzZMvhhR0grhN8OR/txlPCNb0IAd+QnJjRnV1JYQFdaUN bHVsgfDAsyt9nAvTetFKf1trg3OjMKGHtlAJqhIr1zpxpnG84h7R4cDpYmlQvkiBNXWz rTsFMSYo/TB6GS5kRi0e+LXPTI+Ww+H+I4cmkufwOiPMiJHCz5bciCZUrDnRAKI1Qgqg t2H9Q5z57ZoBs1pr8fbsm7Ltzdea1y2KxP7ErRNV5eeYVNlejok+2t1xxmtZ7C3bOwNc Dyw+f2MY+ny6b/cOYAB9lcVdLm8Zz6xjLDdw54+iAix0UeuQAIF4vFQexvzBBDs7T28V nPGw== X-Received: by 10.69.26.4 with SMTP id iu4mr33850394pbd.140.1437177322720; Fri, 17 Jul 2015 16:55:22 -0700 (PDT) Received: from spandex.local (209-112-132-161.dynamic.dsl.acsalaska.net. [209.112.132.161]) by smtp.gmail.com with ESMTPSA id nw8sm12480090pdb.30.2015.07.17.16.55.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2015 16:55:21 -0700 (PDT) Message-ID: <55A995E7.7060202@gmail.com> Date: Fri, 17 Jul 2015 15:55:19 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <55A51E3D.3070608@bbn.com> <55A57FC7.7040700@comodo.com><55A7CE38.4080303@bbn.com> <55A822BD.5000701@comodo.com> <55A904AA.9050206@bbn.com> <55A9926E.708@comodo.com> In-Reply-To: <55A9926E.708@comodo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs todefinetop-levelextension syntax 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, 17 Jul 2015 23:55:24 -0000 On 7/17/15 3:40 PM, Rob Stradling wrote: > GitHub is what the 6962-bis authors are using to collaboratively edit > the document. A GitHub pull request must be created for any proposed > text before that proposed text is reviewed and incorporated into the > document. I think it's not a great idea to restrict document input from people who aren't familiar with a particular tool. Any commit will show up in the document history so I don't think that text really does need to come in the form of a pull request. That said, if people have text and aren't comfortable with git (or with xml2rfc), I can submit the pull request for them. Melinda From nobody Mon Jul 20 04:22:41 2015 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 3010D1A1F1D for ; Mon, 20 Jul 2015 04:22:40 -0700 (PDT) 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 QyAyHjTW_nUp for ; Mon, 20 Jul 2015 04:22:36 -0700 (PDT) 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 A2C311A1EFF for ; Mon, 20 Jul 2015 04:22:36 -0700 (PDT) Received: from localhost ([::1]:38550 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZH99Y-0003hC-0B; Mon, 20 Jul 2015 04:22:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 20 Jul 2015 11:22:35 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/75#comment:2 Message-ID: <067.cbfc40131a3dfa8993da60df22ba2fe4@tools.ietf.org> References: <052.8c83add4a6489debc30278738f81ab1a@tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <052.8c83add4a6489debc30278738f81ab1a@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: <20150720112236.A2C311A1EFF@ietfa.amsl.com> Resent-Date: Mon, 20 Jul 2015 04:22:36 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #75 (rfc6962-bis): run on sentence in section 3 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:22:40 -0000 #75: run on sentence in section 3 Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/7394b2169e532d32752e89cf5d5bf0a6a308a85d -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 20 04:58:51 2015 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 8640D1A6FF2 for ; Mon, 20 Jul 2015 04:58:49 -0700 (PDT) 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 myY8JadsRg1u for ; Mon, 20 Jul 2015 04:58:46 -0700 (PDT) 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 BA56B1A6FF6 for ; Mon, 20 Jul 2015 04:58:46 -0700 (PDT) Received: from localhost ([::1]:40186 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZH9iW-0005vf-6J; Mon, 20 Jul 2015 04:58:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 20 Jul 2015 11:58:44 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/75#comment:3 Message-ID: <067.3c604376ef91cf985cd73870d8bc1e72@tools.ietf.org> References: <052.8c83add4a6489debc30278738f81ab1a@tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <052.8c83add4a6489debc30278738f81ab1a@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: <20150720115846.BA56B1A6FF6@ietfa.amsl.com> Resent-Date: Mon, 20 Jul 2015 04:58:46 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #75 (rfc6962-bis): run on sentence in section 3 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:58:49 -0000 #75: run on sentence in section 3 Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 20 05:53:25 2015 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 D05A81A8770 for ; Mon, 20 Jul 2015 05:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.111 X-Spam-Level: * X-Spam-Status: No, score=1.111 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, 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 O3VtcSCNygTW for ; Mon, 20 Jul 2015 05:53:21 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184661A87B0 for ; Mon, 20 Jul 2015 05:51:34 -0700 (PDT) Received: by ykax123 with SMTP id x123so137893839yka.1 for ; Mon, 20 Jul 2015 05:51:33 -0700 (PDT) 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=HH28oDGxi7qcSRSh9FhiILOkZcTMypOE9eu9xD2MBqo=; b=RQAGEbXR90DsN55UaTGf+W+Nu9K+1IsnKZjyrIXDNtxS14zyiUPfX7pG+R3oL9eqrX fBaaXIUq05yiMXXI/8BtDkKuecNbgyxDP7gxnKN4hhfBR7VmhveFldzr1ghurP6+y6mx z7A6Nl4ZHQ3+mas6+JI49Js44T+/UiHpk0H+pDPg6udVAOhVm1NcZFpyf/liJd+6JR7S 2nJzvIXshKJs0V+P3vSMsPb8jSLldFlV/Wd2efLPMSJCaf2GQa8mv9rspxh6x9gcQ2Yn PxYXNvLopQUCdEYb+t5GWblkLi9OOiwAegGcDCm3p+Ch0yKX9267vfXn+yUa+qMu4nho gDaA== 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=HH28oDGxi7qcSRSh9FhiILOkZcTMypOE9eu9xD2MBqo=; b=FBlzKekZR7idpvRL8o+Z6JkX4egR8bel4e8Aesx8aJVYLqMrF8h+n5Hv16rcADOZ9B 71Rq5liAd5+qJDJf0TghSb73SQUbEoh2uCP4MFBrKrNkM0aRoEjnKzL44E8VG/GK6w+p T0NLlLKqsl4ARumP4XTRMvRPnDJEvmml/kFYKBBRE59OiLJECNbmTFaPtLo4TA6wNPw6 Cg94ViR8toFXLHNRnJ0L25H7a/32rIO11JkP36h0sKzZxBMl0dfi6Q+s4VuP0Qeoh+03 7H92T+eotu+bmfo5fr8NiKd5X1Y/sgQwyKlbCT0pLa2SXpL+v9dhMAtJwkMwIlKWCMk0 7x/g== X-Gm-Message-State: ALoCoQmlrh7dl+hkpL3rv+0h/wrh8EVsshtGzKxtlrct8Tj/bAXLXA94yo8GH4i9uOtyLtXx71Xh MIME-Version: 1.0 X-Received: by 10.170.91.3 with SMTP id i3mr8466975yka.25.1437396693306; Mon, 20 Jul 2015 05:51:33 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Mon, 20 Jul 2015 05:51:33 -0700 (PDT) Date: Mon, 20 Jul 2015 13:51:33 +0100 Message-ID: From: Ben Laurie To: draft-linus-trans-gossip-ct@tools.ietf.org, "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113a05e84eae8e051b4dff3f Archived-At: Subject: [Trans] Review of draft-linus-trans-gossip-ct-02 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, 20 Jul 2015 12:53:24 -0000 --001a113a05e84eae8e051b4dff3f Content-Type: text/plain; charset=UTF-8 Comments in {} when in quoted sections. "2. Overview Public append-only untrusted {verifiable is perhaps a better word} logs " Diagram in section 3 appears to omit SCTs delivered over OCSP. Also, the line from CA to Website is labelled "Cert and SCT" but the SCT may be omitted. Section 5 "Trusted Auditor Stream, HTTPS clients communicating directly with trusted CT auditors/monitors sharing SCTs, certificate chains and STHs. {Slightly confused: section 4 mentions auditors and monitors using this channel between themselves?}" 5.1 " Note that clients send the same SCTs and chains to servers multiple times with the assumption that a potential man-in-the-middle attack eventually will cease so that an honest server will receive collected malicious SCTs and certificate chains. {note that if an SCT is sent over a channel that used an SCT from the same log, then that new SCT can replace the existing one for reporting - bad behaviour is still detected - i.e. an SCT can be considered "sent" if it is sent over a channel validated by the same log}" 5.1.1 " The client MUST send to the server the ones in the store that are for that server and were not received from that server. {comment about "sent SCTs" applies}" "An SCT MUST NOT be sent to any other HTTPS server than one serving the domain that the certificate signed by the SCT refers to.{Not all TLS clients care about privacy: e.g. crawlers, so this MUST NOT is too strong}" "First, the server recieving the SCT would learn about other sites visited by the HTTPS client{if SCTs are gossipped then this is clearly untrue: however, I agree that it is hard to avoid some kind of privacy leak}. " "Secondly, auditors or monitors recieving SCTs from the HTTPS server would learn information about the other HTTPS servers visited by its clients.{ditto}" "If the HTTPS client has configuration options for not sending cookies to third parties, SCTs MUST be treated as cookies with respect to this setting.{don't understand - you already banned sending to third parties}" "The data sent in the POST is defined in Section 5.1.3.{what if the POST fails, as it obviously will for most servers initially?}" " 3. if the leaf cert is not for a domain that the server is authoritative for, the SCT MUST be discarded {only true if you ban SCT gossip}" " It's important to note that the check must be on pairs of SCT and chain in order to catch different chains accompanied by the same SCT. [XXX why is this important?]{given that logs do _not_ have to log multiple chains, I suspect this is actually not important}" " Note that an HTTPS server MAY perform a certificate chain validation on a submitted certificate chain, and if it matches a trust root configured on the server (but is otherwise unknown to the server), the HTTPS server MAY store the certificate chain and MAY choose to store any submitted SCTs even if they are unable to be verified. The risk of spamming and denial of service can be mitigated by configuring the server with all known acceptable certificates (or certificate hashes). {Confused by this, surely the point is to find certs/SCTs the server does not expect?}" 5.1.3 " * sct_data: An array of objects consisting of the base64 representation of the binary SCT data as defined in [RFC6962] Section 3.2. {SCTs may be in the certs, so should they be replicated here or not?}" " The 'x509_chain' element MUST contain at{typo} the leaf certificate and the full chain to a known root." 5.2 " o Logs cannot issue STHs too frequently. This is restricted to 1 per hour. {probably should refer to 6962-bis for this restriction}" Also in 5.2, note that servers could function as their own auditors. 5.2.2 "After retrieving the consistency proof to the most recent STH, they SHOULD pollinate this new STH among participating HTTPS Servers {and may safely discard the older STH}. " 5.2.3 " o sths - an array of 0 or more fresh STH objects [XXX recently collected] from the log associated with log_id. Each of these objects consists of {note that we've moved to binary format for SCTs in 6962-bis}" 6.1.1 " Therefore, a client with an SCT for a given server should transmit that information in only two channels: to a server associated with the SCT itself; and to a trusted CT auditor, if one exists.{only if the client cares about privacy}" 6.1.4 "This is similar to the fingerprinting attack described in Section 6.1.2, but it is mitigated by the following factors: {mention rate limit?}" 6.1.6 "The log's inability to provide either proof will not be externally cryptographically- verifiable, as it may be indistinguishable from a network error. {note that anyone who sees the whole log can independently prove inconsistency/non-inclusion}" --001a113a05e84eae8e051b4dff3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Comments in {} when in quoted sections.

"2.=C2=A0 Overview

=C2=A0 =C2=A0Public appen= d-only untrusted {verifiable is perhaps a better word} logs "


Diagram in section 3 appears to omit SCTs d= elivered over OCSP.

Also, the line from CA to Webs= ite is labelled "Cert and SCT" but the SCT may be omitted.
<= div>

Section 5

"= Trusted Auditor Stream, HTTPS clients communicating directly with
=C2=A0 =C2=A0 =C2=A0 trusted CT auditors/monitors sharing SCTs, certificat= e chains and
=C2=A0 =C2=A0 =C2=A0 STHs. {Slightly confused: secti= on 4 mentions auditors and monitors using this channel between themselves?}= "

5.1

" Note th= at clients
=C2=A0 =C2=A0send the same SCTs and chains to servers = multiple times with the
=C2=A0 =C2=A0assumption that a potential = man-in-the-middle attack eventually will
=C2=A0 =C2=A0cease so th= at an honest server will receive collected malicious SCTs
=C2=A0 = =C2=A0and certificate chains. {note that if an SCT is sent over a channel t= hat used an SCT from the same log, then that new SCT can replace the existi= ng one for reporting - bad behaviour is still detected - i.e. an SCT can be= considered "sent" if it is sent over a channel validated by the = same log}"

5.1.1

&qu= ot; The client MUST
=C2=A0 =C2=A0send to the server the ones in t= he store that are for that server and
=C2=A0 =C2=A0were not recei= ved from that server. {comment about "sent SCTs" applies}"

"An SCT MUST NOT be sent to any other HTTPS se= rver than one serving
=C2=A0 =C2=A0the domain that the certificat= e signed by the SCT refers to.{Not all TLS clients care about privacy: e.g.= crawlers, so this MUST NOT is too strong}"

&= quot;First, the server
=C2=A0 =C2=A0recieving the SCT would learn= about other sites visited by the HTTPS
=C2=A0 =C2=A0client{if SC= Ts are gossipped then this is clearly untrue: however, I agree that it is h= ard to avoid some kind of privacy leak}. "

&q= uot;Secondly, auditors or monitors recieving SCTs from the HTTPS
= =C2=A0 =C2=A0server would learn information about the other HTTPS servers v= isited
=C2=A0 =C2=A0by its clients.{ditto}"

"If the HTTPS client has configuration options for not sendin= g cookies
=C2=A0 =C2=A0to third parties, SCTs MUST be treated as = cookies with respect to
=C2=A0 =C2=A0this setting.{don't unde= rstand - you already banned sending to third parties}"

<= /div>
"The data sent in the POST is defined in Section 5.1.3.{what= if the POST fails, as it obviously will for most servers initially?}"=

" =C2=A0 3. =C2=A0if the leaf cert is not fo= r a domain that the server is
=C2=A0 =C2=A0 =C2=A0 =C2=A0authorit= ative for, the SCT MUST be discarded {only true if you ban SCT gossip}"= ;

" It's important to note
=C2= =A0 =C2=A0that the check must be on pairs of SCT and chain in order to catc= h
=C2=A0 =C2=A0different chains accompanied by the same SCT. =C2= =A0[XXX why is this
=C2=A0 =C2=A0important?]{given that logs do _= not_ have to log multiple chains, I suspect this is actually not important}= "

" Note that an HTTPS server MAY perfor= m a certificate chain validation
=C2=A0 =C2=A0on a submitted cert= ificate chain, and if it matches a trust root
=C2=A0 =C2=A0config= ured on the server (but is otherwise unknown to the server),
=C2= =A0 =C2=A0the HTTPS server MAY store the certificate chain and MAY choose t= o
=C2=A0 =C2=A0store any submitted SCTs even if they are unable t= o be verified.=C2=A0 The
=C2=A0 =C2=A0risk of spamming and denial= of service can be mitigated by
=C2=A0 =C2=A0configuring the serv= er with all known acceptable certificates (or
=C2=A0 =C2=A0certif= icate hashes). {Confused by this, surely the point is to find certs/SCTs th= e server does not expect?}"

5.1.3
<= br>
" =C2=A0 =C2=A0 =C2=A0* =C2=A0sct_data: An array of obje= cts consisting of the base64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0re= presentation of the binary SCT data as defined in [RFC6962]
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.2. {SCTs may be in the certs, so s= hould they be replicated here or not?}"

"= ; =C2=A0 The 'x509_chain' element MUST contain at{typo} the leaf ce= rtificate and the
=C2=A0 =C2=A0full chain to a known root."<= /div>

5.2

" =C2=A0 o =C2= =A0Logs cannot issue STHs too frequently.=C2=A0 This is restricted to 1
=C2=A0 =C2=A0 =C2=A0 per hour. {probably should refer to 6962-bis fo= r this restriction}"

Also in 5.2, note that s= ervers could function as their own auditors.

5.2.2=

"After retrieving the consistency proof to t= he most recent STH, they
=C2=A0 =C2=A0SHOULD pollinate this new S= TH among participating HTTPS Servers {and may safely discard the older STH}= . "

5.2.3

" =C2= =A0o =C2=A0sths - an array of 0 or more fresh STH objects [XXX recently
=C2=A0 =C2=A0 =C2=A0 collected] from the log associated with log_id.= =C2=A0 Each of these
=C2=A0 =C2=A0 =C2=A0 objects consists of {no= te that we've moved to binary format for SCTs in 6962-bis}"
<= div>
6.1.1

" Therefore, a
=
=C2=A0 =C2=A0client with an SCT for a given server should transmit tha= t
=C2=A0 =C2=A0information in only two channels: to a server asso= ciated with the SCT
=C2=A0 =C2=A0itself; and to a trusted CT audi= tor, if one exists.{only if the client cares about privacy}"

6.1.4

"This is similar to
=C2=A0 =C2=A0the fingerprinting attack described in Section 6.1.2, b= ut it is
=C2=A0 =C2=A0mitigated by the following factors: {mentio= n rate limit?}"

6.1.6

"The log's inability to
=C2=A0 =C2=A0 =C2=A0 provide e= ither proof will not be externally cryptographically-
=C2=A0 =C2= =A0 =C2=A0 verifiable, as it may be indistinguishable from a network error.= {note that anyone who sees the whole log can independently prove inconsist= ency/non-inclusion}"

--001a113a05e84eae8e051b4dff3f-- From nobody Mon Jul 20 07:20:59 2015 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 F28871A8932 for ; Mon, 20 Jul 2015 07:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GnkRpajZaIYI for ; Mon, 20 Jul 2015 07:20:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791B51A891C for ; Mon, 20 Jul 2015 07:20:56 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54592 helo=dhcp-a396.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZHBw6-000Px5-Sx for trans@ietf.org; Mon, 20 Jul 2015 10:20:55 -0400 From: Stephen Kent To: trans@ietf.org References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org><067.905aedf191f612b7a69c90d6d2c8ea46@tools.ietf.org><559ACA08.1090609@bbn.com><559FD57F.2060308@bbn.com><559FDB04.7030801@comodo.com> <55A51ED1.5080801@bbn.com> <55A58720.3080001@comodo.com> Message-ID: <55AD03C5.1080509@bbn.com> Date: Mon, 20 Jul 2015 16:20:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55A58720.3080001@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative clientbehaviorspecified in Section 5 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, 20 Jul 2015 14:20:58 -0000 Rob, I'm glad we agree that rejecting a cert is protocol behavior, not just a UI issue. We can't assume that incremental deployment will ever be "complete." I've been told by one major browser vendor that they like the logging and Monitor aspects of CT, but do not see browser behavior as a critical element. Thus they do not plan to make their browsers reject certs (maybe not even discriminate) based on the lack of an SCT. Given the history of browser behavior wrt cert revocation status checking, this is not a surprising perspective. Steve From nobody Mon Jul 20 08:00:23 2015 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 AF8F01A8A61 for ; Mon, 20 Jul 2015 08:00:12 -0700 (PDT) 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 DPsE2UxDHUJE for ; Mon, 20 Jul 2015 08:00:08 -0700 (PDT) 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 C14A11A8A6D for ; Mon, 20 Jul 2015 08:00:08 -0700 (PDT) Received: from localhost ([::1]:55914 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZHCY2-0000gt-8L; Mon, 20 Jul 2015 08:00:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 20 Jul 2015 15:00:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/70#comment:3 Message-ID: <067.da409664960e640a7bcac2bc0b766c0a@tools.ietf.org> References: <052.ecfc9a319e455c61897ed3e82e509b78@tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <052.ecfc9a319e455c61897ed3e82e509b78@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150720150008.C14A11A8A6D@ietfa.amsl.com> Resent-Date: Mon, 20 Jul 2015 08:00:08 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #70 (rfc6962-bis): STH spec needs to define top-level extension syntax X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 15:00:12 -0000 #70: STH spec needs to define top-level extension syntax Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/91a7ce0bc4e1b51e9e22d015cd6fefc0fcebd202 and https://github.com/google/certificate-transparency- rfcs/commit/7525741318ee7cd4f79d126a708522482b81b1f5 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 20 08:08:10 2015 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 40DE31A8AC8 for ; Mon, 20 Jul 2015 08:08:09 -0700 (PDT) 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 ebjp3AdFp_ps for ; Mon, 20 Jul 2015 08:08:05 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9086A1A8ACD for ; Mon, 20 Jul 2015 08:07:56 -0700 (PDT) Received: (qmail 12831 invoked by uid 1004); 20 Jul 2015 15:07:54 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 20 Jul 2015 16:07:54 +0100 Received: (qmail 26909 invoked by uid 1000); 20 Jul 2015 15:07:54 -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, 20 Jul 2015 16:07:54 +0100 To: Stephen Kent , trans@ietf.org References: <55A51E3D.3070608@bbn.com><55A57FC7.7040700@comodo.com><55A7CE38.4080303@bbn.com><55A822BD.5000701@comodo.com> <55A904AA.9050206@bbn.com> <55A9926E.708@comodo.com> From: Rob Stradling Message-ID: <55AD0EC9.9000303@comodo.com> Date: Mon, 20 Jul 2015 16:07:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55A9926E.708@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needstodefinetop-levelextension syntax 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, 20 Jul 2015 15:08:09 -0000 On 18/07/15 00:40, Rob Stradling wrote: > On 17/07/15 14:35, Stephen Kent wrote: > >> If you believe that there are folks who don't track this list and who >> rely on GitHub to track CT stuff, then feel free to post there. > > GitHub is what the 6962-bis authors are using to collaboratively edit > the document. A GitHub pull request must be created for any proposed > text before that proposed text is reviewed and incorporated into the > document. We welcome pull requests from anyone (it's the most > convenient way for us to accept proposed text), but posting proposed > text to this WG mailing list is also fine. > > I've created a pull request and kicked off the review here: > https://github.com/google/certificate-transparency-rfcs/pull/70 Steve, I made some changes to your proposed text to align the syntax with the TLS Hello Extensions syntax from RFC5246, and I've merged the text into rfc6962-bis.xml in the GitHub repo. If you want to review the changes, please browse to the GitHub URLs quoted in the TRAC ticket. > (BTW, the fact that the TRAC ticket and the pull request are both > numbered 70 is purely coincidental). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jul 20 08:38:24 2015 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 5D7DF1A8AF6 for ; Mon, 20 Jul 2015 08:38:22 -0700 (PDT) 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 5Paqw5-YJaJ7 for ; Mon, 20 Jul 2015 08:38:21 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C24D1A8BB1 for ; Mon, 20 Jul 2015 08:38:19 -0700 (PDT) Received: (qmail 14460 invoked by uid 1004); 20 Jul 2015 15:38:17 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 20 Jul 2015 16:38:17 +0100 Received: (qmail 6266 invoked by uid 1000); 20 Jul 2015 15:38:17 -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, 20 Jul 2015 16:38:17 +0100 To: "trans@ietf.org" From: Rob Stradling Message-ID: <55AD15E9.6020807@comodo.com> Date: Mon, 20 Jul 2015 16:38:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH specneedstodefinetop-levelextension syntax 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, 20 Jul 2015 15:38:22 -0000 On 20/07/15 15:20, Stephen Kent wrote: > Rob, > > I'm glad we agree that rejecting a cert is protocol behavior, not > just a UI issue. > > We can't assume that incremental deployment will ever be "complete." > I've been told by one major browser vendor that they like the logging > and Monitor aspects of CT, but do not see browser behavior as a > critical element. Thus they do not plan to make their browsers reject > certs (maybe not even discriminate) based on the lack of an SCT. That's interesting, thanks. I'm not sure how it relates to the point we're discussing though. If a browser is never going to reject certs that are not accompanied by an SCT, it doesn't need an incremental deployment plan that's designed to help it get to the point where it can reject certs that are not accompanied by an SCT. > Given the history of browser behavior wrt cert revocation status > checking, this is not a surprising perspective. I am a bit surprised, actually. Some browsers no longer perform out-of-band revocation checks by contacting CA revocation servers directly, but they do still process revocation information passed in-band (i.e. OCSP Stapling). SCTs are passed in-band. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jul 22 02:27:21 2015 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 947EF1AD2F2 for ; Wed, 22 Jul 2015 02:27:16 -0700 (PDT) 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 d-wH9i_q3m4a for ; Wed, 22 Jul 2015 02:27:15 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3463A1AD2AF for ; Wed, 22 Jul 2015 02:26:01 -0700 (PDT) Received: by ykfw194 with SMTP id w194so107629179ykf.0 for ; Wed, 22 Jul 2015 02:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=D5sSlm26YBIr4taE08KRYJ6+a34Q7QCAg+ljk76cd9I=; b=Ys6zuUQGCTD266s3rEEkvJSZCcnESedirQ4yQcxrAuVUZDNXuCvra/4KYJFvflTylK T28sGQzbtpqukKKkL20eKoOiScbnN9JUC+DjFw808ZQHZPdmzNpSku2TDTstrgEPYCZX CJXjqPS5NPLdYl1TSwK6vZAty8rJPdbFFFF5687S3K8EBQ91lI8BgunuztXpW+64attT oYNU0G6yOHsyNIfwYXC0D840/27gRVYz8vv8Oot/85Tbk9xrc6DXN2YwTqL08AsRLX4Q RjZQPKh19DtbpJkrYUmzihRqACdFfdO2aHDzsPrAfVfnvo4QZObi7G53WQqUDTyzwIZ+ 807g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=D5sSlm26YBIr4taE08KRYJ6+a34Q7QCAg+ljk76cd9I=; b=JQ5ab9CAkBqx3ICJsE6ZR6hd3hNHGmuA2GiM2qCsGkPHM5gefXsS0iORcIoGqkXQnk xg901/jBCr0Hn4000ItCFuzFzEV9eO9XKM1rjve4Q+tCWZ7rVzghYvSOb2Sph44Gg/Xr fzPslbfaWFxYDFCdR2iEm6DmNYTTmKODgIAo13IZNZoYMqflbZNIWSb00JlrQYZQTPPz idC4hmnTgMhhv4aP7KK2Iy3j3bEM07pFXUqPTpnouiecjl1SBmmqYG3jD6rC3HfmMl32 KqVneYY0jH/9T+GQId8tt5XfdFRo2A3vhWvaz+3+FgvXD8bLcB3q2JE0WVUxsrVCWBf0 wT6g== X-Gm-Message-State: ALoCoQlqwMa9ghaK+zj+5euatryT0IdoKT+Y7v3fTz6MUZ3MZU9s6tjL/tWdDKoKDQG2cTXT7A9n X-Received: by 10.170.118.195 with SMTP id k186mr1397342ykb.53.1437557160517; Wed, 22 Jul 2015 02:26:00 -0700 (PDT) MIME-Version: 1.0 References: <55A51E3D.3070608@bbn.com> <55A57FC7.7040700@comodo.com> <55A7CE38.4080303@bbn.com> <55A822BD.5000701@comodo.com> <55A904AA.9050206@bbn.com> <55A9926E.708@comodo.com> <55A995E7.7060202@gmail.com> In-Reply-To: <55A995E7.7060202@gmail.com> From: Ben Laurie Date: Wed, 22 Jul 2015 09:25:51 +0000 Message-ID: To: Melinda Shore , trans@ietf.org Content-Type: multipart/alternative; boundary=001a11391650e5cc96051b735b41 Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH spec needs todefinetop-levelextension syntax 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, 22 Jul 2015 09:27:16 -0000 --001a11391650e5cc96051b735b41 Content-Type: text/plain; charset=UTF-8 On Sat, 18 Jul 2015 at 00:55 Melinda Shore wrote: > On 7/17/15 3:40 PM, Rob Stradling wrote: > > GitHub is what the 6962-bis authors are using to collaboratively edit > > the document. A GitHub pull request must be created for any proposed > > text before that proposed text is reviewed and incorporated into the > > document. > > I think it's not a great idea to restrict document input from people > who aren't familiar with a particular tool. Any commit will show up > in the document history so I don't think that text really does > need to come in the form of a pull request. That said, if people > have text and aren't comfortable with git (or with xml2rfc), I can > submit the pull request for them. > To be clear, Rob said in the following text you redacted that posting text here (or in trac, in fact) would be fine. The point is that we (the editors) are using github to coordinate, so if people want they can directly propose changes to the text in the form of a pull request. Entirely optional. --001a11391650e5cc96051b735b41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat= , 18 Jul 2015 at 00:55 Melinda Shore <melinda.shore@gmail.com> wrote:
On 7/17/15 3:40 PM, Rob Stradling wrote:
> GitHub is what the 6962-bis authors are using to collaboratively edit<= br> > the document.=C2=A0 A GitHub pull request must be created for any prop= osed
> text before that proposed text is reviewed and incorporated into the > document.

I think it's not a great idea to restrict document input from people who aren't familiar with a particular tool.=C2=A0 Any commit will show = up
in the document history so I don't think that text really does
need to come in the form of a pull request.=C2=A0 That said, if people
have text and aren't comfortable with git (or with xml2rfc), I can
submit the pull request for them.

To be= clear, Rob said in the following text you redacted that posting text here = (or in trac, in fact) would be fine.

The point is = that we (the editors) are using github to coordinate, so if people want the= y can directly propose changes to the text in the form of a pull request. E= ntirely optional.

--001a11391650e5cc96051b735b41-- From nobody Wed Jul 22 05:53:21 2015 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 7C8A61A1A39 for ; Wed, 22 Jul 2015 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y5ZYwiQIkJrT for ; Wed, 22 Jul 2015 05:53:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0971B330D for ; Wed, 22 Jul 2015 05:53:13 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:49483 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZHtWF-000LnM-2l for trans@ietf.org; Wed, 22 Jul 2015 08:53:07 -0400 To: trans@ietf.org References: <55AD15E9.6020807@comodo.com> From: Stephen Kent Message-ID: <55AF9230.6090909@bbn.com> Date: Wed, 22 Jul 2015 14:53:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AD15E9.6020807@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STH specneedstodefinetop-levelextension syntax 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, 22 Jul 2015 12:53:18 -0000 Rob, > On 20/07/15 15:20, Stephen Kent wrote: > > Rob, > > > > I'm glad we agree that rejecting a cert is protocol behavior, not > > just a UI issue. > > > > We can't assume that incremental deployment will ever be "complete." > > I've been told by one major browser vendor that they like the logging > > and Monitor aspects of CT, but do not see browser behavior as a > > critical element. Thus they do not plan to make their browsers reject > > certs (maybe not even discriminate) based on the lack of an SCT. > > That's interesting, thanks. > > I'm not sure how it relates to the point we're discussing though. If a > browser is never going to reject certs that are not accompanied by an > SCT, it doesn't need an incremental deployment plan that's designed to > help it get to the point where it can reject certs that are not > accompanied by an SCT. agreed, tautologically. > > > Given the history of browser behavior wrt cert revocation status > > checking, this is not a surprising perspective. > > I am a bit surprised, actually. Some browsers no longer perform > out-of-band revocation checks by contacting CA revocation servers > directly, but they do still process revocation information passed > in-band (i.e. OCSP Stapling). yes, some do. Having a server pass the OCSP data is analogous to having it pass an SCT, and we've been told that it will take too long for that to happen, hence the embedded SCT in a cert feature of CT. > > SCTs are passed in-band. Yes, but 6962-bis says that TLS clients MAY contact a log to get a proof for the SCT, and the gossip proposal relies on clients contacting logs to acquire STHs. So, ... Steve From nobody Wed Jul 22 14:31:35 2015 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 5FB461B2E9E for ; Wed, 22 Jul 2015 14:31:33 -0700 (PDT) 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 fhdH5cJ6Sdy3 for ; Wed, 22 Jul 2015 14:31:32 -0700 (PDT) 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 BFF351B2E5F for ; Wed, 22 Jul 2015 14:31:31 -0700 (PDT) Received: from localhost ([::1]:47358 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZI1bv-00035O-BL; Wed, 22 Jul 2015 14:31:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Wed, 22 Jul 2015 21:31:31 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:3 Message-ID: <076.c8b08bec811b3c3023c89b7709c611cb@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150722213131.BFF351B2E5F@ietfa.amsl.com> Resent-Date: Wed, 22 Jul 2015 14:31:31 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA 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, 22 Jul 2015 21:31:33 -0000 #83: CT should mandate the use of deterministic ECDSA Changes (by eranm@google.com): * status: new => closed * resolution: => needs-review -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: needs-review Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Jul 22 14:45:23 2015 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 D441E1B2F28 for ; Wed, 22 Jul 2015 14:45:22 -0700 (PDT) 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 m2s2Zj7LRs6u for ; Wed, 22 Jul 2015 14:45:21 -0700 (PDT) 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 8958D1B2F26 for ; Wed, 22 Jul 2015 14:45:21 -0700 (PDT) Received: from localhost ([::1]:48788 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZI1pF-0000n5-Ha; Wed, 22 Jul 2015 14:45:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com X-Trac-Project: trans Date: Wed, 22 Jul 2015 21:45:17 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:8 Message-ID: <079.128ceac9ab06831c354ab16201d35255@tools.ietf.org> References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate 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, 22 Jul 2015 21:45:23 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate Changes (by eranm@google.com): * status: closed => reopened * resolution: fixed => Comment: Ben, I note that the github commit you link to only fix spelling of precertificates, not adopting Rob's proposal, is that intentional? -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: reopened Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Jul 23 01:15:31 2015 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 BF2AB1A8AAB for ; Thu, 23 Jul 2015 01:15:29 -0700 (PDT) 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 DmM1hlDiS6Ki for ; Thu, 23 Jul 2015 01:15:29 -0700 (PDT) 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 EF7A51A8AA6 for ; Thu, 23 Jul 2015 01:15:27 -0700 (PDT) Received: from localhost ([::1]:33777 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIBf3-0004mo-Qx; Thu, 23 Jul 2015 01:15:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 08:15:25 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/93 Message-ID: <056.71dd535ebe9cf2cdbc78c1faaa861fac@tools.ietf.org> X-Trac-Ticket-ID: 93 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723081527.EF7A51A8AA6@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 01:15:27 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: [Trans] [trans] #93 (client-behavior): Monitor description: Inconsistency between intro and section 5.4 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, 23 Jul 2015 08:15:29 -0000 #93: Monitor description: Inconsistency between intro and section 5.4 The introduction vaguely describes what monitors are doing (observing that a log is consistent, detection of mis-issued certificates on behalf of site owners). It should be more firm about the monitor's roles and it should be reflected more in-depth in section 5.4. Section 5.4 should mandate checking for mis-issued certificates by monitors (rather than an option - it's now a MAY). -- -------------------------+------------------------------------------------- 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 Thu Jul 23 01:22:55 2015 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 206871A8A1D for ; Thu, 23 Jul 2015 01:22:55 -0700 (PDT) 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 AfHt1ImjLWVx for ; Thu, 23 Jul 2015 01:22:54 -0700 (PDT) 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 413821A8A92 for ; Thu, 23 Jul 2015 01:22:54 -0700 (PDT) Received: from localhost ([::1]:35704 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIBmG-0000SA-Ma; Thu, 23 Jul 2015 01:22:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 08:22:52 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/94 Message-ID: <056.62dbdd537b258354f43bc615afe9cf9d@tools.ietf.org> X-Trac-Ticket-ID: 94 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723082254.413821A8A92@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 01:22:54 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: [Trans] [trans] #94 (client-behavior): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 08:22:55 -0000 #94: Fetching of inclusion proofs: Why and when are clients expected to do this? The introduction implies that clients asynchronously check for inclusion proofs. A rough suggestion by Steve Kent: "If clients check for the presence of SCTs, this is a good start because gives them some confidence the certificate is logged if the log is behaving. They can gain additional confidence by demanding an inclusion proof. We recognise it puts additional burden on clients" We should also point out that a client directly contacting the log to request an inclusion proof discloses private information to the log (the website the client has visited) and so other, indirect methods of contacting the log may be required. -- -------------------------+------------------------------------------------- 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 Thu Jul 23 01:43:27 2015 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 2FFD81A8AF3 for ; Thu, 23 Jul 2015 01:43:26 -0700 (PDT) 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 DbSE0KOBleDU for ; Thu, 23 Jul 2015 01:43:25 -0700 (PDT) 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 1CCC11A8788 for ; Thu, 23 Jul 2015 01:43:25 -0700 (PDT) Received: from localhost ([::1]:43643 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIC68-0000aS-Rt; Thu, 23 Jul 2015 01:43:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 08:43:24 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/95 Message-ID: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-Trac-Ticket-ID: 95 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: <20150723084325.1CCC11A8788@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 01:43:25 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #95 (client-behavior): The response size to get-entries should be a part of the log metadata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 08:43:26 -0000 #95: The response size to get-entries should be a part of the log metadata Section 4.7 says logs MAY restrict the number of entries that can be retrieved. It should be a part of the log's metadata so clients can know it ahead of time. -- -------------------------+------------------------------------------------- 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 Thu Jul 23 01:45:47 2015 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 5B18A1A906B for ; Thu, 23 Jul 2015 01:45:46 -0700 (PDT) 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 O--bBaEdZacB for ; Thu, 23 Jul 2015 01:45:45 -0700 (PDT) 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 A66A71A8F43 for ; Thu, 23 Jul 2015 01:45:38 -0700 (PDT) Received: from localhost ([::1]:44069 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIC8I-0006aS-1j; Thu, 23 Jul 2015 01:45:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 08:45:37 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:1 Message-ID: <071.e1a4f43753276ed498bc8a7195e493e5@tools.ietf.org> References: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723084538.A66A71A8F43@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 01:45:38 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #95 (rfc6962-bis): The response size to get-entries should be a part of the log metadata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 08:45:46 -0000 #95: The response size to get-entries should be a part of the log metadata Changes (by eranm@google.com): * component: client-behavior => rfc6962-bis Comment: Note that this does limit the log's ability to dynamically choose the limit. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 01:53:33 2015 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 53A921AC3ED for ; Thu, 23 Jul 2015 01:53:31 -0700 (PDT) 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 dWkhukh7Wt5A for ; Thu, 23 Jul 2015 01:53:30 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FD41A8783 for ; Thu, 23 Jul 2015 01:53:09 -0700 (PDT) Received: by ykay190 with SMTP id y190so214097400yka.3 for ; Thu, 23 Jul 2015 01:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=8LVZkqgYXmIOwUj+fGS3psqkke65AwRLpDcpUs33Iwk=; b=YLLu2bZpHO2RfXw0RHCg2SFh91KuG02onz/ufD65zSgXK37J2NXJz/FTKJYWrCKYxC yzT0D4I4njD+wBFEm6eWbcW1ps/qio82niXDN2hsBlIgf3X037Kn3ZCysR11EYCF//Yz v0obu+ZQZmfB9zQWLj8JdGAWUsRRqfXU2XSz+z5+1V8shF5JyR+3pNv892YzBms1U00d t5xyU3R9MpbmUTyZU7BvuUtFjt7prlXlwjckSCFtGD7s233FV4KdNFt+NTe/EW4ZIKjH lQNZx9//KYfsIhHAjrBD33XWOv+aZeHsHg5NBc2biDU+e76nLtSI4Gp3wHR8AXJnlQiL S4ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=8LVZkqgYXmIOwUj+fGS3psqkke65AwRLpDcpUs33Iwk=; b=PeLLVsNhiCg4kFgRbkVsW934lQZlaAu1Ns1WO09lpsnwwqkJ0rZaFDH5/qTAgg/PB4 avLDmdoy5D1WUOZBCrUcRyQhZja2JB8ZEdc/T0RzQrRwxDqCm/IeVXtTRNVJpRFPDesx fk7mG46KGZPagtlUjM/jFzhwVpMODBJG0C5kfw0ZscCWHAfXRKOQgyTMVH14p14yDJKk GHb/TC3RzBM8E7EHp++gH1bJ4QqY/SqHz1EzeJqoohiA5v72ERDjfwfxwwp+PsFLmmgy 6kT2E+of+mb35owfW7OnKnf1e1y1k1pIJJKxLFfo4v4639DSuBstPG7VMMVi88VS3Ste TZ2Q== X-Gm-Message-State: ALoCoQnTNw5bi9PIC7r8Jll3Zu9Ay2pcqDziKGA4i3D4lAILJVITitbiKUz+6hzQvOLZtRfPvKd6 X-Received: by 10.13.255.2 with SMTP id p2mr6828820ywf.149.1437641589214; Thu, 23 Jul 2015 01:53:09 -0700 (PDT) MIME-Version: 1.0 From: Ben Laurie Date: Thu, 23 Jul 2015 08:52:59 +0000 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0888f63dbbfd051b870468 Archived-At: Subject: [Trans] Adopt Gossip I-D? 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, 23 Jul 2015 08:53:31 -0000 --94eb2c0888f63dbbfd051b870468 Content-Type: text/plain; charset=UTF-8 The gossip I-D is in a pretty good state from my POV, though obviously work is still required. If I've not missed anything, I believe it is not currently a WG document. Can I suggest we adopt it? --94eb2c0888f63dbbfd051b870468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The gossip I-D is in a pretty good state from my POV, thou= gh obviously work is still required.

If I've not mis= sed anything, I believe it is not currently a WG document. Can I suggest we= adopt it?

--94eb2c0888f63dbbfd051b870468-- From nobody Thu Jul 23 01:55:02 2015 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 74C1B1AC3DF for ; Thu, 23 Jul 2015 01:55:01 -0700 (PDT) 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 tbkcR5JN25t4 for ; Thu, 23 Jul 2015 01:55:00 -0700 (PDT) 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 82D0C1AC3F8 for ; Thu, 23 Jul 2015 01:54:29 -0700 (PDT) Received: from localhost ([::1]:44853 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZICGp-0001It-Uk; Thu, 23 Jul 2015 01:54:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 08:54:27 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/96 Message-ID: <056.5d271b279cc61b979e6443dc0948e24a@tools.ietf.org> X-Trac-Ticket-ID: 96 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723085429.82D0C1AC3F8@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 01:54:29 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: [Trans] [trans] #96 (rfc6962-bis): Metadata: Should it be dynamic? 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, 23 Jul 2015 08:55:01 -0000 #96: Metadata: Should it be dynamic? Logs could advertise parts of the metadata (for example, the MMD) on a well-known location, sign it and have clients fetch it prior to other requests from the log. This means certain parameters could change frequently and logs would know exactly how clients should behave when metadata changes. The downside is that we would have to consider each piece of metadata and the implications of allowing it to change dynamically. For example, if the log is allowed to dynamically change the MMD, what happens to STHs issued "at the seams" ? Does the old MMD apply for them? the new one? *not* advertising parts of the metadata directly by the logs themselves mean logs have no way of knowing which version of the metadata clients have (as it would depend on external update mechanisms such as browser updates). A way to prevent this uncertainty is to declare the metadata immutable - i.e. a log roll-over would be necessary to change any of the log's parameters. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 02:06:15 2015 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 F41741AC3F8 for ; Thu, 23 Jul 2015 02:06:14 -0700 (PDT) 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 VWsT6VXGhmLn for ; Thu, 23 Jul 2015 02:06:14 -0700 (PDT) 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 23AA91A00F0 for ; Thu, 23 Jul 2015 02:06:14 -0700 (PDT) Received: from localhost ([::1]:48604 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZICSC-0001q1-9S; Thu, 23 Jul 2015 02:06:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 09:06:12 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/96#comment:1 Message-ID: <071.139420386221cc6aea4536fab0441820@tools.ietf.org> References: <056.5d271b279cc61b979e6443dc0948e24a@tools.ietf.org> X-Trac-Ticket-ID: 96 In-Reply-To: <056.5d271b279cc61b979e6443dc0948e24a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150723090614.23AA91A00F0@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 02:06:14 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: Re: [Trans] [trans] #96 (rfc6962-bis): Metadata: Should it be dynamic? 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, 23 Jul 2015 09:06:15 -0000 #96: Metadata: Should it be dynamic? Changes (by benl@google.com): * milestone: => review Comment: We've already discussed this, I feel sure, and the general point is that allowing logs to manipulate their own metadata is dangerous, as you state. That's why the I-D says its distribution is out of scope. As you know, in practice, Chrome defines its own log metadata, and that is what clients use. I imagine this will be the general pattern. I propose this is resolved as wontfix. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 02:16:25 2015 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 2C79A1A1B5D for ; Thu, 23 Jul 2015 02:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.848 X-Spam-Level: X-Spam-Status: No, score=0.848 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_62=0.6, 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 Cn1V71jQX9_k for ; Thu, 23 Jul 2015 02:16:19 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 73A5C1A003B for ; Thu, 23 Jul 2015 02:16:19 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6N9GDhT004035 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Jul 2015 11:16:13 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t6N9GAce020517 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2015 09:16:12 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1437642972; bh=u1kH0kBmc/nju2QmE/lDMujxqN6KUPCPLKZaqZmtKJM=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=teO0nqIayNFDRDTLnHsA4FpJ4r6xZOzU250InKaB5HaSjJOZe/ETEg6bqIC2hcX7D vb79xHtBlGBd+6yz8YFWxqhoJX2i/rlt/ubkVWIqojO3UbG/F4tBq3eKJn8Af2zLJ/ UsY7nXX2HNtLjU0o4PFrXmiOMMdeEpKMvjJatGf8= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 23 Jul 2015 11:20:51 +0200 From: Linus Nordberg To: Ben Laurie Organization: NORDUnet A/S References: <874mkvclg5.fsf@totally-fudged-out-message-id> Date: Thu, 23 Jul 2015 11:16:05 +0200 In-Reply-To: <874mkvclg5.fsf@totally-fudged-out-message-id> (Linus Nordberg's message of "(unknown date)") Message-ID: <87zj2nb5ey.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aOTJgdoJ - a16f79ea7578 - 20150723 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Review of draft-linus-trans-gossip-ct-02 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, 23 Jul 2015 09:16:23 -0000 Ben Laurie wrote Mon, 20 Jul 2015 13:51:33 +0100: | Comments in {} when in quoted sections. | | "2. Overview | | Public append-only untrusted {verifiable is perhaps a better word} logs " I kind of like "untrusted" and it seems like 6962 and 6962bis do too. But if they're changing, I guess we should consider changing here too. | Diagram in section 3 appears to omit SCTs delivered over OCSP. Fixed in 03-dev (branch master in git repo at [0]). [0] https://github.com/ln5/draft-linus-trans-gossip-ct | Also, the line from CA to Website is labelled "Cert and SCT" but the SCT | may be omitted. OK. Adding brackets around "& SCT". (We need a better notation for optional.) | Section 5 | | "Trusted Auditor Stream, HTTPS clients communicating directly with | trusted CT auditors/monitors sharing SCTs, certificate chains and | STHs. {Slightly confused: section 4 mentions auditors and monitors | using this channel between themselves?}" Addressed in 03-dev: # Who gossips {#who} - HTTPS clients and servers (SCT Feedback and STH Pollination) - HTTPS servers and CT auditors (SCT Feedback) - CT auditors and monitors (Trusted Auditor Relationship) Additionally, some HTTPS clients may engage with an auditor who they trust with their privacy: - HTTPS clients and CT auditors (Trusted Auditor Relationship) | 5.1 | | " Note that clients | send the same SCTs and chains to servers multiple times with the | assumption that a potential man-in-the-middle attack eventually will | cease so that an honest server will receive collected malicious SCTs | and certificate chains. {note that if an SCT is sent over a channel that | used an SCT from the same log, then that new SCT can replace the existing | one for reporting - bad behaviour is still detected - i.e. an SCT can be | considered "sent" if it is sent over a channel validated by the same log}" | | 5.1.1 | | " The client MUST | send to the server the ones in the store that are for that server and | were not received from that server. {comment about "sent SCTs" applies}" 03-dev hsa the following. The client MUST NOT send the same set of SCTs to the same server more often than TBD. [benl: "sent to the server" only really counts if the server presented a valid SCT in the handshake and the certificate is known to be unrevoked (which will be hard for a MitM to sustain)] Does this capture it? (For purposes of tracking your requested adddition, not resolving it.) | "An SCT MUST NOT be sent to any other HTTPS server than one serving | the domain that the certificate signed by the SCT refers to.{Not all TLS | clients care about privacy: e.g. crawlers, so this MUST NOT is too strong}" I see. Wonder how we could express that. Should we try to differentiate between browsers with real people using them and other clients? Or bring in "user consent"? | "First, the server | recieving the SCT would learn about other sites visited by the HTTPS | client{if SCTs are gossipped then this is clearly untrue: however, I | agree that it is hard to avoid some kind of privacy leak}. " It is true for the first N clients gossiping was my first reaction. Then there was an interesting discussion off list about if either of those claims could be proven correct through simulation. Without more data my position is that we don't know and should err on the side of safety and not gossip SCTs. Not counting SCT Feedback here. That we should do. | "Secondly, auditors or monitors recieving SCTs from the HTTPS | server would learn information about the other HTTPS servers visited | by its clients.{ditto}" See above. | "If the HTTPS client has configuration options for not sending cookies | to third parties, SCTs MUST be treated as cookies with respect to | this setting.{don't understand - you already banned sending to third | parties}" This is for local attacks, i.e. someone digging through the local store. Should probably expand. Added a TODO for now. | "The data sent in the POST is defined in Section 5.1.3.{what if the POST | fails, as it obviously will for most servers initially?}" Then no SCT Feedback is happening. Do we need to add text? | " 3. if the leaf cert is not for a domain that the server is | authoritative for, the SCT MUST be discarded {only true if you ban | SCT gossip}" Yes. | " It's important to note | that the check must be on pairs of SCT and chain in order to catch | different chains accompanied by the same SCT. [XXX why is this | important?]{given that logs do _not_ have to log multiple chains, I | suspect this is actually not important}" This could be of interest to the operator of the web site. Creating more incentive for them to play along is probably valuable. It can be debated whether it's worth it or not. | " Note that an HTTPS server MAY perform a certificate chain validation | on a submitted certificate chain, and if it matches a trust root | configured on the server (but is otherwise unknown to the server), | the HTTPS server MAY store the certificate chain and MAY choose to | store any submitted SCTs even if they are unable to be verified. The | risk of spamming and denial of service can be mitigated by | configuring the server with all known acceptable certificates (or | certificate hashes). {Confused by this, surely the point is to find | certs/SCTs the server does not expect?}" I think we thought this would help catching an SCT even if it doesn't verify correctly by imposing some limits on the cert chain that came with it. | 5.1.3 | | " * sct_data: An array of objects consisting of the base64 | representation of the binary SCT data as defined in [RFC6962] | Section 3.2. {SCTs may be in the certs, so should they be | replicated here or not?}" | | " The 'x509_chain' element MUST contain at{typo} the leaf certificate and | the | full chain to a known root." Fixed. | 5.2 | | " o Logs cannot issue STHs too frequently. This is restricted to 1 | per hour. {probably should refer to 6962-bis for this restriction}" | | Also in 5.2, note that servers could function as their own auditors. Would be good to mention that somewhere, yes. | 5.2.2 | | "After retrieving the consistency proof to the most recent STH, they | SHOULD pollinate this new STH among participating HTTPS Servers {and may | safely discard the older STH}. " Unless it should be gossiped some more? We only know that it's correct with regard to the particular view of the log we're being served. I don't think we've decided when to stop gossiping about a particular STH yet. | 5.2.3 | | " o sths - an array of 0 or more fresh STH objects [XXX recently | collected] from the log associated with log_id. Each of these | objects consists of {note that we've moved to binary format for SCTs | in 6962-bis}" Hmm. We've been looking at RFC6962 so far but that's not how to do it I guess. I'll read up on 6962bis and change this draft accordingly. | 6.1.1 | | " Therefore, a | client with an SCT for a given server should transmit that | information in only two channels: to a server associated with the SCT | itself; and to a trusted CT auditor, if one exists.{only if the client | cares about privacy}" See comment above ("I see. Wonder how we could express that.[...]") | 6.1.4 | | "This is similar to | the fingerprinting attack described in Section 6.1.2, but it is | mitigated by the following factors: {mention rate limit?}" The limitation on how often a log can issue an STH? Yes, we should look over this section in the light of that change. | 6.1.6 | | "The log's inability to | provide either proof will not be externally cryptographically- | verifiable, as it may be indistinguishable from a network error. | {note that anyone who sees the whole log can independently prove | inconsistency/non-inclusion}" That's a monitor, isn't it? From nobody Thu Jul 23 02:19:52 2015 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 DC5D71AC405 for ; Thu, 23 Jul 2015 02:19:51 -0700 (PDT) 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 ZwN9AomcDUNf for ; Thu, 23 Jul 2015 02:19:50 -0700 (PDT) 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 E5E5F1A8756 for ; Thu, 23 Jul 2015 02:19:50 -0700 (PDT) Received: from localhost ([::1]:50571 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZICfO-0007pg-9f; Thu, 23 Jul 2015 02:19:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 09:19:50 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:2 Message-ID: <071.d89581d27373926c935925fea3620bd1@tools.ietf.org> References: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723091950.E5E5F1A8756@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 02:19:50 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #95 (rfc6962-bis): The response size to get-entries should be a part of the log metadata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:19:52 -0000 #95: The response size to get-entries should be a part of the log metadata Comment (by benl@google.com): Disagree. Whilst I can see there might be some slight advantage to the client, what would we do if the server broke the promise, and why? Also, response size limit may be based on dynamic considerations (load, caching, size of responses, etc). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 02:40:14 2015 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 C347B1A0382 for ; Thu, 23 Jul 2015 02:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RlYkSvG8gs6H for ; Thu, 23 Jul 2015 02:40:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4F41A8F4A for ; Thu, 23 Jul 2015 02:40:09 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:49677 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZICz0-0007XI-8w; Thu, 23 Jul 2015 05:40:06 -0400 To: trans issue tracker , draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com References: <056.5d271b279cc61b979e6443dc0948e24a@tools.ietf.org> <071.139420386221cc6aea4536fab0441820@tools.ietf.org> From: Stephen Kent Message-ID: <55B0B674.8090904@bbn.com> Date: Thu, 23 Jul 2015 11:40:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <071.139420386221cc6aea4536fab0441820@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] #96 (rfc6962-bis): Metadata: Should it be dynamic? 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, 23 Jul 2015 09:40:12 -0000 There are two types of log metadata. Some if the data is analogous to trust anchor info and thus distributing it to TLS clients using the same (not standardized) browser vendor mechanisms makes sense. (This does, though, raise an issue about how non-browser client acquire this info; Monitors and Auditors are not necessarily products of vendors and thus there may not be the same infrastructure to distribute this sort of data.) Other log metadata (e.g., MMD and STH frequency) is less like trust anchor info and it could be distributed by having a signed, time-stamped data structure posted at a known location associated with the log. A potential benefit of this model is that a log operator can know that if it changes these parameters, all clients are able to acquire the new info at the same time. If one relies on an unspecified distribution mechanism for these parameters, a log operator cannot know when all clients have received the new info. That uncertainty might cause operational problems. So, the title for this issuer is not really whether ALL metadata should be dynamic, but rather whether some of it should be. Steve > #96: Metadata: Should it be dynamic? > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > We've already discussed this, I feel sure, and the general point is that > allowing logs to manipulate their own metadata is dangerous, as you state. > That's why the I-D says its distribution is out of scope. > > As you know, in practice, Chrome defines its own log metadata, and that is > what clients use. I imagine this will be the general pattern. > > I propose this is resolved as wontfix. > From nobody Thu Jul 23 02:44:48 2015 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 38CCD1A0382 for ; Thu, 23 Jul 2015 02:44:47 -0700 (PDT) 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 6F1veAu8HNw9 for ; Thu, 23 Jul 2015 02:44:46 -0700 (PDT) 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 C3F2C1A6FCF for ; Thu, 23 Jul 2015 02:44:45 -0700 (PDT) Received: from localhost ([::1]:52434 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZID3V-0005iv-J1; Thu, 23 Jul 2015 02:44:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 09:44:45 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:4 Message-ID: <076.71723f92248bba0b1294c30ad6cee954@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150723094445.C3F2C1A6FCF@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 02:44:45 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA 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, 23 Jul 2015 09:44:47 -0000 #83: CT should mandate the use of deterministic ECDSA Changes (by eranm@google.com): * status: closed => reopened * resolution: needs-review => -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 02:45:01 2015 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 8DB061A0211 for ; Thu, 23 Jul 2015 02:45:00 -0700 (PDT) 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 10Rh4jDrermB for ; Thu, 23 Jul 2015 02:44:59 -0700 (PDT) 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 AE0771A1A94 for ; Thu, 23 Jul 2015 02:44:58 -0700 (PDT) Received: from localhost ([::1]:52454 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZID3i-0005n5-G4; Thu, 23 Jul 2015 02:44:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 09:44:58 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:5 Message-ID: <076.95e58dfd2212ad8f139083ab42c37646@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150723094458.AE0771A1A94@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 02:44:58 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA 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, 23 Jul 2015 09:45:00 -0000 #83: CT should mandate the use of deterministic ECDSA Changes (by eranm@google.com): * status: reopened => closed * resolution: => needs-review -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: needs-review Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 02:48:25 2015 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 C5E1F1AC3EF for ; Thu, 23 Jul 2015 02:48:23 -0700 (PDT) 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 eggcUpD6f-Ei for ; Thu, 23 Jul 2015 02:48:22 -0700 (PDT) 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 825F21A854B for ; Thu, 23 Jul 2015 02:48:22 -0700 (PDT) Received: from localhost ([::1]:52713 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZID70-0001TJ-9A; Thu, 23 Jul 2015 02:48:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 09:48:22 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:3 Message-ID: <071.a2060239573c0536ee71409a04201c60@tools.ietf.org> References: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723094822.825F21A854B@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 02:48:22 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #95 (rfc6962-bis): Should the response size to get-entries be a part of the log metadata? (was: The response size to get-entries should be a part of the log metadata) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:48:23 -0000 #95: Should the response size to get-entries be a part of the log metadata? Comment (by eranm@google.com): Original suggestion was by Steve Kent. I agree with some of Ben's comments - as a compromise we can suggest a default of X entries that would generate Y amount of traffic per request (as an implementation guideline), allowing logs to deviate depending on their loads or implementations. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 02:54:07 2015 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 BA43F1A000E for ; Thu, 23 Jul 2015 02:54:06 -0700 (PDT) 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 2gOdtXbAgktq for ; Thu, 23 Jul 2015 02:54:05 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2F51A000D for ; Thu, 23 Jul 2015 02:54:05 -0700 (PDT) Received: by ykay190 with SMTP id y190so215076849yka.3 for ; Thu, 23 Jul 2015 02:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=GNOBnfx5WafRFG/E/LE4HC1QGHerLJ7TqVeO6EbSMPQ=; b=VzNLwb3a7AzNasNqFCMCjYyPWON+sP+9fPIbunS0TqdZ/Vq/BM1NSjoy4PajHihdkw w2JYu5+kKqa3tzw5BL5Ytp+/rV8/HilywkvGUV0aTBbVtemWVAmvFmLkKiIEAelNtMCm H+UWYcT5Ge+g/bvlc3ELlLB8tdTbJyG3Qc3FZlP4cOx81RGSOfjQ6vTHYfuXBiNtXfAl 3dou3YYqgSdAHMqLF7+EJ05orKU/pxbvw5izi7ukh0q+WPdThN3MIvzI2IiqSV+uTpWJ 5tSBWeiD8FP2Slawy5koGM/S35HjGlTjivk8YQUVbQBNJukiNxcEPwsKdaR9o0Lg0Qw+ dVZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=GNOBnfx5WafRFG/E/LE4HC1QGHerLJ7TqVeO6EbSMPQ=; b=HnJDONWT68YU9nVYfIIbyQewMUZxhKo9MrrFEduPZZQ/VA/B2KUnB6OnQdRASLAK1H AbmYX720WY1wfBA0MSzHhQ7JCtUKcTN6j5d3co7YWDjPe3GzRJoMkcZxvm5f/IC7M3LY W8P5Uo6iJSU21v7h52U8+tcMDle887FpxtBt+iPsTSRveKJLiguOqBB+4hsFV/xn5VjM fOqLpXILeN6FLLriT5ky5HvnBvxHprbJ3W8aeEE+SjsTfoBZvZMCfToAPzhoAN3OqaiM mcyvpjepEYai0XG6hplSljzXLzRv4jVqwwi/39ZepKaM4/Bwf1ooJfCkZCLNYEV0e1rY VjDQ== X-Gm-Message-State: ALoCoQl4nLvHCghRO5uDd4tSJDHQOPYu59G7P8Srw6706kZMwtnFYE2f2WPJ4aAnvxp0eXXIwLFR X-Received: by 10.13.249.198 with SMTP id j189mr7194130ywf.170.1437645244967; Thu, 23 Jul 2015 02:54:04 -0700 (PDT) MIME-Version: 1.0 References: <874mkvclg5.fsf@totally-fudged-out-message-id> <87zj2nb5ey.fsf@nordberg.se> In-Reply-To: <87zj2nb5ey.fsf@nordberg.se> From: Ben Laurie Date: Thu, 23 Jul 2015 09:53:55 +0000 Message-ID: To: Linus Nordberg Content-Type: multipart/alternative; boundary=94eb2c080b9623ecfc051b87dec5 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Review of draft-linus-trans-gossip-ct-02 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, 23 Jul 2015 09:54:06 -0000 --94eb2c080b9623ecfc051b87dec5 Content-Type: text/plain; charset=UTF-8 > > | 5.2.2 > | > | "After retrieving the consistency proof to the most recent STH, they > | SHOULD pollinate this new STH among participating HTTPS Servers {and > may > | safely discard the older STH}. " > > Unless it should be gossiped some more? We only know that it's correct > with regard to the particular view of the log we're being served. I > don't think we've decided when to stop gossiping about a particular STH > yet. > The point is that the newer STH includes the older one (i.e. it proves the log contains all the things the older one proved it contained), so there's no value in retaining the older STH... | 6.1.6 > | > | "The log's inability to > | provide either proof will not be externally cryptographically- > | verifiable, as it may be indistinguishable from a network error. > | {note that anyone who sees the whole log can independently prove > | inconsistency/non-inclusion}" > > That's a monitor, isn't it? > > If we define everyone who keeps a copy of the log as a monitor, then yes. Intuitively, a mirror is not a monitor, but still has a complete copy. --94eb2c080b9623ecfc051b87dec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= | 5.2.2
|
| "After retrieving the consistency proof to the most recent STH, they=
|=C2=A0 =C2=A0 SHOULD pollinate this new STH among participating HTTPS Serv= ers {and may
| safely discard the older STH}. "

Unless it should be gossiped some more? We only know that it's correct<= br> with regard to the particular view of the log we're being served. I
don't think we've decided when to stop gossiping about a particular= STH
yet.

The point is that the newer STH in= cludes the older one (i.e. it proves the log contains all the things the ol= der one proved it contained), so there's no value in retaining the olde= r STH...
=C2=A0
| 6.1.6
|
| "The log's inability to
|=C2=A0 =C2=A0 =C2=A0 =C2=A0provide either proof will not be externally cry= ptographically-
|=C2=A0 =C2=A0 =C2=A0 =C2=A0verifiable, as it may be indistinguishable from= a network error.
| {note that anyone who sees the whole log can independently prove
| inconsistency/non-inclusion}"

That's a monitor, isn't it?

If we define everyone who keeps a copy of the log as = a monitor, then yes. Intuitively, a mirror is not a monitor, but still has = a complete copy.

=C2=A0
--94eb2c080b9623ecfc051b87dec5-- From nobody Thu Jul 23 03:07:57 2015 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 A0B581A01FA for ; Thu, 23 Jul 2015 03:07:55 -0700 (PDT) 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 BcCUnBnTjBXm for ; Thu, 23 Jul 2015 03:07:54 -0700 (PDT) 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 ACD5C1A026A for ; Thu, 23 Jul 2015 03:07:51 -0700 (PDT) Received: from localhost ([::1]:55093 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIDPr-0007ZL-Ds; Thu, 23 Jul 2015 03:07:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 10:07:51 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:6 Message-ID: <076.71eb0f7d67dce0c5dfef0dab54ad645b@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150723100751.ACD5C1A026A@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 03:07:51 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA 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, 23 Jul 2015 10:07:55 -0000 #83: CT should mandate the use of deterministic ECDSA Changes (by eranm@google.com): * status: closed => reopened * resolution: needs-review => * milestone: => review -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 03:19:07 2015 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 7308C1A01D6 for ; Thu, 23 Jul 2015 03:19:06 -0700 (PDT) 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 blXR1_Irukt7 for ; Thu, 23 Jul 2015 03:19:04 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958611A0107 for ; Thu, 23 Jul 2015 03:19:03 -0700 (PDT) Received: (qmail 14421 invoked by uid 1004); 23 Jul 2015 10:19:01 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 23 Jul 2015 11:19:01 +0100 Received: (qmail 1850 invoked by uid 1000); 23 Jul 2015 10:19:01 -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, 23 Jul 2015 11:19:01 +0100 To: Stephen Kent , trans@ietf.org References: <55AD15E9.6020807@comodo.com> <55AF9230.6090909@bbn.com> From: Rob Stradling Message-ID: <55B0BF94.9010702@comodo.com> Date: Thu, 23 Jul 2015 11:19:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AF9230.6090909@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] #70 (rfc6962-bis): STHspecneedstodefinetop-levelextension syntax 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, 23 Jul 2015 10:19:06 -0000 On 22/07/15 13:53, Stephen Kent wrote: >> > Given the history of browser behavior wrt cert revocation status >> > checking, this is not a surprising perspective. >> >> I am a bit surprised, actually. Some browsers no longer perform >> out-of-band revocation checks by contacting CA revocation servers >> directly, but they do still process revocation information passed >> in-band (i.e. OCSP Stapling). > > yes, some do. Having a server pass the OCSP data is analogous to having > it pass an SCT, and we've been told that it will take too long for that > to happen, hence the embedded SCT in a cert feature of CT. > >> SCTs are passed in-band. > > Yes, but 6962-bis says that TLS clients MAY contact a log to get a proof > for the SCT, and the gossip proposal relies on clients contacting logs > to acquire STHs. So, ... I think there is value in a TLS client verifying the SCTs supplied in-band in the TLS handshake even if that client doesn't also contact the log out-of-band to fetch and verify STHs and/or inclusion proofs and/or consistency proofs. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jul 23 03:28:13 2015 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 42D151A1A32 for ; Thu, 23 Jul 2015 03:28:12 -0700 (PDT) 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 AZ2mbnKe2yU1 for ; Thu, 23 Jul 2015 03:28:10 -0700 (PDT) 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 485AA1A0370 for ; Thu, 23 Jul 2015 03:26:54 -0700 (PDT) Received: from localhost ([::1]:60661 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIDiH-0004Nk-1O; Thu, 23 Jul 2015 03:26:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 10:26:53 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:7 Message-ID: <076.aba703bfda736cfe92dccace9d085e11@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150723102654.485AA1A0370@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 03:26:54 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA 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, 23 Jul 2015 10:28:12 -0000 #83: CT should mandate the use of deterministic ECDSA Comment (by benl@google.com): Not sure this is ready for closing: the question remains "what about RSA?". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 03:28:52 2015 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 CB1011A0149 for ; Thu, 23 Jul 2015 03:28:51 -0700 (PDT) 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 WoJEnmMHJjBW for ; Thu, 23 Jul 2015 03:28:51 -0700 (PDT) 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 9B81D1A0461 for ; Thu, 23 Jul 2015 03:28:02 -0700 (PDT) Received: from localhost ([::1]:60734 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIDjH-00017J-94; Thu, 23 Jul 2015 03:27:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 10:27:55 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/93#comment:2 Message-ID: <071.39399ef768292680f44d37803b9a7141@tools.ietf.org> References: <056.71dd535ebe9cf2cdbc78c1faaa861fac@tools.ietf.org> X-Trac-Ticket-ID: 93 In-Reply-To: <056.71dd535ebe9cf2cdbc78c1faaa861fac@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, benl@google.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723102802.9B81D1A0461@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 03:28:02 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org, kent@bbn.com 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 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 10:28:51 -0000 #93: Monitor description: Inconsistency between intro and section 5.4 Changes (by benl@google.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 03:28:59 2015 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 305E71A8843 for ; Thu, 23 Jul 2015 03:28:58 -0700 (PDT) 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 MEJ0ewbmG7er for ; Thu, 23 Jul 2015 03:28:56 -0700 (PDT) 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 C465C1A8881 for ; Thu, 23 Jul 2015 03:28:04 -0700 (PDT) Received: from localhost ([::1]:60747 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIDjQ-0002FT-AL; Thu, 23 Jul 2015 03:28:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 10:28:04 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/83#comment:8 Message-ID: <076.e6882818c104327dacbe31d9782523e4@tools.ietf.org> References: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <061.2bfddb2a99fba55e98e48bb1cf4767e9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150723102804.C465C1A8881@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 03:28:04 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #83 (rfc6962-bis): CT should mandate the use of deterministic ECDSA 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, 23 Jul 2015 10:28:58 -0000 #83: CT should mandate the use of deterministic ECDSA Changes (by eranm@google.com): * milestone: review => milestone1 Comment: My bad - that's exactly what I was looking at and don't have an answer yet. (removing 'review' milestone) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: milestone1 Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 03:29:59 2015 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 3900E1A1AE1 for ; Thu, 23 Jul 2015 03:29:57 -0700 (PDT) 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 HohbhrfTkoI6 for ; Thu, 23 Jul 2015 03:29:55 -0700 (PDT) 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 ABB8A1A000E for ; Thu, 23 Jul 2015 03:29:10 -0700 (PDT) Received: from localhost ([::1]:60809 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIDkS-0007IW-85; Thu, 23 Jul 2015 03:29:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 10:29:08 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/94#comment:1 Message-ID: <071.92c1c6b2131102525cfceb5c1f5404e9@tools.ietf.org> References: <056.62dbdd537b258354f43bc615afe9cf9d@tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <056.62dbdd537b258354f43bc615afe9cf9d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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: <20150723102910.ABB8A1A000E@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 03:29:10 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 10:29:57 -0000 #94: Fetching of inclusion proofs: Why and when are clients expected to do this? Changes (by benl@google.com): * component: client-behavior => rfc6962-bis Comment: I note that this question is addressed in the gossip I-D, and perhaps is better left there? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 04:25:26 2015 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 764F41AC3E7 for ; Thu, 23 Jul 2015 04:25:21 -0700 (PDT) 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 YDYL8XbE0AuF for ; Thu, 23 Jul 2015 04:25:20 -0700 (PDT) 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 063F51A8A86 for ; Thu, 23 Jul 2015 04:25:09 -0700 (PDT) Received: from localhost ([::1]:37581 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIEca-0003D3-1w; Thu, 23 Jul 2015 04:25:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, dkg@fifthhorseman.net X-Trac-Project: trans Date: Thu, 23 Jul 2015 11:25:04 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:5 Message-ID: <067.d9c1ab684300e17b1d25b5d78cfc4ff0@tools.ietf.org> References: <052.0789019d9e32c9233f0440891ac5bb94@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <052.0789019d9e32c9233f0440891ac5bb94@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, benl@google.com, melinda.shore@gmail.com, dkg@fifthhorseman.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723112509.063F51A8A86@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 04:25:09 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4 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, 23 Jul 2015 11:25:21 -0000 #76: Normative client behavior specified in Section 3.4 Comment (by benl@google.com): I cannot act on this feedback - there are numerous messages from Steve Kent referring to normative client behaviour, none that I've reviewed have outstanding actions that I can find. The actual text referred to needs to be quoted in this ticket. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 04:30:37 2015 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 11BA01AC41D for ; Thu, 23 Jul 2015 04:30:35 -0700 (PDT) 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 2WoXFoY0fAa1 for ; Thu, 23 Jul 2015 04:30:28 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73211A9062 for ; Thu, 23 Jul 2015 04:30:27 -0700 (PDT) Received: by ykdu72 with SMTP id u72so216756107ykd.2 for ; Thu, 23 Jul 2015 04:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=Zg/08PUlYvMrbuFsAIFiiCC5tYy9jxfyIAcx0UgJyPg=; b=ns67VoJTLMWXSBmJNZ3Gzh8Bk0HppsITydHCFzxN/8F7jeIHWWHlEbueiVAC0YTR9L 0BRxKWQVJaEqWCq2uJsSa5T6xYhU3h+VrNwKEbW459lkdRWy+bX445sg6l+fIw+fVc9Y akffOzcz+3HAhg+PRqK8MGhwGCuwpBzGmyBsOZ5dozuecLGDi0GvbOJZ9ihif/YdX+S2 iWYdpz2AXDotuBAvdGNv4s+js+OzC4zWejcmHJtTW5pIV83X7GysEm22ZDTBVyfhbY9W dyyyZckyUbs9t4BFznc5my4qi6JYCKZSLiee8oCZ/dEZbPoCW1BxgQQxd2VJ1pz6CDuK SPuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=Zg/08PUlYvMrbuFsAIFiiCC5tYy9jxfyIAcx0UgJyPg=; b=AacnsVxe2jiyTiFqs+yeoVfFAi+bhKh8FTmvPXIPfnALsEl2OD98odqKd5vAbcW4IW PI4Y5AYJddYF3cE1UH7nYXAEH63Y0ckXIbLlCg0EGvUaMAF3c8/YmTodCKT06gqTACnw sM8J06ONV5rFzANzgb0xnJsP3xnBojcGeARrK6qeWTjFbFM0RPbYE6fAKcoJrwC15KmN DcKU9yVksx0Kv0BL6ZOC0V+p5HeDC0smUhoOXzeSh03dgs03+YBvJxJ7VvsHUlgtgxoU QTKZGucYjkDNCEBTZZb/bDOaSM6hUJ2szSHSuGis5sCY7DWTg9VsqGmub0q5WurTSIna izew== X-Gm-Message-State: ALoCoQkyP6GQ7MT79fgJIO7O5E3rKRZf9kU8W68hlR48P1yul80fRl4HJK50TzAYrlvHq0lzReKc X-Received: by 10.129.111.65 with SMTP id k62mr8032872ywc.88.1437651027117; Thu, 23 Jul 2015 04:30:27 -0700 (PDT) MIME-Version: 1.0 References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> <559ACA98.2040509@bbn.com> <559BF26F.4010407@bbn.com> In-Reply-To: <559BF26F.4010407@bbn.com> From: Ben Laurie Date: Thu, 23 Jul 2015 11:30:17 +0000 Message-ID: To: Stephen Kent , trans@ietf.org Content-Type: multipart/alternative; boundary=001a114901b4c8b3d7051b893637 Archived-At: Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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, 23 Jul 2015 11:30:35 -0000 --001a114901b4c8b3d7051b893637 Content-Type: text/plain; charset=UTF-8 On Tue, 7 Jul 2015 at 16:38 Stephen Kent wrote: > Ben, > > > A certificate not accompanied by an SCT is not CT compliant. > > This seems redundant: I would've thought that in general everything in > > an RFC only applies to things that are compliant with that RFC. But if > > the WG wants I don't really mind either way. > I prefer the wording I suggested because it emphasizes the status of the > cert relative > to this spec, rather than intimating any TLS client behavior. > > > > OK, I get your point here, and I am happy to go either way: > > > > a) Update TLS to require CT, or > that's not what I meant to suggest. I don't think CT is destined to become > a mandatory aspect of TLS; it's an optional feature. > > b) Update the I-D to say something like "CT compliant TLS clients" or > > as you use below "TLS clients claiming conformance with CT", which > > presumably does not update TLS? > TLS is the definitive spec for the messages exchanged during its > handshake. So > the specs in Section 3.4 represent an update to TLS (1.2). That does not > make > support for CT mandatory, but it informs implementers of the new TLS > extensions > defined here and the processing they imply. > Ah, I see what you mean. A couple of observations: 1. The TLS extension was allocated for 6962, so surely this should already have happened? 2. I notice other extensions exist which are not referenced in the "update by" section of 5246. 3. If this is a requirement for new extensions, why is it not part of the process followed to get an extension allocated? > > Steve > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114901b4c8b3d7051b893637 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue= , 7 Jul 2015 at 16:38 Stephen Kent <kent= @bbn.com> wrote:
Ben,

> A certificate not accompanied by an SCT is not CT compliant.
> This seems redundant: I would've thought that in general everythin= g in
> an RFC only applies to things that are compliant with that RFC. But if=
> the WG wants I don't really mind either way.
I prefer the wording I suggested because it emphasizes the status of the cert relative
to this spec, rather than intimating any TLS client behavior.
>
> OK, I get your point here, and I am happy to go either way:
>
> a) Update TLS to require CT, or
that's not what I meant to suggest. I don't think CT is destined to= become
a mandatory aspect of TLS; it's an optional feature.
> b) Update the I-D to say something like "CT compliant TLS clients= " or
> as you use below "TLS clients claiming conformance with CT",= which
> presumably does not update TLS?
TLS is the definitive spec for the messages exchanged during its
handshake. So
the specs in Section 3.4 represent an update to TLS (1.2). That does not make
support for CT mandatory, but it informs implementers of the new TLS
extensions
defined here and the processing they imply.

=
Ah, I see what you mean.

A couple of observat= ions:

1. The TLS extension was allocated for 6962,= so surely this should already have happened?

2. I= notice other extensions exist which are not referenced in the "update= by" section of 5246.

3. If this is a require= ment for new extensions, why is it not part of the process followed to get = an extension allocated?
=C2=A0
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a114901b4c8b3d7051b893637-- From nobody Thu Jul 23 04:46:03 2015 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 358E91A016C for ; Thu, 23 Jul 2015 04:46:02 -0700 (PDT) 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 bRjKVWh8GR4D for ; Thu, 23 Jul 2015 04:46:00 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44D91ACCE3 for ; Thu, 23 Jul 2015 04:44:29 -0700 (PDT) Received: by ykfw194 with SMTP id w194so136918404ykf.0 for ; Thu, 23 Jul 2015 04:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=VDdvN3dtncecD64YKsh6he5wSgsKSRnUSwCymc8lzgM=; b=V8BL1FQ8DslZDrJbZQXUgJbzrhq733tJVasb42Lso+NnmpP4EDGRa6ABiLsencXBY3 gG34svaaRtevGn2Xvqjh2XnNGt3ybdHxNaqKbgZm93YyPt1JD9xbAHCiFDyeK1Z+Dm/e 1k3vynvLWtsoiOVZ7/LPUvOtSGZoN/wilCvlH5f2dAoxDhUFerczLMwykx9kWcs4KCbf bNmEpy+oUQ21V1B758nyovM+PGafd0n08NRZCRMnDAezZgpFyMDwv4EuCsgO6QheXxVQ FOtR2pWcUIglmcC7NGzbf9k5Vfk+lw4BPs1JqIjIt7JfVBJ6h7/yJNBIBhGguHxMTZEI NvnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=VDdvN3dtncecD64YKsh6he5wSgsKSRnUSwCymc8lzgM=; b=Oh8GZj9Ze4xZKK6o8OqXf06LdbDY8CevAZnay6dbt0UgcbfabRbPgOXaNS6qNgSQaj tMB63lUroHpTYN8AOltSaMI3oHZU9eEqflVa6cPTZdCjuu9ua4GPJvxaFiHFzFffOY6s T8FsiK6cRIodzH+l8WlNAfX845jI4ewbPMdfAS02KyRBGdINDHgfaQ0UsS/VeyHuIqFP pd1krV3ICZ4gNeluLdQtT1zHxTMFuXTB4ZJ3RUkDKhbzs2umJMyPbs8C3yvpwLTBmzt6 X3Z0+dPrI4hwZgTPxkRfHOAITp1s5VUWlNXgnWu9zXMfHm7qW3uDPflEVzDdpZ/xmdoe ipcA== X-Gm-Message-State: ALoCoQnQHkW48TbhYkpoH8nXRgThmBMDSpirW9eLAK5yK5e9ByLAcHpwIIq4Ry4UTfS71aRmEF9k X-Received: by 10.170.91.3 with SMTP id i3mr7670177yka.25.1437651869038; Thu, 23 Jul 2015 04:44:29 -0700 (PDT) MIME-Version: 1.0 References: <056.5d271b279cc61b979e6443dc0948e24a@tools.ietf.org> <071.139420386221cc6aea4536fab0441820@tools.ietf.org> <55B0B674.8090904@bbn.com> In-Reply-To: <55B0B674.8090904@bbn.com> From: Ben Laurie Date: Thu, 23 Jul 2015 11:44:19 +0000 Message-ID: To: Stephen Kent , trans issue tracker , draft-ietf-trans-rfc6962-bis@tools.ietf.org Content-Type: multipart/alternative; boundary=001a113a05e8f7891f051b8968ab Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #96 (rfc6962-bis): Metadata: Should it be dynamic? 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, 23 Jul 2015 11:46:02 -0000 --001a113a05e8f7891f051b8968ab Content-Type: text/plain; charset=UTF-8 On Thu, 23 Jul 2015 at 10:40 Stephen Kent wrote: > There are two types of log metadata. Some if the data is analogous to > trust anchor > info and thus distributing it to TLS clients using the same (not > standardized) browser > vendor mechanisms makes sense. (This does, though, raise an issue about > how non-browser > client acquire this info; Monitors and Auditors are not necessarily > products of vendors > and thus there may not be the same infrastructure to distribute this > sort of data.) > > Other log metadata (e.g., MMD and STH frequency) is less like trust > anchor info and > it could be distributed by having a signed, time-stamped data structure > posted at a known > location associated with the log. A potential benefit of this model is > that a log operator > can know that if it changes these parameters, all clients are able to > acquire the new info > at the same time. If one relies on an unspecified distribution mechanism > for these parameters, > a log operator cannot know when all clients have received the new info. > That uncertainty > might cause operational problems. So, the title for this issuer is not > really whether ALL > metadata should be dynamic, but rather whether some of it should be. > MMD and STH frequency are parameters that cannot be freely varied and still allow useful operation of the system. It does not seem to me that it would ever be appropriate to allow logs to unilaterally change them - that's precisely why they're part of the metadata and not data that can be retrieved from the log. Perhaps the simplest thing to do is note that changing metadata is also implementation dependent (as well as distribution) and out of scope? Obviously if something doesn't belong in metadata at all, that's a different matter. > Steve > > #96: Metadata: Should it be dynamic? > > > > Changes (by benl@google.com): > > > > * milestone: => review > > > > > > Comment: > > > > We've already discussed this, I feel sure, and the general point is > that > > allowing logs to manipulate their own metadata is dangerous, as you > state. > > That's why the I-D says its distribution is out of scope. > > > > As you know, in practice, Chrome defines its own log metadata, and > that is > > what clients use. I imagine this will be the general pattern. > > > > I propose this is resolved as wontfix. > > > > --001a113a05e8f7891f051b8968ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , 23 Jul 2015 at 10:40 Stephen Kent <ken= t@bbn.com> wrote:
There ar= e two types of log metadata. Some if the data is analogous to
trust anchor
info and thus distributing it to TLS clients using the same (not
standardized) browser
vendor mechanisms makes sense. (This does, though, raise an issue about
how non-browser
client acquire this info; Monitors and Auditors are not necessarily
products of vendors
and thus there may not be the same infrastructure to distribute this
sort of data.)

Other log metadata (e.g., MMD and STH frequency) is less like trust
anchor info and
it could be distributed by having a signed, time-stamped data structure
posted at a known
location associated with the log.=C2=A0
A potential benefit of this model is
that a log operator
can know that if it changes these parameters, all clients are able to
acquire the new info
at the same time. If one relies on an unspecified distribution mechanism for these parameters,
a log operator cannot know when all clients have received the new info.
That uncertainty
might cause operational problems. So, the title for this issuer is not
really whether ALL
metadata should be dynamic, but rather whether some of it should be.

MMD and STH frequency are parameters that can= not be freely varied and still allow useful operation of the system. It doe= s not seem to me that it would ever be appropriate to allow logs to unilate= rally change them - that's precisely why they're part of the metada= ta and not data that can be retrieved from the log.

Perhaps the simplest thing to do is note that changing metadata is also i= mplementation dependent (as well as distribution) and out of scope?

Obviously if something doesn't belong in metadata at = all, that's a different matter.


Steve
> #96: Metadata: Should it be dynamic?
>
> Changes (by benl@= google.com):
>
>=C2=A0 =C2=A0* milestone:=C2=A0 =C2=A0=3D> review
>
>
> Comment:
>
>=C2=A0 =C2=A0We've already discussed this, I feel sure, and the gen= eral point is that
>=C2=A0 =C2=A0allowing logs to manipulate their own metadata is dangerou= s, as you state.
>=C2=A0 =C2=A0That's why the I-D says its distribution is out of sco= pe.
>
>=C2=A0 =C2=A0As you know, in practice, Chrome defines its own log metad= ata, and that is
>=C2=A0 =C2=A0what clients use. I imagine this will be the general patte= rn.
>
>=C2=A0 =C2=A0I propose this is resolved as wontfix.
>

--001a113a05e8f7891f051b8968ab-- From nobody Thu Jul 23 04:57:12 2015 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 E602E1A92B2 for ; Thu, 23 Jul 2015 04:57:07 -0700 (PDT) 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 rbKvWM_gOrFu for ; Thu, 23 Jul 2015 04:57:05 -0700 (PDT) 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 198A91A92AE for ; Thu, 23 Jul 2015 04:57:05 -0700 (PDT) Received: from localhost ([::1]:40589 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIF7W-0000XD-U8; Thu, 23 Jul 2015 04:57:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 11:57:02 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/64#comment:2 Message-ID: <067.b0820a40782b1b69e5bd6b7c2efc4e5e@tools.ietf.org> References: <052.21690f37c007741b7f717c5b07ad676c@tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <052.21690f37c007741b7f717c5b07ad676c@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150723115705.198A91A92AE@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 04:57:05 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #64 (rfc6962-bis): remove specification of signature and hash lags from section 2 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, 23 Jul 2015 11:57:08 -0000 #64: remove specification of signature and hash lags from section 2 Comment (by benl@google.com): Hash algorithm has already been replaced by an IANA register in -08. Same needs to be done for signing algorithms. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 05:03:30 2015 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 D536C1A92B5 for ; Thu, 23 Jul 2015 05:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vBmR8rBYoRM for ; Thu, 23 Jul 2015 05:03:27 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 95B921A9250 for ; Thu, 23 Jul 2015 05:03:27 -0700 (PDT) Received: by pdrg1 with SMTP id g1so156268181pdr.2 for ; Thu, 23 Jul 2015 05:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JFCxsNRh966pBz7kEnpi3PnhRD2EiRxLtUootOPWPO4=; b=RWh5xI/OaBHWbb5EVt9ZDe5zG1IfHMCoFmXTAjM5hLCwA3yWI6ca1S4I4CVNmpZUHr Nt7nXqoyYib6Ba7WBG/XhtfTsXBVyipLhIx90dxlsjiLRJOTT18y8HE8zyxLen26jVUu YHDSSAdm38HkqF4g6ty2V6Qj1yt2mE9pSR+Um/3a88RPOkjwt7EfmB84E52aRPw7okWS kIfhX6f7BR36DkN/BKzEUwRnZzjdZRCmdue3yvli7to79Nmkl1vEkxruFER6wpWd6vBd h+bY+cX6sp7A6grfS4Iwce6T11YLivjXROirWlIDqGVYmBNChmG3GkYQmVncgLSfeKfm xyiQ== X-Received: by 10.66.251.135 with SMTP id zk7mr17841474pac.80.1437653007214; Thu, 23 Jul 2015 05:03:27 -0700 (PDT) Received: from spandex.local (63-140-96-125-radius.dynamic.acsalaska.net. [63.140.96.125]) by smtp.gmail.com with ESMTPSA id jw13sm6271044pad.48.2015.07.23.05.03.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 05:03:26 -0700 (PDT) Message-ID: <55B0D80C.1060600@gmail.com> Date: Thu, 23 Jul 2015 04:03:24 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:03:29 -0000 Hi, all: This is a call for adoption of http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ as a working group deliverable. The call closes on August 6. Thanks, Melinda & Paul From nobody Thu Jul 23 05:36:57 2015 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 B150D1A92F2 for ; Thu, 23 Jul 2015 05:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pNaQ_yEmeXnf for ; Thu, 23 Jul 2015 05:36:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474FE1A8725 for ; Thu, 23 Jul 2015 05:36:25 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:50692 helo=dhcp-a067.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZIFja-0008hw-Vo for trans@ietf.org; Thu, 23 Jul 2015 08:36:23 -0400 To: trans@ietf.org References: <052.225d9e4c8d8c45e468832faf6102e815@tools.ietf.org> <067.26cce79c448ae94087e82f3a71addea6@tools.ietf.org> From: Stephen Kent Message-ID: <55B0DFC5.4000300@bbn.com> Date: Thu, 23 Jul 2015 14:36:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <067.26cce79c448ae94087e82f3a71addea6@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate 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, 23 Jul 2015 12:36:55 -0000 Ben, The current, very brief description does not discuss a number of issues of how a planned algorithm transition takes place. For example, if a log operator wants to move to a new signature algorithm, it needs to create the new metadata that points to the new log, including a new URL, new algorithm identifiers and new keys. The means by which this metadata is distributed is not specified, but it seems likely that the browser-vendor channel for distribution of this metadata will take a little while. So, there is a need for guidance to a log operator as to how to deal with the unknown delays for this metadata to become widely available. There is also the question of when the old log is frozen relative to the new log, and how this relates to the various types of log clients (CAs vs. browsers vs. Monitors). For example, do CAs now need to get SCTs for certs from both the old and new logs to ensure continuity for SCT consumers, and if so, for how long does this dual operation persist? I think this is a non-trivial problem and the current text does not address the sorts of issues noted above. Note that the RPKI published a detailed description of how a phased algorithm transition is to be effected for that system. That system faces a much more difficult transition task, but the principle of documenting how a staged transition with some established interval lengths, still seems appropriate. Steve > #78: algorithm agility discussion is inadequate > > > Comment (by benl@google.com): > > I am not clear what you are asking for. I cannot provide a long detailed > plan for migrating from one log to another because the plan is as stated: > freeze one log, start another one. > From nobody Thu Jul 23 05:50:12 2015 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 C89E81A0161 for ; Thu, 23 Jul 2015 05:50:06 -0700 (PDT) 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 KYF9n-26xjdU for ; Thu, 23 Jul 2015 05:50:04 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 805261AC447 for ; Thu, 23 Jul 2015 05:49:49 -0700 (PDT) Received: by ykfw194 with SMTP id w194so138230131ykf.0 for ; Thu, 23 Jul 2015 05:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=ZpWuqgFBF6z+twcs02EnTMmwzCFY94tnbB3FM3tw6SQ=; b=dTF24KoY37MbqbASkIjPY7n8TrFHh5XM/j7hM1NiLT/ergy4cFAyxbsuuob6WSVy79 lElDX5TcHiY5kmVXAnkSG3JF2bMHF8Qk/15MVJhzGRxjSgsQECvjemsIk1W3h+L3R1IV eGXDT84TQAcra8nRxbmh+D38DmGo8q77mNTFxWF3vfj1MnKzCRGrW+yhyW3OcX3XXwyy ClNpjQSh0qhFXDqZkw1BgxF/yAcee0xY7jCXAQWLoK+zYLbywcjfDTCGhgFw0yXKZNlp KVfCL5SHA6cH8mCggzxQjUn5CnaTUb47R2hEa82/qX6FtuL8vBxBGWInEl48Jr8Q+ejD jF0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=ZpWuqgFBF6z+twcs02EnTMmwzCFY94tnbB3FM3tw6SQ=; b=ZtHzedtMYkHFz20MIUEbfoj2kieNgHEPm2X2QHX+MqllPqhDL2RhzUH2DWMxSxQinK Pc17PJJlmaP2+TlWq570asifwsH/95oeXXMFlLJifs4KtYg+Lg+tUZ+/KgDh1/TZwtkw Sim8oJHblvYN3/pXF40MIP6OWgELgQltd77f17MDRFDvAxhguuVcwnMNljFha86q8PEr HLbG/9MrmHNTyA1rLhfW458HgoBDjssJugsp00HVdRvv4HZPzNl0gfXZiyzY1H1n0Exx sFOE7DpqGn9ADfnHsv1IqhXL7kGx57ilESoTZkDZYTP+EcMlHdq9ox+9TMb2wjZBnv7d HyGQ== X-Gm-Message-State: ALoCoQlzlXGq3kmpDFFitXiekQuoqqrZw3V4zWiCWrMDJZBqTOUGgDBV0SiGA+ekirUhBt+sB8v4 X-Received: by 10.170.119.85 with SMTP id l82mr8119414ykb.89.1437655788861; Thu, 23 Jul 2015 05:49:48 -0700 (PDT) MIME-Version: 1.0 References: <052.225d9e4c8d8c45e468832faf6102e815@tools.ietf.org> <067.26cce79c448ae94087e82f3a71addea6@tools.ietf.org> <55B0DFC5.4000300@bbn.com> In-Reply-To: <55B0DFC5.4000300@bbn.com> From: Ben Laurie Date: Thu, 23 Jul 2015 12:49:39 +0000 Message-ID: To: Stephen Kent , trans@ietf.org Content-Type: multipart/alternative; boundary=001a113908ec9b1fd6051b8a5255 Archived-At: Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate 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, 23 Jul 2015 12:50:07 -0000 --001a113908ec9b1fd6051b8a5255 Content-Type: text/plain; charset=UTF-8 Please note that responses to trac emails do not appear to end up in trac, so if you want this response (and others) to be tracked, I guess you need to update trac. On Thu, 23 Jul 2015 at 13:36 Stephen Kent wrote: > Ben, > > The current, very brief description does not discuss a number of issues of > how a planned algorithm transition takes place. For example, if a log > operator > wants to move to a new signature algorithm, it needs to create the new > metadata > that points to the new log, including a new URL, new algorithm > identifiers and > new keys. The means by which this metadata is distributed is not > specified, but > it seems likely that the browser-vendor channel for distribution of this > metadata > will take a little while. So, there is a need for guidance to a log > operator > as to how to deal with the unknown delays for this metadata to become > widely available. > There is also the question of when the old log is frozen relative to the > new > log, and how this relates to the various types of log clients (CAs vs. > browsers vs. Monitors). > For example, do CAs now need to get SCTs for certs from both the old and > new logs > to ensure continuity for SCT consumers, and if so, for how long does > this dual operation > persist? > > I think this is a non-trivial problem and the current text does not > address the sorts > of issues noted above. > > Note that the RPKI published a detailed description of how a phased > algorithm transition > is to be effected for that system. That system faces a much more > difficult transition > task, but the principle of documenting how a staged transition with some > established interval > lengths, still seems appropriate. > > Steve > > > #78: algorithm agility discussion is inadequate > > > > > > Comment (by benl@google.com): > > > > I am not clear what you are asking for. I cannot provide a long > detailed > > plan for migrating from one log to another because the plan is as > stated: > > freeze one log, start another one. > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113908ec9b1fd6051b8a5255 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please note that responses to trac emails do not appear to= end up in trac, so if you want this response (and others) to be tracked, I= guess you need to update trac.

On Thu, 23 Jul 2015 at 13:36 Stephen Kent <kent@bbn.com> wrote:
Ben,

The current, very brief description does not discuss a number of issues of<= br> how a planned algorithm transition takes place. For example, if a log
operator
wants to move to a new signature algorithm, it needs to create the new
metadata
that points to the new log, including a new URL, new algorithm
identifiers and
new keys. The means by which this metadata is distributed is not
specified, but
it seems likely that the browser-vendor channel for distribution of this metadata
will take a little while. So, there is a need for guidance to a log operato= r
as to how to deal with the unknown delays for this metadata to become
widely available.
There is also the question of when the old log is frozen relative to the ne= w
log, and how this relates to the various types of log clients (CAs vs.
browsers vs. Monitors).
For example, do CAs now need to get SCTs for certs from both the old and new logs
to ensure continuity for SCT consumers, and if so, for how long does
this dual operation
persist?

I think this is a non-trivial problem and the current text does not
address the sorts
of issues noted above.

Note that the RPKI published a detailed description of how a phased
algorithm transition
is to be effected for that system. That system faces a much more
difficult transition
task, but the principle of documenting how a staged transition with some established interval
lengths, still seems appropriate.

Steve

> #78: algorithm agility discussion is inadequate
>
>
> Comment (by benl@= google.com):
>
>=C2=A0 =C2=A0I am not clear what you are asking for. I cannot provide a= long detailed
>=C2=A0 =C2=A0plan for migrating from one log to another because the pla= n is as stated:
>=C2=A0 =C2=A0freeze one log, start another one.
>

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a113908ec9b1fd6051b8a5255-- From nobody Thu Jul 23 07:33:58 2015 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 2E36E1A8032 for ; Thu, 23 Jul 2015 07:33:57 -0700 (PDT) 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 sPZTW9FZBS28 for ; Thu, 23 Jul 2015 07:33:56 -0700 (PDT) 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 EABEB1A86F4 for ; Thu, 23 Jul 2015 07:33:23 -0700 (PDT) Received: from localhost ([::1]:56856 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIHYn-0006Vw-Ns; Thu, 23 Jul 2015 07:33:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net X-Trac-Project: trans Date: Thu, 23 Jul 2015 14:33:16 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/98 Message-ID: <055.bc4011473cb4fc46fd07bb547773f0fb@tools.ietf.org> X-Trac-Ticket-ID: 98 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20150723143323.EABEB1A86F4@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 07:33:23 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #98 (gossip): Update gossip-ct for 6962bis 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, 23 Jul 2015 14:33:57 -0000 #98: Update gossip-ct for 6962bis The gossip-ct draft (draft-linus-trans-gossip-ct) is written with RFC6962 in mind. It should be written for 6962bis. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- linus@nordu.net | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: gossip | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 07:37:26 2015 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 54A351ACCF0 for ; Thu, 23 Jul 2015 07:37:25 -0700 (PDT) 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 02FpmdYhIxhg for ; Thu, 23 Jul 2015 07:37:24 -0700 (PDT) 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 2841E1A03FF for ; Thu, 23 Jul 2015 07:37:24 -0700 (PDT) Received: from localhost ([::1]:57739 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIHch-0008Dz-Nv; Thu, 23 Jul 2015 07:37:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net X-Trac-Project: trans Date: Thu, 23 Jul 2015 14:37:23 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/98#comment:1 Message-ID: <070.739b1c47279a2049dd9234d80395055c@tools.ietf.org> References: <055.bc4011473cb4fc46fd07bb547773f0fb@tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <055.bc4011473cb4fc46fd07bb547773f0fb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20150723143724.2841E1A03FF@ietfa.amsl.com> Resent-Date: Thu, 23 Jul 2015 07:37:24 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #98 (gossip): Update gossip-ct for 6962bis 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, 23 Jul 2015 14:37:25 -0000 #98: Update gossip-ct for 6962bis Comment (by linus@nordu.net): At least two issues have been identified: - STH issuance limit - base64 vs. binary format -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- linus@nordu.net | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: gossip | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jul 23 08:08:44 2015 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 521401A0178 for ; Thu, 23 Jul 2015 08:08:43 -0700 (PDT) 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 eagI4xYUK8sH for ; Thu, 23 Jul 2015 08:08:42 -0700 (PDT) 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 28A911A0056 for ; Thu, 23 Jul 2015 08:08:42 -0700 (PDT) Received: from localhost ([::1]:59300 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZII6z-0006oY-PR; Thu, 23 Jul 2015 08:08:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 15:08:41 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/99 Message-ID: <056.44d8e1af7d476e6c42f98a5d494bb486@tools.ietf.org> X-Trac-Ticket-ID: 99 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #99 (rfc6962-bis): Clearer definition of when a certificate is CT-compliant needed 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, 23 Jul 2015 15:08:43 -0000 #99: Clearer definition of when a certificate is CT-compliant needed The current text in the "Including the Signed Certificate Timestamp in the TLS Handshake" has a few problems, particularly: "The SCT data corresponding to at least one certificate in the chain from at least one log must be included in the TLS handshake..." * The text should make a clear assertion that this is for a certificate to be considered CT-compliant. * The 'must' should be a MUST. * The text currently requires 'at least one certificate in the chain'. It does not require the SCTs to be for the leaf cert (although currently there's no way to indicate any of the non-embedded SCTs are for a certificate that's not the leaf certificate). The text could be pivoted to indicate that any certificate in the chain accompanied by SCTs is considered CT-compliant. -- ------------------------------+------------------------------ Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: ------------------------------+------------------------------ Ticket URL: trans From nobody Thu Jul 23 12:59:10 2015 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 713151A87C9 for ; Thu, 23 Jul 2015 12:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 sXuVtHIlV_Ow for ; Thu, 23 Jul 2015 12:59:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 285561A87B2 for ; Thu, 23 Jul 2015 12:59:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 912FA4DEB3 for ; Thu, 23 Jul 2015 19:59:50 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 6F6F74DEAD for ; Thu, 23 Jul 2015 19:59:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437681590; bh=nkb0ojj87+N21YzUkfL972yYRz8lRN7ZI3T0uEeYYSk=; h=From:To:Subject:Date:From; b=EfblpsRzyzcezHYXzJJ00mi1elwLMOye9ba3FVCPY99tRrs/Yo0eXqNhZqc3b3Jhh JVB7fIkpQK2myHK1MYukvVDZ8Awohqk7PpVU+QpUpYvsdwEkBqTVuxHJ6tx7ujZ/RP wTGa/WVRdQdSO0eJOvf6CxLD5EiqV8wWS+8KcUic= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 73D94800CE for ; Thu, 23 Jul 2015 19:59:06 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 23 Jul 2015 14:58:31 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Thu, 23 Jul 2015 14:58:31 -0500 From: "Salz, Rich" To: "trans@ietf.org" Thread-Topic: TRANS Draft minutes for IETF-93 Thread-Index: AdDFYP7WEeHyAUAfShqF+ALMT7NsEQ== Date: Thu, 23 Jul 2015 19:58:30 +0000 Message-ID: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.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.152.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Trans] TRANS Draft minutes for IETF-93 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, 23 Jul 2015 19:59:09 -0000 Please send/post corrections. Paul, WG Status update Charger unchanged; need to reset milestone. Eran RFC6962-bis status+ Still needs some tweaks. Suggests waiting for Google to finish their implem= entation to clean out all nits before WGLC A log cannot do a single v1/v2 log, must run both in parallel. Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, 82, = 83, 84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details Open tickets 78 (alg agility needs more description) 83 (should require det= erministic ECESA) 96 (dynamic metadata; does only CA root list really chang= e?) 95 (include get-entries response size in the log metadata, for cursorin= g through a log) Steve raised issue of exposing what certs a client is interested in if size= of get-entries can shrink to one, for example. More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash = lags) 93 (monitor description inconsistencies) 94 (when/why clients should = fetch inclusion proofs) Stephen raised issue fhat if threat analysis is normative, schedule gets pu= shed out further. Should be informative. Steve Kent, attack model Name changed on doc, even if filename can't easily be changed. Not a threat= model, we don't know what the attackers are thinking, but we do know possi= ble actions so it's an attack model. Includes an intro to CT, he prefers it move into an arch document but if no= t it will stay. "CT is a set of mechanisms, designed to detect, deter, and facilitate remed= iation of certificate mis-issuance" Semantic mis-issuance: name in the cert refers to an entity incorrectly. Syntactic mis-issuance: violation of certificate profile(s) that apply. Reviewed a taxonomy of attacks. Read the doc. Discussion of additions and= bigger picture needs. Incorporated all (but one) comments. Wants WG agreement via list on goals, definitions, attacks. We have a half-dozen people commit to read and review the document. Ben agrees about having an arch doc; Steve and Ben will collaborate on an a= rch doc Dkg, Gossip Gossip important to keep logs accountable by making sure everyone sees the = same append-only data and keep their MMD/SCT promises. Works by browser's sharing and comparing SCT and STH Three channels: SCTFeedback; browser sends cert/sct to website, website sends to auditing= function/third-party auditor STH Pollination: auditor/website send STH to each other. STH are not priv= acy-sensitive Optional Trusted Auditor: browser passes sct/cert to auditor (e.g., the DN= S resolver since it already knows what you might be looking at) Call for adoption is on the mailing list. Dkg, CT for binary=20 Goal is to know that you are running the same software as "everyone else," = not guaranteeing that the software isn't compromised. Add a binary lLogEntryType; add binary and binary_digest to Signed_Type Many details of what and how is signed are still open; need feedback from s= /w distributors. PHB suggest to not use ASN.1 Discussion and agreement that changing the s/w distribution format is a non= -starter. Rich Salz, selective logs Some logs will not log every single cert from the CA's in their root list. What do we do? Discussion, no conclusion. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz - From nobody Thu Jul 23 13:22:44 2015 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 043CA1A8828 for ; Thu, 23 Jul 2015 13:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 BM-wGBgAMlAo for ; Thu, 23 Jul 2015 13:22:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA141A87E3 for ; Thu, 23 Jul 2015 13:22:42 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AB55616A63E; Thu, 23 Jul 2015 20:22:41 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 95C5116A5E6; Thu, 23 Jul 2015 20:22:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1437682961; bh=x1eq836+EocZIOp1gNC1s9SKshFVoYRAjJccBsQMSbI=; h=From:To:Subject:Date:References:In-Reply-To:From; b=ibQ6O0h2tpmaOrnQZiave7wcapSrvNdPVInULE6NPNvDq1U02AxJWXCbc4euf7JTK +0isTMwGW2PoMbdcgg0ypyqUNzer/gYklV1vaabgtwhHX7QfUdQcFClZEPeFrXHaYL Ka3Hw6IBqDLMcIeDHsxkxfk+J5Bs9e/FGLViUX34= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 86B5B1E5B4; Thu, 23 Jul 2015 20:22:41 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 23 Jul 2015 15:22:40 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Thu, 23 Jul 2015 15:22:40 -0500 From: "Salz, Rich" To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Call for adoption, draft-linus-trans-gossip-ct Thread-Index: AQHQxT+qoaIOUj0ovUOYlTUokvi3/p3pgBaA Date: Thu, 23 Jul 2015 20:22:40 +0000 Message-ID: References: <55B0D80C.1060600@gmail.com> In-Reply-To: <55B0D80C.1060600@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.152.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 20:22:43 -0000 Strong yes to adopt. From nobody Thu Jul 23 13:25:22 2015 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 AA40B1A8712 for ; Thu, 23 Jul 2015 13:25:21 -0700 (PDT) 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 wcuQemR-uE6G for ; Thu, 23 Jul 2015 13:25:20 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905811A8874 for ; Thu, 23 Jul 2015 13:25:20 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so300349igb.0 for ; Thu, 23 Jul 2015 13:25:20 -0700 (PDT) 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 :content-type; bh=XJCLXiaZ0Z/Nb6uH8ogJeucPaw8+wtord6LwcysIvjE=; b=EKY1d2prOLN8qfWyS0/A4Dy9i0WQLmMaT06ApSoeW5iq9O78sDBw2q/yfHZqRqBmgP t7nCi/5Wz3ZVLaNtr/R4x+V8ZxVOWbNOG/FXfIoDMWRgdjJWE0Y6S+cE0On60WSA2tX2 m12bhfybt4S5mrGk1pAPZcDqU+s6VnwTvZdZkFIl+w7cdqXDDCeSZlwgBy+hvwLBYOkE OEng9kcyYRfW/ukBGdzo38M9ucJTa9jItwF5cefUVuLJBmuL8bGRhm3QV9TJsVORhPjf fF9S05CP4hrrWrhIwPgXxoEIPiu1Y/Ud0YVppiYPew1efNfyUqynLszXWGyvWi0jb448 eIKw== 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:content-type; bh=XJCLXiaZ0Z/Nb6uH8ogJeucPaw8+wtord6LwcysIvjE=; b=Lycpt61FB9dWxl4HKTLJve9exm3JU5RdMM+vnr60KgowEKmMplx3IGO4Z3Oe/jHWao oGNDzTVyapHwv4ZmlJ07beKvURhwbTQvGlSrLlklXGkPJq4KZSr+LSL753uOeF0/evhl x2tdFEQkxAZ754DO5LnJt4dFoDnDY+Bq0j9PsA0vPBHFzgdia0HBUB2pIGrSULShMMrP 3ZlKqzhdK9QV488+JHfxIpFlaTjsNc6b331ld7FeMo1MCGwIQpLO18tqfMjhF3R+Hm7W 2OlJtWpBlt2lid7dBcxjnO26fYXCQnJekdiP9R3bceyDd1N06qLyLl4Pfcc3fVR1jOnY pYUw== X-Gm-Message-State: ALoCoQkW5T8r/iFEkhjiNn+H5cLZI/FoGSoBzRqhDvd9x9ByvsxYnGV65ltGtgnal7wolgWz9dCf MIME-Version: 1.0 X-Received: by 10.107.138.152 with SMTP id c24mr14972183ioj.74.1437683120038; Thu, 23 Jul 2015 13:25:20 -0700 (PDT) Received: by 10.64.207.225 with HTTP; Thu, 23 Jul 2015 13:25:19 -0700 (PDT) In-Reply-To: References: <55B0D80C.1060600@gmail.com> Date: Thu, 23 Jul 2015 22:25:19 +0200 Message-ID: From: Eran Messeri To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113f2b4eab9a85051b90af45 Archived-At: Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 20:25:21 -0000 --001a113f2b4eab9a85051b90af45 Content-Type: text/plain; charset=UTF-8 Another vote for adoption. On Thu, Jul 23, 2015 at 10:22 PM, Salz, Rich wrote: > Strong yes to adopt. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113f2b4eab9a85051b90af45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another vote for adoption.

On Thu, Jul 23, 2015 at 10:22 PM, Salz, Ric= h <rsalz@akamai.com> wrote:
Strong yes to adopt.

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

--001a113f2b4eab9a85051b90af45-- From nobody Thu Jul 23 13:26:47 2015 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 D27641A89C5 for ; Thu, 23 Jul 2015 13:26:45 -0700 (PDT) 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 fUFeGeWi47PS for ; Thu, 23 Jul 2015 13:26:44 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F651A009E for ; Thu, 23 Jul 2015 13:26:43 -0700 (PDT) Received: (qmail 18970 invoked by uid 1004); 23 Jul 2015 20:26:42 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 23 Jul 2015 21:26:41 +0100 Received: (qmail 26596 invoked by uid 1000); 23 Jul 2015 20:26:41 -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, 23 Jul 2015 21:26:41 +0100 To: "trans@ietf.org" References: <55B0D80C.1060600@gmail.com> From: Rob Stradling Message-ID: <55B14E01.4000407@comodo.com> Date: Thu, 23 Jul 2015 21:26:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 20:26:46 -0000 +1 On 23/07/15 21:25, Eran Messeri wrote: > Another vote for adoption. > > On Thu, Jul 23, 2015 at 10:22 PM, Salz, Rich > wrote: > > Strong yes to adopt. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jul 23 14:25:09 2015 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 559E51A87D0 for ; Thu, 23 Jul 2015 14:25:07 -0700 (PDT) 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 IaVq03y1QTvT for ; Thu, 23 Jul 2015 14:25:06 -0700 (PDT) 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 3E0E21A21A2 for ; Thu, 23 Jul 2015 14:25:06 -0700 (PDT) Received: from localhost ([::1]:48547 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZINzA-0006ui-Br; Thu, 23 Jul 2015 14:25:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com X-Trac-Project: trans Date: Thu, 23 Jul 2015 21:25:00 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:12 Message-ID: <079.e389b9722f913943a494640b664d6e99@tools.ietf.org> References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate 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, 23 Jul 2015 21:25:07 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate Changes (by rob.stradling@comodo.com): * status: reopened => closed * resolution: => fixed Comment: Resolving fixed, since this was reviewed previously. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: closed Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Jul 23 15:27:50 2015 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 392501B2A28 for ; Thu, 23 Jul 2015 15:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 4g2FeWJY-eaw for ; Thu, 23 Jul 2015 15:27:45 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C231B2A27 for ; Thu, 23 Jul 2015 15:27:44 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so3914357wic.1 for ; Thu, 23 Jul 2015 15:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=mj4xLL2K752aWjb6DNNeKePE7xLhlUqnLgptx6ef5F8=; b=PgUUVGu67EGvKKolPP0Jt98nRWvM5A8u0t4x4vmm6ynCEq6GOY/q5p6XqYlmeLLx5Q ZTjWi4I2TRHSRDDJCWE3gSRaufsZG1OPSHCj1T0Ut+xrkRdCU2MBPDEOLIjzeN+rjIS+ baPTRXsBDFPKe8C8Cd+2VMwYaAZKIWP8nKRmFi+5UYeD5X0pDR2RF6POKA8P31hDStUv MsF6fR7+i/MDfF839Uk7LH4Ev3zkxJyXWsKWkiarNS1KKdlj63x1beqwv9TDcQjGVL88 TRlD2twzL5C+EZ7HaH6bnquzr45sgjEbsfhC0ZXO8XAWxbBwb5cC8zsIyEbRFl/jLBgM 2pKQ== X-Received: by 10.194.206.65 with SMTP id lm1mr20156681wjc.117.1437690463193; Thu, 23 Jul 2015 15:27:43 -0700 (PDT) Received: from [10.12.14.178] (198.151.broadband16.iol.cz. [90.183.151.198]) by smtp.gmail.com with ESMTPSA id ul1sm9528460wjc.30.2015.07.23.15.27.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 15:27:41 -0700 (PDT) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_FF3915C9-DD68-47FC-B0BE-82D259FD3C63"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Date: Fri, 24 Jul 2015 00:27:37 +0200 References: To: trans@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 22:27:48 -0000 --Apple-Mail=_FF3915C9-DD68-47FC-B0BE-82D259FD3C63 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C3D4D2B-550B-4008-8F0E-D9FCF5893C7B" --Apple-Mail=_6C3D4D2B-550B-4008-8F0E-D9FCF5893C7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > From: Melinda Shore > Subject: [Trans] Call for adoption, draft-linus-trans-gossip-ct > Date: July 23, 2015 at 2:03:24 PM GMT+2 > To: "trans@ietf.org" >=20 > Hi, all: >=20 > This is a call for adoption of > http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ > as a working group deliverable. The call closes on August 6. While the draft represents a fine start at defining a gossip mechanism, = I would like to express serious reservations about the draft=E2=80=99s = basic premise that a gossip mechanism is the best approach - or even an = adequate approach - =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, = to quote the draft=E2=80=99s self-stated purpose. As such, I have = serious reservations about the WG adopting the draft, not because = there=E2=80=99s anything wrong with the content of the draft per se but = because gossip is simply not the right approach. First, the gossip approach creates severe privacy problems, which are = already well-discussed so I won=E2=80=99t reiterate them. Second, the gossip approach can=E2=80=99t ensure that privacy-sensitive = Web clients (who can=E2=80=99t or don=E2=80=99t want to reveal their = whole browsing history to a Trusted Auditor) will ever actually be able = =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, if for example the = misbehaving log=E2=80=99s private key is controlled by a MITM attacker = between the Web client and the website the client thinks he is visiting. Suppose, for example, it ever so happens that a single company ends up = running both a log server and a [sub-]CA, and keeps both in the same = poorly-protected safe. If an attacker can steal those two private keys, = then the attacker can silently MITM any CT-aware client all it wants, by = producing all the [non-EV] certificates it needs with a valid SCT, valid = STH inclusion proofs in a fake log, etc. The web client isn=E2=80=99t = going to learn about the problem via gossip with the website because = that=E2=80=99s the MITM attacker, and the client can=E2=80=99t gossip = with anyone else without the serious privacy risk of trusting a single = audit server with his entire browsing history. If the =E2=80=9Ctrusted = audit server=E2=80=9D is actually co-located with the client, then the = audit server in turn can=E2=80=99t gossip with the rest of the world = without creating the same privacy risk. Even if the client does = voluntarily gossip with a remote trusted audit server, the MITM attacker = - e.g., an ISP-level or state-level attacker - might simply block = connections to all well-known audit servers. Is it =E2=80=9Ctoo unlikely=E2=80=9D that an attacker can compromise = both a log server key and a CA key? Even if some CT policy is = established that a single company is never allowed to run both a log = server and hold a [sub-]CA key, which might not be a bad idea, it = doesn=E2=80=99t seem beyond reason that some state-level attackers are = incapable of quietly exfiltrating (or just quietly subpoenaing) both a = log server key and a CA key, and then they get the same, silent MITM = power as they can get now. Thus, while CT does potentially =E2=80=9Craise the bar=E2=80=9D a bit by = requiring a MITM attacker to steal both [any one] CA key and [any one] = log server key, the set of all well-known log servers still just forms = another new weakest-link security chain, just like the set of all CAs = and sub-CAs form an old weakest-link security chain. While =E2=80=9Cbest = of two weakest-link chains=E2=80=9D is admittedly better than one = weakest-link chain, it does not seem like the best we can do or the = target we should be aiming for. I posted an E-mail last week suggesting an alternative approach, in = which log servers would not individually sign their STHs but instead = collectively sign them with the active participation of (a suitable = quorum of) the auditors and/or monitors watching their logs. But I got = no response to that, so I=E2=80=99d like to try again. In short: the log server would propose log entries, but the auditors = and/or monitors contribute to the STH signature, only after performing = at least the =E2=80=9Cauditing=E2=80=9D function of verifying that the = log server is behaving like a correct log server. In particular, all = participants could proactively verify that the log server never forks or = reverts the log, never signs something syntactically invalid or with a = wildly-incorrect timestamp (say +/- 24 hours), etc. Then, even if the = log server=E2=80=99s private key was successfully stolen by a = state-level attacker (and the attacker perhaps even compromises a = minority of the monitor/auditor keys), the attacker will be unable to = forge an STH signature that a Web client or anyone else will believe. This would, in effect, convert each log server from yet another juicy = central attack target into a strongest-link set (I like to use the term = =E2=80=9Ccothority=E2=80=9D or collective authority) with all the = monitor and auditor servers watching it and contributing to its = signatures. Of course, the attacker still wins if he successfully = compromises any single CA (or sub-CA) *and* any single =E2=80=9Clogging = cothority=E2=80=9D (i.e., any log server *and* a sufficient quorum of = its followers). But doing the latter becomes way, way harder if = there=E2=80=99s enough size and diversity in each logging cothority. How does this improve things for the Web client in Repressistan who's = getting MITM attacked? If the client is only looking at SCTs that are = individually signed by a log server (and are in any case only a = =E2=80=9Cpromise to log soon=E2=80=9D and not actual evidence that the = cert has been logged), then unfortunately not much: the MITM attacker = can still forge at least one SCT for each of its forged certs, and no = one else learns because the MITM can keep the client=E2=80=99s view = isolated from the rest of the world. But say we enhance CT so clients can demand STHs *with* cert inclusion = proofs from the web servers they talk to - as I suggested in the meeting = today, and which I believe Ben Laurie mentioned is already in the works. = Then any Web client that does this will be proactively protected from = MITM attacks involving faked, forked, or otherwise bad log entries. And = the client doesn=E2=80=99t have to compromise its privacy by gossiping = with anyone. Bryan --Apple-Mail=_6C3D4D2B-550B-4008-8F0E-D9FCF5893C7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
From: = Melinda Shore <melinda.shore@gmail.com>
Subject: = [Trans] Call for = adoption, draft-linus-trans-gossip-ct
Date: = July 23, 2015 at 2:03:24 PM = GMT+2
To: = "trans@ietf.org" <trans@ietf.org>

Hi, all:

This is a call for adoption of
http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/
as a working group deliverable.  The call closes on = August 6.




Suppose, for = example, it ever so happens that a single company ends up running both a = log server and a [sub-]CA, and keeps both in the same poorly-protected = safe.  If an attacker can steal those two private keys, then the = attacker can silently MITM any CT-aware client all it wants, by = producing all the [non-EV] certificates it needs with a valid SCT, valid = STH inclusion proofs in a fake log, etc.  The web client isn=E2=80=99= t going to learn about the problem via gossip with the website because = that=E2=80=99s the MITM attacker, and the client can=E2=80=99t gossip = with anyone else without the serious privacy risk of trusting a single = audit server with his entire browsing history.  If the =E2=80=9Ctrust= ed audit server=E2=80=9D is actually co-located with the client, then = the audit server in turn can=E2=80=99t gossip with the rest of the world = without creating the same privacy risk.  Even if the client does = voluntarily gossip with a remote trusted audit server, the MITM attacker = - e.g., an ISP-level or state-level attacker - might simply block = connections to all well-known audit servers.









= --Apple-Mail=_6C3D4D2B-550B-4008-8F0E-D9FCF5893C7B-- --Apple-Mail=_FF3915C9-DD68-47FC-B0BE-82D259FD3C63 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA3MjMyMjI3MzhaMCMGCSqGSIb3DQEJBDEWBBR++Z0JQF6xHACBT58ZKOQgIKZTkzCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEArmnpIvx4vuyUVxpV8zAwl08mYmKI9H4xZJqJei2NK/JX7CajMtrGZyJJpFWlNimc c8nhbgdyP4QTtSPhQbgHBmwWXLTdBD6yd0SQO0DXkkiUi3aDWtqqYJqhWUeRCzEMwV/IiFGzIKAu h/T2+2gBnnOeW5fEec4iuXH61yz6OTH00eSZgLnLH9kr2qmsNOtKQ3TH6qKsVcLxlmRJuHzlZpGm +j/BqWJUM4cmIEqWl6dbhsYeNsOrdYinxDmPfckxK58aDFL2DDHhzpecVCS+ZB+UQKlxIUdE8K4P fRYWUq45MoxXD4JDzIGnqiPe5nu299tNEYYu4EdRCKyhJXDv2AAAAAAAAA== --Apple-Mail=_FF3915C9-DD68-47FC-B0BE-82D259FD3C63-- From nobody Thu Jul 23 23:18:07 2015 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 8B9E11B2F60 for ; Thu, 23 Jul 2015 23:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gldNnzDZmOBK for ; Thu, 23 Jul 2015 23:18:03 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA4B1B2F5C for ; Thu, 23 Jul 2015 23:18:03 -0700 (PDT) Received: by pdbnt7 with SMTP id nt7so8624886pdb.0 for ; Thu, 23 Jul 2015 23:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=koxcRzOdpoU9gn7MN4FMbY2wui3tmgVDiP7JmV/zDJA=; b=TbGuWpfH5Rbeog5AAvC+E/hCyRjQ4dGYrKBEbIRx/C/o5aG4P8BioUKQtueKUiYW3h YjmEjsz5M2VENOQIXqBdqVzZQqc70DQQ559Zu2tR4Lo4HDNw7J0+93V1XiIKQHzeHKps IrV+C/G9jADwzwJFzrohXN6IYY9Kk/CMUHk10GA3aI3MjH67d+/Lt1yWIY3RLKMhamnm 95fb9irHzIgy00JgCMmKLkKKdq76I5jLgUJJ6h3ivL/3sLwGt1XRE2yyLSFTNnf9xAhj GYaT6A9jNA9XR1Kt/bl4WqVwKH49sG+lpp7NQ4kErXmQPpiQOv1RVGH6R3M2keOpynlm QrCQ== X-Received: by 10.70.88.142 with SMTP id bg14mr27281795pdb.106.1437718682895; Thu, 23 Jul 2015 23:18:02 -0700 (PDT) Received: from spandex.local (209-193-22-100-radius.dynamic.acsalaska.net. [209.193.22.100]) by smtp.gmail.com with ESMTPSA id j5sm12328598pdi.7.2015.07.23.23.18.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 23:18:02 -0700 (PDT) Message-ID: <55B1D898.6030205@gmail.com> Date: Thu, 23 Jul 2015 22:18:00 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Salz, Rich" , "trans@ietf.org" References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> In-Reply-To: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] TRANS Draft minutes for IETF-93 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, 24 Jul 2015 06:18:06 -0000 Thanks, Rich! Melinda On 7/23/15 11:58 AM, Salz, Rich wrote: > Please send/post corrections. > > Paul, WG Status update > Charger unchanged; need to reset milestone. > > Eran RFC6962-bis status+ > Still needs some tweaks. Suggests waiting for Google to finish their implementation to clean out all nits before WGLC > A log cannot do a single v1/v2 log, must run both in parallel. > Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, 82, 83, 84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details > Open tickets 78 (alg agility needs more description) 83 (should require deterministic ECESA) 96 (dynamic metadata; does only CA root list really change?) 95 (include get-entries response size in the log metadata, for cursoring through a log) > Steve raised issue of exposing what certs a client is interested in if size of get-entries can shrink to one, for example. > More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash lags) 93 (monitor description inconsistencies) 94 (when/why clients should fetch inclusion proofs) > Stephen raised issue fhat if threat analysis is normative, schedule gets pushed out further. Should be informative. > > Steve Kent, attack model > Name changed on doc, even if filename can't easily be changed. Not a threat model, we don't know what the attackers are thinking, but we do know possible actions so it's an attack model. > Includes an intro to CT, he prefers it move into an arch document but if not it will stay. > "CT is a set of mechanisms, designed to detect, deter, and facilitate remediation of certificate mis-issuance" > Semantic mis-issuance: name in the cert refers to an entity incorrectly. > Syntactic mis-issuance: violation of certificate profile(s) that apply. > Reviewed a taxonomy of attacks. Read the doc. Discussion of additions and bigger picture needs. > Incorporated all (but one) comments. > Wants WG agreement via list on goals, definitions, attacks. > We have a half-dozen people commit to read and review the document. > Ben agrees about having an arch doc; Steve and Ben will collaborate on an arch doc > > Dkg, Gossip > Gossip important to keep logs accountable by making sure everyone sees the same append-only data and keep their MMD/SCT promises. > Works by browser's sharing and comparing SCT and STH > Three channels: > SCTFeedback; browser sends cert/sct to website, website sends to auditing function/third-party auditor > STH Pollination: auditor/website send STH to each other. STH are not privacy-sensitive > Optional Trusted Auditor: browser passes sct/cert to auditor (e.g., the DNS resolver since it already knows what you might be looking at) > Call for adoption is on the mailing list. > > Dkg, CT for binary > Goal is to know that you are running the same software as "everyone else," not guaranteeing that the software isn't compromised. > Add a binary lLogEntryType; add binary and binary_digest to Signed_Type > Many details of what and how is signed are still open; need feedback from s/w distributors. > PHB suggest to not use ASN.1 > Discussion and agreement that changing the s/w distribution format is a non-starter. > > Rich Salz, selective logs > Some logs will not log every single cert from the CA's in their root list. > What do we do? > Discussion, no conclusion. > > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz > - > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Thu Jul 23 23:49:00 2015 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 BA0B61B2F89 for ; Thu, 23 Jul 2015 23:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jRTOA3UE-n8N for ; Thu, 23 Jul 2015 23:48:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9D71B2F8D for ; Thu, 23 Jul 2015 23:48:58 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37557 helo=dhcp-a032.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZIWmr-000Fbp-Im for trans@ietf.org; Fri, 24 Jul 2015 02:48:53 -0400 To: trans@ietf.org References: <056.62dbdd537b258354f43bc615afe9cf9d@tools.ietf.org> <071.92c1c6b2131102525cfceb5c1f5404e9@tools.ietf.org> From: Stephen Kent Message-ID: <55B1DFD4.7040608@bbn.com> Date: Fri, 24 Jul 2015 08:48:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <071.92c1c6b2131102525cfceb5c1f5404e9@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 06:48:59 -0000 Ben, > #94: Fetching of inclusion proofs: Why and when are clients expected to do this? > > Changes (by benl@google.com): > > * component: client-behavior => rfc6962-bis > > > Comment: > > I note that this question is addressed in the gossip I-D, and perhaps is > better left there? > We should remember that gossip is an Experimental vs. Standards track doc for now. Steve From nobody Fri Jul 24 03:13:13 2015 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 4C0C21A8988 for ; Fri, 24 Jul 2015 03:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 iLFNH6_Q2EXh for ; Fri, 24 Jul 2015 03:13:11 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0301A21C0 for ; Fri, 24 Jul 2015 03:13:10 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so12044428lbb.3 for ; Fri, 24 Jul 2015 03:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F8ufjCmJYxX0YVrUeYQkaYytiPlDzMRFRCGmR7GYu3U=; b=ho17n8MJz4dIGaXjYs0b0g5JSJc/Ek2O3I1DPnvj1ngJQHgH28yBxk2b2KgYKpB36h G+yjuaIfI9Xn61Be4/Qh1VX28LOeWNld6RpazV4YGNqxRLW/obuLxwhZ8m7M3MfOqVDs BDA3vrNfQTtyMsXvJOlbvprWplj0Cw2OW1GRYXXMgml+8JpR8IUD6Xv1T5SmyyL0Qwmi zFYZpkMGcfarGlBvrSKwcIqAu2wQgJvrWf8XPJ7MKl1whPOXQA4IBidcX8pps2WLfdPZ HQyW/aONfJJfRWpFyk4+z1zsKdc3A1s56oSSzgVhcTfl6W8ITyGyOLWBWLqG+0NKDIvp 3dlw== MIME-Version: 1.0 X-Received: by 10.153.6.44 with SMTP id cr12mr12706222lad.92.1437732789005; Fri, 24 Jul 2015 03:13:09 -0700 (PDT) Received: by 10.25.31.21 with HTTP; Fri, 24 Jul 2015 03:13:08 -0700 (PDT) In-Reply-To: <55B0D80C.1060600@gmail.com> References: <55B0D80C.1060600@gmail.com> Date: Fri, 24 Jul 2015 13:13:08 +0300 Message-ID: From: Dmitry Belyavsky To: Melinda Shore Content-Type: multipart/alternative; boundary=001a113430282bb2fd051b9c40ec Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:13:12 -0000 --001a113430282bb2fd051b9c40ec Content-Type: text/plain; charset=UTF-8 Hello all, Strong yes to adopt. On Thu, Jul 23, 2015 at 3:03 PM, Melinda Shore wrote: > Hi, all: > > This is a call for adoption of > http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ > as a working group deliverable. The call closes on August 6. > > -- SY, Dmitry Belyavsky --001a113430282bb2fd051b9c40ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

Strong yes to adopt.

On Thu, Jul 23, 2015 at 3:03 PM, = Melinda Shore <melinda.shore@gmail.com> wrote:
Hi, all:

This is a call for adoption of
http://datatracker.ietf.org/doc/draft-li= nus-trans-gossip-ct/
as a working group deliverable.=C2=A0 The call closes on August 6.



--
SY, Dmitry Belyavsky
--001a113430282bb2fd051b9c40ec-- From nobody Fri Jul 24 04:09:43 2015 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 D92371A8BB3 for ; Fri, 24 Jul 2015 04:09:41 -0700 (PDT) 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 UEBu8Grf0vHl for ; Fri, 24 Jul 2015 04:09:38 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589641A901F for ; Fri, 24 Jul 2015 04:09:34 -0700 (PDT) Received: by ykax123 with SMTP id x123so16823175yka.1 for ; Fri, 24 Jul 2015 04:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=NWIyGFA+0SJaPUqd6niDLg+bH7Jh/NHpIYS1OtPLOxs=; b=BP96HifKjeaCgRO8xvBY7COiYvWBFrnxkIM+6Ft8AaD/ZAf+/eXZKm/D4zcfukhpJy QXgioqX1StvyZ/epZIZdX0naNnDIY4Fc7enmzki/yZeEmOhlAo0S7+3Mp4zxN1lg3D0J 9wXXnwxd/qTiOEuAxOwr4m1p61NNKlVP8yn6KJwsxop4B+kQZGnG3bWh5ACUukeBWIzT /SctN3XkOVBbmjfR/F/qOG6F81COw6RwuKeBuUMffZnyVOv+vdyWLoyyzMZ6spzCqy5F w7PDhYmj/r9GlDs+5KgaCVrtjXq2mskk5c6UM/P0EWFCCzDRI0Mwi72q8DEM71W109Ak uo+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=NWIyGFA+0SJaPUqd6niDLg+bH7Jh/NHpIYS1OtPLOxs=; b=fbULDZjB89IDdmj+6UOV3YU6dT70VAt9ygGBsMWjKBZjSNonEmv3SibFTT0X/m1VeZ C0lt+bhxcXL6j3NcrLC8MPnqJ6lDb/Clca5eppKGqC4kRIP+rHr9sDue49t/Yj+/JAFf 89r4xgSmfSVzDD8IRiOPv/0E5TALQ4xCdP0Ygo9gSVTGbBtkyGL8OefIVQs6an4NzuMx pHf1Jz1XQCHfLyynKT/3x3YewwFkEcpH4BDyt9x3nHPwuca9TksFASwRRVlzyYmyiIBt xnaH5z6UDvLZzagJz4KvVr6JkSxIncdP50+Gbgke76eOa0JVZSsy0tMN1fyxbX91xUu9 nqzA== X-Gm-Message-State: ALoCoQn0yLKX6nzLQ/rxn1pzDqwhipLmyF6GU0HxOCOM05variZttQtjDS9pc/xWD00oQxtz47Ls X-Received: by 10.13.247.3 with SMTP id h3mr14839403ywf.142.1437736172777; Fri, 24 Jul 2015 04:09:32 -0700 (PDT) MIME-Version: 1.0 References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> In-Reply-To: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> From: Ben Laurie Date: Fri, 24 Jul 2015 11:09:23 +0000 Message-ID: To: Bryan Ford , trans@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0802a0dc4246051b9d09ad Archived-At: Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 11:09:42 -0000 --94eb2c0802a0dc4246051b9d09ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 23 Jul 2015 at 23:27 Bryan Ford wrote: > *From: *Melinda Shore > *Subject: **[Trans] Call for adoption, draft-linus-trans-gossip-ct* > *Date: *July 23, 2015 at 2:03:24 PM GMT+2 > *To: *"trans@ietf.org" > > > Hi, all: > > This is a call for adoption of > http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ > as a working group deliverable. The call closes on August 6. > > > While the draft represents a fine start at defining a gossip mechanism, I > would like to express serious reservations about the draft=E2=80=99s basi= c premise > that a gossip mechanism is the best approach - or even an adequate approa= ch > - =E2=80=9Cto detect misbehavior by CT logs=E2=80=9D, to quote the draft= =E2=80=99s self-stated > purpose. As such, I have serious reservations about the WG adopting the > draft, not because there=E2=80=99s anything wrong with the content of the= draft per > se but because gossip is simply not the right approach. > > First, the gossip approach creates severe privacy problems, which are > already well-discussed so I won=E2=80=99t reiterate them. > Actually, I think you need to reiterate them, since we think that gossip as proposed does _not_ create privacy problems. > > Second, the gossip approach can=E2=80=99t ensure that privacy-sensitive W= eb > clients (who can=E2=80=99t or don=E2=80=99t want to reveal their whole br= owsing history to > a Trusted Auditor) will ever actually be able =E2=80=9Cto detect misbehav= ior by CT > logs=E2=80=9D, if for example the misbehaving log=E2=80=99s private key i= s controlled by a > MITM attacker between the Web client and the website the client thinks he > is visiting. > The intent of CT is not to enable clients to detect such behaviour - rather, it is to enable the system as a whole to detect it. > > Suppose, for example, it ever so happens that a single company ends up > running both a log server and a [sub-]CA, and keeps both in the same > poorly-protected safe. If an attacker can steal those two private keys, > then the attacker can silently MITM any CT-aware client all it wants, by > producing all the [non-EV] certificates it needs with a valid SCT, valid > STH inclusion proofs in a fake log, etc. > Chrome's policy would require the subversion of at least two logs to achieve this, but for the sake of argument, I'll concede that. > The web client isn=E2=80=99t going to learn about the problem via gossip= with the > website because that=E2=80=99s the MITM attacker, and the client can=E2= =80=99t gossip with > anyone else without the serious privacy risk of trusting a single audit > server with his entire browsing history. If the =E2=80=9Ctrusted audit s= erver=E2=80=9D is > actually co-located with the client, then the audit server in turn can=E2= =80=99t > gossip with the rest of the world without creating the same privacy risk. > Even if the client does voluntarily gossip with a remote trusted audit > server, the MITM attacker - e.g., an ISP-level or state-level attacker - > might simply block connections to all well-known audit servers. > This attack relies on a MitM that is sustained forever but indeed would succeed. We accept that CT cannot defeat such an attack. > > Is it =E2=80=9Ctoo unlikely=E2=80=9D that an attacker can compromise both= a log server key > and a CA key? Even if some CT policy is established that a single compan= y > is never allowed to run both a log server and hold a [sub-]CA key, which > might not be a bad idea, it doesn=E2=80=99t seem beyond reason that some > state-level attackers are incapable of quietly exfiltrating (or just > quietly subpoenaing) both a log server key and a CA key, and then they ge= t > the same, silent MITM power as they can get now. > > Thus, while CT does potentially =E2=80=9Craise the bar=E2=80=9D a bit by = requiring a MITM > attacker to steal both [any one] CA key and [any one] log server key, the > set of all well-known log servers still just forms another new weakest-li= nk > security chain, just like the set of all CAs and sub-CAs form an old > weakest-link security chain. While =E2=80=9Cbest of two weakest-link cha= ins=E2=80=9D is > admittedly better than one weakest-link chain, it does not seem like the > best we can do or the target we should be aiming for. > > I posted an E-mail last week suggesting an alternative approach, in which > log servers would not individually sign their STHs but instead collective= ly > sign them with the active participation of (a suitable quorum of) the > auditors and/or monitors watching their logs. But I got no response to > that, so I=E2=80=99d like to try again. > > In short: the log server would propose log entries, but the auditors > and/or monitors contribute to the STH signature, only after performing at > least the =E2=80=9Cauditing=E2=80=9D function of verifying that the log s= erver is behaving > like a correct log server. In particular, all participants could > proactively verify that the log server never forks or reverts the log, > never signs something syntactically invalid or with a wildly-incorrect > timestamp (say +/- 24 hours), etc. Then, even if the log server=E2=80=99= s private > key was successfully stolen by a state-level attacker (and the attacker > perhaps even compromises a minority of the monitor/auditor keys), the > attacker will be unable to forge an STH signature that a Web client or > anyone else will believe. > > This would, in effect, convert each log server from yet another juicy > central attack target into a strongest-link set (I like to use the term > =E2=80=9Ccothority=E2=80=9D or collective authority) with all the monitor= and auditor > servers watching it and contributing to its signatures. Of course, the > attacker still wins if he successfully compromises any single CA (or > sub-CA) *and* any single =E2=80=9Clogging cothority=E2=80=9D (i.e., any l= og server *and* a > sufficient quorum of its followers). But doing the latter becomes way, w= ay > harder if there=E2=80=99s enough size and diversity in each logging cotho= rity. > > How does this improve things for the Web client in Repressistan who's > getting MITM attacked? If the client is only looking at SCTs that are > individually signed by a log server (and are in any case only a =E2=80=9C= promise to > log soon=E2=80=9D and not actual evidence that the cert has been logged),= then > unfortunately not much: the MITM attacker can still forge at least one SC= T > for each of its forged certs, and no one else learns because the MITM can > keep the client=E2=80=99s view isolated from the rest of the world. > > But say we enhance CT so clients can demand STHs *with* cert inclusion > proofs from the web servers they talk to - as I suggested in the meeting > today, and which I believe Ben Laurie mentioned is already in the works. > Then any Web client that does this will be proactively protected from MIT= M > attacks involving faked, forked, or otherwise bad log entries. And the > client doesn=E2=80=99t have to compromise its privacy by gossiping with a= nyone. > Two points here: 1. Is this any different to requiring n SCTs from different logs for each certificate (other than the inclusion proof part, which I address below)? 2. Our original design for CT did indeed have certs served along with an STH and an inclusion proof. Unfortunately, CAs categorically rejected this approach because of the latency it introduced in the certificate issuance process. Personally, I think it would be a better approach. Now CAs are more accepting of CT, perhaps it would be worth revisiting the question with them? > > Bryan > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c0802a0dc4246051b9d09ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , 23 Jul 2015 at 23:27 Bryan Ford <brynosaurus@gmail.com> wrote:
From: Melinda Shore <melinda.shore@gmail.com>
Subject: [Trans] Call for = adoption, draft-linus-trans-gossip-ct
Date: July 23, 2015 at 2:0= 3:24 PM GMT+2

Hi, all:

This is a call for adoption of
http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/
as a w= orking group deliverable.=C2=A0 The call closes on August 6.

While the draft rep= resents a fine start at defining a gossip mechanism, I would like to expres= s serious reservations about the draft=E2=80=99s basic premise that a gossi= p mechanism is the best approach - or even an adequate approach - =E2=80=9C= to detect misbehavior by CT logs=E2=80=9D, to quote the draft=E2=80=99s sel= f-stated purpose.=C2=A0 As such, I have serious reservations about the WG a= dopting the draft, not because there=E2=80=99s anything wrong with the cont= ent of the draft per se but because gossip is simply not the right approach= .

First, the gossip approach creates severe privac= y problems, which are already well-discussed so I won=E2=80=99t reiterate t= hem.

Actually, I think yo= u need to reiterate them, since we think that gossip as proposed does _not_= create privacy problems.
=C2=A0

Second, th= e gossip approach can=E2=80=99t ensure that privacy-sensitive Web clients (= who can=E2=80=99t or don=E2=80=99t want to reveal their whole browsing hist= ory to a Trusted Auditor) will ever actually be able =E2=80=9Cto detect mis= behavior by CT logs=E2=80=9D, if for example the misbehaving log=E2=80=99s = private key is controlled by a MITM attacker between the Web client and the= website the client thinks he is visiting.

The intent of CT is not to enable clients to detect such = behaviour - rather, it is to enable the system as a whole to detect it.
=C2=A0

Suppose, for example, it ever so happen= s that a single company ends up running both a log server and a [sub-]CA, a= nd keeps both in the same poorly-protected safe.=C2=A0 If an attacker can s= teal those two private keys, then the attacker can silently MITM any CT-awa= re client all it wants, by producing all the [non-EV] certificates it needs= with a valid SCT, valid STH inclusion proofs in a fake log, etc.

Chrome's policy would require = the subversion of at least two logs to achieve this, but for the sake of ar= gument, I'll concede that.
=C2=A0
=C2=A0The web clien= t isn=E2=80=99t going to learn about the problem via gossip with the websit= e because that=E2=80=99s the MITM attacker, and the client can=E2=80=99t go= ssip with anyone else without the serious privacy risk of trusting a single= audit server with his entire browsing history.=C2=A0 If the =E2=80=9Ctrust= ed audit server=E2=80=9D is actually co-located with the client, then the a= udit server in turn can=E2=80=99t gossip with the rest of the world without= creating the same privacy risk.=C2=A0 Even if the client does voluntarily = gossip with a remote trusted audit server, the MITM attacker - e.g., an ISP= -level or state-level attacker - might simply block connections to all well= -known audit servers.

Thi= s attack relies on a MitM that is sustained forever but indeed would succee= d. We accept that CT cannot defeat such an attack.=C2=A0

<= div>Is it =E2=80=9Ctoo unlikely=E2=80=9D that an attacker can compromise bo= th a log server key and a CA key?=C2=A0 Even if some CT policy is establish= ed that a single company is never allowed to run both a log server and hold= a [sub-]CA key, which might not be a bad idea, it doesn=E2=80=99t seem bey= ond reason that some state-level attackers are incapable of quietly exfiltr= ating (or just quietly subpoenaing) both a log server key and a CA key, and= then they get the same, silent MITM power as they can get now.
<= br>
Thus, while CT does potentially =E2=80=9Craise the bar=E2=80= =9D a bit by requiring a MITM attacker to steal both [any one] CA key and [= any one] log server key, the set of all well-known log servers still just f= orms another new weakest-link security chain, just like the set of all CAs = and sub-CAs form an old weakest-link security chain.=C2=A0 While =E2=80=9Cb= est of two weakest-link chains=E2=80=9D is admittedly better than one weake= st-link chain, it does not seem like the best we can do or the target we sh= ould be aiming for.

I posted an E-mail last week s= uggesting an alternative approach, in which log servers would not individua= lly sign their STHs but instead collectively sign them with the active part= icipation of (a suitable quorum of) the auditors and/or monitors watching t= heir logs.=C2=A0 But I got no response to that, so I=E2=80=99d like to try = again.

In short: the log server would propose log = entries, but the auditors and/or monitors contribute to the STH signature, = only after performing at least the =E2=80=9Cauditing=E2=80=9D function of v= erifying that the log server is behaving like a correct log server.=C2=A0 I= n particular, all participants could proactively verify that the log server= never forks or reverts the log, never signs something syntactically invali= d or with a wildly-incorrect timestamp (say +/- 24 hours), etc.=C2=A0 Then,= even if the log server=E2=80=99s private key was successfully stolen by a = state-level attacker (and the attacker perhaps even compromises a minority = of the monitor/auditor keys), the attacker will be unable to forge an STH s= ignature that a Web client or anyone else will believe.

This would, in effect, convert each log server from yet another juicy= central attack target into a strongest-link set (I like to use the term = =E2=80=9Ccothority=E2=80=9D or collective authority) with all the monitor a= nd auditor servers watching it and contributing to its signatures.=C2=A0 Of= course, the attacker still wins if he successfully compromises any single = CA (or sub-CA) *and* any single =E2=80=9Clogging cothority=E2=80=9D (i.e., = any log server *and* a sufficient quorum of its followers).=C2=A0 But doing= the latter becomes way, way harder if there=E2=80=99s enough size and dive= rsity in each logging cothority.

How does this imp= rove things for the Web client in Repressistan who's getting MITM attac= ked?=C2=A0 If the client is only looking at SCTs that are individually sign= ed by a log server (and are in any case only a =E2=80=9Cpromise to log soon= =E2=80=9D and not actual evidence that the cert has been logged), then unfo= rtunately not much: the MITM attacker can still forge at least one SCT for = each of its forged certs, and no one else learns because the MITM can keep = the client=E2=80=99s view isolated from the rest of the world.
But say we enhance CT so clients can demand STHs *with* cert i= nclusion proofs from the web servers they talk to - as I suggested in the m= eeting today, and which I believe Ben Laurie mentioned is already in the wo= rks.=C2=A0 Then any Web client that does this will be proactively protected= from MITM attacks involving faked, forked, or otherwise bad log entries.= =C2=A0 And the client doesn=E2=80=99t have to compromise its privacy by gos= siping with anyone.

Two p= oints here:

1. Is this any different to requiring = n SCTs from different logs for each certificate (other than the inclusion p= roof part, which I address below)?

2. Our original= design for CT did indeed have certs served along with an STH and an inclus= ion proof. Unfortunately, CAs categorically rejected this approach because = of the latency it introduced in the certificate issuance process. Personall= y, I think it would be a better approach. Now CAs are more accepting of CT,= perhaps it would be worth revisiting the question with them?
=C2= =A0

Bryan
__________________________= _____________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--94eb2c0802a0dc4246051b9d09ad-- From nobody Fri Jul 24 04:24:46 2015 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 C15871A90EC for ; Fri, 24 Jul 2015 04:24:45 -0700 (PDT) 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 PkY4XBkA5O6m for ; Fri, 24 Jul 2015 04:24:44 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981E61A90D4 for ; Fri, 24 Jul 2015 04:24:44 -0700 (PDT) Received: by ykdu72 with SMTP id u72so17004877ykd.2 for ; Fri, 24 Jul 2015 04:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=Bof4I7q8S/C02bv5cSzvVav+UmwSXirJIUQygSDJ8qA=; b=pQ39gWItQUxXnAz+i5Co3WcrVC2BxJmS9Tz6kdeBuTaF4elmumGGKPyJSiCI1XwrYQ kihhFjiUHWWBRAzX1Uf1bVzScoYz3rBYNc8UA2eIuxipRVCvMksCZ9Vzxig+zVoGzmF/ tdtl3mY2qg8mFMFhTks9F71mFrNbf7DIhXXvxDvC9rDqlntWM+uD0oC2LSCSYOZmViLs ZVCk+d1CYtrju8PZSok3B4lFkCd+JExIivfeEEE0CeT+tE2vAOJOMn8mYVkkKVBvLUOm QweLvtMs3to39i0S71e9IgTzFwHS1HOKaXeUqpSBg3WxSdFpzh2XrCFeDNAs7QK6SRBp V7SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=Bof4I7q8S/C02bv5cSzvVav+UmwSXirJIUQygSDJ8qA=; b=P/NEvXfTFy/PTvQK3dpIxBhH35HlVkYJINwUByzkmio//UUrLKfLu0MBYJbztE7HJK 5ZRh2CLWNKOpCnm2xqgFpaoX/ghnl56nquitxQC5LiitaOibrIwqb2/i84rbsjyaYe1F ezjMo457yVvJLl1emYEhNLEfQg6rc35/MRq8oMPaWF+Eck3BRx9fr3gEuX4jhmX8WokS RTHXZvAJABighjN706sU7HuXeA1PYGGrk52k0/WLxB4J5xJHvaUs7hbGku8Un8KMeVwH lIjZUYGhCZM2kcTq8U7B/sBic70FIeUS76UbX/D+U2Yn1FpEY1bZL+Iu/xqehY5L6FZq pcjw== X-Gm-Message-State: ALoCoQmW8iMTvf84BCIEUuBHxhotjawinaxUirbEnmmdXmusNNylYCi+ZM5jD24zvDi4UbkGM9Wl X-Received: by 10.170.119.85 with SMTP id l82mr14528748ykb.89.1437737084019; Fri, 24 Jul 2015 04:24:44 -0700 (PDT) MIME-Version: 1.0 References: <056.62dbdd537b258354f43bc615afe9cf9d@tools.ietf.org> <071.92c1c6b2131102525cfceb5c1f5404e9@tools.ietf.org> <55B1DFD4.7040608@bbn.com> In-Reply-To: <55B1DFD4.7040608@bbn.com> From: Ben Laurie Date: Fri, 24 Jul 2015 11:24:34 +0000 Message-ID: To: Stephen Kent , trans@ietf.org Content-Type: multipart/alternative; boundary=001a113908ec2c8a6f051b9d40ae Archived-At: Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 11:24:45 -0000 --001a113908ec2c8a6f051b9d40ae Content-Type: text/plain; charset=UTF-8 On Fri, 24 Jul 2015 at 07:49 Stephen Kent wrote: > Ben, > > > #94: Fetching of inclusion proofs: Why and when are clients expected to > do this? > > > > Changes (by benl@google.com): > > > > * component: client-behavior => rfc6962-bis > > > > > > Comment: > > > > I note that this question is addressed in the gossip I-D, and perhaps > is > > better left there? > > > We should remember that gossip is an Experimental vs. Standards track > doc for now. > OK, but given yesterday's discussion, seems like the architecture doc is an even better home. > > Steve > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113908ec2c8a6f051b9d40ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , 24 Jul 2015 at 07:49 Stephen Kent <ken= t@bbn.com> wrote:
Ben,

> #94: Fetching of inclusion proofs: Why and when are clients expected t= o do this?
>
> Changes (by benl@= google.com):
>
>=C2=A0 =C2=A0* component:=C2=A0 client-behavior =3D> rfc6962-bis
>
>
> Comment:
>
>=C2=A0 =C2=A0I note that this question is addressed in the gossip I-D, = and perhaps is
>=C2=A0 =C2=A0better left there?
>
We should remember that gossip is an Experimental vs. Standards track
doc for now.

OK, but given yesterday= 9;s discussion, seems like the architecture doc is an even better home.
=C2=A0

Steve

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a113908ec2c8a6f051b9d40ae-- From nobody Fri Jul 24 04:29:09 2015 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 2C6541A910E for ; Fri, 24 Jul 2015 04:29:06 -0700 (PDT) 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 BhyhKPEQyNEf for ; Fri, 24 Jul 2015 04:29:04 -0700 (PDT) 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 D40031A9034 for ; Fri, 24 Jul 2015 04:29:03 -0700 (PDT) Received: by ykfw194 with SMTP id w194so17163329ykf.0 for ; Fri, 24 Jul 2015 04:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=Y6o1Jec/ggHDgPJuvfEl/f7ju027BEdYmxiKVH5CqRw=; b=pLX2fVR4TzpaHxw5av9G0/PPrylh1L3b1a1yWzi4McaqpAvNjlOtvwWhi4pkShNrMz zsk2LG2v/sliuys7Igw8XQu6Zb971DyfXYFyBzh8Kt7A3yrAzW3j3dzdZlgdqad7OC45 p9ZkwPPp51IVPS6RO8oRtN5mIPY2GI0zVeHhWj6NHdmNHF7N8GJdzJJAfVVLuyF/PaDr r5D1lKmosIeQIQCkxbfuhWUfq/qiapXUiBb9Uvfkx8yfDSKomrSr2k9RqPvRniUFSAJS Zwk05TyVNXEzxgy3BSJebnDMvmuwj7JiS77Fd4zHtf+xQs01oN5qqhNxiRHIkGX+QdbZ ip3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=Y6o1Jec/ggHDgPJuvfEl/f7ju027BEdYmxiKVH5CqRw=; b=mPODoh45Q42BAvUKuLLdMb811ReMxsBQB7DGv9VHImrV+4do6rlgEylPQoDQId5I0g zrW8PufskWxh3fxWknJKWNVpTYmLwZ4qDh8L1maQ5OwxUJ1qCRwg53Zp0qtVfNRj14in KJMOTKT7gBZjg6yRaR9uJXct0anDjBOqQ+BvmZe3mf7nRirm+D+FLHppci+sJ1b3qQSt +1DqfCMfc7nKOCMHelgPMWQIaZ5UUcR671/Ad1p4b/vfpBTj96rIQCIq31YBtR5I+M1O dLMGT7Do1m6wxyGZqRZ6IycvY3Kl46kUAbHiWUPvUfeix5fhjBcg1eTOYO0iGTJxyn9l iJsQ== X-Gm-Message-State: ALoCoQl79MxAlPSCRVXqsBzc3yRn2z4mvmfEoEC+otz/PA0jYEFd1AtCJUPgAblkij6kvZYuq/6n X-Received: by 10.129.108.2 with SMTP id h2mr14319629ywc.161.1437737343210; Fri, 24 Jul 2015 04:29:03 -0700 (PDT) MIME-Version: 1.0 References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> In-Reply-To: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> From: Ben Laurie Date: Fri, 24 Jul 2015 11:28:53 +0000 Message-ID: To: "Salz, Rich" , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a114dae7a9faafb051b9d4f64 Archived-At: Subject: Re: [Trans] TRANS Draft minutes for IETF-93 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, 24 Jul 2015 11:29:06 -0000 --001a114dae7a9faafb051b9d4f64 Content-Type: text/plain; charset=UTF-8 On Thu, 23 Jul 2015 at 20:59 Salz, Rich wrote: > Please send/post corrections. > > Paul, WG Status update > Charger unchanged; need to reset milestone. > > Eran RFC6962-bis status+ > Still needs some tweaks. Suggests waiting for Google to finish their > implementation to clean out all nits before WGLC > A log cannot do a single v1/v2 log, must run both in parallel. > Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, 82, > 83, 84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details > Open tickets 78 (alg agility needs more description) 83 (should require > deterministic ECESA) 96 (dynamic metadata; does only CA root list really > change?) 95 (include get-entries response size in the log metadata, for > cursoring through a log) > Steve raised issue of exposing what certs a client is interested in if > size of get-entries can shrink to one, for example. > My response was omitted: this doesn't matter so long as the client continues to request entries until it has all the ones it originally decided to fetch. > More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash > lags) 93 (monitor description inconsistencies) 94 (when/why clients should > fetch inclusion proofs) > Stephen raised issue fhat if threat analysis is normative, schedule gets > pushed out further. Should be informative. > > Steve Kent, attack model > Name changed on doc, even if filename can't easily be changed. Not a > threat model, we don't know what the attackers are thinking, but we do know > possible actions so it's an attack model. > Includes an intro to CT, he prefers it move into an arch document but if > not it will stay. > "CT is a set of mechanisms, designed to detect, deter, and facilitate > remediation of certificate mis-issuance" > Semantic mis-issuance: name in the cert refers to an entity incorrectly. > Syntactic mis-issuance: violation of certificate profile(s) that apply. > Reviewed a taxonomy of attacks. Read the doc. Discussion of additions > and bigger picture needs. > Incorporated all (but one) comments. > Wants WG agreement via list on goals, definitions, attacks. > We have a half-dozen people commit to read and review the document. > Ben agrees about having an arch doc; Steve and Ben will collaborate on an > arch doc > I thought I heard other volunteers. :-) > > Dkg, Gossip > Gossip important to keep logs accountable by making sure everyone sees the > same append-only data and keep their MMD/SCT promises. > Works by browser's sharing and comparing SCT and STH > Three channels: > SCTFeedback; browser sends cert/sct to website, website sends to > auditing function/third-party auditor > STH Pollination: auditor/website send STH to each other. STH are > not privacy-sensitive > Optional Trusted Auditor: browser passes sct/cert to auditor > (e.g., the DNS resolver since it already knows what you might be looking at) > Call for adoption is on the mailing list. > > Dkg, CT for binary > Goal is to know that you are running the same software as "everyone else," > not guaranteeing that the software isn't compromised. > Add a binary lLogEntryType; add binary and binary_digest to Signed_Type > Many details of what and how is signed are still open; need feedback from > s/w distributors. > PHB suggest to not use ASN.1 > Discussion and agreement that changing the s/w distribution format is a > non-starter. > dkg also noted that some distros (at least Debian and FreeBSD) have been discussing the question of what exactly should go in the logs. We'd like to hear from anyone interested in joining those discussions. > > Rich Salz, selective logs > Some logs will not log every single cert from the CA's in their root list. > What do we do? > Discussion, no conclusion. > > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz > - > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114dae7a9faafb051b9d4f64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu= , 23 Jul 2015 at 20:59 Salz, Rich <r= salz@akamai.com> wrote:
Plea= se send/post corrections.

Paul, WG Status update
Charger unchanged; need to reset milestone.

Eran RFC6962-bis status+
Still needs some tweaks. Suggests waiting for Google to finish their implem= entation to clean out all nits before WGLC
A log cannot do a single v1/v2 log, must run both in parallel.
Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, 82, = 83,=C2=A0 84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details
Open tickets 78 (alg agility needs more description) 83 (should require det= erministic ECESA) 96 (dynamic metadata; does only CA root list really chang= e?) 95 (include get-entries response size in the log metadata, for cursorin= g through a log)
Steve raised issue of exposing what certs a client is interested in if size= of get-entries can shrink to one, for example.

My response was omitted: this doesn't matter so long as the cl= ient continues to request entries until it has all the ones it originally d= ecided to fetch.
=C2=A0
More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash = lags) 93 (monitor description inconsistencies) 94 (when/why clients should = fetch inclusion proofs)
Stephen raised issue fhat if threat analysis is normative, schedule gets pu= shed out further. Should be informative.

Steve Kent, attack model
Name changed on doc, even if filename can't easily be changed. Not a th= reat model, we don't know what the attackers are thinking, but we do kn= ow possible actions so it's an attack model.
Includes an intro to CT, he prefers it move into an arch document but if no= t it will stay.
"CT is a set of mechanisms, designed to detect, deter, and facilitate = remediation of certificate mis-issuance"
Semantic mis-issuance: name in the cert refers to an entity incorrectly. Syntactic mis-issuance: violation of certificate profile(s) that apply.
Reviewed a taxonomy of attacks.=C2=A0 Read the doc.=C2=A0 Discussion of add= itions and bigger picture needs.
Incorporated all (but one) comments.
Wants WG agreement via list on goals, definitions, attacks.
We have a half-dozen people commit to read and review the document.
Ben agrees about having an arch doc; Steve and Ben will collaborate on an a= rch doc

I thought I heard other volunte= ers. :-)
=C2=A0

Dkg, Gossip
Gossip important to keep logs accountable by making sure everyone sees the = same append-only data and keep their MMD/SCT promises.
Works by browser's sharing and comparing SCT and STH
Three channels:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SCTFeedback;=C2=A0 browser sends cert/sct to we= bsite, website sends to auditing function/third-party auditor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STH Pollination: auditor/website send STH to ea= ch other.=C2=A0 STH are not privacy-sensitive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Optional Trusted Auditor: browser passes sct/ce= rt to auditor (e.g., the DNS resolver since it already knows what you might= be looking at)
Call for adoption is on the mailing list.

Dkg, CT for binary
Goal is to know that you are running the same software as "everyone el= se," not guaranteeing that the software isn't compromised.
Add a binary lLogEntryType; add binary and binary_digest to Signed_Type
Many details of what and how is signed are still open; need feedback from s= /w distributors.
PHB suggest to not use ASN.1
Discussion and agreement that changing the s/w distribution format is a non= -starter.

dkg also noted that some dist= ros (at least Debian and FreeBSD) have been discussing the question of what= exactly should go in the logs. We'd like to hear from anyone intereste= d in joining those discussions.=C2=A0

Rich Salz, selective logs
Some logs will not log every single cert from the CA's in their root li= st.
What do we do?
Discussion, no conclusion.

--
Senior Architect, Akamai Technologies
IM: richsalz@jabber= .at Twitter: RichSalz
-

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a114dae7a9faafb051b9d4f64-- From nobody Fri Jul 24 06:09:12 2015 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 8FCA01A88E6 for ; Fri, 24 Jul 2015 06:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, 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 ysybe5hrmoRI for ; Fri, 24 Jul 2015 06:09:07 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mail1.comodoca.com [91.209.196.72]) (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 582041A88D6 for ; Fri, 24 Jul 2015 06:09:07 -0700 (PDT) Received: (qmail 26144 invoked by uid 1004); 24 Jul 2015 13:09:04 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 24 Jul 2015 14:09:04 +0100 Received: (qmail 13980 invoked by uid 1000); 24 Jul 2015 13:09:04 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 24 Jul 2015 14:09:04 +0100 To: Ben Laurie , Bryan Ford , trans@ietf.org References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> From: Rob Stradling Message-ID: <55B238F0.2080207@comodo.com> Date: Fri, 24 Jul 2015 14:09:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 13:09:10 -0000 On 24/07/15 12:09, Ben Laurie wrote: > But say we enhance CT so clients can demand STHs *with* cert > inclusion proofs from the web servers they talk to - as I suggested > in the meeting today, and which I believe Ben Laurie mentioned is > already in the works. Then any Web client that does this will be > proactively protected from MITM attacks involving faked, forked, or > otherwise bad log entries. And the client doesn’t have to > compromise its privacy by gossiping with anyone. > 2. Our original design for CT did indeed have certs served along with an > STH and an inclusion proof. Unfortunately, CAs categorically rejected > this approach because of the latency it introduced in the certificate > issuance process. Personally, I think it would be a better approach. Now > CAs are more accepting of CT, perhaps it would be worth revisiting the > question with them? I think we need to make this approach available as an option. We should retain the lower-latency option (i.e. SCTs) too though. TRAC ticket 10 already aims to do this. DV certs are typically validated and issued quickly. For EV certs and name-constrained Sub-CA certs, the process can take days/weeks/months, so added latency in issuance may be less of a concern. When OCSP Stapling and/or the CT TLS extension are used to convey "CT objects" to TLS clients, the TLS server could send SCTs for the first few hours, then switch to sending inclusion proofs / STHs once the log has generated them. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jul 24 07:11:04 2015 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 BCA601A1B00 for ; Fri, 24 Jul 2015 07:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s85EjNLWexlD for ; Fri, 24 Jul 2015 07:11:01 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9081A1A58 for ; Fri, 24 Jul 2015 07:11:01 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so66448084wic.0 for ; Fri, 24 Jul 2015 07:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=arBmSAsYR9IZzOEWENp5TWAwMYvULZmOi8Zoqj0ink8=; b=tJ2zaBDLCq0a/0morvmSRfAoKCNXNJB+AKVbl8QIhfPc7oue3NWX1OpSMDy6LzHDeB ww28RpJjab0wnUrKajoZYX8yQPew8ULO1CfAuthpUshFqFR4OxvdM73B0qvvPFLIoqK7 5Jd+eCmwr6znZizNhc7uX5En5/hRWXNL4jFq0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=arBmSAsYR9IZzOEWENp5TWAwMYvULZmOi8Zoqj0ink8=; b=CVJohL9xR8nLewwAhH+nFV0oZrllUQkU55+YXc96FrZPu1s0w3udpeLjfwIkyoeCo6 BIw7WQQzosAFhNl5r9cqUYwMYapP8flykIvZV/bbQNfTn9clml5m/pOBpQGueojD/wAh ke3z+NE4zs1PR1K+kcSf9ZfF8hqOCi6TsuavtEagNtEWXEZeEpAff9WWWFXUpG6twXEj uYdrfvAp3JSTztLCp3hLyEDPp3MvqE+px/spVt3S4wzeoQ9ecNcdbWGJ7Jim9HVONRW9 QpYCuuzzPaOIF9HAZU1sy1QXmqJpmxxViAAZXO39XbcM0s3znBfbl4KMe3Xupme8SW0g 4hvg== X-Gm-Message-State: ALoCoQk7gRPQG2k5LiMEi54ftdLxFiUESqAlZBPNSxLW29qIXfxeY61EDxLr/t5ltV0MmMnKodpa X-Received: by 10.180.211.196 with SMTP id ne4mr7805609wic.23.1437747060103; Fri, 24 Jul 2015 07:11:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.67 with HTTP; Fri, 24 Jul 2015 07:10:40 -0700 (PDT) In-Reply-To: <55B238F0.2080207@comodo.com> References: <6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com> <55B238F0.2080207@comodo.com> From: Tom Ritter Date: Fri, 24 Jul 2015 09:10:40 -0500 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "trans@ietf.org" , Ben Laurie , Bryan Ford Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 14:11:02 -0000 I'm an author, so +1 to adopt? I reiterate Ben's point that we don't believe this draft has privacy problems. (Well you can _opt in_ to having privacy problems by using a trusted auditor, which does leak your browsing history, but that's not the expected use case for most clients by far. The other two approaches are designed to be privacy preserving.) On 24 July 2015 at 08:09, Rob Stradling wrote: > On 24/07/15 12:09, Ben Laurie wrote: > >> >> But say we enhance CT so clients can demand STHs *with* cert >> inclusion proofs from the web servers they talk to - as I suggested >> in the meeting today, and which I believe Ben Laurie mentioned is >> already in the works. Then any Web client that does this will be >> proactively protected from MITM attacks involving faked, forked, or >> otherwise bad log entries. And the client doesn=E2=80=99t have to >> compromise its privacy by gossiping with anyone. > > >> >> 2. Our original design for CT did indeed have certs served along with an >> STH and an inclusion proof. Unfortunately, CAs categorically rejected >> this approach because of the latency it introduced in the certificate >> issuance process. Personally, I think it would be a better approach. Now >> CAs are more accepting of CT, perhaps it would be worth revisiting the >> question with them? > > > I think we need to make this approach available as an option. We should > retain the lower-latency option (i.e. SCTs) too though. > > TRAC ticket 10 already aims to do this. > > DV certs are typically validated and issued quickly. For EV certs and > name-constrained Sub-CA certs, the process can take days/weeks/months, so > added latency in issuance may be less of a concern. > > When OCSP Stapling and/or the CT TLS extension are used to convey "CT > objects" to TLS clients, the TLS server could send SCTs for the first few > hours, then switch to sending inclusion proofs / STHs once the log has > generated them. I like it. I like the OCSP approach better than Certs though, because it eliminates the requirement of "private-enough DNS" to retrieve Inclusion Proofs in STH Pollination, and lets more privacy-concerned clients participate in STH Pollination. (Because an Inclusion Proof to a STH in a cert would be a very old STH, which we could not gossip because (over time) that STH will become rarer and rarer and probably lead to a fingerprint. -tom From nobody Fri Jul 24 08:25:49 2015 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 AD3931A8748 for ; Fri, 24 Jul 2015 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 XDfnLyDuYi0x for ; Fri, 24 Jul 2015 08:25:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED2C1A872E for ; Fri, 24 Jul 2015 08:25:46 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:45289 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZIer2-000PLk-NB for trans@ietf.org; Fri, 24 Jul 2015 11:25:44 -0400 To: trans@ietf.org References: <056.62dbdd537b258354f43bc615afe9cf9d@tools.ietf.org> <071.92c1c6b2131102525cfceb5c1f5404e9@tools.ietf.org> <55B1DFD4.7040608@bbn.com> From: Stephen Kent Message-ID: <55B258F8.5060803@bbn.com> Date: Fri, 24 Jul 2015 17:25:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020401020208040001000408" Archived-At: Subject: Re: [Trans] [trans] #94 (rfc6962-bis): Fetching of inclusion proofs: Why and when are clients expected to do this? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 15:25:47 -0000 This is a multi-part message in MIME format. --------------020401020208040001000408 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ben, > > > On Fri, 24 Jul 2015 at 07:49 Stephen Kent > wrote: > > Ben, > > > #94: Fetching of inclusion proofs: Why and when are clients > expected to do this? > > > > Changes (by benl@google.com ): > > > > * component: client-behavior => rfc6962-bis > > > > > > Comment: > > > > I note that this question is addressed in the gossip I-D, and > perhaps is > > better left there? > > > We should remember that gossip is an Experimental vs. Standards track > doc for now. > > > OK, but given yesterday's discussion, seems like the architecture doc > is an even better home. works for me. Steve --------------020401020208040001000408 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,




On Fri, 24 Jul 2015 at 07:49 Stephen Kent <kent@bbn.com> wrote:
Ben,

> #94: Fetching of inclusion proofs: Why and when are clients expected to do this?
>
> Changes (by benl@google.com):
>
>   * component:  client-behavior => rfc6962-bis
>
>
> Comment:
>
>   I note that this question is addressed in the gossip I-D, and perhaps is
>   better left there?
>
We should remember that gossip is an Experimental vs. Standards track
doc for now.

OK, but given yesterday's discussion, seems like the architecture doc is an even better home.
works for me.

Steve
--------------020401020208040001000408-- From nobody Fri Jul 24 08:27:59 2015 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 459061A8A77 for ; Fri, 24 Jul 2015 08:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wkbINcgCVQsM for ; Fri, 24 Jul 2015 08:27:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408AF1ACD91 for ; Fri, 24 Jul 2015 08:27:57 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:45304 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZIetA-000PU6-9G for trans@ietf.org; Fri, 24 Jul 2015 11:27:56 -0400 To: trans@ietf.org References: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> <071.d89581d27373926c935925fea3620bd1@tools.ietf.org> From: Stephen Kent Message-ID: <55B2597B.20808@bbn.com> Date: Fri, 24 Jul 2015 17:27:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <071.d89581d27373926c935925fea3620bd1@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #95 (rfc6962-bis): The response size to get-entries should be a part of the log metadata 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, 24 Jul 2015 15:27:58 -0000 I am now convinced that the response size may have to vary dynamically. I suggest the log spec (aka 6962-bis) should mandate a minimum size for the get-entries query for all logs (to address privacy concerns). Steve > #95: The response size to get-entries should be a part of the log metadata > > > Comment (by benl@google.com): > > Disagree. Whilst I can see there might be some slight advantage to the > client, what would we do if the server broke the promise, and why? > > Also, response size limit may be based on dynamic considerations (load, > caching, size of responses, etc). > From nobody Fri Jul 24 08:30:24 2015 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 691E41A6F3C for ; Fri, 24 Jul 2015 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 53lPxogkQA1X for ; Fri, 24 Jul 2015 08:30:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4161A03C7 for ; Fri, 24 Jul 2015 08:30:21 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:36958 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZIevR-000MEX-1f; Fri, 24 Jul 2015 11:30:17 -0400 To: Ben Laurie , trans issue tracker , draft-ietf-trans-rfc6962-bis@tools.ietf.org References: <056.5d271b279cc61b979e6443dc0948e24a@tools.ietf.org> <071.139420386221cc6aea4536fab0441820@tools.ietf.org> <55B0B674.8090904@bbn.com> From: Stephen Kent Message-ID: <55B25A07.9090101@bbn.com> Date: Fri, 24 Jul 2015 17:30:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060504040903020209060302" Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #96 (rfc6962-bis): Metadata: Should it be dynamic? 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, 24 Jul 2015 15:30:23 -0000 This is a multi-part message in MIME format. --------------060504040903020209060302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ben, Based on further discussion during the WG meeting I think all of the metadata should be described as immutable for a log (instance), expect for the final STH. That way it will be clear to readers that if a log wants to change any of these values, a new log MUST be created. Steve > > > On Thu, 23 Jul 2015 at 10:40 Stephen Kent > wrote: > > There are two types of log metadata. Some if the data is analogous to > trust anchor > info and thus distributing it to TLS clients using the same (not > standardized) browser > vendor mechanisms makes sense. (This does, though, raise an issue > about > how non-browser > client acquire this info; Monitors and Auditors are not necessarily > products of vendors > and thus there may not be the same infrastructure to distribute this > sort of data.) > > Other log metadata (e.g., MMD and STH frequency) is less like trust > anchor info and > it could be distributed by having a signed, time-stamped data > structure > posted at a known > location associated with the log. > > A potential benefit of this model is > that a log operator > can know that if it changes these parameters, all clients are able to > acquire the new info > at the same time. If one relies on an unspecified distribution > mechanism > for these parameters, > a log operator cannot know when all clients have received the new > info. > That uncertainty > might cause operational problems. So, the title for this issuer is not > really whether ALL > metadata should be dynamic, but rather whether some of it should be. > > > MMD and STH frequency are parameters that cannot be freely varied and > still allow useful operation of the system. It does not seem to me > that it would ever be appropriate to allow logs to unilaterally change > them - that's precisely why they're part of the metadata and not data > that can be retrieved from the log. > > Perhaps the simplest thing to do is note that changing metadata is > also implementation dependent (as well as distribution) and out of scope? > > Obviously if something doesn't belong in metadata at all, that's a > different matter. > > > Steve > > #96: Metadata: Should it be dynamic? > > > > Changes (by benl@google.com ): > > > > * milestone: => review > > > > > > Comment: > > > > We've already discussed this, I feel sure, and the general > point is that > > allowing logs to manipulate their own metadata is dangerous, > as you state. > > That's why the I-D says its distribution is out of scope. > > > > As you know, in practice, Chrome defines its own log metadata, > and that is > > what clients use. I imagine this will be the general pattern. > > > > I propose this is resolved as wontfix. > > > --------------060504040903020209060302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,

Based on further discussion during the WG meeting I think all
of the metadata should be described as immutable for a log (instance),
expect for the final STH. That way it will be clear to readers that
if a log wants to change any of these values, a new log MUST be created.

Steve



On Thu, 23 Jul 2015 at 10:40 Stephen Kent <kent@bbn.com> wrote:
There are two types of log metadata. Some if the data is analogous to
trust anchor
info and thus distributing it to TLS clients using the same (not
standardized) browser
vendor mechanisms makes sense. (This does, though, raise an issue about
how non-browser
client acquire this info; Monitors and Auditors are not necessarily
products of vendors
and thus there may not be the same infrastructure to distribute this
sort of data.)

Other log metadata (e.g., MMD and STH frequency) is less like trust
anchor info and
it could be distributed by having a signed, time-stamped data structure
posted at a known
location associated with the log. 
A potential benefit of this model is
that a log operator
can know that if it changes these parameters, all clients are able to
acquire the new info
at the same time. If one relies on an unspecified distribution mechanism
for these parameters,
a log operator cannot know when all clients have received the new info.
That uncertainty
might cause operational problems. So, the title for this issuer is not
really whether ALL
metadata should be dynamic, but rather whether some of it should be.

MMD and STH frequency are parameters that cannot be freely varied and still allow useful operation of the system. It does not seem to me that it would ever be appropriate to allow logs to unilaterally change them - that's precisely why they're part of the metadata and not data that can be retrieved from the log.

Perhaps the simplest thing to do is note that changing metadata is also implementation dependent (as well as distribution) and out of scope?

Obviously if something doesn't belong in metadata at all, that's a different matter.


Steve
> #96: Metadata: Should it be dynamic?
>
> Changes (by benl@google.com):
>
>   * milestone:   => review
>
>
> Comment:
>
>   We've already discussed this, I feel sure, and the general point is that
>   allowing logs to manipulate their own metadata is dangerous, as you state.
>   That's why the I-D says its distribution is out of scope.
>
>   As you know, in practice, Chrome defines its own log metadata, and that is
>   what clients use. I imagine this will be the general pattern.
>
>   I propose this is resolved as wontfix.
>


--------------060504040903020209060302-- From nobody Fri Jul 24 08:34:38 2015 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 597D91ACCFE for ; Fri, 24 Jul 2015 08:34:37 -0700 (PDT) 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 Q4vXFQG6M7wv for ; Fri, 24 Jul 2015 08:34:36 -0700 (PDT) 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 56FC01A1BAC for ; Fri, 24 Jul 2015 08:34:36 -0700 (PDT) Received: from localhost ([::1]:53693 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIezQ-0003mk-Rt; Fri, 24 Jul 2015 08:34:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, kent@bbn.com X-Trac-Project: trans Date: Fri, 24 Jul 2015 15:34:24 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/78#comment:3 Message-ID: <067.c9cbff2d37f6abbc61fa7c0d6ef221ac@tools.ietf.org> References: <052.225d9e4c8d8c45e468832faf6102e815@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <052.225d9e4c8d8c45e468832faf6102e815@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, benl@google.com, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150724153436.56FC01A1BAC@ietfa.amsl.com> Resent-Date: Fri, 24 Jul 2015 08:34:36 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 15:34:37 -0000 #78: algorithm agility discussion is inadequate Comment (by kent@bbn.com): The current, very brief description does not discuss a number of issues of how a planned algorithm transition takes place. For example, if a log operator wants to move to a new signature algorithm, it needs to create the new metadata that points to the new log, including a new URL, new algorithm identifiers and new keys. The means by which this metadata is distributed is not specified, but it seems likely that the browser-vendor channel for distribution of this metadata will take a little while. So, there is a need for guidance to a log operator as to how to deal with the unknown delays for this metadata to become widely available. There is also the question of when the old log is frozen relative to the new log, and how this relates to the various types of log clients (CAs vs. browsers vs. Monitors). For example, do CAs now need to get SCTs for certs from both the old and new logs to ensure continuity for SCT consumers, and if so, for how long does this dual operation persist? I think this is a non-trivial problem and the current text does not address the sorts of issues noted above. Note that the RPKI published a detailed description of how a phased algorithm transition is to be effected for that system. That system faces a much more difficult transition task, but the principle of documenting how a staged transition with some established interval lengths, still seems appropriate. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jul 24 08:35:23 2015 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 777F91ACE8A for ; Fri, 24 Jul 2015 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Czzj43Om-hi3 for ; Fri, 24 Jul 2015 08:35:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2B71ACE6E for ; Fri, 24 Jul 2015 08:35:21 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37007 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZIf0K-000MGs-Ga for trans@ietf.org; Fri, 24 Jul 2015 11:35:20 -0400 To: trans@ietf.org References: <052.225d9e4c8d8c45e468832faf6102e815@tools.ietf.org> <067.26cce79c448ae94087e82f3a71addea6@tools.ietf.org> <55B0DFC5.4000300@bbn.com> From: Stephen Kent Message-ID: <55B25B38.1000908@bbn.com> Date: Fri, 24 Jul 2015 17:35:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 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] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate 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, 24 Jul 2015 15:35:22 -0000 Ben, Thanks for the reminder. I submitted my comments to the tracker entry for this topic. Steve From nobody Fri Jul 24 08:38:39 2015 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 984671ACEB8 for ; Fri, 24 Jul 2015 08:38:37 -0700 (PDT) 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 LAkeas5v6DeO for ; Fri, 24 Jul 2015 08:38:36 -0700 (PDT) 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 E774D1ACEA8 for ; Fri, 24 Jul 2015 08:38:35 -0700 (PDT) Received: by ykfw194 with SMTP id w194so22666618ykf.0 for ; Fri, 24 Jul 2015 08:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=zRVJ2DVcXY3mzA19vAYaLHYvUlvBmfvQJxrbhSO0J3U=; b=NrzOq+7S3qwe1k3Ily3nbApTvbBWvnCaGWwSNggliuUGxKIWzIa5mVkgCxa10VlFcx s7Ke9QVA8/b+IARP1bsKbVx7jckQ9dYjgw/B4O7UuYPW/p0yAF45vFPIfQxX2ZZB8619 TjaVlZND1/ocFhGufV0xRnfmI9AWtQ9N1btIEyIhEU/Ns4CZwrBaKxva+rxZFmXvlbVw pj6k1M+QYTCTMXr7CSIDL2bUtdEZ+RpmL+ZkVkKJ7jPIi1KT1Ee7JRMhs4aBtic41VhR MN30BN6fTsPj6NoHm9jolSMaJJNoFpQRxatqAWOOh+nKzH0Ryv7T0XDRXNKOavD4ZGhb 8QCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=zRVJ2DVcXY3mzA19vAYaLHYvUlvBmfvQJxrbhSO0J3U=; b=hx7KTp9SgufUNBA9dQXhUVIUyMkvaApgmO+dtnw/FnrGjjODkMfiTmz8wDfqR/rcJI JO/e+9NO2r9ejQplWaRxH3y5BaWXC0sjIZS6tVr43VwprM43iPAyAytiT8XbuNOpVXoZ YFzg5dpM+0jtXINXwDxIbzCo4KJbEmWLXuB45g8l7gwEP4yxWE8buu1heToRA6M6jUm2 H6euyUa4m9QzTJzU6kvPdoG6qc+LG10iytynFAQu0jkpCB33IfKhm0732DcxWoDq73wj Cs40Ky8h+HcdvB9lrg26PLbL0HcyANqy3r6H3CTW//DATrKCbmHroBbxxoXtKNt10EZx 9yeA== X-Gm-Message-State: ALoCoQmOVJZouinNMunxdxnV0YMq21WFHf6WTPqd8gS/XtuDgdGnz9V2vsiUIfnpMv9KIqd8tbWG X-Received: by 10.170.216.194 with SMTP id i185mr15742237ykf.80.1437752315259; Fri, 24 Jul 2015 08:38:35 -0700 (PDT) MIME-Version: 1.0 References: <056.5d271b279cc61b979e6443dc0948e24a@tools.ietf.org> <071.139420386221cc6aea4536fab0441820@tools.ietf.org> <55B0B674.8090904@bbn.com> <55B25A07.9090101@bbn.com> In-Reply-To: <55B25A07.9090101@bbn.com> From: Ben Laurie Date: Fri, 24 Jul 2015 15:38:25 +0000 Message-ID: To: Stephen Kent , trans issue tracker , draft-ietf-trans-rfc6962-bis@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1139fce4070c34051ba0cc4c Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #96 (rfc6962-bis): Metadata: Should it be dynamic? 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, 24 Jul 2015 15:38:37 -0000 --001a1139fce4070c34051ba0cc4c Content-Type: text/plain; charset=UTF-8 On Fri, 24 Jul 2015 at 16:30 Stephen Kent wrote: > Ben, > > Based on further discussion during the WG meeting I think all > of the metadata should be described as immutable for a log (instance), > expect for the final STH. That way it will be clear to readers that > if a log wants to change any of these values, a new log MUST be created. > Agree. (I know! Twice in 24 hours!). > > Steve > > > > > On Thu, 23 Jul 2015 at 10:40 Stephen Kent < kent@bbn.com> > wrote: > >> There are two types of log metadata. Some if the data is analogous to >> trust anchor >> info and thus distributing it to TLS clients using the same (not >> standardized) browser >> vendor mechanisms makes sense. (This does, though, raise an issue about >> how non-browser >> client acquire this info; Monitors and Auditors are not necessarily >> products of vendors >> and thus there may not be the same infrastructure to distribute this >> sort of data.) >> >> Other log metadata (e.g., MMD and STH frequency) is less like trust >> anchor info and >> it could be distributed by having a signed, time-stamped data structure >> posted at a known >> location associated with the log. > > A potential benefit of this model is >> that a log operator >> can know that if it changes these parameters, all clients are able to >> acquire the new info >> at the same time. If one relies on an unspecified distribution mechanism >> for these parameters, >> a log operator cannot know when all clients have received the new info. >> That uncertainty >> might cause operational problems. So, the title for this issuer is not >> really whether ALL >> metadata should be dynamic, but rather whether some of it should be. >> > > MMD and STH frequency are parameters that cannot be freely varied and > still allow useful operation of the system. It does not seem to me that it > would ever be appropriate to allow logs to unilaterally change them - > that's precisely why they're part of the metadata and not data that can be > retrieved from the log. > > Perhaps the simplest thing to do is note that changing metadata is also > implementation dependent (as well as distribution) and out of scope? > > Obviously if something doesn't belong in metadata at all, that's a > different matter. > > >> Steve >> > #96: Metadata: Should it be dynamic? >> > >> > Changes (by benl@google.com): >> > >> > * milestone: => review >> > >> > >> > Comment: >> > >> > We've already discussed this, I feel sure, and the general point is >> that >> > allowing logs to manipulate their own metadata is dangerous, as you >> state. >> > That's why the I-D says its distribution is out of scope. >> > >> > As you know, in practice, Chrome defines its own log metadata, and >> that is >> > what clients use. I imagine this will be the general pattern. >> > >> > I propose this is resolved as wontfix. >> > >> >> > --001a1139fce4070c34051ba0cc4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , 24 Jul 2015 at 16:30 Stephen Kent <ken= t@bbn.com> wrote:
=20 =20 =20
Ben,

Based on further discussion during the WG meeting I think all
of the metadata should be described as immutable for a log (instance),
expect for the final STH. That way it will be clear to readers that
if a log wants to change any of these values, a new log MUST be created.

Agree.
(I know! Twice in 24 hours!).
=C2=A0

Steve




On Thu, 23 Jul 2015 at 10:40 Stephen Kent <kent@bbn.com> wrote:
There are two types of log metadata. Some if the data is analogous to
trust anchor
info and thus distributing it to TLS clients using the same (not
standardized) browser
vendor mechanisms makes sense. (This does, though, raise an issue about
how non-browser
client acquire this info; Monitors and Auditors are not necessarily
products of vendors
and thus there may not be the same infrastructure to distribute this
sort of data.)

Other log metadata (e.g., MMD and STH frequency) is less like trust
anchor info and
it could be distributed by having a signed, time-stamped data structure
posted at a known
location associated with the log.=C2=A0
A potential benefit of this model is
that a log operator
can know that if it changes these parameters, all clients are able to
acquire the new info
at the same time. If one relies on an unspecified distribution mechanism
for these parameters,
a log operator cannot know when all clients have received the new info.
That uncertainty
might cause operational problems. So, the title for this issuer is not
really whether ALL
metadata should be dynamic, but rather whether some of it should be.

MMD and STH frequency are parameters that cannot be freely varied and still allow useful operation of the system. It does not seem to me that it would ever be appropriate to allow logs to unilaterally change them - that's precisely why they're part of the metadata and n= ot data that can be retrieved from the log.

Perhaps the simplest thing to do is note that changing metadata is also implementation dependent (as well as distribution) and out of scope?

Obviously if something doesn't belong in metadata at all= , that's a different matter.


Steve
> #96: Metadata: Should it be dynamic?
>
> Changes (by benl@google.com):
>
>=C2=A0 =C2=A0* milestone:=C2=A0 =C2=A0=3D> review
>
>
> Comment:
>
>=C2=A0 =C2=A0We've already discussed this, I feel sure,= and the general point is that
>=C2=A0 =C2=A0allowing logs to manipulate their own metadata= is dangerous, as you state.
>=C2=A0 =C2=A0That's why the I-D says its distribution i= s out of scope.
>
>=C2=A0 =C2=A0As you know, in practice, Chrome defines its o= wn log metadata, and that is
>=C2=A0 =C2=A0what clients use. I imagine this will be the g= eneral pattern.
>
>=C2=A0 =C2=A0I propose this is resolved as wontfix.
>


--001a1139fce4070c34051ba0cc4c-- From nobody Fri Jul 24 08:40:25 2015 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 9B7041A875E for ; Fri, 24 Jul 2015 08:40:24 -0700 (PDT) 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 XaZgHPyW-Lvf for ; Fri, 24 Jul 2015 08:40:23 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282731A86EB for ; Fri, 24 Jul 2015 08:40:23 -0700 (PDT) Received: by ykfw194 with SMTP id w194so22709434ykf.0 for ; Fri, 24 Jul 2015 08:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=wtbu4q6MFPVWVsuBT13aOFVAMPn9KwM9I1pD0Hshoh0=; b=eFn379k756p9ZyYxLZWjTvrNFfN/5WDnEFD+5CZKg9tN0ZZhUOVH2xY7x4ZHImWihL LLmi8naX/esFQYYY2AgqJQW061dOgCCBqS8GYiN17Yw2GsTqk+qyGV6RIfol4WXmzM+c dX1XtQCEtEGYRFAVJR6xmKi0o0ukNkSVK4i9S3QnEPBfsHSYyGkqIEEutRsZsNtdm4xJ rnXO1ZApsWbMkYngod6yvSORnjh7DVUI2uXGJEOKJcBPNf1ZZ+nEjec3Y6tkYb03SZrT y83dWY3qIziJAspHgwyGSaWSTxhPa+PGoxiva213IU/ZVmRJVDlqvZkWKjgfuxsQlo5h kdig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=wtbu4q6MFPVWVsuBT13aOFVAMPn9KwM9I1pD0Hshoh0=; b=Od7vXj08JQXP9J5sxAcc9WPLx38fXp0Wqwz/Pmk3xuShk8L3UzHEG4yhjL6LKlJFAn fiCOvN2l0CBU4/KCTIMKewOx1Sl3s+eR+GqhzybA2cA+O/DaolhbpVCB47RWDi6Z7og5 ds3ng1iOo9IOpCH1hGLc46lVAybN/XAR5BBsznGSqz9X7v2ofaOIk1xvn8SQQopyPB8/ NVOdMYIWtJBxk710uR3UWBhUwrHSfq8arU3mLTIRPYd4H6Ek8USSjNPqvvBbhQeKOOGT K5StTbMFoxoVJGjgMPwh/OnrVy0YbzRbDUtBPjR5EBjol49KKdnrguqh3jMzbZ5PyJT0 p5EQ== X-Gm-Message-State: ALoCoQlhsiOV/2uBw1UNsIoU4b7Auj6ZA0NOzEzGltcAybjahNOXlWy0zIGMMN6l1aRPn18byVkM X-Received: by 10.170.119.85 with SMTP id l82mr15782685ykb.89.1437752422501; Fri, 24 Jul 2015 08:40:22 -0700 (PDT) MIME-Version: 1.0 References: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> <071.d89581d27373926c935925fea3620bd1@tools.ietf.org> <55B2597B.20808@bbn.com> In-Reply-To: <55B2597B.20808@bbn.com> From: Ben Laurie Date: Fri, 24 Jul 2015 15:40:13 +0000 Message-ID: To: Stephen Kent , trans@ietf.org Content-Type: multipart/alternative; boundary=001a113908ec6b3dac051ba0d281 Archived-At: Subject: Re: [Trans] [trans] #95 (rfc6962-bis): The response size to get-entries should be a part of the log metadata 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, 24 Jul 2015 15:40:24 -0000 --001a113908ec6b3dac051ba0d281 Content-Type: text/plain; charset=UTF-8 On Fri, 24 Jul 2015 at 16:28 Stephen Kent wrote: > I am now convinced that the response size may have to vary dynamically. > I suggest the log spec (aka 6962-bis) should mandate a minimum size for > the get-entries query for all logs (to address privacy concerns). > As I noted in response to the agenda writeup, I am not convinced by this - the easy way to mitigate the privacy concern is for the client to preselect the entries it wishes to fetch, and fetch all of them regardless of reduced responses (through multiple requests, obviously). > Steve > > #95: The response size to get-entries should be a part of the log > metadata > > > > > > Comment (by benl@google.com): > > > > Disagree. Whilst I can see there might be some slight advantage to the > > client, what would we do if the server broke the promise, and why? > > > > Also, response size limit may be based on dynamic considerations (load, > > caching, size of responses, etc). > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113908ec6b3dac051ba0d281 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , 24 Jul 2015 at 16:28 Stephen Kent <ken= t@bbn.com> wrote:
I am now= convinced that the response size may have to vary dynamically.
I suggest the log spec (aka 6962-bis) should mandate a minimum size for
the get-entries query for all logs (to address privacy concerns).

As I noted in response to the agenda writeup, I = am not convinced by this - the easy way to mitigate the privacy concern is = for the client to preselect the entries it wishes to fetch, and fetch all o= f them regardless of reduced responses (through multiple requests, obviousl= y).


Steve
> #95: The response size to get-entries should be a part of the log meta= data
>
>
> Comment (by benl@= google.com):
>
>=C2=A0 =C2=A0Disagree. Whilst I can see there might be some slight adva= ntage to the
>=C2=A0 =C2=A0client, what would we do if the server broke the promise, = and why?
>
>=C2=A0 =C2=A0Also, response size limit may be based on dynamic consider= ations (load,
>=C2=A0 =C2=A0caching, size of responses, etc).
>

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a113908ec6b3dac051ba0d281-- From nobody Fri Jul 24 18:38:37 2015 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 A04C61B2AB4 for ; Fri, 24 Jul 2015 18:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.12 X-Spam-Level: * X-Spam-Status: No, score=1.12 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_62=0.6, 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 biCTDIb2lRJG for ; Fri, 24 Jul 2015 18:38:33 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB7E1B2AB2 for ; Fri, 24 Jul 2015 18:38:33 -0700 (PDT) Received: by wibud3 with SMTP id ud3so52119358wib.0 for ; Fri, 24 Jul 2015 18:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=d/ttz2VHJuGbaPwET0Gpgk5caMjDInuDShEhJCuSecU=; b=m8n8R5dJQ9C59TFpc1rF1lYEZ3kZfx3aflk3eqG4mAUHuos/mfPUAAm8EfALLol5rs sssTioTyfKDXA6LgswTEmaxO5cb0OS3r6qx72MIj7IapKdv/XkT1B1p+cERofYWffKfg OFB2ifw+SUk/f6nzljr+l2SdtedzzqT0yGBPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=d/ttz2VHJuGbaPwET0Gpgk5caMjDInuDShEhJCuSecU=; b=TSLBKUvRE0MHqcewojw+FBwgPv9r4IsTevA2TtshYgb363OvEts1Hdd7p7YYs8BHN8 gbG/6r+R15Sc8+vNK+0PD+M6CM2hHVarnc2o5aoQwmce+s1SjRF54TZhUd4aEi6SQfPS Z0eFc7US8LPVjI8c1CcEHqgnHZvM8Pl8dqTli+IKGdlZH4Dce/nnL0sKHOxhRnZMvU22 ceizgcMnNqHHLnS2HPruWzuD3t7Pq5B78KoNPFtw+LY938bYfAynGlvBwma5qWjI+gWh aqPJpbYpPZiDhgr1pi/cLo1sw0QKeWfoe9I+utwoycvst1icXEHET6HpgJlM+ZhzLnEo bikw== X-Gm-Message-State: ALoCoQkQlW8SNIRTRhJFJJGJgJhPcEpl62xuAKdqYAkScq6lDhfKyHqKw03nOjpVSJSj0CZx2e5c X-Received: by 10.180.8.68 with SMTP id p4mr2092881wia.27.1437788311838; Fri, 24 Jul 2015 18:38:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.67 with HTTP; Fri, 24 Jul 2015 18:38:12 -0700 (PDT) In-Reply-To: References: <874mkvclg5.fsf@totally-fudged-out-message-id> <87zj2nb5ey.fsf@nordberg.se> From: Tom Ritter Date: Fri, 24 Jul 2015 20:38:12 -0500 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Linus Nordberg Subject: Re: [Trans] Review of draft-linus-trans-gossip-ct-02 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: Sat, 25 Jul 2015 01:38:35 -0000 On 23 July 2015 at 04:16, Linus Nordberg wrote: > | "An SCT MUST NOT be sent to any other HTTPS server than one serving > | the domain that the certificate signed by the SCT refers to.{Not all TLS > | clients care about privacy: e.g. crawlers, so this MUST NOT is too strong}" > > I see. Wonder how we could express that. Should we try to differentiate > between browsers with real people using them and other clients? Or bring > in "user consent"? Well, if a crawler sends an SCT for amazon.com to ritter.vg - I'm going to ignore it. (I don't want you filling up my disk space.) If you configure you server to accept any SCT, and your crawler sends all the SCTs to it... I would describe this as a Trusted Auditor relationship, that just happens to use (roughly) the same protocol as SCT Feedback. How Trusted Auditors are implemented is well out of scope. So I don't think any change is necessary, but we could clarify I suppose. > | "First, the server > | recieving the SCT would learn about other sites visited by the HTTPS > | client{if SCTs are gossipped then this is clearly untrue: however, I > | agree that it is hard to avoid some kind of privacy leak}. " > > It is true for the first N clients gossiping was my first reaction. Then > there was an interesting discussion off list about if either of those > claims could be proven correct through simulation. Without more data my > position is that we don't know and should err on the side of safety and > not gossip SCTs. Strong ++ > | "If the HTTPS client has configuration options for not sending cookies > | to third parties, SCTs MUST be treated as cookies with respect to > | this setting.{don't understand - you already banned sending to third > | parties}" > > This is for local attacks, i.e. someone digging through the local > store. Should probably expand. Added a TODO for now. Did we ban sending to third parties? I don't think so. I know for sure we said "don't send SCTs for amazon.com to ritter.vg". But if ritter.vg embeds something from https://amazon.com - that connection _could_ send SCTs. UNLESS the client is configured to not send cookies on these sort of connections (the browser setting is Third Party Cookies.) If Third Party Cookies are disallowed, then SCTs on such connections should also be disallowed.* * There are probably other sorts of super-cookies amazon.com could use, but we should not introduce a new leak. > | "The data sent in the POST is defined in Section 5.1.3.{what if the POST > | fails, as it obviously will for most servers initially?}" > > Then no SCT Feedback is happening. Do we need to add text? In general we need to do a full pass and review for the cases of "What happens if the client's attempt to send Feedback/Pollination data fails". > | " It's important to note > | that the check must be on pairs of SCT and chain in order to catch > | different chains accompanied by the same SCT. [XXX why is this > | important?]{given that logs do _not_ have to log multiple chains, I > | suspect this is actually not important}" > > This could be of interest to the operator of the web site. Creating more > incentive for them to play along is probably valuable. It can be debated > whether it's worth it or not. I swore earlier Ben said it would be useful for site operators to receive not only chains, but the cert ordering that was sent from the server... but I can't find that email so perhaps I'm attributing someone else's comments to him. I think including the cert chain and the cert ordering from the server* will be an open issue for a bit longer. * If that's even easily retrieved in the appropriate browser layer! > | " Note that an HTTPS server MAY perform a certificate chain validation > | on a submitted certificate chain, and if it matches a trust root > | configured on the server (but is otherwise unknown to the server), > | the HTTPS server MAY store the certificate chain and MAY choose to > | store any submitted SCTs even if they are unable to be verified. The > | risk of spamming and denial of service can be mitigated by > | configuring the server with all known acceptable certificates (or > | certificate hashes). {Confused by this, surely the point is to find > | certs/SCTs the server does not expect?}" > > I think we thought this would help catching an SCT even if it doesn't > verify correctly by imposing some limits on the cert chain that came > with it. Storing the server cert and chain helps catch unknown certs. Storing the SCT(s) may help find that cert in a log. (Or detect misbehavior by a log.) So, to answer Ben's question - yes. Perhaps the "reduce the risk of spamming" sentence was confusing? > | 6.1.1 > | > | " Therefore, a > | client with an SCT for a given server should transmit that > | information in only two channels: to a server associated with the SCT > | itself; and to a trusted CT auditor, if one exists.{only if the client > | cares about privacy}" > > See comment above ("I see. Wonder how we could express that.[...]") If they don't care about privacy, they can talk to a Trusted Auditor. And clients of course choose their own definition of "Trusted". On 23 July 2015 at 04:53, Ben Laurie wrote: >> | 5.2.2 >> | >> | "After retrieving the consistency proof to the most recent STH, they >> | SHOULD pollinate this new STH among participating HTTPS Servers {and >> may >> | safely discard the older STH}. " >> >> Unless it should be gossiped some more? We only know that it's correct >> with regard to the particular view of the log we're being served. I >> don't think we've decided when to stop gossiping about a particular STH >> yet. > > > The point is that the newer STH includes the older one (i.e. it proves the > log contains all the things the older one proved it contained), so there's > no value in retaining the older STH... ++ to this -tom From nobody Sat Jul 25 03:26:52 2015 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 31D6C1B2D76 for ; Sat, 25 Jul 2015 03:26:50 -0700 (PDT) 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 vOiuuOq-bt9e for ; Sat, 25 Jul 2015 03:26:48 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 96D061B2D75 for ; Sat, 25 Jul 2015 03:26:48 -0700 (PDT) Received: by ykfw194 with SMTP id w194so37395270ykf.0 for ; Sat, 25 Jul 2015 03:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=8Om6hLmuLbRoKaFDvn2DowRgG/VoHadClNyi6aZTj4E=; b=n/zmDDOUsxO7X5EPqlBzA+PveiNdZkV2Ayhe0T0GjUv6cchfjeVVHxRdG2tx9Uho+A Wmp1D3WStAM+NLtsKIFnV/nvJeCiEjabqrCm7cNDK06yroiMKaqhUBPFyXU5578C7A/y gyaH1GMhYjeTI7rexEvb222sPgLrMPnefPclhwPXHiX2kNZhsEGY1dYK6jjOaDIN+6vp b1tOi8wo5DpXe9u1gX4yuqUE+pcRQjXxnnFqiGjQZvPG/nprzuOEjl6og3CEHsY1QnMu 81QsBvka5MSJU4wlet91EClNCnios700zqreaNhQEtGA0Ijz74qXI5/Fdq7FEaiQx80D FTDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=8Om6hLmuLbRoKaFDvn2DowRgG/VoHadClNyi6aZTj4E=; b=lxxC1SU6mfe8fVSxMdo94q0KnEb+eScAIOgMi6YxgWvC5h2wqX+K9UrdbCzRzqIn1E sSWsf/RuqIz3v2fAfrNhlwom4CYIqxB1S3GNj/71zXgJ4UoPN1DNcB/jmJ7fVSrZsljC o1TTmvgx4pM6J1pTgjsJhc1bosdL+o24OXNiqTgJwmhVz20SMnO+h5+U093jw6IPrLQE vTBNAkdQFLW7wBpFV+ogFDmjNtWfMDHmqePY5bGV5js4kLmqYY8Ttd15yQycWT97NvkZ FK7fqUQ8vyERdU2+xuPba51Hd+Gr5r/PgsY5SDLDM0k6NdCUDeRHusP9fRcOGD1jSRJC fbvg== X-Gm-Message-State: ALoCoQkdrjoxSxWNeGeZKdrSsDgwjVZaycmRSB7pG3DpIcQkc16xtDo6+GpzFIeK14kUqcHjvYDe X-Received: by 10.129.77.213 with SMTP id a204mr20171000ywb.40.1437820007791; Sat, 25 Jul 2015 03:26:47 -0700 (PDT) MIME-Version: 1.0 References: <874mkvclg5.fsf@totally-fudged-out-message-id> <87zj2nb5ey.fsf@nordberg.se> In-Reply-To: From: Ben Laurie Date: Sat, 25 Jul 2015 10:26:38 +0000 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=001a1140c552d12866051bb08e28 Archived-At: Cc: "trans@ietf.org" , Linus Nordberg Subject: Re: [Trans] Review of draft-linus-trans-gossip-ct-02 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: Sat, 25 Jul 2015 10:26:50 -0000 --001a1140c552d12866051bb08e28 Content-Type: text/plain; charset=UTF-8 On Sat, 25 Jul 2015 at 02:38 Tom Ritter wrote: > On 23 July 2015 at 04:16, Linus Nordberg wrote: > > | " It's important to note > > | that the check must be on pairs of SCT and chain in order to catch > > | different chains accompanied by the same SCT. [XXX why is this > > | important?]{given that logs do _not_ have to log multiple chains, I > > | suspect this is actually not important}" > > > > This could be of interest to the operator of the web site. Creating more > > incentive for them to play along is probably valuable. It can be debated > > whether it's worth it or not. > > I swore earlier Ben said it would be useful for site operators to > receive not only chains, but the cert ordering that was sent from the > server... but I can't find that email so perhaps I'm attributing > someone else's comments to him. I think including the cert chain and > the cert ordering from the server* will be an open issue for a bit > longer. > * If that's even easily retrieved in the appropriate browser layer! > I'm pretty sure I didn't say that. Not that I am particularly opposed to it, my position is simply that I am not sure what value it adds. On ordering: its pretty unclear how clients deal with validating chains in general, and whether they care about order. I know from feeding crawled chains to logs that _many_ chains are served incorrectly, so clearly clients are doing quite a bit of remediation on the served chains. :-) BTW, I snipped all your comments about SCT gossip, but I do agree with your characterisation of the recipient as some kind of Trusted Auditor. I'm not sure I saw gossip between Trusted Auditors explicitly addressed - would that be allowed, or dangerous? --001a1140c552d12866051bb08e28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat= , 25 Jul 2015 at 02:38 Tom Ritter <tom@= ritter.vg> wrote:
On 23 Ju= ly 2015 at 04:16, Linus Nordberg <linus@nordu.net> wrote:
> | " It's important to note
> |=C2=A0 =C2=A0 that the check must be on pairs of SCT and chain in ord= er to catch
> |=C2=A0 =C2=A0 different chains accompanied by the same SCT.=C2=A0 [XX= X why is this
> |=C2=A0 =C2=A0 important?]{given that logs do _not_ have to log multip= le chains, I
> | suspect this is actually not important}"
>
> This could be of interest to the operator of the web site. Creating mo= re
> incentive for them to play along is probably valuable. It can be debat= ed
> whether it's worth it or not.

I swore earlier Ben said it would be useful for site operators to
receive not only chains, but the cert ordering that was sent from the
server... but I can't find that email so perhaps I'm attributing someone else's comments to him.=C2=A0 I think including the cert chain = and
the cert ordering from the server* will be an open issue for a bit
longer.=C2=A0

* If that's even easily retrieved in the appropriate browser layer!
=

I'm pretty sure I didn't say that.= Not that I am particularly opposed to it, my position is simply that I am = not sure what value it adds.

On ordering: its pret= ty unclear how clients deal with validating chains in general, and whether = they care about order. I know from feeding crawled chains to logs that _man= y_ chains are served incorrectly, so clearly clients are doing quite a bit = of remediation on the served chains. :-)
=C2=A0
BTW, I = snipped all your comments about SCT gossip, but I do agree with your charac= terisation of the recipient as some kind of Trusted Auditor. I'm not su= re I saw gossip between Trusted Auditors explicitly addressed - would that = be allowed, or dangerous?
--001a1140c552d12866051bb08e28-- From nobody Sat Jul 25 06:30:25 2015 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 24CD31B2EE4 for ; Sat, 25 Jul 2015 06:30:24 -0700 (PDT) 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 SanO9X1zWYWI for ; Sat, 25 Jul 2015 06:30:23 -0700 (PDT) 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 E51881B2EB3 for ; Sat, 25 Jul 2015 06:30:22 -0700 (PDT) Received: from localhost ([::1]:56477 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZIzWm-00067n-2Z; Sat, 25 Jul 2015 06:30:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, paul@nohats.ca X-Trac-Project: trans Date: Sat, 25 Jul 2015 13:30:12 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/87#comment:2 Message-ID: <070.7df7d064ff6a03c917558e7967a586ee@tools.ietf.org> References: <055.7819ac8587a95086b3d5e12f7059de04@tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <055.7819ac8587a95086b3d5e12f7059de04@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, paul@nohats.ca, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150725133022.E51881B2EB3@ietfa.amsl.com> Resent-Date: Sat, 25 Jul 2015 06:30:22 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #87 (rfc6962-bis): Add reference to threat analysis document X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 13:30:24 -0000 #87: Add reference to threat analysis document Comment (by paul@nohats.ca): Replying to [comment:1 rob.stradling@…]: > Stephen Farrell just asked "Normative or Informative?" Stephen suggested informative, and I agree with that. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 27 09:33:49 2015 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 83B5C1B3052 for ; Mon, 27 Jul 2015 09:33:47 -0700 (PDT) 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 VMKJem3kIueq for ; Mon, 27 Jul 2015 09:33:46 -0700 (PDT) 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 9FAE71B3067 for ; Mon, 27 Jul 2015 09:33:30 -0700 (PDT) Received: from localhost ([::1]:42234 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZJlLF-0008MQ-TL; Mon, 27 Jul 2015 09:33:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Mon, 27 Jul 2015 16:33:29 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/95#comment:4 Message-ID: <071.1cf0f6eddb20d99a7bf2e73e45c39f37@tools.ietf.org> References: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <056.af42a796c215951b1405cbfa6589d27d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150727163330.9FAE71B3067@ietfa.amsl.com> Resent-Date: Mon, 27 Jul 2015 09:33:30 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #95 (rfc6962-bis): Should the response size to get-entries be a part of the log metadata? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 16:33:47 -0000 #95: Should the response size to get-entries be a part of the log metadata? Comment (by eranm@google.com): To clarify - get-entries is not used by the client when fetching an inclusion proof, but by monitors for bulk fetching of entries. As such, the RFC could recommend a number with logs being free to dynamically vary it. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jul 27 09:37:08 2015 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 DE1F01B3066 for ; Mon, 27 Jul 2015 09:36:57 -0700 (PDT) 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 RRi8EZv1tL3f for ; Mon, 27 Jul 2015 09:36:55 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022071B3068 for ; Mon, 27 Jul 2015 09:36:51 -0700 (PDT) Received: by iggf3 with SMTP id f3so84386691igg.1 for ; Mon, 27 Jul 2015 09:36:51 -0700 (PDT) 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=/uUDlpU9ZotS6IPgDmNcVpcoTa9v3TSCwTi7ZJBkNyo=; b=IZHOV4fhLD4l91FxfV5B6oL5pjSDSWK0nyHNSlDZwAVPq0YXZOOl6USzVpyiPfx9F4 HvIN0MCcZJBoT48dirCJ9o15IzqevU/nBzfBmGmHXEzznlVsTArBoJIBQFCQTVgHAsMF +DPQppKoxezQwa2GSueGBs0txpFgzWgryuC6zL6d5Ow9WCrpAiNxfQrsLeYhyoykvbDb 0OblXtqoW6P273ceouKZSlFG1kJGu9fVrkrGSG4W+CXdqL8qMYpNxmN72OSZjC9kKZzM qoPTgVcqK29uSv6Qy2QRHg+ORNlcV8ixH3bAbdIu5CEUfwthMlhuAblsWUG4L5wcOLyi RmhQ== 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=/uUDlpU9ZotS6IPgDmNcVpcoTa9v3TSCwTi7ZJBkNyo=; b=WGEaEBRoF8NIT93Ln1bf3k/hb4DEiFw9X7CRqPrDxUTQzetmbziyONcCJKxd26sWVw os95mTrrRET9xSB6l/Pac74pFl1UPd4tLf5mRsZSUuXfINYUcCjdfFxTpkEnSmBkYqOt sjtUuHkkC/U1d4Cqa+jif9DeOwWftlQbSUsouAkcYpZyzy8GJQXuino6e+hjggsk43D8 s2b7jcKNt4zN32pnjhI3WVVOSoeq/M12asgDSeFW0v4np7adfxqXn9TAc3eWoa1LYEAT z/AXwSn3UkidpYbfYN24MT4Ln85GnU6bvv1YG8rTcJRYGbl6uKBN2aPp0G6b6rDd2S9m 905A== X-Gm-Message-State: ALoCoQntrMie8tlRYw6hWT8btKuLTnGRO/8ixhePSKxObbZU1+DPz0AUu3OTHKGuE6NzSPLDb66H MIME-Version: 1.0 X-Received: by 10.50.66.129 with SMTP id f1mr19431052igt.7.1438015011289; Mon, 27 Jul 2015 09:36:51 -0700 (PDT) Received: by 10.64.207.225 with HTTP; Mon, 27 Jul 2015 09:36:51 -0700 (PDT) In-Reply-To: References: <9ed3e1bb8b1549fd8f87eb327360e9b9@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Mon, 27 Jul 2015 17:36:51 +0100 Message-ID: From: Eran Messeri To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7bdc0cf4ee4bf4051bddf5d8 Archived-At: Cc: "Salz, Rich" , "trans@ietf.org" Subject: Re: [Trans] TRANS Draft minutes for IETF-93 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, 27 Jul 2015 16:36:58 -0000 --047d7bdc0cf4ee4bf4051bddf5d8 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 24, 2015 at 12:28 PM, Ben Laurie wrote: > > > On Thu, 23 Jul 2015 at 20:59 Salz, Rich wrote: > >> Please send/post corrections. >> >> Paul, WG Status update >> Charger unchanged; need to reset milestone. >> >> Eran RFC6962-bis status+ >> Still needs some tweaks. Suggests waiting for Google to finish their >> implementation to clean out all nits before WGLC >> A log cannot do a single v1/v2 log, must run both in parallel. >> Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, >> 82, 83, 84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details >> Open tickets 78 (alg agility needs more description) 83 (should require >> deterministic ECESA) 96 (dynamic metadata; does only CA root list really >> change?) 95 (include get-entries response size in the log metadata, for >> cursoring through a log) >> Steve raised issue of exposing what certs a client is interested in if >> size of get-entries can shrink to one, for example. >> > > My response was omitted: this doesn't matter so long as the client > continues to request entries until it has all the ones it originally > decided to fetch. > > >> More on open: 87 (ref to attack model doc) 64 (remove spec of sig and >> hash lags) 93 (monitor description inconsistencies) 94 (when/why clients >> should fetch inclusion proofs) >> Stephen raised issue fhat if threat analysis is normative, schedule gets >> pushed out further. Should be informative. >> >> Steve Kent, attack model >> Name changed on doc, even if filename can't easily be changed. Not a >> threat model, we don't know what the attackers are thinking, but we do know >> possible actions so it's an attack model. >> Includes an intro to CT, he prefers it move into an arch document but if >> not it will stay. >> "CT is a set of mechanisms, designed to detect, deter, and facilitate >> remediation of certificate mis-issuance" >> Semantic mis-issuance: name in the cert refers to an entity incorrectly. >> Syntactic mis-issuance: violation of certificate profile(s) that apply. >> Reviewed a taxonomy of attacks. Read the doc. Discussion of additions >> and bigger picture needs. >> Incorporated all (but one) comments. >> Wants WG agreement via list on goals, definitions, attacks. >> We have a half-dozen people commit to read and review the document. >> Ben agrees about having an arch doc; Steve and Ben will collaborate on an >> arch doc >> > > I thought I heard other volunteers. :-) > I'm happy to help with the architecture document . > > >> >> Dkg, Gossip >> Gossip important to keep logs accountable by making sure everyone sees >> the same append-only data and keep their MMD/SCT promises. >> Works by browser's sharing and comparing SCT and STH >> Three channels: >> SCTFeedback; browser sends cert/sct to website, website sends to >> auditing function/third-party auditor >> STH Pollination: auditor/website send STH to each other. STH are >> not privacy-sensitive >> Optional Trusted Auditor: browser passes sct/cert to auditor >> (e.g., the DNS resolver since it already knows what you might be looking at) >> Call for adoption is on the mailing list. >> >> Dkg, CT for binary >> Goal is to know that you are running the same software as "everyone >> else," not guaranteeing that the software isn't compromised. >> Add a binary lLogEntryType; add binary and binary_digest to Signed_Type >> Many details of what and how is signed are still open; need feedback from >> s/w distributors. >> PHB suggest to not use ASN.1 >> Discussion and agreement that changing the s/w distribution format is a >> non-starter. >> > > dkg also noted that some distros (at least Debian and FreeBSD) have been > discussing the question of what exactly should go in the logs. We'd like to > hear from anyone interested in joining those discussions. > >> >> Rich Salz, selective logs >> Some logs will not log every single cert from the CA's in their root list. >> What do we do? >> Discussion, no conclusion. >> >> -- >> Senior Architect, Akamai Technologies >> IM: richsalz@jabber.at Twitter: RichSalz >> - >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --047d7bdc0cf4ee4bf4051bddf5d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 24, 2015 at 12:28 PM, Ben Laurie <benl@google.com> wrote:


On Thu, 23 Jul 201= 5 at 20:59 Salz, Rich <rsalz@akamai.com> wrote:
=C2=A0
More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash = lags) 93 (monitor description inconsistencies) 94 (when/why clients should = fetch inclusion proofs)
Stephen raised issue fhat if threat analysis is normative, schedule gets pu= shed out further. Should be informative.

Steve Kent, attack model
Name changed on doc, even if filename can't easily be changed. Not a th= reat model, we don't know what the attackers are thinking, but we do kn= ow possible actions so it's an attack model.
Includes an intro to CT, he prefers it move into an arch document but if no= t it will stay.
"CT is a set of mechanisms, designed to detect, deter, and facilitate = remediation of certificate mis-issuance"
Semantic mis-issuance: name in the cert refers to an entity incorrectly. Syntactic mis-issuance: violation of certificate profile(s) that apply.
Reviewed a taxonomy of attacks.=C2=A0 Read the doc.=C2=A0 Discussion of add= itions and bigger picture needs.
Incorporated all (but one) comments.
Wants WG agreement via list on goals, definitions, attacks.
We have a half-dozen people commit to read and review the document.
Ben agrees about having an arch doc; Steve and Ben will collaborate on an a= rch doc

I thought I heard other = volunteers. :-)
I'm happy to help wi= th the architecture document .
=C2=A0

Dkg, Gossip
Gossip important to keep logs accountable by making sure everyone sees the = same append-only data and keep their MMD/SCT promises.
Works by browser's sharing and comparing SCT and STH
Three channels:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SCTFeedback;=C2=A0 browser sends cert/sct to we= bsite, website sends to auditing function/third-party auditor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STH Pollination: auditor/website send STH to ea= ch other.=C2=A0 STH are not privacy-sensitive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Optional Trusted Auditor: browser passes sct/ce= rt to auditor (e.g., the DNS resolver since it already knows what you might= be looking at)
Call for adoption is on the mailing list.

Dkg, CT for binary
Goal is to know that you are running the same software as "everyone el= se," not guaranteeing that the software isn't compromised.
Add a binary lLogEntryType; add binary and binary_digest to Signed_Type
Many details of what and how is signed are still open; need feedback from s= /w distributors.
PHB suggest to not use ASN.1
Discussion and agreement that changing the s/w distribution format is a non= -starter.

dkg also noted that so= me distros (at least Debian and FreeBSD) have been discussing the question = of what exactly should go in the logs. We'd like to hear from anyone in= terested in joining those discussions.=C2=A0

Rich Salz, selective logs
Some logs will not log every single cert from the CA's in their root li= st.
What do we do?
Discussion, no conclusion.

--
Senior Architect, Akamai Technologies
IM: richsalz@jabber= .at Twitter: RichSalz
-

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

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


--047d7bdc0cf4ee4bf4051bddf5d8-- From nobody Tue Jul 28 05:45:07 2015 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 423DE1A8A8D for ; Tue, 28 Jul 2015 05:45:06 -0700 (PDT) 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 oAiuUEwJxbF2 for ; Tue, 28 Jul 2015 05:45:02 -0700 (PDT) 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 9F3EC1A8A94 for ; Tue, 28 Jul 2015 05:45:00 -0700 (PDT) Received: from localhost ([::1]:35479 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZK4Fg-0003CY-C0; Tue, 28 Jul 2015 05:45:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, tom@ritter.vg X-Trac-Project: trans Date: Tue, 28 Jul 2015 12:45:00 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/100 Message-ID: <053.5d17eed2b9e6d95cd2ee4d7b33a6d5a4@tools.ietf.org> X-Trac-Ticket-ID: 100 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, tom@ritter.vg, 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: <20150728124500.9F3EC1A8A94@ietfa.amsl.com> Resent-Date: Tue, 28 Jul 2015 05:45:00 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #100 (gossip): Review in light of blocking 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, 28 Jul 2015 12:45:06 -0000 #100: Review in light of blocking We should make sure the draft adequately handles the cases of a network attacker temporarily blocking certain upstream requests. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- tom@ritter.vg | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: gossip | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jul 28 05:47:26 2015 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 826491A8A96 for ; Tue, 28 Jul 2015 05:47:25 -0700 (PDT) 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 9_YcJZuk1F0g for ; Tue, 28 Jul 2015 05:47:23 -0700 (PDT) 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 A24DD1A8A92 for ; Tue, 28 Jul 2015 05:47:23 -0700 (PDT) Received: from localhost ([::1]:35604 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZK4Hz-0004K8-Af; Tue, 28 Jul 2015 05:47:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, tom@ritter.vg X-Trac-Project: trans Date: Tue, 28 Jul 2015 12:47:23 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/101 Message-ID: <053.c1a6dde8a4d3c69c616dd40faefb5e86@tools.ietf.org> X-Trac-Ticket-ID: 101 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, tom@ritter.vg, 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: <20150728124723.A24DD1A8A92@ietfa.amsl.com> Resent-Date: Tue, 28 Jul 2015 05:47:23 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #101 (gossip): Handle Shutdown Log Case 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, 28 Jul 2015 12:47:25 -0000 #101: Handle Shutdown Log Case Draft needs to handle what should be done when a log closes. Shouldn't be too difficult, we can have clients pollinate the final STH - but will the client _know_ when a log has been shut down? It seems like there will be two cases: - The client knows the log is shut down or will be shut down at a specific datetime, and it can use this information to correctly pollinate the final STH. - The client doesn't know, the log shuts down, and it starts getting old STHs that it doesn't pollinate (believing them to be a malicious timestamp-fingerprint attack) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- tom@ritter.vg | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: gossip | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Jul 29 17:21:08 2015 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 C91B01B30D0 for ; Wed, 29 Jul 2015 17:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACbYiqiKiqwV for ; Wed, 29 Jul 2015 17:21:05 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c: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 527381B30CF for ; Wed, 29 Jul 2015 17:21:05 -0700 (PDT) Received: by wibud3 with SMTP id ud3so46946455wib.0 for ; Wed, 29 Jul 2015 17:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ba/LNap8BIzePUhuy9aYjovwcpzt5Duh7DwJ6CArKeo=; b=rggjp1RCp/sh6hzOF6sN7xdoX++IhSIDMXkB798ZZbizIvhPTxxh8Mo/AcwwBJu0YT 4HQAoSyigs1Waf9NK63HutU2S29aIq45myx60j6D/sYHswiC74cFwEIOoWsSVrav4fIl exhrktzfOudHzEltPDyfEEbRT7YfXS/ZOy9zA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ba/LNap8BIzePUhuy9aYjovwcpzt5Duh7DwJ6CArKeo=; b=CmdhWTkAtgeeuvaVsCPmqehQi+XJghaNZPMeYr9QdYWxUFAwRY0Tvfo02QCWY5bm59 1u0EZj5SkOf/UUGMvcg/gWw/TjrxditlRfBJ4qV5lz0K5H9MhF2IljMYNj3t0QiFHDgF 7mFqdiGR0Qjmw3rgY+tLkuLCFIDaBciV4iTIi4OU5iCsiGEI4NzBGDPPu6Xjv8SMRXFY FRdnvW6k8G6d9DEWl8tPdW5QbHLQeqVMx9qUmrv1TD2RDUC0tOiedT8uriK5+ifP9tbl j0WWBn/u7Y0gmS7uhwVpigfEeZrfnAdb0Ii0G3CGFuWEEM7y11hwuhnyIRmVSXG7NihX bCAw== X-Gm-Message-State: ALoCoQlDf7OGiAljFf3YawwKtGKruMlu47ayIcXhIviIR04Gm4WrWi451689R/3WJ0OcpXVnkbm9 X-Received: by 10.194.22.105 with SMTP id c9mr87620402wjf.120.1438215664106; Wed, 29 Jul 2015 17:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.67 with HTTP; Wed, 29 Jul 2015 17:20:44 -0700 (PDT) In-Reply-To: References: <874mkvclg5.fsf@totally-fudged-out-message-id> <87zj2nb5ey.fsf@nordberg.se> From: Tom Ritter Date: Wed, 29 Jul 2015 19:20:44 -0500 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Linus Nordberg Subject: Re: [Trans] Review of draft-linus-trans-gossip-ct-02 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, 30 Jul 2015 00:21:07 -0000 On 25 July 2015 at 05:26, Ben Laurie wrote: > I'm pretty sure I didn't say that. Not that I am particularly opposed to it, > my position is simply that I am not sure what value it adds. Sorry, I don't know where it came from then. And agreed. > BTW, I snipped all your comments about SCT gossip, but I do agree with your > characterisation of the recipient as some kind of Trusted Auditor. I'm not > sure I saw gossip between Trusted Auditors explicitly addressed - would that > be allowed, or dangerous? As long as the Trusted Auditor didn't act in a predictable way with regards to data fed by a client, I believe it is safe for them do SCT Feedback to servers, STH pollination to servers, or send their results directly into a whole different Trusted Auditor. It's only dangerous if I can observe a Client <-> Trusted Auditor connection, and make strong inferences about what happened on that connection. So, clients inputs should be delayed/mixed before being acted on, and Trusted Auditors should be _encouraged_ to both collect as many users as they can (including other Trusted Auditors), and to do SCT Feedback and STH Pollination as much as they can. -tom From nobody Fri Jul 31 07:47:30 2015 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 5A8B41A896C for ; Fri, 31 Jul 2015 07:47:28 -0700 (PDT) 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 ZgA8BAV5oLse for ; Fri, 31 Jul 2015 07:47:27 -0700 (PDT) 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 4BA641A8963 for ; Fri, 31 Jul 2015 07:47:27 -0700 (PDT) Received: from localhost ([::1]:60067 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZLBao-0002El-Lz; Fri, 31 Jul 2015 07:47:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Fri, 31 Jul 2015 14:47:26 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/102 Message-ID: <055.3413498b3c6ddedb48a659659f8bc47d@tools.ietf.org> X-Trac-Ticket-ID: 102 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150731144727.4BA641A8963@ietfa.amsl.com> Resent-Date: Fri, 31 Jul 2015 07:47:27 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [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: Fri, 31 Jul 2015 14:47:28 -0000 #102: "root" should be "trust anchor" Through the I-D we refer to root certificates, whereas the intent (and the practice) is that the "roots" actually include intermediates, too. This seems important, since browsers also include intermediates in their trust anchors. So, we need to correct the use of the term "root" throughout the document. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans