From nobody Tue Mar 1 03:49:56 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08F61A21B4 for ; Tue, 1 Mar 2016 03:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 R2usWYRmdxxy for ; Tue, 1 Mar 2016 03:49:51 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FEB1A21AF for ; Tue, 1 Mar 2016 03:49:51 -0800 (PST) Received: (qmail 28722 invoked by uid 1004); 1 Mar 2016 11:49:49 -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, 01 Mar 2016 11:49:49 +0000 Received: (qmail 8761 invoked by uid 1000); 1 Mar 2016 11:49:49 -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, 01 Mar 2016 11:49:49 +0000 To: Stephen Kent , trans issue tracker , eranm@google.com References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> <072.ee7a69299880709258377930de8c1a93@tools.ietf.org> <56D49C49.6050207@bbn.com> From: Rob Stradling Message-ID: <56D581DC.3050409@comodo.com> Date: Tue, 1 Mar 2016 11:49:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D49C49.6050207@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] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:49:55 -0000 On 29/02/16 19:30, Stephen Kent wrote: > Rob, > > I'm not sure what your proposed resolution for this issue means. > > Phases like "a suitably name-constrained intermediate cert" and This phrase is 'd to the section currently numbered 4.3 (Using a Name-Constrained Intermediate CA). Is that not sufficient? > "clients may need to used trial and error" are not really appropriate > for a standard. I'll await publication of the next rev of 6962-bis to > see if there is an algorithmic description of how the matching is to be > performed. I wrote "MAY need to use trial and error", because a TLS client might guess the correct certificate first time (i.e. without any "error"). Also, in the (many) cases where there are zero suitably name-constrained intermediates in the chain, the SCT or inclusion proof MUST be valid for the end-entity certificate. No trial and error is required when there is only 1 possible choice! The important point is that a TLS client MUST NOT declare that an SCT or inclusion proof is _invalid_ until it has attempted to verify that SCT or inclusion proof against the end-entity cert _and_ against each of the zero or more suitably name-constrained intermediate cert in the certificate chain sent by the TLS server. Do we need to state this point more explicitly in the document? It doesn't matter if a TLS client chooses to attempt to validate against the end-entity cert first or against a suitably name-constrained intermediate first, so I don't think 6962-bis needs to mandate the checking order. > Steve >> #23: How can TLS clients match an SCT to a certificate? >> >> Changes (by rob.stradling@comodo.com): >> >> * milestone: => review >> >> >> Comment: >> >> Fixed by https://github.com/google/certificate-transparency- >> rfcs/commit/d71d7707a3eeb5707cf5048c3849b068e477038c >> >> The !ItemExtension field is gone. When there's a suitably name- >> constrained intermediate in the certificate chain, TLS clients may >> need to >> use trial and error to determine which of the certificates in the >> chain an >> SCT or inclusion proof corresponds to. >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Wed Mar 2 08:07:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806111B2BB2 for ; Wed, 2 Mar 2016 08:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5wGB9ILQvro for ; Wed, 2 Mar 2016 08:07:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5C11A88DA for ; Wed, 2 Mar 2016 08:07:36 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:50649 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ab9JG-00006X-2v; Wed, 02 Mar 2016 11:07:34 -0500 To: Rob Stradling , trans issue tracker , eranm@google.com References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> <072.ee7a69299880709258377930de8c1a93@tools.ietf.org> <56D49C49.6050207@bbn.com> <56D581DC.3050409@comodo.com> From: Stephen Kent Message-ID: <56D70FC5.5040700@bbn.com> Date: Wed, 2 Mar 2016 11:07:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D581DC.3050409@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 16:07:38 -0000 Rob, > On 29/02/16 19:30, Stephen Kent wrote: >> Rob, >> >> I'm not sure what your proposed resolution for this issue means. >> >> Phases like "a suitably name-constrained intermediate cert" and > > This phrase is 'd to the section currently numbered 4.3 (Using a > Name-Constrained Intermediate CA). > > Is that not sufficient? Sorry. I misunderstood the constrained context of your comment. > >> "clients may need to used trial and error" are not really appropriate >> for a standard. I'll await publication of the next rev of 6962-bis to >> see if there is an algorithmic description of how the matching is to be >> performed. > > I wrote "MAY need to use trial and error", because a TLS client might > guess the correct certificate first time (i.e. without any "error"). Guess? That's not exactly an algorithmic characterization for how an implementer is supposed to do this, right? > Also, in the (many) cases where there are zero suitably > name-constrained intermediates in the chain, the SCT or inclusion > proof MUST be valid for the end-entity certificate. No trial and > error is required when there is only 1 possible choice! Agreed, and if the text says this clearly, that will be fine. > The important point is that a TLS client MUST NOT declare that an SCT > or inclusion proof is _invalid_ until it has attempted to verify that > SCT or inclusion proof against the end-entity cert _and_ against each > of the zero or more suitably name-constrained intermediate cert in the > certificate chain sent by the TLS server. > Do we need to state this point more explicitly in the document? I though the focus of this issue was a specification of how a TLS client determines to which cert an SCT applies if the SCT is not embedded in the cert. Looking quickly at Section 9.2, I still do not see text that specifically addresses this topic. Steve From nobody Wed Mar 2 08:14:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FED01B2BD2 for ; Wed, 2 Mar 2016 08:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7gxh0K-z0hd for ; Wed, 2 Mar 2016 08:14:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038F91B2BD6 for ; Wed, 2 Mar 2016 08:14:36 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:59078 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ab9Pz-000Lrb-CM; Wed, 02 Mar 2016 11:14:31 -0500 From: Stephen Kent To: Paul Wouters References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> <56D49D30.5070506@bbn.com> Message-ID: <56D71167.7010201@bbn.com> Date: Wed, 2 Mar 2016 11:14:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org, benl@google.com, draft-ietf-trans-rfc6962-bis@tools.ietf.org, trans issue tracker Subject: Re: [Trans] [trans] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 16:14:37 -0000 Paul, > On Mon, 29 Feb 2016, Stephen Kent wrote: > >> The issue was that 6962-bis does a partial job of describing TLS >> server behavior, >> and that one way to fix this is to remove that description and >> provide a more >> complete description in a separate doc. Your comment does not address >> this concern, >> and I disagree with Paul's decision to accept your proposed wontfix >> resolution. > > Writing a separate document is fine, but out of scope for the bis > document. > > Removing text in the bis document and moving it all to a separate > document > that becomes a blocking normative reference to the bis document is not. There is no need for 6962-bis document to cite a TLS server doc, if 6962-bis focuses on CT log operation. You previously stated that 6962-bis cannot be reduced in scope, but that turned out to not be true (based on any IETF procedural constraints). So, moving the partial TLS server discussion to a separate doc (e.g., https://datatracker.ietf.org/doc/draft-kseo-trans-ca-subject/ is a start on this) does not cause the problem you stated. > > If you have proposed text that improves this section of the bis document, > please share so we can discuss that. https://datatracker.ietf.org/doc/draft-kseo-trans-ca-subject/ includes text about TLS server requirements. It cites relevant sections of 6962-bis, but it would be cleaner if these sections were either moved to that doc or if they appeared in an appendix of 6962-bis. Steve From nobody Wed Mar 2 09:15:45 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE8D1B2CE2 for ; Wed, 2 Mar 2016 09:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiM8pwHngNOl for ; Wed, 2 Mar 2016 09:15:43 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4971B2CC2 for ; Wed, 2 Mar 2016 09:15:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qFhmY57sYzJt2; Wed, 2 Mar 2016 18:15:41 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Hb7LAWgbwk7W; Wed, 2 Mar 2016 18:15:40 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 Mar 2016 18:15:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3C3236066254; Wed, 2 Mar 2016 12:15:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3C3236066254 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 383FCDA52F; Wed, 2 Mar 2016 12:15:38 -0500 (EST) Date: Wed, 2 Mar 2016 12:15:38 -0500 (EST) From: Paul Wouters To: Stephen Kent In-Reply-To: <56D71167.7010201@bbn.com> Message-ID: References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> <56D49D30.5070506@bbn.com> <56D71167.7010201@bbn.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: trans@ietf.org, benl@google.com, draft-ietf-trans-rfc6962-bis@tools.ietf.org, trans issue tracker Subject: Re: [Trans] [trans] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:15:45 -0000 On Wed, 2 Mar 2016, Stephen Kent wrote: Steve, >> If you have proposed text that improves this section of the bis document, >> please share so we can discuss that. > https://datatracker.ietf.org/doc/draft-kseo-trans-ca-subject/ includes > text about TLS server requirements. It cites relevant sections of 6962-bis, > but it would be cleaner if these sections were either moved to that doc > or if they appeared in an appendix of 6962-bis. Since you are the one objecting to the current state of the section, you would be the best person to write up a one paragraph summary text to be discussed for inclusion in this section of the bis document. Paul From nobody Wed Mar 2 12:15:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21031B2F0B for ; Wed, 2 Mar 2016 12:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJVUChgRXMqI for ; Wed, 2 Mar 2016 12:15:22 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C781B2F0A for ; Wed, 2 Mar 2016 12:15:22 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qFmlr4gkXzJtM; Wed, 2 Mar 2016 21:15:20 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id kgDFq05sEm2I; Wed, 2 Mar 2016 21:15:19 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 Mar 2016 21:15:19 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D64286066254; Wed, 2 Mar 2016 15:15:18 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D64286066254 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D4B5ADA534; Wed, 2 Mar 2016 15:15:18 -0500 (EST) Date: Wed, 2 Mar 2016 15:15:18 -0500 (EST) From: Paul Wouters To: Trans , Melinda Shore Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) 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, 02 Mar 2016 20:15:23 -0000 This starts a two week WGLC for draft-ietf-trans-threat-analysis https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ The purpose of the WG Last Call is to get working group consensus that the document is complete and provides a threat analysis that is useful to implementors of CT. If you feel this document should not proceed, please also let us know why you think so. Please send all comments to the list. The WGLC ends on March 16, 2016 Paul & Melinda From nobody Wed Mar 2 12:42:07 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A581B2FFA for ; Wed, 2 Mar 2016 12:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrFgWHiQEv8C for ; Wed, 2 Mar 2016 12:42:02 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id AD78D1B2FE5 for ; Wed, 2 Mar 2016 12:42:02 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E098A200007; Wed, 2 Mar 2016 20:42:01 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C960A200006; Wed, 2 Mar 2016 20:42:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456951321; bh=NctwMKzrpSFLmVDS81U0N7SwJZBOpGu5h5eqamQ1jfU=; l=10; h=From:To:Date:References:In-Reply-To:From; b=g00kU7c4O4bOkTAyiI7sF+Gxu+WPesqKavfU011ssGO3AmU/N3Gti/ksr0g+F9T3E 6ZEM+rL34Oj75/QvVo6EWaoZC2r2Sme/SUqgmqF6yMdIeof1t0bYiRX4rkc7ArQZ2l 16NG0cq0BgC/4CnBqc1JO8yxV9KanAdrJmvdnVbs= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id B080C98082; Wed, 2 Mar 2016 20:42:01 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Mar 2016 15:42:01 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 2 Mar 2016 15:42:01 -0500 From: "Salz, Rich" To: Paul Wouters , Trans , Melinda Shore Thread-Topic: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) Thread-Index: AQHRdMBEsUiHu/dcdEyWiiLeKXA2XZ9Gnmmw Date: Wed, 2 Mar 2016 20:42:00 +0000 Message-ID: References: In-Reply-To: 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.112.212] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) 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, 02 Mar 2016 20:42:05 -0000 Ship it! From nobody Wed Mar 2 14:03:21 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E47D1B3292 for ; Wed, 2 Mar 2016 14:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbUHrVAvDKKI for ; Wed, 2 Mar 2016 14:03:19 -0800 (PST) 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 169FB1B3281 for ; Wed, 2 Mar 2016 14:03:19 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id z13so1411015ykd.0 for ; Wed, 02 Mar 2016 14:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5NNjA78+Gshx4sIJ+IlD7SXwhZ2aLirx4/+jC6MuNmI=; b=VYAZSwkNqz97wR04/CL5rtrmv+Me4Y7dBte+O/a3bOS8FvmDBpkBCaNt/eoUzMwFol i/AR1MTfzu+TQ3txT4L3y4P30DiTbmo9mfZS/GC04EOMZ40UKH/uX3W4zlXXHJFJMSks I/QmduPhZT8ntCZi7GYPlICkad3UtjqsirvcQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5NNjA78+Gshx4sIJ+IlD7SXwhZ2aLirx4/+jC6MuNmI=; b=YWFL8Hxwjk7Pk4buWDG/Cs1BnKRD46VxdqlCRVtH3RwTjSWF28/Yx3FT+HW/w7BGof +jlhb+At8Ka6P6FeWi/WCNgRR/lJePdmISgBdBm0zzajbxZb8bRFtUEwgCj9ig7b7jZY r90sCqDxoE8AhwTzX9GkTd8v9XchaYTA+HGbgwPdxdLTxThlOUV/je8OvEzP4X6gaFde ho/OM1gr+HcLrD7jIbUFuiZ3xhxUf4/gCMQ18G+oNwv0tkt0xvT0hJT5xeiPpC1GbRMn HqLo3SKv4KZCZDgiLV5M/qXX3FjVltmkh7IXEidadAvq4z8OIbbJbagODMoRfGtjt6rS +kXQ== X-Gm-Message-State: AD7BkJLrktkjFnUVPxSGl9SvwAZulnyKJb/L9xfejy4/oM1cdLlhJNwXuRr72LkCLfpk5W6couoJ9ZBas7ocXk4e X-Received: by 10.37.92.139 with SMTP id q133mr4760393ybb.118.1456956198405; Wed, 02 Mar 2016 14:03:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.48.214 with HTTP; Wed, 2 Mar 2016 14:02:58 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Wed, 2 Mar 2016 16:02:58 -0600 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Paul Wouters , Trans , Melinda Shore Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) 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, 02 Mar 2016 22:03:20 -0000 I believe this document should include the dual-CA compromise attack that dkg illustrated a short while ago. -tom On 2 March 2016 at 14:42, Salz, Rich wrote: > Ship it! > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Fri Mar 4 04:58:44 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7251B3817 for ; Fri, 4 Mar 2016 04:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09PMzVgkCMqH for ; Fri, 4 Mar 2016 04:58:42 -0800 (PST) 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 412A01B3811 for ; Fri, 4 Mar 2016 04:58:42 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id z13so22401884ykd.0 for ; Fri, 04 Mar 2016 04:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OrK8ObHZbK3XQjuropdooRwa/zZ3BAinSrA9wMnOjow=; b=TKJjVLvNfE04mIO6wBtDPKfr4hx8bkPSNmID+8yccQhx3ju/Lr1A/X837eipgRVG6Z KQbaWSnUGf+REHJG+q2omm0Miq2YaiBZOG/KHh9BL5rnUKKlbFBWKMwAk+DMje+ymAam arPVhsax3LeLPsdextwNhLTxB0owr+scJj5LHaZWqiAN76e5oWUR9jd70VtXwJzDoIye VOAYvrlUs5/QpYSZrHB/bFJ9h+H/+GNsCZfRZkppXNCV60GoiTNB4Gbs4/Giuqj3JGcG IZVthV2aE/6TCNcR4+3Re//m3Ah0oucKa1hwDiPp7hjJMwrSF7HaHTNpTuieyMuWOaRC Mzsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OrK8ObHZbK3XQjuropdooRwa/zZ3BAinSrA9wMnOjow=; b=UDh0uN108RxCbKHnS0hu2IjvREe6zOO1ZZeaTPiHoLVXsQhKfHquW1bGN1iMsj2GWF m6wAN2Ch7b43KxEctKyyinJga+1lR1o7WvtklLBMYBh2LruvXOSM9q+QbHLoWlTBRU7/ qCjyiw+mQYzMuH8CvZxT5lZ++6b+sfDPGAfY6+BXRgrG4xLn2RGtsnFp2z5YUKr35B1A 0p/vrmIaF9ff+lCrpp1O35IN5BsGHh9IDRZtNOBi31MbayKCZyIphxuHQIlNOH+owcSE gio7fiE4sKn/icThjFGwAoNy7QoVsSHh0pi1UCOqV4OplE3HZDPp068DwC7S4+a9l2tG 7tJw== X-Gm-Message-State: AD7BkJIL6XQQm5TMMmHxbLmUxrfTjxLC74SQXBW/TszhWwfKkEcPCC7xn0OM3me9s5CCnMU2lPYggvRKZ1Qf87rJ MIME-Version: 1.0 X-Received: by 10.37.43.87 with SMTP id r84mr4732188ybr.105.1457096321413; Fri, 04 Mar 2016 04:58:41 -0800 (PST) Received: by 10.37.216.21 with HTTP; Fri, 4 Mar 2016 04:58:41 -0800 (PST) In-Reply-To: References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> <56D49D30.5070506@bbn.com> <56D71167.7010201@bbn.com> Date: Fri, 4 Mar 2016 12:58:41 +0000 Message-ID: From: Eran Messeri To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11352f8aa4a78e052d38acae Archived-At: Cc: Ben Laurie , trans issue tracker , "trans@ietf.org" , Stephen Kent , draft-ietf-trans-rfc6962-bis@tools.ietf.org Subject: Re: [Trans] [trans] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 12:58:43 -0000 --001a11352f8aa4a78e052d38acae Content-Type: text/plain; charset=UTF-8 Having reviewed that section, I can't find requirements from CT-enabled TLS servers that are not documented in it. Steve, were there any particular roles/requirements of CT-enabled TLS servers that you feel are missing? The only amendment is appending "CT-aware" to "TLS servers" everywhere, but it seems implied given the entire document is about CT... On Wed, Mar 2, 2016 at 5:15 PM, Paul Wouters wrote: > On Wed, 2 Mar 2016, Stephen Kent wrote: > > Steve, > > If you have proposed text that improves this section of the bis document, >>> please share so we can discuss that. >>> >> > https://datatracker.ietf.org/doc/draft-kseo-trans-ca-subject/ includes >> text about TLS server requirements. It cites relevant sections of >> 6962-bis, >> but it would be cleaner if these sections were either moved to that doc >> or if they appeared in an appendix of 6962-bis. >> > > Since you are the one objecting to the current state of the section, you > would be the best person to write up a one paragraph summary text to be > discussed for inclusion in this section of the bis document. > > Paul > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11352f8aa4a78e052d38acae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Having reviewed that section, I can't find requirement= s from CT-enabled TLS servers that are not documented in it.

S= teve, were there any particular roles/requirements of CT-enabled TLS server= s that you feel are missing?
The only amendment is appending &quo= t;CT-aware" to "TLS servers" everywhere, but it seems implie= d given the entire document is about CT...

On Wed, Mar 2, 2016 at 5:15 PM, = Paul Wouters <paul@nohats.ca> wrote:
On Wed, 2 Mar 2016, Stephen Kent wrote:

Steve,

=C2=A0If you have proposed text that improves this section of the bis docum= ent,
=C2=A0please share so we can discuss that.

https://datatracker.ietf.org/doc/draft-= kseo-trans-ca-subject/ includes
text about TLS server requirements. It cites relevant sections of 6962-bis,=
but it would be cleaner if these sections were either moved to that doc
or if they appeared in an appendix of 6962-bis.

 Since you are the one objecting to the current state of the section, you would be the best person to write up a one paragraph summary text to be
discussed for inclusion in this section of the bis document.

Paul


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

--001a11352f8aa4a78e052d38acae-- From nobody Fri Mar 4 06:13:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB931A01D7 for ; Fri, 4 Mar 2016 06:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PKwmh6dj3xo for ; Fri, 4 Mar 2016 06:13:31 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 F1D7F1A01A4 for ; Fri, 4 Mar 2016 06:13:30 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id m184so63370373iof.1 for ; Fri, 04 Mar 2016 06:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Lynlt6bNoEx7rC83DDZKbe6yeHVs4vO042fD5zxigLI=; b=OM6rzPHEYORXH3rIETNNKEJDfqBoFcXVdAEZqnHBlfXVbTzR+V1rygcQDjIOsJ3YzW SM6DcxGm5Y0K4jRDjvRPuRYBYTlbag6nSUpV1ai7BBRODtVHX5zvj498EQPrajBzChOc KoMjOhrfVipjtSZYOjR9CsqIZpQBKzSFvUSdAFDVD27VcBdeNhuQV0DP8x2+SngtgOzH 8GGjKcOrlpcEL4pvFYzpeVhS3RvRGJUDgA5/RLcCeEGeLy7xNJA3EKZtO5m+qiljS0H7 xVEha1TDR7In7/HtmjAzXf+kYJSVcjdgXlnKRdL9NgeJaq82MkCSme6t/MvlIoqQEQ+E gmHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Lynlt6bNoEx7rC83DDZKbe6yeHVs4vO042fD5zxigLI=; b=CRs+FGz4BRe6qNUWGVINgxBEJgsr0i24rBS4T7DG98E9tE5Cnr+pKHk/dW2Yd6WmNz yB/Y3ekcLVfCX35WssQKzc36ZXVl+dgltIy1LbGmztTg2sn6Rgjue1aVNvi+wh73o6Kc m6+QZtqyrRfA0KA0/OlMbbbZWygzLFdmfCLMtiMoI30WNXJNJm35Ns1/YtqoTXffM2xc FSg1DLYihxL6S76HikVo1md2LH3aUYDaOjNc3L7IE4pnhLdOWj1auwQcsP+lR9bxmXGy JZcezCAM7ba5ryAG6eDUBu8nmtBxN0vEkWaSZ+cGwIa9UJ6FP+poBnbKlS5CzOHsX8vV TZqw== X-Gm-Message-State: AD7BkJKbxsKKjZ7xE1LbsLfi87Jl68xmm/Djfv8qwoVLtj9+zYIuW2+A0pFdJ/L7fNSMPfl3WtBS6h0MzgM/3BZS MIME-Version: 1.0 X-Received: by 10.107.15.148 with SMTP id 20mr6604687iop.119.1457100810207; Fri, 04 Mar 2016 06:13:30 -0800 (PST) Received: by 10.64.143.106 with HTTP; Fri, 4 Mar 2016 06:13:30 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 14:13:30 +0000 Message-ID: From: Ben Laurie To: Tom Ritter Content-Type: multipart/alternative; boundary=001a113ed7263227a8052d39b885 Archived-At: Cc: "Salz, Rich" , Paul Wouters , Trans , Melinda Shore Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) 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, 04 Mar 2016 14:13:32 -0000 --001a113ed7263227a8052d39b885 Content-Type: text/plain; charset=UTF-8 On 2 March 2016 at 22:02, Tom Ritter wrote: > I believe this document should include the dual-CA compromise attack > that dkg illustrated a short while ago. > +1 > > -tom > > On 2 March 2016 at 14:42, Salz, Rich wrote: > > Ship it! > > > > _______________________________________________ > > 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 > --001a113ed7263227a8052d39b885 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 March 2016 at 22:02, Tom Ritter <tom@ritter.vg> wrote:<= br>
I believe this document should include th= e dual-CA compromise attack
that dkg illustrated a short while ago.

+1
=C2=A0

-tom

On 2 March 2016 at 14:42, Salz, Rich <rsalz@akamai.com> wrote:
> Ship it!
>
> _______________________________________________
> 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

--001a113ed7263227a8052d39b885-- From nobody Fri Mar 4 08:16:39 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303C21A6F82 for ; Fri, 4 Mar 2016 08:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH_INSCVotHU for ; Fri, 4 Mar 2016 08:16:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8051A6F7F for ; Fri, 4 Mar 2016 08:16:34 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:39970 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1absOw-000ELG-Lo for trans@ietf.org; Fri, 04 Mar 2016 11:16:26 -0500 To: trans@ietf.org References: From: Stephen Kent Message-ID: <56D9B4DB.3000209@bbn.com> Date: Fri, 4 Mar 2016 11:16:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) 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, 04 Mar 2016 16:16:38 -0000 Good point. I'll try to generate some text to cover this attack, add it, and re-publish when that's done. Steve > I believe this document should include the dual-CA compromise attack > that dkg illustrated a short while ago. > > -tom > > On 2 March 2016 at 14:42, Salz, Rich wrote: >> Ship it! >> >> _______________________________________________ >> 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 > From nobody Mon Mar 7 04:15:29 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C251B3FF4 for ; Mon, 7 Mar 2016 04:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-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 mJGULCZfC1Ky for ; Mon, 7 Mar 2016 04:15:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5873B1B3FEF for ; Mon, 7 Mar 2016 04:15:26 -0800 (PST) Received: from localhost ([::1]:59886 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1acu4K-0004Xz-Gn; Mon, 07 Mar 2016 04:15:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, david@mandelberg.org, eranm@google.com X-Trac-Project: trans Date: Mon, 07 Mar 2016 12:15:24 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:2 Message-ID: <068.fd2c40edee59dd0e795fce22d4350bb7@tools.ietf.org> References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, david@mandelberg.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: <20160307121526.5873B1B3FEF@ietfa.amsl.com> Resent-Date: Mon, 7 Mar 2016 04:15:26 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers 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, 07 Mar 2016 12:15:27 -0000 #145: Section 9.2 (TLS clients) needs more guidance for browsers Comment (by eranm@google.com): My understanding of the original problem raised in the ticket is that the section on TLS clients is vague/confusing because it prescribes some actions but not the results of these actions, is that right? For example that TLS clients MUST reject an SCT whose timestamp is in the future, but not what it implies for a client to have rejected this SCT. Is this understanding accurate? If so, we can remedy these particular points. However,my understanding is that prescribing client behaviour is outside the scope of 6962-bis. Regarding the focus on browsers, I disagree: A significant portion of traffic nowadays is from native mobile applications which rely on SSL+PKI for securing their connections, but are not browsers. Such an application can decide to hard-fail a connection if no valid SCTs are present, for example, because that particular application communicates with a small set of servers, all of which are expected to serve SCTs. For this reason I think that the proposed text in comment 1 about browsers and incremental deployment is not applicable. I have proposed re-wording of the example provided, of SCTs with timestamp in the future, here: https://github.com/eranmes/certificate-transparency- rfcs/commit/c643193aeea93afe57baf7a63589fa5ec4cf5d6e Does that address at least that case? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@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 Mar 7 04:33:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C1A1B4047 for ; Mon, 7 Mar 2016 04:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=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 eR1wcA6dbMg2 for ; Mon, 7 Mar 2016 04:33:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855321B4043 for ; Mon, 7 Mar 2016 04:33:16 -0800 (PST) Received: from localhost ([::1]:60631 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1acuLW-0005L3-8U; Mon, 07 Mar 2016 04:33:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Mon, 07 Mar 2016 12:33:10 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/144#comment:1 Message-ID: <068.32b62e42d03cffe09f16d68e38c96118@tools.ietf.org> References: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-Trac-Ticket-ID: 144 In-Reply-To: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #144 (rfc6962-bis): Need to specify how the CA requirements in 12.3 are to be met 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, 07 Mar 2016 12:33:18 -0000 #144: Need to specify how the CA requirements in 12.3 are to be met Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com Comment: Good point about specifying behaviour of CAs - the definition of a 'single entity' is unclear and anyway, the purpose of this section is to point out the dangers of over-redaction. It is hard to define what over-redaction is here, so my proposal (after talking to Rob about it) is to point out to the PSL as an example of domains for which redacted precertificates would be 'overly-redacted' and make this section more informative, less prescriptive. -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Mon Mar 7 04:39:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E5E1B405A for ; Mon, 7 Mar 2016 04:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uOMdEBZmVn9 for ; Mon, 7 Mar 2016 04:39:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465161B4059 for ; Mon, 7 Mar 2016 04:39:34 -0800 (PST) Received: from localhost ([::1]:60948 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1acuRe-0002LH-Hm; Mon, 07 Mar 2016 04:39:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Mon, 07 Mar 2016 12:39:30 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/155 Message-ID: <057.8604f552ae07311e21d62f3ee9f24898@tools.ietf.org> X-Trac-Ticket-ID: 155 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, 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 Archived-At: Cc: trans@ietf.org, kent@bbn.com Subject: [Trans] [trans] #155 (rfc6962-bis): Describe how to match SCTs to certificates 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, 07 Mar 2016 12:39:36 -0000 #155: Describe how to match SCTs to certificates To capture the discussion here: https://mailarchive.ietf.org/arch/msg/trans/f6t4-uILmlOTg8W4IkwHI16LZx0 Seems sensible to have a description of one way a client could match SCTs to a certificate in the chain, given SCTs could match name-redacted intermediates. This is related to ticket 23. -- ------------------------------+-------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: ------------------------------+-------------------------------------- Ticket URL: trans From nobody Mon Mar 7 04:40:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5FA1B4060 for ; Mon, 7 Mar 2016 04:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9GSh-ZSXqiT for ; Mon, 7 Mar 2016 04:40:12 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 51F6F1B405F for ; Mon, 7 Mar 2016 04:40:12 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id d65so22613822ywb.0 for ; Mon, 07 Mar 2016 04:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Hacd+gfAyhRsbHg5CArecKaOj2+kLYv1JOOnZtmmwz0=; b=Z7mCP5VMsXweNw0R8GbywNv6PZkBw6Bg6Q0qE9GSaRbOW08h3oJMf+UdqtvvE1bWL1 cWjoMjms7x9zw/fL57iM9uk6hSb9fbsjejiUgn+4hEmDBrw6NNI1fy2OkD2YJzxtTzBu PcjA0uAB46bg77IP6oJk1pay6zazLyDF0XplEuSeoe4MvF9WIOWJMDvWeBFDgwY9ph6H cfQOlf3MlotKqeUk1QxPHtszsc6IC2PWd/DAflk5jTeoNZmeSmE3yyoRpOzZ1iDxDa4s 5rb6epq7cEiiqqDQgFxIFLcJLvZouI0UM5CJ7OuQ3WbpJLlLD5gGnU/FXOpMZa3mTIsv 4cEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Hacd+gfAyhRsbHg5CArecKaOj2+kLYv1JOOnZtmmwz0=; b=NoQMndeOwYvFbJRw7ryXOHZZltJP6ra0a2jO7CM1L+KsA0DxcGsrxz2Mn/VV/WQUNP Oss1xqO6NABLMYa74gZ8L/Zsd2BtPl56OzPA9eVhkvQ7v34BmTVmxAg952Y+Tn20UU36 lR3YqljHbQeTSAq96WVkG+8G3VZceh/Z+M3+iMaxMRLi8Tl7Y9SVBAi7zqw/3sjEYyRy +22RN0/b5vfLRoDAEuUuwW1cdcjUyHstXJSRNBJ5cRQxfLqgYIXW/3MAU6+22HXWlIzS MUdfUS3r3Kl2eUnSO1zMDiH8+IJnS/LksNRDqu/MZmra03xzuPR5dynlyQYE0WSoNfgE cVQg== X-Gm-Message-State: AD7BkJJyRhT/pA5UJw16KXB/6ifOwWEH1xGGg/esuAAAYPRYjGlTLwzRXNA2PScKlPhKJLuBK0MojJDRE5Pgc6it MIME-Version: 1.0 X-Received: by 10.13.208.198 with SMTP id s189mr14096780ywd.130.1457354411564; Mon, 07 Mar 2016 04:40:11 -0800 (PST) Received: by 10.37.216.21 with HTTP; Mon, 7 Mar 2016 04:40:11 -0800 (PST) In-Reply-To: <56D70FC5.5040700@bbn.com> References: <057.41d486c63b077d86861cc22b16426ceb@tools.ietf.org> <072.ee7a69299880709258377930de8c1a93@tools.ietf.org> <56D49C49.6050207@bbn.com> <56D581DC.3050409@comodo.com> <56D70FC5.5040700@bbn.com> Date: Mon, 7 Mar 2016 12:40:11 +0000 Message-ID: From: Eran Messeri To: Stephen Kent Content-Type: multipart/alternative; boundary=001a114d76f403bfc6052d74c411 Archived-At: Cc: Rob Stradling , "trans@ietf.org" , trans issue tracker Subject: Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 12:40:14 -0000 --001a114d76f403bfc6052d74c411 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 2, 2016 at 4:07 PM, Stephen Kent wrote: > Rob, > > > On 29/02/16 19:30, Stephen Kent wrote: >> >>> Rob, >>> >>> I'm not sure what your proposed resolution for this issue means. >>> >>> Phases like "a suitably name-constrained intermediate cert" and >>> >> >> This phrase is 'd to the section currently numbered 4.3 (Using a >> Name-Constrained Intermediate CA). >> >> Is that not sufficient? >> > Sorry. I misunderstood the constrained context of your comment. > >> >> "clients may need to used trial and error" are not really appropriate >>> for a standard. I'll await publication of the next rev of 6962-bis to >>> see if there is an algorithmic description of how the matching is to be >>> performed. >>> >> >> I wrote "MAY need to use trial and error", because a TLS client might >> guess the correct certificate first time (i.e. without any "error"). >> > Guess? That's not exactly an algorithmic characterization for how an > implementer is > supposed to do this, right? > >> Also, in the (many) cases where there are zero suitably name-constrained >> intermediates in the chain, the SCT or inclusion proof MUST be valid for >> the end-entity certificate. No trial and error is required when there is >> only 1 possible choice! >> > Agreed, and if the text says this clearly, that will be fine. > >> The important point is that a TLS client MUST NOT declare that an SCT or >> inclusion proof is _invalid_ until it has attempted to verify that SCT or >> inclusion proof against the end-entity cert _and_ against each of the zero >> or more suitably name-constrained intermediate cert in the certificate >> chain sent by the TLS server. >> Do we need to state this point more explicitly in the document? >> > I though the focus of this issue was a specification of how a TLS client > determines to > which cert an SCT applies if the SCT is not embedded in the cert. Looking > quickly at > Section 9.2, I still do not see text that specifically addresses this > topic. > The requirement to suggest at least one way to do so is captured in https://trac.tools.ietf.org/wg/trans/trac/ticket/155. > > Steve > --001a114d76f403bfc6052d74c411 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 2, 2016 at 4:07 PM, Stephen Kent <kent@bbn.com> w= rote:
Rob,


On 29/02/16 19:30, Stephen Kent wrote:
Rob,

I'm not sure what your proposed resolution for this issue means.

Phases like "a suitably name-constrained intermediate cert" and

This phrase is <xref>'d to the section currently numbered 4.3 (Us= ing a Name-Constrained Intermediate CA).

Is that not sufficient?
 Sorry. I misunderstood the constrained context of your comment.

"clients may need to used trial and error" are not really appropr= iate
for a standard. I'll await publication=C2=A0 of the next rev of 6962-bi= s to
see if there is an algorithmic description of how the matching is to be
performed.

I wrote "MAY need to use trial and error", because a TLS client m= ight guess the correct certificate first time (i.e. without any "error= ").
 Guess? That's not exactly an algorithmic characterization for how an im= plementer is
supposed to do this, right?
Also, in the (many) cases where there are zero suitably name-constrained in= termediates in the chain, the SCT or inclusion proof MUST be valid for the = end-entity certificate.=C2=A0 No trial and error is required when there is = only 1 possible choice!
 Agreed, and if the text says this clearly, that will be fine.
The important point is that a TLS client MUST NOT declare that an SCT or in= clusion proof is _invalid_ until it has attempted to verify that SCT or inc= lusion proof against the end-entity cert _and_ against each of the zero or = more suitably name-constrained intermediate cert in the certificate chain s= ent by the TLS server.
Do we need to state this point more explicitly in the document?
 I though the focus of this issue was a specification=C2=A0 of how a TLS cli= ent determines to
which cert an SCT applies if the SCT is not embedded in the cert. Looking q= uickly at
Section 9.2, I still do not see text that specifically addresses this topic= .
The requirement to suggest at least one way to do so= is captured in https://trac.tools.ietf.org/wg/trans/trac/ticket/155.=C2=A0
=

Steve

--001a114d76f403bfc6052d74c411-- From nobody Mon Mar 7 05:51:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92051B4150 for ; Mon, 7 Mar 2016 05:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mh8PQ0Zpu6h for ; Mon, 7 Mar 2016 05:51:11 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 F3ABE1B414C for ; Mon, 7 Mar 2016 05:51:10 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g203so131310953iof.2 for ; Mon, 07 Mar 2016 05:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=f19o9jTen07J6qDTq60ZOlep/PSBinXSCj11ev32iys=; b=Os30vAK+5rsW9NSMQptj4GnVN4mTvd9KUEybLVcvF/AeHOpJ5y7e4j7NFSobC7ChH+ +jvqPg7qK6Wa3Qu8aRIoGj6v4LNCsCO2F+nSB27YRcLJaG/hYGsdD4/NjTvZVCqHIh1B GGKxgbx2c+ublZdOXvBHWV8WjslP2+1oKxy0/8zNCP9KRGGMhwpbWcwRMbt9AoyVWH8L xT7LxdYCxZtUJlXbN5PBU/KA8yZLbyFD9J2/MGuNL6vzV4Lsa4fZr8NDQUfBhoYKP0+4 xKjE+1ANSyym61ukp003Dmd9li7PX8Ws36FsJKGXYD+MqpM3fhuxhFOBP5B8gEmaVv85 Dg8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=f19o9jTen07J6qDTq60ZOlep/PSBinXSCj11ev32iys=; b=VYoIlQCYIu9v710uxvvWuyierolu5+2RqdiXJV0TQWbwb1WdaeVO5WTDWNKnTJpDqB 2MT1io8hnrwvLYISp+NDnKruOUG6Ag/ALlJbX+oDSUN+TRU0+K6IxCS4kY2AA8InKMaM qKBLIgJwMFNccAa8XPEy+9D3Pi+5FcUuvmZlR9ERXdPQyfd+jOiq78K1rJfSgPlo31a+ UMTv4h7CofPP3A4GoVsIc2OMsyG1PZykgQSTG631Z3piei3fJlTDGFzhxz8c1f4Bb2+0 MWeL5PoeGvL9BI30QSGYWh5G5I6Vk5APxRveNCY2HcMbzhWJ4YLcy4p9Yt9tJw9K8yyH 28gg== X-Gm-Message-State: AD7BkJKWJUJS30VjpEyxjO3MDMDkz7LC9c3uGbU2JzaXwbPXFGaYMl/pL2eBNYnQ5g/HZSMCnIlbFKJO9sCB/oVO MIME-Version: 1.0 X-Received: by 10.107.26.201 with SMTP id a192mr21578626ioa.13.1457358670181; Mon, 07 Mar 2016 05:51:10 -0800 (PST) Received: by 10.64.245.105 with HTTP; Mon, 7 Mar 2016 05:51:10 -0800 (PST) In-Reply-To: <56D49EC0.7030709@bbn.com> References: <56B1192D.4020102@gmail.com> <56D49EC0.7030709@bbn.com> Date: Mon, 7 Mar 2016 13:51:10 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Looking for feedback on open issue X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 13:51:14 -0000 On 29 February 2016 at 19:40, Stephen Kent wrote: > Ben, > > > > On 2 February 2016 at 21:01, Melinda Shore wrote: >> >> Hi, all: >> >> We're looking for feedback on ticket 121 >> (https://trac.tools.ietf.org/wg/trans/trac/ticket/121). >> >> The issue is this (from Steve Kent): >> >> "After Prague I agreed that log metadata can be supplied by browser >> vendors for TLS clients hat are browsers. However, max chain length, which >> was just discussed on the list (11/16-17/15), is an example of metadata that >> needs to be acquired by CAs, just like the public key for a log. The text in >> Section 9 needs to say more about how non-browser log clients are expected >> to acquire this data, or maybe it should say that separate docs defining >> requirements for each of these types of log clients will discuss this >> issue."We continue >> >> >> and where it currently stands is this (from Eran Messeri): >> >> I agree that log metadata dissemination is a topic that should be more >> thoroughly discussed at some point. However, I do not think that 6962-bis is >> the right place for it. >> Steve has a very valid point about metadata not being specified in a >> machine-readable format, nor having a part of the protocol describing how it >> is disseminated. >> I believe these issues should be addressed separately of 6962-bis, >> because: >> The topic of log metadata is one level "above" what 6962-bis discusses. >> The requirements for metadata dissemination are very different for each >> type of client. >> Disseminating metadata reliably is a protocol in itself, which (once the >> requirements are clear) deserve its own design. >> My suggestion is to punt the discussion until after 6962-bis is out. >> Presumably then there would be enough different clients implementing >> 6962-bis that disseminating metadata would justify more efforts from this >> workgroup. >> >> This needs further discussion - should this go into a separate >> document? > > > If it needs documenting at all, then yes. > > We continue to have dramatically different views on what needs to be > specified in > one or more RFCs so that a standard is well-specified. This is yet another > example > of our different views. If 6962-bis wants to be viewed as a spec for CT, not > just for > the CT log, then this is another example of a gap in the spec. My point is we seem to be getting along just fine with ad hoc dissemination of metadata so far, and I don't think we have enough experience of the needs of clients in general to start inventing more formal mechanisms. I notice that plenty of the 'net seems to work just fine without nailing down such questions: e.g. what is the mechanism for disseminating metadata about DNS caching resolvers, as used by almost all clients? From nobody Mon Mar 7 06:01:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4681B411F for ; Mon, 7 Mar 2016 06:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQuwE6yvNeQ1 for ; Mon, 7 Mar 2016 06:01:47 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1002F1B417C for ; Mon, 7 Mar 2016 06:01:27 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id g203so131627598iof.2 for ; Mon, 07 Mar 2016 06:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vbygjRcWlGo9W8FdWpHAqXHZJF4M8DFOe0QdPHuNF38=; b=M3ss/egZ3szF0JCN7RhjvlcJ566egGOD/sJb3uVPWSMxf8njJAhKbUC5ux/H0gsz+Z iwOOFW50xUQ+uHZ4Ax3tSCkMcBpQ+Wf4uzf5hdajWHYRN6Q20LXo3C+C5gBB2voL5Dbs fvkQVfw1Ha6n7qIJQV5P0O+7pHZnGRxptDXGIxcEVxbvN+9QEVlRKsJohWvl1rpjTL30 anRmCV26XHvA5g8G9XvzustrSbFsbKEwtApIvM3zZUn28Q9+dCQ7kshm4hta6itciVuS qOXlLRXbYNmFq3pBewyOYXEhUmm10eQA4wM6vEdYZf5jqZ1rjzVgBCwvPyimnUWWPOu0 83lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vbygjRcWlGo9W8FdWpHAqXHZJF4M8DFOe0QdPHuNF38=; b=MGrMnaXnY5GkLZzgst3hU9v2D+W2JLbHsvv50DePwtm25GUQSEPy1X6wkRMCFMBD9g SiyyUEVkhkH3v1z1Ecm+DzdgJ550jdDmqPBNy8NWy8xy2IApQ4TTtdkehwn98cuVLglc tc6zl2hHYHCxz82W6JJtPZYEacErJyRCyULznHxEkt4iqjs0CjRbhSILbIlcQAyNFov0 llgiBWRhyMDaSAo7HaANivPSKw3laM8rQIxTPDpJ2pILliVbhMzAcjZI9cGdjgdzu86k GElFD5cq/QNn3QjjAT5/XjoK1/leQKB7pAIsgOIhUEYiVqrpK6UiiZEdmi2MtUm2Fnfg v9fg== X-Gm-Message-State: AD7BkJJRzyw0EkIEJGacHGNc66zTJYXWoyrYc6iKq8uwNDqoMj1uYi9ntuoG3lRAYQwDabsqH1mXw6vBXPTzZYZz MIME-Version: 1.0 X-Received: by 10.107.157.80 with SMTP id g77mr23518172ioe.172.1457359286986; Mon, 07 Mar 2016 06:01:26 -0800 (PST) Received: by 10.64.245.105 with HTTP; Mon, 7 Mar 2016 06:01:26 -0800 (PST) In-Reply-To: <56D49DD6.9090906@bbn.com> References: <053.1c580d171592bb2acabeaa241fef51ff@tools.ietf.org> <068.d19af4a885287eecc4596e837195df4b@tools.ietf.org> <56D49DD6.9090906@bbn.com> Date: Mon, 7 Mar 2016 14:01:26 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , draft-ietf-trans-rfc6962-bis@tools.ietf.org, trans issue tracker Subject: Re: [Trans] [trans] #123 (rfc6962-bis): log clients description too informal, incomplete X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 14:01:51 -0000 On 29 February 2016 at 19:36, Stephen Kent wrote: > Ben, > >> #123: log clients description too informal, incomplete >> >> Changes (by benl@google.com): >> >> * milestone: => review >> >> >> Comment: >> >> The point is that CT provides data you might choose to act on. This >> section describes some ways in which you can reliably get hold of the >> data >> you might choose to act on. It is intended to be informative and without >> it would make it substantially difficult for implementers to implement >> CT. >> >> Suggest resolve wontfix. >> > My point is that a squishy discussion of what a log client might do isn't > appropriate for a standard. If one cannot be precise in describing how each > element of a system is supposed to work, then readers have no confidence > that > there is a consistent, comprehensive system design. Different readers can > come away with different notions of how the system works, which leads to > confusion. We do describe in considerable detail how each type of client works in that section - but we cannot document every possible use of the APIs the I-D defines. Hence we point out that there are other things you might choose to do, as a user of the API. If you'd prefer a different way to make that point, happy to consider it. From nobody Tue Mar 8 06:30:31 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7529612D721 for ; Tue, 8 Mar 2016 06:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gv6gAYzzflg for ; Tue, 8 Mar 2016 06:30:22 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CACE12D71F for ; Tue, 8 Mar 2016 06:30:19 -0800 (PST) Received: from localhost ([::1]:52557 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1adIeQ-0007FZ-Qz; Tue, 08 Mar 2016 06:30:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Tue, 08 Mar 2016 14:30:18 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/144#comment:2 Message-ID: <068.d1652d7d49dbe26a36e19c9241992fc6@tools.ietf.org> References: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-Trac-Ticket-ID: 144 In-Reply-To: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #144 (rfc6962-bis): Need to specify how the CA requirements in 12.3 are to be met X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 14:30:30 -0000 #144: Need to specify how the CA requirements in 12.3 are to be met Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency-rfcs/pull/131 -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Tue Mar 8 07:46:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C361612D626 for ; Tue, 8 Mar 2016 07:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Trt7ghHWtMFr for ; Tue, 8 Mar 2016 07:46:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5908612D787 for ; Tue, 8 Mar 2016 07:46:37 -0800 (PST) Received: from localhost ([::1]:55105 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1adJqD-0003HP-OX; Tue, 08 Mar 2016 07:46:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com X-Trac-Project: trans Date: Tue, 08 Mar 2016 15:46:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/81#comment:7 Message-ID: <080.a87afd5863948e20482362750eee1709@tools.ietf.org> References: <065.7e2aed9eafe145755b95ef51d9921722@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <065.7e2aed9eafe145755b95ef51d9921722@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 15:46:39 -0000 #81: OIDs and IANA Considerations Changes (by rob.stradling@comodo.com): * milestone: => review Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/0bbcfa5a6feb92cd781978d3757f251aaa8cf0bc -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Mar 8 07:48:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD8212D7B3 for ; Tue, 8 Mar 2016 07:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHfzCxuX4Igz for ; Tue, 8 Mar 2016 07:48:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0FC12D7AA for ; Tue, 8 Mar 2016 07:48:16 -0800 (PST) Received: from localhost ([::1]:55158 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1adJrs-0003v5-Bx; Tue, 08 Mar 2016 07:48:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Tue, 08 Mar 2016 15:48:16 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/154#comment:2 Message-ID: <080.0bb7043e62715ca6b38feb8e3aae7adc@tools.ietf.org> References: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org> X-Trac-Ticket-ID: 154 In-Reply-To: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #154 (rfc6962-bis): CSR extension to convey a certificate subscriber's CT preferences to the CA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 15:48:20 -0000 #154: CSR extension to convey a certificate subscriber's CT preferences to the CA Comment (by rob.stradling@comodo.com): The OID 1.3.101.79 has been reserved for this proposed CSR extension. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Mar 9 07:21:58 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC81D12E0EF for ; Wed, 9 Mar 2016 07:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_YSnH2yJ32D for ; Wed, 9 Mar 2016 07:05:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455C812E07C for ; Wed, 9 Mar 2016 06:57:41 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:33994 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1adfYR-0003tS-N3 for trans@ietf.org; Wed, 09 Mar 2016 09:57:39 -0500 From: Stephen Kent To: trans@ietf.org References: <053.ea75201ed52854fe5b1e6b563b8dcbab@tools.ietf.org> <068.fc184547f1f9f0d48df1bb3a69238013@tools.ietf.org> <56D49D30.5070506@bbn.com> <56D71167.7010201@bbn.com> Message-ID: <56E039E8.4070302@bbn.com> Date: Wed, 9 Mar 2016 09:57:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.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] #122 (rfc6962-bis): TLS server requirements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:05:27 -0000 Eran, > Having reviewed that section, I can't find requirements from > CT-enabled TLS servers that are not documented in it. > > Steve, were there any particular roles/requirements of CT-enabled TLS > servers that you feel are missing? > The only amendment is appending "CT-aware" to "TLS servers" > everywhere, but it seems implied given the entire document is about CT... Karen Seo is the author of the Sever/CA doc, so this is a question best answered by her. I injected my comments because I had not seen a message from her on this topic. Since Karen's long-time significant other, Ray Tomlinson (the man who put "@" in e-mail addresses), passed away on Saturday morning, she may not be ready to deal with this now. Steve From nobody Wed Mar 9 09:39:31 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393A612E07C for ; Wed, 9 Mar 2016 09:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvQbv8QS2zJI for ; Wed, 9 Mar 2016 09:39:24 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B856A12D836 for ; Wed, 9 Mar 2016 09:38:11 -0800 (PST) Received: from localhost ([::1]:58137 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1adi3k-0000K0-Qg; Wed, 09 Mar 2016 09:38:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, hadfieldp@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 09 Mar 2016 17:38:08 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/57#comment:6 Message-ID: <080.785b955d3d34bc0073942e08b5c5b459@tools.ietf.org> References: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, hadfieldp@google.com, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #57 (rfc6962-bis): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:39:29 -0000 #57: Clients MUST NOT match the redaction label with a "*" label Changes (by eranm@google.com): * milestone: => review Comment: Fixed in https://github.com/google/certificate-transparency- rfcs/commit/744e4dbceed5ad46e8f5b3e52b122961cee657e1, please review. -- --------------------------------------+------------------------------- Reporter: rob.stradling@comodo.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 Thu Mar 10 14:58:18 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF012DE80 for ; Thu, 10 Mar 2016 14:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heUzNiOpVSp4 for ; Thu, 10 Mar 2016 14:58:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356B712DE7E for ; Thu, 10 Mar 2016 14:58:15 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52849) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ae9X3-000O2c-Pz for trans@ietf.org; Thu, 10 Mar 2016 17:58:13 -0500 From: Stephen Kent To: trans@ietf.org References: <56B1192D.4020102@gmail.com> <56D49EC0.7030709@bbn.com> Message-ID: <56E1FC05.6070409@bbn.com> Date: Thu, 10 Mar 2016 17:58:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Looking for feedback on open issue X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 22:58:17 -0000 Ben, ... > My point is we seem to be getting along just fine with ad hoc > dissemination of metadata so far, and I don't think we have enough > experience of the needs of clients in general to start inventing more > formal mechanisms. I notice that plenty of the 'net seems to work just > fine without nailing down such questions: e.g. what is the mechanism > for disseminating metadata about DNS caching resolvers, as used by > almost all clients? Ad hoc may be working now, but if CT wants to claim that it can scale to accommodate lots of logs and monitors, including self-monitors, then there needs to be a description of how this will work. Not sure I understand your comment about DNS; DHCP is usually used to acquire the address of the nearest DNS server. DHCP was developed because we lacked a standard way to acquire this data and the ad hoc mechanisms didn't scale well. Steve From nobody Thu Mar 10 14:58:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC34512DE72 for ; Thu, 10 Mar 2016 14:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0_5y_K3tVQh for ; Thu, 10 Mar 2016 14:58:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1EE12DE82 for ; Thu, 10 Mar 2016 14:58:42 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52850) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ae9XT-000O2z-Ji; Thu, 10 Mar 2016 17:58:39 -0500 From: Stephen Kent To: Ben Laurie References: <053.1c580d171592bb2acabeaa241fef51ff@tools.ietf.org> <068.d19af4a885287eecc4596e837195df4b@tools.ietf.org> <56D49DD6.9090906@bbn.com> Message-ID: <56E1FC1F.6020404@bbn.com> Date: Thu, 10 Mar 2016 17:58:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , draft-ietf-trans-rfc6962-bis@tools.ietf.org, trans issue tracker Subject: Re: [Trans] [trans] #123 (rfc6962-bis): log clients description too informal, incomplete X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 22:58:48 -0000 Ben, > ... >> My point is that a squishy discussion of what a log client might do isn't >> appropriate for a standard. If one cannot be precise in describing how each >> element of a system is supposed to work, then readers have no confidence >> that >> there is a consistent, comprehensive system design. Different readers can >> come away with different notions of how the system works, which leads to >> confusion. > We do describe in considerable detail how each type of client works in > that section - but we cannot document every possible use of the APIs > the I-D defines. Hence we point out that there are other things you > might choose to do, as a user of the API. If you'd prefer a different > way to make that point, happy to consider it. I don't think it is necessary to define how every client might use these APIs. I think that a good spec for each CT element would describe what functions the client MUST/SHOULD perform, and how to use the APIs to achieve those functions. Examples are good, but they are never a substitute for well-written specs. Steve From nobody Thu Mar 10 15:08:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBE912DE9D for ; Thu, 10 Mar 2016 15:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kPpt4i8nPwU for ; Thu, 10 Mar 2016 15:08:33 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C68412DE9A for ; Thu, 10 Mar 2016 15:08:28 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52873) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ae9gx-000HY9-AI for trans@ietf.org; Thu, 10 Mar 2016 18:08:27 -0500 From: Stephen Kent To: trans@ietf.org References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> <068.fd2c40edee59dd0e795fce22d4350bb7@tools.ietf.org> Message-ID: <56E1FE6B.4090005@bbn.com> Date: Thu, 10 Mar 2016 18:08:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <068.fd2c40edee59dd0e795fce22d4350bb7@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 23:08:35 -0000 Eran, > #145: Section 9.2 (TLS clients) needs more guidance for browsers > > > Comment (byeranm@google.com): > > My understanding of the original problem raised in the ticket is that the > section on TLS clients is vague/confusing because it prescribes some > actions but not the results of these actions, is that right? > For example that TLS clients MUST reject an SCT whose timestamp is in the > future, but not what it implies for a client to have rejected this SCT. Is > this understanding accurate? That's a pretty good summary. Another way to look at this issue is that the way the text reads, a black box analysis of a TLS client cannot determine if the client complies with the spec. In general, it's a bad idea to state requirements that cannot be verified. > If so, we can remedy these particular points. However,my understanding is > that prescribing client behaviour is outside the scope of 6962-bis. unfortunately, the text tries to have it both ways, i.e., it specifies some level of client behavior using the term "compliant" yet it avoids requiring any specific behavior by the client. That's not helpful. > Regarding the focus on browsers, I disagree: A significant portion of > traffic nowadays is from native mobile applications which rely on SSL+PKI > for securing their connections, but are not browsers. Such an application > can decide to hard-fail a connection if no valid SCTs are present, for > example, because that particular application communicates with a small set > of servers, all of which are expected to serve SCTs. I agree that non-browser TLS clients are becoming more important. But, they need not rely on the Web PKI model that browsers use. You postulated a scenario in which a TLS client communicates with a small set of servers and is configured to know that all of them are expected to provide SCTs. You are describing something that is not, AFAIK, described in any extant RFC. Thus its questionable to make CT TLS client specs vague by citing such client scenarios. I believe almost all of the discussions in TRANS have focused on browsers. Certainly the Auditor proposal seesm to be very-much focused on browsers interacting with web servers. Thus I don't agree with the suggestion that the TLS client discussion should be considered generic, e.g., in order to make statements about non-proscriptive behavior less specific. > For this reason I think that the proposed text in comment 1 about browsers > and incremental deployment is not applicable. I recall the meeting in London where I raised the issue about incremental deployment, in response to the text in the (then current) version of 6962-bis. That text called for a TLS client to reject certs not accompanied by SCTs. Ben's response was to declare that this aspect of client behavior was out of scope for 6962-bis. So, now there's a new, different reason for sort-of specifying client behavior without really specifying it? > I have proposed re-wording of the example provided, of SCTs with timestamp > in the future, here: > https://github.com/eranmes/certificate-transparency- > rfcs/commit/c643193aeea93afe57baf7a63589fa5ec4cf5d6e > > Does that address at least that case? I don't read github posts of proposed text. I read I-Ds when they are posted, or text sent to the list, the common methods for IETF WG discussions of suggested text for I-Ds. Steve From nobody Fri Mar 11 02:27:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A7712DD34 for ; Fri, 11 Mar 2016 02:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQpRVRM53y2E for ; Fri, 11 Mar 2016 02:27:48 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C345812D58A for ; Fri, 11 Mar 2016 02:27:47 -0800 (PST) Received: (qmail 15422 invoked by uid 1004); 11 Mar 2016 10:27:45 -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, 11 Mar 2016 10:27:45 +0000 Received: (qmail 16673 invoked by uid 1000); 11 Mar 2016 10:27:45 -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, 11 Mar 2016 10:27:45 +0000 To: Stephen Kent , trans@ietf.org References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> <068.fd2c40edee59dd0e795fce22d4350bb7@tools.ietf.org> <56E1FE6B.4090005@bbn.com> From: Rob Stradling Message-ID: <56E29D9F.9020409@comodo.com> Date: Fri, 11 Mar 2016 10:27:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E1FE6B.4090005@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 10:27:51 -0000 On 10/03/16 23:08, Stephen Kent wrote: > I don't read github posts of proposed text. I read I-Ds when they are > posted, or text sent to the list, the common methods for IETF WG > discussions of suggested text for I-Ds. Hi Steve. FWIW, I would classify GitHub as a "common method" these days... https://www.ietf.org/mailman/listinfo/ietf-and-github "About Ietf-and-github GitHub is being used by more IETF Working Groups for proposing and tracking changes to WG Internet-Drafts. Using GitHub for normal WG processes requires some training, and edge cases in its usage abound. This list will be used for answering questions of individual WG participants and for creating IETF-wide documentation on how to use GitHub effectively in WG processes." -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Mar 11 04:45:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2677E12E0FE for ; Fri, 11 Mar 2016 04:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXZhdRr3caCi for ; Fri, 11 Mar 2016 04:45:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0660.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::660]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C64612D6CF for ; Fri, 11 Mar 2016 04:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cDhrtZStohm+i0acyRES/Lb3fsO8hXtLvl5xzqcTemw=; b=LezePr76NE2hM8gs1kBwnT+LTugL/nrLdUhanfAakCIl6QhfVTM7HkYJ0mQvcErjXGTxL/9lxZWcw7G3monR7QOEMtXoCPzZ+SDZtymmAs6X6gOKm+Qt4gMrirbG0P+c1u7IiY7k2miqDjTiMIRfp5985U4s7u9RsVRPphgP7wc= Received: from SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) by SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 11 Mar 2016 12:44:46 +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.0427.020; Fri, 11 Mar 2016 12:44:46 +0000 From: Robin Wilton To: Rob Stradling Thread-Topic: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers Thread-Index: AQHRLzAuObncFNjGlUyJTQ+pA7egep9Od60AgAVtdICAAL3JgIAAJhgA Date: Fri, 11 Mar 2016 12:44:46 +0000 Message-ID: References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> <068.fd2c40edee59dd0e795fce22d4350bb7@tools.ietf.org> <56E1FE6B.4090005@bbn.com> <56E29D9F.9020409@comodo.com> In-Reply-To: <56E29D9F.9020409@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: comodo.com; dkim=none (message not signed) header.d=none;comodo.com; dmarc=none action=none header.from=isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [94.174.34.240] x-ms-office365-filtering-correlation-id: adf8bab1-a8b4-45d3-dc7c-08d349aaed7f x-microsoft-exchange-diagnostics: 1; SN1PR06MB1839; 5:aVVEE5F/Iz0wpPp3z2sLqF75wqo/bxxoSDmOz6PaOrrZ8XrBzWvv9XtxvZydE9JQZO21AowDDDaXRRmEkNHRRNNr9FLXz3J+Iq1CyKyNkEuNeUH+OtfoWsragRSCDPyWcE6ZUeMfRnvm3wC4PXiMqg==; 24:/o9F34ruVfj9w+GeQ2fTa14UPIyDm4TpoXLCjahxTUIj1hbHtmVlnIo1UcYBAA4pOF0tPPG30+0I4itYr1Fi7uGbniDuai15NVQsBU5pHig= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB1839; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415293)(102615271)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR06MB1839; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1839; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(15975445007)(10400500002)(77096005)(2906002)(4326007)(1096002)(87936001)(6116002)(11100500001)(102836003)(5008740100001)(106116001)(1220700001)(3660700001)(3846002)(2900100001)(36756003)(2950100001)(189998001)(3280700002)(110136002)(93886004)(76176999)(5002640100001)(122556002)(33656002)(92566002)(99936001)(81166005)(50986999)(54356999)(86362001)(83716003)(66066001)(82746002)(5004730100002)(19580395003)(586003)(99286002)(19580405001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1839; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_9968697C-BDD2-4DA9-BBCB-63FB8E8CCD4C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 12:44:46.4406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1839 Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 12:45:08 -0000 --Apple-Mail=_9968697C-BDD2-4DA9-BBCB-63FB8E8CCD4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 Mar 2016, at 10:27, Rob Stradling = wrote: > On 10/03/16 23:08, Stephen Kent wrote: > >> I don't read github posts of proposed text. I read I-Ds when they are >> posted, or text sent to the list, the common methods for IETF WG >> discussions of suggested text for I-Ds. Hmm. As someone who has just sent a revision-marked draft to an IETF = mailing list (in proprietary file format, too, I=92m ashamed to say), I = was somewhat worried about the potential for confusion if someone else = happened to be editing another copy of it at the time. If Github offers ways to help with version control on collaborative = docs, I think that is to be encouraged. R >=20 > Hi Steve. FWIW, I would classify GitHub as a "common method" these = days... >=20 > https://www.ietf.org/mailman/listinfo/ietf-and-github >=20 > "About Ietf-and-github > GitHub is being used by more IETF Working Groups for proposing and = tracking changes to WG Internet-Drafts. Using GitHub for normal WG = processes requires some training, and edge cases in its usage abound. = This list will be used for answering questions of individual WG = participants and for creating IETF-wide documentation on how to use = GitHub effectively in WG processes." >=20 > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_9968697C-BDD2-4DA9-BBCB-63FB8E8CCD4C 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----- iF4EAREIAAYFAlbivZoACgkQ646Z8yy2wEw08QD9EMVdh1uVEw3ODwr99Ix0kOGO 5qysQ33NUY5D9ttZZJEBAIEAsVOBbzxMNSqo9TxWNI4Y/YqTZGhElUJ7UeKCcr3K =b4nj -----END PGP SIGNATURE----- --Apple-Mail=_9968697C-BDD2-4DA9-BBCB-63FB8E8CCD4C-- From nobody Fri Mar 11 07:03:00 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECDD12D82A for ; Fri, 11 Mar 2016 07:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZGm2mGblZ60 for ; Fri, 11 Mar 2016 07:02:56 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C8512D745 for ; Fri, 11 Mar 2016 07:02:29 -0800 (PST) Received: (qmail 525 invoked by uid 1004); 11 Mar 2016 15:02:27 -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, 11 Mar 2016 15:02:27 +0000 Received: (qmail 17055 invoked by uid 1000); 11 Mar 2016 15:02:27 -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, 11 Mar 2016 15:02:27 +0000 To: Robin Wilton References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> <068.fd2c40edee59dd0e795fce22d4350bb7@tools.ietf.org> <56E1FE6B.4090005@bbn.com> <56E29D9F.9020409@comodo.com> From: Rob Stradling Message-ID: <56E2DE01.20207@comodo.com> Date: Fri, 11 Mar 2016 15:02:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 15:02:59 -0000 On 11/03/16 12:44, Robin Wilton wrote: > Hmm. As someone who has just sent a revision-marked draft to an IETF mailing list (in proprietary file format, too, Im ashamed to say), I was somewhat worried about the potential for confusion if someone else happened to be editing another copy of it at the time. > > If Github offers ways to help with version control on collaborative docs, I think that is to be encouraged. Yes! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Mar 11 09:23:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A2912D9BE for ; Fri, 11 Mar 2016 09:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzWBHLeIK3SG for ; Fri, 11 Mar 2016 09:23:08 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFD512D9C4 for ; Fri, 11 Mar 2016 09:23:08 -0800 (PST) Received: by mail-pa0-x236.google.com with SMTP id td3so76990154pab.2 for ; Fri, 11 Mar 2016 09:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=sd/ZmzU6scsj9lmKRNAl46nQondWH/b1tQcTgs6DP8o=; b=tAlj8yUxvZqCk6YQjZoLLUJ5LynGPg+p5u/iQ576USKrTKE1v652imC0aWMOsj6MIe vhTdJ51EEeax4pJJ2BPy9VtWjOOwaYp3+ktxfQ8AwV1nV2qblQvbWTKnBvqasCtuVeAf UNgAEr4gvxsOPoWCwpcZHRYrvFK2bI5vUed9Uzip/+FsEYn4RetsvaQrHatE6h9AVvap 0HDwsqTAT7ovOzx3l+GXThkawVInNqc6etyee8Xe7JmOJB0x56lPmZKgoellwVh1HjAS mZzkOJ277MRloCOpKh8VIx1kbYTtPKrziaKYM9XkznlDN8MFg+xJXYVWNicXs33fcOaW AClg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sd/ZmzU6scsj9lmKRNAl46nQondWH/b1tQcTgs6DP8o=; b=P3nu285RsN/hOHRSZPlIgsO3M3Khw27x7/GNKAahE6N5+yTzhQgdyth3qdb3oc9jg9 VJ+2znmEB+ehGW9eR/4ptTlA+N4FYBvYnFW549w8lUmSIN43uoePUZUKpFS+MzDroOwB xt1/+d75UPU0jmsq4Ly5wVqWkzjXXH/XAzwzRY3BGx3rSzvfmCTIy7RbNHWIyf6/a209 EWYF4dNHLSeh4CHB8TXJVdZ10vQWMAv0g+qKLJuNG+rT6IXdS7/a/IpenITRs0TGvdiz bxF9QidfRzrpINaI9FrDd/Y9R9VHV9wWC0bfNAhNbz7CmmD3Sw904Me0JFf+v2koRZ6K 55FQ== X-Gm-Message-State: AD7BkJJkBkrKCqdA9VuViIPPkUtw9nO39mCykUpVJGGCbW09tY2IVCPA+7QILKztUoZQsQ== X-Received: by 10.66.199.66 with SMTP id ji2mr15937561pac.34.1457716987956; Fri, 11 Mar 2016 09:23:07 -0800 (PST) Received: from Melindas-MacBook-Pro.local (63-140-101-120-radius.dynamic.acsalaska.net. [63.140.101.120]) by smtp.googlemail.com with ESMTPSA id b74sm14285220pfd.24.2016.03.11.09.23.06 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2016 09:23:07 -0800 (PST) To: trans@ietf.org References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> <068.fd2c40edee59dd0e795fce22d4350bb7@tools.ietf.org> <56E1FE6B.4090005@bbn.com> From: Melinda Shore Message-ID: <56E2FF58.4070508@gmail.com> Date: Fri, 11 Mar 2016 08:24:40 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E1FE6B.4090005@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 17:23:11 -0000 On 3/10/16 2:08 PM, Stephen Kent wrote: > I don't read github posts of proposed text. I read I-Ds when they are > posted, or text sent to the list, the common methods for IETF WG > discussions of suggested text for I-Ds. That's certainly your prerogative, but git is a very widely used tool, Github is free, Github requires no knowledge of git (it's a point-and-click interface), and using a publicly-hosted versioning system provides more transparency, not less. Because of this we will tend to discount objections you've raised based on your unwillingness to look at revised text for which the link has been posted. Melinda From nobody Fri Mar 11 15:28:42 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C6212DE39; Fri, 11 Mar 2016 15:05:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230536.15028.14855.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:36 -0800 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 15:28:40 -0800 Cc: trans@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Trans] trans - Requested session has been scheduled for IETF 95 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:39 -0000 Dear Paul Wouters, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Quebracho A size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Paul Wouters Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: dane curdle dnsop tls Second Priority: ipsecme saag Special Requests: --------------------------------------------------------- From nobody Fri Mar 11 15:29:59 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F07412DD5F for ; Fri, 11 Mar 2016 15:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 905TLNZEAVSX for ; Fri, 11 Mar 2016 15:29:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6103212DD7B for ; Fri, 11 Mar 2016 15:29:47 -0800 (PST) Received: from localhost ([::1]:40672 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aeWV6-0006ff-6D; Fri, 11 Mar 2016 15:29:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com, hadfieldp@google.com, rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Fri, 11 Mar 2016 23:29:44 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/57#comment:7 Message-ID: <080.56d383099f77204aa6e11d4b9edc25d0@tools.ietf.org> References: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <065.9905e58e255dff093227cf657154e341@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, hadfieldp@google.com, rob.stradling@comodo.com, 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] #57 (rfc6962-bis): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:29:57 -0000 #57: Clients MUST NOT match the redaction label with a "*" label Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- --------------------------------------+------------------------------- Reporter: rob.stradling@comodo.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 Mar 14 05:15:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74DA12D587 for ; Mon, 14 Mar 2016 05:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xukLSIk4n-z for ; Mon, 14 Mar 2016 05:15: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 715B912D574 for ; Mon, 14 Mar 2016 05:15:16 -0700 (PDT) Received: from localhost ([::1]:46967 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1afRP1-0004bD-3E; Mon, 14 Mar 2016 05:15:15 -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, david@mandelberg.org, eranm@google.com X-Trac-Project: trans Date: Mon, 14 Mar 2016 12:15:14 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:3 Message-ID: <068.e951c4b95419a2ef5bf6031224ea908a@tools.ietf.org> References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, david@mandelberg.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: <20160314121516.715B912D574@ietfa.amsl.com> Resent-Date: Mon, 14 Mar 2016 05:15:16 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 12:15:19 -0000 #145: Section 9.2 (TLS clients) needs more guidance for browsers Comment (by eranm@google.com): Steve Kent replied on the list, attempting to summarize his response: - It should be possible to do a black-box analysis of a TLS client to determine if it's CT compliant. So prescribing requirements that can't be verified is a bad idea. - He does not agree that with the suggestion that the TLS client discussion should be considered generic (i.e. not specific to browsers). - He claims that "now there's a new, different reason for sort-of specifying client behavior without really specifying it?". (I don't fully understand why this argument is made). Based on his reply I will push the change mentioned in comment #2 for review, which will address the first issue. As for the other issues they are broader and I will leave them for discussion on the mailing list. My opinion is that any browser-specific guidance provided in this RFC should be non-normative, since there are real-world scenarios where 6962-bis could be applied to non-browser TLS clients. But I really don't see the point of suggesting any behaivour to browsers - they're perfectly capable of figuring out themselves what to do once CT compliance/non- compliance has been established. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@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 Mar 14 05:16:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E900212D587 for ; Mon, 14 Mar 2016 05:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pSCt6JBYOqY for ; Mon, 14 Mar 2016 05:16:18 -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 B3A9712D574 for ; Mon, 14 Mar 2016 05:16:18 -0700 (PDT) Received: from localhost ([::1]:47089 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1afRQ1-0000gl-FU; Mon, 14 Mar 2016 05:16: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, david@mandelberg.org, eranm@google.com X-Trac-Project: trans Date: Mon, 14 Mar 2016 12:16:17 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:4 Message-ID: <068.6c09848f96b1d89203a1a9ef11c60e58@tools.ietf.org> References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, david@mandelberg.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: <20160314121618.B3A9712D574@ietfa.amsl.com> Resent-Date: Mon, 14 Mar 2016 05:16:18 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 12:16:20 -0000 #145: Section 9.2 (TLS clients) needs more guidance for browsers Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/134. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kseo@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 Mar 14 05:16:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D93212D58E for ; Mon, 14 Mar 2016 05:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2WONr3cWMwG for ; Mon, 14 Mar 2016 05:16: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 035AA12D55F for ; Mon, 14 Mar 2016 05:16:34 -0700 (PDT) Received: from localhost ([::1]:47112 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1afRQH-0001gI-Ay; Mon, 14 Mar 2016 05:16: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: eranm@google.com, david@mandelberg.org X-Trac-Project: trans Date: Mon, 14 Mar 2016 12:16:33 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:5 Message-ID: <068.c29e5709f8c35a7ffd5f2cad081c64ff@tools.ietf.org> References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, david@mandelberg.org, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 12:16:35 -0000 #145: Section 9.2 (TLS clients) needs more guidance for browsers Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Mon Mar 14 05:24:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2A012D594 for ; Mon, 14 Mar 2016 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SkEcu1EYv7o for ; Mon, 14 Mar 2016 05:24:19 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 0CEAA12D50A for ; Mon, 14 Mar 2016 05:24:11 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g127so164327363ywf.2 for ; Mon, 14 Mar 2016 05:24: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; bh=Bh0IsQM8XM3nVvM6/ju+Ccjx/R1SrTSensd1zoGB/ug=; b=hSBqbm0NjRebUwRQ2PjDa2i29TaBiv7KgCEUrzhF1b4PkoqYgajpwtZwiHcKYOb6Xa llY7KO9LSulKO6Pbfzj8aEJslWIs3bLN9H8Ph+Yqt8fAhe1Uajuy7EU4oLWzzqST5bkP OsTiKO8qY2AQSPUWmjfafYFfLqR32HB9zEAPiH7QIjHNHpHNLqD/2fFVvBnN0su7qGmv gGOspnnYpR6yh/JhCx7vPs84yFYT54b2pZpACllLEM4CrKFYJjhX1osux1Jg1oNhhe6X ihS1FXRP06WOD3gSotqOMeyGo2o5FMHHjMUZoaZlcHEP3Fsynqkzbwvl3udACqdY8T1b 5LXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Bh0IsQM8XM3nVvM6/ju+Ccjx/R1SrTSensd1zoGB/ug=; b=Il4+mnkP8//4Fs3ySqJ+WmRFQeTO+5eqheRjXJfNB0mYH+gLNLefyaJFPs496y/H53 71g3e680yzdzrN+B4Swk5lMya7XnPz1Ws9fwUz2SKfLU9X3s+yo5JHGcFgUvefx5p3tR rc5rDKArcvsmBKpnVgyLrGH6HmFSdOT1eWhsZDst/2WhogunTAb06y54RBgONTKyNjUG IXotzQjhZY76wlD8y9q/5sIc/vFytcwvilWUtEFfCJkG/JesSFvCNz/SHWILpNo+IoVR 6HfS4F7jOY9PKZydhbjuKdS55HVOaRgn2Oi9/+sNqZb14mOTuwOrR3qBNANvs097wXv8 7vvg== X-Gm-Message-State: AD7BkJIFMo/UWMyGlHMwbzdL7Pd9u9/PX1rWF+e3lCaMZsQvgJJ5v5VUjPo+/Gwtt7rCN+mBkYBweqZBBQnff297 MIME-Version: 1.0 X-Received: by 10.129.33.67 with SMTP id h64mr12374100ywh.83.1457958250183; Mon, 14 Mar 2016 05:24:10 -0700 (PDT) Received: by 10.37.48.6 with HTTP; Mon, 14 Mar 2016 05:24:10 -0700 (PDT) In-Reply-To: <56E1FC05.6070409@bbn.com> References: <56B1192D.4020102@gmail.com> <56D49EC0.7030709@bbn.com> <56E1FC05.6070409@bbn.com> Date: Mon, 14 Mar 2016 12:24:10 +0000 Message-ID: From: Eran Messeri To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11425f1699f321052e015ba4 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Looking for feedback on open issue X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 12:24:24 -0000 --001a11425f1699f321052e015ba4 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2016 at 10:58 PM, Stephen Kent wrote: > Ben, > > ... > >> My point is we seem to be getting along just fine with ad hoc >> dissemination of metadata so far, and I don't think we have enough >> experience of the needs of clients in general to start inventing more >> formal mechanisms. I notice that plenty of the 'net seems to work just >> fine without nailing down such questions: e.g. what is the mechanism >> for disseminating metadata about DNS caching resolvers, as used by >> almost all clients? >> > > Ad hoc may be working now, but if CT wants to claim that it can scale > to accommodate lots of logs and monitors, including self-monitors, then > there needs to be a description of how this will work. > One way to view this is that ad-hoc specification of log metadata is enough right now, as CT scales we will need to specify a way to disseminate metadata - so rfc6962-bis should not be blocked on specifying a protocol for metadata dissemination. Note that there is indeed an ad-hoc way to disseminate log metadata, in http://www.certificate-transparency.org/known-logs, which seems to satisfy the needs of current clients/monitors - at least I haven't heard anyone complain about its inadequacy. > > Not sure I understand your comment about DNS; DHCP is usually used to > acquire the address of the nearest DNS server. DHCP was developed because > we > lacked a standard way to acquire this data and the ad hoc mechanisms > didn't scale well. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11425f1699f321052e015ba4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 10, 2016 at 10:58 PM, Stephen Kent <kent@bbn.com>= wrote:
Ben,

...
My point is we seem to be getting along just fine with ad hoc
dissemination of metadata so far, and I don't think we have enough
experience of the needs of clients in general to start inventing more
formal mechanisms. I notice that plenty of the 'net seems to work just<= br> fine without nailing down such questions: e.g. what is the mechanism
for disseminating metadata about DNS caching resolvers, as used by
almost all clients?

 Ad hoc may be working now, but if CT wants to claim that it can scale
to accommodate lots of logs and monitors, including self-monitors, then
there needs to be a description of how this will work.
One way to view this is that ad-hoc specification of log metadata is enoug= h right now, as CT scales we will need to specify a way to disseminate meta= data - so rfc6962-bis should not be blocked on specifying a protocol for me= tadata dissemination.

Note that there is indeed an= ad-hoc way to disseminate log metadata, in=C2=A0http://www.certificate-transparency.or= g/known-logs, which seems to satisfy the needs of current clients/monit= ors - at least I haven't heard anyone complain about its inadequacy.

Not sure I understand your comment about DNS; DHCP is usually used to
acquire the address of the nearest DNS server. DHCP was developed because w= e
lacked a standard way to acquire this data and the ad hoc mechanisms
didn't scale well.

Steve


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

--001a11425f1699f321052e015ba4-- From nobody Mon Mar 14 06:44:59 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB5D12D516 for ; Mon, 14 Mar 2016 06:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFA5s2Rkd41g for ; Mon, 14 Mar 2016 06:44:51 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E487F12D518 for ; Mon, 14 Mar 2016 06:44:49 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g3so167109819ywa.3 for ; Mon, 14 Mar 2016 06:44:49 -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; bh=tlbgkUCCg03k1XGM257T958WMEUnJZfNjrI0LZZQRX0=; b=gj8J5v7UqVU3gf9isNNMeljzXJ29/WEDofXse423EGl2/hCyS3qSnoK1BJpK0FprxG Kugm4ZtdrrOnf2XM/zY+DTUwaW6vkRTsnbL+B1r2kg93nG4iEOtpQArUkAgv1GYt+80H lq9316LXoRCSa3pc2JAL4MzTwQ2iwcSBw9diuayn1CISRRoYP/40lK1dXeJuOXry6ksV oW6u4ry9TXmeamLln58CgVLQWcGIV/uZLA8WlDEsZlSUqaC6rfyYmYsqhovxhuOAjCGy FQd2D/bNDux51YyBcYIqPOzzobRl741DCrkwCEC/3oBID7G3RtbW+KLvHR+IlW3pas1O jV5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tlbgkUCCg03k1XGM257T958WMEUnJZfNjrI0LZZQRX0=; b=Gr3LIEx+/t2fyaDIblBcRPhnhfZ7aZzCbg11eM/RCSpg+3l31iE+mQRe595r8PWfaP /6+XFO+07wKOBba8FBUmE+lPBhuxrIKPkiQY7g7Rk3XdQkjSwZS6pAXWfgWddMW93ui8 p0HX14NBdpSZeXEHRigPxngFuR/unvVkaTedPt0wYeiSzc47Dww417f/g2pduOwNVyT1 Q+bYNo5kkiIiYlreGiIQfIGKBpv9JGoA7gUdwuSHy0V74IeptmchukcjBs/Dh4fsY5QS vmX329NgCfVu8keAstqKjJ4IPgkq/Pkyjz0nQYAWhcyuXapuyAq9iaAPxJYu4dh1D6zq cb2g== X-Gm-Message-State: AD7BkJKAtn1FrVnNc21r67UPhFiKhg5fTz3R3Z1d5Jy87mHUXk3vOgs8vIpR+I+PpWqFEIAOJMe6x1tXF4UbNk9d MIME-Version: 1.0 X-Received: by 10.13.208.198 with SMTP id s189mr14410190ywd.130.1457963089133; Mon, 14 Mar 2016 06:44:49 -0700 (PDT) Received: by 10.37.48.6 with HTTP; Mon, 14 Mar 2016 06:44:49 -0700 (PDT) In-Reply-To: <56D49ADB.1000708@bbn.com> References: <057.35eb1e87b6861f551e4f028e2b93c3f4@tools.ietf.org> <072.7f4522d84e6f746100b591d7f670bc35@tools.ietf.org> <5672E115.1010701@bbn.com> <568D7AC3.2000301@bbn.com> <56D49ADB.1000708@bbn.com> Date: Mon, 14 Mar 2016 13:44:49 +0000 Message-ID: From: Eran Messeri To: Stephen Kent Content-Type: multipart/alternative; boundary=001a114d76f4066c9d052e027c69 Archived-At: Cc: Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] [trans] #93 (rfc6962-bis): Monitor description: Inconsistency between intro and section 5.4 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 13:44:58 -0000 --001a114d76f4066c9d052e027c69 Content-Type: text/plain; charset=UTF-8 Looking at the change history it seems some of your suggested text was adopted into section 9.4: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-12#section-9.4 Auditing is now described as a separate function, independent of a Monitor. Algorithms used to verify consistency of STHs and inclusion of certificates are also clearly laid-out. On Mon, Feb 29, 2016 at 7:24 PM, Stephen Kent wrote: > Eran, > > I would like to see auditing described as a separate function, independent > of a Monitor. > My recollection (after being on vacation for 3 weeks) was that this > distinction was > OK in the intro, then muddled in the discussion of the Monitor, which was > described in > a way that made it an auditor. I provided text to try to fix this. I'm not > sure if you > are saying that the text I provided does not address the problem, or that > you and your > co-authors have rejected that text and are unable to generate alternative > text to address > the concern I cited. > > Steve > > > Risking resurrection of an old thread, I'll point out that when addressing > ticket 141 > > more text was added about auditing, which should clarify what a monitor can > do if it's interested in auditing. > Ticket 118 seems to > repeat the concern originally raised in ticket 93, but we couldn't come up > with text that would be meaningful and address the concern raised in that > ticket. > > On Wed, Jan 6, 2016 at 8:36 PM, Stephen Kent wrote: > >> Paul, >> >> On Thu, 17 Dec 2015, Stephen Kent wrote: >>> >>> I also agree that the architecture document provides a more in-depth >>>> description of the Monitor function, but it is also at odds with the >>>> description in the -11 draft. So, I disagree with the proposal to >>>> leave the current text in place. >>>> >>> >>> Then please provide improved text (not scaffolding) for the bis document. >>> >>> Paul >>> >> I have done so, via the issue tracker. >> >> Steve >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > > --001a114d76f4066c9d052e027c69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looking at the change history it seems some of your sugges= ted text was adopted into section 9.4:

Auditing is now described as a separate function, independent of a M= onitor.
Algorithms used to verify consistency of STHs and inclusi= on of certificates are also clearly laid-out.

On Mon, Feb 29, 2016 at 7:24 PM, St= ephen Kent <kent@bbn.com> wrote:
Eran,

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

Steve


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

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

On Thu, 17 Dec 2015, Stephen Kent wrote:

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

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

Paul
 I have done so, via the issue tracker.

Steve


_______________________________________________
Trans mailing list
Trans@i= etf.org
https://www.ietf.org/mailman/listinfo/tra= ns



--001a114d76f4066c9d052e027c69-- From nobody Mon Mar 14 07:43:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C3812DB2F for ; Mon, 14 Mar 2016 07:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcKWGQlx1Ad5 for ; Mon, 14 Mar 2016 07:43:10 -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 A02C012DB46 for ; Mon, 14 Mar 2016 07:39:46 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:43541 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1afTer-000GoH-8W for trans@ietf.org; Mon, 14 Mar 2016 10:39:45 -0400 To: "trans@ietf.org" From: Stephen Kent Message-ID: <56E6CD30.8070102@bbn.com> Date: Mon, 14 Mar 2016 10:39:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000108090703020103050100" Archived-At: Subject: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 14:43:17 -0000 This is a multi-part message in MIME format. --------------000108090703020103050100 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Below is the text I plan to insert as a new section in the threat analysis doc, to address the attack DKG articulated. Comments welcome. Steve ------ 3.3 Malicious, Colluding CAs Section 3.2 examined attacks in which a single CA issued a bogus certificate. Daniel Kahn Gilmor posited an attack in which two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the safeguards envisioned by CT. Specifically, he suggested that two trust anchors could create intermediate (subordinate) CAs that have the same Subject name, the same public key, and the same Subject Key Identifier) in the their certificates.In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not name-constrained; the attack need not be initiated by trust anchors per se. (Also note that X.509 and RFC 5280 do not preclude creation of doppelganger CAs; the requirement for Subject name uniqueness applies individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.) The attack requires that both of the doppelganger CAs issue a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs a bogus certificate and acquires an SCT for it. Because the bogus certificates are identical, the SCT will match both. The logged bogus certificate can be detected by a Monitor (third party or self), that is watching the log(s) to which the certificate was posted. Thus the detection aspect of CT still works with regard to this certificate. When this certificate is detected, the CA that logged the certificate may revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response will not match this revocationstatus data against the other, not-logged bogus certificate. (This is because revocation status checking is performed in the context of a certificate path and the two bogus certificates have different certificate paths.) Revoking a detected, bogus certificatemay be the best strategy for the malicious CAs. It makes issuance of the bogus certificate appear to be an accident, and thus browser vendors may not feel the need to make an entry on their blacklists for the bogus certificate or the CA that issued it. If the CA that issued the (logged) bogus certificate fails to revoke it, browser vendors might blacklist the certificate. However, as noted above, the other bogus certificate, which was not logged, still will match the SCT created for the logged (now revoked) certificate. If remediation is effected by blacklisting (instead of revocation by the malicious CA) then the ability of CT to deal with this sort of attack may be diminished. Some forms of blacklisting will cause the not-logged bogus certificate to be detected and rejected, while others will not, depending on the details of the blacklisting mechanism. Mechanisms for blacklisting by browsers are not specified in any IETF standards. The mechanisms are browser-specific, and the choice of how to blacklist (e.g., the bogus certificate vs. the CA that issued it) are the purview of each browser vendor. Thus, depending on the details of the blacklist mechanism and the way that a browser vendor chooses to manage this list, a doppelganger CA attack might or might not pose a problem in terms of successful remediation of the attack. --------------000108090703020103050100 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Below is the text I plan to insert as a new section in the threat analysis doc,
to address the attack DKG articulated. Comments welcome.

Steve
------

3.3 Malicious, Colluding CAs

 

Section 3.2 examined attacks in which a single CA issued a bogus certificate. Daniel Kahn Gilmor posited an attack in which two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the safeguards envisioned by CT. Specifically, he suggested that two trust anchors could create intermediate (subordinate) CAs that have the same Subject name, the same public key, and the same Subject Key Identifier) in the their certificates. In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not name-constrained; the attack need not be initiated by trust anchors per se. (Also note that X.509 and RFC 5280 do not preclude creation of doppelganger CAs; the requirement for Subject name uniqueness applies individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.)

 

The attack requires that both of the doppelganger CAs issue a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs a bogus certificate and acquires an SCT for it. Because the bogus certificates are identical, the SCT will match both.

 

The logged bogus certificate can be detected by a Monitor (third party or self), that is watching the log(s) to which the certificate was posted. Thus the detection aspect of CT still works with regard to this certificate. When this certificate is detected, the CA that logged the certificate may revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response will not match this revocation  status data against the other, not-logged bogus certificate. (This is because revocation status checking is performed in the context of a certificate path and the two bogus certificates have different certificate paths.) Revoking a detected, bogus certificate  may be the best strategy for the malicious CAs. It makes issuance of the bogus certificate appear to be an accident, and thus browser vendors may not feel the need to make an entry on their blacklists for the bogus certificate or the CA that issued it.

 

If the CA that issued the (logged) bogus certificate fails to revoke it, browser vendors might blacklist the certificate. However, as noted above, the other bogus certificate, which was not logged, still will match the SCT created for the logged (now revoked) certificate. If remediation is effected by blacklisting (instead of revocation by the malicious CA) then the ability of CT to deal with this sort of attack may be diminished. Some forms of blacklisting will cause the not-logged bogus certificate to be detected and rejected, while others will not, depending on the details of the blacklisting mechanism. Mechanisms for blacklisting by browsers are not specified in any IETF standards. The mechanisms are browser-specific, and the choice of how to blacklist (e.g., the bogus certificate vs. the CA that issued it) are the purview of each browser vendor. Thus, depending on the details of the blacklist mechanism and the way that a browser vendor chooses to manage this list, a doppelganger CA attack might or might not pose a problem in terms of successful remediation of the attack.


--------------000108090703020103050100-- From nobody Mon Mar 14 13:18:54 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ED212D5AC for ; Mon, 14 Mar 2016 13:18:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSeI86pHZ-Fe for ; Mon, 14 Mar 2016 13:18:43 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDC412D54D for ; Mon, 14 Mar 2016 13:18:42 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 749AC3F4012; Mon, 14 Mar 2016 20:18:41 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5C7993F4006; Mon, 14 Mar 2016 20:18:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457986721; bh=bZtcFbDNTwFtGREQBb4NgfPtRu77OFxWD0e2LLVp3pg=; l=17002; h=From:To:Date:References:In-Reply-To:From; b=frDfGpkX7hvNg9Gv2El+3rSF6ul/4r9KFaegYu/6T54MOzLrYrcta/oTKzPfblfhM ovvMzAtyU74o7YAfa5A0QKp1uIg2zBgfWUyzg8uZfpCqso+8OyCOCj8Ymo9N011EgO Vwl5KkcqgR+uIGGDHtBVNxQJiQAMLQHLnknSp5TI= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 57C8A1FC88; Mon, 14 Mar 2016 20:18:41 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 14 Mar 2016 13:18:40 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 14 Mar 2016 16:18:40 -0400 From: "Salz, Rich" To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] text to address DKG's conspiring CAs attack Thread-Index: AQHRff/crGaMUoFfSkalLfdFo0PVGZ9ZYUGg Date: Mon, 14 Mar 2016 20:18:39 +0000 Message-ID: References: <56E6CD30.8070102@bbn.com> In-Reply-To: <56E6CD30.8070102@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.40.105] Content-Type: multipart/alternative; boundary="_000_fb890e6225a14803bababf82e05e017busma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 20:18:52 -0000 --_000_fb890e6225a14803bababf82e05e017busma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZC4gICBDbGV2ZXIgYXR0YWNrOyBka2cgaGFzIGEgdHdpc3RlZCBtaW5kIOKYug0K DQpEbyB3ZSBnZW5lcmFsbHkgY3JlZGl0IGluZGl2aWR1YWxzIGluIGRvY3M/DQoNCi0tDQpTZW5p b3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpJTTogcmljaHNhbHpAamFiYmVyLmF0 IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCkZyb206IFN0ZXBoZW4gS2VudCBbbWFpbHRvOmtlbnRAYmJu LmNvbV0NClNlbnQ6IE1vbmRheSwgTWFyY2ggMTQsIDIwMTYgMTA6NDAgQU0NClRvOiB0cmFuc0Bp ZXRmLm9yZw0KU3ViamVjdDogW1RyYW5zXSB0ZXh0IHRvIGFkZHJlc3MgREtHJ3MgY29uc3Bpcmlu ZyBDQXMgYXR0YWNrDQoNCkJlbG93IGlzIHRoZSB0ZXh0IEkgcGxhbiB0byBpbnNlcnQgYXMgYSBu ZXcgc2VjdGlvbiBpbiB0aGUgdGhyZWF0IGFuYWx5c2lzIGRvYywNCnRvIGFkZHJlc3MgdGhlIGF0 dGFjayBES0cgYXJ0aWN1bGF0ZWQuIENvbW1lbnRzIHdlbGNvbWUuDQoNClN0ZXZlDQotLS0tLS0N Cg0KDQoNCjMuMyBNYWxpY2lvdXMsIENvbGx1ZGluZyBDQXMNCg0KDQoNClNlY3Rpb24gMy4yIGV4 YW1pbmVkIGF0dGFja3MgaW4gd2hpY2ggYSBzaW5nbGUgQ0EgaXNzdWVkIGEgYm9ndXMgY2VydGlm aWNhdGUuIERhbmllbCBLYWhuIEdpbG1vciBwb3NpdGVkIGFuIGF0dGFjayBpbiB3aGljaCB0d28g b3IgbW9yZSBDQXMgbWlnaHQgY29sbHVkZSB0byBpc3N1ZSBhIGJvZ3VzIGNlcnRpZmljYXRlIGlu IGEgZmFzaGlvbiBkZXNpZ25lZCB0byBmb2lsIHRoZSBzYWZlZ3VhcmRzIGVudmlzaW9uZWQgYnkg Q1QuIFNwZWNpZmljYWxseSwgaGUgc3VnZ2VzdGVkIHRoYXQgdHdvIHRydXN0IGFuY2hvcnMgY291 bGQgY3JlYXRlIGludGVybWVkaWF0ZSAoc3Vib3JkaW5hdGUpIENBcyB0aGF0IGhhdmUgdGhlIHNh bWUgU3ViamVjdCBuYW1lLCB0aGUgc2FtZSBwdWJsaWMga2V5LCBhbmQgdGhlIHNhbWUgU3ViamVj dCBLZXkgSWRlbnRpZmllcikgaW4gdGhlIHRoZWlyIGNlcnRpZmljYXRlcy4gSW4gZmFjdCwgYW4g YXR0YWNrIG9mIHRoZSBzb3J0IEdpbG1vciBlbnZpc2lvbmVkIGNhbiBiZSBtb3VudGVkIGJ5IGFu eSB0d28gQ0FzIHRoYXQgYXJlIG5vdCBuYW1lLWNvbnN0cmFpbmVkOyB0aGUgYXR0YWNrIG5lZWQg bm90IGJlIGluaXRpYXRlZCBieSB0cnVzdCBhbmNob3JzIHBlciBzZS4gKEFsc28gbm90ZSB0aGF0 IFguNTA5IGFuZCBSRkMgNTI4MCBkbyBub3QgcHJlY2x1ZGUgY3JlYXRpb24gb2YgZG9wcGVsZ2Fu Z2VyIENBczsgdGhlIHJlcXVpcmVtZW50IGZvciBTdWJqZWN0IG5hbWUgdW5pcXVlbmVzcyBhcHBs aWVzIGluZGl2aWR1YWxseSB0byBlYWNoIENBIGJ1dCBub3QgYWNyb3NzIENBIGJvdW5kYXJpZXMs IGFuZCB0aGVyZSBpcyBubyByZXF1aXJlbWVudCBmb3IgcHVibGljIGtleSB1bmlxdWVuZXNzIGFj cm9zcyBDQXMuKQ0KDQoNCg0KVGhlIGF0dGFjayByZXF1aXJlcyB0aGF0IGJvdGggb2YgdGhlIGRv cHBlbGdhbmdlciBDQXMgaXNzdWUgYSBjZXJ0aWZpY2F0ZSBmb3IgYSB0YXJnZXRlZCBTdWJqZWN0 IChlLmcuLCB3ZWIgc2l0ZSkuIFRoZXNlIHR3byAoRUUpIGNlcnRpZmljYXRlcyBhcmUgaWRlbnRp Y2FsOyB0aGV5IGNvbnRhaW4gdGhlIHNhbWUgbmFtZSwgcHVibGljIGtleSwgc2VyaWFsIG51bWJl ciwgZXRjLiBPbmx5IG9uZSBvZiB0aGUgbWFsaWNpb3VzIENBcyBsb2dzIGEgYm9ndXMgY2VydGlm aWNhdGUgYW5kIGFjcXVpcmVzIGFuIFNDVCBmb3IgaXQuIEJlY2F1c2UgdGhlIGJvZ3VzIGNlcnRp ZmljYXRlcyBhcmUgaWRlbnRpY2FsLCB0aGUgU0NUIHdpbGwgbWF0Y2ggYm90aC4NCg0KDQoNClRo ZSBsb2dnZWQgYm9ndXMgY2VydGlmaWNhdGUgY2FuIGJlIGRldGVjdGVkIGJ5IGEgTW9uaXRvciAo dGhpcmQgcGFydHkgb3Igc2VsZiksIHRoYXQgaXMgd2F0Y2hpbmcgdGhlIGxvZyhzKSB0byB3aGlj aCB0aGUgY2VydGlmaWNhdGUgd2FzIHBvc3RlZC4gVGh1cyB0aGUgZGV0ZWN0aW9uIGFzcGVjdCBv ZiBDVCBzdGlsbCB3b3JrcyB3aXRoIHJlZ2FyZCB0byB0aGlzIGNlcnRpZmljYXRlLiBXaGVuIHRo aXMgY2VydGlmaWNhdGUgaXMgZGV0ZWN0ZWQsIHRoZSBDQSB0aGF0IGxvZ2dlZCB0aGUgY2VydGlm aWNhdGUgbWF5IHJldm9rZSBpdCwgaS5lLiwgcGxhY2UgaXQgb24gYSBDUkwgb3IgY3JlYXRlIGFu IE9DU1AgcmVzcG9uc2UgZm9yIGl0LiBIb3dldmVyLCBhIGJyb3dzZXIgY2hlY2tpbmcgYSBDUkwg b3IgT0NTUCByZXNwb25zZSB3aWxsIG5vdCBtYXRjaCB0aGlzIHJldm9jYXRpb24gIHN0YXR1cyBk YXRhIGFnYWluc3QgdGhlIG90aGVyLCBub3QtbG9nZ2VkIGJvZ3VzIGNlcnRpZmljYXRlLiAoVGhp cyBpcyBiZWNhdXNlIHJldm9jYXRpb24gc3RhdHVzIGNoZWNraW5nIGlzIHBlcmZvcm1lZCBpbiB0 aGUgY29udGV4dCBvZiBhIGNlcnRpZmljYXRlIHBhdGggYW5kIHRoZSB0d28gYm9ndXMgY2VydGlm aWNhdGVzIGhhdmUgZGlmZmVyZW50IGNlcnRpZmljYXRlIHBhdGhzLikgUmV2b2tpbmcgYSBkZXRl Y3RlZCwgYm9ndXMgY2VydGlmaWNhdGUgIG1heSBiZSB0aGUgYmVzdCBzdHJhdGVneSBmb3IgdGhl IG1hbGljaW91cyBDQXMuIEl0IG1ha2VzIGlzc3VhbmNlIG9mIHRoZSBib2d1cyBjZXJ0aWZpY2F0 ZSBhcHBlYXIgdG8gYmUgYW4gYWNjaWRlbnQsIGFuZCB0aHVzIGJyb3dzZXIgdmVuZG9ycyBtYXkg bm90IGZlZWwgdGhlIG5lZWQgdG8gbWFrZSBhbiBlbnRyeSBvbiB0aGVpciBibGFja2xpc3RzIGZv ciB0aGUgYm9ndXMgY2VydGlmaWNhdGUgb3IgdGhlIENBIHRoYXQgaXNzdWVkIGl0Lg0KDQoNCg0K SWYgdGhlIENBIHRoYXQgaXNzdWVkIHRoZSAobG9nZ2VkKSBib2d1cyBjZXJ0aWZpY2F0ZSBmYWls cyB0byByZXZva2UgaXQsIGJyb3dzZXIgdmVuZG9ycyBtaWdodCBibGFja2xpc3QgdGhlIGNlcnRp ZmljYXRlLiBIb3dldmVyLCBhcyBub3RlZCBhYm92ZSwgdGhlIG90aGVyIGJvZ3VzIGNlcnRpZmlj YXRlLCB3aGljaCB3YXMgbm90IGxvZ2dlZCwgc3RpbGwgd2lsbCBtYXRjaCB0aGUgU0NUIGNyZWF0 ZWQgZm9yIHRoZSBsb2dnZWQgKG5vdyByZXZva2VkKSBjZXJ0aWZpY2F0ZS4gSWYgcmVtZWRpYXRp b24gaXMgZWZmZWN0ZWQgYnkgYmxhY2tsaXN0aW5nIChpbnN0ZWFkIG9mIHJldm9jYXRpb24gYnkg dGhlIG1hbGljaW91cyBDQSkgdGhlbiB0aGUgYWJpbGl0eSBvZiBDVCB0byBkZWFsIHdpdGggdGhp cyBzb3J0IG9mIGF0dGFjayBtYXkgYmUgZGltaW5pc2hlZC4gU29tZSBmb3JtcyBvZiBibGFja2xp c3Rpbmcgd2lsbCBjYXVzZSB0aGUgbm90LWxvZ2dlZCBib2d1cyBjZXJ0aWZpY2F0ZSB0byBiZSBk ZXRlY3RlZCBhbmQgcmVqZWN0ZWQsIHdoaWxlIG90aGVycyB3aWxsIG5vdCwgZGVwZW5kaW5nIG9u IHRoZSBkZXRhaWxzIG9mIHRoZSBibGFja2xpc3RpbmcgbWVjaGFuaXNtLiBNZWNoYW5pc21zIGZv ciBibGFja2xpc3RpbmcgYnkgYnJvd3NlcnMgYXJlIG5vdCBzcGVjaWZpZWQgaW4gYW55IElFVEYg c3RhbmRhcmRzLiBUaGUgbWVjaGFuaXNtcyBhcmUgYnJvd3Nlci1zcGVjaWZpYywgYW5kIHRoZSBj aG9pY2Ugb2YgaG93IHRvIGJsYWNrbGlzdCAoZS5nLiwgdGhlIGJvZ3VzIGNlcnRpZmljYXRlIHZz LiB0aGUgQ0EgdGhhdCBpc3N1ZWQgaXQpIGFyZSB0aGUgcHVydmlldyBvZiBlYWNoIGJyb3dzZXIg dmVuZG9yLiBUaHVzLCBkZXBlbmRpbmcgb24gdGhlIGRldGFpbHMgb2YgdGhlIGJsYWNrbGlzdCBt ZWNoYW5pc20gYW5kIHRoZSB3YXkgdGhhdCBhIGJyb3dzZXIgdmVuZG9yIGNob29zZXMgdG8gbWFu YWdlIHRoaXMgbGlzdCwgYSBkb3BwZWxnYW5nZXIgQ0EgYXR0YWNrIG1pZ2h0IG9yIG1pZ2h0IG5v dCBwb3NlIGEgcHJvYmxlbSBpbiB0ZXJtcyBvZiBzdWNjZXNzZnVsIHJlbWVkaWF0aW9uIG9mIHRo ZSBhdHRhY2suDQoNCg== --_000_fb890e6225a14803bababf82e05e017busma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkpBO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6Q291cmllcjsNCgljb2xvcjpibGFjazsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpKQTt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IjsNCglmb250LWZhbWlseTpDb3VyaWVyO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkxvb2tzIGdvb2QuJm5ic3A7 Jm5ic3A7IENsZXZlciBhdHRhY2s7IGRrZyBoYXMgYSB0d2lzdGVkIG1pbmQNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFG NDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj5EbyB3ZSBnZW5lcmFsbHkgY3JlZGl0IGluZGl2aWR1YWxzIGluIGRv Y3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tJm5i c3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5TZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SU06IHJpY2hz YWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+DQogU3RlcGhlbiBLZW50IFttYWlsdG86a2VudEBiYm4uY29tXSA8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBNYXJjaCAxNCwgMjAxNiAxMDo0MCBBTTxicj4NCjxiPlRvOjwvYj4gdHJhbnNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RyYW5zXSB0ZXh0IHRvIGFkZHJlc3MgREtH J3MgY29uc3BpcmluZyBDQXMgYXR0YWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QmVsb3cgaXMgdGhlIHRleHQgSSBwbGFuIHRvIGluc2VydCBhcyBhIG5l dyBzZWN0aW9uIGluIHRoZSB0aHJlYXQgYW5hbHlzaXMgZG9jLDxicj4NCnRvIGFkZHJlc3MgdGhl IGF0dGFjayBES0cgYXJ0aWN1bGF0ZWQuIENvbW1lbnRzIHdlbGNvbWUuPGJyPg0KPGJyPg0KU3Rl dmU8YnI+DQotLS0tLS08YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjMuMyBNYWxpY2lvdXMsIENvbGx1ZGluZyBDQXM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiAzLjIgZXhhbWluZWQgYXR0YWNrcyBpbiB3aGljaCBh IHNpbmdsZSBDQSBpc3N1ZWQgYSBib2d1cyBjZXJ0aWZpY2F0ZS4gRGFuaWVsIEthaG4gR2lsbW9y IHBvc2l0ZWQgYW4gYXR0YWNrIGluIHdoaWNoIHR3byBvciBtb3JlIENBcyBtaWdodCBjb2xsdWRl IHRvIGlzc3VlIGEgYm9ndXMgY2VydGlmaWNhdGUgaW4gYSBmYXNoaW9uIGRlc2lnbmVkIHRvIGZv aWwgdGhlIHNhZmVndWFyZHMgZW52aXNpb25lZA0KIGJ5IENULiBTcGVjaWZpY2FsbHksIGhlIHN1 Z2dlc3RlZCB0aGF0IHR3byB0cnVzdCBhbmNob3JzIGNvdWxkIGNyZWF0ZSBpbnRlcm1lZGlhdGUg KHN1Ym9yZGluYXRlKSBDQXMgdGhhdCBoYXZlIHRoZSBzYW1lIFN1YmplY3QgbmFtZSwgdGhlIHNh bWUgcHVibGljIGtleSwgYW5kIHRoZSBzYW1lIFN1YmplY3QgS2V5IElkZW50aWZpZXIpIGluIHRo ZSB0aGVpciBjZXJ0aWZpY2F0ZXMuIEluIGZhY3QsIGFuIGF0dGFjayBvZiB0aGUgc29ydCBHaWxt b3INCiBlbnZpc2lvbmVkIGNhbiBiZSBtb3VudGVkIGJ5IGFueSB0d28gQ0FzIHRoYXQgYXJlIG5v dCBuYW1lLWNvbnN0cmFpbmVkOyB0aGUgYXR0YWNrIG5lZWQgbm90IGJlIGluaXRpYXRlZCBieSB0 cnVzdCBhbmNob3JzIHBlciBzZS4gKEFsc28gbm90ZSB0aGF0IFguNTA5IGFuZCBSRkMgNTI4MCBk byBub3QgcHJlY2x1ZGUgY3JlYXRpb24gb2YgZG9wcGVsZ2FuZ2VyIENBczsgdGhlIHJlcXVpcmVt ZW50IGZvciBTdWJqZWN0IG5hbWUgdW5pcXVlbmVzcyBhcHBsaWVzDQogaW5kaXZpZHVhbGx5IHRv IGVhY2ggQ0EgYnV0IG5vdCBhY3Jvc3MgQ0EgYm91bmRhcmllcywgYW5kIHRoZXJlIGlzIG5vIHJl cXVpcmVtZW50IGZvciBwdWJsaWMga2V5IHVuaXF1ZW5lc3MgYWNyb3NzIENBcy4pDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGF0dGFjayByZXF1aXJlcyB0aGF0IGJvdGggb2Yg dGhlIGRvcHBlbGdhbmdlciBDQXMgaXNzdWUgYSBjZXJ0aWZpY2F0ZSBmb3IgYSB0YXJnZXRlZCBT dWJqZWN0IChlLmcuLCB3ZWIgc2l0ZSkuIFRoZXNlIHR3byAoRUUpIGNlcnRpZmljYXRlcyBhcmUg aWRlbnRpY2FsOyB0aGV5IGNvbnRhaW4gdGhlIHNhbWUgbmFtZSwgcHVibGljIGtleSwgc2VyaWFs IG51bWJlciwgZXRjLiBPbmx5IG9uZSBvZiB0aGUNCiBtYWxpY2lvdXMgQ0FzIGxvZ3MgYSBib2d1 cyBjZXJ0aWZpY2F0ZSBhbmQgYWNxdWlyZXMgYW4gU0NUIGZvciBpdC4gQmVjYXVzZSB0aGUgYm9n dXMgY2VydGlmaWNhdGVzIGFyZSBpZGVudGljYWwsIHRoZSBTQ1Qgd2lsbCBtYXRjaCBib3RoLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgbG9nZ2VkIGJvZ3VzIGNlcnRpZmljYXRl IGNhbiBiZSBkZXRlY3RlZCBieSBhIE1vbml0b3IgKHRoaXJkIHBhcnR5IG9yIHNlbGYpLCB0aGF0 IGlzIHdhdGNoaW5nIHRoZSBsb2cocykgdG8gd2hpY2ggdGhlIGNlcnRpZmljYXRlIHdhcyBwb3N0 ZWQuIFRodXMgdGhlIGRldGVjdGlvbiBhc3BlY3Qgb2YgQ1Qgc3RpbGwgd29ya3Mgd2l0aCByZWdh cmQgdG8gdGhpcyBjZXJ0aWZpY2F0ZS4gV2hlbiB0aGlzDQogY2VydGlmaWNhdGUgaXMgZGV0ZWN0 ZWQsIHRoZSBDQSB0aGF0IGxvZ2dlZCB0aGUgY2VydGlmaWNhdGUgbWF5IHJldm9rZSBpdCwgaS5l LiwgcGxhY2UgaXQgb24gYSBDUkwgb3IgY3JlYXRlIGFuIE9DU1AgcmVzcG9uc2UgZm9yIGl0LiBI b3dldmVyLCBhIGJyb3dzZXIgY2hlY2tpbmcgYSBDUkwgb3IgT0NTUCByZXNwb25zZSB3aWxsIG5v dCBtYXRjaCB0aGlzIHJldm9jYXRpb24mbmJzcDsgc3RhdHVzIGRhdGEgYWdhaW5zdCB0aGUgb3Ro ZXIsIG5vdC1sb2dnZWQNCiBib2d1cyBjZXJ0aWZpY2F0ZS4gKFRoaXMgaXMgYmVjYXVzZSByZXZv Y2F0aW9uIHN0YXR1cyBjaGVja2luZyBpcyBwZXJmb3JtZWQgaW4gdGhlIGNvbnRleHQgb2YgYSBj ZXJ0aWZpY2F0ZSBwYXRoIGFuZCB0aGUgdHdvIGJvZ3VzIGNlcnRpZmljYXRlcyBoYXZlIGRpZmZl cmVudCBjZXJ0aWZpY2F0ZSBwYXRocy4pIFJldm9raW5nIGEgZGV0ZWN0ZWQsIGJvZ3VzIGNlcnRp ZmljYXRlJm5ic3A7IG1heSBiZSB0aGUgYmVzdCBzdHJhdGVneSBmb3IgdGhlIG1hbGljaW91cw0K IENBcy4gSXQgbWFrZXMgaXNzdWFuY2Ugb2YgdGhlIGJvZ3VzIGNlcnRpZmljYXRlIGFwcGVhciB0 byBiZSBhbiBhY2NpZGVudCwgYW5kIHRodXMgYnJvd3NlciB2ZW5kb3JzIG1heSBub3QgZmVlbCB0 aGUgbmVlZCB0byBtYWtlIGFuIGVudHJ5IG9uIHRoZWlyIGJsYWNrbGlzdHMgZm9yIHRoZSBib2d1 cyBjZXJ0aWZpY2F0ZSBvciB0aGUgQ0EgdGhhdCBpc3N1ZWQgaXQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPklmIHRoZSBDQSB0aGF0IGlzc3VlZCB0aGUgKGxvZ2dlZCkgYm9ndXMgY2Vy dGlmaWNhdGUgZmFpbHMgdG8gcmV2b2tlIGl0LCBicm93c2VyIHZlbmRvcnMgbWlnaHQgYmxhY2ts aXN0IHRoZSBjZXJ0aWZpY2F0ZS4gSG93ZXZlciwgYXMgbm90ZWQgYWJvdmUsIHRoZSBvdGhlciBi b2d1cyBjZXJ0aWZpY2F0ZSwgd2hpY2ggd2FzIG5vdCBsb2dnZWQsIHN0aWxsIHdpbGwgbWF0Y2gg dGhlIFNDVCBjcmVhdGVkIGZvcg0KIHRoZSBsb2dnZWQgKG5vdyByZXZva2VkKSBjZXJ0aWZpY2F0 ZS4gSWYgcmVtZWRpYXRpb24gaXMgZWZmZWN0ZWQgYnkgYmxhY2tsaXN0aW5nIChpbnN0ZWFkIG9m IHJldm9jYXRpb24gYnkgdGhlIG1hbGljaW91cyBDQSkgdGhlbiB0aGUgYWJpbGl0eSBvZiBDVCB0 byBkZWFsIHdpdGggdGhpcyBzb3J0IG9mIGF0dGFjayBtYXkgYmUgZGltaW5pc2hlZC4gU29tZSBm b3JtcyBvZiBibGFja2xpc3Rpbmcgd2lsbCBjYXVzZSB0aGUgbm90LWxvZ2dlZCBib2d1cw0KIGNl cnRpZmljYXRlIHRvIGJlIGRldGVjdGVkIGFuZCByZWplY3RlZCwgd2hpbGUgb3RoZXJzIHdpbGwg bm90LCBkZXBlbmRpbmcgb24gdGhlIGRldGFpbHMgb2YgdGhlIGJsYWNrbGlzdGluZyBtZWNoYW5p c20uIE1lY2hhbmlzbXMgZm9yIGJsYWNrbGlzdGluZyBieSBicm93c2VycyBhcmUgbm90IHNwZWNp ZmllZCBpbiBhbnkgSUVURiBzdGFuZGFyZHMuIFRoZSBtZWNoYW5pc21zIGFyZSBicm93c2VyLXNw ZWNpZmljLCBhbmQgdGhlIGNob2ljZSBvZg0KIGhvdyB0byBibGFja2xpc3QgKGUuZy4sIHRoZSBi b2d1cyBjZXJ0aWZpY2F0ZSB2cy4gdGhlIENBIHRoYXQgaXNzdWVkIGl0KSBhcmUgdGhlIHB1cnZp ZXcgb2YgZWFjaCBicm93c2VyIHZlbmRvci4gVGh1cywgZGVwZW5kaW5nIG9uIHRoZSBkZXRhaWxz IG9mIHRoZSBibGFja2xpc3QgbWVjaGFuaXNtIGFuZCB0aGUgd2F5IHRoYXQgYSBicm93c2VyIHZl bmRvciBjaG9vc2VzIHRvIG1hbmFnZSB0aGlzIGxpc3QsIGEgZG9wcGVsZ2FuZ2VyIENBIGF0dGFj aw0KIG1pZ2h0IG9yIG1pZ2h0IG5vdCBwb3NlIGEgcHJvYmxlbSBpbiB0ZXJtcyBvZiBzdWNjZXNz ZnVsIHJlbWVkaWF0aW9uIG9mIHRoZSBhdHRhY2suPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_fb890e6225a14803bababf82e05e017busma1exdag1mb1msgcorpak_-- From nobody Mon Mar 14 13:22:17 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909DF12D689 for ; Mon, 14 Mar 2016 13:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMfsakEavGyB for ; Mon, 14 Mar 2016 13:22:14 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE66612D62E for ; Mon, 14 Mar 2016 13:22:13 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id n5so104955098pfn.2 for ; Mon, 14 Mar 2016 13:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=RDjXpnzw6P7m7xfNrH8KljlzlPit+4y7Plcj6Tk2lyY=; b=EO68L5fcdQ00K2YOhbDYGHAUqtouxHWFfYf9fsZbGlGW6CFFcGo6gR1DyV71UXPM+a jzy0+qiJSqTesbkzWx3vq7F7j5y8cuO0a8XM+/L0jStaT41HvkfCqyu7inRUW39sx93n ObK+LogxuI7EC5kf+34MSD6rJMS+dDr7rLlMbXgcE7gySoEQ5EjipJQgGgh0MR8RrA37 Qa3ShfGdRYhxx+KbgpMKPta6lBM5Jo4T+Wd5YtoMSwHoFSP0mfhZjOSslhRffo2hxRUk 3tGdK/jeMXgQWoxVeU4qBX73ccf3n6EaNaEkBt3PHYJGtkk16qz7xL7eCjUrvxmklvkg w1qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RDjXpnzw6P7m7xfNrH8KljlzlPit+4y7Plcj6Tk2lyY=; b=BbHP/0GdrkrkteqeDCWv1CJ8l1hmo3hSN94RZNad90Wj4u92OlKc86MXvBWCal3GAr yuir/XqOjztafIdmUHfh5bbVadSuwk2JnZrlHQQ+GfJw1sIUQOR16Q23BBVNKseebNBh H5NB+C/mRzK0/S/LhqsZFBD6uh6toM3r/8MekXJhIfEJp+sb1vacnpVGJlkUh/xRxpRo fRdv/Q2dz2vwWiMRUsh7+v+P6nmgpj7CND3B/l27/1uZ3hyEaBylwKlBamWCeVxw0qGQ WZkbhXH2SZ1AfLvZ0hf7Bn2WFP1Fcb3ydmWcsKqCB35SP5Xi0yCii98e5FhwwZCfWDVO qNBw== X-Gm-Message-State: AD7BkJLzYDRsYDebGXG9UoG5R5M5omCUoz3bnNizqk8IHBqD8hmkNwtnjrYjP2d8X40/xA== X-Received: by 10.98.33.74 with SMTP id h71mr32401753pfh.157.1457986933431; Mon, 14 Mar 2016 13:22:13 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-78-163-radius.dynamic.acsalaska.net. [216.67.78.163]) by smtp.googlemail.com with ESMTPSA id v7sm34128731pfi.56.2016.03.14.13.22.12 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 13:22:12 -0700 (PDT) To: trans@ietf.org References: <56E6CD30.8070102@bbn.com> From: Melinda Shore Message-ID: <56E71E2B.1050407@gmail.com> Date: Mon, 14 Mar 2016 12:25:15 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 20:22:15 -0000 On 3/14/16 12:18 PM, Salz, Rich wrote: > Looks good. Clever attack; dkg has a twisted mind J > > Do we generally credit individuals in docs? Yes, there should be an acknowledgments section when appropriate. Melinda From nobody Mon Mar 14 13:25:58 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312B212D5D8 for ; Mon, 14 Mar 2016 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtZ4RhOaly2J for ; Mon, 14 Mar 2016 13:25:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id A652A12D4FF for ; Mon, 14 Mar 2016 13:25:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E83A7433438; Mon, 14 Mar 2016 20:25:54 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CF248433431; Mon, 14 Mar 2016 20:25:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457987154; bh=ZL5NwZpAbI3TD12D8OQUuiQt0GQN25y8GwiqOX3g3OU=; l=264; h=From:To:Date:References:In-Reply-To:From; b=ggZVI04kqvisU9OBQB+/0+RY0+1D3ZRcKPZrqD2Wtstohg5KU9ew8ac9x8jxENF6g KynWwy0J5WE1rRbe7tEfW4pUZBb+nvOQs+7KN+KOxC9ulZ2LMp/MoBIgHKc/rQbS3t QQYaCElcleCoEnrjqDzuIdbJdrt+Q1IoOGtZ5/rA= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id CA79F1FC8E; Mon, 14 Mar 2016 20:25:54 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 14 Mar 2016 13:25:54 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 14 Mar 2016 16:25:54 -0400 From: "Salz, Rich" To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] text to address DKG's conspiring CAs attack Thread-Index: AQHRff/crGaMUoFfSkalLfdFo0PVGZ9ZYUGggABFCYD//7z5YA== Date: Mon, 14 Mar 2016 20:25:53 +0000 Message-ID: <0c7953b1f0b54c57a87a5497bc4eea23@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56E6CD30.8070102@bbn.com> <56E71E2B.1050407@gmail.com> In-Reply-To: <56E71E2B.1050407@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.40.105] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 20:25:57 -0000 > > Do we generally credit individuals in docs? >=20 > Yes, there should be an acknowledgments section when appropriate. Right, of course, and credit him there for this. But in the prose? When s= ay there's no literature to point to? Shrug. Not a big deal. From nobody Mon Mar 14 14:39:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039F812D789 for ; Mon, 14 Mar 2016 14:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuN3oElfJrnw for ; Mon, 14 Mar 2016 14:39:06 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 6C7F412D6C4 for ; Mon, 14 Mar 2016 14:39:06 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id n190so1460606iof.0 for ; Mon, 14 Mar 2016 14:39:06 -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; bh=/aihJ5AcGrgUpFJcB1Tcitmyx1/H41Ql+779nrV7DGY=; b=INkrMke0kGushSutEq23975VnOEoF7VusW032wRTHJ15Z5yCMeA4hEO+Xpi7XGQ7gK eFIW9cU+0Wg+hEDlxzdjBI1UJMJXbPc4JmLwhBGNhKHJcY8QoUM3pwAfLnwGhzocuUu0 ufM0RE0pLOLMPd6DSnOZeom8uMM9d1Oh012u2+PoiS7Zrv5pkwPLCljVK+fjcapWCAac uN9oqf7G9K7ct4ZqBkLZVxzxu2T2ZnQMy5VzpVwCGjPoMVkLr6I/qWEAS7UKdycVcmrz zVxi/6vr/lwJqnSEQ0gthKlThPbRxXlJO+/QnW1go4fqwOfbSVK9RlKl76Ryw/6IkfKV 8MCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/aihJ5AcGrgUpFJcB1Tcitmyx1/H41Ql+779nrV7DGY=; b=NNATlM8FUUNodOiMDK6V+HOIJh4Ha/gRj5EchQ2XTQKmp2y8kVmHdzITEmL7SgG8q5 54oPvkigrb58cydwnArbqNQLBtGtaRIBMAF85OFUlXnnuVv4GBAGn8DGojyU+mG8LqaV Ch+OCzz62Z5DtpwBxVP1DwGBD/YMFykYBPKi6Jg2CWQLg81vvMOH8CJnRwvM6/BQw9w9 5XOLPyDsVdzGhPbPqlChlqQaIa8iT0yGJHyupvwIL7hWa/p7Jwlayda3oiiw9zHeIZkZ lWMIvqWRcPiezqXi0RPbHb1F2Tt1pvTrkCk3dTYlePyPFzJxGUWjtQDF7O0Jx2YkJdA0 bZLw== X-Gm-Message-State: AD7BkJJZ1XqHKKfqyCjpUbKk2AknXZgwDnZTkvEJQZ9wGI6cE8EnhmaNdZ9wczPm/djRy91RO2ocqch96LHZSGJW MIME-Version: 1.0 X-Received: by 10.107.15.148 with SMTP id 20mr30737394iop.119.1457991545694; Mon, 14 Mar 2016 14:39:05 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Mon, 14 Mar 2016 14:39:05 -0700 (PDT) In-Reply-To: <56E6CD30.8070102@bbn.com> References: <56E6CD30.8070102@bbn.com> Date: Mon, 14 Mar 2016 21:39:05 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 21:39:08 -0000 On 14 March 2016 at 14:39, Stephen Kent wrote: > The logged bogus certificate can be detected by a Monitor (third party or > self), that is watching the log(s) to which the certificate was posted. Thus > the detection aspect of CT still works with regard to this certificate. When > this certificate is detected, the CA that logged the certificate may revoke > it, i.e., place it on a CRL or create an OCSP response for it. However, a > browser checking a CRL or OCSP response will not match this revocation > status data against the other, not-logged bogus certificate. (This is > because revocation status checking is performed in the context of a > certificate path and the two bogus certificates have different certificate > paths.) Revoking a detected, bogus certificate may be the best strategy for > the malicious CAs. It makes issuance of the bogus certificate appear to be > an accident, and thus browser vendors may not feel the need to make an entry > on their blacklists for the bogus certificate or the CA that issued it. I do not believe this is correct. And if it is, it is a serious bug in revocation that has nothing to do with certificate transparency. Also, I don't get the logic of the "not-logged bogus certificate", which is identical to the logged certificate - and is therefore logged. And not bogus. From nobody Mon Mar 14 15:15:18 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B157912D55B for ; Mon, 14 Mar 2016 15:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6GIavy_Q0O6 for ; Mon, 14 Mar 2016 15:15:13 -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 DA8F312D6FE for ; Mon, 14 Mar 2016 15:15:12 -0700 (PDT) Received: (qmail 6545 invoked by uid 1004); 14 Mar 2016 22:15:10 -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, 14 Mar 2016 22:15:10 +0000 Received: (qmail 23893 invoked by uid 1000); 14 Mar 2016 22:15:10 -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, 14 Mar 2016 22:15:10 +0000 From: Rob Stradling To: Ben Laurie , Stephen Kent References: <56E6CD30.8070102@bbn.com> Message-ID: <56E737EC.9020203@comodo.com> Date: Mon, 14 Mar 2016 22:15:08 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 22:15:16 -0000 On 14/03/16 21:39, Ben Laurie wrote: > On 14 March 2016 at 14:39, Stephen Kent wrote: >> The logged bogus certificate can be detected by a Monitor (third party or >> self), that is watching the log(s) to which the certificate was posted. Thus >> the detection aspect of CT still works with regard to this certificate. When >> this certificate is detected, the CA that logged the certificate may revoke >> it, i.e., place it on a CRL or create an OCSP response for it. However, a >> browser checking a CRL or OCSP response will not match this revocation >> status data against the other, not-logged bogus certificate. (This is >> because revocation status checking is performed in the context of a >> certificate path and the two bogus certificates have different certificate >> paths.) Revoking a detected, bogus certificate may be the best strategy for >> the malicious CAs. It makes issuance of the bogus certificate appear to be >> an accident, and thus browser vendors may not feel the need to make an entry >> on their blacklists for the bogus certificate or the CA that issued it. > > I do not believe this is correct. And if it is, it is a serious bug in > revocation that has nothing to do with certificate transparency. > > Also, I don't get the logic of the "not-logged bogus certificate", > which is identical to the logged certificate - and is therefore > logged. And not bogus. +1 The "two" bogus certificates are one and the same. They will contain the same CRL and/or OCSP URLs. The outcome of a CRL/OCSP check will be exactly the same for both certs. AIUI, for DKG's attack to work, it is necessary for: - the "two" bogus certificates to _not_ be revoked. - one of the doppelganger intermediates to be logged and revoked. - the other one (or more) of the doppelganger intermediates to be neither logged nor revoked. I think that there are two possible ways to thwart this attack: 1. Redefine SCTs so that they become SCCTs (Signed Certificate Chain Timestamps) - i.e. the signature is calculated over the entire chain submitted. I think this is unworkable, because there are too many cases where different chains are legitimate and even expected. 2. Declare that this is not a problem with CT. It's a problem with using CRL and/or OCSP to revoke intermediates. So we (where "we" may or may not be TRANS) need to fix revocation! Revoking an intermediate _certificate_ just isn't sufficient. To be effective, the intermediate _public key_ needs to be revoked somehow. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Mar 15 05:10:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8014E12D9C6 for ; Tue, 15 Mar 2016 05:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHGuv_66bCIV for ; Tue, 15 Mar 2016 05:10:05 -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 DD9BC12D9B9 for ; Tue, 15 Mar 2016 05:10:04 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:60343 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1afnnW-0004tX-Ll; Tue, 15 Mar 2016 08:10:02 -0400 To: "Salz, Rich" , "trans@ietf.org" References: <56E6CD30.8070102@bbn.com> From: Stephen Kent Message-ID: <56E7FB9A.7060806@bbn.com> Date: Tue, 15 Mar 2016 08:10:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000502060206090408020001" Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 12:10:07 -0000 This is a multi-part message in MIME format. --------------000502060206090408020001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Rich, > Looks good. Clever attack; dkg has a twisted mind J > > Do we generally credit individuals in docs? > Normally I would not credit an individual in an RFC. However, in this case DKG articulated an attack that had not been described (AFAIK) in this context, and which does have implications for the CT. I'm not hard over on this point, but it seemed reasonable in this case. Steve --------------000502060206090408020001 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Rich,


Looks good.   Clever attack; dkg has a twisted mind J

 

Do we generally credit individuals in docs?

Normally I would not credit an individual in an RFC. However, in this case DKG
articulated an attack that had not been described (AFAIK) in this context, and
which does have implications for the CT. I'm not hard over on this point, but
it seemed reasonable in this case.

Steve


--------------000502060206090408020001-- From nobody Tue Mar 15 06:50:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6EB12D748 for ; Tue, 15 Mar 2016 06:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdeZapzN0LNx for ; Tue, 15 Mar 2016 06:50:45 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 0868412D5B9 for ; Tue, 15 Mar 2016 06:50:45 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id z76so24255466iof.3 for ; Tue, 15 Mar 2016 06:50:44 -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; bh=TUKgn4msxxL87Zqk1le/8RrCaSayyerMCAcsW31ECMs=; b=G4dqsRLoW2SZg3oHKR5z+gBqaQFGn5rpxP9v/Y9kkj5WKrVsF9daDcFjc/rlvMqRBA yXZ2unIr5p2662M3phGhMkzIYvlsFSoy99AnDx7sI2KZg3hdaUUlftkKjZRg4rp4Ppln 1LaQecfwKUlpy8pBO3M/yedJahpWbOkbrbWA0V4Ed/i9R6SKuSgJWa0gPfZZBI3keLCa lO8fYbGbvsoBSUbXbbvYn7iy7NZPxgAW5TnGHc3nYtW6wEdjENL7S5kCc80Y5GrNRreF /xhjfMlE/k9RPZ1lx5RAZqfGHrgs1PyLMJcChoeCWG5JzPl8W8L9h4+qydD6rRXyZEKS PbRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TUKgn4msxxL87Zqk1le/8RrCaSayyerMCAcsW31ECMs=; b=GL7dQ+iSs2jRVBeZFMH3k141TdTgadKuMzbHIyRsTqpYT/swCFEGOS5fnG1Wi5x6ek 2z5USxby1028eCJZwbXD+LP1SSSvymNIyxxEXIqMV5rm77xtgpa/f7sgJsyyC4WLW91x WcSmuX5CRLggCLWrqddt+3WOpVHo2B7El8187kd1s2ROR9sqI0GXHxmexrkUCm+GhC6i 39gzlhmuedINmvCuGtnvTT0Pytl0nSzG8Uqm2kJAzyX2ilesp0a/Um2J+VtASs1llpT/ vPaPvQ3lPsbFdG1OfgNmtHzpgM/Q8+5CX5yjtRhdlvlTija6Wi9lSeyrGMGYHskZTnc5 r2BQ== X-Gm-Message-State: AD7BkJJ3s/ijC5oXisaofLOpJaK75aIz2Ol1p8a8ybIXKk6843QiK8mj/CGQA5ClIlsN4FY0YPixmarvLfqr2SjG MIME-Version: 1.0 X-Received: by 10.107.157.80 with SMTP id g77mr33233095ioe.172.1458049844347; Tue, 15 Mar 2016 06:50:44 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Tue, 15 Mar 2016 06:50:44 -0700 (PDT) In-Reply-To: <56E737EC.9020203@comodo.com> References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> Date: Tue, 15 Mar 2016 13:50:44 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 13:50:46 -0000 On 14 March 2016 at 22:15, Rob Stradling wrote: > On 14/03/16 21:39, Ben Laurie wrote: >> >> On 14 March 2016 at 14:39, Stephen Kent wrote: >>> >>> The logged bogus certificate can be detected by a Monitor (third party or >>> self), that is watching the log(s) to which the certificate was posted. >>> Thus >>> the detection aspect of CT still works with regard to this certificate. >>> When >>> this certificate is detected, the CA that logged the certificate may >>> revoke >>> it, i.e., place it on a CRL or create an OCSP response for it. However, a >>> browser checking a CRL or OCSP response will not match this revocation >>> status data against the other, not-logged bogus certificate. (This is >>> because revocation status checking is performed in the context of a >>> certificate path and the two bogus certificates have different >>> certificate >>> paths.) Revoking a detected, bogus certificate may be the best strategy >>> for >>> the malicious CAs. It makes issuance of the bogus certificate appear to >>> be >>> an accident, and thus browser vendors may not feel the need to make an >>> entry >>> on their blacklists for the bogus certificate or the CA that issued it. >> >> >> I do not believe this is correct. And if it is, it is a serious bug in >> revocation that has nothing to do with certificate transparency. >> >> Also, I don't get the logic of the "not-logged bogus certificate", >> which is identical to the logged certificate - and is therefore >> logged. And not bogus. > > > +1 > > The "two" bogus certificates are one and the same. They will contain the > same CRL and/or OCSP URLs. The outcome of a CRL/OCSP check will be exactly > the same for both certs. > > AIUI, for DKG's attack to work, it is necessary for: > - the "two" bogus certificates to _not_ be revoked. > - one of the doppelganger intermediates to be logged and revoked. > - the other one (or more) of the doppelganger intermediates to be neither > logged nor revoked. > > I think that there are two possible ways to thwart this attack: > > 1. Redefine SCTs so that they become SCCTs (Signed Certificate Chain > Timestamps) - i.e. the signature is calculated over the entire chain > submitted. I think this is unworkable, because there are too many cases > where different chains are legitimate and even expected. > > 2. Declare that this is not a problem with CT. It's a problem with using > CRL and/or OCSP to revoke intermediates. So we (where "we" may or may not > be TRANS) need to fix revocation! > Revoking an intermediate _certificate_ just isn't sufficient. > To be effective, the intermediate _public key_ needs to be revoked somehow. 3. Always revoke bad certs that appear in logs! From nobody Tue Mar 15 06:51:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832E012DA5D for ; Tue, 15 Mar 2016 06:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0d-LP3Bwa_A for ; Tue, 15 Mar 2016 06:51:24 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C242812D5B9 for ; Tue, 15 Mar 2016 06:51:24 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id vf5so87879059igb.0 for ; Tue, 15 Mar 2016 06:51:24 -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; bh=2MhpT3R509rUs95yaeFkK69MOr39/OJZLCIDj1mZ528=; b=G83LKA3uo91jCIfC11rn3mXip6oTLrDICfgsuRvnDVLG28LmWd74i2O3DPpcMkVPqG EKEBn/GmQHulkJ1pULNmHmZ5HQPY00HZvQDfr54SoYJF/8p0i08JY3qC71rwE0+bJwYe acZ/+tZ1y6aYwFhci47WbMKhywa//+B+9joBgQSoOXYtbQOnTd2oz42oX0pOB0YL80Bz O8fekCRxkQYLPIkiZyo9oJ+4hffVrISOiI7fSGuhqmNqcn9Diq8y6gF+BQ+BGjkcOh5W kSxJYGoobGDe0ye3GJwTbShLJ5z0DfJp/V0kiHcOnIEYME2Fx40iDIzbhFRXw7JokEHX m+Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2MhpT3R509rUs95yaeFkK69MOr39/OJZLCIDj1mZ528=; b=N4LXVSj3U31X0denln4iGoMrpHBqyGt+mUr2UdaRMI6g7mefdU7rV6MApn9X9I7soT HH16psLsJ8zC8WWKjvKZtxJH7zJLif1EY7jg2lVSK8REZylMNzlGW/Vl0+BkupBB+7xc +FtReX4IRu5U66YgB3kU2bDQBcP/e2z7B6Sic3hLmgLH6+aYq7kSYfE2Z85RNtMjuwYg Q3ecnBP/sx0eKwACyilS1lDZeC5qrRvPZNoizQT0hG5HByRwjQmCQhBs3IBtumuaXo1w MiEMZ5GNT7mahgezeVaDNYnOwWk+TD/P3jqH/8h+lQlMZLQvfn94XLr0Wgp3LnueXJ5w sqEA== X-Gm-Message-State: AD7BkJIfBuwFmkZmN2SD00wbvzIQTnqKxxLvWinF5jzplFtwZypFh06YmngM3yk2bEdlkUC9oGPdyazJJDGGVsdK MIME-Version: 1.0 X-Received: by 10.50.50.234 with SMTP id f10mr4352310igo.37.1458049883986; Tue, 15 Mar 2016 06:51:23 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Tue, 15 Mar 2016 06:51:23 -0700 (PDT) In-Reply-To: References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> Date: Tue, 15 Mar 2016 13:51:23 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 13:51:30 -0000 Oh, also: 4. Require SCTs for all certs in the chain, which prevents hiding the alternate intermediate. On 15 March 2016 at 13:50, Ben Laurie wrote: > On 14 March 2016 at 22:15, Rob Stradling wrote: >> On 14/03/16 21:39, Ben Laurie wrote: >>> >>> On 14 March 2016 at 14:39, Stephen Kent wrote: >>>> >>>> The logged bogus certificate can be detected by a Monitor (third party or >>>> self), that is watching the log(s) to which the certificate was posted. >>>> Thus >>>> the detection aspect of CT still works with regard to this certificate. >>>> When >>>> this certificate is detected, the CA that logged the certificate may >>>> revoke >>>> it, i.e., place it on a CRL or create an OCSP response for it. However, a >>>> browser checking a CRL or OCSP response will not match this revocation >>>> status data against the other, not-logged bogus certificate. (This is >>>> because revocation status checking is performed in the context of a >>>> certificate path and the two bogus certificates have different >>>> certificate >>>> paths.) Revoking a detected, bogus certificate may be the best strategy >>>> for >>>> the malicious CAs. It makes issuance of the bogus certificate appear to >>>> be >>>> an accident, and thus browser vendors may not feel the need to make an >>>> entry >>>> on their blacklists for the bogus certificate or the CA that issued it. >>> >>> >>> I do not believe this is correct. And if it is, it is a serious bug in >>> revocation that has nothing to do with certificate transparency. >>> >>> Also, I don't get the logic of the "not-logged bogus certificate", >>> which is identical to the logged certificate - and is therefore >>> logged. And not bogus. >> >> >> +1 >> >> The "two" bogus certificates are one and the same. They will contain the >> same CRL and/or OCSP URLs. The outcome of a CRL/OCSP check will be exactly >> the same for both certs. >> >> AIUI, for DKG's attack to work, it is necessary for: >> - the "two" bogus certificates to _not_ be revoked. >> - one of the doppelganger intermediates to be logged and revoked. >> - the other one (or more) of the doppelganger intermediates to be neither >> logged nor revoked. >> >> I think that there are two possible ways to thwart this attack: >> >> 1. Redefine SCTs so that they become SCCTs (Signed Certificate Chain >> Timestamps) - i.e. the signature is calculated over the entire chain >> submitted. I think this is unworkable, because there are too many cases >> where different chains are legitimate and even expected. >> >> 2. Declare that this is not a problem with CT. It's a problem with using >> CRL and/or OCSP to revoke intermediates. So we (where "we" may or may not >> be TRANS) need to fix revocation! >> Revoking an intermediate _certificate_ just isn't sufficient. >> To be effective, the intermediate _public key_ needs to be revoked somehow. > > 3. Always revoke bad certs that appear in logs! From nobody Tue Mar 15 07:03:59 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F8112DA98 for ; Tue, 15 Mar 2016 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMpPXT4zEAxX for ; Tue, 15 Mar 2016 07:03:55 -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 2306712DA8D for ; Tue, 15 Mar 2016 07:03:32 -0700 (PDT) Received: (qmail 23899 invoked by uid 1004); 15 Mar 2016 14:03:29 -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, 15 Mar 2016 14:03:29 +0000 Received: (qmail 956 invoked by uid 1000); 15 Mar 2016 14:03: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; Tue, 15 Mar 2016 14:03:29 +0000 To: Ben Laurie References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> From: Rob Stradling Message-ID: <56E81631.8020909@comodo.com> Date: Tue, 15 Mar 2016 14:03:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 14:03:58 -0000 On 15/03/16 13:50, Ben Laurie wrote: > 3. Always revoke bad certs that appear in logs! If the intermediate is being blacklisted, would you really trust the CA to revoke all of the logged end-entity certs? We need revocation mechanisms that are effective without having to trust the CA. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Mar 15 07:05:07 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A451A12DAE1 for ; Tue, 15 Mar 2016 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqfSYgQKYRTl for ; Tue, 15 Mar 2016 07:04:44 -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 A23D112DA96 for ; Tue, 15 Mar 2016 07:03:45 -0700 (PDT) Received: (qmail 17101 invoked by uid 1004); 15 Mar 2016 14:03:43 -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, 15 Mar 2016 14:03:43 +0000 Received: (qmail 1094 invoked by uid 1000); 15 Mar 2016 14:03:43 -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, 15 Mar 2016 14:03:43 +0000 To: Ben Laurie References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> From: Rob Stradling Message-ID: <56E8163F.2000201@comodo.com> Date: Tue, 15 Mar 2016 14:03:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 14:04:47 -0000 On 15/03/16 13:51, Ben Laurie wrote: > Oh, also: > > 4. Require SCTs for all certs in the chain, which prevents hiding the > alternate intermediate. In my experience CA certificates rarely need to be issued in a hurry, so maybe requiring Inclusion Proofs for all CA certificates in the chain could work. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Mar 15 07:48:57 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D12612D625 for ; Tue, 15 Mar 2016 07:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykWWHo4DlVi8 for ; Tue, 15 Mar 2016 07:48:54 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8FC12D5D5 for ; Tue, 15 Mar 2016 07:48:51 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id m184so26621629iof.1 for ; Tue, 15 Mar 2016 07:48: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; bh=2ff59kI32IBW8NWvFJdHNWXRUMW6AqT7S7vk/UxwBRw=; b=avKZUo7jwRufX2MPflQdvsS2Nj+D8tcOWkyh/TrkgmzlKTJpoa6zcdBf0rqh2ly+wX R7HOK7QSagjBn4H6fWWxYmKnqHqAmqjBmeX/lsxGoBFP1AC5UttjcfK0vMRYOqiMEBxB hvt2WMJq+tPD4it4P9dULQE1DQhE8Dr7X8UkD9AuIqvgfFPZipIYVq82N4xOC2aHBqKi OWkBsYHnG6qe5izpP5COICZ8A/805wDMG9ROu3NdQ52rUkSGoP3PCTqaJ6nlBanJlzWQ 8yXLwSLRZMONL31ElN1XQ/icgEkLeU1tE0meMukvvL2a6C9WAD5eIssHjuD7hPXK/kVU SEOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2ff59kI32IBW8NWvFJdHNWXRUMW6AqT7S7vk/UxwBRw=; b=HPn/HATG7xeL1iZhY5YppbBZ6luqYlFe5vvnlWZOtTQY7/No9grSIaHrtmpjP99vZy WpEn7myUjrtMlnYNuxv0s99IfjSe5ZKX0YiGXOKZ7HU1guZOOk7I3KCShU9PmCQtCVjC 5/j3BeGgrHqUPw/XAJ5RZXBbz58TFot4OctbaTaYHl13kdoQkYi69tACKEHti4mwXQhG AOK5zIKP9Jng8QMN3Kbrg2hPRPaA5EdGnlUavxhJxGBDkhotV/IOK2LxbT/lydbLzo8+ HHJoiSzN0ETKdeO+Mzv/bAGu+HVMei7afDtZqi3oDztvviZfGhSaRPDF93RxsxnagIcp NP4w== X-Gm-Message-State: AD7BkJKrmaq7tV9ID6dwOF/Tl5/VcJ5muHMD7i0a5vbx5KKBIbMlDa4LVAWs37YMzBDwc7GlSKNaH7E+uaS7fGIy MIME-Version: 1.0 X-Received: by 10.107.157.80 with SMTP id g77mr33582607ioe.172.1458053330716; Tue, 15 Mar 2016 07:48:50 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Tue, 15 Mar 2016 07:48:50 -0700 (PDT) In-Reply-To: <56E81631.8020909@comodo.com> References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> <56E81631.8020909@comodo.com> Date: Tue, 15 Mar 2016 14:48:50 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 14:48:56 -0000 On 15 March 2016 at 14:03, Rob Stradling wrote: > On 15/03/16 13:50, Ben Laurie wrote: > >> >> 3. Always revoke bad certs that appear in logs! > > > If the intermediate is being blacklisted, would you really trust the CA to > revoke all of the logged end-entity certs? > > We need revocation mechanisms that are effective without having to trust the > CA. I will not argue with that. From nobody Tue Mar 15 07:49:39 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4112DBEB for ; Tue, 15 Mar 2016 07:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnl_zaMX9aQD for ; Tue, 15 Mar 2016 07:49:31 -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 741C212DB62 for ; Tue, 15 Mar 2016 07:49:26 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id vf5so89390418igb.0 for ; Tue, 15 Mar 2016 07:49:26 -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; bh=SJcU4n4ZonU67i0rjOcfEPHKaGyjVCAlh5iJs452j8k=; b=desiqYZwNEbXRt+egTvxMFBsfHGnHY6LDx9Nblz3cR1YZ1kxkcR2ABBuccdaEu45iT Y+kjDgmDy8vp2x7CTKoq/a89vPDJpL6lkZLbn7RYqUqtP5A6YFO7noz5xGeIDTlcmaPh f95hfmEGTMwp2MMpvoFm2HCVt1uGVEyFpuDn8sAHV9+0St9ilLy9EcNCzAnlkx8xq0LT NUf969O6qU02SZ4fg3zbhGIjJrhdz8O9o7GDRFifX+nZ+vRvzTZbTWpuRJduEDdni+kG Zz2u//6A2IYKM6m36xKT4/j4Bj41BVcMoLycuD53BxD5biHNpFbSQLOhvY2QlXp8LgcX I3LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SJcU4n4ZonU67i0rjOcfEPHKaGyjVCAlh5iJs452j8k=; b=asYAzxLLZnZRzfgTuuA+0+kN6ool4V4030hftSLkq7CV4Y8MnEKV6Gz2PHDHBiyL74 DaFmV+imP6aaSpz1grGxBXiOREpg+M5LRfDtpiHnmcPfu5duHwPCLN40OVsNB7XKgg0a OE2VFYmhUuzHQFVOB6uGWwo1Gn7RQcApk4rR2yaQl4ZZCh+iS3WnHnzGtk3tTYBMJGKO RrBEkcnXr52t5uKu7pIZSEpn0jAlObTd9DhqT0YCW9H7/cV6jzed18nDLv2Nb9aO0xiL Hv8vtLBPRsgN0w0Ad5MyUZPa6am3E1GoS62i2LJxPLLkqSTLezpovxWNx/pZzra9VsjS 5riA== X-Gm-Message-State: AD7BkJJlcgzTP2Gf3DTsx+C6ImBnP4Bv1N7DeS49rPfvv01sbRObFlV2mypGM1LnQYoLJZS/oOVxFOl+usW91Rh/ MIME-Version: 1.0 X-Received: by 10.50.132.6 with SMTP id oq6mr25056139igb.32.1458053365656; Tue, 15 Mar 2016 07:49:25 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Tue, 15 Mar 2016 07:49:25 -0700 (PDT) In-Reply-To: <56E8163F.2000201@comodo.com> References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> <56E8163F.2000201@comodo.com> Date: Tue, 15 Mar 2016 14:49:25 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 14:49:37 -0000 On 15 March 2016 at 14:03, Rob Stradling wrote: > On 15/03/16 13:51, Ben Laurie wrote: >> >> Oh, also: >> >> 4. Require SCTs for all certs in the chain, which prevents hiding the >> alternate intermediate. > > > In my experience CA certificates rarely need to be issued in a hurry, so > maybe requiring Inclusion Proofs for all CA certificates in the chain could > work. That would also work. From nobody Tue Mar 15 07:58:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7087012DAAB for ; Tue, 15 Mar 2016 07:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9odimLCuWoK for ; Tue, 15 Mar 2016 07:58:16 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1682B12DAAD for ; Tue, 15 Mar 2016 07:57:56 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Mar 2016 10:59:27 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.406.0; Tue, 15 Mar 2016 10:57:55 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2FEvi2U015711 for ; Tue, 15 Mar 2016 10:57:44 -0400 To: "trans@ietf.org" References: <56E6CD30.8070102@bbn.com> From: "David A. Cooper" Message-ID: <56E822E8.7000704@nist.gov> Date: Tue, 15 Mar 2016 10:57:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E6CD30.8070102@bbn.com> Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 14:58:19 -0000
As others have pointed out, the description below is fundamentally flawed, and as a result the conclusion is flawed as well. See comments in-line below.

On 03/14/2016 10:39 AM, Stephen Kent wrote:
Below is the text I plan to insert as a new section in the threat analysis doc,
to address the attack DKG articulated. Comments welcome.

Steve
------

3.3 Malicious, Colluding CAs

 

Section 3.2 examined attacks in which a single CA issued a bogus certificate. Daniel Kahn Gilmor posited an attack in which two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the safeguards envisioned by CT. Specifically, he suggested that two trust anchors could create intermediate (subordinate) CAs that have the same Subject name, the same public key, and the same Subject Key Identifier) in the their certificates.


What's effectively happening here is not that the two trust anchors are creating two intermediate (subordinate) CAs. They are creating a single intermediate (subordinate) CA, and each of them is issuing a cross-certificate to it.

     +----------------+    +----------------+
     | trust anchor 1 |    | trust anchor 2 |
     +----------------+    +----------------+
                \              /
                 \            /
               +----------------+
               | subordinate CA |
               +----------------+

In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not name-constrained; the attack need not be initiated by trust anchors per se. (Also note that X.509 and RFC 5280 do not preclude creation of doppelganger CAs; the requirement for Subject name uniqueness applies individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.)


This is incorrect! X.509 requires name uniqueness, including across CA boundaries. [Since this issue isn't relevant to the "conspiring CAs attack," information about this inaccuracy is at the end of the email.

The attack requires that both of the doppelganger CAs issue a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs a bogus certificate and acquires an SCT for it. Because the bogus certificates are identical, the SCT will match both.


As noted by others, if the two (EE) certificates are identical, then there is only one EE certificate. So, in the scenario described above, there aren't two intermediate CAs and two (identical) EE certificates. There are two trust anchors, each issuing a certificate to a single subordinate CA, which in turn has issued a single EE certificate identifying the target Subject:

     +----------------+    +----------------+
     | trust anchor 1 |    | trust anchor 2 |
     +----------------+    +----------------+
                \              /
                 \            /
               +----------------+
               | subordinate CA |
               +----------------+
                       |
                       |  EE certificate
                       |
              +------------------+
              | targeted Subject |
              +------------------+

The logged bogus certificate can be detected by a Monitor (third party or self), that is watching the log(s) to which the certificate was posted. Thus the detection aspect of CT still works with regard to this certificate. When this certificate is detected, the CA that logged the certificate may revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response will not match this revocation  status data against the other, not-logged bogus certificate. (This is because revocation status checking is performed in the context of a certificate path and the two bogus certificates have different certificate paths.)


Again, as others have noted, and as can be seen clearly in the figure above, from the relying party's point of view, there is only one intermediate CA. So, a browser checking a CRL or OCSP response will get the same result whether it is attempting to validate this EE certificate using trust anchor 1 or trust anchor 2 as the starting point for the certification path. There is nothing in a CRL or OCSP response that would make a CRL or OCSP response valid for a path that starts at trust anchor 1 but invalid for a path that starts at trust anchor 2.

The only way I can see to (possibly) get the results described above would be if the "two" EE certificates had different values in the cRLDistributionPoints extension and/or the authorityInfoAccess extension so that the relying party would go to different sources for revocation information for the two EE certificates. But then, that would mean the two EE certificate weren't identical.

Revoking a detected, bogus certificate  may be the best strategy for the malicious CAs. It makes issuance of the bogus certificate appear to be an accident, and thus browser vendors may not feel the need to make an entry on their blacklists for the bogus certificate or the CA that issued it.

 

If the CA that issued the (logged) bogus certificate fails to revoke it, browser vendors might blacklist the certificate. However, as noted above, the other bogus certificate, which was not logged, still will match the SCT created for the logged (now revoked) certificate. If remediation is effected by blacklisting (instead of revocation by the malicious CA) then the ability of CT to deal with this sort of attack may be diminished. Some forms of blacklisting will cause the not-logged bogus certificate to be detected and rejected, while others will not, depending on the details of the blacklisting mechanism. Mechanisms for blacklisting by browsers are not specified in any IETF standards. The mechanisms are browser-specific, and the choice of how to blacklist (e.g., the bogus certificate vs. the CA that issued it) are the purview of each browser vendor. Thus, depending on the details of the blacklist mechanism and the way that a browser vendor chooses to manage this list, a doppelganger CA attack might or might not pose a problem in terms of successful remediation of the attack.



If there is an attack here, it seems that it would be as follows. Upon detection of the bogus certificate browsers determine that the subordinate CA is malicious and blacklist the cross-certificate from trust anchor 1 to subordinate CA, but don't blacklist any of the EE certificates issued by the subordinate CA (and the subordinate CA doesn't revoke them either). The browsers don't notice that there is a second cross-certificate for subordinate CA, from trust anchor 2, and so there continues to be a valid certification path for certificates issued by subordinate CA.

------------------------------------------------------------------

Unfortunately, there is some misinformation that X.509's name uniqueness requirement only applies to each CA. X.509 is very clear that this is not the case. Among other things, it says that "For every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users."

 In addition, there is text in the Security Considerations section of RFC 6818 (RFC 5280 Clarifications) warning that there is a risk that two different CAs could issue certificates with the same subject name:

     Among many other possible attacks, the attacker may issue bogus
     certificates that have the same subject names as legitimate
     certificates in order impersonate legitimate certificate subjects.
     This could include bogus CA certificates in which the subject names
     in the bogus certificates match the names under which legitimate CAs
     issue certificates and CRLs.  This would allow the attacker to issue
     bogus certificates and CRLs that have the same issuer names, and
     possibly the same serial numbers, as certificates and CRLs issued by
     legitimate CAs.

You can also look at CMS (RFC 5652) to see that this is incorrect. It issues issuer name and serial number to identify a certificate:

    The IssuerAndSerialNumber type identifies a certificate, and thereby
    an entity and a public key, by the distinguished name of the
    certificate issuer and an issuer-specific certificate serial number.

This only works because the requirement for name uniqueness applies across all issuers, not individually to each CA.

The indirect CRL mechanism in X.509 also requires on names being unique across CAs. So does the PKIX profile for attribute certificates (RFC 5755):

   If an attribute certificate is tied to the holder's PKC using the
   baseCertificateID component of the Holder field and the PKI in use
   includes a rogue CA with the same issuer name specified in the
   baseCertificateID component, this rogue CA could issue a PKC to a
   malicious party, using the same issuer name and serial number as the
   proper holder's PKC.  Then the malicious party could use this PKC in
   conjunction with the AC.  This scenario SHOULD be avoided by properly
   managing and configuring the PKI so that there cannot be two CAs with
   the same name.  Another alternative is to tie ACs to PKCs using the
   publicKeyCert type in the ObjectDigestInfo field.  Failing this, AC
   verifiers have to establish (using other means) that the potential
   collisions cannot actually occur, for example, the Certificate
   Practice Statements (CPSs) of the CAs involved may make it clear that
   no such name collisions can occur.

Again, it notes that CA names have to be unique across the entire PKI, not just among those that have been issued certificates from a single CA.

 From nobody Tue Mar 15 08:04:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BB612DAAB for ; Tue, 15 Mar 2016 08:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff_hycJmDZ2P for ; Tue, 15 Mar 2016 08:04:10 -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 F15D812D5EF for ; Tue, 15 Mar 2016 08:04:05 -0700 (PDT) Received: (qmail 28506 invoked by uid 1004); 15 Mar 2016 15:04:03 -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, 15 Mar 2016 15:04:03 +0000 Received: (qmail 29439 invoked by uid 1000); 15 Mar 2016 15:04:03 -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, 15 Mar 2016 15:04:03 +0000 To: "David A. Cooper" , "trans@ietf.org" References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> From: Rob Stradling Message-ID: <56E82463.6030602@comodo.com> Date: Tue, 15 Mar 2016 15:04:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56E822E8.7000704@nist.gov> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 15:04:15 -0000 On 15/03/16 14:57, David A. Cooper wrote: > If there is an attack here, it seems that it would be as follows. Upon > detection of the bogus certificate browsers determine that the > subordinate CA is malicious and blacklist the cross-certificate from > trust anchor 1 to subordinate CA, but don't blacklist any of the EE > certificates issued by the subordinate CA (and the subordinate CA > doesn't revoke them either). The browsers don't notice that there is a > second cross-certificate for subordinate CA, from trust anchor 2, and so > there continues to be a valid certification path for certificates issued > by subordinate CA. Yes, that is DKG's attack. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Mar 15 08:19:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FD812DAE6 for ; Tue, 15 Mar 2016 08:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQJ8FPdwC_tq for ; Tue, 15 Mar 2016 08:18:57 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A2712D627 for ; Tue, 15 Mar 2016 08:18:45 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Mar 2016 11:19:06 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.406.0; Tue, 15 Mar 2016 11:18:44 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2FFIWho017752; Tue, 15 Mar 2016 11:18:32 -0400 To: Rob Stradling , "trans@ietf.org" References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E82463.6030602@comodo.com> From: "David A. Cooper" Message-ID: <56E827C8.6080904@nist.gov> Date: Tue, 15 Mar 2016 11:18:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E82463.6030602@comodo.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 15:19:02 -0000
Okay, thanks. I hadn't read DKG's attack before, only Steve Kent's text purportedly describing DKG's attack. It seems that DKG correctly described a possible attack, and then Steve got it totally wrong when he tried to describe it. My comments were on Steve Kent's text, not on DKG's description of the attack.

On 03/15/2016 11:04 AM, Rob Stradling wrote:
On 15/03/16 14:57, David A. Cooper wrote:
<snip>
If there is an attack here, it seems that it would be as follows. Upon
detection of the bogus certificate browsers determine that the
subordinate CA is malicious and blacklist the cross-certificate from
trust anchor 1 to subordinate CA, but don't blacklist any of the EE
certificates issued by the subordinate CA (and the subordinate CA
doesn't revoke them either). The browsers don't notice that there is a
second cross-certificate for subordinate CA, from trust anchor 2, and so
there continues to be a valid certification path for certificates issued
by subordinate CA.

Yes, that is DKG's attack.

---------------------------------------------------------------------------------------------------------


-------- Forwarded Message --------
Subject: [Trans] can CT defend against dual CA compromise?
Date: Sat, 20 Feb 2016 22:05:27 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: trans@ietf.org 


CT currently focuses on logging end-entity (leaf) certs; as a result, i
think that an attacker who can compromise two CAs can keep one of those
compromises secret from the CT ecosystem.

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

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

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

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

Now we have two possible chains:

  A -> A_X -> C

  B -> B_X -> C

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

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

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

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

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

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

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

 * recommend that clients who care about transparency should expect that
   all intermediate certs themselves are logged -- 6962bis already
   permits this, though it seems to be mainly in contemplation of
   name-constrained intermediate authorities.  This expands the number
   of SCTs or inclusion proofs that need to accompany a chain, and makes
   verification logic slightly more complicated.

 * logs could refuse to log any certs that chain back to a known-failed
   CA (or through a known-bad intermediate CA).  This would constrain a
   dual-compromise attacker from minting new certs after the first CA is
   known to be compromised.  This seems like a useful mitigation, but
   it's also complictated and delicate.  What does "known-failed" mean?
   What if there is a dispute over the validity of a cert, with one
   party claiming that it was misissued, and the CA claiming its
   legitimacy?  What if some browser vendors have dropped the CA, and
   others have not?  This puts the logs in a position of being some kind
   of arbiter of the root store, with very subtle knock-on effects to
   security of the whole ecosystem if they decide to not drop a CA.

   Even more subtly, if the public narrative of the compromise ends up
   being "A_X is bad" (include the intermediate cert in client
   blacklists and refuse to log things that chain through it) instead of
   "A is bad" (include the root cert in client blacklists and refuse to
   log things that chain to it), then the attacker can simply mint
   multiple intermediate keys (X_0, X_1, etc) and corresponding
   intermediate certificates at the time of the compromise, and
   burn/expose them one spoofing attack at a time.

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

         --dkg


From nobody Wed Mar 16 05:22:54 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2AD12D577 for ; Wed, 16 Mar 2016 05:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDxtHCaBJPlg for ; Wed, 16 Mar 2016 05:22:51 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 7E55312D579 for ; Wed, 16 Mar 2016 05:22:51 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g3so59178369ywa.3 for ; Wed, 16 Mar 2016 05:22:51 -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; bh=MPNbyJ/V0Tr7hmjUePe21uKZpxZU3NDFgtjIZzDsBsA=; b=LMmpX6Rq5KQ8e/XO1bKCHfD3t9l+AM3CbsACHrw4f6DiDEdrHFouxDMHBHi6h5QtTY hdIOuv9Ef8aQGLwaz1Anam/GqCAhQlCvYwDSADBtw+Hw6ifabdqP02bsdYa1wnvdxsHC 32n1JXquftmNu955YeFCguODP4VJNOim0D5Hz7U9Q0U8ktxEs+Y2SN4uN6Vv1G3xwmnG +yRcDD4JxWh61EDf9W/aCcfHj2KX+QHnBvsEYY3NdZZ0cEqKu49cGU86hk4bxMCx8L38 ifDpxH87LtsCm0fm4eRWJ1+jMkxqTa+ZqJELVD0RCOAhuDexvdyBwKBKwhWPCr5uMF3q D6ZQ== 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; bh=MPNbyJ/V0Tr7hmjUePe21uKZpxZU3NDFgtjIZzDsBsA=; b=UyuqaYAEw05XpaDa58MQiq5MznuGWuMQe3KD8wB1TbGqpqZSpbGcaJrNZkjLKjzf81 z4P8tQaac7YiNZbqsPpsNb+dzXQjbXJtzvw8kCrUTPSOncDDQTO4oYhSz0GCq1/zAa+y mEK5x6gvdIu+vLNfLDJ2u0K/mmGNY6jdfiB5NT2ZNZTbVBsybybRLoKG0uPOvRKuF8M5 +GVt8c0UAXzo+NphHDSq6mBn1vXMa+c/qf+6a3mmp/pK62CYGShjADaf0AiNIc0FWL+Z 16mO73FxeZWlbYt2Hezo5EAim5HGD/fKv8/FzToeKAlI75ZZgk0gIL/sBrD6Aj+laqTK Ve5g== X-Gm-Message-State: AD7BkJL2+f4dft9+HAIu0MBMgiAUtdG9ebaEEiAUfPqGivV4ovhZY7ZRlqIz2ILGbqMYY6Tcymj4LkPMV+P/zVej MIME-Version: 1.0 X-Received: by 10.37.18.84 with SMTP id 81mr1642650ybs.117.1458130970603; Wed, 16 Mar 2016 05:22:50 -0700 (PDT) Received: by 10.37.48.6 with HTTP; Wed, 16 Mar 2016 05:22:50 -0700 (PDT) Date: Wed, 16 Mar 2016 12:22:50 +0000 Message-ID: From: Eran Messeri To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a114235b68a60be052e299259 Archived-At: Subject: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 12:22:53 -0000 --001a114235b68a60be052e299259 Content-Type: text/plain; charset=UTF-8 How desirable is it for issuers to be able to embed V1 and V2 SCTs in the same certificate? Background: V1 SCTs (RFC6962) and V2 SCTs (RFC6992-bis) are completely different and can co-exist for X.509 certificates as they are delivered in different OCSP extensions / TLS exetensions. In the case of precertificates, while in theory V1 and V2 SCTs can be independently embedded (as the X.509 extensions to embed each type are different), in practice SCTs for V1 Precertificates cover the entire TBSCertificate, including the V2 SCTs (otherwise the V1 SCT won't be valid) and the same goes for V2 SCTs. In RFC6962-bis, as it is defined right now, V1 and V2 SCTs for the same precertificate cannot be embedded in the same X.509 certificate. It seems to me there would be benefit to enabling this combination, as that means issuers can issue certificates that would comply both with V1 CT clients and V2 CT clients without forcing V2 clients to also implement RFC6962. The solution I propose: - In the normative section of RFC6962-bis about SCT checking, specify that TLS clients SHOULD remove the V1 X.509 extension (OID XXX) when checking V2 Precertificate SCTs. - In an informal appendix, suggest the following process for issuing an X.509 certificate that contains valid V1 and V2 SCTs embedded: (1) Issuer create a valid RFC6962-bis precertificate and submits it to V2 logs, collecting the returned SCTs. (2) Issuer embeds the V2 SCTs (as TransItems) into the TBSCertificate with the V2 X.509 extension. (3) Issuer then adds the poison extension from RFC6962, signs the TBSCertificate to produce a valid V1 precertificate, which it then submits to V1 logs. (4) Issuer embeds the V1 SCTs in the TBSCertificate and signs it, producing the final X.509 certificate to be used by the server. V1 clients would validate the V1 SCTs and ignore the V2 SCTs. V2 clients would remove the V1 SCTs and validate the signature over the resulting TBSCertificate, which would then exclude V1 and V2 SCTs and be identical to the TBSCertificate in the V2 (CMS) precertificate submitted to the log. Thoughts? Eran --001a114235b68a60be052e299259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How desirable is it for issuers to be able to embed V1 and= V2 SCTs in the same certificate?

Background: V1 SCTs (R= FC6962) and V2 SCTs (RFC6992-bis) are completely different and can co-exist= for X.509 certificates as they are delivered in different OCSP extensions = / TLS exetensions.

In the case of precertificates,= while in theory V1 and V2 SCTs can be independently embedded (as the X.509= extensions to embed each type are different), in practice SCTs for V1 Prec= ertificates cover the entire TBSCertificate, including the V2 SCTs (otherwi= se the V1 SCT won't be valid) and the same goes for V2 SCTs.
=
In RFC6962-bis, as it is defined right now, =C2=A0V1 and V2 = SCTs for the same precertificate cannot be embedded in the same X.509 certi= ficate.
It seems to me there would be benefit to enabling this co= mbination, as that means issuers can issue certificates that would comply b= oth with V1 CT clients and V2 CT clients without forcing V2 clients to also= implement RFC6962.

The solution I propose:
<= div>- In the normative section of RFC6962-bis about SCT checking, specify t= hat TLS clients SHOULD remove the V1 X.509 extension (OID XXX) when checkin= g V2 Precertificate SCTs.
- In an informal appendix, suggest the = following process for issuing an X.509 certificate that contains valid V1 a= nd V2 SCTs embedded:
(1) Issuer create a valid RFC6962-bis precer= tificate and submits it to V2 logs, collecting the returned SCTs.
(2) Issuer embeds the V2 SCTs (as TransItems) into the TBSCertificate with= the V2 X.509 extension.
(3) Issuer then adds the poison extensio= n from RFC6962, signs the TBSCertificate to produce a valid V1 precertifica= te, which it then submits to V1 logs.
(4) Issuer embeds the V1 SC= Ts in the TBSCertificate and signs it, producing the final X.509 certificat= e to be used by the server.

V1 clients would valid= ate the V1 SCTs and ignore the V2 SCTs.
V2 clients would remove t= he V1 SCTs and validate the signature over the resulting TBSCertificate, wh= ich would then exclude V1 and V2 SCTs and be identical to the TBSCertificat= e in the V2 (CMS) precertificate submitted to the log.

=
Thoughts?=C2=A0

Eran
--001a114235b68a60be052e299259-- From nobody Wed Mar 16 06:07:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A6612D912 for ; Wed, 16 Mar 2016 06:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ2xSp3vr8k4 for ; Wed, 16 Mar 2016 06:07:15 -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 2450212D95C for ; Wed, 16 Mar 2016 06:07:13 -0700 (PDT) Received: (qmail 2305 invoked by uid 1004); 16 Mar 2016 13:07:11 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 16 Mar 2016 13:07:11 +0000 Received: (qmail 5552 invoked by uid 1000); 16 Mar 2016 13:07:11 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 16 Mar 2016 13:07:11 +0000 To: Eran Messeri , "trans@ietf.org" References: From: Rob Stradling Message-ID: <56E95A7D.5040102@comodo.com> Date: Wed, 16 Mar 2016 13:07:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.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] Co-existence of V1 and V2 embedded SCTs in certificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 13:07:23 -0000 On 16/03/16 12:22, Eran Messeri wrote: > How desirable is it for issuers to be able to embed V1 and V2 SCTs in > the same certificate? Eran, thanks for thinking this through. I think that this is definitely desirable, and I like the solution you've proposed. If we don't do this, I think it would adversely affect adoption of V2. Embedding SCTs in certificates is the only SCT delivery mechanism that all TLS servers support, and few people are going to want to break compatibility (by embedding only V2 SCTs in certs) with V1 clients that still have a significant userbase. (Pretend for a moment that "V1" is sha1WithRSAEncryption and "V2" is sha256WithRSAEncryption. Adoption of sha256WithRSAEncryption for certificate signatures was extremely slow, because (i) the userbase of clients that only supported sha1WithRSAEncryption was still significant and (ii) certificates can only have 1 signature). > Background: V1 SCTs (RFC6962) and V2 SCTs (RFC6992-bis) are completely > different and can co-exist for X.509 certificates as they are delivered > in different OCSP extensions / TLS exetensions. > > In the case of precertificates, while in theory V1 and V2 SCTs can be > independently embedded (as the X.509 extensions to embed each type are > different), in practice SCTs for V1 Precertificates cover the entire > TBSCertificate, including the V2 SCTs (otherwise the V1 SCT won't be > valid) and the same goes for V2 SCTs. > > In RFC6962-bis, as it is defined right now, V1 and V2 SCTs for the same > precertificate cannot be embedded in the same X.509 certificate. > It seems to me there would be benefit to enabling this combination, as > that means issuers can issue certificates that would comply both with V1 > CT clients and V2 CT clients without forcing V2 clients to also > implement RFC6962. > > The solution I propose: > - In the normative section of RFC6962-bis about SCT checking, specify > that TLS clients SHOULD remove the V1 X.509 extension (OID XXX) when > checking V2 Precertificate SCTs. > - In an informal appendix, suggest the following process for issuing an > X.509 certificate that contains valid V1 and V2 SCTs embedded: > (1) Issuer create a valid RFC6962-bis precertificate and submits it to > V2 logs, collecting the returned SCTs. > (2) Issuer embeds the V2 SCTs (as TransItems) into the TBSCertificate > with the V2 X.509 extension. > (3) Issuer then adds the poison extension from RFC6962, signs the > TBSCertificate to produce a valid V1 precertificate, which it then > submits to V1 logs. > (4) Issuer embeds the V1 SCTs in the TBSCertificate and signs it, > producing the final X.509 certificate to be used by the server. > > V1 clients would validate the V1 SCTs and ignore the V2 SCTs. > V2 clients would remove the V1 SCTs and validate the signature over the > resulting TBSCertificate, which would then exclude V1 and V2 SCTs and be > identical to the TBSCertificate in the V2 (CMS) precertificate submitted > to the log. > > Thoughts? > > Eran -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Mar 16 06:26:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D00512D589 for ; Wed, 16 Mar 2016 06:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rylMjOdKN-ME for ; Wed, 16 Mar 2016 06:26:29 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 30BDC12D970 for ; Wed, 16 Mar 2016 06:26:26 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g3so61364199ywa.3 for ; Wed, 16 Mar 2016 06:26:26 -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; bh=cuBXUvgzBf8mODq3UBlRyp71Z+krW1OKpxiqb+O3ayU=; b=OHupIexXDzG0V1Ji0GcAoPs9+1uSkYGv1b+PUaP5CYtZ1ZV9oh2QzbQo8cIu77aQd3 sR4OOUKr8k67IsRCiUv7QidDPluuul4oRfJvzj+3cb2ERiRdINVAmAheCx9XUfHWZ4iQ yzs4CQvqy2IqXJczUe3N7tXDa0MgOqJ+gcwIv2K7PuYqbMv7GUef6i2s6ncPj4OnqnEn KRT0MFxoQ9pYbpvlDN1mqL2x7qXVdZEjcS6r+U+Z+hRdvedrqapUYa2lJwrY4ZK0dOtX BmegN8lX5ZdReEgj2tLx/E6qtyJnmX7wGfrPXNBSGweGC52rAi9dItvpV/GO6UcV2t7h /IRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cuBXUvgzBf8mODq3UBlRyp71Z+krW1OKpxiqb+O3ayU=; b=FhXeRDKEP3jTwS8/hsTGKm60xTfYWucgPqiI5n8JL9n8lyNa4K7QoBq5hb7JbzxBsE RVjnqiZZnqnm0HGQJI7lTr76cXY3UBdUUmTB2VCQzGezDlf7sw/5sO1mWjmsYJRZYbkY 43b+MsxuoLtSUg/5EjouS09n8e9A0zjopxnjvB1Kcqnmq3psuKpWZmjEDtIczOxKwn8q 38xAyukK1oN3lQg4FZzIrlucyrf4+B7hP6/oJMOehE9cysx6zcF1tjhyXWV1iViGUep8 1lO2SWbZYrm9EpgSx5VnX7YvW/aZdeda/BY0bA+8xgABhzH5JdGJQdnM++QXPPAbDC2y l5jw== X-Gm-Message-State: AD7BkJI0QlxbHscl20hNdtEvypyUUWlqN0dm5oRq/EA+louB4fi7ueKcuO9/wZao3+DqUMKochMCphpzSBmX6MnS MIME-Version: 1.0 X-Received: by 10.37.43.87 with SMTP id r84mr1849475ybr.105.1458134785313; Wed, 16 Mar 2016 06:26:25 -0700 (PDT) Received: by 10.37.48.6 with HTTP; Wed, 16 Mar 2016 06:26:25 -0700 (PDT) In-Reply-To: <56E95A7D.5040102@comodo.com> References: <56E95A7D.5040102@comodo.com> Date: Wed, 16 Mar 2016 13:26:25 +0000 Message-ID: From: Eran Messeri To: Rob Stradling Content-Type: multipart/alternative; boundary=001a11352f8aea1039052e2a754b Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 13:26:33 -0000 --001a11352f8aea1039052e2a754b Content-Type: text/plain; charset=UTF-8 Thanks for the feedback, I'll change https://github.com/google/certificate-transparency-rfcs/pull/135 accordingly. (More feedback is still welcome, of course, but I also strongly think it is beneficial). On Wed, Mar 16, 2016 at 1:07 PM, Rob Stradling wrote: > On 16/03/16 12:22, Eran Messeri wrote: > >> How desirable is it for issuers to be able to embed V1 and V2 SCTs in >> the same certificate? >> > > Eran, thanks for thinking this through. I think that this is definitely > desirable, and I like the solution you've proposed. > > If we don't do this, I think it would adversely affect adoption of V2. > Embedding SCTs in certificates is the only SCT delivery mechanism that all > TLS servers support, and few people are going to want to break > compatibility (by embedding only V2 SCTs in certs) with V1 clients that > still have a significant userbase. > > (Pretend for a moment that "V1" is sha1WithRSAEncryption and "V2" is > sha256WithRSAEncryption. Adoption of sha256WithRSAEncryption for > certificate signatures was extremely slow, because (i) the userbase of > clients that only supported sha1WithRSAEncryption was still significant and > (ii) certificates can only have 1 signature). > > > Background: V1 SCTs (RFC6962) and V2 SCTs (RFC6992-bis) are completely >> different and can co-exist for X.509 certificates as they are delivered >> in different OCSP extensions / TLS exetensions. >> >> In the case of precertificates, while in theory V1 and V2 SCTs can be >> independently embedded (as the X.509 extensions to embed each type are >> different), in practice SCTs for V1 Precertificates cover the entire >> TBSCertificate, including the V2 SCTs (otherwise the V1 SCT won't be >> valid) and the same goes for V2 SCTs. >> >> In RFC6962-bis, as it is defined right now, V1 and V2 SCTs for the same >> precertificate cannot be embedded in the same X.509 certificate. >> It seems to me there would be benefit to enabling this combination, as >> that means issuers can issue certificates that would comply both with V1 >> CT clients and V2 CT clients without forcing V2 clients to also >> implement RFC6962. >> >> The solution I propose: >> - In the normative section of RFC6962-bis about SCT checking, specify >> that TLS clients SHOULD remove the V1 X.509 extension (OID XXX) when >> checking V2 Precertificate SCTs. >> - In an informal appendix, suggest the following process for issuing an >> X.509 certificate that contains valid V1 and V2 SCTs embedded: >> (1) Issuer create a valid RFC6962-bis precertificate and submits it to >> V2 logs, collecting the returned SCTs. >> (2) Issuer embeds the V2 SCTs (as TransItems) into the TBSCertificate >> with the V2 X.509 extension. >> (3) Issuer then adds the poison extension from RFC6962, signs the >> TBSCertificate to produce a valid V1 precertificate, which it then >> submits to V1 logs. >> (4) Issuer embeds the V1 SCTs in the TBSCertificate and signs it, >> producing the final X.509 certificate to be used by the server. >> >> V1 clients would validate the V1 SCTs and ignore the V2 SCTs. >> V2 clients would remove the V1 SCTs and validate the signature over the >> resulting TBSCertificate, which would then exclude V1 and V2 SCTs and be >> identical to the TBSCertificate in the V2 (CMS) precertificate submitted >> to the log. >> >> Thoughts? >> >> Eran >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > --001a11352f8aea1039052e2a754b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the feedback, I'll change https://github.= com/google/certificate-transparency-rfcs/pull/135 accordingly.
= (More feedback is still welcome, of course, but I also strongly think it is= beneficial).

On Wed, Mar 16, 2016 at 1:07 PM, Rob Stradling &l= t;rob.stradli= ng@comodo.com> wrote:
On 16/03/16 12:22, Eran Messeri wrote:
How desirable is it for issuers to be able to embed V1 and V2 SCTs in
the same certificate?

Eran, thanks for thinking this through.=C2=A0 I think that this is definite= ly desirable, and I like the solution you've proposed.

If we don't do this, I think it would adversely affect adoption of V2. = Embedding SCTs in certificates is the only SCT delivery mechanism that all = TLS servers support, and few people are going to want to break compatibilit= y (by embedding only V2 SCTs in certs) with V1 clients that still have a si= gnificant userbase.

(Pretend for a moment that "V1" is sha1WithRSAEncryption and &quo= t;V2" is sha256WithRSAEncryption.=C2=A0 Adoption of sha256WithRSAEncry= ption for certificate signatures was extremely slow, because (i) the userba= se of clients that only supported sha1WithRSAEncryption was still significa= nt and (ii) certificates can only have 1 signature).
<= div class=3D"h5">

Background: V1 SCTs (RFC6962) and V2 SCTs (RFC6992-bis) are completely
different and can co-exist for X.509 certificates as they are delivered
in different OCSP extensions / TLS exetensions.

In the case of precertificates, while in theory V1 and V2 SCTs can be
independently embedded (as the X.509 extensions to embed each type are
different), in practice SCTs for V1 Precertificates cover the entire
TBSCertificate, including the V2 SCTs (otherwise the V1 SCT won't be valid) and the same goes for V2 SCTs.

In RFC6962-bis, as it is defined right now,=C2=A0 V1 and V2 SCTs for the sa= me
precertificate cannot be embedded in the same X.509 certificate.
It seems to me there would be benefit to enabling this combination, as
that means issuers can issue certificates that would comply both with V1 CT clients and V2 CT clients without forcing V2 clients to also
implement RFC6962.

The solution I propose:
- In the normative section of RFC6962-bis about SCT checking, specify
that TLS clients SHOULD remove the V1 X.509 extension (OID XXX) when
checking V2 Precertificate SCTs.
- In an informal appendix, suggest the following process for issuing an
X.509 certificate that contains valid V1 and V2 SCTs embedded:
(1) Issuer create a valid RFC6962-bis precertificate and submits it to
V2 logs, collecting the returned SCTs.
(2) Issuer embeds the V2 SCTs (as TransItems) into the TBSCertificate
with the V2 X.509 extension.
(3) Issuer then adds the poison extension from RFC6962, signs the
TBSCertificate to produce a valid V1 precertificate, which it then
submits to V1 logs.
(4) Issuer embeds the V1 SCTs in the TBSCertificate and signs it,
producing the final X.509 certificate to be used by the server.

V1 clients would validate the V1 SCTs and ignore the V2 SCTs.
V2 clients would remove the V1 SCTs and validate the signature over the
resulting TBSCertificate, which would then exclude V1 and V2 SCTs and be identical to the TBSCertificate in the V2 (CMS) precertificate submitted to the log.

Thoughts?

Eran

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


--001a11352f8aea1039052e2a754b-- From nobody Wed Mar 16 06:40:03 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A771E12D50F for ; Wed, 16 Mar 2016 06:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvmaBbZNdlmA for ; Wed, 16 Mar 2016 06:39:59 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 D495912D888 for ; Wed, 16 Mar 2016 06:39:58 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g127so61844796ywf.2 for ; Wed, 16 Mar 2016 06:39: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; bh=ChJWfTq7a2tK5rszGQcQVH7tldxlcfmA+cqpU8zIN9A=; b=DB+9YjCLyCzk+O4ZaVHDHr8KL91fDcujTxd4QfGP3zaKGh+41ObyPbzBlmQU6SBI+q p6JNd5+n8HTKFAVP7D5m67O98E20oS/rQBf468PCxMyrV3NZxtIr94E5ZEQpOayL2HCh jueziooKVDmzZxkj+ksOw0eAlnmQ4phwEB3jWJdIcvQU46QgecoD62TF/Um4xdZ/Pghr GE5DiJAkb4033R++u3OxfCMTMgO7kFVGxbWgXSrC7I12uANsggAy8EUdYX8AqGsGp+Db vtvT2+rYorHMLkw5+hAe66RX7AltWs87vpMlzuWQXA+dpI/TKP9I7vXJqcicYEnQGP0c fH5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ChJWfTq7a2tK5rszGQcQVH7tldxlcfmA+cqpU8zIN9A=; b=IMrY7O+cZhGyYhWYjzesnK0Y6U5U4ExrgpWRJTS06BMszb8G0SWHIwFRY1cu+d4AJ7 ix4RIG+UG09EpisPs3VvUqL1fDfU4Pb/emPynpfW40cE5Bm0S2Axs5YU4wVF2AeQnbXs ULvd/qsLxFuLCyQYTrSdbG1iydL8A9uIMhGCS1bnqGrcgqhnkMnF8TANH9do3mAujzab TnfDHlAGj62ALjUVwRAm5IR7MvmpIvDNbyB6gqOOQpQoUUAnl1sSiSjgufNbvWWfXPow bzcPK954PlGweIQ2WZKsC61Pak81aAJrA5OxPFTqtuCnPOg9cJmNPaboFGhEP1zDhwOh PTsA== X-Gm-Message-State: AD7BkJLs4mHTKNI2Qm9+MzihYrBmpGGmXsxwWwxT0hW7IYbX9lUOVXl2i5Gl6BRZNjw6FGmw9fxnm8ivRGPFXQqL MIME-Version: 1.0 X-Received: by 10.129.33.67 with SMTP id h64mr1863255ywh.83.1458135597734; Wed, 16 Mar 2016 06:39:57 -0700 (PDT) Received: by 10.37.48.6 with HTTP; Wed, 16 Mar 2016 06:39:57 -0700 (PDT) In-Reply-To: <763539E260C37C46A0D6B340B5434C3B0C93C4D1@AEX06.ejsarea.net> References: <56E95A7D.5040102@comodo.com> <763539E260C37C46A0D6B340B5434C3B0C93C4D1@AEX06.ejsarea.net> Date: Wed, 16 Mar 2016 13:39:57 +0000 Message-ID: From: Eran Messeri To: =?UTF-8?Q?Barreira_Iglesias=2C_I=C3=B1igo?= Content-Type: multipart/related; boundary=001a11425f1656c3b9052e2aa67f Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 13:40:01 -0000 --001a11425f1656c3b9052e2aa67f Content-Type: multipart/alternative; boundary=001a11425f1656c3b7052e2aa67e --001a11425f1656c3b7052e2aa67e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 1:36 PM, "Barreira Iglesias, I=C3=B1igo" < i-barreira@izenpe.eus> wrote: > Agreed, but have in mind that there should be a transition period when RF= C > 6962-bis is published because it affects the issuance procedure in the CA > and not all are quick enough to implement and the processing in the log > servers. > Understood. The change mentioned above is about the *ability* to support V1 and V2 simultaneously. The RFC6962-bis deployment timeline would be, I expect, different for each TLS client and is out of scope of the bis document itself. But when the time comes, this change would allow supporting both simultaneously. > > > > > *I=C3=B1igo Barreira* > Responsable del =C3=81rea t=C3=A9cnica > i-barreira@izenpe.eus > > 945067705 > > > > [image: Descripci=C3=B3n: firma_email_Izenpe_eus] > > > > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta > egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbid= ea > gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi > erantzuna. KONTUZ! > ATENCION! Este mensaje contiene informacion privilegiada o confidencial a > la que solo tiene derecho a acceder el destinatario. Si usted lo recibe p= or > error le agradeceriamos que no hiciera uso de la informacion y que se > pusiese en contacto con el remitente. > > > > *De:* Trans [mailto:trans-bounces@ietf.org] *En nombre de *Eran Messeri > *Enviado el:* mi=C3=A9rcoles, 16 de marzo de 2016 14:26 > *Para:* Rob Stradling > *CC:* trans@ietf.org > *Asunto:* Re: [Trans] Co-existence of V1 and V2 embedded SCTs in > certificates > > > > Thanks for the feedback, I'll change > https://github.com/google/certificate-transparency-rfcs/pull/135 > accordingly. > > (More feedback is still welcome, of course, but I also strongly think it > is beneficial). > > > > On Wed, Mar 16, 2016 at 1:07 PM, Rob Stradling > wrote: > > On 16/03/16 12:22, Eran Messeri wrote: > > How desirable is it for issuers to be able to embed V1 and V2 SCTs in > the same certificate? > > > Eran, thanks for thinking this through. I think that this is definitely > desirable, and I like the solution you've proposed. > > If we don't do this, I think it would adversely affect adoption of V2. > Embedding SCTs in certificates is the only SCT delivery mechanism that al= l > TLS servers support, and few people are going to want to break > compatibility (by embedding only V2 SCTs in certs) with V1 clients that > still have a significant userbase. > > (Pretend for a moment that "V1" is sha1WithRSAEncryption and "V2" is > sha256WithRSAEncryption. Adoption of sha256WithRSAEncryption for > certificate signatures was extremely slow, because (i) the userbase of > clients that only supported sha1WithRSAEncryption was still significant a= nd > (ii) certificates can only have 1 signature). > > > > Background: V1 SCTs (RFC6962) and V2 SCTs (RFC6992-bis) are completely > different and can co-exist for X.509 certificates as they are delivered > in different OCSP extensions / TLS exetensions. > > In the case of precertificates, while in theory V1 and V2 SCTs can be > independently embedded (as the X.509 extensions to embed each type are > different), in practice SCTs for V1 Precertificates cover the entire > TBSCertificate, including the V2 SCTs (otherwise the V1 SCT won't be > valid) and the same goes for V2 SCTs. > > In RFC6962-bis, as it is defined right now, V1 and V2 SCTs for the same > precertificate cannot be embedded in the same X.509 certificate. > It seems to me there would be benefit to enabling this combination, as > that means issuers can issue certificates that would comply both with V1 > CT clients and V2 CT clients without forcing V2 clients to also > implement RFC6962. > > The solution I propose: > - In the normative section of RFC6962-bis about SCT checking, specify > that TLS clients SHOULD remove the V1 X.509 extension (OID XXX) when > checking V2 Precertificate SCTs. > - In an informal appendix, suggest the following process for issuing an > X.509 certificate that contains valid V1 and V2 SCTs embedded: > (1) Issuer create a valid RFC6962-bis precertificate and submits it to > V2 logs, collecting the returned SCTs. > (2) Issuer embeds the V2 SCTs (as TransItems) into the TBSCertificate > with the V2 X.509 extension. > (3) Issuer then adds the poison extension from RFC6962, signs the > TBSCertificate to produce a valid V1 precertificate, which it then > submits to V1 logs. > (4) Issuer embeds the V1 SCTs in the TBSCertificate and signs it, > producing the final X.509 certificate to be used by the server. > > V1 clients would validate the V1 SCTs and ignore the V2 SCTs. > V2 clients would remove the V1 SCTs and validate the signature over the > resulting TBSCertificate, which would then exclude V1 and V2 SCTs and be > identical to the TBSCertificate in the V2 (CMS) precertificate submitted > to the log. > > Thoughts? > > Eran > > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > --001a11425f1656c3b7052e2aa67e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 16, 2016 at 1:36 PM, "Barreira Iglesias, I=C3=B1igo&qu= ot; <i-barreira@izenpe.eus> wrote:

Agreed, but have = in mind that there should be a transition period when RFC 6962-bis is publi= shed because it affects the issuance procedure in the CA and not all are qu= ick enough to implement and the processing in the log servers.

Understood.
The change mentioned abov= e is about the *ability* to support V1 and V2 simultaneously.=C2=A0
The RFC6962-bis deployment timeline would be, I expect, different for ea= ch TLS client and is out of scope of the bis document itself. But when the = time comes, this change would allow supporting both simultaneously.=C2=A0

=C2=A0

=C2=A0

I=C3=B1igo Barreira
Responsable del =C3=81rea t=C3=A9cnica
i-barreira@izenpe.eus =

945067705

=C2=A0

3D"Descripci=C3=B3n:

=C2=A0

ERNE! Baliteke mezu hone= n zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzai= lea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak hu= ts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mens= aje contiene informacion privilegiada o confidencial a la que solo tiene de= recho a acceder el destinatario. Si usted lo recibe por error le agradeceri= amos que no hiciera uso de la informacion y que se pusiese en contacto con = el remitente.

= =C2=A0

De: Trans [mailto:trans-bounces@ietf.org] = En nombre de Eran Messeri
Enviado el: mi=C3=A9rcoles, 16 d= e marzo de 2016 14:26
Para: Rob Stradling
CC: trans@ietf.org
Asunt= o: Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates<= u>

=C2=A0

Thanks for the feedback, I&#= 39;ll change https://github.com/google/certificate-tran= sparency-rfcs/pull/135 accordingly.

(More feedback is still welcome, of course, but I also strongly t= hink it is beneficial).

=C2=A0

On Wed, Mar 16, 2= 016 at 1:07 PM, Rob Stradling <rob.stradling@comodo.com> wrote:<= /p>

On 16/03/16 12:22, Eran Messeri wrote:<= /u>

How desirable is it for issuers to be able to= embed V1 and V2 SCTs in
the same certificate?


Eran, thanks for thinking this through.=C2=A0 I think th= at this is definitely desirable, and I like the solution you've propose= d.

If we don't do this, I think it would adversely affect adopti= on of V2. Embedding SCTs in certificates is the only SCT delivery mechanism= that all TLS servers support, and few people are going to want to break co= mpatibility (by embedding only V2 SCTs in certs) with V1 clients that still= have a significant userbase.

(Pretend for a moment that "V1&qu= ot; is sha1WithRSAEncryption and "V2" is sha256WithRSAEncryption.= =C2=A0 Adoption of sha256WithRSAEncryption for certificate signatures was e= xtremely slow, because (i) the userbase of clients that only supported sha1= WithRSAEncryption was still significant and (ii) certificates can only have= 1 signature).

=C2=A0

Background: V1 SCTs (RFC6962) = and V2 SCTs (RFC6992-bis) are completely
different and can co-exist for = X.509 certificates as they are delivered
in different OCSP extensions / = TLS exetensions.

In the case of precertificates, while in theory V1 = and V2 SCTs can be
independently embedded (as the X.509 extensions to em= bed each type are
different), in practice SCTs for V1 Precertificates co= ver the entire
TBSCertificate, including the V2 SCTs (otherwise the V1 S= CT won't be
valid) and the same goes for V2 SCTs.

In RFC6962-= bis, as it is defined right now,=C2=A0 V1 and V2 SCTs for the same
prece= rtificate cannot be embedded in the same X.509 certificate.
It seems to = me there would be benefit to enabling this combination, as
that means is= suers can issue certificates that would comply both with V1
CT clients a= nd V2 CT clients without forcing V2 clients to also
implement RFC6962.
The solution I propose:
- In the normative section of RFC6962-bis = about SCT checking, specify
that TLS clients SHOULD remove the V1 X.509 = extension (OID XXX) when
checking V2 Precertificate SCTs.
- In an inf= ormal appendix, suggest the following process for issuing an
X.509 certi= ficate that contains valid V1 and V2 SCTs embedded:
(1) Issuer create a = valid RFC6962-bis precertificate and submits it to
V2 logs, collecting t= he returned SCTs.
(2) Issuer embeds the V2 SCTs (as TransItems) into the= TBSCertificate
with the V2 X.509 extension.
(3) Issuer then adds the= poison extension from RFC6962, signs the
TBSCertificate to produce a va= lid V1 precertificate, which it then
submits to V1 logs.
(4) Issuer e= mbeds the V1 SCTs in the TBSCertificate and signs it,
producing the fina= l X.509 certificate to be used by the server.

V1 clients would valid= ate the V1 SCTs and ignore the V2 SCTs.
V2 clients would remove the V1 S= CTs and validate the signature over the
resulting TBSCertificate, which = would then exclude V1 and V2 SCTs and be
identical to the TBSCertificate= in the V2 (CMS) precertificate submitted
to the log.

Thoughts?
Eran

=C2= =A0

--
Rob Stradling
Senior Research & = Development Scientist
COMODO - Creating Trust Online=

=C2=A0<= /p>


--001a11425f1656c3b7052e2aa67e-- --001a11425f1656c3b9052e2aa67f Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 6f56ed3163291681_0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABjAk0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3LVdV tNGsHvLxysakKqqNzOx4CqByWJ4AFYsdp4i10ede3j6JaNylpabWuCP9uQghT7KOPWizjGu+L7u+ m+e00dvs1qh6GcqDJJ9QGCD0+b1rp60+D1M17+vQ54eDrHHz3+syN3ZtUnyfyYCl/wCEO0//AJ/N X/8ABpcf/F1dm8RaLbzPDNqtmkqHDI0ygqfQ81et7mC7gSe2mSaFxlXjYMD9CKhVW9maSw3KryjZ ehif8Idp/wDz+av/AODS4/8Ai6P+EO0//n81f/waXH/xddBRVe0l3I9nDsc//wAIdp//AD+av/4N Lj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX /wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJ dw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8A P5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T /wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAX XQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8A CHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4 uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDB pcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9n Dsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q/ /g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn 81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUU e0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf /wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/h DtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc/ /wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0u P/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/ AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3 D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/ mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/ AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABdd BSEhQSSAB1Jo55dw9nDsYH/CHaf/AM/mr/8Ag0uP/i6P+EO0/wD5/NX/APBpcf8AxdbX2u2/5+Iv ++xR9rtv+fiL/vsUc8+4uSHZGL/wh2n/APP5q/8A4NLj/wCLo/4Q7T/+fzV//Bpcf/F1tfa7b/n4 i/77FH2u2/5+Iv8AvsUc8+4ckOyMX/hDtP8A+fzV/wDwaXH/AMXR/wAIdp//AD+av/4NLj/4utr7 Xbf8/EX/AH2KlBDAEEEHoRRzz7h7OHYwP+EO0/8A5/NX/wDBpcf/ABdNbwhAvNrq+t20g6MuoSSf mrlgfyroqKPaS7j9nDscs+p6v4ZYHXHS/wBKJAOoxR7Hg95UHG3/AG16dwOtdQjq6K6MGVhkEHII pHRZEZHUMjAhlYZBHoa5bQriLw9eahoF1MEtbUpNYtIf+WEm7Cf8BZXA9ttP4ldbivyOz2LXg4D+ y71/4n1O8Zj6nz3H8gK6Guf8Hf8AIIuv+wlef+j3roKVT4mOn8CPnHVCF1i+VsAi5kyD1+8a9f8A huCPBMBwQDJKR/30a6eSws5XLyWkDuerNGCT+lTIiRRhUVURRgADAArio4d0581z3cfmyxVBUVC1 muvkef8A2qO40qS5S9Kz22lgOftTBpZ2iB5Gf4Vwc46t6irGp3MthG09tOqwRWM5lS3uGlTDFRvD HncpwfYZrqLK40jU2aS0+zTMoBJCDOCODyOhGeehq6Ire3iIEcUcffCgDmvQdSz2PnVSutGcVdw3 v2PUr8TeVFHNNG7G6fMn7wKAR0QD1HP611ulKi2CBPKxk/6mYyr17MeTVto0KMrIpQ/eBHBqnp1/ p92JI7B0IiOHVEKhT6dBzUyk5LY0jBRluXqKKZHNHMGMbhgrFDjsR1FZmg+imSzRwBTK4QMwRc92 JwBSTzR28LTSnaiDJOCf5UBckoqCzvbe/g861lEke4qSOxBwR9QanoC9wooooAKKKqyalZQ3aWkl 1Elw5AWNmwST0AotcTaW5aopkcscwJjdXCsVJU5wR1FEsscMZkldUQdWY4AoGPoqut9atNcQiZfM t1DSqeNoIyD9OD+VQ2ms6dfMq213HIzHCrnBPG7ofbmnZi5l3L1FFIrB1DKQVIyCDkEUhi0UUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAZHifxBbeGNBuNUuRvEYCxxg4Mjn7q/wCe2a+b9f8AFWseJbtptRvHZCcr AhKxoPQL/U816l8cZXXSNIiDHY9w7MPUheP5mvItH0i813VbfTbGMPcTthcnAA6kk9gBzXp4SEYw 52eRjqk5VPZooYHpRgelevP8ItD06KNdX8Ui3ncZwTHGp+m45NRzfB+wvrCSbQPESXcqdAxR0J9C ydP1rX6zT7mH1Or2/E8lwPSjA9KvwaNqFxra6NHbN/aBmMHknghwcHPsOefSvTh8INJ0+1ibW/Ey 20z+myNM+gLnJrSdaELXZnToVKl7LY8iwPStzw94s1nwzdpNp92/lA5e3kYtE49Cvb6jmvQT8INJ 1C1lbRPEy3EyDvskTPYEocivLNR0+50rUbiwvIzHcwOUkXrg+x7jvmlGpTq3Q5U6tFqR9ReHNetv EuhW2qWoKpMvzITko44ZT9DWrXl3wQldvD+pxE5RLsFR6EoM/wAq9RryKsFCbij3KE3OmpMK8Z+N U8trq+lPC5RngcMR3Abj+Zr2avFfjl/yE9H/AOuMn/oQrXCfxUZY3+Cz0rwd/wAgi6/7CV5/6Peu grn/AAd/yCLr/sJXn/o966CsanxM3p/AgpHBKMB1IpaR3VEZ2OFUZJ9BUFnCW+j6xHaQhY72NFgh iuQ7oZG2A/LHhh8gJyQSM9u9S3mmavcNLDJbXU0H2by2LSjMxAQqW+fG7KuOABnuc5rcTxGn2Oe5 ksp18uFbhEXDM8TZw3Xjocg9Kfd+IIrK4lEsEn2aFjG84IwJNm/bjr0xz6kCt+ad9jm5IW3ItLtr 6PVpJJUuEjxL5jSS7kky4MW0ZONqZB4H49ao3unakGuTHDcMsk87xiGYIQ5VBG55HyghuPccGrdz 4o+xxH7RYSJcK+1ojIvA27hhuhJHAXqSCO2avX+sLp7sJIHIFq9wpzgsVIBTHr8wqfeTvYq0GrXM VdK1eO7FzuneUSBzm5IRj57Z4zgDyyBjHA96rW9nrShWa1uty3AeOBpf3eCq7snzCwwwbByep45r eh8R2LectxIIZIQpkGdwyWZQAR94/KeBUza3Y+esUVzDI2Rvw4+VShcH3yBnHXBzT5pdg5IdzK1u w1G61VWhilkAMTW8gkxHCQSWLLnk529j+lO0+HVdP8PXbIl5PfHHlx3DISHwASPmORnLcnnnHWt6 1u4L2ATW8gkjJIyOxBwQR2NVbzUZIb6KztrdZpmQyvvk2KiZA64OSSeB7HkVPM/hsU4RT5rmItvq MKRQWVpfRw7YEBkkQEFZd0jthurA9uvNQQ6XrNpEJES5mk8vaySXTMGzCu7+Lr5mTxjnuBzXRvrW nRmQNdIGjcIy4Oc89BjJ6Hp6H0NMi1/TZN2bgIRO0GHBGWUgH8ORz05FVzS7EuEO5hQaZq0lhdeY bxJlhaK2zPtIzK5yMMcHYUGSSRjGeKNSttVj1GU20csNokRi8wXGAybVI+Zn4bhwDgYJBJ5retda s7maG386NbqVS6xBt2QOuD0NaDosiFHUMrDBBGQRSc2nqhqnFrRnFWY1Kd7aS1huTbw3rbW87eRG JiGUkvjAXHZs8jIxXTz28tzrFszri1tkMgOfvSn5Rx7Lu/76HpV2ONIo1jjRURRgKowAPpTqmU7s qNOy3M3TbOW0tLqJESAtcSvF8oKgMxIOAR9ccUmq2U15octu6x3FwVBGE2gsCDkAk4/OtOilzO9y uVWsZsukwRjULi3jb7TdRFWy5IY4OOCcDrWJLod5aWtlPAk13dpDsmMsoyAIyoUbSvALN0IyT171 1tFNTaFKnFnIWmmatIiGcXQMTIkYefA2efJuyAxz+6Kjkk9uop2lWep217pK/Y54beCFYZP3m4Ff LIO7LkcPjgL0wc9h1tFN1G7kqklbUKKKKzNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiqGt6vbaDot3ql2SIbaMuQOrHsB7k4H40AV/EPif SfC9j9r1W6WJTwiDl5D6KveuIPxM8Q6jH9o0PwRf3Fp/DNKSNw9QAP6ms7wLoM/jnV5vGfiZRPH5 hSytWGYwAeuP7o6D1OSa9fAAAAGAOgFLcZ5hoPxZudS1Y6Xe6C1vedoRPtdj/dCuBlvbIz2r0DS9 ZstYjka0kPmRNsmhkUpJE3oynkGvPvjVY20fh201iNVj1K2ukWKZeGwcnGe+CAfbFc3rvjy+TxRp +o6fGq3ENlGJTtwszMoZlc9xk4Hp1qJT5Nzow+HlXk4x/r/h2e6UVz/gu+1TU/DNtfas9tJPPmRW tzkbSeARgYI6Y56da6CtE76nO04uz3PJ/jl/yDtG/wCu0n/oIrifhomsv4nlOhGxF4LViTehigTc ucbec9P1rtvjl/yDtG/67Sf+giuQ+Eup22neOEW5cRrdQNAjMcDeSCB+O3H1Ir06V/q2nmePWt9b V/I39c+F3i7xDq82p39/pTTy4BCvIFUAYAAK8Ctv4f8Aw91vwl4gkvLq8tGtZIGjeOB2JY5BBIKg cYP51neNfBvjS48S3N5ot5czWVwQ6ol6Y/KOACuCwGMjPHrWj8O/C3inS9Wm1HxDeTrAsJRIJLoy 7iSPmPJAAA/Ws5TbpfEvQ1hTSrfA733NG18EX8HxTn8TmS1+xSBtsYJ8wExhc4xjrnv3rG8c/DbX fFPiibUbe8sxbGNEiSZ3ygA5GApA5yfxrI0/xlHJ8ZZLhtSm/smWZoIwZj5Wdm0NjOMFh1981r+P /CXi++8RPqGg3dw9rMigwx3Zi8tgMHgkDBxnj3pLnhNXdtBvknTlyxb16fmHgb4ba74W8UQ6lcXl mbYRukqQu+XBHAwVAPOD+FcZ8W1C/EG6IGC0ERPv8uP6V0vhf4feLLq/ZvEWp6jaWSqcLFfkyO3b GCQB9a4DxnHZQeKry30+8uby3hIj8+4l81mYD5vm7gHI/CtqWta/Nd26GFb3aHLy2V+p6d8D/wDk C6t/18r/AOgCvVK8r+B//IF1b/r5X/0AV6pXFif4rPQwn8GIV4r8cv8AkJ6P/wBcZP8A0IV7VXiv xy/5Cej/APXGT/0IVWE/ionG/wAFnpXg7/kEXX/YSvP/AEe9dBXP+Dv+QRdf9hK8/wDR710FY1Pi ZvT+BBTXRZI2RhlWBBHtTqZKZBC/lBTJtOzd0z2zUFmPD4fKWlxDNdmRpLZbWNxHt2RrnGRnlueT xnA4FLe+Hlvp5hJckWkz+a8ITnzNmzIbPTGDjHUde1ZUXi27mgmnW1hEcQRmyTyrkIn/AI+HB9hR J4uu4baG4ktYRHIGJAJyBGdsv5MRituWpc5+elYu3PhiW73yT30ctxLlZGe3BQjaFBC7uGGCQcnl jxzWhe6NHeJYKZnX7JKr7j8xkUDlWPvwT9Kz77WTaMsrTQq62jl2BLoJQ6KUChgCcnaMnIP41Ani DUxexW8kNkdkCvOyyABmKsTsy2SAVA4BzzyMUWm9R3pp2sW08OywSrLBfBZEYSIXh3ANmTqMjIxK wxx0Bz2oHhlY9PW1gvZYiknmLKqjcD5Plf8A1/0rPHiXUBbxeY9hFI+GMjqwQAwGXGN3XIxnPTnF W7HxDdXWpus0Fvb2caZkMsoV0/dq+cE5x8xHQcDOe1DU9xJ09i7YaHHa6dPZ3EgmSaZpTsBjxkg4 HzE9R60zWNAGqH5JxDuhMEgaISBkyCCMnhgRweep9sUJ/El9Hd6htgthb2xZRvkG/goNxGc4IYno MDByc1KviGZ7uDBtxaPcyQGRfnJIk2KANwIB/vAEZ7Ac0rTvcfNTtyjW8LTNJcSHUA8koUCSSEl0 IZyGDBwQw3kZGBx061KfDAa6SZ54pirucT24f5WKse+N2V69OenFdBRU+0kX7KHYxtM0SbTrtZDe LNEkQiRWhwyL1ODuxyeTxzgegrZooqW23dlxioqyCiiikMKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8V8TeC/FWg 38up2V/qOs6aztJJCl3JHMgPP8J5x6j8q43xJr2nalocENhe68Lgy/6Ta6hdmWNQBwR6nPrz7V9O V5d8XfB9rc6FJrtjZIt9buHuHjXBki6EkDqRwc9cA1LQ7kfhvxhbrHZaXp2q6fZafbwpGDOyggAc scn7xJJx6/Q566/+InhPTo2aXW7aRh/BAfMY/QLmvHvCfw1tvGOiLfWWuCK4RtlxbyQbvLbtgg8g jkV1+mfAzT4ZFfUtWnuVHWOGMRA/jkn+VCuN2MHVtWv/AIveJ7TStOt5LfR7V98juOVHQu3YHHCr 71m+L9POl+LdRtdhSMOGiH+wVG3/AA/CvetI0XTtCsVs9MtI7aBedqDkn1J6k+5rk/iboGn3mhy6 zPcpaXFjGSJWHEi/3D7k9Pc1lXpuUdNz0cqxcMPW9/ZqwvwnuHl8IvExJEN06r7AgN/Mmu6rkvht pz6f4LtGkUrJdE3JVhggN93/AMdArraukmoJM5sdOM8TOUNrnk/xy/5B2jf9dpP/AEEV4vXtHxy/ 5B2jf9dpP/QRXk+mRo8OpF3ZSlkzLhtu4704Pr1PFe1hXaij5nGK9dr+tjRt/Hfiq1gWGLXbsRoM KGIYgfUgmor/AMZ+JNUtWtbzWbqWBxho9wUMPQ4AyKs6hpaWGhs82kD7W8asJIpXKQLxy5LEFj/d HAzzzxVy50TSoop/Lgle3S3LpdKrctsyG3l9hBbtt9utafu97EWq2tzHHVv2fjfxPYWyW9trd2kK DCqWDYHoCwPFPgh0pLvR7OSwjkF5FCbidrhwys7EEjBwuBjqDRDpYGi2lzb6T9vllkmWRjI+AFYB cKpGOp5qpOL3REYzj8LGXfjfxPfWz29xrd20TjDKrBcj0JUA1gV1cOjaWbvVUjVrhreaNIYRmXCl SWPyMpbDALnOPzrH121trTUFjto3jUwozo/8LkcgDJIHQ4JyM0Qcb2igqRna8nc9Z+B//IF1b/r5 X/0AV6pXlfwP/wCQLq3/AF8r/wCgCvVK8rE/xWe1hP4MQrxX45f8hPR/+uMn/oQr2qvFfjl/yE9H /wCuMn/oQqsJ/FRON/gs9K8Hf8gi6/7CV5/6PeugrnPCrfZrvXNLk4lt9QkmUesc37xT+ZYf8BNd HWNT4mb0/gQUUUVBY3y0AxsXB7YoMaEYKLjnt69adRQBG8EMilXiRlPUFQQec0gtoFKFYIwUBCYQ fKD1A9KloouFircada3M1vLLECYGLIMDGdu3kfQ1OYYmkMhiQuV2lioyV9M+lPop3YrIjMEJdnMS FnXax2jJHofakFtApjIhjBjzsIQfL9PSpaKVx2CiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACm uiyxtG6hkYEMpGQQexp1FAHjureDde8A66/iDwcrXNi2fOseWKr1K4/iX0I5Fa9r8atCkjjF1a3V rOFczxuPuEDgD1JPA6e+K9IlVnidEcxsykBwMlT681zi+AfDrFHurBLyRYyrPcfOXYnczt6sT1Pt gYpWGZNx8XPCtrYRzPdma6ZATa2ymQhsfd3YA9s1l2ema38SdTt9S8QWr6d4dtnElvpzZ33Ddmf2 /wAj1ruLDwp4f0uQSWWj2UMgOQ6wjcPoeorYosAgAUAAAAcACloopiPMvjXYS3HhuxvY1JS1uMSY 7BxgH8wB+NeGV9c3tnb6jZTWd3EstvMhSRG6MDXifiD4N6ta3LyaHLHeWpOVjlcJKg9CTwfrkfSv QwteKjyS0PLxuGnKXPBXPMcAdhRgeldd/wAKx8Y/9AZv+/8AH/8AFUf8Kx8Y/wDQGb/v/H/8VXZ7 Wn/MvvOD2NX+V/cclUkk8ssEMDtmKHd5a4+7uOTXU/8ACsfGP/QGb/v/AB//ABVH/CsfGP8A0Bm/ 7/x//FUe1p/zIPY1f5X9xyWB6UdK63/hWPjH/oDN/wB/4/8A4qui8O/BrVLm6STXpY7S1U5aGJw8 j+2Rwv15pSr04q9yo4erJ2UWdR8F9PltvClzdyKVW7uS0ee6qAufzz+Vek1DaWsFjaRWtrEsUEKB I0UcKo6Cpq8epPnm5Hu0oezgo9grxX45f8hPR/8ArjJ/6EK9qrzrxT4bXxx4ouLdXAj0uGONmPTz H3Mw/Bdh/GtMNJRqcz2RlioudPlW7Ol13TryK+g17SIxJf26GKa3LbRdQ5yUz2YHlT65B4NXtI12 w1uFmtJT5sZxNbyDZLC3o6HkH/IrSrK1Tw3pOsSpPd2g+0oMJcRMY5V+jqQ34ZrNNNWkbOLTvE1a K5z/AIRHbwniHX1XsPtu7H4lSaP+ETb/AKGPX/8AwLX/AOJo5Y9xc0v5To6K5z/hE2/6GPX/APwL X/4mj/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0f8Im3/Qx6/8A+Ba/ /E0cse4c0v5To6K5z/hE2/6GPX//AALX/wCJo/4RNv8AoY9f/wDAtf8A4mjlj3Dml/KdHRXOf8Im 3/Qx6/8A+Ba//E0f8Im3/Qx6/wD+Ba//ABNHLHuHNL+U6Oiuc/4RNv8AoY9f/wDAtf8A4mj/AIRN v+hj1/8A8C1/+Jo5Y9w5pfynR0Vzn/CJt/0Mev8A/gWv/wATR/wibf8AQx6//wCBa/8AxNHLHuHN L+U6Oiuc/wCETb/oY9f/APAtf/iaP+ETb/oY9f8A/Atf/iaOWPcOaX8p0dFc5/wibf8AQx6//wCB a/8AxNH/AAibf9DHr/8A4Fr/APE0cse4c0v5To6K5z/hE2/6GPX/APwLX/4mj/hE2/6GPX//AALX /wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0f8Im3/Qx6/8A+Ba//E0cse4c0v5To6K5z/hE 2/6GPX//AALX/wCJo/4RNv8AoY9f/wDAtf8A4mjlj3Dml/KdHRXOf8Im3/Qx6/8A+Ba//E0f8Im3 /Qx6/wD+Ba//ABNHLHuHNL+U6Oiuc/4RNv8AoY9f/wDAtf8A4mj/AIRNv+hj1/8A8C1/+Jo5Y9w5 pfynR0Vzn/CJt/0Mev8A/gWv/wATR/wibf8AQx6//wCBa/8AxNHLHuHNL+U6Oiuc/wCETb/oY9f/ APAtf/iaP+ETb/oY9f8A/Atf/iaOWPcOaX8p0dFc5/wibf8AQx6//wCBa/8AxNH/AAibf9DHr/8A 4Fr/APE0cse4c0v5To6K5z/hE2/6GPX/APwLX/4mj/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/ AAibf9DHr/8A4Fr/APE0f8Im3/Qx6/8A+Ba//E0cse4c0v5To6K5z/hE2/6GPX//AALX/wCJo/4R Nv8AoY9f/wDAtf8A4mjlj3Dml/KdHRXOf8Im3/Qx6/8A+Ba//E0f8Im3/Qx6/wD+Ba//ABNHLHuH NL+U6Oiuc/4RNv8AoY9f/wDAtf8A4mj/AIRNv+hj1/8A8C1/+Jo5Y9w5pfynR0Vzn/CJt/0Mev8A /gWv/wATR/wibf8AQx6//wCBa/8AxNHLHuHNL+U6Oiuc/wCETb/oY9f/APAtf/iaP+ETb/oY9f8A /Atf/iaOWPcOaX8p0dFc5/wibf8AQx6//wCBa/8AxNH/AAibf9DHr/8A4Fr/APE0cse4c0v5To6K 5z/hE2/6GPX/APwLX/4mj/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0 f8Im3/Qx6/8A+Ba//E0cse4c0v5To6K5z/hE2/6GPX//AALX/wCJo/4RNv8AoY9f/wDAtf8A4mjl j3Dml/KdHRXOf8Im3/Qx6/8A+Ba//E0f8Im3/Qx6/wD+Ba//ABNHLHuHNL+U6Oiuc/4RNv8AoY9f /wDAtf8A4mj/AIRNv+hj1/8A8C1/+Jo5Y9w5pfynR0Vzn/CJt/0Mev8A/gWv/wATR/wibf8AQx6/ /wCBa/8AxNHLHuHNL+U6Oiuc/wCETb/oY9f/APAtf/iaP+ETb/oY9f8A/Atf/iaOWPcOaX8p0dFc 5/wibf8AQx6//wCBa/8AxNH/AAibf9DHr/8A4Fr/APE0cse4c0v5To6K5z/hE2/6GPX/APwLX/4m j/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0Hwdby/Ld6xrd1Eescl8y qfrs25otHuHNPt+JJq/iMQ3DaVo6LfaywwIlOUt/9uZh91R6dT0Aq7oWkLoumi381p53dprm4YYa aVuWY/0HYADtU+naXYaRai20+0htoc52xrjJ9T6n3NW6TkrWQ1F35pBRRRUlhRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFAH//Z --001a11425f1656c3b9052e2aa67f-- From nobody Wed Mar 16 07:58:27 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B9112D989 for ; Wed, 16 Mar 2016 07:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pqu8rbwd5SD for ; Wed, 16 Mar 2016 07:58: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 3E3FE12D9AD for ; Wed, 16 Mar 2016 07:58:19 -0700 (PDT) Received: from localhost ([::1]:34765 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agCtu-0004j7-Ks; Wed, 16 Mar 2016 07:58: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, eranm@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 14:58:18 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/153#comment:1 Message-ID: <080.6165930780d930acfea0ff7782db4cfb@tools.ietf.org> References: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <065.3de457ef6eb3dbd65bcf5150524add75@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: <20160316145819.3E3FE12D9AD@ietfa.amsl.com> Resent-Date: Wed, 16 Mar 2016 07:58:19 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #153 (rfc6962-bis): Finish documenting support for RFC6962 (v1) structures in TransInfo X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 14:58:27 -0000 #153: Finish documenting support for RFC6962 (v1) structures in TransInfo Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/135 In short: - Removed all v1 structs because I didn't see a compelling reason to keep them. - Explained V1/V2 interoperability. - Specified a way for V1 and V2 SCTs to co-exist in a certificate. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:09:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D1912D59E for ; Wed, 16 Mar 2016 08:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfKOQtE2emRx for ; Wed, 16 Mar 2016 08:08: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 64DC512D9A1 for ; Wed, 16 Mar 2016 08:08:23 -0700 (PDT) Received: from localhost ([::1]:36546 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agD3f-0003e4-0N; Wed, 16 Mar 2016 08:08: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: eranm@google.com, hadfieldp@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:08:22 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/118#comment:3 Message-ID: <068.0779562256ffb55d064ab4f9e5d0a31c@tools.ietf.org> References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-Trac-Ticket-ID: 118 In-Reply-To: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:09:02 -0000 #118: Monitor function description problem Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com Comment: Is the problem here that the term 'monitoring' means something different in this context, making the introduction and Section 9.3. inconsistent? I can suggest a few resolutions: (1) Replacing the word 'monitor' in the introduction with 'watch'. (2) Modify the Monitor section to indicate a monitor can either ensure logs behave correctly, watch for certificates of interest or do both. From what Steve says, it seems the term 'monitor' in CT context is used to refer both to monitors that audit logs and ones that just watch for certificates of interest, so option (2) seems more reasonable to me. -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:10:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6508012D59E for ; Wed, 16 Mar 2016 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plyt0hz8B3Wj for ; Wed, 16 Mar 2016 08:10: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 4751712D532 for ; Wed, 16 Mar 2016 08:10:25 -0700 (PDT) Received: from localhost ([::1]:37298 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agD5d-0005Lj-4a; Wed, 16 Mar 2016 08:10: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: eranm@google.com, hadfieldp@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:10:25 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/118#comment:4 Message-ID: <068.77d9bbd310d1827183c97f97b5ebdbf7@tools.ietf.org> References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-Trac-Ticket-ID: 118 In-Reply-To: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, hadfieldp@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:10:33 -0000 #118: Monitor function description problem Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/136 -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:13:44 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7950012D8A8 for ; Wed, 16 Mar 2016 08:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DYzrZtv0Gv0 for ; Wed, 16 Mar 2016 08:13:39 -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 92C2B12D97C for ; Wed, 16 Mar 2016 08:12:58 -0700 (PDT) Received: from localhost ([::1]:37933 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agD84-00089D-TY; Wed, 16 Mar 2016 08:12:56 -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: kent@bbn.com, eranm@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:12:56 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/124#comment:1 Message-ID: <068.e6ac6e97a6d438af90b2602573f97ae8@tools.ietf.org> References: <053.d435128a5d6cc5448161942e0b2eaade@tools.ietf.org> X-Trac-Ticket-ID: 124 In-Reply-To: <053.d435128a5d6cc5448161942e0b2eaade@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: kent@bbn.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #124 (rfc6962-bis): introduction needs work X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:13:43 -0000 #124: introduction needs work Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => kent@bbn.com Comment: Steve, can you please point out particular text in the introduction that is less clear than text used in the architecture document? Will be happy to re-use some text from that document, but for me the introduction is pretty straightforward (which isn't surprising given my familiarity with the topic. A fresh opinion would help here). -- --------------------------+--------------------------- Reporter: kent@bbn.com | Owner: kent@bbn.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+--------------------------- Ticket URL: trans From nobody Wed Mar 16 08:18:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699DC12D97C for ; Wed, 16 Mar 2016 08:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux13vvydOWLN for ; Wed, 16 Mar 2016 08:18: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 187CA12DA08 for ; Wed, 16 Mar 2016 08:17:05 -0700 (PDT) Received: from localhost ([::1]:38500 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDC4-000389-FS; Wed, 16 Mar 2016 08:17: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: eranm@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:17:04 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/131#comment:1 Message-ID: <076.1a07c2c799065f85fdb0ca2ab41767e0@tools.ietf.org> References: <061.a402b343ec62e8c46fdf8f5ebd7a8dc0@tools.ietf.org> X-Trac-Ticket-ID: 131 In-Reply-To: <061.a402b343ec62e8c46fdf8f5ebd7a8dc0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #131 (rfc6962-bis): missing guidance for TLS servers to select logs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:18:31 -0000 #131: missing guidance for TLS servers to select logs Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com Comment: Out for review https://github.com/google/certificate-transparency- rfcs/pull/137, adopting David's suggestion. -- ----------------------------------+------------------------------- Reporter: david@mandelberg.org | Owner: eranm@google.com Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ----------------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:19:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66C12D9F4 for ; Wed, 16 Mar 2016 08:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5yY9h9vp_SM for ; Wed, 16 Mar 2016 08:19: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 332C412D56A for ; Wed, 16 Mar 2016 08:18:41 -0700 (PDT) Received: from localhost ([::1]:38765 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDDc-00082x-VP; Wed, 16 Mar 2016 08:18: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: mhs@google.com, eranm@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:18:40 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/132#comment:2 Message-ID: <076.8e68d5df046c7e08d91361d86f2aadd3@tools.ietf.org> References: <061.3cb1275ccf9a2813644b1e30ff83a68f@tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <061.3cb1275ccf9a2813644b1e30ff83a68f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mhs@google.com, eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #132 (rfc6962-bis): unclear motivation for and handling of re-logging entries from a frozen log X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:19:47 -0000 #132: unclear motivation for and handling of re-logging entries from a frozen log Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => mhs@google.com * milestone: => review Comment: Melinda/Paul, please review the fix. -- ----------------------------------+----------------------------- Reporter: david@mandelberg.org | Owner: mhs@google.com Type: enhancement | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ----------------------------------+----------------------------- Ticket URL: trans From nobody Wed Mar 16 08:21:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAB112D9EC for ; Wed, 16 Mar 2016 08:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbli-dId42lP for ; Wed, 16 Mar 2016 08:21: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 DD05612D9A8 for ; Wed, 16 Mar 2016 08:20:20 -0700 (PDT) Received: from localhost ([::1]:39038 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDFE-0004LH-Of; Wed, 16 Mar 2016 08:20:20 -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: Wed, 16 Mar 2016 15:20:20 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/144#comment:3 Message-ID: <068.33d7a4a06e95920bdf566da09988942a@tools.ietf.org> References: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-Trac-Ticket-ID: 144 In-Reply-To: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #144 (rfc6962-bis): Need to specify how the CA requirements in 12.3 are to be met X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:21:47 -0000 #144: Need to specify how the CA requirements in 12.3 are to be met Changes (by eranm@google.com): * milestone: => review Comment: Merged in https://github.com/google/certificate-transparency- rfcs/commit/1049bc98995aaf10f7dff01bf6ba5728b49ce0aa, please review. -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:22:27 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FEC12D53C for ; Wed, 16 Mar 2016 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UfEwKa9MHUt for ; Wed, 16 Mar 2016 08:22:13 -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 B162112D9D0 for ; Wed, 16 Mar 2016 08:21:17 -0700 (PDT) Received: from localhost ([::1]:39240 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDG8-0006Sw-Vt; Wed, 16 Mar 2016 08:21:16 -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, david@mandelberg.org X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:21:16 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:6 Message-ID: <068.3007130b90e14576436448b6dd5862c4@tools.ietf.org> References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, david@mandelberg.org, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:22:19 -0000 #145: Section 9.2 (TLS clients) needs more guidance for browsers Changes (by eranm@google.com): * milestone: => review Comment: Merged as https://github.com/google/certificate-transparency- rfcs/commit/0dfa4a4f30fbfedd259eceae5a067f60904fae65 Please review. -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From i-barreira@izenpe.eus Wed Mar 16 06:36:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F3D12D50A for ; Wed, 16 Mar 2016 06:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id queTyjzriHUg for ; Wed, 16 Mar 2016 06:36:09 -0700 (PDT) Received: from correo.euskaltel.es (ektmail2mta2.euskaltel.es [212.55.8.119]) by ietfa.amsl.com (Postfix) with ESMTP id 66E4912D532 for ; Wed, 16 Mar 2016 06:36:08 -0700 (PDT) Received: from EG5500-LK.ejie.dmz ([194.30.48.226]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0O44004JPWG7Z760@ektmail2mta2.euskaltel.es> for trans@ietf.org; Wed, 16 Mar 2016 14:36:07 +0100 (MET) Received: from ejlp024.ejgv (unknown [10.254.128.49]) by EG5500-LK.ejie.dmz with smtp id 21c8_f471_a52e9708_971a_4019_ac01_7954616a3bf5; Wed, 16 Mar 2016 14:36:06 +0100 Received: from AFE03.ejsarea.net (afe03 [10.200.192.20]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id u2GDa6K5005174; Wed, 16 Mar 2016 14:36:06 +0100 Received: from AEX06.ejsarea.net ([10.200.198.15]) by AFE03.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2016 14:36:06 +0100 Date: Wed, 16 Mar 2016 14:36:06 +0100 From: =?utf-8?B?IkJhcnJlaXJhIElnbGVzaWFzLCBJw7FpZ28i?= In-reply-to: To: Eran Messeri , Rob Stradling Message-id: <763539E260C37C46A0D6B340B5434C3B0C93C4D1@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/related; boundary="Boundary_(ID_6G0gAlZnwVQhCyXAxYXcfw)"; type="multipart/alternative" Content-class: urn:content-classes:message Thread-topic: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates Thread-index: AdF/h3kTwA+EAQQnTJ+Oh0W6yyAFewAALilg X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <56E95A7D.5040102@comodo.com> X-OriginalArrivalTime: 16 Mar 2016 13:36:06.0844 (UTC) FILETIME=[CAFEEFC0:01D17F88] Archived-At: X-Mailman-Approved-At: Wed, 16 Mar 2016 08:26:41 -0700 Cc: trans@ietf.org Subject: Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 13:37:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6G0gAlZnwVQhCyXAxYXcfw) Content-type: multipart/alternative; boundary="Boundary_(ID_m2+QzdQCB7PzTFkIYou01g)" --Boundary_(ID_m2+QzdQCB7PzTFkIYou01g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 QWdyZWVkLCBidXQgaGF2ZSBpbiBtaW5kIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGEgdHJhbnNpdGlv biBwZXJpb2Qgd2hlbiBSRkMgNjk2Mi1iaXMgaXMgcHVibGlzaGVkIGJlY2F1c2UgaXQgYWZmZWN0 cyB0aGUgaXNzdWFuY2UgcHJvY2VkdXJlIGluIHRoZSBDQSBhbmQgbm90IGFsbCBhcmUgcXVpY2sg ZW5vdWdoIHRvIGltcGxlbWVudCBhbmQgdGhlIHByb2Nlc3NpbmcgaW4gdGhlIGxvZyBzZXJ2ZXJz Lg0KDQogDQoNCiANCg0KScOxaWdvIEJhcnJlaXJhDQpSZXNwb25zYWJsZSBkZWwgw4FyZWEgdMOp Y25pY2ENCmktYmFycmVpcmFAaXplbnBlLmV1cyANCg0KOTQ1MDY3NzA1DQoNCiANCg0KIA0KDQog DQoNCkVSTkUhIEJhbGl0ZWtlIG1lenUgaG9uZW4gemF0aXJlbiBiYXQgZWRvIG1lenUgb3NvYSBs ZWdleiBiYWJlc3R1dGEgZWdvdGVhLiBNZXp1YSBiYWR1IGJlcmUgaGFydHphaWxlYS4gT2tlcnJl a28gaGVsYmlkZXJhIGhlbGR1IGJhZGEgKGhlbGJpZGVhIGdhaXpraSBpZGF0emksIHRyYW5zbWlz aW9hayBodXRzIGVnaW4pIGVtYW4gYWJpc3UgaWdvcmxlYXJpLCBrb3JyZW8gaG9uaSBlcmFudHp1 bmEuIEtPTlRVWiENCkFURU5DSU9OISBFc3RlIG1lbnNhamUgY29udGllbmUgaW5mb3JtYWNpb24g cHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIGEgbGEgcXVlIHNvbG8gdGllbmUgZGVyZWNobyBh IGFjY2VkZXIgZWwgZGVzdGluYXRhcmlvLiBTaSB1c3RlZCBsbyByZWNpYmUgcG9yIGVycm9yIGxl IGFncmFkZWNlcmlhbW9zIHF1ZSBubyBoaWNpZXJhIHVzbyBkZSBsYSBpbmZvcm1hY2lvbiB5IHF1 ZSBzZSBwdXNpZXNlIGVuIGNvbnRhY3RvIGNvbiBlbCByZW1pdGVudGUuDQoNCiANCg0KRGU6IFRy YW5zIFttYWlsdG86dHJhbnMtYm91bmNlc0BpZXRmLm9yZ10gRW4gbm9tYnJlIGRlIEVyYW4gTWVz c2VyaQ0KRW52aWFkbyBlbDogbWnDqXJjb2xlcywgMTYgZGUgbWFyem8gZGUgMjAxNiAxNDoyNg0K UGFyYTogUm9iIFN0cmFkbGluZw0KQ0M6IHRyYW5zQGlldGYub3JnDQpBc3VudG86IFJlOiBbVHJh bnNdIENvLWV4aXN0ZW5jZSBvZiBWMSBhbmQgVjIgZW1iZWRkZWQgU0NUcyBpbiBjZXJ0aWZpY2F0 ZXMNCg0KIA0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjaywgSSdsbCBjaGFuZ2UgaHR0cHM6Ly9n aXRodWIuY29tL2dvb2dsZS9jZXJ0aWZpY2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9wdWxsLzEzNSBh Y2NvcmRpbmdseS4NCg0KKE1vcmUgZmVlZGJhY2sgaXMgc3RpbGwgd2VsY29tZSwgb2YgY291cnNl LCBidXQgSSBhbHNvIHN0cm9uZ2x5IHRoaW5rIGl0IGlzIGJlbmVmaWNpYWwpLg0KDQogDQoNCk9u IFdlZCwgTWFyIDE2LCAyMDE2IGF0IDE6MDcgUE0sIFJvYiBTdHJhZGxpbmcgPHJvYi5zdHJhZGxp bmdAY29tb2RvLmNvbT4gd3JvdGU6DQoNCk9uIDE2LzAzLzE2IDEyOjIyLCBFcmFuIE1lc3Nlcmkg d3JvdGU6DQoNCkhvdyBkZXNpcmFibGUgaXMgaXQgZm9yIGlzc3VlcnMgdG8gYmUgYWJsZSB0byBl bWJlZCBWMSBhbmQgVjIgU0NUcyBpbg0KdGhlIHNhbWUgY2VydGlmaWNhdGU/DQoNCg0KRXJhbiwg dGhhbmtzIGZvciB0aGlua2luZyB0aGlzIHRocm91Z2guICBJIHRoaW5rIHRoYXQgdGhpcyBpcyBk ZWZpbml0ZWx5IGRlc2lyYWJsZSwgYW5kIEkgbGlrZSB0aGUgc29sdXRpb24geW91J3ZlIHByb3Bv c2VkLg0KDQpJZiB3ZSBkb24ndCBkbyB0aGlzLCBJIHRoaW5rIGl0IHdvdWxkIGFkdmVyc2VseSBh ZmZlY3QgYWRvcHRpb24gb2YgVjIuIEVtYmVkZGluZyBTQ1RzIGluIGNlcnRpZmljYXRlcyBpcyB0 aGUgb25seSBTQ1QgZGVsaXZlcnkgbWVjaGFuaXNtIHRoYXQgYWxsIFRMUyBzZXJ2ZXJzIHN1cHBv cnQsIGFuZCBmZXcgcGVvcGxlIGFyZSBnb2luZyB0byB3YW50IHRvIGJyZWFrIGNvbXBhdGliaWxp dHkgKGJ5IGVtYmVkZGluZyBvbmx5IFYyIFNDVHMgaW4gY2VydHMpIHdpdGggVjEgY2xpZW50cyB0 aGF0IHN0aWxsIGhhdmUgYSBzaWduaWZpY2FudCB1c2VyYmFzZS4NCg0KKFByZXRlbmQgZm9yIGEg bW9tZW50IHRoYXQgIlYxIiBpcyBzaGExV2l0aFJTQUVuY3J5cHRpb24gYW5kICJWMiIgaXMgc2hh MjU2V2l0aFJTQUVuY3J5cHRpb24uICBBZG9wdGlvbiBvZiBzaGEyNTZXaXRoUlNBRW5jcnlwdGlv biBmb3IgY2VydGlmaWNhdGUgc2lnbmF0dXJlcyB3YXMgZXh0cmVtZWx5IHNsb3csIGJlY2F1c2Ug KGkpIHRoZSB1c2VyYmFzZSBvZiBjbGllbnRzIHRoYXQgb25seSBzdXBwb3J0ZWQgc2hhMVdpdGhS U0FFbmNyeXB0aW9uIHdhcyBzdGlsbCBzaWduaWZpY2FudCBhbmQgKGlpKSBjZXJ0aWZpY2F0ZXMg Y2FuIG9ubHkgaGF2ZSAxIHNpZ25hdHVyZSkuDQoNCgkgDQoNCglCYWNrZ3JvdW5kOiBWMSBTQ1Rz IChSRkM2OTYyKSBhbmQgVjIgU0NUcyAoUkZDNjk5Mi1iaXMpIGFyZSBjb21wbGV0ZWx5DQoJZGlm ZmVyZW50IGFuZCBjYW4gY28tZXhpc3QgZm9yIFguNTA5IGNlcnRpZmljYXRlcyBhcyB0aGV5IGFy ZSBkZWxpdmVyZWQNCglpbiBkaWZmZXJlbnQgT0NTUCBleHRlbnNpb25zIC8gVExTIGV4ZXRlbnNp b25zLg0KCQ0KCUluIHRoZSBjYXNlIG9mIHByZWNlcnRpZmljYXRlcywgd2hpbGUgaW4gdGhlb3J5 IFYxIGFuZCBWMiBTQ1RzIGNhbiBiZQ0KCWluZGVwZW5kZW50bHkgZW1iZWRkZWQgKGFzIHRoZSBY LjUwOSBleHRlbnNpb25zIHRvIGVtYmVkIGVhY2ggdHlwZSBhcmUNCglkaWZmZXJlbnQpLCBpbiBw cmFjdGljZSBTQ1RzIGZvciBWMSBQcmVjZXJ0aWZpY2F0ZXMgY292ZXIgdGhlIGVudGlyZQ0KCVRC U0NlcnRpZmljYXRlLCBpbmNsdWRpbmcgdGhlIFYyIFNDVHMgKG90aGVyd2lzZSB0aGUgVjEgU0NU IHdvbid0IGJlDQoJdmFsaWQpIGFuZCB0aGUgc2FtZSBnb2VzIGZvciBWMiBTQ1RzLg0KCQ0KCUlu IFJGQzY5NjItYmlzLCBhcyBpdCBpcyBkZWZpbmVkIHJpZ2h0IG5vdywgIFYxIGFuZCBWMiBTQ1Rz IGZvciB0aGUgc2FtZQ0KCXByZWNlcnRpZmljYXRlIGNhbm5vdCBiZSBlbWJlZGRlZCBpbiB0aGUg c2FtZSBYLjUwOSBjZXJ0aWZpY2F0ZS4NCglJdCBzZWVtcyB0byBtZSB0aGVyZSB3b3VsZCBiZSBi ZW5lZml0IHRvIGVuYWJsaW5nIHRoaXMgY29tYmluYXRpb24sIGFzDQoJdGhhdCBtZWFucyBpc3N1 ZXJzIGNhbiBpc3N1ZSBjZXJ0aWZpY2F0ZXMgdGhhdCB3b3VsZCBjb21wbHkgYm90aCB3aXRoIFYx DQoJQ1QgY2xpZW50cyBhbmQgVjIgQ1QgY2xpZW50cyB3aXRob3V0IGZvcmNpbmcgVjIgY2xpZW50 cyB0byBhbHNvDQoJaW1wbGVtZW50IFJGQzY5NjIuDQoJDQoJVGhlIHNvbHV0aW9uIEkgcHJvcG9z ZToNCgktIEluIHRoZSBub3JtYXRpdmUgc2VjdGlvbiBvZiBSRkM2OTYyLWJpcyBhYm91dCBTQ1Qg Y2hlY2tpbmcsIHNwZWNpZnkNCgl0aGF0IFRMUyBjbGllbnRzIFNIT1VMRCByZW1vdmUgdGhlIFYx IFguNTA5IGV4dGVuc2lvbiAoT0lEIFhYWCkgd2hlbg0KCWNoZWNraW5nIFYyIFByZWNlcnRpZmlj YXRlIFNDVHMuDQoJLSBJbiBhbiBpbmZvcm1hbCBhcHBlbmRpeCwgc3VnZ2VzdCB0aGUgZm9sbG93 aW5nIHByb2Nlc3MgZm9yIGlzc3VpbmcgYW4NCglYLjUwOSBjZXJ0aWZpY2F0ZSB0aGF0IGNvbnRh aW5zIHZhbGlkIFYxIGFuZCBWMiBTQ1RzIGVtYmVkZGVkOg0KCSgxKSBJc3N1ZXIgY3JlYXRlIGEg dmFsaWQgUkZDNjk2Mi1iaXMgcHJlY2VydGlmaWNhdGUgYW5kIHN1Ym1pdHMgaXQgdG8NCglWMiBs b2dzLCBjb2xsZWN0aW5nIHRoZSByZXR1cm5lZCBTQ1RzLg0KCSgyKSBJc3N1ZXIgZW1iZWRzIHRo ZSBWMiBTQ1RzIChhcyBUcmFuc0l0ZW1zKSBpbnRvIHRoZSBUQlNDZXJ0aWZpY2F0ZQ0KCXdpdGgg dGhlIFYyIFguNTA5IGV4dGVuc2lvbi4NCgkoMykgSXNzdWVyIHRoZW4gYWRkcyB0aGUgcG9pc29u IGV4dGVuc2lvbiBmcm9tIFJGQzY5NjIsIHNpZ25zIHRoZQ0KCVRCU0NlcnRpZmljYXRlIHRvIHBy b2R1Y2UgYSB2YWxpZCBWMSBwcmVjZXJ0aWZpY2F0ZSwgd2hpY2ggaXQgdGhlbg0KCXN1Ym1pdHMg dG8gVjEgbG9ncy4NCgkoNCkgSXNzdWVyIGVtYmVkcyB0aGUgVjEgU0NUcyBpbiB0aGUgVEJTQ2Vy dGlmaWNhdGUgYW5kIHNpZ25zIGl0LA0KCXByb2R1Y2luZyB0aGUgZmluYWwgWC41MDkgY2VydGlm aWNhdGUgdG8gYmUgdXNlZCBieSB0aGUgc2VydmVyLg0KCQ0KCVYxIGNsaWVudHMgd291bGQgdmFs aWRhdGUgdGhlIFYxIFNDVHMgYW5kIGlnbm9yZSB0aGUgVjIgU0NUcy4NCglWMiBjbGllbnRzIHdv dWxkIHJlbW92ZSB0aGUgVjEgU0NUcyBhbmQgdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBvdmVyIHRo ZQ0KCXJlc3VsdGluZyBUQlNDZXJ0aWZpY2F0ZSwgd2hpY2ggd291bGQgdGhlbiBleGNsdWRlIFYx IGFuZCBWMiBTQ1RzIGFuZCBiZQ0KCWlkZW50aWNhbCB0byB0aGUgVEJTQ2VydGlmaWNhdGUgaW4g dGhlIFYyIChDTVMpIHByZWNlcnRpZmljYXRlIHN1Ym1pdHRlZA0KCXRvIHRoZSBsb2cuDQoJDQoJ VGhvdWdodHM/DQoJDQoJRXJhbg0KDQogDQoNCi0tIA0KUm9iIFN0cmFkbGluZw0KU2VuaW9yIFJl c2VhcmNoICYgRGV2ZWxvcG1lbnQgU2NpZW50aXN0DQpDT01PRE8gLSBDcmVhdGluZyBUcnVzdCBP bmxpbmUNCg0KIA0KDQo= --Boundary_(ID_m2+QzdQCB7PzTFkIYou01g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJUZXh0byBkZSBnbG9ibyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNw YW4uRXN0aWxvQ29ycmVvMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u VGV4dG9kZWdsb2JvQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0byBkZSBnbG9ibyBDYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dG8gZGUgZ2xvYm8i Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFUzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCAzLjBjbSA3MC44NXB0IDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVTIGxpbms9Ymx1ZSB2 bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BZ3JlZWQsIGJ1dCBoYXZlIGluIG1pbmQg dGhhdCB0aGVyZSBzaG91bGQgYmUgYSB0cmFuc2l0aW9uIHBlcmlvZCB3aGVuIFJGQyA2OTYyLWJp cyBpcyBwdWJsaXNoZWQgYmVjYXVzZSBpdCBhZmZlY3RzIHRoZSBpc3N1YW5jZSBwcm9jZWR1cmUg aW4gdGhlIENBIGFuZCBub3QgYWxsIGFyZSBxdWljayBlbm91Z2ggdG8gaW1wbGVtZW50IGFuZCB0 aGUgcHJvY2Vzc2luZyBpbiB0aGUgbG9nIHNlcnZlcnMuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6OS43NXB0Jz48Yj48c3BhbiBsYW5nPUVTLVRSQUQg c3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPknDsWlnbyBCYXJyZWlyYTwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FUy1UUkFE IHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrJz48YnI+UmVzcG9uc2FibGUgZGVsIMOBcmVhIHTDqWNuaWNhPGJyPjxhIGhy ZWY9Im1haWx0bzppLWJhcnJlaXJhQGl6ZW5wZS5ldXMiPmktYmFycmVpcmFAaXplbnBlLmV1czwv YT4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVT LVRSQUQgc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPjk0NTA2NzcwNTwvc3Bhbj48c3BhbiBsYW5nPUVTLVRSQUQgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz48aW1nIGJvcmRlcj0w IHdpZHRoPTU4OSBoZWlnaHQ9OTkgaWQ9IkltYWdlbl94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAw MS5qcGdAMDFEMTdGOTEuMkM1MDcxQjAiIGFsdD0iRGVzY3JpcGNpw7NuOiBmaXJtYV9lbWFpbF9J emVucGVfZXVzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RVMtVFJBRCBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjkuNzVwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s b3I6Izg4ODg4ODttc28tZmFyZWFzdC1sYW5ndWFnZTpFUy1UUkFEJz5FUk5FISBCYWxpdGVrZSBt ZXp1IGhvbmVuIHphdGlyZW4gYmF0IGVkbyBtZXp1IG9zb2EgbGVnZXogYmFiZXN0dXRhIGVnb3Rl YS4gTWV6dWEgYmFkdSBiZXJlIGhhcnR6YWlsZWEuIE9rZXJyZWtvIGhlbGJpZGVyYSBoZWxkdSBi YWRhIChoZWxiaWRlYSBnYWl6a2kgaWRhdHppLCB0cmFuc21pc2lvYWsgaHV0cyBlZ2luKSBlbWFu IGFiaXN1IGlnb3JsZWFyaSwga29ycmVvIGhvbmkgZXJhbnR6dW5hLiBLT05UVVohPC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6Izg4ODg4ODttc28tZmFyZWFzdC1sYW5ndWFnZTpFUy1UUkFEJz48YnI+PC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO2NvbG9yOiM4ODg4ODg7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RVMtVFJBRCc+QVRF TkNJT04hIEVzdGUgbWVuc2FqZSBjb250aWVuZSBpbmZvcm1hY2lvbiBwcml2aWxlZ2lhZGEgbyBj b25maWRlbmNpYWwgYSBsYSBxdWUgc29sbyB0aWVuZSBkZXJlY2hvIGEgYWNjZWRlciBlbCBkZXN0 aW5hdGFyaW8uIFNpIHVzdGVkIGxvIHJlY2liZSBwb3IgZXJyb3IgbGUgYWdyYWRlY2VyaWFtb3Mg cXVlIG5vIGhpY2llcmEgdXNvIGRlIGxhIGluZm9ybWFjaW9uIHkgcXVlIHNlIHB1c2llc2UgZW4g Y29udGFjdG8gY29uIGVsIHJlbWl0ZW50ZS48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eTttc28tZmFyZWFzdC1sYW5ndWFnZTpF Uy1UUkFEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPkRlOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gVHJhbnMgW21haWx0bzp0cmFu cy1ib3VuY2VzQGlldGYub3JnXSA8Yj5FbiBub21icmUgZGUgPC9iPkVyYW4gTWVzc2VyaTxicj48 Yj5FbnZpYWRvIGVsOjwvYj4gbWnDqXJjb2xlcywgMTYgZGUgbWFyem8gZGUgMjAxNiAxNDoyNjxi cj48Yj5QYXJhOjwvYj4gUm9iIFN0cmFkbGluZzxicj48Yj5DQzo8L2I+IHRyYW5zQGlldGYub3Jn PGJyPjxiPkFzdW50bzo8L2I+IFJlOiBbVHJhbnNdIENvLWV4aXN0ZW5jZSBvZiBWMSBhbmQgVjIg ZW1iZWRkZWQgU0NUcyBpbiBjZXJ0aWZpY2F0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLCBJJ2xsIGNoYW5nZSA8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNzL3B1bGwvMTM1Ij5o dHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNzL3B1 bGwvMTM1PC9hPiBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4oTW9yZSBmZWVkYmFjayBpcyBzdGlsbCB3ZWxjb21lLCBvZiBjb3Vyc2UsIGJ1dCBJIGFs c28gc3Ryb25nbHkgdGhpbmsgaXQgaXMgYmVuZWZpY2lhbCkuPG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+T24gV2VkLCBNYXIgMTYsIDIwMTYgYXQgMTowNyBQTSwgUm9iIFN0 cmFkbGluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYi5zdHJhZGxpbmdAY29tb2RvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJvYi5zdHJhZGxpbmdAY29tb2RvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5PbiAxNi8wMy8xNiAxMjoyMiwgRXJhbiBNZXNz ZXJpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5Ib3cgZGVzaXJhYmxl IGlzIGl0IGZvciBpc3N1ZXJzIHRvIGJlIGFibGUgdG8gZW1iZWQgVjEgYW5kIFYyIFNDVHMgaW48 YnI+dGhlIHNhbWUgY2VydGlmaWNhdGU/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs Pjxicj5FcmFuLCB0aGFua3MgZm9yIHRoaW5raW5nIHRoaXMgdGhyb3VnaC4mbmJzcDsgSSB0aGlu ayB0aGF0IHRoaXMgaXMgZGVmaW5pdGVseSBkZXNpcmFibGUsIGFuZCBJIGxpa2UgdGhlIHNvbHV0 aW9uIHlvdSd2ZSBwcm9wb3NlZC48YnI+PGJyPklmIHdlIGRvbid0IGRvIHRoaXMsIEkgdGhpbmsg aXQgd291bGQgYWR2ZXJzZWx5IGFmZmVjdCBhZG9wdGlvbiBvZiBWMi4gRW1iZWRkaW5nIFNDVHMg aW4gY2VydGlmaWNhdGVzIGlzIHRoZSBvbmx5IFNDVCBkZWxpdmVyeSBtZWNoYW5pc20gdGhhdCBh bGwgVExTIHNlcnZlcnMgc3VwcG9ydCwgYW5kIGZldyBwZW9wbGUgYXJlIGdvaW5nIHRvIHdhbnQg dG8gYnJlYWsgY29tcGF0aWJpbGl0eSAoYnkgZW1iZWRkaW5nIG9ubHkgVjIgU0NUcyBpbiBjZXJ0 cykgd2l0aCBWMSBjbGllbnRzIHRoYXQgc3RpbGwgaGF2ZSBhIHNpZ25pZmljYW50IHVzZXJiYXNl Ljxicj48YnI+KFByZXRlbmQgZm9yIGEgbW9tZW50IHRoYXQgJnF1b3Q7VjEmcXVvdDsgaXMgc2hh MVdpdGhSU0FFbmNyeXB0aW9uIGFuZCAmcXVvdDtWMiZxdW90OyBpcyBzaGEyNTZXaXRoUlNBRW5j cnlwdGlvbi4mbmJzcDsgQWRvcHRpb24gb2Ygc2hhMjU2V2l0aFJTQUVuY3J5cHRpb24gZm9yIGNl cnRpZmljYXRlIHNpZ25hdHVyZXMgd2FzIGV4dHJlbWVseSBzbG93LCBiZWNhdXNlIChpKSB0aGUg dXNlcmJhc2Ugb2YgY2xpZW50cyB0aGF0IG9ubHkgc3VwcG9ydGVkIHNoYTFXaXRoUlNBRW5jcnlw dGlvbiB3YXMgc3RpbGwgc2lnbmlmaWNhbnQgYW5kIChpaSkgY2VydGlmaWNhdGVzIGNhbiBvbmx5 IGhhdmUgMSBzaWduYXR1cmUpLjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48YmxvY2txdW90ZSBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5CYWNrZ3JvdW5kOiBWMSBTQ1RzIChSRkM2OTYy KSBhbmQgVjIgU0NUcyAoUkZDNjk5Mi1iaXMpIGFyZSBjb21wbGV0ZWx5PGJyPmRpZmZlcmVudCBh bmQgY2FuIGNvLWV4aXN0IGZvciBYLjUwOSBjZXJ0aWZpY2F0ZXMgYXMgdGhleSBhcmUgZGVsaXZl cmVkPGJyPmluIGRpZmZlcmVudCBPQ1NQIGV4dGVuc2lvbnMgLyBUTFMgZXhldGVuc2lvbnMuPGJy Pjxicj5JbiB0aGUgY2FzZSBvZiBwcmVjZXJ0aWZpY2F0ZXMsIHdoaWxlIGluIHRoZW9yeSBWMSBh bmQgVjIgU0NUcyBjYW4gYmU8YnI+aW5kZXBlbmRlbnRseSBlbWJlZGRlZCAoYXMgdGhlIFguNTA5 IGV4dGVuc2lvbnMgdG8gZW1iZWQgZWFjaCB0eXBlIGFyZTxicj5kaWZmZXJlbnQpLCBpbiBwcmFj dGljZSBTQ1RzIGZvciBWMSBQcmVjZXJ0aWZpY2F0ZXMgY292ZXIgdGhlIGVudGlyZTxicj5UQlND ZXJ0aWZpY2F0ZSwgaW5jbHVkaW5nIHRoZSBWMiBTQ1RzIChvdGhlcndpc2UgdGhlIFYxIFNDVCB3 b24ndCBiZTxicj52YWxpZCkgYW5kIHRoZSBzYW1lIGdvZXMgZm9yIFYyIFNDVHMuPGJyPjxicj5J biBSRkM2OTYyLWJpcywgYXMgaXQgaXMgZGVmaW5lZCByaWdodCBub3csJm5ic3A7IFYxIGFuZCBW MiBTQ1RzIGZvciB0aGUgc2FtZTxicj5wcmVjZXJ0aWZpY2F0ZSBjYW5ub3QgYmUgZW1iZWRkZWQg aW4gdGhlIHNhbWUgWC41MDkgY2VydGlmaWNhdGUuPGJyPkl0IHNlZW1zIHRvIG1lIHRoZXJlIHdv dWxkIGJlIGJlbmVmaXQgdG8gZW5hYmxpbmcgdGhpcyBjb21iaW5hdGlvbiwgYXM8YnI+dGhhdCBt ZWFucyBpc3N1ZXJzIGNhbiBpc3N1ZSBjZXJ0aWZpY2F0ZXMgdGhhdCB3b3VsZCBjb21wbHkgYm90 aCB3aXRoIFYxPGJyPkNUIGNsaWVudHMgYW5kIFYyIENUIGNsaWVudHMgd2l0aG91dCBmb3JjaW5n IFYyIGNsaWVudHMgdG8gYWxzbzxicj5pbXBsZW1lbnQgUkZDNjk2Mi48YnI+PGJyPlRoZSBzb2x1 dGlvbiBJIHByb3Bvc2U6PGJyPi0gSW4gdGhlIG5vcm1hdGl2ZSBzZWN0aW9uIG9mIFJGQzY5NjIt YmlzIGFib3V0IFNDVCBjaGVja2luZywgc3BlY2lmeTxicj50aGF0IFRMUyBjbGllbnRzIFNIT1VM RCByZW1vdmUgdGhlIFYxIFguNTA5IGV4dGVuc2lvbiAoT0lEIFhYWCkgd2hlbjxicj5jaGVja2lu ZyBWMiBQcmVjZXJ0aWZpY2F0ZSBTQ1RzLjxicj4tIEluIGFuIGluZm9ybWFsIGFwcGVuZGl4LCBz dWdnZXN0IHRoZSBmb2xsb3dpbmcgcHJvY2VzcyBmb3IgaXNzdWluZyBhbjxicj5YLjUwOSBjZXJ0 aWZpY2F0ZSB0aGF0IGNvbnRhaW5zIHZhbGlkIFYxIGFuZCBWMiBTQ1RzIGVtYmVkZGVkOjxicj4o MSkgSXNzdWVyIGNyZWF0ZSBhIHZhbGlkIFJGQzY5NjItYmlzIHByZWNlcnRpZmljYXRlIGFuZCBz dWJtaXRzIGl0IHRvPGJyPlYyIGxvZ3MsIGNvbGxlY3RpbmcgdGhlIHJldHVybmVkIFNDVHMuPGJy PigyKSBJc3N1ZXIgZW1iZWRzIHRoZSBWMiBTQ1RzIChhcyBUcmFuc0l0ZW1zKSBpbnRvIHRoZSBU QlNDZXJ0aWZpY2F0ZTxicj53aXRoIHRoZSBWMiBYLjUwOSBleHRlbnNpb24uPGJyPigzKSBJc3N1 ZXIgdGhlbiBhZGRzIHRoZSBwb2lzb24gZXh0ZW5zaW9uIGZyb20gUkZDNjk2Miwgc2lnbnMgdGhl PGJyPlRCU0NlcnRpZmljYXRlIHRvIHByb2R1Y2UgYSB2YWxpZCBWMSBwcmVjZXJ0aWZpY2F0ZSwg d2hpY2ggaXQgdGhlbjxicj5zdWJtaXRzIHRvIFYxIGxvZ3MuPGJyPig0KSBJc3N1ZXIgZW1iZWRz IHRoZSBWMSBTQ1RzIGluIHRoZSBUQlNDZXJ0aWZpY2F0ZSBhbmQgc2lnbnMgaXQsPGJyPnByb2R1 Y2luZyB0aGUgZmluYWwgWC41MDkgY2VydGlmaWNhdGUgdG8gYmUgdXNlZCBieSB0aGUgc2VydmVy Ljxicj48YnI+VjEgY2xpZW50cyB3b3VsZCB2YWxpZGF0ZSB0aGUgVjEgU0NUcyBhbmQgaWdub3Jl IHRoZSBWMiBTQ1RzLjxicj5WMiBjbGllbnRzIHdvdWxkIHJlbW92ZSB0aGUgVjEgU0NUcyBhbmQg dmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBvdmVyIHRoZTxicj5yZXN1bHRpbmcgVEJTQ2VydGlmaWNh dGUsIHdoaWNoIHdvdWxkIHRoZW4gZXhjbHVkZSBWMSBhbmQgVjIgU0NUcyBhbmQgYmU8YnI+aWRl bnRpY2FsIHRvIHRoZSBUQlNDZXJ0aWZpY2F0ZSBpbiB0aGUgVjIgKENNUykgcHJlY2VydGlmaWNh dGUgc3VibWl0dGVkPGJyPnRvIHRoZSBsb2cuPGJyPjxicj5UaG91Z2h0cz88YnI+PGJyPkVyYW48 bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxzcGFuIGNsYXNzPWhvZW56Yj48c3BhbiBzdHlsZT0nY29sb3I6Izg4ODg4 OCc+LS0gPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Izg4ODg4OCc+PGJyPjxzcGFu IGNsYXNzPWhvZW56Yj5Sb2IgU3RyYWRsaW5nPC9zcGFuPjxicj48c3BhbiBjbGFzcz1ob2VuemI+ U2VuaW9yIFJlc2VhcmNoICZhbXA7IERldmVsb3BtZW50IFNjaWVudGlzdDwvc3Bhbj48YnI+PHNw YW4gY2xhc3M9aG9lbnpiPkNPTU9ETyAtIENyZWF0aW5nIFRydXN0IE9ubGluZTwvc3Bhbj48L3Nw YW4+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --Boundary_(ID_m2+QzdQCB7PzTFkIYou01g)-- --Boundary_(ID_6G0gAlZnwVQhCyXAxYXcfw) Content-id: Content-type: image/jpeg; name=image001.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.jpg Content-description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABjAk0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3LVdV tNGsHvLxysakKqqNzOx4CqByWJ4AFYsdp4i10ede3j6JaNylpabWuCP9uQghT7KOPWizjGu+L7u+ m+e00dvs1qh6GcqDJJ9QGCD0+b1rp60+D1M17+vQ54eDrHHz3+syN3ZtUnyfyYCl/wCEO0//AJ/N X/8ABpcf/F1dm8RaLbzPDNqtmkqHDI0ygqfQ81et7mC7gSe2mSaFxlXjYMD9CKhVW9maSw3KryjZ ehif8Idp/wDz+av/AODS4/8Ai6P+EO0//n81f/waXH/xddBRVe0l3I9nDsc//wAIdp//AD+av/4N Lj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX /wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJ dw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8A P5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T /wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAX XQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8A CHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4 uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDB pcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9n Dsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q/ /g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn 81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUU e0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf /wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/h DtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc/ /wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0u P/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/mr/+DS4/+Lo/4Q7T/wDn81f/ AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/AOfzV/8AwaXH/wAXXQUUe0l3 D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABddBRR7SXcPZw7HP/8ACHaf/wA/ mr/+DS4/+Lo/4Q7T/wDn81f/AMGlx/8AF10FFHtJdw9nDsc//wAIdp//AD+av/4NLj/4uj/hDtP/ AOfzV/8AwaXH/wAXXQUUe0l3D2cOxz//AAh2n/8AP5q//g0uP/i6P+EO0/8A5/NX/wDBpcf/ABdd BSEhQSSAB1Jo55dw9nDsYH/CHaf/AM/mr/8Ag0uP/i6P+EO0/wD5/NX/APBpcf8AxdbX2u2/5+Iv ++xR9rtv+fiL/vsUc8+4uSHZGL/wh2n/APP5q/8A4NLj/wCLo/4Q7T/+fzV//Bpcf/F1tfa7b/n4 i/77FH2u2/5+Iv8AvsUc8+4ckOyMX/hDtP8A+fzV/wDwaXH/AMXR/wAIdp//AD+av/4NLj/4utr7 Xbf8/EX/AH2KlBDAEEEHoRRzz7h7OHYwP+EO0/8A5/NX/wDBpcf/ABdNbwhAvNrq+t20g6MuoSSf mrlgfyroqKPaS7j9nDscs+p6v4ZYHXHS/wBKJAOoxR7Hg95UHG3/AG16dwOtdQjq6K6MGVhkEHII pHRZEZHUMjAhlYZBHoa5bQriLw9eahoF1MEtbUpNYtIf+WEm7Cf8BZXA9ttP4ldbivyOz2LXg4D+ y71/4n1O8Zj6nz3H8gK6Guf8Hf8AIIuv+wlef+j3roKVT4mOn8CPnHVCF1i+VsAi5kyD1+8a9f8A huCPBMBwQDJKR/30a6eSws5XLyWkDuerNGCT+lTIiRRhUVURRgADAArio4d0581z3cfmyxVBUVC1 muvkef8A2qO40qS5S9Kz22lgOftTBpZ2iB5Gf4Vwc46t6irGp3MthG09tOqwRWM5lS3uGlTDFRvD HncpwfYZrqLK40jU2aS0+zTMoBJCDOCODyOhGeehq6Ire3iIEcUcffCgDmvQdSz2PnVSutGcVdw3 v2PUr8TeVFHNNG7G6fMn7wKAR0QD1HP611ulKi2CBPKxk/6mYyr17MeTVto0KMrIpQ/eBHBqnp1/ p92JI7B0IiOHVEKhT6dBzUyk5LY0jBRluXqKKZHNHMGMbhgrFDjsR1FZmg+imSzRwBTK4QMwRc92 JwBSTzR28LTSnaiDJOCf5UBckoqCzvbe/g861lEke4qSOxBwR9QanoC9wooooAKKKqyalZQ3aWkl 1Elw5AWNmwST0AotcTaW5aopkcscwJjdXCsVJU5wR1FEsscMZkldUQdWY4AoGPoqut9atNcQiZfM t1DSqeNoIyD9OD+VQ2ms6dfMq213HIzHCrnBPG7ofbmnZi5l3L1FFIrB1DKQVIyCDkEUhi0UUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAZHifxBbeGNBuNUuRvEYCxxg4Mjn7q/wCe2a+b9f8AFWseJbtptRvHZCcr AhKxoPQL/U816l8cZXXSNIiDHY9w7MPUheP5mvItH0i813VbfTbGMPcTthcnAA6kk9gBzXp4SEYw 52eRjqk5VPZooYHpRgelevP8ItD06KNdX8Ui3ncZwTHGp+m45NRzfB+wvrCSbQPESXcqdAxR0J9C ydP1rX6zT7mH1Or2/E8lwPSjA9KvwaNqFxra6NHbN/aBmMHknghwcHPsOefSvTh8INJ0+1ibW/Ey 20z+myNM+gLnJrSdaELXZnToVKl7LY8iwPStzw94s1nwzdpNp92/lA5e3kYtE49Cvb6jmvQT8INJ 1C1lbRPEy3EyDvskTPYEocivLNR0+50rUbiwvIzHcwOUkXrg+x7jvmlGpTq3Q5U6tFqR9ReHNetv EuhW2qWoKpMvzITko44ZT9DWrXl3wQldvD+pxE5RLsFR6EoM/wAq9RryKsFCbij3KE3OmpMK8Z+N U8trq+lPC5RngcMR3Abj+Zr2avFfjl/yE9H/AOuMn/oQrXCfxUZY3+Cz0rwd/wAgi6/7CV5/6Peu grn/AAd/yCLr/sJXn/o966CsanxM3p/AgpHBKMB1IpaR3VEZ2OFUZJ9BUFnCW+j6xHaQhY72NFgh iuQ7oZG2A/LHhh8gJyQSM9u9S3mmavcNLDJbXU0H2by2LSjMxAQqW+fG7KuOABnuc5rcTxGn2Oe5 ksp18uFbhEXDM8TZw3Xjocg9Kfd+IIrK4lEsEn2aFjG84IwJNm/bjr0xz6kCt+ad9jm5IW3ItLtr 6PVpJJUuEjxL5jSS7kky4MW0ZONqZB4H49ao3unakGuTHDcMsk87xiGYIQ5VBG55HyghuPccGrdz 4o+xxH7RYSJcK+1ojIvA27hhuhJHAXqSCO2avX+sLp7sJIHIFq9wpzgsVIBTHr8wqfeTvYq0GrXM VdK1eO7FzuneUSBzm5IRj57Z4zgDyyBjHA96rW9nrShWa1uty3AeOBpf3eCq7snzCwwwbByep45r eh8R2LectxIIZIQpkGdwyWZQAR94/KeBUza3Y+esUVzDI2Rvw4+VShcH3yBnHXBzT5pdg5IdzK1u w1G61VWhilkAMTW8gkxHCQSWLLnk529j+lO0+HVdP8PXbIl5PfHHlx3DISHwASPmORnLcnnnHWt6 1u4L2ATW8gkjJIyOxBwQR2NVbzUZIb6KztrdZpmQyvvk2KiZA64OSSeB7HkVPM/hsU4RT5rmItvq MKRQWVpfRw7YEBkkQEFZd0jthurA9uvNQQ6XrNpEJES5mk8vaySXTMGzCu7+Lr5mTxjnuBzXRvrW nRmQNdIGjcIy4Oc89BjJ6Hp6H0NMi1/TZN2bgIRO0GHBGWUgH8ORz05FVzS7EuEO5hQaZq0lhdeY bxJlhaK2zPtIzK5yMMcHYUGSSRjGeKNSttVj1GU20csNokRi8wXGAybVI+Zn4bhwDgYJBJ5retda s7maG386NbqVS6xBt2QOuD0NaDosiFHUMrDBBGQRSc2nqhqnFrRnFWY1Kd7aS1huTbw3rbW87eRG JiGUkvjAXHZs8jIxXTz28tzrFszri1tkMgOfvSn5Rx7Lu/76HpV2ONIo1jjRURRgKowAPpTqmU7s qNOy3M3TbOW0tLqJESAtcSvF8oKgMxIOAR9ccUmq2U15octu6x3FwVBGE2gsCDkAk4/OtOilzO9y uVWsZsukwRjULi3jb7TdRFWy5IY4OOCcDrWJLod5aWtlPAk13dpDsmMsoyAIyoUbSvALN0IyT171 1tFNTaFKnFnIWmmatIiGcXQMTIkYefA2efJuyAxz+6Kjkk9uop2lWep217pK/Y54beCFYZP3m4Ff LIO7LkcPjgL0wc9h1tFN1G7kqklbUKKKKzNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiqGt6vbaDot3ql2SIbaMuQOrHsB7k4H40AV/EPif SfC9j9r1W6WJTwiDl5D6KveuIPxM8Q6jH9o0PwRf3Fp/DNKSNw9QAP6ms7wLoM/jnV5vGfiZRPH5 hSytWGYwAeuP7o6D1OSa9fAAAAGAOgFLcZ5hoPxZudS1Y6Xe6C1vedoRPtdj/dCuBlvbIz2r0DS9 ZstYjka0kPmRNsmhkUpJE3oynkGvPvjVY20fh201iNVj1K2ukWKZeGwcnGe+CAfbFc3rvjy+TxRp +o6fGq3ENlGJTtwszMoZlc9xk4Hp1qJT5Nzow+HlXk4x/r/h2e6UVz/gu+1TU/DNtfas9tJPPmRW tzkbSeARgYI6Y56da6CtE76nO04uz3PJ/jl/yDtG/wCu0n/oIrifhomsv4nlOhGxF4LViTehigTc ucbec9P1rtvjl/yDtG/67Sf+giuQ+Eup22neOEW5cRrdQNAjMcDeSCB+O3H1Ir06V/q2nmePWt9b V/I39c+F3i7xDq82p39/pTTy4BCvIFUAYAAK8Ctv4f8Aw91vwl4gkvLq8tGtZIGjeOB2JY5BBIKg cYP51neNfBvjS48S3N5ot5czWVwQ6ol6Y/KOACuCwGMjPHrWj8O/C3inS9Wm1HxDeTrAsJRIJLoy 7iSPmPJAAA/Ws5TbpfEvQ1hTSrfA733NG18EX8HxTn8TmS1+xSBtsYJ8wExhc4xjrnv3rG8c/DbX fFPiibUbe8sxbGNEiSZ3ygA5GApA5yfxrI0/xlHJ8ZZLhtSm/smWZoIwZj5Wdm0NjOMFh1981r+P /CXi++8RPqGg3dw9rMigwx3Zi8tgMHgkDBxnj3pLnhNXdtBvknTlyxb16fmHgb4ba74W8UQ6lcXl mbYRukqQu+XBHAwVAPOD+FcZ8W1C/EG6IGC0ERPv8uP6V0vhf4feLLq/ZvEWp6jaWSqcLFfkyO3b GCQB9a4DxnHZQeKry30+8uby3hIj8+4l81mYD5vm7gHI/CtqWta/Nd26GFb3aHLy2V+p6d8D/wDk C6t/18r/AOgCvVK8r+B//IF1b/r5X/0AV6pXFif4rPQwn8GIV4r8cv8AkJ6P/wBcZP8A0IV7VXiv xy/5Cej/APXGT/0IVWE/ionG/wAFnpXg7/kEXX/YSvP/AEe9dBXP+Dv+QRdf9hK8/wDR710FY1Pi ZvT+BBTXRZI2RhlWBBHtTqZKZBC/lBTJtOzd0z2zUFmPD4fKWlxDNdmRpLZbWNxHt2RrnGRnlueT xnA4FLe+Hlvp5hJckWkz+a8ITnzNmzIbPTGDjHUde1ZUXi27mgmnW1hEcQRmyTyrkIn/AI+HB9hR J4uu4baG4ktYRHIGJAJyBGdsv5MRituWpc5+elYu3PhiW73yT30ctxLlZGe3BQjaFBC7uGGCQcnl jxzWhe6NHeJYKZnX7JKr7j8xkUDlWPvwT9Kz77WTaMsrTQq62jl2BLoJQ6KUChgCcnaMnIP41Ani DUxexW8kNkdkCvOyyABmKsTsy2SAVA4BzzyMUWm9R3pp2sW08OywSrLBfBZEYSIXh3ANmTqMjIxK wxx0Bz2oHhlY9PW1gvZYiknmLKqjcD5Plf8A1/0rPHiXUBbxeY9hFI+GMjqwQAwGXGN3XIxnPTnF W7HxDdXWpus0Fvb2caZkMsoV0/dq+cE5x8xHQcDOe1DU9xJ09i7YaHHa6dPZ3EgmSaZpTsBjxkg4 HzE9R60zWNAGqH5JxDuhMEgaISBkyCCMnhgRweep9sUJ/El9Hd6htgthb2xZRvkG/goNxGc4IYno MDByc1KviGZ7uDBtxaPcyQGRfnJIk2KANwIB/vAEZ7Ac0rTvcfNTtyjW8LTNJcSHUA8koUCSSEl0 IZyGDBwQw3kZGBx061KfDAa6SZ54pirucT24f5WKse+N2V69OenFdBRU+0kX7KHYxtM0SbTrtZDe LNEkQiRWhwyL1ODuxyeTxzgegrZooqW23dlxioqyCiiikMKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8V8TeC/FWg 38up2V/qOs6aztJJCl3JHMgPP8J5x6j8q43xJr2nalocENhe68Lgy/6Ta6hdmWNQBwR6nPrz7V9O V5d8XfB9rc6FJrtjZIt9buHuHjXBki6EkDqRwc9cA1LQ7kfhvxhbrHZaXp2q6fZafbwpGDOyggAc scn7xJJx6/Q566/+InhPTo2aXW7aRh/BAfMY/QLmvHvCfw1tvGOiLfWWuCK4RtlxbyQbvLbtgg8g jkV1+mfAzT4ZFfUtWnuVHWOGMRA/jkn+VCuN2MHVtWv/AIveJ7TStOt5LfR7V98juOVHQu3YHHCr 71m+L9POl+LdRtdhSMOGiH+wVG3/AA/CvetI0XTtCsVs9MtI7aBedqDkn1J6k+5rk/iboGn3mhy6 zPcpaXFjGSJWHEi/3D7k9Pc1lXpuUdNz0cqxcMPW9/ZqwvwnuHl8IvExJEN06r7AgN/Mmu6rkvht pz6f4LtGkUrJdE3JVhggN93/AMdArraukmoJM5sdOM8TOUNrnk/xy/5B2jf9dpP/AEEV4vXtHxy/ 5B2jf9dpP/QRXk+mRo8OpF3ZSlkzLhtu4704Pr1PFe1hXaij5nGK9dr+tjRt/Hfiq1gWGLXbsRoM KGIYgfUgmor/AMZ+JNUtWtbzWbqWBxho9wUMPQ4AyKs6hpaWGhs82kD7W8asJIpXKQLxy5LEFj/d HAzzzxVy50TSoop/Lgle3S3LpdKrctsyG3l9hBbtt9utafu97EWq2tzHHVv2fjfxPYWyW9trd2kK DCqWDYHoCwPFPgh0pLvR7OSwjkF5FCbidrhwys7EEjBwuBjqDRDpYGi2lzb6T9vllkmWRjI+AFYB cKpGOp5qpOL3REYzj8LGXfjfxPfWz29xrd20TjDKrBcj0JUA1gV1cOjaWbvVUjVrhreaNIYRmXCl SWPyMpbDALnOPzrH121trTUFjto3jUwozo/8LkcgDJIHQ4JyM0Qcb2igqRna8nc9Z+B//IF1b/r5 X/0AV6pXlfwP/wCQLq3/AF8r/wCgCvVK8rE/xWe1hP4MQrxX45f8hPR/+uMn/oQr2qvFfjl/yE9H /wCuMn/oQqsJ/FRON/gs9K8Hf8gi6/7CV5/6PeugrnPCrfZrvXNLk4lt9QkmUesc37xT+ZYf8BNd HWNT4mb0/gQUUUVBY3y0AxsXB7YoMaEYKLjnt69adRQBG8EMilXiRlPUFQQec0gtoFKFYIwUBCYQ fKD1A9KloouFircada3M1vLLECYGLIMDGdu3kfQ1OYYmkMhiQuV2lioyV9M+lPop3YrIjMEJdnMS FnXax2jJHofakFtApjIhjBjzsIQfL9PSpaKVx2CiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACm uiyxtG6hkYEMpGQQexp1FAHjureDde8A66/iDwcrXNi2fOseWKr1K4/iX0I5Fa9r8atCkjjF1a3V rOFczxuPuEDgD1JPA6e+K9IlVnidEcxsykBwMlT681zi+AfDrFHurBLyRYyrPcfOXYnczt6sT1Pt gYpWGZNx8XPCtrYRzPdma6ZATa2ymQhsfd3YA9s1l2ema38SdTt9S8QWr6d4dtnElvpzZ33Ddmf2 /wAj1ruLDwp4f0uQSWWj2UMgOQ6wjcPoeorYosAgAUAAAAcACloopiPMvjXYS3HhuxvY1JS1uMSY 7BxgH8wB+NeGV9c3tnb6jZTWd3EstvMhSRG6MDXifiD4N6ta3LyaHLHeWpOVjlcJKg9CTwfrkfSv QwteKjyS0PLxuGnKXPBXPMcAdhRgeldd/wAKx8Y/9AZv+/8AH/8AFUf8Kx8Y/wDQGb/v/H/8VXZ7 Wn/MvvOD2NX+V/cclUkk8ssEMDtmKHd5a4+7uOTXU/8ACsfGP/QGb/v/AB//ABVH/CsfGP8A0Bm/ 7/x//FUe1p/zIPY1f5X9xyWB6UdK63/hWPjH/oDN/wB/4/8A4qui8O/BrVLm6STXpY7S1U5aGJw8 j+2Rwv15pSr04q9yo4erJ2UWdR8F9PltvClzdyKVW7uS0ee6qAufzz+Vek1DaWsFjaRWtrEsUEKB I0UcKo6Cpq8epPnm5Hu0oezgo9grxX45f8hPR/8ArjJ/6EK9qrzrxT4bXxx4ouLdXAj0uGONmPTz H3Mw/Bdh/GtMNJRqcz2RlioudPlW7Ol13TryK+g17SIxJf26GKa3LbRdQ5yUz2YHlT65B4NXtI12 w1uFmtJT5sZxNbyDZLC3o6HkH/IrSrK1Tw3pOsSpPd2g+0oMJcRMY5V+jqQ34ZrNNNWkbOLTvE1a K5z/AIRHbwniHX1XsPtu7H4lSaP+ETb/AKGPX/8AwLX/AOJo5Y9xc0v5To6K5z/hE2/6GPX/APwL X/4mj/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0f8Im3/Qx6/8A+Ba/ /E0cse4c0v5To6K5z/hE2/6GPX//AALX/wCJo/4RNv8AoY9f/wDAtf8A4mjlj3Dml/KdHRXOf8Im 3/Qx6/8A+Ba//E0f8Im3/Qx6/wD+Ba//ABNHLHuHNL+U6Oiuc/4RNv8AoY9f/wDAtf8A4mj/AIRN v+hj1/8A8C1/+Jo5Y9w5pfynR0Vzn/CJt/0Mev8A/gWv/wATR/wibf8AQx6//wCBa/8AxNHLHuHN L+U6Oiuc/wCETb/oY9f/APAtf/iaP+ETb/oY9f8A/Atf/iaOWPcOaX8p0dFc5/wibf8AQx6//wCB a/8AxNH/AAibf9DHr/8A4Fr/APE0cse4c0v5To6K5z/hE2/6GPX/APwLX/4mj/hE2/6GPX//AALX /wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0f8Im3/Qx6/8A+Ba//E0cse4c0v5To6K5z/hE 2/6GPX//AALX/wCJo/4RNv8AoY9f/wDAtf8A4mjlj3Dml/KdHRXOf8Im3/Qx6/8A+Ba//E0f8Im3 /Qx6/wD+Ba//ABNHLHuHNL+U6Oiuc/4RNv8AoY9f/wDAtf8A4mj/AIRNv+hj1/8A8C1/+Jo5Y9w5 pfynR0Vzn/CJt/0Mev8A/gWv/wATR/wibf8AQx6//wCBa/8AxNHLHuHNL+U6Oiuc/wCETb/oY9f/ APAtf/iaP+ETb/oY9f8A/Atf/iaOWPcOaX8p0dFc5/wibf8AQx6//wCBa/8AxNH/AAibf9DHr/8A 4Fr/APE0cse4c0v5To6K5z/hE2/6GPX/APwLX/4mj/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/ AAibf9DHr/8A4Fr/APE0f8Im3/Qx6/8A+Ba//E0cse4c0v5To6K5z/hE2/6GPX//AALX/wCJo/4R Nv8AoY9f/wDAtf8A4mjlj3Dml/KdHRXOf8Im3/Qx6/8A+Ba//E0f8Im3/Qx6/wD+Ba//ABNHLHuH NL+U6Oiuc/4RNv8AoY9f/wDAtf8A4mj/AIRNv+hj1/8A8C1/+Jo5Y9w5pfynR0Vzn/CJt/0Mev8A /gWv/wATR/wibf8AQx6//wCBa/8AxNHLHuHNL+U6Oiuc/wCETb/oY9f/APAtf/iaP+ETb/oY9f8A /Atf/iaOWPcOaX8p0dFc5/wibf8AQx6//wCBa/8AxNH/AAibf9DHr/8A4Fr/APE0cse4c0v5To6K 5z/hE2/6GPX/APwLX/4mj/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0 f8Im3/Qx6/8A+Ba//E0cse4c0v5To6K5z/hE2/6GPX//AALX/wCJo/4RNv8AoY9f/wDAtf8A4mjl j3Dml/KdHRXOf8Im3/Qx6/8A+Ba//E0f8Im3/Qx6/wD+Ba//ABNHLHuHNL+U6Oiuc/4RNv8AoY9f /wDAtf8A4mj/AIRNv+hj1/8A8C1/+Jo5Y9w5pfynR0Vzn/CJt/0Mev8A/gWv/wATR/wibf8AQx6/ /wCBa/8AxNHLHuHNL+U6Oiuc/wCETb/oY9f/APAtf/iaP+ETb/oY9f8A/Atf/iaOWPcOaX8p0dFc 5/wibf8AQx6//wCBa/8AxNH/AAibf9DHr/8A4Fr/APE0cse4c0v5To6K5z/hE2/6GPX/APwLX/4m j/hE2/6GPX//AALX/wCJo5Y9w5pfynR0Vzn/AAibf9DHr/8A4Fr/APE0Hwdby/Ld6xrd1Eescl8y qfrs25otHuHNPt+JJq/iMQ3DaVo6LfaywwIlOUt/9uZh91R6dT0Aq7oWkLoumi381p53dprm4YYa aVuWY/0HYADtU+naXYaRai20+0htoc52xrjJ9T6n3NW6TkrWQ1F35pBRRRUlhRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFAH//Z --Boundary_(ID_6G0gAlZnwVQhCyXAxYXcfw)-- From nobody Wed Mar 16 08:28:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBDF12D8A8 for ; Wed, 16 Mar 2016 08:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_XkSBLFJeih for ; Wed, 16 Mar 2016 08:28: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 5F24512D53C for ; Wed, 16 Mar 2016 08:28:08 -0700 (PDT) Received: from localhost ([::1]:40322 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDMk-0000dm-Fo; Wed, 16 Mar 2016 08:28: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: rob.stradling@comodo.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:28:06 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/111#comment:2 Message-ID: <080.6b7797a81df349f4d82a64cf27611832@tools.ietf.org> References: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, eranm@google.com, 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] #111 (rfc6962-bis): Consider using the cached-info TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:28:26 -0000 #111: Consider using the cached-info TLS extension Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com Comment: Rob, assigning that to you as you originally suggested it. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:28:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A04C12D618 for ; Wed, 16 Mar 2016 08:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MhyIA--rm0p for ; Wed, 16 Mar 2016 08:28: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 6A9CC12D97C for ; Wed, 16 Mar 2016 08:28:31 -0700 (PDT) Received: from localhost ([::1]:40352 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDN8-0001jU-Mp; Wed, 16 Mar 2016 08:28:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: mhs@google.com, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:28:30 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/132#comment:3 Message-ID: <076.e9d3e14f2c96f4ce6ad406d5a9d49512@tools.ietf.org> References: <061.3cb1275ccf9a2813644b1e30ff83a68f@tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <061.3cb1275ccf9a2813644b1e30ff83a68f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mhs@google.com, eranm@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #132 (rfc6962-bis): unclear motivation for and handling of re-logging entries from a frozen log X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:28:39 -0000 #132: unclear motivation for and handling of re-logging entries from a frozen log Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- ----------------------------------+----------------------------- Reporter: david@mandelberg.org | Owner: mhs@google.com Type: enhancement | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------- Ticket URL: trans From nobody Wed Mar 16 08:29:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787FD12D9BE for ; Wed, 16 Mar 2016 08:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwdhmiXpwfxu for ; Wed, 16 Mar 2016 08:29:33 -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 1AD8112D52B for ; Wed, 16 Mar 2016 08:29:16 -0700 (PDT) Received: from localhost ([::1]:40403 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDNr-00041p-Jv; Wed, 16 Mar 2016 08:29:15 -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, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:29:15 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/144#comment:4 Message-ID: <068.6c7ba71e9f0b37a3d64d61ad4e599bc3@tools.ietf.org> References: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-Trac-Ticket-ID: 144 In-Reply-To: <053.cda9d1ed2721ac055bd5e77fa6b4faaa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #144 (rfc6962-bis): Need to specify how the CA requirements in 12.3 are to be met X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:29:35 -0000 #144: Need to specify how the CA requirements in 12.3 are to be met Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:30:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE4812D680 for ; Wed, 16 Mar 2016 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGdScogbe2Ha for ; Wed, 16 Mar 2016 08:30: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 8D36E12D532 for ; Wed, 16 Mar 2016 08:30:12 -0700 (PDT) Received: from localhost ([::1]:40500 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDOl-0007BM-IN; Wed, 16 Mar 2016 08:30:11 -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, david@mandelberg.org, melinda.shore@gmail.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:30:11 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/145#comment:7 Message-ID: <068.a605513df283b5af02719ead05c62296@tools.ietf.org> References: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-Trac-Ticket-ID: 145 In-Reply-To: <053.b9c80d4e3911c651387db3acbf4d6ab1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, david@mandelberg.org, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:30:37 -0000 #145: Section 9.2 (TLS clients) needs more guidance for browsers Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:34:30 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F278912D9F0 for ; Wed, 16 Mar 2016 08:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax5jTQtk5c7k for ; Wed, 16 Mar 2016 08:34:26 -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 1A3E512D9B6 for ; Wed, 16 Mar 2016 08:33:27 -0700 (PDT) Received: from localhost ([::1]:40732 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDRu-00044c-Bc; Wed, 16 Mar 2016 08:33:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:33:26 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/134#comment:1 Message-ID: <068.19ca18ebcdf4b196b9c1a9256139ad76@tools.ietf.org> References: <053.b603d1ab41ff0bb44c4a9af0ca19756a@tools.ietf.org> X-Trac-Ticket-ID: 134 In-Reply-To: <053.b603d1ab41ff0bb44c4a9af0ca19756a@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: <20160316153327.1A3E512D9B6@ietfa.amsl.com> Resent-Date: Wed, 16 Mar 2016 08:33:27 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #134 (rfc6962-bis): client use of logs to detect mis-issued certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:34:29 -0000 #134: client use of logs to detect mis-issued certs Changes (by eranm@google.com): * status: new => closed * resolution: => duplicate Comment: Marking as a duplicate of issue #141, even though it's not really a duplicate, since addressing issue #141 would make this issue obsolete. I will add the privacy concerns to issue #141. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: duplicate Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:35:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E29A12D9B6 for ; Wed, 16 Mar 2016 08:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In1NvWaZQalI for ; Wed, 16 Mar 2016 08:35: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 2AB0412D9F0 for ; Wed, 16 Mar 2016 08:34:31 -0700 (PDT) Received: from localhost ([::1]:40829 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDSt-00087O-3S; Wed, 16 Mar 2016 08:34:27 -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: eranm@google.com, paul@nohats.ca, kent@bbn.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:34:27 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/141#comment:4 Message-ID: <068.5f5f0cce299ba0951e483d6d4b086d39@tools.ietf.org> References: <053.8c537c2a7f50054133a842bd78583444@tools.ietf.org> X-Trac-Ticket-ID: 141 In-Reply-To: <053.8c537c2a7f50054133a842bd78583444@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, paul@nohats.ca, kent@bbn.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #141 (rfc6962-bis): expanding audit description X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:35:35 -0000 #141: expanding audit description Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com Comment: From issue #134 which I've just merged to this one: "Section 12 says that TLS clients can use logs and SCTs to reduce the likelihood that they will accept misissued [sic] certificates. Since direct access to a log to acquire an inclusion proof is viewed as bad from a privacy perspective, it’s not clear what sort of log access by a client is being suggested here. This needs to be clarified, or just removed." Point out there are privacy implications of clients directly communicating with logs, which the use of proxies can alleviate. -- --------------------------+------------------------------- Reporter: kseo@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 08:37:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135812D56A for ; Wed, 16 Mar 2016 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qlfSTyqyPYh for ; Wed, 16 Mar 2016 08:37:31 -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 4809712D8A8 for ; Wed, 16 Mar 2016 08:36:30 -0700 (PDT) Received: from localhost ([::1]:41001 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agDUs-00083R-5A; Wed, 16 Mar 2016 08:36:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Wed, 16 Mar 2016 15:36:30 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/153#comment:2 Message-ID: <080.c84eed914d064a1b2529fc5a0262ecfd@tools.ietf.org> References: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #153 (rfc6962-bis): Finish documenting support for RFC6962 (v1) structures in TransInfo X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 15:37:33 -0000 #153: Finish documenting support for RFC6962 (v1) structures in TransInfo Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com -- --------------------------------------+------------------------------- Reporter: rob.stradling@comodo.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------- Ticket URL: trans From nobody Wed Mar 16 09:01:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486D112D78A for ; Wed, 16 Mar 2016 09:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTu5OwnAzPpM for ; Wed, 16 Mar 2016 09:01:18 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB77512D7D0 for ; Wed, 16 Mar 2016 09:01:07 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id u190so80254508pfb.3 for ; Wed, 16 Mar 2016 09:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5Dt0DELBQzwcvUshuPcIRJsW/uaZ0D/7WYwi0f6G4nk=; b=tXb8wBuyx3bFdwl1/gsZOa9GzaKYc5xNXdhGf1CasK4uIAFIvpDDLxbmiNrCD26R8P Ix21p9EMFOTrpHzO/RS4rG6v05w2uATh3krPdAKnKHths4kwZOfLggbEO5cuejV4lEy1 IQZ2ZISoXIgtcOqx9SWcIjjw7BkzLwGKSCRf44j56B+AkvVrSEiuah1gNQi2Jcmn+nd3 SjdDzAuPYxA37kkENO9MFTCiB4osehe3UMPKQfMLhLU3/GEiMZ5mVcTZbbheLM+Yn8j+ 08frIcZUNAjt6MIcURgey3aJoMeQaNHg8OjqY/qSnKlFbq54ZsNS5JZuZH2v4EcFuPCN VJ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5Dt0DELBQzwcvUshuPcIRJsW/uaZ0D/7WYwi0f6G4nk=; b=DAxUmTzN9q2UgSkehHuZiCaj9fWs3gnNl1m59DSEJ0SiOaNCWzbMeXCzcgo6UBMxnm 64iIsnnnhqvmGYElgUHjccjltsJYgJj9hD350NHDORmrWgaezd6HxtsNFUUnPQHeG2K0 IxFF4MuQA8li7J6tue7nTC1AhkWUgp207xfpHq46jcGNPdgs1vj0Nxq+cbIbQFzL42rl RvYjZO1SetdtJkUkOJ4rxKTFhnaqg4R/Jpmg8Uk607OgcwLnw9usUzuc2XLJdrPNeksf /UAWqb0/+FVLT/Z14qmN3Gnk+AXD5QVjeS7zSyRJa8y41UJrSGnaIZXUo99Sj3cNj7z4 KKzw== X-Gm-Message-State: AD7BkJIb9TtTw0CpR652T/K9l/Fau5Rr8TclH5AQgBpdD8Nmq+LPvfLb1oFC+X2kowz+Dw== X-Received: by 10.98.72.89 with SMTP id v86mr505812pfa.156.1458144067252; Wed, 16 Mar 2016 09:01:07 -0700 (PDT) Received: from bookz.att.net (162-236-128-30.lightspeed.sntcca.sbcglobal.net. [162.236.128.30]) by smtp.gmail.com with ESMTPSA id p85sm856417pfj.16.2016.03.16.09.01.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 09:01:05 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_97842D2C-8025-4C12-A2EB-C91C5153A000"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Bryan Ford In-Reply-To: Date: Wed, 16 Mar 2016 09:00:58 -0700 Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Melinda Shore , Trans Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:01:21 -0000 --Apple-Mail=_97842D2C-8025-4C12-A2EB-C91C5153A000 Content-Type: multipart/alternative; boundary="Apple-Mail=_17F63CDA-C87C-468E-B304-EF34196D07DE" --Apple-Mail=_17F63CDA-C87C-468E-B304-EF34196D07DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I finally had a chance to take a look at the latest version of the = threat analysis document. Months ago, I pointed out that the document presents a lopsided view of = the potential types of attacks, in general considering only attacks in = which CAs or log servers misbehave =E2=80=9Cin place=E2=80=9D, while = completely neglecting even to mention the large class of attack = scenarios in which an attacker steals the servers=E2=80=99 keys and uses = them to create secret =E2=80=9Cevil twins=E2=80=9D of the CAs and/or log = servers elsewhere on the Internet (or off the Internet) in domains more = under the attacker=E2=80=99s control. In other words, the attacker = leaves the =E2=80=9Cnormal=E2=80=9D CAs and log servers that most of the = Internet sees operating completely normally and appearing to be honest, = but creates and uses evil twins of those CAs and log servers elsewhere = for (basically undetectable) attacks against target victims. As far as I can see, this entire class of threats is still not even = mentioned in the threat analysis document, let alone analyzed. This = seems to me to be a fairly serious omission for a document that is = supposed to be a comprehensive threat model analysis for CT. The currently-raging Apple vs FBI case represents a great example of = such a threat, as explained in my recent Freedom to Tinker blog post: = https://freedom-to-tinker.com/blog/bford/apple-fbi-and-software-transparen= cy/ = In short, suppose the FBI were attempting to secretly (rather than = publicly) coerce Apple to sign their backdoored software update, and = further suppose that the iPhone in question used something like = Certificate Transparency in attempt to provide transparency to software = updates. The FBI would not need to, and probably would not want to, = make Apple=E2=80=99s software update server (i.e., =E2=80=9CCA=E2=80=9D) = misbehave publicly, or to make the CT log servers on which those updates = are normally logged misbehave publicly - but they wouldn=E2=80=99t need = to. They could instead just commandeer the keys of the =E2=80=9CCA=E2=80=9D= (Apple=E2=80=99s update server) and any two CT log servers (e.g., any = two that conveniently happen to be in the US) - or just coerce the = holders of those keys to secretly produce signatures of the FBI=E2=80=99s = choosing - to produce not only an apparently correctly-signed software = update but also the fake SCTs, signed log-heads, or whatever needed to = persuade the CT-enhanced iPhone that the correctly-signed software = update has also been =E2=80=9Clogged=E2=80=9D. =20 But of course the FBI need not and would not ever need to show those = fake signatures or logs to anyone but the iPhone in question, =E2=80=9Cin = utmost secrecy=E2=80=9D (the FBI=E2=80=99s words). The target/victim of = the attack in this case is held and thus completely =E2=80=9Ccaptured=E2=80= =9D by the FBI: it will never have any opportunity to gossip with the = outside world to compare SCTs or log heads or anything. Thus, the FBI = has created a =E2=80=9Cevil twins=E2=80=9D of both the CA (software = update server) and log servers in attacker-controlled territory while = leaving the public versions of those services completely untouched and = apparently working fine as far as everyone else sees, and CT completely = fails to reveal the existence of these evil twins or the = =E2=80=9Cmisissuance=E2=80=9D (backdoored software updates) they have = been used to sign. If this working group has decided that threats of this form are not of = interest or too unlikely to happen (despite the events playing out right = now), then I do not have the time to keep arguing the point. But at the = very least, the threat model analysis document should simply pretend = that such attack scenarios do not exist at all. Bryan > On Mar 2, 2016, at 12:15 PM, Paul Wouters wrote: >=20 >=20 > This starts a two week WGLC for draft-ietf-trans-threat-analysis >=20 > https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ >=20 > The purpose of the WG Last Call is to get working group consensus that > the document is complete and provides a threat analysis that is useful > to implementors of CT. If you feel this document should not proceed, > please also let us know why you think so. >=20 > Please send all comments to the list. >=20 > The WGLC ends on March 16, 2016 >=20 > Paul & Melinda >=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_17F63CDA-C87C-468E-B304-EF34196D07DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I finally had a chance to take a look at the = latest version of the threat analysis document.

Months ago, I pointed out that the = document presents a lopsided view of the potential types of attacks, in = general considering only attacks in which CAs or log servers misbehave = =E2=80=9Cin place=E2=80=9D, while completely neglecting even to mention = the large class of attack scenarios in which an attacker steals the = servers=E2=80=99 keys and uses them to create secret =E2=80=9Cevil = twins=E2=80=9D of the CAs and/or log servers elsewhere on the Internet = (or off the Internet) in domains more under the attacker=E2=80=99s = control.  In other words, the attacker leaves the =E2=80=9Cnormal=E2=80= =9D CAs and log servers that most of the Internet sees operating = completely normally and appearing to be honest, but creates and uses = evil twins of those CAs and log servers elsewhere for (basically = undetectable) attacks against target victims.

As far as I can see, this entire class = of threats is still not even mentioned in the threat analysis document, = let alone analyzed.  This seems to me to be a fairly serious = omission for a document that is supposed to be a comprehensive threat = model analysis for CT.

The currently-raging Apple vs FBI case represents a great = example of such a threat, as explained in my recent Freedom to Tinker = blog post:

https://freedom-to-tinker.com/blog/bford/apple-fbi-and-software= -transparency/

In short, suppose the FBI were attempting to secretly (rather = than publicly) coerce Apple to sign their backdoored software update, = and further suppose that the iPhone in question used something like = Certificate Transparency in attempt to provide transparency to software = updates.  The FBI would not need to, and probably would not want = to, make Apple=E2=80=99s software update server (i.e., =E2=80=9CCA=E2=80=9D= ) misbehave publicly, or to make the CT log servers on which those = updates are normally logged misbehave publicly - but they wouldn=E2=80=99t= need to.  They could instead just commandeer the keys of the = =E2=80=9CCA=E2=80=9D (Apple=E2=80=99s update server) and any two CT log = servers (e.g., any two that conveniently happen to be in the US) - or = just coerce the holders of those keys to secretly produce signatures of = the FBI=E2=80=99s choosing - to produce not only an apparently = correctly-signed software update but also the fake SCTs, signed = log-heads, or whatever needed to persuade the CT-enhanced iPhone that = the correctly-signed software update has also been =E2=80=9Clogged=E2=80=9D= .  

But = of course the FBI need not and would not ever need to show those fake = signatures or logs to anyone but the iPhone in question, =E2=80=9Cin = utmost secrecy=E2=80=9D (the FBI=E2=80=99s words).  The = target/victim of the attack in this case is held and thus completely = =E2=80=9Ccaptured=E2=80=9D by the FBI: it will never have any = opportunity to gossip with the outside world to compare SCTs or log = heads or anything.  Thus, the FBI has created a =E2=80=9Cevil = twins=E2=80=9D of both the CA (software update server) and log servers = in attacker-controlled territory while leaving the public versions of = those services completely untouched and apparently working fine as far = as everyone else sees, and CT completely fails to reveal the existence = of these evil twins or the =E2=80=9Cmisissuance=E2=80=9D (backdoored = software updates) they have been used to sign.

If this working group has decided that = threats of this form are not of interest or too unlikely to happen = (despite the events playing out right now), then I do not have the time = to keep arguing the point.  But at the very least, the threat model = analysis document should simply pretend that such attack scenarios do = not exist at all.

Bryan

On Mar 2, 2016, at 12:15 PM, Paul Wouters = <paul@nohats.ca> = wrote:


This starts a two week WGLC for = draft-ietf-trans-threat-analysis

https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analys= is/

The purpose of the WG Last Call is = to get working group consensus that
the document is = complete and provides a threat analysis that is useful
to = implementors of CT. If you feel this document should not proceed,
please also let us know why you think so.

Please send all comments to the list.

The WGLC ends on March 16, 2016

Paul & Melinda


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

= --Apple-Mail=_17F63CDA-C87C-468E-B304-EF34196D07DE-- --Apple-Mail=_97842D2C-8025-4C12-A2EB-C91C5153A000 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 Fw0xNjAzMTYxNjAwNTlaMCMGCSqGSIb3DQEJBDEWBBRiuPKLEHMbOUFYWS7/alovCEdJODCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAI+M76NtR7gxptE77BJp9+7nvWsCarPpvPzxgTq4w24M/VYKGeGYRkZ56gV5sRZeC TWzoCGTjYPgKHyHSmO0GNYeF+LxU0VLs9mKKxEToalL/jUDtmt/xNsL3c/YqwRIqdODzW9ghyGu8 HDMLEaqxke8djRhWjcbEq+PDGPYtiSQj+C3kN/7/nr9tLfRnC+os2hH0aowHNAh4DRaAP9HKfwZH Jpn4T0GONLulIm+935MS7ZNo4xW7g/TFfoZ0I+jyh538VvZ8Wg5Qpw6CV6nKCZ4Au3uALbZvkGsm hM72u91WD0PDGqdGW29828LE/N1cRWJe/BUvEJZA05dtKmtvrwAAAAAAAA== --Apple-Mail=_97842D2C-8025-4C12-A2EB-C91C5153A000-- From nobody Wed Mar 16 09:50:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A2A12D65D for ; Wed, 16 Mar 2016 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25DBYioL45ZA for ; Wed, 16 Mar 2016 09:50:03 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 49CE312DA03 for ; Wed, 16 Mar 2016 09:49:59 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id n190so66603901iof.0 for ; Wed, 16 Mar 2016 09:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=UoDJTgvJKCWdJ+QW3R2ihX9IM6j1sI0Ou9/htqWh0GY=; b=hlPs+VwZqUwL7b5m6sl5zeaSSm7YXuidi/knISlEXPUk8b75w+l8L2lM3OPEbkYKoo 0tzqAIrCKIigakTeAxUm2UtklYlS7HqmEg8AeNERYn3CBCS038OIov30vv/jkvJKH44Q DgaqNca28r7etuLmjM9lmn3RCQ5GFovJ/bPl3rg8aE72cN0BProcGiLDP2fb5GVksi4O f32cirk1OY84YwXNQ9hFUzPKCP5GNrC+el3jIPbOmsEqhjRQ9fpPqLDtxJR7Kh/yzgQe gKWezqCPXFcYEko2QolOLBHNwxB6ybX1D0Dy3AXLWq3rWJNbo/ZHxzcMkGbBa2kr8cOv 5Jlg== 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-transfer-encoding; bh=UoDJTgvJKCWdJ+QW3R2ihX9IM6j1sI0Ou9/htqWh0GY=; b=XCpDQy6X/6mXM3dfxhklsc/t6XSQ57QBMZEOoZR0osVTfAuQ2HpTcstKYb191sE+EJ XVrnbaa0atHRg6NEkHF3csIgaHqn1aXDBtFXj/0r6L1ffVL66kslnpDV4YUNpKIwi6LI M8xLECr123Yekdf4CYbs9bJK7b6/+UXEFzhrj39+ZOwkI0GxBgQEsapxYyYIDlsN2y6b vsmzGRBIOlU+A1saZVi2zL2r3NNJx9FhHiDICjtem9kpeLIvUe7NF5MXa/jBRgDOYsL7 v9I+hpqnViCP+reVJhXhiKm2NAHOHI6dumn5u2WHLwYPG+fLge7N7iRQoPbV4JJUmK0p +Tfg== X-Gm-Message-State: AD7BkJJJdrGuD8Tppev2rGWr3tgmwoedHo98L5L4Sjd4frAeYtgPEE0e761XdyxrXYPBGaPOn4l5hlqNELU3nYSp MIME-Version: 1.0 X-Received: by 10.107.26.201 with SMTP id a192mr5017389ioa.13.1458146998269; Wed, 16 Mar 2016 09:49:58 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Wed, 16 Mar 2016 09:49:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 16:49:58 +0000 Message-ID: From: Ben Laurie To: Bryan Ford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Paul Wouters , Trans , Melinda Shore Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 16:50:06 -0000 On 16 March 2016 at 16:00, Bryan Ford wrote: > I finally had a chance to take a look at the latest version of the threat > analysis document. > > Months ago, I pointed out that the document presents a lopsided view of t= he > potential types of attacks, in general considering only attacks in which = CAs > or log servers misbehave =E2=80=9Cin place=E2=80=9D, while completely neg= lecting even to > mention the large class of attack scenarios in which an attacker steals t= he > servers=E2=80=99 keys and uses them to create secret =E2=80=9Cevil twins= =E2=80=9D of the CAs and/or > log servers elsewhere on the Internet (or off the Internet) in domains mo= re > under the attacker=E2=80=99s control. In other words, the attacker leave= s the > =E2=80=9Cnormal=E2=80=9D CAs and log servers that most of the Internet se= es operating > completely normally and appearing to be honest, but creates and uses evil > twins of those CAs and log servers elsewhere for (basically undetectable) > attacks against target victims. > > As far as I can see, this entire class of threats is still not even > mentioned in the threat analysis document, let alone analyzed. This seem= s > to me to be a fairly serious omission for a document that is supposed to = be > a comprehensive threat model analysis for CT. > > The currently-raging Apple vs FBI case represents a great example of such= a > threat, as explained in my recent Freedom to Tinker blog post: > > https://freedom-to-tinker.com/blog/bford/apple-fbi-and-software-transpare= ncy/ > > In short, suppose the FBI were attempting to secretly (rather than public= ly) > coerce Apple to sign their backdoored software update, and further suppos= e > that the iPhone in question used something like Certificate Transparency = in > attempt to provide transparency to software updates. The FBI would not n= eed > to, and probably would not want to, make Apple=E2=80=99s software update = server > (i.e., =E2=80=9CCA=E2=80=9D) misbehave publicly, or to make the CT log se= rvers on which > those updates are normally logged misbehave publicly - but they wouldn=E2= =80=99t > need to. They could instead just commandeer the keys of the =E2=80=9CCA= =E2=80=9D (Apple=E2=80=99s > update server) and any two CT log servers (e.g., any two that convenientl= y > happen to be in the US) - or just coerce the holders of those keys to > secretly produce signatures of the FBI=E2=80=99s choosing - to produce no= t only an > apparently correctly-signed software update but also the fake SCTs, signe= d > log-heads, or whatever needed to persuade the CT-enhanced iPhone that the > correctly-signed software update has also been =E2=80=9Clogged=E2=80=9D. > > But of course the FBI need not and would not ever need to show those fake > signatures or logs to anyone but the iPhone in question, =E2=80=9Cin utmo= st secrecy=E2=80=9D > (the FBI=E2=80=99s words). The target/victim of the attack in this case = is held and > thus completely =E2=80=9Ccaptured=E2=80=9D by the FBI: it will never have= any opportunity to > gossip with the outside world to compare SCTs or log heads or anything. > Thus, the FBI has created a =E2=80=9Cevil twins=E2=80=9D of both the CA (= software update > server) and log servers in attacker-controlled territory while leaving th= e > public versions of those services completely untouched and apparently > working fine as far as everyone else sees, and CT completely fails to rev= eal > the existence of these evil twins or the =E2=80=9Cmisissuance=E2=80=9D (b= ackdoored software > updates) they have been used to sign. > > If this working group has decided that threats of this form are not of > interest or too unlikely to happen (despite the events playing out right > now), then I do not have the time to keep arguing the point. But at the > very least, the threat model analysis document should simply pretend that > such attack scenarios do not exist at all. I do agree that these attacks can be mounted, and are in fact already discussed in general in 6962 and 6962-bis (s7.3 for the latter). I have still not yet had the time to thoroughly review the threat analysis document, so I can't comment on it at this time. In general, it seems hard to defend against attacks that permanently separate their victims from the rest of the world - and it also seems hard to mount such an attack. From nobody Wed Mar 16 10:13:54 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31C12D596 for ; Wed, 16 Mar 2016 10:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9mixEzu4HYa for ; Wed, 16 Mar 2016 10:13:50 -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 8373012D518 for ; Wed, 16 Mar 2016 10:13:50 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:47887 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agF13-0008An-Ad for trans@ietf.org; Wed, 16 Mar 2016 13:13:49 -0400 To: trans@ietf.org References: <56E6CD30.8070102@bbn.com> <56E71E2B.1050407@gmail.com> <0c7953b1f0b54c57a87a5497bc4eea23@usma1ex-dag1mb1.msg.corp.akamai.com> From: Stephen Kent Message-ID: <56E9944C.5040200@bbn.com> Date: Wed, 16 Mar 2016 13:13:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <0c7953b1f0b54c57a87a5497bc4eea23@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:13:53 -0000 Good point. I'll move DKGs acknowledgement the Acknowledgments section. Steve On 3/14/16 4:25 PM, Salz, Rich wrote: >>> Do we generally credit individuals in docs? >> Yes, there should be an acknowledgments section when appropriate. > Right, of course, and credit him there for this. But in the prose? When say there's no literature to point to? Shrug. Not a big deal. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Wed Mar 16 10:44:25 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5B12D63A for ; Wed, 16 Mar 2016 10:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeA9G1euejQv for ; Wed, 16 Mar 2016 10:44:22 -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 BCC2712D61A for ; Wed, 16 Mar 2016 10:44:20 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:39989 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agFUX-000B7n-CY; Wed, 16 Mar 2016 13:44:17 -0400 From: Stephen Kent To: Ben Laurie References: <56E6CD30.8070102@bbn.com> Message-ID: <56E99B71.7060003@bbn.com> Date: Wed, 16 Mar 2016 13:44:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 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] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:44:23 -0000 zBen, > On 14 March 2016 at 14:39, Stephen Kent wrote: >> The logged bogus certificate can be detected by a Monitor (third party or >> self), that is watching the log(s) to which the certificate was posted. Thus >> the detection aspect of CT still works with regard to this certificate. When >> this certificate is detected, the CA that logged the certificate may revoke >> it, i.e., place it on a CRL or create an OCSP response for it. However, a >> browser checking a CRL or OCSP response will not match this revocation >> status data against the other, not-logged bogus certificate. (This is >> because revocation status checking is performed in the context of a >> certificate path and the two bogus certificates have different certificate >> paths.) Revoking a detected, bogus certificate may be the best strategy for >> the malicious CAs. It makes issuance of the bogus certificate appear to be >> an accident, and thus browser vendors may not feel the need to make an entry >> on their blacklists for the bogus certificate or the CA that issued it. > I do not believe this is correct. And if it is, it is a serious bug in > revocation that has nothing to do with certificate transparency. What do you believe is incorrect about my description of revocation status checking? A relying party validates a cert by walking down a cert pat from a trust anchor to a target cert. In DKG's example, the two CAs with the same name have different trust anchor parents, thus there are two distinct paths. A CRL (or OCSP response) issued by a CA on one path is totally independent from A CRL (or OSCSP response) issued by a CA on a distinct path. > Also, I don't get the logic of the "not-logged bogus certificate", > which is identical to the logged certificate - and is therefore > logged. And not bogus. A cert is bogus when it is issued to an entity that is not authorized to represent the Subject of the cert. This is true whether the cert is logged or not. Steve From nobody Wed Mar 16 10:45:46 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FC012D5A4 for ; Wed, 16 Mar 2016 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yny3pVQkSJsD for ; Wed, 16 Mar 2016 10:45:42 -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 7021112D652 for ; Wed, 16 Mar 2016 10:45:40 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48425 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agFVr-0008ud-Hk for trans@ietf.org; Wed, 16 Mar 2016 13:45:39 -0400 From: Stephen Kent To: trans@ietf.org References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> Message-ID: <56E99BC3.80606@bbn.com> Date: Wed, 16 Mar 2016 13:45:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E737EC.9020203@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:45:44 -0000 Rob, > On 14/03/16 21:39, Ben Laurie wrote: >> On 14 March 2016 at 14:39, Stephen Kent wrote: >>> The logged bogus certificate can be detected by a Monitor (third >>> party or >>> self), that is watching the log(s) to which the certificate was >>> posted. Thus >>> the detection aspect of CT still works with regard to this >>> certificate. When >>> this certificate is detected, the CA that logged the certificate may >>> revoke >>> it, i.e., place it on a CRL or create an OCSP response for it. >>> However, a >>> browser checking a CRL or OCSP response will not match this revocation >>> status data against the other, not-logged bogus certificate. (This is >>> because revocation status checking is performed in the context of a >>> certificate path and the two bogus certificates have different >>> certificate >>> paths.) Revoking a detected, bogus certificate may be the best >>> strategy for >>> the malicious CAs. It makes issuance of the bogus certificate appear >>> to be >>> an accident, and thus browser vendors may not feel the need to make >>> an entry >>> on their blacklists for the bogus certificate or the CA that issued it. >> >> I do not believe this is correct. And if it is, it is a serious bug in >> revocation that has nothing to do with certificate transparency. >> >> Also, I don't get the logic of the "not-logged bogus certificate", >> which is identical to the logged certificate - and is therefore >> logged. And not bogus. > > +1 > > The "two" bogus certificates are one and the same. They will contain > the same CRL and/or OCSP URLs. The outcome of a CRL/OCSP check will > be exactly the same for both certs. There is no requirement for a cert to contain a back pointer to the CRL on which it would be listed or to provide OCSP info. The extension (AIA) that enables these capabilities is not required by 5280 and because it is not marked critical, there is no requirement for all relyng parties to be able to process it. 4.2.2.1. Authority Information Access The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears. Information and services may include on-line validation services and CA policy data. (The location of CRLs is not specified in this extension; that information is provided by the cRLDistributionPoints extension.) This extension may be included in end entity or CA certificates. Conforming CAs MUST mark this extension as non-critical. > > AIUI, for DKG's attack to work, it is necessary for: > - the "two" bogus certificates to _not_ be revoked. disagree, see above. > - one of the doppelganger intermediates to be logged and revoked. logged, yes. blacklisted, maybe. > - the other one (or more) of the doppelganger intermediates to be > neither logged nor revoked. agreed. > I think that there are two possible ways to thwart this attack: > > 1. Redefine SCTs so that they become SCCTs (Signed Certificate Chain > Timestamps) - i.e. the signature is calculated over the entire chain > submitted. I think this is unworkable, because there are too many > cases where different chains are legitimate and even expected. > > 2. Declare that this is not a problem with CT. It's a problem with > using CRL and/or OCSP to revoke intermediates. my example does not assume that an intermediate CA cert was revoked. It suggests that a clever, malicious CA might revoke the bogus EE cert to deflect suspicion from itself and to avoid having browser vendors blacklist the CA or the bogus cert. > So we (where "we" may or may not be TRANS) need to fix revocation! > Revoking an intermediate _certificate_ just isn't sufficient. > To be effective, the intermediate _public key_ needs to be revoked > somehow. One does not revoke keys in a PKI. One revokes certs. Steve From nobody Wed Mar 16 10:46:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1DE12D5E0 for ; Wed, 16 Mar 2016 10:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHlqlxkDV8um for ; Wed, 16 Mar 2016 10:46:06 -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 5865512D5B0 for ; Wed, 16 Mar 2016 10:46:06 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:40034 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agFWH-000B8l-FF for trans@ietf.org; Wed, 16 Mar 2016 13:46:05 -0400 From: Stephen Kent To: trans@ietf.org References: <56E6CD30.8070102@bbn.com> <56E737EC.9020203@comodo.com> Message-ID: <56E99BDD.4050905@bbn.com> Date: Wed, 16 Mar 2016 13:46:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:46:07 -0000 Ben, > Oh, also: > > 4. Require SCTs for all certs in the chain, which prevents hiding the > alternate intermediate. If one were to do this, then it would seem to be a significant change to the CT design, affecting TLS clients, CAs, and Subjects (who acquire SCTs for themselves). Do you really want to mandate this? Steve From nobody Wed Mar 16 10:47:23 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3AD12DA57 for ; Wed, 16 Mar 2016 10:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud-QtbP6q7v0 for ; Wed, 16 Mar 2016 10:47:19 -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 82B8812D5E0 for ; Wed, 16 Mar 2016 10:47:08 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48460 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agFXH-0008wP-I6 for trans@ietf.org; Wed, 16 Mar 2016 13:47:07 -0400 From: Stephen Kent To: trans@ietf.org References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> Message-ID: <56E99C1B.4080602@bbn.com> Date: Wed, 16 Mar 2016 13:47:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E822E8.7000704@nist.gov> Content-Type: multipart/alternative; boundary="------------040604020903080800060403" Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:47:21 -0000 This is a multi-part message in MIME format. --------------040604020903080800060403 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit David, > As others have pointed out, the description below is fundamentally > flawed, and as a result the conclusion is flawed as well. See comments > in-line below. Others are wrong :-). > ... >> >> In fact, an attack of the sort Gilmor envisioned can be mounted by >> any two CAs that are not name-constrained; the attack need not be >> initiated by trust anchors per se. (Also note that X.509 and RFC 5280 >> do not preclude creation of doppelganger CAs; the requirement for >> Subject name uniqueness applies individually to each CA but not >> across CA boundaries, and there is no requirement for public key >> uniqueness across CAs.) >> > > This is incorrect! X.509 requires name uniqueness, including across CA > boundaries. [Since this issue isn't relevant to the "conspiring CAs > attack," information about this inaccuracy is at the end of the email. David still believes that the X.500 directory tree is the basis for all names in certs. of course this is not even remotely true, and 5280 is quite clear about this. But I am happy to avoid this argument by omitting the reference to X.509, since we're discussing Internet standards and thus RFC 5280 is relevant reference. > >> The attack requires that both of the doppelganger CAs issue a >> certificate for a targeted Subject (e.g., web site). These two (EE) >> certificates are identical; they contain the same name, public key, >> serial number, etc. Only one of the malicious CAs logs a bogus >> certificate and acquires an SCT for it. Because the bogus >> certificates are identical, the SCT will match both. >> > > As noted by others, if the two (EE) certificates are identical, then > there is only one EE certificate. So, in the scenario described above, > there aren't two intermediate CAs and two (identical) EE certificates. > There are two trust anchors, each issuing a certificate to a single > subordinate CA, which in turn has issued a single EE certificate > identifying the target Subject: wrong, again. In the scenaior there are two distinct, intermediate CAs, with distinct parents. The CA certs for the malicious CAs are different, e.g., at a minimum they have different Issuer names. The question of whether there are one or two bogus certs strikes me as an existential distinction. I'm not going spend my time rebuting the rest of your analysis, as it is based on a faulty interpretation of what I wrote, and is illustrated with diagrams that don't match the scenario that DKG and I are describe. Steve --------------040604020903080800060403 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit David,


As others have pointed out, the description below is fundamentally flawed, and as a result the conclusion is flawed as well. See comments in-line below.
Others are wrong :-).
...

In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not name-constrained; the attack need not be initiated by trust anchors per se. (Also note that X.509 and RFC 5280 do not preclude creation of doppelganger CAs; the requirement for Subject name uniqueness applies individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.)


This is incorrect! X.509 requires name uniqueness, including across CA boundaries. [Since this issue isn't relevant to the "conspiring CAs attack," information about this inaccuracy is at the end of the email.

David still believes that the X.500 directory tree is the basis for all names in certs.
of course this is not even remotely true, and 5280 is quite clear about this. But I am happy
to avoid this argument by omitting the reference to X.509, since we're discussing Internet
standards and thus RFC 5280 is relevant reference.

The attack requires that both of the doppelganger CAs issue a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs a bogus certificate and acquires an SCT for it. Because the bogus certificates are identical, the SCT will match both.


As noted by others, if the two (EE) certificates are identical, then there is only one EE certificate. So, in the scenario described above, there aren't two intermediate CAs and two (identical) EE certificates. There are two trust anchors, each issuing a certificate to a single subordinate CA, which in turn has issued a single EE certificate identifying the target Subject:
wrong, again. In the scenaior there are two distinct, intermediate CAs, with distinct parents.
The CA certs for the malicious CAs are different, e.g., at a minimum they have different Issuer names.
The question of whether there are one or two bogus certs strikes me as an existential distinction.

I'm not going spend my time rebuting the rest of your analysis, as it is based on a faulty interpretation
of what I wrote, and is illustrated with diagrams that don't match the scenario that DKG and
I are describe.

Steve


--------------040604020903080800060403-- From nobody Wed Mar 16 10:50:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2769A12DA4A for ; Wed, 16 Mar 2016 10:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SISId9VTsDS for ; Wed, 16 Mar 2016 10:50:51 -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 D3E4512D52D for ; Wed, 16 Mar 2016 10:50:51 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48495 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agFas-00090X-Uq for trans@ietf.org; Wed, 16 Mar 2016 13:50:51 -0400 From: Stephen Kent To: trans@ietf.org References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> <068.0779562256ffb55d064ab4f9e5d0a31c@tools.ietf.org> Message-ID: <56E99CFA.8010601@bbn.com> Date: Wed, 16 Mar 2016 13:50:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <068.0779562256ffb55d064ab4f9e5d0a31c@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:50:53 -0000 Eran, > #118: Monitor function description problem > > Changes (byeranm@google.com): > > * owner:draft-ietf-trans-rfc6962-bis@tools.ietf.org =>eranm@google.com > > > Comment: > > Is the problem here that the term 'monitoring' means something different > in this context, making the introduction and Section 9.3. inconsistent? > I can suggest a few resolutions: > (1) Replacing the word 'monitor' in the introduction with 'watch'. > (2) Modify the Monitor section to indicate a monitor can either ensure > logs behave correctly, watch for certificates of interest or do both. In most prior versions of 6962-bis, Auditing has focused on detecting mis-behaving logs. Why not stick with that characterization of the function? Your suggestion #2 above seems to make Monitors overlap with Auditors, rather than having simple, distinct definitions for them. Let's say that a Monitor observes an enumerated set of logs for certs of interest, so that it can inform Subjects if there is evidence that a bogus cert has been logged (relative to the Subject in question). An Auditor observes an enumerated set of losg to detect log misbehavior. These are roughly the ways that draft-kent-trans-monitor-auditor-00.txt characterizes the two functions. Steve From nobody Wed Mar 16 11:12:37 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF2912DA57 for ; Wed, 16 Mar 2016 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wyz9DnJKDUj for ; Wed, 16 Mar 2016 11:12:33 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C5012D596 for ; Wed, 16 Mar 2016 11:12:31 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 16 Mar 2016 14:13:59 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.406.0; Wed, 16 Mar 2016 14:12:29 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2GICF39026105; Wed, 16 Mar 2016 14:12:15 -0400 To: Stephen Kent , References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> From: "David A. Cooper" Message-ID: <56E9A1FF.4050301@nist.gov> Date: Wed, 16 Mar 2016 14:12:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E99C1B.4080602@bbn.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:12:35 -0000
I have never believed that "the X.500 directory tree is the basis for all names in certs.," and you know that! Nor does that have anything to do with what I said in my previous email.

There's no reason for you to rebut my analysis. What is needed is for someone to write a description of the attack scenario that accurately describes the attack scenario DKG presented, and the text you proposed doesn't do that.

If my description of the scenario is so wrong, then please explain (in detail) how a relying party would be able to determine that there are two distinct intermediate CAs in this scenario and not a single CA that has been issued cross-certificates by two different roots (as depicted in my diagrams) and how that fits in with your response to Ben Laurie that:
A relying party validates a cert by walking down a cert pat from a trust anchor to
a target cert. In DKG's example, the two CAs with the same name have different
trust anchor parents, thus there are two distinct paths. A CRL (or OCSP response)
issued by a CA on one path is totally independent from A CRL (or OSCSP response)
issued by a CA on a distinct path.
What information (specifically) would appear in a CRL or OCSP response issued by a CA on one path that would make it distinguishable to a relying party from a CRL or OCSP response issued by a CA on the other path in the scenario DKG described?

On 03/16/2016 01:47 PM, Stephen Kent wrote:
David,


As others have pointed out, the description below is fundamentally flawed, and as a result the conclusion is flawed as well. See comments in-line below.
Others are wrong :-).
...

In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not name-constrained; the attack need not be initiated by trust anchors per se. (Also note that X.509 and RFC 5280 do not preclude creation of doppelganger CAs; the requirement for Subject name uniqueness applies individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.)


This is incorrect! X.509 requires name uniqueness, including across CA boundaries. [Since this issue isn't relevant to the "conspiring CAs attack," information about this inaccuracy is at the end of the email.

David still believes that the X.500 directory tree is the basis for all names in certs.
of course this is not even remotely true, and 5280 is quite clear about this. But I am happy
to avoid this argument by omitting the reference to X.509, since we're discussing Internet
standards and thus RFC 5280 is relevant reference.

The attack requires that both of the doppelganger CAs issue a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs a bogus certificate and acquires an SCT for it. Because the bogus certificates are identical, the SCT will match both.


As noted by others, if the two (EE) certificates are identical, then there is only one EE certificate. So, in the scenario described above, there aren't two intermediate CAs and two (identical) EE certificates. There are two trust anchors, each issuing a certificate to a single subordinate CA, which in turn has issued a single EE certificate identifying the target Subject:
wrong, again. In the scenaior there are two distinct, intermediate CAs, with distinct parents.
The CA certs for the malicious CAs are different, e.g., at a minimum they have different Issuer names.
The question of whether there are one or two bogus certs strikes me as an existential distinction.

I'm not going spend my time rebuting the rest of your analysis, as it is based on a faulty interpretation
of what I wrote, and is illustrated with diagrams that don't match the scenario that DKG and
I are describe.

Steve




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

From nobody Wed Mar 16 11:13:47 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F4312D616 for ; Wed, 16 Mar 2016 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvsMIGODisTt for ; Wed, 16 Mar 2016 11:13:43 -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 BCCFC12DA69 for ; Wed, 16 Mar 2016 11:07:59 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48722 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agFrS-0009Pn-Jd for trans@ietf.org; Wed, 16 Mar 2016 14:07:58 -0400 To: "trans@ietf.org" From: Stephen Kent Message-ID: <56E9A0FE.1080002@bbn.com> Date: Wed, 16 Mar 2016 14:07:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070901050409000406010304" Archived-At: Subject: [Trans] revised text for colluding, malicious CAs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:13:45 -0000 This is a multi-part message in MIME format. --------------070901050409000406010304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit - removed the reference to DKG (it will appear in the Acknowledgements section) - used "doppelganger" to refer to the bogus EE cert, trying to avoid the question of whether there are one or two bogus certs - removed reference to X.509 (to make David Cooper happier) - clarified why revocation by one malicious CA does not cause the doppleganger EE cert to be treated as revoked by relying parties - noted the constraint that the two malicious CAs must not have a common trust anchor Steve ----- 3.3 Malicious, Colluding CAs Section 3.2 examined attacks in which a single CA issued a bogus certificate. There is also the potential that two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the remediation safeguards envisioned by CT. In general, any two CAs that are not name-constrained and do not share a common path to a trust anchor can collude to create a “doppelganger” EE certificate that is bogus. The attack need not be initiated by trust anchors; any subordinate pair of (not name-constrained) CAs can effect this attack without the knowledge of superiors CAs. (Also note that X. RFC 5280 do not preclude creation of doppelganger certificates for either CAs or EEs. Requirements for Subject name uniqueness apply individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.) The attack requires that each of the colluding CAs issues a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical, hence the use of the term “doppelganger”; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs the bogus certificate and acquires an SCT for it. The logged bogus certificate can be detected by a Monitor (third party or self), that is watching the log(s) to which the certificate was posted. Thus the detection aspect of CT still works with regard to this certificate. When this certificate is detected, the CA that logged the certificate may choose to revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response may not match this revocationstatus data against the doppelganger certificate; revocation status checking is performed in the context of a certificate path and the doppelganger certificates have different certificate paths. Revoking a detected, bogus certificatemay be the best strategy for the malicious CA that logged the certificate; it makes issuance of the bogus certificate appear to be an accident, and thus browser vendors may not feel the need to make an entry on their blacklists for the bogus certificate or the CA that issued it. (If the bogus certificate included an AIA extension providing information for revocation status checking, revocation by the CA that logged the bogus certificate would not be an effective strategy. However, inclusion of this extension is not mandated by RFC 5280. Also the extension is not critical, meaning that relying parties are not required to be able to process it.) If the CA that logged the bogus certificate fails to revoke it, browser vendors might blacklist the certificate. However, as noted above, the doppelganger, which was not logged, will match the SCT created for the logged certificate. If remediation is effected by blacklisting (instead of revocation by one of the malicious CAs) then the ability of CT to deal with this sort of attack may be diminished. Some forms of blacklisting will cause the not-logged bogus certificate to be detected and rejected, while others will not, depending on the details of the blacklisting mechanism. Mechanisms for blacklisting by browsers are not specified in any IETF standards. The mechanisms are browser-specific, and the choice of how to blacklist (e.g., the bogus certificate vs. the CA that issued it) are the purview of each browser vendor. Thus, depending on the details of the blacklist mechanism and the way that a browser vendor chooses to manage this list, a doppelganger CA attack might or might not pose a problem in terms of successful remediation of the attack. --------------070901050409000406010304 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit     - removed the reference to DKG (it will appear in the Acknowledgements section)

    - used "doppelganger" to refer to the bogus EE cert, trying to avoid the
      question of whether there are one or two bogus certs

    - removed reference to X.509 (to make David Cooper happier)

    - clarified why revocation by one malicious CA does not cause the doppleganger
      EE cert to be treated as revoked by relying parties

    - noted the constraint that the two malicious CAs must not have a common trust anchor

Steve
-----

3.3 Malicious, Colluding CAs

 

Section 3.2 examined attacks in which a single CA issued a bogus certificate. There is also the potential that two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the remediation safeguards envisioned by CT.

 

In general, any two CAs that are not name-constrained and do not share a common path to a trust anchor can collude to create a “doppelganger” EE certificate that is bogus. The attack need not be initiated by trust anchors; any subordinate pair of (not name-constrained) CAs can effect this attack without the knowledge of superiors CAs. (Also note that X. RFC 5280 do not preclude creation of doppelganger certificates for either CAs or EEs. Requirements for Subject name uniqueness apply individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.)

 

The attack requires that each of the colluding CAs issues a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical, hence the use of the term “doppelganger”; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs the bogus certificate and acquires an SCT for it.

 

The logged bogus certificate can be detected by a Monitor (third party or self), that is watching the log(s) to which the certificate was posted. Thus the detection aspect of CT still works with regard to this certificate. When this certificate is detected, the CA that logged the certificate may choose to revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response may not match this revocation  status data against the doppelganger certificate; revocation status checking is performed in the context of a certificate path and the doppelganger certificates have different certificate paths. Revoking a detected, bogus certificate  may be the best strategy for the malicious CA that logged the certificate; it makes issuance of the bogus certificate appear to be an accident, and thus browser vendors may not feel the need to make an entry on their blacklists for the bogus certificate or the CA that issued it. (If the bogus certificate included an AIA extension providing information for revocation status checking, revocation by the CA that logged the bogus certificate would not be an effective strategy. However, inclusion of this extension is not mandated by RFC 5280. Also the extension is not critical, meaning that relying parties are not required to be able to process it.)

 

If the CA that logged the bogus certificate fails to revoke it, browser vendors might blacklist the certificate. However, as noted above, the doppelganger, which was not logged, will match the SCT created for the logged certificate. If remediation is effected by blacklisting (instead of revocation by one of the malicious CAs) then the ability of CT to deal with this sort of attack may be diminished. Some forms of blacklisting will cause the not-logged bogus certificate to be detected and rejected, while others will not, depending on the details of the blacklisting mechanism. Mechanisms for blacklisting by browsers are not specified in any IETF standards. The mechanisms are browser-specific, and the choice of how to blacklist (e.g., the bogus certificate vs. the CA that issued it) are the purview of each browser vendor. Thus, depending on the details of the blacklist mechanism and the way that a browser vendor chooses to manage this list, a doppelganger CA attack might or might not pose a problem in terms of successful remediation of the attack.



--------------070901050409000406010304-- From nobody Wed Mar 16 11:34:49 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3910712DA8C for ; Wed, 16 Mar 2016 11:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZmN9tR0vcha for ; Wed, 16 Mar 2016 11:34:46 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 220B612DA90 for ; Wed, 16 Mar 2016 11:34:45 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id n5so84900524pfn.2 for ; Wed, 16 Mar 2016 11:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=c2BzfZkiDYCfp9ykbV+C2t9UxGLLT/kbOf8dLfelYmE=; b=Em2PqleZzQ3DPaa2QvS3oowqvjImRuc6qQoeO5DeBMTAtSK5cp1kHLCG9i+EHrQXzu HZmhKcN/UdpKB5K4Y5xAW2n2lR/LWhe1pXc6CtRq7G1Ey5aHfkFkERoDzrJnSHsCvYpa 8JbFSY7tFVQLZL6zD3NP8ryeKG9D5ZtVKwJalCpEVUE1f1MZHdh+5AV6dUarRihocul0 5ni2fzd+qSBrrDdrG5Kn8kWNmJfMVwew3oVfPuJAl5YsjwYuw1v5xx8NagIPGsropjy8 2Myses9TwB6Rxt0dASOMAumasKESHAiPK+EtSYqGBT3S98kT5fPJRet/za/q3J1Xbzbl ax3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=c2BzfZkiDYCfp9ykbV+C2t9UxGLLT/kbOf8dLfelYmE=; b=WvdGSihwjX04TL8ODqUyBKhsGDXT6pspQmJGCG8P0NxrPr4rtVNOJUYqKujSlaCfQj 2dK1EgDBAYhmiccEbup11SO2yc+hX1SFNXhYr5S+3vtZFCovj8/ZYFBmJFzLvILno0MZ 6KSf6SAUl39g8QrS6vMpCbVCJP3DsDgdy1eAp1RcsXpn5YZ9J+9+JeqcIDD3MXmwgfqT vRsvcc5R4Zehz/Zvh60UXBegNUise6SkXS7AYQ0ju8SRA9icPMYvkRZTjpyShBvi4jzE n38zkTF6Y9x+FjO60NiEaFRgmZ46EbgMdBcPEb+0rw2X3tCeU3diD6uzLrga6eAttGGa ElDA== X-Gm-Message-State: AD7BkJKfP2gfp7+68hsVLG6x5rpXGi2mvKLp6svJd9L11yBUiYbO99miwJusLNJbmta3GA== X-Received: by 10.66.226.135 with SMTP id rs7mr8410627pac.116.1458153284675; Wed, 16 Mar 2016 11:34:44 -0700 (PDT) Received: from [10.71.13.113] ([8.25.222.2]) by smtp.gmail.com with ESMTPSA id kw10sm7376358pab.0.2016.03.16.11.34.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 11:34:43 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9A8621DF-E212-4A2F-98F0-394945DDD058"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Bryan Ford In-Reply-To: Date: Wed, 16 Mar 2016 11:34:41 -0700 Message-Id: <9D88AE18-4C6F-4A16-9C52-DA6E5EA06195@gmail.com> References: To: Ben Laurie X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Paul Wouters , Trans , Melinda Shore Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:34:48 -0000 --Apple-Mail=_9A8621DF-E212-4A2F-98F0-394945DDD058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 16, 2016, at 9:49 AM, Ben Laurie wrote: > I do agree that these attacks can be mounted, and are in fact already > discussed in general in 6962 and 6962-bis (s7.3 for the latter). I don=E2=80=99t see a section 7.3 in draft-ietf-trans-rfc6962-bis-12, = which appears to be the latest version; did the section numbers change = recently and you=E2=80=99re referring to a different version? I would = most naturally expect such issues to be discussed in section 12 = =E2=80=9CSecurity Considerations=E2=80=9D, but see no obvious mention of = this class of attacks anywhere in there. > I have still not yet had the time to thoroughly review the threat > analysis document, so I can't comment on it at this time. Perhaps the WGLC shouldn=E2=80=99t close until at least the core CT = developers such as you have had a chance to do that review? > In general, it seems hard to defend against attacks that permanently > separate their victims from the rest of the world - and it also seems > hard to mount such an attack. Hard to defend: perhaps, but does that justify ignoring that entire = threat vector space in a threat analysis document? And do you (still) = maintain that collective signing is not a workable defence against = precisely such attacks? If so, I=E2=80=99m still curious why. Hard to mount: perhaps, but do you disagree that such an attack appears = to be exactly what the FBI is at the moment quite explicitly threatening = to perform against Apple (by threatening just to commandeer their = signing keys and sign their own backdoored software update)? And that = the FBI appears to be in a perfect position to perform such an attack = secretly even against a CT-hardened system, if they didn=E2=80=99t = happen to want the publicity like they seem to this time? Bryan --Apple-Mail=_9A8621DF-E212-4A2F-98F0-394945DDD058 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 Fw0xNjAzMTYxODM0NDJaMCMGCSqGSIb3DQEJBDEWBBQ0m5qF83An9MCCSJNi6Lia9PUMrTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAia+6AV1RDk2TlYH67Y632nXSUUuqHD3KRvapH50bUhTaCX/nRlvzkEJWHSFKNZmt 3V4zOxpUZs3ffMPjnqNz2NPlFFKZ87XbjJrDedxAWgdsjN8juIELGYCjR+hpQRRReBjTV442mbkg uKWmaE5LZYdWz+NRyxJmuF2OYsYMvxki/KWak17WIJz4zhwgqX5wJ+LbLE0aWPmPm0dukuxaVdKb wHpB69rm8kH7951g+OKgVAIa7g5zXMJiG+71a8EBbBYjPupN1sqGDH/+Gyi831+cjlp+YCwcIX2z 7VDu5eSlWz8qBPeqgxxjBDxha3IcLR5aUXMrL7+3AZssB308UQAAAAAAAA== --Apple-Mail=_9A8621DF-E212-4A2F-98F0-394945DDD058-- From nobody Wed Mar 16 11:48:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9742D12DA30 for ; Wed, 16 Mar 2016 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXomnnf-rRhY for ; Wed, 16 Mar 2016 11:48:37 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 630B612DA8C for ; Wed, 16 Mar 2016 11:48:33 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g203so70634041iof.2 for ; Wed, 16 Mar 2016 11:48:33 -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; bh=Z9/as8l/oAjKIT9h1MHESCoGnIidbC7QHA1ipd1mUhs=; b=b3CNDbiATB3JBi/qT2Q52AXcZxCKGoZnJdSpPY0aCMnNORy8LSerMtOgsy5Sk+2vzu UCf4AOyj+LJrRFp2jk7c0KZtkRvtMXbCmSOLcfudbERV3u8OFQkFRx+Lnz3n2IU80FaA KEXs1R8tX/fXO2UYmbUTjt5vAQsKTQQEQjnnfCYKdLnpBK5N30PTiL3GD1XmGWZOQ/Au WYvoXu2M2oZzJxy2jSXnHh1y0sYTRIEJWyOQmhB4i1cH7hyHYntLG2dDDe10cVPBO+d3 TfC6J/j4PR1J8V63xq/asdO5sHSa4FF/fwcYWAfo+NWhZM++T/X+VIqedX7oxb8O667m hO9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Z9/as8l/oAjKIT9h1MHESCoGnIidbC7QHA1ipd1mUhs=; b=OtJgmxyXvnKSjdjvDFMtRKwJox7G8UYnjCVtLuBlRMmQL4mpscbuC9xKS0w2Jaxrag 6bH1RfxYZH4U+k/GpSreh615+320hJRCDQzmedwv5wNxfY2tLIZNhL72Ov0s0NiRmUYt 5gEzThok3cdE/1FzKEgxJr2m/4uk99cRBY0nzyVCN7cIj5SrUMhgVLwB/nshRLyIea2G FQgWJH1+PY5gkvJ3N/jsdIseSmR1C5h1vTBzT2pkyjLCtAPj7nrQ+AxI4wqIMT+jh8HC R+Ruhq+8o1HhAqdXGyuPPdOTxOBpEeQDL4UFMN4HGMVSU+VOCkO0W8I8Bzi8IcOfbiJv d8Qw== X-Gm-Message-State: AD7BkJICrmsGY4AvhXHYfja+ayQ+F6cYQ/5OsYeYh5iSiF3aea2PLDUHkAsOkexvKnLKRw9W5ksTf7y7+GYPJF/x MIME-Version: 1.0 X-Received: by 10.107.26.201 with SMTP id a192mr5629107ioa.13.1458154112611; Wed, 16 Mar 2016 11:48:32 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Wed, 16 Mar 2016 11:48:32 -0700 (PDT) In-Reply-To: <56E99B71.7060003@bbn.com> References: <56E6CD30.8070102@bbn.com> <56E99B71.7060003@bbn.com> Date: Wed, 16 Mar 2016 18:48:32 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:48:38 -0000 On 16 March 2016 at 17:44, Stephen Kent wrote: > zBen, > >> On 14 March 2016 at 14:39, Stephen Kent wrote: >>> >>> The logged bogus certificate can be detected by a Monitor (third party or >>> self), that is watching the log(s) to which the certificate was posted. >>> Thus >>> the detection aspect of CT still works with regard to this certificate. >>> When >>> this certificate is detected, the CA that logged the certificate may >>> revoke >>> it, i.e., place it on a CRL or create an OCSP response for it. However, a >>> browser checking a CRL or OCSP response will not match this revocation >>> status data against the other, not-logged bogus certificate. (This is >>> because revocation status checking is performed in the context of a >>> certificate path and the two bogus certificates have different >>> certificate >>> paths.) Revoking a detected, bogus certificate may be the best strategy >>> for >>> the malicious CAs. It makes issuance of the bogus certificate appear to >>> be >>> an accident, and thus browser vendors may not feel the need to make an >>> entry >>> on their blacklists for the bogus certificate or the CA that issued it. >> >> I do not believe this is correct. And if it is, it is a serious bug in >> revocation that has nothing to do with certificate transparency. > > What do you believe is incorrect about my description of revocation status > checking? > A relying party validates a cert by walking down a cert pat from a trust > anchor to > a target cert. In DKG's example, the two CAs with the same name have > different > trust anchor parents, thus there are two distinct paths. A CRL (or OCSP > response) > issued by a CA on one path is totally independent from A CRL (or OSCSP > response) > issued by a CA on a distinct path. OK. If you are right, then its pretty clear that any implementation that relies on CRLs/OCSP specified further up the path than the EE cert has a serious problem that has nothing to do with CT. The CT related problem is that people could perhaps be fooled into thinking it was not necessary to revoke some logged bogus certificates because they appear to come from a chain that was not trusted anyway. Don't forget that the purpose of CT is to reveal problems with certificates, not to solve them. >> Also, I don't get the logic of the "not-logged bogus certificate", >> which is identical to the logged certificate - and is therefore >> logged. And not bogus. > > A cert is bogus when it is issued to an entity that is not authorized > to represent the Subject of the cert. This is true whether the cert is > logged or not. Ah, I see. In that case, is the cert in question not a "logged bogus cert"? From nobody Wed Mar 16 12:10:00 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817EB12D69A for ; Wed, 16 Mar 2016 12:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go3i0tkjenT6 for ; Wed, 16 Mar 2016 12:09:57 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 B455C12D59D for ; Wed, 16 Mar 2016 12:09:57 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id g184so14049896ioa.3 for ; Wed, 16 Mar 2016 12:09:57 -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-transfer-encoding; bh=Bi6sF45M2bmfGdowL3tJrLs5mMx6Rd92Au9Nu2LIew8=; b=kx/Db50XbK2fP00rsmEKvoWJB6iU1ERg3IY7eaCBCk444vPIMzIfDMogEE8kAJEtgI 1I8K2Rl0fRFNyuVGFYnberz8EqxNFKrEcODLKRmoUJgf9ahH/YHm+QHysbRluxya1W6g s89Bj9FGnlBa4XlNXPCVgbjgasZOUWZA5ZCYg0wTUdLMXB0eiSflcakskLOFfIAg3J7H FmqIx6KwCIuSrQWOOiLTI7EllCyMYkljafQK0FzK4TNCDCb0onOamM8QtxuvwBlXsTtt dD+GEpM5imbIl6HLyLDRVWAQ+Q/OPVXVXHGIDV1fFmTm3nDNF67AZ1qlJSDECMUQiie2 FJMQ== 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-transfer-encoding; bh=Bi6sF45M2bmfGdowL3tJrLs5mMx6Rd92Au9Nu2LIew8=; b=cI6gtxlmmhtQWF4f36oVh6T1qZ2YEZ7zKRheKvW5IWFZX4TPEAPqGQTedMtN9eYZmw RG8VQ5XhQ2uxvy8b8iPWcLmQtB2L5Mi7DqtY9S2GAS9E0C1bDlfYg8gxTwBUj0I4C5vb 8maNWVUiZqEyF6aUvSojA8Rro7CCu+T4nc5wHv3oC+s93cUWYmnJIA433bWdk16Qgkun hPIIXz1vxwSCvcq4UQcCpjSw89QvGb3cx7P+YhVMpQ0JaAV5UsshqvszOGB8ObrsNdKb RAoJgeYvi+ffghHV5kPsYitFghKuCaktFChmOdor6aT+dVNTws1JBax0tHEn5uzHkTdI tCwg== X-Gm-Message-State: AD7BkJL50fFCHVFJbVDetvCfpV9lpJCCRrtrIeEhU7nSWzSJKikwOwRuJE5KuIvC3AKG3NDaWag6GPuS5gzWnvhA MIME-Version: 1.0 X-Received: by 10.107.26.201 with SMTP id a192mr5735324ioa.13.1458155396806; Wed, 16 Mar 2016 12:09:56 -0700 (PDT) Received: by 10.64.245.105 with HTTP; Wed, 16 Mar 2016 12:09:56 -0700 (PDT) In-Reply-To: <9D88AE18-4C6F-4A16-9C52-DA6E5EA06195@gmail.com> References: <9D88AE18-4C6F-4A16-9C52-DA6E5EA06195@gmail.com> Date: Wed, 16 Mar 2016 19:09:56 +0000 Message-ID: From: Ben Laurie To: Bryan Ford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Paul Wouters , Trans , Melinda Shore Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:09:59 -0000 On 16 March 2016 at 18:34, Bryan Ford wrote: > On Mar 16, 2016, at 9:49 AM, Ben Laurie wrote: >> I do agree that these attacks can be mounted, and are in fact already >> discussed in general in 6962 and 6962-bis (s7.3 for the latter). > > I don=E2=80=99t see a section 7.3 in draft-ietf-trans-rfc6962-bis-12, whi= ch appears to be the latest version; did the section numbers change recentl= y and you=E2=80=99re referring to a different version? I would most natura= lly expect such issues to be discussed in section 12 =E2=80=9CSecurity Cons= iderations=E2=80=9D, but see no obvious mention of this class of attacks an= ywhere in there. Sorry, 7.3 is the relevant section in 6962. I meant 12.4! "(2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties. " > >> I have still not yet had the time to thoroughly review the threat >> analysis document, so I can't comment on it at this time. > > Perhaps the WGLC shouldn=E2=80=99t close until at least the core CT devel= opers such as you have had a chance to do that review? WGLC for a document we don't depend on? Why not? >> In general, it seems hard to defend against attacks that permanently >> separate their victims from the rest of the world - and it also seems >> hard to mount such an attack. > > Hard to defend: perhaps, but does that justify ignoring that entire threa= t vector space in a threat analysis document? I have already said I am not commenting on the threat analysis document at this time. > And do you (still) maintain that collective signing is not a workable def= ence against precisely such attacks? If so, I=E2=80=99m still curious why. This is not really a question for this group, and I have already explained why I don't think its a workable solution, as have others. > Hard to mount: perhaps, but do you disagree that such an attack appears t= o be exactly what the FBI is at the moment quite explicitly threatening to = perform against Apple (by threatening just to commandeer their signing keys= and sign their own backdoored software update)? And that the FBI appears = to be in a perfect position to perform such an attack secretly even against= a CT-hardened system, if they didn=E2=80=99t happen to want the publicity = like they seem to this time? No, I don't agree that - the attack they are proposing is against a single phone, in their possession, whose user is dead. That seems like a pretty ideal situation for mounting an isolation attack. I also agree in advance that CT would not defend against such a strong and narrowly targeted attack. Since you like this example, I'd love to hear how you think collective signing would, in detail, for this particular example. From nobody Wed Mar 16 14:51:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDE712D58E for ; Wed, 16 Mar 2016 14:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yax7mxCvV6St for ; Wed, 16 Mar 2016 14:51:09 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BF412D545 for ; Wed, 16 Mar 2016 14:51:09 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id m126so54691137ywd.0 for ; Wed, 16 Mar 2016 14:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y+lAPXngNS2RNryDTCQ9DwvZv6qAG4w7OnMg4N7/Fvc=; b=H1ujdFuXnvjYDZKT8GnnsMJuT5nwnHehfW8+y3I+7NPNq+IKIHlnwopj3w06IvP5Ye nmvqTwWJgyKzJG2JUdPQBVFkG+CeXWnU5r/YoCpTRGUNDBOC9aTpm5CK1P+UR28NaH0N 63j8v+RPRFELTTtihu5P8CZ23ndc/LVWz/AC8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y+lAPXngNS2RNryDTCQ9DwvZv6qAG4w7OnMg4N7/Fvc=; b=ItsqWCN/i5tLjpsza0guuh9bGfZmyncqyzc5J31ahnJabvwRrXxlG7GOqSgSe79G0w +/PndUFGAC/jIbDNQ/zjfQj/yKFLNzeAVGIIln3Y4V8NAvaG4fo+gWUC0m21EQlmxLnP tazNhdr2NoRPb6KzwssGc5KYqPUdvB04gBGhL635fT87cVVlBytHAMNWnOfgkTaXW0/F bVHkP4kVJA5PqDQkuRmqqpoIna990A5ANRFRME9Ulia0ErS+Ad0fjSbZm2rJEh8xR+3h gP4Ee5O84vhH0M6KUbXgih0/YEgYvpzA6f/Rq3/j19xdVe6wccUmweH/n3syQG5TkXXh EXXg== X-Gm-Message-State: AD7BkJLnBRNPIaMkMc6LYKdicf/xpPMR0yhXVo1dpFiPXJayoWaKJ6aGCu905G5lnfNSC2IviQ+ZqTBt3F4IR047 X-Received: by 10.13.213.130 with SMTP id x124mr2712863ywd.208.1458165068954; Wed, 16 Mar 2016 14:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.126.197 with HTTP; Wed, 16 Mar 2016 14:50:49 -0700 (PDT) In-Reply-To: References: <56E6CD30.8070102@bbn.com> <56E99B71.7060003@bbn.com> From: Tom Ritter Date: Wed, 16 Mar 2016 16:50:49 -0500 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 21:51:12 -0000 My notes on several comments in thread: ================================== I want to add to this part: On 15 March 2016 at 09:57, David A. Cooper wrote: > If there is an attack here, it seems that it would be as follows. Upon > detection of the bogus certificate browsers determine that the subordinate > CA is malicious and blacklist the cross-certificate from trust anchor 1 to > subordinate CA, but don't blacklist any of the EE certificates issued by the > subordinate CA (and the subordinate CA doesn't revoke them either). The > browsers don't notice that there is a second cross-certificate for > subordinate CA, from trust anchor 2, and so there continues to be a valid > certification path for certificates issued by subordinate CA. This is correct, but there is another attack, one I consider more damning, new fradulent intermediates that the community 'doesn't care about' because the issuer has been removed from trust stores. This isn't mentioned in the text present. Attacker issues intermediates A_X and B_X from CAs A and B that are identical. They issue an end entity cert EE1, signed by *_X (doesn't matter who signs it, the signature is identical.) They Log A -> A_X -> EE1, and get SCTs for EE1. EE, A_X, and A are revoked and blacklisted. Attacker issues a new intermediate A_Y and B_Y from CAs A and B that are identical. They issue another end entity cert EE2, signed by *_Y (again, doesn't matter who signs it) They log A -> A_Y -> EE2, and get SCTs for EE2. A_Y is *not* blacklisted, because the path we see in the logs is not trusted. People decide they don't care. The attacker can use B -> B_Y -> EE2 with the SCTs for EE2 to perform attacks. ================================== On 14 March 2016 at 17:15, Rob Stradling wrote: > 2. Declare that this is not a problem with CT. It's a problem with using > CRL and/or OCSP to revoke intermediates. So we (where "we" may or may not > be TRANS) need to fix revocation! > Revoking an intermediate _certificate_ just isn't sufficient. > To be effective, the intermediate _public key_ needs to be revoked somehow. I agree with this, except not just intermediates. Revocation should be done by either the public key or the certificate everywhere (intermediates and end-entity.) But practically, because of CA operations, I think it makes sense to revoke by public key for intermediates and by certificates for end-entity. That said, it's a bit beyond our mandate to redo revocation for the whole internet.... ================================== On 15 March 2016 at 08:50, Ben Laurie wrote: > > 3. Always revoke bad certs that appear in logs! That revocation would need to be via crl-sets or OneCRL. So while this... could work: If I'm the smart attacker I'm going to spam the everloving shit out of the log with bad certs. And when you have to revoke 1 million certificates via crl-sets you will be sad. =) So.... ================================== On 15 March 2016 at 08:51, Ben Laurie wrote: > Oh, also: > > 4. Require SCTs for all certs in the chain, which prevents hiding the > alternate intermediate. I think this is the answer. I think we need SCTs for all the certs in the chain. And yea, I think we need to mandate this. But how? It's a huge change right, it's going to be some time before Intermediates are issued as PreCerts. So there'll probably need to be a bandaid for the time being. The only thing I can think of is using Mozilla's Intermediate database and hardcoding a few kilobytes of SCTs into browsers. Ugly but... could get most of the way there? ================================== I'll also note that right now we (Gossip authors) don't want to make defending against this attack one of Gossip's responsabilities. But we can defend against this attack in a certain configuration. We have some in-progress text I wrote this morning about it, but it is in-progress. https://github.com/ln5/draft-ietf-trans-gossip/pull/16/files -tom From nobody Thu Mar 17 05:19:51 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB012D535 for ; Thu, 17 Mar 2016 05:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t91U5Pc5FfIn for ; Thu, 17 Mar 2016 05:19:48 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 335F412DA65 for ; Thu, 17 Mar 2016 05:19:46 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h129so97336898ywb.1 for ; Thu, 17 Mar 2016 05:19:46 -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; bh=iqaHB21Zh2XoG48cRzqqm4bekkw6H/2dMvzF/uphzd4=; b=dMY31X7VKU2v1OHTwJGa7FLFYYJodpJ2PbLbxvGmAFzL4aSGa6JIFudvlBLfGRexaj qfR+GobO0xyW2SM8xaRfoXelBf4SXa8JIWrC7wb9QND+N3udc8Nv+/vRU2fp5QdxTd8q 7ufw8bBTmIvqBhNZ2nnMGFE8gkpIjIBhxHjEA1Qk9Bu17hL7wfZ3wZCQdluy+dcxTdfk sjd4JBSpxG9kBd7u5AMcEbvVbt+57pIOVqilm0TjUemIReoRjzpuP4o25hC6ROWpqYfu McuAx4CqtsIxlq5Aw5af6ki4PrunuZgBV0Ah1HlPorB6Mu1ya6f8c5gqnLfJ69pdzXlf MneA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iqaHB21Zh2XoG48cRzqqm4bekkw6H/2dMvzF/uphzd4=; b=A08ZzIcbd1v610opg9aiso+L0Y+lAjMc9hiD2HbNZBeV8+kvWwhjquN95jRCMVtKmU 8KFaQKgORtaQGE2DbWoGdIRSsFy8bPbNPUs+TGNhA2rvoj61V0tBwgfZby0i5RcG456w ospRczX1EwYI/IRTctOKgJR1YQalmi/NRxlXE4qHmI+7ocJW0hec1AtVwaEsQt00+zaR wYQIUFEGRyz4c6NIWHUyv+lGDhOC6L8qdQ2+sUmWy72gtTTKUFiGxmh9xMZ8e6Y2WnG8 V3l/hWPkoRAuGwaf2OZZ0o7ltqIrr6/Bc6IBqUyNJFo5dkkeBeTRjbmUJmTx0k5ap6Ho 24pg== X-Gm-Message-State: AD7BkJL/R9O6y5tiwUastWc/Cqh1gSLKJ3ozEaXqhmUNK/8ixyWbuFiQYOzB1mdAbfbvgNusDJsoPeoPSoS8d/wB MIME-Version: 1.0 X-Received: by 10.129.131.9 with SMTP id t9mr3583350ywf.140.1458217185331; Thu, 17 Mar 2016 05:19:45 -0700 (PDT) Received: by 10.37.48.6 with HTTP; Thu, 17 Mar 2016 05:19:45 -0700 (PDT) In-Reply-To: <56E99CFA.8010601@bbn.com> References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> <068.0779562256ffb55d064ab4f9e5d0a31c@tools.ietf.org> <56E99CFA.8010601@bbn.com> Date: Thu, 17 Mar 2016 12:19:45 +0000 Message-ID: From: Eran Messeri To: Stephen Kent Content-Type: multipart/alternative; boundary=94eb2c07ad4656bc8f052e3da5c9 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:19:50 -0000 --94eb2c07ad4656bc8f052e3da5c9 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 5:50 PM, Stephen Kent wrote: > Eran, > > #118: Monitor function description problem >> >> Changes (byeranm@google.com): >> >> * owner:draft-ietf-trans-rfc6962-bis@tools.ietf.org =>eranm@google.com >> >> >> Comment: >> >> Is the problem here that the term 'monitoring' means something different >> in this context, making the introduction and Section 9.3. inconsistent? >> I can suggest a few resolutions: >> (1) Replacing the word 'monitor' in the introduction with 'watch'. >> (2) Modify the Monitor section to indicate a monitor can either ensure >> logs behave correctly, watch for certificates of interest or do both. >> > In most prior versions of 6962-bis, Auditing has focused on detecting > mis-behaving logs. Why not stick with that characterization of the > function? > Your suggestion #2 above seems to make Monitors overlap with Auditors, > rather than having simple, distinct definitions for them. > > Let's say that a Monitor observes an enumerated set of logs for certs of > interest, > so that it can inform Subjects if there is evidence that a bogus cert has > been logged (relative to the Subject in question). > > An Auditor observes an enumerated set of losg to detect log misbehavior. > There may be a misunderstanding here: in 6962-bis the Auditor entity was replaced with an auditing role, that different entities (a Monitor being one) can take. Section 9.4. of draft 12 explains how monitors can audit and how TLS clients can, while section 9.3., about Monitors, describes the process a Monitor should use to audit. I believe that change was partly made thanks to your feedback that the Monitor and Auditor entities have some overlap and the distinction wasn't quite clear. > > These are roughly the ways that draft-kent-trans-monitor-auditor-00.txt > characterizes the two functions. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c07ad4656bc8f052e3da5c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 16, 2016 at 5:50 PM, Stephen Kent <kent@bbn.com> = wrote:
Eran,

#118: Monitor function description problem

Changes (byeranm@go= ogle.com):

=C2=A0 * owner:draft-ietf-trans-rfc6962-bis@tools.ietf.org=C2=A0 =3D>eranm@= google.com


Comment:

=C2=A0 Is the problem here that the term 'monitoring' means somethi= ng different
=C2=A0 in this context, making the introduction and Section 9.3. inconsiste= nt?
=C2=A0 I can suggest a few resolutions:
=C2=A0 (1) Replacing the word 'monitor' in the introduction with &#= 39;watch'.
=C2=A0 (2) Modify the Monitor section to indicate a monitor can either ensu= re
=C2=A0 logs behave correctly, watch for certificates of interest or do both= .
 In most prior versions of 6962-bis, Auditing has focused on detecting
mis-behaving logs. Why not stick with that characterization of the function= ?
Your suggestion #2 above seems to make Monitors overlap with Auditors,
rather than having simple, distinct definitions for them.

Let's=C2=A0 =C2=A0say that a Monitor observes an enumerated set of logs= for certs of interest,
so that it can inform Subjects if there is evidence that a bogus cert has been logged (relative to the Subject in question).

An Auditor observes an enumerated set of losg to detect log misbehavior.
There may be a misunderstanding here: in 6962-bis the Au= ditor entity was replaced with an auditing role, that different entities (a= Monitor being one) can take.
Section 9.4. of draft 12 explains h= ow monitors can audit and how TLS clients can, while section 9.3., about Mo= nitors, describes the process a Monitor should use to audit.

=
I believe that change was partly made thanks to your feedback th= at the Monitor and Auditor entities have some overlap and the distinction w= asn't quite clear.
=C2=A0

These are roughly the ways that draft-kent-trans-monitor-auditor-00.txt
characterizes the two functions.

Steve


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

--94eb2c07ad4656bc8f052e3da5c9-- From nobody Thu Mar 17 05:57:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6948212D55E for ; Thu, 17 Mar 2016 05:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1R-ec8CB3oN for ; Thu, 17 Mar 2016 05:57:13 -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 A075312DBD0 for ; Thu, 17 Mar 2016 05:56:42 -0700 (PDT) Received: from localhost ([::1]:41399 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agXTm-0005Ka-H8; Thu, 17 Mar 2016 05:56: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: eranm@google.com X-Trac-Project: trans Date: Thu, 17 Mar 2016 12:56:42 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/142#comment:2 Message-ID: <080.d9b79ebd94595ad4f6fe183d3ea11486@tools.ietf.org> References: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org> X-Trac-Ticket-ID: 142 In-Reply-To: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #142 (rfc6962-bis): Specify what TLS clients should send in the extension_data of the transparency_info TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 12:57:14 -0000 #142: Specify what TLS clients should send in the extension_data of the transparency_info TLS extension Comment (by eranm@google.com): Advice obtained from exchange with Adam Langley: - The server doesn't have much control over which logs it has SCTs from so it may not be entirely useful to specify them. - Because we aren't certain what we'll need we'll just be building an extension-within-extension mechanism, might as well use the existing TLS extensions mechanism. - Specifying that the client sends nothing but the server does not reject non-empty extension_data, but, because we won't be using it initially, "it might get bug-rusted before you can use it". So the conclusion is we leave the extension data empty, which simplifies the protocol but does not prevent us from sending additional data in the future using a different TLS extension. -- --------------------------------------+------------------------------- Reporter: rob.stradling@comodo.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------- Ticket URL: trans From nobody Thu Mar 17 06:06:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CED12D55F for ; Thu, 17 Mar 2016 06:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zTitJ5b1LtN for ; Thu, 17 Mar 2016 06:06:47 -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 BE61112D560 for ; Thu, 17 Mar 2016 06:05:34 -0700 (PDT) Received: from localhost ([::1]:42482 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agXcM-0003VJ-LE; Thu, 17 Mar 2016 06:05:34 -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, 17 Mar 2016 13:05:34 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/142#comment:3 Message-ID: <080.d03cd6f68227637ad6f6ce12898b4696@tools.ietf.org> References: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org> X-Trac-Ticket-ID: 142 In-Reply-To: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #142 (rfc6962-bis): Specify what TLS clients should send in the extension_data of the transparency_info TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 13:06:50 -0000 #142: Specify what TLS clients should send in the extension_data of the transparency_info TLS extension Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/138 -- --------------------------------------+------------------------------- Reporter: rob.stradling@comodo.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------------------+------------------------------- Ticket URL: trans From nobody Thu Mar 17 07:18:16 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B4412D923 for ; Thu, 17 Mar 2016 07:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEkMk9NAdn-X for ; Thu, 17 Mar 2016 07:18: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 9DF6412D589 for ; Thu, 17 Mar 2016 07:18:06 -0700 (PDT) Received: from localhost ([::1]:48824 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agYkW-0007Ac-6s; Thu, 17 Mar 2016 07:18: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: rob.stradling@comodo.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Thu, 17 Mar 2016 14:18:04 -0000 X-URL: https://tools.ietf.org/trans/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/111#comment:3 Message-ID: <080.9bfe7cc729c874dbe4ebbbda3f842341@tools.ietf.org> References: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, eranm@google.com, 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] #111 (rfc6962-bis): Consider using the cached-info TLS extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 14:18:14 -0000 #111: Consider using the cached-info TLS extension Comment (by rob.stradling@comodo.com): Cached-info is still not an RFC. Further delays... https://mailarchive.ietf.org/arch/msg/tls/qBJf-aozr4eKIFcOXVDh85TcZZY Let's not block WGLC for 6962-bis on this ticket. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Mar 17 08:00:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4AE12D53D for ; Thu, 17 Mar 2016 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoGn2ojBh1SJ for ; Thu, 17 Mar 2016 08:00:30 -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 0943B12D66C for ; Thu, 17 Mar 2016 08:00:30 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48318 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agZPV-000ImU-3n; Thu, 17 Mar 2016 11:00:25 -0400 From: Stephen Kent To: Ben Laurie References: <56E6CD30.8070102@bbn.com> <56E99B71.7060003@bbn.com> Message-ID: <56EAC688.1030707@bbn.com> Date: Thu, 17 Mar 2016 11:00:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080801050908080400020603" Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] text to address DKG's conspiring CAs attack X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:00:38 -0000 This is a multi-part message in MIME format. --------------080801050908080400020603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ben, > OK. If you are right, then its pretty clear that any implementation > that relies on CRLs/OCSP specified further up the path than the EE > cert has a serious problem that has nothing to do with CT. Yes, I am right. But, again, I am puzzled by your comment. In PKIs in general, the revocation status of an EE cert is specified by the CA that issued the cert. (There are provisions for indirect CRLs, but that's not a commonly used mechanism). RFC 5280 recognizes that there can be vulnerabilities associated with acquiring CRLs or OCSP data in some contexts, and that's why AIA allows a CA to tell RPs where to acquire such data. However, for backward compatibility purposes, and because this is not a problem in all contexts, 5280 does not mandate use of this extension. Thus one ought not assume that it is always present, and it is appropriate to acknowledge this residual vulnerability where applicable. Note, that the RPKI does mandate use of AIA to point to CRLs, and relying parties in that context are required to verify that the extension is present,. If it's missing the cert (EE or CA) is rejected. > The CT related problem is that people could perhaps be fooled into > thinking it was not necessary to revoke some logged bogus certificates > because they appear to come from a chain that was not trusted anyway. True. Also, a browser vendor might decide that it didn't need to blacklist the EE cert because it had already been revoked by the CA. > Don't forget that the purpose of CT is to reveal problems with > certificates, not to solve them. My characterization of CT (draft-kent-trans-architecture-02.txt) is: Certificate transparency (CT) is a set of mechanisms designed to deter, detect, and facilitate remediation of certificate mis-issuance (as defined below). I wrote this (month ago) because I thought it was useful to provide a concise characterization of CT goals. Do you disagree with the text above? >>> Also, I don't get the logic of the "not-logged bogus certificate", >>> which is identical to the logged certificate - and is therefore >>> logged. And not bogus. >> A cert is bogus when it is issued to an entity that is not authorized >> to represent the Subject of the cert. This is true whether the cert is >> logged or not. > Ah, I see. In that case, is the cert in question not a "logged bogus cert"? yes, it is. Steve --------------080801050908080400020603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,


OK. If you are right, then its pretty clear that any implementation that relies on CRLs/OCSP specified further up the path than the EE cert has a serious problem that has nothing to do with CT.
Yes, I am right. But, again, I am puzzled by your comment. In PKIs in general, the revocation
status of an EE cert is specified by the CA that issued the cert. (There are provisions
for indirect CRLs, but that's not a commonly used mechanism). RFC 5280 recognizes that there
can be vulnerabilities associated with acquiring CRLs or OCSP data in some contexts, and
that's why AIA allows a CA to tell RPs where to acquire such data. However, for backward
compatibility purposes, and because this is not a problem in all contexts, 5280 does not
mandate use  of this extension. Thus one ought not assume that it is always present,
and it is appropriate to acknowledge this residual vulnerability where applicable.
Note, that the RPKI does mandate use of AIA to point to CRLs, and relying parties
in that context are required to verify that the extension is present,. If it's missing
the cert (EE or CA) is rejected.
The CT related problem is that people could perhaps be fooled into
thinking it was not necessary to revoke some logged bogus certificates
because they appear to come from a chain that was not trusted anyway.
True. Also, a browser vendor might decide that it didn't need to blacklist the
EE cert because it had already been revoked by the CA.
Don't forget that the purpose of CT is to reveal problems with
certificates, not to solve them.
My characterization of CT (draft-kent-trans-architecture-02.txt) is:

   Certificate transparency (CT) is a set of mechanisms designed to
   deter, detect, and facilitate remediation of certificate mis-issuance
   (as defined below).

I wrote this (month ago) because I thought it was useful to provide a concise
characterization of CT goals. Do you disagree with the text above?

      

        

          
Also, I don't get the logic of the "not-logged bogus certificate",
which is identical to the logged certificate - and is therefore
logged. And not bogus.


        

        
A cert is bogus when it is issued to an entity that is not authorized
to represent the Subject of the cert. This is true whether the cert is
logged or not.


      

      
Ah, I see. In that case, is the cert in question not a "logged bogus cert"?

    

    

    yes, it is.

    

    Steve

    
 

    

  


--------------080801050908080400020603--


From nobody Thu Mar 17 08:13:38 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5863D12D5B4 for ; Thu, 17 Mar 2016 08:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJZL6KC2yTBu for ; Thu, 17 Mar 2016 08:13:25 -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 3938C12D57F for ; Thu, 17 Mar 2016 08:13:25 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:48529 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agZc3-000ItE-Mz; Thu, 17 Mar 2016 11:13:23 -0400
From: Stephen Kent 
To: "David A. Cooper" , trans@ietf.org
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov>
Message-ID: <56EAC993.20200@bbn.com>
Date: Thu, 17 Mar 2016 11:13:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56E9A1FF.4050301@nist.gov>
Content-Type: multipart/alternative; boundary="------------040904080704040802050309"
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 15:13:29 -0000

This is a multi-part message in MIME format.
--------------040904080704040802050309
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

David,


> I have never believed that "the X.500 directory tree is the basis for 
> all names in certs.," and you know that!
your assertion that X.509 requires all name uniqueness across CA 
boundaries makes sense
only in the context of an X.500 DIT world. We had this debate already in 
the RPKI context
a few years ago. That WG disagreed with your assertion, and nothign has 
changed to suggest
a different resolution this time. But, I.ve removed the mention of X.509 
from my proposed
text, so this is moot.
> Nor does that have anything to do with what I said in my previous email.
it was an attempt to explain your statement about global name uniqueness.
> There's no reason for you to rebut my analysis. What is needed is for 
> someone to write a description of the attack scenario that accurately 
> describes the attack scenario DKG presented, and the text you proposed 
> doesn't do that.
DKG's description was a bit narrow compared to the full range of 
possible attacks enabled
by colluding CAs. I changed the description to try to capture the 
broader attack space. That's
why it differs from DKG's original wording.
> If my description of the scenario is so wrong, then please explain (in 
> detail) how a relying party would be able to determine that there are 
> two distinct intermediate CAs in this scenario and not a single CA 
> that has been issued cross-certificates by two different roots (as 
> depicted in my diagrams) and how that fits in with your response to 
> Ben Laurie that:
the two colluding CAs appear in different cert paths, and thus an RP 
following one cert
path may see revocation status info for only the CA that issued and 
logged the bogus cert.
Remember that the two malicious CAs have the same Subject name but 
different Issuer names
in their certs, so they are distinct in terms of cert paths. A malocious 
web site can send
a full cert path to the browser and thus direct the browser to validate 
the EE cert relative
to the CA that did not log the cert and did not revoke it.

The fact that Ben (and Rob) questioned why the revocation status info 
from one CA would
not match the other CA is an issue I addressed in my replies to them.
> What information (specifically) would appear in a CRL or OCSP response 
> issued by a CA on one path that would make it distinguishable to a 
> relying party from a CRL or OCSP response issued by a CA on the other 
> path in the scenario DKG described?
I'm afraid this question is not relevant to the attack I described.

A web server also can supply OCSP data to a browser as part of the TLS 
handshake (RFC 6066),
thus it may influence the revocation status info that the browser sees. 
(RFC 6066 allows a
client to send a list of OCSP servers that it trusts, but it also allows 
a null list to
indicate that the client assumes that the server knows what this list 
is, implicitly.
The client should verify that the returned OCSP response matches what it 
asked for, but
given the history of buggy browser PKI software, I would not be too 
confident in how
rigorously this is implemented in all browsers.) In this fashion a bogus 
web server, aided
by a malicious CA, may be able to supply revocation status data that 
reflects the not-logged and
not-revoked instance of the bogus cert.

Steve

--------------040904080704040802050309
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    David,

    

    


    

    

      
      
I have never believed that "the X.500
        directory tree is the basis for all names in certs.," and you
        know that! 

    

    your assertion that X.509 requires all name uniqueness across CA
    boundaries makes sense

    only in the context of an X.500 DIT world. We had this debate
    already in the RPKI context

    a few years ago. That WG disagreed with your assertion, and nothign
    has changed to suggest

    a different resolution this time. But, I.ve removed the mention of
    X.509 from my proposed

    text, so this is moot.

    

      
Nor does that have anything to do
        with what I said in my previous email.

      

    

    it was an attempt to explain your statement about global name
    uniqueness.

    

      
 There's no reason for you to rebut
        my analysis. What is needed is for someone to write a
        description of the attack scenario that accurately describes the
        attack scenario DKG presented, and the text you proposed doesn't
        do that.

      

    

    DKG's description was a bit narrow compared to the full range of
    possible attacks enabled

    by colluding CAs. I changed the description to try to capture the
    broader attack space. That's

    why it differs from DKG's original wording.

    

      
 If my description of the scenario is
        so wrong, then please explain (in detail) how a relying party
        would be able to determine that there are two distinct
        intermediate CAs in this scenario and not a single CA that has
        been issued cross-certificates by two different roots (as
        depicted in my diagrams) and how that fits in with your response
        to Ben Laurie that:

      

    

    the two colluding CAs appear in different cert paths, and thus an RP
    following one cert

    path may see revocation status info for only the CA that issued and
    logged the bogus cert. 

    Remember that the two malicious CAs have the same Subject name but
    different Issuer names 

    in their certs, so they are distinct in terms of cert paths. A
    malocious web site can send 

    a full cert path to the browser and thus direct the browser to
    validate the EE cert relative 

    to the CA that did not log the cert and did not revoke it.

    

    The fact that Ben (and Rob) questioned why the revocation status
    info from one CA would 

    not match the other CA is an issue I addressed in my replies to
    them.

    

      
 What information (specifically)
        would appear in a CRL or OCSP response issued by a CA on one
        path that would make it distinguishable to a relying party from
        a CRL or OCSP response issued by a CA on the other path in the
        scenario DKG described?

      

    

    I'm afraid this question is not relevant to the attack I described.

    

    A web server also can supply OCSP data to a browser as part of the
    TLS handshake (RFC 6066), 

    thus it may influence the revocation status info that the browser
    sees. (RFC 6066 allows a 

    client to send a list of OCSP servers that it trusts, but it also
    allows a null list to

    indicate that the client assumes that the server knows what this
    list is, implicitly.

    The client should verify that the returned OCSP response matches
    what it asked for, but

    given the history of buggy browser PKI software, I would not be too
    confident in how

    rigorously this is implemented in all browsers.) In this fashion a
    bogus web server, aided

    by a malicious CA, may be able to supply revocation status data that
    reflects the not-logged and

    not-revoked instance of the bogus cert. 

    

    Steve

  


--------------040904080704040802050309--


From nobody Thu Mar 17 09:26:36 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A2212D883 for ; Thu, 17 Mar 2016 09:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.478
X-Spam-Level: 
X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COHNvBRdVqKV for ; Thu, 17 Mar 2016 09:26:32 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F7712D61E for ; Thu, 17 Mar 2016 09:26:29 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Mar 2016 12:27:55 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.406.0; Thu, 17 Mar 2016 12:26:26 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2HGQEgv010732;	Thu, 17 Mar 2016 12:26:14 -0400
To: Stephen Kent , 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com>
From: "David A. Cooper" 
Message-ID: <56EADAA6.6010306@nist.gov>
Date: Thu, 17 Mar 2016 12:26:14 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56EAC993.20200@bbn.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2016 16:26:35 -0000


  
    
  
  
    
On 03/17/2016 11:13 AM, Stephen Kent
      wrote:

    

    

      
      David,

      

      


      

      

        
I have never believed that "the
          X.500 directory tree is the basis for all names in certs.,"
          and you know that! 

      

      your assertion that X.509 requires all name uniqueness across CA
      boundaries makes sense

      only in the context of an X.500 DIT world. We had this debate
      already in the RPKI context

      a few years ago. That WG disagreed with your assertion, and
      nothign has changed to suggest

      a different resolution this time. But, I.ve removed the mention of
      X.509 from my proposed

      text, so this is moot.

    

    

      The issue is not moot, since the revised text continues to say
      that "Requirements for Subject name uniqueness apply individually
      to each CA but not across CA boundaries."

      

      You've made it very clear that you don't like that X.509 requires
      name uniqueness across CA boundaries, but just because you don't
      like the requirement (and believe it couldn't be enforced) doesn't
      mean the requirement doesn't exist. The biggest problem for you is
      that without the name uniqueness requirement, X.509 (and RFC 5280)
      no longer works. I provided several examples of that in my
      previous email, and your flawed description of DKG's attack
      scenario is also largely based on that.

      

      The RPKI is a specific, highly-constrained hierarchical PKI, and
      in that environment, if all of the RPKI-specific constraints are
      followed and relying party software is careful to check those
      RPKI-specific constraints when validating certificates, then it is
      likely that name collisions across CA boundaries would not break
      that PKI. However, your assertion that the RPKI WG "disagreed with
      [my] assertion" is totally wrong. That is why RFC 6487 (A Profile
      for X.509 PKIX Resource Certificates) includes (over your
      objections) a warning about name collisions in its Security
      Considerations section.

    

    

      

        
Nor does that have anything to do
          with what I said in my previous email.

        

      

      it was an attempt to explain your statement about global name
      uniqueness.

      

        
 There's no reason for you to rebut
          my analysis. What is needed is for someone to write a
          description of the attack scenario that accurately describes
          the attack scenario DKG presented, and the text you proposed
          doesn't do that.

        

      

      DKG's description was a bit narrow compared to the full range of
      possible attacks enabled

      by colluding CAs. I changed the description to try to capture the
      broader attack space. That's

      why it differs from DKG's original wording.

    

    

    In your description the attacker revokes the
      EE certificate. In DKG's description one of the CA certificates is
      revoked:

    
    

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


    

    

      Revoking the EE certificate is very different from revoking the CA
      certificate. If the CA certificate is revoked, but the EE
      certificate is not, then the certification path using the other CA
      certificate remains valid.

    

    

      

        
 If my description of the scenario
          is so wrong, then please explain (in detail) how a relying
          party would be able to determine that there are two distinct
          intermediate CAs in this scenario and not a single CA that has
          been issued cross-certificates by two different roots (as
          depicted in my diagrams) and how that fits in with your
          response to Ben Laurie that:

        

      

      the two colluding CAs appear in different cert paths, and thus an
      RP following one cert

      path may see revocation status info for only the CA that issued
      and logged the bogus cert. 

      Remember that the two malicious CAs have the same Subject name but
      different Issuer names 

      in their certs, so they are distinct in terms of cert paths. A
      malocious web site can send 

      a full cert path to the browser and thus direct the browser to
      validate the EE cert relative 

      to the CA that did not log the cert and did not revoke it.

      

      The fact that Ben (and Rob) questioned why the revocation status
      info from one CA would 

      not match the other CA is an issue I addressed in my replies to
      them.

    

    

    Actually, there was nothing in your response that addressed the
    issue, and your statement in the proposed text about how status
    checking is performed in the context of a certification path is
    nonsensical. There is nothing in a CRL or OCSP response that limits
    it for use with a specific certification path.

    

    

      

        
 What information (specifically)
          would appear in a CRL or OCSP response issued by a CA on one
          path that would make it distinguishable to a relying party
          from a CRL or OCSP response issued by a CA on the other path
          in the scenario DKG described?

        

      

      I'm afraid this question is not relevant to the attack I
      described.

      

      A web server also can supply OCSP data to a browser as part of the
      TLS handshake (RFC 6066), 

      thus it may influence the revocation status info that the browser
      sees. (RFC 6066 allows a

      client to send a list of OCSP servers that it trusts, but it also
      allows a null list to

      indicate that the client assumes that the server knows what this
      list is, implicitly.

      The client should verify that the returned OCSP response matches
      what it asked for, but

      given the history of buggy browser PKI software, I would not be
      too confident in how

      rigorously this is implemented in all browsers.) In this fashion a
      bogus web server, aided

      by a malicious CA, may be able to supply revocation status data
      that reflects the not-logged and

      not-revoked instance of the bogus cert. 

    

    

    Here you note a possible way in which the
      attack you described could be carried out, but this is not at all
      what you describe in your proposed text. If the attacker controls
      the web server, and it pushes the entire certification path along
      with the certificate status information (CRL or OCSP) for the
      certificates to the browser, then it can send different
      information to the browser about the EE certificate depending on
      which path it sends. It could send an OCSP response to indicates
      the certificate is revoked when sending the certification path
      that begins with trust anchor A and could send an OCSP response
      that indicates the certificate is not revoked when sending the
      certification path that begins with trust anchor B.

      

      I don't understand the part about "buggy browser PKI software." In
      most cases, the CA that issued the certificate whose status is
      being checked (e.g., the EE certificate) would designate the
      appropriate OCSP response to sign the OCSP response by issuing the
      responder a certificate with an extended key usage of
      id-kp-OCSPSigning. Since the attacker controls the CA, the
      attacker would be able to create an OCSP response signed by a
      responder under its control and containing a certificate for the
      responder that it signed. There would be nothing buggy about PKI
      software accepting such a response. The problem is if you trust a
      CA that is malicious, then that CA can not only feed you bogus
      certificates (limited by whatever constraints are imposed by CAs
      earlier in the path or by the relying party) and it can feed you
      incorrect information about the status of the certificates it has
      issued.

      

      Note that a description like this wouldn't require any fuzzy
      wording about two different CAs that just happen to be controlled
      by the same entity (the attacker) and have the same name and
      public key along with two EE certificates (that just happen to be
      bit-for-bit identical), or about how CRLs or OCSP responses issued
      for use with one certification path "may not match" when a
      different certification path is used to validate the same
      certificate.

    

    

  



From nobody Fri Mar 18 05:38:11 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D0212D902 for ; Fri, 18 Mar 2016 05:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PCDvJdkLqHI for ; Fri, 18 Mar 2016 05:38: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 4EC8712DB98 for ; Fri, 18 Mar 2016 05:34:54 -0700 (PDT)
Received: from localhost ([::1]:55146 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agtcB-0002C6-B1; Fri, 18 Mar 2016 05:34:51 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "trans issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, rob.stradling@comodo.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 12:34:51 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/156#comment:4
Message-ID: <072.80c0d3c34faed41d24ec5e25ab85469e@tools.ietf.org>
References: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-Trac-Ticket-ID: 156
In-Reply-To: <057.0d95c321188cdb7c3a9d91d74944a13b@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, 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: <20160318123454.4EC8712DB98@ietfa.amsl.com>
Resent-Date: Fri, 18 Mar 2016 05:34:54 -0700 (PDT)
Resent-From: trac+trans@tools.ietf.org
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #156 (rfc6962-bis): Can inclusion proofs properly substitute SCTs?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 12:38:09 -0000

#156: Can inclusion proofs properly substitute SCTs?


Comment (by rob.stradling@comodo.com):

 Sending multiple SCTs, multiple inclusion proofs and multiple STHs as
 separate TransItems would presumably mean added complexity for the client
 in terms of figuring out which ones go with which.

 To avoid that complexity, and to avoid unnecessarily increasing the
 handshake size, why don't we create a new "standalone_inclusion_proof"
 TransItem type that contains just the necessary fields for "SCT +
 Inclusion proof + STH"?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  eranm@google.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 Fri Mar 18 05:44:39 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07B812D514 for ; Fri, 18 Mar 2016 05:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnRruVHs2oUe for ; Fri, 18 Mar 2016 05:44: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 BC34A12D691 for ; Fri, 18 Mar 2016 05:44:23 -0700 (PDT)
Received: from localhost ([::1]:55862 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agtlO-00041w-4X; Fri, 18 Mar 2016 05:44: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, rob.stradling@comodo.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 12:44:22 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/157
Message-ID: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-Trac-Ticket-ID: 157
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: <20160318124423.BC34A12D691@ietfa.amsl.com>
Resent-Date: Fri, 18 Mar 2016 05:44:23 -0700 (PDT)
Resent-From: trac+trans@tools.ietf.org
Archived-At: 
Cc: trans@ietf.org
Subject: [Trans] [trans] #157 (rfc6962-bis): Conflate Version and TransType
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 12:44:38 -0000

#157: Conflate Version and TransType

 With TransItem support for v1 (RFC6962) disappearing in ticket #153, it
 seems that having the type and version as separate fields just seems to
 complicate matters unnecessarily.  So let's conflate the two fields:

 enum {
     (0), x509_entry_v2(1), precert_entry_v2(2), x509_sct_v2(3),
     precert_sct_v2(4), tree_head_v2(5), signed_tree_head_v2(6),
     consistency_proof_v2(7), inclusion_proof_v2(8), (65535)
 } TransTypeAndVersion;

 The zero value is reserved to avoid confusion with a v1 SCT (which is
 guaranteed to have zero as its first byte).

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-trans-
  rob.stradling@comodo.com           |  rfc6962-bis@tools.ietf.org
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Fri Mar 18 06:06:43 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FB012D693 for ; Fri, 18 Mar 2016 06:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSro9Jk-TSUQ for ; Fri, 18 Mar 2016 06:06:39 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 C59B412D6F3 for ; Fri, 18 Mar 2016 06:06:36 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id o5so52500826iod.2 for ; Fri, 18 Mar 2016 06:06:36 -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; bh=kGXlguLENICU8vC+de6k+46CKtKjhKlM6yYsLN0V73o=; b=TxIXLUlYkmwJXnTx3xV7wOEwLgFp1R53J1SnGl0jad6bjQsqX9hQ1phc/90RUHEHDQ AgHJu6uNVZdSf8mQUVR7m8lQYnfX/40M7MF3YFXrANBg+H+DeMd2CHkq5KhXDBz15OIr kWgjJspQQKXzFkrHU2ymiBMBFGF1J2VSD+dT5HkInoB/RVuWk6YOqo1A1Hy58UOFSo2C 1rztugxIDBE3Hr246I1E2o+vc+UpNOM8ItqwO6xDwjYatRdBE3ZSuXsifn2It4IcnvKg CIk+RR7E146NiT1XVpB8E37JJWxXuPMLO0MZEsB59Zju+zxRuE83z6ytUvUiUVxVCGj6 uJ5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kGXlguLENICU8vC+de6k+46CKtKjhKlM6yYsLN0V73o=; b=P1o2uSJhoigvQrwOr6jzUPSAs+Vrt6B5E+9Hty5DcRTC9i0pXX9126etj4ytL7ks6z 0VaPpbRQJkx0Hl75+QO2ocWBII6z6GhTS39DGKVDqAZGAmTMBdLSwhe/kYazWr+rzOBL aAXrJEz9OK1HXsghh8K/D54T16GUlrU1rervdUNKZrT4PeyAd4qmS5TjbvxKIrJy5CYT Lqf8d5/LAjEz9xtK5s3WKYuXVK5UXYhK7qhUZkV4h5k+GWCZDj+FTv9uMoGS0PmMNYF5 8PmHtdxI5wBiuBYJo0n4B7RKCEXr0gfOYyJALEj0y/pkiWix+uWsXHt8dWlKnrBAptF8 SPYg==
X-Gm-Message-State: AD7BkJIdvstoHnoezGwL1qW7DVSCXgEK9RrQNwMamE4/5iJfYLt9dksLPFNMhcdCnw/Zd8u4bva56TM2SbDLyIf7
MIME-Version: 1.0
X-Received: by 10.107.157.80 with SMTP id g77mr16983250ioe.172.1458306395920;  Fri, 18 Mar 2016 06:06:35 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Fri, 18 Mar 2016 06:06:35 -0700 (PDT)
In-Reply-To: 
References: <56E6CD30.8070102@bbn.com>  <56E99B71.7060003@bbn.com>  
Date: Fri, 18 Mar 2016 13:06:35 +0000
Message-ID: 
From: Ben Laurie 
To: Tom Ritter 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 13:06:42 -0000

On 16 March 2016 at 21:50, Tom Ritter  wrote:
> My notes on several comments in thread:
>
> ==================================
>
> I want to add to this part:
>
> On 15 March 2016 at 09:57, David A. Cooper  wrote:
>> If there is an attack here, it seems that it would be as follows. Upon
>> detection of the bogus certificate browsers determine that the subordinate
>> CA is malicious and blacklist the cross-certificate from trust anchor 1 to
>> subordinate CA, but don't blacklist any of the EE certificates issued by the
>> subordinate CA (and the subordinate CA doesn't revoke them either). The
>> browsers don't notice that there is a second cross-certificate for
>> subordinate CA, from trust anchor 2, and so there continues to be a valid
>> certification path for certificates issued by subordinate CA.
>
> This is correct, but there is another attack, one I consider more
> damning, new fradulent intermediates that the community 'doesn't care
> about' because the issuer has been removed from trust stores. This
> isn't mentioned in the text present.
>
> Attacker issues intermediates A_X and B_X from CAs A and B that are identical.
> They issue an end entity cert EE1, signed by *_X (doesn't matter who
> signs it, the signature is identical.)
> They Log A -> A_X -> EE1, and get SCTs for EE1.
> EE, A_X, and A are revoked and blacklisted.
>
> Attacker issues a new intermediate A_Y and B_Y from CAs A and B that
> are identical.
> They issue another end entity cert EE2, signed by *_Y (again, doesn't
> matter who signs it)
> They log A -> A_Y -> EE2, and get SCTs for EE2.
> A_Y is *not* blacklisted, because the path we see in the logs is not
> trusted. People decide they don't care.

Since CT does not claim to log all possible chains, this is an
erroneous decision.

> The attacker can use B -> B_Y -> EE2 with the SCTs for EE2 to perform attacks.
>
> ==================================
>
> On 14 March 2016 at 17:15, Rob Stradling  wrote:
>>   2. Declare that this is not a problem with CT.  It's a problem with using
>> CRL and/or OCSP to revoke intermediates.  So we (where "we" may or may not
>> be TRANS) need to fix revocation!
>> Revoking an intermediate _certificate_ just isn't sufficient.
>> To be effective, the intermediate _public key_ needs to be revoked somehow.
>
>
> I agree with this, except not just intermediates.
> Revocation should be done by either the public key or the certificate
> everywhere (intermediates and end-entity.)
> But practically, because of CA operations, I think it makes sense to
> revoke by public key for intermediates and by certificates for
> end-entity.
>
> That said, it's a bit beyond our mandate to redo revocation for the
> whole internet....

I agree, revocation is not within CT's remit :-)

Obviously its important, though!

> ==================================
>
> On 15 March 2016 at 08:50, Ben Laurie  wrote:
>>
>> 3. Always revoke bad certs that appear in logs!
>
> That revocation would need to be via crl-sets or OneCRL.  So while
> this... could work: If I'm the smart attacker I'm going to spam the
> everloving shit out of the log with bad certs. And when you have to
> revoke 1 million certificates via crl-sets you will be sad. =)

The smart attacker will cause his roots/intermediates to be dropped
from the logs if he does that.

>
> So....
>
> ==================================
>
> On 15 March 2016 at 08:51, Ben Laurie  wrote:
>> Oh, also:
>>
>> 4. Require SCTs for all certs in the chain, which prevents hiding the
>> alternate intermediate.
>
> I think this is the answer.  I think we need SCTs for all the certs in
> the chain.  And yea, I think we need to mandate this.
>
> But how? It's a huge change right, it's going to be some time before
> Intermediates are issued as PreCerts. So there'll probably need to be
> a bandaid for the time being. The only thing I can think of is using
> Mozilla's Intermediate database and hardcoding a few kilobytes of SCTs
> into browsers.  Ugly but... could get most of the way there?

Yeah, that sounds plausible. FWIW, we're currently pushing an update
to our log pre-loader that should cause all intermediates we see to be
logged, so that would provide another way to construct such a list.

>
> ==================================
>
> I'll also note that right now we (Gossip authors) don't want to make
> defending against this attack one of Gossip's responsabilities.  But
> we can defend against this attack in a certain configuration.  We have
> some in-progress text I wrote this morning about it, but it is
> in-progress. https://github.com/ln5/draft-ietf-trans-gossip/pull/16/files

Interesting.


From nobody Fri Mar 18 06:15:46 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B99512D56E for ; Fri, 18 Mar 2016 06:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1PaK5Ss8fIq for ; Fri, 18 Mar 2016 06:15:42 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8B212D556 for ; Fri, 18 Mar 2016 06:15:42 -0700 (PDT)
Received: by mail-ig0-x22a.google.com with SMTP id vf5so21869620igb.0 for ; Fri, 18 Mar 2016 06:15:42 -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; bh=a9Gypw9JEF0rdN9+/pkkk0cWDpUBJ9p6/kt86yMWErY=; b=EdR5QHekDzIbt4L3dzE8QttKCc+D2iWLc70mnCjrpb88VRW7ZW5csgp3vwSDNT3SLV QhevuMJuAutBsy0lOn8bfWXWGRjnKZoVdQ+fn0aOxiwxJ+MLqXiCwTt3AD1sXfzCImsb Tl8iCWQIByoSgnS0qhSVbhPH2s5YErWBHZz1ZU0/P0vEazxO1CnkQ44ufcDBIJ9690B4 fRK2AbgQ/os9UyeDqa7Coah0eRBvcsiz9VauIiLvXuYW0nUSMT2UzwBSpBsPrh3FZT0e HqM/4DG7yAUSiMwFKcOF1RlqB71J7C1Y4CZXn7p+SzRpwdTmUJc4e649KfEW3ucgRg7J UE9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=a9Gypw9JEF0rdN9+/pkkk0cWDpUBJ9p6/kt86yMWErY=; b=flHbA3NOxb5/optuNiL7F2q367NqTpP35Fjj10pIJQ58hdyy8o1PphcDx0f3fjhGak q/v4SFhgFg5B9AWA+v2/DyHbspNL01UDoP+ZvzvVp/kaHUGmdfU5Y5WRWEqSV3QAVUZ1 5kMKID76FyIC6mQ/fOWOjO5Nb0CzKXcgCww1FkH1MJRNxTpUocXIeRHUaCE9D2a/O3vm FG63dy321L0VHg/UfYiFTv1Jia0pf8uEZ4/auTeQ0e4fhBLjPxYJNxze7Wv75MfzPsXw fbMBUQnqKC+FDrcdjgu7N4uJeTX33dT5C4yZ2xxwA32VVppvPWJmNOUjytPed+iitHaG 9leA==
X-Gm-Message-State: AD7BkJLJCyBVCTzZXHyvMfC4qwbHWZvP8wZ3CNWw8G1nykWL5sX5JjpamO4ozur+iXtbq8RYkoxVkAU5NihVmFIe
MIME-Version: 1.0
X-Received: by 10.50.40.36 with SMTP id u4mr17248511igk.23.1458306941721; Fri, 18 Mar 2016 06:15:41 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Fri, 18 Mar 2016 06:15:41 -0700 (PDT)
In-Reply-To: <56EAC688.1030707@bbn.com>
References: <56E6CD30.8070102@bbn.com>  <56E99B71.7060003@bbn.com>  <56EAC688.1030707@bbn.com>
Date: Fri, 18 Mar 2016 13:15:41 +0000
Message-ID: 
From: Ben Laurie 
To: Stephen Kent 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 13:15:44 -0000

On 17 March 2016 at 15:00, Stephen Kent  wrote:
> Ben,
>
>
> OK. If you are right, then its pretty clear that any implementation that
> relies on CRLs/OCSP specified further up the path than the EE cert has a
> serious problem that has nothing to do with CT.
>
> Yes, I am right. But, again, I am puzzled by your comment. In PKIs in
> general, the revocation
> status of an EE cert is specified by the CA that issued the cert. (There are
> provisions
> for indirect CRLs, but that's not a commonly used mechanism). RFC 5280
> recognizes that there
> can be vulnerabilities associated with acquiring CRLs or OCSP data in some
> contexts, and
> that's why AIA allows a CA to tell RPs where to acquire such data. However,
> for backward
> compatibility purposes, and because this is not a problem in all contexts,
> 5280 does not
> mandate use  of this extension. Thus one ought not assume that it is always
> present,
> and it is appropriate to acknowledge this residual vulnerability where
> applicable.

I am struggling to imagine a context in which this is not a problem.
But maybe there is one.

> Note, that the RPKI does mandate use of AIA to point to CRLs, and relying
> parties
> in that context are required to verify that the extension is present,. If
> it's missing
> the cert (EE or CA) is rejected.
>
> The CT related problem is that people could perhaps be fooled into
> thinking it was not necessary to revoke some logged bogus certificates
> because they appear to come from a chain that was not trusted anyway.
>
> True. Also, a browser vendor might decide that it didn't need to blacklist
> the
> EE cert because it had already been revoked by the CA.

I think that would depend on the EE cert (i.e. does it include the
AIAs needed?).

> Don't forget that the purpose of CT is to reveal problems with
> certificates, not to solve them.
>
> My characterization of CT (draft-kent-trans-architecture-02.txt) is:
>
>    Certificate transparency (CT) is a set of mechanisms designed to
>    deter, detect, and facilitate remediation of certificate mis-issuance
>    (as defined below).
>
> I wrote this (month ago) because I thought it was useful to provide a
> concise
> characterization of CT goals. Do you disagree with the text above?

No.

>
> Also, I don't get the logic of the "not-logged bogus certificate",
> which is identical to the logged certificate - and is therefore
> logged. And not bogus.
>
> A cert is bogus when it is issued to an entity that is not authorized
> to represent the Subject of the cert. This is true whether the cert is
> logged or not.
>
> Ah, I see. In that case, is the cert in question not a "logged bogus cert"?
>
>
> yes, it is.
>
> Steve
>
>


From nobody Fri Mar 18 06:56:28 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC3A12D9AC for ; Fri, 18 Mar 2016 06:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv0CXcH8kGyu for ; Fri, 18 Mar 2016 06:56:22 -0700 (PDT)
Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F07612D9AB for ; Fri, 18 Mar 2016 06:55:11 -0700 (PDT)
Received: (qmail 5953 invoked by uid 1004); 18 Mar 2016 13:55:08 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 18 Mar 2016 13:55:08 +0000
Received: (qmail 11505 invoked by uid 1000); 18 Mar 2016 13:55:08 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 18 Mar 2016 13:55:08 +0000
To: Stephen Kent , trans@ietf.org
References: <56E6CD30.8070102@bbn.com>  <56E737EC.9020203@comodo.com> <56E99BC3.80606@bbn.com>
From: Rob Stradling 
Message-ID: <56EC08BC.7010404@comodo.com>
Date: Fri, 18 Mar 2016 13:55:08 +0000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <56E99BC3.80606@bbn.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 13:56:27 -0000

On 16/03/16 17:45, Stephen Kent wrote:
> Rob,

>> So we (where "we" may or may not be TRANS) need to fix revocation!
>> Revoking an intermediate _certificate_ just isn't sufficient.
>> To be effective, the intermediate _public key_ needs to be revoked
>> somehow.
>
> One does not revoke keys in a PKI. One revokes certs.

Steve, I know very well how the existing IETF mechanisms for revocation 
(i.e. CRL and OCSP) work.  But I don't see why that should mean that new 
revocation mechanisms can't be invented, especially if those new 
mechanisms can thwart attacks that CRL and OCSP can't.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Fri Mar 18 07:10:28 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD97D12D5C9 for ; Fri, 18 Mar 2016 07:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Level: 
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1bo2OjuJioJ for ; Fri, 18 Mar 2016 07:10:19 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 17C2C12D64B for ; Fri, 18 Mar 2016 07:09:17 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6678742370E; Fri, 18 Mar 2016 14:09:16 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 50685423707; Fri, 18 Mar 2016 14:09:16 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458310156; bh=4T6CxPrYVAdP4mZfRZ9/IJqrR6ShGrVjF28AEtdv+Yo=; l=468; h=From:To:Date:References:In-Reply-To:From; b=etUyAjER3eM5zhmz3zXdXDoW/aIyi0WP2FwmL/ody0dPvDa+DpfsDwn6ZYOh8JBCi pe0Xcp1tkxsJvToeB+4zTpD01tC1xYBk1EV4GDMd2F4TvgDjwUnd6xmehFxK2JQ03L J3d8KVQ1k7VVjqmo6kBSIQ8YBrAjnzwUjQtHmlZc=
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 4C9C61FC86; Fri, 18 Mar 2016 14:09:16 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 18 Mar 2016 10:09:15 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Fri, 18 Mar 2016 10:09:15 -0400
From: "Salz, Rich" 
To: Rob Stradling , Stephen Kent , "trans@ietf.org" 
Thread-Topic: [Trans] text to address DKG's conspiring CAs attack
Thread-Index: AQHRff/crGaMUoFfSkalLfdFo0PVGZ9ZuuuAgAAKEgCAAtlfgIAC5EIA///AxPA=
Date: Fri, 18 Mar 2016 14:09:15 +0000
Message-ID: 
References: <56E6CD30.8070102@bbn.com>  <56E737EC.9020203@comodo.com> <56E99BC3.80606@bbn.com> <56EC08BC.7010404@comodo.com>
In-Reply-To: <56EC08BC.7010404@comodo.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.114]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 14:10:26 -0000

> Steve, I know very well how the existing IETF mechanisms for revocation (=
i.e.
> CRL and OCSP) work.  But I don't see why that should mean that new
> revocation mechanisms can't be invented, especially if those new
> mechanisms can thwart attacks that CRL and OCSP can't.

And it would also require changes to CT, no?

I think raw key stuff is out of scope for now.

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


From nobody Fri Mar 18 07:12:10 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B957412D54E for ; Fri, 18 Mar 2016 07:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PXfmJ1uEWjx for ; Fri, 18 Mar 2016 07:12:07 -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 1623412D593 for ; Fri, 18 Mar 2016 07:12:06 -0700 (PDT)
Received: from localhost ([::1]:34264 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agv8H-0008RV-TP; Fri, 18 Mar 2016 07:12: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: eranm@google.com, hadfieldp@google.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 14:12:05 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/118#comment:5
Message-ID: <068.dd1a46111ae646c1b9ace63cdd72c889@tools.ietf.org>
References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org>
X-Trac-Ticket-ID: 118
In-Reply-To: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, hadfieldp@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 14:12:08 -0000

#118: Monitor function description problem

Changes (by eranm@google.com):

 * milestone:   => review


Comment:

 Landed in https://github.com/google/certificate-transparency-
 rfcs/commit/7120d1867d40522f65c8fe19191388c6b88560c7

-- 
--------------------------+-------------------------------
 Reporter:  kent@bbn.com  |       Owner:  eranm@google.com
     Type:  defect        |      Status:  new
 Priority:  major         |   Milestone:  review
Component:  rfc6962-bis   |     Version:
 Severity:  -             |  Resolution:
 Keywords:                |
--------------------------+-------------------------------

Ticket URL: 
trans 


From nobody Fri Mar 18 07:12:43 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C9612D5C9 for ; Fri, 18 Mar 2016 07:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGkgNRNAMP2B for ; Fri, 18 Mar 2016 07:12: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 81C2812D582 for ; Fri, 18 Mar 2016 07:12:40 -0700 (PDT)
Received: from localhost ([::1]:34303 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agv8q-0000Cx-Dt; Fri, 18 Mar 2016 07:12: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: eranm@google.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 14:12:40 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/153#comment:3
Message-ID: <080.f6372777d43eec645ac7321cddae144c@tools.ietf.org>
References: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org>
X-Trac-Ticket-ID: 153
In-Reply-To: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #153 (rfc6962-bis): Finish documenting support for RFC6962 (v1) structures in TransInfo
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 14:12:42 -0000

#153: Finish documenting support for RFC6962 (v1) structures in TransInfo

Changes (by eranm@google.com):

 * milestone:   => review


Comment:

 Landed in https://github.com/google/certificate-transparency-
 rfcs/commit/ddaff4fc87cb52bbcb84891abec6cdac371d2935

-- 
--------------------------------------+-------------------------------
 Reporter:  rob.stradling@comodo.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 Fri Mar 18 07:14:21 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A77412D593 for ; Fri, 18 Mar 2016 07:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7OM21hGjM6F for ; Fri, 18 Mar 2016 07:14: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 C5E2712D55F for ; Fri, 18 Mar 2016 07:14:16 -0700 (PDT)
Received: from localhost ([::1]:34406 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agvAO-0002DS-Dj; Fri, 18 Mar 2016 07:14:16 -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: Fri, 18 Mar 2016 14:14:16 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/131#comment:2
Message-ID: <076.d346558d82229b5e4a60a3b4d4d76501@tools.ietf.org>
References: <061.a402b343ec62e8c46fdf8f5ebd7a8dc0@tools.ietf.org>
X-Trac-Ticket-ID: 131
In-Reply-To: <061.a402b343ec62e8c46fdf8f5ebd7a8dc0@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #131 (rfc6962-bis): missing guidance for TLS servers to select logs
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 14:14:19 -0000

#131: missing guidance for TLS servers to select logs

Changes (by eranm@google.com):

 * milestone:   => review


Comment:

 Landed in https://github.com/google/certificate-transparency-
 rfcs/commit/f2c1120f8f77461b8d36224ac211eef8257efa33

-- 
----------------------------------+-------------------------------
 Reporter:  david@mandelberg.org  |       Owner:  eranm@google.com
     Type:  enhancement           |      Status:  new
 Priority:  major                 |   Milestone:  review
Component:  rfc6962-bis           |     Version:
 Severity:  -                     |  Resolution:
 Keywords:                        |
----------------------------------+-------------------------------

Ticket URL: 
trans 


From nobody Fri Mar 18 07:19:39 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8437212D5DB for ; Fri, 18 Mar 2016 07:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIs70zQ0_GD0 for ; Fri, 18 Mar 2016 07:19:36 -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 E360E12D5CF for ; Fri, 18 Mar 2016 07:19:30 -0700 (PDT)
Received: (qmail 7263 invoked by uid 1004); 18 Mar 2016 14:19:28 -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, 18 Mar 2016 14:19:28 +0000
Received: (qmail 6103 invoked by uid 1000); 18 Mar 2016 14:19:28 -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, 18 Mar 2016 14:19:28 +0000
To: "Salz, Rich" , Stephen Kent , "trans@ietf.org" 
References: <56E6CD30.8070102@bbn.com>  <56E737EC.9020203@comodo.com> <56E99BC3.80606@bbn.com> <56EC08BC.7010404@comodo.com> 
From: Rob Stradling 
Message-ID: <56EC0E70.7060103@comodo.com>
Date: Fri, 18 Mar 2016 14:19:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.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] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 14:19:38 -0000

On 18/03/16 14:09, Salz, Rich wrote:
>> Steve, I know very well how the existing IETF mechanisms for revocation (i.e.
>> CRL and OCSP) work.  But I don't see why that should mean that new
>> revocation mechanisms can't be invented, especially if those new
>> mechanisms can thwart attacks that CRL and OCSP can't.
>
> And it would also require changes to CT, no?

No.  Revoking intermediate keys is one way to defeat DKG's attack.  If 
we decide that this is _the_ way that we plan to defeat DKG's attack, 
then we (for some value of "we") will need to define such a mechanism, 
but CT won't need to be changed.

> I think raw key stuff is out of scope for now.

Indeed.  Revocation is out of scope for CT anyway.

-- 
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 Fri Mar 18 08:09:11 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5688A12D8FB for ; Fri, 18 Mar 2016 08:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzP4FWsaJTgl for ; Fri, 18 Mar 2016 08:09:08 -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 8765612D563 for ; Fri, 18 Mar 2016 08:09:08 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:59715 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agw1O-0002sn-4a for trans@ietf.org; Fri, 18 Mar 2016 11:09:02 -0400
From: Stephen Kent 
To: trans@ietf.org
References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> <068.0779562256ffb55d064ab4f9e5d0a31c@tools.ietf.org> <56E99CFA.8010601@bbn.com> 
Message-ID: <56EC1A0D.5030308@bbn.com>
Date: Fri, 18 Mar 2016 11:09:01 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.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] #118 (rfc6962-bis): Monitor function description problem
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 15:09:10 -0000

Eran,


> There may be a misunderstanding here: in 6962-bis the Auditor entity 
> was replaced with an auditing role, that different entities (a Monitor 
> being one) can take.
I recall when you and your co-authors unilaterally decided that there 
would be no Auditor
as a separate CT element. Both DKG and I complained about that decision, 
to no avail.
However, let's compromise and consider both Monitors and Auditors to be 
functions or roles.
so that readers do not assume that these roles must be implemented by 
separate systems. OK?

I object to the current wording in the Monitor description because it 
mandates that a Monitor
perform auditing, and does not mandate that it perform what I see as the 
the basic Monitor role.
As currently described, there is no mandated role in CT that observes 
logs looking for possibly
bogus certs on behalf of Subjects. This strikes me as a serious omission.

> Section 9.4. of draft 12 explains how monitors can audit and how TLS 
> clients can, while section 9.3., about Monitors, describes the process 
> a Monitor should use to audit.
Rob Stradling reviewed my Monitor doc a few month ago and agreed with 
the description,
noting that his implementation of a Monitor also did not perform 
auditing. (It just
observes logs to detect certs of "interest." I mentioned this on the 
TRANS list as part
of why I believe that it is inappropriate to mandate any Auditor 
functions as
part of the Monitor role. again, this feedback seems to have been ignored.
> I believe that change was partly made thanks to your feedback that the 
> Monitor and Auditor entities have some overlap and the distinction 
> wasn't quite clear.
The distinction was not clear, but this revised set of definitions is 
worse, i.e.,
it does not require a Monitor to watch for potentially bogus certs.

Steve


From nobody Fri Mar 18 10:00:40 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45FA12D5CA for ; Fri, 18 Mar 2016 10:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVy4yJwpqOHi for ; Fri, 18 Mar 2016 10:00:36 -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 30B1612D63B for ; Fri, 18 Mar 2016 10:00:28 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:33362 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1agxlC-000426-1b for trans@ietf.org; Fri, 18 Mar 2016 13:00:26 -0400
To: trans@ietf.org
References:  
From: Stephen Kent 
Message-ID: <56EC3429.60200@bbn.com>
Date: Fri, 18 Mar 2016 13:00:25 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030606030209090607070109"
Archived-At: 
Subject: Re: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 17:00:39 -0000

This is a multi-part message in MIME format.
--------------030606030209090607070109
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Bryan,

Thanks for the feedback.

I added text to address the concerns you cited about the threat analysis 
document
last year, based on comments you made in the London meeting. I don't 
recall you mentioning
this specific concern at that time or in subsequent messages. Can you 
refer me to one or
more specific message in which you cited the oversight you mentioned below?

> I finally had a chance to take a look at the latest version of the 
> threat analysis document.
>
> Months ago, I pointed out that the document presents a lopsided view 
> of the potential types of attacks, in general considering only attacks 
> in which CAs or log servers misbehave “in place”, while completely 
> neglecting even to mention the large class of attack scenarios in 
> which an attacker steals the servers’ keys and uses them to create 
> secret “evil twins” of the CAs and/or log servers elsewhere on the 
> Internet (or off the Internet) in domains more under the attacker’s 
> control.  In other words, the attacker leaves the “normal” CAs and log 
> servers that most of the Internet sees operating completely normally 
> and appearing to be honest, but creates and uses evil twins of those 
> CAs and log servers elsewhere for (basically undetectable) attacks 
> against target victims.
I will write text to address a class of attacks where a CA's or a a 
log's private key is compromised
and the attack is undetected. I do agree with Ben, however, about the 
difficulty faced by CT or other
mechanisms when users operate in an isolated environment. If a user 
lives in a country where the
telecom infrastructure is controlled by state security forces, there may 
be few if any ways for
the user to acquire externally supplied security info. I don't 
anticipate addressing that topic.

Also, BTW, Eran (a co-author of 6962-bis) provided feedback on the treat 
analysis document,
which was reflected in the -02 version.

Steve

--------------030606030209090607070109
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Bryan,

    

    Thanks for the feedback.

    

    I added text to address the concerns you cited about the threat
    analysis document

    last year, based on comments you made in the London meeting. I don't
    recall you mentioning 

    this specific concern at that time or in subsequent messages. Can
    you refer me to one or

    more specific message in which you cited the oversight you mentioned
    below?

    


    

    

      
      
I finally had a chance to take a look at the latest
        version of the threat analysis document.

      


      

      
Months ago, I pointed out that the document presents
        a lopsided view of the potential types of attacks, in general
        considering only attacks in which CAs or log servers misbehave
        “in place”, while completely neglecting even to mention the
        large class of attack scenarios in which an attacker steals the
        servers’ keys and uses them to create secret “evil twins” of the
        CAs and/or log servers elsewhere on the Internet (or off the
        Internet) in domains more under the attacker’s control.  In
        other words, the attacker leaves the “normal” CAs and log
        servers that most of the Internet sees operating completely
        normally and appearing to be honest, but creates and uses evil
        twins of those CAs and log servers elsewhere for (basically
        undetectable) attacks against target victims.

    

    I will write text to address a class of attacks where a CA's or a a
    log's private key is compromised 

    and the attack is undetected. I do agree with Ben, however, about
    the difficulty faced by CT or other

    mechanisms when users operate in an isolated environment. If a user
    lives in a country where the

    telecom infrastructure is controlled by state security forces, there
    may be few if any ways for

    the user to acquire externally supplied security info. I don't
    anticipate addressing that topic.

    

    Also, BTW, Eran (a co-author of 6962-bis) provided feedback on the
    treat analysis document,

    which was reflected in the -02 version.

    

    Steve

  


--------------030606030209090607070109--


From nobody Fri Mar 18 12:17:25 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5AF12D6C2 for ; Fri, 18 Mar 2016 12:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3Dv4Jf7Z7tK for ; Fri, 18 Mar 2016 12:17: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 D498F12D628 for ; Fri, 18 Mar 2016 12:17:21 -0700 (PDT)
Received: from localhost ([::1]:58546 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agztg-0000OW-9T; Fri, 18 Mar 2016 12:17:20 -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, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 19:17:19 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/153#comment:4
Message-ID: <080.4a726afea167adb66e40531b1829c665@tools.ietf.org>
References: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org>
X-Trac-Ticket-ID: 153
In-Reply-To: <065.3de457ef6eb3dbd65bcf5150524add75@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, melinda.shore@gmail.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #153 (rfc6962-bis): Finish documenting support for RFC6962 (v1) structures in TransInfo
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 19:17:23 -0000

#153: Finish documenting support for RFC6962 (v1) structures in TransInfo

Changes (by melinda.shore@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
--------------------------------------+-------------------------------
 Reporter:  rob.stradling@comodo.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 Fri Mar 18 12:19:22 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240DC12D50C for ; Fri, 18 Mar 2016 12:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju67xwAOJCwn for ; Fri, 18 Mar 2016 12:19:18 -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 4A89012D6D7 for ; Fri, 18 Mar 2016 12:19:15 -0700 (PDT)
Received: from localhost ([::1]:58970 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agzvU-0005z6-Q0; Fri, 18 Mar 2016 12:19: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: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 19:19:12 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/81#comment:8
Message-ID: <080.33ed1aceb59d566b918a9dca50ca9889@tools.ietf.org>
References: <065.7e2aed9eafe145755b95ef51d9921722@tools.ietf.org>
X-Trac-Ticket-ID: 81
In-Reply-To: <065.7e2aed9eafe145755b95ef51d9921722@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com, eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 19:19:21 -0000

#81: OIDs and IANA Considerations

Changes (by melinda.shore@gmail.com):

 * status:  assigned => closed
 * resolution:   => fixed


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling@comodo.com           |  rob.stradling@comodo.com
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:  review
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Fri Mar 18 12:23:20 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C8E12D6C2 for ; Fri, 18 Mar 2016 12:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9D-R-I1bAYt for ; Fri, 18 Mar 2016 12:23: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 B5CAB12D564 for ; Fri, 18 Mar 2016 12:23:17 -0700 (PDT)
Received: from localhost ([::1]:59936 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agzzQ-0001p3-PI; Fri, 18 Mar 2016 12:23:16 -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, hadfieldp@google.com, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 19:23:16 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/118#comment:6
Message-ID: <068.656abb1dbab7e74c433bb9a63180c71f@tools.ietf.org>
References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org>
X-Trac-Ticket-ID: 118
In-Reply-To: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, hadfieldp@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] #118 (rfc6962-bis): Monitor function description problem
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 19:23:19 -0000

#118: Monitor function description problem

Changes (by melinda.shore@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
--------------------------+-------------------------------
 Reporter:  kent@bbn.com  |       Owner:  eranm@google.com
     Type:  defect        |      Status:  closed
 Priority:  major         |   Milestone:  review
Component:  rfc6962-bis   |     Version:
 Severity:  -             |  Resolution:  fixed
 Keywords:                |
--------------------------+-------------------------------

Ticket URL: 
trans 


From nobody Fri Mar 18 12:23:44 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFBB12D757 for ; Fri, 18 Mar 2016 12:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2e1fy5k8tUn for ; Fri, 18 Mar 2016 12:23: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 5FD8A12D728 for ; Fri, 18 Mar 2016 12:23:40 -0700 (PDT)
Received: from localhost ([::1]:59963 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1agzzn-0004aT-Ur; Fri, 18 Mar 2016 12:23: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: eranm@google.com, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 19:23:39 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/142#comment:5
Message-ID: <080.586d36f32ad98a3546c31846531f2ec9@tools.ietf.org>
References: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org>
X-Trac-Ticket-ID: 142
In-Reply-To: <065.b41f045ee2b9e04edf383be8a676ae50@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, 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] #142 (rfc6962-bis): Specify what TLS clients should send in the extension_data of the transparency_info TLS extension
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 19:23:42 -0000

#142: Specify what TLS clients should send in the extension_data of the
transparency_info TLS extension

Changes (by melinda.shore@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
--------------------------------------+-------------------------------
 Reporter:  rob.stradling@comodo.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 Fri Mar 18 12:24:12 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560F612D5B8 for ; Fri, 18 Mar 2016 12:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZMVbxIUl5I9 for ; Fri, 18 Mar 2016 12:24:09 -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 CB59712D5A5 for ; Fri, 18 Mar 2016 12:24:09 -0700 (PDT)
Received: from localhost ([::1]:59997 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ah00F-0006Q9-3M; Fri, 18 Mar 2016 12:24:07 -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: Fri, 18 Mar 2016 19:24:07 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/155#comment:2
Message-ID: <072.386cbfc5ac1902e0caac19106175d7a6@tools.ietf.org>
References: <057.8604f552ae07311e21d62f3ee9f24898@tools.ietf.org>
X-Trac-Ticket-ID: 155
In-Reply-To: <057.8604f552ae07311e21d62f3ee9f24898@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, melinda.shore@gmail.com, kent@bbn.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org, kent@bbn.com
Subject: Re: [Trans] [trans] #155 (rfc6962-bis): Describe how to match SCTs to certificates
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 19:24:11 -0000

#155: Describe how to match SCTs to certificates

Changes (by melinda.shore@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
------------------------------+---------------------------------------
 Reporter:  eranm@google.com  |       Owner:  rob.stradling@comodo.com
     Type:  defect            |      Status:  closed
 Priority:  major             |   Milestone:  review
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:  fixed
 Keywords:                    |
------------------------------+---------------------------------------

Ticket URL: 
trans 


From nobody Fri Mar 18 12:24:37 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E59212D68C for ; Fri, 18 Mar 2016 12:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx8H-f4_3m0Y for ; Fri, 18 Mar 2016 12:24: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 CC31D12D6C2 for ; Fri, 18 Mar 2016 12:24:34 -0700 (PDT)
Received: from localhost ([::1]:60032 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ah00f-0007Sm-FE; Fri, 18 Mar 2016 12:24:34 -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, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Fri, 18 Mar 2016 19:24:33 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/131#comment:3
Message-ID: <076.2774157e5feb90e7b7d825b7b7374d7b@tools.ietf.org>
References: <061.a402b343ec62e8c46fdf8f5ebd7a8dc0@tools.ietf.org>
X-Trac-Ticket-ID: 131
In-Reply-To: <061.a402b343ec62e8c46fdf8f5ebd7a8dc0@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, melinda.shore@gmail.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #131 (rfc6962-bis): missing guidance for TLS servers to select logs
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Mar 2016 19:24:36 -0000

#131: missing guidance for TLS servers to select logs

Changes (by melinda.shore@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
----------------------------------+-------------------------------
 Reporter:  david@mandelberg.org  |       Owner:  eranm@google.com
     Type:  enhancement           |      Status:  closed
 Priority:  major                 |   Milestone:  review
Component:  rfc6962-bis           |     Version:
 Severity:  -                     |  Resolution:  fixed
 Keywords:                        |
----------------------------------+-------------------------------

Ticket URL: 
trans 


From nobody Sun Mar 20 10:30:09 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4741A12D563 for ; Sun, 20 Mar 2016 10:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level: 
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2jdG9lJGt5C for ; Sun, 20 Mar 2016 10:30:06 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A8C12D516 for ; Sun, 20 Mar 2016 10:30:06 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qSmDr0trHz3QH; Sun, 20 Mar 2016 18:30:04 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id MZEeGUBt1IOR; Sun, 20 Mar 2016 18:30:02 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 20 Mar 2016 18:30:02 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 914CB6019B73; Sun, 20 Mar 2016 13:30:01 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 914CB6019B73
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8CB5B26087; Sun, 20 Mar 2016 13:30:01 -0400 (EDT)
Date: Sun, 20 Mar 2016 13:30:01 -0400 (EDT)
From: Paul Wouters 
To: Trans , Melinda Shore ,  Stephen Kent 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: 
Subject: Re: [Trans] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2016 17:30:07 -0000

On Wed, 2 Mar 2016, Paul Wouters wrote:

> From: Paul Wouters 
> To: Trans , Melinda Shore 
> Subject: [Trans] Working Group Last Call for
>     draft-ietf-trans-threat-analysis (fwd)
> 
>
> This starts a two week WGLC for draft-ietf-trans-threat-analysis
>
> https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/
>
> The purpose of the WG Last Call is to get working group consensus that
> the document is complete and provides a threat analysis that is useful
> to implementors of CT. If you feel this document should not proceed,
> please also let us know why you think so.
>
> Please send all comments to the list.
>
> The WGLC ends on March 16, 2016

So the WGLC ended but it seems we still need another iteration of the
draft to work out the dual CA compromise attack. I'm also would like
to see a few more people read the document for other issues, as it
seems the discussion mostly focused on this one attack.

We will do another WGLC once Steve has produced another version of
the draft. It would be nice if we could finish this before IETF-95.

Paul


From nobody Mon Mar 21 04:08:44 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA212D627 for ; Mon, 21 Mar 2016 04:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBIqGTPW7ydQ for ; Mon, 21 Mar 2016 04:08:36 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 4F4E912D734 for ; Mon, 21 Mar 2016 04:08:28 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id h65so67620169ywe.0 for ; Mon, 21 Mar 2016 04:08:28 -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; bh=PfvPaMPkd5GzOVcWgn5CC8m1COy6YQIiiDFsTKdcseI=; b=CWYGmZg7zGgoRdHOcXpLiHPjF8fFuujt1ne6wGB3FOgg0zPH49rZO7AML7r4RhnMGb Kx48AW6Pl0bwW0zr8CIvhpYdiYYwtLgaABlPUGaXBtZ1VzFsp/Mtu+63gy1TDDWBZXav IRlXH39p/CBFpUaoNkswylhiOeVtSANpPi1w/RT31Cz95189pAuFLEksVHztuoLLWmQE vGHLW/rVFU3OkVXrmOobivD8ht+3TPxLazMMrZUzEUo7Nwv4a3jHPtVs26ea2a2qzUBv LVFEeqYAzCX+mXGw8ZTy5IyWeldlqlfkJPARnVY5ak/Kbf3sEcVKSq3JbZ9TWigFTJ0F Vndg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PfvPaMPkd5GzOVcWgn5CC8m1COy6YQIiiDFsTKdcseI=; b=ASoRiheELohj4tMVhyMBcVcH1NyMXEY1qIpYcTUh5UO/6RYu744X6OdAfvhP1srIMX aMAT1UNLdCCMIYVvlTZJ0foIi/5SkXYkB4OtlCdVvUzOFGYhKsTVhhEchseOyvOigqYf 0rshY7CU0lT6hieyloIUEYvlahhl3PCl5W1h9I7BpZRJb+r+LE7Jdk0eXIquma9/Etfc QMZV69DMXUU9yht6NxxowrgktLD9FlHrUFAwcUUAZYhenriG7hVLUxr/gvTDad6RRau9 aVlvh/gGhxyNQGH+JqJQv9cY52J9QREBpP82NAkaSawDMLfDmFOG6Irg7UZrQcDY7+TU 6jUA==
X-Gm-Message-State: AD7BkJJo0bT+7j0aUn86E4ocZ93dDIVAQ8wVrhTabI6isMtOvVFgksP8KZE5dNk4+3tc/O9r/Ji8vCQ5cvC8tmD+
MIME-Version: 1.0
X-Received: by 10.37.13.204 with SMTP id 195mr7160388ybn.105.1458558507433; Mon, 21 Mar 2016 04:08:27 -0700 (PDT)
Received: by 10.37.48.6 with HTTP; Mon, 21 Mar 2016 04:08:27 -0700 (PDT)
In-Reply-To: <56EC1A0D.5030308@bbn.com>
References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> <068.0779562256ffb55d064ab4f9e5d0a31c@tools.ietf.org> <56E99CFA.8010601@bbn.com>  <56EC1A0D.5030308@bbn.com>
Date: Mon, 21 Mar 2016 11:08:27 +0000
Message-ID: 
From: Eran Messeri 
To: Stephen Kent 
Content-Type: multipart/alternative; boundary=001a11c010b6b8b79d052e8d1d0f
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 11:08:42 -0000

--001a11c010b6b8b79d052e8d1d0f
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 18, 2016 at 3:09 PM, Stephen Kent  wrote:

> Eran,
>
>
> There may be a misunderstanding here: in 6962-bis the Auditor entity was
>> replaced with an auditing role, that different entities (a Monitor being
>> one) can take.
>>
> I recall when you and your co-authors unilaterally decided that there
> would be no Auditor
> as a separate CT element. Both DKG and I complained about that decision,
> to no avail.
> However, let's compromise and consider both Monitors and Auditors to be
> functions or roles.
> so that readers do not assume that these roles must be implemented by
> separate systems. OK?
>
Sounds good! FWIW the reason to remove Auditor as a separate CT element is
that it confused people in 6962-bis and whoever implemented "log clients
that are not just TLS clients" always called them monitors.

>
> I object to the current wording in the Monitor description because it
> mandates that a Monitor
> perform auditing, and does not mandate that it perform what I see as the
> the basic Monitor role.
> As currently described, there is no mandated role in CT that observes logs
> looking for possibly
> bogus certs on behalf of Subjects. This strikes me as a serious omission.
>
> Section 9.4. of draft 12 explains how monitors can audit and how TLS
>> clients can, while section 9.3., about Monitors, describes the process a
>> Monitor should use to audit.
>>
> Rob Stradling reviewed my Monitor doc a few month ago and agreed with the
> description,
> noting that his implementation of a Monitor also did not perform auditing.
> (It just
> observes logs to detect certs of "interest." I mentioned this on the TRANS
> list as part
> of why I believe that it is inappropriate to mandate any Auditor functions
> as
> part of the Monitor role. again, this feedback seems to have been ignored.

This is very valid feedback - the change I've pushed last week (and should
be in a draft 13 I'll publish later today) takes it into account: I've
clarified that a Monitor can do each of these actions (or both) and states
that the rest of the section describes algorithms how to do it, in addition
to saying clients can audit as well (and describe the algorithms they can
use for that).


> I believe that change was partly made thanks to your feedback that the
>> Monitor and Auditor entities have some overlap and the distinction wasn't
>> quite clear.
>>
> The distinction was not clear, but this revised set of definitions is
> worse, i.e.,
> it does not require a Monitor to watch for potentially bogus certs.
>
>
> Steve
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

--001a11c010b6b8b79d052e8d1d0f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Mar 18, 2016 at 3:09 PM, Stephen Kent <kent@bbn.com> =
wrote:
Eran,







There may be a misunderstanding here: in 6962-bis the Auditor entity was re=
placed with an auditing role, that different entities (a Monitor being one)=
 can take.



I recall when you and your co-authors unilaterally decided that there would=
 be no Auditor

as a separate CT element. Both DKG and I complained about that decision, to=
 no avail.

However, let's compromise and consider both Monitors and Auditors to be=
 functions or roles.

so that readers do not assume that these roles must be implemented by separ=
ate systems. OK?
Sounds good! FWIW the reason to remov=
e Auditor as a separate CT element is that it confused people in 6962-bis a=
nd whoever implemented "log clients that are not just TLS clients"=
; always called them monitors.



I object to the current wording in the Monitor description because it manda=
tes that a Monitor

perform auditing, and does not mandate that it perform what I see as the th=
e basic Monitor role.

As currently described, there is no mandated role in CT that observes logs =
looking for possibly

bogus certs on behalf of Subjects. This strikes me as a serious omission.





Section 9.4. of draft 12 explains how monitors can audit and how TLS client=
s can, while section 9.3., about Monitors, describes the process a Monitor =
should use to audit.



Rob Stradling reviewed my Monitor doc a few month ago and agreed with the d=
escription,

noting that his implementation of a Monitor also did not perform auditing. =
(It just

observes logs to detect certs of "interest." I mentioned this on =
the TRANS list as part

of why I believe that it is inappropriate to mandate any Auditor functions =
as

part of the Monitor role. again, this feedback seems to have been ignored.<=
/blockquote>
This is very valid feedback - the change I've pushed l=
ast week (and should be in a draft 13 I'll publish later today) takes i=
t into account: I've clarified that a Monitor can do each of these acti=
ons (or both) and states that the rest of the section describes algorithms =
how to do it, in addition to saying clients can audit as well (and describe=
 the algorithms they can use for that).





I believe that change was partly made thanks to your feedback that the Moni=
tor and Auditor entities have some overlap and the distinction wasn't q=
uite clear.



The distinction was not clear, but this revised set of definitions is worse=
, i.e.,

it does not require a Monitor to watch for potentially bogus certs.




Steve



_______________________________________________

Trans mailing list

Trans@ietf.org

https://www.ietf.org/mailman/listinfo/trans





--001a11c010b6b8b79d052e8d1d0f--


From nobody Mon Mar 21 04:15:03 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388A912D70D for ; Mon, 21 Mar 2016 04:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oMyUrhygnfi for ; Mon, 21 Mar 2016 04:15: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 8731012D640 for ; Mon, 21 Mar 2016 04:15:00 -0700 (PDT)
Received: from localhost ([::1]:40100 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ahxnW-0003OY-Pl; Mon, 21 Mar 2016 04:14: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: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com
X-Trac-Project: trans
Date: Mon, 21 Mar 2016 11:14:58 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/157#comment:1
Message-ID: <080.9cf9ff04754a9f0d50f4a3c21a01b772@tools.ietf.org>
References: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-Trac-Ticket-ID: 157
In-Reply-To: <065.007e30d36ed8223cfb3ab6ae8333ea4b@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: <20160321111500.8731012D640@ietfa.amsl.com>
Resent-Date: Mon, 21 Mar 2016 04:15:00 -0700 (PDT)
Resent-From: trac+trans@tools.ietf.org
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #157 (rfc6962-bis): Conflate Version and TransType
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 11:15:02 -0000

#157: Conflate Version and TransType


Comment (by eranm@google.com):

 Sounds good to me - not only will it remove a field, it will also make it
 crystal clear in implementations which SCTs and other data structures the
 code is referring to (assuming they stick to the RFC naming convention!).

 The only suggestion I have, and it's a very minor one, is to name it
 VersionedTransType.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-trans-
  rob.stradling@comodo.com           |  rfc6962-bis@tools.ietf.org
     Type:  enhancement              |      Status:  new
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Mon Mar 21 04:21:57 2016
Return-Path: 
X-Original-To: trans@ietf.org
Delivered-To: trans@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DC212D74C; Mon, 21 Mar 2016 04:21:53 -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.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160321112153.25099.80272.idtracker@ietfa.amsl.com>
Date: Mon, 21 Mar 2016 04:21:53 -0700
Archived-At: 
Cc: trans@ietf.org
Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-13.txt
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 11:21:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  of the IETF.

        Title           : Certificate Transparency
        Authors         : Ben Laurie
                          Adam Langley
                          Emilia Kasper
                          Eran Messeri
                          Rob Stradling
	Filename        : draft-ietf-trans-rfc6962-bis-13.txt
	Pages           : 50
	Date            : 2016-03-21

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-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-13


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 Mar 21 05:48:21 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2612D553 for ; Mon, 21 Mar 2016 05:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G27XZf7HwxSP for ; Mon, 21 Mar 2016 05:48:18 -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 0755912D526 for ; Mon, 21 Mar 2016 05:48:18 -0700 (PDT)
Received: from localhost ([::1]:47502 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ahzFn-0002N8-PI; Mon, 21 Mar 2016 05:48:15 -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, eranm@google.com
X-Trac-Project: trans
Date: Mon, 21 Mar 2016 12:48:15 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/157#comment:2
Message-ID: <080.82b66ead7f71cdf826776c3cd01b323f@tools.ietf.org>
References: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-Trac-Ticket-ID: 157
In-Reply-To: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #157 (rfc6962-bis): Conflate Version and TransType
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 12:48:19 -0000

#157: Conflate Version and TransType

Changes (by rob.stradling@comodo.com):

 * owner:  draft-ietf-trans-rfc6962-bis@tools.ietf.org =>
     rob.stradling@comodo.com
 * status:  new => assigned


Comment:

 OK.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling@comodo.com           |  rob.stradling@comodo.com
     Type:  enhancement              |      Status:  assigned
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Mon Mar 21 06:43:07 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5BE12D833 for ; Mon, 21 Mar 2016 06:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6kvUw40-FQo for ; Mon, 21 Mar 2016 06:43: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 14B8D12D842 for ; Mon, 21 Mar 2016 06:42:51 -0700 (PDT)
Received: from localhost ([::1]:51554 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ai06X-0006ZO-Gm; Mon, 21 Mar 2016 06:42: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-threat-analysis@tools.ietf.org, linus@nordu.net
X-Trac-Project: trans
Date: Mon, 21 Mar 2016 13:42:45 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/101#comment:1
Message-ID: <069.150ac6304b553fc296bd9d5aabd27278@tools.ietf.org>
References: <054.594fc339510384b88e41096bcfecccc3@tools.ietf.org>
X-Trac-Ticket-ID: 101
In-Reply-To: <054.594fc339510384b88e41096bcfecccc3@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: <20160321134251.14B8D12D842@ietfa.amsl.com>
Resent-Date: Mon, 21 Mar 2016 06:42:51 -0700 (PDT)
Resent-From: trac+trans@tools.ietf.org
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #101 (gossip): Handle Shutdown Log Case
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 13:43:07 -0000

#101: Handle Shutdown Log Case


Comment (by linus@nordu.net):

 Text has been added to upcoming -02 that addresses this.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-threat-
  tom@ritter.vg          |  analysis@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  gossip       |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
trans 


From nobody Mon Mar 21 07:14:48 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0D012D844 for ; Mon, 21 Mar 2016 07:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjoyW6m-jSKe for ; Mon, 21 Mar 2016 07:14: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 72ED512D73D for ; Mon, 21 Mar 2016 07:14:26 -0700 (PDT)
Received: from localhost ([::1]:55035 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ai0bB-0002Sj-55; Mon, 21 Mar 2016 07:14: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-threat-analysis@tools.ietf.org, linus@nordu.net
X-Trac-Project: trans
Date: Mon, 21 Mar 2016 14:14:25 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/103#comment:1
Message-ID: <069.e8ff5e2ba0dcad8599152d7d897b6266@tools.ietf.org>
References: <054.7ef09aa7ae3f095e1a81a92258dd356d@tools.ietf.org>
X-Trac-Ticket-ID: 103
In-Reply-To: <054.7ef09aa7ae3f095e1a81a92258dd356d@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: <20160321141426.72ED512D73D@ietfa.amsl.com>
Resent-Date: Mon, 21 Mar 2016 07:14:26 -0700 (PDT)
Resent-From: trac+trans@tools.ietf.org
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #103 (gossip): Evaluate if we need tighter requirements around STHs when we take into account multiple logs.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 14:14:47 -0000

#103: Evaluate if we need tighter requirements around STHs when we take into
account multiple logs.


Comment (by linus@nordu.net):

 Upcoming -02 has

 - text limiting STH pollination using the logs STH issuance rate and STH
 freshness
 - section "Privacy in STH Interaction" describing some of the privacy
 issues
 - section "Record Distribution Recommendations" suggesting ways of how
 servers can mix STHs (and SCTs) in order to be performant while preserving
 user privacy

 Are we satisfied with this or should we limit STH handling further?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-threat-
  tom@ritter.vg          |  analysis@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  gossip       |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
trans 


From nobody Mon Mar 21 09:17:39 2016
Return-Path: 
X-Original-To: trans@ietf.org
Delivered-To: trans@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2271512D8DC; Mon, 21 Mar 2016 09:17:39 -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.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160321161739.31924.54170.idtracker@ietfa.amsl.com>
Date: Mon, 21 Mar 2016 09:17:39 -0700
Archived-At: 
Cc: trans@ietf.org
Subject: [Trans] I-D Action: draft-ietf-trans-gossip-02.txt
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 16:17:39 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  of the IETF.

        Title           : Gossiping in CT
        Authors         : Linus Nordberg
                          Daniel Kahn Gillmor
                          Tom Ritter
	Filename        : draft-ietf-trans-gossip-02.txt
	Pages           : 47
	Date            : 2016-03-21

Abstract:
   The logs in Certificate Transparency are untrusted in the sense that
   the users of the system don't have to trust that they behave
   correctly since the behaviour of a log can be verified to be correct.

   This document tries to solve the problem with logs presenting a
   "split view" of their operations.  It describes three gossiping
   mechanisms for Certificate Transparency: SCT Feedback, STH
   Pollination and Trusted Auditor Relationship.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-trans-gossip-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-gossip-02


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 Mar 21 11:37:01 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4561612DA1F for ; Mon, 21 Mar 2016 11:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDmilLWhARll for ; Mon, 21 Mar 2016 11:36: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 983FE12DA1C for ; Mon, 21 Mar 2016 11:36:58 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:60145 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ai4hF-0004iD-Fv for trans@ietf.org; Mon, 21 Mar 2016 14:36:57 -0400
From: Stephen Kent 
To: trans@ietf.org
References: <56E6CD30.8070102@bbn.com>  <56E99B71.7060003@bbn.com>  <56EAC688.1030707@bbn.com> 
Message-ID: <56F03F4B.2090304@bbn.com>
Date: Mon, 21 Mar 2016 14:36:59 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000404040901040109020708"
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 18:37:00 -0000

This is a multi-part message in MIME format.
--------------000404040901040109020708
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Ben,


> ...
> I am struggling to imagine a context in which this is not a problem.
> But maybe there is one.
In any environment where all relying parties make use of just one
source of revocation  status info AIA is not required. Also, if the
RPs deal with just one CA, or in a very tightly managed PKI, or ...
Remember, 5280 is the IETF PKI spec for _all_ apps and _all_ contexts,
so it needs to avoid being too proscriptive. For a given app or context one
can profile 52580, as we did for the RPKI, as I noted.

> I think that would depend on the EE cert (i.e. does it include the
> AIAs needed?).
I agree that if the EE cert contained the AIA extension (there can be only
one per cert) and the extension specified the CRL or OSCP source, then
a browser vendor might decide it isn't necessary to blacklist. But, since
this decision is up to each vendor and there are no IETF guidelines for
how to make such a decision, we really can't assume how this is managed
for browsers in general. Also, if one wants to assert that the CT specs
apply to all TLS client/server contexts (as opposed to the HTTPS context
specified in the charter), then the problem is even less bounded.
> I wrote this (month ago) because I thought it was useful to provide a
> concise
> characterization of CT goals. Do you disagree with the text above?
> No.
thanks.

Steve

--------------000404040901040109020708
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Ben,

    

    

    
...
      
I am struggling to imagine a context in which this is not a problem.
But maybe there is one.

    

    In any environment where all relying parties make use of just one

    source of revocation status info AIA is not required. Also, if the

    RPs deal with just one CA, or in a very tightly managed PKI, or ...
    

    Remember, 5280 is the IETF PKI spec for all apps and all
    contexts, 

    so it needs to avoid being too proscriptive. For a given app or
    context one

    can profile 52580, as we did for the RPKI, as I noted.

    

    

      
I think that would depend on the EE cert (i.e. does it include the
AIAs needed?).

    

    I agree that if the EE cert contained the AIA extension (there can
    be only

    one per cert) and the extension specified the CRL or OSCP source,
    then

    a browser vendor might decide it isn't necessary to blacklist. But,
    since

    this decision is up to each vendor and there are no IETF guidelines
    for

    how to make such a decision, we really can't assume how this is
    managed

    for browsers in general. Also, if one wants to assert that the CT
    specs 

    apply to all TLS client/server contexts (as opposed to the HTTPS
    context

    specified in the charter), then the problem is even less bounded.

    

      
I wrote this (month ago) because I thought it was useful to provide a
concise
characterization of CT goals. Do you disagree with the text above?


      
No.

    

    thanks.

    

    Steve

  


--------------000404040901040109020708--


From nobody Mon Mar 21 11:39:06 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A412DA26 for ; Mon, 21 Mar 2016 11:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1YTWfN2bmVA for ; Mon, 21 Mar 2016 11:39:03 -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 00D6112D9FB for ; Mon, 21 Mar 2016 11:39:02 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:60204 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ai4jG-0004kv-6k for trans@ietf.org; Mon, 21 Mar 2016 14:39:02 -0400
From: Stephen Kent 
To: trans@ietf.org
References: <56E6CD30.8070102@bbn.com>  <56E737EC.9020203@comodo.com> <56E99BC3.80606@bbn.com> <56EC08BC.7010404@comodo.com>
Message-ID: <56F03FC8.6050704@bbn.com>
Date: Mon, 21 Mar 2016 14:39:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56EC08BC.7010404@comodo.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Mar 2016 18:39:04 -0000

Rob,

> On 16/03/16 17:45, Stephen Kent wrote:
>> Rob,
> 
>>> So we (where "we" may or may not be TRANS) need to fix revocation!
>>> Revoking an intermediate _certificate_ just isn't sufficient.
>>> To be effective, the intermediate _public key_ needs to be revoked
>>> somehow.
>>
>> One does not revoke keys in a PKI. One revokes certs.
>
> Steve, I know very well how the existing IETF mechanisms for 
> revocation (i.e. CRL and OCSP) work.  But I don't see why that should 
> mean that new revocation mechanisms can't be invented, especially if 
> those new mechanisms can thwart attacks that CRL and OCSP can't.
I don't dispute the potential for developing new revocation mechanisms. 
But, in writing the threat
analysis I am dealing with what is specified in current IETF standards. 
If your comment was meant
to suggest a mechanism for use in browsers, not PKIs in general, then I 
apologize. Also, it would
be good if there were an RFC defining browser cert blacklisting 
mechanisms, so that we might know
what capabilities we can rely on, in general.

Note that, in PKI in general, revoking a key, vs. a cert, may be 
inappropriate. For example, in the
RPKI context we focus on address and ASN extensions as capabilities, for 
authorization. We might
want to revoke a cert, but not the key in the cert, because a new cert 
will be issued with different extensions. We may not want to create 
operational problems by requiring the new cert to have a new key.


Steve


From nobody Tue Mar 22 05:10:38 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8BB12D57D for ; Tue, 22 Mar 2016 05:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj2-jzYdhQTt for ; Tue, 22 Mar 2016 05:10: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 6605212D55A for ; Tue, 22 Mar 2016 05:10:35 -0700 (PDT)
Received: from localhost ([::1]:36918 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aiL8r-0002C9-Er; Tue, 22 Mar 2016 05:10: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: rob.stradling@comodo.com, eranm@google.com
X-Trac-Project: trans
Date: Tue, 22 Mar 2016 12:10:33 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/157#comment:3
Message-ID: <080.44d15509e6def9769e72451d3e93eceb@tools.ietf.org>
References: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-Trac-Ticket-ID: 157
In-Reply-To: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #157 (rfc6962-bis): Conflate Version and TransType
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 12:10:37 -0000

#157: Conflate Version and TransType

Changes (by rob.stradling@comodo.com):

 * milestone:   => review


Comment:

 Fixed by https://github.com/google/certificate-transparency-
 rfcs/commit/919489291b7c9556d70e91e830045d54f7441f1f

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling@comodo.com           |  rob.stradling@comodo.com
     Type:  enhancement              |      Status:  assigned
 Priority:  major                    |   Milestone:  review
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Tue Mar 22 10:09:42 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF6312D7D2 for ; Tue, 22 Mar 2016 10:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M4XzwO82jEz for ; Tue, 22 Mar 2016 10:09:39 -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 4A35D12D7D0 for ; Tue, 22 Mar 2016 10:09:39 -0700 (PDT)
Received: from localhost ([::1]:36100 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aiPoH-0003JX-SI; Tue, 22 Mar 2016 10:09: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: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, rob.stradling@comodo.com
X-Trac-Project: trans
Date: Tue, 22 Mar 2016 17:09:37 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/156#comment:5
Message-ID: <072.cae7fee538d5e579eeabeced212517d2@tools.ietf.org>
References: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-Trac-Ticket-ID: 156
In-Reply-To: <057.0d95c321188cdb7c3a9d91d74944a13b@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, 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: <20160322170939.4A35D12D7D0@ietfa.amsl.com>
Resent-Date: Tue, 22 Mar 2016 10:09:39 -0700 (PDT)
Resent-From: trac+trans@tools.ietf.org
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #156 (rfc6962-bis): Can inclusion proofs properly substitute SCTs?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 17:09:41 -0000

#156: Can inclusion proofs properly substitute SCTs?


Comment (by eranm@google.com):

 A proposed solution is out for review in https://github.com/google
 /certificate-transparency-rfcs/pull/142.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  eranm@google.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 Tue Mar 22 10:13:25 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DA312D1A6 for ; Tue, 22 Mar 2016 10:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqIQyQHl3yH8 for ; Tue, 22 Mar 2016 10:13: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 63D7612D5A7 for ; Tue, 22 Mar 2016 10:07:45 -0700 (PDT)
Received: from localhost ([::1]:35896 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aiPmM-0007BU-WB; Tue, 22 Mar 2016 10:07: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: eranm@google.com, paul@nohats.ca, kent@bbn.com
X-Trac-Project: trans
Date: Tue, 22 Mar 2016 17:07:38 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/141#comment:6
Message-ID: <068.d724702e662050fa1a4aa0e4a9233fd8@tools.ietf.org>
References: <053.8c537c2a7f50054133a842bd78583444@tools.ietf.org>
X-Trac-Ticket-ID: 141
In-Reply-To: <053.8c537c2a7f50054133a842bd78583444@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, paul@nohats.ca, kent@bbn.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #141 (rfc6962-bis): expanding audit description
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 17:13:23 -0000

#141: expanding audit description

Changes (by eranm@google.com):

 * milestone:   => review


Comment:

 Landed in https://github.com/google/certificate-transparency-
 rfcs/commit/5ba34b4843d89a53089995ce814d683ed98c8659

-- 
--------------------------+-------------------------------
 Reporter:  kseo@bbn.com  |       Owner:  eranm@google.com
     Type:  defect        |      Status:  new
 Priority:  major         |   Milestone:  review
Component:  rfc6962-bis   |     Version:
 Severity:  -             |  Resolution:
 Keywords:                |
--------------------------+-------------------------------

Ticket URL: 
trans 


From nobody Tue Mar 22 13:02:18 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4143112D775 for ; Tue, 22 Mar 2016 13:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i3gi35JHGF7 for ; Tue, 22 Mar 2016 13:02: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 C6B5F12D6F9 for ; Tue, 22 Mar 2016 13:02:16 -0700 (PDT)
Received: from localhost ([::1]:49599 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aiSVI-0005Yb-42; Tue, 22 Mar 2016 13:02: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: eranm@google.com, paul@nohats.ca, kent@bbn.com, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Tue, 22 Mar 2016 20:02:12 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/141#comment:7
Message-ID: <068.b218eaf633d5270f5020ade5d45077a7@tools.ietf.org>
References: <053.8c537c2a7f50054133a842bd78583444@tools.ietf.org>
X-Trac-Ticket-ID: 141
In-Reply-To: <053.8c537c2a7f50054133a842bd78583444@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: eranm@google.com, paul@nohats.ca, kent@bbn.com, melinda.shore@gmail.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #141 (rfc6962-bis): expanding audit description
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 20:02:18 -0000

#141: expanding audit description

Changes (by melinda.shore@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
--------------------------+-------------------------------
 Reporter:  kseo@bbn.com  |       Owner:  eranm@google.com
     Type:  defect        |      Status:  closed
 Priority:  major         |   Milestone:  review
Component:  rfc6962-bis   |     Version:
 Severity:  -             |  Resolution:  fixed
 Keywords:                |
--------------------------+-------------------------------

Ticket URL: 
trans 


From nobody Tue Mar 22 13:02:42 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E967B12D840 for ; Tue, 22 Mar 2016 13:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brdivEKdQglB for ; Tue, 22 Mar 2016 13:02:39 -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 E88A112D6F9 for ; Tue, 22 Mar 2016 13:02:38 -0700 (PDT)
Received: from localhost ([::1]:49619 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aiSVh-0005dl-7p; Tue, 22 Mar 2016 13:02: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, eranm@google.com, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Tue, 22 Mar 2016 20:02:37 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/157#comment:4
Message-ID: <080.5391cf87796ac8db08c247185f00c0e1@tools.ietf.org>
References: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-Trac-Ticket-ID: 157
In-Reply-To: <065.007e30d36ed8223cfb3ab6ae8333ea4b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, melinda.shore@gmail.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #157 (rfc6962-bis): Conflate Version and TransType
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 20:02:41 -0000

#157: Conflate Version and TransType

Changes (by melinda.shore@gmail.com):

 * status:  assigned => closed
 * resolution:   => fixed


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling@comodo.com           |  rob.stradling@comodo.com
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:  review
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Wed Mar 23 08:11:43 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A377112D1B5 for ; Wed, 23 Mar 2016 08:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd66euwNzipW for ; Wed, 23 Mar 2016 08:11:38 -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 1E36B12D0EE for ; Wed, 23 Mar 2016 08:11:17 -0700 (PDT)
Received: from localhost ([::1]:40938 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aikRH-0002lY-Et; Wed, 23 Mar 2016 08:11:15 -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, eranm@google.com
X-Trac-Project: trans
Date: Wed, 23 Mar 2016 15:11:15 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/156#comment:6
Message-ID: <072.5fb1f45ea0c183946d9e5508573f69cb@tools.ietf.org>
References: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-Trac-Ticket-ID: 156
In-Reply-To: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #156 (rfc6962-bis): Can inclusion proofs properly substitute SCTs?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 15:11:41 -0000

#156: Can inclusion proofs properly substitute SCTs?

Changes (by eranm@google.com):

 * owner:  draft-ietf-trans-rfc6962-bis@tools.ietf.org =>
     rob.stradling@comodo.com


Comment:

 PR 142 mentioned above was merged.
 Re-assigning to Rob for him to add the mentioned data structure.

-- 
------------------------------+---------------------------------------
 Reporter:  eranm@google.com  |       Owner:  rob.stradling@comodo.com
     Type:  defect            |      Status:  new
 Priority:  critical          |   Milestone:
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |
------------------------------+---------------------------------------

Ticket URL: 
trans 


From nobody Thu Mar 24 08:25:57 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC4612DCF8 for ; Thu, 24 Mar 2016 08:25:56 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSspvoGABCyF for ; Thu, 24 Mar 2016 08:25:53 -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 96C1412DD0E for ; Thu, 24 Mar 2016 08:09:42 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:59515 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aj6tI-0000Qu-RL for trans@ietf.org; Thu, 24 Mar 2016 11:09:40 -0400
From: Stephen Kent 
To: trans@ietf.org
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov>
Message-ID: <56F4032F.9030800@bbn.com>
Date: Thu, 24 Mar 2016 11:09:35 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56EADAA6.6010306@nist.gov>
Content-Type: multipart/alternative; boundary="------------050602060600090606060007"
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 15:25:56 -0000

This is a multi-part message in MIME format.
--------------050602060600090606060007
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

David,

No text in 5280 requires name uniqueness across all CAs. It does require 
uniqueness
on a per-CA basis (Section 4.1.2.6 of 5280). So, when two CAs with 
different parents
are created with the same name, that is not a violation of 5280. The 
creation of
the doppelganger EE certs may violate 5280. The relevant text says:

    The DN MUST be unique for each subject entity certified by _the one 
CA_ as defined
    by the issuer field.

The two CAs in my scenario have different parents, but the same name and 
same public key. So
whether they are "the one CA" named in the issuer field is open to 
debate. I have modified
my text to avoid this issue.

As I explained, my description of an colluding CA attack differs from 
DKGs in that it
is more general and thus. I think, more useful for discussion in the 
threat analysis.

Yes, it is true that CRLs and OCSP responses would not generally be tied 
to the
two CA instances on different cert paths. But, that's not the point. It 
would be dangerous
to assume that an RP can be confident that the revocation status data it 
acquires comes
from a specific instance of a CA, when there are two CAs with the same 
names and
same public keys. RFC 5280 does not provide implementation guidance that 
calls for
pooling of revocation status info based on CA name. An RP may maintain a 
cache organized
by cert path, associating revocation status info with each CA in each 
cert path. Such
an implementation strategy is attractive because it can allow an RP to 
avoid redundant
cert path validation processing when a target cert shares a portion of a 
cert path with
other certs that have been validated. In such an implementation an RP 
would not be aware that
there are two CAs with the same name on different cert paths, and 
revocation status data
associated with each of these CAs would be acquired and maintained 
separately. In such
circumstances an attack of the sort I described is feasible.

Thus I stand by my analysis of the vulnerability, in the more general case.

Steve

--------------050602060600090606060007
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    David,

    

    No text in 5280 requires name uniqueness across all CAs. It does
    require uniqueness

    on a per-CA basis (Section 4.1.2.6 of 5280). So, when two CAs with
    different parents

    are created with the same name, that is not a violation of 5280. The
    creation of

    the doppelganger EE certs may violate 5280. The relevant text says:

    

       The DN MUST be unique for each subject entity certified by the

      one CA as defined 

       by the issuer field.

    

    The two CAs in my scenario have different parents, but the same name
    and same public key. So

    whether they are "the one CA" named in the issuer field is open to
    debate. I have modified 

    my text to avoid this issue.

    

    
 As I explained, my description of an
      colluding CA attack differs from DKGs in that it

      is more general and thus. I think, more useful for discussion in
      the threat analysis.

      

      Yes, it is true that CRLs and OCSP responses would not generally
      be tied to the

      two CA instances on different cert paths. But, that's not the
      point. It would be dangerous 

      to assume that an RP can be confident that the revocation status
      data it acquires comes

      from a specific instance of a CA, when there are two CAs with the
      same names and 

      same public keys. RFC 5280 does not provide implementation
      guidance that calls for

      pooling of revocation status info based on CA name. An RP may
      maintain a cache organized

      by cert path, associating revocation status info with each CA in
      each cert path. Such

      an implementation strategy is attractive because it can allow an
      RP to avoid redundant

      cert path validation processing when a target cert shares a
      portion of a cert path with

      other certs that have been validated. In such an implementation an
      RP would not be aware that

      there are two CAs with the same name on different cert paths, and
      revocation status data 

      associated with each of these CAs would be acquired and maintained
      separately. In such

      circumstances an attack of the sort I described is feasible.

      

      Thus I stand by my analysis of the vulnerability, in the more
      general case.

      

      Steve

    

  


--------------050602060600090606060007--


From nobody Thu Mar 24 08:27:57 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC64A12DD40 for ; Thu, 24 Mar 2016 08:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level: 
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aCbFBYtZeOz for ; Thu, 24 Mar 2016 08:27: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 26F0F12DDFE for ; Thu, 24 Mar 2016 08:11:25 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:51122 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aj6uy-0005Hu-0J for trans@ietf.org; Thu, 24 Mar 2016 11:11:24 -0400
From: Stephen Kent 
To: "trans@ietf.org" 
Message-ID: <56F4039B.2020604@bbn.com>
Date: Thu, 24 Mar 2016 11:11:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------080904040601050104060307"
Archived-At: 
Subject: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 15:27:55 -0000

This is a multi-part message in MIME format.
--------------080904040601050104060307
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

3.3 Malicious, Colluding CAs

Section 3.2 examined attacks in which a single CA issued a bogus 
certificate. There is also the potential that two or more CAs might 
collude to issue a bogus certificate in a fashion designed to foil the 
remediation safeguards envisioned by CT.

In general, any two CAs that are not name-constrained and do not share a 
common path to a trust anchor can collude to create a “doppelganger” EE 
certificate that is bogus. The attack need not be initiated by trust 
anchors; any subordinate pair of (not name-constrained) CAs can effect 
this attack without the knowledge of superiors CAs. (RFC 5280 doe not 
preclude the creation of two CAs with the same name, so long as the 
parent CAs are distinct. Requirements for Subject name uniqueness apply 
individually to each CA but not across CA boundaries. There also is no 
requirement for public key uniqueness across all CAs. However, the 
creation of doppelganger EE certificates by these CAs may be a violation 
of RFC 5280 (if one views the CAs that appear on different certification 
paths as one CA).

The attack requires that each of the colluding CAs issues a certificate 
for a targeted Subject (e.g., web site). These two (EE) certificates are 
identical, hence the use of the term “doppelganger”; they contain the 
same name, public key, serial number, etc. Only one of the malicious CAs 
logs the bogus certificate and acquires an SCT for it.

The logged bogus certificate can be detected by a Monitor (third party 
or self), that is observing the log(s) to which the certificate was 
posted. Thus the detection aspect of CT still works with regard to this 
(bogus) certificate. When this certificate is detected, the CA that 
logged the certificate might choose to revoke it, i.e., place it on a 
CRL or create an OCSP response for it. However, a browser checking a CRL 
or OCSP response may not match this revocationstatus data against the 
doppelganger certificate. This is because revocation status checking is 
performed in the context of a certificate path. The doppelganger 
certificates have different certificate paths and thus the revocation 
status data for each might be acquired and stored independently. (RFC 
5280 does not provide implementation guidance for management of 
revocation data.) Revoking a detected, bogus certificatemight be the 
best strategy for the malicious CA that logged the certificate; it makes 
issuance of the bogus certificate appear to be an accident, and thus a 
browser vendor might not feel the need to make an entry on its 
blacklists for the bogus certificate or for the CA that issued it. (If 
the bogus certificate included an AIA extension providing information 
for revocation status checking, revocation by the CA that logged the 
bogus certificate would not be an effective strategy for these colluding 
CAs. However, inclusion of this extension is not mandated by RFC 5280. 
Also the extension is not critical, meaning that relying parties are not 
required to be able to process it.)

If the CA that logged the bogus certificate fails to revoke it, browser 
vendors might blacklist the certificate. However, as noted above, the 
doppelganger, which was not logged, will match the SCT created for the 
logged certificate. If remediation is effected by blacklisting (instead 
of revocation by one of the malicious CAs) then the ability of CT to 
deal with this sort of attack may be diminished. Some forms of 
blacklisting will cause the not-logged bogus certificate to be detected 
and rejected, while others will not, depending on the details of the 
blacklisting mechanism. Mechanisms for blacklisting by browsers are not 
specified in any IETF standards. The mechanisms are browser-specific, 
and the choice of how to blacklist (e.g., the bogus certificate vs. the 
CA that issued it) are the purview of each browser vendor. Thus, 
depending on the details of the blacklist mechanism and the way that a 
browser vendor chooses to manage this list, a doppelganger CA attack 
might or might not pose a problem in terms of successful remediation of 
the attack.


--------------080904040601050104060307
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    
3.3
        Malicious, Colluding CAs

    
 

    
Section
        3.2 examined attacks in which a single CA issued a bogus
        certificate. There is also the potential that two or more CAs
        might collude to issue a bogus certificate in a fashion designed
        to foil the remediation safeguards envisioned by CT. 

    
 

    
In
        general, any two CAs that are not name-constrained and do not
        share a common path to a trust anchor can collude to create a
        “doppelganger” EE certificate that is bogus. The attack need not
        be initiated by trust anchors; any subordinate pair of (not
        name-constrained) CAs can effect this attack without the
        knowledge of superiors CAs. (RFC 5280 doe not preclude the
        creation of two CAs with the same name, so long as the parent
        CAs are distinct. Requirements for Subject name uniqueness apply
        individually to each CA but not across CA boundaries. There also
        is no requirement for public key uniqueness across all CAs.
        However, the creation of doppelganger EE certificates by these
        CAs may be a violation of RFC 5280 (if one views the CAs that
        appear on different certification paths as one CA).

    
 

    
The
        attack requires that each of the colluding CAs issues a
        certificate for a targeted Subject (e.g., web site). These two
        (EE) certificates are identical, hence the use of the term
        “doppelganger”; they contain the same name, public key, serial
        number, etc. Only one of the malicious CAs logs the bogus
        certificate and acquires an SCT for it.

    
 

    
The
        logged bogus certificate can be detected by a Monitor (third
        party or self), that is observing the log(s) to which the
        certificate was posted. Thus the detection aspect of CT still
        works with regard to this
        (bogus) certificate. When this certificate is detected, the CA
        that logged the certificate might choose to revoke it, i.e.,
        place it on a CRL or create an OCSP response for it. However, a
        browser checking a CRL or OCSP response may not match this
        revocation status data
        against the doppelganger certificate. This is because revocation
        status checking is performed in the context of a certificate
        path. The doppelganger certificates have different certificate
        paths and thus the revocation status data for each might be
        acquired and stored independently. (RFC 5280 does not provide
        implementation guidance for management of revocation data.)
        Revoking a detected, bogus certificate might be the best strategy
        for the malicious CA that logged the certificate; it makes
        issuance of the bogus certificate appear to be an accident, and
        thus a browser vendor might not feel the need to make an entry
        on its blacklists for the bogus certificate or
        for the CA that issued it. (If
        the bogus certificate included an AIA extension providing
        information for revocation status checking, revocation by the CA
        that logged the bogus certificate would not be an effective
        strategy for these colluding CAs. However, inclusion of this
        extension is not mandated by RFC 5280. Also the extension is not
        critical, meaning that relying parties are not required to be
        able to process it.)

    
 

    
 If the CA that logged the
                bogus certificate fails to revoke it, browser vendors
                might blacklist the certificate. However, as noted
                above, the doppelganger, which was not logged, will
                match the SCT created for the logged certificate. If
                remediation is effected by blacklisting (instead of
                revocation by one of the malicious CAs) then the ability
                of CT to deal with this sort of attack may be
                diminished. Some forms of blacklisting will cause the
                not-logged bogus certificate to be detected and
                rejected, while others will not, depending on the
                details of the blacklisting mechanism. Mechanisms for
                blacklisting by browsers are not specified in any IETF
                standards. The mechanisms are browser-specific, and the
                choice of how to blacklist (e.g., the bogus certificate
                vs. the CA that issued it) are the purview of each
                browser vendor. Thus, depending on the details of the
                blacklist mechanism and the way that a browser vendor
                chooses to manage this list, a doppelganger CA attack
                might or might not pose a problem in terms of successful
                remediation of the attack.
    

    
    
    
    
    
    
    
    
    
    
  


--------------080904040601050104060307--


From nobody Thu Mar 24 08:46:37 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F5D12D527 for ; Thu, 24 Mar 2016 08:46:35 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3IuslLNNw3w for ; Thu, 24 Mar 2016 08:46:33 -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 9F6FC12DBC4 for ; Thu, 24 Mar 2016 08:33:04 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:59716 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aj7Fv-0001BY-0a; Thu, 24 Mar 2016 11:33:03 -0400
From: Stephen Kent 
To: Eran Messeri 
References: <053.295250cc5a90d6e6c0794fe09149ea46@tools.ietf.org> <068.0779562256ffb55d064ab4f9e5d0a31c@tools.ietf.org> <56E99CFA.8010601@bbn.com>  <56EC1A0D.5030308@bbn.com> 
Message-ID: <56F408A9.3040704@bbn.com>
Date: Thu, 24 Mar 2016 11:32:57 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030906090003080301010408"
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] [trans] #118 (rfc6962-bis): Monitor function description problem
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 15:46:35 -0000

This is a multi-part message in MIME format.
--------------030906090003080301010408
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Eran,

Thanks for being willing to make changes to the Monitor description.

the next text is better, but, IMHO it still has problems. For example

    Monitors watch logs to check that they behave correctly, for
    certificates of interest, or both.  For example, a monitor may be
    configured to report on all certificates that apply to a specific
    domain name when fetching new entries for consistency validation.

    A monitor needs to, at least, inspect every new entry in each log it
    watches.

The first sentence is very confusing. I still think the primary job of a 
monitor
is to observe logs for cert "of interest" not to detect log misbehavior. 
The latter
function is the focus of auditing. Why make one (of 4) types of log 
misbehavior a
function for Monitors? Why not focus exclusively on log observation? The
characterization of monitoring in the introduction (page 4) says:

*   Those who are concerned about misissuance can monitor the logs,
    asking them regularly for all new entries, and can thus check whether
    domains they are responsible for have had certificates issued that
    they did not expect.*

Thus the changes I have requested are consistent with what the doc 
already says.

The "for example" sentence also isn't great from a standards 
perspective. First, it's
just an example, and "domain" isn't defined. Also it again focuses on 
consistentcy
validation for a log instead of protecting Subjects by detecting issuance of
bogus certs.

I cold go on, but I think you get the sense of my concerns.

Steve

--------------030906090003080301010408
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Eran,

    

    Thanks for being willing to make changes to the Monitor description.

    

    the next text is better, but, IMHO it still has problems. For
    example 

    

       Monitors watch logs to check that they behave correctly, for

       certificates of interest, or both.  For example, a monitor may be

       configured to report on all certificates that apply to a specific

       domain name when fetching new entries for consistency validation.

    

       A monitor needs to, at least, inspect every new entry in each log
    it

       watches. 

    

    The first sentence is very confusing. I still think the primary job
    of a monitor

    is to observe logs for cert "of interest" not to detect log
    misbehavior. The latter

    function is the focus of auditing. Why make one (of 4) types of log
    misbehavior a

    function for Monitors? Why not focus exclusively on log observation?
    The

    characterization of monitoring in the introduction (page 4) says:

    

       Those who are concerned about misissuance can monitor the
      logs,

         asking them regularly for all new entries, and can thus check
      whether

         domains they are responsible for have had certificates issued
      that

         they did not expect.

    

    Thus the changes I have requested are consistent with what the doc
    already says.

    

    The "for example" sentence also isn't great from a standards
    perspective. First, it's

    just an example, and "domain" isn't defined. Also it again focuses
    on consistentcy

    validation for a log instead of protecting Subjects by detecting
    issuance of

    bogus certs.

    

    I cold go on, but I think you get the sense of my concerns.

    

      
      
      
      
      
      
      
      
      
      
       

    

    Steve

  


--------------030906090003080301010408--


From nobody Thu Mar 24 09:07:04 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836EF12DC8F for ; Thu, 24 Mar 2016 09:07:03 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrbfsdF6ow-X for ; Thu, 24 Mar 2016 09:06:57 -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 8BB8312DD1C for ; Thu, 24 Mar 2016 08:55:13 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:51476 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aj7bM-0005mZ-4U for trans@ietf.org; Thu, 24 Mar 2016 11:55:12 -0400
To: "trans@ietf.org" 
From: Stephen Kent 
Message-ID: <56F40DDF.2050900@bbn.com>
Date: Thu, 24 Mar 2016 11:55:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------090404000509030405070304"
Archived-At: 
Subject: [Trans] proposed text to address Bryan's concerns
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 16:07:03 -0000

This is a multi-part message in MIME format.
--------------090404000509030405070304
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The following text is intended to address the concerns raised by Bryan, 
about
compromise of a CA or log.  The threat analysis already mentioned the 
possibility
of a CA or log being compromised or coerced (Section 2) but this text 
goes examines
attacks based on such compromises, especially undetected compromises, in 
more depth.

Steve
------

3.4 Undetected Compromise of CAs or Logs

Sections 3.1 and 3.2 examined attacks in the context of non-malicious 
and malicious CAs and benign and misbehaving logs. Another class of 
attacks might occur in the context of a non-malicious CA and/or a benign 
log. Specifically these CT elements might be compromised and the 
compromise might go undetected. Compromise of CAs and logs was noted in 
Section 2, as was coercion of a CA. As noted there, a compromised CA is 
essentially a malicious CA, and thus the discussions in Section 3.2 are 
applicable. The case of an undetected compromise warrants some 
additional discussion, as some relying parties may see signed objects 
only with the legitimate (non-malicious) CA, others may see signed 
objects from it’s compromised counterpart, and some may see objects from 
both.

In the case of a compromised CA or log the adversary is presumed to have 
access to the private key used by a CA to sign certificates, or used by 
a log to sign SCTs and STHs. Because the compromise is undetected, there 
will be no effort by a CA to have it’s certificate revoked or by a log 
to shut down the log.

In the case of a compromised, non-malicious CA an attacker uses the 
purloined private key to generate a bogus certificate (that the 
compromised CA would not issue). If this certificate is submitted to a 
legitimate log, then it subject to detection by a Monitor, as discussed 
in 3.1.1.1. If the bogus certificate is submitted to a misbehaving log, 
then an SCT can be generated, but there will be no entry for it, as 
discussed in 3.1.1.2. If the bogus certificate is not logged, then there 
will be no SCT, and the implications are as described in 3.1.2.

This sort of attack may be most effective if the CA that is the victim 
of the attack has issueda certificate for the targeted Subject. In this 
case the bogus certificate will then have the same certificate path as 
the legitimate certificate, which may help hide the bogus certificate. 
However, means of remedying the attack are independent of this aspect, 
i.e., revocation canbe effected irrespective of whether the targeted 
Subject received its certificate from the compromised CA.

A compromised, non-malicious CA may be able to revoke the bogus 
certificate if it is detected by a Monitor. It can do so only when the 
serial number of the bogus certificate is made known to this CA, and if 
the bogus certificate was not issued with an Authority Information 
Access (AIA) extension that enables only the malicious twin to revoke 
the certificate. (The AIA extension could be used to direct relying 
parties to a CRL or OCSP server controlled by the malicious twin. If the 
bogus certificate contains such an extension, the compromised CA cannot 
revoke it, but it will also be apparent that the bogus certificate was 
issued by the malicious twin; the AIA extension would provide a strong 
indication that the bogus certificate was not generated by the 
compromised CA itself.)

If the serial number of the bogus certificate is the same as for a 
valid, not-expired certificate issued by the CA (to the target or to 
another Subject), then revocationposes a problem. This is because 
revocation of the bogus certificate will also invalidate a legitimate 
certificate. This problem may cause the compromised CA to delay 
revocation, thus allowing the bogus certificate to remain a danger for a 
longer time.

The compromised CA may not realize that the bogus certificate was issued 
by a malicious twin; one occurrence of this sort might be regarded as an 
error, and not cause the CA to transition to a new key pair. (This 
assumes that the bogus certificate does not contain an AIA extension 
that wrests control of revocation from the compromised CA.) If the 
compromised CA does determine that its private key has been stolen, it 
may take some time to transition to a new key pair, and reissue 
certificates to all of its legitimate Subjects. Thus an attack of this 
sort may take a while to be remedied.

Also note that the malicious twin of the compromised CA may be capable 
of issuing its own CRL or OCSP responses, without changing any AIA data 
present in the targeted certificate. This revocation status data items 
will appear as valid as those of the compromised CA. If the attacker has 
the ability to control the sources of revocation status data available 
to a targeted user, then the user may not become aware of the attack.

A bogus certificate issued by the malicious CA will not match the SCT 
for the legitimate certificate, since they are not identical, e.g., at a 
minimum the private keys do not match.Thus a CT-enabled browser that 
rejects certificates without SCTs (Section 3.1.2.2) will reject a bogus 
certificate created under these circumstances if it is not logged. If 
the certificate has been logged by a compromised or malicious log, then 
an SCT will be available, but there will be no log entry (Section 
3.2.1.2). The lack of a log entry prevents detection by Monitors, and 
the presence of the SCT prevents rejection by a CT-aware browser that 
accepts SCTs from the malicious or compromised log.

In the case of a compromised, non-malicious log an attacker uses the 
purloined private key to generate SCTs for certificates that have not 
been logged by its legitimate counterpart. These SCTs will appear valid 
relative to the public key associated with the legitimate log. However, 
the STH issued by the legitimate log will not contain these SCTs. Thus 
more thorough checking of the SCTs issued by the evil twin log will note 
the discrepancy. An Auditor performing such a check might conclude that 
the log is acting maliciously, and is presenting a split view to its 
clients. In this fashion the compromised log may be shunned and forced 
to shot down. However, if an attacker targets a set of TLS clients that 
do not have access to the legitimate log, they may not be able to detect 
this inconsistency. In this case CT would need to rely on a distributed 
gossiping audit mechanism to detect the compromise (see Section 5.6).



--------------090404000509030405070304
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    The following text is intended to address the concerns raised by
    Bryan, about

    compromise of a CA or log.  The threat analysis already mentioned
    the possibility 

    of a CA or log being compromised or coerced (Section 2) but this
    text goes examines

    attacks based on such compromises, especially undetected
    compromises, in more depth.

    

    Steve

    ------

    

    
    
3.4 Undetected
        Compromise of CAs or Logs

    
 

    
Sections
        3.1 and 3.2 examined attacks in the context of non-malicious and
        malicious CAs
        and benign and misbehaving logs. Another class of attacks might
        occur in the
        context of a non-malicious CA and/or a benign log. Specifically
        these CT
        elements might be compromised and the compromise might go
        undetected. Compromise
        of CAs and logs was noted in Section 2, as was coercion of a CA.
        As noted
        there, a compromised CA is essentially a malicious CA, and thus
        the discussions
        in Section 3.2 are applicable. The case of an undetected
        compromise warrants
        some additional discussion, as some relying parties may see
        signed objects only
        with the legitimate (non-malicious) CA, others may see signed
        objects from it’s
        compromised counterpart, and some may see objects from both.

    
 

    
In the
        case of a compromised CA or log the adversary is presumed to
        have access to the
        private key used by a CA to sign certificates, or used by a log
        to sign SCTs
        and STHs. Because the compromise is undetected, there will be no
        effort by a CA
        to have it’s certificate revoked or by a log to shut down the
        log.

    
 

    
In the
        case of a compromised, non-malicious CA an attacker uses the
        purloined private
        key to generate a bogus certificate (that the compromised CA
        would not issue).
        If this certificate is submitted to a legitimate log, then it
        subject to
        detection by a Monitor, as discussed in 3.1.1.1. If the bogus
        certificate is
        submitted to a misbehaving log, then an SCT can be generated,
        but there will be
        no entry for it, as discussed in 3.1.1.2. If the bogus
        certificate is not
        logged, then there will be no SCT, and the implications are as
        described in
        3.1.2.  

    
 

    
This sort
        of attack may be most effective if the CA that is the victim of
        the attack has
        issued  a certificate for
        the targeted
        Subject. In this case the bogus certificate will then have the
        same certificate
        path as the legitimate certificate, which may help hide the
        bogus certificate. However,
        means of remedying the attack are independent of this aspect,
        i.e., revocation
        can  be effected
        irrespective of whether
        the targeted Subject received its certificate from the
        compromised CA. 

    
 

    
A compromised,
        non-malicious CA may be able to revoke the bogus certificate if
        it is detected by
        a Monitor. It can do so only when the serial number of the bogus
        certificate is
        made known to this CA, and if the bogus certificate was not
        issued with an
        Authority Information Access (AIA) extension that enables only
        the malicious
        twin to revoke the certificate. (The AIA extension could be used
        to direct
        relying parties to a CRL or OCSP server controlled by the
        malicious twin. If
        the bogus certificate contains such an extension, the
        compromised CA cannot
        revoke it, but it will also be apparent that the bogus
        certificate was issued
        by the malicious twin; the AIA extension would provide a strong
        indication that
        the bogus certificate was not generated by the compromised CA
        itself.)

    
 

    
If the
        serial number of the bogus certificate is the same as for a
        valid, not-expired
        certificate issued by the CA (to the target or to another
        Subject), then
        revocation  poses a
        problem. This is
        because revocation of the bogus certificate will also invalidate
        a legitimate
        certificate. This problem may cause the compromised CA to delay
        revocation,
        thus allowing the bogus certificate to remain a danger for a
        longer time. 

    
 

    
The
        compromised CA may not realize that the bogus certificate was
        issued by a
        malicious twin; one occurrence of this sort might be regarded as
        an error, and
        not cause the CA to transition to a new key pair. (This assumes
        that the bogus
        certificate does not contain an AIA extension that wrests
        control of revocation
        from the compromised CA.)  If
        the
        compromised CA does determine that its private key has been
        stolen, it may take
        some time to transition to a new key pair, and reissue
        certificates to all of
        its legitimate Subjects. Thus an attack of this sort may take a
        while to be
        remedied.

    
 

    
Also note
        that the malicious twin of the compromised CA may be capable of
        issuing its own
        CRL or OCSP responses, without changing any AIA data present in
        the targeted
        certificate. This revocation status data items will appear as
        valid as those of
        the compromised CA. If the attacker has the ability to control
        the sources of
        revocation status data available to a targeted user, then the
        user may not
        become aware of the attack.

    
 

    
A bogus
        certificate issued by the malicious CA will not match the SCT
        for the
        legitimate certificate, since they are not identical, e.g., at a
        minimum the
        private keys do not match.  Thus
        a
        CT-enabled browser that rejects certificates without SCTs
        (Section 3.1.2.2) will
        reject a bogus certificate created under these circumstances if
        it is not
        logged. If the certificate has been logged by a compromised or
        malicious log,
        then an SCT will be available, but there will be no log entry
        (Section
        3.2.1.2). The lack of a log entry prevents detection by
        Monitors, and the
        presence of the SCT prevents rejection by a CT-aware browser
        that accepts SCTs
        from the malicious or compromised log.

    
 

    
In the
        case of a compromised, non-malicious log an attacker uses the
        purloined private
        key to generate SCTs for certificates that have not been logged
        by its
        legitimate counterpart. These SCTs will appear valid relative to
        the public key
        associated with the legitimate log. However, the STH issued by
        the legitimate
        log will not contain these SCTs. Thus more thorough checking of
        the SCTs issued
        by the evil twin log will note the discrepancy. An Auditor
        performing such a
        check might conclude that the log is acting maliciously, and is
        presenting a
        split view to its clients. In this fashion the compromised log
        may be shunned
        and forced to shot down. However, if an attacker targets a set
        of TLS clients
        that do not have access to the legitimate log, they may not be
        able to detect
        this inconsistency. In this case CT would need to rely on a
        distributed gossiping
        audit mechanism to detect the compromise (see Section 5.6).

    
    
    
    
    
    
    
    
    
    

  


--------------090404000509030405070304--


From nobody Thu Mar 24 09:12:51 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738212D530 for ; Thu, 24 Mar 2016 09:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71sWVplCoB3X for ; Thu, 24 Mar 2016 09:12:47 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06E712D5D6 for ; Thu, 24 Mar 2016 09:02:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qWB5t6KlQz3TW; Thu, 24 Mar 2016 17:02:26 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id zKVCWK6OAaAK; Thu, 24 Mar 2016 17:02:26 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 24 Mar 2016 17:02:25 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1DDF0600BAE7; Thu, 24 Mar 2016 12:02:25 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 1DDF0600BAE7
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1C6A518D60; Thu, 24 Mar 2016 12:02:25 -0400 (EDT)
Date: Thu, 24 Mar 2016 12:02:25 -0400 (EDT)
From: Paul Wouters 
To: Stephen Kent 
In-Reply-To: <56F4039B.2020604@bbn.com>
Message-ID: 
References: <56F4039B.2020604@bbn.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 16:12:49 -0000

On Thu, 24 Mar 2016, Stephen Kent wrote:

> The attack requires that each of the colluding CAs issues a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are
> identical, hence the use of the term “doppelganger”; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs
> the bogus certificate and acquires an SCT for it.

I don't fully understand your description of the attack.

If the certificates are doppelgangers, wouldn't that mean that they
cannot have AIA's ? Otherwise at least one CA would be using an "unusual"
AIA revocation location that monitors would detect.

> The logged bogus certificate can be detected by a Monitor (third party or self), that is observing the log(s) to which the certificate was posted.
> Thus the detection aspect of CT still works with regard to this (bogus) certificate. When this certificate is detected, the CA that logged the
> certificate might choose to revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response
> may not match this revocation status data against the doppelganger certificate.

So either the EE-certificates have different AIA's and are not doppelgangers,
or they would have the same AIA's and a browser would always find the
matching CRL/OCSP responses? Or the EE-certs cannot contain AIA
revocation information (which in itself should be unusual enough for
monitors to pick up)

My understanding is that a lot of code (eg NSS) ignores AIA revocation
information specified on the Root CA's, but do check them on the
intermediate CA's and EE-certs, so I guess the attack can work if the
EE-cert has no AIA but the intermediate CA's do? But I guess it would
also be odd for an intermediate CA with AIA revocation on it, to issue
EE-certifications with no AIA revocation information in it?

Paul


From nobody Thu Mar 24 14:34:29 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6A12D79C for ; Thu, 24 Mar 2016 14:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydju0dvDMGAs for ; Thu, 24 Mar 2016 14:34: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 6953B12D703 for ; Thu, 24 Mar 2016 14:34:27 -0700 (PDT)
Received: from localhost ([::1]:33108 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ajCtd-0003LN-4G; Thu, 24 Mar 2016 14:34: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: rob.stradling@comodo.com, benl@google.com
X-Trac-Project: trans
Date: Thu, 24 Mar 2016 21:34:25 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/154#comment:3
Message-ID: <080.a6841853f7c4bd5098093a30f532f85e@tools.ietf.org>
References: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org>
X-Trac-Ticket-ID: 154
In-Reply-To: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #154 (rfc6962-bis): CSR extension to convey a certificate subscriber's CT preferences to the CA
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 21:34:29 -0000

#154: CSR extension to convey a certificate subscriber's CT preferences to the CA


Comment (by rob.stradling@comodo.com):

 Certificate subscribers will also need to be able to communicate name
 redaction requirements to CAs.  One way to do that would be to require the
 CSR to have:
   - all of the required domain name(s) in a SAN extension.
   - a corresponding "redacted labels" extension (OID 1.3.101.77, with
 syntax as defined by 6962-bis).

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling@comodo.com           |  rob.stradling@comodo.com
     Type:  enhancement              |      Status:  new
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Thu Mar 24 14:52:52 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533D312D871 for ; Thu, 24 Mar 2016 14:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3OSeTmBT5d0 for ; Thu, 24 Mar 2016 14:52: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 B5E5412D830 for ; Thu, 24 Mar 2016 14:52:49 -0700 (PDT)
Received: from localhost ([::1]:34034 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ajDBP-0006dR-Hj; Thu, 24 Mar 2016 14:52: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: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Thu, 24 Mar 2016 21:52:47 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/154#comment:4
Message-ID: <080.bc294f3138242db6496f418e91a787f4@tools.ietf.org>
References: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org>
X-Trac-Ticket-ID: 154
In-Reply-To: <065.c4b15e6c4f869845c93207c4640d700b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, 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] #154 (to-be-decided): CSR extension to convey a certificate subscriber's CT preferences to the CA
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 21:52:51 -0000

#154: CSR extension to convey a certificate subscriber's CT preferences to the CA

Changes (by melinda.shore@gmail.com):

 * component:  rfc6962-bis => to-be-decided


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling@comodo.com           |  rob.stradling@comodo.com
     Type:  enhancement              |      Status:  new
 Priority:  major                    |   Milestone:
Component:  to-be-decided            |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Thu Mar 24 15:47:22 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2169D12D94C for ; Thu, 24 Mar 2016 15:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVHQ1u-o-lc6 for ; Thu, 24 Mar 2016 15:47: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 9AA2212D937 for ; Thu, 24 Mar 2016 15:47:20 -0700 (PDT)
Received: from localhost ([::1]:36586 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ajE28-0000lT-I6; Thu, 24 Mar 2016 15:47:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "trans issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: rob.stradling@comodo.com, benl@google.com, eranm@google.com, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Thu, 24 Mar 2016 22:47:16 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/111#comment:4
Message-ID: <080.5e42b543c6687a0aa23f991e1fa3cd7c@tools.ietf.org>
References: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org>
X-Trac-Ticket-ID: 111
In-Reply-To: <065.0226a5b84d88bdfc7c9b20fa02c5a3aa@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, eranm@google.com, melinda.shore@gmail.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #111 (to-be-decided): Consider using the cached-info TLS extension
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 22:47:22 -0000

#111: Consider using the cached-info TLS extension

Changes (by melinda.shore@gmail.com):

 * component:  rfc6962-bis => to-be-decided


-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  rob.stradling@comodo.com           |  rob.stradling@comodo.com
     Type:  enhancement              |      Status:  new
 Priority:  minor                    |   Milestone:
Component:  to-be-decided            |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
trans 


From nobody Thu Mar 24 17:41:49 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2910312D1B4 for ; Thu, 24 Mar 2016 17:41:49 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_4YEz-g-Zig for ; Thu, 24 Mar 2016 17:41:47 -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 A9D2212D0DD for ; Thu, 24 Mar 2016 17:41:47 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:38301 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ajFow-000CTn-7E for trans@ietf.org; Thu, 24 Mar 2016 20:41:46 -0400
To: trans@ietf.org
References:  
From: Stephen Kent 
Message-ID: <56F48949.2080403@bbn.com>
Date: Thu, 24 Mar 2016 20:41:45 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Trans] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd)
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Mar 2016 00:41:49 -0000

I concur with Paul's conclusion.

Will push out a new version as soon as the system allows.

Steve


From nobody Fri Mar 25 07:44:55 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6597112DAF8 for ; Fri, 25 Mar 2016 07:44:54 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzQIcKnK9n1y for ; Fri, 25 Mar 2016 07:44:52 -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 7726312DAF7 for ; Fri, 25 Mar 2016 07:44:52 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:33170 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ajSyo-000EmA-Hs; Fri, 25 Mar 2016 10:44:50 -0400
From: Stephen Kent 
To: Paul Wouters 
References: <56F4039B.2020604@bbn.com> 
Message-ID: <56F54EE2.1000008@bbn.com>
Date: Fri, 25 Mar 2016 10:44:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
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] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Mar 2016 14:44:54 -0000

Paul,

> ...
>
> If the certificates are doppelgangers, wouldn't that mean that they
> cannot have AIA's ? Otherwise at least one CA would be using an "unusual"
> AIA revocation location that monitors would detect.
The doppelgangers could have AIAs, but they need not, and that is the 
assumption
I adopted here. In general it is in the interest of the CAs to not put 
AIAs in these certs,
if the plan is to revoke one, but not the other.  (Unless the CAs can 
control which
revocation status info is accessible to targeted browser users, in which 
case it doesn't
matter.)
>
>> The logged bogus certificate can be detected by a Monitor (third 
>> party or self), that is observing the log(s) to which the certificate 
>> was posted.
>> Thus the detection aspect of CT still works with regard to this 
>> (bogus) certificate. When this certificate is detected, the CA that 
>> logged the
>> certificate might choose to revoke it, i.e., place it on a CRL or 
>> create an OCSP response for it. However, a browser checking a CRL or 
>> OCSP response
>> may not match this revocation status data against the doppelganger 
>> certificate.
>
> So either the EE-certificates have different AIA's and are not 
> doppelgangers,
> or they would have the same AIA's and a browser would always find the
> matching CRL/OCSP responses? 
There is no requirement that certs contain an AIA extension. It also is 
not mandated by
5280, nor is it required for EE certs that meet the CABF DV or EV profiles.
> Or the EE-certs cannot contain AIA
> revocation information (which in itself should be unusual enough for
> monitors to pick up)

Because there is no requirement in 5280 (or in DV/EV profiles) that any 
cert to contain an AIA
extension, that is hardly a reason for a Monitor to flag these cert. CA 
certs
MUST contain a CRL DP extension if they conform to the DV or EV 
profiles. But, it appears
that most browsers do not fetch CRLs, so this mandate for DV/EV certs is 
probably moot.
The proposal that I put forth over a year ago would allow a CA to assert 
that it was
issuing a cert that conformed to DV or EV profiles. If that extension to 
the cert submission
data and SCT were adopted, then it would make sense for a Monitor to 
flag a CA cert
that lacked a CRL DP extension, and which claimed to be issued under 
these profiles.
But, that proposal went nowhere, so ...

A Monitor should notify a Subject if the Monitor detects a logged cert 
that does not
have the same public key as a registered by the Subject with the same DN 
or AltName
(as described in draft-kent-trans-monitor-auditor-00.txt, but not 
mentioned in 6962-bis).
> My understanding is that a lot of code (eg NSS) ignores AIA revocation
> information specified on the Root CA's, but do check them on the
> intermediate CA's and EE-certs, so I guess the attack can work if the
> EE-cert has no AIA but the intermediate CA's do? But I guess it would
> also be odd for an intermediate CA with AIA revocation on it, to issue
> EE-certifications with no AIA revocation information in it?
As I noted above, there is no requirement (in 5280 or in CABF profiles) 
that a cert
contain an AIA extension. Also, the colluding CA certs can contain AIA 
extensions,
but those point to revocation data issued by their parents. If the 
colluding CA certs
contained CRL DP data it could be different for each. Tthere is no 
requirement that those
certs be identical; they need only share the same Subject name for the 
attack to work.
In fact using two different CRLs for these two colluding CAs might even 
help, as it would
naturally direct RPs to different sources for revocation  status info. 
Thus the CA that
revoked the bogus cert would have a different CRL from its partner, and 
an RP would
associate the tow different CRLs with the two CAs (on different paths), 
thus supporting
the attack.

Steve


From nobody Fri Mar 25 07:56:21 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D6612D666 for ; Fri, 25 Mar 2016 07:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTHB1Brp6CyE for ; Fri, 25 Mar 2016 07:56:16 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A3E12DAFF for ; Fri, 25 Mar 2016 07:56:15 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qWmb13xcmz4Kc; Fri, 25 Mar 2016 15:56:13 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tszX4f6t7-ur; Fri, 25 Mar 2016 15:56:12 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 25 Mar 2016 15:56:12 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3B9106003151; Fri, 25 Mar 2016 10:56:10 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3B9106003151
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 36D5518D6D; Fri, 25 Mar 2016 10:56:10 -0400 (EDT)
Date: Fri, 25 Mar 2016 10:56:10 -0400 (EDT)
From: Paul Wouters 
To: Stephen Kent 
In-Reply-To: <56F54EE2.1000008@bbn.com>
Message-ID: 
References: <56F4039B.2020604@bbn.com>  <56F54EE2.1000008@bbn.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Mar 2016 14:56:17 -0000

On Fri, 25 Mar 2016, Stephen Kent wrote:

>>  If the certificates are doppelgangers, wouldn't that mean that they
>>  cannot have AIA's ? Otherwise at least one CA would be using an "unusual"
>>  AIA revocation location that monitors would detect.
> The doppelgangers could have AIAs, but they need not, and that is the 
> assumption  I adopted here. In general it is in the interest of the CAs to not put AIAs 
> in these certs,
> if the plan is to revoke one, but not the other.  (Unless the CAs can control 
> which
> revocation status info is accessible to targeted browser users, in which case 
> it doesn't
> matter.)

I would hope that the CT ecosystem would see that if a CA always issues
with AIA in the EE-cert, and then it issues a cert where it does not,
that it would get flagged for a human to look at. Part of CT is keeping
an eye out on the CAs, and this clearly shows some unexpected behaviour
on one or two particular CA's for not including AIA's. It might not be
syntactically bogus, but hopefully something the clients and monitors
would keep an eye out for.

So it seems to me this attack is not very likely to succeed - or at
least would be a short-lived one with a guarantee of being detected.
So it comes with a big enigma problem.

Paul


From nobody Fri Mar 25 10:42:36 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7B12D0DC for ; Fri, 25 Mar 2016 10:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level: 
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9JrcLIebygF for ; Fri, 25 Mar 2016 10:42:31 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8E712D1E2 for ; Fri, 25 Mar 2016 10:42:30 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 25 Mar 2016 13:42:17 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Fri, 25 Mar 2016 13:42:26 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2PHgHiP016549;	Fri, 25 Mar 2016 13:42:17 -0400
To: Stephen Kent , 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com>
From: "David A. Cooper" 
Message-ID: <56F57879.5060005@nist.gov>
Date: Fri, 25 Mar 2016 13:42:17 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56F4032F.9030800@bbn.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner-Information: 
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Mar 2016 17:42:34 -0000


  
    
  
  
    
On 03/24/2016 11:09 AM, Stephen Kent
      wrote:

    

    

      
      David,

      

      No text in 5280 requires name uniqueness across all CAs.

    

    Untrue, as I'll demonstrate below.

    

    
It does
      require uniqueness

      on a per-CA basis (Section 4.1.2.6 of 5280). So, when two CAs with
      different parents

      are created with the same name, that is not a violation of 5280.
      The creation of

      the doppelganger EE certs may violate 5280. The relevant text
      says:

      

       The DN MUST be unique for each subject entity certified by the


        one CA as defined 

       by the issuer field.

    

    

    That is only one relevant statement in RFC 5280. There are many
    others, and there are also relevant statements in other PKIX
    documents. There is also plenty of text in X.509 indicating that
    names need to be unambiguous across CAs, and the PKIX charter called
    for maintaining compatibility with X.509:

    
PKIX will continue to track the
        evolution of ITU-T X.509 documents, and will maintain
        compatibility between these documents and IETF PKI standards,
        since the profiling of X.509 standards for use in the Internet
        remains an important topic for the working group.

    

    

    Within the RFC 5280 Security Considerations section (as updated by
    RFC 6818), there are at least two paragraphs that address this:

    
While X.509 mandates that names be
        unambiguous, there is a risk that two unrelated authorities will
        issue certificates and/or CRLs under the same issuer name. As a
        means of reducing problems and security issues related to issuer
        name collisions, CA and CRL issuer names SHOULD be formed in a
        way that reduces the likelihood of name collisions.
        Implementers should take into account the possible existence of
        multiple unrelated CAs and CRL issuers with the same name. At a
        minimum, implementations validating CRLs MUST ensure that the
        certification path of a certificate and the CRL issuer
        certification path used to validate the certificate terminate at
        the same trust anchor.

    

    Why would RFC 5280 describe risks related to two unrelated
    authorities issuing certificates under the same name if it is
    permitted for two unrelated authorities to issue certificates under
    the same name? Are you really suggesting that the document
    simultaneously indicates that it is acceptable for two unrelated
    authorities issuing certificates under the same name (your claim),
    while also stating that CAs SHOULD NOT do this and warning that
    there are risks if they do?

    
If an attacker obtains the private
        key of a CA unnoticed, the attacker may issue bogus certificates
        and CRLs. Even if an attacker is unable to obtain a copy of a
        CA's private key, the attacker may be able to issue bogus
        certificates and CRLs by making unauthorized use of the CA's
        workstation or of an RA's workstation. Such an attack may be
        the result of an attacker obtaining unauthorized access to the
        workstation, either locally or remotely, or may be the result of
        inappropriate activity by an insider. Existence of bogus
        certificates and CRLs will undermine confidence in the system.Among many other possible
          attacks, the attacker may issue bogus certificates that have
          the same subject names as legitimate certificates in order
          impersonate legitimate certificate subjects. This could
          include bogus CA certificates in which the subject names in
          the bogus certificates match the names under which legitimate
          CAs issue certificates and CRLs. This would allow the attacker
          to issue bogus certificates and CRLs that have the same issuer
          names, and possibly the same serial numbers, as certificates
          and CRLs issued by legitimate CAs.

    

    

    Again, why would the RFC permit something so risky? Why would a
    document with such a security flaw be allowed to progress to RFC
    status? Perhaps the answer is that (as I've repeatedly pointed) out,
    neither RFC 5280 nor the X.509 standard that it profiles permits two
    different CAs to issue certificates with the same subject names to
    two different entities, and the Security Considerations section of
    RFC 5280 is pointing out that there is a risk that this could happen
    even though the standard doesn't permit it, and pointing out some of
    the problems that could occur if it did.

    

    Looking at the Section 6.3 of RFC 5280 (CRL Validation) also makes
    the requirement clear. When deciding whether a CRL (that could have
    been obtained from anywhere) may be used to determine the status of
    a certificate, RFC 5280 says:

    
(f) Obtain and validate the
          certification path for the issuer of

           the complete CRL. The trust anchor for the certification

           path MUST be the same as the trust anchor used to
          validate

           the target certificate. If a key usage extension is
          present

           in the CRL issuer's certificate, verify that the cRLSign
          bit

           is set.

    

    RFC 5280 explicitly allows the certification path for the CRL to be
    different from the certification path for the certificate whose
    status is being checked, as long as both certification paths start
    with the same trust anchor (a requirement imposed by RFC 5280, but
    not X.509). So, using the figure below as an example, RFC 5280
    states that the CRL shown on the left could be used to determine the
    status of the EE certificate on the right (assuming the CRL does not
    include an optional issuingDistributionPoint extension). [Feel free
    to read all of RFC 5280 Section 6.3 to verify this.]

    

    According to you, however, RFC 5280 permits the subject of the
    certificate from subordinate CA 1 and the subject of the certificate
    from subordinate CA 2 to be unrelated entities. If that were true,
    why would it allow a CRL issued by one entity to be used to
    determine the status of a certificate issued by an unrelated entity?
    It doesn't, because RFC 5280 doesn't permit unrelated CAs to issue
    certificates and/or CRLs under the same name. If it did, then it
    would need to impose a much stricter requirement for validating CRLs
    than that the certification path MUST have the same trust anchor. It
    would need to require something closer to MUST be the same
    certification path.

    

    Along the lines of the text in the Security Considerations section,
    the text in Section 6.3 requires that the paths start with the same
    trust anchor in order to protect against the risk that two
    unrelated CAs issue certificates and CRLs under the same name, but
    it assumes that there will not be two unrelated CAs issuing under
    the same name that are part of the same PKI (i.e., are under the
    same trust anchor). Are you really suggesting that RFC 5280 permits
    something, but then assumes it won't happen, and then warns that
    there are risks if it does happen?

    

          +--------------+

           | trust anchor |

           +--------------+

           / \

           / \

          +------------------+ +------------------+

          | subordinate CA 1 | | subordinate CA 2 |

          +------------------+ +------------------+

           | |

           | |

          +-------------------------------------+

          |+--------------+ +--------------+|

          || issuing CA A | | issuing CA A ||

          |+--------------+ +--------------+|

          +-------------------------------------+

           | |

           | | EE certificate

           | |

           +-----+ +------------+

           | CRL | | end entity |

           +-----+ +------------+

    

    

    As I noted before, RFC 5280 isn't the only document that includes
    text related to this requirement. RFC 5755 (Attribute Certificate
    Profile) is another example. RFC 5755 indicates that there are three
    ways to specify the Holder of an attribute certificate (the Holder
    of an attribute certificate is the equivalent of the Subject of a
    public-key certificate), and then it says:

    
For any environment where the AC
        is passed in an authenticated message or session and where the
        authentication is based on the use of an X.509 PKC, the Holder
        field SHOULD use the baseCertificateID.

      

    where baseCertificateID is defined as
    IssuerSerial, and IssuerSerial is defined as:

    
IssuerSerial ::= SEQUENCE {

         issuer GeneralNames,

         serial CertificateSerialNumber,

         issuerUID UniqueIdentifier OPTIONAL

        }

    

    [The issuerUID field would almost always be absent, since public-key
    certificates almost never include this field.]

    

    So, RFC 5755 encourages identifying the Holder of an AC by the
    issuer name and serial number of the Holder's public-key
    certificate, and yet it says the following the Security
    Considerations section:

    
If an attribute certificate is
        tied to the holder's PKC using the baseCertificateID component
        of the Holder field and the PKI in use includes a rogue CA with
        the same issuer name specified in the baseCertificateID
        component,this rogue CA
          could issue a PKC to a malicious party, using the same issuer
          name and serial number as the proper holder's PKC.Then the malicious party could
          use this PKC in conjunction with the AC.This scenario SHOULD be avoided
          by properly managing and configuring the PKI so that there
          cannot be two CAs with the same name. Another
        alternative is to tie ACs to PKCs using the publicKeyCert type
        in the ObjectDigestInfo field. Failing this, AC verifiers have
        to establish (using other means) that the potential collisions
        cannot actually occur, for example, the Certificate Practice
        Statements (CPSs) of the CAs involved may make it clear that no
        such name collisions can occur.

    

    If the PKIX profile for public-key certificates (RFC 5280) really
    allowed unrelated CAs to issue certificates under the same name, why
    would the PKIX AC profile say that issuers of ACs SHOULD use the
    baseCertificateID choice to identity a Holder in some cases and then
    warn that using that choice could allow one entity to use (claim
    "ownership") of another entity's AC if two unrelated CAs issue
    certificates under the same name and happen to issue certificates
    with the same serial number (a likely possibility since some CAs
    issue certificates with sequential serial numbers)? That would seem
    like a fatal flaw in th profile.

    

    If the PKIX profile for public-key certificates (RFC 5280) really
    allowed unrelated CAs to issue certificates under the same name, why
    would the text above refer to one of the CAs issuing under this name
    as a "rogue CA"? Why limit this text to a "rogue CA" if the same
    circumstance could occur by accident with two legitimate CAs that
    just happen to issue certificates under the same name?

    

    If the PKIX profile for public-key certificates (RFC 5280) really
    allowed unrelated CAs to issue certificates under the same name, why
    would the text above suggest "properly managing and configuring the
    PKI so that there cannot be two CAs with the same name." Doesn't
    that imply that a PKI with two CAs issuing under the same name isn't
    "properly managed"? Why would it suggest that if, as you claim,
    there is nothing improper about two unrelated CAs issuing
    certificates under the same name, as long the two unrelated CAs are
    not both issued cross-certificates by the same CA?

    

    The answer to all of the above is quite clear. PKIX does not permit
    two unrelated CAs to issue certificates under the same name. That
    is, it does require names to be unambiguous across CAs.

    

    
 The two
      CAs in my scenario have different parents, but the same name and
      same public key. So

      whether they are "the one CA" named in the issuer field is open to
      debate. I have modified 

      my text to avoid this issue.

    

    

    Aside from the gratuitous parenthetical in your text falsely stating
    that RFC 5280 "doe not preclude the creation of two CAs with the
    same name, so long as the parent CAs are distinct," you still write
    about two CAs issuing two EE certificates that are identical. If it
    walks like a duck and it quacks like a duck, then chances are its a
    duck. In the scenario you are trying to describe, there is one CA
    that issues one EE certificate. If you stopped trying to pretend
    otherwise, that would be a great starting point in improving the
    rest of the text, since so much of the rest of the description is
    based on trying to treat a single EE certificate issued by a CA as
    if it were two different, but identical, certificates issued by two
    different, but colluding, CAs that happen to issue under the same
    name and using the same key.

    

    Why not just acknowledge that this attack scenario involves one CA
    issuing one EE certificate, where the one CA has been issued
    cross-certificates by two different "parent" CAs and then write the
    remainder of the text based on that. That would eliminate any
    justification for including a parenthetical falsely claiming that
    RFC 5280 does not preclude the creation of two CAs with the same
    name, but it would make the description of the attack so much
    better. Right now, the proposed text isn't "more general," it is
    just convoluted.

    

    

      
 As I explained, my description of an
        colluding CA attack differs from DKGs in that it

        is more general and thus. I think, more useful for discussion in
        the threat analysis.

        

        Yes, it is true that CRLs and OCSP responses would not generally
        be tied to the

        two CA instances on different cert paths. But, that's not the
        point. It would be dangerous 

        to assume that an RP can be confident that the revocation status
        data it acquires comes

        from a specific instance of a CA, when there are two CAs with
        the same names and 

        same public keys. RFC 5280 does not provide implementation
        guidance that calls for

        pooling of revocation status info based on CA name. An RP may
        maintain a cache organized

        by cert path, associating revocation status info with each CA in
        each cert path.

    

    

    Can you name even one RP that maintains a cache of revocation status
    info organized by cert path? If not, then why all the text about
    revocation status checking being performed in the context of a
    certification path and how "a browser checking a CRL or OCSP
    response may not match this revocation status data against the
    doppelganger certificate," followed by a suggestion that the
    attacker might take advantage of this by revoking one of the two
    identical EE certificates while not revoking the other. Why would it
    be the "best strategy" for the attacker to rely on browsers behaving
    in a way that no browsers actually behave? As I said before, there
    are ways the attacker might be able to perform the type of attack
    where some RPs see the EE certificate as having been revoked and
    others do not, but that it not what you described.

    

    Why not just go back to what DKG described, where the attacker
    revokes the CA certificate along the path submitted to the log and
    leaves the other CA certificate unrevoked so that there is still a
    valid certification path to the one EE certificate?

    

    

      
Such

        an implementation strategy is attractive because it can allow an
        RP to avoid redundant

        cert path validation processing when a target cert shares a
        portion of a cert path with

        other certs that have been validated. In such an implementation
        an RP would not be aware that

        there are two CAs with the same name on different cert paths,
        and revocation status data 

        associated with each of these CAs would be acquired and
        maintained separately. In such

        circumstances an attack of the sort I described is feasible.

        

        Thus I stand by my analysis of the vulnerability, in the more
        general case.

        

        Steve

      

      

    

    

  



From nobody Sat Mar 26 14:58:06 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C4712D165 for ; Sat, 26 Mar 2016 14:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15bN5Qe76zTP for ; Sat, 26 Mar 2016 14:58:02 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4543F12D0CC for ; Sat, 26 Mar 2016 14:58:02 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id x64so26636472qkd.1 for ; Sat, 26 Mar 2016 14:58:01 -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; bh=9aUipFNWoutLPdgOkCcbpgTSMAQnbkTcmfiPat6HYVg=; b=ncZBf+lT5Pkt3Zi9USYKI9Xx8lVeZhy4EaVxA7x2m5MZpeh6CBk8H8GpUowSa5P9Fy 5e+nZ30cLpOfFbbY/BQ9uofQn8rPqzNNqMRgLqYdUGuw9ES9Di+sQjwRDzu2rMoXrR3Y 54lxbSlgUyQJYgwIZS/5Kfn2GZ6PJutvvDUBB9k+7az2uPL1If6WRs0i4W24SFmf9hH7 Jhf3QqjyvfxARnoo7htOq1inmTEseUPe4s/Zvzya6MohySXvFCY58sEkIMvOL+auliP2 R1Cp6F6A8G6PVwZhsrTyym1cDDYxIzbWvniqJLR4QGrYUKJ8jVS1LqSx2ZwXWZzM+alq ArJg==
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; bh=9aUipFNWoutLPdgOkCcbpgTSMAQnbkTcmfiPat6HYVg=; b=nMlFEB57SObL8/egn6/fsF+oRAQz/vvAKIP+lKpXqQ2NM8PMV+V9inaQN8httIEk8N 5gyTUEWDkzJ3yFzi5dK9LJu21VT30HXz6Ry0gfqUycDbsYiUpNkpD+SRr/lklt1BoCfX 6soQN5fqizhacSAFqDkJiS/GZhfxNElttLt69JdY+5QjPQ7qzv8ils9rmgAqc2bJy5Mp XRyTeIdwsyFl9UJLZgMXQyiiKNVK6T7hiP4LFWD8LqBTMie9esTmgtzYAuCn1VdM7AKt LOzvQimK5itpyRr8MfqWcquAORWPTQ5dwMAoQ7moQXKKk53GOmqlUQiYN0dlM9C309hF mJiQ==
X-Gm-Message-State: AD7BkJJ+y0XspOeFFLGIvLU/XPrRLcX2vYds6dvxVqtkrTCECOMJaDfKfjXOlb/6b8cKoIE6qG9TBTGASM+L2hkW
MIME-Version: 1.0
X-Received: by 10.37.24.69 with SMTP id 66mr10147319yby.187.1459029480985; Sat, 26 Mar 2016 14:58:00 -0700 (PDT)
Received: by 10.37.48.6 with HTTP; Sat, 26 Mar 2016 14:58:00 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sat, 26 Mar 2016 21:58:00 +0000
Message-ID: 
From: Eran Messeri 
To: "certificate-transparency@googlegroups.com" ,  "trans@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113fc6b2eefdd7052efac54b
Archived-At: 
Subject: Re: [Trans] Why "Poison Extension" disappeared in rfc6962-bis?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Mar 2016 21:58:05 -0000

--001a113fc6b2eefdd7052efac54b
Content-Type: text/plain; charset=UTF-8

[+trans mailing list]
The poison extension was removed because it is no longer necessary - the
purpose was to allow creating a pre-certificate in the form of an unusable
X.509 certificate (the poison extension is a critical extension that made
an otherwise valid X.509 certificate unusable).

In 6962-bis the pre-certificate is encoded using Cryptographic Message
Syntax (CMS), not X.509 certificates, so the poison extension is no longer
needed.

One reason for the precertificate format transition I recall is concerns
that issuing two X.509 certificates with the same serial number (even
though one of them is unusable) is against the CA/Browsers forum Baseline
Requirements.
The related discussions can be found in the trans mailing list:
https://www.ietf.org/mailman/listinfo/trans

Hope this helps,
Eran

On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI  wrote:

> Hi,
>
> I read rfc6962-bis, and found that description of "Poison Extension (OID
> 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
> I want to view a discussion about this issue(and want to know the reason
> why it disappeard), so can I get URLs about the discussion?
>
> Thanks,
> Yusuke
>
> --
> You received this message because you are subscribed to the Google Groups
> "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to certificate-transparency+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--001a113fc6b2eefdd7052efac54b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


[+trans mailing list]
The poison extension was removed=
 because it is no longer necessary - the purpose was to allow creating a pr=
e-certificate in the form of an unusable X.509 certificate (the poison exte=
nsion is a critical extension that made an otherwise valid X.509 certificat=
e unusable).

In 6962-bis the pre-certificate is en=
coded using Cryptographic Message Syntax (CMS), not X.509 certificates, so =
the poison extension is no longer needed.

One reas=
on for the precertificate format transition I recall is concerns that issui=
ng two X.509 certificates with the same serial number (even though one of t=
hem is unusable) is against the CA/Browsers forum Baseline Requirements.=C2=
=A0
The related discussions can be found in the trans mailing lis=
t:=C2=A0https://www=
.ietf.org/mailman/listinfo/trans

Hope this hel=
ps,
Eran

On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI <ozuma5119@gm=
ail.com> wrote:
Hi,=C2=A0

I read rfc6962-bis, and found=
 that description of "Poison Extension (OID 1.3.6.1.4.1.11129.2.4.3)&q=
uot; has disappeared.
I want to view a discussion about this issu=
e(and want to know the reason why it disappeard), so can I get URLs about t=
he discussion?

Thanks,
Yusuke






-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegroups.c=
om.

For more options, visit https://groups.google.com/d/optout.





--001a113fc6b2eefdd7052efac54b--


From nobody Sun Mar 27 11:18:54 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A468C12D513 for ; Sun, 27 Mar 2016 11:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUDrUNBy0zXb for ; Sun, 27 Mar 2016 11:18:50 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 590AB12D0C3 for ; Sun, 27 Mar 2016 11:18:50 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id g185so1429358ioa.2 for ; Sun, 27 Mar 2016 11:18:50 -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; bh=1ktxef/nVr8qWr6bcIhUj25wryzQ9FiUVYMKxkdM+uE=; b=MuzgKrXR7jdI9kfXmEtVKJgF9MisurddfkT8d4PHbcsx5E0wcadu5UVnXlk3gPyru9 qQ5r7+W9dnbXugdfSgZHdWWbancLm76APiLi7iQleutzQgkMAwBu4wm/nX+tKoeFTlgi Fv5qFCvvSOVSCUUCt230EQ3zaqIQZ4kkrkL0T8js2YCTcbEVYxyS9OMYJXe1v19TTqEq OYi4Cr/O2WrlAKod2kzZyuMYE/UGjqOUSNtG37gQtVT+duvaYSrlFZTCO7+fiyhuS4Ws 1muiFjQQCFWu6w10GB+SweMH/zspJ1+5it5EfZb5WYMLfye/Aprp6GkVPU10GXa1rssS OnZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1ktxef/nVr8qWr6bcIhUj25wryzQ9FiUVYMKxkdM+uE=; b=S0Y/sYTDy4uGCJtYyJCE1wQovaeu8NedEicjADK1t1GaJH25k0Wn0OkB+MP0vA7dKo cw3hS6t431jEP7YmphFVKbngmOWF5bQuIaVV3PQZP99fKhI/ZjuFc2+F+Actulqm77rS MJSOHfi7LyyCNe1AlUoeawa8S65lqCB7SZ55dAo6Qi/6KF635pbl2mOvZR2DozV+puiH yONKLIK0YSdhlHcCyEGzqpV46Y9FGToJdRIgP0ct9dQAmI0nWTWtrPUwc7qMss8MqqVz kHA4fqRyUye61LgIe7QNOBcdDQsk9vRNUdWeOHHZnSZVqqwmZfvF+o6js9xuITTFdd3W GRTw==
X-Gm-Message-State: AD7BkJJShlekiSc4AA+8SPhCxGEVVAE/dCMbV7QrWksLQ36EOiK4w+WH4+fdoWn9EG6ysGJt4RYGgGNVNzhVytu+
MIME-Version: 1.0
X-Received: by 10.107.35.209 with SMTP id j200mr6733057ioj.119.1459102729479;  Sun, 27 Mar 2016 11:18:49 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Sun, 27 Mar 2016 11:18:49 -0700 (PDT)
In-Reply-To: 
References:   
Date: Sun, 27 Mar 2016 19:18:49 +0100
Message-ID: 
From: Ben Laurie 
To: "certificate-transparency@googlegroups.com" 
Content-Type: multipart/alternative; boundary=001a1141b946e22ae6052f0bd389
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Why "Poison Extension" disappeared in rfc6962-bis?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Mar 2016 18:18:52 -0000

--001a1141b946e22ae6052f0bd389
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 27 March 2016 at 08:32, Yusuke OSUMI  wrote:

> Eran,
>
> Thanks, I get the picture!
> I also think "precertificate and issued certificate have the same serial
> number" is weird and strange, so this change is welcome.
>

Note that the precertificate still has the same serial number as the
certificate. Its just that it is not a certificate anymore.


>
>
> 2016=E5=B9=B43=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=825=
8=E5=88=8601=E7=A7=92 UTC+9 Eran Messeri:
>>
>> [+trans mailing list]
>> The poison extension was removed because it is no longer necessary - the
>> purpose was to allow creating a pre-certificate in the form of an unusab=
le
>> X.509 certificate (the poison extension is a critical extension that mad=
e
>> an otherwise valid X.509 certificate unusable).
>>
>> In 6962-bis the pre-certificate is encoded using Cryptographic Message
>> Syntax (CMS), not X.509 certificates, so the poison extension is no long=
er
>> needed.
>>
>> One reason for the precertificate format transition I recall is concerns
>> that issuing two X.509 certificates with the same serial number (even
>> though one of them is unusable) is against the CA/Browsers forum Baselin=
e
>> Requirements.
>> The related discussions can be found in the trans mailing list:
>> https://www.ietf.org/mailman/listinfo/trans
>>
>> Hope this helps,
>> Eran
>>
>> On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI  wrote:
>>
>>> Hi,
>>>
>>> I read rfc6962-bis, and found that description of "Poison Extension (OI=
D
>>> 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
>>> I want to view a discussion about this issue(and want to know the reaso=
n
>>> why it disappeard), so can I get URLs about the discussion?
>>>
>>> Thanks,
>>> Yusuke
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "certificate-transparency" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to certificate-transparency+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to certificate-transparency+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--001a1141b946e22ae6052f0bd389
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 27 March 2016 at 08:32, Yusuke OSUMI <ozuma5119@gmail.com&g=
t; wrote:
Eran,
Thanks, I get the picture!
I also think "precertificate and i=
ssued certificate have the same serial number" is weird and strange, s=
o this change is welcome.

Note th=
at the precertificate still has the same serial number as the certificate. =
Its just that it is not a certificate anymore.
=C2=A0


2016=E5=B9=B43=E6=9C=8827=
=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=8258=E5=88=8601=E7=A7=92 UTC+9=
 Eran Messeri:
[+trans mailing list]
The poison extension was removed bec=
ause it is no longer necessary - the purpose was to allow creating a pre-ce=
rtificate in the form of an unusable X.509 certificate (the poison extensio=
n is a critical extension that made an otherwise valid X.509 certificate un=
usable).

In 6962-bis the pre-certificate is encode=
d using Cryptographic Message Syntax (CMS), not X.509 certificates, so the =
poison extension is no longer needed.

One reason f=
or the precertificate format transition I recall is concerns that issuing t=
wo X.509 certificates with the same serial number (even though one of them =
is unusable) is against the CA/Browsers forum Baseline Requirements.=C2=A0<=
/div>
The related discussions can be found in the trans mailing list:=
=C2=A0https://www.ietf.org/mailman/listinfo/trans
=


Hope this helps,
Eran

On Sat, Mar 26, 2016 at 5:4=
9 AM, Yusuke OSUMI <ozum...@gmail.=
com> wrote:
Hi,=C2=A0

I read rfc6962-bis, and found tha=
t description of "Poison Extension (OID 1.3.6.1.4.1.11129.2.4.3)"=
 has disappeared.
I want to view a discussion about this issue(an=
d want to know the reason why it disappeard), so can I get URLs about the d=
iscussion?

Thanks,
Yusuke






-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegrou=
ps.com.

For more options, visit https://groups.google.com/d/optout.










-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegroups.c=
om.

For more options, visit https://groups.google.com/d/optout.





--001a1141b946e22ae6052f0bd389--


From nobody Mon Mar 28 07:22:39 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3912D996 for ; Mon, 28 Mar 2016 07:22: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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNdo7yyX8BXv for ; Mon, 28 Mar 2016 07:22:35 -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 DE28E12D9AA for ; Mon, 28 Mar 2016 07:20:13 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:54218 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1akY1b-000BCv-N2; Mon, 28 Mar 2016 10:20:11 -0400
From: Stephen Kent 
To: Paul Wouters 
References: <56F4039B.2020604@bbn.com>  <56F54EE2.1000008@bbn.com> 
Message-ID: <56F93D9D.2070704@bbn.com>
Date: Mon, 28 Mar 2016 10:20:13 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Mar 2016 14:22:39 -0000

Paul,

> On Fri, 25 Mar 2016, Stephen Kent wrote:
>
>>>  If the certificates are doppelgangers, wouldn't that mean that they
>>>  cannot have AIA's ? Otherwise at least one CA would be using an 
>>> "unusual"
>>>  AIA revocation location that monitors would detect.
>> The doppelgangers could have AIAs, but they need not, and that is the 
>> assumption  I adopted here. In general it is in the interest of the 
>> CAs to not put AIAs in these certs,
>> if the plan is to revoke one, but not the other.  (Unless the CAs can 
>> control which
>> revocation status info is accessible to targeted browser users, in 
>> which case it doesn't
>> matter.)
>
> I would hope that the CT ecosystem would see that if a CA always issues
> with AIA in the EE-cert, and then it issues a cert where it does not,
> that it would get flagged for a human to look at. Part of CT is keeping
> an eye out on the CAs, and this clearly shows some unexpected behaviour
> on one or two particular CA's for not including AIA's. It might not be
> syntactically bogus, but hopefully something the clients and monitors
> would keep an eye out for.
There is no text in any monitor description that calls for this, so it
may be unduly optimistic to assume such ;-).  Also, if the CAs collude
they would be smart to never include an AIA extension, so as to avoid
drawing attention when an EE cert w/o such an extension is issued.
> So it seems to me this attack is not very likely to succeed - or at
> least would be a short-lived one with a guarantee of being detected.
> So it comes with a big enigma problem.
I can't agree with your conclusion if it's based on the analysis above,
but I also can't predict how long such an attack might go undetected given
the many variables involved.

Steve


From nobody Mon Mar 28 07:36:53 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C16812D9AF for ; Mon, 28 Mar 2016 07:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw6jVC2ivUDD for ; Mon, 28 Mar 2016 07:36:52 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F25F12DA48 for ; Mon, 28 Mar 2016 07:35:28 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qYbzf3qDLzCJn; Mon, 28 Mar 2016 16:35:26 +0200 (CEST)
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 rJZJRHw41pF2; Mon, 28 Mar 2016 16:35:25 +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; Mon, 28 Mar 2016 16:35:25 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id EDE2A60007EA; Mon, 28 Mar 2016 10:35:24 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca EDE2A60007EA
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E894718D6F; Mon, 28 Mar 2016 10:35:24 -0400 (EDT)
Date: Mon, 28 Mar 2016 10:35:24 -0400 (EDT)
From: Paul Wouters 
To: Stephen Kent , Melinda Shore 
In-Reply-To: <56F93D9D.2070704@bbn.com>
Message-ID: 
References: <56F4039B.2020604@bbn.com>  <56F54EE2.1000008@bbn.com>  <56F93D9D.2070704@bbn.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Mar 2016 14:36:53 -0000

On Mon, 28 Mar 2016, Stephen Kent wrote:



> I can't agree with your conclusion if it's based on the analysis above,
> but I also can't predict how long such an attack might go undetected given
> the many variables involved.

So there seems to be no consensus about the colluding CA's scenario,
and thus no consensus on the text that needs to go into the threat
document. A few people think your text needs changes. It also seems
to be the only issue left for WGLC.

Do you have an idea on how to change the text to accomodate the feedback
received on the list? Should we ask someone else to help you with
this section? Perhaps dkg could help, since he originally came up with
the attack?

We really want to move this document into WGLC, so that the 6962bis
document doesn't have to refer to a draft name, and we are very close
to putting 6962 into WGLC.

Paul


From ozuma5119@gmail.com  Sun Mar 27 00:32:41 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6175912D102 for ; Sun, 27 Mar 2016 00:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCA_BOucGiT7 for ; Sun, 27 Mar 2016 00:32:39 -0700 (PDT)
Received: from mail-ig0-x239.google.com (mail-ig0-x239.google.com [IPv6:2607:f8b0:4001:c05::239]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6A412D0A4 for ; Sun, 27 Mar 2016 00:32:39 -0700 (PDT)
Received: by mail-ig0-x239.google.com with SMTP id nt3so293915igb.0 for ; Sun, 27 Mar 2016 00:32:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=r+uHFJx5oP4tWnIIz0UfLXtOEJAaA3jo+ac0fasJeVE=; b=zzVPxGPDM7VJXJehTbXI2Lt1tv3hR56LKyENOU+e/wGVkf7T/Vbh1b1n/o6C5M3bKH 8YFiS6roz6epwqpdrL0kCcb1OasF15CyZ3Ac/SJ0mp9zbVkjAu1KIjCJ9ze7AHkVrihY o2OcqPqqHG/iim5bN4lh27ryaSrA34QxBkuz/q0quB5bKurZO9l7S5RAcswf+K56q2Ql pJqBZ2zfohmzQPr0Ppwwcphz7hUK7CA3sJhdnTFHjcnZjrQLqSwmbqyY7doe1H46Owom qsviZtTogYOJGRDCnGX3Rii3/GsLWP0u9sXYYN3A9N4vRiXi7zt0xHEhjoSM3h68EyzD 4dfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=r+uHFJx5oP4tWnIIz0UfLXtOEJAaA3jo+ac0fasJeVE=; b=hOiZTa9vIplp4xvtClyIu6hSeU3fU3WSYoX+cMjtr9JfH1qf2UP+b4OAHiYu+Z53gP IfuvcQbSoIPNh+NQIZufGvWKhNlf8A9jY11/uGKrbMS6Sgz5ocmRFq5RI5b+7ndrPXi9 ewZ0ZG4Tf0Y5uni2cnB4JIy96wnM3uxiG8hCFLvmdpXO+ppwRUD9fN7mTuBTUDwnRi8n MR8VBxz+nxDj1Kj/A+VHnfSybpF5Mn/B6DTg246aGojEJwV5Ed5nABi4zgSef+4iBF9v zhFUVJimDBoyha875YEvg8XHYHv59vyva+TFsLrgPEx+KQYpukHOIuaBhTblP3hLda8s D/vQ==
X-Gm-Message-State: AD7BkJKi5O9CbQpXoq4X5bLo4W0zniIkp/vOqEReBqQ6J4ifm3oTJKIf/pMxjEaWEPTqWwXobC5n
X-Received: by 10.182.125.225 with SMTP id mt1mr173415obb.17.1459063958472; Sun, 27 Mar 2016 00:32:38 -0700 (PDT)
X-Google-Already-Archived: Yes
X-Google-Already-Archived-Group-Id: c29adbd6b4
X-Google-Doc-Id: 6ed5bd8715dfe
X-Google-Thread-Id: 8296d3128f373182
X-Google-Message-Url: http://groups.google.com/group/certificate-transparency/msg/6ed5bd8715dfe
X-Google-Thread-Url: http://groups.google.com/group/certificate-transparency/t/8296d3128f373182
X-Google-Web-Client: true
Date: Sun, 27 Mar 2016 00:32:37 -0700 (PDT)
From: Yusuke OSUMI 
To: certificate-transparency 
Message-Id: 
In-Reply-To: 
References:  
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_210_1366993043.1459063957594"
X-Google-Token: EJWZ3rcFU-YECiuN25Q0
X-Google-IP: 114.178.214.201
Archived-At: 
X-Mailman-Approved-At: Mon, 28 Mar 2016 10:09:35 -0700
Cc: trans@ietf.org
Subject: Re: [Trans] Why "Poison Extension" disappeared in rfc6962-bis?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Mar 2016 15:18:33 -0000

------=_Part_210_1366993043.1459063957594
Content-Type: multipart/alternative; 
	boundary="----=_Part_211_2016472205.1459063957594"

------=_Part_211_2016472205.1459063957594
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Eran,

Thanks, I get the picture!
I also think "precertificate and issued certificate have the same serial=20
number" is weird and strange, so this change is welcome.


2016=E5=B9=B43=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=8258=
=E5=88=8601=E7=A7=92 UTC+9 Eran Messeri:
>
> [+trans mailing list]
> The poison extension was removed because it is no longer necessary - the=
=20
> purpose was to allow creating a pre-certificate in the form of an unusabl=
e=20
> X.509 certificate (the poison extension is a critical extension that made=
=20
> an otherwise valid X.509 certificate unusable).
>
> In 6962-bis the pre-certificate is encoded using Cryptographic Message=20
> Syntax (CMS), not X.509 certificates, so the poison extension is no longe=
r=20
> needed.
>
> One reason for the precertificate format transition I recall is concerns=
=20
> that issuing two X.509 certificates with the same serial number (even=20
> though one of them is unusable) is against the CA/Browsers forum Baseline=
=20
> Requirements.=20
> The related discussions can be found in the trans mailing list:=20
> https://www.ietf.org/mailman/listinfo/trans
>
> Hope this helps,
> Eran
>
> On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI  > wrote:
>
>> Hi,=20
>>
>> I read rfc6962-bis, and found that description of "Poison Extension (OID=
=20
>> 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
>> I want to view a discussion about this issue(and want to know the reason=
=20
>> why it disappeard), so can I get URLs about the discussion?
>>
>> Thanks,
>> Yusuke
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "certificate-transparency" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to certificate-transparency+unsubscribe@googlegroups.com=20
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
------=_Part_211_2016472205.1459063957594
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Eran,

Thanks, I get the picture!
I also think &q=
uot;precertificate and issued certificate have the same serial number"=
 is weird and strange, so this change is welcome.


2016=E5=B9=B43=
=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=8258=E5=88=8601=E7=
=A7=92 UTC+9 Eran Messeri:
[+trans mailing list]
The poison extension was removed bec=
ause it is no longer necessary - the purpose was to allow creating a pre-ce=
rtificate in the form of an unusable X.509 certificate (the poison extensio=
n is a critical extension that made an otherwise valid X.509 certificate un=
usable).

In 6962-bis the pre-certificate is encode=
d using Cryptographic Message Syntax (CMS), not X.509 certificates, so the =
poison extension is no longer needed.

One reason f=
or the precertificate format transition I recall is concerns that issuing t=
wo X.509 certificates with the same serial number (even though one of them =
is unusable) is against the CA/Browsers forum Baseline Requirements.=C2=A0<=
/div>
The related discussions can be found in the trans mailing list:=
=C2=A0https://www.ietf.org/ma=
ilman/listinfo/trans

Hope this helps,
Eran

On Sat, Mar 26, 2016 =
at 5:49 AM, Yusuke OSUMI <ozum...@gmail.com> =
wrote:
Hi,=C2=A0

I read rfc6962-bis, and found that description of &q=
uot;Poison Extension (OID 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
I want to view a discussion about this issue(and want to know the =
reason why it disappeard), so can I get URLs about the discussion?

Thanks,
Yusuke






-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/=
d/optout.





------=_Part_211_2016472205.1459063957594--

------=_Part_210_1366993043.1459063957594--


From nobody Mon Mar 28 10:09:40 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF1E12DA51 for ; Mon, 28 Mar 2016 08:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c-rHmJmQuyp for ; Mon, 28 Mar 2016 08:24:58 -0700 (PDT)
Received: from mail-pf0-x238.google.com (mail-pf0-x238.google.com [IPv6:2607:f8b0:400e:c00::238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9123A12DA8D for ; Mon, 28 Mar 2016 08:24:54 -0700 (PDT)
Received: by mail-pf0-x238.google.com with SMTP id q129so31467416pfb.1 for ; Mon, 28 Mar 2016 08:24:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=BWddATGxFamr58P1zPtbNNnkSfWF+WRYNtr59RSrsAc=; b=KId/rYlpQD7lKvtlnlhEpvhBB6tAqRLve4TmobSSj+LCEhzgtwb4NUUkf+50l9p2qC MORkEL+vslV8xK5V5joR5ZIPd+LGuTfOLq9yCnNNcR0/KtkZ1i1haI00N9v7hWwhuLZ/ VJul4X7P1JKgbypwP3IqcBW4Wr0lGsVEtOP8lZPvrKJsiq+kLOyzHKZcVP+TdSNZX7KW GRjgC69KOh7mEFRJAYruFjmw60v52thCIlQXDLnxfDxs+zf2MKGfemnHBB4bBRylmhXq P0J/t7FqUJJdwuAZO7DFiE62L14/yPtqHGwq+JR2N8QxGL+IQTVPVjng0PUGXkpqr40x LsRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=BWddATGxFamr58P1zPtbNNnkSfWF+WRYNtr59RSrsAc=; b=YRHfuOKVnbVHdzwIYCqdch+9MYo5di0ip5tFLnXxfiYsCwF0yyLFSYUi7vjdIDTzQK DHHZQTTQGe5RTGoNlEcm8hJOdig0+R5LhlK6tB9ol0Wa6f2bfYI2v8vSjD+zJDxM7YsM +6qmaidKKaGLLBGA2EYSQdoDAdl6edGI43Y3paMZwavrqbkoFCrmiyAPJPNH9Mqzsj52 BkITx4iyIoKQQQry/MK+Ll6uMKXcHZAM8NsXwTPUXm7k6JqjSEPCgVSIERK9QRaqh6tQ 5NtOYP+YHtSetpC3ZsBIL1AMeMEVy+YGPXxA4kYD8LLg8fLdxDibgp+xisPiU8ZZdT/L 71fg==
X-Gm-Message-State: AD7BkJLH6YVIvmleqVd9h1hYouQutMpiTOig0MAlpR1rvQbjpir/nnaBsqNk4wUD9PjlEvNiemZh
X-Received: by 10.182.210.167 with SMTP id mv7mr209325obc.18.1459178694151; Mon, 28 Mar 2016 08:24:54 -0700 (PDT)
X-Google-Already-Archived: Yes
X-Google-Already-Archived-Group-Id: c29adbd6b4
X-Google-Doc-Id: 755b5d42104a1
X-Google-Thread-Id: 8296d3128f373182
X-Google-Message-Url: http://groups.google.com/group/certificate-transparency/msg/755b5d42104a1
X-Google-Thread-Url: http://groups.google.com/group/certificate-transparency/t/8296d3128f373182
X-Google-Web-Client: true
Date: Mon, 28 Mar 2016 08:24:53 -0700 (PDT)
From: Yusuke OSUMI 
To: certificate-transparency 
Message-Id: <52019c48-1997-4035-bc44-35e0e649e410@googlegroups.com>
In-Reply-To: 
References:    
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_5137_1691016721.1459178693312"
X-Google-Token: EMWZ5bcF6dCy8ysyrVM0
X-Google-IP: 1.115.197.235
Archived-At: 
X-Mailman-Approved-At: Mon, 28 Mar 2016 10:09:35 -0700
Cc: trans@ietf.org
Subject: Re: [Trans] Why "Poison Extension" disappeared in rfc6962-bis?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Mar 2016 15:25:01 -0000

------=_Part_5137_1691016721.1459178693312
Content-Type: multipart/alternative; 
	boundary="----=_Part_5138_568783485.1459178693320"

------=_Part_5138_568783485.1459178693320
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ben,

Oh, I misunderstanding little bit...
To confirm my understanding, can I summary precertificate in rfc6962-bis=20
below?

* Precertificate and issued certificate has the same serial number.
 =3D> In this context, "serial number of precertificate" means the serial=
=20
number of tbscertificate in precertificate.

* Old problem(RFC6962) is "There are two X.509 certificates with the same=
=20
serial number".
Now on rfc6962-bis, there are still two certificates with the same serial=
=20
number. But one is encoded using X.509(to use for services), and another is=
=20
encoded using CMS(precertificate).

* We don't regard precertificate as 'Certificate', because it is just a=20
Cryptographic Message (based on RFC5652).

Thanks,


On Monday, March 28, 2016 at 3:18:50 AM UTC+9, Ben Laurie wrote:
>
>
>
> On 27 March 2016 at 08:32, Yusuke OSUMI >=
=20
> wrote:
>
>> Eran,
>>
>> Thanks, I get the picture!
>> I also think "precertificate and issued certificate have the same serial=
=20
>> number" is weird and strange, so this change is welcome.
>>
>
> Note that the precertificate still has the same serial number as the=20
> certificate. Its just that it is not a certificate anymore.
> =20
>
>>
>>
>> 2016=E5=B9=B43=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=82=
58=E5=88=8601=E7=A7=92 UTC+9 Eran Messeri:
>>>
>>> [+trans mailing list]
>>> The poison extension was removed because it is no longer necessary - th=
e=20
>>> purpose was to allow creating a pre-certificate in the form of an unusa=
ble=20
>>> X.509 certificate (the poison extension is a critical extension that ma=
de=20
>>> an otherwise valid X.509 certificate unusable).
>>>
>>> In 6962-bis the pre-certificate is encoded using Cryptographic Message=
=20
>>> Syntax (CMS), not X.509 certificates, so the poison extension is no lon=
ger=20
>>> needed.
>>>
>>> One reason for the precertificate format transition I recall is concern=
s=20
>>> that issuing two X.509 certificates with the same serial number (even=
=20
>>> though one of them is unusable) is against the CA/Browsers forum Baseli=
ne=20
>>> Requirements.=20
>>> The related discussions can be found in the trans mailing list:=20
>>> https://www.ietf.org/mailman/listinfo/trans
>>>
>>> Hope this helps,
>>> Eran
>>>
>>> On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI  wrote=
:
>>>
>>>> Hi,=20
>>>>
>>>> I read rfc6962-bis, and found that description of "Poison Extension=20
>>>> (OID 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
>>>> I want to view a discussion about this issue(and want to know the=20
>>>> reason why it disappeard), so can I get URLs about the discussion?
>>>>
>>>> Thanks,
>>>> Yusuke
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "certificate-transparency" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to certificate-transparency+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "certificate-transparency" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to certificate-transparency+unsubscribe@googlegroups.com=20
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
------=_Part_5138_568783485.1459178693320
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ben,

Oh, I misunderstanding =
little bit...
To confirm my understanding, can I summary precerti=
ficate in rfc6962-bis below?

* Precertificate and =
issued certificate has the same serial number.
=C2=A0=3D> In t=
his context, "serial number of precertificate" means the serial n=
umber of tbscertificate in precertificate.

* Old p=
roblem(RFC6962) is "There are two X.509 certificates with the same ser=
ial number".
Now on rfc6962-bis, there are still two certifi=
cates with the same serial number. But one is encoded using X.509(to use fo=
r services), and another is encoded using CMS(precertificate).
* We don't regard precertificate as 'Certificate',=
 because it is just a Cryptographic Message (based on RFC5652).
<=
br>
Thanks,


On Monday, March 28, 2016 at =
3:18:50 AM UTC+9, Ben Laurie wrote:


On 27 March =
2016 at 08:32, Yusuke OSUMI <ozum...@gmail.com> wrote:
Eran,

T=
hanks, I get the picture!
I also think "precertificate and issued c=
ertificate have the same serial number" is weird and strange, so this =
change is welcome.

Note that the =
precertificate still has the same serial number as the certificate. Its jus=
t that it is not a certificate anymore.
=C2=A0


2016=E5=B9=B43=E6=9C=8827=E6=97=
=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=8258=E5=88=8601=E7=A7=92 UTC+9 Eran =
Messeri:
[+tr=
ans mailing list]
The poison extension was removed because it is no lon=
ger necessary - the purpose was to allow creating a pre-certificate in the =
form of an unusable X.509 certificate (the poison extension is a critical e=
xtension that made an otherwise valid X.509 certificate unusable).

In 6962-bis the pre-certificate is encoded using Cryptogra=
phic Message Syntax (CMS), not X.509 certificates, so the poison extension =
is no longer needed.

One reason for the precertifi=
cate format transition I recall is concerns that issuing two X.509 certific=
ates with the same serial number (even though one of them is unusable) is a=
gainst the CA/Browsers forum Baseline Requirements.=C2=A0
The rel=
ated discussions can be found in the trans mailing list:=C2=A0https://www.ietf.org/mailman/listinfo/tran=
s

Hope this helps,
Eran
<=
/span>

On Sat, Mar 26, 2016 at 5:4=
9 AM, Yusuke OSUMI <ozum...@gmail.=
com> wrote:
Hi,=C2=A0

I read rfc6962-bis, and found tha=
t description of "Poison Extension (OID 1.3.6.1.4.1.11129.2.4.3)"=
 has disappeared.
I want to view a discussion about this issue(an=
d want to know the reason why it disappeard), so can I get URLs about the d=
iscussion?

Thanks,
Yusuke






-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googl=
egroups.com.

For more options, visit https://groups.google.com=
/d/optout.










-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/=
d/optout.





------=_Part_5138_568783485.1459178693320--

------=_Part_5137_1691016721.1459178693312--


From nobody Tue Mar 29 04:38:32 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EBB12D6E1 for ; Tue, 29 Mar 2016 04:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGBi29OGRpZb for ; Tue, 29 Mar 2016 04:38:29 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9EE12D6EA for ; Tue, 29 Mar 2016 04:38:11 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id a129so18043467ioe.0 for ; Tue, 29 Mar 2016 04:38: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; bh=kyqVjedk1jFQ0xO9aQInBGVXrZWbdraKzLisxtQ0rcU=; b=pt8itoEvEBsysgbL8SoFag9HwRseI8tjf3EeeukuCEPZbCBAvMtXpOz7nIGL0rEEvv 0ZJORhgEeht9fSfapnK2EjN+BwQ0mYOCPziH0/vXByrNFQ92faQTgMo0/3Au3NLrjsDN s7wOGrZgCGgT64bbHEKv0GypAT04D7gzCdkxLshfQcBbbbXWPR1Q/5TyDikj11ADbxOr vOulSg334SkeorFK9HpFzBp5xDdotGYXDLUar8PMiIydy/M74YRTDz/gS3ZM9J1WLsX2 Vny+afiYMvFZJ/TpIEfcNoIZJKC6ZVXqoxAus5PTBCL54oOJpJ953WERZQjAKqUWws34 BBUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kyqVjedk1jFQ0xO9aQInBGVXrZWbdraKzLisxtQ0rcU=; b=XE5TgCzk+0Ji7pTUNKNI1DmJLutBaoYJ0clPkPqY8jes1sk5FdwkIaK/MquL9uJSGo sNvdhrbv1dLabT37Tx6JF/W/Jn3J5EmWaJhEIgxl9yjreB4bPVerDpf0Bq4e2cyW0el+ 81YV2l3E9rz6QEKr0PInNi6cbdBjrny+W5xyB37DM6GdCT7xn7GcJbxJDMeNo1/IpLXR rdeAakVCihur/mvz/w/SlWuEIbVXo/igW/iqyySlsOEY5+lDtssci/EEluvpkjAOVgBp ts4dBEKO1Cn27KckHHXb3ywb+9HQuDYBtILpJyAle5ZOQHh4RuxY0bxblanYtMgOIGjT GIOA==
X-Gm-Message-State: AD7BkJIaSatSyy5SG1pLwJ6HQz4OJY/YSs+zGNQncV2OUQJvc8cXwhwJvuKJaAi3bmkjyDhu/WIyJCxL9LqMzTY4
MIME-Version: 1.0
X-Received: by 10.107.41.133 with SMTP id p127mr2454165iop.172.1459251491000;  Tue, 29 Mar 2016 04:38:11 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Tue, 29 Mar 2016 04:38:10 -0700 (PDT)
In-Reply-To: <52019c48-1997-4035-bc44-35e0e649e410@googlegroups.com>
References:     <52019c48-1997-4035-bc44-35e0e649e410@googlegroups.com>
Date: Tue, 29 Mar 2016 12:38:10 +0100
Message-ID: 
From: Ben Laurie 
To: "certificate-transparency@googlegroups.com" 
Content-Type: multipart/alternative; boundary=001a1137b81cc2a2b3052f2e76eb
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Why "Poison Extension" disappeared in rfc6962-bis?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2016 11:38:31 -0000

--001a1137b81cc2a2b3052f2e76eb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 28 March 2016 at 16:24, Yusuke OSUMI  wrote:

> Ben,
>
> Oh, I misunderstanding little bit...
> To confirm my understanding, can I summary precertificate in rfc6962-bis
> below?
>
> * Precertificate and issued certificate has the same serial number.
>  =3D> In this context, "serial number of precertificate" means the serial
> number of tbscertificate in precertificate.
>

Correct.


>
> * Old problem(RFC6962) is "There are two X.509 certificates with the same
> serial number".
> Now on rfc6962-bis, there are still two certificates with the same serial
> number. But one is encoded using X.509(to use for services), and another =
is
> encoded using CMS(precertificate).
>

Well, that means the second one is not a certificate.


>
> * We don't regard precertificate as 'Certificate', because it is just a
> Cryptographic Message (based on RFC5652).
>

Exactly.


>
> Thanks,
>
>
> On Monday, March 28, 2016 at 3:18:50 AM UTC+9, Ben Laurie wrote:
>
>>
>>
>> On 27 March 2016 at 08:32, Yusuke OSUMI  wrote:
>>
>>> Eran,
>>>
>>> Thanks, I get the picture!
>>> I also think "precertificate and issued certificate have the same seria=
l
>>> number" is weird and strange, so this change is welcome.
>>>
>>
>> Note that the precertificate still has the same serial number as the
>> certificate. Its just that it is not a certificate anymore.
>>
>>
>>>
>>>
>>> 2016=E5=B9=B43=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=
=8258=E5=88=8601=E7=A7=92 UTC+9 Eran Messeri:
>>>>
>>>> [+trans mailing list]
>>>> The poison extension was removed because it is no longer necessary -
>>>> the purpose was to allow creating a pre-certificate in the form of an
>>>> unusable X.509 certificate (the poison extension is a critical extensi=
on
>>>> that made an otherwise valid X.509 certificate unusable).
>>>>
>>>> In 6962-bis the pre-certificate is encoded using Cryptographic Message
>>>> Syntax (CMS), not X.509 certificates, so the poison extension is no lo=
nger
>>>> needed.
>>>>
>>>> One reason for the precertificate format transition I recall is
>>>> concerns that issuing two X.509 certificates with the same serial numb=
er
>>>> (even though one of them is unusable) is against the CA/Browsers forum
>>>> Baseline Requirements.
>>>> The related discussions can be found in the trans mailing list:
>>>> https://www.ietf.org/mailman/listinfo/trans
>>>>
>>>> Hope this helps,
>>>> Eran
>>>>
>>>> On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I read rfc6962-bis, and found that description of "Poison Extension
>>>>> (OID 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
>>>>> I want to view a discussion about this issue(and want to know the
>>>>> reason why it disappeard), so can I get URLs about the discussion?
>>>>>
>>>>> Thanks,
>>>>> Yusuke
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "certificate-transparency" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d
>>>>> an email to certificate-transparency+unsubscribe@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "certificate-transparency" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to certificate-transparency+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to certificate-transparency+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--001a1137b81cc2a2b3052f2e76eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 28 March 2016 at 16:24, Yusuke OSUMI <ozuma5119@gmail.com&g=
t; wrote:
Be=
n,

Oh, I misunderstanding little bit...
=
To confirm my understanding, can I summary precertificate in rfc6962-bis be=
low?

* Precertificate and issued certificate has t=
he same serial number.
=C2=A0=3D> In this context, "seria=
l number of precertificate" means the serial number of tbscertificate =
in precertificate.

Correct.
=C2=A0
* Old problem(RFC6962) is "There are two X.509 certificate=
s with the same serial number".
Now on rfc6962-bis, there ar=
e still two certificates with the same serial number. But one is encoded us=
ing X.509(to use for services), and another is encoded using CMS(precertifi=
cate).

Well, that means the sec=
ond one is not a certificate.
=C2=A0

* We don't regard precerti=
ficate as 'Certificate', because it is just a Cryptographic Message=
 (based on RFC5652).

Exactly.
=C2=A0
<=
br>
Thanks,


On Monday, March 28, 2016 at =
3:18:50 AM UTC+9, Ben Laurie wrote:


On 27 March 2016 at 08:32, Yusuke OSUMI <ozum...@gmail.com> wrote:
Eran,

Thanks, I get the picture!
I=
 also think "precertificate and issued certificate have the same seria=
l number" is weird and strange, so this change is welcome.

Note that the precertificate still has the s=
ame serial number as the certificate. Its just that it is not a certificate=
 anymore.
=C2=A0


2016=E5=B9=B43=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 =
6=E6=99=8258=E5=88=8601=E7=A7=92 UTC+9 Eran Messeri:
[+trans mailing list]
The poiso=
n extension was removed because it is no longer necessary - the purpose was=
 to allow creating a pre-certificate in the form of an unusable X.509 certi=
ficate (the poison extension is a critical extension that made an otherwise=
 valid X.509 certificate unusable).

In 6962-bis th=
e pre-certificate is encoded using Cryptographic Message Syntax (CMS), not =
X.509 certificates, so the poison extension is no longer needed.
=

One reason for the precertificate format transition I recall=
 is concerns that issuing two X.509 certificates with the same serial numbe=
r (even though one of them is unusable) is against the CA/Browsers forum Ba=
seline Requirements.=C2=A0
The related discussions can be found i=
n the trans mailing list:=C2=A0https://www.ietf.org/mailman=
/listinfo/trans

Hope this helps,
Era=
n

On Sat, Mar 2=
6, 2016 at 5:49 AM, Yusuke OSUMI <=
ozum...@gmail.com> wrote:
<=
div dir=3D"ltr">
Hi,=C2=A0

I read rfc6962-bis,=
 and found that description of "Poison Extension (OID 1.3.6.1.4.1.1112=
9.2.4.3)" has disappeared.
I want to view a discussion about=
 this issue(and want to know the reason why it disappeard), so can I get UR=
Ls about the discussion?

Thanks,
Yusuke<=
/div>






-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegrou=
ps.com.

For more options, visit https://groups.google.com/d/optout.










-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegrou=
ps.com.

For more options, visit https://groups.google.com/d/optout.










-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegroups.c=
om.

For more options, visit https://groups.google.com/d/optout.





--001a1137b81cc2a2b3052f2e76eb--


From nobody Tue Mar 29 04:42:58 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803E212D6EE for ; Tue, 29 Mar 2016 04:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level: 
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUJAVfEgBXne for ; Tue, 29 Mar 2016 04:42:42 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E44212D6D7 for ; Tue, 29 Mar 2016 04:42:42 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id av4so74803101igc.1 for ; Tue, 29 Mar 2016 04:42:42 -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; bh=5/68JECvUcIl+DUSNSTUOmqJieBJX1byicvMiS0PFpI=; b=btaraP0esnASC3bCTRmZ0GMW6fEXoyO3uoOqzRhFtyVgGrBNUXlhb7IpASMRPbBIxO RuxqRsFXG7ALOSqIzV2w5N7zpqMkzfkHdTy9sst3CPhVOHbzLZ2AI79tmYLhbZQXZZSH LJZY2VeBlhrL/rMgcRYY4FT70xXDOwGNToY22mKURgXR45scKl0OnHXhw+C+kPZY3ADX tjjmmc4NuT497nWhbdoynkBYNfzGRseI5wYUV4+pxGzx458wiplEU9UlmCugQcYowNYj fVYaszVRTGbv9KGzZqFGuoTE+vaSIVZbAOf2nHCsk3TlYmVSkzO/jp7O1Uf/TjDhz9wV WoZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5/68JECvUcIl+DUSNSTUOmqJieBJX1byicvMiS0PFpI=; b=RA5OnztRaRq2CZUgWwdXzAIHEF1c0ueNo0oWSWs0wwkh64QNfvG5XmJ1Bs4VnNlhRK 63HL+BgiETrxJ4j0eaFyTmB7yq30t6BMJC2OumDI1mNjkE9Bnufk/ZWwsDlbPCd99tSH QrfkrTzPXk7sISJmrPdQtZYuTAqlToHltad4ki8RRvtbJi4ZjPO54uH8qQUfONhFjKdG qaPGrmxiD31En5jR39yRT+XBoCv87eY8t+cEcV2rGMzZfzQVPhSipTa8sTe99NK4/Zkd OlDiL9X2qz9XzvLjTAB/RmswGY2L1thPL+DQNsAxDp3OjQjI/ak0o5QQa6Cj6z/UCu7e rkOQ==
X-Gm-Message-State: AD7BkJJ2Yo8xIYkGdoNCLPtfhALPsNBCKoE4YdpBCqBRzVaWtHVqAwlCikEQAlMz1B/2uU515z/hI7L41XuF/c9n
MIME-Version: 1.0
X-Received: by 10.50.8.102 with SMTP id q6mr2337256iga.37.1459251761663; Tue, 29 Mar 2016 04:42:41 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Tue, 29 Mar 2016 04:42:41 -0700 (PDT)
In-Reply-To: <56F4039B.2020604@bbn.com>
References: <56F4039B.2020604@bbn.com>
Date: Tue, 29 Mar 2016 12:42:41 +0100
Message-ID: 
From: Ben Laurie 
To: Stephen Kent 
Content-Type: multipart/alternative; boundary=089e0118482ce4a3fc052f2e86b4
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2016 11:42:48 -0000

--089e0118482ce4a3fc052f2e86b4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 24 March 2016 at 15:11, Stephen Kent  wrote:

> 3.3 Malicious, Colluding CAs
>
>
>
> Section 3.2 examined attacks in which a single CA issued a bogus
> certificate. There is also the potential that two or more CAs might collu=
de
> to issue a bogus certificate in a fashion designed to foil the remediatio=
n
> safeguards envisioned by CT.
>
>
>
> In general, any two CAs that are not name-constrained and do not share a
> common path to a trust anchor can collude to create a =E2=80=9Cdoppelgang=
er=E2=80=9D EE
> certificate that is bogus. The attack need not be initiated by trust
> anchors; any subordinate pair of (not name-constrained) CAs can effect th=
is
> attack without the knowledge of superiors CAs. (RFC 5280 doe not preclude
> the creation of two CAs with the same name, so long as the parent CAs are
> distinct. Requirements for Subject name uniqueness apply individually to
> each CA but not across CA boundaries. There also is no requirement for
> public key uniqueness across all CAs. However, the creation of doppelgang=
er
> EE certificates by these CAs may be a violation of RFC 5280 (if one views
> the CAs that appear on different certification paths as one CA).
>
>
>
> The attack requires that each of the colluding CAs issues a certificate
> for a targeted Subject (e.g., web site). These two (EE) certificates are
> identical, hence the use of the term =E2=80=9Cdoppelganger=E2=80=9D; they=
 contain the same
> name, public key, serial number, etc. Only one of the malicious CAs logs
> the bogus certificate and acquires an SCT for it.
>
>
>
> The logged bogus certificate can be detected by a Monitor (third party or
> self), that is observing the log(s) to which the certificate was posted.
> Thus the detection aspect of CT still works with regard to this (bogus)
> certificate. When this certificate is detected, the CA that logged the
> certificate might choose to revoke it, i.e., place it on a CRL or create =
an
> OCSP response for it. However, a browser checking a CRL or OCSP response
> may not match this revocation status data against the doppelganger
> certificate. This is because revocation status checking is performed in t=
he
> context of a certificate path. The doppelganger certificates have differe=
nt
> certificate paths and thus the revocation status data for each might be
> acquired and stored independently. (RFC 5280 does not provide
> implementation guidance for management of revocation data.) Revoking a
> detected, bogus certificate might be the best strategy for the malicious
> CA that logged the certificate; it makes issuance of the bogus certificat=
e
> appear to be an accident, and thus a browser vendor might not feel the ne=
ed
> to make an entry on its blacklists for the bogus certificate or for the
> CA that issued it. (If the bogus certificate included an AIA extension
> providing information for revocation status checking, revocation by the C=
A
> that logged the bogus certificate would not be an effective strategy for
> these colluding CAs. However, inclusion of this extension is not mandated
> by RFC 5280. Also the extension is not critical, meaning that relying
> parties are not required to be able to process it.)
>
>
>
> If the CA that logged the bogus certificate fails to revoke it, browser
> vendors might blacklist the certificate. However, as noted above, the
> doppelganger, which was not logged, will match the SCT created for the
> logged certificate. If remediation is effected by blacklisting (instead o=
f
> revocation by one of the malicious CAs) then the ability of CT to deal wi=
th
> this sort of attack may be diminished.
>

Once more, this problem is not CT's problem - it is a problem with RFC 5280
et al. That is, the problem exists regardless of the existence or use of CT=
.

Does this mean 5280 should be updated?


> Some forms of blacklisting will cause the not-logged bogus certificate to
> be detected and rejected, while others will not, depending on the details
> of the blacklisting mechanism. Mechanisms for blacklisting by browsers ar=
e
> not specified in any IETF standards. The mechanisms are browser-specific,
> and the choice of how to blacklist (e.g., the bogus certificate vs. the C=
A
> that issued it) are the purview of each browser vendor. Thus, depending o=
n
> the details of the blacklist mechanism and the way that a browser vendor
> chooses to manage this list, a doppelganger CA attack might or might not
> pose a problem in terms of successful remediation of the attack.
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>

--089e0118482ce4a3fc052f2e86b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 24 March 2016 at 15:11, Stephen Kent <kent@bbn.com> wrot=
e:

 =20
   =20
 =20
  

   =20
    
3.3
        Malicious, Colluding CAs

    
=C2=A0

    
Section
        3.2 examined attacks in which a single CA issued a bogus
        certificate. There is also the potential that two or more CAs
        might collude to issue a bogus certificate in a fashion designed
        to foil the remediation safeguards envisioned by CT. =


    
=C2=A0

    
In
        general, any two CAs that are not name-constrained and do not
        share a common path to a trust anchor can collude to create a
        =E2=80=9Cdoppelganger=E2=80=9D EE certificate that is bogus. The at=
tack need not
        be initiated by trust anchors; any subordinate pair of (not
        name-constrained) CAs can effect this attack without the
        knowledge of superiors CAs. (RFC 5280 doe not preclude the
        creation of two CAs with the same name, so long as the parent
        CAs are distinct. Requirements for Subject name uniqueness apply
        individually to each CA but not across CA boundaries. There also
        is no requirement for public key uniqueness across all CAs.
        However, the creation of doppelganger EE certificates by these
        CAs may be a violation of RFC 5280 (if one views the CAs that
        appear on different certification paths as one CA).

    
=C2=A0

    
The
        attack requires that each of the colluding CAs issues a
        certificate for a targeted Subject (e.g., web site). These two
        (EE) certificates are identical, hence the use of the term
        =E2=80=9Cdoppelganger=E2=80=9D; they contain the same name, public =
key, serial
        number, etc. Only one of the malicious CAs logs the bogus
        certificate and acquires an SCT for it.

    
=C2=A0

    
The
        logged bogus certificate can be detected by a Monitor (third
        party or self), that is observing the log(s) to which the
        certificate was posted. Thus the detection aspect of CT still
        works with regard to this
        (bogus) certificate. When this certificate is detected, the CA
        that logged the certificate might choose to revoke it, i.e.,
        place it on a CRL or create an OCSP response for it. However, a
        browser checking a CRL or OCSP response may not match this
        revocation status data
        against the doppelganger certificate. This is because revocation
        status checking is performed in the context of a certificate
        path. The doppelganger certificates have different certificate
        paths and thus the revocation status data for each might be
        acquired and stored independently. (RFC 5280 does not provide
        implementation guidance for management of revocation data.)
        Revoking a detected, bogus certificate might be the be=
st strategy
        for the malicious CA that logged the certificate; it makes
        issuance of the bogus certificate appear to be an accident, and
        thus a browser vendor might not feel the need to make an entry
        on its blacklists for the bogus certificate or
        for the CA that issued it. (If
        the bogus certificate included an AIA extension providing
        information for revocation status checking, revocation by the CA
        that logged the bogus certificate would not be an effective
        strategy for these colluding CAs. However, inclusion of this
        extension is not mandated by RFC 5280. Also the extension is not
        critical, meaning that relying parties are not required to be
        able to process it.)

    
=C2=A0

    
 If the CA that logged the
                bogus certificate fails to revoke it, browser vendors
                might blacklist the certificate. However, as noted
                above, the doppelganger, which was not logged, will
                match the SCT created for the logged certificate. If
                remediation is effected by blacklisting (instead of
                revocation by one of the malicious CAs) then the ability
                of CT to deal with this sort of attack may be
                diminished.
=


Once more, this problem is not CT's pr=
oblem - it is a problem with RFC 5280 et al. That is, the problem exists re=
gardless of the existence or use of CT.

Does this =
mean 5280 should be updated?
=C2=A0
 Some forms of blacklisting will cause the
                not-logged bogus certificate to be detected and
                rejected, while others will not, depending on the
                details of the blacklisting mechanism. Mechanisms for
                blacklisting by browsers are not specified in any IETF
                standards. The mechanisms are browser-specific, and the
                choice of how to blacklist (e.g., the bogus certificate
                vs. the CA that issued it) are the purview of each
                browser vendor. Thus, depending on the details of the
                blacklist mechanism and the way that a browser vendor
                chooses to manage this list, a doppelganger CA attack
                might or might not pose a problem in terms of successful
                remediation of the attack.
    

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



_______________________________________________

Trans mailing list

Trans@ietf.org

https://www.ietf.org/mailman/listinfo/trans





--089e0118482ce4a3fc052f2e86b4--


From nobody Tue Mar 29 04:52:48 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BCE12D1C0 for ; Tue, 29 Mar 2016 04:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPH9YgrFP8FN for ; Tue, 29 Mar 2016 04:52:43 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 0922C12D0EC for ; Tue, 29 Mar 2016 04:52:43 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id e3so18343967ioa.1 for ; Tue, 29 Mar 2016 04:52:43 -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; bh=SIFRnZIKNEu9c1wTDNhjmE95/eFblNxzvZHFtj8k+0s=; b=kK63pww5cFUHIiM0mP4be/Ajnw4tcKk17sXrqEJw6B4Y2uLacrKvZOvwcQ9gjNABL3 G4tSBtdl/O/qIPUB1b58UsUliwnwXITDaSItTLOcaehIhv30oPzB5cjfu8KY2A3hnePu nub5dUsYAgob/m4OqQPXU/e63z25XIqUidC7APPAra9JIaijr149VTJ8zHda3qt28OaN 0Rr6lZzeJLrFJ4CGXxw0ZSKSUkO9dJujv7oSxFWhdy1glriMrscuddZNOKcLiCht+ZoH ePqxhtigSPaFXf1aCaDt5yt0wtK/cFuS6HrX9P5OLZnnviOKG2mNuqEV5OmabzFw/1ue bylw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SIFRnZIKNEu9c1wTDNhjmE95/eFblNxzvZHFtj8k+0s=; b=DlBfAZtTdpw9BMfv1g0iVKaeWKBVvvgW1UXnBqNTEOtXWnQCE6ho2JGq5zAcLkQcxV fvXhz22LeBqp+0viSeVcSX4qiN9jtwcU2GFaOjO5viOHC6oUj8gHkZr9eAnbAvcu8t6D LJqCsBamGw4ag9JsbUW/ctLWut68lMHhfkIO1J2o92WCD29XCzjqKZ/Eb9KD3v5LIpak 6Qc92WCODaR1UNKeZ2BQxI1c5XKaBzZjtnhjJIqgtoqvWV+t06LNcNeFZdDYEW/bzfT+ P0XSRGQ+nwWLBwLoaF6rdnBJAAPcH/8ARQgu9cFY9RhcGXX7Te/sdXo2dq5Sjx3fw9Hs z/Xg==
X-Gm-Message-State: AD7BkJJrGZ8CU2FPNklGnHEgr81QRax7G3DFWhdMhzEWtDEYAFogAN8lDDHx2Teqbz/MtL6ToNL+YtfSv2IL+p3S
MIME-Version: 1.0
X-Received: by 10.107.41.133 with SMTP id p127mr2533617iop.172.1459252362055;  Tue, 29 Mar 2016 04:52:42 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Tue, 29 Mar 2016 04:52:41 -0700 (PDT)
In-Reply-To: <56F54EE2.1000008@bbn.com>
References: <56F4039B.2020604@bbn.com>  <56F54EE2.1000008@bbn.com>
Date: Tue, 29 Mar 2016 12:52:41 +0100
Message-ID: 
From: Ben Laurie 
To: Stephen Kent 
Content-Type: multipart/alternative; boundary=001a1137b81cae1b77052f2eaa45
Archived-At: 
Cc: Paul Wouters , "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2016 11:52:47 -0000

--001a1137b81cae1b77052f2eaa45
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 25 March 2016 at 14:44, Stephen Kent  wrote:

> As I noted above, there is no requirement (in 5280 or in CABF profiles)
> that a cert
> contain an AIA extension.
>

This appears to be incorrect. Section 7.1.3.2c of
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.3.pdf says:

"c. authorityInformationAccess

With the exception of stapling, which is noted below, this extension MUST
be present. It MUST NOT be marked critical, and it MUST contain the HTTP
URL of the Issuing CA=E2=80=99s OCSP responder (accessMethod =3D 1.3.6.1.5.=
5.7.48.1).
It SHOULD also contain the HTTP URL of the Issuing CA=E2=80=99s certificate
(accessMethod =3D 1.3.6.1.5.5.7.48.2). . The HTTP URL of the Issuing CA=E2=
=80=99s
OCSP responder MAY be omitted provided that the Subscriber =E2=80=9Cstaples=
=E2=80=9D OCSP
responses for the Certificate in its TLS handshakes [RFC4366]."

--001a1137b81cae1b77052f2eaa45
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On 25 March 2016 at 14:44, Stephen Kent <kent@bbn.com> wrote:
=

As I=
 noted above, there is no requirement (in 5280 or in CABF profiles) that a =
cert

contain an AIA extension.

This appears to be in=
correct. Section 7.1.3.2c of=C2=A0https://cabforum.org/wp-content/up=
loads/CA-Browser-Forum-BR-1.3.3.pdf says:

"c. authorityInformationAccess=


With	=
the	exception	of	stapling,	which	is	noted	below,	this	extension	MUST	be	pre=
sent.		It	MUST	NOT	be=09
marked	critical,	and	it	MUST	contain	the	HTTP	URL	of	the	Issuing	CA=E2=80=
=99s	OCSP	responder	(accessMethod	=3D=09
1.3.6.1.5.5.7.48.1).		It	SHOULD	also	contain	the	HTTP	URL	of	the	Issuing	CA=
=E2=80=99s	certificate	(accessMethod	=3D=09
1.3.6.1.5.5.7.48.2).		.=09
The	HTTP	URL	of	the	Issuing	CA=E2=80=99s	OCSP	responder	MAY	be	omitted	prov=
ided	that	the	Subscriber	=E2=80=9Cstaples=E2=80=9D=09
OCSP	responses	for	the	Certificate	in	its	TLS	handshakes	[RFC4366]."

=C2=A0


--001a1137b81cae1b77052f2eaa45--


From nobody Tue Mar 29 10:46:04 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC07E12D970 for ; Tue, 29 Mar 2016 08:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdp4PStaJ7x1 for ; Tue, 29 Mar 2016 08:46:50 -0700 (PDT)
Received: from mail-pa0-x239.google.com (mail-pa0-x239.google.com [IPv6:2607:f8b0:400e:c03::239]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C05F12D963 for ; Tue, 29 Mar 2016 08:46:23 -0700 (PDT)
Received: by mail-pa0-x239.google.com with SMTP id hn5so1496624pac.1 for ; Tue, 29 Mar 2016 08:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=XHkmu8ndeLTtpqOpPsgpQUkzBvDnUV+SUlhPcVloUTg=; b=tgcntqEIcIQVD8tZ/nM9DUNgs6aMib2mnFeKKWzaaQtYOWP204NwbaSx98vvHSoZPZ wrN0FK5HLbryR/rCA7rrUKwwPdHdTgV5BH3MCo1toT6chL7HYUMPyMXO6WAftzjwkaLO EFwgOH9QhPkVsSP7y7gIiY2lzs4buzxRwfVpJT9JvT0zcs2AT0N9ZijJRs9koidKXyq/ XA4IpYrngK4Gzdq9H5P3qbC+ayU4Tb1nkH3m4hAzXWaLnjCcB3m4qoA09Rsd7l9fEcm+ Fa12nlAecJHA5ojUAayeuLQZaYGp7jq003ngc1fuW6n0P24c5xseB5RBvo1q9stfgYsF NvqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=XHkmu8ndeLTtpqOpPsgpQUkzBvDnUV+SUlhPcVloUTg=; b=dAHV6zjNoXEdupQGy0+v4Ta+ips/FIaMC5J0xkLxMCs3RumMhlVU3SWegIEHjv+UZG uSfnu+f39322aqSiCz4ZwGBlbHeooBl7llKg80ZSwJmrckOR8EKUWtqpHg0grBf2zCwi d3AYMvXRros9d9hMYjmhIKxsT4+iimyHqBBdsfv4FNLJ13iqpXAO+fLDYjXqszV+2CYT 7ySMV3sNvDz38kchcCW8T8tkpMN6rFba8Z76BrSOub3n/yAUuJyBeEl68zC9oiRPMM7b H/FTDxNT/H8D8elo2mw3HBhBNSXlMTZWUlaeYbIjTKeXPoi5z5PRC0Afyrt/1v1N30P8 27sw==
X-Gm-Message-State: AD7BkJKGqBxQf/nxjIY3Hr9sBNoNubjsWBcx7ZXUZsFF4biUd5ALvo9n5XX4lrT+/GgxHpSSoY97
X-Received: by 10.182.24.67 with SMTP id s3mr31929obf.12.1459266383015; Tue, 29 Mar 2016 08:46:23 -0700 (PDT)
X-Google-Already-Archived: Yes
X-Google-Already-Archived-Group-Id: c29adbd6b4
X-Google-Doc-Id: 7a576878fc4f8
X-Google-Thread-Id: 8296d3128f373182
X-Google-Message-Url: http://groups.google.com/group/certificate-transparency/msg/7a576878fc4f8
X-Google-Thread-Url: http://groups.google.com/group/certificate-transparency/t/8296d3128f373182
X-Google-Web-Client: true
Date: Tue, 29 Mar 2016 08:46:22 -0700 (PDT)
From: Yusuke OSUMI 
To: certificate-transparency 
Message-Id: <75fa48e8-f8cd-405b-91c0-ac02e82c1eba@googlegroups.com>
In-Reply-To: 
References:     <52019c48-1997-4035-bc44-35e0e649e410@googlegroups.com> 
MIME-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_2513_811341150.1459266382292"
X-Google-Token: EM7G6rcFk7Jms99_bxk0
X-Google-IP: 1.115.198.61
Archived-At: 
X-Mailman-Approved-At: Tue, 29 Mar 2016 10:46:02 -0700
Cc: trans@ietf.org
Subject: Re: [Trans] Why "Poison Extension" disappeared in rfc6962-bis?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2016 15:46:54 -0000

------=_Part_2513_811341150.1459266382292
Content-Type: multipart/alternative; 
	boundary="----=_Part_2514_2051398092.1459266382292"

------=_Part_2514_2051398092.1459266382292
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ben,

Thanks, I got it!


On Tuesday, March 29, 2016 at 8:38:11 PM UTC+9, Ben Laurie wrote:
>
>
>
> On 28 March 2016 at 16:24, Yusuke OSUMI >=
=20
> wrote:
>
>> Ben,
>>
>> Oh, I misunderstanding little bit...
>> To confirm my understanding, can I summary precertificate in rfc6962-bis=
=20
>> below?
>>
>> * Precertificate and issued certificate has the same serial number.
>>  =3D> In this context, "serial number of precertificate" means the seria=
l=20
>> number of tbscertificate in precertificate.
>>
>
> Correct.
> =20
>
>>
>> * Old problem(RFC6962) is "There are two X.509 certificates with the sam=
e=20
>> serial number".
>> Now on rfc6962-bis, there are still two certificates with the same seria=
l=20
>> number. But one is encoded using X.509(to use for services), and another=
 is=20
>> encoded using CMS(precertificate).
>>
>
> Well, that means the second one is not a certificate.
> =20
>
>>
>> * We don't regard precertificate as 'Certificate', because it is just a=
=20
>> Cryptographic Message (based on RFC5652).
>>
>
> Exactly.
> =20
>
>>
>> Thanks,
>>
>>
>> On Monday, March 28, 2016 at 3:18:50 AM UTC+9, Ben Laurie wrote:
>>
>>>
>>>
>>> On 27 March 2016 at 08:32, Yusuke OSUMI  wrote:
>>>
>>>> Eran,
>>>>
>>>> Thanks, I get the picture!
>>>> I also think "precertificate and issued certificate have the same=20
>>>> serial number" is weird and strange, so this change is welcome.
>>>>
>>>
>>> Note that the precertificate still has the same serial number as the=20
>>> certificate. Its just that it is not a certificate anymore.
>>> =20
>>>
>>>>
>>>>
>>>> 2016=E5=B9=B43=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=E6=97=A5 6=E6=99=
=8258=E5=88=8601=E7=A7=92 UTC+9 Eran Messeri:
>>>>>
>>>>> [+trans mailing list]
>>>>> The poison extension was removed because it is no longer necessary -=
=20
>>>>> the purpose was to allow creating a pre-certificate in the form of an=
=20
>>>>> unusable X.509 certificate (the poison extension is a critical extens=
ion=20
>>>>> that made an otherwise valid X.509 certificate unusable).
>>>>>
>>>>> In 6962-bis the pre-certificate is encoded using Cryptographic Messag=
e=20
>>>>> Syntax (CMS), not X.509 certificates, so the poison extension is no l=
onger=20
>>>>> needed.
>>>>>
>>>>> One reason for the precertificate format transition I recall is=20
>>>>> concerns that issuing two X.509 certificates with the same serial num=
ber=20
>>>>> (even though one of them is unusable) is against the CA/Browsers foru=
m=20
>>>>> Baseline Requirements.=20
>>>>> The related discussions can be found in the trans mailing list:=20
>>>>> https://www.ietf.org/mailman/listinfo/trans
>>>>>
>>>>> Hope this helps,
>>>>> Eran
>>>>>
>>>>> On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI =20
>>>>> wrote:
>>>>>
>>>>>> Hi,=20
>>>>>>
>>>>>> I read rfc6962-bis, and found that description of "Poison Extension=
=20
>>>>>> (OID 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
>>>>>> I want to view a discussion about this issue(and want to know the=20
>>>>>> reason why it disappeard), so can I get URLs about the discussion?
>>>>>>
>>>>>> Thanks,
>>>>>> Yusuke
>>>>>>
>>>>>> --=20
>>>>>> You received this message because you are subscribed to the Google=
=20
>>>>>> Groups "certificate-transparency" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,=20
>>>>>> send an email to=20
>>>>>> certificate-transparency+unsubscribe@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "certificate-transparency" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to certificate-transparency+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "certificate-transparency" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to certificate-transparency+unsubscribe@googlegroups.com=20
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
------=_Part_2514_2051398092.1459266382292
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ben,

Thanks, I got it!

On Tuesday, March 29, 2016 at 8:38:11 PM UTC+9, Ben Laurie wrote:


On 28 March 2016 at 16:24, Yusuke OSUMI <ozum...@gmail.com> wrote:
=

Ben,

Oh, I misunderstanding =
little bit...
To confirm my understanding, can I summary precerti=
ficate in rfc6962-bis below?

* Precertificate and =
issued certificate has the same serial number.
=C2=A0=3D> In t=
his context, "serial number of precertificate" means the serial n=
umber of tbscertificate in precertificate.
Correct.
=C2=A0
<=
div dir=3D"ltr">

* Old problem(RFC6962) is "There a=
re two X.509 certificates with the same serial number".
Now =
on rfc6962-bis, there are still two certificates with the same serial numbe=
r. But one is encoded using X.509(to use for services), and another is enco=
ded using CMS(precertificate).

=
Well, that means the second one is not a certificate.
=C2=A0

* We d=
on't regard precertificate as 'Certificate', because it is just=
 a Cryptographic Message (based on RFC5652).
<=
br>
Exactly.
=C2=A0

Thanks,


On Mo=
nday, March 28, 2016 at 3:18:50 AM UTC+9, Ben Laurie wrote:


On 27 March 2016 at 08:32, Yusuke OSUMI =
<ozum...@gmail.com> wrote:
Eran,

Thanks, I get the pict=
ure!
I also think "precertificate and issued certificate have the s=
ame serial number" is weird and strange, so this change is welcome.

Note that the precertificate still =
has the same serial number as the certificate. Its just that it is not a ce=
rtificate anymore.
=C2=A0


2016=E5=B9=B43=E6=9C=8827=E6=97=A5=E6=97=A5=E6=9B=9C=
=E6=97=A5 6=E6=99=8258=E5=88=8601=E7=A7=92 UTC+9 Eran Messeri:
[+trans mailing list]The poison extension was removed because it is no longer necessary - the p=
urpose was to allow creating a pre-certificate in the form of an unusable X=
.509 certificate (the poison extension is a critical extension that made an=
 otherwise valid X.509 certificate unusable).

In 6=
962-bis the pre-certificate is encoded using Cryptographic Message Syntax (=
CMS), not X.509 certificates, so the poison extension is no longer needed.<=
/div>

One reason for the precertificate format transitio=
n I recall is concerns that issuing two X.509 certificates with the same se=
rial number (even though one of them is unusable) is against the CA/Browser=
s forum Baseline Requirements.=C2=A0
The related discussions can =
be found in the trans mailing list:=C2=A0https://www.ietf.org/mailman/listinfo/trans

<=
/div>
Hope this helps,
Eran

=

On Sat, Mar 26, 2016 at 5:49 AM, Yusuke OSUMI <ozum...@gmail.com> wr=
ote:
Hi,=C2=A0

I read rfc6962-bis, and found that description of &quo=
t;Poison Extension (OID 1.3.6.1.4.1.11129.2.4.3)" has disappeared.
I want to view a discussion about this issue(and want to know the re=
ason why it disappeard), so can I get URLs about the discussion?
=

Thanks,
Yusuke
=







-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googl=
egroups.com.

For more options, visit https://groups.google.com=
/d/optout.










-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googl=
egroups.com.

For more options, visit https://groups.google.com=
/d/optout.










-- 

You received this message because you are subscribed to the Google Groups &=
quot;certificate-transparency" group.

To unsubscribe from this group and stop receiving emails from it, send an e=
mail to certificate-transparency+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/=
d/optout.





------=_Part_2514_2051398092.1459266382292--

------=_Part_2513_811341150.1459266382292--


From nobody Wed Mar 30 03:09:59 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3620E12D5BF for ; Wed, 30 Mar 2016 03:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUN7US1WktH3 for ; Wed, 30 Mar 2016 03:09: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 AD01612D5A4 for ; Wed, 30 Mar 2016 03:09:44 -0700 (PDT)
Received: from localhost ([::1]:59422 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1alD4I-0004VW-Lq; Wed, 30 Mar 2016 03:09: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: rob.stradling@comodo.com, eranm@google.com
X-Trac-Project: trans
Date: Wed, 30 Mar 2016 10:09:42 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/156#comment:7
Message-ID: <072.85fed289f76057c07f0d27efa5708acd@tools.ietf.org>
References: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-Trac-Ticket-ID: 156
In-Reply-To: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #156 (rfc6962-bis): Can inclusion proofs properly substitute SCTs?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 10:09:58 -0000

#156: Can inclusion proofs properly substitute SCTs?


Comment (by eranm@google.com):

 Out for review in https://github.com/google/certificate-transparency-
 rfcs/pull/148, based on Rob's changes and addressing Ben's review
 comments.

-- 
------------------------------+---------------------------------------
 Reporter:  eranm@google.com  |       Owner:  rob.stradling@comodo.com
     Type:  defect            |      Status:  new
 Priority:  critical          |   Milestone:
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |
------------------------------+---------------------------------------

Ticket URL: 
trans 


From nobody Wed Mar 30 07:24:48 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEEB12D1AB for ; Wed, 30 Mar 2016 07:24: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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4Ji2ZVqk_Ya for ; Wed, 30 Mar 2016 07:24:45 -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 167FA12D0A8 for ; Wed, 30 Mar 2016 07:24:45 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:35973 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alH34-000IWT-BW; Wed, 30 Mar 2016 10:24:42 -0400
From: Stephen Kent 
To: Ben Laurie 
References: <56F4039B.2020604@bbn.com>  <56F54EE2.1000008@bbn.com> 
Message-ID: <56FBE1AA.6090106@bbn.com>
Date: Wed, 30 Mar 2016 10:24:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010207060506070006030100"
Archived-At: 
Cc: Paul Wouters , "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 14:24:47 -0000

This is a multi-part message in MIME format.
--------------010207060506070006030100
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Ben,

Whoops, you're right. I missed the reference because I searched for AIA.

So, an EV or DV subscriber cert must contain this extension, although
5280 does not mandate it, and even though no browser is required to be
able to process it (since it's not CRITICAL).

I will revise the text for 3.3 to reflect this.

Steve

>
> On 25 March 2016 at 14:44, Stephen Kent  > wrote:
>
>     As I noted above, there is no requirement (in 5280 or in CABF
>     profiles) that a cert
>     contain an AIA extension.
>
>
> This appears to be incorrect. Section 7.1.3.2c of 
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.3.pdf 
> says:
>
> "c. authorityInformationAccess
>
> With the exception of stapling, which is noted below, this extension 
> MUST be present. It MUST NOT be marked critical, and it MUST contain 
> the HTTP URL of the Issuing CA’s OCSP responder (accessMethod = 
> 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the 
> Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). . The 
> HTTP URL of the Issuing CA’s OCSP responder MAY be omitted provided 
> that the Subscriber “staples” OCSP responses for the Certificate in 
> its TLS handshakes [RFC4366]."
>
>


--------------010207060506070006030100
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Ben,

    

    Whoops, you're right. I missed the reference because I searched for
    AIA.

    

    So, an EV or DV subscriber cert must contain this extension,
    although 

    5280 does not mandate it, and even though no browser is required to
    be

    able to process it (since it's not CRITICAL).

    

    I will revise the text for 3.3 to reflect this.

    

    Steve

    


    

    

      

        


          
On 25 March 2016 at 14:44, Stephen
            Kent <kent@bbn.com>
            wrote:

            

              
As I noted
                above, there is no requirement (in 5280 or in CABF
                profiles) that a cert

                contain an AIA extension.

            

          

          

          This appears to be incorrect. Section 7.1.3.2c of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.3.pdf
          says:

        


        

        
"c. authorityInformationAccess

        


        

        
With the exception of stapling, which
          is noted below, this extension MUST be present. It MUST NOT be
          marked critical, and it MUST contain the HTTP URL of the
          Issuing CA’s OCSP responder (accessMethod =
          1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of
          the Issuing CA’s certificate (accessMethod =
          1.3.6.1.5.5.7.48.2). . The HTTP URL of the Issuing CA’s OCSP
          responder MAY be omitted provided that the Subscriber
          “staples” OCSP responses for the Certificate in its TLS
          handshakes [RFC4366]."

        


        

         

      

    

    

  


--------------010207060506070006030100--


From nobody Wed Mar 30 07:25:07 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8499F12D135 for ; Wed, 30 Mar 2016 07:25:06 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMQdU3OedVqz for ; Wed, 30 Mar 2016 07:25:05 -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 42CAB12D1A3 for ; Wed, 30 Mar 2016 07:25:05 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:44385 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alH3Q-000Lzh-91 for trans@ietf.org; Wed, 30 Mar 2016 10:25:04 -0400
From: Stephen Kent 
To: trans@ietf.org
References: <56F4039B.2020604@bbn.com>  <56F54EE2.1000008@bbn.com>  <56F93D9D.2070704@bbn.com> 
Message-ID: <56FBE1C0.2000200@bbn.com>
Date: Wed, 30 Mar 2016 10:25:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 14:25:06 -0000

Paul,
> On Mon, 28 Mar 2016, Stephen Kent wrote:
>
> 
>
>> I can't agree with your conclusion if it's based on the analysis above,
>> but I also can't predict how long such an attack might go undetected 
>> given
>> the many variables involved.
>
> So there seems to be no consensus about the colluding CA's scenario,
> and thus no consensus on the text that needs to go into the threat
> document. 
> A few people think your text needs changes. 
A "few people" also think there need to be changes to 6269-bis :-).
> It also seems
> to be the only issue left for WGLC.
I also posted proposed text (3.4) to address the concerns raised by 
Bryan Ford.
I've received no feedback on that text yet.
> Do you have an idea on how to change the text to accomodate the feedback
> received on the list? 
I will make changes to accommodate feedback that is accurate and rational.
I believe I have been making changes much faster than the authors of 
6269-bis,
over the past 18-24 months.
> Should we ask someone else to help you with
> this section? Perhaps dkg could help, since he originally came up with
> the attack?
I welcome contributions from DKG.

Steve


From nobody Wed Mar 30 07:25:23 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E025E12D0A8 for ; Wed, 30 Mar 2016 07:25:20 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2J8R_IjAU38 for ; Wed, 30 Mar 2016 07:25:19 -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 D260A12D70C for ; Wed, 30 Mar 2016 07:25:10 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:35976 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alH3V-000IWj-UU; Wed, 30 Mar 2016 10:25:10 -0400
From: Stephen Kent 
To: Ben Laurie 
References: <56F4039B.2020604@bbn.com> 
Message-ID: <56FBE1C5.1080301@bbn.com>
Date: Wed, 30 Mar 2016 10:25:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040109010603050403040505"
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 14:25:21 -0000

This is a multi-part message in MIME format.
--------------040109010603050403040505
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Ben,


> ...
>
>     If the CA that logged the bogus certificate fails to revoke it,
>     browser vendors might blacklist the certificate. However, as noted
>     above, the doppelganger, which was not logged, will match the SCT
>     created for the logged certificate. If remediation is effected by
>     blacklisting (instead of revocation by one of the malicious CAs)
>     then the ability of CT to deal with this sort of attack may be
>     diminished.
>
>
> Once more, this problem is not CT's problem - it is a problem with RFC 
> 5280 et al. That is, the problem exists regardless of the existence or 
> use of CT.
I assume we agree that the issue is not whether inclusion of the AIA 
extension in all EE certs
should be a MUST in 5280, right? Is your point that no standard 
specifies in detail how to manage
revocation status data? If so, then this lack of detail applies not only 
to CRLs and OCSP but
also to browser blacklists, so it's not just a 5280 issue.

In any case, the discussion is an analysis of attacks in the context of 
CT, so to that
extent it is a CT issue.

> Does this mean 5280 should be updated?
I think not. As I noted in prior messages, 5820 is the general PKI spec 
for Internet use of X.509 certs.
There is not always a need to mandate inclusion of AIA, hence it's 
optional. It's appropriate to
profile 5280 for specific application contexts, like the Web PKI. There 
was an IETF WG that was
trying to characterize that context (WPKOPS) but it failed.

Steve

--------------040109010603050403040505
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ben,

    

    


    

    

      
...

        

          

            

              

                
 If


                            the CA that logged the bogus certificate
                            fails to revoke it, browser vendors might
                            blacklist the certificate. However, as noted
                            above, the doppelganger, which was not
                            logged, will match the SCT created for the
                            logged certificate. If remediation is
                            effected by blacklisting (instead of
                            revocation by one of the malicious CAs) then
                            the ability of CT to deal with this sort of
                            attack may be diminished.

              

            

            


            

            
Once more, this problem is not CT's problem - it is a
              problem with RFC 5280 et al. That is, the problem exists
              regardless of the existence or use of CT.

          

        

      

    

    I assume we agree that the issue is not whether inclusion of the AIA
    extension in all EE certs

    should be a MUST in 5280, right? Is your point that no standard
    specifies in detail how to manage 

    revocation status data? If so, then this lack of detail applies not
    only to CRLs and OCSP but

    also to browser blacklists, so it's not just a 5280 issue.

    

    In any case, the discussion is an analysis of attacks in the context
    of CT, so to that

    extent it is a CT issue.

    

    

      

        

          

            
Does this mean 5280 should be updated? 

          

        

      

    

    I think not. As I noted in prior messages, 5820 is the general PKI
    spec for Internet use of X.509 certs.

    There is not always a need to mandate inclusion of AIA, hence it's
    optional. It's appropriate to 

    profile 5280 for specific application contexts, like the Web PKI.
    There was an IETF WG that was

    trying to characterize that context (WPKOPS) but it failed. 

    

    Steve

  


--------------040109010603050403040505--


From nobody Wed Mar 30 07:52:07 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D619E12D580 for ; Wed, 30 Mar 2016 07:52:05 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp2lTcNLCy5u for ; Wed, 30 Mar 2016 07:52: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 55C2C12D107 for ; Wed, 30 Mar 2016 07:52:04 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:35977 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1alH3Z-000IWn-U5; Wed, 30 Mar 2016 10:25:14 -0400
From: Stephen Kent 
To: "David A. Cooper" , trans@ietf.org
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov>
Message-ID: <56FBE1C9.9020000@bbn.com>
Date: Wed, 30 Mar 2016 10:25:13 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56F57879.5060005@nist.gov>
Content-Type: multipart/alternative; boundary="------------040706050004090901000002"
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 14:52:06 -0000

This is a multi-part message in MIME format.
--------------040706050004090901000002
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

David,

I appreciate your persistence, but we will just have to agree to 
disagree on the
topic of whether 5280 requires global name uniqueness.

First, I cited text from Secyion 4.1.2.6, which is the one place in 5280 
where global
name uniqueness should be mandated if it were a requirement. That 
section establishes a
requirement for local (per-CA) name uniqueness, not for global name 
uniqueness. IMHO
that is the definitive statement on this topic.

RFC 5280, like its predecessors, has deviated from X.509 where we felt 
necessary. Your
argument that PKIX docs will maintain compatibility with X.509 is just 
an indication
of overall intent, not a promise to never deviate. You acknowledge this 
later when you
discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280, 
but not X.509."

Yes, the Security Considerations section of 5280 notes that problems 
that can arise if
names are not globally unique. However, that is not the same as saying 
that 5280 requires
them to be so. Rather it is a warning of the bad things that may happen 
if name collisions
occur. A warning in the Security Considerations section the way we 
usually note a residual
vulnerability in a standard. It is NOT a backdoor way to add a 
requirement to a standard.

Your other comments cite text that, in your opinion, suggests the need 
for global name
uniqueness, rather than citing text that establishes this requirement. 
Hence I'm not going
to spend time addressing those comments.

> Aside from the gratuitous parenthetical in your text falsely stating 
> that RFC 5280 "doe not preclude the creation of two CAs with the same 
> name, so long as the parent CAs are distinct," you still write about 
> two CAs issuing two EE certificates that are identical. If it walks 
> like a duck and it quacks like a duck, then chances are its a duck. In 
> the scenario you are trying to describe, there is one CA that issues 
> one EE certificate. 
One might argue that two entities acting as CAs that have the same name 
and same public
key are the same CA. But if the entities happen to be different 
organizations, perhaps
in different geopolitical regions, others might argue that they are 
different CAs.
> Can you name even one RP that maintains a cache of revocation status 
> info organized by cert path? 
BBN has implemented RP code for at least 4 products over the past 20 
years. Some were part
of PKI systems developed for clients in the financial services area. The 
most recent is
the RPSTIR code for the RPKI. All of them operate as I described.

I'll discuss whether my attack scenarios are accurate and match the 
spirit of DKGs original
message with him, not you.

Steve

--------------040706050004090901000002
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    David,

    

    
I appreciate your persistence, but we
      will just have to agree to disagree on the

      topic of whether 5280 requires global name uniqueness.

      

      First, I cited text from Secyion 4.1.2.6, which is the one place
      in 5280 where global 

      name uniqueness should be mandated if it were a requirement. That
      section establishes a 

      requirement for local (per-CA) name uniqueness, not for global
      name uniqueness. IMHO

      that is the definitive statement on this topic.

      

      RFC 5280, like its predecessors, has deviated from X.509 where we
      felt necessary. Your

      argument that PKIX docs will maintain compatibility with X.509 is
      just an indication

      of overall intent, not a promise to never deviate. You acknowledge
      this later when you 

      discuss CRL issuer paths and say ".. a requirement imposed by RFC
      5280, but not X.509."

      

      Yes, the Security Considerations section of 5280 notes that
      problems that can arise if

      names are not globally unique. However, that is not the same as
      saying that 5280 requires

      them to be so. Rather it is a warning of the bad things that may
      happen if name collisions

      occur. A warning in the Security Considerations section the way we
      usually note a residual 

      vulnerability in a standard. It is NOT a backdoor way to add a
      requirement to a standard.

      

      Your other comments cite text that, in your opinion, suggests the
      need for global name 

      uniqueness, rather than citing text that establishes this
      requirement. Hence I'm not going 

      to spend time addressing those comments.

      

    

    

      
      Aside from the gratuitous parenthetical in your text falsely
      stating that RFC 5280 "doe not preclude the creation of two CAs
      with the same name, so long as the parent CAs are distinct," you
      still write about two CAs issuing two EE certificates that are
      identical. If it walks like a duck and it quacks like a duck, then
      chances are its a duck. In the scenario you are trying to
      describe, there is one CA that issues one EE certificate. 

    One might argue that two entities acting as CAs that have the same
    name and same public

    key are the same CA. But if the entities happen to be different
    organizations, perhaps 

    in different geopolitical regions, others might argue that they are
    different CAs.

    
Can you
      name even one RP that maintains a cache of revocation status info
      organized by cert path? 

    BBN has implemented RP code for at least 4 products over the past 20
    years. Some were part

    of PKI systems developed for clients in the financial services area.
    The most recent is 

    the RPSTIR code for the RPKI. All of them operate as I described. 

    

    I'll discuss whether my attack scenarios are accurate and match the
    spirit of DKGs original 

    message with him, not you.

    

    Steve

  


--------------040706050004090901000002--


From nobody Wed Mar 30 08:34:00 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D910F12D795 for ; Wed, 30 Mar 2016 08:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level: 
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-IhZfDo8Enc for ; Wed, 30 Mar 2016 08:33:56 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0038712D7A9 for ; Wed, 30 Mar 2016 08:33:47 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 30 Mar 2016 11:35:08 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Wed, 30 Mar 2016 11:33:45 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2UFXbWE018273;	Wed, 30 Mar 2016 11:33:37 -0400
To: Paul Wouters , Melinda Shore 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com>
From: "David A. Cooper" 
Message-ID: <56FBF1D1.9030907@nist.gov>
Date: Wed, 30 Mar 2016 11:33:37 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56FBE1C9.9020000@bbn.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
Archived-At: 
Cc: trans@ietf.org, Stephen Farrell 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 15:33:59 -0000


  
    
  
  
    
On 03/30/2016 10:25 AM, Stephen Kent
      wrote:

    

    

      
      I'll discuss whether my attack scenarios are accurate and match
      the spirit of DKGs original 

      message with him, not you.

    

    

    Is it appropriate for a document editor to declare that he will
    ignore input from members of the working group?

    

  



From nobody Wed Mar 30 08:37:12 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2773E12D19F for ; Wed, 30 Mar 2016 08:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8m6nWgZH8Pn for ; Wed, 30 Mar 2016 08:37:10 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 92B7112D0B6 for ; Wed, 30 Mar 2016 08:37:10 -0700 (PDT)
Received: by mail-pa0-x233.google.com with SMTP id tt10so43780246pab.3 for ; Wed, 30 Mar 2016 08:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=gtul3kqNsqLDE1M3vmCY6jHkxITkr9LKk1ZQfggF+u8=; b=kTg6b/Xp97U9DM5eJ/BPxZ+WA9kkD1AHKLLpuHcw2aP+lxEty3DDTh0BT9PDbonjsz b5/vmJsEjP7NIPvDvn63jOp2DlGdhwHYlegQbBoalYAyhh/YVTM/L2XNHPUEDI+7rpsm PF2xAaEVhel5SDsVAuSF+FiiW4fk2Kp8c7zKwhYZ26GBYHOs33g08lLXotmQXBwXAO8O tj92TexWJ3CtSCXeqgA3SBKL/ZQRkwW2WTEtT5w0UwgDpHUqepuBnmAlyJ7cTkjoCy69 2e4zfPqsH1hc+KxKScUbW8H3r5VvVhOCEYvuKj+tsE60HnMD+qKfLIfnkoJiGsVzWqNV 48bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gtul3kqNsqLDE1M3vmCY6jHkxITkr9LKk1ZQfggF+u8=; b=MHQQT1JuSfhyhcfdeYR0lcY4tzl2Dmf3209mjpE1SAmNaWqzvtZ9YPChGLR03tQFmg tsE8COvfMeR1BfECZcFjo8uWRMY1k4geIuRlqH0e4qTYmIwNFWKOoH1yaQbxLW6a+eSz sc3C/Y+MrHjxhjRucJo3kb/h9TvV8XNnlUdzbkcJq9jP9/VgvV6rT5ObT2NW8JGPgREC O0gj54+OCaJ+420N90DL0Xi14KGmYSEEtAVI+EOElvJMoimWEzpT1hOdgcP7zpMO2fsT iCNRboJ9vk+diJ0roAsOzJrKt7JeD0Tv9XkirVGsZp5CdQb29DuHcoS6mhkkcg0bG0FV wPkw==
X-Gm-Message-State: AD7BkJKCGh7t6wHqmBZ+Mnih4cSvyRnCqBsriQN4pMQNxU396MzsIxGybdZZutgPrQMouQ==
X-Received: by 10.66.141.76 with SMTP id rm12mr14448611pab.30.1459352230214; Wed, 30 Mar 2016 08:37:10 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (209-112-213-121-radius.dynamic.acsalaska.net. [209.112.213.121]) by smtp.googlemail.com with ESMTPSA id ml5sm6905065pab.2.2016.03.30.08.37.08 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 08:37:09 -0700 (PDT)
To: trans@ietf.org
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com>
From: Melinda Shore 
Message-ID: <56FBF2B8.5040501@gmail.com>
Date: Wed, 30 Mar 2016 07:37:28 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56FBE1C9.9020000@bbn.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 15:37:12 -0000

On 3/30/16 6:25 AM, Stephen Kent wrote:
> I'll discuss whether my attack scenarios are accurate and match the
> spirit of DKGs original
> message with him, not you.

Just a friendly reminder that the draft is a working group
document, not an individual contribution.

Melinda


From nobody Wed Mar 30 08:38:21 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0B12D79F for ; Wed, 30 Mar 2016 08:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm03lXDlu7d5 for ; Wed, 30 Mar 2016 08:38:19 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3602C12D19F for ; Wed, 30 Mar 2016 08:38:19 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id 4so46076794pfd.0 for ; Wed, 30 Mar 2016 08:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=CTUHGGUG7kOdv4qHDkOR6GfHQ9h26iR3JSHOhqMkV70=; b=HCSmS38JELRvVV1QYEsmLVALMcCw6YCEJq8MNEFq9+PnyaAd78wtUQP20907qHPg91 Jj7G5kREfE74W0bKLbSIcIZmJRAy1dc7/9rVGyQr7HNFHx7RbuhZwJTlZJNzwqs9K8uY mUnRGmILTeE0YjDl/IZ3DcO8CoLHdgXMdwgURZktU4qmG54OnM5gn04BHjKYNa7cJXv4 A0Bdgq7FHp+0NdZVu4cFX9PYj+aEPpOZSVNP/IOEVoOPTPDisnKZhzc58ZbXiBKONP4M w+kSgNWYjtmnSW3dJ2lk8k+8vLS3DQNVy7L0f61PsUB4snHjKU3ZBuTLFIMp35tIhzH2 xQdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CTUHGGUG7kOdv4qHDkOR6GfHQ9h26iR3JSHOhqMkV70=; b=D5hqxHCajoTzqVWdLMsP8y0CodPWEkXB8WVGVtOd6y8hp9EcKxwqlnrLnpK+tqHL/9 8WECaJzDVQIRuIPnn2fIJTnds7wltS9KY6cLr0DaN+w+7PAz0UJ4Q7WvHxghocHE4eTC oGFfH+he1x/AsxENLecCPH0MWoxxdRups36egZRK/YBYxe8psNTMUDHdey4dqv7LwHKu zEHA5/1VPrxX4Zti2Wbye1ywdluJ/KxY1G82gBwB1hLKFVlIdA91Ue5rrkQUqcoIY8Eg TDrJ3daq8dWWZ4rpzoY5Et4caZ55bDqV5KL5T7fp0XYY4Y32NrXn+dB3nx5Lo7jxC0gD WPHQ==
X-Gm-Message-State: AD7BkJK2WDbhX5PVe7aaf/1fAaWGbv/W9Om/SXfEc7b67wT5ZM6q8/gtcDSNE0nIsFhAZg==
X-Received: by 10.98.14.147 with SMTP id 19mr14226047pfo.79.1459352298824; Wed, 30 Mar 2016 08:38:18 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (209-112-213-121-radius.dynamic.acsalaska.net. [209.112.213.121]) by smtp.googlemail.com with ESMTPSA id dy6sm6833430pab.48.2016.03.30.08.38.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 08:38:18 -0700 (PDT)
To: "David A. Cooper" , Paul Wouters 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF1D1.9030907@nist.gov>
From: Melinda Shore 
Message-ID: <56FBF302.8090606@gmail.com>
Date: Wed, 30 Mar 2016 07:38:42 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56FBF1D1.9030907@nist.gov>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: trans@ietf.org, Stephen Farrell 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 15:38:21 -0000

On 3/30/16 7:33 AM, David A. Cooper wrote:
> Is it appropriate for a document editor to declare that he will ignore
> input from members of the working group?

Of course not.

Melinda



From nobody Wed Mar 30 09:02:43 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6821712D5E2 for ; Wed, 30 Mar 2016 09:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level: 
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLj9EDVt7-36 for ; Wed, 30 Mar 2016 09:02:38 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF1312D161 for ; Wed, 30 Mar 2016 09:02:37 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 30 Mar 2016 12:02:18 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Wed, 30 Mar 2016 12:02:35 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2UG2NQ7020492;	Wed, 30 Mar 2016 12:02:23 -0400
To: Stephen Kent 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com>
From: "David A. Cooper" 
Message-ID: <56FBF88F.2050407@nist.gov>
Date: Wed, 30 Mar 2016 12:02:23 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56FBE1C9.9020000@bbn.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 16:02:41 -0000


  
    
  
  
    
So, your contention is that PKIX
      diverged from X.509 by removing the requirement for names to be
      unambiguous, and did nothing to address the vulnerability created
      by this divergence other than noting the vulnerability in the
      Security Considerations sections of its documents? The working
      group then went on to develop protocols and profiles that relied
      on names being unambiguous, and then just noted in the Security
      Considerations that an unnecessary vulnerability had been created?
      I have even looked for evidence that the PKIX WG discussed the
      idea of deviating from X.509 and allowing names to be ambiguous
      (i.e., unrelated entities operating under the same name) and have
      been unable to find any evidence of that on the mail list. I have,
      however, heard an explanation for why the text in Section 4.1.2.6
      says what it does, and it was not about a deliberate decision to
      deviate from X.509.

      

      The proposed text for Section 3.3 seems to be written with the
      goal of advancing your personal belief about what RFC 5280 does or
      does not require rather than trying to explain a potential attack
      in the clearest way possible. Removing the parenthetical about RFC
      5280 and simply referring to the intermediate CA and EE as the
      single entities that they are would go a long way towards
      improving the text.

      

      On 03/30/2016 10:25 AM, Stephen Kent wrote:

    

    

      
      David,

      

      
I appreciate your persistence, but we
        will just have to agree to disagree on the

        topic of whether 5280 requires global name uniqueness.

        

        First, I cited text from Secyion 4.1.2.6, which is the one place
        in 5280 where global 

        name uniqueness should be mandated if it were a requirement.
        That section establishes a 

        requirement for local (per-CA) name uniqueness, not for global
        name uniqueness. IMHO

        that is the definitive statement on this topic.

        

        RFC 5280, like its predecessors, has deviated from X.509 where
        we felt necessary. Your

        argument that PKIX docs will maintain compatibility with X.509
        is just an indication

        of overall intent, not a promise to never deviate. You
        acknowledge this later when you 

        discuss CRL issuer paths and say ".. a requirement imposed by
        RFC 5280, but not X.509."

        

        Yes, the Security Considerations section of 5280 notes that
        problems that can arise if

        names are not globally unique. However, that is not the same as
        saying that 5280 requires

        them to be so. Rather it is a warning of the bad things that may
        happen if name collisions

        occur. A warning in the Security Considerations section the way
        we usually note a residual 

        vulnerability in a standard. It is NOT a backdoor way to add a
        requirement to a standard.

        

        Your other comments cite text that, in your opinion, suggests
        the need for global name 

        uniqueness, rather than citing text that establishes this
        requirement. Hence I'm not going 

        to spend time addressing those comments.

        

      

      

        Aside from the gratuitous parenthetical in your text falsely
        stating that RFC 5280 "doe not preclude the creation of two CAs
        with the same name, so long as the parent CAs are distinct," you
        still write about two CAs issuing two EE certificates that are
        identical. If it walks like a duck and it quacks like a duck,
        then chances are its a duck. In the scenario you are trying to
        describe, there is one CA that issues one EE certificate. 

      One might argue that two entities acting as CAs that have the same
      name and same public

      key are the same CA. But if the entities happen to be different
      organizations, perhaps 

      in different geopolitical regions, others might argue that they
      are different CAs.

      
Can
        you name even one RP that maintains a cache of revocation status
        info organized by cert path? 

      BBN has implemented RP code for at least 4 products over the past
      20 years. Some were part

      of PKI systems developed for clients in the financial services
      area. The most recent is 

      the RPSTIR code for the RPKI. All of them operate as I described.
      

      

      I'll discuss whether my attack scenarios are accurate and match
      the spirit of DKGs original 

      message with him, not you.

      

      Steve

    

    

  



From nobody Wed Mar 30 09:09:48 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8231212D78B for ; Wed, 30 Mar 2016 09:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a8NcUcseJbt for ; Wed, 30 Mar 2016 09:09:45 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0: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 2FD3C12D19F for ; Wed, 30 Mar 2016 09:09:45 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id z68so67344081vkg.3 for ; Wed, 30 Mar 2016 09:09:45 -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; bh=ew1Nou3P9ZGpdkkVetLrZLMN0D6DitFdnPjXvJkA4vo=; b=vQCgmYLbzKr16NOKBbf8b3r8IiuwXxhbGOF+Ovhoof2ek583P0w/P8n2lSq9hwtosf /0THBDHhVlCLVue1Y+lIe2Ylcro/kmqU/92YdgjqJCIex6Yd5boq2eBHolNIEuEBoFOK TTOssOp9kJ1G3x3c7od84x8aL/e0UKUdArMs5tdLVXLm6OdJVsgJqg/7YihUse4WAbwe qOkaFlKnW9P/SmNcvalghjWwXbau9rhRPguaVc/KQ1wuqJDKD7pjsMxXJrbzd+BPs609 TQ98mlp3yudQ46gfnicU1jlZ7TM44hfA2H2NrR2ii7A/3uiGmXa+sS8YbeNoQiCky9Wt Cu7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ew1Nou3P9ZGpdkkVetLrZLMN0D6DitFdnPjXvJkA4vo=; b=YDFUPouxzsEUe4BpSg0UYBmx9OHxJ1fa0E9TVg1OWn0+KSKsIxmOkey9osIFxRph/G NOqwxV331ti2gv97q2EOHGxXBMVpU5c4tfnzwywgdxFrBMphJ/FouncprvCIf+oplmRS eG1NzAZg6T2pGADyK8XjmXEWgcMDhndtUxFsY8TnZaCnH2ZzoMTUfFR7xkE9tA7LtW/c EbK2ckOBIDox4ogXJfXvxs1PdCV55ScI4W0pZ2wIkDusdz5rK7fahs2PdHNAhgdFSFU9 FQnFeVyMbCFMa6fzTRTY4yRRia9e9GJZzjlNZLVe85hf5zNfaAB7DrX9HPLGFEuTYqMp xcRQ==
X-Gm-Message-State: AD7BkJJhXRFFC0AbuYg+nLFq+ORsuB0LeWuTTs6r0YfozhX/6l0jalGQG8BhPFYHGrICKUJU4dXvoHmtPYI9oQ==
MIME-Version: 1.0
X-Received: by 10.176.1.109 with SMTP id 100mr5683851uak.90.1459354184093; Wed, 30 Mar 2016 09:09:44 -0700 (PDT)
Received: by 10.176.1.208 with HTTP; Wed, 30 Mar 2016 09:09:43 -0700 (PDT)
In-Reply-To: <56FBF88F.2050407@nist.gov>
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>
Date: Wed, 30 Mar 2016 09:09:43 -0700
Message-ID: 
From: Watson Ladd 
To: "David A. Cooper" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 16:09:47 -0000

On Wed, Mar 30, 2016 at 9:02 AM, David A. Cooper  wrote:
> So, your contention is that PKIX diverged from X.509 by removing the
> requirement for names to be unambiguous, and did nothing to address the
> vulnerability created by this divergence other than noting the vulnerability
> in the Security Considerations sections of its documents? The working group
> then went on to develop protocols and profiles that relied on names being
> unambiguous, and then just noted in the Security Considerations that an
> unnecessary vulnerability had been created? I have even looked for evidence
> that the PKIX WG discussed the idea of deviating from X.509 and allowing
> names to be ambiguous (i.e., unrelated entities operating under the same
> name) and have been unable to find any evidence of that on the mail list. I
> have, however, heard an explanation for why the text in Section 4.1.2.6 says
> what it does, and it was not about a deliberate decision to deviate from
> X.509.

What "vulnerability" is created? The reason DKG's attack functions is
CT records the end entity certificate,

In the attack model the conspiring CAs can just ignore the requirement
on name validity. I don't see why X509 protects against this more.

>
> The proposed text for Section 3.3 seems to be written with the goal of
> advancing your personal belief about what RFC 5280 does or does not require
> rather than trying to explain a potential attack in the clearest way
> possible. Removing the parenthetical about RFC 5280 and simply referring to
> the intermediate CA and EE as the single entities that they are would go a
> long way towards improving the text.

Define "entity". End of the day there are only bits: the question is
how implementations will behave when given two bitstrings concocted in
the way described by DKG. Disputes over the metaphysics are really
in(trans)substantial.

>
>
> On 03/30/2016 10:25 AM, Stephen Kent wrote:
>
> David,
>
> I appreciate your persistence, but we will just have to agree to disagree on
> the
> topic of whether 5280 requires global name uniqueness.
>
> First, I cited text from Secyion 4.1.2.6, which is the one place in 5280
> where global
> name uniqueness should be mandated if it were a requirement. That section
> establishes a
> requirement for local (per-CA) name uniqueness, not for global name
> uniqueness. IMHO
> that is the definitive statement on this topic.
>
> RFC 5280, like its predecessors, has deviated from X.509 where we felt
> necessary. Your
> argument that PKIX docs will maintain compatibility with X.509 is just an
> indication
> of overall intent, not a promise to never deviate. You acknowledge this
> later when you
> discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280, but
> not X.509."
>
> Yes, the Security Considerations section of 5280 notes that problems that
> can arise if
> names are not globally unique. However, that is not the same as saying that
> 5280 requires
> them to be so. Rather it is a warning of the bad things that may happen if
> name collisions
> occur. A warning in the Security Considerations section the way we usually
> note a residual
> vulnerability in a standard. It is NOT a backdoor way to add a requirement
> to a standard.
>
> Your other comments cite text that, in your opinion, suggests the need for
> global name
> uniqueness, rather than citing text that establishes this requirement. Hence
> I'm not going
> to spend time addressing those comments.
>
> Aside from the gratuitous parenthetical in your text falsely stating that
> RFC 5280 "doe not preclude the creation of two CAs with the same name, so
> long as the parent CAs are distinct," you still write about two CAs issuing
> two EE certificates that are identical. If it walks like a duck and it
> quacks like a duck, then chances are its a duck. In the scenario you are
> trying to describe, there is one CA that issues one EE certificate.
>
> One might argue that two entities acting as CAs that have the same name and
> same public
> key are the same CA. But if the entities happen to be different
> organizations, perhaps
> in different geopolitical regions, others might argue that they are
> different CAs.
>
> Can you name even one RP that maintains a cache of revocation status info
> organized by cert path?
>
> BBN has implemented RP code for at least 4 products over the past 20 years.
> Some were part
> of PKI systems developed for clients in the financial services area. The
> most recent is
> the RPSTIR code for the RPKI. All of them operate as I described.
>
> I'll discuss whether my attack scenarios are accurate and match the spirit
> of DKGs original
> message with him, not you.
>
> Steve
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.


From nobody Wed Mar 30 10:04:51 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D133012D6E1 for ; Wed, 30 Mar 2016 10:04:50 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4v_bBVCCVDs for ; Wed, 30 Mar 2016 10:04:48 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9F312D5AF for ; Wed, 30 Mar 2016 10:04:47 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 30 Mar 2016 13:04:29 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Wed, 30 Mar 2016 13:04:46 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2UH4WNa024678;	Wed, 30 Mar 2016 13:04:32 -0400
To: Watson Ladd 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov> 
From: "David A. Cooper" 
Message-ID: <56FC0720.5090204@nist.gov>
Date: Wed, 30 Mar 2016 13:04:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 17:04:51 -0000

I described some of the vulnerabilities that I was referring to in a 
message on March 25, and they had nothing to do with CT or DKG's attack.

The problem is that Steve's proposed text for Section 3.3 includes a 
false statement about RFC 5280. The rest of the text then seems to have 
been written in a way to try to justify the inclusion of this false 
statement, with the result that it is very confusing, and it is leading 
some people on this list to believe that X.509 must be broken.

My point was that both X.509 and PKIX (RFC 5280 is just a profile of 
X.509) work well as long as there are not two different trusted entities 
(e.g., CAs, CRL issuers, OCSP responders) that operate under the same 
entity, but that if Steve's claim about RFC 5280 was true, there would 
be vulnerabilities in PKIX profiles/protocols even if all of the CAs in 
the PKI were honest and followed the requirements in RFC 5280. An 
example of a vulnerability (see the March 25 email) would be that a 
relying party might use a CRL issued by one CA to determine the status 
of a certificate issued by another CA, even though the CAs are unrelated 
and the CRL doesn't actually provide any status information about 
certificates issued by the other CA. This would happen even though 
neither CA was trying to "attack" the other, and they were just each 
operating in a way that Steve claims that RFC 5280 allows.

I agree with you about "metaphysics." When I read Steve's text, I 
couldn't understand what it was trying to say, even though I was the 
primary author of RFC 5280 and have been working in PKI for almost 20 
years. When I then read DKG's email, it was very easy for me to 
understand the attack he was trying to describe, and it was clear that 
it was not the same as what Steve was describing in his text.

If Steve would just describe DKG's attack instead of trying to use this 
as a forum for advancing his personal beliefs about X.509, then we 
wouldn't have to deal with these metaphysical arguments.

On 03/30/2016 12:09 PM, Watson Ladd wrote:
> On Wed, Mar 30, 2016 at 9:02 AM, David A. Cooper  wrote:
>> So, your contention is that PKIX diverged from X.509 by removing the
>> requirement for names to be unambiguous, and did nothing to address the
>> vulnerability created by this divergence other than noting the vulnerability
>> in the Security Considerations sections of its documents? The working group
>> then went on to develop protocols and profiles that relied on names being
>> unambiguous, and then just noted in the Security Considerations that an
>> unnecessary vulnerability had been created? I have even looked for evidence
>> that the PKIX WG discussed the idea of deviating from X.509 and allowing
>> names to be ambiguous (i.e., unrelated entities operating under the same
>> name) and have been unable to find any evidence of that on the mail list. I
>> have, however, heard an explanation for why the text in Section 4.1.2.6 says
>> what it does, and it was not about a deliberate decision to deviate from
>> X.509.
> What "vulnerability" is created? The reason DKG's attack functions is
> CT records the end entity certificate,
>
> In the attack model the conspiring CAs can just ignore the requirement
> on name validity. I don't see why X509 protects against this more.
>
>> The proposed text for Section 3.3 seems to be written with the goal of
>> advancing your personal belief about what RFC 5280 does or does not require
>> rather than trying to explain a potential attack in the clearest way
>> possible. Removing the parenthetical about RFC 5280 and simply referring to
>> the intermediate CA and EE as the single entities that they are would go a
>> long way towards improving the text.
> Define "entity". End of the day there are only bits: the question is
> how implementations will behave when given two bitstrings concocted in
> the way described by DKG. Disputes over the metaphysics are really
> in(trans)substantial.
>
>>
>> On 03/30/2016 10:25 AM, Stephen Kent wrote:
>>
>> David,
>>
>> I appreciate your persistence, but we will just have to agree to disagree on
>> the
>> topic of whether 5280 requires global name uniqueness.
>>
>> First, I cited text from Secyion 4.1.2.6, which is the one place in 5280
>> where global
>> name uniqueness should be mandated if it were a requirement. That section
>> establishes a
>> requirement for local (per-CA) name uniqueness, not for global name
>> uniqueness. IMHO
>> that is the definitive statement on this topic.
>>
>> RFC 5280, like its predecessors, has deviated from X.509 where we felt
>> necessary. Your
>> argument that PKIX docs will maintain compatibility with X.509 is just an
>> indication
>> of overall intent, not a promise to never deviate. You acknowledge this
>> later when you
>> discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280, but
>> not X.509."
>>
>> Yes, the Security Considerations section of 5280 notes that problems that
>> can arise if
>> names are not globally unique. However, that is not the same as saying that
>> 5280 requires
>> them to be so. Rather it is a warning of the bad things that may happen if
>> name collisions
>> occur. A warning in the Security Considerations section the way we usually
>> note a residual
>> vulnerability in a standard. It is NOT a backdoor way to add a requirement
>> to a standard.
>>
>> Your other comments cite text that, in your opinion, suggests the need for
>> global name
>> uniqueness, rather than citing text that establishes this requirement. Hence
>> I'm not going
>> to spend time addressing those comments.
>>
>> Aside from the gratuitous parenthetical in your text falsely stating that
>> RFC 5280 "doe not preclude the creation of two CAs with the same name, so
>> long as the parent CAs are distinct," you still write about two CAs issuing
>> two EE certificates that are identical. If it walks like a duck and it
>> quacks like a duck, then chances are its a duck. In the scenario you are
>> trying to describe, there is one CA that issues one EE certificate.
>>
>> One might argue that two entities acting as CAs that have the same name and
>> same public
>> key are the same CA. But if the entities happen to be different
>> organizations, perhaps
>> in different geopolitical regions, others might argue that they are
>> different CAs.
>>
>> Can you name even one RP that maintains a cache of revocation status info
>> organized by cert path?
>>
>> BBN has implemented RP code for at least 4 products over the past 20 years.
>> Some were part
>> of PKI systems developed for clients in the financial services area. The
>> most recent is
>> the RPSTIR code for the RPKI. All of them operate as I described.
>>
>> I'll discuss whether my attack scenarios are accurate and match the spirit
>> of DKGs original
>> message with him, not you.
>>
>> Steve
>>
>>
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>


From nobody Wed Mar 30 10:15:18 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0C312D74D for ; Wed, 30 Mar 2016 10:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5YsXzah_VIn for ; Wed, 30 Mar 2016 10:15:15 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3C912D6B8 for ; Wed, 30 Mar 2016 10:15:07 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id ma7so70959338igc.0 for ; Wed, 30 Mar 2016 10:15:07 -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; bh=80+NBvNwtS/+9SLvSdpqBBjrFZpj3TWk5KDkyEZVs/E=; b=Z6TpGfwtLJo2KqQX42PDjtjGhti8lOpSEui6LcHBQo3qOysDydjqocDlcf+NhEfw8E exssjkutZSLtiG37VKTa/em6qsRVFNX3NmEXtDlDosRo8HFqA2cL7Pza75loC5GveBO2 utEaM8RYieso4ESwaWwsQ15u9wpXBZUQzJB8yrMKUUNImI61BFvFjzkPQ3tjVJM+RjK5 fgXOqzUWPKnhQMSE3qEIzJwcojUuqHGyTp9e3EgJyS5jtMq+q89w0xKdySraOe3ENcJV PHFnCesg/7tRDdZs3p6pt0d418JqlOWyJ7GyR47AEH1tmZfI3G2t+uNvCofICSkZZdtu ybCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=80+NBvNwtS/+9SLvSdpqBBjrFZpj3TWk5KDkyEZVs/E=; b=LDMCdSYhsoAFCqDboKQm6CrHDjzwgviR4nMvPC0A/cUrz8iso9E6FR1vMrKRpfm/5b R726R6NgB91Zzc3HvK3oJNLLE9Dxp/dLJXcx5TuiU3WdQFohZzszBgwi7vYsz6qNJjsV VA4Lf3bPAtDK1Dw4j9te3/rAa0SILKl8LH2qC0APGb6WjByTp3hMtRZmSyUK59hXA/jF S+wjx0MpGTc9qSRmUhe2u52D122/cH+YxglUCR1sMzvooavbA2ZFux3255kY5lyKnaTw of4tjN88F7ldWaSx5b304a42SO3FFZGzDivmR1rnbgki3+BIE9wHen5Fu5F4lvuRWmpS 0vYg==
X-Gm-Message-State: AD7BkJLRHAT4QW285UKRc0JBFooNUsKAsK2Y8+kpMLpwrOrMRaDiUUa/Et53RkP5vGpHIp3IPZTh/E6bWhzbvPWH
MIME-Version: 1.0
X-Received: by 10.50.132.36 with SMTP id or4mr10728739igb.23.1459358105531; Wed, 30 Mar 2016 10:15:05 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Wed, 30 Mar 2016 10:15:05 -0700 (PDT)
In-Reply-To: <56FBF88F.2050407@nist.gov>
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>
Date: Wed, 30 Mar 2016 18:15:05 +0100
Message-ID: 
From: Ben Laurie 
To: "David A. Cooper" 
Content-Type: multipart/alternative; boundary=047d7b3a9b4c7b4b2d052f474953
Archived-At: 
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 17:15:17 -0000

--047d7b3a9b4c7b4b2d052f474953
Content-Type: text/plain; charset=UTF-8

On 30 March 2016 at 17:02, David A. Cooper  wrote:

> So, your contention is that PKIX diverged from X.509 by removing the
> requirement for names to be unambiguous, and did nothing to address the
> vulnerability created by this divergence other than noting the
> vulnerability in the Security Considerations sections of its documents? The
> working group then went on to develop protocols and profiles that relied on
> names being unambiguous, and then just noted in the Security Considerations
> that an unnecessary vulnerability had been created? I have even looked for
> evidence that the PKIX WG discussed the idea of deviating from X.509 and
> allowing names to be ambiguous (i.e., unrelated entities operating under
> the same name) and have been unable to find any evidence of that on the
> mail list. I have, however, heard an explanation for why the text in
> Section 4.1.2.6 says what it does, and it was not about a deliberate
> decision to deviate from X.509.
>

In practice, how would you ensure names were unambiguous? (actually, a
CT-like mechanism could be used, but CT does rather post-date 5280)

The vulnerability is also mitigated by requiring AIA in the EE certificate,
which the BRs do. Arguably, 5280 should also.

BTW, in case it is not clear, I do agree with Steve that 5280 does not
require global uniqueness.


>
> The proposed text for Section 3.3 seems to be written with the goal of
> advancing your personal belief about what RFC 5280 does or does not require
> rather than trying to explain a potential attack in the clearest way
> possible. Removing the parenthetical about RFC 5280 and simply referring to
> the intermediate CA and EE as the single entities that they are would go a
> long way towards improving the text.
>
>
> On 03/30/2016 10:25 AM, Stephen Kent wrote:
>
> David,
>
> I appreciate your persistence, but we will just have to agree to disagree
> on the
> topic of whether 5280 requires global name uniqueness.
>
> First, I cited text from Secyion 4.1.2.6, which is the one place in 5280
> where global
> name uniqueness should be mandated if it were a requirement. That section
> establishes a
> requirement for local (per-CA) name uniqueness, not for global name
> uniqueness. IMHO
> that is the definitive statement on this topic.
>
> RFC 5280, like its predecessors, has deviated from X.509 where we felt
> necessary. Your
> argument that PKIX docs will maintain compatibility with X.509 is just an
> indication
> of overall intent, not a promise to never deviate. You acknowledge this
> later when you
> discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280,
> but not X.509."
>
> Yes, the Security Considerations section of 5280 notes that problems that
> can arise if
> names are not globally unique. However, that is not the same as saying
> that 5280 requires
> them to be so. Rather it is a warning of the bad things that may happen if
> name collisions
> occur. A warning in the Security Considerations section the way we usually
> note a residual
> vulnerability in a standard. It is NOT a backdoor way to add a requirement
> to a standard.
>
> Your other comments cite text that, in your opinion, suggests the need for
> global name
> uniqueness, rather than citing text that establishes this requirement.
> Hence I'm not going
> to spend time addressing those comments.
>
> Aside from the gratuitous parenthetical in your text falsely stating that
> RFC 5280 "doe not preclude the creation of two CAs with the same name, so
> long as the parent CAs are distinct," you still write about two CAs issuing
> two EE certificates that are identical. If it walks like a duck and it
> quacks like a duck, then chances are its a duck. In the scenario you are
> trying to describe, there is one CA that issues one EE certificate.
>
> One might argue that two entities acting as CAs that have the same name
> and same public
> key are the same CA. But if the entities happen to be different
> organizations, perhaps
> in different geopolitical regions, others might argue that they are
> different CAs.
>
> Can you name even one RP that maintains a cache of revocation status info
> organized by cert path?
>
> BBN has implemented RP code for at least 4 products over the past 20
> years. Some were part
> of PKI systems developed for clients in the financial services area. The
> most recent is
> the RPSTIR code for the RPKI. All of them operate as I described.
>
> I'll discuss whether my attack scenarios are accurate and match the spirit
> of DKGs original
> message with him, not you.
>
> Steve
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>

--047d7b3a9b4c7b4b2d052f474953
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 30 March 2016 at 17:02, David A. Cooper <david.cooper@nist.gov<=
/a>> wrote:

 =20
   =20
 =20
  

    
So, your contention is that PKIX
      diverged from X.509 by removing the requirement for names to be
      unambiguous, and did nothing to address the vulnerability created
      by this divergence other than noting the vulnerability in the
      Security Considerations sections of its documents? The working
      group then went on to develop protocols and profiles that relied
      on names being unambiguous, and then just noted in the Security
      Considerations that an unnecessary vulnerability had been created?
      I have even looked for evidence that the PKIX WG discussed the
      idea of deviating from X.509 and allowing names to be ambiguous
      (i.e., unrelated entities operating under the same name) and have
      been unable to find any evidence of that on the mail list. I have,
      however, heard an explanation for why the text in Section 4.1.2.6
      says what it does, and it was not about a deliberate decision to
      deviate from X.509.

I=
n practice, how would you ensure names were unambiguous? (actually, a CT-li=
ke mechanism could be used, but CT does rather post-date 5280)
The vulnerability is also mitigated by requiring AIA in the EE=
 certificate, which the BRs do. Arguably, 5280 should also.

<=
/div>
BTW, in case it is not clear, I do agree with Steve that 5280 doe=
s not require global uniqueness.
=C2=A0

      

      The proposed text for Section 3.3 seems to be written with the
      goal of advancing your personal belief about what RFC 5280 does or
      does not require rather than trying to explain a potential attack
      in the clearest way possible. Removing the parenthetical about RFC
      5280 and simply referring to the intermediate CA and EE as the
      single entities that they are would go a long way towards
      improving the text.


      

      On 03/30/2016 10:25 AM, Stephen Kent wrote:

    

    

     =20
      David,

      

      
I appreciate your persistence, but we
        will just have to agree to disagree on the

        topic of whether 5280 requires global name uniqueness.

        

        First, I cited text from Secyion 4.1.2.6, which is the one place
        in 5280 where global 

        name uniqueness should be mandated if it were a requirement.
        That section establishes a 

        requirement for local (per-CA) name uniqueness, not for global
        name uniqueness. IMHO

        that is the definitive statement on this topic.

        

        RFC 5280, like its predecessors, has deviated from X.509 where
        we felt necessary. Your

        argument that PKIX docs will maintain compatibility with X.509
        is just an indication

        of overall intent, not a promise to never deviate. You
        acknowledge this later when you 

        discuss CRL issuer paths and say ".. a requirement imposed by
        RFC 5280, but not X.509."

        

        Yes, the Security Considerations section of 5280 notes that
        problems that can arise if

        names are not globally unique. However, that is not the same as
        saying that 5280 requires

        them to be so. Rather it is a warning of the bad things that may
        happen if name collisions

        occur. A warning in the Security Considerations section the way
        we usually note a residual 

        vulnerability in a standard. It is NOT a backdoor way to add a
        requirement to a standard.

        

        Your other comments cite text that, in your opinion, suggests
        the need for global name 

        uniqueness, rather than citing text that establishes this
        requirement. Hence I'm not going 

        to spend time addressing those comments.

        

      

      

        Aside from the gratuitous parenthetical in your text falsely
        stating that RFC 5280 "doe not preclude the creation of two CA=
s
        with the same name, so long as the parent CAs are distinct," y=
ou
        still write about two CAs issuing two EE certificates that are
        identical. If it walks like a duck and it quacks like a duck,
        then chances are its a duck. In the scenario you are trying to
        describe, there is one CA that issues one EE certificate. 
      One might argue that two entities acting as CAs that have the same
      name and same public

      key are the same CA. But if the entities happen to be different
      organizations, perhaps 

      in different geopolitical regions, others might argue that they
      are different CAs.

      
Can
        you name even one RP that maintains a cache of revocation status
        info organized by cert path? 

      BBN has implemented RP code for at least 4 products over the past
      20 years. Some were part

      of PKI systems developed for clients in the financial services
      area. The most recent is 

      the RPSTIR code for the RPKI. All of them operate as I described.
      

      

      I'll discuss whether my attack scenarios are accurate and match
      the spirit of DKGs original 

      message with him, not you.

      

      Steve

    

    

  




_______________________________________________

Trans mailing list

Trans@ietf.org

https://www.ietf.org/mailman/listinfo/trans





--047d7b3a9b4c7b4b2d052f474953--


From nobody Wed Mar 30 10:18:14 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7820212D794 for ; Wed, 30 Mar 2016 10:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM0A2ssaVAlL for ; Wed, 30 Mar 2016 10:18:09 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 705C112D5AF for ; Wed, 30 Mar 2016 10:18:09 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id n5so47815174pfn.2 for ; Wed, 30 Mar 2016 10:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=arjA63D+PvxnnRgtmw6il5r/HLPDLQOzP2FKMuiKHbs=; b=nKkCIqhsIJnanPx9yOGzXGq2CMugdQ5pbsesWrsRsfMEOalEVA1H0uUDnXTQcVG/Cu 5mTV/y7rFZAkoIVJw9JQ+BdEkPEC5fGbnpwpJpZW48X1NC/Ew6SECa8woaj5KAbTLUE5 RyApu/B0VOSs7yGAQ/YxFr047mf/dvZVtyErVuu4tZ3WTQH2PIi4bpli6jC+5Zgl16sI tsk2dbCMpL66XnVo4IrU+Rx05vi1CXKOwq1K+1uzTLt/KABV1mc3W7V1L4wIXDecwKgT IGWGrWEVrilm8yqfFpW/+5ceFdAqMtE3MQURi0OFXgWkqwPJxpZHlYiwFUesD8Gv6+rW AT5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=arjA63D+PvxnnRgtmw6il5r/HLPDLQOzP2FKMuiKHbs=; b=KDcJnBHqXttl6Yb0HFKKbbxFde+OPm7GAlqXGi+xc01o8boHz0DZlf1XJ4yRyFeMqn P0O76QlPRSNHC9pG+JheGAm3GdoFJoYfWaHB1s7zs3maizKvtvqp4mU4EtOsAaFgV8OP ZMUfXg1FzeR3lS8EOXH4S/XLHs/vJ5FnCHSps74u9w2Rq5+s3Nq8uGmLbrN/zPSSNvt4 varcORq667sh7T0TVpgtFAr2VJ/Uz7ACtGDRXO8GuaVUoj5GxffpMrmGg1N5K4i9ATYp C1TONajHg2NxTfZ1tyCnwNSYeqBYlWA11+tuwJOmcBncKdQioSDtVWouZABPVkE3dDxA 6pWA==
X-Gm-Message-State: AD7BkJIPBh7M5YbhG8Is0xW3iXVQ/IewN32wLlXVcO5pYxBpe7nAMe9C2kG7zENcO5ErTg==
X-Received: by 10.98.14.207 with SMTP id 76mr15033382pfo.1.1459358289050; Wed, 30 Mar 2016 10:18:09 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (209-112-213-121-radius.dynamic.acsalaska.net. [209.112.213.121]) by smtp.googlemail.com with ESMTPSA id q2sm7270351pfq.88.2016.03.30.10.18.07 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 10:18:08 -0700 (PDT)
To: trans@ietf.org
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>  <56FC0720.5090204@nist.gov>
From: Melinda Shore 
Message-ID: <56FC0A65.5060602@gmail.com>
Date: Wed, 30 Mar 2016 09:18:29 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56FC0720.5090204@nist.gov>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 17:18:11 -0000

On 3/30/16 9:04 AM, David A. Cooper wrote:
> If Steve would just describe DKG's attack instead of trying to use this
> as a forum for advancing his personal beliefs about X.509, then we
> wouldn't have to deal with these metaphysical arguments.

I understand that you and some other participants are
frustrated at the moment but it would be helpful if the
discussion could remain technical in nature.

We have working group agreement that the attack described
by DKG needs to be documented and included in the threat
draft.  The draft is not going to back into working group
last call without it, period.

There may be other missing attacks as well and I think
that given where we are today it might be productive for
those to be discussed in a  different thread, to avoid
confusion about what's actually under discussion.

In the meantime, if we can't get some text about the
dual CA attack in the next few weeks we may reach out to
other participants to draft something up for inclusion.

Melinda


From nobody Wed Mar 30 10:31:33 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1348012D818 for ; Wed, 30 Mar 2016 10:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=redhoundsoftware-com.20150623.gappssmtp.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 jz0Z6xcbAcRU for ; Wed, 30 Mar 2016 10:31:30 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 55F2112D7FD for ; Wed, 30 Mar 2016 10:31:30 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id g185so83569052ioa.2 for ; Wed, 30 Mar 2016 10:31:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=DuDb5mosOMY9+pP+HIx0ErjjSqDxTPmcrK80HyqTsr4=; b=p+tL2tAJR3++X2E1rkFGqj2JRxQkfkdFqhwPVoB7Xe4/JRR7g6HFIj5fwhy+8xI0uy uJPNLjMOhKU/R5kE9aOtEkgBMYP0QpjqwKsuvlsI4e4AXu3HT7DPA9JEsTJAb2rmZt6P ERBCrgNqy6tFdm2Bk2lV+PQpBwLvCz+yIQnA/R3NdeYkQg7RCqGNRySAdV8VQPxkt9zp 6upyXZz/hR1XPPLMhdF5CIbsM6NtJMaxWeYoBgsK5evLrVp+gnORfuvFYITlgvrzsfSN CfYQBv2bFVwYNcdIJJTB8ldSVyQadh6PYWNvDAWSnFwGQujzwNcvrou7hL7HIfzsqhNF nGfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=DuDb5mosOMY9+pP+HIx0ErjjSqDxTPmcrK80HyqTsr4=; b=NaR0U325O9jEsjqdIcFCe4V6aeKPOMLS8xcHBvHVgaTv0Pj5KVkYGACVnhhnucxT+n 76FvfT4/9VF73W0av7FT3xk1aPZE4dL8PaU1x1xjRGZ2kwqimFiHMq/2NPG83SC+xC7d LwFzyQFfeVgbcpwKWlZh75gSqzCHo5YnIVR0Z5o7WU1f+bAELDf1N5I1mv/rWmIKOY46 vKYOsMOfKv7jfN8PG/Tra8/Q9b9Lx7TB1dw+j9wV25OgmpODeRNpd2XjjrJSBklB0ADJ HY9cHYGmhHWzOmaMhRMPfYfdhmpRrAiaHqR6T+rCVJkDojwsP+U46uEHcz3Z2xbic/wD d64A==
X-Gm-Message-State: AD7BkJKH/TDMcyiz6VTFatRDnjv59h2979bo3UgH+WhdR+i5ASdyD3rz4n38cKVu8F3gng==
X-Received: by 10.157.61.161 with SMTP id l30mr6056989otc.108.1459359088928; Wed, 30 Mar 2016 10:31:28 -0700 (PDT)
Received: from [10.247.170.171] ([97.65.242.177]) by smtp.gmail.com with ESMTPSA id w9sm1458674oie.3.2016.03.30.10.31.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 10:31:28 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Wed, 30 Mar 2016 13:31:19 -0400
From: Carl Wallace 
To: Ben Laurie , "David A. Cooper" 
Message-ID: 
Thread-Topic: [Trans] text to address DKG's conspiring CAs attack
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov> 
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3542189487_6647173"
Archived-At: 
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 17:31:32 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3542189487_6647173
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit


From:  Trans  on behalf of Ben Laurie

Subject:  Re: [Trans] text to address DKG's conspiring CAs attack

> 
> 
> On 30 March 2016 at 17:02, David A. Cooper  wrote:
>>     
>>  
>> So, your contention is that PKIX diverged from X.509 by removing the
>> requirement for names to be unambiguous, and did nothing to address the
>> vulnerability created by this divergence other than noting the vulnerability
>> in the Security Considerations sections of its documents? The working group
>> then went on to develop protocols and profiles that relied on names being
>> unambiguous, and then just noted in the Security Considerations that an
>> unnecessary vulnerability had been created? I have even looked for evidence
>> that the PKIX WG discussed the idea of deviating from X.509 and allowing
>> names to be ambiguous (i.e., unrelated entities operating under the same
>> name) and have been unable to find any evidence of that on the mail list. I
>> have, however, heard an explanation for why the text in Section 4.1.2.6 says
>> what it does, and it was not about a deliberate decision to deviate from
>> X.509.
> 
> In practice, how would you ensure names were unambiguous? (actually, a CT-like
> mechanism could be used, but CT does rather post-date 5280)

You could express name constraints on a trust anchor to prevent re-use of
the same CA subject name. Of course, there are very few implementations of
this and none (that I know of) in the web PKI and the expression could get
long for overpopulated TA stores. Details are in 5914 and 5937, as noted in
6818. Using this you would just need to make sure there are no overlaps in
your TA store. 

> 
> The vulnerability is also mitigated by requiring AIA in the EE certificate,
> which the BRs do. Arguably, 5280 should also.

How does an AIA help? AIAs could be suppressed or mis-populated and path
building may use artifacts previously download from a different AIA.

> 
> BTW, in case it is not clear, I do agree with Steve that 5280 does not require
> global uniqueness.
> 



--B_3542189487_6647173
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



From:  Trans <tra=
ns-bounces@ietf.org> on behalf of Ben Laurie <benl@google.com>
Subje=
ct:  Re: [Trans] text to address DKG's conspiring CAs attack



On 30 March 2016=
 at 17:02, David A. Cooper <david.cooper@nist.gov> wrote:

  
    
  
  

    
So, your contention is that PKIX
      diverged from X.509 by removing the requirement for names to be
      unambiguous, and did nothing to address the vulnerability created
      by this divergence other than noting the vulnerability in the
      Security Considerations sections of its documents? The working
      group then went on to develop protocols and profiles that relied
      on names being unambiguous, and then just noted in the Security
      Considerations that an unnecessary vulnerability had been created?
      I have even looked for evidence that the PKIX WG discussed the
      idea of deviating from X.509 and allowing names to be ambiguous
      (i.e., unrelated entities operating under the same name) and have
      been unable to find any evidence of that on the mail list. I have,
      however, heard an explanation for why the text in Section 4.1.2.6
      says what it does, and it was not about a deliberate decision to
      deviate from X.509.

I=
n practice, how would you ensure names were unambiguous? (actually, a CT-lik=
e mechanism could be used, but CT does rather post-date 5280)

You could express name cons=
traints on a trust anchor to prevent re-use of the same CA subject name. Of =
course, there are very few implementations of this and none (that I know of)=
 in the web PKI and the expression could get long for overpopulated TA store=
s. Details are in 5914 and 5937, as noted in 6818. Using this you would just=
 need to make sure there are no overlaps in your TA store. 
<=
br>

The vulnerability is also mitigated by requiring AIA in=
 the EE certificate, which the BRs do. Arguably, 5280 should also.

How does an AIA help? =
AIAs could be suppressed or mis-populated and path building may use artifact=
s previously download from a different AIA. 


BTW, in case it is not clear, I do agree with Steve that 5280 does not=
 require global uniqueness.



--B_3542189487_6647173--



From nobody Wed Mar 30 11:36:25 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E04812D8AC for ; Wed, 30 Mar 2016 11:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level: 
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ma2Z-Ya2a3p for ; Wed, 30 Mar 2016 11:36:20 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F324512D8AB for ; Wed, 30 Mar 2016 11:36:19 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 30 Mar 2016 14:37:40 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Wed, 30 Mar 2016 14:36:18 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2UIaEma031326;	Wed, 30 Mar 2016 14:36:15 -0400
To: Ben Laurie 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov> 
From: "David A. Cooper" 
Message-ID: <56FC1C9E.4030605@nist.gov>
Date: Wed, 30 Mar 2016 14:36:14 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner-Information: 
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 18:36:23 -0000


  
    
  
  
    
I provided rather detailed evidence
      that RFC 5280 does require global name uniqueness. Can you explain
      why my evidence is wrong? How does the text in Section 6.3 of RFC
      5280 ensure that a CRL issued by one CA isn't used to determine
      the status of certificates issued by an unrelated CA issuing
      certificates under the same name if both can be validated from the
      same trust anchor?

      

      I have been explaining what RFC 5280 says (and what X.509 says). I
      have not been trying to justify that it was a correct design
      decision, so there's no need for me to answer the question about
      how one would ensure names are unambiguous.

      

      You are free to agree with Steve that RFC 5280 shouldn't
      have required names to be globally unambiguous, but that doesn't
      change the fact that (as I have shown) RFC 5280 and other PKIX
      documents were written in a way that things don't work unless
      names are globally unambiguous.

      

      If RFC 5280 didn't require names to be unambiguous, why didn't the
      text in Section 6.3.3 address the problem I mentioned above by
      requiring that the certification path for a CRL be the same as for
      the certificate whose status is being checked (or at least require
      that the list of CA names in the paths be the same)? Again, you
      can agree with Steve that something like that should have
      been done, but where's the evidence that it was done?

      

      Dave

      

      P.S. It would really be helpful if this discussion thread could
      end. It's not relevant to TRANS, and there would be no reason to
      discuss it at all in this group if there wasn't an attempt to
      include text about it in one of the TRANS documents.

      

      On 03/30/2016 01:15 PM, Ben Laurie wrote:

    

    

      
      
On 30 March 2016 at 17:02, David A. Cooper <david.cooper@nist.gov>
        wrote:

        

          

            

              

                
So, your contention is that PKIX diverged from
                  X.509 by removing the requirement for names to be
                  unambiguous, and did nothing to address the
                  vulnerability created by this divergence other than
                  noting the vulnerability in the Security
                  Considerations sections of its documents? The working
                  group then went on to develop protocols and profiles
                  that relied on names being unambiguous, and then just
                  noted in the Security Considerations that an
                  unnecessary vulnerability had been created? I have
                  even looked for evidence that the PKIX WG discussed
                  the idea of deviating from X.509 and allowing names to
                  be ambiguous (i.e., unrelated entities operating under
                  the same name) and have been unable to find any
                  evidence of that on the mail list. I have, however,
                  heard an explanation for why the text in Section
                  4.1.2.6 says what it does, and it was not about a
                  deliberate decision to deviate from X.509.

                

              

            

            


            

            
In practice, how would you ensure names were
              unambiguous? (actually, a CT-like mechanism could be used,
              but CT does rather post-date 5280)

            


            

            
The vulnerability is also mitigated by requiring AIA in
              the EE certificate, which the BRs do. Arguably, 5280
              should also.

            


            

            
BTW, in case it is not clear, I do agree with Steve
              that 5280 does not require global uniqueness.

            
 

          

        

      

    

  



From nobody Wed Mar 30 13:16:15 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B77612D93E for ; Wed, 30 Mar 2016 13:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_Mluvsk7WKD for ; Wed, 30 Mar 2016 13:16:13 -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 7C7D412D8B3 for ; Wed, 30 Mar 2016 13:16:13 -0700 (PDT)
Received: from localhost ([::1]:57058 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1alMXD-00085K-E8; Wed, 30 Mar 2016 13:16:11 -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, eranm@google.com
X-Trac-Project: trans
Date: Wed, 30 Mar 2016 20:16:11 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/156#comment:8
Message-ID: <072.936bef17c57674b00a6123fb722138b2@tools.ietf.org>
References: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-Trac-Ticket-ID: 156
In-Reply-To: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #156 (rfc6962-bis): Can inclusion proofs properly substitute SCTs?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 20:16:15 -0000

#156: Can inclusion proofs properly substitute SCTs?

Changes (by eranm@google.com):

 * milestone:   => review


Comment:

 Merged, please review.

-- 
------------------------------+---------------------------------------
 Reporter:  eranm@google.com  |       Owner:  rob.stradling@comodo.com
     Type:  defect            |      Status:  new
 Priority:  critical          |   Milestone:  review
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:
 Keywords:                    |
------------------------------+---------------------------------------

Ticket URL: 
trans 


From nobody Wed Mar 30 13:18:49 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3326312D8B3 for ; Wed, 30 Mar 2016 13:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNfrCrJ7LtFp for ; Wed, 30 Mar 2016 13:18: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 B4D6B12D675 for ; Wed, 30 Mar 2016 13:18:45 -0700 (PDT)
Received: from localhost ([::1]:57288 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1alMZg-0006Hm-ED; Wed, 30 Mar 2016 13:18: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: rob.stradling@comodo.com, eranm@google.com, melinda.shore@gmail.com
X-Trac-Project: trans
Date: Wed, 30 Mar 2016 20:18:44 -0000
X-URL: https://tools.ietf.org/trans/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/trans/trac/ticket/156#comment:9
Message-ID: <072.6a1b646073fe08abc0bde57b0c14a20f@tools.ietf.org>
References: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-Trac-Ticket-ID: 156
In-Reply-To: <057.0d95c321188cdb7c3a9d91d74944a13b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, melinda.shore@gmail.com, trans@ietf.org
X-SA-Exim-Mail-From: trac+trans@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: trans@ietf.org
Subject: Re: [Trans] [trans] #156 (rfc6962-bis): Can inclusion proofs properly substitute SCTs?
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 20:18:47 -0000

#156: Can inclusion proofs properly substitute SCTs?

Changes (by melinda.shore@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
------------------------------+---------------------------------------
 Reporter:  eranm@google.com  |       Owner:  rob.stradling@comodo.com
     Type:  defect            |      Status:  closed
 Priority:  critical          |   Milestone:  review
Component:  rfc6962-bis       |     Version:
 Severity:  -                 |  Resolution:  fixed
 Keywords:                    |
------------------------------+---------------------------------------

Ticket URL: 
trans 


From nobody Wed Mar 30 13:28:48 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA0312D832 for ; Wed, 30 Mar 2016 13:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d23RJteWWk4n for ; Wed, 30 Mar 2016 13:28:37 -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 372BF12D96C for ; Wed, 30 Mar 2016 13:27:22 -0700 (PDT)
Received: by mail-pa0-x22b.google.com with SMTP id fe3so48762930pab.1 for ; Wed, 30 Mar 2016 13:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=k3+NHMF6PKWi/TR6eWnNswzO6L2VvO0DODyOUIQL6Ak=; b=OVDpwUn/H7+V2PcqIle+st0fDTZAvLaW2ElfIyDgGu3dGNG0w0Ga9/b+lO23A0yLL4 Ivp8Wp9zbXxpuKutyCBHjAuyIX4nAELSxrd4rfiZcD2ytzfh7cf/8xGwkzh9XhAPo6JF ZPuUUlZsLKNBUWj7RoqqQtmH+NkntQCi8laBqyMpt0CAXiyjNjh5Qr/JM1MCVZ6HEAeA +RvkiiLGwMpXP6/nqhQ5fYur2UDPa0VyOgIAGGcyYO/sJTm0rlemVWGI/D/UPx5jhanv bT6kXTG/X9/FvXnCCX4qdRJqMTUZIQ5Pl70zoH6MLhwsXWw6xp8PoOYKod/UTV5vLljp ib8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=k3+NHMF6PKWi/TR6eWnNswzO6L2VvO0DODyOUIQL6Ak=; b=UF9Jy5eetVTXlcqDidryLuzgeAIMLC3qAnbxjbwzd6Le+iOzLdyu/SDYleEJMjSQOC wUdTd7WjIygSON5miltm2eqhccnsi6EcG4yVnDHvPAgezFKo9VEl8zMHE93ooYLzkLwK Vlk4voYoQaM0KqCe4MjdLh9jZAzQZFbI8717M+J2Qu2Lhc5ljOpympJZmmqv3+5CkJ6K 8YhS+VtcxblM88LC+VBQyrFrvgiG8vSgCdak6iSyUvN7j7/EI/10NQGD+lzu3AGsE86o pml7XUBZ8oj+hR2tE69XPNwnlFqyTk1CFbnQWOoB5wowd4stVfWRLzQ1Hygz1z7VX3Fc f5bQ==
X-Gm-Message-State: AD7BkJJ37xdAnv5LqHGBUcjIt/nbTJxXWRExsvGSnrG3mPANcQVjCcQ45Ni2FFRiQn4atw==
X-Received: by 10.67.1.65 with SMTP id be1mr16346899pad.46.1459369641760; Wed, 30 Mar 2016 13:27:21 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (209-112-213-121-radius.dynamic.acsalaska.net. [209.112.213.121]) by smtp.googlemail.com with ESMTPSA id f12sm7893132pfd.87.2016.03.30.13.27.19 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 13:27:21 -0700 (PDT)
To: "trans@ietf.org" 
From: Melinda Shore 
Message-ID: <56FC36C5.3000709@gmail.com>
Date: Wed, 30 Mar 2016 12:27:49 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Trans] Open issues update
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 20:28:47 -0000

As of this afternoon, we have only one remaining open ticket
(https://trac.tools.ietf.org/wg/trans/trac/ticket/124) on
6962-bis, concerning the clarity of the introduction.
Personally, I find it sufficiently clear with respect to the
entire document (that is to say that the introduction
provides sufficient background to understand the rest of
the document) and am generally not a fan of redundant
document content, which can be a maintenance headache and
can get out of sync.

That said, if anybody feels strongly about this they need
to contribute some text.  Steve Kent currently owns the
ticket but anybody can write something up.

On the other hand, if nobody else feels strongly about
this I propose closing it as wontfix.  Lack of text will
tend to be highly suggestive of nobody else feeling
strongly.

Melinda


From nobody Wed Mar 30 13:29:37 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A7B12D935 for ; Wed, 30 Mar 2016 13:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFkDZDG1g8Nd for ; Wed, 30 Mar 2016 13:29:34 -0700 (PDT)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132FC12D832 for ; Wed, 30 Mar 2016 13:29:34 -0700 (PDT)
Received: by mail-pf0-x242.google.com with SMTP id n5so8468602pfn.1 for ; Wed, 30 Mar 2016 13:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=qYn0lQ1xRT3GoKGbjueYCHIUr30i5muM+1MZCY1ukpk=; b=HphWK2RhNXx97WTLLeXz+Ze72neovgVz8Pt20rUru2mzhlPNT27944np3UfS4sDs5Q teJaR015E20IlzJw9biwa66JwULEWvFL6MIG0O/TH6mleISMmJdHLi2DObTUeBJuI1Fz XhSSCVDuMNMzH/JhtcZ7MsZ4hmNcTdEmNWXMQNh+EwBhbDGiMsFb6vZxcmV1QdbqeU2V xE2sPdrZrqCKIqze7L0TqPxD6fVi4ZUGxnY7b4AdYf2Y/0IzD/VaKpOPC0oGufZtJxL8 gxFwMGWp7y2SoMG13Yds1b+NeFZqXq1JzmrfE2Rg9hFxV9zmGV21t92o9K7fXbBQ4tjM hqdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qYn0lQ1xRT3GoKGbjueYCHIUr30i5muM+1MZCY1ukpk=; b=U/j5mtRKO0urgEhR+xrEYcEcxEhzjp5gvy2xgEKypu7Zg9LVycdHuT+B3V3Zr2GJ4R LDhOqgZsJudVEoumpF900gTgiiRHnT1qM7gbCHvNZi484MBXkzQkjyzIo8fP4qp57OcE nA40HkAz6owppXv7TfMdOcW8+s7QyswEEC43lPno5BnoAr0ocuLVcu7WVzvuJ1+GM3c1 OHpwtzKeZF8tc5D3A9J08PGb18jfjKW6GC8Mok3/LBimBRXzb4p2sGOQ3g3y4rWALsFV N3PFHXHrZ9z4DWOCNmlzqUtIn/EAzES05oZ/mVSsqzz7Z1ZoHS+VZkwe4K37sXHhS1PU qf3Q==
X-Gm-Message-State: AD7BkJJ89yKHVLzrNv1KDGUNUrAkm0+yTP2K7dvOYPFL4gs2GN/AFRBjnPMyopnHlcNzug==
X-Received: by 10.98.12.153 with SMTP id 25mr16175719pfm.27.1459369773657; Wed, 30 Mar 2016 13:29:33 -0700 (PDT)
Received: from Melindas-MacBook-Pro.local (209-112-213-121-radius.dynamic.acsalaska.net. [209.112.213.121]) by smtp.googlemail.com with ESMTPSA id p85sm7950025pfj.16.2016.03.30.13.29.32 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 13:29:33 -0700 (PDT)
References: <20160330202243.4795.63685.idtracker@ietfa.amsl.com>
To: "trans@ietf.org" 
From: Melinda Shore 
X-Forwarded-Message-Id: <20160330202243.4795.63685.idtracker@ietfa.amsl.com>
Message-ID: <56FC374C.9090904@gmail.com>
Date: Wed, 30 Mar 2016 12:30:04 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160330202243.4795.63685.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Trans] Fwd: Remote Participation for IETF 95: Meetecho Details
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 20:29:36 -0000

There's apparently been a change in remote participation
policy - please note that it seems that if you wish to
participate from a remote location, or even just listen,
you'll need to register for the meeting as a remote
participant (no charge).

Melinda


-------- Forwarded Message --------
Subject: Remote Participation for IETF 95: Meetecho Details
Date: Wed, 30 Mar 2016 13:22:43 -0700
From: IETF Secretariat 
Reply-To: ietf@ietf.org
To: IETF Announcement List 
CC: wgchairs@ietf.org, recentattendees@ietf.org, 95all@ietf.org

You may use Meetecho to participate in or just observe any session being 
held in Buenos Aires. Here are the requirements and details.

1. Individuals are required to register for the meeting to observe or 
participate via Meetecho.
- Individuals are required to enter registration I.D and name when 
logging into a session via Meetecho
- The name must match that used to register for the meeting
- Please register even if you are participating as part of remote hub
- There is no cost to register as a remote attendee. Register 
here:http://ietf.org/meeting/register.html.

2. Participation includes the ability to transmit audio and video via 
the Meetecho virtual queue.
- The virtual queue permits remote attendees to share audio and video if 
they choose, see here for more information: 
https://ietf95.conf.meetecho.com/index.php/UMPIRE_Project
- Anyone who thinks they may want to participate by transmitting audio / 
video should perform the Meetecho self-test prior to the start of the 
session: http://ietf95.conf.meetecho.com/index.php/Self_Test

3. WG Chairs will control the virtual queue, unmuting and muting of 
remote participants

4. The agenda for the WG sessions, as well as more detail on how to use 
Meetecho to participate, can be found here: 
https://ietf95.conf.meetecho.com/index.php/.




From nobody Wed Mar 30 13:33:11 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6CD12D942 for ; Wed, 30 Mar 2016 13:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.731
X-Spam-Level: 
X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx1mLwBPR-PI for ; Wed, 30 Mar 2016 13:32:58 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id D325612D979 for ; Wed, 30 Mar 2016 13:32:51 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 31E8F42372E; Wed, 30 Mar 2016 20:32:51 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 1BB00423711; Wed, 30 Mar 2016 20:32:51 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459369971; bh=YkDguwrTJcl4xWg4unDRMOknWDfQ2PLqWD8XoBoazao=; l=252; h=From:To:Date:References:In-Reply-To:From; b=e2VJi2E6btHmtXyh5TExKsNt/6d/zpYD7aT4PqywEqsEE9CFIoL8DcGu//HKb4fp8 JHvo+U6khjxahG9D6gefcFUVuspjI7K5fNl8bGROqeIikMfgaMhTqo+sctohXCuiLx VC/4HKtMObGu4ZYaPPTCm0zi6ckvUYKpxP96s1A8=
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 18FDA1FC8B; Wed, 30 Mar 2016 20:32:51 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 30 Mar 2016 16:32:50 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 30 Mar 2016 16:32:50 -0400
From: "Salz, Rich" 
To: Melinda Shore , "trans@ietf.org" 
Thread-Topic: [Trans] Open issues update
Thread-Index: AQHRisLGEBtwNstWZkmXbjo54t51p59ycQ1A
Date: Wed, 30 Mar 2016 20:32:49 +0000
Message-ID: <42de6511b9d7427fb92497cc5b174b21@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <56FC36C5.3000709@gmail.com>
In-Reply-To: <56FC36C5.3000709@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.117.92]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Trans] Open issues update
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 20:33:06 -0000

> On the other hand, if nobody else feels strongly about this I propose clo=
sing
> it as wontfix.  Lack of text will tend to be highly suggestive of nobody =
else
> feeling strongly.

I will pro-actively say that I support doing nothing here.


From nobody Thu Mar 31 04:38:15 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931DE12D59B for ; Thu, 31 Mar 2016 04:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR7jXw7a6W7M for ; Thu, 31 Mar 2016 04:38:13 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 8C2DE12D5AA for ; Thu, 31 Mar 2016 04:38:12 -0700 (PDT)
Received: by mail-ig0-x235.google.com with SMTP id ui10so55904695igc.1 for ; Thu, 31 Mar 2016 04:38:12 -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; bh=nc/MV1xLBZXpehjODgci/rG2AE+Xs0+BbX/3vRlrTFM=; b=o0GgOq+Zy9cXYwU2gZp/x1Y81Ja096IxKpZQuHmy4mqt7wR61PYVye16cjacaIdvyo Vouocz83LAIS6ptfYm0HGeQJU8qNmFFB9zTwcCYDRQXeIUJgd6kLBbRkMKA9bu0qvUkq UHMMVyxtOvHOnScLIgwhNx+5A3HWVxTFMX1H1to9sPsr+K90S0cHtHWMf+28w1HvZBPf R661j3ZiSxfVyCMBVx8aTyIKqkBjCEkbjPI8k+Oc0GQDYiERmQUw34ufL8ATdAbtf5LM FQJXwH0iGVEflEuIhzoX+JcgcSG1ik4Lfko+0qqYecHwoNGzY+U2P/ZbBtSEJ1CUDjVz Bang==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nc/MV1xLBZXpehjODgci/rG2AE+Xs0+BbX/3vRlrTFM=; b=B0RPokqOFbBzHkc4HYQngC+WJpMKJeHyAyatOLap6T/hzn6Lt9oaExf5ZAc170TThQ QtjqSI5ssMvcgCqDVP7YmUEpVcc75aFzpzb4yRBWWajnw8vTW4y4gTfhpHun5eAb9aap 2sVMANDQWDSZn0czNJnGrs6PUsvdXXWjQRlQB3xZYyKmBEKFzITspX+yK3bDkBSp7SxG WE9CIxIxePyDKs/VJZy5kcRBnBfDqaYwomVMzX+8eQPKXjWLRMY/JTHFPAc/xKyXplYv A2DRHfvwXczBCcQ1p4BY3aUe9Dcd61tdZ/xcoYJc2omL8z3OMOi3/tVIwbSHHNokoKpb 6LVg==
X-Gm-Message-State: AD7BkJIAmH00WKw0NSW5hk1o0bs8zlOYIjoigmRgDabxCK1mew2pN3pXy+xhxpHrGZTq0MXsdXDHZm7wLCNlq0pc
MIME-Version: 1.0
X-Received: by 10.50.78.234 with SMTP id e10mr19943406igx.32.1459424291262; Thu, 31 Mar 2016 04:38:11 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Thu, 31 Mar 2016 04:38:11 -0700 (PDT)
In-Reply-To: <56FC0A65.5060602@gmail.com>
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>  <56FC0720.5090204@nist.gov> <56FC0A65.5060602@gmail.com>
Date: Thu, 31 Mar 2016 12:38:11 +0100
Message-ID: 
From: Ben Laurie 
To: Melinda Shore 
Content-Type: multipart/alternative; boundary=089e013c65e07598ef052f56b207
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 11:38:14 -0000

--089e013c65e07598ef052f56b207
Content-Type: text/plain; charset=UTF-8

On 30 March 2016 at 18:18, Melinda Shore  wrote:

> We have working group agreement that the attack described
> by DKG needs to be documented and included in the threat
> draft.  The draft is not going to back into working group
> last call without it, period.
>

I should reiterate that this is _not_ an attack on CT, but on RFC 5280. Is
our document the right place for it?

--089e013c65e07598ef052f56b207
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



--089e013c65e07598ef052f56b207--


From nobody Thu Mar 31 04:41:54 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F3A12D5A2 for ; Thu, 31 Mar 2016 04:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTK86rTm9TGV for ; Thu, 31 Mar 2016 04:41:50 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 2D58112D127 for ; Thu, 31 Mar 2016 04:41:50 -0700 (PDT)
Received: by mail-ig0-x235.google.com with SMTP id cl4so124226614igb.0 for ; Thu, 31 Mar 2016 04:41:50 -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; bh=+q9tzOzW0zKseSNZCh0Sygq70MNgZaY/ohhnziUznjE=; b=V4Emdn8tOhK2q+PeseST2dEQu6x2ficIIdMxB347tVe3h+SCT8o8QpvzhkjwkgWndW MbQkafWVxafXys1HU+K1SeLdyzB5PKsKw39Gb27AeFZji3/l2T+A/CWYqpl3qmDOoFLD h2d82aqxeGhTGSOhzWWmB15o7wgIBX2ra51EW2Sb1TkL+4YxDEoZrtGdpF/NhAgjXAGo R6p76KwfwJt81knPNQjg0UAZc/ZqD1kbZX4RESviTvmA9pkAO6KRGpNHtoW/O8bq3eBH zmTQrHQxL3AB9tzgyu9Bo/gJFrzm8imurfbhb/HjoJerRxZ2uyzst/0VYqgaJHcagTua sLyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+q9tzOzW0zKseSNZCh0Sygq70MNgZaY/ohhnziUznjE=; b=msWR+VEjCitse4S4vj9hvKiw4E+ol4MGihULpQlPl2u0c7g5mEnDPWR8ewdcptxLAZ ASe14T7IbRf75Qvmu1C5d6V01BOu/WRIBNpMFh7zzyVayT8MoS+fvAsNZwEB2jS511wy pdK2YaYT9uE8Zmf0B63nEJ0fVQeqiHT98CMgSvrwQZDt5T9DUXK8hcZgNcWRXGs99iSE Nt3c95kMOcjo4/hKkDAnQvZyd/B2BY9zsXljvvsJ+A/JAd3zSdibEAplBmZLQBFSZqjA n4FcQvlBvik6leh0rjdjZ6FPRIDt/Vg2MT7XCmYwQQfaU485JQeWzz+6YInItIjPpHBP QKXw==
X-Gm-Message-State: AD7BkJIzzoL/TA01HWDx0lRog4tuAj42WHz4nak41ag7uM05p9POLfzRD+8+a2NBogViDoFbR8BDC2d762NXOmls
MIME-Version: 1.0
X-Received: by 10.50.78.234 with SMTP id e10mr19962966igx.32.1459424509357; Thu, 31 Mar 2016 04:41:49 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Thu, 31 Mar 2016 04:41:49 -0700 (PDT)
In-Reply-To: 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>  
Date: Thu, 31 Mar 2016 12:41:49 +0100
Message-ID: 
From: Ben Laurie 
To: Carl Wallace 
Content-Type: multipart/alternative; boundary=089e013c65e0754321052f56bf73
Archived-At: 
Cc: "David A. Cooper" , "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 11:41:53 -0000

--089e013c65e0754321052f56bf73
Content-Type: text/plain; charset=UTF-8

On 30 March 2016 at 18:31, Carl Wallace  wrote:

>
> From: Trans  on behalf of Ben Laurie <
> benl@google.com>
> Subject: Re: [Trans] text to address DKG's conspiring CAs attack
>
>
>
> On 30 March 2016 at 17:02, David A. Cooper  wrote:
>
>> So, your contention is that PKIX diverged from X.509 by removing the
>> requirement for names to be unambiguous, and did nothing to address the
>> vulnerability created by this divergence other than noting the
>> vulnerability in the Security Considerations sections of its documents? The
>> working group then went on to develop protocols and profiles that relied on
>> names being unambiguous, and then just noted in the Security Considerations
>> that an unnecessary vulnerability had been created? I have even looked for
>> evidence that the PKIX WG discussed the idea of deviating from X.509 and
>> allowing names to be ambiguous (i.e., unrelated entities operating under
>> the same name) and have been unable to find any evidence of that on the
>> mail list. I have, however, heard an explanation for why the text in
>> Section 4.1.2.6 says what it does, and it was not about a deliberate
>> decision to deviate from X.509.
>>
>
> In practice, how would you ensure names were unambiguous? (actually, a
> CT-like mechanism could be used, but CT does rather post-date 5280)
>
>
> You could express name constraints on a trust anchor to prevent re-use of
> the same CA subject name.
>

How would that work? Name constraints only constrain subordinate certs...



> Of course, there are very few implementations of this and none (that I
> know of) in the web PKI and the expression could get long for overpopulated
> TA stores. Details are in 5914 and 5937, as noted in 6818. Using this you
> would just need to make sure there are no overlaps in your TA store.
>

AFAIK, all modern browsers support name constraints. But perhaps that's not
what you meant?


>
>
> The vulnerability is also mitigated by requiring AIA in the EE
> certificate, which the BRs do. Arguably, 5280 should also.
>
>
> How does an AIA help? AIAs could be suppressed or mis-populated and path
> building may use artifacts previously download from a different AIA.
>

If the AIA is in the end cert, then it is unambiguous how that cert is
revoked.



>
>
> BTW, in case it is not clear, I do agree with Steve that 5280 does not
> require global uniqueness.
>
>

--089e013c65e0754321052f56bf73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 30 March 2016 at 18:31, Carl Wallace <carl@redhoundsoftwa=
re.com> wrote:

From:  Trans <trans-bounces@ietf.org> on behalf of =
Ben Laurie <benl@go=
ogle.com>
Subje=
ct:  Re: [Trans] text to address DKG's conspiring CAs attack
=




On 30 March 2016 at =
17:02, David A. Cooper <david.cooper@nist.gov> wrote:

 =20
   =20
 =20
  

    
So, your contention is that PKIX
      diverged from X.509 by removing the requirement for names to be
      unambiguous, and did nothing to address the vulnerability created
      by this divergence other than noting the vulnerability in the
      Security Considerations sections of its documents? The working
      group then went on to develop protocols and profiles that relied
      on names being unambiguous, and then just noted in the Security
      Considerations that an unnecessary vulnerability had been created?
      I have even looked for evidence that the PKIX WG discussed the
      idea of deviating from X.509 and allowing names to be ambiguous
      (i.e., unrelated entities operating under the same name) and have
      been unable to find any evidence of that on the mail list. I have,
      however, heard an explanation for why the text in Section 4.1.2.6
      says what it does, and it was not about a deliberate decision to
      deviate from X.509.

I=
n practice, how would you ensure names were unambiguous? (actually, a CT-li=
ke mechanism could be used, but CT does rather post-date 5280)
<=
/span>

You could express=
 name constraints on a trust anchor to prevent re-use of the same CA subjec=
t name.

How would that work? Na=
me constraints only constrain subordinate certs...

=C2=A0
 O=
f course, there are very few implementations of this and none (that I know =
of) in the web PKI and the expression could get long for overpopulated TA s=
tores. Details are in 5914 and 5937, as noted in 6818. Using this you would=
 just need to make sure there are no overlaps in your TA store.=C2=A0
=


AFAIK, all modern browsers support n=
ame constraints. But perhaps that's not what you meant?
=C2=
=A0


The vulnerability is also =
mitigated by requiring AIA in the EE certificate, which the BRs do. Arguabl=
y, 5280 should also.

How does an AIA help? AIAs could be suppressed or mis-popul=
ated and path building may use artifacts previously download from a differe=
nt AIA.=C2=A0

If the AIA is in =
the end cert, then it is unambiguous how that cert is revoked.
=C2=A0


BTW, in ca=
se it is not clear, I do agree with Steve that 5280 does not require global=
 uniqueness.






--089e013c65e0754321052f56bf73--


From nobody Thu Mar 31 04:52:04 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D517312D0F5 for ; Thu, 31 Mar 2016 04:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE4jS3cojzpb for ; Thu, 31 Mar 2016 04:52:00 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C2D12D0C9 for ; Thu, 31 Mar 2016 04:52:00 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id a129so103123478ioe.0 for ; Thu, 31 Mar 2016 04:52:00 -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; bh=t3Ug5xPv6Lrxg1oxOAVoJF0QJOdLaP5Fghcfwps/htQ=; b=JAgC3baPqZfHcJRmuLj7ZLRPHyJ3M8qItT9w+bs9FAWU7Q2rZN9APmK7E6J6RR7bD5 NI80xjWaIoXwCZL+gwuBFnVZ9wvejbru5/9S4rocMx5ynQbKzBkf2H8fV0cYOZh7bl/J UhylkWKbLEQ99mnj5fZUpR/RlVmjqH5i2ClI35BcJJEqcDvO0RczN9B6muaiKMjPOMw+ Ib7B2hWIzKFRo8KK8+6glA9RsUK3ZiqNf6DSPUqU/zE+XzQgx3uoSsLYK2ffAPPtFukE pjECQUhB+fO2G18UDVoZ1Rf2403JG4O1TT5TVNMkFuxnDKl1CuEpToXukst7jBoZ08ZC tOnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=t3Ug5xPv6Lrxg1oxOAVoJF0QJOdLaP5Fghcfwps/htQ=; b=DYNGIiAKRUVxizuzZjLOK3jJGTwEdMmekTIgQyFYHzF3zIK6JNFfQlLYjMByPpoCTO yMmaf8qBu/kxW0BqTzw+jCMErMH+mqnsBuuhb4x4iZVRGd9ysYOJCh4D+YvumJgYRiWE HDxOCUbq7Orvo5iWxYDAUOvHKtntCVhd9LRKGjLReGQ6QSMSz0dwmF6+IGwPX9ZhHtOG GdUFi/DGRNDPIIauHly0BBgCKQUqNGjnR4fjG1kSGBEbguJf5du4O1dObvz4H05YdUZt Me9zvUZlYSAma7dTHNaz9QBt9h3r/a5JXij/7GxO3AaHhgwP5yV1dXR4whdmu6+CMSpx QFOg==
X-Gm-Message-State: AD7BkJLFYd9CH6hhSrL57SMivpxloBrCHKMaEM/bnvxDQrRTlYjVO5y58urBNeKx/eKUuGK7Kv0U/EzSIl4gM3Ur
MIME-Version: 1.0
X-Received: by 10.107.41.133 with SMTP id p127mr2553783iop.172.1459425119679;  Thu, 31 Mar 2016 04:51:59 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Thu, 31 Mar 2016 04:51:59 -0700 (PDT)
In-Reply-To: <56FC1C9E.4030605@nist.gov>
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>  <56FC1C9E.4030605@nist.gov>
Date: Thu, 31 Mar 2016 12:51:59 +0100
Message-ID: 
From: Ben Laurie 
To: "David A. Cooper" 
Content-Type: multipart/alternative; boundary=001a1137b81cd63ade052f56e3b3
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 11:52:03 -0000

--001a1137b81cd63ade052f56e3b3
Content-Type: text/plain; charset=UTF-8

On 30 March 2016 at 19:36, David A. Cooper  wrote:

> I provided rather detailed evidence that RFC 5280 does require global name
> uniqueness. Can you explain why my evidence is wrong?
>

As far as I can work out, your evidence is that RFC 5280 _ought_ to have
required global name uniqueness, not that it _does_. I haven't seen you
quote anything from RFC 5280 that requires it.


> How does the text in Section 6.3 of RFC 5280 ensure that a CRL issued by
> one CA isn't used to determine the status of certificates issued by an
> unrelated CA issuing certificates under the same name if both can be
> validated from the same trust anchor?
>

It doesn't.


>
> I have been explaining what RFC 5280 says (and what X.509 says). I have
> not been trying to justify that it was a correct design decision, so
> there's no need for me to answer the question about how one would ensure
> names are unambiguous.
>
> You are free to agree with Steve that RFC 5280 *shouldn't* have required
> names to be globally unambiguous, but that doesn't change the fact that (as
> I have shown) RFC 5280 and other PKIX documents were written in a way that
> things don't work unless names are globally unambiguous.
>

I don't agree with Steve that RFC 5280 *shouldn't* have required names to
be globally unambiguous, because AFAICS it doesn't.

I also don't agree that RFC 5280 was written s.t. it doesn't work unless
names are globally unambiguous - there is at least one other solution to
the problem, as I've pointed out.


> If RFC 5280 didn't require names to be unambiguous, why didn't the text in
> Section 6.3.3 address the problem I mentioned above by requiring that the
> certification path for a CRL be the same as for the certificate whose
> status is being checked (or at least require that the list of CA names in
> the paths be the same)? Again, you can agree with Steve that something like
> that *should* have been done, but where's the evidence that it was done?
>

I am not saying there is any evidence it was done.


>
> Dave
>
> P.S. It would really be helpful if this discussion thread could end. It's
> not relevant to TRANS, and there would be no reason to discuss it at all in
> this group if there wasn't an attempt to include text about it in one of
> the TRANS documents.
>

Agreed.


>
>
> On 03/30/2016 01:15 PM, Ben Laurie wrote:
>
> On 30 March 2016 at 17:02, David A. Cooper  wrote:
>
>> So, your contention is that PKIX diverged from X.509 by removing the
>> requirement for names to be unambiguous, and did nothing to address the
>> vulnerability created by this divergence other than noting the
>> vulnerability in the Security Considerations sections of its documents? The
>> working group then went on to develop protocols and profiles that relied on
>> names being unambiguous, and then just noted in the Security Considerations
>> that an unnecessary vulnerability had been created? I have even looked for
>> evidence that the PKIX WG discussed the idea of deviating from X.509 and
>> allowing names to be ambiguous (i.e., unrelated entities operating under
>> the same name) and have been unable to find any evidence of that on the
>> mail list. I have, however, heard an explanation for why the text in
>> Section 4.1.2.6 says what it does, and it was not about a deliberate
>> decision to deviate from X.509.
>>
>
> In practice, how would you ensure names were unambiguous? (actually, a
> CT-like mechanism could be used, but CT does rather post-date 5280)
>
> The vulnerability is also mitigated by requiring AIA in the EE
> certificate, which the BRs do. Arguably, 5280 should also.
>
> BTW, in case it is not clear, I do agree with Steve that 5280 does not
> require global uniqueness.
>
>
>

--001a1137b81cd63ade052f56e3b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable







=



      

      On 03/30/2016 01:15 PM, Ben Laurie wrote:

    

    

     =20
      
On 30 March 2016 at 17:02, David A. Cooper <dav=
id.cooper@nist.gov>
        wrote:

        

          

            

              

                
So, your contention is that PKIX diverged from
                  X.509 by removing the requirement for names to be
                  unambiguous, and did nothing to address the
                  vulnerability created by this divergence other than
                  noting the vulnerability in the Security
                  Considerations sections of its documents? The working
                  group then went on to develop protocols and profiles
                  that relied on names being unambiguous, and then just
                  noted in the Security Considerations that an
                  unnecessary vulnerability had been created? I have
                  even looked for evidence that the PKIX WG discussed
                  the idea of deviating from X.509 and allowing names to
                  be ambiguous (i.e., unrelated entities operating under
                  the same name) and have been unable to find any
                  evidence of that on the mail list. I have, however,
                  heard an explanation for why the text in Section
                  4.1.2.6 says what it does, and it was not about a
                  deliberate decision to deviate from X.509.

                

              

            

            


            

            
In practice, how would you ensure names were
              unambiguous? (actually, a CT-like mechanism could be used,
              but CT does rather post-date 5280)

            


            

            
The vulnerability is also mitigated by requiring AIA in
              the EE certificate, which the BRs do. Arguably, 5280
              should also.

            


            

            
BTW, in case it is not clear, I do agree with Steve
              that 5280 does not require global uniqueness.

            
=C2=A0

          

        

      

    

  






--001a1137b81cd63ade052f56e3b3--


From nobody Thu Mar 31 05:12:27 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E570E12D13D for ; Thu, 31 Mar 2016 05:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhFI6TsgC51V for ; Thu, 31 Mar 2016 05:12:23 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287CD12D0DA for ; Thu, 31 Mar 2016 05:12:23 -0700 (PDT)
Received: by mail-ig0-x22b.google.com with SMTP id ma7so91752687igc.0 for ; Thu, 31 Mar 2016 05:12:23 -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; bh=Qx2bU9TH+EtP9yZE+NREWv5UKhzkHEt+ogu40lCUJzY=; b=a0icjZkawfE+C0L9oGX+ugbZLAv/mAKrDxoD7WmdaZPzeuM1tRXBAytFA26XWCa+lK KLWUnEpYjU3ETK0RP6GfkMhJBo2BbXuva8tNzzOv9tE+21CYPe23w/3KIs/naIn1mFEh JL515zxSKMiH+ydr0gRgII/Y/TZn5rt/pKuBmMZrTzf2bKYhVV4t97QVhcBzrllQZZar JhWTa0Xcv8Ygbl6I8PXtEZz/Ksn84apEKfoMnysUJGJZjjc60NwizC/KPPTVPKuvEKio /g74zoZpkKj9ccPJMgSe27It3VQar/3BVpZwefCl9y1zaYuII50M+SbIVxn/LqczIiaC qV4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Qx2bU9TH+EtP9yZE+NREWv5UKhzkHEt+ogu40lCUJzY=; b=dGT9DtsuBLQ4+w2PyNgIaEFyzrR44frrCq6gslfh/BjdAJkPJinV9fnpfNNJgu5HU0 SkVsPPh1v+ocx2ijVFkxBT2LA3moAiOCYx7nIMuFe4Y7ivx4DjSZWFtoesV7ItoCMDsr MhWhocUW0pe0sfD92MGpgaR+L3t1TdWBk1+HEqJ3FQlfmoU1S1QcGn46MG+kt3VlUEum QmBdUoj/rwdM9tj2l0VkRT6MnSocrYw6EoR7tyTO67k7YpBvpKBXpzCUqAKwsVmgodjh 92Ucdi7M2Af/Qt1bKqNiI+hrzyh9cKH1sdIgEyu5+m2waGndIDILl+pVMnJq/dT+01RR 5BcA==
X-Gm-Message-State: AD7BkJKF83HYY3p1UzEVV1Y0PrG5Zvg00STK9H/P8CBLowPTNE2rAnTUzNpUGgdvaKMzFkImUU+m9f9zIrSa/8PH
MIME-Version: 1.0
X-Received: by 10.50.50.234 with SMTP id f10mr2528011igo.37.1459426342226; Thu, 31 Mar 2016 05:12:22 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Thu, 31 Mar 2016 05:12:22 -0700 (PDT)
In-Reply-To: <56FBE1C5.1080301@bbn.com>
References: <56F4039B.2020604@bbn.com>  <56FBE1C5.1080301@bbn.com>
Date: Thu, 31 Mar 2016 13:12:22 +0100
Message-ID: 
From: Ben Laurie 
To: Stephen Kent 
Content-Type: multipart/alternative; boundary=047d7bd75b22b4d4ce052f572c1e
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] updated Section 3.3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 12:12:25 -0000

--047d7bd75b22b4d4ce052f572c1e
Content-Type: text/plain; charset=UTF-8

On 30 March 2016 at 15:25, Stephen Kent  wrote:

> Ben,
>
>
> ...
>
>> If the CA that logged the bogus certificate fails to revoke it, browser
>> vendors might blacklist the certificate. However, as noted above, the
>> doppelganger, which was not logged, will match the SCT created for the
>> logged certificate. If remediation is effected by blacklisting (instead of
>> revocation by one of the malicious CAs) then the ability of CT to deal with
>> this sort of attack may be diminished.
>>
>
> Once more, this problem is not CT's problem - it is a problem with RFC
> 5280 et al. That is, the problem exists regardless of the existence or use
> of CT.
>
> I assume we agree that the issue is not whether inclusion of the AIA
> extension in all EE certs
> should be a MUST in 5280, right?
>

Right.


> Is your point that no standard specifies in detail how to manage
> revocation status data? If so, then this lack of detail applies not only
> to CRLs and OCSP but
> also to browser blacklists, so it's not just a 5280 issue.
>
> In any case, the discussion is an analysis of attacks in the context of
> CT, so to that
> extent it is a CT issue.
>
> Does this mean 5280 should be updated?
>
> I think not. As I noted in prior messages, 5820 is the general PKI spec
> for Internet use of X.509 certs.
> There is not always a need to mandate inclusion of AIA, hence it's
> optional. It's appropriate to
> profile 5280 for specific application contexts, like the Web PKI. There
> was an IETF WG that was
> trying to characterize that context (WPKOPS) but it failed.
>

It seems to me 5280 should at least explain the threat and potential
mitigations (I assume that were you think AIA is not needed has some other
mitigation that should also be documented).


>
>
> Steve
>

--047d7bd75b22b4d4ce052f572c1e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 30 March 2016 at 15:25, Stephen Kent <kent@bbn.com> wrot=
e:

 =20
   =20
 =20
  

    Ben,

    

    


    

    

      
...

        

          

            

              

                
 If


                            the CA that logged the bogus certificate
                            fails to revoke it, browser vendors might
                            blacklist the certificate. However, as noted
                            above, the doppelganger, which was not
                            logged, will match the SCT created for the
                            logged certificate. If remediation is
                            effected by blacklisting (instead of
                            revocation by one of the malicious CAs) then
                            the ability of CT to deal with this sort of
                            attack may be diminished.=


              

            

            


            

            
Once more, this problem is not CT's problem - it is a
              problem with RFC 5280 et al. That is, the problem exists
              regardless of the existence or use of CT.

          

        

      

    

    I assume we agree that the issue is not whether inclusion of the AIA
    extension in all EE certs

    should be a MUST in 5280, right?

=
Right.
=C2=A0
 Is your point that no standard
    specifies in detail how to manage 

    revocation status data? If so, then this lack of detail applies not
    only to CRLs and OCSP but

    also to browser blacklists, so it's not just a 5280 issue.

    

    In any case, the discussion is an analysis of attacks in the context
    of CT, so to that

    extent it is a CT issue.

    

    

      

        

          

            
Does this mean 5280 should be updated? 

          

        

      

    

    I think not. As I noted in prior messages, 5820 is the general PKI
    spec for Internet use of X.509 certs.

    There is not always a need to mandate inclusion of AIA, hence it's
    optional. It's appropriate to 

    profile 5280 for specific application contexts, like the Web PKI.
    There was an IETF WG that was

    trying to characterize that context (WPKOPS) but it failed.

It seems to me 5280 should at least explain the =
threat and potential mitigations (I assume that were you think AIA is not n=
eeded has some other mitigation that should also be documented).
=
=C2=A0
 

    

    Steve

  






--047d7bd75b22b4d4ce052f572c1e--


From nobody Thu Mar 31 05:14:16 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9C12D5E8 for ; Thu, 31 Mar 2016 05:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=redhoundsoftware-com.20150623.gappssmtp.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 Q9x5Gzalzi_D for ; Thu, 31 Mar 2016 05:14:11 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d: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 502FB12D5E9 for ; Thu, 31 Mar 2016 05:14:11 -0700 (PDT)
Received: by mail-qg0-x22a.google.com with SMTP id y89so62929921qge.2 for ; Thu, 31 Mar 2016 05:14:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=L59O0WRLPLXyRqwv69eNRYIDfr7eM76wNAhNQ022Ec0=; b=sQivPKrWIgWhR23CKIyvFwUyq1JT9Zb8LsCHSa5R0fS25yzewG8jXbHV2bvbJt/DLs yJE7jaCfCoa+NQBgH3iJfw91YdC7k8S4GgzHLOleKQIQk8ESg+g/gOv/8rg8Co+SvROH fa47leauwn22gApuMWfZLE7RAmTFbD05wsf4WkhouiA9mClW453MN/87sqOIyAetPOU7 h8Z6eDUp1ZY68BLUxpBnCPFZGAzZJ/4p/uKbMgqYjtoQ5AUJHEIDfnj3bBUPezzntEem GiPJ25SSvVIM7EzmBC20AO1R1iC3copT1c+HgxuUXFsn2BVMXEOHqcZdqCJUuKMtrLss TPjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=L59O0WRLPLXyRqwv69eNRYIDfr7eM76wNAhNQ022Ec0=; b=cZBjLzl+MoGNElrzs0C/d8G3VYm8hsi6gC0b7jsKt8S1OCOmHnUa8F5BQJHBB1AA4O 9nl3hrifw+rMt/P2S/ZxWb9nSKPS69/qAnXL2cNuI5Q/sKJq8YkRj4+Yi7UiR2hHy8Il XCPsh0Sg6HbgbozzvS3TpegeEsDWESiGJukPM6oEXjN96uIOlhVfeAPW5GgZYkv01O8l oYSLtRkR5mVsSowfbubjiTTtmbNaTtIf2aJdNYajb9fZEa8s9gunELL9Wljy0Fc8IRzi 8FNmHCn2LqUKoLDQl9E1tpGA0ZcEPZb8fTinEHKFtqkXTrNBfaCDrf9FCJkAx2J3c8oj UCGA==
X-Gm-Message-State: AD7BkJIrO+5NCAn7poSd+Xyczx831QUgqLBypMt0pxennIAqA6p0vdSz8/oWGspfiCHBLw==
X-Received: by 10.140.82.20 with SMTP id g20mr15652523qgd.69.1459426450161; Thu, 31 Mar 2016 05:14:10 -0700 (PDT)
Received: from [192.168.2.30] (pool-96-255-23-4.washdc.fios.verizon.net. [96.255.23.4]) by smtp.gmail.com with ESMTPSA id z130sm3762508qhc.28.2016.03.31.05.14.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2016 05:14:09 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Thu, 31 Mar 2016 08:14:04 -0400
From: Carl Wallace 
To: Ben Laurie 
Message-ID: 
Thread-Topic: [Trans] text to address DKG's conspiring CAs attack
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>   
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3542256847_7756391"
Archived-At: 
Cc: "David A. Cooper" , "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 12:14:14 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3542256847_7756391
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit


From:  Ben Laurie 
Date:  Thursday, March 31, 2016 at 7:41 AM
To:  Carl Wallace 
Cc:  "David A. Cooper" , "trans@ietf.org"
, Stephen Kent 
Subject:  Re: [Trans] text to address DKG's conspiring CAs attack

> 
> 
> On 30 March 2016 at 18:31, Carl Wallace  wrote:
>> 
>> From:  Trans  on behalf of Ben Laurie
>> 
>> Subject:  Re: [Trans] text to address DKG's conspiring CAs attack
>> 
>>> 
>>> 
>>> On 30 March 2016 at 17:02, David A. Cooper  wrote:
>>>>     
>>>>  
>>>> So, your contention is that PKIX diverged from X.509 by removing the
>>>> requirement for names to be unambiguous, and did nothing to address the
>>>> vulnerability created by this divergence other than noting the
>>>> vulnerability in the Security Considerations sections of its documents? The
>>>> working group then went on to develop protocols and profiles that relied on
>>>> names being unambiguous, and then just noted in the Security Considerations
>>>> that an unnecessary vulnerability had been created? I have even looked for
>>>> evidence that the PKIX WG discussed the idea of deviating from X.509 and
>>>> allowing names to be ambiguous (i.e., unrelated entities operating under
>>>> the same name) and have been unable to find any evidence of that on the
>>>> mail list. I have, however, heard an explanation for why the text in
>>>> Section 4.1.2.6 says what it does, and it was not about a deliberate
>>>> decision to deviate from X.509.
>>> 
>>> In practice, how would you ensure names were unambiguous? (actually, a
>>> CT-like mechanism could be used, but CT does rather post-date 5280)
>> 
>> You could express name constraints on a trust anchor to prevent re-use of the
>> same CA subject name.
> 
> How would that work? Name constraints only constrain subordinate certs...

All CA certs are subordinate to trust anchors. RFC5914 defines how to
associate name constraints with a TA. RFC5937 defines how to use those
constraints to provide inputs to a 5280 compliant validation engine so they
apply across a certification path. The attack (as I followed it early on in
this thread) required two CAs to have the same subject name in an
arrangement like this:

  A -> A_X -> C

  B -> B_X -> C

If B was defined with an excluded name constraint asserting subject name
from A_X, then the B_X certificate with that name could not be validated.
This mechanism is used when validating client certificates presented during
mutually authenticated TLS within the US Federal PKI, where the names are
sufficiently hierarchical that the name constraints expression is not
terribly verbose. In the implementation I am familiar with, the
TrustAnchorInfo option from 5914 is used exclusively, with self-signed root
certs wrapped by a structure that asserts the name constraints (or policy
constraints). B could also be defined with permitted name constraints that
align with CAs it legitimately issues.

The validation rules are straightforward. Once you build a path, you use the
constraints from the trust anchor to set the inputs to the 5280 validation
algorithm. So the name constraints from the TA would be used to populate the
permitted_subtrees or excluded_subtrees input variables defined in 5280. As
long as you can store/use the alternative TA structure, any 5280 compliant
validation engine can be used for processing (since the mechanism only
manipulates inputs to the validation algorithm, not internal details).

> 
>  
>>  Of course, there are very few implementations of this and none (that I know
>> of) in the web PKI and the expression could get long for overpopulated TA
>> stores. Details are in 5914 and 5937, as noted in 6818. Using this you would
>> just need to make sure there are no overlaps in your TA store.
> 
> AFAIK, all modern browsers support name constraints. But perhaps that's not
> what you meant?

I meant use of name constraints associated with a TA.

>  
>> 
>>> 
>>> The vulnerability is also mitigated by requiring AIA in the EE certificate,
>>> which the BRs do. Arguably, 5280 should also.
>> 
>> How does an AIA help? AIAs could be suppressed or mis-populated and path
>> building may use artifacts previously download from a different AIA.
> 
> If the AIA is in the end cert, then it is unambiguous how that cert is
> revoked.

OK, I was focused on the caIssuers AIA. How does that help, though? The X
key could either sign OCSP responses itself or sign an OCSP responder cert
that could be used to provide the desired revocation results.




--B_3542256847_7756391
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



From:  Ben Laurie <benl@google.com>
Date:  Thursday, March 31, 2016 at 7:41 AM
To:=
  Carl Wallace <carl@re=
dhoundsoftware.com>
Cc:  "Da=
vid A. Cooper" <david.cooper@nist.=
gov>, "trans@ietf.org" <trans@ietf.org>, Stephen Kent <kent@bbn.com>
=
Subject:  Re: [Trans] text to address DKG's conspiring CAs attack
=




On 30 March=
 2016 at 18:31, Carl Wallace <carl@redhoundsoftware.com> wro=
te:

<=
div style=3D"font-family:Calibri;font-size:11pt;text-align:left;color:black;BO=
RDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-L=
EFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium n=
one;PADDING-TOP:3pt">From:  Trans <=
trans-bounces@ietf.o=
rg> on behalf of Ben Laurie <benl@google.com>
Subject:  Re: [Trans] text to address DKG's conspiring CAs a=
ttack



On 30 March 2016 at 17:0=
2, David A. Cooper <david.cooper@nist.gov> wrote:

  
    
  
  

    
So, your contention is that PKIX
      diverged from X.509 by removing the requirement for names to be
      unambiguous, and did nothing to address the vulnerability created
      by this divergence other than noting the vulnerability in the
      Security Considerations sections of its documents? The working
      group then went on to develop protocols and profiles that relied
      on names being unambiguous, and then just noted in the Security
      Considerations that an unnecessary vulnerability had been created?
      I have even looked for evidence that the PKIX WG discussed the
      idea of deviating from X.509 and allowing names to be ambiguous
      (i.e., unrelated entities operating under the same name) and have
      been unable to find any evidence of that on the mail list. I have,
      however, heard an explanation for why the text in Section 4.1.2.6
      says what it does, and it was not about a deliberate decision to
      deviate from X.509.

I=
n practice, how would you ensure names were unambiguous? (actually, a CT-lik=
e mechanism could be used, but CT does rather post-date 5280)

You could express na=
me constraints on a trust anchor to prevent re-use of the same CA subject na=
me.

How would that work? Name co=
nstraints only constrain subordinate certs...

All CA certs are subordinate to tru=
st anchors. RFC5914 defines how to associate name constraints with a TA. RFC=
5937 defines how to use those constraints to provide inputs to a 5280 compli=
ant validation engine so they apply across a certification path. The attack =
(as I followed it early on in this thread) required two CAs to have the same=
 subject name in an arrangement like this:

  A -> A_X -> C

  B -> B_X -> C

If B was defined with an ex=
cluded name constraint asserting subject name from A_X, then the B_X certifi=
cate with that name could not be validated. This mechanism is used when vali=
dating client certificates presented during mutually authenticated TLS withi=
n the US Federal PKI, where the names are sufficiently hierarchical that the=
 name constraints expression is not terribly verbose. In the implementation =
I am familiar with, the TrustAnchorInfo option from 5914 is us=
ed exclusively, with self-signed root certs wrapped by a structure that asse=
rts the name constraints (or policy constraints). B could also be defined wi=
th permitted name constraints that align with CAs it legitimately issues.

The validation rules are straight=
forward. Once you build a path, you use the constraints from the trust ancho=
r to set the inputs to the 5280 validation algorithm. So the name constraint=
s from the TA would be used to populate the permitted_subtrees or excluded_s=
ubtrees input variables defined in 5280. As long as you can store/use the al=
ternative TA structure, any 5280 compliant validation engine can be used for=
 processing (since the mechanism only manipulates inputs to the validation a=
lgorithm, not internal details).


<=
/div>
 
 O=
f course, there are very few implementations of this and none (that I know o=
f) in the web PKI and the expression could get long for overpopulated TA sto=
res. Details are in 5914 and 5937, as noted in 6818. Using this you would ju=
st need to make sure there are no overlaps in your TA store. 

AFAIK, all modern browsers support name c=
onstraints. But perhaps that's not what you meant?

I meant use of name constraint=
s associated with a TA. 

=

 


<=
/div>
The vulnerability is also mitigated by requiring AIA in the EE cer=
tificate, which the BRs do. Arguably, 5280 should also.

How does an AIA help? AIAs=
 could be suppressed or mis-populated and path building may use artifacts pr=
eviously download from a different AIA. 
<=
br>
If the AIA is in the end cert, then it is unambiguous how that=
 cert is revoked.

OK, I was focused on the caIssuers AIA. How does that help, tho=
ugh? The X key could either sign OCSP responses itself or sign an OCSP respo=
nder cert that could be used to provide the desired revocation results.



--B_3542256847_7756391--



From nobody Thu Mar 31 06:59:04 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EAA12D621 for ; Thu, 31 Mar 2016 06:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r5MQvV6WOPq for ; Thu, 31 Mar 2016 06:59:01 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 A3C2E12D0EC for ; Thu, 31 Mar 2016 06:58:31 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id q128so112757561iof.3 for ; Thu, 31 Mar 2016 06:58:31 -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; bh=SdEK8Ntb7zeVvLnWTQrkCmuAMD2oHYjsuxtcsOu56X0=; b=AaiUAMcSg3Jsx847P72yNvQ1uzMudCjfaVNK3+7pmKrwbEsa0bfgVQdItfKnHYJQP6 eRsfuL9zcb6I2XDCH2RDQGJtuIdJ0ZCro/U3RGuBs9L3JsPUrzy9g8idKEBgDGPr9HJH w7Gq9vQ/vbIueX0fCG0tkkJiiKtkOn7RkPLGPtiTpgVZQ7StHFaxoG60iUXwMPFzMlX/ Fai2/Xu42SP8hEsBqIjrDgsjvTjqCCitkBEAsI5Vpqvx6y62cFhUtghBSw9NqGk02GMO wJ6QbGgOwE/EuuAsV+0AAwlARdcpjD5b5pZ2IoXiNOpx4tbSzcRvwqxjOCFJpIGVZpqP COeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SdEK8Ntb7zeVvLnWTQrkCmuAMD2oHYjsuxtcsOu56X0=; b=dFdu5WeKnWQv6SUaqbJZxLo5brJIExvnHIgyjLWi25I+ZiwHtRnTgueCT0/PFMsKMt 2/fF5qfKmVG8rOKLZFKFkYkCDcHDAsW/1C+c0+QjeJxa4k6i4uEdtUVWzffCAL5SzHSM 75RPixyy7JbCP+3uEPYGcBU6TwdW5TKX+muTToYpMn+5cM3gjFbJ46evLxoK8iTQ6u1S 72GScReaC47upD/udsHrftG0weVfDbiyPEAj+F8vjoxlN3m1sgWsuIgU212Z11/eNEPw ylgCGQA4QIf6Wd5Am3HC1sMR8hvefw58INIQSu20H8p6bbxltGbT4ZMEusyxzfgGut9T fojw==
X-Gm-Message-State: AD7BkJLbst6wr7ETRPHeJ0+oJAS4vAz7YVjEsfYsn07iYeVKgZng/Dnzshu5zQod0TQPwJjlAQA5E8Yf02wLYSrB
MIME-Version: 1.0
X-Received: by 10.107.41.133 with SMTP id p127mr3297443iop.172.1459432710921;  Thu, 31 Mar 2016 06:58:30 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Thu, 31 Mar 2016 06:58:30 -0700 (PDT)
In-Reply-To: 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>    
Date: Thu, 31 Mar 2016 14:58:30 +0100
Message-ID: 
From: Ben Laurie 
To: Carl Wallace 
Content-Type: multipart/alternative; boundary=001a1137b81c4f3556052f58a8d0
Archived-At: 
Cc: "David A. Cooper" , "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 13:59:03 -0000

--001a1137b81c4f3556052f58a8d0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 31 March 2016 at 13:14, Carl Wallace  wrote:

>
> From: Ben Laurie 
> Date: Thursday, March 31, 2016 at 7:41 AM
> To: Carl Wallace 
> Cc: "David A. Cooper" , "trans@ietf.org" <
> trans@ietf.org>, Stephen Kent 
> Subject: Re: [Trans] text to address DKG's conspiring CAs attack
>
>
>
> On 30 March 2016 at 18:31, Carl Wallace  wrote=
:
>
>>
>> From: Trans  on behalf of Ben Laurie <
>> benl@google.com>
>> Subject: Re: [Trans] text to address DKG's conspiring CAs attack
>>
>>
>>
>> On 30 March 2016 at 17:02, David A. Cooper  wrote=
:
>>
>>> So, your contention is that PKIX diverged from X.509 by removing the
>>> requirement for names to be unambiguous, and did nothing to address the
>>> vulnerability created by this divergence other than noting the
>>> vulnerability in the Security Considerations sections of its documents?=
 The
>>> working group then went on to develop protocols and profiles that relie=
d on
>>> names being unambiguous, and then just noted in the Security Considerat=
ions
>>> that an unnecessary vulnerability had been created? I have even looked =
for
>>> evidence that the PKIX WG discussed the idea of deviating from X.509 an=
d
>>> allowing names to be ambiguous (i.e., unrelated entities operating unde=
r
>>> the same name) and have been unable to find any evidence of that on the
>>> mail list. I have, however, heard an explanation for why the text in
>>> Section 4.1.2.6 says what it does, and it was not about a deliberate
>>> decision to deviate from X.509.
>>>
>>
>> In practice, how would you ensure names were unambiguous? (actually, a
>> CT-like mechanism could be used, but CT does rather post-date 5280)
>>
>>
>> You could express name constraints on a trust anchor to prevent re-use o=
f
>> the same CA subject name.
>>
>
> How would that work? Name constraints only constrain subordinate certs...
>
>
> All CA certs are subordinate to trust anchors.
>

Surely not? Surely many of them are trust anchors?



> RFC5914 defines how to associate name constraints with a TA. RFC5937
> defines how to use those constraints to provide inputs to a 5280 complian=
t
> validation engine so they apply across a certification path. The attack (=
as
> I followed it early on in this thread) required two CAs to have the same
> subject name in an arrangement like this:
>
>   A -> A_X -> C
>
>   B -> B_X -> C
>
>
> If B was defined with an excluded name constraint asserting subject name =
from A_X, then the B_X certificate with that name could not be validated. T=
his mechanism is used when validating client certificates presented during =
mutually authenticated TLS within the US Federal PKI, where the names are s=
ufficiently hierarchical that the name constraints expression is not terrib=
ly verbose. In the implementation I am familiar with, the TrustAnchorInfo o=
ption from 5914 is used exclusively, with self-signed root certs wrapped by=
 a structure that asserts the name constraints (or policy constraints). B c=
ould also be defined with permitted name constraints that align with CAs it=
 legitimately issues.
>
>
> The validation rules are straightforward. Once you build a path, you use =
the constraints from the trust anchor to set the inputs to the 5280 validat=
ion algorithm. So the name constraints from the TA would be used to populat=
e the permitted_subtrees or excluded_subtrees input variables defined in 52=
80. As long as you can store/use the alternative TA structure, any 5280 com=
pliant validation engine can be used for processing (since the mechanism on=
ly manipulates inputs to the validation algorithm, not internal details).
>
>
>
>
>
>> Of course, there are very few implementations of this and none (that I
>> know of) in the web PKI and the expression could get long for overpopula=
ted
>> TA stores. Details are in 5914 and 5937, as noted in 6818. Using this yo=
u
>> would just need to make sure there are no overlaps in your TA store.
>>
>
> AFAIK, all modern browsers support name constraints. But perhaps that's
> not what you meant?
>
>
> I meant use of name constraints associated with a TA.
>
>
>
>>
>>
>> The vulnerability is also mitigated by requiring AIA in the EE
>> certificate, which the BRs do. Arguably, 5280 should also.
>>
>>
>> How does an AIA help? AIAs could be suppressed or mis-populated and path
>> building may use artifacts previously download from a different AIA.
>>
>
> If the AIA is in the end cert, then it is unambiguous how that cert is
> revoked.
>
>
> OK, I was focused on the caIssuers AIA. How does that help, though? The X
> key could either sign OCSP responses itself or sign an OCSP responder cer=
t
> that could be used to provide the desired revocation results.
>
>
That is a different attack. And is why you also need Revocation
Transparency. :-)

--001a1137b81c4f3556052f58a8d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 31 March 2016 at 13:14, Carl Wallace <carl@redhoundsoftwa=
re.com> wrote:

From:  Ben Laurie <benl@google.com>
Date:  Thursday, March 31, 2016 at 7:41 AM
=
To:  Carl Wallace <carl@redhoundsoftware.com=
>
Cc:  "David A. Coo=
per" <da=
vid.cooper@nist.gov>, "trans@ietf.org" <trans@ietf.org>, Stephen Kent <kent@bbn.com>
=
Subject:  Re: [Trans] text to addre=
ss DKG's conspiring CAs attack


On 30 March 2016 at 18:31, Carl Wallace <carl@re=
dhoundsoftware.com> wrote:
=


From:  Trans <trans-bounces@ietf.org> on be=
half of Ben Laurie <benl@google.com>
Subject:=
  Re: [Trans] text to address DKG's conspiring CAs attack



On 30 March 2016 at 17:02, David A=
. Cooper <david.cooper@nist.gov> wrote:

 =20
   =20
 =20
  

    
So, your contention is that PKIX
      diverged from X.509 by removing the requirement for names to be
      unambiguous, and did nothing to address the vulnerability created
      by this divergence other than noting the vulnerability in the
      Security Considerations sections of its documents? The working
      group then went on to develop protocols and profiles that relied
      on names being unambiguous, and then just noted in the Security
      Considerations that an unnecessary vulnerability had been created?
      I have even looked for evidence that the PKIX WG discussed the
      idea of deviating from X.509 and allowing names to be ambiguous
      (i.e., unrelated entities operating under the same name) and have
      been unable to find any evidence of that on the mail list. I have,
      however, heard an explanation for why the text in Section 4.1.2.6
      says what it does, and it was not about a deliberate decision to
      deviate from X.509.

I=
n practice, how would you ensure names were unambiguous? (actually, a CT-li=
ke mechanism could be used, but CT does rather post-date 5280)
<=
/span>

You could express=
 name constraints on a trust anchor to prevent re-use of the same CA subjec=
t name.

How would that work? Na=
me constraints only constrain subordinate certs...
<=
/blockquote>

All CA certs are subordinate to t=
rust anchors.

Surely not? Surel=
y many of them are trust anchors?

=C2=A0
 RFC591=
4 defines how to associate name constraints with a TA. RFC5937 defines how =
to use those constraints to provide inputs to a 5280 compliant validation e=
ngine so they apply across a certification path. The attack (as I followed =
it early on in this thread) required two CAs to have the same subject name =
in an arrangement like this:

  A -> A_X=
 -> C

  B -> B_X -> C

=

If B was defined with an excl=
uded name constraint asserting subject name from A_X, then the B_X certific=
ate with that name could not be validated. This mechanism is used when vali=
dating client certificates presented during mutually authenticated TLS with=
in the US Federal PKI, where the names are sufficiently hierarchical that t=
he name constraints expression is not terribly verbose. In the implementati=
on I am familiar with, the TrustAnchorInfo option from 5914 i=
s used exclusively, with self-signed root certs wrapped by a structure that=
 asserts the name constraints (or policy constraints). B could also be defi=
ned with permitted name constraints that align with CAs it legitimately iss=
ues.

The validation rules =
are straightforward. Once you build a path, you use the constraints from th=
e trust anchor to set the inputs to the 5280 validation algorithm. So the n=
ame constraints from the TA would be used to populate the permitted_subtree=
s or excluded_subtrees input variables defined in 5280. As long as you can =
store/use the alternative TA structure, any 5280 compliant validation engin=
e can be used for processing (since the mechanism only manipulates inputs t=
o the validation algorithm, not internal details).


=C2=A0
 Of course, there are very f=
ew implementations of this and none (that I know of) in the web PKI and the=
 expression could get long for overpopulated TA stores. Details are in 5914=
 and 5937, as noted in 6818. Using this you would just need to make sure th=
ere are no overlaps in your TA store.=C2=A0
AFAIK, all modern browsers support name constraints. But perha=
ps that's not what you meant?

I meant use of name constraints associated with a =
TA.=C2=A0

=C2=A0

=


The vulnerability is also mitigated by requiring AIA =
in the EE certificate, which the BRs do. Arguably, 5280 should also.
<=
/div>

How does an=
 AIA help? AIAs could be suppressed or mis-populated and path building may =
use artifacts previously download from a different AIA.=C2=A0

If the AIA is in the end cert, then it is un=
ambiguous how that cert is revoked.

OK, I was focused on the caIssuers AIA. How does=
 that help, though? The X key could either sign OCSP responses itself or si=
gn an OCSP responder cert that could be used to provide the desired revocat=
ion results.




That is a different=
 attack. And is why you also need Revocation Transparency. :-)



--001a1137b81c4f3556052f58a8d0--


From nobody Thu Mar 31 07:21:49 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952C312D150 for ; Thu, 31 Mar 2016 07:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=redhoundsoftware-com.20150623.gappssmtp.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 zL52-GYUBrmQ for ; Thu, 31 Mar 2016 07:21:47 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FCE12D0D8 for ; Thu, 31 Mar 2016 07:21:46 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id s5so32585147qkd.0 for ; Thu, 31 Mar 2016 07:21:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=9587k3y8YcOIl3P39V8QIeQXPsE2a5LmgNyRgxcuqUg=; b=EjtQFDJaz/vfaGl4kKVfzOmEo08vAgIUpgKLdc/4vq6agJI+Z3bpYcUYsOM2W/c13B crTaafZx7duDRCWSePSADO4fmF9hclZI+suR2cJ8YG29Yzf/+2nosIFH2DgpkqlO5TX4 GWMUJ+/6YxFzycNWQTFkh8wkU93vHO/OhbHw33YoVtJCRXc+s5CYi10K7Zo6H6QeXIW9 hQJrJX7UKEJWalYn+0cMj5a0ne4sHbvZkwbP/4aG79O74Ag5u5HgIrPm2Etj21YGd2uI oTTl1tpT15LxTTyajNqeun0kHFWb6MyhsAMcf5avTws0Fv/QrI2KyTP59RlP1MwRV5vf bl8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=9587k3y8YcOIl3P39V8QIeQXPsE2a5LmgNyRgxcuqUg=; b=AUk991ypkZBjPoBDX98OtelzxgAFy1CAClehHtAQ1Z3R0draUUUFVq759HWzpq7yDX x14VnoeaGoiyPLIDSxsoLpq8hU/+LelqsCP0dlKcK1RBC3wah7Ibs/uPQq9mtbFt+jnr 3dHdnmSl3fKuyRgfdLiG2FmnocisSSjI/gF4cjoaF+olr2iN53e+QsSqZwvt4fBRhYMv eCbcuZQw8TiJQm4oMIRk6WbNeF/n+McI9SuLHNtvvqIe3ZDKI6tPNMqiSGwWPo5W4LH3 ho2flWZbpuewQYA3WpXsdVEHwE1gPVxPa39q5yHDHB/g0teo6qox62on2b24T35RhFmb 3zVg==
X-Gm-Message-State: AD7BkJITTH2xeaKdTLyr39O/Ftt/T0UraJwjBUn4oCE+MxTFPMEmtrz5v8UqdrMRY5sdSw==
X-Received: by 10.55.24.82 with SMTP id j79mr16531635qkh.92.1459434105935; Thu, 31 Mar 2016 07:21:45 -0700 (PDT)
Received: from [192.168.2.30] (pool-96-255-23-4.washdc.fios.verizon.net. [96.255.23.4]) by smtp.gmail.com with ESMTPSA id b69sm4036239qka.2.2016.03.31.07.21.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2016 07:21:44 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Thu, 31 Mar 2016 10:21:27 -0400
From: Carl Wallace 
To: Ben Laurie 
Message-ID: 
Thread-Topic: [Trans] text to address DKG's conspiring CAs attack
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>     
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3542264500_8212299"
Archived-At: 
Cc: "David A. Cooper" , "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 14:21:48 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3542264500_8212299
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit

>>> 
>>> 
>>> How would that work? Name constraints only constrain subordinate certs...
>> 
>> All CA certs are subordinate to trust anchors.
> 
> Surely not? Surely many of them are trust anchors?

OK, but the name constraints asserted in a TA as passed in validation would
still be enforced.





--B_3542264500_8212299
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



<snip>
How would=
 that work? Name constraints only constrain subordinate certs...
=


All CA certs are subordinat=
e to trust anchors.

Surely not? =
Surely many of them are trust anchors?
<=
/span>

OK, but the name constraints asserted in a TA as p=
assed in validation would still be enforced.

<snip>


--B_3542264500_8212299--



From nobody Thu Mar 31 08:15:59 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61512D1A3 for ; Thu, 31 Mar 2016 08:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level: 
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma8igPS5qh4a for ; Thu, 31 Mar 2016 08:15:56 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116B812D150 for ; Thu, 31 Mar 2016 08:15:55 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 31 Mar 2016 11:17:13 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Thu, 31 Mar 2016 11:15:52 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2VFFded027331;	Thu, 31 Mar 2016 11:15:40 -0400
To: Ben Laurie 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>  <56FC1C9E.4030605@nist.gov> 
From: "David A. Cooper" 
Message-ID: <56FD3F1B.6000900@nist.gov>
Date: Thu, 31 Mar 2016 11:15:39 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner-Information: 
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 15:15:59 -0000


  
    
  
  
    
You seem to contradict yourself. You
      say you disagree with my assertion that RFC 5280 as written
      doesn't work unless names are globally unambiguous, and then you
      try to support your disagreement by saying that "there is at least
      one other solution to the problem." So, you acknowledge
      that if RFC 5280 didn't require names to be globally unambiguous,
      then there would be a problem, and then suggest how RFC 5280 could
        be changed to address that problem.

      

      Even Steve Kent acknowledges this:

      
Yes, the Security Considerations section
        of 5280 notes that problems that can arise if names are not
        globally unique. However, that is not the same as saying that
        5280 requires them to be so. Rather it is a warning of the bad
        things that may happen if name collisions occur. A warning in
        the Security Considerations section the way we usually note a
        residual vulnerability in a standard. It is NOT a backdoor way
        to add a requirement to a standard.

      

      If you and Steve were correct that RFC 5280 didn't require names
      to be globally unambiguous, then (as I've shown) relying parties
      could obtain incorrect results even if all of the CAs, OCSP
      responders, etc., in the PKI were behaving honestly in accordance
      with the standard. That isn't residual security risk to documented
      in the Security Considerations section. That is a design flaw in
      the protocol that should have prevented the document from becoming
      an RFC. Are you and Steve really saying that the PKIX WG
      deliberating chose to introduce a design flaw into RFC 5280 (and
      RFC 5755 and other PKIX documents) by deviating from X.509? Why
      would the PKIX WG co-chairs allow this?

      

      I also disagree that you've pointed out "at least one other
      solution to the problem." The only things I've seen you suggest is
      that "the vulnerability is also mitigated by requiring AIA in the
      EE certificate." I can only guess what that means. Do you mean
      require an AIA extension with the id-ad-ocsp access method in the
      EE certificate? Would you simultaneously be forbidding the use of
      CRLs? What about CA certificates? How would the AIA extension fix
      the problem with attribute certificates (RFC 5755) that I
      highlighted?

      

      Need further evidence of the RFC 5280 requirement? RFC 5280 says:

      
Section 4.1.2.4: The issuer
          field identifies the entity that has signed and issued the
          certificate.  The issuer field MUST contain a non-empty
          distinguished name (DN).  The issuer field is defined as the
          X.501 type Name [X.501].

          

          Section 4.1.2.6: The subject field is defined as the X.501
          type Name.  Implementation requirements for this field are
          those defined for the issuer field (Section 4.1.2.4).

      

      How does X.509 define the Name type:

      
A (directory) name is a construct that
        identifies a particular object from among the set of all
        objects. A name shall be
          unambiguous, that is, denotes just one object. However,
        a name need not be unique, that is, be the only name that
        unambiguously denotes the object.

      

      

      So, RFC 5280 says that the issuer and subject fields in
      certificates as defined as the X.501 type Name, and point to X.501
      for the definition of Name, which defines Name to be something
      that is unambiguous.

      

      I'm sure some will argue that RFC 5280 only intended to adopt some
      aspects of the definition of Name from X.501, and not this part of
      the definition. However, there is nothing in RFC 5280 to support
      that. And, you still can't get around the problem that if RFC 5280
      didn't require names to be unambiguous, then as it is currently
      written, it and other PKIX documents would be flawed by design.

      

      On 03/31/2016 07:51 AM, Ben Laurie wrote:

    

    

      
      
On 30 March 2016 at 19:36, David A. Cooper <david.cooper@nist.gov>
        wrote:

        

          

            

              

                
I provided rather detailed evidence that RFC 5280
                  does require global name uniqueness. Can you explain
                  why my evidence is wrong?

              

            

            


            

            
As far as I can work out, your evidence is that RFC
              5280 _ought_ to have required global name uniqueness, not
              that it _does_. I haven't seen you quote anything from RFC
              5280 that requires it.

            
 

            

              

                
 How does the text in Section 6.3 of RFC 5280
                  ensure that a CRL issued by one CA isn't used to
                  determine the status of certificates issued by an
                  unrelated CA issuing certificates under the same name
                  if both can be validated from the same trust anchor?

                

              

            

            


            

            
It doesn't.

            
 

            

              

                
 

                  I have been explaining what RFC 5280 says (and what
                  X.509 says). I have not been trying to justify that it
                  was a correct design decision, so there's no need for
                  me to answer the question about how one would ensure
                  names are unambiguous.

                  

                  You are free to agree with Steve that RFC 5280 shouldn't
                  have required names to be globally unambiguous, but
                  that doesn't change the fact that (as I have shown)
                  RFC 5280 and other PKIX documents were written in a
                  way that things don't work unless names are globally
                  unambiguous.

                

              

            

            


            

            
I don't agree with Steve that RFC 5280 shouldn't have
              required names to be globally unambiguous, because AFAICS
              it doesn't.

            


            

            
I also don't agree that RFC 5280 was written s.t. it
              doesn't work unless names are globally unambiguous - there
              is at least one other solution to the problem, as I've
              pointed out.

            


            

            

              

                
 

                  If RFC 5280 didn't require names to be unambiguous,
                  why didn't the text in Section 6.3.3 address the
                  problem I mentioned above by requiring that the
                  certification path for a CRL be the same as for the
                  certificate whose status is being checked (or at least
                  require that the list of CA names in the paths be the
                  same)? Again, you can agree with Steve that something
                  like that should have been done, but where's
                  the evidence that it was done?

                

              

            

            


            

            
I am not saying there is any evidence it was done.

            
 

            

              

                
 

                  Dave

                  

                  P.S. It would really be helpful if this discussion
                  thread could end. It's not relevant to TRANS, and
                  there would be no reason to discuss it at all in this
                  group if there wasn't an attempt to include text about
                  it in one of the TRANS documents.

              

            

            


            

            
Agreed.

            
 

            

              

                


                    

                    On 03/30/2016 01:15 PM, Ben Laurie wrote:

                  

                
                  

                    
On 30 March 2016 at 17:02, David A.
                      Cooper <david.cooper@nist.gov>
                      wrote:

                      

                        

                          

                            

                              
So, your contention is that PKIX
                                diverged from X.509 by removing the
                                requirement for names to be unambiguous,
                                and did nothing to address the
                                vulnerability created by this divergence
                                other than noting the vulnerability in
                                the Security Considerations sections of
                                its documents? The working group then
                                went on to develop protocols and
                                profiles that relied on names being
                                unambiguous, and then just noted in the
                                Security Considerations that an
                                unnecessary vulnerability had been
                                created? I have even looked for evidence
                                that the PKIX WG discussed the idea of
                                deviating from X.509 and allowing names
                                to be ambiguous (i.e., unrelated
                                entities operating under the same name)
                                and have been unable to find any
                                evidence of that on the mail list. I
                                have, however, heard an explanation for
                                why the text in Section 4.1.2.6 says
                                what it does, and it was not about a
                                deliberate decision to deviate from
                                X.509.

                              

                            

                          

                          


                          

                          
In practice, how would you ensure names
                            were unambiguous? (actually, a CT-like
                            mechanism could be used, but CT does rather
                            post-date 5280)

                          


                          

                          
The vulnerability is also mitigated by
                            requiring AIA in the EE certificate, which
                            the BRs do. Arguably, 5280 should also.

                          


                          

                          
BTW, in case it is not clear, I do agree
                            with Steve that 5280 does not require global
                            uniqueness.

                          
 

                        

                      

                    

                  

                

            

          

          

        

      

    

    

  



From nobody Thu Mar 31 08:31:01 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDFA12D551 for ; Thu, 31 Mar 2016 08:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level: 
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nerkHHLWUG0x for ; Thu, 31 Mar 2016 08:30:56 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA2A12D0F8 for ; Thu, 31 Mar 2016 08:30:56 -0700 (PDT)
Received: by mail-ig0-x22a.google.com with SMTP id ui10so60879655igc.1 for ; Thu, 31 Mar 2016 08:30:56 -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; bh=YqIr1eHf3IQJw7hxH4MopKuJo3BTw8b/DRfLvxcNg/0=; b=oRDG5Mt0CsRuUlMWojHop7RXIJWAzeiKOrY6GoQDrjUGNXJxdaSPUAMDfFsG9JQ/mu UT16wgpw+lIgHumKLBGZoEweb7apZqV53QTE+Xm3TfqEtfAchj8Th8ejECG3CU4lZnGK cAOdvehbBDC6QZjU0Kr+POfafkUS5Mz0hMUWfYuK2QcQDqgAq1L2Rs28b4G+6iHnYoXq yt/2Tf4atUNIUSVCYanuFA7gg8k8TIw6nLUbuniFqgwBgDUZ3ZLyOzQVHtPJOkYUbt6r foAYhfyJZWxSnJ9bTzW+Yjo2YbnKEYZOPWiSeaQsLv4LicDgKuifigu7KVvCfdEHEexB GLMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YqIr1eHf3IQJw7hxH4MopKuJo3BTw8b/DRfLvxcNg/0=; b=RFK+KPIEtD0asSopHuIE14HT1XAoMP+IADq92NOb3UghbZJ1tEZesn6S+Gh5Z+WDp5 IH2i4lYP+PPqjKlgoPmrGCbr3V7pSMVSyTD8dRLQkTVCgMoRqtlfoXLgAV+MyZ4MRUgz MdNUiYtyYco4DMXids8mx/Uo0AK/u2BJlfLK+46F/QU3OVN9QxhfNF6dAiNHCEXeGlgL 69fh5AWV3H+TCEZHRYvHNgxo+uyro/IXScKbwAJ4rdOjOr81hJ1OAKKCjuOzrr0IvBbT BF1Lgf5XUW2qkYCOSUj3vsxgjUIe0us+LcGYv4PISTvn6d/dlUoLxLbglGwUzP2v2RfN vCrQ==
X-Gm-Message-State: AD7BkJJ/m4bPZif9nKdS5HOrRjFm9GuG0M2XykJ7NqKTmU84cgyrv6n7WSxud2Op/5SEO2Hk+/oZpk4NNzx8eNV/
MIME-Version: 1.0
X-Received: by 10.50.225.106 with SMTP id rj10mr28017981igc.23.1459438255490;  Thu, 31 Mar 2016 08:30:55 -0700 (PDT)
Received: by 10.64.245.105 with HTTP; Thu, 31 Mar 2016 08:30:55 -0700 (PDT)
In-Reply-To: <56FD3F1B.6000900@nist.gov>
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>  <56FC1C9E.4030605@nist.gov>  <56FD3F1B.6000900@nist.gov>
Date: Thu, 31 Mar 2016 16:30:55 +0100
Message-ID: 
From: Ben Laurie 
To: "David A. Cooper" 
Content-Type: multipart/alternative; boundary=001a11c39aa6cab4d0052f59f2f0
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 15:30:59 -0000

--001a11c39aa6cab4d0052f59f2f0
Content-Type: text/plain; charset=UTF-8

On 31 March 2016 at 16:15, David A. Cooper  wrote:

> You seem to contradict yourself. You say you disagree with my assertion
> that RFC 5280 as written doesn't work unless names are globally
> unambiguous, and then you try to support your disagreement by saying that
> "there is at least one other solution to the *problem*." So, you
> acknowledge that if RFC 5280 didn't require names to be globally
> unambiguous, then there would be a problem,
>

I do, but I also assert that it does not require names to be unambiguous.


> and then suggest how RFC 5280 *could be changed* to address that problem.
>
> Even Steve Kent acknowledges this:
>
> Yes, the Security Considerations section of 5280 notes that problems that
> can arise if names are not globally unique. However, that is not the same
> as saying that 5280 requires them to be so. Rather it is a warning of the
> bad things that may happen if name collisions occur. A warning in the
> Security Considerations section the way we usually note a residual
> vulnerability in a standard. It is NOT a backdoor way to add a requirement
> to a standard.
>
>
> If you and Steve were correct that RFC 5280 didn't require names to be
> globally unambiguous, then (as I've shown) relying parties could obtain
> incorrect results even if all of the CAs, OCSP responders, etc., in the PKI
> were behaving honestly in accordance with the standard.
>

I agree!


> That isn't residual security risk to documented in the Security
> Considerations section. That is a design flaw in the protocol that should
> have prevented the document from becoming an RFC. Are you and Steve really
> saying that the PKIX WG deliberating chose to introduce a design flaw into
> RFC 5280 (and RFC 5755 and other PKIX documents) by deviating from X.509?
> Why would the PKIX WG co-chairs allow this?
>

I am not saying anything of the sort. I am just observing that the flaw
exists.


>
>

> I also disagree that you've pointed out "at least one other solution to
> the problem." The only things I've seen you suggest is that "the
> vulnerability is also mitigated by requiring AIA in the EE certificate." I
> can only guess what that means. Do you mean require an AIA extension with
> the id-ad-ocsp access method in the EE certificate?
>

Yes.


> Would you simultaneously be forbidding the use of CRLs?
>

Specifying the CRL endpoint would also fix the problem.


> What about CA certificates?
>

What about them?


> How would the AIA extension fix the problem with attribute certificates
> (RFC 5755) that I highlighted?
>

I don't know. Are you saying it wouldn't? I don't really know anything
about 5755.


>
> Need further evidence of the RFC 5280 requirement? RFC 5280 says:
>
> Section 4.1.2.4: The issuer field identifies the entity that has signed
> and issued the certificate.  The issuer field MUST contain a non-empty
> distinguished name (DN).  The issuer field is defined as the X.501 type
> Name [X.501].
>
> Section 4.1.2.6: The subject field is defined as the X.501 type Name.
> Implementation requirements for this field are those defined for the issuer
> field (Section 4.1.2.4).
>
> How does X.509 define the Name type:
>
> A *(directory) name* is a construct that identifies a particular object
> from among the set of all objects. A name shall be unambiguous, that is,
> denotes just one object. However, a name need not be unique, that is, be
> the only name that unambiguously denotes the object.
>
>
> So, RFC 5280 says that the issuer and subject fields in certificates as
> defined as the X.501 type Name, and point to X.501 for the definition of
> Name, which defines Name to be something that is unambiguous.
>
> I'm sure some will argue that RFC 5280 only intended to adopt some aspects
> of the definition of Name from X.501, and not this part of the definition.
> However, there is nothing in RFC 5280 to support that. And, you still can't
> get around the problem that if RFC 5280 didn't require names to be
> unambiguous, then as it is currently written, it and other PKIX documents
> would be flawed by design.
>

Interesting.

OK, for the sake of argument, let's assume that RFC 5280 does require names
to be unambiguous. Now what? There is no mechanism in place to prevent (or
even detect) ambiguity - that seems like a problem. Furthermore, what
happens when it turns out a name is ambiguous? Presumably that makes all
certs containing that name not 5280 compliant?


>
>
> On 03/31/2016 07:51 AM, Ben Laurie wrote:
>
> On 30 March 2016 at 19:36, David A. Cooper  wrote:
>
>> I provided rather detailed evidence that RFC 5280 does require global
>> name uniqueness. Can you explain why my evidence is wrong?
>>
>
> As far as I can work out, your evidence is that RFC 5280 _ought_ to have
> required global name uniqueness, not that it _does_. I haven't seen you
> quote anything from RFC 5280 that requires it.
>
>
>> How does the text in Section 6.3 of RFC 5280 ensure that a CRL issued by
>> one CA isn't used to determine the status of certificates issued by an
>> unrelated CA issuing certificates under the same name if both can be
>> validated from the same trust anchor?
>>
>
> It doesn't.
>
>
>>
>> I have been explaining what RFC 5280 says (and what X.509 says). I have
>> not been trying to justify that it was a correct design decision, so
>> there's no need for me to answer the question about how one would ensure
>> names are unambiguous.
>>
>> You are free to agree with Steve that RFC 5280 *shouldn't* have required
>> names to be globally unambiguous, but that doesn't change the fact that (as
>> I have shown) RFC 5280 and other PKIX documents were written in a way that
>> things don't work unless names are globally unambiguous.
>>
>
> I don't agree with Steve that RFC 5280 *shouldn't* have required names to
> be globally unambiguous, because AFAICS it doesn't.
>
> I also don't agree that RFC 5280 was written s.t. it doesn't work unless
> names are globally unambiguous - there is at least one other solution to
> the problem, as I've pointed out.
>
>
>> If RFC 5280 didn't require names to be unambiguous, why didn't the text
>> in Section 6.3.3 address the problem I mentioned above by requiring that
>> the certification path for a CRL be the same as for the certificate whose
>> status is being checked (or at least require that the list of CA names in
>> the paths be the same)? Again, you can agree with Steve that something like
>> that *should* have been done, but where's the evidence that it was done?
>>
>
> I am not saying there is any evidence it was done.
>
>
>>
>> Dave
>>
>> P.S. It would really be helpful if this discussion thread could end. It's
>> not relevant to TRANS, and there would be no reason to discuss it at all in
>> this group if there wasn't an attempt to include text about it in one of
>> the TRANS documents.
>>
>
> Agreed.
>
>
>>
>>
>> On 03/30/2016 01:15 PM, Ben Laurie wrote:
>>
>> On 30 March 2016 at 17:02, David A. Cooper < 
>> david.cooper@nist.gov> wrote:
>>
>>> So, your contention is that PKIX diverged from X.509 by removing the
>>> requirement for names to be unambiguous, and did nothing to address the
>>> vulnerability created by this divergence other than noting the
>>> vulnerability in the Security Considerations sections of its documents? The
>>> working group then went on to develop protocols and profiles that relied on
>>> names being unambiguous, and then just noted in the Security Considerations
>>> that an unnecessary vulnerability had been created? I have even looked for
>>> evidence that the PKIX WG discussed the idea of deviating from X.509 and
>>> allowing names to be ambiguous (i.e., unrelated entities operating under
>>> the same name) and have been unable to find any evidence of that on the
>>> mail list. I have, however, heard an explanation for why the text in
>>> Section 4.1.2.6 says what it does, and it was not about a deliberate
>>> decision to deviate from X.509.
>>>
>>
>> In practice, how would you ensure names were unambiguous? (actually, a
>> CT-like mechanism could be used, but CT does rather post-date 5280)
>>
>> The vulnerability is also mitigated by requiring AIA in the EE
>> certificate, which the BRs do. Arguably, 5280 should also.
>>
>> BTW, in case it is not clear, I do agree with Steve that 5280 does not
>> require global uniqueness.
>>
>>
>>
>
>

--001a11c39aa6cab4d0052f59f2f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 31 March 2016 at 16:15, David A. Cooper <david.cooper@nist.gov<=
/a>> wrote:

 =20
   =20
 =20
  

    
You seem to contradict yourself. You
      say you disagree with my assertion that RFC 5280 as written
      doesn't work unless names are globally unambiguous, and then you
      try to support your disagreement by saying that "there is at lea=
st
      one other solution to the problem." So, you acknowledge
      that if RFC 5280 didn't require names to be globally unambiguous,
      then there would be a problem, 

I do, but I also assert that it does not require names to be unambig=
uous.
=C2=A0
and then suggest how RFC 5280 could
        be changed to address that problem.

      

      Even Steve Kent acknowledges this:

      
Yes, the Security Considerations section
        of 5280 notes that problems that can arise if names are not
        globally unique. However, that is not the same as saying that
        5280 requires them to be so. Rather it is a warning of the bad
        things that may happen if name collisions occur. A warning in
        the Security Considerations section the way we usually note a
        residual vulnerability in a standard. It is NOT a backdoor way
        to add a requirement to a standard.

      

      If you and Steve were correct that RFC 5280 didn't require names
      to be globally unambiguous, then (as I've shown) relying parties
      could obtain incorrect results even if all of the CAs, OCSP
      responders, etc., in the PKI were behaving honestly in accordance
      with the standard.

I agre=
e!
=C2=A0
 That isn't residual security risk to d=
ocumented
      in the Security Considerations section. That is a design flaw in
      the protocol that should have prevented the document from becoming
      an RFC. Are you and Steve really saying that the PKIX WG
      deliberating chose to introduce a design flaw into RFC 5280 (and
      RFC 5755 and other PKIX documents) by deviating from X.509? Why
      would the PKIX WG co-chairs allow this?
=

I am not saying anything of the sort. I am just observing th=
at the flaw exists.
=C2=A0
=C2=A0
<=
div>
      

      I also disagree that you've pointed out "at least one other
      solution to the problem." The only things I've seen you sugg=
est is
      that "the vulnerability is also mitigated by requiring AIA in th=
e
      EE certificate." I can only guess what that means. Do you mean
      require an AIA extension with the id-ad-ocsp access method in the
      EE certificate?

Yes.
=C2=A0
 Would you simultaneously be forbidding the use of
      CRLs?

Specifying the CRL =
endpoint would also fix the problem.
=C2=A0
 What about C=
A certificates?

What about them=
?
=C2=A0
 How would the AIA extension fix
      the problem with attribute certificates (RFC 5755) that I
      highlighted?

I don=
9;t know. Are you saying it wouldn't? I don't really know anything =
about 5755.
=C2=A0

      

      Need further evidence of the RFC 5280 requirement? RFC 5280 says:

      
Section 4.1.2.4: The issuer
          field identifies the entity that has signed and issued the
          certificate.=C2=A0 The issuer field MUST contain a non-empty
          distinguished name (DN).=C2=A0 The issuer field is defined as the
          X.501 type Name [X.501].

          

          Section 4.1.2.6:=
 The subject field is defined as the X.501
          type Name.=C2=A0 Implementation requirements for this field are
          those defined for the issuer field (Section 4.1.2.4).

      

      How does X.509 define the Name type:

      
A (directory) name is a construct that
        identifies a particular object from among the set of all
        objects.=C2=A0A name shall be
          unambiguous, that is, denotes just one object. However,
        a name need not be unique, that is, be the only name that
        unambiguously denotes the object.

      

      

      So, RFC 5280 says that the issuer and subject fields in
      certificates as defined as the X.501 type Name, and point to X.501
      for the definition of Name, which defines Name to be something
      that is unambiguous.

      

      I'm sure some will argue that RFC 5280 only intended to adopt som=
e
      aspects of the definition of Name from X.501, and not this part of
      the definition. However, there is nothing in RFC 5280 to support
      that. And, you still can't get around the problem that if RFC 528=
0
      didn't require names to be unambiguous, then as it is currently
      written, it and other PKIX documents would be flawed by design.
=


Interesting.

OK, for the sake of argument, let's assume that RFC 5280 does require=
 names to be unambiguous. Now what? There is no mechanism in place to preve=
nt (or even detect) ambiguity - that seems like a problem. Furthermore, wha=
t happens when it turns out a name is ambiguous? Presumably that makes all =
certs containing that name not 5280 compliant?
=C2=A0


      

      On 03/31/2016 07:51 AM, Ben Laurie wrote:

    

    

     =20
      
On 30 March 2016 at 19:36, David A. Cooper <dav=
id.cooper@nist.gov>
        wrote:

        

          

            

              

                
I provided rather detailed evidence that RFC 5280
                  does require global name uniqueness. Can you explain
                  why my evidence is wrong?

              

            

            


            

            
As far as I can work out, your evidence is that RFC
              5280 _ought_ to have required global name uniqueness, not
              that it _does_. I haven't seen you quote anything from RF=
C
              5280 that requires it.

            
=C2=A0

            

              

                
 How does the text in Section 6.3 of RFC 5280
                  ensure that a CRL issued by one CA isn't used to
                  determine the status of certificates issued by an
                  unrelated CA issuing certificates under the same name
                  if both can be validated from the same trust anchor?

                

              

            

            


            

            
It doesn't.

            
=C2=A0

            

              

                
 

                  I have been explaining what RFC 5280 says (and what
                  X.509 says). I have not been trying to justify that it
                  was a correct design decision, so there's no need for
                  me to answer the question about how one would ensure
                  names are unambiguous.

                  

                  You are free to agree with Steve that RFC 5280 shouldn=
't
                  have required names to be globally unambiguous, but
                  that doesn't change the fact that (as I have shown)
                  RFC 5280 and other PKIX documents were written in a
                  way that things don't work unless names are globally
                  unambiguous.

                

              

            

            


            

            
I don't agree with Steve that RFC 5280=C2=A0shouldn=
't=C2=A0have
              required names to be globally unambiguous, because AFAICS
              it doesn't.

            


            

            
I also don't agree that RFC 5280 was written s.t. it
              doesn't work unless names are globally unambiguous - ther=
e
              is at least one other solution to the problem, as I've
              pointed out.

            


            

            

              

                
 

                  If RFC 5280 didn't require names to be unambiguous,
                  why didn't the text in Section 6.3.3 address the
                  problem I mentioned above by requiring that the
                  certification path for a CRL be the same as for the
                  certificate whose status is being checked (or at least
                  require that the list of CA names in the paths be the
                  same)? Again, you can agree with Steve that something
                  like that should have been done, but where's
                  the evidence that it was done?

                

              

            

            


            

            
I am not saying there is any evidence it was done.

            
=C2=A0

            

              

                
 

                  Dave

                  

                  P.S. It would really be helpful if this discussion
                  thread could end. It's not relevant to TRANS, and
                  there would be no reason to discuss it at all in this
                  group if there wasn't an attempt to include text abou=
t
                  it in one of the TRANS documents.

              

            

            


            

            
Agreed.

            
=C2=A0

            

              

                


                    

                    On 03/30/2016 01:15 PM, Ben Laurie wrote:

                  

                
                  

                    
On 30 March 2016 at 17:02, David A.
                      Cooper <david.cooper@nist.gov>
                      wrote:

                      

                        

                          

                            

                              
So, your contention is that PKIX
                                diverged from X.509 by removing the
                                requirement for names to be unambiguous,
                                and did nothing to address the
                                vulnerability created by this divergence
                                other than noting the vulnerability in
                                the Security Considerations sections of
                                its documents? The working group then
                                went on to develop protocols and
                                profiles that relied on names being
                                unambiguous, and then just noted in the
                                Security Considerations that an
                                unnecessary vulnerability had been
                                created? I have even looked for evidence
                                that the PKIX WG discussed the idea of
                                deviating from X.509 and allowing names
                                to be ambiguous (i.e., unrelated
                                entities operating under the same name)
                                and have been unable to find any
                                evidence of that on the mail list. I
                                have, however, heard an explanation for
                                why the text in Section 4.1.2.6 says
                                what it does, and it was not about a
                                deliberate decision to deviate from
                                X.509.

                              

                            

                          

                          


                          

                          
In practice, how would you ensure names
                            were unambiguous? (actually, a CT-like
                            mechanism could be used, but CT does rather
                            post-date 5280)

                          


                          

                          
The vulnerability is also mitigated by
                            requiring AIA in the EE certificate, which
                            the BRs do. Arguably, 5280 should also.

                          


                          

                          
BTW, in case it is not clear, I do agree
                            with Steve that 5280 does not require global
                            uniqueness.

                          
=C2=A0

                        

                      

                    

                  

                

            

          

          

        

      

    

    

  






--001a11c39aa6cab4d0052f59f2f0--


From nobody Thu Mar 31 11:38:57 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBF612D098 for ; Thu, 31 Mar 2016 11:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.486
X-Spam-Level: 
X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-u2ktr8swdc for ; Thu, 31 Mar 2016 11:38:53 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA5312D5AB for ; Thu, 31 Mar 2016 11:38:53 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 31 Mar 2016 14:38:07 -0400
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Thu, 31 Mar 2016 14:38:26 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u2VIcJ7v008253;	Thu, 31 Mar 2016 14:38:19 -0400
To: Ben Laurie 
References: <56E6CD30.8070102@bbn.com> <56E822E8.7000704@nist.gov> <56E99C1B.4080602@bbn.com> <56E9A1FF.4050301@nist.gov> <56EAC993.20200@bbn.com> <56EADAA6.6010306@nist.gov> <56F4032F.9030800@bbn.com> <56F57879.5060005@nist.gov> <56FBE1C9.9020000@bbn.com> <56FBF88F.2050407@nist.gov>  <56FC1C9E.4030605@nist.gov>  <56FD3F1B.6000900@nist.gov> 
From: "David A. Cooper" 
Message-ID: <56FD6E9B.2030708@nist.gov>
Date: Thu, 31 Mar 2016 14:38:19 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner-Information: 
Archived-At: 
Cc: "trans@ietf.org" 
Subject: Re: [Trans] text to address DKG's conspiring CAs attack
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Mar 2016 18:38:56 -0000


  
    
  
  
    
On 03/31/2016 11:30 AM, Ben Laurie
      wrote:

    

    

      
      


        
On 31 March 2016 at 16:15, David A.
          Cooper <david.cooper@nist.gov>
          wrote:

          


            

              

                
 I also disagree that you've pointed out "at least
                  one other solution to the problem." The only things
                  I've seen you suggest is that "the vulnerability is
                  also mitigated by requiring AIA in the EE
                  certificate." I can only guess what that means. Do you
                  mean require an AIA extension with the id-ad-ocsp
                  access method in the EE certificate?

              

            

            


            

            
Yes.

          

        

      

    

    

    The id-ad-ocsp access method in AIA just contains an HTTP URI that
    provides information about where an OCSP responder can be found. It
    does nothing to help ensure that the response it authoritative for
    the certificate. That is addressed by other means. Perhaps if PKIX
    were changed to only allow the use of OCSP to distribute status
    information and it imposed (as SHALLs) certain restrictions on the
    validation of OCSP responses, this would avoid the problems that
    name collisions might cause with respect to determining the
    revocation status of a certificate. But, there's a lot more to a PKI
    than just determining whether certificates are revoked.

    

    

      

        

          

            
 

            

              

                
 Would you simultaneously be forbidding the use of
                  CRLs?

              

            

            


            

            
Specifying the CRL endpoint would also fix the problem.

          

        

      

    

    

    I can again only guess what you mean. As with OCSP, including a URL
    in the cRLDistributionPoints extension just provides an (insecure)
    pointer to where a CRL can be found. It doesn't provide any
    security. In order for the URL to provide any additional assurance,
    that same URL would need to appear in a critical
    issuingDistributionPoint extension in the CRL. If it appeared in the
    CRL's IDP extension, then the CRL could only be used if the same
    name (e.g., HTTP URI) appeared in both the CRL's IDP and the
    certificate's CRLDP. But this again relies on names being
    unambiguous, because it wouldn't solve the problem if unrelated
    issuers could use the same names for distribution points.

    

    

      

        

          

            
 

            

              

                
 What about CA certificates?

              

            

            


            

            
What about them?

          

        

      

    

    

    There needs to be a reliable revocation mechanism for all
    certificates, not just EE certificates, and the mechanisms that PKIX
    describes (CRLs and OCSP) are the same for both. So, if something
    needs to be done in EE certificates to make revocation reliable,
    then something needs to be done in CA certificates as well.

    

    

      

        

          

            
 

            

              

                
 How would the AIA extension fix the problem with
                  attribute certificates (RFC 5755) that I highlighted?

                

              

            

            


            

            
I don't know. Are you saying it wouldn't? I don't
              really know anything about 5755.

          

        

      

    

    

    Yes. The problem with attribute certificates has nothing to do with
    revocation. RFC 5755 allows attribute certificates to be issued to
    entities (humans, devices, etc.). How does a relying party know to
    whom (or what) the attribute certificate was issued? The entity to
    which the attribute certificate was issued is identified by
    providing the issuer name and serial number of the entity's public
    key certificate. So, if issuer names are ambiguous, then relying
    parties cannot reliably determine to whom (or to what) an attribute
    certificate has been issued.

    

    

      

        

          

            
 

            

              

                
 Need further evidence of the RFC 5280 requirement?
                  RFC 5280 says:

                  
Section 4.1.2.4: The issuer field
                      identifies the entity that has signed and issued
                      the certificate.  The issuer field MUST contain a
                      non-empty distinguished name (DN).  The issuer
                      field is defined as the X.501 type Name [X.501].

                      

                      Section 4.1.2.6:
                      The subject field is defined as the X.501 type
                      Name.  Implementation requirements for this field
                      are those defined for the issuer field (Section
                      4.1.2.4).

                  

                  How does X.509 define the Name type:

                  
A (directory) name is a construct
                    that identifies a particular object from among the
                    set of all objects. A name shall be
                      unambiguous, that is, denotes just one object.
                    However, a name need not be unique, that is, be the
                    only name that unambiguously denotes the object.

                  

                  

                  So, RFC 5280 says that the issuer and subject fields
                  in certificates as defined as the X.501 type Name, and
                  point to X.501 for the definition of Name, which
                  defines Name to be something that is unambiguous.

                  

                  I'm sure some will argue that RFC 5280 only intended
                  to adopt some aspects of the definition of Name from
                  X.501, and not this part of the definition. However,
                  there is nothing in RFC 5280 to support that. And, you
                  still can't get around the problem that if RFC 5280
                  didn't require names to be unambiguous, then as it is
                  currently written, it and other PKIX documents would
                  be flawed by design.

              

            

            


            

            
Interesting.

            


            

            
OK, for the sake of argument, let's assume that RFC
              5280 does require names to be unambiguous. Now what? There
              is no mechanism in place to prevent (or even detect)
              ambiguity - that seems like a problem. Furthermore, what
              happens when it turns out a name is ambiguous? Presumably
              that makes all certs containing that name not 5280
              compliant?

          

        

      

    

    

    In practice, this just isn't a problem. CAs aren't just arbitrary
    system components. They are trusted entities that operate under
    well-defined policies and practices, and they don't just assign
    simple names for their CAs like "cn=Joe's CA". Just look, for
    example, at the name of the CA that issued the certificate for the
    IETF web site:

    
CN = Starfield Secure Certificate
        Authority - G2, OU = http://certs.starfieldtech.com/repository/,
        O = "Starfield Technologies, Inc.", L = Scottsdale, ST =
        Arizona, C = US

    

    Is some unrelated entity going to issue certificates under that same
    name by accident?

    

    Given the way names are formed, if two entities were found to be
    using the same name, it is far more likely that is was a
    result of one of these entities deliberately trying to impersonate
    the other. That's not a case of names being ambiguous, that's an
    attack. The solution to that (if name constraints don't prevent the
    impersonator's certificate from being validated) is revocation. PKIX
    doesn't deal with the issue of how to detect that there is a
    certificate that should be revoked. But this has nothing to do with
    names. If you have an undetected attacker in your PKI that is
    trusted as a CA, then you have problems regardless of whether the
    PKI standard was developed to mitigate problems associated with
    ambiguous CA names.

    

  



From nobody Thu Mar 31 19:59:02 2016
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565F312D16B for ; Thu, 31 Mar 2016 19:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level: 
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, FUZZY_CPILL=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf3mxIcWS15o for ; Thu, 31 Mar 2016 19:58:59 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E40F12D10C for ; Thu, 31 Mar 2016 19:58:59 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qbmL93HHnz3C5 for ; Fri,  1 Apr 2016 04:58:57 +0200 (CEST)
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 Ve_Ey-MXC7nx for ; Fri,  1 Apr 2016 04:58:55 +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 for ; Fri,  1 Apr 2016 04:58:55 +0200 (CEST)
Received: from [192.168.1.44] (unknown [181.229.86.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 763FB600BAE6 for ; Thu, 31 Mar 2016 22:58:53 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 763FB600BAE6
References: 
From: Paul Wouters 
Content-Type: multipart/alternative; boundary=Apple-Mail-62FDDA24-107C-4976-B33C-6D48AB04005B
X-Mailer: iPhone Mail (13E237)
Message-Id: 
Date: Thu, 31 Mar 2016 23:58:49 -0300
To: trans@ietf.org
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Archived-At: 
Subject: [Trans] Fwd: [Crosspost/FYI] Name redaction in CT logs
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2016 02:59:01 -0000

--Apple-Mail-62FDDA24-107C-4976-B33C-6D48AB04005B
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



Sent from my iPhone

Begin forwarded message:

> From: Ryan Sleevi 
> Date: March 31, 2016 at 23:36:50 GMT-3
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: [Crosspost/FYI] Name redaction in CT logs
>=20
> Given the broad interests and community here, I just wanted to let everyon=
e know that we on the Chrome team are soliciting feedback and thoughts on po=
licies regarding name redaction (aka "hiding the DNS name") in certificates w=
hen logged via Certificate Transparency.
>=20
> This discussion has started at https://groups.google.com/a/chromium.org/d/=
msg/ct-policy/vsTzv8oNcws/g96TSYPjCAAJ , and would like to ask that you post=
 any replies to that list.
>=20
> While this is seeking to form an appropriate Chrome policy, given that suc=
h policies may also end up affecting or informing any Mozilla policies, part=
icularly as support for CT is landing in Firefox, it seemed appropriate to c=
ross-post here to solicit feedback, criticisms, use cases, concerns, etc.
>=20
> Thanks
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

--Apple-Mail-62FDDA24-107C-4976-B33C-6D48AB04005B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




Sent from my iPhone
=

Begin forwarded message:

=
From: Ryan Sleevi <ryan@sleevi.com=
>
Date: March 31, 2016 at 23:36:50 GMT-3
To: mozilla-dev-sec=
urity-policy@lists.mozilla.org
Subject: [Crosspost/FYI] Nam=
e redaction in CT logs

Given the broad interests and community here, I just wanted to=
 let everyone know that we on the Chrome team are soliciting feedback and th=
oughts on policies regarding name redaction (aka "hiding the DNS name") in c=
ertificates when logged via Certificate Transparency.

This discussion has started at https://groups.g=
oogle.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/g96TSYPjCAAJ , and w=
ould like to ask that you post any replies to that list.

While this is seeking to form an appropriate Chrome policy, gi=
ven that such policies may also end up affecting or informing any Mozilla po=
licies, particularly as support for CT is landing in Firefox, it seemed appr=
opriate to cross-post here to solicit feedback, criticisms, use cases, conce=
rns, etc.

Thanks
__________=
_____________________________________
dev-security-policy ma=
iling list
dev-security-policy@lists.mozilla.org
https://lists.mozil=
la.org/listinfo/dev-security-policy
=
=

--Apple-Mail-62FDDA24-107C-4976-B33C-6D48AB04005B--