From nobody Mon Feb 2 01:46: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 3163B1A0092 for ; Mon, 2 Feb 2015 01:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9s9wjSojQ_lF for ; Mon, 2 Feb 2015 01:46: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 78B481A0084 for ; Mon, 2 Feb 2015 01:46:13 -0800 (PST) Received: from localhost ([::1]:42510 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YIDa7-0007e1-7g; Mon, 02 Feb 2015 01:46: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: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 02 Feb 2015 09:46:11 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/56#comment:1 Message-ID: <079.33d0b18cf9d3664b53fb436f7fe9917e@tools.ietf.org> References: <064.ad3ccf5068565e4491a4337770641dc9@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <064.ad3ccf5068565e4491a4337770641dc9@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, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [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: Mon, 02 Feb 2015 09:46:27 -0000 #56: "*" domain labels MUST NOT be redacted Comment (by rob.stradling@comodo.com): The current text of 6962-bis says: 'When creating a Precertificate, the CA MAY substitute one or more of the complete leftmost labels in each DNS-ID with the literal string "(PRIVATE)".' On the mailing list we considered relaxing the "complete" and/or "leftmost" requirements, but everyone seems to agree that both of these requirements should remain. Peter Bowen suggests that... '...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.' (Note: Peter's example assumes that we will change the redaction label from "(PRIVATE)" to "?", as proposed in ticket #54). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Feb 2 01:53: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 0BE4D1A00B1 for ; Mon, 2 Feb 2015 01:53:47 -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 VfGBGK_rYK7U for ; Mon, 2 Feb 2015 01:53:42 -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 D2CC51A00A2 for ; Mon, 2 Feb 2015 01:53:40 -0800 (PST) Received: (qmail 16277 invoked by uid 1004); 2 Feb 2015 09:53:38 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 02 Feb 2015 09:53:38 +0000 Received: (qmail 13041 invoked by uid 1000); 2 Feb 2015 09:53:38 -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, 02 Feb 2015 09:53:38 +0000 Message-ID: <54CF4922.1000902@comodo.com> Date: Mon, 02 Feb 2015 09:53:38 +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: Peter Bowen References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans , Daniel Kahn Gillmor , Jeremy Rowley 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, 02 Feb 2015 09:53:47 -0000 On 31/01/15 01:58, Peter Bowen wrote: > 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 domain. 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 everything 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 the 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. http://trac.tools.ietf.org/wg/trans/trac/ticket/56 > 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. Good idea. I've noted this suggestion on ticket #56. Thanks Peter. > 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. That's what this section of the I-D attempts to address: 7.3. Redaction of Public Domain Name Labels CAs SHOULD NOT redact domain name labels in Precertificates to the extent that domain name ownership becomes unclear (e.g. "(PRIVATE).com" and "(PRIVATE).co.uk" would both be problematic). Logs MUST NOT reject any Precertificate that is overly redacted but which is otherwise considered compliant. It is expected that monitors will treat overly redacted Precertificates as potentially misissued. TLS clients MAY reject a certificate whose corresponding Precertificate would be overly redacted. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Feb 2 02:35: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 9B9601A00BE for ; Mon, 2 Feb 2015 02:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSxJRRDoKWsm for ; Mon, 2 Feb 2015 02:35:08 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 4E0801A0092 for ; Mon, 2 Feb 2015 02:35:08 -0800 (PST) Received: from [10.246.38.222] (unknown [207.218.72.66]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BA326F258F; Mon, 2 Feb 2015 02:35:06 -0800 (PST) Message-ID: <54CF3531.7090100@mozilla.org> Date: Mon, 02 Feb 2015 08:28:33 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Bowen , Jeremy Rowley References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <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: OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Mon, 02 Feb 2015 10:35:10 -0000 On 31/01/15 02:18, Peter Bowen wrote: > 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 Er, .mil is a public suffix. Check the public suffix list. :-) Gerv From nobody Mon Feb 2 06: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 266731A1A23 for ; Mon, 2 Feb 2015 06:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf_5ARMHZ5Tp for ; Mon, 2 Feb 2015 06:37:24 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A331A039A for ; Mon, 2 Feb 2015 06:37:24 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id rd3so82984061pab.9 for ; Mon, 02 Feb 2015 06:37:23 -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=lQGcgSlhFjjkYXAptxQS6cIlBymVSE/A+Kz8+p2pDJI=; b=o7FfZAJUP79FsS3JqRjpJlixBCvZ/MAQ5btB8BsM1EjTuc7BlM9cuoy7raWEnBKp1l 9ugA2xJyPqoLJg9/tPDi/H4QAM8mbRaqhumy+TLNS4rzVllEnxpcwCNFnd6d6zZrYQkN ZMYTHEVRB+0zvT2NeTmoMIGjsihI6BG8zohTLfA2jKIa7ZblpGD2a0QjNgFP5XJYRzYP T5mUbxaRq1CH2+3tUkSK040VPotr9moawr8hPOp0bvuqYoYO7fWyiOi8wF8Zs+O2w23f WnqdpP0b3n3MVMK2shGuElbcGtYPL+A4kZkOBSFhjSPHnoU2FfeEeMDf4Bvvu/HVjQyA LNhA== MIME-Version: 1.0 X-Received: by 10.70.138.77 with SMTP id qo13mr19231107pdb.135.1422887843700; Mon, 02 Feb 2015 06:37:23 -0800 (PST) Received: by 10.70.95.40 with HTTP; Mon, 2 Feb 2015 06:37:23 -0800 (PST) Received: by 10.70.95.40 with HTTP; Mon, 2 Feb 2015 06:37:23 -0800 (PST) In-Reply-To: <54CF3531.7090100@mozilla.org> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <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> <54CF3531.7090100@mozilla.org> Date: Mon, 2 Feb 2015 06:37:23 -0800 Message-ID: From: Peter Bowen To: Gervase Markham Content-Type: multipart/alternative; boundary=001a11363c6a7aa7e0050e1be47c Archived-At: Cc: trans , jeremy rowley , 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: Mon, 02 Feb 2015 14:37:26 -0000 --001a11363c6a7aa7e0050e1be47c Content-Type: text/plain; charset=UTF-8 On Feb 2, 2015 2:35 AM, "Gervase Markham" wrote: > > On 31/01/15 02:18, Peter Bowen wrote: > > 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 > > Er, .mil is a public suffix. Check the public suffix list. :-) > I know what the list says. This is not rally a core topic for this WG/list. Is there a list for PSL discussion? --001a11363c6a7aa7e0050e1be47c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 2, 2015 2:35 AM, "Gervase Markham" <gerv@mozilla.org> wrote:
>
> On 31/01/15 02:18, Peter Bowen wrote:
> > Nor do I think we want a ?.mil=C2=A0 or ?.pvt.k12.ma.us logged.=C2=A0 The former
> > is technically valid, as mil is not a public suffix, rather it is= a
> > registered name
>
> Er, .mil is a public suffix. Check the public suffix list. :-)
>

I know what the list says.=C2=A0 This is not rally a core to= pic for this WG/list.=C2=A0 Is there a list for PSL discussion?

--001a11363c6a7aa7e0050e1be47c-- From nobody Mon Feb 2 06:44:44 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14C71A1A70 for ; Mon, 2 Feb 2015 06:44:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 YxQZlUWKohsR for ; Mon, 2 Feb 2015 06:44:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF621A1B14 for ; Mon, 2 Feb 2015 06:44:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 877D9BF06; Mon, 2 Feb 2015 14:44:59 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bx0wh-K48GG; Mon, 2 Feb 2015 14:44:59 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 613D5BEF6; Mon, 2 Feb 2015 14:44:59 +0000 (GMT) Message-ID: <54CF8D4D.5050001@cs.tcd.ie> Date: Mon, 02 Feb 2015 14:44:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Bowen , Gervase Markham References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <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> <54CF3531.7090100@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: trans , Daniel Kahn Gillmor , jeremy rowley 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, 02 Feb 2015 14:44:43 -0000 On 02/02/15 14:37, Peter Bowen wrote: > On Feb 2, 2015 2:35 AM, "Gervase Markham" wrote: >> >> On 31/01/15 02:18, Peter Bowen wrote: >>> 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 >> >> Er, .mil is a public suffix. Check the public suffix list. :-) >> > > I know what the list says. This is not rally a core topic for this > WG/list. Is there a list for PSL discussion? Not exactly, but the currently-being-chartered dbound wg [1] list [2] is probably the closest IETF list. I'd expect there's a better list elsewhere specifically for the PSL S. [1] https://datatracker.ietf.org/doc/charter-ietf-dbound/ [2] https://www.ietf.org/mailman/listinfo/dbound > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Mon Feb 2 11:02: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 3BD591A885C for ; Mon, 2 Feb 2015 11:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWRFBt4o-AMv for ; Mon, 2 Feb 2015 11:02:33 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (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 510011A883F for ; Mon, 2 Feb 2015 11:02:32 -0800 (PST) Received: from [192.168.0.103] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B7834F25D1; Mon, 2 Feb 2015 11:02:30 -0800 (PST) Message-ID: <54CFC9C4.30403@mozilla.org> Date: Mon, 02 Feb 2015 19:02:28 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Bowen References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <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> <54CF3531.7090100@mozilla.org> In-Reply-To: OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: trans , jeremy rowley , 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: Mon, 02 Feb 2015 19:02:36 -0000 On 02/02/15 14:37, Peter Bowen wrote: > I know what the list says. This is not rally a core topic for this > WG/list. Is there a list for PSL discussion? No; if you want to propose the removal or reclassification of .mil, email submissions@publicsuffix.org. We would open a bug in bugzilla.mozilla.org. Gerv From nobody Mon Feb 2 12:49:47 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A5E1A8F34 for ; Mon, 2 Feb 2015 12:49:46 -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 t5BWDHf0EB0U for ; Mon, 2 Feb 2015 12:49:45 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1641A876B for ; Mon, 2 Feb 2015 12:49:45 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id fa1so86880676pad.8 for ; Mon, 02 Feb 2015 12:49:44 -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=T6cujCoRpmMTwa4X7AYvWv+h9HScK8SwUAxHUgrTW2A=; b=Tqxgq3tPlgR9s+p+RQmGBtDub1s06gczpGgn2a00QhWUiO11G5OiC91FdJYZ8LfEYt TJzqnB7/ZqJRAHNwsC8AFnt9cEqVN6KrbzN86ZGw3GVX/MNbRBazkyS2SactRruoGrKO C5+pXS/GpnZB0StbK4Xu4hCDpqVTNnS3Rl03cx1Yej0/cNaj5emgyoT5eU+1a+atLBS+ yKqsgtQCXVTSP4iUVYQPSYPzDBi9mC4T6qekUmDuImXsNPBbbYKErgSi6bRTtR5tjLDO lBjQ1x+U8FTArZxREEsE8QPqT304V5jjCh1IdmztPVUUQscFGth0yYq92ieOfqJjdb0X gR+w== MIME-Version: 1.0 X-Received: by 10.68.200.97 with SMTP id jr1mr31934814pbc.123.1422910184502; Mon, 02 Feb 2015 12:49:44 -0800 (PST) Received: by 10.70.95.40 with HTTP; Mon, 2 Feb 2015 12:49:44 -0800 (PST) In-Reply-To: <54CFC9C4.30403@mozilla.org> References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <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> <54CF3531.7090100@mozilla.org> <54CFC9C4.30403@mozilla.org> Date: Mon, 2 Feb 2015 12:49:44 -0800 Message-ID: From: Peter Bowen To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: trans , jeremy rowley , 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: Mon, 02 Feb 2015 20:49:46 -0000 On Mon, Feb 2, 2015 at 11:02 AM, Gervase Markham wrote: > On 02/02/15 14:37, Peter Bowen wrote: >> I know what the list says. This is not rally a core topic for this >> WG/list. Is there a list for PSL discussion? > > No; if you want to propose the removal or reclassification of .mil, > email submissions@publicsuffix.org. We would open a bug in > bugzilla.mozilla.org. https://bugzilla.mozilla.org/show_bug.cgi?id=1128673 From nobody Thu Feb 5 04:30:57 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC39D1A87BD for ; Thu, 5 Feb 2015 04:30:55 -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 38eonXpikNNY for ; Thu, 5 Feb 2015 04:30:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D98D1A00C3 for ; Thu, 5 Feb 2015 04:30:54 -0800 (PST) Received: from localhost ([::1]:46703 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YJLa5-0003L7-HJ; Thu, 05 Feb 2015 04:30:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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: Thu, 05 Feb 2015 12:30:49 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/40#comment:2 Message-ID: <067.5edeeb8e3f92ccc587ca9c9bd65c8f74@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, 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, eranm@google.com, rob.stradling@comodo.com Archived-At: 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: Thu, 05 Feb 2015 12:30:56 -0000 #40: Auditor behavior Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Fixed in https://github.com/google/certificate-transparency- rfcs/commit/6076dccaadfcd70af8f6ce3aa725aacd6e8f553e. -- -------------------------+------------------------------------------------- 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 Thu Feb 5 04:42: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 D79981A87D9 for ; Thu, 5 Feb 2015 04:42:16 -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 y0d43x0KC79B for ; Thu, 5 Feb 2015 04:42:15 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFE91A87D2 for ; Thu, 5 Feb 2015 04:42:14 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id z60so1919296qgd.10 for ; Thu, 05 Feb 2015 04:42:14 -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=oQhU+GaI51ZH9pMhFyozDzYE/dr7mbIm6N5zetXwhak=; b=alfAUhKwpV+L0HjzmFbrPIicEe0XdLk4ZKxi56w9/NfpQysQeFDsAYW64aO+WzBxtP q4A0NbTKXwB2TKtcsgmVDZVjnDR8Qti8HU/GFDXRMVxDMmh0oLL6emIsXCe2QwRVVbEU zIPhqCk4VUafCmSfbOOnECicB2AE7EgfRfBOC5YGA8+TVFafnyJ9BWjZSI3g0gw2e3iz BhYpwY0tMU5iAbf/QRVQgza9gDPub48X8hzrXBzKezaN+t74savnDtkx5O3KJ8GUPC9k x6hbgHbK7VIPofWzr0ydxdmK/tOUesZna2kifshUd5W3/57hOmzplxGSfAFgsvcze/Lc sc5Q== 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=oQhU+GaI51ZH9pMhFyozDzYE/dr7mbIm6N5zetXwhak=; b=TXEb/tQc8ws7745IysMnXhSXGIafdJKAnjCA7fye89sunve4yycfOPVmOh37EXajgw LXjeQ8w1BTiDcUGAdqM53jAkhyPZUEQE7oL/Mv9aCmbkq/HLhIT1cVLbDi9c2xjMYz/k CcQkBxTpxg0C6gd8P6LZuR2qU5u/1cnACZMnXqcT4NUotQon9IwPy2GwgPOQdazr/Ege okmXC/u1FJ5yUp//YlyfX51ZNrrweSzAtQi0LJ/8qSu4MVSE/nAhU3bUTlDlscWufQ4c qeVbzwsy+uLYy54k/e3hKrcbk35rZiQtqsKxaKAoeASjeRf0jqraWnFvZsaAVpYL9CyE nWjw== X-Gm-Message-State: ALoCoQkpy7IDJKlyOfkJBbt7v7T2z8cbLGeNYpa8ifIqzwEZ8W+LnD8ravzEOiYI3A0cVTL/w6+j MIME-Version: 1.0 X-Received: by 10.140.94.236 with SMTP id g99mr2981378qge.70.1423140134007; Thu, 05 Feb 2015 04:42:14 -0800 (PST) Received: by 10.229.224.6 with HTTP; Thu, 5 Feb 2015 04:42:13 -0800 (PST) In-Reply-To: <548B55BB.4010501@bbn.com> References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> Date: Thu, 5 Feb 2015 12:42:13 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: multipart/alternative; boundary=001a113a69f8276148050e56a220 Archived-At: 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: Thu, 05 Feb 2015 12:42:17 -0000 --001a113a69f8276148050e56a220 Content-Type: text/plain; charset=UTF-8 On 12 December 2014 at 20:53, Stephen Kent wrote: > Ben, > > On 11 December 2014 at 16:50, Paul Wouters wrote: >> >>> On Thu, 11 Dec 2014, Melinda Shore wrote: >>> >>> One of the open issues (ticket 34: >>>> https://tools.ietf.org/wg/trans/trac/ticket/34) >>>> concerns SCT syntax, with Steve Kent arguing that either ASN.1 should >>>> be used or that there needs to be a clearer justification for the >>>> choice of 5246 representation (see RFC 5246, section 4). We need to >>>> come to a decision whether or not to go ahead and carry forward what's >>>> in 6962 (the TLS format). This is a call for discussion - we'd really >>>> like to close this in the next week or so. >>>> >>> See also Ben's slide deck from IETF-91 (slide 6 & 7) >>> >>> http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf >>> >>> And the raw minutes (look for "slides-91-trans-4.pdf" in the text) >>> >>> http://www.ietf.org/proceedings/91/minutes/minutes-91-trans >>> >>> Ben has argued that SCT's appear only as TLS structures or DER format, >>> and prefers the TLS structure as the DER format is used with OCSP only. >>> >> Actually, also used in certs. >> > Yes, but when used in certs (and OCSP responses) the SCT will be in > an ASN.1 encoded context. > >> Steve has argued against that since two of the three formats are ASN.1. >>> >> That's not really an argument. My argument is that in ten years' time >> almost all CT info will be transmitted as TLS extensions. >> > I think mine is a very valid argument based on the fact that 6962-bis > proposed 3 ways to convey the same data and did not explain why we need > all three ways. Your argument above says that CAs will (essentially) cease > logging pre-certs, after having rewritten their code to do so to meet > Google's mandate for EV certs and Chrome acceptance in early 2015. This > seems > like a questionable projection to me, but maybe there are other details > that > lead you to this conclusion, but which you have mot shared. Can you > elaborate > on why you anticipate such a change? (The analysis should be on the list, > to > facilitate discussion, but it also belongs in the document if the WG elects > to retain the 5246 encoding convention.) > My thinking is that: 1. There is concern, generally, about the size of certificates (really about the size of handshakes). 2. Embedding SCTs in certs leads to more bloat than either OCSP stapling or the TLS extension because the SCTs cannot be updated, and so more are required (see Chrome's EV/CT policy). 3. Embedding SCTs in certs runs the risk that the SCTs will become invalid before the cert does. 4. Certs are not generally updated before expiry. 5. Stapled OCSP requires the CA, the webserver and the CT logs to be actively involved. 6. The TLS extension only requires the webserver and the CT logs to be actively involved. 7. All three mechanisms can be made essentially automatic from the webservers POV. So, I would expect in the long run that the TLS extension would be the favoured option. --001a113a69f8276148050e56a220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 12 December 2014 at 20:53, Stephen Kent <kent@bbn.com> wro= te:
Ben,

On 11 December 2014 at 16:50, Paul Wouters<paul@nohats.ca>=C2=A0 wrote:
On Thu, 11 Dec 2014, Melinda Shore wrote:

One of the open issues (ticket 34:
https://tools.ietf.org/wg/trans/trac/ticket/34)
concerns SCT syntax, with Steve Kent arguing that either ASN.1 should
be used or that there needs to be a clearer justification for the
choice of 5246 representation (see RFC 5246, section 4).=C2=A0 We need to come to a decision whether or not to go ahead and carry forward what's<= br> in 6962 (the TLS format).=C2=A0 This is a call for discussion - we'd re= ally
like to close this in the next week or so.
See also Ben's slide deck from IETF-91 (slide 6 & 7)

http://www.ietf.org/proceedings/91/slides/slides-= 91-trans-4.pdf

And the raw minutes (look for "slides-91-trans-4.pdf" in the text= )

http://www.ietf.org/proceedings/91/minutes/min= utes-91-trans

Ben has argued that SCT's appear only as TLS structures or DER format,<= br> and prefers the TLS structure as the DER format is used with OCSP only.
Actually, also used in certs.
 Yes, but when used in certs (and OCSP responses) the SCT will be in
an ASN.1 encoded context.
Steve has argued against that since two of the three formats are ASN.1.
That's not really an argument. My argument is that in ten years' ti= me
almost all CT info will be transmitted as TLS extensions.
 I think mine is a very valid argument based on the fact that 6962-bis
proposed 3 ways to convey the same data and did not explain why we need
all three ways. Your argument above says that CAs will (essentially) cease<= br> logging pre-certs, after having rewritten their code to do so to meet
Google's mandate for EV certs and Chrome acceptance in early 2015. This= seems
like a questionable projection to me, but maybe there are other details tha= t
lead you to this conclusion, but which you have mot shared. Can you elabora= te
on why you anticipate such a change? (The analysis should be on the list, t= o
facilitate discussion, but it also belongs in the document if the WG elects=
to retain the 5246 encoding convention.)

My thinking is that:

1. There is concern, genera= lly, about the size of certificates (really about the size of handshakes).<= /div>

2. Embedding SCTs in certs leads to more bloat tha= n either OCSP stapling or the TLS extension because the SCTs cannot be upda= ted, and so more are required (see Chrome's EV/CT policy).
3. Embedding SCTs in certs runs the risk that the SCTs will be= come invalid before the cert does.

4. Certs are no= t generally updated before expiry.

5. Stapled OCSP= requires the CA, the webserver and the CT logs to be actively involved.

6. The TLS extension only requires the webserver and= the CT logs to be actively involved.

7. All three= mechanisms can be made essentially automatic from the webservers POV.

So, I would expect in the long run that the TLS extens= ion would be the favoured option.

--001a113a69f8276148050e56a220-- From nobody Thu Feb 5 04:47: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 66EC91A879D for ; Thu, 5 Feb 2015 04:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 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, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsWsdfjwU2_m for ; Thu, 5 Feb 2015 04:47:18 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA061A00B6 for ; Thu, 5 Feb 2015 04:47:18 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id l89so5911449qgf.3 for ; Thu, 05 Feb 2015 04:47:17 -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=3puLII4toEcNBNIcKrRZ8RHAiXUDg4zmj5NQ9g4J70I=; b=NRSMZDEfS07Mc8+jWDB6mYa0mPCVyz6kghw+mbAfKhnaP5wPece5hSSPSgtFTYXFGX +gZ00iPX4fzedPk3TRt5M01C4ZqhXLS7OxiJzxCiTZ22Fw5kWMER5+Q4inZoorQK3KkJ ZUf11Ie8fsl6x51j4K4O+NR/53cJ2oQ9eBV4ZMDI9+la9eC5E4dXXYGdORTAiHz9rntJ ByGm/eCPXdhUV4H+s2lfrMHGGeMHSATrORvFDQaqmHSQ0uQraB+RHHH9rp00/x6CmcHO T1Pj6VSrZdMxhZrc2UXlF3x6Qr2pNWLmDzyCRWl0/U81VgztKGBkSM9hQ3RHIAVIcorH rTyw== 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=3puLII4toEcNBNIcKrRZ8RHAiXUDg4zmj5NQ9g4J70I=; b=ebXRqP/A+SbRKjxVdqBVmaSKaAOrRNclWpx5aCfwb2ffXQFOqOCZ/gnHCAPGx7LTNt UFcYXhMsWNIP3ProkQeVoCwN+n4mbrqgDpPmOh/jnGOX0o8awiZhIL1wKN3bWugrwqPK pB4k4Qepe3xYHEQjMZG+HWRC64P0vnCKF6a/CDpsG2Mlt8K/0WkaA2UE6UlduUzl7Py/ qVxWpNO/dSNF/VINg1TMgJsMVR+lAUws0UYKFdGr9nGc1Nu0N0XH8Jc76rIAVUuRFPCJ yCW54oGKp970sr9SKbFtLaHh4f4uW7JBvvuF+lkqSZE6HPRu/Zuuha1No4g8js2FUUcI 0naQ== X-Gm-Message-State: ALoCoQkKK1itkGO0F8pLZ9UuOkY2RrCCfZKlQO8nrmiDUCKebBO5i4D75UCUYhZPjkempA5+s/WX MIME-Version: 1.0 X-Received: by 10.224.135.200 with SMTP id o8mr7967634qat.1.1423140437276; Thu, 05 Feb 2015 04:47:17 -0800 (PST) Received: by 10.229.224.6 with HTTP; Thu, 5 Feb 2015 04:47:17 -0800 (PST) In-Reply-To: <54AAB0F8.6010707@bbn.com> References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> <54AAB0F8.6010707@bbn.com> Date: Thu, 5 Feb 2015 12:47:17 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11c2a3483adf8a050e56b484 Archived-At: 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: Thu, 05 Feb 2015 12:47:20 -0000 --001a11c2a3483adf8a050e56b484 Content-Type: text/plain; charset=UTF-8 On 5 January 2015 at 15:42, Stephen Kent wrote: > 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? > My argument is that over time servers will deal with SCTs automatically and CAs will stop including SCTs (at least optionally) as a result. --001a11c2a3483adf8a050e56b484 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 5 January 2015 at 15:42, Stephen Kent <kent@bbn.com> wrot= e:
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 th= e
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 PK= I 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 tha= t 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<= br> 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?

My argument is that over time servers wi= ll deal with SCTs automatically and CAs will stop including SCTs (at least = optionally) as a result.

--001a11c2a3483adf8a050e56b484-- From nobody Thu Feb 5 05:08: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 282201A874C for ; Thu, 5 Feb 2015 05:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4O42w7WaagtK for ; Thu, 5 Feb 2015 05:07:47 -0800 (PST) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440821A87AD for ; Thu, 5 Feb 2015 05:07:16 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id v8so5631707qal.8 for ; Thu, 05 Feb 2015 05:07:15 -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=papDouR2lCMQ0e9+UY93gNz3IqZrSASCfNOuZXzxSb8=; b=N4UM/8R0ipEQ71GvzTHobPFGudwdxPUZslNKsRKUiXNFQRRMtSxtxVbO3opcheTcJU oJ7hbHV2lcTxq5VFLkQIZQ68iift7G3Jafc1Y07a8P+ElrOvO63GwpFfH83rnJqeQTc9 2HGH31NqPsPhHrjOIKynGVyLXg2vQHE0wSEG83e8rqQ9W+6W4GkHvHNeHjGnur0KRoUH kaIESUXbs9JHsKUrwWW27d+E9E9xeWM8FDbEWWZ0g4V0g06huuU1NNBkViHa8pS65ZOJ 9Qem9mOT8YqSbSu0TtNg53VVMsEa0SkC4HGm/xousKu97nAM0e907mWoK1t0yXqdPVB2 DM8Q== 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=papDouR2lCMQ0e9+UY93gNz3IqZrSASCfNOuZXzxSb8=; b=RwMV5qvhzThMl2ERuUebqtYcoB6yFl0MwFK69zUfMJ9KD6NWAOVupo1nZYOe8SFnjY Ef15cyFs6vjbn3+2CFIh6YR1uLTGTJNCf5vfMUh3UarrSAg2ROX3/6wTaNsXzs5TwpeA PsZ0+1JEtHyMFuUXXiXd7CUWgqQqcyt+27aNRQ5dsT97KgkMV1njPnJhkI5cJXwRIau5 aNXfgp2ChrnBKnTMcjO65JEVHV46kzhcMS8nmPoxRbrx31/2jhJbYkdLEI37/hM4/LLv EdDziFnuvIjFc9RHdPI+0B8BE45hYmP9N7nWjBWnHthVZImsGD41AwNQPXR8LftFXMpw 2LHw== X-Gm-Message-State: ALoCoQnV4ZJQTbopq/8kZ8qOB4Gay+WjDyUvPKARg0nUOwEtqXYKyZPHu7FyZD79Yr/oTwJXLNjJ MIME-Version: 1.0 X-Received: by 10.140.36.239 with SMTP id p102mr7937708qgp.8.1423141635384; Thu, 05 Feb 2015 05:07:15 -0800 (PST) Received: by 10.229.224.6 with HTTP; Thu, 5 Feb 2015 05:07:15 -0800 (PST) In-Reply-To: <54C129CF.3020800@bbn.com> References: <54C129CF.3020800@bbn.com> Date: Thu, 5 Feb 2015 13:07:15 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11c11e06a49357050e56fbd6 Archived-At: Cc: "trans@ietf.org" Subject: Re: [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, 05 Feb 2015 13:07:54 -0000 X-List-Received-Date: Thu, 05 Feb 2015 13:07:54 -0000 --001a11c11e06a49357050e56fbd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22 January 2015 at 16:48, Stephen Kent wrote: > updated to reflect dropping TLS client behavior specs, no gossip protoco= l > yet defined, > and no stand-alone Auditors. > > comments welcome, but I'm abut to head off on vacation, so I won't be abl= e > 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 depen= ds > 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. I= f > not, then the next point of differentiation is whether the mis-issuance w= as > 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 logge= d, > it is necessary to consider whether the log(s) may have conspired with th= e > attacker. Finally, one must consider the possibility that a third party > Monitor might collude with an attacker (or a malicious CA). Here=E2=80=99= 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. Certi= ficate > 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 an= d > 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 context= s. > > > > > > *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 detecti= on > 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 Subje= ct > 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 fo= r > 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 check= s, > 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.) > Note that there's nothing special about the log here: anyone can detect syntactic mis-issuance by simply feeding the certificate to an appropriate tool. > > > *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 =E2=80=9Cbogus=E2=80=9D. In this cas= e 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 o= ne > or more logs. If a Monitor is =E2=80=9Cprotecting=E2=80=9D the affected S= ubject, 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 th= e > 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 (supplie= d > by the Subject) to determine the serial number of the mis-issued > certificate, and revoke it (after investigation). (See Notes 1 + 2.) *Sin= ce > 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 bog= us > certificates*. (See XX.1.2.2 and Note 3.) > The lack of a requirement for rejection does not mean that popular TLS clients will not reject. As you know, Chrome will shortly stop showing EV indicators for EV certs without valid SCTs, even though there is no requirement to do so. It seems to me a more accurate analysis would be along the lines of: *"If TLS clients do not reject certificates or otherwise notify users 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.) > See above. > > > 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 > =E2=80=9Cgossip=E2=80=9D 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.* > Again, lack of requirement does not imply lack of implementation. Again, I would suggest this should be phrased conditionally. > > > 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. > Not sure of the relevance of "non-conspiring" here? > 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 o= f > 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 =E2=80=9Cno guidelines=E2=80=9D reserved CC= ID). > > 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 indicate= d > by the SCT), a malicious CA need not worry about failing a log-based chec= k. > 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, th= e > 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 cou= ld > be thwarted. > Again, the log has no special role to play in the detection of syntactic errors: TLS clients that wish to reject such certificates can do so unaided. Indeed, I would've thought conformance to existing RFCs would imply such behaviour - and if they don't, surely CT is not the place to fix that? > > > *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.)* > See above (both on requirements and on CT's role in syntax). > > > *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 als= o > perform syntactic checks, this form of mis-issuance will not be thwarted. > TLS clients will believe that the certificate has been syntactically > verified. > Why would they believe that, given there's no requirement to do such verification? > > > *XX*.2.4 A malicious CA may semantically mis-issue a certificate that is > syntactically valid. Because it is syntactically valid, logs will not mar= k > the bogus certificate as failing a syntax check. The semantically bogus > certificate may have been issued because the CA was bribed or was compell= ed > 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 lac= ks > (or is not accompanied by) an SCT, there is no motivation for an attacker > to submit the certificate in this case. (See Note 3.)* > See above. > > > *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 arg= ue > 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 logge= d. > 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 entrie= s > from some or all Monitors. Any Monitor (even a self-Monitor) from which t= he > 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 =E2=80=9C= gossip=E2=80=9D > 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 generat= ed > 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 =E2=80=9Csufficient=E2=80=9D coverage? If a Subject= acts as its own > Monitor, this problem is solved for that Subject. It also is not clear ho= w > a Monitor becomes aware of all (relevant?) logs, including newly created > logs. The means by which Monitors become aware of new logs MUST accommoda= te > 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 Subjec= t > should not expect immediate revocation of a contested certificate. The ti= me > 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, bas= ed > 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 t= o > (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 certificat= es > 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 seriou= s > collateral damage. If this specification were to require that a browser c= an > be configured to reject a specific, bogus certificate identified by a > Monitor, then the bogus certificate could be rejected in that fashion. Th= is > 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 externa= l > entity such as a Monitor. Moreover, the same or another malicious CA coul= d > issue new bogus certificates for the targeted Subject, which would have t= o > 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, i= t > cannot alert the Subject. If one or more SCTs are present in a certificat= e, > 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 clien= ts > reject certificates that contains SCTs from conspiring logs (based on inf= o > 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 =E2=80=9Cgossip=E2=80=9D protocol that enables Monitors to verif= y 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 effecti= ng > 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 t= o > 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 tha= t > 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 certifica= te > discovery mechanisms to build the list of valid certificates since such > mechanisms might result in mis-issued certificates being added to the lis= t. > > > > As noted above, Monitors represent another target for adversaries who wis= h > 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 b= e > universal when evaluating protection against Monitor compromise. > > > > A final note: Now that certificate pinning has been approved as a standar= d > (currently in the RFC Editor=E2=80=99s queue), it is appropriate to facto= r 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 withou= t > use of any CT mechanisms. The security considerations section of 6962-bis > needs to note this, since deployment of pinning appears to reduces the ne= ed > for CT in the Web PKI context. > It is Google's view that pinning is not a scalable solution, unlike CT. We do not agree that pinning reduces the need for CT. --001a11c11e06a49357050e56fbd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 January 2015 at 16:48, Stephen Kent <kent@bbn.com> wrot= e:
=20 =20 =20
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= 9;t be able to respond immediately

Steve
=20 =20 =20 =20 =20 =20 =20 =20 =20 ------

=20

XX. Attack Model and Discussion of Detection and Mitigation Options

=C2=A0

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.

=C2=A0

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=E2=80=99s an taxonomy of attacks and assumption= s about the attack environment:

1. CA

<= span>a. Non-malicious CA<= /p>

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 i.=C2=A0=C2=A0 Error<= /p>

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 ii.= =C2=A0=C2=A0 Attack victim<= /p>

<= span>1. Certificate logged

<= span>a. Benign log

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 i.=C2=A0=C2=A0 Self-mon= itor

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 ii.=C2=A0=C2=A0 Benign 3rd party Monitor

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 iii.=C2=A0=C2=A0 Conspiri= ng 3rd party Monitor

<= span>b. Conspiring log

<= span>2. Certificate not logged

<= span>b. Malicious CA

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 i.=C2=A0=C2=A0 Certificate logged

<= span>1. Benign log

<= span>a. Self-monitor

<= span>b. Benign 3rd party Monitor

<= span>c. Conspiring 3rd party Monitor

<= span>2. Conspiring log

<= span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ii.=C2=A0=C2=A0 Certificate not logged

=C2=A0

=C2=A0

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.

=C2=A0

=C2=A0

XX.1 Non-malicious Web PKI CA context

=C2=A0

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.<= /span>

=C2=A0

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.

=C2=A0

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.

=C2=A0

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.)


Note that there's nothing special about the l= og here: anyone can detect syntactic mis-issuance by simply feeding the cer= tificate to an appropriate tool.
=C2=A0

=

=C2=A0

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 =E2=80=9Cbogus=E2=80=9D. 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 =E2=80=9Cprotecting=E2=80=9D the affecte= d 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.=C2=A0

=

<= /u>

=C2=A0

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.

=C2=A0

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.)


The lack of a requirement for= rejection does not mean that popular TLS clients will not reject. As you k= now, Chrome will shortly stop showing EV indicators for EV certs without va= lid SCTs, even though there is no requirement to do so.

It seems to me a more accurate analysis would be along the lines of:<= /div>

"If TLS clients do not reject certificates or = otherwise notify users 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.)."

=C2=A0

=C2=A0

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.)


See above.
=C2=A0

=C2=A0

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 =E2=80=9Cgossip=E2=80=9D to detec= t 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.


Again, lack of requirement does not imply lack of implementation. Ag= ain, I would suggest this should be phrased conditionally.
=C2=A0=

=C2=A0

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.


Not su= re of the relevance of "non-conspiring" here?

=C2=A0

If a Subject relies on a third-party Monito= r, and that Monitor conspires with the attacker, the Subject will not be alerted and thus will not request revocation.

=C2=A0

=C2=A0

XX.2 Malicious Web PKI CA context

=C2=A0

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.

=C2=A0

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

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The CA may assert that the certificate is being issued w/o regard to any guidelines (the =E2=80=9Cno guidelines=E2=80=9D reserved CCID).

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

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 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.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The CA may submit a (pre-) certificate to a log that is known to not perform any syntactic checks, and thus avoid syntactic checking.

=C2=A0

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.


Again, the log has no special role to play in the detection of synta= ctic errors: TLS clients that wish to reject such certificates can do so un= aided. Indeed, I would've thought conformance to existing RFCs would im= ply such behaviour - and if they don't, surely CT is not the place to f= ix that?

=C2=A0

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.)


See above (both on requireme= nts and on CT's role in syntax).
=C2=A0

=

=C2=A0

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. =C2=A0The 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.


Why would they believe that, given there's no requirement to do s= uch verification?
=C2=A0

=

=C2=A0

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.)=C2=A0 This CA might be one or more tiers below a trust anchor (aka root CA).

=C2=A0

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.)


See above.
=C2=A0

<= u>

=C2=A0

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.)

=C2=A0

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.

=C2=A0

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.

=C2=A0

The audit function is intended to detect logs that conspire to suppress log entries, based on consistency checking of logs and use of a =E2=80=9Cgossip=E2=80=9D = 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.)

=C2=A0

Notes:

=C2=A0

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 =E2=80=9Csufficien= t=E2=80=9D 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.

=C2=A0

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).

=C2=A0

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.=

=C2=A0

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.

=C2=A0

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.

=C2=A0

Absent a =E2=80=9Cgossip=E2=80=9D 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.

=C2=A0

Monitors pla= y 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.=C2=A0

Note: =C2=A0A 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.=C2=A0If 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,=C2=A0or due to compromise of the CA or the RA.=C2=A0 If a CA or RA database is used, it does detect mis-issuance by an unauthorized CA.=C2=A0 A Monitor must not rely o= n certificate discovery mechanisms to build the list of valid certificates since such mechanisms might result in mis-issued certificates being added to the list.

=C2=A0

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.

=C2=A0

A final note: Now that certificate pinning has been approved as a standard (currently in the RFC Editor=E2=80=99s 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.


It is Goo= gle's view that pinning is not a scalable solution, unlike CT. We do no= t agree that pinning reduces the need for CT.

--001a11c11e06a49357050e56fbd6-- From nobody Thu Feb 5 06: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 0AA8C1A88BA for ; Thu, 5 Feb 2015 06:14: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 Lth1P4Qf4VFf for ; Thu, 5 Feb 2015 06:13: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 592FA1A88C3 for ; Thu, 5 Feb 2015 06:13:50 -0800 (PST) Received: from localhost ([::1]:52284 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YJNBb-00077B-CY; Thu, 05 Feb 2015 06:13:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, linus@nordu.net X-Trac-Project: trans Date: Thu, 05 Feb 2015 14:13:39 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/58 Message-ID: <055.b793219aebf9d4b50b2e649d13c13ebe@tools.ietf.org> X-Trac-Ticket-ID: 58 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #58 (rfc6962-bis): Maximise number of STH's published per time unit X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 14:14:00 -0000 #58: Maximise number of STH's published per time unit Logs can mount a fingerprinting attack against clients by issuing separate STH's for clients the wish to track. This could be thwarted by the standard stipulating a maximum number of STH's that a log is allowed to issue per time unit before it is considered bad. Monitors should be able to detect if a log ignores this limitation. A fair figure might be max one STH per hour, unless someone sees a need for a higher frequency. Implementation wise, you might want this to be configurable for debugging purposes. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- linus@nordu.net | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 9 05:21: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 8F9C51A0354 for ; Mon, 9 Feb 2015 05:16: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 gbqDVAsCF9bE for ; Mon, 9 Feb 2015 05:16: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 60AB91A00F4 for ; Mon, 9 Feb 2015 05:16:07 -0800 (PST) Received: from localhost ([::1]:54246 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YKoC6-0003X2-Vq; Mon, 09 Feb 2015 05:16: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: benl@google.com X-Trac-Project: trans Date: Mon, 09 Feb 2015 13:16:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/13#comment:2 Message-ID: <070.3dfbb4e90c6de783d964176daf3c3c3b@tools.ietf.org> References: <055.ba070951954649e9f972ab2851b0d608@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <055.ba070951954649e9f972ab2851b0d608@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #13 (rfc6962-bis): Deal with server farm skew 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, 09 Feb 2015 13:16:09 -0000 #13: Deal with server farm skew Changes (by benl@google.com): * status: assigned => closed * resolution: => fixed Comment: Done at https://github.com/google/certificate-transparency- rfcs/commit/d7291e1946d2f845f35f7468d109b347d5daa49f. -- -----------------------------+------------------------------ Reporter: benl@google.com | Owner: benl@google.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+------------------------------ Ticket URL: trans From nobody Mon Feb 9 05:39:20 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040601A00BB for ; Mon, 9 Feb 2015 05:39:19 -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 Gf1-IOdkn-Ke for ; Mon, 9 Feb 2015 05:39:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCB31A0018 for ; Mon, 9 Feb 2015 05:39:17 -0800 (PST) Received: from localhost ([::1]:55319 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YKoYU-0001TJ-CK; Mon, 09 Feb 2015 05:39: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, benl@google.com X-Trac-Project: trans Date: Mon, 09 Feb 2015 13:39:14 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/35#comment:1 Message-ID: <067.0e467e1ead6063613f9d849768ccdf20@tools.ietf.org> References: <052.0e59a44f849382436b8e6495ba8fb961@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <052.0e59a44f849382436b8e6495ba8fb961@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #35 (rfc6962-bis): server SCT transmission restriction is misstated 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, 09 Feb 2015 13:39:19 -0000 #35: server SCT transmission restriction is misstated Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Closed with https://github.com/google/certificate-transparency- rfcs/commit/3cf83718c385e41f8e838b2b0351c595b86c1ac1. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Feb 10 06:26:38 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD25D1A026E for ; Tue, 10 Feb 2015 06:26:34 -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 2GTf7JmfTNKC for ; Tue, 10 Feb 2015 06:26:32 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5421A0267 for ; Tue, 10 Feb 2015 06:26:32 -0800 (PST) Received: from localhost ([::1]:53782 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YLBla-00083r-Go; Tue, 10 Feb 2015 06:26: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, rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 10 Feb 2015 14:26:18 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/59 Message-ID: <064.8c7fdcc81bea3236b4aa924cd51122dd@tools.ietf.org> X-Trac-Ticket-ID: 59 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, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #59 (rfc6962-bis): Clarify STH versioning 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, 10 Feb 2015 14:26:35 -0000 #59: Clarify STH versioning The current draft defines TreeHeadVersion v2, denoting a v2 STH. However, in a couple of places the current draft still requires the STH version to be v1. The only reason for TreeHeadVersion v2 was to add the CtSthExtensions field, which we perhaps don't need. We should either: 1. Revert the changes that introduced TreeHeadVersion v2. or 2. Change the text that currently requires STH v1 to require STH v2 instead. -- -------------------------------------+------------------------------------- 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 Feb 10 07:01: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 ADF071A903D for ; Tue, 10 Feb 2015 07:01:41 -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 6mpimlCEKs5b for ; Tue, 10 Feb 2015 07:01: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 59E0C1A9034 for ; Tue, 10 Feb 2015 07:00:50 -0800 (PST) Received: from localhost ([::1]:56830 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YLCIx-0004ke-PU; Tue, 10 Feb 2015 07:00: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, benl@google.com X-Trac-Project: trans Date: Tue, 10 Feb 2015 15:00:47 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/19#comment:1 Message-ID: <070.1cda334a5aae053220bad9e95e161a02@tools.ietf.org> References: <055.0b3a2471215c7078e9351aebe921f126@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <055.0b3a2471215c7078e9351aebe921f126@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #19 (rfc6962-bis): Rejig API for efficiency/correctness 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, 10 Feb 2015 15:01:42 -0000 #19: Rejig API for efficiency/correctness Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Clock skew was partially dealt with in response to other tickets. The remaining issues were dealt with in https://github.com/google /certificate-transparency- rfcs/commit/e3ddb2a1da0b0551e0f83fcb27ed5a7d438a5fe1. -- -------------------------+------------------------------------------------- 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: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 16 07:46: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 8C1751A88A5 for ; Mon, 16 Feb 2015 07:46:31 -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_20=-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 6VH3W1JdBE3I for ; Mon, 16 Feb 2015 07:46: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 ED0611A1EED for ; Mon, 16 Feb 2015 07:46:29 -0800 (PST) Received: from localhost ([::1]:38589 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNNsO-0002bc-WC; Mon, 16 Feb 2015 07:46:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Mon, 16 Feb 2015 15:46:24 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/22#comment:1 Message-ID: <070.561f4156dd5a1f2ba23794f87dc56126@tools.ietf.org> References: <055.3058e6b07c40fa8cc9c757257fab482e@tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <055.3058e6b07c40fa8cc9c757257fab482e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #22 (rfc6962-bis): Explain why there are three delivery mechanisms for SCTs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 15:46:31 -0000 #22: Explain why there are three delivery mechanisms for SCTs Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Fixed in https://github.com/google/certificate-transparency- rfcs/commit/0cf9709247f82b2438202743ffeb95a9345f8675. -- -------------------------+------------------------------------------------- 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: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Feb 16 15:39: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 349941A88EB for ; Mon, 16 Feb 2015 15:39:23 -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 tL6e02WHSSCo for ; Mon, 16 Feb 2015 15:39:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2CD1A88EA for ; Mon, 16 Feb 2015 15:39:21 -0800 (PST) Received: from dhcp89-089-186.bbn.com ([128.89.89.186]:52967) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YNVG4-000L5F-6q; Mon, 16 Feb 2015 18:39:20 -0500 Message-ID: <54E27FA9.6020100@bbn.com> Date: Mon, 16 Feb 2015 18:39:21 -0500 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: trans@ietf.org References: <54C129CF.3020800@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "kseo@bbn.com" Subject: Re: [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: Mon, 16 Feb 2015 23:39:23 -0000 Folks, I've found the discussion on the list and the analysis itself helpful in clarifying and assessing the aims and mechanisms 6962-bis. It strikes me that it would be similarly helpful to other users/readers of 6962-bis. What does the group think of adding it to 6962-bis? Thank you, Karen From nobody Tue Feb 17 05:55: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 1F4E31A1B13 for ; Tue, 17 Feb 2015 05:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KkCZLVtixUX0 for ; Tue, 17 Feb 2015 05:55:17 -0800 (PST) Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817601A1ADC for ; Tue, 17 Feb 2015 05:55:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFABdH41QKPDLY/2dsb2JhbABbgwZSWgSCMMANCoVxAoESQwEBAQEBAXyEDAEBAQQBAQE3NBcEAgEFAw0BAwQBAR8JBycLFAkIAgQBEgiIJwUI0BwBAQEBAQEEAQEBAQEBARcEiw+EdQaEJAWfVIwoIoNuPjGBRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,594,1418101200"; d="scan'208";a="32540" Received: from unknown (HELO svaexch1.cygnacom.com) ([10.60.50.216]) by ipesa2.cygnacom.com with ESMTP; 17 Feb 2015 08:55:15 -0500 Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch1.cygnacom.com (10.60.50.216) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 17 Feb 2015 08:55:14 -0500 Received: from svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e]) by svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e%12]) with mapi id 15.00.0913.011; Tue, 17 Feb 2015 08:55:13 -0500 From: Santosh Chokhani To: Karen Seo , "trans@ietf.org" Thread-Topic: [Trans] updated attack analysis Thread-Index: AQHQQUTJaBwtu5DVokCClHZ2IrRITpz0VNuAgACXqHA= Date: Tue, 17 Feb 2015 13:55:13 +0000 Message-ID: References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> In-Reply-To: <54E27FA9.6020100@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.191.89.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [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: Tue, 17 Feb 2015 13:55:19 -0000 Karen, This is a good idea. We need the threat analysis to document the assumptio= ns under which the mechanisms are effective and what the residual vulnerabi= lities are. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Karen Seo Sent: Monday, February 16, 2015 6:39 PM To: trans@ietf.org Cc: kseo@bbn.com Subject: Re: [Trans] updated attack analysis Folks, I've found the discussion on the list and the analysis itself helpful in cl= arifying and assessing the aims and mechanisms 6962-bis. It strikes me tha= t it would be similarly helpful to other users/readers of 6962-bis. What d= oes the group think of adding it to 6962-bis? Thank you, Karen _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Tue Feb 17 06:56:13 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8A1A89A8 for ; Tue, 17 Feb 2015 06:56:12 -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 UE2eghPXqyQa for ; Tue, 17 Feb 2015 06:56: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 C90821A8951 for ; Tue, 17 Feb 2015 06:56:10 -0800 (PST) Received: from localhost ([::1]:44671 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNjZG-0005MP-MG; Tue, 17 Feb 2015 06:56: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, rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 17 Feb 2015 14:56:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/60 Message-ID: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-Trac-Ticket-ID: 60 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, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #60 (rfc6962-bis): The number of redacted labels should be revealed in the Precertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:56:13 -0000 #60: The number of redacted labels should be revealed in the Precertificate The current -bis draft says: 'When creating a Precertificate, the CA MAY substitute one or more of the complete leftmost labels in each DNS-ID with the literal string "(PRIVATE)".' In a recent thread on the list there was clear support for the idea of requiring a separate token for each redacted label, instead of permitting one token to cover several redacted labels. Also, it would be nice to use a token that is shorter than "(PRIVATE)". Steve Kent has asked that we consult some DNS experts before we make a final decision on what the token will be. I'll kick off some discussion on that and report back to this ticket. For now, my proposal is "?". Quick comparison of how to redact 2 labels from "a.b.example.com": Current -bis draft: (PRIVATE).example.com This proposal: ?.?.example.com -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Feb 17 06:56: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 9FB021A8951 for ; Tue, 17 Feb 2015 06:56:50 -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 J5IB1m4QfpXg for ; Tue, 17 Feb 2015 06:56:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29CE31A1AB5 for ; Tue, 17 Feb 2015 06:56:49 -0800 (PST) Received: from localhost ([::1]:44690 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNjZw-0005QR-La; Tue, 17 Feb 2015 06:56:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, 17 Feb 2015 14:56:48 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/54#comment:4 Message-ID: <079.b5eca875b9f06d4a70d19cc3b3495604@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, 17 Feb 2015 14:56:50 -0000 #54: Simplify name redaction Changes (by rob.stradling@comodo.com): * status: new => closed * resolution: => invalid Comment: FWIW, the last line in that example should be ".top-secret.com" rather than "top-secret.com". I've discussed my comment:3 proposal with Ben and Eran. We've decided to not use it. We'll stick with the SEQUENCE OF INTEGERs extension in the current draft. So, since the idea of simplifying name redaction seems to have reached a dead end, I'm marking this ticket as INVALID. I've just created ticket #60 to salvage the idea of revealing the number of redacted labels. In a recent discussion on the list, there was clear support for this, albeit for security reasons rather than for simplification reasons. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: invalid Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Feb 17 06:57:09 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39881A89B5 for ; Tue, 17 Feb 2015 06:57:07 -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 xyh6paD07mSW for ; Tue, 17 Feb 2015 06:57: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 38CF91A8951 for ; Tue, 17 Feb 2015 06:57:05 -0800 (PST) Received: from localhost ([::1]:44704 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNjaD-0005SB-4E; Tue, 17 Feb 2015 06:57: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: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 17 Feb 2015 14:57:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/60#comment:1 Message-ID: <079.d37f6342f2b812ed3716157e7a05e7c3@tools.ietf.org> References: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <064.b47307e4e2d27d4e3760ec3de4410d3a@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] #60 (rfc6962-bis): The number of redacted labels should be revealed in the Precertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:57:08 -0000 #60: The number of redacted labels should be revealed in the Precertificate 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 Tue Feb 17 06:58:49 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627AC1A8A01 for ; Tue, 17 Feb 2015 06:58:48 -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 3-Yc6IJEBoLe for ; Tue, 17 Feb 2015 06:58:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1446F1A8A28 for ; Tue, 17 Feb 2015 06:57:59 -0800 (PST) Received: from localhost ([::1]:44742 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNjb4-0005XQ-W2; Tue, 17 Feb 2015 06:57:58 -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, 17 Feb 2015 14:57:58 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/60#comment:2 Message-ID: <079.6cedf64c94e0316b6284f03c6b2f40db@tools.ietf.org> References: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <064.b47307e4e2d27d4e3760ec3de4410d3a@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] #60 (rfc6962-bis): The number of redacted labels should be revealed in the Precertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:58:48 -0000 #60: The number of redacted labels should be revealed in the Precertificate Changes (by rob.stradling@comodo.com): * type: enhancement => defect -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Feb 17 07:10: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 839071A1B60 for ; Tue, 17 Feb 2015 07:10:34 -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 0qcCFy80_muu for ; Tue, 17 Feb 2015 07:10: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 641381A873A for ; Tue, 17 Feb 2015 07:10:29 -0800 (PST) Received: from localhost ([::1]:45146 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNjnA-0007sy-9R; Tue, 17 Feb 2015 07:10:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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: Tue, 17 Feb 2015 15:10:28 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/17#comment:7 Message-ID: <070.c9fa45c1ddca50b9ad85808ded05fcb0@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: Tue, 17 Feb 2015 15:10:34 -0000 #17: Add advice on CNs Changes (by rob.stradling@comodo.com): * status: new => assigned Comment: We'll use Ben's proposal from comment:2: "...we should allow a single CN, which, if present, uses the first entry in the redaction list." Let's require the Subject CN, if present, to match the first dNSName in the SAN extension, so that they can both use the first entry in the redaction list. -- -----------------------------+--------------------------------------- Reporter: benl@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Feb 17 07:11: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 1CC0A1A1B60 for ; Tue, 17 Feb 2015 07:11: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 ytA5AxBgtzGX for ; Tue, 17 Feb 2015 07:11: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 7012E1A873A for ; Tue, 17 Feb 2015 07:11:13 -0800 (PST) Received: from localhost ([::1]:45176 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNjnt-00084g-B4; Tue, 17 Feb 2015 07:11: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: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 17 Feb 2015 15:11:13 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/60#comment:3 Message-ID: <079.be7255cf521c6ce77e80f409a636bb54@tools.ietf.org> References: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <064.b47307e4e2d27d4e3760ec3de4410d3a@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] #60 (rfc6962-bis): The number of redacted labels should be revealed in the Precertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:11:15 -0000 #60: The number of redacted labels should be revealed in the Precertificate Changes (by rob.stradling@comodo.com): * status: new => assigned -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Feb 17 07:11:49 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7221A89D3 for ; Tue, 17 Feb 2015 07:11:48 -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 qtSpX0w3niYD for ; Tue, 17 Feb 2015 07:11:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18BF1A89B4 for ; Tue, 17 Feb 2015 07:11:46 -0800 (PST) Received: from localhost ([::1]:45184 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNjoQ-00086M-R4; Tue, 17 Feb 2015 07:11:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, 17 Feb 2015 15:11:46 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/56#comment:2 Message-ID: <079.6fdd4606d7f8120574e3baa77382a671@tools.ietf.org> References: <064.ad3ccf5068565e4491a4337770641dc9@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <064.ad3ccf5068565e4491a4337770641dc9@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] #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, 17 Feb 2015 15:11:48 -0000 #56: "*" domain labels MUST NOT be redacted Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Feb 17 07:21: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 CEBE81A89C5 for ; Tue, 17 Feb 2015 07:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfcLNyxjMkRC for ; Tue, 17 Feb 2015 07:21:37 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D761A8853 for ; Tue, 17 Feb 2015 07:21:37 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id c9so17547379qcz.1 for ; Tue, 17 Feb 2015 07:21:36 -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=u3qLjS1Dz5ZOsyyfv1E9jk7DVzaKi8FQGjJ8DpMQ4Zs=; b=bRWkX2M8gDoa4zOHFF1YWfqzUNkVJnQZ3RV2BLZa+zgE1VhRWftXbFmmwZqVv+OYCx zCqSAdzCZGmSLg6o894WsRQ+mDRRuZspe6CZVxDPnhi5C/X8WP9Q1FKG1C0T68LmGb9M /SQK2CZAN2SkSIwOhOCP6heUTVwM8qNaCY5mC0pDI7J1PjuPX9PCn8uDB3iWxvpDwy15 cDAqRhsrN+Qv8ujnGb5ct0rwRIfp2TVefvRPTCTNKY5Dwk2t5O9c2o4zuscxbX223xar N3vYuTOF38YoMqgfDZyljlQ9k0S4FIZfS/ITPucJFIwqmdYZunC08K4/i8i30YCPWlmh 8hcA== 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=u3qLjS1Dz5ZOsyyfv1E9jk7DVzaKi8FQGjJ8DpMQ4Zs=; b=Z7VbBPkoUvzInzFgoOgBx/etghonTmw8RLAEwG1ofQtFO/B3GhKB1+znhgDwdBs6wk WFc//DRD3LoA+q8F71reYVDMK76iAFZuHiZPEexJrmTngT4tH8E15jpLqCU7nC5uSg9+ 3GF7FERFBHKiaqsBcBruMSFElIUXWR7vigBVNgTZZKtDkKvgel5jszv0aeitxeUg6FQ6 sWNdgjEixtmeHBEtN3rJjBwxsAsLR8josE3XZ/gxXRFEbK2dKZJUgY4LuEFMkTFDX3wL hsMlGVakJ0xReTzBFEs9X3ehawLejuyNN84QH6hHy5gF18S5MeNOfhYx5ZAwJ65loJrZ JE6A== X-Gm-Message-State: ALoCoQkrXXwetzu9svI7CCjA+r5PTBY9k7baGU41nEYPjTaJ8Uv2wAFskdlrHbKbTdlDAv/EAGx9 MIME-Version: 1.0 X-Received: by 10.229.190.6 with SMTP id dg6mr43501qcb.16.1424186496770; Tue, 17 Feb 2015 07:21:36 -0800 (PST) Received: by 10.229.224.6 with HTTP; Tue, 17 Feb 2015 07:21:36 -0800 (PST) In-Reply-To: <54E27FA9.6020100@bbn.com> References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> Date: Tue, 17 Feb 2015 15:21:36 +0000 Message-ID: From: Ben Laurie To: Karen Seo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [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: Tue, 17 Feb 2015 15:21:39 -0000 On 16 February 2015 at 23:39, Karen Seo wrote: > Folks, > > I've found the discussion on the list and the analysis itself helpful in > clarifying and assessing the aims and mechanisms 6962-bis. It strikes me > that it would be similarly helpful to other users/readers of 6962-bis. What > does the group think of adding it to 6962-bis? As I indicated in my previous message, it needs some work before it could be added. However, I do think it is a useful starting point. From nobody Tue Feb 17 08:06: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 11E471A8AF4 for ; Tue, 17 Feb 2015 08:06: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 WDRVOLkloYCu for ; Tue, 17 Feb 2015 08:06: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 3BCD51A8AFB for ; Tue, 17 Feb 2015 08:04:05 -0800 (PST) Received: from localhost ([::1]:47712 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNkd1-00076y-O0; Tue, 17 Feb 2015 08:04:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, pzbowen@gmail.com X-Trac-Project: trans Date: Tue, 17 Feb 2015 16:04:03 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/60#comment:4 Message-ID: <079.a0c259e656cd4a263f7b2fa66448b751@tools.ietf.org> References: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, pzbowen@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #60 (rfc6962-bis): The number of redacted labels should be revealed in the Precertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:06:38 -0000 #60: The number of redacted labels should be revealed in the Precertificate Changes (by pzbowen@gmail.com): * cc: pzbowen@gmail.com (added) -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Feb 17 08:41: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 2C9111A8F33 for ; Tue, 17 Feb 2015 08:41:26 -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 RIDMYdw1fFLq for ; Tue, 17 Feb 2015 08:41:24 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01041A8BC1 for ; Tue, 17 Feb 2015 08:41:24 -0800 (PST) Received: from localhost ([::1]:49169 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YNlD8-0007vd-1x; Tue, 17 Feb 2015 08:41:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Tue, 17 Feb 2015 16:41:22 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/25#comment:1 Message-ID: <071.3ecfdadcbed3311bf8a06c3ed340633d@tools.ietf.org> References: <056.2c76a9b4be9ed599f5fa07beed720620@tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <056.2c76a9b4be9ed599f5fa07beed720620@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #25 (rfc6962-bis): Freezing a log's state 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, 17 Feb 2015 16:41:26 -0000 #25: Freezing a log's state Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/b750e18e45eed3405cb6c956d09a48b2ae48bb4f -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Feb 17 10:29: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 497CB1A1F01 for ; Tue, 17 Feb 2015 10:29:14 -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 ZVdMjAxa4Ht6 for ; Tue, 17 Feb 2015 10:29:12 -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 458251A8FD3 for ; Tue, 17 Feb 2015 10:29:12 -0800 (PST) Received: from dhcp89-089-186.bbn.com ([128.89.89.186]:54888) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YNmtN-000BAJ-W8; Tue, 17 Feb 2015 13:29:06 -0500 Message-ID: <54E38872.4080509@bbn.com> Date: Tue, 17 Feb 2015 13:29:06 -0500 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Santosh Chokhani References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "kseo@bbn.com" , "trans@ietf.org" Subject: Re: [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: Tue, 17 Feb 2015 18:29:14 -0000 Santosh, Thank you for the encouragement. Karen On 2/17/15 8:55 AM, Santosh Chokhani wrote: > Karen, > > This is a good idea. We need the threat analysis to document the assumptions under which the mechanisms are effective and what the residual vulnerabilities are. > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Karen Seo > Sent: Monday, February 16, 2015 6:39 PM > To: trans@ietf.org > Cc: kseo@bbn.com > Subject: Re: [Trans] updated attack analysis > > Folks, > > I've found the discussion on the list and the analysis itself helpful in clarifying and assessing the aims and mechanisms 6962-bis. It strikes me that it would be similarly helpful to other users/readers of 6962-bis. What does the group think of adding it to 6962-bis? > > Thank you, > Karen > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Tue Feb 17 10:50: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 262A21A907C for ; Tue, 17 Feb 2015 10:50:01 -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 0GR-xPz-rhyB for ; Tue, 17 Feb 2015 10:49:59 -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 869461A8F4A for ; Tue, 17 Feb 2015 10:49:59 -0800 (PST) Received: from dhcp89-089-186.bbn.com ([128.89.89.186]:54914) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YNnDa-000LNM-4d; Tue, 17 Feb 2015 13:49:58 -0500 Message-ID: <54E38D56.6090903@bbn.com> Date: Tue, 17 Feb 2015 13:49:58 -0500 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Laurie References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] updated 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: Tue, 17 Feb 2015 18:50:01 -0000 I see what you mean. Thank you. On 2/17/15 10:21 AM, Ben Laurie wrote: > On 16 February 2015 at 23:39, Karen Seo wrote: >> Folks, >> >> I've found the discussion on the list and the analysis itself helpful in >> clarifying and assessing the aims and mechanisms 6962-bis. It strikes me >> that it would be similarly helpful to other users/readers of 6962-bis. What >> does the group think of adding it to 6962-bis? > As I indicated in my previous message, it needs some work before it > could be added. However, I do think it is a useful starting point. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Tue Feb 17 11:05:05 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5E01A9078 for ; Tue, 17 Feb 2015 11:05:04 -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 og5XcCZnxG_h for ; Tue, 17 Feb 2015 11:05:03 -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 4342E1A9092 for ; Tue, 17 Feb 2015 11:04:38 -0800 (PST) Received: from dhcp89-089-186.bbn.com ([128.89.89.186]:54915) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YNnRl-000LUo-4y for trans@ietf.org; Tue, 17 Feb 2015 14:04:37 -0500 Message-ID: <54E390C5.5020404@bbn.com> Date: Tue, 17 Feb 2015 14:04:37 -0500 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: trans@ietf.org References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Tue, 17 Feb 2015 19:05:04 -0000 Folks, Sorry if my message implied that I thought the text was in its final form. I agree that there is not yet consensus on the text/topic and that further work is needed. However, if the working group agrees that the threat analysis should be added to 6962, then I believe it would be more expedient if the text were incorporated into 6962-bis sooner rather than later. Anyone who reviews 6962-bis will then likely review this text, increasing the number of eyes on it. And having the threat analysis in the draft will hopefully facilitate its use in ensuring that the document is consistent/correct/complete. Perhaps we could incorporate the next revision of the text with any remaining unresolved comments placed in the issue tracker? What do folks think? Karen From nobody Wed Feb 18 05:31:09 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7E81A8871 for ; Wed, 18 Feb 2015 05:31: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 q4kayWKsD5cO for ; Wed, 18 Feb 2015 05:31: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 0D6A11A8854 for ; Wed, 18 Feb 2015 05:31:06 -0800 (PST) Received: from localhost ([::1]:54435 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YO4iX-000590-RU; Wed, 18 Feb 2015 05:31: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: eranm@google.com, benl@google.com X-Trac-Project: trans Date: Wed, 18 Feb 2015 13:31:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/24#comment:4 Message-ID: <071.9689863501db89f59f0cb3bb9417bf4b@tools.ietf.org> References: <056.ec296f99c4f067c1c72c883b77925a17@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <056.ec296f99c4f067c1c72c883b77925a17@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #24 (rfc6962-bis): Add a section about log metadata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:31:08 -0000 #24: Add a section about log metadata Changes (by benl@google.com): * priority: major => minor * type: defect => enhancement Comment: Partially closed by https://github.com/google/certificate-transparency- rfcs/commit/b750e18e45eed3405cb6c956d09a48b2ae48bb4f. As I said at IETF 90 (transcript is incomplete), allowing a log to define its own metadata is obviously a security hole, so it is not clear to me what the value of defining an API for the metadata is. -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Wed Feb 18 05:33:45 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EF01A1AB0 for ; Wed, 18 Feb 2015 05:33:44 -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 fCS_jQnvEucg for ; Wed, 18 Feb 2015 05:33:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914071A8851 for ; Wed, 18 Feb 2015 05:33:42 -0800 (PST) Received: from localhost ([::1]:54617 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YO4l2-0006CM-Rt; Wed, 18 Feb 2015 05:33:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Wed, 18 Feb 2015 13:33:40 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/27#comment:1 Message-ID: <067.f30190f320766058bae09964b1f8c0d4@tools.ietf.org> References: <052.15b149c4fd4a0f0330230897b6e9dc89@tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <052.15b149c4fd4a0f0330230897b6e9dc89@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #27 (rfc6962-bis): Signature & hash alg specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:33:44 -0000 #27: Signature & hash alg specification Comment (by benl@google.com): We would be happy with EC signatures only, but we hear that some people are still concerned about IP. So, we have to provide an alternative for those people - RSA is considered safe, if slower and bigger, so that is what we propose. -- -------------------------+------------------------------------------------- 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: Active WG | Resolution: Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 18 05:34: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 1D4A71A049C for ; Wed, 18 Feb 2015 05:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3Bcadg8B2dG for ; Wed, 18 Feb 2015 05:34:24 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC8E1A1AB0 for ; Wed, 18 Feb 2015 05:34:24 -0800 (PST) Received: from localhost ([::1]:54642 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YO4lj-0006Fv-Cc; Wed, 18 Feb 2015 05:34:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Wed, 18 Feb 2015 13:34:23 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/27#comment:2 Message-ID: <067.a15c4e4282b66b755750b102584c1f30@tools.ietf.org> References: <052.15b149c4fd4a0f0330230897b6e9dc89@tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <052.15b149c4fd4a0f0330230897b6e9dc89@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #27 (rfc6962-bis): Signature & hash alg specification X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:34:27 -0000 #27: Signature & hash alg specification 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: major | Milestone: Component: rfc6962-bis | Version: Severity: Active WG | Resolution: fixed Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 18 06:17: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 47ACF1A8821 for ; Wed, 18 Feb 2015 06:17: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 qQmjqTf_A2o2 for ; Wed, 18 Feb 2015 06:17: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 42C5F1A87D7 for ; Wed, 18 Feb 2015 06:17:33 -0800 (PST) Received: from localhost ([::1]:57586 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YO5RS-0008KM-Np; Wed, 18 Feb 2015 06:17:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Wed, 18 Feb 2015 14:17:30 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/28#comment:1 Message-ID: <067.2098b8ac9feb0465ecdac13edd9ea16c@tools.ietf.org> References: <052.688c174331cffcc9bcf2c280f0e9ecce@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <052.688c174331cffcc9bcf2c280f0e9ecce@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #28 (rfc6962-bis): Algorithm agility X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:17:35 -0000 #28: Algorithm agility Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: I believe that cert algorithms are already specified by reference to the relevant RFCs, and whatever agility mechanisms those have. For the log algorithms, fixed in https://github.com/google/certificate- transparency-rfcs/commit/0c5b808345812946d8d36c692f0607b5262ca9a3. -- -------------------------+------------------------------------------------- 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: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 18 06:19: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 727F61A8797 for ; Wed, 18 Feb 2015 06:19:26 -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 TLBAg0KmBYLr for ; Wed, 18 Feb 2015 06:19:25 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1351F1A87F0 for ; Wed, 18 Feb 2015 06:19:21 -0800 (PST) Received: from localhost ([::1]:57699 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YO5TD-0007Dr-UR; Wed, 18 Feb 2015 06:19: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: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Wed, 18 Feb 2015 14:19:19 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/29#comment:1 Message-ID: <067.eaf3fc690f78a4ec85d8ae1a2e13c20e@tools.ietf.org> References: <052.eb380d6b597f084aec645136d4d2318a@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <052.eb380d6b597f084aec645136d4d2318a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #29 (rfc6962-bis): what does "immediately" mean? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:19:26 -0000 #29: what does "immediately" mean? Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Section 3 no longer says this. -- -------------------------+------------------------------------------------- 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: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 18 06:23: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 1E9E01A8932 for ; Wed, 18 Feb 2015 06:23:04 -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 mYIyvIcFT9RH for ; Wed, 18 Feb 2015 06:23:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B901A892C for ; Wed, 18 Feb 2015 06:23:02 -0800 (PST) Received: from localhost ([::1]:57912 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YO5Wm-00074u-9k; Wed, 18 Feb 2015 06:23:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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: Wed, 18 Feb 2015 14:23:00 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/32#comment:2 Message-ID: <067.be1b7efd0c1fdb3a169cb2a93fa28730@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, 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, eranm@google.com, rob.stradling@comodo.com Archived-At: 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: Wed, 18 Feb 2015 14:23:04 -0000 #32: algorithm needed for client checks of SCT Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: I believe this has been addressed by changes in sections 3 and 5. -- -------------------------+------------------------------------------------- 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: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Wed Feb 18 08:24:56 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014CB1A896D for ; Wed, 18 Feb 2015 08:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lD3ybc5IX-4 for ; Wed, 18 Feb 2015 08:24:53 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4431A89B4 for ; Wed, 18 Feb 2015 08:24:53 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id w7so1670760qcr.4 for ; Wed, 18 Feb 2015 08:24:52 -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=rSHjvhrV07T8i388aobsUIOk7eTdXacIcPHrAYRRTC8=; b=iuUcaaneSG9SxTpi9ouhEBkMihTasCTM5AVMFgtulItsGxZjsGwYu4ksAhQ7vk045j +/EKp5fXBDD/vGluG2OmjiYtgTVc2Fz2joXAUjmoxWFN9Dcp7CCcbvAgVuG6Et+sp/68 YVMPSTH2RTgdNSeN4uehtA4ozX5WVtnL7Mm2BdZi7HG+3KunCULNxfW/DLqPBh0xkYlo H3yEgevA75QB4Tp9zlxxKX2+N0eEbPppMqUjhHZ8e0v7kUPExRYAYvtXzqOEOkf06xPp qtvD5EDOTUbt2y6J7m1u4htnUbbhbWcXsqAD8vwua1KxLTYQsHCs8i9EdJ6AU641jCHy CI8g== 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=rSHjvhrV07T8i388aobsUIOk7eTdXacIcPHrAYRRTC8=; b=WwWK6d7NrF4BM69HKX+qa5tSnkn6gosMeYmWyDemF2EwNMMizgybfl1xkgevxHSz1B qc4z+r7jXQGdNFFjwVVdBz7oL6vuVnorv1mF2m/NIqiBU3ho36XFx5770G5gfKS8H0Hc 6gjEtR9JAHeYcUGi6a//1U+jEqD4wEUPHpmHe3ol4bd34OMKQfiX1/2CeY5On1rDCWFg /vYsv2FN0m/yTye2w8Frg1tVCPLyW8IFIN0BATk2RsGrrCIw3HQ+/G7PBz60PSYNmBBZ LmYOTBEZ071hP8TO2JsqjHaSyDWasM+0lOsvOVgYh70IdbQqqA0qBOWI/PwJkitEa8iY n0Iw== X-Gm-Message-State: ALoCoQkpXZOZYJoez8Xv2RQisPP3EzDKPuA7DLcLuo9AKPp1qPBrOiXdG+t21h8HVoUDBEUYh79G MIME-Version: 1.0 X-Received: by 10.140.131.9 with SMTP id 9mr1633717qhd.59.1424276692661; Wed, 18 Feb 2015 08:24:52 -0800 (PST) Received: by 10.229.224.6 with HTTP; Wed, 18 Feb 2015 08:24:52 -0800 (PST) In-Reply-To: <54E390C5.5020404@bbn.com> References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> <54E390C5.5020404@bbn.com> Date: Wed, 18 Feb 2015 16:24:52 +0000 Message-ID: From: Ben Laurie To: Karen Seo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [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: Wed, 18 Feb 2015 16:24:55 -0000 On 17 February 2015 at 19:04, Karen Seo wrote: > Folks, > > Sorry if my message implied that I thought the text was in its final form. I > agree that there is not yet consensus on the text/topic and that further > work is needed. However, if the working group agrees that the threat > analysis should be added to 6962, then I believe it would be more expedient > if the text were incorporated into 6962-bis sooner rather than later. > Anyone who reviews 6962-bis will then likely review this text, increasing > the number of eyes on it. And having the threat analysis in the draft will > hopefully facilitate its use in ensuring that the document is > consistent/correct/complete. Perhaps we could incorporate the next revision > of the text with any remaining unresolved comments placed in the issue > tracker? What do folks think? I would happily use it as a starting point for text in 6962-bis, but I would feel compelled to remove text that attempts to force issues which the WG has already decided to defer to later documents (such as the definition of a gossip protocol), or has decided it does not have jurisdiction over (such as client behaviour). From nobody Wed Feb 18 08:51: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 3F1DF1A1BD1 for ; Wed, 18 Feb 2015 08:51: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 HcDwNFuZm67F for ; Wed, 18 Feb 2015 08:50: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 13E6A1A8A43 for ; Wed, 18 Feb 2015 08:50:46 -0800 (PST) Received: from localhost ([::1]:38462 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YO7pj-0000tE-7g; Wed, 18 Feb 2015 08:50:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, pzbowen@gmail.com X-Trac-Project: trans Date: Wed, 18 Feb 2015 16:50:43 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/60#comment:5 Message-ID: <079.03a91a5c30beb1cf6b357336041f470d@tools.ietf.org> References: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <064.b47307e4e2d27d4e3760ec3de4410d3a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, pzbowen@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #60 (rfc6962-bis): The number of redacted labels should be revealed in the Precertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:51:02 -0000 #60: The number of redacted labels should be revealed in the Precertificate Comment (by rob.stradling@comodo.com): Committed as... https://github.com/google/certificate-transparency- rfcs/commit/82ee686fa39a4fc10b6bca05aca0aa3d6ca5afd3 Leaving this ticket open whilst we consult some DNS experts on "?". -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Feb 18 10:36:20 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CC41A0055 for ; Wed, 18 Feb 2015 10:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 thpyXvtDTpiS for ; Wed, 18 Feb 2015 10:36:17 -0800 (PST) Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE06C1A001B for ; Wed, 18 Feb 2015 10:36:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoEAAPb5FQKPDLY/2dsb2JhbABbg1haBMJQCoVxAoFiAQEBAQEBfIQMAQEBBAEBATc0CwwEAgEIDQQEAQEBHgkHJwsUCQgCBAENBQiILAjTBAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiw+EbgcGhCQFn2eDfogshBBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,603,1418101200"; d="scan'208";a="33819" Received: from unknown (HELO svaexch1.cygnacom.com) ([10.60.50.216]) by ipesa2.cygnacom.com with ESMTP; 18 Feb 2015 13:36:15 -0500 Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch1.cygnacom.com (10.60.50.216) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 18 Feb 2015 13:36:15 -0500 Received: from svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e]) by svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e%12]) with mapi id 15.00.0913.011; Wed, 18 Feb 2015 13:36:15 -0500 From: Santosh Chokhani To: Ben Laurie , Karen Seo Thread-Topic: [Trans] updated attack analysis Thread-Index: AQHQQUTJaBwtu5DVokCClHZ2IrRITpz0VNuAgAEHQwCAAD5PgIABZbMA///O1AA= Date: Wed, 18 Feb 2015 18:36:14 +0000 Message-ID: <51b33c7af9e24b629566d72e189e473a@svaexch1.cygnacom.com> References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> <54E390C5.5020404@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [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: Wed, 18 Feb 2015 18:36:19 -0000 Ben, The document at least should describe what the residual vulnerability is if= the client does not take appropriate/recommended action. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Wednesday, February 18, 2015 11:25 AM To: Karen Seo Cc: trans@ietf.org Subject: Re: [Trans] updated attack analysis On 17 February 2015 at 19:04, Karen Seo wrote: > Folks, > > Sorry if my message implied that I thought the text was in its final=20 > form. I agree that there is not yet consensus on the text/topic and=20 > that further work is needed. However, if the working group agrees that=20 > the threat analysis should be added to 6962, then I believe it would=20 > be more expedient if the text were incorporated into 6962-bis sooner rath= er than later. > Anyone who reviews 6962-bis will then likely review this text,=20 > increasing the number of eyes on it. And having the threat analysis=20 > in the draft will hopefully facilitate its use in ensuring that the=20 > document is consistent/correct/complete. Perhaps we could incorporate=20 > the next revision of the text with any remaining unresolved comments=20 > placed in the issue tracker? What do folks think? I would happily use it as a starting point for text in 6962-bis, but I woul= d feel compelled to remove text that attempts to force issues which the WG = has already decided to defer to later documents (such as the definition of = a gossip protocol), or has decided it does not have jurisdiction over (such= as client behaviour). _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Wed Feb 18 10:50: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 6954E1A0055 for ; Wed, 18 Feb 2015 10:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp3SrXCzp6ln for ; Wed, 18 Feb 2015 10:50:21 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C961A0046 for ; Wed, 18 Feb 2015 10:50:21 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id a108so2489309qge.7 for ; Wed, 18 Feb 2015 10:50:20 -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:content-transfer-encoding; bh=8iPuUasZ/7+9c68HMLK6S88bN8hSUWmzkOLhw1iK7Bo=; b=cOAJQR9gTMrhzw0xy4Jvq//dUtu2Xqp3vhF4nlbursxr+pkhEmuPym5CLUz+7eI2ik W6t4HFQJxcmdGQc5Mnosrh6nI/D91ErYJ30j0carK/XmYdeqEBUJ3xrvN9vFESblRBW9 mDxKB8t2LEq8k0+jg0ky6TBow6QGelPG9iJyAZmHQvq2Gi4uB0Wzhx9eh4BScpwlhI/L eOPS5NJQkIoUaw2uj964FZDrd8Fxmi0cJZM+a8FEfZ1kmahYqRzwg/qvbay7Zmirvg69 YK837YuJbySWCZOgMRLtTdgJh/s63Rfgy4qIzULqQD0hZj01jBUOblWV/zmdsoeSOkq1 0JNQ== 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 :content-transfer-encoding; bh=8iPuUasZ/7+9c68HMLK6S88bN8hSUWmzkOLhw1iK7Bo=; b=EWn82bgRcwF9MXcB5RZj8P9s0Fey8WkOYjhavnmw6lnLxr24MtIeRsfqPTWq4H5k5o TjNqyqSAIzoa9ZHhFPdwG/DEMS63Yeb0Jv5w6YnHSG2oJRkGA7VVofxAXDs0d8Hqx8xT OdISkOC5iqpg45WihxJeX3SFVNQojCcTJHfLpzW/Kb6rB0VcEi5+2DXQeohYvodZtB4I 0LHSEb6cDOqxhRvjyYG4Z9VYAQYbMnuWmSSBJdQcbD09+45EIpK0VJHPjYP+inS/HPpu 3v+kH5EtQ75gbvvAyU0vxsb3qOXdGrUH66TVD9cpzGb0up2NtEGeD6CkTWucC1x2g0zB HmuA== X-Gm-Message-State: ALoCoQnpMvpMeZlAyxmdIpJPQOVcGFcIIZB4l/i4lZMfPyDlE1DvhmrySRIpJhcCZw4BEBNZ50s2 MIME-Version: 1.0 X-Received: by 10.140.92.33 with SMTP id a30mr3091284qge.30.1424285419908; Wed, 18 Feb 2015 10:50:19 -0800 (PST) Received: by 10.229.224.6 with HTTP; Wed, 18 Feb 2015 10:50:19 -0800 (PST) In-Reply-To: <51b33c7af9e24b629566d72e189e473a@svaexch1.cygnacom.com> References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> <54E390C5.5020404@bbn.com> <51b33c7af9e24b629566d72e189e473a@svaexch1.cygnacom.com> Date: Wed, 18 Feb 2015 18:50:19 +0000 Message-ID: From: Ben Laurie To: Santosh Chokhani Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Karen Seo , "trans@ietf.org" Subject: Re: [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: Wed, 18 Feb 2015 18:50:23 -0000 On 18 February 2015 at 18:36, Santosh Chokhani wro= te: > Ben, > > The document at least should describe what the residual vulnerability is = if the client does not take appropriate/recommended action. I agree, and that is what I suggested in my response... > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie > Sent: Wednesday, February 18, 2015 11:25 AM > To: Karen Seo > Cc: trans@ietf.org > Subject: Re: [Trans] updated attack analysis > > On 17 February 2015 at 19:04, Karen Seo wrote: >> Folks, >> >> Sorry if my message implied that I thought the text was in its final >> form. I agree that there is not yet consensus on the text/topic and >> that further work is needed. However, if the working group agrees that >> the threat analysis should be added to 6962, then I believe it would >> be more expedient if the text were incorporated into 6962-bis sooner rat= her than later. >> Anyone who reviews 6962-bis will then likely review this text, >> increasing the number of eyes on it. And having the threat analysis >> in the draft will hopefully facilitate its use in ensuring that the >> document is consistent/correct/complete. Perhaps we could incorporate >> the next revision of the text with any remaining unresolved comments >> placed in the issue tracker? What do folks think? > > I would happily use it as a starting point for text in 6962-bis, but I wo= uld feel compelled to remove text that attempts to force issues which the W= G has already decided to defer to later documents (such as the definition o= f a gossip protocol), or has decided it does not have jurisdiction over (su= ch as client behaviour). > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Wed Feb 18 13:09: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 99CC91A1B38 for ; Wed, 18 Feb 2015 13:09:04 -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_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAhYmkqCcQkp for ; Wed, 18 Feb 2015 13:09:01 -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 BC0C31A1B14 for ; Wed, 18 Feb 2015 13:07:14 -0800 (PST) Received: (qmail 29175 invoked by uid 1004); 18 Feb 2015 21:07:12 -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, 18 Feb 2015 21:07:12 +0000 Received: (qmail 24376 invoked by uid 1000); 18 Feb 2015 21:07:12 -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, 18 Feb 2015 21:07:12 +0000 Message-ID: <54E4FEFF.7030100@comodo.com> Date: Wed, 18 Feb 2015 21:07:11 +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: Ben Laurie , Santosh Chokhani References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> <54E390C5.5020404@bbn.com> <51b33c7af9e24b629566d72e189e473a@svaexch1.cygnacom.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Karen Seo , "trans@ietf.org" Subject: Re: [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: Wed, 18 Feb 2015 21:09:04 -0000 On 18/02/15 18:50, Ben Laurie wrote: > On 18 February 2015 at 18:36, Santosh Chokhani wrote: >> Ben, >> >> The document at least should describe what the residual vulnerability is if the client does not take appropriate/recommended action. > > I agree, and that is what I suggested in my response... That sounds like this ticket... http://trac.tools.ietf.org/wg/trans/trac/ticket/55 >> -----Original Message----- >> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie >> Sent: Wednesday, February 18, 2015 11:25 AM >> To: Karen Seo >> Cc: trans@ietf.org >> Subject: Re: [Trans] updated attack analysis >> >> On 17 February 2015 at 19:04, Karen Seo wrote: >>> Folks, >>> >>> Sorry if my message implied that I thought the text was in its final >>> form. I agree that there is not yet consensus on the text/topic and >>> that further work is needed. However, if the working group agrees that >>> the threat analysis should be added to 6962, then I believe it would >>> be more expedient if the text were incorporated into 6962-bis sooner rather than later. >>> Anyone who reviews 6962-bis will then likely review this text, >>> increasing the number of eyes on it. And having the threat analysis >>> in the draft will hopefully facilitate its use in ensuring that the >>> document is consistent/correct/complete. Perhaps we could incorporate >>> the next revision of the text with any remaining unresolved comments >>> placed in the issue tracker? What do folks think? >> >> I would happily use it as a starting point for text in 6962-bis, but I would feel compelled to remove text that attempts to force issues which the WG has already decided to defer to later documents (such as the definition of a gossip protocol), or has decided it does not have jurisdiction over (such as client behaviour). >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Thu Feb 19 05:04: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 30D051A8A90 for ; Thu, 19 Feb 2015 05:04:44 -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 BKVh7VCOmgMF for ; Thu, 19 Feb 2015 05:04:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962661A8A1D for ; Thu, 19 Feb 2015 05:04:42 -0800 (PST) Received: from localhost ([::1]:49455 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOQmU-0006xq-VN; Thu, 19 Feb 2015 05:04: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: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Thu, 19 Feb 2015 13:04:38 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/33#comment:1 Message-ID: <067.4babe667b822b0ddf0a0566dcc7930ae@tools.ietf.org> References: <052.293f8f314ea921d6ec0e7385a9422a2b@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <052.293f8f314ea921d6ec0e7385a9422a2b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #33 (rfc6962-bis): Cert chain length as log metadata X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:04:44 -0000 #33: Cert chain length as log metadata Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/c183b63d1c48841733707f1950b640098e2dfa19. The chain length was already a SHOULD. -- -------------------------+------------------------------------------------- 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: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Feb 20 03:27:21 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1D91A6FCB for ; Fri, 20 Feb 2015 03:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN52qnemugRW for ; Fri, 20 Feb 2015 03:27:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBBB1A6F2E for ; Fri, 20 Feb 2015 03:27:18 -0800 (PST) Received: from localhost ([::1]:45455 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOljq-0003DJ-6e; Fri, 20 Feb 2015 03:27: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: rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 20 Feb 2015 11:27:18 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/56#comment:3 Message-ID: <079.7b52a1de4867e25b01b3658c096ba171@tools.ietf.org> References: <064.ad3ccf5068565e4491a4337770641dc9@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <064.ad3ccf5068565e4491a4337770641dc9@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] #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: Fri, 20 Feb 2015 11:27:20 -0000 #56: "*" domain labels MUST NOT be redacted Changes (by rob.stradling@comodo.com): * status: assigned => closed * resolution: => fixed Comment: Committed as... https://github.com/google/certificate-transparency- rfcs/commit/49de5eb87e1e6d29e50c418c00654a79a950522d -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Feb 20 03:31: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 E28321A8857 for ; Fri, 20 Feb 2015 03:31:40 -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 iGGvJxnw0e7Q for ; Fri, 20 Feb 2015 03:31:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC6D1A6FCB for ; Fri, 20 Feb 2015 03:30:51 -0800 (PST) Received: from localhost ([::1]:45564 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOlnF-0008Vw-Tx; Fri, 20 Feb 2015 03:30:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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: Fri, 20 Feb 2015 11:30:49 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/17#comment:8 Message-ID: <070.47c08651d59b791b17503c405e42f0f4@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: Fri, 20 Feb 2015 11:31:41 -0000 #17: Add advice on CNs Changes (by rob.stradling@comodo.com): * status: assigned => closed * resolution: => fixed Comment: Committed as... https://github.com/google/certificate-transparency- rfcs/commit/49de5eb87e1e6d29e50c418c00654a79a950522d -- -----------------------------+--------------------------------------- Reporter: benl@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 Fri Feb 20 04:33: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 E7DF81A007A for ; Fri, 20 Feb 2015 04:33: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 4ho_Gx-Ykjpx for ; Fri, 20 Feb 2015 04:33: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 89BF91A1A2E for ; Fri, 20 Feb 2015 04:33:38 -0800 (PST) Received: from localhost ([::1]:49637 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOmlx-0002Gm-KB; Fri, 20 Feb 2015 04:33:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Fri, 20 Feb 2015 12:33:33 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/39#comment:3 Message-ID: <067.184ff8ae6c443fd5abac71898f23b7a9@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #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: Fri, 20 Feb 2015 12:33:40 -0000 #39: Monitor behavior Changes (by benl@google.com): * status: new => closed * resolution: => wontfix Comment: As agreed, we are not specifying client behaviour. -- -----------------------------+---------------------- Reporter: kent@bbn.com | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: wontfix Keywords: | -----------------------------+---------------------- Ticket URL: trans From nobody Fri Feb 20 07:23:37 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5DA1A87E9 for ; Fri, 20 Feb 2015 07:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIM2n_hGkXgX for ; Fri, 20 Feb 2015 07:23: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 DBC431A879E for ; Fri, 20 Feb 2015 07:16:39 -0800 (PST) Received: from localhost ([::1]:59376 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOpJl-00071a-Oa; Fri, 20 Feb 2015 07:16:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Fri, 20 Feb 2015 15:16:37 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/39#comment:4 Message-ID: <067.1e5703a96b15d8e45381f526896ccf16@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #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: Fri, 20 Feb 2015 15:23:36 -0000 #39: Monitor behavior Changes (by benl@google.com): * status: closed => reopened * resolution: wontfix => Comment: Re-opened in case anyone wants to write a client behaviour doc. -- -----------------------------+----------------------- Reporter: kent@bbn.com | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -----------------------------+----------------------- Ticket URL: trans From nobody Fri Feb 20 07:24: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 4BF721A1B13 for ; Fri, 20 Feb 2015 07:24:24 -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 mlPASwad_mOd for ; Fri, 20 Feb 2015 07:24: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 499F71A882A for ; Fri, 20 Feb 2015 07:18:59 -0800 (PST) Received: from localhost ([::1]:59718 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOpM3-0007WL-59; Fri, 20 Feb 2015 07:18:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: eranm@google.com, benl@google.com X-Trac-Project: trans Date: Fri, 20 Feb 2015 15:18:59 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/31#comment:4 Message-ID: <067.7ba4ab8bf7190b926ba412e6e5f4c0e6@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, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #31 (client-behavior): 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: Fri, 20 Feb 2015 15:24:24 -0000 #31: incremental deployment and client behavior Changes (by benl@google.com): * component: rfc6962-bis => client-behavior -- -----------------------------+------------------------------- Reporter: kent@bbn.com | Owner: eranm@google.com Type: defect | Status: new Priority: critical | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------- Ticket URL: trans From nobody Fri Feb 20 07:39: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 D8F351A8547 for ; Fri, 20 Feb 2015 07:39: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 dKuTmh3sC2YI for ; Fri, 20 Feb 2015 07:39: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 C3D7B1A8033 for ; Fri, 20 Feb 2015 07:39:22 -0800 (PST) Received: from localhost ([::1]:60764 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YOpfk-0001rL-T5; Fri, 20 Feb 2015 07:39:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, benl@google.com X-Trac-Project: trans Date: Fri, 20 Feb 2015 15:39:20 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/34#comment:2 Message-ID: <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> References: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, eranm@google.com, rob.stradling@comodo.com Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:39:31 -0000 #34: use of RFC 5246 syntax to define the SCT Changes (by benl@google.com): * status: new => closed * resolution: => wontfix Comment: TLS extensions are defined using RFC 5246 format, so clearly it is correct to use that format for the TLS extension. There is no compelling reason to have multiple SCT formats, and good reasons to not do so (complexity, extra signing overhead). So, closing this ticket without changing the format. -- -------------------------+------------------------------------------------- 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 Fri Feb 20 17:02: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 0C6801A06FD for ; Fri, 20 Feb 2015 17:02:19 -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 VV78ER6wUyoq for ; Fri, 20 Feb 2015 17:02:16 -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 9ED1F1A0687 for ; Fri, 20 Feb 2015 17:02:16 -0800 (PST) Received: from dhcp89-089-186.bbn.com ([128.89.89.186]:54471) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YOySV-0000sm-B9 for trans@ietf.org; Fri, 20 Feb 2015 20:02:15 -0500 Message-ID: <54E7D919.5050809@bbn.com> Date: Fri, 20 Feb 2015 20:02:17 -0500 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: trans@ietf.org References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> <54E390C5.5020404@bbn.com> <51b33c7af9e24b629566d72e189e473a@svaexch1.cygnacom.com> <54E4FEFF.7030100@comodo.com> In-Reply-To: <54E4FEFF.7030100@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Sat, 21 Feb 2015 01:02:19 -0000 Thanks, Rob. Ben, Rob, Santosh, I think we're in agreement but just in case.... I agree with Santosh and would like to extend that principle. I think that to ensure that it's clear to the readers/users of this technology what vulnerabilities it covers and what it doesn't, the document needs to include the entire attack/threat taxonomy. Re: your concern about including topics/mitigations that the WG has agreed are out of scope, all attacks should be included but the document should describe the WG consensus on what mitigation is provided (or is not) by 6962, and what the residual vulnerabilities are. In the case of client behavior, if the WG decides (as described in Ticket 55) to specify but not mandate checks that a client could do, then the relevant section of the analysis would state this and indicate the residual vulnerabilities. I admit I'm not sure what would then be put into the Security Considerations section, perhaps a brief summary and pointers to the relevant sections of the attack analysis. Per BCP 72, the Security Considerations Section MUST describe which attacks are out of scope (and why), which attacks are in-scope, etc. Karen On 2/18/15 4:07 PM, Rob Stradling wrote: > On 18/02/15 18:50, Ben Laurie wrote: >> On 18 February 2015 at 18:36, Santosh Chokhani >> wrote: >>> Ben, >>> >>> The document at least should describe what the residual >>> vulnerability is if the client does not take appropriate/recommended >>> action. >> >> I agree, and that is what I suggested in my response... > > That sounds like this ticket... > > http://trac.tools.ietf.org/wg/trans/trac/ticket/55 > >>> -----Original Message----- >>> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie >>> Sent: Wednesday, February 18, 2015 11:25 AM >>> To: Karen Seo >>> Cc: trans@ietf.org >>> Subject: Re: [Trans] updated attack analysis >>> >>> On 17 February 2015 at 19:04, Karen Seo wrote: >>>> Folks, >>>> >>>> Sorry if my message implied that I thought the text was in its final >>>> form. I agree that there is not yet consensus on the text/topic and >>>> that further work is needed. However, if the working group agrees that >>>> the threat analysis should be added to 6962, then I believe it would >>>> be more expedient if the text were incorporated into 6962-bis >>>> sooner rather than later. >>>> Anyone who reviews 6962-bis will then likely review this text, >>>> increasing the number of eyes on it. And having the threat analysis >>>> in the draft will hopefully facilitate its use in ensuring that the >>>> document is consistent/correct/complete. Perhaps we could incorporate >>>> the next revision of the text with any remaining unresolved comments >>>> placed in the issue tracker? What do folks think? >>> >>> I would happily use it as a starting point for text in 6962-bis, but >>> I would feel compelled to remove text that attempts to force issues >>> which the WG has already decided to defer to later documents (such >>> as the definition of a gossip protocol), or has decided it does not >>> have jurisdiction over (such as client behaviour). >>> >>> _______________________________________________ >>> 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 Wed Feb 25 08:04: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 E5D6E1A90E5 for ; Wed, 25 Feb 2015 08:04:51 -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 SF3Qle6LAz9C for ; Wed, 25 Feb 2015 08:04:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6687E1A9116 for ; Wed, 25 Feb 2015 08:04:46 -0800 (PST) Received: from localhost ([::1]:35257 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YQeS2-0005SE-JW; Wed, 25 Feb 2015 08:04:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com X-Trac-Project: trans Date: Wed, 25 Feb 2015 16:04:42 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/36#comment:1 Message-ID: <067.eb2008a562558cdd90c8432b90e7d186@tools.ietf.org> References: <052.952e8d9e8b6f052fa8ba26510c96117f@tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <052.952e8d9e8b6f052fa8ba26510c96117f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #36 (rfc6962-bis): error indications for log/client exchanges X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 16:04:52 -0000 #36: error indications for log/client exchanges Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Closed by https://github.com/google/certificate-transparency- rfcs/commit/3ea4baf931c2b479340ab5916267949fc864c4c1. -- -------------------------+------------------------------------------------- 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: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Feb 26 12:37: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 5B7041A1B6B for ; Thu, 26 Feb 2015 12:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBFqG8nyJqOc for ; Thu, 26 Feb 2015 12:37:06 -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 8B41C1A875D for ; Thu, 26 Feb 2015 12:37:06 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:37955 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YR5BA-000K0a-PF; Thu, 26 Feb 2015 15:37:04 -0500 Message-ID: <54EF83F0.60802@bbn.com> Date: Thu, 26 Feb 2015 15:37:04 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.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: 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: Thu, 26 Feb 2015 20:37:08 -0000 Ben, > > My thinking is that: > > 1. There is concern, generally, about the size of certificates (really > about the size of handshakes). That concern varies a lot, depending on context. I don't agree that this is a universal, major concern. Look at JSON; it's use of XML encoding suggests no concern about bloat in a web context. > > 2. Embedding SCTs in certs leads to more bloat than either OCSP > stapling or the TLS extension because the SCTs cannot be updated, and > so more are required (see Chrome's EV/CT policy). I am not familiar with Chrome's EV/CT policy, and I think you argued that what Google has chosen to do is out of scope, in the context of a prior argument in TRANS. Anyway, absent a spec for TLS client behavior, one cannot discuss the need to update SCTs, right? > 3. Embedding SCTs in certs runs the risk that the SCTs will become > invalid before the cert does. until we have a precise description of how a client will deal with an invalid SCT, we can't really evaluate the implications of this potential mismatch. Also, what causes an SCT to become invalid?. > 4. Certs are not generally updated before expiry. agreed. > 5. Stapled OCSP requires the CA, the webserver and the CT logs to be > actively involved. agreed. which gets back to my question from several months ago as to why we have 3 ways of signalling SCT info. > 6. The TLS extension only requires the webserver and the CT logs to be > actively involved. agreed, if the web serer operator submits the cert to the log. > 7. All three mechanisms can be made essentially automatic from the > webservers POV. This point, in conjunction with #5, sounds like you're trying to have it both ways :-). Lots of things can be made automatic, with the right support software. In the IETF we often try (though we do not always succeed) to limit the number of mandatory to support ways to do the same thing. That's why I questioned the specification of OCSP delivery of SCT data, plus pre-certs plus TLS handshake delivery. > So, I would expect in the long run that the TLS extension would be the > favoured option. Maybe. But, as I noted, if CAs have already gone to the trouble of embedding SCT data in certs, and if this is free for web site operators, there seems to be more inertia than motivation to change, from the perspective of operators. Steve From nobody Thu Feb 26 12:37:20 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1B1A8766 for ; Thu, 26 Feb 2015 12:37:19 -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 iFD1mPJ7L9Jw for ; Thu, 26 Feb 2015 12:37:18 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E2E1A70FE for ; Thu, 26 Feb 2015 12:37:18 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:57780 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YR5BN-0003Aw-Mz; Thu, 26 Feb 2015 15:37:17 -0500 Message-ID: <54EF83FD.7070803@bbn.com> Date: Thu, 26 Feb 2015 15:37:17 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ben Laurie References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> <54AAB0F8.6010707@bbn.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] 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: Thu, 26 Feb 2015 20:37:19 -0000 Ben, > My argument is that over time servers will deal with SCTs > automatically and CAs will stop including SCTs (at least optionally) > as a result. I understand your assertion, but I don't feel that you have made a strong case for why this specific path will become the norm. From nobody Thu Feb 26 12: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 38F971A8763 for ; Thu, 26 Feb 2015 12:37:29 -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 V9EInxl0cAd1 for ; Thu, 26 Feb 2015 12:37:28 -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 796D11A1B6B for ; Thu, 26 Feb 2015 12:37:26 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:37958 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YR5BT-000K10-Es for trans@ietf.org; Thu, 26 Feb 2015 15:37:23 -0500 Message-ID: <54EF8403.90307@bbn.com> Date: Thu, 26 Feb 2015 15:37:23 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> In-Reply-To: <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> Content-Type: multipart/alternative; boundary="------------040906070402040207020503" Archived-At: Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT 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, 26 Feb 2015 20:37:29 -0000 This is a multi-part message in MIME format. --------------040906070402040207020503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I disagree with this proposed resolution of the issue. RFC 5246 says of the syntax: ... The following very basic and somewhat casually defined presentation syntax will be used. The syntax draws from several sources in its structure. Although it resembles the programming language "C" in its syntax and XDR [XDR] in both its syntax and intent, it would be risky to draw too many parallels. *The** ** purpose of this presentation language is to document TLS only; it has** ** no general application beyond that particular goal.* Thus use of this syntax in an X.509 cert extension is contrary to the spirit of 5246. Steve > #34: use of RFC 5246 syntax to define the SCT > > Changes (bybenl@google.com): > > * status: new => closed > * resolution: => wontfix > > > Comment: > > TLS extensions are defined using RFC 5246 format, so clearly it is correct > to use that format for the TLS extension. > > There is no compelling reason to have multiple SCT formats, and good > reasons to not do so (complexity, extra signing overhead). > > So, closing this ticket without changing the format. > --------------040906070402040207020503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I disagree with this proposed resolution of the issue.

RFC 5246 says of the syntax:

   ...  The following very basic and somewhat casually
   defined presentation syntax will be used.  The syntax draws from
   several sources in its structure.  Although it resembles the
   programming language "C" in its syntax and XDR [XDR] in both its
   syntax and intent, it would be risky to draw too many parallels.  The
   purpose of this presentation language is to document TLS only; it has
   no general application beyond that particular goal.

Thus use of this syntax in an X.509 cert extension is contrary to the spirit of 5246.

Steve
#34: use of RFC 5246 syntax to define the SCT

Changes (by benl@google.com):

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


Comment:

 TLS extensions are defined using RFC 5246 format, so clearly it is correct
 to use that format for the TLS extension.

 There is no compelling reason to have multiple SCT formats, and good
 reasons to not do so (complexity, extra signing overhead).

 So, closing this ticket without changing the format.

--------------040906070402040207020503-- From nobody Thu Feb 26 12:37: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 67C711A872A for ; Thu, 26 Feb 2015 12:37:38 -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 0Kzi0MS0P3qS for ; Thu, 26 Feb 2015 12:37:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0A61A1B6B for ; Thu, 26 Feb 2015 12:37:36 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:37959 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YR5Bf-000K1K-Rz for trans@ietf.org; Thu, 26 Feb 2015 15:37:35 -0500 Message-ID: <54EF840F.70501@bbn.com> Date: Thu, 26 Feb 2015 15:37:35 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.688c174331cffcc9bcf2c280f0e9ecce@tools.ietf.org> <067.2098b8ac9feb0465ecdac13edd9ea16c@tools.ietf.org> In-Reply-To: <067.2098b8ac9feb0465ecdac13edd9ea16c@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #28 (rfc6962-bis): Algorithm agility 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, 26 Feb 2015 20:37:38 -0000 I disagree with the explanation provided below. referencing an RFC that defines an alg does not satisfy the need to specify how a system like CT transitions to using a new alg, signaling the transition to all affected parties, etc. > #28: Algorithm agility > > Changes (bybenl@google.com): > > * status: new => closed > * resolution: => fixed > > > Comment: > > I believe that cert algorithms are already specified by reference to the > relevant RFCs, and whatever agility mechanisms those have. > > For the log algorithms, fixed inhttps://github.com/google/certificate- > transparency-rfcs/commit/0c5b808345812946d8d36c692f0607b5262ca9a3. > From nobody Thu Feb 26 12:41:20 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1FB1A8758 for ; Thu, 26 Feb 2015 12:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0DMIkyZFrMu for ; Thu, 26 Feb 2015 12:41:17 -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 9AAC01A039B for ; Thu, 26 Feb 2015 12:41:17 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:37975 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YR5FE-000K60-Ma for trans@ietf.org; Thu, 26 Feb 2015 15:41:16 -0500 Message-ID: <54EF84EC.20101@bbn.com> Date: Thu, 26 Feb 2015 15:41:16 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <54C129CF.3020800@bbn.com> <54E27FA9.6020100@bbn.com> <54E390C5.5020404@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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, 26 Feb 2015 20:41:20 -0000 Ben, > On 17 February 2015 at 19:04, Karen Seo wrote: >> Folks, >> >> Sorry if my message implied that I thought the text was in its final form. I >> agree that there is not yet consensus on the text/topic and that further >> work is needed. However, if the working group agrees that the threat >> analysis should be added to 6962, then I believe it would be more expedient >> if the text were incorporated into 6962-bis sooner rather than later. >> Anyone who reviews 6962-bis will then likely review this text, increasing >> the number of eyes on it. And having the threat analysis in the draft will >> hopefully facilitate its use in ensuring that the document is >> consistent/correct/complete. Perhaps we could incorporate the next revision >> of the text with any remaining unresolved comments placed in the issue >> tracker? What do folks think? > I would happily use it as a starting point for text in 6962-bis, but I > would feel compelled to remove text that attempts to force issues > which the WG has already decided to defer to later documents (such as > the definition of a gossip protocol), or has decided it does not have > jurisdiction over (such as client behaviour) The WG can elect to move a discussion of client behavior and gossip protocols into separate docs. That's a good approach to keeping each do a reasonable size. But, a security analysis of CT needs to provide a taxonomy of attacks, explore the implications of failures or compromises of different system elements, and describe residual vulnerabilities based on what is and is not mandated by the specs. Thus, by deferring specs for other elements of the system, the analysis will, of necessity, identify more residual vulnerabilities. Steve From nobody Thu Feb 26 12:41: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 3D5281A8774 for ; Thu, 26 Feb 2015 12:41:31 -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 l9YqAYgJNI9n for ; Thu, 26 Feb 2015 12:41:23 -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 9923D1A8766 for ; Thu, 26 Feb 2015 12:41:23 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:37976 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YR5FK-000K66-AY for trans@ietf.org; Thu, 26 Feb 2015 15:41:22 -0500 Message-ID: <54EF84F2.5000603@bbn.com> Date: Thu, 26 Feb 2015 15:41:22 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <54C129CF.3020800@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050105050104080308020808" Archived-At: Subject: Re: [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, 26 Feb 2015 20:41:31 -0000 This is a multi-part message in MIME format. --------------050105050104080308020808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ben, Thanks for the feedback on my attack analysis text. I will make some changes based on your comments. > *XX*.1 Non-malicious Web PKI CA context > > > > Note that there's nothing special about the log here: anyone can > detect syntactic mis-issuance by simply feeding the certificate to an > appropriate tool. I agree. But, if a log elects to offer this service, the results of the check visible to all clients (e.g., TLS and Monitors) and that has two useful benefits. Also, even if a log does not perform a syntax check, the fact that a submitter asserted the type of cert being logged is useful to TLS clients, and maybe to Monitors and the Audit function. > > The lack of a requirement for rejection does not mean that popular TLS > clients will not reject. As you know, Chrome will shortly stop showing > EV indicators for EV certs without valid SCTs, even though there is no > requirement to do so. > > It seems to me a more accurate analysis would be along the lines of: > > _"If TLS clients do not reject certificates or otherwise notify users > 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.)." I agree with your suggested text change. > > *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.) > ibid. > > 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._ > > > Again, lack of requirement does not imply lack of implementation. > Again, I would suggest this should be phrased conditionally. In the context of a standard, one OUGHT NOT (as per 6919) rely on client behavior that is not mandated. I could re-phrase this, but there is a bigger issue lurking here. If mandated client behavior is out of scope for 6269-bis, i.e., if the doc focuses only on the operation of logs, then I believe the doc cannot be evaluated (and thus approved by the WG) until ancillary docs specifying client behavior have been completed. My argument is that we don't know if the spec for log operation is complete and correct until we know what log clients will do based on interactions with a log, processing of SCTs, etc. > > __ > > 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. > > > Not sure of the relevance of "non-conspiring" here? If logs conspire with a CA, they may not report a log entry for a bogus cert to an affected subject. > > _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. > > > Again, the log has no special role to play in the detection of > syntactic errors: TLS clients that wish to reject such certificates > can do so unaided. Indeed, I would've thought conformance to existing > RFCs would imply such behaviour - and if they don't, surely CT is not > the place to fix that? I noted above why syntax checking by logs is beneficial. Experience shows that a number of TLS clients have been very bad about checking certs relative to existing RFCs, so having such checks offered by logs is beneficial for that reason too. CT is supposed to create an infrastructure that helps detect/deter issuance of "mis-issued" certs? Syntactically broken certs are mis-issued, relative to a specified cert profile, whether that DV, EV, S/MIME, or whatever. > *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.)_ > > > See above (both on requirements and on CT's role in syntax). see my (distinct) replies to you comments above. > > *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. > > > Why would they believe that, given there's no requirement to do such > verification? Since there appear to be NO TLS client requirements today :-). As I mentioned earlier, until we have a complete set of specs for client behavior, TLS clients and Monitors, we can't have high confidence that the CT log spec is right. > > > ***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.)_ > > > See above. I'll change this to be consistent with the text change you noted earlier. > > 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. > > > It is Google's view that pinning is not a scalable solution, unlike > CT. We do not agree that pinning reduces the need for CT. Well, some part of Google obviously believes pinning is a useful solution, since all three editors for the pinning spec are from Google :-). More to the point, we're developing an IETF RFC; Google's "view" is just one input. Thus your very terse reply is not a basis for failing to address this obvious issue. Steve --------------050105050104080308020808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ben,

Thanks for the feedback on my attack analysis text. I will make some changes based on
your comments.


 XX.1 Non-malicious Web PKI CA context



Note that there's nothing special about the log here: anyone can detect syntactic mis-issuance by simply feeding the certificate to an appropriate tool.
I agree. But, if a log elects to offer this service, the results of the check visible to all clients
(e.g., TLS and Monitors) and that has two useful benefits. Also, even if a log does not perform a
syntax check, the fact that a submitter asserted the type of cert being logged is useful to TLS clients,
and maybe to Monitors and the Audit function.
 

The lack of a requirement for rejection does not mean that popular TLS clients will not reject. As you know, Chrome will shortly stop showing EV indicators for EV certs without valid SCTs, even though there is no requirement to do so.

It seems to me a more accurate analysis would be along the lines of:

"If TLS clients do not reject certificates or otherwise notify users 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.)."
I agree with your suggested text change.

 

 

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.)

ibid.
 

 

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.


Again, lack of requirement does not imply lack of implementation. Again, I would suggest this should be phrased conditionally.
In the context of a standard, one OUGHT NOT (as per 6919) rely on client behavior that is not mandated.
I could re-phrase this, but there is a bigger issue lurking here. If mandated client behavior is
out of scope for 6269-bis, i.e., if the doc focuses only on the operation of logs, then I believe
the doc cannot be evaluated (and thus approved by the WG) until ancillary docs specifying client
behavior have been completed. My argument is that we don't know if the spec for log operation
is complete and correct until we know what log clients will do based on interactions with a log,
processing of SCTs, etc.
 

 

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.


Not sure of the relevance of "non-conspiring" here?
If logs conspire with a CA, they may not report a log entry for a bogus cert to an affected subject.

 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.


Again, the log has no special role to play in the detection of syntactic errors: TLS clients that wish to reject such certificates can do so unaided. Indeed, I would've thought conformance to existing RFCs would imply such behaviour - and if they don't, surely CT is not the place to fix that?
I noted above why syntax checking by logs is beneficial. Experience shows that a number of TLS clients
have been very bad about checking certs relative to existing RFCs, so having such checks offered
by logs is beneficial for that reason too. CT is supposed to create an infrastructure that helps
detect/deter issuance of "mis-issued" certs?  Syntactically broken certs are mis-issued, relative
to a specified cert profile, whether that DV, EV, S/MIME, or whatever.

 

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.)


See above (both on requirements and on CT's role in syntax).
see my (distinct) replies to you comments above.
 

 

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.


Why would they believe that, given there's no requirement to do such verification?
Since there appear to be NO TLS client requirements today :-).

As I mentioned earlier, until we have a complete set of specs for client behavior, TLS
clients and Monitors, we can't have high confidence that the CT log spec is right.
 


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.)


See above.
I'll change this to be consistent with the text change you noted earlier.
 

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.

It is Google's view that pinning is not a scalable solution, unlike CT. We do not agree that pinning reduces the need for CT.
Well, some part of Google obviously believes pinning is a useful solution, since all three editors for
the pinning spec are from Google :-).

More to the point, we're developing an IETF RFC; Google's "view" is just one input. Thus your
very terse reply is not a basis for failing to address this obvious issue.

Steve

--------------050105050104080308020808-- From nobody Thu Feb 26 14:02: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 5F8D81A6F39 for ; Thu, 26 Feb 2015 14:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tm1Z_aCgLvDc for ; Thu, 26 Feb 2015 14:02:51 -0800 (PST) Received: from mail.hezmatt.org (sasquatch.hezmatt.org [70.85.129.92]) by ietfa.amsl.com (Postfix) with ESMTP id 212541A1EF3 for ; Thu, 26 Feb 2015 14:02:51 -0800 (PST) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 76635D691 for ; Fri, 27 Feb 2015 09:02:50 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 1B11EA0746; Fri, 27 Feb 2015 09:02:50 +1100 (AEDT) Date: Fri, 27 Feb 2015 09:02:50 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20150226220250.GW27986@hezmatt.org> References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> <54AAB0F8.6010707@bbn.com> <54EF83FD.7070803@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EF83FD.7070803@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: 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: Thu, 26 Feb 2015 22:02:53 -0000 On Thu, Feb 26, 2015 at 03:37:17PM -0500, Stephen Kent wrote: > Ben, > > >My argument is that over time servers will deal with SCTs automatically > >and CAs will stop including SCTs (at least optionally) as a result. > > I understand your assertion, but I don't feel that you have made a strong > case for why this specific path will become the norm. Because it is operationally more flexible than embedding SCTs in the certificate (rotating SCTs if logs cease operation or become untrusted), and hence can make the TLS handshake smaller (only need to transmit the one SCT that is trusted, rather than N SCTs in the certificate). - Matt From nobody Thu Feb 26 14:16: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 C18241A1ABF for ; Thu, 26 Feb 2015 14:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2gniYPWULoRe for ; Thu, 26 Feb 2015 14:16:29 -0800 (PST) Received: from mail.hezmatt.org (sasquatch.hezmatt.org [70.85.129.92]) by ietfa.amsl.com (Postfix) with ESMTP id D762E1A016B for ; Thu, 26 Feb 2015 14:16:29 -0800 (PST) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 7A14AD691 for ; Fri, 27 Feb 2015 09:16:29 +1100 (EST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id D1248A0746; Fri, 27 Feb 2015 09:16:28 +1100 (AEDT) Date: Fri, 27 Feb 2015 09:16:28 +1100 From: Matt Palmer To: trans@ietf.org Message-ID: <20150226221628.GX27986@hezmatt.org> References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> <54EF83F0.60802@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EF83F0.60802@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: 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: Thu, 26 Feb 2015 22:16:30 -0000 On Thu, Feb 26, 2015 at 03:37:04PM -0500, Stephen Kent wrote: > Ben, > > >My thinking is that: > > > >1. There is concern, generally, about the size of certificates (really > >about the size of handshakes). > That concern varies a lot, depending on context. I don't agree that this > is a universal, major concern. Look at JSON; it's use of XML encoding > suggests no concern about bloat in a web context. This isn't a *web* context, though; it's a TLS session establishment context. Bloating the handshake so as to require an additional round trip increases session establishment time, which degrades user experience -- something which is generally considered a bad thing. > >3. Embedding SCTs in certs runs the risk that the SCTs will become invalid > >before the cert does. > > until we have a precise description of how a client will deal with an > invalid SCT, we can't really evaluate the implications of this potential > mismatch. Also, what causes an SCT to become invalid?. An SCT becomes invalid when the log which issued it ceases to be trusted by the browser. - Matt From nobody Thu Feb 26 15:07: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 C1B5B1A86DD for ; Thu, 26 Feb 2015 15:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v96YEIBi7tJk for ; Thu, 26 Feb 2015 15:07:46 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9301A0252 for ; Thu, 26 Feb 2015 15:07:45 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so5140554vcb.13 for ; Thu, 26 Feb 2015 15:07:45 -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=yIpOKmt8dZl6g/Wy1Z8zbeC4uyQ61SYnuC8qTZZFpuA=; b=YyDVGgjCSpxEXm8M37dGX4nAS8/kuP53vHfKlK4UNE8j97qgYfRNiE9wlDLCzeJWr5 wAPShYar9m2kDkZNG0FHmZ41/w4kTMYqvGeuEiPaEA2EqSfaTHVtUtwXbSOpP4REMZJr iX5Pj3vVf24g35LE917I8QZEhmNVBCMLK2Um0l3HCTnn5sjFQHegRvE/4Ab3HxOXkO7Y mjlO35Ntylc8sEZfP+s23/rh5C0ydzCGG+8uQbwac0e4UOWFF8cqNt9D6FJHsH4EqrBt jXZ46q6b7EVQFfE04qsPO3CgN/Wf8BkIiNdzSM4rg7/wv8omTVOcnDaF+wNiAUDeZoW6 fJKQ== MIME-Version: 1.0 X-Received: by 10.52.162.72 with SMTP id xy8mr10897512vdb.12.1424992065094; Thu, 26 Feb 2015 15:07:45 -0800 (PST) Received: by 10.52.254.235 with HTTP; Thu, 26 Feb 2015 15:07:45 -0800 (PST) In-Reply-To: <54EF8403.90307@bbn.com> References: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> <54EF8403.90307@bbn.com> Date: Fri, 27 Feb 2015 00:07:45 +0100 Message-ID: From: Erwann Abalea To: Stephen Kent Content-Type: multipart/alternative; boundary=089e01628326d90b3d051005d1df Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT 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, 26 Feb 2015 23:07:47 -0000 --089e01628326d90b3d051005d1df Content-Type: text/plain; charset=UTF-8 The "TLS" syntax/notation is also used to describe certificates and messages in ITS world. It's very bad, but that's not RFC5246 authors's fault. X.509 permits the inclusion of anything in an extension, as long as it's enclosed in something that has an ASN.1+DER representation, whence the double OCTET STRING sometimes found. That's not new to CT. 2015-02-26 21:37 GMT+01:00 Stephen Kent : > I disagree with this proposed resolution of the issue. > > RFC 5246 says of the syntax: > > ... The following very basic and somewhat casually > defined presentation syntax will be used. The syntax draws from > several sources in its structure. Although it resembles the > programming language "C" in its syntax and XDR [XDR] in both its > syntax and intent, it would be risky to draw too many parallels. *The* > * purpose of this presentation language is to document TLS only; it has* > * no general application beyond that particular goal.* > > Thus use of this syntax in an X.509 cert extension is contrary to the > spirit of 5246. > > Steve > > #34: use of RFC 5246 syntax to define the SCT > > Changes (by benl@google.com): > > * status: new => closed > * resolution: => wontfix > > > Comment: > > TLS extensions are defined using RFC 5246 format, so clearly it is correct > to use that format for the TLS extension. > > There is no compelling reason to have multiple SCT formats, and good > reasons to not do so (complexity, extra signing overhead). > > So, closing this ticket without changing the format. > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > -- Erwann. --089e01628326d90b3d051005d1df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The "TLS" syntax/notation is also used to descri= be certificates and messages in ITS world. It's very bad, but that'= s not RFC5246 authors's fault.

X.509 permits the inc= lusion of anything in an extension, as long as it's enclosed in somethi= ng that has an ASN.1+DER representation, whence the double OCTET STRING som= etimes found. That's not new to CT.

<= div class=3D"gmail_quote">2015-02-26 21:37 GMT+01:00 Stephen Kent <kent@bbn.com= >:
=20 =20 =20
I disagree with this proposed resolution of the issue.

RFC 5246 says of the syntax:

=C2=A0=C2=A0 ...=C2=A0 The following very basic and somewhat casually =C2=A0=C2=A0 defined presentation syntax will be used.=C2=A0 The syntax= draws from
=C2=A0=C2=A0 several sources in its structure.=C2=A0 Although it resemb= les the
=C2=A0=C2=A0 programming language "C" in its syntax and XDR [= XDR] in both its
=C2=A0=C2=A0 syntax and intent, it would be risky to draw too many para= llels.=C2=A0 The
=C2=A0=C2=A0 purpose of this presentation language is to documen= t TLS only; it has
=C2=A0=C2=A0 no general application beyond that particular goal.=

Thus use of this syntax in an X.509 cert extension is contrary to the spirit of 5246.

Steve
#34: use of RFC 5246 syntax to define the SCT

Changes (by benl@googl=
e.com):

 * status:  new =3D> closed
 * resolution:   =3D> wontfix


Comment:

 TLS extensions are defined using RFC 5246 format, so clearly it is correct
 to use that format for the TLS extension.

 There is no compelling reason to have multiple SCT formats, and good
 reasons to not do so (complexity, extra signing overhead).

 So, closing this ticket without changing the format.


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




--
Erwann.
--089e01628326d90b3d051005d1df-- From nobody Thu Feb 26 15:23: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 6C1E01A8749 for ; Thu, 26 Feb 2015 15:23:24 -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 QEnysBv9hsWK for ; Thu, 26 Feb 2015 15:23:22 -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 E2EB61A0077 for ; Thu, 26 Feb 2015 15:23:21 -0800 (PST) Received: (qmail 29816 invoked by uid 1004); 26 Feb 2015 23:23:19 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 26 Feb 2015 23:23:19 +0000 Received: (qmail 29553 invoked by uid 1000); 26 Feb 2015 23:23:19 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 26 Feb 2015 23:23:19 +0000 Message-ID: <54EFAAE7.3040707@comodo.com> Date: Thu, 26 Feb 2015 18:23:19 -0500 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: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> <54EF8403.90307@bbn.com> In-Reply-To: <54EF8403.90307@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT 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, 26 Feb 2015 23:23:24 -0000 On 26/02/15 15:37, Stephen Kent wrote: > I disagree with this proposed resolution of the issue. > > RFC 5246 says of the syntax: > > ... The following very basic and somewhat casually > defined presentation syntax will be used. The syntax draws from > several sources in its structure. Although it resembles the > programming language "C" in its syntax and XDR [XDR] in both its > syntax and intent, it would be risky to draw too many parallels. *The** > ** purpose of this presentation language is to document TLS only; it has** > ** no general application beyond that particular goal.* > > Thus use of this syntax in an X.509 cert extension is contrary to the > spirit of 5246. If that was the intended spirit, why didn't the 5246 authors write this instead: "; it MUST NOT be used beyond that particular goal." ? > Steve >> #34: use of RFC 5246 syntax to define the SCT >> >> Changes (bybenl@google.com): >> >> * status: new => closed >> * resolution: => wontfix >> >> >> Comment: >> >> TLS extensions are defined using RFC 5246 format, so clearly it is correct >> to use that format for the TLS extension. >> >> There is no compelling reason to have multiple SCT formats, and good >> reasons to not do so (complexity, extra signing overhead). >> >> So, closing this ticket without changing the format. >> > > > > _______________________________________________ > 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 Thu Feb 26 16:18:07 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8B91A1B51 for ; Thu, 26 Feb 2015 16:18:05 -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 1-cXD87P5oat for ; Thu, 26 Feb 2015 16:18:04 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3431A1B30 for ; Thu, 26 Feb 2015 16:18:04 -0800 (PST) Received: by pdjp10 with SMTP id p10so16829830pdj.3 for ; Thu, 26 Feb 2015 16:18:03 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wL1Uf/A4JPYtY1JNAxrL8yUjA1ZLkfa/wXqd/cbV1A4=; b=tohmPQKzhADQ6I2M1aonKw4emSW7QvFaUPMIFn3Ua6fvbGGNv6BDckQsIRQvZE97JC 3ITdlMYLrr/X1Z5/96sZTh7++Q9DPErF374E22wkCPLrjktKqH4HJOnlvGr3r5hWCsg8 apFaLZGYdhBNcZMQwdGDU8oGl2bjkTcrp04qk3TW5DPZUcvUcugKiJtqVK7AjThujWmv EBzkHQrZ4dIjlofdzErbY2iIjrgZ1onCxe2R0++H4kh1yiSG3PnfYq9AxOJOijWFtRjy z2ssG2nO1rLfDok62b9uFyfTBDp9M7ALiMqC6Hwo9FREyZuL14JrQY0aqnmbMmF478TF spKg== X-Received: by 10.68.135.166 with SMTP id pt6mr19478264pbb.74.1424996283782; Thu, 26 Feb 2015 16:18:03 -0800 (PST) Received: from spandex.local (63-140-88-158.dynamic.dsl.acsalaska.net. [63.140.88.158]) by mx.google.com with ESMTPSA id je2sm2087252pbd.44.2015.02.26.16.18.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Feb 2015 16:18:03 -0800 (PST) Message-ID: <54EFB7B9.1010001@gmail.com> Date: Thu, 26 Feb 2015 15:18:01 -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 References: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> <54EF8403.90307@bbn.com> <54EFAAE7.3040707@comodo.com> In-Reply-To: <54EFAAE7.3040707@comodo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT 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, 27 Feb 2015 00:18:06 -0000 First, I need to apologize for being largely checked out the past while - I've been down with a particularly virulent flu and am still largely flattened by it. I'll do better. Second, taking my chair hat off, a couple of comments on the syntax question: I'm not sure that there have been any technical arguments made for why either approach must be excluded, which would be the first place to start, I think. 5246 definitely does not say that that syntax must not be used for anything else, ever. What it says is: "The purpose of this presentation language is to document TLS only; it has no general application beyond that particular goal." Because you've wanted to treat this legalistically I think it's reasonable to point out that the phrase "has no general application" does not exclude the use of the same syntax to describe what are TLS-coupled data structures, unless you're arguing that CT logging of TLS certs would be a "general application." Even so, you don't have to look through many IETF specifications to find instances of later protocols violating some of the constraints written into earlier specifications - for example, in RSVP-TE extensions to RSVP. So, I think that's a tough path to follow. Frankly, in the absence of compelling technical arguments either way, my personal inclination is to privilege implementation. Again, that's my *personal* inclination. In the meantime, if there's a compelling technical argument against this encoding, it's definitely time to make it. We do need to make progress and not keep going over the same ground and arriving at same outcomes. Melinda From nobody Fri Feb 27 02:48: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 CD6601A8840 for ; Fri, 27 Feb 2015 02:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ0IhrWg1JXR for ; Fri, 27 Feb 2015 02:48:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E695C1A87B9 for ; Fri, 27 Feb 2015 02:48:26 -0800 (PST) Received: from localhost ([::1]:38967 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YRIT2-00059n-7J; Fri, 27 Feb 2015 02:48:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.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, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Fri, 27 Feb 2015 10:48:24 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/47#comment:4 Message-ID: <079.0d47ebce78e3b551a34142ce26121020@tools.ietf.org> References: <064.d6e5f5af90b5101c7d9459e45d8dd103@tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <064.d6e5f5af90b5101c7d9459e45d8dd103@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, eranm@google.com, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150227104826.E695C1A87B9@ietfa.amsl.com> Resent-Date: Fri, 27 Feb 2015 02:48:26 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #47 (rfc6962-bis): Clarify how to deal with (minor) DER violations when manipulating a TBSCertificate X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 10:48:28 -0000 #47: Clarify how to deal with (minor) DER violations when manipulating a TBSCertificate Comment (by eranm@google.com): Seems to me that this issue is still present after the Precertificate changes as clients would still have to manipulate the final X.509 certificate to extract the TBSCertificate part, remove extensions and reconstruct the redacted TBSCertificate if there are redactions. It would be exacerbated if we accept ticket #4 (Signing the TBSCertificate part for certificates as well). Ben, are you suggesting the log does not provide SCTs for such certificates but does include them in the tree? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Feb 27 03:08:56 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CADA1A8938 for ; Fri, 27 Feb 2015 03:08:53 -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 yeZB5r1gmiAH for ; Fri, 27 Feb 2015 03:08:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E272A1A8840 for ; Fri, 27 Feb 2015 03:08:51 -0800 (PST) Received: from localhost ([::1]:40130 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YRImo-00039n-61; Fri, 27 Feb 2015 03:08: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: rob.stradling@comodo.com, benl@google.com, eranm@google.com X-Trac-Project: trans Date: Fri, 27 Feb 2015 11:08:50 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/39#comment:5 Message-ID: <067.fd9a18463727bdccd50b2b69b302fcea@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, 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] #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: Fri, 27 Feb 2015 11:08:53 -0000 #39: Monitor behavior Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/31 Only provides an example of what a monitor may do. -- -----------------------------+----------------------- Reporter: kent@bbn.com | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Resolution: Keywords: | -----------------------------+----------------------- Ticket URL: trans From nobody Fri Feb 27 03:11:44 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C0A1A9040 for ; Fri, 27 Feb 2015 03:11: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 pLyNQJUpKW0U for ; Fri, 27 Feb 2015 03:11:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5D01A903F for ; Fri, 27 Feb 2015 03:11:42 -0800 (PST) Received: from localhost ([::1]:40203 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YRIpa-0003ed-AO; Fri, 27 Feb 2015 03:11:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: benl@google.com, eranm@google.com X-Trac-Project: trans Date: Fri, 27 Feb 2015 11:11:42 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/4#comment:1 Message-ID: <071.8c86644a1f3afb05749c53564bba8c33@tools.ietf.org> References: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #4 (rfc6962-bis): Should we sign TBS for Certificates? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 11:11:43 -0000 #4: Should we sign TBS for Certificates? Comment (by eranm@google.com): IIRC Rob Stradling suggested this is a good idea to avoid the issue of logs being susceptible to spamming by varying the signature algorithm specifier in the signature part of the X.509 certificate (so it does not match the one in the TBSCertificate part). -- ------------------------------+------------------------------ Reporter: eranm@google.com | Owner: benl@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------ Ticket URL: trans From nobody Fri Feb 27 06:32: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 DBF9E1A88F6 for ; Fri, 27 Feb 2015 06:32: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 cLvHpx71Qcq0 for ; Fri, 27 Feb 2015 06:32:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C501A88F3 for ; Fri, 27 Feb 2015 06:32:37 -0800 (PST) Received: from localhost ([::1]:51254 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YRLxy-0000B6-TJ; Fri, 27 Feb 2015 06:32:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: benl@google.com, eranm@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Fri, 27 Feb 2015 14:32:34 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/4#comment:2 Message-ID: <071.9072cb3f8088e3c0f6c575bd413b2c84@tools.ietf.org> References: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: benl@google.com, 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: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #4 (rfc6962-bis): Should we sign TBS for Certificates? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 14:32:39 -0000 #4: Should we sign TBS for Certificates? Comment (by rob.stradling@comodo.com): Yes. There are an unlimited number of ways that a spammer could incorrectly re-encode the signature algorithm parameters in the signature part of a single certificate, so I think we definitely need to address this. We could address it by saying that logs MUST check that the signature parameters are encoded identically in a cert's signature part and TBSCertificate part, but I think this ticket's suggestion (to always sign TBS) is the more elegant solution. -- ------------------------------+------------------------------ Reporter: eranm@google.com | Owner: benl@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------ Ticket URL: trans From nobody Fri Feb 27 06:42:08 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993E41ACC87 for ; Fri, 27 Feb 2015 06:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNNmYPwGqcVj for ; Fri, 27 Feb 2015 06:42: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 99D901ACC86 for ; Fri, 27 Feb 2015 06:42:06 -0800 (PST) Received: from localhost ([::1]:51695 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YRM7C-00048D-2K; Fri, 27 Feb 2015 06:42: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, benl@google.com X-Trac-Project: trans Date: Fri, 27 Feb 2015 14:42:06 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/49#comment:2 Message-ID: <079.968b60b80f35482f3fdf45e391b14a36@tools.ietf.org> References: <064.fba389268ce572d40a11602e41e69d8d@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <064.fba389268ce572d40a11602e41e69d8d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150227144206.99D901ACC86@ietfa.amsl.com> Resent-Date: Fri, 27 Feb 2015 06:42:06 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #49 (rfc6962-bis): Explain why OCSP Stapling is acceptable but OCSP Fetching is not X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 14:42:07 -0000 #49: Explain why OCSP Stapling is acceptable but OCSP Fetching is not Changes (by benl@google.com): * status: new => closed * resolution: => invalid Comment: We already explain why, closing. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: invalid Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Feb 27 06:54: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 BBC9A1ACCDA for ; Fri, 27 Feb 2015 06:54:45 -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 ifI7AL87HZA4 for ; Fri, 27 Feb 2015 06:54:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E7E1ACCD8 for ; Fri, 27 Feb 2015 06:54:44 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:43072 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YRMJO-0005Ay-SX; Fri, 27 Feb 2015 09:54:42 -0500 Message-ID: <54F08532.9030001@bbn.com> Date: Fri, 27 Feb 2015 09:54:42 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Rob Stradling , trans@ietf.org References: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> <54EF8403.90307@bbn.com> <54EFAAE7.3040707@comodo.com> In-Reply-To: <54EFAAE7.3040707@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT 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, 27 Feb 2015 14:54:45 -0000 Rob, > On 26/02/15 15:37, Stephen Kent wrote: >> I disagree with this proposed resolution of the issue. >> >> RFC 5246 says of the syntax: >> >> ... The following very basic and somewhat casually >> defined presentation syntax will be used. The syntax draws from >> several sources in its structure. Although it resembles the >> programming language "C" in its syntax and XDR [XDR] in both its >> syntax and intent, it would be risky to draw too many parallels. >> *The** >> ** purpose of this presentation language is to document TLS only; >> it has** >> ** no general application beyond that particular goal.* >> >> Thus use of this syntax in an X.509 cert extension is contrary to the >> spirit of 5246. > > If that was the intended spirit, why didn't the 5246 authors write > this instead: > > "; it MUST NOT be used beyond that particular goal." That's a fair question for EKR. Normally an RFC author doesn't say that a given construct is intended for use only in the context of the RFC. We usually like to assume that what we develop may have more widespread application beyond the context of the RFC. When an author does make a statement of the sort cited above, it suggests that the author was concerned about more widespread use of the syntax (in this case). Steve From nobody Fri Feb 27 07:35: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 DA3BC1ACD4E for ; Fri, 27 Feb 2015 07:35: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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUtRVZ0G9opr for ; Fri, 27 Feb 2015 07:35:01 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6331A88F3 for ; Fri, 27 Feb 2015 07:34:53 -0800 (PST) Received: from localhost ([::1]:54799 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YRMwH-0008Pf-0f; Fri, 27 Feb 2015 07:34: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, benl@google.com X-Trac-Project: trans Date: Fri, 27 Feb 2015 15:34:52 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/46#comment:1 Message-ID: <080.8f0a0b2f6aa9e3e7e98f0879d1f24e8c@tools.ietf.org> References: <065.2a77fb5e7d4ce96b58a426fdc551edad@tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <065.2a77fb5e7d4ce96b58a426fdc551edad@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150227153453.6B6331A88F3@ietfa.amsl.com> Resent-Date: Fri, 27 Feb 2015 07:34:53 -0800 (PST) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #46 (rfc6962-bis): Provide explicit instructions for how log servers should handle already-logged certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 15:35:02 -0000 #46: Provide explicit instructions for how log servers should handle already- logged certs Changes (by benl@google.com): * status: new => closed * resolution: => fixed Comment: Fixed by https://github.com/google/certificate-transparency- rfcs/commit/26354c90154c5849eb7c59f8e0b68aadaf8b2b9f. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rick_andrews@symantec.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: rfc6962-bis | Version: 1.0 Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Fri Feb 27 13:16:09 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7F41A0173 for ; Fri, 27 Feb 2015 13:16:08 -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 E1uDyH51ejHQ for ; Fri, 27 Feb 2015 13:16:06 -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 7D7921A00FE for ; Fri, 27 Feb 2015 13:16:06 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:47075 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YRSGT-000Dj6-BT; Fri, 27 Feb 2015 16:16:05 -0500 Message-ID: <54F0DE95.1030509@bbn.com> Date: Fri, 27 Feb 2015 16:16:05 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Erwann Abalea References: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> <54EF8403.90307@bbn.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT 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, 27 Feb 2015 21:16:08 -0000 Erwann, > The "TLS" syntax/notation is also used to describe certificates and > messages in ITS world. It's very bad, but that's not RFC5246 authors's > fault. What is the "ITS" world? And is it under the IETF standards umbrella? if not, then this is not a good rationale for veering from the statement in 5246. > > X.509 permits the inclusion of anything in an extension, as long as > it's enclosed in something that has an ASN.1+DER representation, > whence the double OCTET STRING sometimes found. That's not new to CT. True, but I think that is not commonly done in standard extensions. Do you have some examples that counter my perception? In my experience, people developing extensions for X.509 usually try to avoid cramming arbitrary data into an OCTET string. Steve From nobody Fri Feb 27 13:16: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 D4D351A0211 for ; Fri, 27 Feb 2015 13:16:17 -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 jBRU2ejoklxJ for ; Fri, 27 Feb 2015 13:16:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F97D1A020D for ; Fri, 27 Feb 2015 13:16:16 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:38669 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YRSGd-000ALF-6n for trans@ietf.org; Fri, 27 Feb 2015 16:16:15 -0500 Message-ID: <54F0DE9E.9090504@bbn.com> Date: Fri, 27 Feb 2015 16:16:14 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <052.35c4bb490ca830a7c003481975592e44@tools.ietf.org> <067.fd9a18463727bdccd50b2b69b302fcea@tools.ietf.org> In-Reply-To: <067.fd9a18463727bdccd50b2b69b302fcea@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #39 (client-behavior): Monitor behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 21:16:18 -0000 While I agree that examples are useful in RFCs, they are not a substitute for specifications of MTI behavior. They also do not provide a rationale for what features are or are not needed from a system component, because examples are not comprehensive nor authoritative. Thus I question the utility of including only examples of Monitor behavior in this doc. > #39: Monitor behavior > > > Comment (byeranm@google.com): > > Out for review inhttps://github.com/google/certificate-transparency- > rfcs/pull/31 > Only provides an example of what a monitor may do. > From nobody Fri Feb 27 13:16:47 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1DF1A0178 for ; Fri, 27 Feb 2015 13:16:46 -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 4AZ7-QhPIDrw for ; Fri, 27 Feb 2015 13:16:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A7C1A0173 for ; Fri, 27 Feb 2015 13:16:44 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:38693 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YRSH5-000ALL-Lq for trans@ietf.org; Fri, 27 Feb 2015 16:16:43 -0500 Message-ID: <54F0DEBB.2010804@bbn.com> Date: Fri, 27 Feb 2015 16:16:43 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> <54EF83F0.60802@bbn.com> <20150226221628.GX27986@hezmatt.org> In-Reply-To: <20150226221628.GX27986@hezmatt.org> Content-Type: multipart/alternative; boundary="------------080104010705030003060202" Archived-At: 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: Fri, 27 Feb 2015 21:16:46 -0000 This is a multi-part message in MIME format. --------------080104010705030003060202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Matt, > On Thu, Feb 26, 2015 at 03:37:04PM -0500, Stephen Kent wrote: >> Ben, >> >>> My thinking is that: >>> >>> 1. There is concern, generally, about the size of certificates (really >>> about the size of handshakes). >> That concern varies a lot, depending on context. I don't agree that this >> is a universal, major concern. Look at JSON; it's use of XML encoding >> suggests no concern about bloat in a web context. > This isn't a *web* context, though; it's a TLS session establishment > context. Bloating the handshake so as to require an additional round trip > increases session establishment time, which degrades user experience -- > something which is generally considered a bad thing. The charter for the WG says: "The working group will produce a standards-track version of the experimental RFC 6962 *for HTTP over TLS*, ..." so I think it's appropriate to discuss this in the web context. >>> 3. Embedding SCTs in certs runs the risk that the SCTs will become invalid >>> before the cert does. >> until we have a precise description of how a client will deal with an >> invalid SCT, we can't really evaluate the implications of this potential >> mismatch. Also, what causes an SCT to become invalid?. > An SCT becomes invalid when the log which issued it ceases to be trusted by > the browser. Thanks for that clarification. But, since there is no spec for client behavior, the notion of a browser no longer trusting a log is undefined at this time. Also, there is no description of how a web site operator will learn that some non-trivial set of clients no longer trust a given log, and thus the operator will be motivated to acquire a new SCT for his cert from another log. Finally, the text above refers to a cert becoming "invalid." Does this mean the cert is revoked, or does this refer to a cert expiring? if the latter is intended, then it is preferable to use the correct term. Steve --------------080104010705030003060202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Matt,

On Thu, Feb 26, 2015 at 03:37:04PM -0500, Stephen Kent wrote:

Ben,


My thinking is that:

1. There is concern, generally, about the size of certificates (really
about the size of handshakes).

That concern varies a lot, depending on context. I don't agree that this
is a universal, major concern.  Look at JSON; it's use of XML encoding
suggests no concern about bloat in a web context.

This isn't a *web* context, though; it's a TLS session establishment
context.  Bloating the handshake so as to require an additional round trip
increases session establishment time, which degrades user experience --
something which is generally considered a bad thing.
The charter for the WG says:
"The working group will produce a standards-track version of the experimental RFC 6962
for HTTP over TLS, ..." so I think it's appropriate to discuss this in the web context.

3. Embedding SCTs in certs runs the risk that the SCTs will become invalid
before the cert does.

until we have a precise description of how a client will deal with an
invalid SCT, we can't really evaluate the implications of this potential
mismatch.  Also, what causes an SCT to become invalid?.

An SCT becomes invalid when the log which issued it ceases to be trusted by
the browser.
Thanks for that clarification. But, since there is no spec for client behavior,
the notion of a browser no longer trusting a log is undefined at this time. Also,
there is no description of how a web site operator will learn that some non-trivial set
of clients no longer trust  a given log, and thus the operator will be motivated to
acquire a new SCT for his cert from another log. Finally, the text above refers to a
cert becoming "invalid." Does this mean the cert is revoked, or does this refer to a
cert expiring? if the latter is intended, then it is preferable to use the correct term.

Steve
--------------080104010705030003060202-- From nobody Fri Feb 27 13:45: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 8437A1A034C for ; Fri, 27 Feb 2015 13:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5qeG2goIHX9 for ; Fri, 27 Feb 2015 13:45:32 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89ED1A035F for ; Fri, 27 Feb 2015 13:45:31 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id hy10so7260811vcb.8 for ; Fri, 27 Feb 2015 13:45:31 -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=Dme2iknpa19nZFJMjzm1xFwv0uRR1/YNNLdCQrf/Rqg=; b=nTqHq5RR7Jr/gvEAkzMc33qUhCUhHdWniZuM3DgPc3dD4iLuHxa7I/bUq0S6MeyK8w ovSvOM1IQWAAUByYwlRmy/LjZoEqmqphi5xTNkkc06iLTgPadWsF41iJ4SLGRVWONIq+ fH8czD/UztUJUgeo4VsBM756NsuWnz3DqaeK8nPOkBr56ylWaMFFlx6ncb/HoTKY00NS AaTkE5+NGeZCQn/BIBAaZ+TzutF+m4yYivMMR5ZUcuzlHX1ouZ6PRYTJc2T4L18jLPIc FirfpYqgzbfKAeoyTl5qahCdncvLz1h09YJvs0CLNrgGWP8e9D3+jIGDo2OaoFAZZ+c5 hqQA== MIME-Version: 1.0 X-Received: by 10.52.180.232 with SMTP id dr8mr14922504vdc.62.1425073531106; Fri, 27 Feb 2015 13:45:31 -0800 (PST) Received: by 10.52.254.235 with HTTP; Fri, 27 Feb 2015 13:45:31 -0800 (PST) In-Reply-To: <54F0DE95.1030509@bbn.com> References: <052.10eb26d4fde793d0a60756eb4c9dc8cc@tools.ietf.org> <067.3f6fd76ea878508f23fc24cdf754d7e0@tools.ietf.org> <54EF8403.90307@bbn.com> <54F0DE95.1030509@bbn.com> Date: Fri, 27 Feb 2015 22:45:31 +0100 Message-ID: From: Erwann Abalea To: Stephen Kent Content-Type: multipart/alternative; boundary=bcaec517ab0299bcc7051018c9e7 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT 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, 27 Feb 2015 21:45:33 -0000 --bcaec517ab0299bcc7051018c9e7 Content-Type: text/plain; charset=UTF-8 Bonsoir Stephen, 2015-02-27 22:16 GMT+01:00 Stephen Kent : > Erwann, > >> The "TLS" syntax/notation is also used to describe certificates and >> messages in ITS world. It's very bad, but that's not RFC5246 authors's >> fault. >> > What is the "ITS" world? And is it under the IETF standards umbrella? if > not, then this is > not a good rationale for veering from the statement in 5246. > "Intelligent Transport System". Cars, trucks, motorbikes, tramways, trains, road equipment, ... See IEEE1609.2 and ETSI TS103097 if you're curious :) That's not (yet) under IETF umbrella. Point taken. X.509 permits the inclusion of anything in an extension, as long as it's >> enclosed in something that has an ASN.1+DER representation, whence the >> double OCTET STRING sometimes found. That's not new to CT. >> > True, but I think that is not commonly done in standard extensions. Do you > have some examples > that counter my perception? In my experience, people developing extensions > for > X.509 usually try to avoid cramming arbitrary data into an OCTET string. > You're right again. I can't think of a single extension except SignedCertificateTimestampList defined in anything other than ASN.1. When working around X.509, ASN.1 is natural. Going back into "silent lurker" mode... -- Erwann. --bcaec517ab0299bcc7051018c9e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bonsoir Stephen,

2015-02-27 22:16 GMT+01:00 Stephen Kent <kent@bbn.com&g= t;:
Erwann,
The "TLS" syntax/notation is also used to describe certificates a= nd messages in ITS world. It's very bad, but that's not RFC5246 aut= hors's fault.
What is the "ITS" world? And is it under the IETF standards umbre= lla? if not, then this is
not a good rationale for veering from the statement in 5246.

"Intelligent Transport System". Cars, truck= s, motorbikes, tramways, trains, road equipment, ... See IEEE1609.2 and ETS= I TS103097 if you're curious :)
That's not (yet) under IE= TF umbrella. Point taken.

X.509 permits the inclusion of anything in an extension, as long as it'= s enclosed in something that has an ASN.1+DER representation, whence the do= uble OCTET STRING sometimes found. That's not new to CT.
True, but I think that is not commonly done in standard extensions. Do you = have some examples
that counter my perception? In my experience, people developing extensions = for
X.509 usually try to avoid cramming arbitrary data into an OCTET string.

You're right again. I can't think= of a single extension except SignedCertificateTimestampList defined in any= thing other than ASN.1. When working around X.509, ASN.1 is natural.
<= div>
Going back into "silent lurker" mode...
<= /div>

--
Erwann.
--bcaec517ab0299bcc7051018c9e7--