From nobody Mon Jan 5 07:42:41 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5C61A01BA for ; Mon, 5 Jan 2015 07:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHFh6K_Kxgo4 for ; Mon, 5 Jan 2015 07:42:37 -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 BA4721A0197 for ; Mon, 5 Jan 2015 07:42:37 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:35261 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Y89ng-0004tj-BF; Mon, 05 Jan 2015 10:42:36 -0500 Message-ID: <54AAB0EC.5080007@bbn.com> Date: Mon, 05 Jan 2015 10:42:36 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rob Stradling , trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> In-Reply-To: <54997600.4060506@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/tgLAku6NfSKnxi8syxyGC2789qk Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 05 Jan 2015 15:42:40 -0000 Rob, Happy New Year. > > >>> - stating that the literal string "(PRIVATE)" always covers >>> precisely >>> _one_ label. >> Since DNS names are case insensitive, I suggest we not represent a >> reserved >> label in uppercase. It may cause some readers to believe that the >> label is >> special because of its case. > > The private label _is_ "special" though. :-) > > It's intended to be a placeholder for a real label. I'm not sure what you mean by these two sentences. I hope you don't mean that you expect an RP to treat the uppercase representation as different from lowercase. That would not be consistent with DNS canonicalization rules (as per 1034) and thus not consistent with 5280. If you mean that you plan to replace "PRIVATE" with some other word, which will treated in a case-insensitive fashion, then NEVERMIND. > >>> So for example, if you wanted to redact 3 components, you'd put >>> "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the >>> Precertificate. >>> >>> To reduce bloat, I think we should also change "(PRIVATE)" to "?". >>> e.g. "SAN:dNSName=?.?.?.mydomain.com" >> >> Is "?" a legal DNS label character? It doesn't seem so as per RFC 1034, >> and RFC 5280 cites 1034 as the normative spec for dNSName syntax in >> the subjectAltName extension. > > I agree that "?" is not a valid DNS label character according to RFC > 1034, but that's actually a useful characteristic here. If it was a > valid DNS label character, then it could be mistakenly interpreted as > a real label rather than as just a placeholder! true. > > "*" isn't a valid DNS label character either, and yet it is commonly > used in SAN->dNSName fields as a placeholder. yes, I'm sad to say. PKIX gave into this misuse of DNS syntax because so many CAs adopted the convention. So we added an explicit exception in 5280. I don't think it's a good idea to request another exception. Why not use "*" instead, since that seems semantically appropriate? > > You're referring to this part of RFC5280 Section 4.2.1.6: > "When the subjectAltName extension contains a domain name system > label, the domain name MUST be stored in the dNSName (an IA5String). > The name MUST be in the "preferred name syntax", as specified by > Section 3.5 of [RFC1034] and as modified by Section 2.1 of > [RFC1123]." > > If one or more labels is a placeholder rather than a real label, then > IMHO the string is _not_ a "domain name system label". And therefore, > the two MUST requirements quoted above don't apply. I find this reasoning rather circular; it sounds like you're saying "since we violated the syntax already, we can do a anything we want." I'd argue that if you use the dNSNAme SAN type, the string that appears there MUST adhere to DNS name syntax. If you want to use some other syntax, then create a new SAN type. > Also, AFAICT RFC5280 doesn't prohibit putting strings that are _not_ > "domain name system labels" into SAN->dNSName fields. > > Towards the end of Section 4.2.1.6 it says: > "Finally, the semantics of subject alternative names that include > wildcard characters (e.g., as a placeholder for a set of names) are > not addressed by this specification. Applications with specific > requirements MAY use such names, but they must define the semantics." > > So, as long as we "define the semantics" for our use of "?", I don't > think we're doing anything wrong. > > Do you agree? No,I do not. As I noted above, PKIX made an explicit exception for "*" because it was a widely adopted convention. If you want to use "*" then the above-cited paragraph covers this use. If not, then you need to request an update to 5280. Steve From nobody Mon Jan 5 07:42:59 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C741A0242 for ; Mon, 5 Jan 2015 07:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l3m154Mb9ny for ; Mon, 5 Jan 2015 07:42:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27BA1A0233 for ; Mon, 5 Jan 2015 07:42:49 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:51130 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Y89o9-00012Z-8p; Mon, 05 Jan 2015 10:43:05 -0500 Message-ID: <54AAB0F8.6010707@bbn.com> Date: Mon, 05 Jan 2015 10:42:48 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Laurie References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/HlOFlKBt0279QXhZW-XTk0EM-r8 Cc: "trans@ietf.org" Subject: Re: [Trans] SCT encoding 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, 05 Jan 2015 15:42:54 -0000 Ben, Happy New year! > ... > Because of the risk of logs becoming untrusted, SCTs in certificates > may become invalid before the certificate expires, effectively > terminating the cert early. If a log becomes untrusted then the cert is "invalid" only for the set of clients who relied upon that log. It may be that the cert was fine and the log was misbehaving with respect to other certs. So the term "invalid" is not quite appropriate here, in the usual PKI sense. > You can mitigate this to some extent by including many SCTs, but its > clearly better/safer to use SCTs that are retrieved "live" so that you > can always be sure they're valid. I agree that this would be preferable. > This requires either OCSP stapling or the TLS extension. Using the TLS > extension puts updating the SCTs in the control of the site operator, > which seems like the best way forward. Maybe. I've been told that site operators are not always very reliable when it comes to maintenance issues. Also, I believe you argued that it was critical to put SCTs in certs because it would take a very long time for site operators to update their software to trans,it SCTs. So, is your argument that, over time, the vast majority of site operators will go to the effort of getting an SCT for their web certs and transmit it instead of just using the SCT that is already embedded in the same certs? Steve From nobody Mon Jan 5 15:01:02 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FEC1A0187 for ; Mon, 5 Jan 2015 15:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6] 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 JMUS0TF6U7bg for ; Mon, 5 Jan 2015 15:00:57 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91441A0181 for ; Mon, 5 Jan 2015 15:00:56 -0800 (PST) Received: (qmail 22410 invoked by uid 1004); 5 Jan 2015 23:00:54 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 05 Jan 2015 23:00:54 +0000 Received: (qmail 9542 invoked by uid 1000); 5 Jan 2015 23:00:54 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 05 Jan 2015 23:00:54 +0000 Message-ID: <54AB17A5.1090505@comodo.com> Date: Mon, 05 Jan 2015 23:00:53 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> In-Reply-To: <54AAB0EC.5080007@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/gjKw2Yx0SqndzavLb8o8qQL2qao Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 05 Jan 2015 23:01:00 -0000 On 05/01/15 15:42, Stephen Kent wrote: > Rob, > > Happy New Year. Happy New Year, Steve. >>>> - stating that the literal string "(PRIVATE)" always covers >>>> precisely _one_ label. >>> Since DNS names are case insensitive, I suggest we not represent a >>> reserved label in uppercase. It may cause some readers to believe >>> that the label is special because of its case. >> >> The private label _is_ "special" though. :-) >> >> It's intended to be a placeholder for a real label. > > I'm not sure what you mean by these two sentences. I hope you don't mean > that you expect an RP to treat the uppercase representation as different > from lowercase. That would not be consistent with DNS canonicalization > rules (as per 1034) and thus not consistent with 5280. If you mean that > you plan to replace "PRIVATE" with some other word, which will treated > in a case-insensitive fashion, then NEVERMIND. My intention was that the literal, case-sensitive string "(PRIVATE)." would appear zero or more times at the start of each SAN:dNSName in each Precertificate. In each real X.509 certificate, each instance of "(PRIVATE)" would be replaced by a real, case-insensitive label. I don't object to saying that "(PRIVATE)" can be case-insensitive. That said, my preference is still to ditch "(PRIVATE)" and use "?" instead. Note that we've decided to change the Precertificate format in 6962-bis. The format will no longer be the X.509 certificate format. Therefore, RFC5280 does not apply, which means that a 6962-bis Precertificate and the associated X.509 certificate can have the same Issuer and Serial Number. If RFC5280 does not apply to the serial number field of a (non-X.509) Precertificate, then why would RFC5280 apply to the SAN:dNSName field(s) of a (non-X.509) Precertificate? >> "*" isn't a valid DNS label character either, and yet it is commonly >> used in SAN->dNSName fields as a placeholder. > > yes, I'm sad to say. PKIX gave into this misuse of DNS syntax because so > many CAs adopted the convention. So we added an explicit exception in 5280. The explicit exception is also present in RFC5280's predecessors: RFC3280 (published April 2002) and RFC2459 (published January 1999). Were there really "many CAs" in existence in January 1999? The exception in 5280/3280/2459 does _not_ say that "wildcard" has to mean the "*" character. RFC2818 (HTTP Over TLS) is an example of "Applications with specific requirements MAY use such names, but they must define the semantics". It says that "Names may contain the wildcard character * which is considered to match any single domain name component or component fragment". > I don't think it's a good idea to request another exception. Why not use > "*" instead, since that seems semantically appropriate? RFC6125 says that if "*" is used in a cert's CN or SAN:dNSName, it must appear only once per name and it must be the left-most label. It would be useful to be able to audit compliance to this rule using CT logs. Such auditing would be impossible if we were to use "*" for name redaction too. The semantics are different. "*" means "matches any label", whereas "?" (or "(PRIVATE)", or "(private)", or even "(pRivATe)") means "matches one particular label, the value of which has been redacted". >> You're referring to this part of RFC5280 Section 4.2.1.6: >> "When the subjectAltName extension contains a domain name system >> label, the domain name MUST be stored in the dNSName (an IA5String). >> The name MUST be in the "preferred name syntax", as specified by >> Section 3.5 of [RFC1034] and as modified by Section 2.1 of >> [RFC1123]." >> >> If one or more labels is a placeholder rather than a real label, then >> IMHO the string is _not_ a "domain name system label". And therefore, >> the two MUST requirements quoted above don't apply. > > I find this reasoning rather circular; it sounds like you're saying > "since we violated the syntax already, we can do a anything we want." Kinda. > I'd argue that if you use the dNSNAme SAN type, the string that appears > there MUST adhere to DNS name syntax. > If you want to use some other syntax, then create a new SAN type. > >> Also, AFAICT RFC5280 doesn't prohibit putting strings that are _not_ >> "domain name system labels" into SAN->dNSName fields. >> >> Towards the end of Section 4.2.1.6 it says: >> "Finally, the semantics of subject alternative names that include >> wildcard characters (e.g., as a placeholder for a set of names) are >> not addressed by this specification. Applications with specific >> requirements MAY use such names, but they must define the semantics." >> >> So, as long as we "define the semantics" for our use of "?", I don't >> think we're doing anything wrong. >> >> Do you agree? > > No,I do not. As I noted above, PKIX made an explicit exception for "*" All of the 43 "*" characters in rfc5280.txt are bullet point. RFC5280 never mentions "*" as a/the wildcard character. The word "asterisk" doesn't appear in RFC5280 at all. AFAICT, "*" is neither more nor less legal than "?", as far as RFC5280 is concerned. Where is this 'explicit exception for "*"' that you're talking about? > because it was a widely adopted convention. If you want to use "*" then the > above-cited paragraph covers this use. If not, then you need to request an > update to 5280. I can only go by what 5280 actually says. And AFAICT, even if 5280 applies to (non-X.509) Precertificates (which I don't think it does), 5280 would not need to be updated to permit the use of "?" as a different sort of wildcard/placeholder label for (non-X.509) Precertificate CN and SAN:dNSName strings. > Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jan 6 02:37:37 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45F61A9148 for ; Tue, 6 Jan 2015 02:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O-0aRVQ1_aK for ; Tue, 6 Jan 2015 02:37: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 33B2A1A9165 for ; Tue, 6 Jan 2015 02:37:34 -0800 (PST) Received: from localhost ([::1]:56356 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8RVu-0007yo-2X; Tue, 06 Jan 2015 02:37:26 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 10:37:26 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/38#comment:1 Message-ID: <067.b18a6905b80cde42b3bceea81b73e963@tools.ietf.org> References: <052.52c4f5b412dc9b96ff35523e9ae0a49e@tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <052.52c4f5b412dc9b96ff35523e9ae0a49e@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/043SMMqe6uK13nYZEatjF6JReNM Cc: trans@ietf.org Subject: Re: [Trans] [trans] #38 (rfc6962-bis): Client Behavior: A separate document for specifying client behavior (was: client behavior) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:37:35 -0000 #38: Client Behavior: A separate document for specifying client behavior Changes (by eranm@google.com): * priority: blocker => minor * type: defect => enhancement Comment: Per the discussion in IETF 91 (see minutes here: http://www.ietf.org/proceedings/91/minutes/minutes-91-trans), seems there's a consensus for: * Specifying client behaviour in a separate document. * In RFC6962-bis, listing the situations the client could encounter (which is not likely to be an exhaustive list), without specifying exactly how it should behave in each and every situation. * In the security considerations section, we will specify what *not* doing certain, non-mandatory checks would imply. We'll create a new ticket for listing the situations the client could encounter and leave this ticket for tracking the client behaviour document. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 02:38:10 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3751A9165 for ; Tue, 6 Jan 2015 02:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYRyLyiWfJKW for ; Tue, 6 Jan 2015 02:38:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F81D1A916F for ; Tue, 6 Jan 2015 02:38:06 -0800 (PST) Received: from localhost ([::1]:56372 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8RWY-00083Z-E6; Tue, 06 Jan 2015 02:38:06 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 10:38:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/38#comment:2 Message-ID: <067.a1d0bff79c547f6d041bc4496b5746ae@tools.ietf.org> References: <052.52c4f5b412dc9b96ff35523e9ae0a49e@tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <052.52c4f5b412dc9b96ff35523e9ae0a49e@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: http://mailarchive.ietf.org/arch/msg/trans/GgMH4emF2ZtXI0HCCJToO5MC1vg Cc: trans@ietf.org Subject: Re: [Trans] [trans] #38 (rfc6962-bis): Client Behavior: A separate document for specifying client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:38:08 -0000 #38: Client Behavior: A separate document for specifying client behavior Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => -- --------------------------+------------------ Reporter: kent@bbn.com | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------ Ticket URL: trans From nobody Tue Jan 6 02:45:30 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40D71A9150 for ; Tue, 6 Jan 2015 02:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix8GCTraFnhc for ; Tue, 6 Jan 2015 02:45:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6842F1A9148 for ; Tue, 6 Jan 2015 02:45:21 -0800 (PST) Received: from localhost ([::1]:56620 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8RdX-0001N0-O7; Tue, 06 Jan 2015 02:45:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: benl@google.com, eranm@google.com, beldmit@gmail.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 10:45:19 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/15#comment:5 Message-ID: <072.0e12be2f9f1156477f03fdd37d503259@tools.ietf.org> References: <057.c35ea8d0aaec7267e36b7a8fced32d9f@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <057.c35ea8d0aaec7267e36b7a8fced32d9f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, eranm@google.com, beldmit@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: http://mailarchive.ietf.org/arch/msg/trans/agPp3Jb35r5F1aY0vWD7rnXd2Bw Cc: trans@ietf.org Subject: Re: [Trans] [trans] #15 (rfc6962-bis): Client behaviour specification needed X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:45:28 -0000 #15: Client behaviour specification needed Comment (by eranm@google.com): Note: This should be a part of the client behaviour document (but the list of situations here is useful for specifying in rfc6962-bis, just without the client behaviour details). -- -------------------------------+------------------------------ Reporter: beldmit@gmail.com | Owner: benl@google.com Type: task | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------+------------------------------ Ticket URL: trans From nobody Tue Jan 6 02:45:48 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B605B1A9165 for ; Tue, 6 Jan 2015 02:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emxc2_YN3HoG for ; Tue, 6 Jan 2015 02:45:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D36B1A9162 for ; Tue, 6 Jan 2015 02:45:45 -0800 (PST) Received: from localhost ([::1]:56654 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8Rdw-0001Um-BR; Tue, 06 Jan 2015 02:45: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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com, benl@google.com, beldmit@gmail.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 10:45:44 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/15#comment:6 Message-ID: <072.c884875dc1a27c1b18ebf3f3ee2cc206@tools.ietf.org> References: <057.c35ea8d0aaec7267e36b7a8fced32d9f@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <057.c35ea8d0aaec7267e36b7a8fced32d9f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, benl@google.com, beldmit@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: http://mailarchive.ietf.org/arch/msg/trans/QKrztdoUlaVPOWTwEtEBkyaTQOY Cc: trans@ietf.org Subject: Re: [Trans] [trans] #15 (rfc6962-bis): Client behaviour specification needed X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:45:46 -0000 #15: Client behaviour specification needed Changes (by eranm@google.com): * owner: benl@google.com => * status: assigned => new -- -------------------------------+------------------ Reporter: beldmit@gmail.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------+------------------ Ticket URL: trans From nobody Tue Jan 6 02:50:11 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7371A914B for ; Tue, 6 Jan 2015 02:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFOMgOobm-BP for ; Tue, 6 Jan 2015 02:50:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73A71A9133 for ; Tue, 6 Jan 2015 02:50:07 -0800 (PST) Received: from localhost ([::1]:56815 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8Ri8-0008Gp-GX; Tue, 06 Jan 2015 02:50:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 10:50:04 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/32#comment:1 Message-ID: <067.da1b401b7d94997f6f1fb0a06fb12a5f@tools.ietf.org> References: <052.61160c764926010ce5201368f967f42c@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <052.61160c764926010ce5201368f967f42c@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YD05QaS0hTfnhGk99xEPC5YOK98 Cc: trans@ietf.org Subject: Re: [Trans] [trans] #32 (rfc6962-bis): algorithm needed for client checks of SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:50:09 -0000 #32: algorithm needed for client checks of SCT Comment (by eranm@google.com): Per ticket #38, we should list the situations the client could encounter - that includes after checking some, or all, SCTs, and trying to fetch inclusion proofs from logs. This should address the original comment in ticket. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 02:54:31 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC42C1A9162 for ; Tue, 6 Jan 2015 02:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2ZFjGlzQ71l for ; Tue, 6 Jan 2015 02:54:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04441A9133 for ; Tue, 6 Jan 2015 02:54:27 -0800 (PST) Received: from localhost ([::1]:56940 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8RmL-0003Fs-87; Tue, 06 Jan 2015 02:54:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 10:54:25 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/55 Message-ID: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> X-Trac-Ticket-ID: 55 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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uxWifb0YnbyBRCgQyVsPF9OtEPI Cc: trans@ietf.org Subject: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:54:30 -0000 #55: Security Considerations: Describe the implications of clients *not* doing certain optional checks Client behaviour is not mandated in RFC6962-bis - but the list of checks a client could do is specified. We should document, in the Security Considerations section, what happens if a client does not perform each (or some) of these checks. For example, the implications of not checking the validity of SCTs or not terminating a connection if there are no enough valid SCTs. Hopefully this is an acceptable middle-ground between mandating client behaviour and not mandating it at all. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 03:25:28 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97601ABD37 for ; Tue, 6 Jan 2015 03:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV2iiQyo6ZyN for ; Tue, 6 Jan 2015 03:25: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 43EC21A9252 for ; Tue, 6 Jan 2015 03:25:17 -0800 (PST) Received: from localhost ([::1]:58819 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8SG6-0007Pp-NU; Tue, 06 Jan 2015 03:25:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 11:25:10 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/42#comment:1 Message-ID: <067.b64fca23654a447e28e222447af99345@tools.ietf.org> References: <052.950544e6062028ff9f6230f03eb5f37c@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <052.950544e6062028ff9f6230f03eb5f37c@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/tS7j-Pt7YDMEm-5WAvBjNftYRO4 Cc: trans@ietf.org Subject: Re: [Trans] [trans] #42 (rfc6962-bis): redacted cert dangers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:25:26 -0000 #42: redacted cert dangers Comment (by eranm@google.com): Overly redacted: (Looking only at the labels in the Precertificate) Where the entirety of the domain space below the unredacted part of the domain name is not owned or controlled by a single entity. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 03:34:31 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBA61AC39B for ; Tue, 6 Jan 2015 03:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGwwVbWfkj0G for ; Tue, 6 Jan 2015 03:34:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1D41AC3A8 for ; Tue, 6 Jan 2015 03:34:29 -0800 (PST) Received: from localhost ([::1]:59337 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8SP4-00077P-JQ; Tue, 06 Jan 2015 03:34:26 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 11:34:26 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/42#comment:2 Message-ID: <067.e2d19becb218fbaeb9105c8f6326c022@tools.ietf.org> References: <052.950544e6062028ff9f6230f03eb5f37c@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <052.950544e6062028ff9f6230f03eb5f37c@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QQKmuxGtSQHB9VFpdK0aydQuWqE Cc: trans@ietf.org Subject: Re: [Trans] [trans] #42 (rfc6962-bis): redacted cert dangers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:34:30 -0000 #42: redacted cert dangers Comment (by eranm@google.com): This is out for review here: https://github.com/google/certificate- transparency-rfcs/pull/10 We solicit feedback on the terminology used to describe domain names and how to describe such names that contain wildcards deemed too broad. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 03:38:12 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34E1AC3AD for ; Tue, 6 Jan 2015 03:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP0Zgf_rDeOf for ; Tue, 6 Jan 2015 03:38:08 -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 8595B1A9252 for ; Tue, 6 Jan 2015 03:38:08 -0800 (PST) Received: from localhost ([::1]:59478 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8SSc-00086A-Fl; Tue, 06 Jan 2015 03:38:06 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 11:38:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/31#comment:1 Message-ID: <067.b4bfaa55d13a67afc75a8065dcabbc10@tools.ietf.org> References: <052.88969a6568e09ab3e9fd597ebb5d3047@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <052.88969a6568e09ab3e9fd597ebb5d3047@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/i4jJniGcgkP05Yk89Rfb_7iIWDA Cc: trans@ietf.org Subject: Re: [Trans] [trans] #31 (rfc6962-bis): incremental deployment and client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:38:10 -0000 #31: incremental deployment and client behavior Comment (by eranm@google.com): (1) The current wording implies specifying client behaviour. As we do not intend to specify it, we should reword it to say that a certificate not accompanied by an SCT MUST NOT be considered CT compliant (as one of the situations the client could encounter). (2) Then there's no mandated hard-fail and the issue around incremental deployment is moot - the client can decide when, and for which certificates, it requires CT compliance. Bottom line: Reword to remove the hard requirement and include this situation in the list of situations a client could encounter. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 03:44:24 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145DA1AC3BB for ; Tue, 6 Jan 2015 03:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS9vftlv_qIE for ; Tue, 6 Jan 2015 03:44:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4712E1AC3B5 for ; Tue, 6 Jan 2015 03:44:21 -0800 (PST) Received: from localhost ([::1]:59689 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8SYc-0001W9-VW; Tue, 06 Jan 2015 03:44: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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 11:44:18 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/37#comment:1 Message-ID: <067.e6c3b06d16a33c97065751dd8dc9a59f@tools.ietf.org> References: <052.101c2ba37e44958f96f881c29ffb59aa@tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <052.101c2ba37e44958f96f881c29ffb59aa@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/0yeqROavmD7_Nwwh7VYk5eejL68 Cc: trans@ietf.org Subject: Re: [Trans] [trans] #37 (rfc6962-bis): client gossping X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:44:23 -0000 #37: client gossping Comment (by eranm@google.com): Linus has started working on a draft describing gossip, so this ticket could probably be assigned to him. Also, a new component should be created for this. Bottom line: Suggest that clients should somehow 'gossip' (by detailing, in the security considerations, what would happen if clients don't do this). Defer the definition of gossiping to the document produced by Linus. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 04:34:34 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369B11AC425 for ; Tue, 6 Jan 2015 04:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_QxUcXQsS4m for ; Tue, 6 Jan 2015 04:34:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5A91ACD26 for ; Tue, 6 Jan 2015 04:32:18 -0800 (PST) Received: from localhost ([::1]:33750 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8TJ1-00071e-Fj; Tue, 06 Jan 2015 04:32:15 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 12:32:15 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/40#comment:1 Message-ID: <067.4ecaf3acdcd689a59761562d70222781@tools.ietf.org> References: <052.209604b41feaa87f9afa6c39944805d9@tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <052.209604b41feaa87f9afa6c39944805d9@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/MJCONP-_fH_XUqbt1EI7Ou-EqNM Cc: trans@ietf.org Subject: Re: [Trans] [trans] #40 (rfc6962-bis): Auditor behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 12:34:32 -0000 #40: Auditor behavior Comment (by eranm@google.com): This is out for review in: https://github.com/google/certificate-transparency-rfcs/pull/11 Change description: Stand-alone auditing isn't likely to happen. Instead, each of the clients mentioned can take on the additional responsibility of auditing. Re-word to clarify what are the auditing aspects of each client and include them in the section for each client (if not already there). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 05:04:24 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AD11ACD1C for ; Tue, 6 Jan 2015 05:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjri1OgciGdK for ; Tue, 6 Jan 2015 05:04:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208F71ACD22 for ; Tue, 6 Jan 2015 05:03:32 -0800 (PST) Received: from localhost ([::1]:34832 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8TnF-0007eQ-SJ; Tue, 06 Jan 2015 05:03:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com, benl@google.com, beldmit@gmail.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 13:03:29 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/15#comment:7 Message-ID: <072.5ea601791b69aeda40878d50235a0716@tools.ietf.org> References: <057.c35ea8d0aaec7267e36b7a8fced32d9f@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <057.c35ea8d0aaec7267e36b7a8fced32d9f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, benl@google.com, beldmit@gmail.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YyMflXT4k89LaPrfUwU2w2ymmnc Cc: trans@ietf.org Subject: Re: [Trans] [trans] #15 (client-behavior): Client behaviour specification needed X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:04:15 -0000 #15: Client behaviour specification needed Changes (by melinda.shore@gmail.com): * component: rfc6962-bis => client-behavior -- -------------------------------+------------------ Reporter: beldmit@gmail.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -------------------------------+------------------ Ticket URL: trans From nobody Tue Jan 6 05:04:35 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B036D1ACD2D for ; Tue, 6 Jan 2015 05:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zVmJ1dNoDt4 for ; Tue, 6 Jan 2015 05:04:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F141ACD35 for ; Tue, 6 Jan 2015 05:03:58 -0800 (PST) Received: from localhost ([::1]:34847 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8Tnh-0007hd-C7; Tue, 06 Jan 2015 05:03:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 13:03:57 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/38#comment:3 Message-ID: <067.5a9fd15693d4fac51739cc6732006b8f@tools.ietf.org> References: <052.52c4f5b412dc9b96ff35523e9ae0a49e@tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <052.52c4f5b412dc9b96ff35523e9ae0a49e@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: http://mailarchive.ietf.org/arch/msg/trans/rq2SvxpPfwNFj8YLwV6p626lx-Y Cc: trans@ietf.org Subject: Re: [Trans] [trans] #38 (client-behavior): Client Behavior: A separate document for specifying client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:04:33 -0000 #38: Client Behavior: A separate document for specifying client behavior Changes (by melinda.shore@gmail.com): * component: rfc6962-bis => client-behavior -- -----------------------------+------------------ Reporter: kent@bbn.com | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------ Ticket URL: trans From nobody Tue Jan 6 05:59:23 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632AF1A6F21 for ; Tue, 6 Jan 2015 05:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiPb-w2opuzf for ; Tue, 6 Jan 2015 05:59: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 684EC1A6F20 for ; Tue, 6 Jan 2015 05:59:19 -0800 (PST) Received: from localhost ([::1]:37977 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8UfC-0005V9-V8; Tue, 06 Jan 2015 05:59:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 13:59:14 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/55#comment:1 Message-ID: <071.1f61cacfd76e662142920c2318c3a472@tools.ietf.org> References: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/0JJr7VB60o9t-9dsu4UGg2lZ1rE Cc: trans@ietf.org Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:59:21 -0000 #55: Security Considerations: Describe the implications of clients *not* doing certain optional checks Comment (by eranm@google.com): To clarify: This refers both to TLS clients and monitors not doing these checks, not just the TLS clients. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 06:46:59 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0AF1A888E for ; Tue, 6 Jan 2015 06:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBiwxEVQbHQ8 for ; Tue, 6 Jan 2015 06:46:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801771A883B for ; Tue, 6 Jan 2015 06:46:55 -0800 (PST) Received: from localhost ([::1]:39874 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8VPG-0005kg-1Z; Tue, 06 Jan 2015 06:46:50 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 14:46:50 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/42#comment:3 Message-ID: <067.06ed92d57e18bddf6cf1a3c2ffb4ad00@tools.ietf.org> References: <052.950544e6062028ff9f6230f03eb5f37c@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <052.950544e6062028ff9f6230f03eb5f37c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hk2bUDKna5x97yPRXIVecqHlgSk Cc: trans@ietf.org Subject: Re: [Trans] [trans] #42 (rfc6962-bis): redacted cert dangers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:46:58 -0000 #42: redacted cert dangers Comment (by benl@google.com): As previously decided, we will not specify client behaviour in 6962-bis. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 06:56:18 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2863F1A879B for ; Tue, 6 Jan 2015 06:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCnfKKU1opdt for ; Tue, 6 Jan 2015 06:56:15 -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 54F901A6F21 for ; Tue, 6 Jan 2015 06:56:15 -0800 (PST) Received: from localhost ([::1]:40178 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8VYM-0008Nj-W2; Tue, 06 Jan 2015 06:56:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 14:56:14 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/31#comment:2 Message-ID: <067.2218f16afa4aeef9196c3b475544f053@tools.ietf.org> References: <052.88969a6568e09ab3e9fd597ebb5d3047@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <052.88969a6568e09ab3e9fd597ebb5d3047@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: http://mailarchive.ietf.org/arch/msg/trans/d8WzLtBvzRpeMyMTJZJzSfW59ks Cc: trans@ietf.org Subject: Re: [Trans] [trans] #31 (rfc6962-bis): incremental deployment and client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:56:17 -0000 #31: incremental deployment and client behavior Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com Comment: This is out for review: https://github.com/google/certificate-transparency-rfcs/pull/12 -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Tue Jan 6 07:08:04 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926DB1A8852 for ; Tue, 6 Jan 2015 07:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbWWVDCpebwX for ; Tue, 6 Jan 2015 07:07:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08021A8850 for ; Tue, 6 Jan 2015 07:07:57 -0800 (PST) Received: from localhost ([::1]:40533 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8Vjh-00036B-Fa; Tue, 06 Jan 2015 07:07:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 15:07:57 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/26#comment:2 Message-ID: <071.40ed62576d194d2d6373bba88ee3f035@tools.ietf.org> References: <056.eb75bd494f786a9950a7a694bb5dfc0f@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <056.eb75bd494f786a9950a7a694bb5dfc0f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DTQcWX7Bqm2jETZylr87OhS-lYs Cc: trans@ietf.org Subject: Re: [Trans] [trans] #26 (rfc6962-bis): Precertificates: Find alternative format to X.509 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:08:01 -0000 #26: Precertificates: Find alternative format to X.509 Changes (by rob.stradling@comodo.com): * status: new => closed * resolution: => fixed -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Jan 6 07:11:27 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821911A87AE for ; Tue, 6 Jan 2015 07:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miq_TmpwNtbs for ; Tue, 6 Jan 2015 07:11:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63E71A882E for ; Tue, 6 Jan 2015 07:11:19 -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 1Y8Vmw-0004EH-TB; Tue, 06 Jan 2015 07:11: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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 15:11:18 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/45#comment:1 Message-ID: <071.a50b47aaf9c5ff1a89af9a038182ac52@tools.ietf.org> References: <056.166dc4103479f983aac3fcdb5774ceac@tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <056.166dc4103479f983aac3fcdb5774ceac@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/GJZqzFbXvxMHYLIzugh_m-uF7MU Cc: trans@ietf.org Subject: Re: [Trans] [trans] #45 (rfc6962-bis): Incorporate RFC6962 errata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:11:23 -0000 #45: Incorporate RFC6962 errata Changes (by rob.stradling@comodo.com): * status: new => closed * resolution: => fixed Comment: Fixed in -05. -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Tue Jan 6 07:33:15 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765041A883A for ; Tue, 6 Jan 2015 07:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PonFJ2tZ35sx for ; Tue, 6 Jan 2015 07:33:00 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658481A8886 for ; Tue, 6 Jan 2015 07:32:19 -0800 (PST) Received: from localhost ([::1]:41990 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8W7D-0005mL-Jh; Tue, 06 Jan 2015 07:32:15 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 15:32:15 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/17#comment:4 Message-ID: <070.9ddfde5d5185b934d9035c4b9c273c78@tools.ietf.org> References: <055.08fd455285c038bb24d0616bf52462c8@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <055.08fd455285c038bb24d0616bf52462c8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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 Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/BDdQp0i_-swCWwLwoUzTOepiIJU Cc: trans@ietf.org Subject: Re: [Trans] [trans] #17 (rfc6962-bis): Add advice on CNs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:33:09 -0000 #17: Add advice on CNs Changes (by eranm@google.com): * status: new => closed * resolution: => duplicate Comment: Ticket #54 addresses this, marking as duplicate. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: duplicate Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 07:37:42 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191791A005C for ; Tue, 6 Jan 2015 07:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1XOIFG8n-6Y for ; Tue, 6 Jan 2015 07:37:33 -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 53F131A0052 for ; Tue, 6 Jan 2015 07:37:29 -0800 (PST) Received: from localhost ([::1]:42202 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8WCE-0008FA-CV; Tue, 06 Jan 2015 07:37:26 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 15:37:26 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/37#comment:2 Message-ID: <067.083e843820e31ac6654b4eea1beb6dff@tools.ietf.org> References: <052.101c2ba37e44958f96f881c29ffb59aa@tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <052.101c2ba37e44958f96f881c29ffb59aa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/kaKqEwxovHQu-BIvNXjniUTZskY Cc: trans@ietf.org Subject: Re: [Trans] [trans] #37 (rfc6962-bis): client gossping X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:37:39 -0000 #37: client gossping Comment (by benl@google.com): Text updated to: a) Be less prescriptive about how STHs are exchanged, b) Point to the gossip I-D. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 07:38:01 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC01A6F32 for ; Tue, 6 Jan 2015 07:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIcXdbo0_yZ0 for ; Tue, 6 Jan 2015 07:37: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 3B5571A1A5E for ; Tue, 6 Jan 2015 07:37:56 -0800 (PST) Received: from localhost ([::1]:42222 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8WCf-0008If-Dn; Tue, 06 Jan 2015 07:37:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 15:37:53 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/37#comment:3 Message-ID: <067.f65bec9d2720c11cc6c6715d714fe3d4@tools.ietf.org> References: <052.101c2ba37e44958f96f881c29ffb59aa@tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <052.101c2ba37e44958f96f881c29ffb59aa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/K5iN9vJ648j8b8UQ8GsVQxOGnvs Cc: trans@ietf.org Subject: Re: [Trans] [trans] #37 (rfc6962-bis): client gossping X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:37:59 -0000 #37: client gossping Changes (by benl@google.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 07:38:41 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603EA1A6F2E for ; Tue, 6 Jan 2015 07:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaHdXvIVcbJ1 for ; Tue, 6 Jan 2015 07:38:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBAF1A0052 for ; Tue, 6 Jan 2015 07:38:36 -0800 (PST) Received: from localhost ([::1]:42279 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8WDK-0000As-MW; Tue, 06 Jan 2015 07:38:34 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 15:38:34 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/42#comment:4 Message-ID: <067.2b1665395db091f3dd65de4291815f1a@tools.ietf.org> References: <052.950544e6062028ff9f6230f03eb5f37c@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <052.950544e6062028ff9f6230f03eb5f37c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/fxKeRQ1IHp_8IW_MwT9IgFcZknY Cc: trans@ietf.org Subject: Re: [Trans] [trans] #42 (rfc6962-bis): redacted cert dangers X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:38:38 -0000 #42: redacted cert dangers Changes (by benl@google.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 08:12:21 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15091A00EA for ; Tue, 6 Jan 2015 08:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZBA4Oo3PmPi for ; Tue, 6 Jan 2015 08:12:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF571A00DC for ; Tue, 6 Jan 2015 08:12:11 -0800 (PST) Received: from localhost ([::1]:44127 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8Wjm-0000wT-Tv; Tue, 06 Jan 2015 08:12:06 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 16:12:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/21#comment:2 Message-ID: <070.a38cec297d5942b7d66eb2a1d64cf9a6@tools.ietf.org> References: <055.e195c2a1c7a5a4b76a9f7bef68253585@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <055.e195c2a1c7a5a4b76a9f7bef68253585@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/fFMct0k_AkuTMMuIXepvVagMVRs Cc: trans@ietf.org Subject: Re: [Trans] [trans] #21 (rfc6962-bis): Clarify signature checking purpose and mechanism X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:12:14 -0000 #21: Clarify signature checking purpose and mechanism Comment (by eranm@google.com): (1) The "Informal Introduction" section explains why checking signatures over the chain is necessary. (2) We've proposed language to clarify which certificates must be accepted by logs (logs may accept additional certificates but that is not required or guaranteed). Out for review: https://github.com/google/certificate-transparency-rfcs/pull/14 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 08:12:25 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFD1A009E for ; Tue, 6 Jan 2015 08:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3dEST7OCPcV for ; Tue, 6 Jan 2015 08:12:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC38A1A00E9 for ; Tue, 6 Jan 2015 08:12:13 -0800 (PST) Received: from localhost ([::1]:44132 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8Wjt-0000xD-NO; Tue, 06 Jan 2015 08:12: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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 16:12:13 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/21#comment:3 Message-ID: <070.f4718d733c97a9d77c2b68b4a24d63b9@tools.ietf.org> References: <055.e195c2a1c7a5a4b76a9f7bef68253585@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <055.e195c2a1c7a5a4b76a9f7bef68253585@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: http://mailarchive.ietf.org/arch/msg/trans/3qnhuuCeXjTr3hjzHlfvyWTruD8 Cc: trans@ietf.org Subject: Re: [Trans] [trans] #21 (rfc6962-bis): Clarify signature checking purpose and mechanism X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:12:19 -0000 #21: Clarify signature checking purpose and mechanism Changes (by eranm@google.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => eranm@google.com -- -----------------------------+------------------------------- Reporter: benl@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------- Ticket URL: trans From nobody Tue Jan 6 08:26:10 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD31A0115 for ; Tue, 6 Jan 2015 08:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJqF9NM4LZ9C for ; Tue, 6 Jan 2015 08:26:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793E01A0102 for ; Tue, 6 Jan 2015 08:26:06 -0800 (PST) Received: from localhost ([::1]:45046 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8WxJ-0000T6-9C; Tue, 06 Jan 2015 08:26:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 16:26:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/39#comment:1 Message-ID: <067.0dc3bbe6dcb407aeb247b4d11df55859@tools.ietf.org> References: <052.35c4bb490ca830a7c003481975592e44@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <052.35c4bb490ca830a7c003481975592e44@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3EPOBJxdXTNVRYWcSwDMw9b5prw Cc: trans@ietf.org Subject: Re: [Trans] [trans] #39 (client-behavior): Monitor behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:26:08 -0000 #39: Monitor behavior Changes (by rob.stradling@comodo.com): * component: rfc6962-bis => client-behavior -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: client- | Version: behavior | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 08:26:53 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E7D1A00E2 for ; Tue, 6 Jan 2015 08:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuqZLY1KqilG for ; Tue, 6 Jan 2015 08:26:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EBB1A0102 for ; Tue, 6 Jan 2015 08:26:50 -0800 (PST) Received: from localhost ([::1]:45064 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8Wxz-00039j-Ef; Tue, 06 Jan 2015 08:26:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 16:26:47 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/43#comment:1 Message-ID: <067.74f7d1fedd1c3df6958f6d672d411c47@tools.ietf.org> References: <052.a82c601d75b10a91fbfc3a757edf6632@tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <052.a82c601d75b10a91fbfc3a757edf6632@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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Xvej6R-xNuSuJWOfkQUyGEYuZeI Cc: trans@ietf.org Subject: Re: [Trans] [trans] #43 (rfc6962-bis): key rollover X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:26:52 -0000 #43: key rollover Changes (by eranm@google.com): * status: new => closed * resolution: => wontfix Comment: Will not fix because the feasible way to change a log's key is to freeze it and start a new one. The alternative is to build into all data structures an indication of which key was used to sign the SCTs, coordination with TLS clients on when to switch to the new key, etc. I think it's a significant complexity to add for no real benefit - freezing a log and starting a new one is much simpler conceptually (and is operationally as complex as key rollover, if not less). Note that policies of TLS clients for recognizing a log, although out of scope for the trans wg, could have different requirements for logs from new operators vs logs from recognized operators that would like to use a different key for their log. -- -------------------------+------------------------------------------------- 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: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jan 6 08:37:30 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2226B1A037F for ; Tue, 6 Jan 2015 08:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skJcehrwgWkH for ; Tue, 6 Jan 2015 08:37:27 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61AD1A0242 for ; Tue, 6 Jan 2015 08:37:27 -0800 (PST) Received: from localhost ([::1]:45464 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8X8J-0000hS-CV; Tue, 06 Jan 2015 08:37:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 16:37:27 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/39#comment:2 Message-ID: <067.0cb2d73a6dd8f94622cf7c2486fec00f@tools.ietf.org> References: <052.35c4bb490ca830a7c003481975592e44@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <052.35c4bb490ca830a7c003481975592e44@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/fxcKLmynWTt_y2EZq3B0cEPZNqg Cc: trans@ietf.org Subject: Re: [Trans] [trans] #39 (client-behavior): Monitor behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:37:29 -0000 #39: Monitor behavior Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => -- -----------------------------+------------------ Reporter: kent@bbn.com | Owner: Type: defect | Status: new Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------ Ticket URL: trans From nobody Tue Jan 6 08:50:38 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E69D1A19EF for ; Tue, 6 Jan 2015 08:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUzI_radfN_k for ; Tue, 6 Jan 2015 08:50:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173271A0B00 for ; Tue, 6 Jan 2015 08:50:36 -0800 (PST) Received: from localhost ([::1]:46077 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8XKv-0001k0-1a; Tue, 06 Jan 2015 08:50:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, tom@tom-fitzhenry.me.uk X-Trac-Project: trans Date: Tue, 06 Jan 2015 16:50:28 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/8#comment:9 Message-ID: <071.09e49df5ef2d9233f7b7bffb3fbc1eba@tools.ietf.org> References: <056.c28d2ccb6b4e6358f3bf90177e3e788d@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <056.c28d2ccb6b4e6358f3bf90177e3e788d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, rob.stradling@comodo.com, benl@google.com, tom@tom-fitzhenry.me.uk, 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: http://mailarchive.ietf.org/arch/msg/trans/HfWRx1VEZ5YO13P0nTk9Gd1CquE Cc: trans@ietf.org Subject: Re: [Trans] [trans] #8 (rfc6962-bis): Need a way to obtain Merkle proofs for a batch for certificates around the SCT timestamp X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:50:37 -0000 #8: Need a way to obtain Merkle proofs for a batch for certificates around the SCT timestamp Comment (by eranm@google.com): Note: We should punt this to a separate document. This is a big change and it's yet unclear how good it is as a privacy-preserving proof retrieval mechanism. In the separate document we could explore (in addition to DNS), Private information retrieval. -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Tue Jan 6 08:55:38 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181AA1A0687 for ; Tue, 6 Jan 2015 08:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52A47Hk4sBuJ for ; Tue, 6 Jan 2015 08:55:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303F71A039A for ; Tue, 6 Jan 2015 08:55:36 -0800 (PST) Received: from localhost ([::1]:46231 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y8XPs-0004gR-3f; Tue, 06 Jan 2015 08:55:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 06 Jan 2015 16:55:36 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/54#comment:1 Message-ID: <079.fb8f7b820200ffaf3afc3cb106dd0576@tools.ietf.org> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RndOF061GRjCCIO1FPPFmDtHg6s Cc: trans@ietf.org Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:55:38 -0000 #54: Simplify name redaction Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com -- -------------------------------------+------------------------------------- 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 Jan 7 09:59:40 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AA41A00E9 for ; Wed, 7 Jan 2015 09:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng7i_OVM3IA1 for ; Wed, 7 Jan 2015 09:59:36 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5001A00B0 for ; Wed, 7 Jan 2015 09:59:35 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so6297078pab.4 for ; Wed, 07 Jan 2015 09:59:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=FmULheRZKVHrI8XJ5eYkFny4/ukHwOdXebXiZTkQsV8=; b=KUcXYHSX+NEbAQaScNukqeeA/7qFzbA/P7vKZEvlojUqqhj++8cRA9CJbYPzqVOhv9 gRc0aebB+hKGhYw6+N5WNl1qCSkJDuUGoBX+MclP9dYvTDiX47JfUc755pDYdxaTByVQ Udj7uLZOKmOCl3/ffA8IO4Z6SD40SDkRgZQXdsK226cfalZ7jChi7rBB85ZIgycbUass b2/rBnEKntTW95cRi6SPeJBDyIAcreg2kzoqs6F8uKDimYRzh1sJrypfoKUVREeBPIAa ZKv3Ox2wlnEVM66dHC0CLz9USAnLiifnykoMIDvdzBnZU2+Cw2xenUcyWLCgFxQO7ZMj lWKg== X-Received: by 10.70.50.228 with SMTP id f4mr7400005pdo.27.1420653575212; Wed, 07 Jan 2015 09:59:35 -0800 (PST) Received: from spandex.local (216-67-123-142.dynamic.cdma.acsalaska.net. [216.67.123.142]) by mx.google.com with ESMTPSA id j15sm2402301pdk.49.2015.01.07.09.59.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 09:59:34 -0800 (PST) Message-ID: <54AD7404.7020604@gmail.com> Date: Wed, 07 Jan 2015 08:59:32 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RcqnatE0XLKOqYo7_O6lrsZdAyg Cc: Paul Wouters Subject: [Trans] Recent issue tracker activity 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, 07 Jan 2015 17:59:38 -0000 You may have noticed a recent burst of activity on the issue tracker, including the closure of issues 17, 26, 37, 42, 43, and 45. Please review the tickets with an eye towards identifying items which might block consensus on future draft revisions. A 6962-bis revision should be out shortly. Melinda From nobody Wed Jan 7 10:00:43 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43D71A00B0 for ; Wed, 7 Jan 2015 10:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaj0xUVsrU8A for ; Wed, 7 Jan 2015 10:00:40 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1EB1A008A for ; Wed, 7 Jan 2015 10:00:40 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so6321027pad.1 for ; Wed, 07 Jan 2015 10:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=7mfcNlpRwILN2AoMY0w1+sq1qQ//aNzmjBkgpfzDv4A=; b=nW6kx+qeBDFc7fxRXXONL9GNwE4QhYxDlw2zxp4PPdHbwbgN5kGxIcqHryD8geD5ks 1HAV2FHVPcFz9XRW6LVeIeTMk0QDxn/NMU5B7kSF41OpoY0hoFVkLU3mUiimwuFcXB0N 94FmHJPaHWcfmtwmNL/RSe69ltfvRRWtXR80ra/NbVZkM5bPTZ8LZaCppGT5s2u1mVrd E4Jbenq+6wfzrdgJYa6HrcW9VDc3L70k/z7EDy5LWOmKCNeMaIXa0acIctQLyqGYOnYM B9WMacBkpp02fQ17K6bDsSLY9K9lxvsDKySppKluBgSyCryDWq8WKFPLjFAVg4wJB0C2 C/+Q== X-Received: by 10.70.124.200 with SMTP id mk8mr7367638pdb.147.1420653639016; Wed, 07 Jan 2015 10:00:39 -0800 (PST) Received: from spandex.local (216-67-123-142.dynamic.cdma.acsalaska.net. [216.67.123.142]) by mx.google.com with ESMTPSA id lo3sm2444807pab.26.2015.01.07.10.00.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 10:00:38 -0800 (PST) Message-ID: <54AD7445.4050604@gmail.com> Date: Wed, 07 Jan 2015 09:00:37 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wgk35E-7DRY8iI3P54_2LptIli0 Cc: Paul Wouters Subject: [Trans] Addendum 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, 07 Jan 2015 18:00:41 -0000 To make it easier to review recent changes, you can see a list of them here: http://trac.tools.ietf.org/wg/trans/trac/query?changetime=2015-01-01..2015-01-07&col=id&col=summary&col=changetime&col=status&col=owner&col=type&col=priority&col=milestone&col=resolution&order=priority Melinda From nobody Thu Jan 8 11:49:29 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CE21A9128 for ; Thu, 8 Jan 2015 11:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qJBHcRZHpox for ; Thu, 8 Jan 2015 11:49:26 -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 3D2691A9126 for ; Thu, 8 Jan 2015 11:49:26 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:34192 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Y9J5A-0009gm-V9 for trans@ietf.org; Thu, 08 Jan 2015 14:49:25 -0500 Message-ID: <54AEDF44.2040907@bbn.com> Date: Thu, 08 Jan 2015 14:49:24 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <54AD7445.4050604@gmail.com> In-Reply-To: <54AD7445.4050604@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Addendum X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:49:28 -0000 I have a few questions/comments about the set of proposed ticket closures: #37 - Are the gossiping clients discussed by this ticket just Auditors and Monitors, or does it apply to TLS clients as well? Also, if gossiping is addressed in a separate set of docs, does that mean that 6962-bis will make only minimal mention of it? That seems appropriate since until those specs are completed and approved, on cannot attribute any security features to gossiping, right? #15 + #38 - For what range of clients is behavior not being specified? My recollection from the IETF meeting was that the discussion focused on TLS clients, not Monitors or Auditors, but the ticket closing comment is not clear on this point. Also, is it useful (vs. confusing) to discuss possible client behaviors in this doc, yet mandate none? I don't recall this issue (what to say about client behavior if we mandate none) being discussed ion detail on the list. #40 - I don't recall seeing an explanation by the editors about why they have decided that "stand-along auditing isn't likely to happen." Absent such an explanation, and WG concurrence, it seems that closing this ticket is premature. #42 - Since this is a ticket I submitted, let me say that I don't think the adverb "overly" is appropriate ;-). My concern is that the text didn't provide an algorithmic way to determine when a submitted (pre-)cert with a redacted SAN was "dangerous" and ought not be accepted. Also, the issue was not whether a single entity controls the name space covered by the redacted name; it's whether the CA submitting the pre-cert controls that space. Finally, if we are not specifying how any client (TLS or Monitor) makes use of this feature, why is it part of the spec? Unless we have an agreed-upon set of rules for how to use redacted certs, we are adding complexity to 6962-bis without identifying any benefits. #43 - If key rollover is not supported, then the "freeze and begin a new one" process needs to be documented in detail. This description must describe how clients of the old log become aware of the transition to a new log (to avoid false positives). Steve From nobody Tue Jan 13 07:10:40 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD01A8AF5 for ; Tue, 13 Jan 2015 07:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xs0b4c12n-l for ; Tue, 13 Jan 2015 07:10:33 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A85B1A8AAA for ; Tue, 13 Jan 2015 07:10:33 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id uz6so2923562obc.5 for ; Tue, 13 Jan 2015 07:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hfuvRcqs5OfkqLEVNsidktZ+jKUH0rTVb5n02tUkPQ8=; b=kUadf3y/o/jpfSn6Z1O4vWmgDn5HB3+g9LY0R5ee5TwxNnP8lIXL/dHjhBxDg31aVy xwr1FQbZUtEm0w660bX/L7Srotq619AZc2J2JObl7tIrMsC4o+aBtHEjfK9oON2UCrYj 0Zw61F3KgYDVxJ2ILpPej7QNVG4bnY09ela3+zkDNoiTBZd31WMn21+zxl2zNhN6BBuz veiAeO11LpfahveOotMMr8R5DWcA0NAW603vXw34rBj2EwjhvhQtRR99ozP8VXN2Ix78 wt+hzsdJvURnMqnLqgAXiNs3lPeK2SFHqYInuCeFI3RqRHy4cyeov7+VQi+0mwrkT7eS mefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hfuvRcqs5OfkqLEVNsidktZ+jKUH0rTVb5n02tUkPQ8=; b=gL3Imd2hfPa38gF6Bne4spnxce5kydq8AzHmhvYX56Leua1jMB+WyFC+FxvEvTwian 9vRl6H+PtPwxDVRCoS0sPwB7C5k4UZOAmTShY/Kne56M/Gqmgy2rHePrtNu/OamvFCiM r+KF6hLkX2ZbdQJ9egKeWtk8voEsRMZpOumI/10/4zUs7Wo7vOuSIQTOcthZ/O8H03KF s5mDazK64dVjHM/IsztIwz06CexuEWQt1wm/clPGkxwbzCeZGN3oL1fdol4n6Dc4Pcnk pfOFAzulWsZ9KImRgrWX8ORr5GtV4PPMtDusxWpLOvd9xS8zBkbXpfrTcXznh1amULbf tWqg== X-Gm-Message-State: ALoCoQnW81QcAItHmIdpV+w5eM6kypTB7SlTVExTM+HF6zCFZib2eiXZpdzH8VO37Lap3uFLo12A MIME-Version: 1.0 X-Received: by 10.182.58.81 with SMTP id o17mr21244552obq.82.1421161832764; Tue, 13 Jan 2015 07:10:32 -0800 (PST) Received: by 10.182.199.100 with HTTP; Tue, 13 Jan 2015 07:10:32 -0800 (PST) In-Reply-To: <54AEDF44.2040907@bbn.com> References: <54AD7445.4050604@gmail.com> <54AEDF44.2040907@bbn.com> Date: Tue, 13 Jan 2015 15:10:32 +0000 Message-ID: From: Eran Messeri To: Stephen Kent Content-Type: multipart/alternative; boundary=e89a8f83a83b35f1c2050c8a0685 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Addendum 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, 13 Jan 2015 15:10:36 -0000 --e89a8f83a83b35f1c2050c8a0685 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent wrote: > I have a few questions/comments about the set of proposed ticket closures: > > > #37 - Are the gossiping clients discussed by this ticket just Auditors and > Monitors, or > does it apply to TLS clients as well? Yes. Do you find it necessary to explicitly state that? > Also, if gossiping is addressed in a separate set > of docs, does that mean that 6962-bis will make only minimal mention of > it? That seems > appropriate since until those specs are completed and approved, on cannot > attribute > any security features to gossiping, right? > Correct - let's break this to two: (1) How clients can compare instances of Signed Tree Heads. (2) The security features that are achieved by comparing instances of STHs. 6962-bis makes only minimal mention of gossip in relation to (1). Regarding (2), rfc6962-bis can only point out the overall benefit of comparing STH instances (and it does), but the exact security benefits depends on the mechanism used for (1). FYI, the text diff is here: https://github.com/google/certificate-transparency-rfcs/commit/52b15187c291a9a9e4aa2fa7146693d7487899f4 > > #15 + #38 - For what range of clients is behavior not being specified? My > recollection from > the IETF meeting was that the discussion focused on TLS clients, not > Monitors or > Auditors, but the ticket closing comment is not clear on this point. Also, > is it useful > (vs. confusing) to discuss possible client behaviors in this doc, yet > mandate none? I don't > recall this issue (what to say about client behavior if we mandate none) > being discussed > ion detail on the list. > (1) Client behaviour is mostly not specified for TLS clients, which, as you correctly point out, was the topic discussed during the IETF meeting. Regarding monitors, given that there's benefit to the community even from partial monitors, I do not think it's reasonable to require a monitor to do *all* the things described in 6962-bis to be compliant, but point out the useful operations a monitor can perform and how it can do them. (2) I think it's useful to point out the possible situations a TLS client my find itself in, so we have common terminology when we discuss client behaviour. It was not discussed on detail on the list but different aspects have been brought up in the last IETF meeting and on several tickets. > > #40 - I don't recall seeing an explanation by the editors about why they > have decided > that "stand-along auditing isn't likely to happen." Absent such an > explanation, and WG > concurrence, it seems that closing this ticket is premature. > Is "based on experience from deploying RFC6962" a valid explanation? :) In my opinion this section in RFC6962 was not clear and Ben added (in-person) that his intent was never to have a stand-alone entity that only does auditing, but that it is something that each participant in CT could do. The original section in RFC6962 contained a bit of both, so we cleared it up to indicate what are the auditing operations each participant can do. > > #42 - Since this is a ticket I submitted, let me say that I don't think the > adverb "overly" is appropriate ;-). My concern is that the text didn't > provide an > algorithmic way to determine when a submitted (pre-)cert with a redacted > SAN was > "dangerous" and ought not be accepted. Also, the issue was not whether a > single entity > controls the name space covered by the redacted name; it's whether the CA > submitting the > pre-cert controls that space. Finally, if we are not specifying how any > client (TLS or Monitor) > makes use of this feature, why is it part of the spec? Unless we have an > agreed-upon set of > rules for how to use redacted certs, we are adding complexity to 6962-bis > without identifying > any benefits. > (1) to the best of my knowledge, detecting when a wildcard in a SAN is "too wild" is not specified anywhere, other than the CA/Browser Forum BR, and that is an equivalent problem. That's why I don't think it's appropriate to try and specify it here. (2) This falls into the TLS client behaviour specification - we'll point out this situation but it's up to the client to decide what to do with such a certificate. > > #43 - If key rollover is not supported, then the "freeze and begin a new > one" process > needs to be documented in detail. This description must describe how > clients of the old > log become aware of the transition to a new log (to avoid false positives). > Acknowledged - this will be described in the metadata section I intend to add. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --e89a8f83a83b35f1c2050c8a0685 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent <kent@bbn.com> w= rote:
I have a few questions/comments about the set of = proposed ticket closures:


#37 - Are the gossiping clients discussed by this ticket just Auditors and = Monitors, or
does it apply to TLS clients as well?
Yes. Do you find it = necessary to explicitly state that?=C2=A0
Also, if g= ossiping is addressed in a separate set
of docs, does that mean that 6962-bis will make only minimal mention of it?= That seems
appropriate since until those specs are completed and approved, on cannot a= ttribute
any security features to gossiping, right?
=C2=A0Corre= ct - let's break this to two:
(1) How clients can compare ins= tances of Signed Tree Heads.
(2) The security features that are a= chieved by comparing instances of STHs.
6962-bis makes only minim= al mention of gossip in relation to (1).=C2=A0
Regarding (2), rfc= 6962-bis can only point out the overall benefit of comparing STH instances = (and it does), but the exact security benefits depends on the mechanism use= d for (1).
FYI, the text diff is here:

#15 + #38 - For what range of clients is behavior not being specified? My r= ecollection from
the IETF meeting was that the discussion focused on TLS clients, not Monito= rs or
Auditors, but the ticket closing comment is not clear on this point. Also, = is it useful
(vs. confusing) to discuss possible client behaviors in this doc, yet manda= te none? I don't
recall this issue (what to say about client behavior if we mandate none) be= ing discussed
ion detail on the list.
(1) Client behaviour is mostly= not specified for TLS clients, which, as you correctly point out, was the = topic discussed during the IETF meeting. Regarding monitors, given that the= re's benefit to the community even from partial monitors, I do not thin= k it's reasonable to require a monitor to do *all* the things described= in 6962-bis to be compliant, but point out the useful operations a monitor= can perform and how it can do them.
(2) I think it's useful = to point out the possible situations a TLS client my find itself in, so we = have common terminology when we discuss client behaviour. It was not discus= sed on detail on the list but different aspects have been brought up in the= last IETF meeting and on several tickets.

#40 - I don't recall seeing an explanation by the editors about why the= y have decided
that "stand-along auditing isn't likely to happen." Absent su= ch an explanation, and WG
concurrence, it seems that closing this ticket is premature.
Is "based on experience from deploying RFC6962" a valid ex= planation? :)
In my opinion this section in RFC6962 was not clear= and Ben added (in-person) that his intent was never to have a stand-alone = entity that only does auditing, but that it is something that each particip= ant in CT could do. The original section in RFC6962 contained a bit of both= , so we cleared it up to indicate what are the auditing operations each par= ticipant can do.

#42 - Since this is a ticket I submitted, let me say that I don't think= the
adverb "overly" is appropriate ;-). My concern is that the text d= idn't provide an
algorithmic way to determine when a submitted (pre-)cert with a redacted SA= N was
"dangerous" and ought not be accepted. Also, the issue was not wh= ether a single entity
controls the name space covered by the redacted name; it's whether the = CA submitting the
pre-cert controls that space. Finally, if we are not specifying how any cli= ent (TLS or Monitor)
makes use of this feature, why is it part of the spec? Unless we have an ag= reed-upon set of
rules for how to use redacted certs, we are adding complexity to 6962-bis w= ithout identifying
any benefits.
(1) to the best of my knowledge, detecti= ng when a wildcard in a SAN is "too wild" is not specified anywhe= re, other than the CA/Browser Forum BR, and that is an equivalent problem. = That's why I don't think it's appropriate to try and specify it= here.
(2) This falls into the TLS client behaviour specification= - we'll point out this situation but it's up to the client to deci= de what to do with such a certificate.

#43 - If key rollover is not supported, then the "freeze and begin a n= ew one" process
needs to be documented in detail. This description must describe how client= s of the old
log become aware of the transition to a new log (to avoid false positives).=
Acknowledged - this will be described in the metadata= section I intend to add.=C2=A0

Steve


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

--e89a8f83a83b35f1c2050c8a0685-- From nobody Wed Jan 14 12:10:12 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C95B1AD366 for ; Wed, 14 Jan 2015 12:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DB9ZcVxlLkJ for ; Wed, 14 Jan 2015 12:10:07 -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 B11DE1AD49F for ; Wed, 14 Jan 2015 12:09:59 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:48874 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YBUGM-0005PS-AA for trans@ietf.org; Wed, 14 Jan 2015 15:09:58 -0500 Message-ID: <54B6CD16.4030105@bbn.com> Date: Wed, 14 Jan 2015 15:09:58 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> In-Reply-To: <54AB17A5.1090505@comodo.com> Content-Type: multipart/alternative; boundary="------------010608040106070001000909" Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 14 Jan 2015 20:10:10 -0000 This is a multi-part message in MIME format. --------------010608040106070001000909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Rob, You made several good points that address the concerns I raised. If the pre-cert format is NOT a cert (or a TBScertificate), then the syntax specified in 5280 and its predecessors (and X.509) don't strictly apply. I forgot, what is the source of the CMS object format we decided upon. I also checked with one of the authors of 2459 and he agreed that we always thought in terms of "*" as _the_ wildcard character, but that since we didn't say so explicitly, there is no basis for rejecting "?" or another character. I do suggest that the WG coordinate with some DNS experts to see what they think about our use of non-DNS characters in what is a DNS name pattern matching context, and whether they have a preference for any specific character. The distinction that you made between the semantics of "*" and the intended semantics for "PRIVATE" was one I had not realized . Specifically, you noted that "*" matches any labal whereas "?" is intended to match only one (redacted) label. That seems like a good reason to us a different character, but it also raises the question of how a Monitor or TLS client is supposed to enforce this requirement. Do you envision these clients remembering every cert that they encounter that matches a redacted pre-cert, and check to see if a CA has issue two certs with different values for a redacted DNS label? if not, why state this as a requirement? Steve --------------010608040106070001000909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rob,

You made several good points that address the concerns I raised. If the pre-cert format is NOT a cert
(or a TBScertificate), then the syntax specified in 5280 and its predecessors (and X.509)
don't strictly apply.  I forgot, what is the source of the CMS object format we decided upon.

I also checked with one of the authors of 2459 and he agreed that we always thought in terms
of "*" as the wildcard character, but that since we didn't say so explicitly, there is no
basis for rejecting "?" or another character.  I do suggest that the WG coordinate with some
DNS experts to see what they think about our use of non-DNS characters in what is a DNS
name pattern matching context, and whether they have a preference for any specific character.

The distinction that you made between the semantics of "*" and the intended semantics
for "PRIVATE" was one I had not realized . Specifically, you noted that "*" matches
any labal whereas "?" is intended to match only one (redacted) label.  That seems like
a good reason to us a different character, but it also raises the question of how
a Monitor or TLS client is supposed to enforce this requirement. Do you envision these clients
remembering every cert that they encounter that matches a redacted pre-cert, and check to
see if a CA has issue two certs with different values for a redacted DNS label? if not, why
state this as a requirement?

Steve
--------------010608040106070001000909-- From nobody Wed Jan 14 14:00:21 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6332B1ACD8E for ; Wed, 14 Jan 2015 14:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOsUs-5LglS5 for ; Wed, 14 Jan 2015 14:00:15 -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 668621ACD6B for ; Wed, 14 Jan 2015 14:00:03 -0800 (PST) Received: (qmail 5376 invoked by uid 1004); 14 Jan 2015 22:00:01 -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, 14 Jan 2015 22:00:01 +0000 Received: (qmail 20221 invoked by uid 1000); 14 Jan 2015 22:00:01 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 14 Jan 2015 22:00:01 +0000 Message-ID: <54B6E6E0.4040509@comodo.com> Date: Wed, 14 Jan 2015 22:00:00 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> In-Reply-To: <54B6CD16.4030105@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 14 Jan 2015 22:00:19 -0000 On 14/01/15 20:09, Stephen Kent wrote: > Rob, > > You made several good points that address the concerns I raised. Thanks Steve. :-) > If the pre-cert format is NOT a cert (or a TBScertificate), > then the syntax specified in 5280 and its predecessors (and X.509) > don't strictly apply. I forgot, what is the source of the CMS object > format we decided upon. The new precert format will be documented in the -05 version of the 6962-bis I-D (which we intend to publish real soon now). For a preview of the text, look here... https://github.com/google/certificate-transparency-rfcs/blob/master/rfc6962-bis.xml#L332 It's not (just) a TBSCertificate, but it does incorporate a TBSCertificate (wrapped inside a CMS signed-data object). > I also checked with one of the authors of 2459 and he agreed that we > always thought in terms of "*" as _the_ wildcard character, but that > since we didn't say so explicitly, there is no basis for rejecting > "?" or another character. I do suggest that the WG coordinate with some > DNS experts to see what they think about our use of non-DNS characters > in what is a DNS name pattern matching context, and whether they have a > preference for any specific character. That seems like a good idea. Did you have any particular DNS experts in mind? > The distinction that you made between the semantics of "*" and the > intended semantics for "PRIVATE" was one I had not realized. > Specifically, you noted that "*" matches any labal whereas "?" is > intended to match only one (redacted) label. > That seems like a good reason to us a different character, but it also > raises the question of how a Monitor or TLS client is supposed to > enforce this requirement. Do you envision these clients remembering > every cert that they encounter that matches a redacted pre-cert, and > check to see if a CA has issue two certs with different values for a > redacted DNS label? No, I wasn't envisaging that Monitors and/or TLS clients would necessarily do that. > if not, why state this as a requirement? I don't think the current text does state this as a requirement. If there are multiple certs (which may or may not contain different unredacted domain label(s)) that match one redacted precert, then those certs will all share the same Serial Number and be issued by the same CA. RFC5280 already disallows this, so 6962-bis doesn't also need to disallow it. :-) Hmmm... Should we specify that the redaction label (i.e. "(PRIVATE)" or "?" or whatever the DNS experts prefer) MUST NOT match "*" in the cert? I can't think of a legitimate reason to hide wildcard certs from the log. > Steve > > > _______________________________________________ > 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 Fri Jan 16 10:30:11 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B051B2A19 for ; Fri, 16 Jan 2015 10:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3fbzyYHwvTM for ; Fri, 16 Jan 2015 10:30:05 -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 04E6F1ACE84 for ; Fri, 16 Jan 2015 10:30:05 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:43655 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YCBek-000KMi-KM; Fri, 16 Jan 2015 13:30:03 -0500 Message-ID: <54B958AA.9040009@bbn.com> Date: Fri, 16 Jan 2015 13:30:02 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eran Messeri References: <54AD7445.4050604@gmail.com> <54AEDF44.2040907@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010502020408020707040207" Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Addendum 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, 16 Jan 2015 18:30:10 -0000 This is a multi-part message in MIME format. --------------010502020408020707040207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eran, > On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent > wrote: > > I have a few questions/comments about the set of proposed ticket > closures: > > > #37 - Are the gossiping clients discussed by this ticket just > Auditors and Monitors, or > does it apply to TLS clients as well? > > Yes. Do you find it necessary to explicitly state that? yes, I do. Gossiping among Monitors and Auditors seems more realistic than gossiping among TLS clients. The former are (presumably) a much smaller set of entities than the latter, and may be well known, making it credible that they may choose to communicate. > > Also, if gossiping is addressed in a separate set > of docs, does that mean that 6962-bis will make only minimal > mention of it? That seems > appropriate since until those specs are completed and approved, on > cannot attribute > any security features to gossiping, right? > > Correct - let's break this to two: > (1) How clients can compare instances of Signed Tree Heads. > (2) The security features that are achieved by comparing instances of > STHs. > 6962-bis makes only minimal mention of gossip in relation to (1). > Regarding (2), rfc6962-bis can only point out the overall benefit of > comparing STH instances (and it does), but the exact security benefits > depends on the mechanism used for (1). My reason for posing this question is so that I can accurately update the attack analysis that I posted previously, and that I hope will be part of 6962-bis. Since gossiping is not being specified yet, this means that some attacks that would have been detected will now be described as successful. > FYI, the text diff is here: > https://github.com/google/certificate-transparency-rfcs/commit/52b15187c291a9a9e4aa2fa7146693d7487899f4 > > > #15 + #38 - For what range of clients is behavior not being > specified? My recollection from > the IETF meeting was that the discussion focused on TLS clients, > not Monitors or > Auditors, but the ticket closing comment is not clear on this > point. Also, is it useful > (vs. confusing) to discuss possible client behaviors in this doc, > yet mandate none? I don't > recall this issue (what to say about client behavior if we mandate > none) being discussed > ion detail on the list. > > (1) Client behaviour is mostly not specified for TLS clients, which, > as you correctly point out, was the topic discussed during the IETF > meeting. Regarding monitors, given that there's benefit to the > community even from partial monitors, I do not think it's reasonable > to require a monitor to do *all* the things described in 6962-bis to > be compliant, but point out the useful operations a monitor can > perform and how it can do them. Again, my reason for posing this question is to enable updating of the attack analysis. First, I'm not sure what a "partial" Monitor is. In my description of the function, a Monitor looks for certs in logs relative to a set of client-specified criteria. So, no Monitor is expected to examine ALL certs being logged on behalf of everybody. Second, I think I suggested that each Monitor advertise the set of logs that it examines, so there is also no expectation that every Monitor examines every log. So, if one adopts these definitions of what a Monitor does, what is a "partial" Monitor? If you think these definitions aren't appropriate, please offer concrete, alternative text, so that we have a common basis for discussing Monitor behavior. If we just describe "useful" operations for Monitors, then an attack analysis can't be accurate in describing what benefits Monitors confer. I'd argue for being more precise in describing a minimal set of Monitor functions that every Monitor MUST perform, and then note additional, optional operations, if necessary. The two I-Ds that Rick and I authored, on checks to be performed for DV and EV certs, follow this model. If 6962-bis adds text of the sort I proposed, calling for a submitter of a (pre-)cert to state what sort of cert it is, then one can defer the spec of Monitor (and optional log) checking to the ancillary docs for each cert type. > (2) I think it's useful to point out the possible situations a TLS > client my find itself in, so we have common terminology when we > discuss client behaviour. It was not discussed on detail on the list > but different aspects have been brought up in the last IETF meeting > and on several tickets. I'm not sure what "situations" means here; please elaborate. > > > #40 - I don't recall seeing an explanation by the editors about > why they have decided > that "stand-along auditing isn't likely to happen." Absent such an > explanation, and WG > concurrence, it seems that closing this ticket is premature. > > Is "based on experience from deploying RFC6962" a valid explanation? :) not for me ;-). > In my opinion this section in RFC6962 was not clear and Ben added > (in-person) that his intent was never to have a stand-alone entity > that only does auditing, but that it is something that each > participant in CT could do. The original section in RFC6962 contained > a bit of both, so we cleared it up to indicate what are the auditing > operations each participant can do. Is a "participant" a client or is this a new, more generic term? > > > #42 - Since this is a ticket I submitted, let me say that I don't > think the > adverb "overly" is appropriate ;-). My concern is that the text > didn't provide an > algorithmic way to determine when a submitted (pre-)cert with a > redacted SAN was > "dangerous" and ought not be accepted. Also, the issue was not > whether a single entity > controls the name space covered by the redacted name; it's whether > the CA submitting the > pre-cert controls that space. Finally, if we are not specifying > how any client (TLS or Monitor) > makes use of this feature, why is it part of the spec? Unless we > have an agreed-upon set of > rules for how to use redacted certs, we are adding complexity to > 6962-bis without identifying > any benefits. > > (1) to the best of my knowledge, detecting when a wildcard in a SAN is > "too wild" is not specified anywhere, other than the CA/Browser Forum > BR, and that is an equivalent problem. That's why I don't think it's > appropriate to try and specify it here. I see your point, but disagree. Yes, the use of wildcard DNS names in certs is analogous, to the redacted cert issue for pre-certs. But, as Rob noted in his message, the semantics are not identical. This is new, a CT-created topic. The CABF defines (for DV certs) the criteria to be used by a CA when a Subject requests a wildcard cert, and that spec is more detailed than what the most recent version of 6962-bis says. You seem to be saying that the IETF has no RFC for what constitutes appropriate checks for issuing a wildcard cert. Yes, that's true, but since we have no standards for ANY Web PKI cert issuance, this seems like an irrelevant observation ion this case. We're creating a new opportunity for bad things to happen, so why do we get a pass on addressing the security issues that arise? The CABF DV cert BR describes (11.1.3) the checks that a CA is supposed to perform to ensure that the Subject of such a cert controls the affected DNS subtree (and the EV spec prohibits wildcards). This is an appropriate statement because it is describing a procedure to be followed by a CA. But, in CT, CAs are not trusted, and the goal is to enable clients (of all sorts) to detect mis-issued certs. I don't think we can rely on a procedural statement for a CA to use here. 6962-bis needs to be more specific about what clients (at least Monitors, if we punt on requirements for TLS clients) are supposed to do to detect bad redacted certs. If we describe Monitor behavior, then at least we can justify the text by saying what a Monitor does when checking logs of redacted certs against cert info for its clients. > (2) This falls into the TLS client behaviour specification - we'll > point out this situation but it's up to the client to decide what to > do with such a certificate. Also Monitor behavior, as noted above. > > > #43 - If key rollover is not supported, then the "freeze and begin > a new one" process > needs to be documented in detail. This description must describe > how clients of the old > log become aware of the transition to a new log (to avoid false > positives). > > Acknowledged - this will be described in the metadata section I intend > to add. great. --------------010502020408020707040207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eran,

On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent <kent@bbn.com> wrote:
I have a few questions/comments about the set of proposed ticket closures:


#37 - Are the gossiping clients discussed by this ticket just Auditors and Monitors, or
does it apply to TLS clients as well?
Yes. Do you find it necessary to explicitly state that?
yes, I do. Gossiping among Monitors and Auditors seems more realistic than gossiping
among TLS clients. The former are (presumably) a much smaller set of entities
than the latter, and may be well known, making it credible that they may choose to communicate.
Also, if gossiping is addressed in a separate set
of docs, does that mean that 6962-bis will make only minimal mention of it? That seems
appropriate since until those specs are completed and approved, on cannot attribute
any security features to gossiping, right?
 Correct - let's break this to two:
(1) How clients can compare instances of Signed Tree Heads.
(2) The security features that are achieved by comparing instances of STHs.
6962-bis makes only minimal mention of gossip in relation to (1). 
Regarding (2), rfc6962-bis can only point out the overall benefit of comparing STH instances (and it does), but the exact security benefits depends on the mechanism used for (1).
My reason for posing this question is so that I can accurately update the attack analysis that
I posted previously, and that I hope will be part of 6962-bis. Since gossiping is not being
specified yet, this means that some attacks that would have been detected will now be described
as successful.
FYI, the text diff is here:

#15 + #38 - For what range of clients is behavior not being specified? My recollection from
the IETF meeting was that the discussion focused on TLS clients, not Monitors or
Auditors, but the ticket closing comment is not clear on this point. Also, is it useful
(vs. confusing) to discuss possible client behaviors in this doc, yet mandate none? I don't
recall this issue (what to say about client behavior if we mandate none) being discussed
ion detail on the list.
(1) Client behaviour is mostly not specified for TLS clients, which, as you correctly point out, was the topic discussed during the IETF meeting. Regarding monitors, given that there's benefit to the community even from partial monitors, I do not think it's reasonable to require a monitor to do *all* the things described in 6962-bis to be compliant, but point out the useful operations a monitor can perform and how it can do them.
Again, my reason for posing this question is to enable updating of the attack analysis. First, I'm
not sure what a "partial" Monitor is. In my description of the function, a Monitor looks for
certs in logs relative to a set of client-specified criteria. So, no Monitor is expected to
examine ALL certs being logged on behalf of everybody. Second, I think I suggested that each
Monitor advertise the set of logs that it examines, so there is also no expectation that every
Monitor examines every log. So, if one adopts these definitions of what a Monitor does, what is
a "partial" Monitor? If you think these definitions aren't appropriate, please offer concrete,
alternative text, so that we have a common basis for discussing Monitor behavior.

If we just describe "useful" operations for Monitors, then an attack analysis can't be accurate
in describing what benefits Monitors confer. I'd argue for being more precise in describing a minimal
set of Monitor functions that every Monitor MUST perform, and then note additional, optional
operations, if necessary. The two I-Ds that Rick and I authored, on checks to be performed
for DV and EV certs, follow this model. If 6962-bis adds text of the sort I proposed, calling
for a submitter of a (pre-)cert to state what sort of cert it is, then one can defer the
spec of Monitor (and optional log) checking to the ancillary docs for each cert type.

(2) I think it's useful to point out the possible situations a TLS client my find itself in, so we have common terminology when we discuss client behaviour. It was not discussed on detail on the list but different aspects have been brought up in the last IETF meeting and on several tickets.
I'm not sure what "situations" means here; please elaborate.

#40 - I don't recall seeing an explanation by the editors about why they have decided
that "stand-along auditing isn't likely to happen." Absent such an explanation, and WG
concurrence, it seems that closing this ticket is premature.
Is "based on experience from deploying RFC6962" a valid explanation? :)
not for me ;-).
In my opinion this section in RFC6962 was not clear and Ben added (in-person) that his intent was never to have a stand-alone entity that only does auditing, but that it is something that each participant in CT could do. The original section in RFC6962 contained a bit of both, so we cleared it up to indicate what are the auditing operations each participant can do.
Is a "participant" a client or is this a new, more generic term?

#42 - Since this is a ticket I submitted, let me say that I don't think the
adverb "overly" is appropriate ;-). My concern is that the text didn't provide an
algorithmic way to determine when a submitted (pre-)cert with a redacted SAN was
"dangerous" and ought not be accepted. Also, the issue was not whether a single entity
controls the name space covered by the redacted name; it's whether the CA submitting the
pre-cert controls that space. Finally, if we are not specifying how any client (TLS or Monitor)
makes use of this feature, why is it part of the spec? Unless we have an agreed-upon set of
rules for how to use redacted certs, we are adding complexity to 6962-bis without identifying
any benefits.
(1) to the best of my knowledge, detecting when a wildcard in a SAN is "too wild" is not specified anywhere, other than the CA/Browser Forum BR, and that is an equivalent problem. That's why I don't think it's appropriate to try and specify it here.
I see your point, but disagree. Yes, the use of wildcard DNS names in certs is analogous, to
the redacted cert issue for pre-certs.  But, as Rob noted in his message, the semantics are
not identical. This is new, a CT-created topic. The CABF defines (for DV certs) the
criteria to be used by a CA when a Subject requests a wildcard cert, and that spec is more
detailed than what the most recent version of 6962-bis says. You seem to be saying that
the IETF has no RFC for what constitutes appropriate checks for issuing a wildcard cert.
Yes, that's true, but since we have no standards for ANY Web PKI cert issuance, this seems
like an irrelevant observation ion this case. We're creating a new opportunity for bad things
to happen, so why do we get a pass on addressing the security issues that arise?  The CABF DV
cert BR describes (11.1.3) the checks that a CA is supposed to perform to ensure that the Subject
of such a cert controls the affected DNS subtree (and the EV spec prohibits wildcards). This
is an appropriate statement because it is describing a procedure to be followed by a CA.
But, in CT, CAs are not trusted, and the goal is to enable clients (of all sorts) to detect
mis-issued certs. I don't think we can rely on a procedural statement for a CA to use here.
6962-bis needs to be more specific about what clients (at least Monitors, if we punt on
requirements for TLS clients) are supposed to do to detect bad redacted certs. If we describe
Monitor behavior, then at least we can justify the text by saying what a Monitor does when
checking logs of redacted certs against cert info for its clients.

(2) This falls into the TLS client behaviour specification - we'll point out this situation but it's up to the client to decide what to do with such a certificate.
Also Monitor behavior, as noted above.

#43 - If key rollover is not supported, then the "freeze and begin a new one" process
needs to be documented in detail. This description must describe how clients of the old
log become aware of the transition to a new log (to avoid false positives).
Acknowledged - this will be described in the metadata section I intend to add.
great.

--------------010502020408020707040207-- From nobody Mon Jan 19 09:05:55 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFBA1B2A0D for ; Mon, 19 Jan 2015 09:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbtPfzibO-Ar for ; Mon, 19 Jan 2015 09:05:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF831ACD87 for ; Mon, 19 Jan 2015 09:05:47 -0800 (PST) Received: from localhost ([::1]:43685 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDFlr-0000Yb-BP; Mon, 19 Jan 2015 09:05:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 19 Jan 2015 17:05:47 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/54#comment:2 Message-ID: <079.e61fdfb3d14af1551441d60014d9fa8e@tools.ietf.org> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 19 Jan 2015 17:05:51 -0000 #54: Simplify name redaction Comment (by rob.stradling@comodo.com): I've just spotted the glaring error in this proposal. Without the "redactedLabels" extension in the Certificate, it would be rather hard to reconstruct the TBSCertificate and verify the SCT signature(s) because you'd have to guess which labels need to be changed to "?"s. Let's leave this ticket open for now, in the hope that we can find some other way to reduce the "risk of misalignment" that Eran mentioned. If we can't, then I suppose this ticket will need to be resolved as invalid. -- -------------------------------------+------------------------------------- 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 Mon Jan 19 09:10:14 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2864E1B2B12 for ; Mon, 19 Jan 2015 09:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95A0zxbD-Gww for ; Mon, 19 Jan 2015 09:09:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CC91B2B62 for ; Mon, 19 Jan 2015 09:09:43 -0800 (PST) Received: from localhost ([::1]:43764 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDFpc-0001EY-U5; Mon, 19 Jan 2015 09:09:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Mon, 19 Jan 2015 17:09:40 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/17#comment:5 Message-ID: <070.5518963939b5f3add4ff510fde4130f2@tools.ietf.org> References: <055.08fd455285c038bb24d0616bf52462c8@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <055.08fd455285c038bb24d0616bf52462c8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, 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 Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #17 (rfc6962-bis): Add advice on CNs 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, 19 Jan 2015 17:10:04 -0000 #17: Add advice on CNs Changes (by rob.stradling@comodo.com): * status: closed => reopened * resolution: duplicate => Comment: Replying to [comment:4 eranm@…]: > Ticket #54 addresses this, marking as duplicate. It turns out that the initial proposal in ticket #54 doesn't actually work. Reopening this ticket. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jan 19 09:12:05 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33B41B2B45 for ; Mon, 19 Jan 2015 09:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTzH_SqMgNKI for ; Mon, 19 Jan 2015 09:11:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03921B2B7D for ; Mon, 19 Jan 2015 09:11:39 -0800 (PST) Received: from localhost ([::1]:43834 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDFrW-0001la-Ey; Mon, 19 Jan 2015 09:11:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Mon, 19 Jan 2015 17:11:38 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/17#comment:6 Message-ID: <070.c57b0837057093e9d6ca9555a94f1b8e@tools.ietf.org> References: <055.08fd455285c038bb24d0616bf52462c8@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <055.08fd455285c038bb24d0616bf52462c8@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] #17 (rfc6962-bis): Add advice on CNs 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, 19 Jan 2015 17:12:02 -0000 #17: Add advice on CNs Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: reopened => new -- -----------------------------+--------------------------------------- Reporter: benl@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Jan 20 04:40:45 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2FE1B2A1A for ; Tue, 20 Jan 2015 04:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-mxmyu_wIm9 for ; Tue, 20 Jan 2015 04:40:38 -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 C02831B29B5 for ; Tue, 20 Jan 2015 04:40:38 -0800 (PST) Received: from localhost ([::1]:56970 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDY6o-0004Ev-Gy; Tue, 20 Jan 2015 04:40:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Tue, 20 Jan 2015 12:40:38 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/21#comment:4 Message-ID: <070.ea7de92ce04207a3fab0d1be536956c2@tools.ietf.org> References: <055.e195c2a1c7a5a4b76a9f7bef68253585@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <055.e195c2a1c7a5a4b76a9f7bef68253585@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] #21 (rfc6962-bis): Clarify signature checking purpose and mechanism X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 12:40:44 -0000 #21: Clarify signature checking purpose and mechanism Changes (by eranm@google.com): * status: new => closed * resolution: => fixed Comment: Committed as https://github.com/google/certificate-transparency- rfcs/commit/88c7bf44d6a5d81204276a637a1dd0a49c70b8b4 -- -----------------------------+------------------------------- Reporter: benl@google.com | Owner: eranm@google.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+------------------------------- Ticket URL: trans From nobody Tue Jan 20 04:43:15 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8311B2A32 for ; Tue, 20 Jan 2015 04:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZxXyLRIrZm2 for ; Tue, 20 Jan 2015 04:43:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CEA1B2A1A for ; Tue, 20 Jan 2015 04:43:11 -0800 (PST) Received: from localhost ([::1]:57063 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDY9H-0006rP-B2; Tue, 20 Jan 2015 04:43:11 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com X-Trac-Project: trans Date: Tue, 20 Jan 2015 12:43:11 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/31#comment:3 Message-ID: <067.bf90a05dc98faf8199b49ff7bf4c11f5@tools.ietf.org> References: <052.88969a6568e09ab3e9fd597ebb5d3047@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <052.88969a6568e09ab3e9fd597ebb5d3047@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] #31 (rfc6962-bis): incremental deployment and client behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 12:43:14 -0000 #31: incremental deployment and client behavior Comment (by eranm@google.com): Committed as https://github.com/google/certificate-transparency- rfcs/commit/075ef0338f7d9e989a6a54027ca5c457e2586e9b Leaving ticket open as a reminder to include this situation when listing situations a client may encounter. -- --------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | --------------------------+------------------------------- Ticket URL: trans From nobody Wed Jan 21 10:49:51 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1E11A6F29 for ; Wed, 21 Jan 2015 10:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg0MHPMVUX6k for ; Wed, 21 Jan 2015 10:49:40 -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 0ED8F1A6F2A for ; Wed, 21 Jan 2015 10:49:40 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:35607 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YE0LS-000Obh-Ki for trans@ietf.org; Wed, 21 Jan 2015 13:49:38 -0500 Message-ID: <54BFF4C2.20905@bbn.com> Date: Wed, 21 Jan 2015 13:49:38 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> In-Reply-To: <54B6E6E0.4040509@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 21 Jan 2015 18:49:42 -0000 Rob, > That seems like a good idea. Did you have any particular DNS experts > in mind? I'd ask Joel Jaeggli for suggestions. > >> if not, why state this as a requirement? > > I don't think the current text does state this as a requirement. Your message to me cited this as a reason for not using "*" in this context. If the different semantics for PRIVATE/? are not a requirement, that argument isn't applicable. Color me confused. > If there are multiple certs (which may or may not contain different > unredacted domain label(s)) that match one redacted precert, then > those certs will all share the same Serial Number and be issued by the > same CA. > RFC5280 already disallows this, so 6962-bis doesn't also need to > disallow it. :-) Can you cite the part of 5280 that you feel is applicable here? 4.1.2.2 notes that a cert serial number uniquely identifies a cert, which doesn't seem compatible with your comment. > Hmmm... > Should we specify that the redaction label (i.e. "(PRIVATE)" or "?" or > whatever the DNS experts prefer) MUST NOT match "*" in the cert? > I can't think of a legitimate reason to hide wildcard certs from the log. I agree that wildcard certs should be logged. Steve From nobody Thu Jan 22 08:48:27 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642331A1ACA for ; Thu, 22 Jan 2015 08:48:26 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fhPWE7CXu_X for ; Thu, 22 Jan 2015 08:48:18 -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 433E21A1AD2 for ; Thu, 22 Jan 2015 08:48:18 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:46400 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YEKvX-000EsU-W8 for trans@ietf.org; Thu, 22 Jan 2015 11:48:16 -0500 Message-ID: <54C129CF.3020800@bbn.com> Date: Thu, 22 Jan 2015 11:48:15 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------060405040006060001050903" Archived-At: Subject: [Trans] updated attack analysis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:48:26 -0000 This is a multi-part message in MIME format. --------------060405040006060001050903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit updated to reflect dropping TLS client behavior specs, no gossip protocol yet defined, and no stand-alone Auditors. comments welcome, but I'm abut to head off on vacation, so I won't be able to respond immediately Steve ------ *XX*. Attack Model and Discussion of Detection and Mitigation Options Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to detect and redress mis-issuance depends on the context and the entities involved in the mis-issuance. This attack model applies to the Web PKI context. If CT is applied to other contexts, each will require its own attack model, although most of the model described here is likely to be applicable. Certificates are issued by CAs, so the top level differentiation is whether the CA that mis-issued a certificate did so maliciously or not. If not, then the next point of differentiation is whether the mis-issuance was the result of an error, an attack, or malicious behavior by a CA. In the case of an attack or malicious behavior by a CA, it is necessary to consider whether the certificate was logged. If the certificate was logged, it is necessary to consider whether the log(s) may have conspired with the attacker. Finally, one must consider the possibility that a third party Monitor might collude with an attacker (or a malicious CA). Here’s an taxonomy of attacks and assumptions about the attack environment: 1.CA a.Non-malicious CA i.Error ii.Attack victim 1.Certificate logged a.Benign log i.Self-monitor ii.Benign 3^rd party Monitor iii.Conspiring 3^rd party Monitor b.Conspiring log 2.Certificate not logged b.Malicious CA i.Certificate logged 1.Benign log a.Self-monitor b.Benign 3^rd party Monitor c.Conspiring 3^rd party Monitor 2.Conspiring log ii.Certificate not logged The following sections examine each of these cases, for both syntactic and semantic mis-issuance. As noted above, the focus here is on the Web PKI context, although most of the analysis is applicable to other PKI contexts. *XX*.1 Non-malicious Web PKI CA context If a pre-certificate is submitted to a log, prior to issuance of a certificate, syntactic mis-issuance can (optionally) be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted (pre-) certificate. (A pre-certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance.) If syntactic validation fails, this will be noted in the SCT returned to the CA. Because this case assumes a non-malicious CA, the CA will remedy the syntactic problem and re-submit the pre-certificate to a log. In this case syntactic checking by a log helps avoid issuance of a malformed certificate. If a certificate is submitted by its Subject, we assume that the Subject will contact the issuer and request a new certificate if a log indicates that the certificate failed the applicable syntactic check. Here too syntactic checking by a log enables a Subject to be informed that its certificate is malformed and thus may hasten issuance of a replacement certificate. If the certificate was submitted by a third party, that party might contact the Subject or the issuer, but because the party is not the Subject of the certificate it is not clear how the issuer will respond. Bottom line: Syntactic mis-issuance of a certificate can be avoided by a CA if it makes use of logs that are capable of performing these checks for the types of certificates that are submitted, and if the CA acts on the feedback it receives. If a CA uses a log that does not perform such checks, or if the CA requests checking relative to criteria not supported by the log, then syntactic mis-issuance will not be detected or avoided by this mechanism. Syntactic mis-issuance can be remedied if a Subject submits a certificate to a log that performs syntactic checks, and if the Subject requests the issuer to fix problems detected by the log. (The issuer is presumed to be willing to re-issue the certificate, correcting any problems, because the CA is not malicious.) *XX*.1.1 A CA may issue the certificate to an unauthorized party (semantic mis-issuance), as a result of an error or because it was the victim of a social engineering attack. We will refer to such a certificate as “bogus”. In this case the CA has a record of the bogus certificate and it is prepared to revoke the bogus certificate once it has confirmed its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is “protecting” the affected Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should be able to revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate is irrelevant to the mitigation procedure in this case. (See Note 1 below.) Because the mis-issuance was not malicious, there is no notion of a log operator or a Monitor conspiring with the CA. *XX*.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a certificate. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content. *XX*.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and can alert the Subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will make use of the log entry (supplied by the Subject) to determine the serial number of the mis-issued certificate, and revoke it (after investigation). (See Notes 1 + 2.) _Since there is no requirement for a TLS client to reject a certificate when no SCT is provided, the preferred strategy for an attacker is to not log bogus certificates_. (See XX.1.2.2 and Note 3.) *XX*.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. _Since TLS clients are not required to reject a certificate that lacks (or is not accompanied by) an SCT, or even to notify a user in such situations, the attacker will not be thwarted in this case._ (See Note 3.) XX.1.2.3 The bogus certificate may have been submitted to logs that are conspiring with the attacker. In this case, Monitors will not detect the bogus certificate because the logs will suppress a bogus certificate log entry. TLS clients will not reject a bogus certificate in this case, because it is accompanied by an SCT. In this scenario, unless Monitors “gossip” to detect conspiring logs, the bogus certificate will not be detected. _Because there are no requirements for such gossiping, an attack of this sort can succeed based on the current CT design._ __ XX.1.2.4 If a semantically bogus certificate is submitted to non-conspiring logs, a Subject performing self-monitoring will be able to detect the bogus certificate and request revocation. If a Subject relies on a third-party Monitor, and that Monitor conspires with the attacker, the Subject will not be alerted and thus will not request revocation. *XX*.2 Malicious Web PKI CA context *XX*.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance. Because the CA is presumed to be malicious, the CA may cause the log to not perform checks, in one of several ways. 1.The CA may assert that the certificate is being issued w/o regard to any guidelines (the “no guidelines” reserved CCID). 2.The CA may assert a CCID that has not been registered, and thus no log will be able to perform a check. 3.the CA may check to see which CCIDs a log declares it can check, and chose a registered CCID that is not checked by the log in question. In this fashion the CA can prevent the log from performing checks, and the SCT and log entry will not contain an indication of a failed check. 4.The CA may submit a (pre-) certificate to a log that is known to not perform any syntactic checks, and thus avoid syntactic checking. _Since there is no requirement that a TLS client can be configured to reject a certificate that has not been syntactically checked (as indicated by the SCT), a malicious CA need not worry about failing a log-based check. Similarly, _ _since there is no requirement for a TLS client to reject a certificate that was logged by an operator that does not perform syntactic checks, the fourth approach noted above will succeed as well_. If a client were configured to know which versions of certificate types are applicable to its use of a certificate, the second and third strategies noted above could be thwarted. *XX*.2.2 Because the CA is presumed malicious, it may choose to not submit a certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. _Since there is no requirement for a TLS client to reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will succeed. (See Note 3.)_ *XX*.2.3 A malicious CA may submit a certificate to one or more logs that collude with this CA to not perform syntactic checks, even though they claim to do so. In this case syntactic mis-issuance will not be detected by logs. The log entry and the SCT for a syntactically invalid certificate will assert that the certificate syntax was verified. Unless Monitors also perform syntactic checks, this form of mis-issuance will not be thwarted. TLS clients will believe that the certificate has been syntactically verified. *XX*.2.4 A malicious CA may semantically mis-issue a certificate that is syntactically valid. Because it is syntactically valid, logs will not mark the bogus certificate as failing a syntax check. The semantically bogus certificate may have been issued because the CA was bribed or was compelled to issue the certificate. (A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.)This CA might be one or more tiers below a trust anchor (aka root CA). *XX*.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. _Since there is no requirement for a TLS client to reject a certificate that lacks (or is not accompanied by) an SCT, there is no motivation for an attacker to submit the certificate in this case. (See Note 3.)_ *XX*.2.4.2 A bogus pre-certificate may have been submitted to one or more logs, to acquire an embedded SCT, a certificate may have been submitted post-issuance (to acquire a standalone SCT). In either case, a (non-conspiring) Monitor protecting the targeted Subject will detect a bogus certificate and alert that Subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc. In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4.) *XX*.2.4.3 If a third-party Monitor conspires with the malicious CA, then it will not notify the targeted Subject when a bogus certificate is logged. If a Subject performs self-monitoring this sort of attack will be avoided. *XX*.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor (even a self-Monitor) from which the log is hiding data will not detect the bogus certificate, even if it is trying to protect the targeted Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the bogus certificate. The audit function is intended to detect logs that conspire to suppress log entries, based on consistency checking of logs and use of a “gossip” protocol. It is assumed that Monitors will perform the audit functions described in Section <*insert #*>. A Monitor performing an audit function could alert its clients if the Monitor detects evidence of malfeasant log operation. This would cause Monitors to avoid using such a log, and clients would reject SCTs generated by such a log. _Because there is no defined gossip protocol, CT does not provide the necessary info to detect this form of mis-issuance. _(See Note 5 below.) Notes: 1.If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide “sufficient” coverage? If a Subject acts as its own Monitor, this problem is solved for that Subject. It also is not clear how a Monitor becomes aware of all (relevant?) logs, including newly created logs. The means by which Monitors become aware of new logs MUST accommodate self-monitoring by a potentially very large number of web site operators. 2.A CA being presented with evidence of a bogus certificate, in the form of a log entry, will need to examine its records to determine if it has knowledge of the certificate in question. It also will likely require the targeted Subject to provide assurances that it is the authorized entity representing the Subject name (subjectAltname) in question. Thus a Subject should not expect immediate revocation of a contested certificate. The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA. Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on applicable criteria. The SCT and log entry, because each contains a timestamp from a third party, is probably valuable for forensic purposes (assuming a non-conspiring log operator). 3.If a TLS client were to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules. _Until a mechanism is defined that accommodates incremental deployment of this capability, attackers probably will avoid submitting bogus certificates to (non-conspiring) logs as a means of evading detection._ 4.A targeted Subject might request the parent of a malicious CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If this specification were to require that a browser can be configured to reject a specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. This mitigation strategy calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication has not been specified, i.e., there are no standard ways to configure a browser to reject individual bogus certificates based on info provided by an external entity such as a Monitor. Moreover, the same or another malicious CA could issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks. 5.The combination of a malicious CA and one or more conspiring logs motivates the definition of an audit function, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or more SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if Monitors and clients reject certificates that contains SCTs from conspiring logs (based on info from an audit) will CT be able to deter use of such logs. Thus the means by which a Monitor performing an audit function detect such logs, and inform TLS clients must be specified for this to be effective. Moreover, if a certificate (or TLS handshake) contains more than one SCT, unless the client verifies all of them if it is to counter the threat posed by conspiring logs. Absent a “gossip” protocol that enables Monitors to verify that data from logs are reported in a consistent fashion, CT does not provide protection against logs that may conspire with, or are victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log? Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance. Monitors play a critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. A monitor (including a Subject performing self-monitoring) examines logs for certificates associated with one or more Subjects. It must obtain a list valid certificates for the Subject being monitored, in a secure manner. Note: A Monitor must not rely on a CA or RA database for this information or use certificate discovery protocols; this information must be acquired by the Monitor based on reference certificates provided by a Subject. If a Monitor were to rely on a CA or RA database (for the CA that issued a targeted certificate), the Monitor would not detect mis-issuance due to malfeasance on the part of that CA or the RA, or due to compromise of the CA or the RA. If a CA or RA database is used, it does detect mis-issuance by an unauthorized CA. A Monitor must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms might result in mis-issued certificates being added to the list. As noted above, Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject, as noted above. It is RECOMMENDED that a Subject request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors. However, the burden of Monitor operation may be viewed as too great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise. A final note: Now that certificate pinning has been approved as a standard (currently in the RFC Editor’s queue), it is appropriate to factor in its use by TLS clients. It would appear that pinning will dramatically reduce the set of TLS clients that are vulnerable to mis-issuance; a client that pins a certificate for a web site would reject a bogus certificate without use of any CT mechanisms. The security considerations section of 6962-bis needs to note this, since deployment of pinning appears to reduces the need for CT in the Web PKI context. --------------060405040006060001050903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit updated to reflect dropping TLS client behavior specs, no gossip protocol yet defined,
and no stand-alone Auditors.

comments welcome, but I'm abut to head off on vacation, so I won't be able to respond immediately

Steve
------

XX. Attack Model and Discussion of Detection and Mitigation Options

 

Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to detect and redress mis-issuance depends on the context and the entities involved in the mis-issuance. This attack model applies to the Web PKI context. If CT is applied to other contexts, each will require its own attack model, although most of the model described here is likely to be applicable.

 

Certificates are issued by CAs, so the top level differentiation is whether the CA that mis-issued a certificate did so maliciously or not. If not, then the next point of differentiation is whether the mis-issuance was the result of an error, an attack, or malicious behavior by a CA. In the case of an attack or malicious behavior by a CA, it is necessary to consider whether the certificate was logged. If the certificate was logged, it is necessary to consider whether the log(s) may have conspired with the attacker. Finally, one must consider the possibility that a third party Monitor might collude with an attacker (or a malicious CA). Here’s an taxonomy of attacks and assumptions about the attack environment:

1. CA

a. Non-malicious CA

                                                                        i.   Error

                                                                     ii.   Attack victim

1. Certificate logged

a. Benign log

                                                                          i.   Self-monitor

                                                                                                                        ii.   Benign 3rd party Monitor

                                                                                                                      iii.   Conspiring 3rd party Monitor

b. Conspiring log

2. Certificate not logged

b. Malicious CA

                                                               i.   Certificate logged

1. Benign log

a. Self-monitor

b. Benign 3rd party Monitor

c. Conspiring 3rd party Monitor

2. Conspiring log

                                        ii.   Certificate not logged

 

 

The following sections examine each of these cases, for both syntactic and semantic mis-issuance. As noted above, the focus here is on the Web PKI context, although most of the analysis is applicable to other PKI contexts.

 

 

XX.1 Non-malicious Web PKI CA context

 

If a pre-certificate is submitted to a log, prior to issuance of a certificate, syntactic mis-issuance can (optionally) be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted (pre-) certificate. (A pre-certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance.) If syntactic validation fails, this will be noted in the SCT returned to the CA. Because this case assumes a non-malicious CA, the CA will remedy the syntactic problem and re-submit the pre-certificate to a log. In this case syntactic checking by a log helps avoid issuance of a malformed certificate.

 

If a certificate is submitted by its Subject, we assume that the Subject will contact the issuer and request a new certificate if a log indicates that the certificate failed the applicable syntactic check. Here too syntactic checking by a log enables a Subject to be informed that its certificate is malformed and thus may hasten issuance of a replacement certificate.

 

If the certificate was submitted by a third party, that party might contact the Subject or the issuer, but because the party is not the Subject of the certificate it is not clear how the issuer will respond.

 

Bottom line: Syntactic mis-issuance of a certificate can be avoided by a CA if it makes use of logs that are capable of performing these checks for the types of certificates that are submitted, and if the CA acts on the feedback it receives. If a CA uses a log that does not perform such checks, or if the CA requests checking relative to criteria not supported by the log, then syntactic mis-issuance will not be detected or avoided by this mechanism. Syntactic mis-issuance can be remedied if a Subject submits a certificate to a log that performs syntactic checks, and if the Subject requests the issuer to fix problems detected by the log. (The issuer is presumed to be willing to re-issue the certificate, correcting any problems, because the CA is not malicious.)

 

XX.1.1 A CA may issue the certificate to an unauthorized party (semantic mis-issuance), as a result of an error or because it was the victim of a social engineering attack. We will refer to such a certificate as “bogus”. In this case the CA has a record of the bogus certificate and it is prepared to revoke the bogus certificate once it has confirmed its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is “protecting” the affected Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should be able to revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate is irrelevant to the mitigation procedure in this case. (See Note 1 below.) Because the mis-issuance was not malicious, there is no notion of a log operator or a Monitor conspiring with the CA.

 

XX.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a certificate. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content.

 

XX.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and can alert the Subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will make use of the log entry (supplied by the Subject) to determine the serial number of the mis-issued certificate, and revoke it (after investigation). (See Notes 1 + 2.) Since there is no requirement for a TLS client to reject a certificate when no SCT is provided, the preferred strategy for an attacker is to not log bogus certificates. (See XX.1.2.2 and Note 3.)

 

XX.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. Since TLS clients are not required to reject a certificate that lacks (or is not accompanied by) an SCT, or even to notify a user in such situations, the attacker will not be thwarted in this case. (See Note 3.)

 

XX.1.2.3 The bogus certificate may have been submitted to logs that are conspiring with the attacker. In this case, Monitors will not detect the bogus certificate because the logs will suppress a bogus certificate log entry. TLS clients will not reject a bogus certificate in this case, because it is accompanied by an SCT. In this scenario, unless Monitors “gossip” to detect conspiring logs, the bogus certificate will not be detected. Because there are no requirements for such gossiping, an attack of this sort can succeed based on the current CT design.

 

XX.1.2.4 If a semantically bogus certificate is submitted to non-conspiring logs, a Subject performing self-monitoring will be able to detect the bogus certificate and request revocation. If a Subject relies on a third-party Monitor, and that Monitor conspires with the attacker, the Subject will not be alerted and thus will not request revocation.

 

 

XX.2 Malicious Web PKI CA context

 

XX.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, syntactic mis-issuance can be detected, and noted. This will happen only if the log performs syntactic checks in general, and if the log is capable of performing the checks applicable to the submitted certificate. A (pre-) certificate will be logged even if it fails syntactic validation, thus logging takes precedence over detection of syntactic mis-issuance.

 

Because the CA is presumed to be malicious, the CA may cause the log to not perform checks, in one of several ways.

1.           The CA may assert that the certificate is being issued w/o regard to any guidelines (the “no guidelines” reserved CCID).

2.           The CA may assert a CCID that has not been registered, and thus no log will be able to perform a check.

3.           the CA may check to see which CCIDs a log declares it can check, and chose a registered CCID that is not checked by the log in question. In this fashion the CA can prevent the log from performing checks, and the SCT and log entry will not contain an indication of a failed check.

4.           The CA may submit a (pre-) certificate to a log that is known to not perform any syntactic checks, and thus avoid syntactic checking.

 

Since there is no requirement that a TLS client can be configured to reject a certificate that has not been syntactically checked (as indicated by the SCT), a malicious CA need not worry about failing a log-based check. Similarly,

since there is no requirement for a TLS client to reject a certificate that was logged by an operator that does not perform syntactic checks, the fourth approach noted above will succeed as well. If a client were configured to know which versions of certificate types are applicable to its use of a certificate, the second and third strategies noted above could be thwarted.

 

XX.2.2 Because the CA is presumed malicious, it may choose to not submit a certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. Since there is no requirement for a TLS client to reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will succeed. (See Note 3.)

 

XX.2.3 A malicious CA may submit a certificate to one or more logs that collude with this CA to not perform syntactic checks, even though they claim to do so. In this case syntactic mis-issuance will not be detected by logs.  The log entry and the SCT for a syntactically invalid certificate will assert that the certificate syntax was verified. Unless Monitors also perform syntactic checks, this form of mis-issuance will not be thwarted. TLS clients will believe that the certificate has been syntactically verified.

 

XX.2.4 A malicious CA may semantically mis-issue a certificate that is syntactically valid. Because it is syntactically valid, logs will not mark the bogus certificate as failing a syntax check. The semantically bogus certificate may have been issued because the CA was bribed or was compelled to issue the certificate. (A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.)  This CA might be one or more tiers below a trust anchor (aka root CA).

 

XX.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. Since there is no requirement for a TLS client to reject a certificate that lacks (or is not accompanied by) an SCT, there is no motivation for an attacker to submit the certificate in this case. (See Note 3.)

 

XX.2.4.2 A bogus pre-certificate may have been submitted to one or more logs, to acquire an embedded SCT, a certificate may have been submitted post-issuance (to acquire a standalone SCT). In either case, a (non-conspiring) Monitor protecting the targeted Subject will detect a bogus certificate and alert that Subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc. In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4.)

 

XX.2.4.3 If a third-party Monitor conspires with the malicious CA, then it will not notify the targeted Subject when a bogus certificate is logged. If a Subject performs self-monitoring this sort of attack will be avoided.

 

XX.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor (even a self-Monitor) from which the log is hiding data will not detect the bogus certificate, even if it is trying to protect the targeted Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the bogus certificate.

 

The audit function is intended to detect logs that conspire to suppress log entries, based on consistency checking of logs and use of a “gossip” protocol. It is assumed that Monitors will perform the audit functions described in Section <insert #>.

A Monitor performing an audit function could alert its clients if the Monitor detects evidence of malfeasant log operation. This would cause Monitors to avoid using such a log, and clients would reject SCTs generated by such a log. Because there is no defined gossip protocol, CT does not provide the necessary info to detect this form of mis-issuance. (See Note 5 below.)

 

Notes:

 

1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide “sufficient” coverage? If a Subject acts as its own Monitor, this problem is solved for that Subject. It also is not clear how a Monitor becomes aware of all (relevant?) logs, including newly created logs. The means by which Monitors become aware of new logs MUST accommodate self-monitoring by a potentially very large number of web site operators.

 

2. A CA being presented with evidence of a bogus certificate, in the form of a log entry, will need to examine its records to determine if it has knowledge of the certificate in question. It also will likely require the targeted Subject to provide assurances that it is the authorized entity representing the Subject name (subjectAltname) in question. Thus a Subject should not expect immediate revocation of a contested certificate. The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA. Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on applicable criteria. The SCT and log entry, because each contains a timestamp from a third party, is probably valuable for forensic purposes (assuming a non-conspiring log operator).

 

3. If a TLS client were to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules. Until a mechanism is defined that accommodates incremental deployment of this capability, attackers probably will avoid submitting bogus certificates to (non-conspiring) logs as a means of evading detection.

 

4. A targeted Subject might request the parent of a malicious CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If this specification were to require that a browser can be configured to reject a specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. This mitigation strategy calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication has not been specified, i.e., there are no standard ways to configure a browser to reject individual bogus certificates based on info provided by an external entity such as a Monitor. Moreover, the same or another malicious CA could issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks.

 

5. The combination of a malicious CA and one or more conspiring logs motivates the definition of an audit function, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or more SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if Monitors and clients reject certificates that contains SCTs from conspiring logs (based on info from an audit) will CT be able to deter use of such logs. Thus the means by which a Monitor performing an audit function detect such logs, and inform TLS clients must be specified for this to be effective. Moreover, if a certificate (or TLS handshake) contains more than one SCT, unless the client verifies all of them if it is to counter the threat posed by conspiring logs.

 

Absent a “gossip” protocol that enables Monitors to verify that data from logs are reported in a consistent fashion, CT does not provide protection against logs that may conspire with, or are victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log? Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance.

 

Monitors play a critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. A monitor (including a Subject performing self-monitoring) examines logs for certificates associated with one or more Subjects. It must obtain a list valid certificates for the Subject being monitored, in a secure manner. 

Note:  A Monitor must not rely on a CA or RA database for this information or use certificate discovery protocols; this information must be acquired by the Monitor based on reference certificates provided by a Subject. If a Monitor were to rely on a CA or RA database (for the CA that issued a targeted certificate), the Monitor would not detect mis-issuance due to malfeasance on the part of that CA or the RA, or due to compromise of the CA or the RA.  If a CA or RA database is used, it does detect mis-issuance by an unauthorized CA.  A Monitor must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms might result in mis-issued certificates being added to the list.

 

As noted above, Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject, as noted above. It is RECOMMENDED that a Subject request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors. However, the burden of Monitor operation may be viewed as too great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise.

 

A final note: Now that certificate pinning has been approved as a standard (currently in the RFC Editor’s queue), it is appropriate to factor in its use by TLS clients. It would appear that pinning will dramatically reduce the set of TLS clients that are vulnerable to mis-issuance; a client that pins a certificate for a web site would reject a bogus certificate without use of any CT mechanisms. The security considerations section of 6962-bis needs to note this, since deployment of pinning appears to reduces the need for CT in the Web PKI context.


--------------060405040006060001050903-- From nobody Thu Jan 22 08:56:00 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34F71A1B03 for ; Thu, 22 Jan 2015 08:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGSWS6hNYZGY for ; Thu, 22 Jan 2015 08:55:57 -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 40AE21A1ADD for ; Thu, 22 Jan 2015 08:55:57 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:46454 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YEL2x-000F4d-SK for trans@ietf.org; Thu, 22 Jan 2015 11:55:56 -0500 Message-ID: <54C12B9B.6000905@bbn.com> Date: Thu, 22 Jan 2015 11:55:55 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------080206020808030406050508" Archived-At: Subject: [Trans] sorry about the formatting problem for the attack taxonomy outline X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:55:59 -0000 This is a multi-part message in MIME format. --------------080206020808030406050508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit looked good in my e-mail SW :-( this version, using decimal numbering for the outline should be easier to read even if the formatting is messed up ... Steve ----- 1.CA 1.1.Non-malicious CA 1.1.1.Error 1.1.2.Attack victim 1.1.2.1.Certificate logged 1.1.2.1.1.Benign log 1.1.2.1.1.1.Self-monitor 1.1.2.1.1.2.Benign 3^rd party Monitor 1.1.2.1.1.3.Conspiring 3^rd party Monitor 1.1.2.1.2.Conspiring log 1.1.2.2.Certificate not logged 1.2.Malicious CA 1.2.1.Certificate logged 1.2.1.1.Benign log 1.2.1.1.1.Self-monitor 1.2.1.1.2.Benign 3^rd party Monitor 1.2.1.1.3.Conspiring 3^rd party Monitor 1.2.1.2.Conspiring log 1.2.2.Certificate not logged --------------080206020808030406050508 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit looked good in my e-mail SW :-(

this version, using decimal numbering for the outline should be
easier to read even if the formatting is messed up ...


Steve

-----

1. CA

1.1.       Non-malicious CA

1.1.1.        Error

1.1.2.        Attack victim

1.1.2.1.         Certificate logged

1.1.2.1.1. Benign log

1.1.2.1.1.1.  Self-monitor

1.1.2.1.1.2.  Benign 3rd party Monitor

1.1.2.1.1.3.  Conspiring 3rd party Monitor

1.1.2.1.2. Conspiring log

1.1.2.2.         Certificate not logged

1.2.       Malicious CA

1.2.1.        Certificate logged

1.2.1.1.         Benign log

1.2.1.1.1. Self-monitor

1.2.1.1.2. Benign 3rd party Monitor

1.2.1.1.3. Conspiring 3rd party Monitor

1.2.1.2.         Conspiring log

1.2.2.        Certificate not logged


--------------080206020808030406050508-- From nobody Tue Jan 27 02:48:19 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33CA1A8765 for ; Tue, 27 Jan 2015 02:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2OJSVpHoMkm for ; Tue, 27 Jan 2015 02:48:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1B31A8748 for ; Tue, 27 Jan 2015 02:48:07 -0800 (PST) Received: from localhost ([::1]:41521 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YG3gf-0003gK-9a; Tue, 27 Jan 2015 02:48:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 27 Jan 2015 10:48:01 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/56 Message-ID: <064.ad3ccf5068565e4491a4337770641dc9@tools.ietf.org> X-Trac-Ticket-ID: 56 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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #56 (rfc6962-bis): "*" domain labels MUST NOT be redacted X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 10:48:15 -0000 #56: "*" domain labels MUST NOT be redacted I can't think of any legitimate reason to redact a "*" label. We should disallow redaction of "*" labels, so that a bad actor cannot attempt to hide their use of "*" labels in a disallowed context (e.g. EV certs). 6962-bis needs to state this as a CA requirement. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Jan 27 02:50:26 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADB81A878B for ; Tue, 27 Jan 2015 02:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xp_2oc3cL99 for ; Tue, 27 Jan 2015 02:50: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 A909E1A701E for ; Tue, 27 Jan 2015 02:50:19 -0800 (PST) Received: from localhost ([::1]:41595 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YG3ir-0000ts-VK; Tue, 27 Jan 2015 02:50:17 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 27 Jan 2015 10:50:17 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/57 Message-ID: <064.8a66ec6ed3c832bc37574a10f0cffd81@tools.ietf.org> X-Trac-Ticket-ID: 57 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: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #57 (client-behavior): Clients MUST NOT match the redaction label with a "*" label X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 10:50:23 -0000 #57: Clients MUST NOT match the redaction label with a "*" label This ticket is to track enforcement of ticket #56 in the client behavior doc. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Jan 27 02:51:55 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A011A701E for ; Tue, 27 Jan 2015 02:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF5dtvtdQeUO for ; Tue, 27 Jan 2015 02:51:49 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FD41A8748 for ; Tue, 27 Jan 2015 02:51:48 -0800 (PST) Received: (qmail 29488 invoked by uid 1004); 27 Jan 2015 10:51:46 -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, 27 Jan 2015 10:51:46 +0000 Received: (qmail 28266 invoked by uid 1000); 27 Jan 2015 10:51:46 -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, 27 Jan 2015 10:51:46 +0000 Message-ID: <54C76DC2.3080209@comodo.com> Date: Tue, 27 Jan 2015 10:51:46 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> In-Reply-To: <54BFF4C2.20905@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 27 Jan 2015 10:51:53 -0000 On 21/01/15 18:49, Stephen Kent wrote: > Rob, Hi Steve. >> That seems like a good idea. Did you have any particular DNS experts >> in mind? > > I'd ask Joel Jaeggli for suggestions. Thanks. I'll contact Joel. >>> if not, why state this as a requirement? >> >> I don't think the current text does state this as a requirement. > > Your message to me cited this as a reason for not using "*" in this > context. If the different semantics for PRIVATE/? are not a requirement, > that argument isn't applicable. Color me confused. IIUC, you're saying that since "*" and "PRIVATE/?" are intended to have different semantics, 6962-bis needs to specify the required semantics more explicitly than it currently does. Have I got that right? I think we could address this by adding text to 6962-bis to specify that CAs MUST NOT use "PRIVATE/?" in a Precertificate domain label if the corresponding domain label in the Certificate is "*". If we want TLS Clients to enforce this rule, I think the appropriate place for that will be the envisaged client behaviour document (rather than 6962-bis). I've just created these two tickets: http://trac.tools.ietf.org/wg/trans/trac/ticket/56 http://trac.tools.ietf.org/wg/trans/trac/ticket/57 >> If there are multiple certs (which may or may not contain different >> unredacted domain label(s)) that match one redacted precert, then >> those certs will all share the same Serial Number and be issued by the >> same CA. >> RFC5280 already disallows this, so 6962-bis doesn't also need to >> disallow it. :-) > > Can you cite the part of 5280 that you feel is applicable here? 4.1.2.2 > notes that a cert serial number uniquely identifies a cert, which doesn't > seem compatible with your comment. I don't see any incompatibility. Your question was... "Do you envision these clients remembering every cert that they encounter that matches a redacted pre-cert, and check to see if a CA has issue two certs with different values for a redacted DNS label?" Even issuing two certs with the same values for a redacted DNS label would be wrong. If a client is checking for RFC5280 4.1.2.2 serial number uniqueness, then they are implicitly checking for multiple certs that match a single Precertificate. A Precertificate contains Issuer Name and Serial Number. Every Certificate that matches that particular Precertificate will, by definition, contain the same Issuer Name and Serial Number. So, if there is >1 matching Certificate then RFC5280 Section 4.1.2.2 has been violated. >> Hmmm... >> Should we specify that the redaction label (i.e. "(PRIVATE)" or "?" or >> whatever the DNS experts prefer) MUST NOT match "*" in the cert? >> I can't think of a legitimate reason to hide wildcard certs from the log. > > I agree that wildcard certs should be logged. Great. I think the two new tickets I mentioned above are sufficient. > Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jan 27 03:54:12 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1A81A879B for ; Tue, 27 Jan 2015 03:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, J_CHICKENPOX_72=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaZMixfsfMss for ; Tue, 27 Jan 2015 03:54:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03431A8797 for ; Tue, 27 Jan 2015 03:54:06 -0800 (PST) Received: from localhost ([::1]:44924 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YG4ic-0004Xq-77; Tue, 27 Jan 2015 03:54:06 -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.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 27 Jan 2015 11:54:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/54#comment:3 Message-ID: <079.6c4647f7153511bb640df7c219035f38@tools.ietf.org> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 11:54:11 -0000 #54: Simplify name redaction Comment (by rob.stradling@comodo.com): Alternative "redactedLabels" extension proposal: Instead of the SEQUENCE OF INTEGERs extension in the current draft, I think we should define an extension that's more similar in syntax to the RFC5280 nameConstraints extension. Instead of "permittedSubtrees" and/or "excludedSubtrees", we'd be listing "redactedSubtrees". I think this approach would reduce the "risk of misalignment". Here's a rough example of how it could work... Precertificate: Subject:CN = ?.example.com SAN:dNSName = ?.example.com SAN:dNSName = ?.example.com SAN:dNSName = www.example.com SAN:dNSName = ?.top-secret.com SAN:dNSName = ?.top-secret.com SAN:dNSName = top-secret.com Certificate: Subject:CN = this-is-redacted-1.example.com SAN:dNSName = this-is-redacted-1.example.com SAN:dNSName = this-is-redacted-2.example.com SAN:dNSName = www.example.com SAN:dNSName = this-is-redacted-3.top-secret.com SAN:dNSName = this-is-redacted-4.top-secret.com SAN:dNSName = top-secret.com Extension:redactedSubtrees = this-is-redacted-1.example.com this-is-redacted-2.example.com top-secret.com -- -------------------------------------+------------------------------------- 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 Tue Jan 27 04:58:21 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE11A8743 for ; Tue, 27 Jan 2015 04:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW06WIqXcPuY for ; Tue, 27 Jan 2015 04:58:17 -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 EB1A91A1EF7 for ; Tue, 27 Jan 2015 04:58:16 -0800 (PST) Received: (qmail 28783 invoked by uid 1004); 27 Jan 2015 12:58:14 -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, 27 Jan 2015 12:58:14 +0000 Received: (qmail 7685 invoked by uid 1000); 27 Jan 2015 12:58:14 -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, 27 Jan 2015 12:58:14 +0000 Message-ID: <54C78B66.6040405@comodo.com> Date: Tue, 27 Jan 2015 12:58:14 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> In-Reply-To: <54C76DC2.3080209@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 27 Jan 2015 12:58:20 -0000 On 27/01/15 10:51, Rob Stradling wrote: > On 21/01/15 18:49, Stephen Kent wrote: >> Rob, > > Hi Steve. > >>> That seems like a good idea. Did you have any particular DNS experts >>> in mind? >> >> I'd ask Joel Jaeggli for suggestions. > > Thanks. I'll contact Joel. Actually, before I do that... We've already thought of two possible ways to express redacted label(s) in a Precertificate: 1. "(PRIVATE)." matching >=1 redacted labels. 2. "?." matching =1 redacted label. But it occurs to me that there's a third option: 3. "" matching >=0 redacted labels. Option 3 would hide the fact that redaction is even occurring. We wouldn't need to use "(PRIVATE)" or "?" or seek any alternative redaction label proposals from the DNS experts. :-) Would folks be happy with option 3? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jan 27 05:48:00 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60821A8739; Tue, 27 Jan 2015 05:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5sVWPH5ZnuD; Tue, 27 Jan 2015 05:47:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB381A026F; Tue, 27 Jan 2015 05:47:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127134749.12082.64332.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 05:47:49 -0800 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-05.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 13:47:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-05.txt Pages : 31 Date : 2015-01-27 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 certificate 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: http://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-05 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 Wed Jan 28 14:56:12 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ABB1A1B7A for ; Wed, 28 Jan 2015 14:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdY06I-WPWOz for ; Wed, 28 Jan 2015 14:56:08 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DD8501A1A4D for ; Wed, 28 Jan 2015 14:56:07 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 54B30F984; Wed, 28 Jan 2015 17:56:05 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A68EA203A0; Wed, 28 Jan 2015 17:56:03 -0500 (EST) From: Daniel Kahn Gillmor To: Rob Stradling , trans@ietf.org In-Reply-To: <54C78B66.6040405@comodo.com> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 28 Jan 2015 17:56:03 -0500 Message-ID: <87iofqecqk.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 28 Jan 2015 22:56:10 -0000 On Tue 2015-01-27 07:58:14 -0500, Rob Stradling wrote: > On 27/01/15 10:51, Rob Stradling wrote: >> On 21/01/15 18:49, Stephen Kent wrote: >>> Rob, >> >> Hi Steve. >> >>>> That seems like a good idea. Did you have any particular DNS experts >>>> in mind? >>> >>> I'd ask Joel Jaeggli for suggestions. >> >> Thanks. I'll contact Joel. > > Actually, before I do that... > > We've already thought of two possible ways to express redacted label(s) > in a Precertificate: > 1. "(PRIVATE)." matching >=1 redacted labels. > 2. "?." matching =1 redacted label. > > But it occurs to me that there's a third option: > 3. "" matching >=0 redacted labels. > > Option 3 would hide the fact that redaction is even occurring. We > wouldn't need to use "(PRIVATE)" or "?" or seek any alternative > redaction label proposals from the DNS experts. :-) > > Would folks be happy with option 3? The proposal is that "foo.example.com" could be registered with the CA as "example.com" -- this seems problematic for operators of a sub-zone who expect their parent zone to be fully-enumerated. let's say the operator of example claims to be fully-publicly logged, and lets me register dkg.example.net. i want to know that the .example.net operators won't be able to masquerade as dkg.example.net without issuing a certificate that i can find in the public logs, tied to my name. If under proposal (2), i need to scan the logs for anything that ends in dkg.example.net, or ?.example.net that i didn't request. if something like that shows up, then i know something is fishy. But the .example.net operators may have a legitimate reason for wanting to issue a certificate for "example.net" -- now they have a way of impersonating me that CT doesn't help me to detect. I think option 3 defeats one of the main aims of CT. --dkg From nobody Wed Jan 28 15:20:07 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8F1A6F0B for ; Wed, 28 Jan 2015 15:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 175gYxYYwJVb for ; Wed, 28 Jan 2015 15:20:01 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1301A6EE8 for ; Wed, 28 Jan 2015 15:20:01 -0800 (PST) Received: (qmail 28330 invoked by uid 1004); 28 Jan 2015 23:19:58 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 28 Jan 2015 23:19:58 +0000 Received: (qmail 1722 invoked by uid 1000); 28 Jan 2015 23:19:58 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 28 Jan 2015 23:19:58 +0000 Message-ID: <54C96E9E.1010102@comodo.com> Date: Wed, 28 Jan 2015 23:19:58 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> In-Reply-To: <87iofqecqk.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 28 Jan 2015 23:20:05 -0000 Thanks for explaining that, DKG. Makes sense. Is there ever such a thing as a "sub-sub-zone" whose operators expect their parent and grandparent zones to be fully-enumerated? If so, that would suggest that option 1 is also insufficient, in which case we'd need to do option 2. Or if not, is there any reason to prefer option 1 over option 2, or vice versa? On 28/01/15 22:56, Daniel Kahn Gillmor wrote: > On Tue 2015-01-27 07:58:14 -0500, Rob Stradling wrote: >> On 27/01/15 10:51, Rob Stradling wrote: >>> On 21/01/15 18:49, Stephen Kent wrote: >>>> Rob, >>> >>> Hi Steve. >>> >>>>> That seems like a good idea. Did you have any particular DNS experts >>>>> in mind? >>>> >>>> I'd ask Joel Jaeggli for suggestions. >>> >>> Thanks. I'll contact Joel. >> >> Actually, before I do that... >> >> We've already thought of two possible ways to express redacted label(s) >> in a Precertificate: >> 1. "(PRIVATE)." matching >=1 redacted labels. >> 2. "?." matching =1 redacted label. >> >> But it occurs to me that there's a third option: >> 3. "" matching >=0 redacted labels. >> >> Option 3 would hide the fact that redaction is even occurring. We >> wouldn't need to use "(PRIVATE)" or "?" or seek any alternative >> redaction label proposals from the DNS experts. :-) >> >> Would folks be happy with option 3? > > The proposal is that "foo.example.com" could be registered with the CA > as "example.com" -- this seems problematic for operators of a sub-zone > who expect their parent zone to be fully-enumerated. > > let's say the operator of example claims to be fully-publicly logged, > and lets me register dkg.example.net. i want to know that the .example.net > operators won't be able to masquerade as dkg.example.net without issuing a > certificate that i can find in the public logs, tied to my name. > > If under proposal (2), i need to scan the logs for anything that ends in > dkg.example.net, or ?.example.net that i didn't request. if something like that > shows up, then i know something is fishy. > > But the .example.net operators may have a legitimate reason for wanting to > issue a certificate for "example.net" -- now they have a way of > impersonating me that CT doesn't help me to detect. > > I think option 3 defeats one of the main aims of CT. > > --dkg > > _______________________________________________ > 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 Jan 28 15:50:50 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA101A87BB for ; Wed, 28 Jan 2015 15:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kklunDyq4YCA for ; Wed, 28 Jan 2015 15:50:47 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837751A87AB for ; Wed, 28 Jan 2015 15:50:47 -0800 (PST) From: Jeremy Rowley To: Rob Stradling , Daniel Kahn Gillmor , "trans@ietf.org" Thread-Topic: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thread-Index: AQHQGhfAvkg+AumBDUi8y+0yiCcXtpyUjGwAgAkm9wCAFI/UhYAOahUAgAAevwCACsshAIAI6HoAgAAjVQCAAjlcgIAABq8A//+SfVA= Date: Wed, 28 Jan 2015 23:50:43 +0000 Message-ID: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> In-Reply-To: <54C96E9E.1010102@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: [67.137.52.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 28 Jan 2015 23:50:49 -0000 I'd prefer option 2 for simplicity and because I think the CT log should re= flect the number of levels redacted. Do you gain much advantage if topsecre= t.secret.example.com is redacted as (PRIVATE).example.com v. ?.?.example.co= m. I think the second is more straight forward and gives more insight on w= hat certs are out there. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling Sent: Wednesday, January 28, 2015 4:20 PM To: Daniel Kahn Gillmor; trans@ietf.org Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thanks for explaining that, DKG. Makes sense. Is there ever such a thing as a "sub-sub-zone" whose operators expect their= parent and grandparent zones to be fully-enumerated? If so, that would suggest that option 1 is also insufficient, in which case= we'd need to do option 2. Or if not, is there any reason to prefer option 1 over option 2, or vice ve= rsa? On 28/01/15 22:56, Daniel Kahn Gillmor wrote: > On Tue 2015-01-27 07:58:14 -0500, Rob Stradling wrote: >> On 27/01/15 10:51, Rob Stradling wrote: >>> On 21/01/15 18:49, Stephen Kent wrote: >>>> Rob, >>> >>> Hi Steve. >>> >>>>> That seems like a good idea. Did you have any particular DNS=20 >>>>> experts in mind? >>>> >>>> I'd ask Joel Jaeggli for suggestions. >>> >>> Thanks. I'll contact Joel. >> >> Actually, before I do that... >> >> We've already thought of two possible ways to express redacted=20 >> label(s) in a Precertificate: >> 1. "(PRIVATE)." matching >=3D1 redacted labels. >> 2. "?." matching =3D1 redacted label. >> >> But it occurs to me that there's a third option: >> 3. "" matching >=3D0 redacted labels. >> >> Option 3 would hide the fact that redaction is even occurring. We=20 >> wouldn't need to use "(PRIVATE)" or "?" or seek any alternative=20 >> redaction label proposals from the DNS experts. :-) >> >> Would folks be happy with option 3? > > The proposal is that "foo.example.com" could be registered with the CA=20 > as "example.com" -- this seems problematic for operators of a sub-zone=20 > who expect their parent zone to be fully-enumerated. > > let's say the operator of example claims to be fully-publicly logged,=20 > and lets me register dkg.example.net. i want to know that the=20 > .example.net operators won't be able to masquerade as dkg.example.net=20 > without issuing a certificate that i can find in the public logs, tied to= my name. > > If under proposal (2), i need to scan the logs for anything that ends=20 > in dkg.example.net, or ?.example.net that i didn't request. if=20 > something like that shows up, then i know something is fishy. > > But the .example.net operators may have a legitimate reason for=20 > wanting to issue a certificate for "example.net" -- now they have a=20 > way of impersonating me that CT doesn't help me to detect. > > I think option 3 defeats one of the main aims of CT. > > --dkg > > _______________________________________________ > 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 repl= ying to the e-mail containing this attachment. Replies to this email may be= monitored by COMODO for operational or business reasons. Whilst every ende= avour is taken to ensure that e-mails are free from viruses, no liability c= an be accepted and the recipient is requested to use their own virus checki= ng software. _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Thu Jan 29 13:41:36 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ED31A87E1 for ; Thu, 29 Jan 2015 13:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOkR4yyPrQtc for ; Thu, 29 Jan 2015 13:41:29 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0164F1A87DB for ; Thu, 29 Jan 2015 13:41:28 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E7153F984; Thu, 29 Jan 2015 16:41:26 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9D021203A0; Thu, 29 Jan 2015 16:41:25 -0500 (EST) From: Daniel Kahn Gillmor To: Rob Stradling , trans@ietf.org In-Reply-To: <54C96E9E.1010102@comodo.com> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 29 Jan 2015 16:41:25 -0500 Message-ID: <87a911cliy.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 21:41:32 -0000 On Wed 2015-01-28 18:19:58 -0500, Rob Stradling wrote: > Thanks for explaining that, DKG. Makes sense. > > Is there ever such a thing as a "sub-sub-zone" whose operators expect > their parent and grandparent zones to be fully-enumerated? Sure. Consider any ISP that hands out sub-zones to any customer who wants them. Say i run Example WebHosting, and i control example.net, which i use to hand out foo.example.net domains to those customers who don't have their own names and don't want to register them. i (and my customers) would certainly want .net to be fully-enumerated (and we all want the root zone to be fully-enumerated). And my customers would want example.net to be fully-enumerated, because they don't want me being able to impersonate them. > If so, that would suggest that option 1 is also insufficient, in which > case we'd need to do option 2. I'm not sure that this proves that option 1 is actually insufficient -- your real question is whether it's possible to have a non-enumerated zone sandwiched between two fully-enumerated zones. for example, consider a hypothetical example.com, which specializes in non-enumerability (hiding the public names of its child zones for those that trust it) -- its parent (the root zone) should be fully-enumerable, but it itself chooses to hide its list of immediate children. It could still delegate the foo.example.com zone to someone else, with the proviso that it could impersonate foo.example.com, but not x.foo.example.com. then the customers/zone-children of example.com would have the option of either: a) hiding in the anonymized/non-enumerable space, while risking undetectable compromise by their parent zone, or b) avoiding use of the apex of their zone, and exposing their delegation as (e.g.) whatever.foo.example.com, while being able to monitor for misuse by their parent. if ?.?.example.com ever shows up in the logs, then customers in group (b) know that they might have a problem. if we go with option 1, then customers in group (b) have no recourse. > Or if not, is there any reason to prefer option 1 over option 2, or vice > versa? I think you're right, we should go for option 2 (also, it's the simplest and easiest to explain, i think). --dkg From nobody Fri Jan 30 08:09:26 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9C01A90E7 for ; Fri, 30 Jan 2015 08:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHr9xk-l6Wdj for ; Fri, 30 Jan 2015 08:09:14 -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 10D251A90EB for ; Fri, 30 Jan 2015 08:09:12 -0800 (PST) Received: (qmail 15725 invoked by uid 1004); 30 Jan 2015 16:09: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; Fri, 30 Jan 2015 16:09:11 +0000 Received: (qmail 10849 invoked by uid 1000); 30 Jan 2015 16:09: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; Fri, 30 Jan 2015 16:09:10 +0000 Message-ID: <54CBACA6.3010509@comodo.com> Date: Fri, 30 Jan 2015 16:09:10 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , trans@ietf.org, Jeremy Rowley References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> In-Reply-To: <87a911cliy.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 16:09:20 -0000 On 29/01/15 21:41, Daniel Kahn Gillmor wrote: > On Wed 2015-01-28 18:19:58 -0500, Rob Stradling wrote: >> Or if not, is there any reason to prefer option 1 over option 2, or vice >> versa? > > I think you're right, we should go for option 2 (also, it's the > simplest and easiest to explain, i think). On 28/01/15 23:50, Jeremy Rowley wrote: > I'd prefer option 2 for simplicity and because I think the CT log > should reflect the number of levels redacted. Do you gain much > advantage if topsecret.secret.example.com is redacted as > (PRIVATE).example.com v. ?.?.example.com. I think the second is more > straight forward and gives more insight on what certs are out there. OK, let's discard option 1 and option 3. Before we settle on option 2, here's an option 4 to consider... 4. "?" matching =1 character in a redacted label. Examples: "dkg.example.net" would be redacted as "???.example.net". "???.example.net" cannot match "jeremy.example.net", because the label lengths are different (i.e. 3 != 6). However, "???.example.net" might match "rob.example.net". "topsecret.secret.example.com" would be redacted as "?????????.??????.example.com". I don't think there's anything to gain from redacting the length of a label, so I prefer option 4. Any thoughts? AFAICT, matching =1 character seem marginally more consistent with other uses of "?" as a wildcard character: http://en.wikipedia.org/wiki/Wildcard_character "In Unix-like and DOS operating systems, the question mark ("?") matches exactly one character;" "In Microsoft Access, wildcard characters can be used in "LIKE" expressions; the asterisk sign (*) matches zero or more characters, and the question mark (?) matches a single character." -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jan 30 08:23:16 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702751A6EDC for ; Fri, 30 Jan 2015 08:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7AtYgbFOcxE for ; Fri, 30 Jan 2015 08:23:12 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA221A1AF4 for ; Fri, 30 Jan 2015 08:22:54 -0800 (PST) From: Jeremy Rowley To: Rob Stradling , Daniel Kahn Gillmor , "trans@ietf.org" Thread-Topic: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thread-Index: AQHQPAxUvkg+AumBDUi8y+0yiCcXtpzZS2kA//+LSwA= Date: Fri, 30 Jan 2015 16:22:52 +0000 Message-ID: <773f2c4b972045cca2c0074bfae2cc1f@EX2.corp.digicert.com> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> In-Reply-To: <54CBACA6.3010509@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: [67.166.110.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 16:23:14 -0000 SSBhZ3JlZSB0aGF0IHRoZXJlIGlzbid0IG11Y2ggdG8gZ2FpbiB3aXRoIG1hdGNoaW5nICI/IiB0 byBlYWNoIGNoYXJhY3Rlci4gIChXb3VsZCB5b3UgZXZlciB3YW50IHRvIGRvICJ0P3BzZWNyZXQu ZXhtYXBsZS5jb20iPykNCg0KT3B0aW9uIDQgaXMgcHJlZmVyYWJsZSBzaW5jZSBpdCBpbmRpY2F0 ZXMgYSBsYWJlbCBleGlzdHMuIA0KDQpQbHVzLCB0aGUgZG9jdW1lbnQgcmVmZXJlbmNlZCAodGhl IEZlZGVyYWwgR2xvc3Nhcnkgb2YgVGVsZWNvbW11bmljYXRpb24gVGVybXMpIGluZGljYXRlcyB5 b3UgY2FuIHVzZSAiPyIgdG8gcmVmZXJlbmNlIGFuIGVudGlyZSBzdHJpbmcgYXMgbG9uZyBhcyB0 aGF0IGlzIHNwZWNpZmllZC4gIEFzIGxvbmcgYXMgdGhlIG1lYW5pbmcgb2YgdGhlICI/IiBjaGFy YWN0ZXIgaXMgY2xlYXIgaW4gdGhlIFJGQywgSSBkb24ndCB0aGluayB3ZSdyZSBicmVha2luZyBl c3RhYmxpc2hlZCBjb252ZW50aW9ucy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFJvYiBTdHJhZGxpbmcgW21haWx0bzpyb2Iuc3RyYWRsaW5nQGNvbW9kby5jb21dIA0KU2Vu dDogRnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1IDk6MDkgQU0NClRvOiBEYW5pZWwgS2FobiBHaWxs bW9yOyB0cmFuc0BpZXRmLm9yZzsgSmVyZW15IFJvd2xleQ0KU3ViamVjdDogUmU6IFtUcmFuc10g W3RyYW5zXSAjNTQgKHJmYzY5NjItYmlzKTogU2ltcGxpZnkgbmFtZSByZWRhY3Rpb24NCg0KT24g MjkvMDEvMTUgMjE6NDEsIERhbmllbCBLYWhuIEdpbGxtb3Igd3JvdGU6DQo+IE9uIFdlZCAyMDE1 LTAxLTI4IDE4OjE5OjU4IC0wNTAwLCBSb2IgU3RyYWRsaW5nIHdyb3RlOg0KPFVzZWZ1bCBleHBs YW5hdGlvbiBzbmlwcGVkIC0gdGhhbmtzIERLRz4NCj4+IE9yIGlmIG5vdCwgaXMgdGhlcmUgYW55 IHJlYXNvbiB0byBwcmVmZXIgb3B0aW9uIDEgb3ZlciBvcHRpb24gMiwgb3IgDQo+PiB2aWNlIHZl cnNhPw0KPg0KPiBJIHRoaW5rIHlvdSdyZSByaWdodCwgd2Ugc2hvdWxkIGdvIGZvciBvcHRpb24g MiAoYWxzbywgaXQncyB0aGUgDQo+IHNpbXBsZXN0IGFuZCBlYXNpZXN0IHRvIGV4cGxhaW4sIGkg dGhpbmspLg0KDQpPbiAyOC8wMS8xNSAyMzo1MCwgSmVyZW15IFJvd2xleSB3cm90ZToNCj4gSSdk IHByZWZlciBvcHRpb24gMiBmb3Igc2ltcGxpY2l0eSBhbmQgYmVjYXVzZSBJIHRoaW5rIHRoZSBD VCBsb2cgDQo+IHNob3VsZCByZWZsZWN0IHRoZSBudW1iZXIgb2YgbGV2ZWxzIHJlZGFjdGVkLiBE byB5b3UgZ2FpbiBtdWNoIA0KPiBhZHZhbnRhZ2UgaWYgdG9wc2VjcmV0LnNlY3JldC5leGFtcGxl LmNvbSBpcyByZWRhY3RlZCBhcyANCj4gKFBSSVZBVEUpLmV4YW1wbGUuY29tIHYuID8uPy5leGFt cGxlLmNvbS4gIEkgdGhpbmsgdGhlIHNlY29uZCBpcyBtb3JlIA0KPiBzdHJhaWdodCBmb3J3YXJk IGFuZCBnaXZlcyBtb3JlIGluc2lnaHQgb24gd2hhdCBjZXJ0cyBhcmUgb3V0IHRoZXJlLg0KDQpP SywgbGV0J3MgZGlzY2FyZCBvcHRpb24gMSBhbmQgb3B0aW9uIDMuICBCZWZvcmUgd2Ugc2V0dGxl IG9uIG9wdGlvbiAyLCBoZXJlJ3MgYW4gb3B0aW9uIDQgdG8gY29uc2lkZXIuLi4NCg0KNC4gIj8i IG1hdGNoaW5nID0xIGNoYXJhY3RlciBpbiBhIHJlZGFjdGVkIGxhYmVsLg0KDQpFeGFtcGxlczoN CiJka2cuZXhhbXBsZS5uZXQiIHdvdWxkIGJlIHJlZGFjdGVkIGFzICI/Pz8uZXhhbXBsZS5uZXQi Lg0KIj8/Py5leGFtcGxlLm5ldCIgY2Fubm90IG1hdGNoICJqZXJlbXkuZXhhbXBsZS5uZXQiLCBi ZWNhdXNlIHRoZSBsYWJlbCBsZW5ndGhzIGFyZSBkaWZmZXJlbnQgKGkuZS4gMyAhPSA2KS4NCkhv d2V2ZXIsICI/Pz8uZXhhbXBsZS5uZXQiIG1pZ2h0IG1hdGNoICJyb2IuZXhhbXBsZS5uZXQiLg0K DQoidG9wc2VjcmV0LnNlY3JldC5leGFtcGxlLmNvbSIgd291bGQgYmUgcmVkYWN0ZWQgYXMgIj8/ Pz8/Pz8/Py4/Pz8/Pz8uZXhhbXBsZS5jb20iLg0KDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUncyBh bnl0aGluZyB0byBnYWluIGZyb20gcmVkYWN0aW5nIHRoZSBsZW5ndGggb2YgYSANCmxhYmVsLCBz byBJIHByZWZlciBvcHRpb24gNC4gIEFueSB0aG91Z2h0cz8NCg0KDQpBRkFJQ1QsIG1hdGNoaW5n ID0xIGNoYXJhY3RlciBzZWVtIG1hcmdpbmFsbHkgbW9yZSBjb25zaXN0ZW50IHdpdGggb3RoZXIg DQp1c2VzIG9mICI/IiBhcyBhIHdpbGRjYXJkIGNoYXJhY3RlcjoNCmh0dHA6Ly9lbi53aWtpcGVk aWEub3JnL3dpa2kvV2lsZGNhcmRfY2hhcmFjdGVyDQoiSW4gVW5peC1saWtlIGFuZCBET1Mgb3Bl cmF0aW5nIHN5c3RlbXMsIHRoZSBxdWVzdGlvbiBtYXJrICgiPyIpIG1hdGNoZXMgDQpleGFjdGx5 IG9uZSBjaGFyYWN0ZXI7Ig0KIkluIE1pY3Jvc29mdCBBY2Nlc3MsIHdpbGRjYXJkIGNoYXJhY3Rl cnMgY2FuIGJlIHVzZWQgaW4gIkxJS0UiIA0KZXhwcmVzc2lvbnM7IHRoZSBhc3RlcmlzayBzaWdu ICgqKSBtYXRjaGVzIHplcm8gb3IgbW9yZSBjaGFyYWN0ZXJzLCBhbmQgDQp0aGUgcXVlc3Rpb24g bWFyayAoPykgbWF0Y2hlcyBhIHNpbmdsZSBjaGFyYWN0ZXIuIg0KDQotLSANClJvYiBTdHJhZGxp bmcNClNlbmlvciBSZXNlYXJjaCAmIERldmVsb3BtZW50IFNjaWVudGlzdA0KQ09NT0RPIC0gQ3Jl YXRpbmcgVHJ1c3QgT25saW5lDQoNCg== From nobody Fri Jan 30 08:32:31 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8EE1A6F07 for ; Fri, 30 Jan 2015 08:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY2XXtGkEC4H for ; Fri, 30 Jan 2015 08:32:26 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA64C1A6EF0 for ; Fri, 30 Jan 2015 08:32:25 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D196CF984 for ; Fri, 30 Jan 2015 11:32:23 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 04DDB201F8; Fri, 30 Jan 2015 11:32:22 -0500 (EST) From: Daniel Kahn Gillmor To: trans@ietf.org In-Reply-To: <54CBACA6.3010509@comodo.com> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 30 Jan 2015 11:32:19 -0500 Message-ID: <87egqcrzzg.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 16:32:30 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2015-01-30 11:09:10 -0500, Rob Stradling wrote: > OK, let's discard option 1 and option 3. Before we settle on option 2,=20 > here's an option 4 to consider... > > 4. "?" matching =3D1 character in a redacted label. > > Examples: > "dkg.example.net" would be redacted as "???.example.net". > "???.example.net" cannot match "jeremy.example.net", because the label=20 > lengths are different (i.e. 3 !=3D 6). > However, "???.example.net" might match "rob.example.net". > > "topsecret.secret.example.com" would be redacted as=20 > "?????????.??????.example.com". > > > I don't think there's anything to gain from redacting the length of a=20 > label, so I prefer option 4. Any thoughts? Say i've got a dozen machines in my domain, all using an obscure naming scheme that you won't be able to guess. with option 2, i request and log a single cert for all of them, but someone monitoring the log can't tell whether i've got a dozen services or a single service with 11 backup certs. My naming scheme might scatter the lengths of the names between 6 and 15 characters, perhaps into 8 different lengths for the 12 services (there is some random overlap, and some lengths happen to not get hit). With option 4, you now know that i have at least 8 different services certified. furthermore, you know how many characters exactly to search in. Why would i want to leak this information if i'm interested in avoiding enumeration? I also think option 4 is currently ambiguous because of IDN: Is the '?' one character in IDN? or one byte in UTF-8 representation of the IDN? or one character in punycode? We can clarify it, but it seems likely to encourage a little bit of implementation confusion at least (IDN is confusing enough). The native unit of DNS is the label. It's simplest to use one redaction symbol for one label. > AFAICT, matching =3D1 character seem marginally more consistent with othe= r=20 > uses of "?" as a wildcard character: > http://en.wikipedia.org/wiki/Wildcard_character > "In Unix-like and DOS operating systems, the question mark ("?") matches= =20 > exactly one character;" > "In Microsoft Access, wildcard characters can be used in "LIKE"=20 > expressions; the asterisk sign (*) matches zero or more characters, and=20 > the question mark (?) matches a single character." If we follow this reasoning, then the better response is to choose a different redaction mark, not to make the redaction mark be per-character. if we don't like ?, and we don't want to use * because of the overlap with current wildcard practice, then we should choose something else outside the range of the acceptable characters for DNS. We could use '%' (thanks, SQL!) or '~' or '!' or '#' or '^' or '|' if we're looking for single-character replacements. I'm personally fine with '?' to mean "matches a single redacted label", though. I'd recommend against '_' because even though it is not a valid character for a hostname, it is a valid DNS label that is used for things like SRV records (e.g. _foo._tcp.example.net), and SRVName SubjectAltName entries could include an '_'. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUy7IUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcUWcP+wa92i9VZ9sVIQissPW34w5N Zd7MC66LKc2ZvS77ToikMU3SRg6wqRl+5g7lpLDybhPC02iAZ21lySa6SD6hMtbG lGFMHU0m3DLjOzq+60CvzxjGBbOxLtsgNgSdtuM7L+jkP0H9zd8Z1h40t4luXWIp STvx6Vdc64U9jCoQ9rNgBJlRl6g70MQ+J7bqnZtNqOUuxnnwPFPhRS3J3oENiqrC 0JlyfPVVLYtu1Nx1FVztD01s3B7LPLPcqHr1sQPLTwIFxrAw3sOgGiEOdbaQlZt5 CwoGchTEzCgLd2L/pjTC6jPLk5FJpFy4HCtDhip2pX8TTNnEKTGQbDvOuRtw+UyT 9joC25OOMNJ9jjRxbsxOJT3Vg59Vr+wKYyKrRUj6kMu9ZHQm6yCv/W5E9pGBxCK+ wDyHvjVGxP4l2NOtfHnc0Pg8Odj6YOmaXN5ZwvC0dqZSBYHC9PKowuimKESrtSfF BDg7EUSyAUCOZ1VrE+zpRd2/T9UNOb+Z44TM+/XYlrWSu1C1UX3CsD60zGhP4Ljy kUpQPrz0kNyb/n7kPcFD9ZApxlyJBedMKNyCS5lmaFR5OrXw6RHf/oxjOfMmPGlC Yg6yAtDhsA+rTN+rz+WC0rmewLkgDG831Ag3XzULKm0SRHwdrw8PKMpNn7W33UG9 ZjgZxGgX/wUILbIMV3hu =nKnS -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 30 08:54:23 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CEF1A2119 for ; Fri, 30 Jan 2015 08:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf-iRE2gslo1 for ; Fri, 30 Jan 2015 08:54:18 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C601A1EF7 for ; Fri, 30 Jan 2015 08:54:18 -0800 (PST) Received: (qmail 3737 invoked by uid 1004); 30 Jan 2015 16:54:16 -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, 30 Jan 2015 16:54:16 +0000 Received: (qmail 23583 invoked by uid 1000); 30 Jan 2015 16:54:16 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 30 Jan 2015 16:54:16 +0000 Message-ID: <54CBB737.9030809@comodo.com> Date: Fri, 30 Jan 2015 16:54:15 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> In-Reply-To: <87egqcrzzg.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 16:54:21 -0000 Thanks again, DKG. Option 2 it is then. 2. "?." matching =1 redacted label. Do you think we should support redacting (for example) "public.secret.example.com" to "public.?.example.com" ? Or, to keep it simple, shall we disallow unredacted labels to the left of a redacted label? On 30/01/15 16:32, Daniel Kahn Gillmor wrote: > On Fri 2015-01-30 11:09:10 -0500, Rob Stradling wrote: >> OK, let's discard option 1 and option 3. Before we settle on option 2, >> here's an option 4 to consider... >> >> 4. "?" matching =1 character in a redacted label. >> >> Examples: >> "dkg.example.net" would be redacted as "???.example.net". >> "???.example.net" cannot match "jeremy.example.net", because the label >> lengths are different (i.e. 3 != 6). >> However, "???.example.net" might match "rob.example.net". >> >> "topsecret.secret.example.com" would be redacted as >> "?????????.??????.example.com". >> >> >> I don't think there's anything to gain from redacting the length of a >> label, so I prefer option 4. Any thoughts? > > Say i've got a dozen machines in my domain, all using an obscure naming > scheme that you won't be able to guess. > > with option 2, i request and log a single cert for all of them, but > someone monitoring the log can't tell whether i've got a dozen services > or a single service with 11 backup certs. > > My naming scheme might scatter the lengths of the names between 6 and 15 > characters, perhaps into 8 different lengths for the 12 services (there > is some random overlap, and some lengths happen to not get hit). > > With option 4, you now know that i have at least 8 different services > certified. furthermore, you know how many characters exactly to search > in. > > Why would i want to leak this information if i'm interested in avoiding > enumeration? > > > > I also think option 4 is currently ambiguous because of IDN: > > Is the '?' one character in IDN? or one byte in UTF-8 representation of > the IDN? or one character in punycode? We can clarify it, but it seems > likely to encourage a little bit of implementation confusion at least > (IDN is confusing enough). > > The native unit of DNS is the label. It's simplest to use one redaction > symbol for one label. > > >> AFAICT, matching =1 character seem marginally more consistent with other >> uses of "?" as a wildcard character: >> http://en.wikipedia.org/wiki/Wildcard_character >> "In Unix-like and DOS operating systems, the question mark ("?") matches >> exactly one character;" >> "In Microsoft Access, wildcard characters can be used in "LIKE" >> expressions; the asterisk sign (*) matches zero or more characters, and >> the question mark (?) matches a single character." > > If we follow this reasoning, then the better response is to choose a > different redaction mark, not to make the redaction mark be > per-character. if we don't like ?, and we don't want to use * because > of the overlap with current wildcard practice, then we should choose > something else outside the range of the acceptable characters for DNS. > > We could use '%' (thanks, SQL!) or '~' or '!' or '#' or '^' or '|' if > we're looking for single-character replacements. > > I'm personally fine with '?' to mean "matches a single redacted label", > though. > > I'd recommend against '_' because even though it is not a valid > character for a hostname, it is a valid DNS label that is used for > things like SRV records (e.g. _foo._tcp.example.net), and SRVName > SubjectAltName entries could include an '_'. > > --dkg > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jan 30 10:22:46 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2ED1A1BCF for ; Fri, 30 Jan 2015 10:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ZYFlUnLGoIiZ for ; Fri, 30 Jan 2015 10:22:35 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFEE1A1AB9 for ; Fri, 30 Jan 2015 10:21:57 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so37687722lbj.0 for ; Fri, 30 Jan 2015 10:21:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=stxmwqC3Xe2F76/nbwkP5i5HafOaixAnmLveEFD7DIw=; b=TZdpiF1F2WEHs1dy9ePllWjjpij77XcjLRcvTibFBhzVzcVMFYemjrdZuzbDBn+A82 ascNlz/rwt7eRmLURTLAMooUtG00YtZ1P53nj/04FCJHn5t8Y0j37+D9efuNiCOIBbWj K9q/iU4P6ClLx2beqeekNrHmAR/ixr7KtbMfpUaysXiO16WVNaejtIuL1rhsj7xEkEAs /u+e3ailTcts4X1WzXHC0rSNkb5LENXUr8FOeQF90FwjwnsJRSBX7tIcuibhxcBj/Wz+ ggQ7g05P+MBw3P4LQuyw0BSQrs/Ff0akDnp2L+QLkexq6C1Tz+tDf1nHm+t2z0NaEtR3 vntA== X-Gm-Message-State: ALoCoQljXwO4OW72LB4bSMYzma6HIKcq8KoZMaMMLZNIEsbWyUHjVxqGcsyz1JpvpPQuXIHT1QMp X-Received: by 10.112.172.167 with SMTP id bd7mr8084730lbc.14.1422642115917; Fri, 30 Jan 2015 10:21:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.139.36 with HTTP; Fri, 30 Jan 2015 10:21:15 -0800 (PST) X-Originating-IP: [50.5.83.246] In-Reply-To: <54CBB737.9030809@comodo.com> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> From: "Scott R. Corzine" Date: Fri, 30 Jan 2015 13:21:15 -0500 Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=001a11c26986f64f1b050de2adab Archived-At: Cc: trans , Daniel Kahn Gillmor Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 18:22:38 -0000 --001a11c26986f64f1b050de2adab Content-Type: text/plain; charset=UTF-8 On Fri, Jan 30, 2015 at 11:54 AM, Rob Stradling wrote: > Thanks again, DKG. Option 2 it is then. > > 2. "?." matching =1 redacted label. > > > Do you think we should support redacting (for example) " > public.secret.example.com" to "public.?.example.com" ? > > Or, to keep it simple, shall we disallow unredacted labels to the left of > a redacted label? > >From an operations viewpoint I would say to disallow them: * It will at best be rarely used, with few, if any, non-contrived use cases. * It is begging humans or software to miss seeing/correctly processing the unusual "?" buried in the middle of what is easily mistaken for a normal FQDN. * Additional (if only slightly) code complexity and testing will be required but rarely used and unimportant to most customers. Often such low priority features get poorly implemented/tested. * The preceding two points suggest some implementations and deployments could end up with vulnerabilities from a little known feature.. * (Remembering non-contiguous subnet masks) It potentially could prevent some sort of optimization for the other 99+% of cases. * An attacker (or mistake) could exploit the increased chance of human misreading. Detecting/fixing this mistake may be difficult for those who made it in the first place. Without a really strong use case it seems the negatives easily win over the minor increase in flexibility. -Scott- --001a11c26986f64f1b050de2adab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jan 30, 2015 at 11:54 AM, Rob Stradling <rob.stradling@como= do.com> wrote:
Thanks again, DKG.=C2=A0 Option 2 it is then.

2. "?." matching =3D1 redacted label.


Do you think we should support redacting (for example) "public.secret.example.com<= /a>" to "public.?.example.com" ?

Or, to keep it simple, shall we disallow unredacted labels to the left of a= redacted label?

Fro= m an operations viewpoint I would say to disallow them:

* It will at best be rare= ly used, with few, if any, non-contrived use cases.

* It is begging humans or= software to miss seeing/correctly processing the unusual "?" bur= ied in the middle of what is easily mistaken for a normal FQDN.

* Additional (if = only slightly) code complexity and testing will be required but rarely used= and unimportant to most customers. Often such low priority features get po= orly implemented/tested.

* The preceding two points suggest some implementations = and deployments could end up with vulnerabilities from a little known featu= re..

* (Remembering non-contiguous subnet masks) It potentially could prevent= some sort of optimization for the other 99+% of cases.

* An attacker (or mistake) could exploit the increased chance of h= uman misreading. Detecting/fixing this mistake may be difficult for those w= ho made it in the first place.


Without a really strong use case it s= eems the negatives easily win over the minor increase in flexibility.
=

-Scott-
--001a11c26986f64f1b050de2adab-- From nobody Fri Jan 30 10:28:40 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CBC1A1B36 for ; Fri, 30 Jan 2015 10:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4233xcMTwf3 for ; Fri, 30 Jan 2015 10:28:37 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 399631A00BF for ; Fri, 30 Jan 2015 10:28:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 142094770B; Fri, 30 Jan 2015 18:28:36 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id DE1BA4770D; Fri, 30 Jan 2015 18:28:35 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id B71F18004A; Fri, 30 Jan 2015 18:28:35 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 30 Jan 2015 12:28:17 -0600 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.0913.011; Fri, 30 Jan 2015 12:28:17 -0600 From: "Salz, Rich" To: "Scott R. Corzine" , Rob Stradling Thread-Topic: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thread-Index: AdAwRYHYXNIQMi7VQCiOWiH++C2UAAFj2jQAAR8nmQAABGq0AABHK4CAAADV1QAALtl/gAAmsA8AAADO+oAAAMQZgAADCdeAAAxZlAA= Date: Fri, 30 Jan 2015 18:28:17 +0000 Message-ID: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.46.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: trans , Daniel Kahn Gillmor Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 18:28:39 -0000 PiBEbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIHN1cHBvcnQgcmVkYWN0aW5nIChmb3IgZXhhbXBsZSkg InB1YmxpYy5zZWNyZXQuZXhhbXBsZS5jb20iIHRvICJwdWJsaWMuPy5leGFtcGxlLmNvbSIgPw0K DQpOby4gIE1heWJlIGxhdGVyIGlmIHRoZXJlIGlzIGEgc3Ryb25nIGRlbWFuZCBmb3IgdGhpcy4g IFlBR05JLCByaWdodD8NCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyLCBBa2Ft YWkgVGVjaG5vbG9naWVzDQpJTTogcnNhbHpAamFiYmVyLm1lIFR3aXR0ZXI6IFJpY2hTYWx6DQoN Cg0K From nobody Fri Jan 30 11:29:03 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A99C1A006F for ; Fri, 30 Jan 2015 11:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2RuouhI4fq5 for ; Fri, 30 Jan 2015 11:28:59 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id ECC071A0358 for ; Fri, 30 Jan 2015 11:28:58 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CABF7F984; Fri, 30 Jan 2015 14:28:54 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id CAEE0201D1; Fri, 30 Jan 2015 14:28:53 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , "Scott R. Corzine" , Rob Stradling In-Reply-To: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 30 Jan 2015 14:28:52 -0500 Message-ID: <87oapgqd8r.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 19:29:01 -0000 --=-=-= Content-Type: text/plain On Fri 2015-01-30 13:28:17 -0500, Salz, Rich wrote: >> Do you think we should support redacting (for example) "public.secret.example.com" to "public.?.example.com" ? > > No. Maybe later if there is a strong demand for this. YAGNI, right? Barring anyone else speaking up with a clear use case, i'm convinced by Scott and Rich that we don't need this -- so ? redactions are only allowable at the front of the domain name. No redacted labels can be higher in the DNS hierarchy than any non-redacted label. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUy9t1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpchIcP/0b777a0q82KLi2vcGeI9k62 Dyu/XIT09x4Vj3OpFY0HEEou1gJfwc90g+/cR4Dq2xDE4R1/J0lkHQCmoqa5CuqU +dQseCdyTs5OsHyfNtn6bwrXf6s4tfQDAUIElWKMcz0m7qTZ4HJFm71BgWTMCt5q P/3H8TZ9SfC7vWqvgeoj0Z13/Jwy3TJjO4sqjZ4xLTA7fk3IsJbvRnoJq3jfAb8C gZi/w9/tksCWEa69/BfNm51rsznw2RhmeDZA1/3OBzBTrli2mNBtKDwo7rxkhTvM sxAquFsPhwNl1QJb8FMqW5WqfTn0q1zDBsUI0Bhz3dRvJa6dw6+XiW0Hz3guPLo2 nIxYTDpSejP9J92ezDenrd+W7fjIbF25qPLF8PA4zTGgVdfv9sbyyTXKz7haTjpi 4giIyRDVrxh5C5ZCh5QKpajhHLdKq+GG6PT29qOE4Cb3tlMf/k6e0GSFalfKfYvK cAlV6T4OcP21FOJaUONJfQHkm092eeEfZoVkOeipLbJlJHYEShD4+R244oK01ATJ d8Z6dOb8/aD/qMPUjr4oblmfTFYpyQEjqV1vAV0aA7aPslO4zDR2LuTkGrKyEHbg lRXrQKUYL+wAZi7mWsQE3Y1I6ZOuKzb0NLfDvwqEvPotmQ+aY6qo8mjwbzBQQyHy +f4rvfgWKbjB8S0e79IE =hqCr -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 30 12:13:24 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFFE1A1EEF for ; Fri, 30 Jan 2015 12:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i5_wruiGDJp for ; Fri, 30 Jan 2015 12:13:22 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12B51A001A for ; Fri, 30 Jan 2015 12:13:21 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id bj1so56348075pad.1 for ; Fri, 30 Jan 2015 12:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S10LsL0gmblFHSC2crUDJdGcGoLf3ELNUpEhOiwK7jo=; b=rWQKpG/axOqeaoo6FWpJ1YTQ3BFLt3wQoEs6Gq/Cf6xzo1RbIDEZD4UYckyvSqV/uw +9DLzU3PMaB0zaYfeeyfczA8/DqZ47QKHsWcH1MARYU5RpoHCQx64N9zcLOUrxEdTK/j pHyLSl4RDNx8ztY81r58Bm9FKcUfvjO64FqUbkJM8TtJF2CPVDwo+ZV21GQynDIqYkVZ tus5u6Nj+umQU0yf/IVGRd+pnaeWiPMnTY83tIP/oAuy1UVHd4RC6Oot6avl4/B+m/0b +GV5h9l45RhOsCZMQiBzD39ZYs6yyo4opX9nxp8zw2X4f2Elgze4um0czNH53AsVpX/8 s2Ww== MIME-Version: 1.0 X-Received: by 10.70.1.7 with SMTP id 7mr11523115pdi.74.1422648801223; Fri, 30 Jan 2015 12:13:21 -0800 (PST) Received: by 10.70.95.40 with HTTP; Fri, 30 Jan 2015 12:13:21 -0800 (PST) In-Reply-To: <87oapgqd8r.fsf@alice.fifthhorseman.net> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> Date: Fri, 30 Jan 2015 12:13:21 -0800 Message-ID: From: Peter Bowen To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Scott R. Corzine" , "Salz, Rich" , Rob Stradling , trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 20:13:23 -0000 On Fri, Jan 30, 2015 at 11:28 AM, Daniel Kahn Gillmor wrote: > On Fri 2015-01-30 13:28:17 -0500, Salz, Rich wrote: >>> Do you think we should support redacting (for example) "public.secret.example.com" to "public.?.example.com" ? >> >> No. Maybe later if there is a strong demand for this. YAGNI, right? > > Barring anyone else speaking up with a clear use case, i'm convinced by > Scott and Rich that we don't need this -- so ? redactions are only > allowable at the front of the domain name. No redacted labels can be > higher in the DNS hierarchy than any non-redacted label. Is "?" allowed to substitute for "*". I would prefer not, which means that it might be reasonable to have "*.?.example.com" (assuming ?.example.com is reasonable). Thanks, Peter From nobody Fri Jan 30 12:36:24 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BDF1A7006 for ; Fri, 30 Jan 2015 12:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rD8U8Z-o0-w for ; Fri, 30 Jan 2015 12:36:20 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637FB1A7016 for ; Fri, 30 Jan 2015 12:36:04 -0800 (PST) From: Jeremy Rowley To: Peter Bowen , Daniel Kahn Gillmor Thread-Topic: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thread-Index: AQHQPAxUvkg+AumBDUi8y+0yiCcXtpzZS2kAgAAGeICAAAYhgP//wlKugAADLfA= Date: Fri, 30 Jan 2015 20:36:02 +0000 Message-ID: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> 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: [67.137.52.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Scott R. Corzine" , "Salz, Rich" , Rob Stradling , trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 20:36:22 -0000 * isn't a redacted label so the example (*.?.example.com) wouldn't be allow= ed. Also, the CAB Forum prohibits * characters except as the left most lab= el in the cert. Therefore, you would never have an instance with both a "?= " and a "*' in the same cert. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Peter Bowen Sent: Friday, January 30, 2015 1:13 PM To: Daniel Kahn Gillmor Cc: Scott R. Corzine; Salz, Rich; Rob Stradling; trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction On Fri, Jan 30, 2015 at 11:28 AM, Daniel Kahn Gillmor wrote: > On Fri 2015-01-30 13:28:17 -0500, Salz, Rich wrote: >>> Do you think we should support redacting (for example) "public.secret.e= xample.com" to "public.?.example.com" ? >> >> No. Maybe later if there is a strong demand for this. YAGNI, right? > > Barring anyone else speaking up with a clear use case, i'm convinced=20 > by Scott and Rich that we don't need this -- so ? redactions are only=20 > allowable at the front of the domain name. No redacted labels can be=20 > higher in the DNS hierarchy than any non-redacted label. Is "?" allowed to substitute for "*". I would prefer not, which means that it might be reasonable to have "*.?.example.com" (assuming ?.exa= mple.com is reasonable). Thanks, Peter _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Fri Jan 30 12:40:43 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B181A7018 for ; Fri, 30 Jan 2015 12:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OcEE8H3nf2v for ; Fri, 30 Jan 2015 12:40:40 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FFE1A7006 for ; Fri, 30 Jan 2015 12:40:40 -0800 (PST) From: Jeremy Rowley To: Jeremy Rowley , Peter Bowen , Daniel Kahn Gillmor Thread-Topic: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thread-Index: AQHQPAxUvkg+AumBDUi8y+0yiCcXtpzZS2kAgAAGeICAAAYhgP//wlKugAADLfCAAAOiIA== Date: Fri, 30 Jan 2015 20:40:38 +0000 Message-ID: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> 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: [67.137.52.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Scott R. Corzine" , "Salz, Rich" , Rob Stradling , trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 20:40:42 -0000 Although I just realized you're probably wondering if you can substitute "?= " of "*" - so *.example.com would become ?.example.com. =20 It's a good question. I think there's real value in knowing whether a wildc= ard cert was issued over a non-wildcard. I'd actually like the rfc to say = you can't substitute ? for a wildcard character as you're essentially subst= ituting ? for an unlimited number of based domain names.=20 -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Jeremy Rowley Sent: Friday, January 30, 2015 1:36 PM To: Peter Bowen; Daniel Kahn Gillmor Cc: Scott R. Corzine; Salz, Rich; Rob Stradling; trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction * isn't a redacted label so the example (*.?.example.com) wouldn't be allow= ed. Also, the CAB Forum prohibits * characters except as the left most lab= el in the cert. Therefore, you would never have an instance with both a "?= " and a "*' in the same cert. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Peter Bowen Sent: Friday, January 30, 2015 1:13 PM To: Daniel Kahn Gillmor Cc: Scott R. Corzine; Salz, Rich; Rob Stradling; trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction On Fri, Jan 30, 2015 at 11:28 AM, Daniel Kahn Gillmor wrote: > On Fri 2015-01-30 13:28:17 -0500, Salz, Rich wrote: >>> Do you think we should support redacting (for example) "public.secret.e= xample.com" to "public.?.example.com" ? >> >> No. Maybe later if there is a strong demand for this. YAGNI, right? > > Barring anyone else speaking up with a clear use case, i'm convinced=20 > by Scott and Rich that we don't need this -- so ? redactions are only=20 > allowable at the front of the domain name. No redacted labels can be=20 > higher in the DNS hierarchy than any non-redacted label. Is "?" allowed to substitute for "*". I would prefer not, which means that it might be reasonable to have "*.?.example.com" (assuming ?.exa= mple.com is reasonable). Thanks, Peter _______________________________________________ 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 Fri Jan 30 13:24:39 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249821A700F for ; Fri, 30 Jan 2015 13:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgkhAlSzFN-w for ; Fri, 30 Jan 2015 13:24:33 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A705B1A1BE0 for ; Fri, 30 Jan 2015 13:24:33 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 9D7E0F984; Fri, 30 Jan 2015 16:24:30 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id B10F22016E; Fri, 30 Jan 2015 16:24:39 -0500 (EST) From: Daniel Kahn Gillmor To: Peter Bowen In-Reply-To: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 30 Jan 2015 16:24:39 -0500 Message-ID: <878ugkq7vs.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "Scott R. Corzine" , "Salz, Rich" , Rob Stradling , trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 21:24:35 -0000 On Fri 2015-01-30 15:13:21 -0500, Peter Bowen wrote: > On Fri, Jan 30, 2015 at 11:28 AM, Daniel Kahn Gillmor > wrote: >> On Fri 2015-01-30 13:28:17 -0500, Salz, Rich wrote: >>>> Do you think we should support redacting (for example) "public.secret.example.com" to "public.?.example.com" ? >>> >>> No. Maybe later if there is a strong demand for this. YAGNI, right? >> >> Barring anyone else speaking up with a clear use case, i'm convinced by >> Scott and Rich that we don't need this -- so ? redactions are only >> allowable at the front of the domain name. No redacted labels can be >> higher in the DNS hierarchy than any non-redacted label. > > Is "?" allowed to substitute for "*". I would prefer not, which > means that it might be reasonable to have "*.?.example.com" (assuming > ?.example.com is reasonable). Thanks for raising this, Peter. Can you explain why you think it shouldn't be OK for "?" to substitute for "*"? I'm trying to think through the different attack scenarios that CT is intended to mitigate (or at least expose), and the rationales for label redaction, and i'm not seeing why "?" shouldn't be able to stand in for the wildcard. --dkg From nobody Fri Jan 30 14:07:06 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975E61A00ED for ; Fri, 30 Jan 2015 14:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6] 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 PtjdVJTUPi9S for ; Fri, 30 Jan 2015 14:07:04 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D3D791A0070 for ; Fri, 30 Jan 2015 14:07:03 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 939B4F984 for ; Fri, 30 Jan 2015 17:07:01 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id BE094201F8; Fri, 30 Jan 2015 17:07:10 -0500 (EST) From: Daniel Kahn Gillmor To: trans In-Reply-To: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 30 Jan 2015 17:07:07 -0500 Message-ID: <87mw4zq5x0.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 22:07:05 -0000 --=-=-= Content-Type: text/plain On Fri 2015-01-30 15:40:38 -0500, Jeremy Rowley wrote: > Although I just realized you're probably wondering if you can > substitute "?" of "*" - so *.example.com would become ?.example.com. > > It's a good question. I think there's real value in knowing whether a > wildcard cert was issued over a non-wildcard. I'd actually like the > rfc to say you can't substitute ? for a wildcard character as you're > essentially substituting ? for an unlimited number of based domain > names. But isn't that kind of the point? If i control foo.example, and i'm monitoring the logs to make sure no one impersonates anything in my zone (including the apex), then i'm looking for all of the following literal matches as suffixes: foo.example ?.example *.example In particular, of course, i'm looking for entries in the logs that are associated with public keys not under my control (i can ignore my own entries). Note that the first entry there also covers literal strings like: ?.foo.example *.foo.example If i find anything in the logs matching those suffixes, i know that my domain name may have been hijacked, because a matching form could be there. It wouldn't matter to me whether it was being hijacked by someone with a cert that says "foo.example" instead of "*.example", or "*.foo.example" instead of "www.foo.example" -- either one is sufficient to raise an alarm, and (because of the redaction) i wouldn't know if "?.foo.example" was issued to "www.foo.example" or "bar.foo.example" anyway. I still don't see why we shouldn't allow redaction of a wildcard label. What does this restriction defend against? how does it make life easier or better for any of the players in the CT ecosystem? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUzACMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpckOsQAIfUGpFvY/K0bcFMxAV1WLHf JfQUP0NGLmGOa7JLQOXrV0QLbentrKEMc8MlItYzJY9k9dJQ92TsIROcTABwjp8B FG4FyRW0PTXIFJufuzVqGravE3IRSDMU9gd1Lo1zejDqJ+aqUIh4JRYcmlouH3JD JwijrJlUCWUVObRgMqLpvQvFNaEkYPYOHGeAGB2eTChVIlg1GtaliMSLSOXfZ4KM Ox1UPf5pW2rdYJSRODIS6rLXEgSMKAzv4rdmjHB/ZTDArxhs4TvHmC8gG6O50S3L lhCmn9XLTJURsQ7tHCkh5PAO7U284/jaxGLsTROiMAewsLxcJUHwZPrTiHoP6gq/ lZEAXVLUtcYNEW58uSylnmwpF4vWmoVmd5d47PexPPe8ARYPl5jrSgjenvpGS7yT 99DGPnEtzAq3x4/rXrH2YPDwTsRNjEL6Qvr19zdjG+IQgLiLsaZ2aEQxxbKdIP0T 5hRduht1rOIHMrAFe1eDJcYD1YBoWT9lj8iaZmJUep+1pCcQSUbj3R4siPS4FFfp MRtyUg2QZkRnsEgdNjioO/BIoRP/TiPiXBZxSOi1e5pUBf4Igs+VedlrbXTmDyn/ Sqkq9VtZGvh+u9sXUTNiGisTEq8W7mcVoFY40/5wJol2QIMT964EN7q5vcMLI5Zl 5AEeKBxHBRR0wWNZhDU8 =MYOS -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 30 14:16:12 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41471A1B0A for ; Fri, 30 Jan 2015 14:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.612 X-Spam-Level: X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-8LxiwmDDHh for ; Fri, 30 Jan 2015 14:16:08 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A081A0195 for ; Fri, 30 Jan 2015 14:16:08 -0800 (PST) From: Jeremy Rowley To: Daniel Kahn Gillmor , trans Thread-Topic: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thread-Index: AQHQPAxUvkg+AumBDUi8y+0yiCcXtpzZS2kAgAAGeICAAAYhgP//wlKugAADLfCAAAOiIIAAjkmA//+MEqA= Date: Fri, 30 Jan 2015 22:16:06 +0000 Message-ID: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> <87mw4zq5x0.fsf@alice.fifthhorseman.net> In-Reply-To: <87mw4zq5x0.fsf@alice.fifthhorseman.net> 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: [67.137.52.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction 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, 30 Jan 2015 22:16:10 -0000 My idea isn't fully formed yet, but... Wildcard certs are more risky than normal certs since the CA doesn't know e= xactly what they are securing. All they know is the secured base level dom= ain. Therefore, I think the public has a strong interest in knowing when a= wildcard cert was issued v. a standard FQDN cert. However, I'm not sure t= here's much more risk to end certificate requester - they still know everyt= hing that's been issued for their domain. It certainly doesn't make life e= asier for the CT operator or CA, but it gives important information to the = relying parties looking at certs. If they look up a cert in the CT log, th= ey'll be able to easily identify if the entire domain is secured by the sam= e, logged cert. =20 Jeremy -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmo= r Sent: Friday, January 30, 2015 3:07 PM To: trans Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction On Fri 2015-01-30 15:40:38 -0500, Jeremy Rowley wrote: > Although I just realized you're probably wondering if you can=20 > substitute "?" of "*" - so *.example.com would become ?.example.com. > > It's a good question. I think there's real value in knowing whether a=20 > wildcard cert was issued over a non-wildcard. I'd actually like the=20 > rfc to say you can't substitute ? for a wildcard character as you're=20 > essentially substituting ? for an unlimited number of based domain=20 > names. But isn't that kind of the point? If i control foo.example, and i'm monito= ring the logs to make sure no one impersonates anything in my zone (includi= ng the apex), then i'm looking for all of the following literal matches as = suffixes: foo.example ?.example *.example In particular, of course, i'm looking for entries in the logs that are asso= ciated with public keys not under my control (i can ignore my own entries). Note that the first entry there also covers literal strings like: ?.foo.example *.foo.example If i find anything in the logs matching those suffixes, i know that my doma= in name may have been hijacked, because a matching form could be there. It wouldn't matter to me whether it was being hijacked by someone with a ce= rt that says "foo.example" instead of "*.example", or "*.foo.example" instead of "www.foo.example" -- either one is sufficient to raise an alarm,= and (because of the redaction) i wouldn't know if "?.foo.example" was issued to "www.foo.example" or "bar.foo.example" anyway. I still don't see why we shouldn't allow redaction of a wildcard label. What does this restriction defend against? how does it make life easier or= better for any of the players in the CT ecosystem? --dkg From nobody Fri Jan 30 17:58:54 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81CE1A8838 for ; Fri, 30 Jan 2015 17:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf7RvSIXxbe0 for ; Fri, 30 Jan 2015 17:58:51 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDB71A882A for ; Fri, 30 Jan 2015 17:58:51 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id bj1so59108580pad.1 for ; Fri, 30 Jan 2015 17:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Cnzy18DSXjIkxRPcSb8GCKkg1vR9y4oA7SeLiy2dGFA=; b=CELA/Kr3OsNqk2EKMS8CR9M1VJ0CSlkt+SaY2tbvDSeWi3ZGPLJQU6bDsGdaYGV9K5 I/aBJrDwllOndtXrxd8d+ltnmgZAqZcAy0uFdgfGTfpa7QhusIaKeUeY5KQKuhTHl43K qCw+MBAz5QbHH8/AfhofFYnsqdTreXTuf9J70lKB/cho+TslnHyjPBAA34BlnOtsg0lv dIigQTcqO2C4BrhMcnepHKmv8Zg7llUQ/fk52voxlM3LJdRHuFodDlxoRBB+qzf7qyid T8xdhU0XhSwVKi4Grp3UUIlR3Oj+IVQuQDbCDsqRKhKAaiRYk6Duf+52iak2nLQhc15j rlmQ== MIME-Version: 1.0 X-Received: by 10.68.200.97 with SMTP id jr1mr12696674pbc.123.1422669531028; Fri, 30 Jan 2015 17:58:51 -0800 (PST) Received: by 10.70.95.40 with HTTP; Fri, 30 Jan 2015 17:58:50 -0800 (PST) In-Reply-To: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> <87mw4zq5x0.fsf@alice.fifthhorseman.net> Date: Fri, 30 Jan 2015 17:58:50 -0800 Message-ID: From: Peter Bowen To: Jeremy Rowley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: trans , Daniel Kahn Gillmor Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 01:58:53 -0000 On Fri, Jan 30, 2015 at 2:16 PM, Jeremy Rowley wrote: > My idea isn't fully formed yet, but... > > Wildcard certs are more risky than normal certs since the CA doesn't know= exactly what they are securing. All they know is the secured base level d= omain. Therefore, I think the public has a strong interest in knowing when= a wildcard cert was issued v. a standard FQDN cert. However, I'm not sure= there's much more risk to end certificate requester - they still know ever= ything that's been issued for their domain. It certainly doesn't make life= easier for the CT operator or CA, but it gives important information to th= e relying parties looking at certs. If they look up a cert in the CT log, = they'll be able to easily identify if the entire domain is secured by the s= ame, logged cert. I was thinking similarly. I propose that labels containing a "*" may not be redacted, as the "*" effectively is redaction. Additionally, if the left most label is exactly "*", then it is considered redacted for the purposes of determining if the label to the right may be redacted. That would allow *.?.?.example.com to be an allowable redaction. I would also recommend that the right most two labels AND any labels making up a "public suffix" not be allowed to be redacted. I'm not sure if this should go into 6962bis or the policy of clients, auditors, and monitors, but the redacting these effectively nullifies the reason for CT as far as I'm concerned. Thanks, Peter From nobody Fri Jan 30 18:01:50 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7341A8838 for ; Fri, 30 Jan 2015 18:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPNOOuEA0uZ9 for ; Fri, 30 Jan 2015 18:01:47 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FAD1A882A for ; Fri, 30 Jan 2015 18:01:47 -0800 (PST) From: Jeremy Rowley To: Peter Bowen Thread-Topic: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thread-Index: AQHQPAxUvkg+AumBDUi8y+0yiCcXtpzZS2kAgAAGeICAAAYhgP//wlKugAADLfCAAAOiIIAAjkmA//+MEqCAALSrAP//i1Vw Date: Sat, 31 Jan 2015 02:01:45 +0000 Message-ID: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> <87mw4zq5x0.fsf@alice.fifthhorseman.net> 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: [205.118.217.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: trans , Daniel Kahn Gillmor Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 02:01:48 -0000 WWVhaCAtIGdvb2QgcG9pbnRzLiAgV2UgZGVmaW5pdGVseSBkb24ndCB3YW50IHRvIHNlZSBhID8u Y29tIGNlcnQgbG9nZ2VkLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0 ZXIgQm93ZW4gW21haWx0bzpwemJvd2VuQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIEphbnVh cnkgMzAsIDIwMTUgNjo1OSBQTQ0KVG86IEplcmVteSBSb3dsZXkNCkNjOiBEYW5pZWwgS2FobiBH aWxsbW9yOyB0cmFucw0KU3ViamVjdDogUmU6IFtUcmFuc10gW3RyYW5zXSAjNTQgKHJmYzY5NjIt YmlzKTogU2ltcGxpZnkgbmFtZSByZWRhY3Rpb24NCg0KT24gRnJpLCBKYW4gMzAsIDIwMTUgYXQg MjoxNiBQTSwgSmVyZW15IFJvd2xleSA8amVyZW15LnJvd2xleUBkaWdpY2VydC5jb20+IHdyb3Rl Og0KPiBNeSBpZGVhIGlzbid0IGZ1bGx5IGZvcm1lZCB5ZXQsIGJ1dC4uLg0KPg0KPiBXaWxkY2Fy ZCBjZXJ0cyBhcmUgbW9yZSByaXNreSB0aGFuIG5vcm1hbCBjZXJ0cyBzaW5jZSB0aGUgQ0EgZG9l c24ndCBrbm93IGV4YWN0bHkgd2hhdCB0aGV5IGFyZSBzZWN1cmluZy4gIEFsbCB0aGV5IGtub3cg aXMgdGhlIHNlY3VyZWQgYmFzZSBsZXZlbCBkb21haW4uICBUaGVyZWZvcmUsIEkgdGhpbmsgdGhl IHB1YmxpYyBoYXMgYSBzdHJvbmcgaW50ZXJlc3QgaW4ga25vd2luZyB3aGVuIGEgd2lsZGNhcmQg Y2VydCB3YXMgaXNzdWVkIHYuIGEgc3RhbmRhcmQgRlFETiBjZXJ0LiAgSG93ZXZlciwgSSdtIG5v dCBzdXJlIHRoZXJlJ3MgbXVjaCBtb3JlIHJpc2sgdG8gZW5kIGNlcnRpZmljYXRlIHJlcXVlc3Rl ciAtIHRoZXkgc3RpbGwga25vdyBldmVyeXRoaW5nIHRoYXQncyBiZWVuIGlzc3VlZCBmb3IgdGhl aXIgZG9tYWluLiAgSXQgY2VydGFpbmx5IGRvZXNuJ3QgbWFrZSBsaWZlIGVhc2llciBmb3IgdGhl IENUIG9wZXJhdG9yIG9yIENBLCBidXQgaXQgZ2l2ZXMgaW1wb3J0YW50IGluZm9ybWF0aW9uIHRv IHRoZSByZWx5aW5nIHBhcnRpZXMgbG9va2luZyBhdCBjZXJ0cy4gIElmIHRoZXkgbG9vayB1cCBh IGNlcnQgaW4gdGhlIENUIGxvZywgdGhleSdsbCBiZSBhYmxlIHRvIGVhc2lseSBpZGVudGlmeSBp ZiB0aGUgZW50aXJlIGRvbWFpbiBpcyBzZWN1cmVkIGJ5IHRoZSBzYW1lLCBsb2dnZWQgY2VydC4N Cg0KSSB3YXMgdGhpbmtpbmcgc2ltaWxhcmx5LiAgSSBwcm9wb3NlIHRoYXQgbGFiZWxzIGNvbnRh aW5pbmcgYSAiKiIgbWF5IG5vdCBiZSByZWRhY3RlZCwgYXMgdGhlICIqIiBlZmZlY3RpdmVseSBp cyByZWRhY3Rpb24uICBBZGRpdGlvbmFsbHksIGlmIHRoZSBsZWZ0IG1vc3QgbGFiZWwgaXMgZXhh Y3RseSAiKiIsIHRoZW4gaXQgaXMgY29uc2lkZXJlZCByZWRhY3RlZCBmb3IgdGhlIHB1cnBvc2Vz IG9mIGRldGVybWluaW5nIGlmIHRoZSBsYWJlbCB0byB0aGUgcmlnaHQgbWF5IGJlIHJlZGFjdGVk LiBUaGF0IHdvdWxkIGFsbG93ICouPy4/LmV4YW1wbGUuY29tIHRvIGJlIGFuIGFsbG93YWJsZSBy ZWRhY3Rpb24uDQoNCkkgd291bGQgYWxzbyByZWNvbW1lbmQgdGhhdCB0aGUgcmlnaHQgbW9zdCB0 d28gbGFiZWxzIEFORCBhbnkgbGFiZWxzIG1ha2luZyB1cCBhICJwdWJsaWMgc3VmZml4IiBub3Qg YmUgYWxsb3dlZCB0byBiZSByZWRhY3RlZC4gIEknbSBub3Qgc3VyZSBpZiB0aGlzIHNob3VsZCBn byBpbnRvIDY5NjJiaXMgb3IgdGhlIHBvbGljeSBvZiBjbGllbnRzLCBhdWRpdG9ycywgYW5kIG1v bml0b3JzLCBidXQgdGhlIHJlZGFjdGluZyB0aGVzZSBlZmZlY3RpdmVseSBudWxsaWZpZXMgdGhl IHJlYXNvbiBmb3IgQ1QgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQuDQoNClRoYW5rcywNClBldGVy DQo= From nobody Fri Jan 30 18:18:18 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85C1A883D for ; Fri, 30 Jan 2015 18:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_MgO7Pr4BUP for ; Fri, 30 Jan 2015 18:18:14 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647611A883C for ; Fri, 30 Jan 2015 18:18:14 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id eu11so59170691pac.13 for ; Fri, 30 Jan 2015 18:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IkQpyTX3T7956M+imfjRo2MQ1sK/ZrSIBaZ8AbmIjL4=; b=sJR+r7EfhTkBcwqgWxy26yO6Pdg9WCm4UFy222J7MFeRXAuuvpMywcv9zduI/5JCZe nEgFS5+t5akAgBJCZrAwCmUqhqUJqRJZOb7/Yc9T4IQfTD3TXy+nAxDCF7GXK01ge8r2 pDtXEqkiXZDF3iW93BU3EF80QNJ8rt5GAUs+IgM8fYq8u84WQACjimJLY3SCtHVYM7GY oE30Ko4SqPoryH5kFlx02qrC+AfG5rl1B+AETazNwhJGwNi7JyCL3w6S7xIj+aZGT/ov LUdZx2qb/xWeOddO5UvTiVzpOfQkGmi+Zn1MCpbduzDtTgRraw2RJ3H1O7KuZmu6+Fet XImg== MIME-Version: 1.0 X-Received: by 10.66.100.230 with SMTP id fb6mr13254108pab.156.1422670693676; Fri, 30 Jan 2015 18:18:13 -0800 (PST) Received: by 10.70.95.40 with HTTP; Fri, 30 Jan 2015 18:18:13 -0800 (PST) In-Reply-To: References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <54997600.4060506@comodo.com> <54AAB0EC.5080007@bbn.com> <54AB17A5.1090505@comodo.com> <54B6CD16.4030105@bbn.com> <54B6E6E0.4040509@comodo.com> <54BFF4C2.20905@bbn.com> <54C76DC2.3080209@comodo.com> <54C78B66.6040405@comodo.com> <87iofqecqk.fsf@alice.fifthhorseman.net> <54C96E9E.1010102@comodo.com> <87a911cliy.fsf@alice.fifthhorseman.net> <54CBACA6.3010509@comodo.com> <87egqcrzzg.fsf@alice.fifthhorseman.net> <54CBB737.9030809@comodo.com> <87oapgqd8r.fsf@alice.fifthhorseman.net> <87mw4zq5x0.fsf@alice.fifthhorseman.net> Date: Fri, 30 Jan 2015 18:18:13 -0800 Message-ID: From: Peter Bowen To: Jeremy Rowley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: trans , Daniel Kahn Gillmor Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 02:18:16 -0000 Nor do I think we want a ?.mil or ?.pvt.k12.ma.us logged. The former is technically valid, as mil is not a public suffix, rather it is a registered name and the latter has the longest public suffix I've seen. On Fri, Jan 30, 2015 at 6:01 PM, Jeremy Rowley wrote: > Yeah - good points. We definitely don't want to see a ?.com cert logged. > > -----Original Message----- > From: Peter Bowen [mailto:pzbowen@gmail.com] > Sent: Friday, January 30, 2015 6:59 PM > To: Jeremy Rowley > Cc: Daniel Kahn Gillmor; trans > Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction > > On Fri, Jan 30, 2015 at 2:16 PM, Jeremy Rowley wrote: >> My idea isn't fully formed yet, but... >> >> Wildcard certs are more risky than normal certs since the CA doesn't kno= w exactly what they are securing. All they know is the secured base level = domain. Therefore, I think the public has a strong interest in knowing whe= n a wildcard cert was issued v. a standard FQDN cert. However, I'm not sur= e there's much more risk to end certificate requester - they still know eve= rything that's been issued for their domain. It certainly doesn't make lif= e easier for the CT operator or CA, but it gives important information to t= he relying parties looking at certs. If they look up a cert in the CT log,= they'll be able to easily identify if the entire domain is secured by the = same, logged cert. > > I was thinking similarly. I propose that labels containing a "*" may not= be redacted, as the "*" effectively is redaction. Additionally, if the le= ft most label is exactly "*", then it is considered redacted for the purpos= es of determining if the label to the right may be redacted. That would all= ow *.?.?.example.com to be an allowable redaction. > > I would also recommend that the right most two labels AND any labels maki= ng up a "public suffix" not be allowed to be redacted. I'm not sure if thi= s should go into 6962bis or the policy of clients, auditors, and monitors, = but the redacting these effectively nullifies the reason for CT as far as I= 'm concerned. > > Thanks, > Peter From nobody Fri Jan 30 18:35:55 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0341A8849 for ; Fri, 30 Jan 2015 18:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.421 X-Spam-Level: X-Spam-Status: No, score=0.421 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, 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 dTIhG_BLiWxK for ; Fri, 30 Jan 2015 18:35:51 -0800 (PST) Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id DE8BC1A8829 for ; Fri, 30 Jan 2015 18:35:50 -0800 (PST) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id D11F8282E37 for ; Sat, 31 Jan 2015 13:35:49 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id C94009FFFC; Sat, 31 Jan 2015 13:35:48 +1100 (AEDT) Date: Sat, 31 Jan 2015 13:35:48 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20150131023548.GQ13742@hezmatt.org> References: <87oapgqd8r.fsf@alice.fifthhorseman.net> <87mw4zq5x0.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 02:35:52 -0000 On Sat, Jan 31, 2015 at 02:01:45AM +0000, Jeremy Rowley wrote: > Yeah - good points. We definitely don't want to see a ?.com cert logged. Actually, I'd be quite happy to see a precert for ?.com logged. It would make it quite clear which CA is failing to play by the rules, which is, after all, rather the point of CT. - Matt From nobody Fri Jan 30 19:03:32 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A31A8858 for ; Fri, 30 Jan 2015 19:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ueglxu5bXmkJ for ; Fri, 30 Jan 2015 19:03:29 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F37A1A8852 for ; Fri, 30 Jan 2015 19:03:29 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id z6so12407828yhz.10 for ; Fri, 30 Jan 2015 19:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zL7L3GyIGgofTdBofn6wKgWXH8vJ6PNTIzlfPgu2MUc=; b=iz1xucv+1Gw2rknMqMBjI40U4o8S/1sqUOwEep9hX8wo45+HcCi4rYL4OqZQck2m8Y ZZnbv/I2TpQfLsNziRfUCfoNcxaxupAY9UJEKHHMAUDdNVNL3boRNI1eqVNuoH5i4DHg JqZo4HAXrXGOIljsRhMScr22/IKQWFPbgtmAcLn/swFNMfvScJTJJ31MujdTJ7X3Co53 eg6KakuaoaEveElFCA8n64p1qcuFJKQk52QH/Ar5LQnn8o0jKz+sP2IO6LMfLURPS3hB Df8zcCmOd6ac2v54y99bvLMXRXsVWcTDEL3SdacQK94X9AF2wcD2Z7Q7mbGPfE/ZOunv Z8/Q== MIME-Version: 1.0 X-Received: by 10.170.217.9 with SMTP id j9mr4895255ykf.19.1422673408324; Fri, 30 Jan 2015 19:03:28 -0800 (PST) Received: by 10.170.115.77 with HTTP; Fri, 30 Jan 2015 19:03:28 -0800 (PST) In-Reply-To: <20150131023548.GQ13742@hezmatt.org> References: <87oapgqd8r.fsf@alice.fifthhorseman.net> <87mw4zq5x0.fsf@alice.fifthhorseman.net> <20150131023548.GQ13742@hezmatt.org> Date: Fri, 30 Jan 2015 19:03:28 -0800 Message-ID: From: Watson Ladd To: Matt Palmer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 03:03:31 -0000 On Fri, Jan 30, 2015 at 6:35 PM, Matt Palmer wrote: > On Sat, Jan 31, 2015 at 02:01:45AM +0000, Jeremy Rowley wrote: >> Yeah - good points. We definitely don't want to see a ?.com cert logged. > > Actually, I'd be quite happy to see a precert for ?.com logged. It would > make it quite clear which CA is failing to play by the rules, which is, > after all, rather the point of CT. Backing up quite a bit: It's clear from the examples that the level at which you can safely truncate a domain and know that you are identifying a unique organization is extremely difficult to determine. I'm sure there is a list out there, but it may change. And when it changes, old software may suddenly either accept too many certs, or too few. I'm sure people have thought about this more than I have. Sincerely, Watson Ladd > > - Matt > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jan 30 22:14:02 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9061E1A8885 for ; Fri, 30 Jan 2015 22:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b5_JBxvWrsR for ; Fri, 30 Jan 2015 22:13:58 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A311A8879 for ; Fri, 30 Jan 2015 22:13:58 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id ey11so60785134pad.7 for ; Fri, 30 Jan 2015 22:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BSYxTechyS8XmF+3LNAF9RLf1uhdZ1Ulnj8tanbqcxk=; b=spXTFcxG37lsndarsrqwEIexKrTlOIdaF+Yc464Z5BXStQ4JUNg99ibqgxyM819LeQ 9gBNpZI0Cs0JT0g5aGbfvxmjbwtNfHdVan643xe2au4/s9SBwm0tLBigPJuHGnsvXsbn XvLEbH6YtPJxgvKEGtjq10/ErQsIs9sU5pBwjhO4Imf9fOU2RKOta0wRMLXRwQt5mMBt UEhLvr5XgUDJPITIH+0UFHNQZq+1Qj3uUwiAL13Zo8YBtwooJ/BFd8JhexELgWdJwfiJ xN50MfXSkkd31+rMPfNvxIYEjnP8PX9EdCSX8r4eIKHYXvnA+qq19Il0nQr6S2/rjznr hPBg== MIME-Version: 1.0 X-Received: by 10.66.164.163 with SMTP id yr3mr14326928pab.154.1422684837919; Fri, 30 Jan 2015 22:13:57 -0800 (PST) Received: by 10.70.95.40 with HTTP; Fri, 30 Jan 2015 22:13:57 -0800 (PST) In-Reply-To: References: <87oapgqd8r.fsf@alice.fifthhorseman.net> <87mw4zq5x0.fsf@alice.fifthhorseman.net> <20150131023548.GQ13742@hezmatt.org> Date: Fri, 30 Jan 2015 22:13:57 -0800 Message-ID: From: Peter Bowen To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Matt Palmer , "trans@ietf.org" Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 06:14:00 -0000 On Fri, Jan 30, 2015 at 7:03 PM, Watson Ladd wrote: > On Fri, Jan 30, 2015 at 6:35 PM, Matt Palmer wrote: >> On Sat, Jan 31, 2015 at 02:01:45AM +0000, Jeremy Rowley wrote: >>> Yeah - good points. We definitely don't want to see a ?.com cert logged. >> >> Actually, I'd be quite happy to see a precert for ?.com logged. It would >> make it quite clear which CA is failing to play by the rules, which is, >> after all, rather the point of CT. > > Backing up quite a bit: It's clear from the examples that the level at > which you can safely truncate a domain and know that you are > identifying a unique organization is extremely difficult to determine. > I'm sure there is a list out there, but it may change. And when it > changes, old software may suddenly either accept too many certs, or > too few. > > I'm sure people have thought about this more than I have. Take a look at http://www.publicsuffix.org/ It is a formatted list that attempts to document the split between shared (e.g. public) portions of a fully qualified domain name and the registered (private) portion. The new TLD rush is going to cause interesting issues, as there is a concept of a ".brand" where the whole TLD represents one organization. I think there is an argument these are not new (as .mil is effectively a .brand for the US Department of Defense), but I'm sure that they will be interesting from a processing perspective. ? anyone? From nobody Fri Jan 30 23:00:05 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EC51A88A7 for ; Fri, 30 Jan 2015 23:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, 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 ZQhGP3Wi7egF for ; Fri, 30 Jan 2015 23:00:01 -0800 (PST) Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 524B41A8889 for ; Fri, 30 Jan 2015 23:00:01 -0800 (PST) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 70AC9282E37 for ; Sat, 31 Jan 2015 18:00:00 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 848199FFFC; Sat, 31 Jan 2015 17:59:59 +1100 (AEDT) Date: Sat, 31 Jan 2015 17:59:59 +1100 From: Matt Palmer To: "trans@ietf.org" Message-ID: <20150131065959.GR13742@hezmatt.org> References: <87mw4zq5x0.fsf@alice.fifthhorseman.net> <20150131023548.GQ13742@hezmatt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 07:00:03 -0000 On Fri, Jan 30, 2015 at 10:13:57PM -0800, Peter Bowen wrote: > On Fri, Jan 30, 2015 at 7:03 PM, Watson Ladd wrote: > > On Fri, Jan 30, 2015 at 6:35 PM, Matt Palmer wrote: > >> On Sat, Jan 31, 2015 at 02:01:45AM +0000, Jeremy Rowley wrote: > >>> Yeah - good points. We definitely don't want to see a ?.com cert logged. > >> > >> Actually, I'd be quite happy to see a precert for ?.com logged. It would > >> make it quite clear which CA is failing to play by the rules, which is, > >> after all, rather the point of CT. > > > > Backing up quite a bit: It's clear from the examples that the level at > > which you can safely truncate a domain and know that you are > > identifying a unique organization is extremely difficult to determine. > > I'm sure there is a list out there, but it may change. And when it > > changes, old software may suddenly either accept too many certs, or > > too few. > > > > I'm sure people have thought about this more than I have. > > Take a look at http://www.publicsuffix.org/ It is a formatted list > that attempts to document the split between shared (e.g. public) > portions of a fully qualified domain name and the registered (private) > portion. > > The new TLD rush is going to cause interesting issues, as there is a > concept of a ".brand" where the whole TLD represents one organization. > I think there is an argument these are not new (as .mil is effectively > a .brand for the US Department of Defense), but I'm sure that they > will be interesting from a processing perspective. ? anyone? publicsuffix.org is what is recommended for CAs to use in determining whether to allow registration of a name, I believe. For the purposes of CT logs, specifically, though, I believe it's irrelevant. Logging a certificate shows what was issued, logging a precert shows what was intended to be issued. CT monitors should be watching for signs of inappropriate behaviour. Logging a precert such that the legitimate owner of *any* FQDN cannot determine with confidence that the unredacted precert could actually be for something in their namespace is an inappropriate behaviour. It's no different than logging a cert with an overly-broad wildcard, such as a sAN of `dNSName:*.com`. - Matt