From nobody Thu May 1 06:56:17 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8D71A08CB; Thu, 1 May 2014 06:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPKZxQZuhQfE; Thu, 1 May 2014 06:56:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 721541A08CD; Thu, 1 May 2014 06:56:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140501135613.11925.92356.idtracker@ietfa.amsl.com> Date: Thu, 01 May 2014 06:56:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Bo1kZISD6DdAIdPIqmL5vcQ9atQ Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-03.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 13:56:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-03.txt Pages : 30 Date : 2014-05-01 Abstract: This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 5 10:23:15 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A514F1A0296 for ; Mon, 5 May 2014 01:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.623 X-Spam-Level: * X-Spam-Status: No, score=1.623 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 V15iM5Kvq86G for ; Mon, 5 May 2014 01:48:59 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 994B01A0157 for ; Mon, 5 May 2014 01:48:59 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id m20so4257397qcx.40 for ; Mon, 05 May 2014 01:48:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=B8TchLD/qw2Jgs4K04r3JbGW6XY24vTC9jd6KRidZOI=; b=DPI8hHgzuDkephkwzD0K/sslr5zaiSvT4teEWjo4uP8tPbv1zKKnp2ElDV9yGHXtlq P32fPkCYCRSixFgML0W7df2uAWLKuaISFZolm1ulp3CBlQQVnHp1V24SZFXejfVz/G4y o00YijxkW5vN9R/5IPu6QgVh7oT1nQSe1xJyOcKLEODDn4z5You46ASTUMY+arf5l0Z3 ZsRWjozT7tzQbroD8yiyO72lDSnnGUo6Gh61NmoFJu4D+P3AjX0WrKPyDDI1nsahyxHb y6LVqXTOSYflCWFzPOMWA/525J8F6POjbjmmuYemUl6rpjB71CEaGoF5scNp/cnat3NH E6Bw== X-Gm-Message-State: ALoCoQlVhvrkBo2sdzOmLt/dqy9e9092QnSdDrH5PSJxLnoaJjdrLvFLoD2Ufb5otpGRnwC7+M4u X-Received: by 10.224.134.194 with SMTP id k2mr42249657qat.5.1399279735806; Mon, 05 May 2014 01:48:55 -0700 (PDT) MIME-Version: 1.0 Sender: me@chemalogo.com Received: by 10.140.108.33 with HTTP; Mon, 5 May 2014 01:48:25 -0700 (PDT) X-Originating-IP: [84.88.59.1] In-Reply-To: <763539E260C37C46A0D6B340B5434C3B093F1CBC@AEX06.ejsarea.net> References: <763539E260C37C46A0D6B340B5434C3B093F1CBC@AEX06.ejsarea.net> From: =?UTF-8?Q?Chema_L=C3=B3pez_Gonz=C3=A1lez?= Date: Mon, 5 May 2014 10:48:25 +0200 X-Google-Sender-Auth: cJNYP9ljRxBHaRpwdFP2PyT32Bw Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a11c2c3469833ca04f8a3333f Archived-At: http://mailarchive.ietf.org/arch/msg/trans/pKh_xkmFQiI7AlQcirYXZ4eY3kM X-Mailman-Approved-At: Mon, 05 May 2014 10:23:11 -0700 Cc: trans@ietf.org, "public@cabforum.org" Subject: Re: [Trans] [cabfpub] Infrastructure for logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 08:49:02 -0000 --001a11c2c3469833ca04f8a3333f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 1.- Ubuntu xx.xx LTS 2.- MySQL 3.- none at this moment --=20 *Chema L=C3=B3pez* *Gestor de Proyectos - Departamento T=C3=A9cnico* *AC Firmaprofesional, S.A.* Edificio ESADECREAPOLIS - 1B13 08173 Sant Cugat del Vall=C3=A8s, Barcelona. T. 934 774 245 M. 666 429 224 On Wed, Apr 23, 2014 at 12:00 PM, wrote: > Hi Ben, > > > > > I=C3=B1igo Barreira > Responsable del =C3=81rea t=C3=A9cnica > i-barreira@izenpe.net > 945067705 > > > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta > egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbid= ea > gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi > erantzuna. KONTUZ! > ATENCION! Este mensaje contiene informacion privilegiada o confidencial a > la que solo tiene derecho a acceder el destinatario. Si usted lo recibe p= or > error le agradeceriamos que no hiciera uso de la informacion y que se > pusiese en contacto con el remitente. > > > -----Mensaje original----- > De: Trans [mailto:trans-bounces@ietf.org] En nombre de Ben Laurie > Enviado el: jueves, 17 de abril de 2014 19:08 > Para: CABFPub; trans@ietf.org > Asunto: [Trans] Infrastructure for logs? > > My team is considering doing some work on the open source log > implementation to make it less of a reference implementation and more > something that you could consider running in (or adapting for) a producti= on > environment. > > It would help guide our thinking of those CAs (and others) who are > considering running logs would give us some hints about the kind of > production environment they would like to run in. In particular: > > 1. Operating systems. > > 2. Database managers. > > 3. Any other constraints you might have on a production environment. > > Public discussion would be useful, but if you would rather tell me > privately that is also fine. Bear in mind that what we learn will probabl= y > influence open source code, though that's obviously very unlikely to reve= al > anything about anyone in particular. > > -- > Certificate Transparency is hiring! Let me know if you're interested. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > _______________________________________________ > Public mailing list > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public > --001a11c2c3469833ca04f8a3333f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
1.- Ubuntu xx.xx LTS
2.- MySQL
3.- none at this mome= nt

--=C2=A0
<= b>Chema L=C3=B3pez
Gestor de Proy= ectos - Departamento T=C3=A9cnico
AC Firmaprofesional, S.A.

Edificio ESADECREAPOLIS - 1B13
0817= 3 Sant Cugat del Vall=C3=A8s, Barcelona.=C2=A0
T. =C2=A0934 = 774 245
M. 666 429 224


On Wed, Apr 23, 2014 at 12:00 PM, <i-barreira@izenpe.net> wrote:
Hi Ben,




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


ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea.= Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki= idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzun= a. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a l= a que solo tiene derecho a acceder el destinatario. Si usted lo recibe por = error le agradeceriamos que no hiciera uso de la informacion y que se pusie= se en contacto con el remitente.


-----Mensaje original-----
De: Trans [mailto:trans-bounces@i= etf.org] En nombre de Ben Laurie
Enviado el: jueves, 17 de abril de 2014 19:08
Para: CABFPub; trans@ietf.org
Asunto: [Trans] Infrastructure for logs?

My team is considering doing some work on the open source log implementatio= n to make it less of a reference implementation and more something that you= could consider running in (or adapting for) a production environment.

It would help guide our thinking of those CAs (and others) who are consider= ing running logs would give us some hints about the kind of production envi= ronment they would like to run in. In particular:

1. Operating systems.

2. Database managers.

3. Any other constraints you might have on a production environment.

Public discussion would be useful, but if you would rather tell me privatel= y that is also fine. Bear in mind that what we learn will probably influenc= e open source code, though that's obviously very unlikely to reveal any= thing about anyone in particular.

--
Certificate Transparency is hiring! Let me know if you're interested.
_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans
___________________________________= ____________
Public mailing list
Public@cabforum.org
= https://cabforum.org/mailman/listinfo/public

--001a11c2c3469833ca04f8a3333f-- From nobody Fri May 9 14:31:32 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7CD1A00EC for ; Fri, 9 May 2014 14:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334] 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 XqYndxus8MpR for ; Fri, 9 May 2014 14:31:30 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C28E61A00D8 for ; Fri, 9 May 2014 14:31:30 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 51D872007F109 for ; Fri, 9 May 2014 14:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=31JXLBJ6jSMBaCCn5zoOGkD0qAs=; b=tKN9kTln6c3 cMSqgPKonasW0rLVkQzutzXbGk9w6bIfGCpLXoMchy9MJ0ra3Dvj+2o7VMJoTtOd troYh5UYTiCusxOHtbuLuyaFx0I7gR1H7aHofuRxAm4SkBSDqqeRTvlMSE/7Dk5h d2k+3VrD7wa98s191l2UgsGxt/2fh3wo= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 079D42007F10B for ; Fri, 9 May 2014 14:31:24 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so4602983wgh.32 for ; Fri, 09 May 2014 14:31:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.187.107 with SMTP id fr11mr3494290wjc.70.1399671083737; Fri, 09 May 2014 14:31:23 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Fri, 9 May 2014 14:31:23 -0700 (PDT) Date: Fri, 9 May 2014 16:31:23 -0500 Message-ID: From: Nico Williams To: trans@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/MzKKnPN96N48DVDeNaWMB-oWWvA Subject: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:31:31 -0000 DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. It stands to reason that DNSSEC should have similar trust problems as PKIX. I believe it does indeed. It follows that things like CT that we're applying to PKIX should be applied to DNSSEC as well, where possible. I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it should be done. Note that DNSSEC needs CT independently of protocols like DANE, but any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE effectively does) should increase the need for CT for DNSSEC. Note too that I'm not in any way saying that DANE and similar should block on CT for DNSSEC. Sincerely, Nico -- From nobody Fri May 9 14:58:49 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120831A010D for ; Fri, 9 May 2014 14:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 eaN9I41GCWm0 for ; Fri, 9 May 2014 14:58:41 -0700 (PDT) Received: from prodomx03.usaa.com (prodomx03.usaa.com [167.24.101.121]) by ietfa.amsl.com (Postfix) with ESMTP id 483781A00BF for ; Fri, 9 May 2014 14:58:41 -0700 (PDT) Received: from pps.filterd (prodomx03.usaa.com [127.0.0.1]) by prodomx03.usaa.com (8.14.5/8.14.5) with SMTP id s49LwHxs018830; Fri, 9 May 2014 16:58:35 -0500 Received: from prodexch05w.eagle.usaa.com (prodexch05w.eagle.usaa.com [10.70.40.23]) by prodomx03.usaa.com with ESMTP id 1kka2237tm-1; Fri, 09 May 2014 16:58:34 -0500 Received: from PRODEXCH09W.eagle.usaa.com (10.70.40.35) by PRODEXCH05W.eagle.usaa.com (10.70.40.23) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 16:58:34 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.164]) by PRODEXCH09W.eagle.usaa.com ([10.70.40.35]) with mapi id 14.03.0158.001; Fri, 9 May 2014 16:58:34 -0500 From: "Mehner, Carl" To: Nico Williams , "trans@ietf.org" Thread-Topic: EXTERNAL: [Trans] DNSSEC also needs CT Thread-Index: AQHPa84KI9PZzmYM/EislSNGZSjevZs4y1ag Date: Fri, 9 May 2014 21:58:34 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.15.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Direction: FromExch X-Proofpoint-Direction: Internet X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-09_08:2014-05-09,2014-05-09,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/NlXXQvKVeN2gpVnYqL4BXfFkBtc Subject: Re: [Trans] EXTERNAL: DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:58:48 -0000 RFC6698 says: >This chain is required to prevent a CA from avoiding blame > by logging a partial or empty chain. (Note: This effectively > excludes self-signed and DANE-based certificates until some mechanism > to control spam for those certificates is found. The authors welcome > suggestions.) I propose: To have a DANE certificate (not signed by a public CA) included into a CT l= og: 1) a pre-certificate be created 2) the pre-certificate submitted to a log 3) the log will verify based on a valid DANE record of type PKIX-EE 4) return a SCT to the submitter to include in the final certificate Carl Mehner 210.416.0942 Info Security -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Nico Williams Sent: Friday, May 09, 2014 4:31 PM To: trans@ietf.org Subject: EXTERNAL: [Trans] DNSSEC also needs CT DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. It stands to reason that DNSSEC should have similar trust problems as PKIX. I believe it does indeed. It follows that things like CT that we're applying to PKIX should be applied to DNSSEC as well, where possible. I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it should be done. Note that DNSSEC needs CT independently of protocols like DANE, but any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE effectively does) should increase the need for CT for DNSSEC. Note too that I'm not in any way saying that DANE and similar should block on CT for DNSSEC. Sincerely, Nico -- _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Fri May 9 15:13:51 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6221A0118 for ; Fri, 9 May 2014 15:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spz4M9HdnVFZ for ; Fri, 9 May 2014 15:13:46 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5276B1A010D for ; Fri, 9 May 2014 15:13:46 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 4A3C1392076; Fri, 9 May 2014 15:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=5IzDrxlyNRPD9+TCV WW1lJxCc84=; b=X0d63WCY/x0vDgH81uIZg1LfsI73QuTYfLmXna90i7DWwbS9+ xl2CKrrVXAVL0T2l9bkzlbzA9HFfYDsPw+VdXt4QoVx49cBxPXiC3eI/GMd+KY7A 3lZnF4SbvuOvX8dhyw/bzCSdIZvZbZfUQMAAS8xKMXfo3fBkJK5bXUfWnU= Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPSA id 41BCE39206D; Fri, 9 May 2014 15:13:40 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_305E70B0-259D-47B5-801A-364EAB217050"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Pgp-Agent: GPGMail 2.1 (525b9ae) From: Tao Effect In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com> Date: Fri, 9 May 2014 17:13:37 -0500 X-Mao-Original-Outgoing-Id: 421366417.513644-b64096aee58d7394958914ae964f890b Message-Id: <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com> References: <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com> To: "Mehner, Carl" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IwLqIiArdwnbQ2Ya_SGyRnmoPAE Cc: Nico Williams , "trans@ietf.org" Subject: Re: [Trans] EXTERNAL: DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 22:13:49 -0000 --Apple-Mail=_305E70B0-259D-47B5-801A-364EAB217050 Content-Type: multipart/alternative; boundary="Apple-Mail=_31956DF9-8E63-40B4-BC74-E0D2B5979FAA" --Apple-Mail=_31956DF9-8E63-40B4-BC74-E0D2B5979FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DNSSEC is certainly broken, but the solution to have a Frankenstein on = your hands isn't to staple another Frankenstein onto its body. DNSSEC insecurities and problems are well documented in the resource on = this webpage: http://ianix.com/pub/dnssec-outages.html The solution to DNSSEC is *no* DNSSEC. DNSCrypt, DNSCurve, and DNSChain = are all better solutions. Likewise the solution to X.509 PKI problems is *no* X.509 PKI. X.509 is = _fundamentally_ the wrong approach. CT doesn't fix X.509 PKI, it merely gives the illusion of a fix, and = still maintains today's global mass-surveillance state and requires = people to pay money for insecurity: http://lists.randombit.net/pipermail/cryptography/2014-April/006480.html Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also = sharing with the NSA. On May 9, 2014, at 4:58 PM, Mehner, Carl wrote: > RFC6698 says: >> This chain is required to prevent a CA from avoiding blame >> by logging a partial or empty chain. (Note: This effectively >> excludes self-signed and DANE-based certificates until some = mechanism >> to control spam for those certificates is found. The authors = welcome >> suggestions.) >=20 > I propose: >=20 > To have a DANE certificate (not signed by a public CA) included into a = CT log: > 1) a pre-certificate be created > 2) the pre-certificate submitted to a log > 3) the log will verify based on a valid DANE record of type PKIX-EE > 4) return a SCT to the submitter to include in the final certificate >=20 >=20 > Carl Mehner > 210.416.0942 > Info Security >=20 >=20 > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Nico Williams > Sent: Friday, May 09, 2014 4:31 PM > To: trans@ietf.org > Subject: EXTERNAL: [Trans] DNSSEC also needs CT >=20 > DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. >=20 > It stands to reason that DNSSEC should have similar trust problems as > PKIX. I believe it does indeed. >=20 > It follows that things like CT that we're applying to PKIX should be > applied to DNSSEC as well, where possible. >=20 > I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it > should be done. >=20 > Note that DNSSEC needs CT independently of protocols like DANE, but > any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE > effectively does) should increase the need for CT for DNSSEC. >=20 > Note too that I'm not in any way saying that DANE and similar should > block on CT for DNSSEC. >=20 > Sincerely, >=20 > Nico > -- >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_31956DF9-8E63-40B4-BC74-E0D2B5979FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
DNSSEC is certainly broken, but the solution to = have a Frankenstein on your hands isn't to staple another Frankenstein = onto its body.

DNSSEC insecurities and problems = are well documented in the resource on this = webpage:


The solution to DNSSEC is = *no* DNSSEC. DNSCrypt, DNSCurve, and DNSChain are all better = solutions.

Likewise the solution to X.509 PKI = problems is *no* X.509 PKI. X.509 is _fundamentally_ the wrong = approach.

CT doesn't fix X.509 PKI, it merely = gives the illusion of a fix, and still maintains today's global = mass-surveillance state and requires people to pay money for = insecurity:


Kind regards,
Greg = Slepak

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

On May 9, 2014, at 4:58 PM, Mehner, Carl <Carl.Mehner@usaa.com> = wrote:

RFC6698 says:
This chain is = required to prevent a CA from avoiding blame
 by logging a = partial or empty chain.  (Note: This effectively
 excludes = self-signed and DANE-based certificates until some mechanism
=  to control spam for those certificates is found.  The authors = welcome
 suggestions.)

I propose:

To = have a DANE certificate (not signed by a public CA) included into a CT = log:
1) a pre-certificate be created
2) the pre-certificate = submitted to a log
3) the log will verify based on a valid DANE = record of type PKIX-EE
4) return a SCT to the submitter to include in = the final certificate


Carl Mehner
210.416.0942
Info = Security


-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] = On Behalf Of Nico Williams
Sent: Friday, May 09, 2014 4:31 PM
To: = trans@ietf.org
Subject: = EXTERNAL: [Trans] DNSSEC also needs CT

DNSSEC is a PKI [of sorts; = please, no need to pick nits about that].

It stands to reason = that DNSSEC should have similar trust problems as
PKIX.  I = believe it does indeed.

It follows that things like CT that we're = applying to PKIX should be
applied to DNSSEC as well, where = possible.

I don't see any reason why CT couldn't be extended to = DNSSEC.  IMO, it
should be done.

Note that DNSSEC needs = CT independently of protocols like DANE, but
any protocol that allows = a DNSSEC MITM to bypass PKIX CT (as DANE
effectively does) should = increase the need for CT for DNSSEC.

Note too that I'm not in any = way saying that DANE and similar should
block on CT for = DNSSEC.

Sincerely,

Nico
--

_______________________= ________________________
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
<= /blockquote>

= --Apple-Mail=_31956DF9-8E63-40B4-BC74-E0D2B5979FAA-- --Apple-Mail=_305E70B0-259D-47B5-801A-364EAB217050 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTbVMRAAoJEOxnICvpCVJHtYgP/RIb6nGNyX90XDLxEHldrW2/ mj1X+ooz6vsyguIJh1jki3SGIMqGSXZzfa+EvGSRHnkpp0UzbrUApTFJdFyFDoPw F4F2JKwVpW71ggLe01ZkS89pUlb0cOMFA321BcXc/1SGYA3TD4oIA/VRm5wtPFXS VmcrmCxYvmW7G/AeLpzyqRBLo83TUni2by+g+lgFiXiYpGS+5VdUs7IOckS5cnea Fka8pnQYXkekTPN+YznBct8NkgRqCRscDyF3ruvvmdQz1Tgixl/OrVGak73StfHT l/jc8aDDzHK1AOm7VCbqxwaD2x/WKf1kljwLD3/L4+2TXUbTK5szEfidns+IKzbC 2XdHfQcdkecYJoAE2+1m3JfXxTJR6lns5dD/B6kScDzDJWCuE6Dx0pV9csmZ+SJq vGLKDcKYiow/g/V5Fh1nb8sypPQaKIaG/RnqVaZxod3y/G8c8UsMOVdW8QYSEd0S TqUnmwYfDvxaC1wll2KFRLtW1a4156E28FUJl9F1mzmB/IFrkjmuLqoq1sSyVJWv JxDv8ePFu8welij5KS8eH2DHEvx+RD4DX9GK1Lr4xjiNYPIB+rDq+/Pi8H5E0vC7 Y6zPkBEeeYJQKzmwAqzYYnE7ZLimXLWq6BzvNT2+nzPLte0QTndOZUtZGPic73i2 XghTBYSfAe4E2cfIkXCi =Vj2B -----END PGP SIGNATURE----- --Apple-Mail=_305E70B0-259D-47B5-801A-364EAB217050-- From nobody Fri May 9 15:52:46 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B641A0118 for ; Fri, 9 May 2014 15:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddrAnd1vAVGc for ; Fri, 9 May 2014 15:52:41 -0700 (PDT) Received: from homiemail-a8.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 32AAF1A00F6 for ; Fri, 9 May 2014 15:52:41 -0700 (PDT) Received: from homiemail-a8.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTP id 36313D22070; Fri, 9 May 2014 15:52:36 -0700 (PDT) Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTPSA id EA5ABD22069; Fri, 9 May 2014 15:52:34 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_187DF914-3AC6-450A-95D8-B10B7D2DABD4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Pgp-Agent: GPGMail 2.1 (525b9ae) From: Tao Effect In-Reply-To: <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com> Date: Fri, 9 May 2014 17:52:32 -0500 X-Mao-Original-Outgoing-Id: 421368752.664473-e23d2383c2d5259b8aa9d4f553cccd7e Message-Id: References: <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com> <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com> To: Tao Effect Support X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RCv1QhM-h96UfJx0ER3waJ7VTi0 Cc: Nico Williams , "trans@ietf.org" , "Mehner, Carl" Subject: Re: [Trans] EXTERNAL: DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 22:52:43 -0000 --Apple-Mail=_187DF914-3AC6-450A-95D8-B10B7D2DABD4 Content-Type: multipart/alternative; boundary="Apple-Mail=_8D77C2CD-15BB-4DD1-9019-EEA66A689DEE" --Apple-Mail=_8D77C2CD-15BB-4DD1-9019-EEA66A689DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Incidentally, DNSChain + DNSCrypt/DNSCurve is a simple and actually = secure solution to not just the problems DNSSEC tried to solve, but the = ones CT tried to solve as well (and without the additional problems that = CT creates anew). -- Please do not email me anything that you are not comfortable also = sharing with the NSA. On May 9, 2014, at 5:13 PM, Tao Effect wrote: > DNSSEC is certainly broken, but the solution to have a Frankenstein on = your hands isn't to staple another Frankenstein onto its body. >=20 > DNSSEC insecurities and problems are well documented in the resource = on this webpage: >=20 > http://ianix.com/pub/dnssec-outages.html >=20 > The solution to DNSSEC is *no* DNSSEC. DNSCrypt, DNSCurve, and = DNSChain are all better solutions. >=20 > Likewise the solution to X.509 PKI problems is *no* X.509 PKI. X.509 = is _fundamentally_ the wrong approach. >=20 > CT doesn't fix X.509 PKI, it merely gives the illusion of a fix, and = still maintains today's global mass-surveillance state and requires = people to pay money for insecurity: >=20 > = http://lists.randombit.net/pipermail/cryptography/2014-April/006480.html >=20 > Kind regards, > Greg Slepak >=20 > -- > Please do not email me anything that you are not comfortable also = sharing with the NSA. >=20 > On May 9, 2014, at 4:58 PM, Mehner, Carl wrote: >=20 >> RFC6698 says: >>> This chain is required to prevent a CA from avoiding blame >>> by logging a partial or empty chain. (Note: This effectively >>> excludes self-signed and DANE-based certificates until some = mechanism >>> to control spam for those certificates is found. The authors = welcome >>> suggestions.) >>=20 >> I propose: >>=20 >> To have a DANE certificate (not signed by a public CA) included into = a CT log: >> 1) a pre-certificate be created >> 2) the pre-certificate submitted to a log >> 3) the log will verify based on a valid DANE record of type PKIX-EE >> 4) return a SCT to the submitter to include in the final certificate >>=20 >>=20 >> Carl Mehner >> 210.416.0942 >> Info Security >>=20 >>=20 >> -----Original Message----- >> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Nico = Williams >> Sent: Friday, May 09, 2014 4:31 PM >> To: trans@ietf.org >> Subject: EXTERNAL: [Trans] DNSSEC also needs CT >>=20 >> DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. >>=20 >> It stands to reason that DNSSEC should have similar trust problems as >> PKIX. I believe it does indeed. >>=20 >> It follows that things like CT that we're applying to PKIX should be >> applied to DNSSEC as well, where possible. >>=20 >> I don't see any reason why CT couldn't be extended to DNSSEC. IMO, = it >> should be done. >>=20 >> Note that DNSSEC needs CT independently of protocols like DANE, but >> any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE >> effectively does) should increase the need for CT for DNSSEC. >>=20 >> Note too that I'm not in any way saying that DANE and similar should >> block on CT for DNSSEC. >>=20 >> Sincerely, >>=20 >> Nico >> -- >>=20 >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >>=20 >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_8D77C2CD-15BB-4DD1-9019-EEA66A689DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Incidentally, DNSChain + DNSCrypt/DNSCurve is a = simple and actually secure solution to not just the problems DNSSEC = tried to solve, but the ones CT tried to solve as well (and without the = additional problems that CT creates anew).

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

On May 9, 2014, at 5:13 PM, Tao Effect <contact@taoeffect.com> = wrote:

DNSSEC is certainly broken, but the solution to = have a Frankenstein on your hands isn't to staple another Frankenstein = onto its body.

DNSSEC insecurities and problems = are well documented in the resource on this = webpage:


The solution to DNSSEC is = *no* DNSSEC. DNSCrypt, DNSCurve, and DNSChain are all better = solutions.

Likewise the solution to X.509 PKI = problems is *no* X.509 PKI. X.509 is _fundamentally_ the wrong = approach.

CT doesn't fix X.509 PKI, it merely = gives the illusion of a fix, and still maintains today's global = mass-surveillance state and requires people to pay money for = insecurity:


Kind regards,
Greg = Slepak

--
Please do not email me anything that you are not = comfortable also sharing with the NSA.

On May 9, 2014, at 4:58 PM, Mehner, Carl <Carl.Mehner@usaa.com> = wrote:

RFC6698 says:
This chain is = required to prevent a CA from avoiding blame
 by logging a = partial or empty chain.  (Note: This effectively
 excludes = self-signed and DANE-based certificates until some mechanism
=  to control spam for those certificates is found.  The authors = welcome
 suggestions.)

I propose:

To = have a DANE certificate (not signed by a public CA) included into a CT = log:
1) a pre-certificate be created
2) the pre-certificate = submitted to a log
3) the log will verify based on a valid DANE = record of type PKIX-EE
4) return a SCT to the submitter to include in = the final certificate


Carl Mehner
210.416.0942
Info = Security


-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] = On Behalf Of Nico Williams
Sent: Friday, May 09, 2014 4:31 PM
To: = trans@ietf.org
Subject: = EXTERNAL: [Trans] DNSSEC also needs CT

DNSSEC is a PKI [of sorts; = please, no need to pick nits about that].

It stands to reason = that DNSSEC should have similar trust problems as
PKIX.  I = believe it does indeed.

It follows that things like CT that we're = applying to PKIX should be
applied to DNSSEC as well, where = possible.

I don't see any reason why CT couldn't be extended to = DNSSEC.  IMO, it
should be done.

Note that DNSSEC needs = CT independently of protocols like DANE, but
any protocol that allows = a DNSSEC MITM to bypass PKIX CT (as DANE
effectively does) should = increase the need for CT for DNSSEC.

Note too that I'm not in any = way saying that DANE and similar should
block on CT for = DNSSEC.

Sincerely,

Nico
--

_______________________= ________________________
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
<= /blockquote>

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

= --Apple-Mail=_8D77C2CD-15BB-4DD1-9019-EEA66A689DEE-- --Apple-Mail=_187DF914-3AC6-450A-95D8-B10B7D2DABD4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTbVwwAAoJEOxnICvpCVJHh5MP/3LS/+Yt+sukINyeK/bboY6d 0Sj1u3iRujJDerOLuaj+tGFWdOKOzcIWhSebil+UmlKlDhddj4Irxu4sSjL9E6h8 r15nF4+1+PnYWRj04GbVl2+WZGYGqTBBs9V8glHAJ2mr3LOyjQdwKBJWYNtF8r+o cQawd6Ou0lLO7nuAk1bj1CTglN7ULmNaISv1GYMUsnqMVrXqK4bEsq6ZUaNytDaQ 1fmxIf/xsZmofgpgtRfY+DEQEMZijPblAPueO5HbE7czajdCsLN7dvLf2uhqqiii urjBr3S2gIEt5LDFaP+56FN/kRJY9p6dQTTnkOmJMrjeDLPVL/TK3NHZsaJ/IHZm ctAZ0T8HCB3NK1KFG+9ozRQjIFDZO76CWRi2eUMsP+pR9mFwUlrHGyzFE62N2yIl qYoCo8tEAaAV5wHGt6mhcb0MqOA0eSuoWCaBC7QFFqoMQ0RnMfrGhB+Ym1d63IOU ZYOad8tGL3Z3ghBdE3ApqZSiUy5t2yjIHPctby2wUVbl1PqzOXQnMzkiRFdMJt6/ OpDWHQHXXa/dxrIYBAMBsXCWbFH9ehP0BtBGXVwhTaJmi38S3f4LVvy6rGqY1Ix2 8aXoVZFYE1CqmR1b+gzud8mOyzoDG7QmZzubCSzCui96JwNT3eI/xzYRK9HhCXkK 0GU6Iuoj3xIWadM2gxlD =3I5U -----END PGP SIGNATURE----- --Apple-Mail=_187DF914-3AC6-450A-95D8-B10B7D2DABD4-- From nobody Fri May 9 16:09:36 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C343A1A0114 for ; Fri, 9 May 2014 16:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334] 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 YCtD8ipNsgal for ; Fri, 9 May 2014 16:09:33 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08E1A0049 for ; Fri, 9 May 2014 16:09:33 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 63D6F31805D for ; Fri, 9 May 2014 16:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ttmqJj6J+6NTty1VyEEu EJINe2s=; b=YE6hfIs5ERpRkuf8Jqmx0q0dNxN7+vIY5sQExTnJpycczLSCl2PP D/Yd4n/iTPN5oaa3pQuRBg8r0fhHMpcFRBJmSIYhF92F1e074q3TUnFMFbagGNJ/ OPOF3bLuYxAGzGT8nDoCJnUXYuLWkw37aar5dd8j+SW5Q8xjfbhP+pM= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 175C231805C for ; Fri, 9 May 2014 16:09:27 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so4503274wgh.2 for ; Fri, 09 May 2014 16:09:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr5283468wib.42.1399676966754; Fri, 09 May 2014 16:09:26 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Fri, 9 May 2014 16:09:26 -0700 (PDT) In-Reply-To: <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com> References: <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com> <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com> Date: Fri, 9 May 2014 18:09:26 -0500 Message-ID: From: Nico Williams To: Tao Effect Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/C1iIpnpogBw3NtmRNPL6du65ybU Cc: "trans@ietf.org" , "Mehner, Carl" Subject: Re: [Trans] EXTERNAL: DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 23:09:33 -0000 On Fri, May 9, 2014 at 5:13 PM, Tao Effect wrote: > ... Noted. From nobody Fri May 9 16:12:18 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FF31A008A for ; Fri, 9 May 2014 16:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyw8fo3HWd5D for ; Fri, 9 May 2014 16:12:16 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 90F651A0049 for ; Fri, 9 May 2014 16:12:15 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so5805982lbv.7 for ; Fri, 09 May 2014 16:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MNUCYhMpfUIoIyo7oY8cTgFLGOmi1Cm628EqAXM6Pag=; b=WKhHsF2wRXaG1p+zq2E6IvyRJa/gZitNN6GXk+3SPBcNklXDtS7fhnb6BfpAEBRC/F S+PY1WvHq+ucWCajKgckL8chUOY03GR1xrtTii1PCC7Iceg1vGnjgKz0iKWLSQDWUBI1 FZjJkkXQPYsAYiOPmjMZSkS5LFlGK/0ZnLTTrlsBC9Zu8MbAfWoPN4UZyHQQ4HBA1LL6 UHF5stI8SH/iOsIVK/nbc+VvF2epj6KS1pvgNpLT0Jymh66byvhJ4E/V7pqfqPIzoYjT yls8TwaC6GrJ0bQ6hPuXuXhOcObHOTcw48oG8u+RITyNjIWl/KFMc5yXl8QEJbNJSaXV y/xQ== MIME-Version: 1.0 X-Received: by 10.152.205.106 with SMTP id lf10mr1214408lac.21.1399677129768; Fri, 09 May 2014 16:12:09 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Fri, 9 May 2014 16:12:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 May 2014 19:12:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/q854170O7wOi34DhCtFSLamNEYU Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 23:12:17 -0000 There are lots of tricky problems here. * DNSSEC assertions are time limited * DNSSEC record signatures have to be rolled up into some sort of container before they could be used * TRANS assumes X.509v3 certs. The simplest way to align things is to simply have a certificate issued for the DNSSEC zone KSK and plop that in the log as normal. The actual certificate could be self signed or signed by another hierarchy. I can't see any value in making specific requirements about the cert unless there is an ulterior motive to ram some other technology down people's throats. Which is a really bad move for trying to get adoption of a science lab stage technology. We did that with PGP (and S/MIME come to think of it). Given the Trans architecture, it probably makes most sense if someone is signing the certificate with some sort of key because the basic principle of Trans is that the log is holding the certificate issuer accountable for what they sign. But rolling up self signed certs into a trans log can also make sense. On Fri, May 9, 2014 at 5:31 PM, Nico Williams wrote: > DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. > > It stands to reason that DNSSEC should have similar trust problems as > PKIX. I believe it does indeed. > > It follows that things like CT that we're applying to PKIX should be > applied to DNSSEC as well, where possible. > > I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it > should be done. > > Note that DNSSEC needs CT independently of protocols like DANE, but > any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE > effectively does) should increase the need for CT for DNSSEC. > > Note too that I'm not in any way saying that DANE and similar should > block on CT for DNSSEC. > > Sincerely, > > Nico > -- > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- Website: http://hallambaker.com/ From nobody Fri May 9 16:27:40 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAC81A011B for ; Fri, 9 May 2014 16:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6QBEnXjFgbT for ; Fri, 9 May 2014 16:27:38 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id C36201A008A for ; Fri, 9 May 2014 16:27:38 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id E4511208063; Fri, 9 May 2014 16:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=vXNM01V8ZIhfHOwj0 OzoEV/mlro=; b=jKtXv2yxrI9R/JD8NiF79J66Wfb9difbh8YXtzojDyFD3TbVf OIItNYFWq1jrdj2F5WToRG283QhEWcCv7UcEJLgsnhy6Ncgl3inwG0DfqRGHNezW B2e0IAhacOA4oVEYKm8ZzV0F+u39ibYaXcK8z1E0S/93Yq8cGMVUgwYE6I= Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 17EAC20806B; Fri, 9 May 2014 16:27:32 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5DA8AA30-35C1-4AFB-A716-5146DEB04399"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Pgp-Agent: GPGMail 2.1 (525b9ae) From: Tao Effect In-Reply-To: Date: Fri, 9 May 2014 18:27:30 -0500 X-Mao-Original-Outgoing-Id: 421370850.719378-78ce237b620b2e7daac8b029fa492cf7 Message-Id: <2630C99C-BA80-49D3-A0BF-C93F8C88F564@taoeffect.com> References: <19075EB00EA7FE49AFF87E5818D673D41110CD50@PRODEXMB01W.eagle.usaa.com> <5241C11D-BD9B-4946-BB84-B0AE754DFA9B@taoeffect.com> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/kY2T3IyJkm86w2meFwTWw0m-52E Cc: "Mehner, Carl" , "trans@ietf.org" Subject: Re: [Trans] EXTERNAL: DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 23:27:40 -0000 --Apple-Mail=_5DA8AA30-35C1-4AFB-A716-5146DEB04399 Content-Type: multipart/alternative; boundary="Apple-Mail=_F6FC6F3D-B9E8-452B-90DA-E9D6FCC2BE86" --Apple-Mail=_F6FC6F3D-B9E8-452B-90DA-E9D6FCC2BE86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you Nico for at least noting it. ;-) This list is about making CT happen, and here I come saying that CT is a = horrible and insecure protocol. Such a civil reply is almost unexpected. ^_^ -- Please do not email me anything that you are not comfortable also = sharing with the NSA. On May 9, 2014, at 6:09 PM, Nico Williams wrote: > On Fri, May 9, 2014 at 5:13 PM, Tao Effect = wrote: >> ... >=20 > Noted. >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_F6FC6F3D-B9E8-452B-90DA-E9D6FCC2BE86 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thank = you Nico for at least noting it. ;-)

This list is = about making CT happen, and here I come saying that CT is a horrible and = insecure protocol.

Such a civil reply is almost = unexpected. ^_^

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

On May 9, 2014, at 6:09 PM, Nico Williams <nico@cryptonector.com> = wrote:

On Fri, May 9, 2014 at 5:13 PM, Tao Effect <contact@taoeffect.com> = wrote:
...

Noted.

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

= --Apple-Mail=_F6FC6F3D-B9E8-452B-90DA-E9D6FCC2BE86-- --Apple-Mail=_5DA8AA30-35C1-4AFB-A716-5146DEB04399 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTbWRiAAoJEOxnICvpCVJHpmAP/3C8Sbbb+fkpNp/FRgeMlN8h gl6JCTiLGba462xf/BUWef3CXmr0oWBt4jjqqnvl3UlcoUhrfAWEDKtf0dbAPC5K X5cF05/wcvGfSEjuHj8Uq+kUXKrc8Yc8AiSxIeBpTjEkkvTKM5JsU+goOgzFqnEL 8BYXyJ3cAMURwhgBPCUy9Ek5QAqOsK5npQW2y/7en7NfzOmQXogi7EaQ+2DxtxF4 JKScPUP2l3+0c+W9+7C3xqVNuT+VP5+iGrCh9KwLkOMAMH1//7dtbuDR4Cmj9W55 gHvszMhyU1HChW7NiUXbzXJnXu99wKc584Ul2wOxbRE5JegVaItZaeDtVqvGQcQa oUjaE2kWxj8iAgUyok9R48nWUcnII8c0mxQGzjn27HX4du/WArv7Rgrz9mgGj9Qg BI6MzlSs1Mh/KcOpdsVjDE+HRUl0KCRVQYRjSDoGlVjEWJhsK/2YysoflZBgv5jG 6L8GwTHfcAo1OXKE2bCvrI0CURa84q+2pTukpG4rgK6HNYw72GKACMiyFOC2ChV7 vFIgq0lON7gjvbVT7V4+aXdPtEOwhGDQHYX7W+CnyBb73+zbwgtngw4Sk1Ut/Vqk sQ+Q9/yyJd/kfwQdDIg17dVUrotW9lIJ1zJmVGw/U/93eu2dI1nl6qTzJhoEkKXS A0OCzyp6ddtpDL2vQiOH =opHH -----END PGP SIGNATURE----- --Apple-Mail=_5DA8AA30-35C1-4AFB-A716-5146DEB04399-- From nobody Fri May 9 16:29:19 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C801A011B for ; Fri, 9 May 2014 16:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334] 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 GbQUoNBWrtdo for ; Fri, 9 May 2014 16:29:17 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 609E81A008A for ; Fri, 9 May 2014 16:29:17 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 8DA2EB805B for ; Fri, 9 May 2014 16:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=J3y5Rz9fMhjeBfqTiaq4 oXSe9xo=; b=aOdYx9/c5bsqUASE9TFg2T6RkvMBwqpCBIhnRCz310B3R1sHkMLW WXO5w7q5ZdrAEmviGi6h87dMf8vmytrvA6D8wpkZFNcp+awX0GXvvcmyh3DI4s9r 7cHFRjih4kL+r0Q572FizGrjNJg9t5x7KZOJdKEscwxcQGtU6+1yIoY= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 3E385B8058 for ; Fri, 9 May 2014 16:29:12 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id q59so4511870wes.24 for ; Fri, 09 May 2014 16:29:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.10 with SMTP id d10mr5488299wiz.0.1399678151231; Fri, 09 May 2014 16:29:11 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Fri, 9 May 2014 16:29:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 May 2014 18:29:11 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/JPzxzCqBiBXMIxnDtW4mYFwX0Fk Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 23:29:18 -0000 On Fri, May 9, 2014 at 6:12 PM, Phillip Hallam-Baker wrote: > The simplest way to align things is to simply have a certificate > issued for the DNSSEC zone KSK and plop that in the log as normal. Sure, each zone acts as a CA for its children. That works, I think. From nobody Fri May 9 16:51:05 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063421A011E for ; Fri, 9 May 2014 16:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334] 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 VH6FMQNpPbVz for ; Fri, 9 May 2014 16:50:59 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E49E21A011B for ; Fri, 9 May 2014 16:50:59 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 0A89931805D for ; Fri, 9 May 2014 16:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=uY3dXLBgBvuiNFlsaafKEEChstw=; b=ZdxJj1SKFdG c++Iu4bgAh2Rlp7meeMM0rUcPzRkhHYKtli2DDT6hFKxt7to5evwvMLbroEDFTfj MK2x66V+OrIyVwTYegd8VfE+rDbHGxQk+DywPozjvImTCsCxzyXKJFChGXJB1ooT pUYpp0si8VNPg1n5yb4C2lY4jr+kjH2I= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id AE267318059 for ; Fri, 9 May 2014 16:50:54 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id r20so2069920wiv.13 for ; Fri, 09 May 2014 16:50:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr5338056wib.42.1399679453372; Fri, 09 May 2014 16:50:53 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Fri, 9 May 2014 16:50:53 -0700 (PDT) Date: Fri, 9 May 2014 18:50:53 -0500 Message-ID: From: Nico Williams To: Tao Effect Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/d56QpDxwmxHPRG4BdhXkM_PhE4Y Cc: "Mehner, Carl" , "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 23:51:02 -0000 On Fri, May 9, 2014 at 6:27 PM, Tao Effect wrote: > Thank you Nico for at least noting it. ;-) That's all I'll do for now. I don't have time to engage your position at this time. Surely others already have anyways. > This list is about making CT happen, and here I come saying that CT is a Right. > horrible and insecure protocol. Maybe. > Such a civil reply is almost unexpected. ^_^ By "noted" I meant to say that yes, I took note of your position but I don't want to discuss that topic in the context of "DNSSEC needs CT" -- the two matters are separable. To discuss your response in the same thread would just create noise. At any rate, I don't have time to address it separately anyways. Feel free to educate us though. Nico -- From nobody Fri May 9 17:31:53 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BFC1A013A for ; Fri, 9 May 2014 17:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-c4dXZDpMuC for ; Fri, 9 May 2014 17:31:50 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 16A781A0114 for ; Fri, 9 May 2014 17:31:50 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 35BC63BC06A; Fri, 9 May 2014 17:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=dAqICtFduTK6wfiOb hwUwakWM8k=; b=ZxuXR0G3JJ4g4AuDdx+3n/zSwGq/OsdSGA5pPkYoeB1VvmRY9 ntYuHX85oWBFFBQofHbG1+KQqJNYXl/Sk06DlFGHpoM/sudYI0EsdPRwPhISDyqB w2YpVE706xEdlSRAProVSeqYD9QiMvR9XPwv/m8LRLZYjXwLAMnRpgfu7s= Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 3BAAE3BC059; Fri, 9 May 2014 17:31:43 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_54E551C7-B4EA-41A5-BF81-465E82370333"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Pgp-Agent: GPGMail 2.1 (525b9ae) From: Tao Effect In-Reply-To: Date: Fri, 9 May 2014 19:31:41 -0500 X-Mao-Original-Outgoing-Id: 421374701.157575-34bc64d8fc668f0d9b1e0e09799a1a5b Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/cW9LceRTTikgUh8kdltjGcT5y70 Cc: "trans@ietf.org" , "Mehner, Carl" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 00:31:52 -0000 --Apple-Mail=_54E551C7-B4EA-41A5-BF81-465E82370333 Content-Type: multipart/alternative; boundary="Apple-Mail=_7A7CAE03-CF26-4BE0-8D12-FF31770FFB4D" --Apple-Mail=_7A7CAE03-CF26-4BE0-8D12-FF31770FFB4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 9, 2014, at 6:50 PM, Nico Williams wrote: > That's all I'll do for now. I don't have time to engage your position > at this time. As you say, noted. > Surely others already have anyways. Actually not really, this email, and the randombit thread that I linked = to (which didn't get a reply), has been about it. Part of the reason, I think, is because I haven't really spelled out in = detail what the problems with CT are, just alluded to them, which may = make it easy for folks to dismiss the comments as "he doesn't know what = he's talking about." It's something I just need to find the time to do. > By "noted" I meant to say that yes, I took note of your position but I > don't want to discuss that topic in the context of "DNSSEC needs CT" > -- the two matters are separable. To discuss your response in the > same thread would just create noise. At any rate, I don't have time > to address it separately anyways. Feel free to educate us though. The fact that the folks on this list are supposed to be CT specialists = makes it easier for me to write very brief critiques (without having to = explain the details of how CT works). CT is X.509 on steroids, and I mean that in the most negative of ways = possible. The crux is just this then: CT makes X.509 even more complicated than it already is. This inherently = makes it less secure than even today's already totally insecure X.509 = system (more moving parts). CT does not prevent Man-in-the-Middle (MITM) attacks. Given that the = purpose of CT is supposedly to protect from such attacks, this is = embarrassing and shameful. Expanding on 2: CT takes today's PKI and divides it up into "The Server" = (the NSA), "The CA" (the NSA), and "The Log Server" (the NSA). This is = how MITM works, it doesn't matter if the NSA doesn't actually own those = servers because they effectively do by controlling the network itself. Clients have no way of detecting a MITM attack because the RFC gives = them no such powers. If this complicated system were implemented = perfectly, then most of the security rests not on the log servers, but = on the "gossip protocols" that the RFC alludes to but does not describe. = These protocols are supposed to be described in other documents, but as = far as I'm aware they do not exist. Nor is any hint given as to their = feasibility or to how the gossip channels themselves will be protected = from MITM. CT centralizes security into the hands of a limited amount of CAs and = Log Servers that must be trusted by everyone on the internet. It = explicitly excludes support for self-signed certificates, ensuring lots = and lots of $$$$ for those that run those servers, making todays = pay-for-insecurity system even worse than it is. It effectively takes = the security of the entire internet for ransom and puts it into the = hands of government intelligence agencies and anyone else with MITM = capabilities. CT does not actually care about preventing MITM attacks and places the = burden of detecting such attacks squarely on the shoulders of domain = owners and individuals. Attacks will happen successfully CT explicitly = takes no steps to stop them as they happen. CT's very existence distracts the internet from real solutions that = actually prevent MITM attacks, are far simpler, and provide security to = everyone for ~$0. This alone makes it a significant threat to global = security. Maybe I'll post a more detailed version of this later (with citations, = illustrations, etc.). But seeing as this is a technical list, I hope it = will do for now. Cheers, Greg Slepak -- Please do not email me anything that you are not comfortable also = sharing with the NSA. --Apple-Mail=_7A7CAE03-CF26-4BE0-8D12-FF31770FFB4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 9, 2014, at 6:50 PM, Nico Williams = <nico@cryptonector.com>= wrote:
That's all I'll do for now. =  I don't have time to engage your position
at this = time.

As you say, = noted.

Surely others already have = anyways.

Actually not really, this email, = and the randombit thread that I linked to (which didn't get a reply), = has been about it.

Part of the reason, I think, is = because I haven't really spelled out in detail what the problems with CT = are, just alluded to them, which may make it easy for folks to dismiss = the comments as "he doesn't know what he's talking = about."

It's something I just need to find the = time to do.

By = "noted" I meant to say that yes, I took note of your position but = I
don't want to discuss that topic in the context of "DNSSEC needs = CT"
-- the two matters are separable.  To discuss your response = in the
same thread would just create noise.  At any rate, I = don't have time
to address it separately anyways.  Feel free to = educate us though.

The fact that the = folks on this list are supposed to be CT specialists makes it easier for = me to write very brief critiques (without having to explain the details = of how CT works).

CT is X.509 on steroids, and = I mean that in the most negative of ways = possible.

The crux is just this = then:

  1. CT makes = X.509 even more complicated than it already is. This inherently makes it = less secure than even today's already totally insecure X.509 system = (more moving parts).
  2. CT does not prevent Man-in-the-Middle = (MITM) attacks. Given that the purpose of CT is supposedly to protect = from such attacks, this is embarrassing and = shameful.
    1. Expanding on 2: CT takes today's PKI and divides = it up into "The Server" (the NSA), "The CA" (the NSA), and "The Log = Server" (the NSA). This is how MITM works, it doesn't matter if the NSA = doesn't actually own those servers because they effectively do by = controlling the network itself.
    2. Clients have no way of detecting = a MITM attack because the RFC gives them no such powers. If this = complicated system were implemented perfectly, then most of the security = rests not on the log servers, but on the "gossip protocols" that the RFC = alludes to but does not describe. These protocols are supposed to be = described in other documents, but as far as I'm aware they do not exist. = Nor is any hint given as to their feasibility or to how the gossip = channels themselves will be protected from MITM.
  3. CT = centralizes security into the hands of a limited amount of CAs and Log = Servers that must be trusted by everyone on the internet. It explicitly = excludes support for self-signed certificates, ensuring lots and lots of = $$$$ for those that run those servers, making todays pay-for-insecurity = system even worse than it is. It effectively takes the security of the = entire internet for ransom and puts it into the hands of government = intelligence agencies and anyone else with MITM capabilities.
  4. CT = does not actually care about preventing MITM attacks and places the = burden of detecting such attacks squarely on the shoulders of domain = owners and individuals. Attacks will happen successfully CT explicitly = takes no steps to stop them as they happen.
  5. CT's very existence = distracts the internet from real solutions that actually prevent MITM = attacks, are far simpler, and provide security to everyone for ~$0. This = alone makes it a significant threat to global = security.

Maybe I'll post a more = detailed version of this later (with citations, illustrations, etc.). = But seeing as this is a technical list, I hope it will do for = now.

Cheers,
Greg = Slepak

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.
= --Apple-Mail=_7A7CAE03-CF26-4BE0-8D12-FF31770FFB4D-- --Apple-Mail=_54E551C7-B4EA-41A5-BF81-465E82370333 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTbXNtAAoJEOxnICvpCVJH10cP/1EuCyGe8mRJpxK7yjdPm1kx MtYjTbIbYCZ7IjrmP+ItIoHkoq8IgVpMjSwnuEd7REcBQ2xX0DM2XRyHL9CPLobM ZauXprg1yR+uU4ZX3t7C6peIvTMicc1qZDlPqLka0pFwXB8iRwgaADwmbIjNu8Dn BL0lHo3zILoYGabN1vzMECi1TUUzOYJhL82Xs+2NfMgQLRR4QU5u+uOnRwXFmIft 7PY6cDH/9coHOnwcQqsycCB4YoC38RbuahGsYmJhZzhxb8byxBmdOb1+YrGYWdVU ayC3Z0Eq3zA67i3meA5Hd+5nC4Jq7aG86oXn28hch92fL3uQKY0HNGtxWUb1Y2qj wC1rR4XFHd+EFiq+v6t6Dr7FrUMEJ2ElzamUZkLnB9J9Uf57+vvVp6pHAoPX1Us2 H5JKu05vs4wZZ9rWd04DkvPa410+SYGUTbjvWSouKLZU0NLNvv0NFWkNPwmaXmjB 1EoAfcsWuV9oJjJ3Oi6rIP44G1lhuyRYRZ+gQxpytxym0JJcYce2VXseeEEvMdDY 2irAfTUyAzd8f5ExQGsJtDM4yCzIcMfuqxezJZ76ydqta6MkDh2vEkuENvY1Z8i1 P096e2XdTjdzcbF2DY21CHvjmdRALEaFsRcqan+N9UoWNCMH7nbwbIdVRW8OFjPn yqT0IqXKwCszCj3HBRLp =CHrt -----END PGP SIGNATURE----- --Apple-Mail=_54E551C7-B4EA-41A5-BF81-465E82370333-- From nobody Fri May 9 18:06:44 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519AE1A00DD for ; Fri, 9 May 2014 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 iLt0Wi0MtvzF for ; Fri, 9 May 2014 18:06:41 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1421A014E for ; Fri, 9 May 2014 18:06:39 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 100134012373F for ; Fri, 9 May 2014 18:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=JE/68LmD0TpDVe4+ZV98q+zdXlU=; b=nP5rdG3DMdB hMXlDL67aga4TMmGwymXfgxr2H9puabijEKiHJnpRUJGSpUVffS36KELA7KTnss8 Tq7kzkdWC1JWNJ4zImT3ZK3HdcWnXv00qGiWWP2l1GKbOccJXmgAiS1O+ARLUIMr 9IpHcHsJFkZ9CUMiIpdPhn1Qfp/4ccG8= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id B56A540123736 for ; Fri, 9 May 2014 18:06:33 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so2115707wiw.14 for ; Fri, 09 May 2014 18:06:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr5493988wid.39.1399683992567; Fri, 09 May 2014 18:06:32 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Fri, 9 May 2014 18:06:32 -0700 (PDT) Date: Fri, 9 May 2014 20:06:32 -0500 Message-ID: From: Nico Williams To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ZOHY1_nEz_qUkQbLJMqktP_CaTk Subject: [Trans] A counter-argument (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 01:06:42 -0000 A counter-argument would be that DNSSEC is like PKI with name constraints done properly, and with most domains being children of TLDs, there's really only two entities that can MITM them: the root and the TLD registrars. Therefore the risk of dishonest "CAs" is lower for DNSSEC than it is for PKI. I've seen skepticism about CT along the lines of "who will pay?" and "it's just another tax". I don't think that should be dismissed out of hand. But I do think that in the long run we should do anything that we can do and that is economical (very important, that) to make it easier to at least catch misbehaving CAs/registrars/... the jury is still out as to whether CT be economical, right? Nico -- From nobody Fri May 9 20:08:24 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDF31A01A7 for ; Fri, 9 May 2014 20:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrgkP-RO-zKC for ; Fri, 9 May 2014 20:08:14 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEBD1A01AD for ; Fri, 9 May 2014 20:08:14 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id y10so4403641pdj.32 for ; Fri, 09 May 2014 20:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Vl0TYbVdCVItm0zoc36KUSTD3k7EHGwyybLbl9XfFYA=; b=O9/F/UA5544NyBuBTIFrkIM3vShnl0SWMMVZcQLmoX2ytWQTtNnLJwGXWBa8Ohpmza DyGjxigHsWt8VIq89hjhcv7rMvJ6N3/uAGgX1TQAX/gLjxJDUgEhYbuD6bpuf/x88hwy 7pK0A4dqjQdGAzNK6fC4bUNwdRcE/nNqeyM0bZSmpEUYYrAOdrwLu0tTYFp5MdUubiCU FwwOWS67jIDGt8KeqpW7PBt5PWVYABVyxaK2OUm5BVtYXJSD1qrxsGpyqSTsKhYO+vI/ fBK/9lrf3DwT5IwiQe1Xq9GX5DJ4nQYK41njfNMKqfQsRwQgcGRmL9GTnh3UdN/Mg5nI 7FRw== X-Received: by 10.66.66.108 with SMTP id e12mr27708747pat.35.1399691288746; Fri, 09 May 2014 20:08:08 -0700 (PDT) Received: from spandex.local (63-140-99-143.dynamic.dsl.acsalaska.net. [63.140.99.143]) by mx.google.com with ESMTPSA id ss2sm15687589pab.8.2014.05.09.20.08.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 20:08:07 -0700 (PDT) Message-ID: <536D9816.1070008@gmail.com> Date: Fri, 09 May 2014 19:08:06 -0800 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: Tao Effect References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EaDbWM1Vn7O6oxLfNTyh4Th91oI Cc: "Mehner, Carl" , "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 03:08:20 -0000 On 5/9/14 4:31 PM, Tao Effect wrote: > Maybe I'll post a more detailed version of this later (with citations, > illustrations, etc.). But seeing as this is a technical list, I hope it > will do for now. Hi, Greg: This mailing list is to support the work of the trans working group rather than for general discussion of CT, and this discussion is starting to skirt the edges of what we're doing. Right now there's a proposal to look at the possibility of applying CT to DNSSEC. A general discussion of "the worthiness of DNSSEC and PKI" doesn't really go to that proposal. We kept the therightkey@ietf.org mailing list around for discussions of just this nature, and I'd be grateful if you could keep the discussion here focused on the applicability of CT to DNSSEC and take the more general discussion over there. Thanks, Melinda From nobody Fri May 9 20:37:15 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE311A011A for ; Fri, 9 May 2014 20:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwGg0nwvYz4t for ; Fri, 9 May 2014 20:37:12 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5381A0107 for ; Fri, 9 May 2014 20:37:12 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id BCD9B280069; Fri, 9 May 2014 20:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=QsthcA+/wDU3KaD5S 0352jmmePs=; b=FAyaEH5SYFRC9LvomUnJ5RZiWLaJsAv6+2QN12w1CSbB0YA/0 ZzrRqQ9Po6CzlewbOJtKX1VN6Z36Hill4/9SiWdFQ/lTSO3I9wpX+2vr0dmq2l2I uLVPpXDkzxERWztRA5xtBtoC6JA/nfwRWhij+TjY+JKqrMKYV7C25qxV6A= Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id CEEF4280063; Fri, 9 May 2014 20:37:05 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E12EA9B6-703B-497E-A165-1D48EAC1FB9B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Pgp-Agent: GPGMail 2.1 (525b9ae) From: Tao Effect In-Reply-To: <536D9816.1070008@gmail.com> Date: Fri, 9 May 2014 22:37:01 -0500 X-Mao-Original-Outgoing-Id: 421385821.345719-a679889874d787c882f2ae5e4da50588 Message-Id: <7719F0ED-7188-4B57-BEE6-245FD0314D36@taoeffect.com> References: <536D9816.1070008@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/xEZJK0nK4bPXlRj2Lem0mk6KRcA Cc: "Mehner, Carl" , "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 03:37:13 -0000 --Apple-Mail=_E12EA9B6-703B-497E-A165-1D48EAC1FB9B Content-Type: multipart/alternative; boundary="Apple-Mail=_DE2F46EB-7F4B-46A5-953B-A8A2AA85D608" --Apple-Mail=_DE2F46EB-7F4B-46A5-953B-A8A2AA85D608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Melinda, > Right now there's a proposal to look at the possibility of > applying CT to DNSSEC. A general discussion of "the worthiness of > DNSSEC and PKI" doesn't really go to that proposal. Understood! (FTR, I didn't come up with that subject title. ^_^) > We kept the therightkey@ietf.org mailing list around for discussions > of just this nature, and I'd be grateful if you could keep the > discussion here focused on the applicability of CT to DNSSEC and > take the more general discussion over there. Pointing out security and design flaws in CT is off-topic, noted, = thanks. Kind regards, Greg -- Please do not email me anything that you are not comfortable also = sharing with the NSA. --Apple-Mail=_DE2F46EB-7F4B-46A5-953B-A8A2AA85D608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Melinda,

Right now = there's a proposal to look at the possibility of
applying CT to = DNSSEC.  A general discussion of "the worthiness of
DNSSEC and = PKI" doesn't really go to that = proposal.

Understood! (FTR, I didn't come up = with that subject title. ^_^)

We= kept the therightkey@ietf.org= mailing list around for discussions
of just this nature, and I'd be = grateful if you could keep the
discussion here focused on the = applicability of CT to DNSSEC and
take the more general discussion = over there.

Pointing out security and = design flaws in CT is off-topic, noted, = thanks.

Kind regards,
Greg

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

= --Apple-Mail=_DE2F46EB-7F4B-46A5-953B-A8A2AA85D608-- --Apple-Mail=_E12EA9B6-703B-497E-A165-1D48EAC1FB9B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTbZ7dAAoJEOxnICvpCVJHynAQAI493sRRzPp0JAFyu8lCBa6i iz267gj6yuzyMFJhwdWUspJo6ew1sVhT/niXTjUtOHOoVldiAUTHFtdo+IibaL3O CtNFlETEFmJFSxGQrA5VzpeSzzK2KM04Udau+hWdoWWlIHyN9NLuJEKa4xTJw6kL jzow0rSZI70qAPM4WVU86/PwWGnV+7U21Im2SxBGaGTliYfv7VLrW+QPvOMS49mG YucH3FVb8/f8uiXneBfgll+xjqmOQGTEsZS57juEphz12xEjp2idz9Vhq3kDokoT ZHSAcItscj6/GpfkkV9VtOLic8I+/kMAfJGBMRJXE3nsgRXgnUPAZbH5DlLlFf1r tRm/G55oevAr8zJ3RIpQL3N7fgI9Vi8xWHaRUNYdqO3rnOjgMDLQnR6TadLr5DdX VeFDZVbG4h0ptIvJgSEtS0GSeuXwMadozEkQjrB8GnLJs9C1XmRO/8q97abjSRKT mkVVtibIldbydsqcSqQaGBa+HlDCWuJV5SZE8tLCPldQOnsRVpCIQHboT+guPKlk rbSwELaTPIljYMFpVnAWxSB7xNNWdvlfRZS8C0R4iaw3zNs9foNICvQFhw9zjDOd Ms47uMnErJqQ5jUKU8piLvxdS5zFWPJK3aq8In9jOebxC1KekSOcGjd0aIkCZZY0 gbFNK27SVr5XaH7/fzqb =3HMw -----END PGP SIGNATURE----- --Apple-Mail=_E12EA9B6-703B-497E-A165-1D48EAC1FB9B-- From nobody Fri May 9 20:47:29 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AFC1A0139 for ; Fri, 9 May 2014 20:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_8VczmOQFiA for ; Fri, 9 May 2014 20:47:26 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D32C1A0138 for ; Fri, 9 May 2014 20:47:26 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kq14so1013257pab.19 for ; Fri, 09 May 2014 20:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+mUhZpoAVy3bDavKK6LYajNmr5iUMCejBjoOp4RV+1U=; b=YZvCJiR6SAkyME9GUCOXO8SaMBjnjkLUS1PI+SATu7Gz5a7v2mc1VElanv0I/MePVw vwmNyrKJExdr2S3ucEwQP2+aPum9ROhQJiOCAzt5z9wW83HuSgnHKwyGakwu/RSK/0tq XY6xIX0eofNOEUm0lV7/uQdjiuV8CZQwgB44JkwiV3nAcr9mrIUqwDFwVncWrbPUbw3+ /7rX/8I+7gFcEUhzgaJ3yCn7s/bev81no1/LgyECN8GeUEw/8r1X1qwSjtLtOJXrFJzG Mz+Q/wUKoSfkpssaS16DuW8h+iALUhMnt5PBZjoK4nbqtn5l16IMi4QhMRUXEPiESOja bk1A== X-Received: by 10.66.254.3 with SMTP id ae3mr27987687pad.49.1399693641033; Fri, 09 May 2014 20:47:21 -0700 (PDT) Received: from spandex.local (63-140-99-143.dynamic.dsl.acsalaska.net. [63.140.99.143]) by mx.google.com with ESMTPSA id ja8sm10316130pbd.3.2014.05.09.20.47.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 20:47:20 -0700 (PDT) Message-ID: <536DA145.6050305@gmail.com> Date: Fri, 09 May 2014 19:47:17 -0800 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: Tao Effect References: <536D9816.1070008@gmail.com> <7719F0ED-7188-4B57-BEE6-245FD0314D36@taoeffect.com> In-Reply-To: <7719F0ED-7188-4B57-BEE6-245FD0314D36@taoeffect.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_qq2PG-6iVXjGp_Xm5OeaZ_3j0Q Cc: "Mehner, Carl" , "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 03:47:27 -0000 On 5/9/14 7:37 PM, Tao Effect wrote: > Pointing out security and design flaws in CT is off-topic, noted, thanks. Yes and no. We produce documents. There's a working group draft in development, and if there are problems with that draft there's no time like the present for starting a discussion and proposing text. There's also the beginnings of a discussion about whether or not to take on the development of a document on CT for DNSSEC. If there are specific issues those need to be brought up as well. But we've got another mailing list for higher-level discussions of how to deal with certificate misissuance and it's a good place for CT discussions that don't directly address the working group's products. Melinda From nobody Fri May 9 21:08:14 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6343E1A0139 for ; Fri, 9 May 2014 21:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pSuxvl9SDUX for ; Fri, 9 May 2014 21:08:09 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 23E871A0141 for ; Fri, 9 May 2014 21:08:09 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 0176F25C063; Fri, 9 May 2014 21:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=IpuRs4h2EaUhLhFUE CX77IkBTDE=; b=FO2FQQGm5rxvTO2sJj+SN78pwwXxWmFEjAAghquXb/9nFo7fv qG0zrkXJMTwDxvpPRygDvyK8998cNskyqvKQt2V4HGuDKnt//h67c7f/obyM2BuD ER6mTowO9/VU9j6Vs7VV11bkHcnF1Kj+/Fd3CnWMD3fpnavQVyL2FZe3pU= Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 6F3DE25C062; Fri, 9 May 2014 21:08:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_715EFE23-A93A-4197-8860-FA7DD7605A51"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Pgp-Agent: GPGMail 2.1 (525b9ae) From: Tao Effect In-Reply-To: <536DA145.6050305@gmail.com> Date: Fri, 9 May 2014 23:07:58 -0500 X-Mao-Original-Outgoing-Id: 421387678.321059-4e91f3b100c8c4accb7275b0dfc7c155 Message-Id: References: <536D9816.1070008@gmail.com> <7719F0ED-7188-4B57-BEE6-245FD0314D36@taoeffect.com> <536DA145.6050305@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5i0KHm3EHjLQoHsTn9K4a4loY_Y Cc: "Mehner, Carl" , "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 04:08:10 -0000 --Apple-Mail=_715EFE23-A93A-4197-8860-FA7DD7605A51 Content-Type: multipart/alternative; boundary="Apple-Mail=_184C2202-D20A-4C8E-ABE2-592A17692C02" --Apple-Mail=_184C2202-D20A-4C8E-ABE2-592A17692C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 9, 2014, at 10:47 PM, Melinda Shore = wrote: >=20 > Yes and no. We produce documents. There's a working group > draft in development, and if there are problems with that > draft there's no time like the present for starting a discussion > and proposing text. ... OK, I think I did Step 1: "starting a discussion" about the problems = in CT. Is Step 2: "proposing a modification to the RFC that fixes those = problems"? What do I do if the problems are fundamental to the design of CT and the = solution is to do something else? Is there an IETF process in place for "The work we're doing would harm = the Internet so maybe we should stop?" > But we've got another mailing list for > higher-level discussions of how to deal with certificate > misissuance and it's a good place for CT discussions that don't > directly address the working group's products. Wasn't the point of CT precisely to "deal with certificate misissuance"? That is to be discussed in a list that is not specific to CT though? Apologies for all these questions. I'm just confused by the rules of = this list. -- Please do not email me anything that you are not comfortable also = sharing with the NSA. --Apple-Mail=_184C2202-D20A-4C8E-ABE2-592A17692C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 On May = 9, 2014, at 10:47 PM, Melinda Shore <melinda.shore@gmail.com> = wrote:
Yes and no.  We produce documents. =  There's a working group
draft in development, and if there are = problems with that
draft there's no time like the present for = starting a discussion
and proposing text.

... OK, I think I did Step = 1: "starting a discussion" about the problems in = CT.

Is Step 2: "proposing a modification to the = RFC that fixes those problems"?

What do I do if = the problems are fundamental to the design of CT and the solution is to = do something else?

Is there an IETF process in = place for "The work we're doing would harm the Internet so maybe we = should stop?"

But we've got = another mailing list for
higher-level discussions of how to deal with = certificate
misissuance and it's a good place for CT discussions that = don't
directly address the working group's = products.

Wasn't = the point of CT precisely to "deal with certificate = misissuance"?

That is to be discussed in a list that is = not specific to CT though?

Apologies for all these questions. I'm = just confused by the rules of this list.

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

= --Apple-Mail=_184C2202-D20A-4C8E-ABE2-592A17692C02-- --Apple-Mail=_715EFE23-A93A-4197-8860-FA7DD7605A51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTbaYeAAoJEOxnICvpCVJHXM0P/30awvjlOp7iVjCJo2f2I5aC ZIwDybMseT+NnDXyCk6gGyQ3iUFXgQUhYP6CFNYKXJwsXT7TX9bQNpOox6co+Zs0 TnU7nteRpgwkpJjNIOa9YXWP8MTTAmAGNpdHSttLiQ8CryyJ5uuB8Dmjpqu8Bybm ff+dyazYqN8pVoyDlzvfQEB3gF5/tkyIWzrFAeI2FW7Ng/4vwK/sNEc5m1aJ424j Nps9PHKEb3ufnzdilQYj6mkVrsENhEOGeCLeb7+zSOC7EEEP2l/fRO4nP4lJS9v8 kdXSQz2bQC4ivZ5lTa+DZdFQTVCimwTM/gH2Y+9UAegP4dlMIT/esxkE4mn1raqK gpyh9k3MBcRJte3O5Was2rt/yOs6H7SINSqnRx8rvT0DoSOk159pJbwUSTZkQZhz 7y6V0fNtA8i4FvnMWzu91H7trt4l+0SUGf26XAFt3qBbfdDby5VbK0hxVCKIjEJf 45UD+4KGNa8baqpMwaTO63FG6WOQnS7BxQZB5RhEm2gSZgrRZ0lZWQmnsZhriRCX Ax8Ycb4udcAD6ekmZIhFjezCSiecniuGCTXWfOZdj7yEvz0sjVr2/WErYmpy/227 l26tHC92nqFZ/1BaWyLeoJC7BSF9A6vaF59pFIgEKIj2slaO11UUGe0lzcI3ImXA RAltmX6kMGDcHo9jMTlG =Z5UB -----END PGP SIGNATURE----- --Apple-Mail=_715EFE23-A93A-4197-8860-FA7DD7605A51-- From nobody Fri May 9 21:37:34 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711581A014D for ; Fri, 9 May 2014 21:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OQq848hVrV3 for ; Fri, 9 May 2014 21:37:31 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D33FA1A010F for ; Fri, 9 May 2014 21:37:31 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id v10so4506941pde.27 for ; Fri, 09 May 2014 21:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vt8XYAVSGhq58Li9+JHWZOW9qfYwfIHOI4ruC0bDrXA=; b=xEJH0TmCCRe5LjoaJDS/DQgcrYdC314gkgJAD7yY2HHY8uz/HnocGhSe+/Ogs0iSU7 PLFwxbPIY7pO3/mFkG+qSSaIPF+98l8nHEzJ+zn74wGA5xGJTcqh2oX7ZzzIg0BNS8ZR bgFeqbxdI12zbFXrh4sQwymTZ3cQWoYuHA7I7HxibqOHLGKFECjKg3i8bu/88wK4YlLi Wx33VgsFICfpgX8Gi1oU+rIg3VRQCir0RtnFiN8u8l0977QurriLBNjHjoNGjRKQ4fXa gMd9cwy0VYDi1npjxHrNkEUJA2SkC7EJRrx1lM7S17UiyxmQ0xaudOIdHsWF4imR8Te8 N5VQ== X-Received: by 10.66.254.198 with SMTP id ak6mr16700925pad.156.1399696646372; Fri, 09 May 2014 21:37:26 -0700 (PDT) Received: from spandex.local (63-140-99-143.dynamic.dsl.acsalaska.net. [63.140.99.143]) by mx.google.com with ESMTPSA id xg4sm10466289pbb.47.2014.05.09.21.37.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 21:37:25 -0700 (PDT) Message-ID: <536DAD03.6000608@gmail.com> Date: Fri, 09 May 2014 20:37:23 -0800 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: Tao Effect References: <536D9816.1070008@gmail.com> <7719F0ED-7188-4B57-BEE6-245FD0314D36@taoeffect.com> <536DA145.6050305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/iy_Xee14aOYruqx-aBW_Gv5drHM Cc: "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 04:37:33 -0000 On 5/9/14 8:07 PM, Tao Effect wrote: > ... OK, I think I did Step 1: "starting a discussion" about the problems > in CT. Right. That's actually off-topic - if there are specific problems in the working group draft, that's a great place to start a discussion. More general discussion of problems with CT would be on-topic for therightkey@ietf.org. Also, to be clear, we are not going to rathole on this. Melinda From nobody Sat May 10 02:39:11 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F396D1A0209 for ; Sat, 10 May 2014 02:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mul_DgSklZM for ; Sat, 10 May 2014 02:39:06 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 19A291A0208 for ; Sat, 10 May 2014 02:39:05 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so4851033wes.41 for ; Sat, 10 May 2014 02:39:00 -0700 (PDT) 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=Q/6OfjpRv+zlu0x9oXvza5CFBkKgoqtdSJAaNyeh/k4=; b=RyONXTkiN4KhqKdu9ENatulncwV7FzGUF2wGU/IIAFBBQ3kmLcF2RXbZ6INq4E50Xw 8xDRIuFj7J09YIsJFALPhcbb0FUF1pZbwz40oQBz63Dus8QM1F79nvCVvvNe/WEN53S4 1tZ6isBYPaeI32UNPgLgtB7jXq9m//y5UzsOUzDJRqnGRmnXvK5rP0zhHqN5HjQoUCff SdHS9xOu7I0yd85AMgiHicrhKkDpOvcSgnxzeu3uSEhUCci5fxky3sI9n8Y8d49GH0gz 5NA74wvqK01M92EesF/mGF1XjKiZbhfztSnvU6/nHtu1vvP69pyMeCoFYmK+/IvlP1hO 9THg== X-Gm-Message-State: ALoCoQk/lvKUgAIqhN4qynkWOE6YzGPVqnIVsta17Dz0SKrlf7lzyih/6cfR1MQTCGiq0BlWJhZ3 MIME-Version: 1.0 X-Received: by 10.194.91.175 with SMTP id cf15mr12459558wjb.5.1399714740034; Sat, 10 May 2014 02:39:00 -0700 (PDT) Received: by 10.194.62.70 with HTTP; Sat, 10 May 2014 02:38:59 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 May 2014 05:38:59 -0400 Message-ID: From: Warren Kumari To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/zY-dgRWsxBwyVH7KqPEUn4PIlDs Cc: "trans@ietf.org" , Phillip Hallam-Baker Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 09:39:08 -0000 On Fri, May 9, 2014 at 7:29 PM, Nico Williams wrote: > On Fri, May 9, 2014 at 6:12 PM, Phillip Hallam-Baker wrote: >> The simplest way to align things is to simply have a certificate >> issued for the DNSSEC zone KSK and plop that in the log as normal. > > Sure, each zone acts as a CA for its children. That works, I think. I have previously had some discussions about including DNSSEC / DANE / self signed certs -- one of the objections / concerns was the threat of someone DoSing the logs by making up data (there is a cost to a CA cert, but I can create an infinite number of TLSA records or self signed certs). The main incentive (that I can see) to DoS the logs would be for the lolz[0], and so (IMO) the protection does not need to be very strong - having someone have to solve a captcha or make a small payment (could become a donation) would be enough. W [0]: Unless you could kill off CT completely / make browsers stop requiring it (and so allow someone to use an incorrect (misissued) cert) I cannot see a financial incentive for anyone to do this. > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Sat May 10 03:30:56 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9696E1A0210 for ; Sat, 10 May 2014 03:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZfwc5znwdyG for ; Sat, 10 May 2014 03:30:53 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB79D1A020E for ; Sat, 10 May 2014 03:30:52 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so2421366wib.17 for ; Sat, 10 May 2014 03:30:46 -0700 (PDT) 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=Zk5yOn9pHHyUrvGsteQIeOogHLjOh7lhXH7PHGuVgKg=; b=VV1O5w3Zq+rcs1dadsoxBsEjkgHwlQ27mI1143YMmOKmzamcroySDOY7blKCkcXR+b nlS8WnKcar15QiV24KLeP2Hm9LsCMiFcDVThvWLK/TUuK/rffwrRwBtUVQp4LP7jHU8Z oFLXgWsXh/YgvupAhMhG2J8WL1ljWeQykDYXVMKtVlQCCXAobodF2MG53Riz3RSpdA2x dReqgQ7L8CyGdTtNXbL3iJMVzI78/Lq39+9SnWZQNaiphycQHIvVLgd10ybBUSuRYX5d FvvZ+oWi/dZfIlmzap0/Zksch09/IWk6ihjsV83hpMqyIu+AtzFJXIeAP/Cm+sRjmcy+ qT0w== X-Gm-Message-State: ALoCoQm0NyEIE+S9WAE1rofGc+Qyul0/XzeyZ+A8kau79+ZrYRPlK+getuTG2Y32sW0GAD1l9B4i MIME-Version: 1.0 X-Received: by 10.194.84.101 with SMTP id x5mr1250532wjy.52.1399717846746; Sat, 10 May 2014 03:30:46 -0700 (PDT) Received: by 10.194.62.70 with HTTP; Sat, 10 May 2014 03:30:46 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 May 2014 06:30:46 -0400 Message-ID: From: Warren Kumari To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7Zi-FTbaTbEAknUTxP5RR3kvGfY Cc: "trans@ietf.org" Subject: Re: [Trans] A counter-argument (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 10:30:54 -0000 On Fri, May 9, 2014 at 9:06 PM, Nico Williams wrote: > A counter-argument would be that DNSSEC is like PKI with name > constraints done properly, and with most domains being children of > TLDs, there's really only two entities that can MITM them: the root > and the TLD registrars. ... and the (outsourced) DNS operator and the DNS parent(s) / registry.. This is also the set of folk who can update / return other answers for MX queries, and so, if willing to dink with stuff, could obtain a domain validated cert. I suspect we may be getting somewhat off topic for Trans, and into discussions we have had a number of times on the DANE list... W > > Therefore the risk of dishonest "CAs" is lower for DNSSEC than it is for PKI. > > I've seen skepticism about CT along the lines of "who will pay?" and > "it's just another tax". I don't think that should be dismissed out > of hand. But I do think that in the long run we should do anything > that we can do and that is economical (very important, that) to make > it easier to at least catch misbehaving CAs/registrars/... the jury > is still out as to whether CT be economical, right? > > Nico > -- > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Sat May 10 07:52:32 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7154E1A025C for ; Sat, 10 May 2014 07:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzox5OFPe9PF for ; Sat, 10 May 2014 07:52:28 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7461A0020 for ; Sat, 10 May 2014 07:52:28 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A305B165ADC; Sat, 10 May 2014 14:52:22 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 97BD9165ACD; Sat, 10 May 2014 14:52:22 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 6C5B298069; Sat, 10 May 2014 14:52:22 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sat, 10 May 2014 10:52:22 -0400 From: "Salz, Rich" To: Tao Effect , Melinda Shore Date: Sat, 10 May 2014 10:52:17 -0400 Thread-Topic: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) Thread-Index: Ac9sBXTyWYWvBBe+TuG/p9zvq8w2nQAWdw/Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13ECA0@USMBX1.msg.corp.akamai.com> References: <536D9816.1070008@gmail.com> <7719F0ED-7188-4B57-BEE6-245FD0314D36@taoeffect.com> <536DA145.6050305@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130A13ECA0USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wsimBc25tPe6aWY0fQj06nWi6B0 Cc: "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 14:52:30 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130A13ECA0USMBX1msgcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 What do I do if the problems are fundamental to the design of CT and t= he solution is to do something else? Write up your own document and circulate it. I'll be happy to give you som= e pointers to the second part, once you have the first part. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130A13ECA0USMBX1msgcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  Wha= t do I do if the problems are fundamental to the design of CT and the solut= ion is to do something else?

 

Write up your own docum= ent and circulate it.=A0 I’ll be happy to give you some pointers to t= he second part, once you have the first part.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>--=A0

Principal Sec= urity Engineer

Akamai Tech= nologies, Cambridge, MA

IM= : rsalz@jabbe= r.me; Twitter: RichSalz

 

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130A13ECA0USMBX1msgcorp_-- From nobody Sat May 10 14:31:34 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156A11A00E8 for ; Sat, 10 May 2014 14:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvGMni23-foC for ; Sat, 10 May 2014 14:31:28 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEEA1A00DE for ; Sat, 10 May 2014 14:31:28 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8EC2881703; Sat, 10 May 2014 17:31:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399757482; bh=5j+PDVPGakhqWjNauxedrHQOKOkqbcQWjFMWYqbOQxc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=T6DyLKTVWe+KYK0mfzLwbBhWPfDFTJ8fElZb09iePS2HhR1vVUFma7aOkpZJmdF8m 4EhHDBnP6z8H9D9t6noYcOf+cfYB0NnvP0duQlg3WfKEa79wA5xDTVgZk2e55zdX/W Yv+6Q7geeSx01b8D7woAdDF8aRHoDvIomZz43LOw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4ALVMvn004379; Sat, 10 May 2014 17:31:22 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 10 May 2014 17:31:22 -0400 (EDT) From: Paul Wouters To: Warren Kumari In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/kQYTVZCTgZNgUm2avNZN4PCls5k Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 21:31:33 -0000 On Sat, 10 May 2014, Warren Kumari wrote: > On Fri, May 9, 2014 at 7:29 PM, Nico Williams wrote: >> On Fri, May 9, 2014 at 6:12 PM, Phillip Hallam-Baker wrote: >>> The simplest way to align things is to simply have a certificate >>> issued for the DNSSEC zone KSK and plop that in the log as normal. >> >> Sure, each zone acts as a CA for its children. That works, I think. The problem with that approach is that it does not make DNSSEC distinct from the existing CA PKI. It will also not remove the cost factor of getting a DNSSEC "certificate" from a "certified" CABforum member. > I have previously had some discussions about including DNSSEC / DANE / > self signed certs -- one of the objections / concerns was the threat > of someone DoSing the logs by making up data (there is a cost to a CA > cert, but I can create an infinite number of TLSA records or self > signed certs). Cost should IMHO not become a verification factor. That's the whole reason https hasn't been universally deployed to begin with. We should not make the same mistake with DNSSEC. > The main incentive (that I can see) to DoS the logs would be for the > lolz[0], and so (IMO) the protection does not need to be very strong - > having someone have to solve a captcha or make a small payment (could > become a donation) would be enough. Or just say that anyone who puts in more than X amount of DNSSEC CT entries underneath themselves must run a public CT node themselves. So if nohats.ca want to get more then X entries, or one of their subzones/customers wants more than X entries, either they or their subzone/customer will have to run a fully functional CT node. And if the node goes down, their new entries will be refused. Paul From nobody Sun May 11 07:40:51 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCE11A025D for ; Sun, 11 May 2014 07:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0LX7AZE9pvZ for ; Sun, 11 May 2014 07:40:41 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 88E5D1A0225 for ; Sun, 11 May 2014 07:40:41 -0700 (PDT) Received: from [192.168.1.211] (fluxo.info [201.27.11.148]) by che.mayfirst.org (Postfix) with ESMTPSA id 6657CF984; Sun, 11 May 2014 10:40:23 -0400 (EDT) Message-ID: <536F8BC4.5070405@fifthhorseman.net> Date: Sun, 11 May 2014 11:40:04 -0300 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Paul Wouters , Warren Kumari References: In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7ICnWfun8VottXnugAD5AbbK8hn8RWAL3" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mc9I6LZ29__RvZG76GkvWFGWZEQ Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 14:40:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7ICnWfun8VottXnugAD5AbbK8hn8RWAL3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/10/2014 06:31 PM, Paul Wouters wrote: > On Sat, 10 May 2014, Warren Kumari wrote: >> The main incentive (that I can see) to DoS the logs would be for the >> lolz[0], and so (IMO) the protection does not need to be very strong Do not underestimate the appeal of the lulz for some people. > Or just say that anyone who puts in more than X amount of DNSSEC CT > entries underneath themselves must run a public CT node themselves. So > if nohats.ca want to get more then X entries, or one of their > subzones/customers wants more than X entries, either they or their > subzone/customer will have to run a fully functional CT node. And if > the node goes down, their new entries will be refused. This sounds expensive to verify, and still a bit unclear to me. do you mean that nohats.ca would need to run its own log for its own zone? At the moment, we're not expecting the authorities to run their own logs -- this seems like a change in semantics and control. clients would also need to know to switch over to another log in that case -- how would that be done? What kind of limits would this architecture place on undetectable misissuance? Or do you mean they would would need to contribute to the CT architecture in some other way? Tthis question is related to the (currently idle) DBOUND discussion [0] and (currently) the public suffix list [1]. If we can draw a line between public registries (which need to be held publicly accountable) and private zones (which in many cases may prefer to avoid full zone enumerability that comes with CT) then we can just ensure that CT-style audit logs apply only to the public registries. Public registries themselves have some interest in limiting pollution, and usually a revenue stream that scales with the size of the registry. These are properties that we might be able to align with a logging infrastructure. So the idea is that for DNSSEC: the root zones and the TLDs (or TLD-equivalents) would get CT-like logging, but children of those zones (as you cross into a private administrative zone) would *not* get CT-like logging. I'd be curious to hear what other folks think about this balance, and what it would take to draw that line cleanly. --dkg [0] https://www.ietf.org/mailman/listinfo/dbound [1] https://publicsuffix.org/ --7ICnWfun8VottXnugAD5AbbK8hn8RWAL3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTb4vEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc32UQAOjXjLksJQk4PSfsRdjTt/s3 L/hUfI49BGWQbrMbq3XNYjU/53vbSdOWYBVtLhLNsuEXqkzSdx9FbzRL9zbtnHAw xK4tlbbf4IyJT1HYQlzGeTrdxGa7TARGBz2eFKuugKIdGfhrfF8h6/3R3xcG0TZT 3jNNrEDJZ58RYjRwCwnzsoVxIdFV91D0IGSflu9ZSHOjNLzF5z/Z1G/o01vTbQIW qSOIbhWAtfXrJX/aFQBOvTplYwJdLyj/Jp7++P7izqWggjFh19PMTf474pPUqx0Z c3XASeBFBit195Fmh0WGdTsojOlkwXDv0yBOq5nJqeFLnB9cfkyPez9X62Phh+O2 LBWk7mfPrr+Ygou5tDFU8WGJYQPDezuN0CfZi0itAhck7dZkZaKeW/ONp5cb8yXr T0hUi25QY3UC9m7YNgXvE5M3/28YUUOxXRCH8zzj3pkZsuJIq4PnzW6nqQP8/Wcs 28LCvRFp6jFQjr++SEU0ScNPy4Yv1mh8uifBFVIhKGz5mBlboZmExrIPF1SJ1N4s iL8zw+GE+HoO5Y8UvdXFel3PG9DMUwjT1lIpz2NBnMqA+I6KEnnrcgOLdBE1tZwk hDO18+LCoFWDaB+UxY9RfGTf/kCgr9AYVm8KJxCYjNAv84tAq7BrEUY6v8Yr01x1 08QJhjzuL9VOGVr0uifS =49vR -----END PGP SIGNATURE----- --7ICnWfun8VottXnugAD5AbbK8hn8RWAL3-- From nobody Sun May 11 08:21:25 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665771A0258 for ; Sun, 11 May 2014 08:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=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 7DvXe0ztYL3C for ; Sun, 11 May 2014 08:20:24 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E99861A0259 for ; Sun, 11 May 2014 08:20:23 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so5911503wgh.29 for ; Sun, 11 May 2014 08:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lA5XAm0f8cQP9lf+J3mf2zBQu4Ql/RmmjWqv4p+bb3g=; b=PdmzUo9GxtguYroTNAFXkRYLx/rXzJdz1Su/NAE2D2YU4mlHPrvkuGPS45wNiVLTx2 2OQo0xnzsEjCIa2fwZt9NLjdqJkZ+7c3Tuso6EJaBvr5XCyalbTtuVnquxoMk8j4qdx1 H0H0kyCSodSa7QFnNoxK4+GCRxcg70aHNFp2mRzvYXUmfgCg7O0bUquI7nYyUGRk3aUv s1bUb9uyeD3i06PKS0ZEihxpEsyKa8i4nxkZ8N3ptFQ+j90XYau3sNBVGN0CE9/5FxJr pojnNHjPEtem0Ne/6SOOCSF7B3ooLZQ4cnsxLHlLtHKOihJC2DT0Yu0cZzn0Aql3wmy8 BQmg== MIME-Version: 1.0 X-Received: by 10.180.105.72 with SMTP id gk8mr11759124wib.32.1399821617801; Sun, 11 May 2014 08:20:17 -0700 (PDT) Received: by 10.194.157.9 with HTTP; Sun, 11 May 2014 08:20:17 -0700 (PDT) In-Reply-To: <536F8BC4.5070405@fifthhorseman.net> References: <536F8BC4.5070405@fifthhorseman.net> Date: Sun, 11 May 2014 11:20:17 -0400 Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/lzSjPmPkfAkYaOm5Oep6HojPooE Cc: "trans@ietf.org" , Paul Wouters , Warren Kumari Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 15:20:31 -0000 What I think this discussion is really uncovering is that we don't really have a model for how CT is applied to WebPKI certificates. All the questions raised in the DNSSEC discussion seem to be predicated on assumptions as to how CT logs are managed that are outside the spec. Which is why having the DNSSEC discussion now is useful. I don't like specs that are based on unwritten assumptions. That leads to a situation where implementations have to understand folklore. In particular, does CA = log maintainer? For DNSSEC there seem to be a lot of unnecessary assumptions being made. I certainly don't think everyone wants to run their own CT log for DNSSEC. And there would be little value in the scheme if they did. The value of a CT log depends in part on aggregation. Another unnecessary assumption is that any log maintainer would have to be a CABForum member. Membership in the forum has no impact on root inclusion or CT. The only requirement for root inclusion is acceptance by the root maintainer, most of which adopt the CABForum EV and BR criteria. The most important part there being audit. It is probably fair to assume that CT logs will be maintained by CAs but it would be entirely practical for an open service to be established. The criteria are rather simpler to enforce than certificate issue. It might or might not be desirable to require some sort of certificate chain to some sort of root. But any such chain does not need to be the only validation chain PKIX supports cross certificates and an end-entity certificate may be legitimately accredited to multiple roots. The main question is what purpose a CT log for DNSSEC would serve. For me the value would be to protect my domain against having it stolen by ICANN. The idea that we should put trust or faith in an organization extorting $250,000 for domains is ridiculous. And so is the fact that IESG members have told me that they don't think they should make that kind of comment even if true because of 'politics'. If you don't like your WebPKI CA then you can get another. And that means the costs are competitive. But ICANN has a monopoly and a rent seeking management. Deploying CT to establish an independent claim on the domains makes perfect sense. From nobody Sun May 11 08:38:23 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095721A0338 for ; Sun, 11 May 2014 08:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxGD9PplMQoB for ; Sun, 11 May 2014 08:38:06 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 208801A0261 for ; Sun, 11 May 2014 08:38:06 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 390E281703; Sun, 11 May 2014 11:38:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399822680; bh=nxJ6Gs9zyqGS8OsQ8AiUYFST5ICKzF0R2WcgiBcJ5YQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RGGko/VKYhftK4SJvrcaBPswLUHVulTp4CVal6VJwR781erbg4Pio+igJN/AsXyBi bWD/Gk1bFWg+qVHZMjsDQYrTy1IRhZE0QsGmkJtaaDXvqe2gKz8LQoV+dSQEwnNqaG AGvXnUTJySynSGsmyevlAPk7q+oHUse+XurE+/Zk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4BFbxnb032714; Sun, 11 May 2014 11:37:59 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 11 May 2014 11:37:59 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <536F8BC4.5070405@fifthhorseman.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Hr80lu-aBr2dk6Z9PXlnRAsQFrw Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 15:38:08 -0000 On Sun, 11 May 2014, Phillip Hallam-Baker wrote: > It is probably fair to assume that CT logs will be maintained by CAs That would be a non-starter for those people (let's call them the defcon crowd) who are looking at dnssec as a way out of the trust in a handful of CAs or TLD operators. > The main question is what purpose a CT log for DNSSEC would serve. For > me the value would be to protect my domain against having it stolen by > ICANN. Or any of the parental zones above your own zone. Paul From nobody Sun May 11 10:14:00 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9BC1A0267 for ; Sun, 11 May 2014 09:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqyqbj5cE_Gs for ; Sun, 11 May 2014 09:49:51 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 085B31A0266 for ; Sun, 11 May 2014 09:49:50 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so5961180wgh.29 for ; Sun, 11 May 2014 09:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OQ7mnFElna7D49wamo6ldIg2FFut26aUdbIpoNVK0H4=; b=shPnGhIdwPW075fuibfU0dIjG9MGCDTRUAuNKP//JS6yVYafnfzU4Xds2erf+7r13p JpgbTI6clCY/4AUTffSUouVvGmE3YCOt26sAuk0q+OORORLpJhJ6O3VwM0w9iIyskq+p YNn/AaOwzeWB2XCq8lylSoRnj+7C6Bj9U78SbGwRGbbUPj2hjFDdN7a9UwlcgtlJ4nJH m2eZ7piyU1BXutA4IJEQZrZMAS7nhFYwuxyq5esuAiKt3TCW98+FHMbUWNiXsKzHCFX1 Gh2aVCs92kd75vrR/YShXPW5h3xu1FhZXjEEqXpluBoEoSxCT4iTswlH2rUCI/8RqHlu 2b3A== MIME-Version: 1.0 X-Received: by 10.194.92.81 with SMTP id ck17mr17829384wjb.14.1399826985006; Sun, 11 May 2014 09:49:45 -0700 (PDT) Received: by 10.194.157.9 with HTTP; Sun, 11 May 2014 09:49:44 -0700 (PDT) In-Reply-To: References: <536F8BC4.5070405@fifthhorseman.net> Date: Sun, 11 May 2014 12:49:44 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ULWQgRBXCL04qx_pfF_UstIf-jY Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 16:49:52 -0000 On Sun, May 11, 2014 at 11:37 AM, Paul Wouters wrote: > On Sun, 11 May 2014, Phillip Hallam-Baker wrote: > >> It is probably fair to assume that CT logs will be maintained by CAs > > > That would be a non-starter for those people (let's call them the defcon > crowd) who are looking at dnssec as a way out of the trust in a handful > of CAs or TLD operators. As I went on to say: "It is probably fair to assume that CT logs will be maintained by CAs but it would be entirely practical for an open service to be established. The criteria are rather simpler to enforce than certificate issue." I don't see the CAs running CT logs as being necessarily exclusive. In particular, running a CT log does not require audit which is the difficult part of being a CA. The whole point of transparency is that the operation of the log does not need a trusted auditor with special access. Anyone can audit the operation of the log. Now what the non-CA application does call for is thinking through a lot more of the operation of the logs and how they are held accountable. >> The main question is what purpose a CT log for DNSSEC would serve. For >> me the value would be to protect my domain against having it stolen by >> ICANN. > > > Or any of the parental zones above your own zone. True and that concern has already been an issue with zones such as vb.ly which was grabbed back when the value of the zone was realized. -- Website: http://hallambaker.com/ From nobody Sun May 11 14:33:00 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843B41A0368 for ; Sun, 11 May 2014 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 iC7dRh43T6Uq for ; Sun, 11 May 2014 14:32:54 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id F14061A0366 for ; Sun, 11 May 2014 14:32:53 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lg15so7696945vcb.7 for ; Sun, 11 May 2014 14:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QFcaYSI4YmaOlZm5I8fUSEmaHnl4xlVmdGfZ0/CJlg8=; b=XI90QVEzlqPdBnWZQgYbcukJixRKMDJR5jT897K10f9x7ZgdZDzYM/GtuvjTfLI5gk IPwCMtlKoowwAoiNjNLSmf8/KP5yAroo+/Ku/gqWu0QoPjqhy9hfMY/YcEsTuEXOWLBn 3PRhxMohC3tD+E8XrPtcBBKOd+awnn/iUgeJqdkIU7SxnXSwPesWyX71C+qjR03fD1+K RdZ8uy0rowBP5OAFU2xZUbNxLP1QVnYYmrbbuyhc2hx+WkjsZ+pomuKCeCjgwjCjkIa9 rlSkrNZlGt/Vl3pOCymmOVT5bvEBkEivtf7CIiT4vOgbvpBt6GH7FzeoZio5gWJxhXTU egXw== 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=QFcaYSI4YmaOlZm5I8fUSEmaHnl4xlVmdGfZ0/CJlg8=; b=MpvB50O2Nka1bNi/Nvsa0wIoy0HcDqsc7eSd7tkiO2o2/Ln5+gK2dwwDcpAckYawBw F4V3/P84mMncF5muPpili8W5jhDSeHrefrcQscowjDM4OhmJOT74nsKFZyFZyKQtN0Cj 2nKQWbl/zKvJgeQtCTip/wgfXSFhqGpGnBTWuodpOK+gilZgO+WoBU2aqRQ7FCi6/fK5 8FxST+CbAcVVY6/oDLlaqGLU+ejndtscqYFZ2GPT/kst0Nihtr2GHrMiyC7qRduiT5v7 xOfIg7unuGO89ypkgdrTOBZrJtbLHDm2BkFBEKqWLqrIYLa73F0NJtUP2kal6QxbDmPr Ko2Q== X-Gm-Message-State: ALoCoQn2ZWhpSHfI6TXNYmRdqfH6DNLBx9gzvwYSMLGYyxB0y/3bjRBZ+HF8AUxQa/O9D3XAm2qz MIME-Version: 1.0 X-Received: by 10.220.163.3 with SMTP id y3mr19532250vcx.7.1399843967897; Sun, 11 May 2014 14:32:47 -0700 (PDT) Received: by 10.52.252.97 with HTTP; Sun, 11 May 2014 14:32:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 May 2014 22:32:47 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: multipart/alternative; boundary=001a1133da6672b24104f9269260 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Xs1xYAL95N-RDGhsWqbQRJCeYtA Cc: "trans@ietf.org" , Warren Kumari Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 21:32:56 -0000 --001a1133da6672b24104f9269260 Content-Type: text/plain; charset=UTF-8 On 10 May 2014 22:31, Paul Wouters wrote: > On Sat, 10 May 2014, Warren Kumari wrote: > > On Fri, May 9, 2014 at 7:29 PM, Nico Williams >> wrote: >> >>> On Fri, May 9, 2014 at 6:12 PM, Phillip Hallam-Baker >>> wrote: >>> >>>> The simplest way to align things is to simply have a certificate >>>> issued for the DNSSEC zone KSK and plop that in the log as normal. >>>> >>> >>> Sure, each zone acts as a CA for its children. That works, I think. >>> >> > The problem with that approach is that it does not make DNSSEC distinct > from the existing CA PKI. It will also not remove the cost factor of > getting a DNSSEC "certificate" from a "certified" CABforum member. I think you're reading too much into "acts as a CA" ... it is a matter of fact that the parent zone signs for its children. > I have previously had some discussions about including DNSSEC / DANE / >> self signed certs -- one of the objections / concerns was the threat >> of someone DoSing the logs by making up data (there is a cost to a CA >> cert, but I can create an infinite number of TLSA records or self >> signed certs). >> > > Cost should IMHO not become a verification factor. That's the whole > reason https hasn't been universally deployed to begin with. We should > not make the same mistake with DNSSEC. > > > The main incentive (that I can see) to DoS the logs would be for the >> lolz[0], and so (IMO) the protection does not need to be very strong - >> having someone have to solve a captcha or make a small payment (could >> become a donation) would be enough. >> > > Or just say that anyone who puts in more than X amount of DNSSEC CT > entries underneath themselves must run a public CT node themselves. So > if nohats.ca want to get more then X entries, or one of their > subzones/customers wants more than X entries, either they or their > subzone/customer will have to run a fully functional CT node. And if > the node goes down, their new entries will be refused. Yes, exactly. +1 > > > Paul > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Certificate Transparency is hiring! Let me know if you're interested. --001a1133da6672b24104f9269260 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 10 May 2014 22:31, Paul Wouters <paul@nohats.ca> wro= te:
On Sat, 10 May 2014, Warren Kumari wrote:

On Fri, May 9, 2014 at 7:29 PM, Nico Williams <nico@cryptonector.com> wrote:
On Fri, May 9, 2014 at 6:12 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
The simplest way to align things is to simply have a certificate
issued for the DNSSEC zone KSK and plop that in the log as normal.

Sure, each zone acts as a CA for its children. =C2=A0That works, I think.

The problem with that approach is that it does not make DNSSEC distinct
from the existing CA PKI. It will also not remove the cost factor of
getting a DNSSEC "certificate" from a "certified" CABfo= rum member.

I think you're reading too = much into "acts as a CA" ... it is a matter of fact that the pare= nt zone signs for its children.
=C2=A0
I have previously had some discussions about including DNSSEC / DANE /
self signed certs -- one of the objections / concerns was the threat
of someone DoSing the logs by making up data (there is a cost to a CA
cert, but I can create an infinite number of TLSA records or self
signed certs).

Cost should IMHO not become a verification factor. That's the whole
reason https hasn't been universally deployed to begin with. We should<= br> not make the same mistake with DNSSEC.


The main incentive (that I can see) to DoS the logs would be for the
lolz[0], and so (IMO) the protection does not need to be very strong -
having someone have to solve a captcha or make a small payment (could
become a donation) would be enough.

Or just say that anyone who puts in more than X amount of DNSSEC CT
entries underneath themselves must run a public CT node themselves. So
if nohats.ca want to get= more then X entries, or one of their
subzones/customers wants more than X entries, either they or their
subzone/customer will have to run a fully functional CT node. And if
the node goes down, their new entries will be refused.
Yes, exactly. +1
=C2=A0


Paul


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



--
= Certificate Transparency is hiring! Let me know if you're interested.
--001a1133da6672b24104f9269260-- From nobody Sun May 11 21:23:36 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2537E1A03E8 for ; Sun, 11 May 2014 21:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 329q2-ZYZD26 for ; Sun, 11 May 2014 21:23:31 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id DED521A03E2 for ; Sun, 11 May 2014 21:23:31 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id A8689598070; Sun, 11 May 2014 21:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=3mjKhh4bBdslVQWoI KIrD5Eh+ok=; b=dXTeVQm2qBCvCp2FcbBPCSDIiWu7KH5ZAqPDW5RHg/Arw/5CR iNjV76wT2trd2qAf2/UoHsYiZRZgSRh1tf0Lboj4tnTjwKsI1WBW0MREN2532pYY sbSJ3iAMe2/YBXAfRJD7mwium74pslIAyyRk0XA/DUIJ82JGYckEiBfEMo= Received: from [192.168.1.5] (173-17-72-87.client.mchsi.com [173.17.72.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id B3E0959806C; Sun, 11 May 2014 21:23:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A912849B-3A49-4C08-B28D-495D67827D9E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Pgp-Agent: GPGMail 2.1 (525b9ae) From: Tao Effect In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130A13ECA0@USMBX1.msg.corp.akamai.com> Date: Sun, 11 May 2014 23:23:22 -0500 X-Mao-Original-Outgoing-Id: 421561402.210287-b8bbe52a578478fd05e8c7beaa7f8636 Message-Id: <6D89657B-997C-4587-A1E2-8822F6D2FE69@taoeffect.com> References: <536D9816.1070008@gmail.com> <7719F0ED-7188-4B57-BEE6-245FD0314D36@taoeffect.com> <536DA145.6050305@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130A13ECA0@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/HpIr1zpEN2cULjbbLeO56bfYQdU Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 04:23:33 -0000 --Apple-Mail=_A912849B-3A49-4C08-B28D-495D67827D9E Content-Type: multipart/alternative; boundary="Apple-Mail=_56A605AD-E9E2-4F45-B5E1-1D704903FCB3" --Apple-Mail=_56A605AD-E9E2-4F45-B5E1-1D704903FCB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thank you Rich for answering that, and it's kind of you to offer your = help. I'll look into this as soon as time allows. Kind regards, Greg -- Please do not email me anything that you are not comfortable also = sharing with the NSA. On May 10, 2014, at 9:52 AM, Salz, Rich wrote: =D8 What do I do if the problems are fundamental to the design of CT = and the solution is to do something else? Write up your own document and circulate it. I=92ll be happy to give = you some pointers to the second part, once you have the first part. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_56A605AD-E9E2-4F45-B5E1-1D704903FCB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thank = you Rich for answering that, and it's kind of you to offer your = help.

I'll look into this as soon as time = allows.

Kind = regards,
Greg

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

On May 10, 2014, at 9:52 AM, Salz, Rich <rsalz@akamai.com> = wrote:

=D8  What = do I do if the problems are fundamental to the design of CT and the = solution is to do something else?
 
Write up your own = document and circulate it.  I=92ll be happy to give you some = pointers to the second part, once you have the first = part.
 
-- 
Principal Security = Engineer
Akamai Technologies, Cambridge, = MA
IM: rsalz@jabber.me; = Twitter: RichSalz
 
 
__________________________________________= _____
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans

= --Apple-Mail=_56A605AD-E9E2-4F45-B5E1-1D704903FCB3-- --Apple-Mail=_A912849B-3A49-4C08-B28D-495D67827D9E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTcEy6AAoJEOxnICvpCVJHR1gP/ijD7+JGY/uVJ8DQrmeMlk40 uoFnsBVfYl/aa2Pa3LnuFVBl5AlHJmfunma38w5LY51VGW4R8jr11sAIP/Q+z7bz Qc5dCmRxhFflx5WZIRNPRfGoc6QowQVcrmM7HUQdI44wjGtCUi0mHFaZy86vIyQ3 5JbShA9QD0o75e6PgpINFZGK7ymBUNpSzzi5XyP6/WG+5TyCQn+nBRi2Rl9C1L2U x1ePcmoC6MNOFJerJA/jtPteGsz2n0eOHxxbQLYdm0r/WOTOKxRR2XGDzeexRbiA GWWnttVaUzYK7WKEa5YcRmJl7LJDosC1GT4Xyd61fE83VSDWoPOQ7RlGjlBjxs48 GIxI6diX+31UoCPUyTcf6fU3j4rgRanctPYBQ75lZZxDlNO8B11O3GQrrBUfhFlX Kv5AYYvBGjfQb4L5gKz3FNQFqF3dggeHSOfTK09+l2GmL8bQSUG/pwrO7twRgF08 5JaLPjC+saPdhtmJcrjuBy/Zd5bVHd7XhEWP3sAtgJAUFuIFMpp3VAz76OMRv9hl +nKWGpIvXczMgPNo1p661ZynuT4iULdlQjpxVdTQkygKd8x5TuifWyUZmbKiJMHP UmZAJk2zaRhvWR5AbpR+6gGodDXr+Q69qJeY8NO+knCMlt3TbB5lXWBKFBsOH//8 T+VFRn1c3xZYogXSiKNT =Cx4A -----END PGP SIGNATURE----- --Apple-Mail=_A912849B-3A49-4C08-B28D-495D67827D9E-- From nobody Mon May 12 10:23:13 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675821A0760 for ; Mon, 12 May 2014 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgo9Y4VWjkyo for ; Mon, 12 May 2014 10:23:08 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2561A075D for ; Mon, 12 May 2014 10:23:08 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lg15so9106401vcb.7 for ; Mon, 12 May 2014 10:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lbsKXvJH9jKKAdVr9bTTKc4QqbnYqTjq8inBwX80hXM=; b=FABHn6/TMkL2gh6LLrHiJM5m3mSpEH/8bkLEcZq+3GhF6ONruDwBqBkfcJC5h3lO4u abXA6DpGGuPBbxdXH5zeLZwAN8qv/Dovxl2dgbL4S++bEebpX1INMVjVCJPmYpW4wk50 cxoQ1fkze/uX0LYJTK2HWpACJHuTRvXJUTrAkYO+x1omCA+HjG73MNqALtFZesoFGOHP OUUjuraElCAGgYugiQXUafyTuYJwwqEeNaQbvVGToYA/LSYE9LbLB3VNcTJNp8i6q0vC RhZSeGpYVocfMt3X3TUXn1M9IUrr5XzrzygVpLJfyCG9Uus9aH8yt7PCPBWNRoOgaE2z /fQw== X-Received: by 10.220.59.65 with SMTP id k1mr24115731vch.22.1399915381954; Mon, 12 May 2014 10:23:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.136 with HTTP; Mon, 12 May 2014 10:22:41 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Mon, 12 May 2014 13:22:41 -0400 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a11c295020e9d7704f937332f Archived-At: http://mailarchive.ietf.org/arch/msg/trans/eBGRYl_Vb4aIHVhr68w4vQaXwxw Cc: Warren Kumari , Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:23:10 -0000 --001a11c295020e9d7704f937332f Content-Type: text/plain; charset=UTF-8 > > Or just say that anyone who puts in more than X amount of DNSSEC CT >> entries underneath themselves must run a public CT node themselves. So >> if nohats.ca want to get more then X entries, or one of their >> subzones/customers wants more than X entries, either they or their >> subzone/customer will have to run a fully functional CT node. And if >> the node goes down, their new entries will be refused. > > > Yes, exactly. +1 > I'm wondering what the exact threat model is here. Imagine a malicious domain operator wants to sign some DNSSEC records for use in an attack. They include hashed of them in their log, then claim to "lose" the original records, or issue the equivalent of SCTs and then never include them within the MMD. Who is checking up on them for this? Does the superdomain that signs this domain's record has to be doing full auditing of their DNSSEC-CT log? Does this still work then as anti-DOS if the superdomain has to do all of this auditing anyways (I suppose it could be made random, but then the domain can try to hide malicious entries with lots and lots of spam ones). Furthermore, is this requirement recursive? What if a malicious domain evil.com agrees with a subdomain really.evil.com to not audit their DNSSEC-CT log properly, so malicious records can be signed for really.evil.com, not audited by evil.com, but if com (who we assume is honest) only audits evil.com's log they'll think it's in valid order. Is there a way to prevent the root from having to audit every log everywhere? Also, the penalty for failing some audit check is losing control of your domain? That seems like a sufficient disincentive that few domains will want to go beyond whatever their superdomain's policy is and have to run their own log, enough that some current practices (like giving users of a website their own subdomain) would be affected. --001a11c295020e9d7704f937332f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Or just say that anyone who puts i= n more than X amount of DNSSEC CT
entries underneath themselves must run a public CT node themselves. So
if nohats.ca want to get= more then X entries, or one of their
subzones/customers wants more than X entries, either they or their
subzone/customer will have to run a fully functional CT node. And if
the node goes down, their new entries will be refused.
Yes, exactly. +1

I'm wondering what the exact threat model is here. Imag= ine a malicious domain operator wants to sign some DNSSEC records for use i= n an attack. They include hashed of them in their log, then claim to "= lose" the original records, or issue the equivalent of SCTs and then n= ever include them within the MMD. Who is checking up on them for this? Does= the superdomain that signs this domain's record has to be doing full a= uditing of their DNSSEC-CT log? Does this still work then as anti-DOS if th= e superdomain has to do all of this auditing anyways (I suppose it could be= made random, but then the domain can try to hide malicious entries with lo= ts and lots of spam ones).

Furthermore, is this requirement recursive? What if a m= alicious domain evil.com = agrees with a subdomain really.evil.com to not audit their DNSSEC-CT log properly, so malicio= us records can be signed for=C2=A0really.evil.com, not audited by evil.com, but if com (who we assume is honest) only = audits evil.com's log= they'll think it's in valid order. Is there a way to prevent the r= oot from having to audit every log everywhere?

Also, the penalty for failing some audit check is losin= g control of your domain? That seems like a sufficient disincentive that fe= w domains will want to go beyond whatever their superdomain's policy is= and have to run their own log, enough that some current practices (like gi= ving users of a website their own subdomain) would be affected.
--001a11c295020e9d7704f937332f-- From nobody Mon May 12 10:40:51 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD241A073E for ; Mon, 12 May 2014 10:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 cwdMj9JFrvZT for ; Mon, 12 May 2014 10:40:47 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3E1A073C for ; Mon, 12 May 2014 10:40:47 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 03EEA674059 for ; Mon, 12 May 2014 10:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=cXKm/je4UhHt9j5fWQrW 3Q4DUfw=; b=ZEhh2VhJVLDBJ3zTGyF+cb95xGIc5XmPU/fbYxhItQz+wHFy0E4W 6/tNfmlEg8KUECkq+yNd2qy9c69XIiC6yOExxqdXMmkENNP9MfbiEKfHGyjboZww skL93bTnFASvPE+y7TSIiP1lygrypXu5+IO0nZZOYAjUMPXCHtNxoeM= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 7A4C5674058 for ; Mon, 12 May 2014 10:40:41 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so7084334wgh.4 for ; Mon, 12 May 2014 10:40:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr16586777wiw.5.1399916439809; Mon, 12 May 2014 10:40:39 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 12 May 2014 10:40:39 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 May 2014 12:40:39 -0500 Message-ID: From: Nico Williams To: Joseph Bonneau Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2SIyjL4TkZCYeBmhUfzftXxvAlo Cc: Warren Kumari , "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:40:48 -0000 On Mon, May 12, 2014 at 12:22 PM, Joseph Bonneau wrote: > I'm wondering what the exact threat model is here. Imagine a malicious > domain operator wants to sign some DNSSEC records for use in an attack. They > include hashed of them in their log, then claim to "lose" the original > records, or issue the equivalent of SCTs and then never include them within > the MMD. Who is checking up on them for this? Does the superdomain that Clients (lazily perhaps). The public. Domain owners. Registrars. Remember, com. and . cannot merely MITM foo.bar.com. com. would have to MITM bar.com. as well. And . would have to MITM com. too. These would be noticeable. > signs this domain's record has to be doing full auditing of their DNSSEC-CT > log? Does this still work then as anti-DOS if the superdomain has to do all > of this auditing anyways (I suppose it could be made random, but then the > domain can try to hide malicious entries with lots and lots of spam ones). "Loss" of log entries gets detected. Detection of MITM attacks by . and TLDs would result in bad PR, and the news would spread quickly, therefore they [mostly] wouldn't do it. That's the point of CT. I don't understand you question about anti-DOS. > Furthermore, is this requirement recursive? What if a malicious domain > evil.com agrees with a subdomain really.evil.com to not audit their > DNSSEC-CT log properly, so malicious records can be signed for > really.evil.com, not audited by evil.com, but if com (who we assume is > honest) only audits evil.com's log they'll think it's in valid order. Is > there a way to prevent the root from having to audit every log everywhere? Domains would get to opt out for privacy reasons. If evil.com opts out, oh well. This isn't about auditing every zone. > Also, the penalty for failing some audit check is losing control of your > domain? [...] Eh?! Who said that?? Nobody proposed that; nobody would. Failure to include signatures in the log -> detection -> bad for public relations -> incentive for CAs/registrars not to MITM. Nico -- From nobody Mon May 12 10:55:13 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A021A0745 for ; Mon, 12 May 2014 10:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX4GthrTVfY9 for ; Mon, 12 May 2014 10:55:08 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 591591A0741 for ; Mon, 12 May 2014 10:55:08 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id sa20so9231777veb.37 for ; Mon, 12 May 2014 10:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xhu0CRXChWiYzv/TfRCe67JhChEMm6GXhqsKKnP92GY=; b=EYVGMA8Yvqit8PXFLdnsF+8+kIuU7NJol6Lz4MpzK7Q3oVxkq89+GqiK6xV195m9zw XfEul9QU8jlYG07mKXRb1NW0H4hkwahPyx/8iX4IkHDFUgnxGFL0i2pW9T3CXcvld0t2 1JwPUvJafs/wMKBy4+OSfa2pianUf5cJ0iTJdo86s44TnXB0O6YDO/Cqh5NARAFVozfW JHDeJHoIxRBsWZxgKIM5+gu+/P4ORyFbQU2XMVVQmp+xbb9AT6ozgkKQKwlaiYfTiVoJ 248PFAJ0dLnyQkZNe0rKoo8D8Bo4asTP8RRS3/hAqYIYLkbhcIvi1T639pSDzaYjcJ+e snsQ== X-Received: by 10.52.125.147 with SMTP id mq19mr8990510vdb.2.1399917302023; Mon, 12 May 2014 10:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.136 with HTTP; Mon, 12 May 2014 10:54:41 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Mon, 12 May 2014 13:54:41 -0400 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec51b97b3808eb004f937a55a Archived-At: http://mailarchive.ietf.org/arch/msg/trans/HhCaYBRvhnQSuMUXOymZ1O0ug3M Cc: Warren Kumari , "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:55:10 -0000 --bcaec51b97b3808eb004f937a55a Content-Type: text/plain; charset=UTF-8 > > > Clients (lazily perhaps). The public. Domain owners. Registrars. > Certainly possible, but I wonder how much this will happen in a world of thousands of DNSSEC-CT logs existing for various domains. Some of them will inevitably screw up. Will it be front-page news the 10th time that happens due to server outages or administrative screwups? I imagine it will be kind of like using an expired x.509 cert today. People on hackernews might comment if a top website did it, but not an emergency board meeting type of situation for that company. With CT for x.509 certs the assumption is that smaller number of logs are run which are very important and any screwup is a BFD. I don't know if that assumption scales to thousands of DNSSEC-CT logs. > Remember, com. and . cannot merely MITM foo.bar.com. com. would have > to MITM bar.com. as well. And . would have to MITM com. too. These > would be noticeable. What about a compelled creation attack (or undetected key compromise) where malicious entries are signed by the genuine evil.com key? For example, say evilhosting.com gives me jbonneau.evilhosting.com and I care that they only sign my records for this domain so that nobody can MITM my site. But they secretly agree to give the government of Elbonia a signed record for my domain and then fail to log them properly. They can do this without any compromise or intervention of com, right? --bcaec51b97b3808eb004f937a55a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Clients (lazily perhaps). =C2=A0The public. =C2=A0Domain owners. =C2= =A0Registrars.

Certainly possible, but = I wonder how much this will happen in a world of thousands of DNSSEC-CT log= s existing for various domains. Some of them will inevitably screw up. Will= it be front-page news the 10th time that happens due to server outages or = administrative screwups? I imagine it will be kind of like using an expired= x.509 cert today. People on hackernews might comment if a top website did = it, but not an emergency board meeting type of situation for that company.<= /div>

With CT for x.509 certs the assumption is that smaller = number of logs are run which are very important and any screwup is a BFD. I= don't know if that assumption scales to thousands of DNSSEC-CT logs.
=C2=A0
Remember, com. and . cannot merely MITM foo.bar.com. =C2=A0com. would have
to MITM bar.com. as well. = =C2=A0And . would have to MITM com. too. =C2=A0These
would be noticeable.

What about a compelled= creation attack (or undetected key compromise) where malicious entries are= signed by the genuine evil.com key? For ex= ample, say evilhosting.com gives me = jbonneau.evilhosting.com an= d I care that they only sign my records for this domain so that nobody can = MITM my site. But they secretly agree to give the government of Elbonia a s= igned record for my domain and then fail to log them properly. They can do = this without any compromise or intervention of com, right?
--bcaec51b97b3808eb004f937a55a-- From nobody Mon May 12 11:01:38 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2901A0756 for ; Mon, 12 May 2014 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 Ej6v4HdP2EW9 for ; Mon, 12 May 2014 11:01:35 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 313FE1A0766 for ; Mon, 12 May 2014 11:01:35 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 5AEED160C for ; Mon, 12 May 2014 11:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=p28MhpvpFjezL/jDutfq GJ313eU=; b=CPGwljvZoU7HvCDPv29+jTmHqYcoxW3/Ytxdi69Cy4JwNqoOz27j XjAa+Yw2sGry4BItZ0giVKel9ZHEtwZb5Mzt9xsyjQ5R8QtA2fvl+OuPqcH+0VUo ajVs8BFnIsdjy1+SCxwczzzdJJpmiSjv0IN1+bNhhamHiQbXTP63kkQ= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 03879161E for ; Mon, 12 May 2014 11:01:28 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so7325681wgh.20 for ; Mon, 12 May 2014 11:01:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.34 with SMTP id kr2mr23109004wjb.34.1399917687791; Mon, 12 May 2014 11:01:27 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 12 May 2014 11:01:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 May 2014 13:01:27 -0500 Message-ID: From: Nico Williams To: Joseph Bonneau Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-20f6oTfyMBXvW8tDfgtDmcY5fo Cc: Warren Kumari , "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:01:37 -0000 On Mon, May 12, 2014 at 12:54 PM, Joseph Bonneau wrote: >> Clients (lazily perhaps). The public. Domain owners. Registrars. > > Certainly possible, but I wonder how much this will happen in a world of > thousands of DNSSEC-CT logs existing for various domains. Some of them The ones that matter most are the TLDs and the root. Those get so many users that they will be caught MITMing, if they do. > With CT for x.509 certs the assumption is that smaller number of logs are > run which are very important and any screwup is a BFD. I don't know if that > assumption scales to thousands of DNSSEC-CT logs. You're assuming I zones below the ones that matter audited, but I don't. I want the root ones audited -- same as with the TLS server PKI. Why would I have wanted anything else? >> Remember, com. and . cannot merely MITM foo.bar.com. com. would have >> to MITM bar.com. as well. And . would have to MITM com. too. These >> would be noticeable. > > What about a compelled creation attack (or undetected key compromise) where > malicious entries are signed by the genuine evil.com key? For example, say > evilhosting.com gives me jbonneau.evilhosting.com and I care that they only > sign my records for this domain so that nobody can MITM my site. But they > secretly agree to give the government of Elbonia a signed record for my > domain and then fail to log them properly. They can do this without any > compromise or intervention of com, right? If evilhosting.com has lots of customers, then they'll help audit it, else they might not. At any rate, the first-order problem in a hierarchical public key system is keeping the roots and intermediates closest to the roots honest. Nico -- From nobody Mon May 12 12:53:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB061A0772 for ; Mon, 12 May 2014 12:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hZovggRrj_P for ; Mon, 12 May 2014 12:53:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id D1EF41A033A for ; Mon, 12 May 2014 12:53:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BB2A247548; Mon, 12 May 2014 19:53:02 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AEC2E47547; Mon, 12 May 2014 19:53:02 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 6F33E8004F; Mon, 12 May 2014 19:53:02 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.79]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 12 May 2014 15:53:01 -0400 From: "Salz, Rich" To: Phillip Hallam-Baker , Paul Wouters Date: Mon, 12 May 2014 15:53:00 -0400 Thread-Topic: [Trans] DNSSEC also needs CT Thread-Index: Ac9tPGPmUcqq9Q6qQv28jFeaa0YEUgA3yRiQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130ABE9E58@USMBX1.msg.corp.akamai.com> References: <536F8BC4.5070405@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/tDRRbREXs_jJV1QK_wOlHM2ySSU Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 19:53:10 -0000 > I don't see the CAs running CT logs as being necessarily exclusive. Nor do we :) /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon May 12 21:57:13 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FD01A0844 for ; Mon, 12 May 2014 21:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTRAk05Im2x4 for ; Mon, 12 May 2014 21:57:08 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 34BB11A083C for ; Mon, 12 May 2014 21:57:08 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id oz11so10183845veb.30 for ; Mon, 12 May 2014 21:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W3HQRf1CETtdHILsz+WOHbh7QwZUbVjBHlDDwxszGPo=; b=mz9S5lDvAN5/z4tfDfzZQupRQUWkuuegmuVlOho/MJIT4W87zKJfgSchy9eEheTXBT u5dQpqnr1p/wCgY5kVJrPcMdyoJIWWx6sihPjyBWwARQVHevOg/m8E5m31m8uoHS/FQy DpwGWQWHMHCi799+U9KX0GJCg0yOijZaGejY91ezjll90eFL1A/afWmWAJnZDnV1ESCj nUA5KC0Fg9jtc4yYWlDF6mHgQOWBEpPHbJV6PHE4wrzFTr79FFf2zW7RSmBUsc6/TQer T1jrZ5hf+MuWTtscZMB0woaBkA0JDbav5QBulq/1JGfLwaXVP/tS983mnU4aRCTU4mrs 1kkw== X-Received: by 10.221.26.10 with SMTP id rk10mr27089507vcb.0.1399957021891; Mon, 12 May 2014 21:57:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.136 with HTTP; Mon, 12 May 2014 21:56:41 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Tue, 13 May 2014 00:56:41 -0400 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a11339ae4fda0a404f940e462 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/xKYB9w7Ie4NKHu5HMHBASjU97Kk Cc: Warren Kumari , "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 04:57:10 -0000 --001a11339ae4fda0a404f940e462 Content-Type: text/plain; charset=UTF-8 On Mon, May 12, 2014 at 2:01 PM, Nico Williams wrote: > > The ones that matter most are the TLDs and the root. Those get so > many users that they will be caught MITMing, if they do. > ... > You're assuming I zones below the ones that matter audited, but I > don't. I want the root ones audited -- same as with the TLS server > PKI. Why would I have wanted anything else? Your original email didn't specify if you were interested in logs only for the root/important TLDs or for every domain. I (and I think others in this thread) interpreted the idea as being some form of hierarchical logging for all or almost all (non-private) domains. Are we on the same page now that the stronger version seems very unlikely in the short to medium term? --001a11339ae4fda0a404f940e462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, May 12, 2014 at 2:01 PM, Nico Williams <nico@cryptonector.com<= /a>> wrote:
The ones that matter most are the TLDs and the root. =C2=A0Those get so
many users that they will be caught MITMing, if they do.
...=C2=A0
You're assuming I zones below the ones that matter audited, but I=
don't. =C2=A0I want the root ones audited -- same as with the TLS serve= r
PKI. =C2=A0Why would I have wanted anything else?

Your original email didn't specify if you were interested in log= s only for the root/important TLDs or for every domain. I (and I think othe= rs in this thread) interpreted the idea as being some form of hierarchical = logging for all or almost all (non-private) domains. Are we on the same pag= e now that the stronger version seems very unlikely in the short to medium = term?=C2=A0
--001a11339ae4fda0a404f940e462-- From nobody Mon May 12 22:12:14 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AF21A03F0 for ; Mon, 12 May 2014 22:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 ILvAj8YvBASN for ; Mon, 12 May 2014 22:12:10 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3101A03EA for ; Mon, 12 May 2014 22:12:10 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 7B3DE20047B70 for ; Mon, 12 May 2014 22:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=EtutI248/gwJrmY6pO6k GQKSyW4=; b=G44aU6nWyturI7xP+Bhx6Yv/UZ3eBbX4vpBxot1KGNVTKEmABllj 9M0e15FNIdJbdIZXmBpBWdHmHbeS1UOOa6Z0hVRyQSBWw7+Op6aYw/7BmMwkgSJz yjegtcyRjTLURVGyGzcNzzbgjsoo0KDBkP5ZFLZduWtX/wYp0iHt5Wk= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 304F820047B6F for ; Mon, 12 May 2014 22:12:04 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so7853427wes.30 for ; Mon, 12 May 2014 22:12:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.60.4 with SMTP id d4mr25057991wjr.28.1399957923004; Mon, 12 May 2014 22:12:03 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 12 May 2014 22:12:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 00:12:02 -0500 Message-ID: From: Nico Williams To: Joseph Bonneau Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/MW79QHK-5nVKK6kPAPJLc0-p57g Cc: Warren Kumari , "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 05:12:12 -0000 On Mon, May 12, 2014 at 11:56 PM, Joseph Bonneau wrote: > On Mon, May 12, 2014 at 2:01 PM, Nico Williams > wrote: >> You're assuming I zones below the ones that matter audited, but I >> don't. I want the root ones audited -- same as with the TLS server >> PKI. Why would I have wanted anything else? > > > Your original email didn't specify if you were interested in logs only for > the root/important TLDs or for every domain. I (and I think others in this > thread) interpreted the idea as being some form of hierarchical logging for > all or almost all (non-private) domains. Are we on the same page now that > the stronger version seems very unlikely in the short to medium term? Is CT intended to be run all the way from the root to the CAs furthest from the root? I didn't think it was, and if it is, please tell me. Incidentally, rfc6962bis could use an operational considerations section covering issues such as what CAs are expected to be logged. Nico -- From nobody Mon May 12 22:23:17 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513AD1A083F for ; Mon, 12 May 2014 22:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKuKGOaijJxZ for ; Mon, 12 May 2014 22:23:14 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D86951A03F0 for ; Mon, 12 May 2014 22:23:13 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lg15so10088010vcb.35 for ; Mon, 12 May 2014 22:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xOObAaoTQv0Fb0FtRzezITTdCCSa7vb37/J8+1XvspQ=; b=oTkadybAzlKapnixGS8GGmHWWTjTH2w0KhYvLqHmcwTU7YtQl8JZpwV6QLQ91G/qCL crC11fNnwKTMxmCuGYrmsgRFQ6kR/sHR7WmRz4Ccpl7sAPZfoooPKqDvdHUI0SfErMnN MrqGIW59zjexiSxjqDKBBTT4Hop++0YiP6j2i+PfZ8fgZcAmmSgGldODmWnEtXJtGdDy Ls9q5ai7+R3L4R+LE6B4ffw3lzKdwr6CnKHuTPZ0jsDmwvUjOxpIJLJEp5As5ujGUMXK Mx5WufG9TSy2mMxjWQAx5iZWtJrGCnccE4Awsi+AcOi2454WLhD+w58mNjUPc9C5A5pn Y7bw== X-Received: by 10.220.159.4 with SMTP id h4mr27442359vcx.1.1399958587517; Mon, 12 May 2014 22:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.136 with HTTP; Mon, 12 May 2014 22:22:47 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Tue, 13 May 2014 01:22:47 -0400 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c2ca0c4f2f4c04f941428a Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qp6e0WIiHTzpRH21BYCFFDqiVL0 Cc: Warren Kumari , "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 05:23:15 -0000 --001a11c2ca0c4f2f4c04f941428a Content-Type: text/plain; charset=UTF-8 > > Is CT intended to be run all the way from the root to the CAs furthest > from the root? I didn't think it was, and if it is, please tell me. > Yes, it is. The goal of CT is that browsers will eventually reject any end-entity TLS certificate that doesn't have an SCT. I believe this is true regardless of the number of intermediate CAs in the cert's path to a trusted root. There's an exception for trust anchors manually added to the browser to accommodate private CAs, but essentially all certificates that standard browsers will accept out of the box must be logged. By contrast with DNSSEC you seem to be suggesting that many DNSSEC records that browsers/resolvers will accept as genuine will not be logged anywhere (or be logged somewhere that isn't necessarily audited) and the browser will still accept them. --001a11c2ca0c4f2f4c04f941428a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is CT intended to be run all the= way from the root to the CAs furthest
from the root? =C2=A0I didn't think it was, and if it is, please tell m= e.

Yes, it is. The goal of CT is that b= rowsers will eventually reject any end-entity TLS certificate that doesn= 9;t have an SCT. I believe this is true regardless of the number of interme= diate CAs in the cert's path to a trusted root. There's an exceptio= n for trust anchors manually added to the browser to accommodate private CA= s, but essentially all certificates that standard browsers will accept out = of the box must be logged.

By contrast with DNSSEC you seem to be suggesting that = many DNSSEC records that browsers/resolvers will accept as genuine will not= be logged anywhere (or be logged somewhere that isn't necessarily audi= ted) and the browser will still accept them.
--001a11c2ca0c4f2f4c04f941428a-- From nobody Mon May 12 22:26:30 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C61A0842 for ; Mon, 12 May 2014 22:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INUNzWuR0jSm for ; Mon, 12 May 2014 22:26:28 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EE9A31A083F for ; Mon, 12 May 2014 22:26:27 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id rp16so565100pbb.1 for ; Mon, 12 May 2014 22:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=P9eQlMmnGasB1zwP3q9rbRG+NtjamKjdsvFQbij7G1w=; b=uYNenK2NNpRd9P1ji9u9DWZGWDuLZ7sW56YEWWsaU2UDZnONYPNp27Y867/LIrA6dz GmHiVjcjtGzduN7k6/M9psFUwlbTSHu/ullKxgX7B27XXN+mRwVKD8Z2x5kDH3cv/Aej nyV8Y+ZY7pL7oSLzO8YePmp3hpwvicPDYSG/QxJb+0rWzxQZNBLYmVoceyJRiL24d1BF CBVsKsG6HAvkekPtAw6TDNYlXno11WPScmAMbAVswYgp9l+sqfmDfDDn1mXLQ45knvhA VtktpCKmDc2ItHFT/kXehRketMjEAfpBkBdRZ3WMtXXtznZx6+edHdopx6EeoS8aVyMK Xhog== X-Received: by 10.66.248.228 with SMTP id yp4mr62237957pac.94.1399958781941; Mon, 12 May 2014 22:26:21 -0700 (PDT) Received: from spandex.local (216-67-116-181-rb3.fai.dsl.dynamic.acsalaska.net. [216.67.116.181]) by mx.google.com with ESMTPSA id jq6sm6422829pbb.76.2014.05.12.22.26.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 22:26:21 -0700 (PDT) Message-ID: <5371ACFB.5020604@gmail.com> Date: Mon, 12 May 2014 21:26:19 -0800 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Pw5zcQrNVYGNcQutmLvSldSVQJw Subject: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 05:26:29 -0000 On 5/12/14 9:12 PM, Nico Williams wrote: > Incidentally, rfc6962bis could use an operational considerations > section covering issues such as what CAs are expected to be logged. We've talked about the possibility of breaking out client behavior into a separate document, and while that discussion focused on the protocol between a client and a log server it seems that this sort of thing may belong there, as well. Nobody has stepped forward to draft a document but at this point it would be very helpful indeed if someone could step forward and contribute some text. Melinda From nobody Mon May 12 23:34:55 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027BA1A07D0 for ; Mon, 12 May 2014 23:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 CuCYlD2HJksj for ; Mon, 12 May 2014 23:34:48 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 606521A07C8 for ; Mon, 12 May 2014 23:34:48 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 5F47E598057 for ; Mon, 12 May 2014 23:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VY3w+GwU6/jCeYW5W7fD p8YSLLk=; b=hO7FoH5wGj2O0y2ImAWSC3qczFVz7bqBTp6teKm4w3vKCKVu+ex+ Tx/818fmLezVRJfSeOJSRoSF1a2oOX7WmzAgALuCxC3HP0Ap01t6w9L9MTH3ebT/ KoffkGV0OA+LynTMpfpMCY8bCRmV0xMNhs4KHJWQHNbo5F6uViyO9/4= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 1425659805F for ; Mon, 12 May 2014 23:34:41 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so7930829wgg.30 for ; Mon, 12 May 2014 23:34:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr19079846wiw.5.1399962880808; Mon, 12 May 2014 23:34:40 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 12 May 2014 23:34:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 01:34:40 -0500 Message-ID: From: Nico Williams To: Joseph Bonneau Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/760egDijmXU8h_LryERhzxwgmU4 Cc: Warren Kumari , "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 06:34:49 -0000 On Tue, May 13, 2014 at 12:22 AM, Joseph Bonneau wrote: >> Is CT intended to be run all the way from the root to the CAs furthest >> from the root? I didn't think it was, and if it is, please tell me. > > Yes, it is. The goal of CT is that browsers will eventually reject any > end-entity TLS certificate that doesn't have an SCT. I believe this is true > regardless of the number of intermediate CAs in the cert's path to a trusted > root. There's an exception for trust anchors manually added to the browser > to accommodate private CAs, but essentially all certificates that standard > browsers will accept out of the box must be logged. Ah, yes, and actually we should want the same for DNSSEC. The problem then becomes privacy. But I think we can achieve that by not logging names, just hashes of the relevant RRsets, no? Since public keys will generally be part of the relevant RRsets this won't help zone enumerators. Nico -- From nobody Tue May 13 01:42:06 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2FE1A01C3 for ; Tue, 13 May 2014 01:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG9R_E6Ua1qQ for ; Tue, 13 May 2014 01:42:03 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A61FB1A0429 for ; Tue, 13 May 2014 01:42:03 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so12435yho.29 for ; Tue, 13 May 2014 01:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X7SoQBXg+fQtdzy655UV8/mEwGTvInzemDDodggAz+Q=; b=g/aTZO6GVwD1dRMh4VBcTrMSUqcFUDEQ4j8ffF9EdXwvIRmMx+knBO3euzw0viaE9V a+2QnUSMCwLIALAFBOzj22ntQqw4rFd0YhMeitZM8+KU4kmH4GGJ+hGqdX5Mh+CM24By WW30GeaR7BmGwIKRrqFQm55UK0KqdEzuQILZvpT7tfFVmDTntkBogwdWS2t5Lv/VNBbv UUahtKsjBsp/M1NhzlBeyxvdH5fBIDG5p8Rs+im/F5IJzh/1eqhaVhLSSTU+HGuooW4G e1MRi9yW2ojfwaesibHApAW55OIVWXp6Fliz+KXVFWo77U+W9FONw0zc81+Npbijkui/ qDIw== MIME-Version: 1.0 X-Received: by 10.236.46.5 with SMTP id q5mr48851121yhb.21.1399970517356; Tue, 13 May 2014 01:41:57 -0700 (PDT) Received: by 10.170.91.85 with HTTP; Tue, 13 May 2014 01:41:57 -0700 (PDT) In-Reply-To: <5371ACFB.5020604@gmail.com> References: <5371ACFB.5020604@gmail.com> Date: Tue, 13 May 2014 12:41:57 +0400 Message-ID: From: Dmitry Belyavsky To: Melinda Shore Content-Type: multipart/alternative; boundary=047d7b5d83916213cc04f94409f8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/cI7AVulbTM52IR6KNfQtRy8S_8A Cc: "trans@ietf.org" Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 08:42:05 -0000 --047d7b5d83916213cc04f94409f8 Content-Type: text/plain; charset=UTF-8 Hello Melinda, On Tue, May 13, 2014 at 9:26 AM, Melinda Shore wrote: > On 5/12/14 9:12 PM, Nico Williams wrote: > > Incidentally, rfc6962bis could use an operational considerations > > section covering issues such as what CAs are expected to be logged. > > We've talked about the possibility of breaking out client behavior > into a separate document, and while that discussion focused on > the protocol between a client and a log server it seems that > this sort of thing may belong there, as well. > > Nobody has stepped forward to draft a document but at this point > it would be very helpful indeed if someone could step forward and > contribute some text. > > Here are my ideas about "strict" behaviour of the TLS client: ============== TLS clients supporting CT are supposed to have a preconfigured set of logs and their public keys. In addition to normal validation of the certificate and its chain, they should validate the SCTs received during the TLS connection. The client fully conforming to the specification SHOULD perform the following steps before establishing the connection for every certificate in the chain: 1. If no SCTs are provided, the client SHOULD reject the connection. 2. The client MUST ignore all the SCTs provided by unknown logs. 3. TLS clients MUST reject SCTs whose timestamp is in the future. 4. If no SCTs has left after steps 2-3, the client SHOULD reject the connection. 5. If any of SCTs left after steps 2-3 has invalid signature, the client SHOULD reject the connection. Client MAY check whether the certificate is present in the log corresponding to the passed SCT. If the certificate is not present in the log, the connection MUST be rejected. ============= Can it be a starting point or you want something else? -- SY, Dmitry Belyavsky --047d7b5d83916213cc04f94409f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Melinda,




On Tue, May 13, 2014 at 9:2= 6 AM, Melinda Shore <melinda.shore@gmail.com> wrote:
On 5/12/14 9:12 PM, Nico Williams wrote:
> Incidentally, rfc6962bis could use an operational considerations
> section covering issues such as what CAs are expected to be logged.
We've talked about the possibility of breaking out client behavior
into a separate document, and while that discussion focused on
the protocol between a client and a log server it seems that
this sort of thing may belong there, as well.

Nobody has stepped forward to draft a document but at this point
it would be very helpful indeed if someone could step forward and
contribute some text.


Here are my ideas about "strict&q= uot; behaviour of the TLS client:

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
TLS clients supporting CT are su= pposed to have a preconfigured set of logs and
their public keys.

In addition to normal vali= dation of the certificate and its chain, they should
validate the= SCTs received during the TLS connection.

The clie= nt fully conforming to the specification SHOULD perform the following
steps before establishing the connection for every certificate in the = chain:

1. If no SCTs are provided, the client SHOU= LD reject the connection.

2. The client MUST ignor= e all the SCTs provided by unknown logs.

3. TLS clients MUST reject SCTs whose timestamp is in t= he future.

4. If no SCTs has left after steps 2-3,= the client SHOULD reject the connection.

5. If an= y of SCTs left after steps 2-3 has invalid signature, the client SHOULD rej= ect the connection.

Client MAY check whether the certificate is present in = the log corresponding to the passed SCT.
If the certificate is no= t present in the log, the connection MUST be rejected.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=C2=A0

Can it be a starting point or you want something else?

--
SY, Dmitry Belyavsky
--047d7b5d83916213cc04f94409f8-- From nobody Tue May 13 04:52:10 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6D01A008D for ; Tue, 13 May 2014 04:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 2Bm9kwLvUvwA for ; Tue, 13 May 2014 04:52:05 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 61B041A0084 for ; Tue, 13 May 2014 04:52:05 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db11so254561veb.22 for ; Tue, 13 May 2014 04:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tCMtZj3lWFO/Fb4tMEwm+GTzqpjjYtFGEhhsVflJAoE=; b=Y9JBL6OZ9wUtWR/edG76sI570brGceNFE4Ji+0uMtBO6bRL8LYTOFO8Ni50KRjXDSx RN0SAMH1BvW2fsLhiB09qVJ+NsjD36T7fVluuJs+/G77n8Rp32f+DjBFpJNEBHuqiG4C 3rPLr8SXT8bduWPx7Keot+Ows2ebwBrd8ity7ChYtM390q94G4mFgB6RETsXvelj2WvR /OZtxHfOdP1RNxVhS4dW0D9vYcxrd6hZcrgwAJIF0HHmlKMGlRwUvgvgT/2U+9skYv9k m6ITYC/TZo2j4hHwL0u/rzYMkNEZP10hhnDUECaEszRwGxNKWqZwbLHTtzK0H3mTl+Ln Ooaw== 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=tCMtZj3lWFO/Fb4tMEwm+GTzqpjjYtFGEhhsVflJAoE=; b=K8YWo/RaJ587ofK/yo92tm+1PpnGw03F6hvwrlzbimslXgOwHVfrjY9PkC3faqfziy r6p4DFl/MM468FLz7nRK1rBm9KVCSGv864WlBoL5m6+gm8aTV/a/b3p5af64lgTlAx4W Z1l2riuLBPQ90B8NYU1su03fqOEcC7AVZV+1l6DaaDEbJQuhT2u9RT4+Sg6gSEcIjhxC sgtzvhL8jmfnQoKTVa6m7vwlm8z5yxI2Jk3IEjs5yo79j0N+z6uLEP6j5BiFBo+a8cgB I+qufMd4dYYcEXPq3L4flXvLQusIG4lr7qxBxSfPE8xamw5zAHME4HKZgiS57XjyUK2i Lrtg== X-Gm-Message-State: ALoCoQlncMFTOVIClARbLPxrbKefZn/Qx49hgGUIAKiCK+QKHjZ4ri+IuL+J6fj83lv8egWi0BU2 MIME-Version: 1.0 X-Received: by 10.221.42.135 with SMTP id ty7mr28732645vcb.14.1399981918932; Tue, 13 May 2014 04:51:58 -0700 (PDT) Received: by 10.52.252.97 with HTTP; Tue, 13 May 2014 04:51:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 12:51:58 +0100 Message-ID: From: Ben Laurie To: Nico Williams Content-Type: multipart/alternative; boundary=001a11339974f86e1304f946b008 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/35_3vQhVCbljIK3tTByH5qqAbxw Cc: Paul Wouters , "trans@ietf.org" , Joseph Bonneau , Warren Kumari Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 11:52:07 -0000 --001a11339974f86e1304f946b008 Content-Type: text/plain; charset=UTF-8 On 13 May 2014 07:34, Nico Williams wrote: > On Tue, May 13, 2014 at 12:22 AM, Joseph Bonneau > wrote: > >> Is CT intended to be run all the way from the root to the CAs furthest > >> from the root? I didn't think it was, and if it is, please tell me. > > > > Yes, it is. The goal of CT is that browsers will eventually reject any > > end-entity TLS certificate that doesn't have an SCT. I believe this is > true > > regardless of the number of intermediate CAs in the cert's path to a > trusted > > root. There's an exception for trust anchors manually added to the > browser > > to accommodate private CAs, but essentially all certificates that > standard > > browsers will accept out of the box must be logged. > > Ah, yes, and actually we should want the same for DNSSEC. The problem > then becomes privacy. But I think we can achieve that by not logging > names, just hashes of the relevant RRsets, no? Since public keys will > generally be part of the relevant RRsets this won't help zone > enumerators. > Is it necessary to log anything other than keys? My base assumption was no: if the keys are as expected, then all records signed by those keys can be trusted. If someone wants to publish RRsets that are other than the one the true domain owner wants to publish, they necessarily have to inject a key they control, which becomes apparent from the logs. -- Certificate Transparency is hiring! Let me know if you're interested. --001a11339974f86e1304f946b008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 13 May 2014 07:34, Nico Williams <nico@cryptonector.com> wrote:
On Tue, May 13, 2014 at 12:2= 2 AM, Joseph Bonneau <jbonneau@gma= il.com> wrote:
>> Is CT intended to be run all the way from the root to the CAs furt= hest
>> from the root? =C2=A0I didn't think it was, and if it is, plea= se tell me.
>
> Yes, it is. The goal of CT is that browsers will eventually reject any=
> end-entity TLS certificate that doesn't have an SCT. I believe thi= s is true
> regardless of the number of intermediate CAs in the cert's path to= a trusted
> root. There's an exception for trust anchors manually added to the= browser
> to accommodate private CAs, but essentially all certificates that stan= dard
> browsers will accept out of the box must be logged.

Ah, yes, and actually we should want the same for DNSSEC. =C2=A0The p= roblem
then becomes privacy. =C2=A0But I think we can achieve that by not logging<= br> names, just hashes of the relevant RRsets, no? =C2=A0Since public keys will=
generally be part of the relevant RRsets this won't help zone
enumerators.

Is it necessary to log any= thing other than keys? My base assumption was no: if the keys are as expect= ed, then all records signed by those keys can be trusted. If someone wants = to publish RRsets that are other than the one the true domain owner wants t= o publish, they necessarily have to inject a key they control, which become= s apparent from the logs.

--
Certificate Transparency is hiring! Let me know= if you're interested.
--001a11339974f86e1304f946b008-- From nobody Tue May 13 05:19:47 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91D1A0085 for ; Tue, 13 May 2014 05:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoZ8NpwGw41U for ; Tue, 13 May 2014 05:19:45 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFF31A0081 for ; Tue, 13 May 2014 05:19:44 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id q9so176792ykb.21 for ; Tue, 13 May 2014 05:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=C06kxeovBL0I8IeYzIDT6PaoViUYaJQesVKphAcpsgk=; b=rWaVa20Z9Rz/1scY5k6xCwWsObiIEHduls98tiXFxikgKxnAESr7RBLQrtprw0bKCa 7T9iNYc1Gc4vSY4sxZFfJL+tvump/W3V7sJOpJjOLDpYDni3BY88Xd4XhWHNh0kArnIR W7kU5Q8UXSHaLnexxe1slEjC/Ojp0IEDFFURgqGXL39EY1VJJ3NcGJjCyPJa5JCnsel6 6WUiAnAV5/FYDZYYFL3rhfFMtf91F4oUyhkTl3pjJhcYRGZflQ8LAVQk9q1Jco5/LYvC RnfqN6GCTV6x0FSWe8F2D926Fc16Tjv+fUzoTwx4JOCt9WAL4yof4+Eadt6+ptHKigr7 iNww== MIME-Version: 1.0 X-Received: by 10.236.115.198 with SMTP id e46mr50032139yhh.24.1399983578714; Tue, 13 May 2014 05:19:38 -0700 (PDT) Received: by 10.170.91.85 with HTTP; Tue, 13 May 2014 05:19:38 -0700 (PDT) Date: Tue, 13 May 2014 16:19:38 +0400 Message-ID: From: Dmitry Belyavsky To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=20cf303b41cde697a504f94713e0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/aPz6EBC6HiDyGDV64d_8EiPhHeE Subject: [Trans] CT and non-public CAs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 12:19:46 -0000 --20cf303b41cde697a504f94713e0 Content-Type: text/plain; charset=UTF-8 Hello All, A lot of companies have their own CAs for their internal purposes (intranets, VPNs, etc). If CT support will be widely used, does it mean that such companies will have to configure their own (non-public) logs to avoid software's reports about absence of SCTs? -- SY, Dmitry Belyavsky --20cf303b41cde697a504f94713e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,

A lot of companies have thei= r own CAs for their internal purposes (intranets, VPNs, etc).=C2=A0
If CT support will be widely used, does it mean that such companies will= have to configure their own (non-public) logs to avoid software's repo= rts about absence of SCTs?=C2=A0


--
SY, Dmitry Belyavsky
--20cf303b41cde697a504f94713e0-- From nobody Tue May 13 05:42:45 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE341A00A8 for ; Tue, 13 May 2014 05:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 psco6XfGdtQ7 for ; Tue, 13 May 2014 05:42:40 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C802E1A00A5 for ; Tue, 13 May 2014 05:42:39 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so338565veb.10 for ; Tue, 13 May 2014 05:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oBL0/EHSKOYuAKWBCrcoOPMYosBdPRE9Zj/Dpo9kTOU=; b=ppzwUhfILGL1nw2nv0GJRjxrwpV1lIOENe3E8SIxETLT1C0zl49Gh3jMkjZmbghyim Qalm9C3AGXFvRxjm/DwFWvyaYtd780ufgpwnWLbmX4h1WFdT/K7mZJ2TcnS0s0Xhub/Q 61EEumMlMhnibH6yAjX3ZNoLtVUksdiusnDFi/uV1MF0mj+8NRqPxRgOmzafuuJbYbQt gVRkxXR25op59MySqiSuv6nIL+UDt4mv9FdP4bsVuSC13jkbshDiUe+tiQ6aUM0pS4d2 jeiT0LNrHGAYR3wkqBXPWUB53BEg/yWoSthDlT8oOp5pr1EEtllsV7xo27fAVDfO2ScH 9ogQ== 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=oBL0/EHSKOYuAKWBCrcoOPMYosBdPRE9Zj/Dpo9kTOU=; b=mqKTMA5Q7yz+DE7Zaq80hjYGW2AC45KYoIKHVmaC96qOzftTMKmRXE3NVFXVub9/nz papFZrgjxrWCtsvlxNSAklsshs7oV2ul9OCr1+JLcXla9/dDLOzbCuasYvUbUINZXW5V GhOYLjBTPNSlsB1GkUXEK0s/Z0/3Ce9M3uWXBuy4IOHvDJpOjx1V19ELiknC6hJv4Lpw XXJJ6NlqCuLr+HoPU4bc06rgIEBpjjUNxZ+YUdnuaTDq9R1z5vBFs8Lx7pXEXiyxQgGJ XrHWTIOsGZ95ZWCJGdguWrhmH/M6A+FLJUGDben+hQaMZWLLcEXb329L+9E+HR1SfbiO 7nHQ== X-Gm-Message-State: ALoCoQkzCVDpBxgevl5OYlfPdy3lpIBao7YsqZbSnM8t8cab20WjxkDgfXNtaG04kRSJFDVUwDfr MIME-Version: 1.0 X-Received: by 10.58.188.14 with SMTP id fw14mr267355vec.14.1399984953150; Tue, 13 May 2014 05:42:33 -0700 (PDT) Received: by 10.52.252.97 with HTTP; Tue, 13 May 2014 05:42:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 13:42:33 +0100 Message-ID: From: Ben Laurie To: Dmitry Belyavsky Content-Type: multipart/alternative; boundary=089e010d8498d2f23804f947652f Archived-At: http://mailarchive.ietf.org/arch/msg/trans/OplWJ7VA_nlrY5IkaJMqkr3m9yI Cc: "trans@ietf.org" Subject: Re: [Trans] CT and non-public CAs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 12:42:41 -0000 --089e010d8498d2f23804f947652f Content-Type: text/plain; charset=UTF-8 On 13 May 2014 13:19, Dmitry Belyavsky wrote: > Hello All, > > A lot of companies have their own CAs for their internal purposes > (intranets, VPNs, etc). > If CT support will be widely used, does it mean that such companies will > have to configure their own (non-public) logs to avoid software's reports > about absence of SCTs? > We anticipate browsers providing enterprise controls to either configure extra logs or disable them for certain CAs/domains. > > > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > -- Certificate Transparency is hiring! Let me know if you're interested. --089e010d8498d2f23804f947652f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 13 May 2014 13:19, Dmitry Belyavsky <beldmit@gmail.com><= /span> wrote:
Hello All,

A lot of companies have their own CAs for their internal purposes (intra= nets, VPNs, etc).=C2=A0
If CT support will be widely used, does it mean that such companies wi= ll have to configure their own (non-public) logs to avoid software's re= ports about absence of SCTs?=C2=A0

<= div> We anticipate browsers providing enterprise controls to either configure ex= tra logs or disable them for certain CAs/domains.
=C2=A0



--
SY, Dmitry Belyavsky

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




--
Certific= ate Transparency is hiring! Let me know if you're interested.
--089e010d8498d2f23804f947652f-- From nobody Tue May 13 06:55:22 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372BD1A00F0 for ; Tue, 13 May 2014 06:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qMDVbjpo71R for ; Tue, 13 May 2014 06:55:12 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id CCA6E1A0096 for ; Tue, 13 May 2014 06:55:12 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E24FE81703; Tue, 13 May 2014 09:55:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399989305; bh=dKCzEX8lWN4vAgZ1nFDsTgQspVGqXQ1wd+8MI7EwW1k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JRDmUyy1NwZVVltBmPmr/C9KETZepFg8kc31XtFd5QpwHR2MV7cwWPHUqpM1vJ/l9 M+s+u+0bUJ1P3Dp90oc6vyccWcnxkB1Zf/vrcGMCgDQ/wurQu/CxyX0oV8RdOwKj55 LVnvw8mSyaAzp82fnlm4lz9Ogkged2z6dL4qqOek= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4DDt5xj027859; Tue, 13 May 2014 09:55:05 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 May 2014 09:55:05 -0400 (EDT) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Vb5Yjv0JDPfFzRU8U4jmHuTNSGU Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 13:55:18 -0000 On Tue, 13 May 2014, Ben Laurie wrote: [DNSSEC CT] > Is it necessary to log anything other than keys? My base assumption was no: if the keys are as expected, then all records signed by those keys > can be trusted. If someone wants to publish RRsets that are other than the one the true domain owner wants to publish, they necessarily have > to inject a key they control, which becomes apparent from the logs. That would not allow us to detect coercion, that is a custom RRset signed to be used only for a targetted attack (by say, .com or the root) But I'm not sure how we _could_ detect that. Let's say they get an A record for www.victim.com that bypasses the NS RRset completely, that is, signed by the .com key. To notice this case, you would also need to log the change of zone cut. The other case is injection of a custom DS RRset. How would we tell the difference between the legitimate zone owner adding a DS record or an attacker/parent zone owner adding one? One defense would be to ignore any new DS record for a certain amount of time, but that runs into similar issues as pinning and TACK. Paul From nobody Tue May 13 07:41:35 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5F1A00BC for ; Tue, 13 May 2014 07:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 cfG-bX9066EG for ; Tue, 13 May 2014 07:41:31 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EA0CC1A00B2 for ; Tue, 13 May 2014 07:41:30 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id C15361B406B for ; Tue, 13 May 2014 07:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=acalljOfzrWXE4FD7xrc WWbQwI8=; b=giWlr9VSW7jMmMTEMOblM8QPQHw0GdILmGt/ZcaXp+9pCHOJbew4 q0rekwlPAI1GeF1C70fYouC++sE51FNhyVkjxeVrQL5r/GRUbUyNLJzt/zIZG6b+ ze2fRH8sUjTrYyBFbf1WjltxzSNALuIelDdi9mDodYws1zVKDrTcMPw= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 6641B1B4061 for ; Tue, 13 May 2014 07:41:24 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so6370859wib.17 for ; Tue, 13 May 2014 07:41:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr21112232wib.42.1399992082989; Tue, 13 May 2014 07:41:22 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 13 May 2014 07:41:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 09:41:22 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bxs-weiUYLlxXcmmzTm8XHstPNg Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:41:32 -0000 On Tue, May 13, 2014 at 8:55 AM, Paul Wouters wrote: > On Tue, 13 May 2014, Ben Laurie wrote: > > [DNSSEC CT] > > >> Is it necessary to log anything other than keys? My base assumption was >> no: if the keys are as expected, then all records signed by those keys >> can be trusted. If someone wants to publish RRsets that are other than the >> one the true domain owner wants to publish, they necessarily have >> to inject a key they control, which becomes apparent from the logs. > > > That would not allow us to detect coercion, that is a custom RRset signed > to be used only for a targetted attack (by say, .com or the root) > > But I'm not sure how we _could_ detect that. Let's say they get an A > record for www.victim.com that bypasses the NS RRset completely, that > is, signed by the .com key. To notice this case, you would also need to log > the change of zone cut. > > The other case is injection of a custom DS RRset. How would we tell the > difference between the legitimate zone owner adding a DS record or an > attacker/parent zone owner adding one? One defense would be to ignore > any new DS record for a certain amount of time, but that runs into > similar issues as pinning and TACK. Yes, these are the issues that need resolving. Hashing the RRset name doesn't help either where the attack is based on inserting a different RRset to misdirect the victim. Nor is it possible to audit logs to look for such attacks if there's no names. Still, if the goal is to get the root(s) and TLDs to stay honest, and since they don't need privacy, their logs can include unhashed names. Further below in the hierarchy things get murky; I have no answers as to those, but it seems likely that some (most! probably) zones below the TLDs will absolutely want protection against zone enumeration. Is a modicum of privacy possible with CT for the PKI? Nico -- From nobody Tue May 13 07:58:14 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67A01A00D7 for ; Tue, 13 May 2014 07:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 p7v2yiXMdcIp for ; Tue, 13 May 2014 07:58:11 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 148111A00DE for ; Tue, 13 May 2014 07:58:11 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id EC79B2007F21E for ; Tue, 13 May 2014 07:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6K1uOZMY8a/FvLkLiquK 4i0NYAY=; b=OWvwJx4F4TEieQZGsrRsSPrv0aKaIfMFSKRQ+2dOeH4R2r3C3Z8k v6oCPX3bAXirame9H4osL7HlD6afcjmXw/m52kdSCXI69Jw2psWRuAdQIJutSq4r uyzTPSCWymwOKWL0Qkn/kTJ/oCQjwXoD++0Tpijyucs6TXZpqdkJPyI= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id A1CEC2007F228 for ; Tue, 13 May 2014 07:58:04 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so516148wgh.19 for ; Tue, 13 May 2014 07:58:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.92.228 with SMTP id cp4mr1875314wjb.81.1399993083575; Tue, 13 May 2014 07:58:03 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 13 May 2014 07:58:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 09:58:03 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/0wvovTX6oVuyzwE9wazAtwJy3ig Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 14:58:12 -0000 To what degree are the privacy issues different for DNSSEC than for PKI? I would think: they aren't! Both are PKIs, both have public data, users (in the sense of having certificates) tend to want to avoid enumeration below certain points in the hierarchy. Nico -- From nobody Tue May 13 08:02:31 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E45C1A00DB for ; Tue, 13 May 2014 08:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 cXF4AwJperCE for ; Tue, 13 May 2014 08:02:18 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A01A008E for ; Tue, 13 May 2014 08:02:18 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hu19so607983vcb.20 for ; Tue, 13 May 2014 08:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jfP7HXmA6O4Plvzynz8F+QBu+Yymx1v+ft58hBjpEGM=; b=gsJedB3xxIP7NNqmCHIb0s+vF+/C0K3m5gjHSlrlPxwUMVrQZf55oxWnOdELxSjkfY 4wP7r3QFGdwwPZQZRClqwHvzhG0AY+6WZJ669OB8Aw5iq/NdJSt1V8EjEzt6oRwNWWVm BJLHzqXd2nZK7wZExH+iFqD0+N1A603MdNroXHsiTQnm3tRHJgBaUV5VarvX4NuyHfgP wfIcuXsoM8xu7q8oeQzEcT2acupQOuqqENRtkC9ABAs0YWnbg9cPtJgTuLLtfMN42fLy nGiUf3EP8vXKaalV+KjJFN5Fkms0+p1TdgODut3xrZ50nHY4QscalCmu0OQOadFu2aYp C5pg== 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=jfP7HXmA6O4Plvzynz8F+QBu+Yymx1v+ft58hBjpEGM=; b=d0CZxbl3MhAFuYSpi+HCPrrMBhLOZk7JxpgTuVJ0YuvA4LcKJfp4d+bUZeb07+oruq ryKc/17sNI7DpuUpRn9lnR3YPPac/v6DTA3QTeceioVCs7HCnlIwQkRCk5rdxPXrVa2v k9sveITb5F8ZsMqznDKlZtq4y8qN1yBtCkEB+BbNtDpkajtP3OMBhsMfnX9ivOKqTsfa UNyFAgDuZkbB91OWfw7CujPFN7hGRgJszvaJQf3Rfa9N9tcOcE+5JRyDdumV+0F+CnaG j2RjhGoCpVCd8i+MB9k4glZEtGUb5M7Ca8hXFoIK08q7i8kv7y5xk8esTrbfyiZBmKJ5 axvA== X-Gm-Message-State: ALoCoQnd6qGejkw1aP3t0ihq+2T0AjtKi3MKL9WMYhuzQA5s86tF2VvL1gDYXnqPU4Sh4yWO0F0S MIME-Version: 1.0 X-Received: by 10.220.163.201 with SMTP id b9mr256772vcy.79.1399993331863; Tue, 13 May 2014 08:02:11 -0700 (PDT) Received: by 10.52.252.97 with HTTP; Tue, 13 May 2014 08:02:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 16:02:11 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/zqhQLT2PD4m3CUJUCLEeNsMTn50 Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:02:21 -0000 On 13 May 2014 14:55, Paul Wouters wrote: > > On Tue, 13 May 2014, Ben Laurie wrote: > > [DNSSEC CT] > > >> Is it necessary to log anything other than keys? My base assumption was no: if the keys are as expected, then all records signed by those keys >> can be trusted. If someone wants to publish RRsets that are other than the one the true domain owner wants to publish, they necessarily have >> to inject a key they control, which becomes apparent from the logs. > > > That would not allow us to detect coercion, that is a custom RRset signed > to be used only for a targetted attack (by say, .com or the root) > > But I'm not sure how we _could_ detect that. Let's say they get an A > record for www.victim.com that bypasses the NS RRset completely, that > is, signed by the .com key. To notice this case, you would also need to log > the change of zone cut. OK, good point: zone cuts need to also be verified. > The other case is injection of a custom DS RRset. How would we tell the > difference between the legitimate zone owner adding a DS record or an > attacker/parent zone owner adding one? The legitimate owner can tell - that's the point, right? > One defense would be to ignore > any new DS record for a certain amount of time, but that runs into > similar issues as pinning and TACK. > > Paul -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue May 13 08:12:29 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F741A0124 for ; Tue, 13 May 2014 08:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 KyJ7Z4uZRTPr for ; Tue, 13 May 2014 08:12:18 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 74E2C1A0125 for ; Tue, 13 May 2014 08:11:39 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 1660A2007F008 for ; Tue, 13 May 2014 08:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=g48Y6LRCtThv6aMbKR++ gMsxTes=; b=ibrT3uKFllhqDJHSbxxzotzJHWMrggbnekRvGxtmIBsj9zY8LbgX H9lNg2TXWJTUFoRW6YVnhe16uBv92GMJWUn9qebls6mkqVixkxBc0/LcJqQqnOit Va5zRtF5zyyW+iqh081bzW2+7Rm4tClVV7aCvfN+CEhyxXGEySh6u8o= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id BF8212007F003 for ; Tue, 13 May 2014 08:11:32 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so7264616wib.3 for ; Tue, 13 May 2014 08:11:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr21252934wib.42.1399993891648; Tue, 13 May 2014 08:11:31 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 13 May 2014 08:11:31 -0700 (PDT) In-Reply-To: <537231FC.4010007@fifthhorseman.net> References: <537231FC.4010007@fifthhorseman.net> Date: Tue, 13 May 2014 10:11:31 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5yM3EYb-MJlWAMsAJxnpSrFPqdo Cc: Ben Laurie , "trans@ietf.org" , Joseph Bonneau , Warren Kumari , Paul Wouters Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:12:20 -0000 On Tue, May 13, 2014 at 9:53 AM, Daniel Kahn Gillmor wrote: > On 05/12/2014 02:01 PM, Nico Williams wrote: >> The ones that matter most are the TLDs and the root. Those get so >> many users that they will be caught MITMing, if they do. > > I think technically what we care about is the public registries, not the > TLDs. This was my point about the public suffix list and DBOUND: that > we care about .co.uk just as much as we care about .net. > > I know that some people use the term TLD to refer to the public > registries instead of "top-level domains", but i think it's worthwhile > to be precise in this discussion. That's fair. I do tend to think of co.uk. as a TLD... for lack of a better term (is there one?), yes. You're quite right: if a zone is (has) a public registrar(s) then it should be audited w/o privacy. Whereas if it doesn't sell registrar services, then it is less important that it log names: we can assume that names below it are roughly in the same administrative domain as the zone itself. >> If evilhosting.com has lots of customers, then they'll help audit it, >> else they might not. > > If evilhosting.com is handing out subdomains to its customers and > expecting them to act as different administrative sub-zones, then > evilhosting.com effectively *is* a public registry, and as such it needs > to be auditable as well. (it also needs to be considered a public > registry for the sake of cookies and other same-origin policy things on > the web, for example, so that jbonneau.evilhosting.com can't set cookies > that would apply to dkg.evilhosting.com). Agreed. > Who is actually doing the monitoring and auditing is a separate > question, though. > > note that CT appears to differentiate between monitoring (RFC 6962 > section 5.3) and auditing (RFC 6962 section 5.4) in this way: > > Auditors make sure that SCTs are cryptographically valid against an > STH, and that one STH chains properly to another; > > Monitors make sure that the whole log itself is cryptographically > valid, looking at all the data. > > Neither of these activities describes the actual checks that would need > to happen for misissuance to be detected. As noted in section 7.2, > "interested parties" need to think about how to monitor to ensure that > items with their administrative domains are not logged by other parties. I would think that domain owners are "interested parties", and/or maybe agents they delegate to (e.g., hosting companies). I can audit the logs for my domain's parent zone. But yes, this probably needs to be covered in more detail. (Are there FOSS implementations of monitors/auditors?) > If this is neither "Monitoring" nor "Auditing" maybe we need a name for > this kind of activity, so we can discuss it more directly? how about > "misissuance review"? It seems to fall into "monitoring" given the text of the RFC. > How does she know what logs to look in for this misissuance review? Is > there a way she can do this review efficiently? I think these questions > are relevant for regular CT as well, but a DNSSEC-focused CT adds the > wrinkle of delegated zones. (maybe this isn't actually worse than X.509 > PKI with its fully-delegated intermediate CAs though?) No, it's easier! With the name contraint-free TLS PKI the domain owner has to check... every root CA. With DNSSEC, which has strict name constraints, there's only one issuer for each zone cut. Nico -- From nobody Tue May 13 08:34:00 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAD61A011D for ; Tue, 13 May 2014 08:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoJ0FsHIvwoX for ; Tue, 13 May 2014 08:33:55 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id F2F761A00B2 for ; Tue, 13 May 2014 08:33:54 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DBD7B813B3; Tue, 13 May 2014 11:33:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399995227; bh=VjvVkssJfAdKbHQRS6j0RzJn9ybyZt3+AKKCf7uxpBw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZNFZq1vGJYZEiZv5bTSbAhM6bj9mhPzWsvHlFJKn+XXApLGssOw/xjlIfFei705iX BjodBc3ymLMXoSE90+8EIYGoO+enwz3OIS/36a22WpdQYECPB9WdMMG95TmQBpVcpe C2kFYwRRhSn1bcBUlpBd9M1X0Czkq8odiUEk/pZM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4DFXlu4000636; Tue, 13 May 2014 11:33:47 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 May 2014 11:33:47 -0400 (EDT) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/z5s5SqpRP5C70xHH2He2ePACwKk Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:33:58 -0000 On Tue, 13 May 2014, Ben Laurie wrote: > OK, good point: zone cuts need to also be verified. > >> The other case is injection of a custom DS RRset. How would we tell the >> difference between the legitimate zone owner adding a DS record or an >> attacker/parent zone owner adding one? > > The legitimate owner can tell - that's the point, right? How does that help protect a non-owner user of someone's site being attacked with a targetted attack? If I don't run victim.com, and I am just a visitor of victim.com, but only I am given rogue DNSSEC records, how can I tell something is wrong? I would go to the public log and see the DS I received is not in there? (I'm late in this discussion, so I wouldn't know how this gets authenticated by the consumer and the victim.com's owner, especially if the parent could do a hostile takeover) Paul From nobody Tue May 13 08:40:48 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665A51A010A for ; Tue, 13 May 2014 08:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 YLGeE7S1p8Fg for ; Tue, 13 May 2014 08:40:44 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 93B981A0102 for ; Tue, 13 May 2014 08:40:44 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id il7so695736vcb.4 for ; Tue, 13 May 2014 08:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DMyetM2s/vW42hd7tI1AAuZVFaaz9K86IBMASOf98iY=; b=X7WCzru0GBJvTTetGEdiJBQfoaeL+AEPndOwcu4a+RLRe5V9GpZyd4YxCqBYzd/VGz G/tkTmIByV5dkSrFqXISf3Y6Q1ItnCEQjGCsNoiqH5Bsc8ej4UJvHy2578yXZf9j6fvw 8SQcoieRas8MBQAaJ/z5+vi49fdCTcv0WDg0CxKa1uBKejFAMmE+87kPtRqNRKJLZvmy vUQYDpbT36R36gen9HWrouxVM8av3ovvPCFQerHbOiPM0QDdtDjCvJUXXmBNlO2FE0Ip QoV6o5+IfnW/oTn/mPDJe3/0YI9Wce/NYMB9bneLTzq+EOs6JFqcaiqnz+YioVIUEweI SAOg== 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=DMyetM2s/vW42hd7tI1AAuZVFaaz9K86IBMASOf98iY=; b=Ge5Q2oQOhe2SGrWfnDOHOUMZMGK8PY4CA2AuPD8sOX2umZUoJZ4HMVP9ZVxXjnZG9I +BkN3/JXU50H9OXO3QMsr7NbiUtTaoBNolvXNonfzXQ6H89B7ioemA68nd9vIuUGiwSR b84NBOncRMoO2S6yKbJTnDMjcHlg7Y/kX8rpzwMGQ2eGNbJWSrKbi+EL8AtjYFBzDU5z OMW0gjqQhFJS7GOqH4WXZNM5c3kmBAd74KdIgJQLjcE+tv66JnMvY4mGy+7yUgep+ZAL Bxjw3t1EIXwBaI40ZoxlxXpQzhXHq6nxnfdVhJG26OBoZ7m5ZQ+SmPlO1P4lo3BgMvWv vA2w== X-Gm-Message-State: ALoCoQlWhde9ZONUCtHeQYsKPedV3GUP16s0AojP2UD9z6ccB4D2xSQmRObU//LDqVTx0RxumSZY MIME-Version: 1.0 X-Received: by 10.58.122.164 with SMTP id lt4mr29970575veb.2.1399995637981; Tue, 13 May 2014 08:40:37 -0700 (PDT) Received: by 10.52.252.97 with HTTP; Tue, 13 May 2014 08:40:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 16:40:37 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/kuHvvEEtSz17txBg1gAWviTvqZ8 Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:40:46 -0000 On 13 May 2014 16:33, Paul Wouters wrote: > On Tue, 13 May 2014, Ben Laurie wrote: > >> OK, good point: zone cuts need to also be verified. >> >>> The other case is injection of a custom DS RRset. How would we tell the >>> difference between the legitimate zone owner adding a DS record or an >>> attacker/parent zone owner adding one? >> >> >> The legitimate owner can tell - that's the point, right? > > > How does that help protect a non-owner user of someone's site being > attacked with a targetted attack? If I don't run victim.com, and I am > just a visitor of victim.com, but only I am given rogue DNSSEC records, > how can I tell something is wrong? I would go to the public log and see > the DS I received is not in there? Right, exactly. > > (I'm late in this discussion, so I wouldn't know how this gets > authenticated by the consumer and the victim.com's owner, especially > if the parent could do a hostile takeover) > > Paul -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue May 13 09:11:37 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188841A0115 for ; Tue, 13 May 2014 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 DYEseMpeRRfY for ; Tue, 13 May 2014 09:11:26 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 997161A0117 for ; Tue, 13 May 2014 09:10:37 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by hapkido.dreamhost.com (Postfix) with ESMTP id C39CA9280A for ; Tue, 13 May 2014 08:59:55 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 8B3B0584064 for ; Tue, 13 May 2014 08:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VMaLJpv/9ahMw1ok3bT1 at+yGL4=; b=RCZQBDr0AJt3tP259ykPysj1ZlMl3YNUwRd16bwsAPd0JLZpb8By TyoGSxkrHVtrN/NhrZE5LY6RF+UlsUirKYSl5lZ6EnarPVnuYH/i6ugj74e7REkr 8s4niWHlR9mQGb3x4+kYdCajHCXUdMqJrLLxo5QSYK6n4+7hHz3WTnw= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 29AEA584065 for ; Tue, 13 May 2014 08:54:33 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so599975wes.14 for ; Tue, 13 May 2014 08:54:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.59.231 with SMTP id c7mr213796wjr.95.1399996472669; Tue, 13 May 2014 08:54:32 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 13 May 2014 08:54:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 10:54:32 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mvta1iPdIF0f6WJlVvUjRBOikmA Cc: "trans@ietf.org" , Ben Laurie Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:11:35 -0000 On Tue, May 13, 2014 at 10:33 AM, Paul Wouters wrote: > On Tue, 13 May 2014, Ben Laurie wrote: >> OK, good point: zone cuts need to also be verified. >> >>> The other case is injection of a custom DS RRset. How would we tell the >>> difference between the legitimate zone owner adding a DS record or an >>> attacker/parent zone owner adding one? >> >> The legitimate owner can tell - that's the point, right? > > How does that help protect a non-owner user of someone's site being > attacked with a targetted attack? If I don't run victim.com, and I am They check that what they see appears in the issuers' logs and rely on domain owners to monitor their issuers. If at all possible TLS (and other) clients will tell their peers what STHs the saw, and the servers can check that those appear in the log). If enough domain owners do this then targeted MITM attacks get harder to pull off without being detected. This is the herd immunity theory: eventually the risk of detection is so high for would-be MITMers that they won't risk it at all (except, of course, for cases like open war, where detection is a non-issue). This seems especially likely to be the case for DNSSEC because of caching. > just a visitor of victim.com, but only I am given rogue DNSSEC records, > how can I tell something is wrong? I would go to the public log and see > the DS I received is not in there? Yes. Or that it is. If it is and your peers monitor the logs then you can at least rest easy that the likelihood of MITM issuer detection is very high. Nico -- From nobody Tue May 13 09:11:53 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FB11A0102 for ; Tue, 13 May 2014 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLk13-XSge_P for ; Tue, 13 May 2014 09:11:41 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 999561A011A for ; Tue, 13 May 2014 09:10:56 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CDBA8813B3; Tue, 13 May 2014 11:57:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399996624; bh=XO3xhpYH+scnjcW+5lA3IdEDH+02Vwnk/uJKcSwh8i0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=aSQ+DehiKFcNjtP6ghyJdC8wsDqQfLksACkqLz7WqcBVwexA0x39aQkJOFSAgkyKr 9CcoE5mU1iq0mmLoKtcSlsfa8oy7DGBmLngk+5vslk2T9sPgC9/PLdg7zb+71FnIlx +SY37jDW33ure2fhtLyta0VNeANnHI53KlnsFjqI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4DFv4Pg007272; Tue, 13 May 2014 11:57:04 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 13 May 2014 11:57:04 -0400 (EDT) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4hMRi_oFxPsoDAD6zWLUTGof8y0 Cc: Trans Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:11:52 -0000 On Tue, 13 May 2014, Ben Laurie wrote: >>> The legitimate owner can tell - that's the point, right? >> >> How does that help protect a non-owner user of someone's site being >> attacked with a targetted attack? If I don't run victim.com, and I am >> just a visitor of victim.com, but only I am given rogue DNSSEC records, >> how can I tell something is wrong? I would go to the public log and see >> the DS I received is not in there? > > Right, exactly. So how does the owner authorize a new DS in such a way that the parent could not override? I'm reminded of the dlv.isc.org setup, where the zone owner had to prove control of the private key by publishing something in the zone. In a way this is also similar to the DS update problem in general. A rogue/hacked registry could also perform a DS update. I'm still not sure how to prevent a rogue update in the CT. And once you fix the rogue update problem, you face the reverse problem. A zone legitimately changes ownership and the old owner is malicious. How do you deal with that? Adding transition time into the equation could address some of this, but that will re-add the pinning problems. And adding another kind of authentication key would be adding similar problems as with TACK. Maybe some of these attacks are just out of scope and unfixable. After all, most domains are not "owned" but wrapped in legalese to really only give me a limited lease on it. In that case, we could do things like "warn if a DS is present in the DS RRset that has not been logged into the CT with a known signature by a current KSK" and "zone cut changed KSK". I'm just not sure how many false positives that would give with people rolling keys too fast for the CT log (and slow enough to indeed give that added protection). The last thing we need is another "cert patrol" style avalanche of popups. Paul From nobody Tue May 13 09:17:25 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C23D1A00DD for ; Tue, 13 May 2014 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 FMtprOS_V-tH for ; Tue, 13 May 2014 09:17:20 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A98F11A00B2 for ; Tue, 13 May 2014 09:17:20 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so733301veb.38 for ; Tue, 13 May 2014 09:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zTv/dbYC9jx3EWZYZKXqMbakV2zd71Pw27yAgkGJ0T8=; b=Plt3TVyaD1CV9PlswIP2UOPKaGVppsHKrNrL7xwM/wu5Tk2a4gBVfNFNorPWHrTglB qM0SQ9HytAZZxLKEnR/aeVmZLXYmqVaBipzkqlzUdqF65bn3Fn3vZnPEjobCT8Ivp+p5 0Q/uPahhRvzENhd+l2564IobgaZ+bTd+D2MPj2Q5hD9BFZEchsh4BL/74S7QAOUq40XX SVne75Y/EdJMJKihsUtD5vqtHMcQBeaApHG1+87O4HDjh6sEVz7cXqllK4KhQ6tWQBZx yYxzdatQ8dRBcLvkBwImd7+bSE1DLhlJZQnjsdTNMpW0IDtIfU542/k8wwoJRAiaNXm3 F+GA== 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=zTv/dbYC9jx3EWZYZKXqMbakV2zd71Pw27yAgkGJ0T8=; b=XCLNo7mT3wOh0YuG76CKQu67UnkLy2h3RRQaaMeJXaV0x5nxLHhVDN6k05JJkA+00Q rR2UNNDGq3xXYoajov5Df49Zpc2fUKtXS80KHiEVi952ceca9Lj1FKmwPSLgbHePn5W1 sdKa3uxxxELig/D6Q9Y29DKww0eXyNIQ8jm9b/9UxnBmKz3CEQ6QimXJqxwrYoUln4t2 83KXj12x+8dzpMRUj7XVwK/0h4oIYsxvX2acYiWgJzAg6BR+CeCEX/uv4OnA/MTV+4Oo IT8XfgQnVBucYMMKJHXMjStL47kPnL0fPu3JBOAHcPD4APyrB/sWwVz0PMSYERzQRphI Temw== X-Gm-Message-State: ALoCoQl6svufBLmEQaO0QauVt2ZFna0cWelWMVEfnwAM1s/Lbl7VOdVIj9ctYSDNRTg9IeFe2LjZ MIME-Version: 1.0 X-Received: by 10.221.36.73 with SMTP id sz9mr1001286vcb.62.1399997834160; Tue, 13 May 2014 09:17:14 -0700 (PDT) Received: by 10.52.252.97 with HTTP; Tue, 13 May 2014 09:17:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 17:17:14 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4hbnbyX1g5T08QyfNCNbJzn9iMM Cc: Trans Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:17:22 -0000 On 13 May 2014 16:57, Paul Wouters wrote: > On Tue, 13 May 2014, Ben Laurie wrote: > >>>> The legitimate owner can tell - that's the point, right? >>> >>> >>> How does that help protect a non-owner user of someone's site being >>> attacked with a targetted attack? If I don't run victim.com, and I am >>> just a visitor of victim.com, but only I am given rogue DNSSEC records, >>> how can I tell something is wrong? I would go to the public log and see >>> the DS I received is not in there? >> >> >> Right, exactly. > > > So how does the owner authorize a new DS in such a way that the parent > could not override? I don't know: this is not a question transparency addresses. Transparency allows the owner to detect that the parent has overridden. What happens then depends on how it is all supposed to work, which I presume varies by registry/registrar. > I'm reminded of the dlv.isc.org setup, where the zone owner had to prove > control of the private key by publishing something in the zone. In a way > this is also similar to the DS update problem in general. A rogue/hacked > registry could also perform a DS update. > > I'm still not sure how to prevent a rogue update in the CT. And once you > fix the rogue update problem, you face the reverse problem. A zone > legitimately changes ownership and the old owner is malicious. How do > you deal with that? It seems to me that this is a contractual/legal/infrastructural question. CT allows everyone to verify that everyone has done what they're supposed to (modulo their own knowledge of what "supposed to" is). Once you discover they haven't, then you have to invoke mechanisms that are nothing to do with CT. > Adding transition time into the equation could address some of this, > but that will re-add the pinning problems. > > And adding another kind of authentication key would be adding similar > problems as with TACK. > > Maybe some of these attacks are just out of scope and unfixable. After > all, most domains are not "owned" but wrapped in legalese to really only > give me a limited lease on it. > > In that case, we could do things like "warn if a DS is present in the DS > RRset that has not been logged into the CT with a known signature by a > current KSK" and "zone cut changed KSK". I'm just not sure how many > false positives that would give with people rolling keys too fast for > the CT log (and slow enough to indeed give that added protection). > > The last thing we need is another "cert patrol" style avalanche of > popups. Agreed. And one thing you may have to accept is that CT leaves open a window during which attacks are feasible, but guarantees that they can eventually be discovered. This is certainly the case for the PKI version of CT. I think you can reduce the size of the window in various ways - for example, preventing key roll until logs have caught up, or until logs and monitors have caught up. -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue May 13 12:14:34 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ACB1A0185 for ; Tue, 13 May 2014 12:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkzh5409m1MR for ; Tue, 13 May 2014 12:14:30 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 392751A010C for ; Tue, 13 May 2014 12:14:30 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so640440pbb.11 for ; Tue, 13 May 2014 12:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LQZn7/FTFJOTp/3igMa524dMSZUGThaf/mcq2Y1bYnM=; b=dunmF0SKpch4VrBhlzZmqFk+tnfTXTRhnYStEOrAMBQQH79b4gOmGaf8Sjehrbqs64 eJ0ODVwaDnMphkrnvpUhJ46CsjV8RItReswVGYbiJ03HfjvF+naMyRjDP2frPUcr0vc2 q1GxCkZ4J/6tyTgBxtxlXc18sxzRqlW04k02WrlD6pj4AKGbQfaSx53IpI2inuZonmsI 0MQ3piX9laiQAYF3W+tOpO+cZH4iVRhnajnZrIrfm8WwXls8U5vk45jCFKmIFUk/lpLw VT0XARXnYAcn/pi1oNZ5feAvnvrhc1jJgiuji25xHBtEpu0uzzGeTV6nOYmv8MZ0HgSh gdrg== X-Received: by 10.68.226.105 with SMTP id rr9mr7407426pbc.161.1400008463609; Tue, 13 May 2014 12:14:23 -0700 (PDT) Received: from spandex.local (216-67-48-234-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.48.234]) by mx.google.com with ESMTPSA id qv9sm29570014pbc.71.2014.05.13.12.14.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 12:14:22 -0700 (PDT) Message-ID: <53726F0C.6020907@gmail.com> Date: Tue, 13 May 2014 11:14:20 -0800 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: Dmitry Belyavsky References: <5371ACFB.5020604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/tm6B1bOmzr27j_eF0v0JVpxMpsY Cc: "trans@ietf.org" Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 19:14:31 -0000 On 5/13/14 12:41 AM, Dmitry Belyavsky wrote: > Can it be a starting point or you want something else? It's certainly a very good starting point for discussion. We've got a couple of options for publishing text on client behavior. One would be to propose some text for inclusion in 6962bis. Another would be to write up a draft, start a discussion, and see if there's interest in picking it up as a working group document. Publishing a draft should not be seen as a big deal - they're used in the IETF in a number of ways, including as scratch pads for ideas/discussion. You might also wish to open an issue in the issue tracker. Melinda From nobody Tue May 13 12:22:14 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A311A0188 for ; Tue, 13 May 2014 12:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsvRCH8iS4ci for ; Tue, 13 May 2014 12:22:10 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id DE5ED1A0164 for ; Tue, 13 May 2014 12:22:09 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 20so689800yks.37 for ; Tue, 13 May 2014 12:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J4tgU4O+rIFw1+bLQrvG+JI/FmxdwqJ6spbOTRrgFUE=; b=YC2dQzgmGSQYFmqf+EXmmzNDLdzJci0rYwr3PLvChAHN5xGT0Ss0FU5eOYfWT6XUwg 5LBl4l8d87iceb0YdMkeoiGg/k25a/jaMrmDgfuYLoGBBDwILQIcTysUNBDWkVl5MSr1 TItCv8xop7MyooI9jQQ+755Vv7icZZ6X7KyFbiQfIpsZ5AGoA8QgcILWQrK2FO9iN647 pzL/vt1iEInTZDH6c15lHo2OYCQsURxkrx2UqO5aCm+Mc4hLrx6viqag7QikQ4HLeKLX dL2b58ZGicaJzCJMWvw27PSnyIb4g9Noh/OuAmvK/PhIynuA4vpCfat1hPZI88+TtHOw uxhw== MIME-Version: 1.0 X-Received: by 10.236.165.102 with SMTP id d66mr54119795yhl.67.1400008923451; Tue, 13 May 2014 12:22:03 -0700 (PDT) Received: by 10.170.91.85 with HTTP; Tue, 13 May 2014 12:22:03 -0700 (PDT) In-Reply-To: <53726F0C.6020907@gmail.com> References: <5371ACFB.5020604@gmail.com> <53726F0C.6020907@gmail.com> Date: Tue, 13 May 2014 23:22:03 +0400 Message-ID: From: Dmitry Belyavsky To: Melinda Shore Content-Type: multipart/alternative; boundary=20cf30563c3790955804f94cfa94 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/B60GjWMUK0anu1cZg6p-SK4Gl9k Cc: "trans@ietf.org" Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 19:22:12 -0000 --20cf30563c3790955804f94cfa94 Content-Type: text/plain; charset=UTF-8 Hello Melinda, On Tue, May 13, 2014 at 11:14 PM, Melinda Shore wrote: > On 5/13/14 12:41 AM, Dmitry Belyavsky wrote: > > Can it be a starting point or you want something else? > > It's certainly a very good starting point for discussion. > We've got a couple of options for publishing text on client > behavior. One would be to propose some text for inclusion > in 6962bis. Another would be to write up a draft, start > a discussion, and see if there's interest in picking it up > as a working group document. Publishing a draft should not > be seen as a big deal - they're used in the IETF in a number > of ways, including as scratch pads for ideas/discussion. > > You might also wish to open an issue in the issue tracker. > I think that, if my submission after discussion, is good enough, it should be a part of 6962bis. But I think that the specification of the gossip protocol should be a separate document. -- SY, Dmitry Belyavsky --20cf30563c3790955804f94cfa94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Melinda,


On Tue, May 13, 2014 at 11:14 PM, Melinda Shore <melinda.shore@gmail.com> wrote:
On 5/13/14 12:41 AM, Dmitry Belyavsky wrot= e:
> Can it be a starting point or you want something else?

It's certainly a very good starting point for discussion.
We've got a couple of options for publishing text on client
behavior. =C2=A0One would be to propose some text for inclusion
in 6962bis. =C2=A0Another would be to write up a draft, start
a discussion, and see if there's interest in picking it up
as a working group document. =C2=A0Publishing a draft should not
be seen as a big deal - they're used in the IETF in a number
of ways, including as scratch pads for ideas/discussion.

You might also wish to open an issue in the issue tracker.
=

I think that, if my submission after discussion, is goo= d enough, it should be a part of =C2=A06962bis.

Bu= t I think that the specification of the gossip protocol should be a separat= e document.


--
SY, Dmitry Belyavsky
--20cf30563c3790955804f94cfa94-- From nobody Wed May 14 15:16:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638531A032F for ; Wed, 14 May 2014 15:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7518sxWsGsx for ; Wed, 14 May 2014 15:16:09 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 52A971A032E for ; Wed, 14 May 2014 15:16:09 -0700 (PDT) Received: (qmail 17730 invoked by uid 0); 14 May 2014 22:16:01 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 14 May 2014 22:16:00 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id 1yFx1o00d2UhLwi01yG0J3; Wed, 14 May 2014 16:16:00 -0600 X-Authority-Analysis: v=2.1 cv=EOmVjTpC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=4eyjf-e663kA:10 a=xojvF6Qnh0oA:10 a=3NT3xRclEPMA:10 a=N659UExz7-8A:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=vS7MmSmxvPQA:10 a=pE7ifguLAAAA:8 a=1XWaLZrsAAAA:8 a=3vSUqmUqjfIkEuI9opIA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=JqEYdk2rMmSHXuhweeTY63LqJt9wc/gev2XxQAr2gtQ=; b=JCjRr71nUijWndIq4KJBx6JQe0NkrfLkvODtPxJt1XrvJNq1SkiKAD/jFyfDvNIypR6FxlVy/Xl/9zdBQgcJdup88VimutCn18U60bPYZ/HY1PEZGppHe85XSzb8LKqX; Received: from [216.113.168.128] (port=55434 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WkhSv-0001ow-G5; Wed, 14 May 2014 16:15:57 -0600 Message-ID: <5373EB1B.9000906@KingsMountain.com> Date: Wed, 14 May 2014 15:15:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: wpkops@ietf.org, trans@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Archived-At: http://mailarchive.ietf.org/arch/msg/trans/BTk9pfuyv-A8n5XlyraxAF3AWSk Subject: [Trans] fyi: Analyzing Forged SSL Certificates in the Wild X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:16:10 -0000 Analyzing Forged SSL Certificates in the Wild Lin-Shung Huang=03, Alex Ricey, Erling Ellingseny, Collin Jackson Abstract=97The SSL man-in-the-middle attack uses forged SSL certificates to intercept encrypted connections between clients and servers. However, due to a lack of reliable indicators, it is still unclear how commonplace these attacks occur in the wild. In this work, we have designed and implemented a method to detect the occurrence of SSL man-in-the-middle attack on a top global website, Facebook. Over 3 million real-world SSL connections to this website were analyzed. Our results indicate that 0.2% of the SSL connections analyzed were tampered with forged SSL certificates, most of them related to antivirus software and corporate-scale content filters. We have also identified some SSL connections intercepted by malware. Limitations of the method and possible defenses to such attacks are also discussed. https://www.linshunghuang.com/papers/mitm.pdf news coverage.. https://news.google.com/news?ncl=3DdCtyuKtyM9cSNPM9nzTnp15Wfnh4M&q=3DIopF= ailZeroAccessCreate&lr=3DEnglish&hl=3Den&sa=3DX From nobody Sat May 17 16:44:29 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657C41A017D for ; Sat, 17 May 2014 16:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwkkGl0qSZtI for ; Sat, 17 May 2014 16:44:24 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDAE1A017B for ; Sat, 17 May 2014 16:44:23 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rd3so4135271pab.29 for ; Sat, 17 May 2014 16:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=9WY3emasN0Fpw7f7FNur2bIrM2tvYVM/nzQ+sZVrc9A=; b=jTLMMZzpZM6KXLRhpiOp/6G4DK9GiF34fxsHHCvf4fxwdTGvlgSfWySVWt5JqKWRIE 00HDB0DyDReoM44AnXdgj1Ju/5XuLv1dMe1CshfSiGIsWJeVoczCV7xW06FpK2fZfzr9 FozX8rcec68RMtZOm+Is7dvtiDYRWW6JUSDxeEvnRFw+aq4WsElRHtt+/uUCTo4WY90v WxkCKQMVcs+jvnkZFK9pZu8Osq0/cOWz1b9cz4tToMPbhEPaB9hUoxekJuAFhQxZ9IVR a4rDuqX+ezLXDLtTXSUYGo0ztrM64lfm3NYMQ2aVsA82ZZsJ+brvJuqFpWJSblsCUIXa eFxA== X-Received: by 10.69.1.69 with SMTP id be5mr31788187pbd.126.1400370263483; Sat, 17 May 2014 16:44:23 -0700 (PDT) Received: from spandex.local (63-140-81-2.nwc.dsl.dynamic.acsalaska.net. [63.140.81.2]) by mx.google.com with ESMTPSA id bc4sm21938757pbb.2.2014.05.17.16.44.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 May 2014 16:44:22 -0700 (PDT) Message-ID: <5377F454.5030006@gmail.com> Date: Sat, 17 May 2014 15:44:20 -0800 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: <9913.1400250296@sandelman.ca> In-Reply-To: <9913.1400250296@sandelman.ca> X-Forwarded-Message-Id: <9913.1400250296@sandelman.ca> Content-Type: multipart/mixed; boundary="------------050006080901050003050707" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/aR3yaoEcutF11lBRyzzcYZLxyek Subject: [Trans] Fwd: NomCom 2014-2015 Call for Volunteers 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, 17 May 2014 23:44:26 -0000 This is a multi-part message in MIME format. --------------050006080901050003050707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There are a number of ways to contribute to the IETF, and participating in the Nomcom is an extremely important one. If you have attended three out of the last five IETF meetings please give some serious thought to volunteering. Melinda -------- Original Message -------- Subject: NomCom 2014-2015 Call for Volunteers Date: Fri, 16 May 2014 10:24:56 -0400 From: Michael Richardson Reply-To: nomcom-chair-2014@ietf.org To: ietf@ietf.org {I have to post using my subscribed address. Appologies for duplicates} The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org --------------050006080901050003050707 Content-Type: application/pgp-signature; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xMiAo R05VL0xpbnV4KQoKaVFFVkF3VUJVM1lmdDRDTGNQdmQwTjFsQVFLNEVnZi9WZmxWbmdiTHU3 NEhpai83WUtDbGVLcG8ybWZUVi90NAplcWhacndkWkh1SlhrbTdlZWEzbk5TdG5jQXRiY0dD R1hUZXY1WThEMkFMdkJtamdUZlpRano0YXNkcjVNU3BnCkZ3aEM1ZVNSRVJFbVpiSU5mbjdY L2NtOHZFc1RpWjFDbndPUUdHMWxPVjFUQ1Q4TWg0aEFNYnZpZWJtRHdOdFkKTWVmU1VkV21S YkF4TkdqbDJmQkRoeDRvV3lNaDNaa1hyWnNwMlNHMzloUWoweFZUcGEvdXJvMGRqNFB3Q0NK SgpjTXFnbUVKd1V1VXpLc3RCdzY4U3BsT3B5ZUIreDZxZ1QwcmVaK0Z2RXhtbk8rZlhDdDRI c25yRG9DQkREckp4CmdJQVBEaTVsdVpmSndzM1pxbmhJLzNoVTFNaHVpT0dickhRRkpoYURt aiswTk9YbzNXbkR2dz09Cj1PUHM3Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --------------050006080901050003050707-- From nobody Tue May 20 11:59:40 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD001A00E9 for ; Tue, 20 May 2014 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJxDE9DatVmp for ; Tue, 20 May 2014 08:09:17 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8331A0182 for ; Tue, 20 May 2014 08:09:15 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1147783wib.1 for ; Tue, 20 May 2014 08:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=+47MP6nV7kecTlM2P9/zZCOm7CZkgMN6Z8/s5FyJ8Mc=; b=k6ICF5mpcwdcB0wZGPVAsqG421HpJRgd5623y+3LhIXQiXpgE4cENL9+AAESvYv8Rq EFQqFn7cUB3oTa0OYBYSh8vvoQfkQd0m0b/v8fuFG2sqsr8zzGosfPBn3ajH1tQlox24 nBAWNuZW+TMEpLKZM7kDl59kEWg8MC9ry4p6zOPyoiW//rSj6S3NdonhzQAHAJn2cTuu gbPif34rcKs/FJ0pBJLIELXwl4fwbUI8ivEWCErJPNIn0J7xmflmKzLjI1EWVtOD2hPj 93wmrOAlZy4MCd0TR8y+GCOUtbtWLJXEyq0FQAuBnWvw7pA2hhGgHEP5KZTxjgS4jegS mCuA== MIME-Version: 1.0 X-Received: by 10.180.13.139 with SMTP id h11mr4725236wic.34.1400598553742; Tue, 20 May 2014 08:09:13 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.157.9 with HTTP; Tue, 20 May 2014 08:09:13 -0700 (PDT) Date: Tue, 20 May 2014 11:09:13 -0400 X-Google-Sender-Auth: BK-vaPEuFRDp82cZrh_BCkCmYxg Message-ID: From: Phillip Hallam-Baker To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/6l8ZN-5-zY0-0agjZeMLmTzN9kw X-Mailman-Approved-At: Tue, 20 May 2014 11:59:39 -0700 Subject: [Trans] How to make use of DNSSEC + TRANS 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, 20 May 2014 15:09:22 -0000 I started this discussion on the Apps list but the technology that would make it work is TRANS so I thought I would raise it here as well. One of the big problems with DNS is that I don't buy a DNS name, I can only rent it. And that means that names that are DNS bound can always be reassigned in the future. Which is one of the reasons why HTTP urls are unsatisfactory. Larry Masinter has of course raised this sort of concern before and proposed dated URLs. But this morning a different approach to the problem occurred to me: Lets take a URL at a web site and imagine I download a page on 1st Jan 2010: http://www.cnn.com/whatever.html Now what if I wanted to connect up today to the same party that I connected to last time. This is not the same as the URN or the dated URL problem. I want to connect up to the same entity regardless of whom ICANN happen to sell the domain name to next. How about one of the following: http://www.cnn.com.2010/whatever.html http://www.cnn.com.1.2010/whatever.html http://www.cnn.com.1.1.2010/whatever.html DNS labels are not allowed to be all numbers but the DNS protocol works for them. In fact they seem to work with my existing software which was not a design goal but would be cool. Now resolving such names would of course require a new infrastructure, quite possibly a subscription infrastructure that would track the changing ownership of the names over time. And this infrastructure would probably involve Certificate Transparency like services and DNSSEC. But we could use this to provide persistence for Web content and for Web services which would be incredibly cool. We can also apply the same idea to email addresses: phill@hallambaker.com could be anyone. phill@hallambaker.com.16.5.2014 is uniquely my account. So the infrastructure that would be required here would be 1) A set of trans notary logs that people could register their DNSSEC KSKs in. 2) A set of DNS servers that accepted DNS zone updates for dated zones from the keyholders of the registered keys. The practical effect would be that once a name was registered and the key enrolled in the log, the holder of the key can then maintain the claim to the dated zone for as long as they hold the key. Resolution will continue to function as long as the keyholder provides updates. One of the uses for this type of technology would be in cyber conflict situations where we want to make use of a naming infrastructure that does not introduce a possible point of compromise. From nobody Tue May 20 17:23:02 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1401A03CC for ; Tue, 20 May 2014 17:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE692ZhJwTOz for ; Tue, 20 May 2014 17:23:00 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9621A0194 for ; Tue, 20 May 2014 17:22:59 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so7636304wib.1 for ; Tue, 20 May 2014 17:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=uzWr9X/LlezOrkZQ0j/E4wXi12GE7/56EveSzYCL+sI=; b=Otdw5G+Twp8U6pInE35uW2Ceaett4XUXh4XzC4/oHJX/Ztxi9OkrG7WFoh706wQ7Jl ZSCznzaUFAp9bHc2dEs3RINy39KqeSTlYJ41f4DBWf3XXOG5V9IW7nbw+2Ai2oO77Me9 XktdALiq6hB+tv2AMApUfQhZkl7DbpViUfquaowHPK2WpKsdQ1SvSaV2l3ix3J/IK/Wl nfGdS0Oo0r5nxv/I4AqGbSRmmu9w2X2kHgk4LygUcTfbLU1R3WgCr2/Ye3v31sPp/P5M xNQqmgomAOXbr6LkF7r36OfwK2UzaWjOQQbh+DJN2Y9xbAVBVpYbHIdAyqkYkRIa6Rl0 wdug== MIME-Version: 1.0 X-Received: by 10.194.103.36 with SMTP id ft4mr13103055wjb.66.1400631777932; Tue, 20 May 2014 17:22:57 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.157.9 with HTTP; Tue, 20 May 2014 17:22:57 -0700 (PDT) Date: Tue, 20 May 2014 20:22:57 -0400 X-Google-Sender-Auth: 2dUa9lZ2CAmRG35NQB2kMNub1ak Message-ID: From: Phillip Hallam-Baker To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-74HTmBTDMcdPU-YNir46RGgegI Subject: [Trans] Trans content types X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 00:23:01 -0000 If we are going to do trans in Internet apps we need to have a content-type for trans data. 5.1. Content-Type Identifiers The following content identifiers are defined elsewhere and repeated here for the convenience of implementers. application/ocsp-response OCSP Response token as specified in [RFC6090]. application/pkix-cert A single DER encoded PKIX Certificate as specified in [RFC5280]. TBS A Certificate Transparency notary chain as specified in [RFC6962]. application/pkcs-12 A PKCS#12 encrypted private key. From nobody Wed May 21 03:13:41 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABE11A04CA for ; Wed, 21 May 2014 03:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 Wm4Ymi7zH12x for ; Wed, 21 May 2014 03:13:38 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526121A04C5 for ; Wed, 21 May 2014 03:13:38 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so2221668vcb.1 for ; Wed, 21 May 2014 03:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rdKwM6hx2Xz7mgnpvbs/EdkRAjdpTGqc+IoxPgZyIXI=; b=COLIhYJnRQJ0jT/9CuGOVleHHDfNugqlB2hOp8rV0B5qs0gE8CG2MPVV2HpOthpV69 hwbT0tObjHh0DiDrcOhHtQa67tBZN+MnPwOrTC8qPakDe3dGxP2f9Lh1aH8OnzUYUSpj nTTAhfNQ1bLV1CuHq7Xoo6/Zz710GQ93aCyPhIazr/a2gAmp8zg0S6uZXAbfCYEUOcKO zKuYFsCJ0HsLFr4IlxqbV66Sqgik4rhwvBN6Cgnl+Rvas5cIwaXviPiDmlIIgzrFlufa 2ICFTqnY1RtvI7KmvBWQSe7jMUkHTEAX1oktu5j2MMNTrN3r7u9yNr/8V/OkSz5XWFHN 5znw== 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=rdKwM6hx2Xz7mgnpvbs/EdkRAjdpTGqc+IoxPgZyIXI=; b=KuJ3lbevGhcSmIxMt8UbjOPaA8qOb4SvVJaK3Wb7ubKFUweIK5SIO9u6ZvJOcOlUYl Q7Cr9461hbv39XUQ19tgWiv6QT6Tp/qwl3nMu0m6WLTW8upoTLZ5GgMhOzpbn/OKNkt2 4M59cTFjv0rRFfXxMM3BPS8P+SThTKbqnQKMTxpPW9cg8jRvhnP/6T7C011zPkctJKBx w7Wr79wuuhEp59RQYBus4maePNgmgViJSJWJ1WtF1/NSQcnQddPzvLq8sfbt0fhtuFpO PVLjaqnf0eu+Rg8n3ErJqEXeg3S4r9mXMRN5fxjkGBdnXLJWqnX3inbSDSgudCRIg7eQ C3zA== X-Gm-Message-State: ALoCoQm5mPTxUIM6tAhrHSM7u0lifVMXnKg0o7kSY4hCMfsrr694eN8Sxs4JzuPNJVRYv4NAYkYZ MIME-Version: 1.0 X-Received: by 10.58.219.166 with SMTP id pp6mr42219274vec.1.1400667216866; Wed, 21 May 2014 03:13:36 -0700 (PDT) Received: by 10.52.107.132 with HTTP; Wed, 21 May 2014 03:13:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 11:13:36 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/MoOW4O4v2Yow3Xm92Nz6guZwSfc Cc: "trans@ietf.org" Subject: Re: [Trans] Trans content types X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 10:13:40 -0000 On 21 May 2014 01:22, Phillip Hallam-Baker wrote: > If we are going to do trans in Internet apps we need to have a > content-type for trans data. When you say "trans data", do you mean the leaves? If we want to allow for general content, then there are some other variables, too - e.g. do you get an SCT (Signed _Content_ Timestamp :-) or a proof of inclusion (STH + Merkle Proof) on submission? Also, you need to specify where content types are included. If you want to submit a patch for review against the I-D, you can find it here: https://github.com/google/certificate-transparency/blob/master/doc/rfc6962-bis.xml > 5.1. Content-Type Identifiers > > The following content identifiers are defined elsewhere and repeated > here for the convenience of implementers. > > application/ocsp-response > OCSP Response token as specified in [RFC6090]. > > application/pkix-cert > A single DER encoded PKIX Certificate as specified in > [RFC5280]. > > TBS > A Certificate Transparency notary chain as specified in > [RFC6962]. > > application/pkcs-12 > A PKCS#12 encrypted private key. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Wed May 21 12:40:00 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCE41A070F for ; Wed, 21 May 2014 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEzhEKLQH7Of for ; Wed, 21 May 2014 12:39:57 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E361A082A for ; Wed, 21 May 2014 12:39:57 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y13so1687780pdi.30 for ; Wed, 21 May 2014 12:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=AzIQBwL4eiAwhbDbloGHY4dvuyWAE+zbtQQRu5+2ztg=; b=mtgqMBwlNSH6lcsGwSfYajmIuS8UntyOZ7cxMZ6wrqsiKzj/ruVjOj5ZWsZ9ZzdaIG JNl/VVZTNzRWhdgrSKCs49K52nHfIfuO/4E2YEwAw9A2gHNatd3bhYixsd1SNptRZaq/ CVeX2Q/tu20CcjkSxWbFuft8/v1PeKUP0MWUgHsuctybC3ykcnLCqP0m69v094ozmH9Y FhOPD49BwRaXyETD1Vabz9VAYeJDGorwwsr0PQ9QV1uG/m2pzTSv+ktY+tGemMtYhUoN CAJ+fPYHkAWMzvBUUrhR21BTmXjWIrghBFWObyMTTptnE8YghUUOtz62zfjwRbfxoPYR ORgQ== X-Received: by 10.69.15.2 with SMTP id fk2mr61456781pbd.123.1400701196093; Wed, 21 May 2014 12:39:56 -0700 (PDT) Received: from spandex.local (63-140-81-2.nwc.dsl.dynamic.acsalaska.net. [63.140.81.2]) by mx.google.com with ESMTPSA id uk1sm108992542pac.26.2014.05.21.12.38.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 12:38:15 -0700 (PDT) Message-ID: <537D00A5.7050103@gmail.com> Date: Wed, 21 May 2014 11:38:13 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Akwzl9DUfAJ83V5hqrtxdVA5iRw Subject: [Trans] CT for DNSSEC discussion - is someone writing a draft? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:39:58 -0000 It looks like there's interest in logging DNSSEC, but we haven't seen anybody step forward and say that they'll be producing a draft. Is someone planning on writing one, or do they know of someone doing an implementation? Melinda From nobody Thu May 22 03:05:09 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC9D1A00CD for ; Thu, 22 May 2014 03:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHbQqdIu91ms for ; Thu, 22 May 2014 03:05:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 087F31A0081 for ; Thu, 22 May 2014 03:05:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51A1FBE47 for ; Thu, 22 May 2014 11:05:06 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 257YglAhYzcf for ; Thu, 22 May 2014 11:05:06 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34D30BE39 for ; Thu, 22 May 2014 11:05:06 +0100 (IST) Message-ID: <537DCBD2.8070905@cs.tcd.ie> Date: Thu, 22 May 2014 11:05:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "trans@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Cx2tYgqrmGGsz6ciimO2V7TYPp8 Subject: [Trans] New co-chair - Paul Wouters X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 10:05:09 -0000 Hiya, Melinda has been flying solo with this group for the last while (and thanks for being willing to do that Melinda). Its generally better to have two chairs just in case stuff comes up, so I'm happy to announce that we've managed to get Paul Wouters to co-chair with Melinda. Please welcome Paul as your new co-chair. Cheers, S. From nobody Thu May 22 09:17:11 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09C11A01F3 for ; Thu, 22 May 2014 09:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 w5qaKLzMM-3Q for ; Thu, 22 May 2014 09:17:07 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19391A01ED for ; Thu, 22 May 2014 09:17:07 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ij19so4785435vcb.28 for ; Thu, 22 May 2014 09:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u04oa3NnUe3I6Gymdx/r2wYLE+2HMSrPDLF9uG0N7SU=; b=iVWYLVCnvr/kQXCWNoBAo52a5fZCTXW55jRD0dQuJfWgyQmZmxHjNZlTO/eUFWZwwh GpdLJuqqPctFIjTb4L4gbFefNVOpiaGfoFECs5lDBclve65XCPA3S19shFhEwo5EYWRb 8JP6GLVKIVb/1UuLXZAXJD83fmchNCg6hOU8+FLrEV0ozPnBBYXC+JjhxmcRbxZnuu2y BuP/44zOQYg2uys+I30+f9OZwO0qP7LhvuHrTq7OeUVyzciuFH0kE3dlxUe7DMOugrPN GzCIezV8KD0IISH2THGHmw0GxG6jyW30Fv60L6u+y19RUSWOu3sQh9pLPeE8C0jOVK3d j4Wg== 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=u04oa3NnUe3I6Gymdx/r2wYLE+2HMSrPDLF9uG0N7SU=; b=TW3XluDrP1CU71CNaBLaXdF8LClNhCZbb9v8skFaiXOBzJKTsvWD80F2uko42x/S8o BASpM0u5n+INRmCXBwcC4CH8tYGf/YmS1zvHF2WeekqHm5gd03DuY0fg/D7Db0EHqBIA mNCgKYM3scc2ADedJ6WkAfp+ELbyQyD6n78GWuv9i+2l2u/uAmXaeiMYOtivzFi3sPAp lOtnmz4214MhmW5DSdJvttpiuas6Pat4FCxCrxMN3eT+y0i91pAIcsCihHaTMRTwJfHR onCXISYNbuaCXMzZ64XT/Xvv51ccyYQy5FExDkX5USb6A5Rk3fR2dPpdIccdCE6xsS1O nrPg== X-Gm-Message-State: ALoCoQkTqpIuz7Cp9FJdFw5rbABRblzkMiTn+h9ugZ61gL9AcobjjxMonX//89Ll3ZMpS0hPkBTm MIME-Version: 1.0 X-Received: by 10.58.74.38 with SMTP id q6mr49233706vev.7.1400775425860; Thu, 22 May 2014 09:17:05 -0700 (PDT) Received: by 10.52.107.132 with HTTP; Thu, 22 May 2014 09:17:05 -0700 (PDT) In-Reply-To: <537DCBD2.8070905@cs.tcd.ie> References: <537DCBD2.8070905@cs.tcd.ie> Date: Thu, 22 May 2014 17:17:05 +0100 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7bacbedcab4d3e04f9ff7190 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ZvsV3uzfSz0yjzDXrO4ZyEZu21c Cc: "trans@ietf.org" Subject: Re: [Trans] New co-chair - Paul Wouters X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:17:09 -0000 --047d7bacbedcab4d3e04f9ff7190 Content-Type: text/plain; charset=UTF-8 On 22 May 2014 11:05, Stephen Farrell wrote: > > Hiya, > > Melinda has been flying solo with this group for the > last while (and thanks for being willing to do that > Melinda). Its generally better to have two chairs just > in case stuff comes up, so I'm happy to announce that > we've managed to get Paul Wouters to co-chair with > Melinda. Please welcome Paul as your new co-chair. > Welcome aboard, Paul. --047d7bacbedcab4d3e04f9ff7190 Content-Type: text/html; charset=UTF-8



On 22 May 2014 11:05, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

Melinda has been flying solo with this group for the
last while (and thanks for being willing to do that
Melinda). Its generally better to have two chairs just
in case stuff comes up, so I'm happy to announce that
we've managed to get Paul Wouters to co-chair with
Melinda. Please welcome Paul as your new co-chair.

Welcome aboard, Paul.

--047d7bacbedcab4d3e04f9ff7190-- From nobody Thu May 22 09:38:54 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C0B1A01F7 for ; Thu, 22 May 2014 09:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ_PY0o4DM-A for ; Thu, 22 May 2014 09:38:52 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0A61A01ED for ; Thu, 22 May 2014 09:38:46 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id rd3so2728873pab.35 for ; Thu, 22 May 2014 09:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sAd+4RJcXLDqiu5n1PjM9DhavMIkX64M8D/IhxhOu2A=; b=WRQV4d2ACJ02X5GgzVvQdZJNWTo4f6/rceM+QDcjtMCaaw8gCWUSJm3EN/0v2V9G3N +4/K0CeF2JDfAaRGOiPKLutfbt8cKvZajzyDH35ocL3ezB5pnFL7lywYoufamFEMfrMO iEEf5tohYs9hWukC1dUptFdzQ4+eN2+WmoieNe9hCkqaxRd4pft+gdRdhOu6V2eo225W qXJuVoX2WRIX+Vkej+iow5PJiOh3WnkL1J+UORJCV0sBofT+TiSqxQlwt6I44PSoUQRU 0qVRa4cbS2rg9pBSSxWuo9ohMEGSC0D4T4yHmiD1qDEuylMzxvC/3KAwpJy0mFkCD/D6 RnKg== X-Received: by 10.66.66.199 with SMTP id h7mr69804029pat.30.1400776725178; Thu, 22 May 2014 09:38:45 -0700 (PDT) Received: from spandex.local (63-140-81-2.nwc.dsl.dynamic.acsalaska.net. [63.140.81.2]) by mx.google.com with ESMTPSA id bs17sm1313472pac.28.2014.05.22.09.38.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 09:38:44 -0700 (PDT) Message-ID: <537E2812.4090704@gmail.com> Date: Thu, 22 May 2014 08:38:42 -0800 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: <537DCBD2.8070905@cs.tcd.ie> In-Reply-To: <537DCBD2.8070905@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/GjZU7-JE__Y8c2ZdL6-rssFdMIc Subject: Re: [Trans] New co-chair - Paul Wouters X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:38:53 -0000 Many thanks to Paul for stepping up. Right now the group is pretty quiet but I expect that to change as we move towards last call on the document and/if we start to see proposals for logging other applications. He also brings significant expertise to the discussions. Melinda From nobody Thu May 22 10:21:54 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C1B1A0226 for ; Thu, 22 May 2014 10:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 YnrCBp2p5io2 for ; Thu, 22 May 2014 10:21:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FD21A0219 for ; Thu, 22 May 2014 10:21:48 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57420) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WnWgm-000BBi-TO for trans@ietf.org; Thu, 22 May 2014 13:21:56 -0400 Message-ID: <537E3229.4070402@bbn.com> Date: Thu, 22 May 2014 13:21:45 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: trans@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Q6mcEHJuKYYgu4DNFbv6dvKMUoI Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:21:50 -0000 Nico, > DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. agreed. > It stands to reason that DNSSEC should have similar trust problems as > PKIX. I believe it does indeed. PKIX, per se, does not have the trust problems that seem to motivate CT; the Web PKI does. That PKI has always had a serious problem because any TA can issue a cert for any Subject, irrespective of the Subject name. because DNSSEC intrinsically incorporate the equivalent of PKIX Name Constraints, it does not suffer from that specific problem. That's not to say that mis-issuance is not possible in DNSSEC, but rather that its effects are more limited. > It follows that things like CT that we're applying to PKIX should be > applied to DNSSEC as well, where possible. maybe. > I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it > should be done. I'll defer to DNS experts on that. Steve From nobody Thu May 22 10:32:45 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF8F1A023D for ; Thu, 22 May 2014 10:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GeCB2i-pvJou for ; Thu, 22 May 2014 10:32:42 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63ED1A01C2 for ; Thu, 22 May 2014 10:32:41 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKU340uJmbpap4Mh9uvmUk5zaNrJ70u8l8@postini.com; Thu, 22 May 2014 10:32:40 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s4MHWdBV008179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 May 2014 13:32:39 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 22 May 2014 13:32:39 -0400 From: "Osterweil, Eric" To: "trans@ietf.org" Thread-Topic: [Trans] DNSSEC also needs CT Thread-Index: AQHPa84LSH1SIX2llEKvVF71u2zhO5tNMA6AgAADCgA= Date: Thu, 22 May 2014 17:32:38 +0000 Message-ID: <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com> References: <537E3229.4070402@bbn.com> In-Reply-To: <537E3229.4070402@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_EF12A61A-9F51-4CE6-918E-0A6B3818FF17"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/w078YCOxUY6QtylfLIm5_ep9cDg Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:32:44 -0000 --Apple-Mail=_EF12A61A-9F51-4CE6-918E-0A6B3818FF17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 22, 2014, at 1:21 PM, Stephen Kent wrote: > Nico, >> DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. > agreed. >> It stands to reason that DNSSEC should have similar trust problems as >> PKIX. I believe it does indeed. > PKIX, per se, does not have the trust problems that seem to motivate > CT; the Web PKI does. That PKI has always had a serious problem = because > any TA can issue a cert for any Subject, irrespective of the Subject = name. > because DNSSEC intrinsically incorporate the equivalent of PKIX Name > Constraints, it does not suffer from that specific problem. That's not = to > say that mis-issuance is not possible in DNSSEC, but rather that its > effects are more limited. >> It follows that things like CT that we're applying to PKIX should be >> applied to DNSSEC as well, where possible. > maybe. >> I don't see any reason why CT couldn't be extended to DNSSEC. IMO, = it >> should be done. > I'll defer to DNS experts on that. Without implying an presumption of expertise on DNS, I would argue that = DNSSEC avoids the problems CT seems to be trying to solve by coupling = its key learning (and verification) methods to the hierarchical = namespace. As Steve said (I believe) PKIX !=3D Web PKI, and the = problems addressed by CT seem to be focused more on the latter. I don't = think there is a key learning/verification dilemma in DNSSEC that CT is = appropriate for. Eric= --Apple-Mail=_EF12A61A-9F51-4CE6-918E-0A6B3818FF17 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyMjE3MzIzOVowIwYJKoZIhvcN AQkEMRYEFGkd3ov/wOKPdm27ZuQvR2P/WYFRMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBADtbEI+3lu8n8U3piJ+7jvXlQAGQ6a6lhf5O8HJye9RvSSr4fzbM kEJEpJ+g3iUl1w0V3JyDF7whq4DL4P9D8QABlIHo0JELNm7nwpcpYjQ2sZsTtXzvRmYViVqQGGKC IMc0A70lr7ypzxRf8Cbz82mSPdJNjxSf7rDOrmejRNsfjfj/ZmGAvzjcy/RW2zacsoQiiybKcQPq dfvrQ2/9wRG7ilO8QUAgiEZ2heCvW2NWD1EVPmMyfeL747/y6L1MU8XF20/5gqr4aai7dyQAA086 IhMNw2qrsUkfOkgxq7mQb8hyRt/Tpm9SXapbai/bJKXp21rFuFEexK2eexKXs/gAAAAAAAA= --Apple-Mail=_EF12A61A-9F51-4CE6-918E-0A6B3818FF17-- From nobody Thu May 22 10:33:01 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1258F1A0259 for ; Thu, 22 May 2014 10:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDeCutBu15w5 for ; Thu, 22 May 2014 10:32:59 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC3E1A024B for ; Thu, 22 May 2014 10:32:58 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so3739589wgh.20 for ; Thu, 22 May 2014 10:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I52WWhD4uYf2KrVy66eVjVNF1xIXK2uniaZUQ0qGkos=; b=ecMVZBoFScXuKS1MTWLh3tOOx55YemiTwxoQ2ZaDvXxfl+PAxUAJu7pqMl5MkjRqjG aJ6i6prX8BBbSQAt/AulHITcG/ZXErA18oDLCC1i+nOGhFWcYOTP/vm/lfoGonCXP2v1 DRemrH9RwlACex1FmEOQCopRkuINwoBeIVeQCLHfI0icu79oEKiYuQtjg9p6EhCn2Uaw UiHknN0oyM56xUosYU0FHwCxBOuYISQmRvTLCZ4sj67iy0WdxzO28y2xUmsCsaFyOK2E p5B1ojGIC0l7ndEYJ3i0YVNvWPwtcZ+6xXn0zF555ZQevudT4iW3fITyTRQOK9qwKimA IGXA== MIME-Version: 1.0 X-Received: by 10.180.101.6 with SMTP id fc6mr17446098wib.59.1400779976348; Thu, 22 May 2014 10:32:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Thu, 22 May 2014 10:32:56 -0700 (PDT) In-Reply-To: <537E3229.4070402@bbn.com> References: <537E3229.4070402@bbn.com> Date: Thu, 22 May 2014 13:32:56 -0400 X-Google-Sender-Auth: wpSxivotOSyUtJ04_JXxHyc9p-M Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wtwS1-nNWRghj3bpO0WqDcuhVEM Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:33:00 -0000 On Thu, May 22, 2014 at 1:21 PM, Stephen Kent wrote: > PKIX, per se, does not have the trust problems that seem to motivate > CT; the Web PKI does. That PKI has always had a serious problem because > any TA can issue a cert for any Subject, irrespective of the Subject name. > because DNSSEC intrinsically incorporate the equivalent of PKIX Name > Constraints, it does not suffer from that specific problem. That's not to > say that mis-issuance is not possible in DNSSEC, but rather that its > effects are more limited. On the contrary, it has a rather more severe problem in that the names can be reassigned by the upstream zone. Depending on your application, this might not matter. But if you want to try hooking an enterprise PKI off a DNSSEC system then this matters a great deal. I am sure that Google would not want to find that VeriSign could direct their infrastructure to change configuration by issuing a fraudulent DNSSEC signed zone. Come to that, that particular sort of compromise is the type of thing that we spent a lot of time and effort trying to put out of reach when I worked at VRSN. I don't want to have someone's private key because I don't want to be accused of losing it. Don't think of CT in this case being something to solve a problem faced by DNSSEC users, instead think of it as something that enables use for problems where it is otherwise unsuited. The other major advantage is that it provides a tool to avoid some of the cryptographic lock in problems that are causing certain countries to cause issues in ICANN. You don't have to agree with their analysis to find value in addressing the concerns. From nobody Thu May 22 10:38:56 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B201A0298 for ; Thu, 22 May 2014 10:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 MDm7mXs45jjr for ; Thu, 22 May 2014 10:38:47 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 35FBE1A0275 for ; Thu, 22 May 2014 10:38:39 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 08BA52007F232 for ; Thu, 22 May 2014 10:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Ski18ZQrVRHA1zw3WtHA mN3B6IY=; b=HzwgsQEDy68FqdMmWkTuAu3xq6zNBbjVN2bYV69VjiSXk8qM31JT U/ReREi6gCJP0I4dK5/dqczV39mkBzrM0JXWZvcxwa7g5LT7SgGrnHIsIsifSoPs 37lq9I6MC2B1bY/Qfr5jnEHm0UVUkBZJ0PuATTqemglctiTUlDee0yo= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id AF55A2007F227 for ; Thu, 22 May 2014 10:38:37 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so3781975wev.19 for ; Thu, 22 May 2014 10:38:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.185.244 with SMTP id ff20mr155696wic.42.1400780316578; Thu, 22 May 2014 10:38:36 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 22 May 2014 10:38:36 -0700 (PDT) In-Reply-To: <537E3229.4070402@bbn.com> References: <537E3229.4070402@bbn.com> Date: Thu, 22 May 2014 12:38:36 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/p87f80Muc-_eyWtytldA8PHBr6M Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:38:48 -0000 On Thu, May 22, 2014 at 12:21 PM, Stephen Kent wrote: >> DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. > > agreed. > >> It stands to reason that DNSSEC should have similar trust problems as >> PKIX. I believe it does indeed. > > PKIX, per se, does not have the trust problems that seem to motivate > CT; the Web PKI does. That PKI has always had a serious problem because > any TA can issue a cert for any Subject, irrespective of the Subject name. > because DNSSEC intrinsically incorporate the equivalent of PKIX Name > Constraints, it does not suffer from that specific problem. That's not to > say that mis-issuance is not possible in DNSSEC, but rather that its > effects are more limited. I've already said that DNSSEC fundamentally has strong naming constraints, whereas the TLS web server PKI doesn't (and worse: has been deployed with none). However, I don't think it necessarily follows that having name constraints -> no need for CT. CT is about keeping CAs honest. In the TLS web server PKI there are very many CAs to keep honest, therefore anything that helps automate that task is greatly helpful. DNSSEC "CAs" also could use being kept honest, even if none of them have yet failed to be honest. >> It follows that things like CT that we're applying to PKIX should be >> applied to DNSSEC as well, where possible. > > maybe. Sure, maybe. Nico -- From nobody Thu May 22 10:47:28 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9261A0236 for ; Thu, 22 May 2014 10:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6HCdrix0CiKy for ; Thu, 22 May 2014 10:47:24 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225031A01C2 for ; Thu, 22 May 2014 10:47:23 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKU344KbR3GBuzHA6IBAT1qa48OLjHcya2@postini.com; Thu, 22 May 2014 10:47:22 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s4MHlKV8008668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 May 2014 13:47:21 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 22 May 2014 13:47:20 -0400 From: "Osterweil, Eric" To: Nico Williams Thread-Topic: [Trans] DNSSEC also needs CT Thread-Index: AQHPa84LSH1SIX2llEKvVF71u2zhO5tNMA6AgAAEtQCAAAJuAA== Date: Thu, 22 May 2014 17:47:19 +0000 Message-ID: <8952DCE6-37BA-4063-8D6F-D061E9D50194@verisign.com> References: <537E3229.4070402@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_AECFFB06-05E8-4912-8AED-F2E3F03638D3"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5aOiuhce0PiUmHl39xXiYL5-C0o Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:47:25 -0000 --Apple-Mail=_AECFFB06-05E8-4912-8AED-F2E3F03638D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 22, 2014, at 1:38 PM, Nico Williams wrote: > On Thu, May 22, 2014 at 12:21 PM, Stephen Kent wrote: >>> DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. >>=20 >> agreed. >>=20 >>> It stands to reason that DNSSEC should have similar trust problems = as >>> PKIX. I believe it does indeed. >>=20 >> PKIX, per se, does not have the trust problems that seem to motivate >> CT; the Web PKI does. That PKI has always had a serious problem = because >> any TA can issue a cert for any Subject, irrespective of the Subject = name. >> because DNSSEC intrinsically incorporate the equivalent of PKIX Name >> Constraints, it does not suffer from that specific problem. That's = not to >> say that mis-issuance is not possible in DNSSEC, but rather that its >> effects are more limited. >=20 > I've already said that DNSSEC fundamentally has strong naming > constraints, whereas the TLS web server PKI doesn't (and worse: has > been deployed with none). >=20 > However, I don't think it necessarily follows that having name > constraints -> no need for CT. >=20 > CT is about keeping CAs honest. In the TLS web server PKI there are > very many CAs to keep honest, therefore anything that helps automate > that task is greatly helpful. >=20 > DNSSEC "CAs" also could use being kept honest, even if none of them > have yet failed to be honest. If I understand your point (perhaps I don't) the type of ``honest[y]'' = that you are talking about (in the Web PKI) refers to a CA vouching for = a name binding that is illegitimate. How do you imagine this is possible = in DNSSEC? I could (for example) stand up a DNSSEC signed zone for = someone else's zone, but because key verification and key learning are = tied to the DNS delegation hierarchy, no resolver would learn of my = doppelg=E4nger zone, right Eric= --Apple-Mail=_AECFFB06-05E8-4912-8AED-F2E3F03638D3 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyMjE3NDcxOVowIwYJKoZIhvcN AQkEMRYEFE8Wv53nTUCf+MvAJVzXVBL7ZQCmMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAB18wlLsC4Me5Ra9hbH9XIicEpWi6iSGx6w7unGViBNYDE/mzjVk zaT2j8TFbqKM9Lb9usbK5YEquIwKz0rtnQJ7bcoAgV4hXeeYbG/DTVzdEHQJl3yfM+E9+MY+T5z1 2ggmDAgiaV0Yx4+k5HJxVocmCVCEtyyyHaa4lszehw9TMLHSxih+wtR3TMZolbqCP+1IKMAb6FoZ ulLoqF/BSlP+3g7T3epk1k6ABSAV/VG3lXSIqOEYBNfMTnjMcv4BDzHrL4F0zd5bJyrq+h1DrpvO hY9F9vm10jJsBmM8aW+iMCKt7khkGDvX7Dl6I2B6Qr82+hFGJMpeJsxzj6NKk4sAAAAAAAA= --Apple-Mail=_AECFFB06-05E8-4912-8AED-F2E3F03638D3-- From nobody Thu May 22 10:55:18 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873BA1A026C for ; Thu, 22 May 2014 10:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZxwxc0EK4-6 for ; Thu, 22 May 2014 10:54:59 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200FC1A0289 for ; Thu, 22 May 2014 10:54:56 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5B1FB802BF; Thu, 22 May 2014 13:54:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1400781294; bh=dm4Cl97q0zS0HhsslwZawqAybGUJnxM8suRXtlHuZDY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LpOWQn/r0xZLYxupyNIqMGcESIIwG+Bnjgdk4kJpGwVbvm06rgHPd5qohZLPYAABT rihMjh+ZjmyER6dVCKBvMjYUusieLczb4kuvHgQNTypJgxSMaam3tImLRQyNEPcrkQ Sn4m/Pfi6X1mRVsnQVewO7ZMRx+J3Ezj7uQwzYjA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4MHsrT1006830; Thu, 22 May 2014 13:54:54 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 22 May 2014 13:54:53 -0400 (EDT) From: Paul Wouters To: "Osterweil, Eric" In-Reply-To: <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com> Message-ID: References: <537E3229.4070402@bbn.com> <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_WgO7diOtdwP_W_ejAu8p8eeoBo Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 17:55:10 -0000 On Thu, 22 May 2014, Osterweil, Eric wrote: > Without implying an presumption of expertise on DNS, I would argue that DNSSEC avoids the problems CT seems to be trying to solve by coupling its key learning (and verification) methods to the hierarchical namespace. As Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT seem to be focused more on the latter. I don't think there is a key learning/verification dilemma in DNSSEC that CT is appropriate for. There are some very visible and vocal people that have rejected DNSSEC flat out because it can be circumvented or co-erced by the higher up parental zones. They have an inherent distrust of the US Government, Verisign, ICANN, etc. In fact, they are often trying to replace the DNS with some peer-to-peer type solution for this very reason. I see CT-DNSSEC as a way to address that concern, and get those people onboard for DNS with DNSSEC security without the need for an alternative to DNS. Paul From nobody Thu May 22 11:01:35 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3941A028D for ; Thu, 22 May 2014 11:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWxvC7rQb0em for ; Thu, 22 May 2014 11:01:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5EE1A0276 for ; Thu, 22 May 2014 11:01:15 -0700 (PDT) Received: from [10.70.10.78] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D7C03F984; Thu, 22 May 2014 14:01:10 -0400 (EDT) Message-ID: <537E3B5A.8090808@fifthhorseman.net> Date: Thu, 22 May 2014 14:00:58 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Osterweil, Eric" , Nico Williams References: <537E3229.4070402@bbn.com> <8952DCE6-37BA-4063-8D6F-D061E9D50194@verisign.com> In-Reply-To: <8952DCE6-37BA-4063-8D6F-D061E9D50194@verisign.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aSun3IqLfTgx9fSBEQEgevxmdXvCNchFB" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AdmHWoprEa2RBWwb-JPcfOKcL9A Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:01:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aSun3IqLfTgx9fSBEQEgevxmdXvCNchFB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/22/2014 01:47 PM, Osterweil, Eric wrote: > If I understand your point (perhaps I don't) the type of ``honest[y]'' = that you are talking about (in the Web PKI) refers to a CA vouching for a= name binding that is illegitimate. How do you imagine this is possible i= n DNSSEC? I could (for example) stand up a DNSSEC signed zone for someon= e else's zone, but because key verification and key learning are tied to = the DNS delegation hierarchy, no resolver would learn of my doppelg=C3=A4= nger zone, right if i control zone foo.bar.example, and you control my parent zone (bar.example), you can do the following: * make a new zone-signing key X * stand up an "authoritative" server for the foo.bar.example zone, signed by X, with a DNSKEY record for X. * serve the appropriate DS record in the parent zone (bar.example) to delegate foo.bar.example to X instead of the correct ZSK. I'd very much like to know if you've ever done this rather than publishing the correct DS. DNSSEC-for-CT seems like one approach to be able to detect this kind of misissuance. --dkg --aSun3IqLfTgx9fSBEQEgevxmdXvCNchFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTfjtaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcqCkQAMVtPyICOURsWsSbAluX4EWK AbubHOurX21bzzErs3qn7O2GpMYSf8neGIjhU75wl6It2q3Kue1H08UfDrC+Qk9K +vSkqvnOFXYC7zk5KBxV1p+pcjfS4rOXKNOka672sL9fviQJSqJ/U5OkZwD4vyxl VSNNsrJifNuTDK5+uCaKKFucNJijIwLoMdUrAOyJPQ9F3sRTwsBpAcegjinIK0wb uFc0phpVKBt/5DB+M5/hdVBlcp3fWh6usp4aDpznnzNMgf5NVzrgAccxeD5cZOFl HmMq/Dzt8xNYEr91ViMYd20AzuonZZu4iN6w9CpqF2ZMAFa12vr+bE9dGlblepB4 qJs5FxwzI2+don/qloJxBB81ZQnIS0eO8hfSACxhLtvMhsty5i57z3pCzSzo+HAT e/EJwIgfcPHCjPBENIpFIzorJIBkCYnwyrWWWwZDoqRosrzqsW0soNROpgkEV1yL lQ4Xi9X00oiaJY1eGk7yWiZa1MqimwYFeUwIIxIvjZYzi9Kzxm7YxfJI2p1hWFfy eLQ1aZ9ryJw+1281gtGnQQtSy18RHkt1kpepMb7CRE3qPShK8jgbVQ7dzhpHQJk7 Ot1Pmo+CEXQF79glRIlnRCcKuPHuU6UkXtzxc/134Jg79nIwVVBLp3O/Eocxqbaq fBDejYSo0cQmBaIGsg4T =0JO1 -----END PGP SIGNATURE----- --aSun3IqLfTgx9fSBEQEgevxmdXvCNchFB-- From nobody Thu May 22 11:12:43 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC01A0274 for ; Thu, 22 May 2014 11:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 qWe_yLU1TFK8 for ; Thu, 22 May 2014 11:12:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF251A0271 for ; Thu, 22 May 2014 11:12:39 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57454) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WnXTz-000BZe-Bh for trans@ietf.org; Thu, 22 May 2014 14:12:47 -0400 Message-ID: <537E3E13.30709@bbn.com> Date: Thu, 22 May 2014 14:12:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <5371ACFB.5020604@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080808080901020306070308" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FRYsXmPCX-4iVqZdLm2lyL3c2lo Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:12:41 -0000 This is a multi-part message in MIME format. --------------080808080901020306070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dimitry, Thanks for posting the list below. I have become very concerned that the doc we're working on describes a mechanism, but we seem to lack a good description of the architectural context in which CT is supposed to work. The intro text for the I-D is not at all adequate for this. Maybe the charter for this WG would have included the need to publish a doc of this sort if we had gone through the usual BoF process :-). I'd like to see a doc that addresses a number of points that are now beginning to be raised by several folks: - who is expected to operate logs, does every log cover all CAs, is one log per CA (even if operated by someone else) adequate, how are users supposed to select logs (what the UI like?), etc. - how are browsers expected to deal with missing SCTs, missing or non-matching log entries, (crypto) invalid log entries, etc. are browser actions supposed to be effect in real time or is this deferred activity model? - hard fail vs. warnings for CT "exceptions?" - how are browsers expected to deal with certs from CAs that are not part of the Web PKI? - what are the fallback plans if some number of the Web PKI CAs elect to not participate? - same question for major browser vendors? - what are the plans for alg aglity, for logs? CT is a system, not just a handful of mechanisms. It needs to be described that way. Although not perfect, I suggest the set of RFCs that describe the RPKI is illustrative of the many aspects of a global system (with PKI aspects) that need to be documented. Steve > > > > Here are my ideas about "strict" behaviour of the TLS client: > > ============== > TLS clients supporting CT are supposed to have a preconfigured set of > logs and > their public keys. > > In addition to normal validation of the certificate and its chain, > they should > validate the SCTs received during the TLS connection. > > The client fully conforming to the specification SHOULD perform the > following > steps before establishing the connection for every certificate in the > chain: > > 1. If no SCTs are provided, the client SHOULD reject the connection. > > 2. The client MUST ignore all the SCTs provided by unknown logs. > > 3. TLS clients MUST reject SCTs whose timestamp is in the future. > > 4. If no SCTs has left after steps 2-3, the client SHOULD reject the > connection. > > 5. If any of SCTs left after steps 2-3 has invalid signature, the > client SHOULD reject the connection. > > Client MAY check whether the certificate is present in the log > corresponding to the passed SCT. > If the certificate is not present in the log, the connection MUST be > rejected. > ============= > > Can it be a starting point or you want something else? > > -- > SY, Dmitry Belyavsky > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --------------080808080901020306070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dimitry,

Thanks for posting the list below.

I have become very concerned that the doc we're working on describes a mechanism,
but we seem to lack a good description of the architectural context in which CT
is supposed to work. The intro text for the I-D is not at all adequate for this.
Maybe the charter for this WG would have included the need to publish a doc of
this sort if we had gone through the usual BoF process :-).

I'd like to see a doc that addresses a number of points that are now beginning to
be raised by several folks:
    - who is expected to operate logs, does every log cover all CAs, is one
log per CA (even if operated by someone else) adequate, how are users supposed to
select logs (what the UI like?), etc.
    - how are browsers expected to deal with missing SCTs, missing or non-matching
log entries, (crypto) invalid log entries, etc. are browser actions supposed to be
effect in real time or is this deferred activity model?
    - hard fail vs. warnings for CT "exceptions?"
    - how are browsers expected to deal with certs from CAs that are not
part of the Web PKI?
    - what are the fallback plans if some number of the Web PKI CAs elect to not
participate?
    - same question for major browser vendors?
    - what are the plans for alg aglity, for logs?

CT is a system, not just a handful of mechanisms. It needs to be described that way.

Although not perfect, I suggest the set of RFCs that describe the RPKI is illustrative
of the many aspects of a global system (with PKI aspects) that need to be documented.

Steve


Here are my ideas about "strict" behaviour of the TLS client:

==============
TLS clients supporting CT are supposed to have a preconfigured set of logs and
their public keys.

In addition to normal validation of the certificate and its chain, they should
validate the SCTs received during the TLS connection.

The client fully conforming to the specification SHOULD perform the following
steps before establishing the connection for every certificate in the chain:

1. If no SCTs are provided, the client SHOULD reject the connection.

2. The client MUST ignore all the SCTs provided by unknown logs.

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

4. If no SCTs has left after steps 2-3, the client SHOULD reject the connection.

5. If any of SCTs left after steps 2-3 has invalid signature, the client SHOULD reject the connection.

Client MAY check whether the certificate is present in the log corresponding to the passed SCT.
If the certificate is not present in the log, the connection MUST be rejected.
============= 

Can it be a starting point or you want something else?

--
SY, Dmitry Belyavsky 


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

--------------080808080901020306070308-- From nobody Thu May 22 11:12:46 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96821A0283 for ; Thu, 22 May 2014 11:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Zq2oZ2xcCZY5 for ; Thu, 22 May 2014 11:12:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2401A0271 for ; Thu, 22 May 2014 11:12:42 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57455) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WnXU3-000BZk-NG for trans@ietf.org; Thu, 22 May 2014 14:12:51 -0400 Message-ID: <537E3E17.8000901@bbn.com> Date: Thu, 22 May 2014 14:12:39 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <537E3229.4070402@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4pGFzA5UIgNVxwaNtanZ32LKrMM Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:12:44 -0000 PHB, > On Thu, May 22, 2014 at 1:21 PM, Stephen Kent wrote: > >> PKIX, per se, does not have the trust problems that seem to motivate >> CT; the Web PKI does. That PKI has always had a serious problem because >> any TA can issue a cert for any Subject, irrespective of the Subject name. >> because DNSSEC intrinsically incorporate the equivalent of PKIX Name >> Constraints, it does not suffer from that specific problem. That's not to >> say that mis-issuance is not possible in DNSSEC, but rather that its >> effects are more limited. > On the contrary, it has a rather more severe problem in that the names > can be reassigned by the upstream zone. is that really more "serve" than an ability to issue a credential for ANY name, as in the Web PKI? > Depending on your application, this might not matter. But if you want > to try hooking an enterprise PKI off a DNSSEC system then this matters > a great deal. I am sure that Google would not want to find that > VeriSign could direct their infrastructure to change configuration by > issuing a fraudulent DNSSEC signed zone. A large, competent enterprise (if that's not an oxymoron) can run its own PKI w/o using DNSSEC. This seems like a red herring. > Come to that, that particular sort of compromise is the type of thing > that we spent a lot of time and effort trying to put out of reach when > I worked at VRSN. I don't want to have someone's private key because I > don't want to be accused of losing it. no argument there. > Don't think of CT in this case being something to solve a problem > faced by DNSSEC users, instead think of it as something that enables > use for problems where it is otherwise unsuited. That's a very confusing last phrase. > The other major advantage is that it provides a tool to avoid some of > the cryptographic lock in problems that are causing certain countries > to cause issues in ICANN. You don't have to agree with their analysis > to find value in addressing the concerns. I understand their concerns. But the lack of a well-articulated architecture for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether this is a good idea. Steve From nobody Thu May 22 11:25:06 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6C41A02AC for ; Thu, 22 May 2014 11:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 ryVbuqpngzMI for ; Thu, 22 May 2014 11:25:00 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFA51A02AD for ; Thu, 22 May 2014 11:24:53 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id E9BC14012D68E for ; Thu, 22 May 2014 11:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=jis4ZhvOVGigV6sZvmKg eiiJe9I=; b=cJNjvTVSkhSbPzNKL3ElUZQuE0/HCDZeIjvwU/5BRQkZtjuRdVXe qVXf5IfdTGpBkdNm92rJq0WUr4Mu8VbCZmM9otk+QgLw72LWyhjE+3smP1ULbuKr OCr8tkxEkhLHdjDbpvw2DYQasdxqViqRsRvgaiCaQtqwxw+akYfdYhw= Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 95E674012D68B for ; Thu, 22 May 2014 11:24:51 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so3713902wgh.15 for ; Thu, 22 May 2014 11:24:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.142.205 with SMTP id ry13mr4041575wjb.69.1400783090296; Thu, 22 May 2014 11:24:50 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 22 May 2014 11:24:49 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 22 May 2014 11:24:49 -0700 (PDT) In-Reply-To: <537E3E17.8000901@bbn.com> References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> Date: Thu, 22 May 2014 13:24:49 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: multipart/alternative; boundary=089e0122f1b681338704fa013a52 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hCSgFuNg5u1Qc_y0NJS7APYNTP0 Cc: trans@ietf.org Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:25:02 -0000 --089e0122f1b681338704fa013a52 Content-Type: text/plain; charset=UTF-8 On May 22, 2014 1:12 PM, "Stephen Kent" wrote: > > PHB, > >> On Thu, May 22, 2014 at 1:21 PM, Stephen Kent wrote: >> Don't think of CT in this case being something to solve a problem >> faced by DNSSEC users, instead think of it as something that enables >> use for problems where it is otherwise unsuited. > > That's a very confusing last phrase. I had no problem reading it. Your complaints that we're all inarticulate are getting old. >> The other major advantage is that it provides a tool to avoid some of >> the cryptographic lock in problems that are causing certain countries >> to cause issues in ICANN. You don't have to agree with their analysis >> to find value in addressing the concerns. > > I understand their concerns. But the lack of a well-articulated architecture > for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether > this is a good idea. In other words, your concern is about CT in general, not DNSSEC in particular. Sounds like a separable issue to me. But if CT makes sense then it makes sense for DNSSEC. Nico -- --089e0122f1b681338704fa013a52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 22, 2014 1:12 PM, "Stephen Kent" <kent@bbn.com> wrote:
>
> PHB,
>
>> On Thu, May 22, 2014 at 1:21 PM, Stephen Kent<kent@bbn.com> =C2=A0wrote:
>> Don't think of CT in this case being something to solve a prob= lem
>> faced by DNSSEC users, instead think of it as something that enabl= es
>> use for problems where it is otherwise unsuited.
>
> That's a very confusing last phrase.

I had no problem reading it.=C2=A0 Your complaints that we&#= 39;re all inarticulate are getting old.

>> The other major advantage is that it provides a too= l to avoid some of
>> the cryptographic lock in problems that are causing certain countr= ies
>> to cause issues in ICANN. You don't have to agree with their a= nalysis
>> to find value in addressing the concerns.
>
> I understand their concerns. But the lack of a well-articulated archit= ecture
> for CT, much less a CT for DNSSEC, makes it hard for me to gauge wheth= er
> this is a good idea.

In other words, your concern is about CT in general, not DNS= SEC in particular.=C2=A0 Sounds like a separable issue to me.=C2=A0 But if = CT makes sense then it makes sense for DNSSEC.

Nico
--

--089e0122f1b681338704fa013a52-- From nobody Thu May 22 11:48:49 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3425D1A029D for ; Thu, 22 May 2014 11:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 x8pPaDK_p19u for ; Thu, 22 May 2014 11:48:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAED21A02B0 for ; Thu, 22 May 2014 11:48:32 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57980) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WnY2i-000Bsb-Fg; Thu, 22 May 2014 14:48:40 -0400 Message-ID: <537E467C.7010405@bbn.com> Date: Thu, 22 May 2014 14:48:28 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Nico Williams References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/pFEWQu38RoFDmeIWIQZ4IydAQas Cc: trans@ietf.org Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:48:47 -0000 Nico, > > ... > > > > That's a very confusing last phrase. > > I had no problem reading it. > a literal reading of it is as sarcasm. If that's PHB's intent, fine, but I just wanted to verify that there was no typo. > > Your complaints that we're all inarticulate are getting old. > not everyone, but a lot of messages and docs seem to validate my complaint :-). > >> The other major advantage is that it provides a tool to avoid some of > >> the cryptographic lock in problems that are causing certain countries > >> to cause issues in ICANN. You don't have to agree with their analysis > >> to find value in addressing the concerns. > > > > I understand their concerns. But the lack of a well-articulated > architecture > > for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether > > this is a good idea. > > In other words, your concern is about CT in general, not DNSSEC in > particular. Sounds like a separable issue to me. But if CT makes > sense then it makes sense for DNSSEC. > yes, my complaint about a lack of a doc describing CT architecture is not specific to the CT for DNSSEC discussion. CT may be appropriate for the Web PKI, w/o being a great idea for DNSSEC. Until we have a doc that describes the architecture, we can't evaluate how good it is in either context. Steve From nobody Thu May 22 13:46:05 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89751A0370 for ; Thu, 22 May 2014 13:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJHeKoqOKuPI for ; Thu, 22 May 2014 13:46:02 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351F61A034D for ; Thu, 22 May 2014 13:46:00 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so4975925wib.12 for ; Thu, 22 May 2014 13:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=roc/NfoQ5fF6uVQmJfdlU/IRR2/QXFx7SmtxPE+u6YY=; b=LkssVkkJFigrolKUCqfQEhv20cM2lbd9gFlfCKULguUfq6dOthXbDTi54oih++SRsv qsa1ykYUhbyhCs9ORJkMAYHOT2+YPZ49+cqeWAJUZ696WqA6uWLnXEuKRTH23/A5XV2r v60y9bbrkIwwe0za5WfzYsOVi86uidD+GXlCvbim3mpdp+iBHBlb+XVfg7RNoAqs1NGC 9M82OjWUo0YkQUp+zNtQB6m2UPVCdskK77cMxRVNeVu43S+Rkv4CbJlxGjXiutYKsEKP eykj/gAmevCQjt9YNwHA6pBrYQpUOH/JKw1+kPZ69ANbavkQlRiFH1y4VBmzU+orDjah BxSw== MIME-Version: 1.0 X-Received: by 10.180.105.72 with SMTP id gk8mr18417893wib.32.1400791557749; Thu, 22 May 2014 13:45:57 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Thu, 22 May 2014 13:45:57 -0700 (PDT) In-Reply-To: <537E3E17.8000901@bbn.com> References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> Date: Thu, 22 May 2014 16:45:57 -0400 X-Google-Sender-Auth: boTA6ZFHQi57Gr-x4POQHqXIczg Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/WCuOOkSfy0DLhfO2ApGkogAxQC0 Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:46:03 -0000 On Thu, May 22, 2014 at 2:12 PM, Stephen Kent wrote: > PHB, > >> On Thu, May 22, 2014 at 1:21 PM, Stephen Kent wrote: >> >>> PKIX, per se, does not have the trust problems that seem to motivate >>> CT; the Web PKI does. That PKI has always had a serious problem because >>> any TA can issue a cert for any Subject, irrespective of the Subject >>> name. >>> because DNSSEC intrinsically incorporate the equivalent of PKIX Name >>> Constraints, it does not suffer from that specific problem. That's not to >>> say that mis-issuance is not possible in DNSSEC, but rather that its >>> effects are more limited. >> >> On the contrary, it has a rather more severe problem in that the names >> can be reassigned by the upstream zone. > > is that really more "serve" than an ability to issue a credential > for ANY name, as in the Web PKI? At least that is a temporary condition. Any trust infrastructure that ultimately rests on the common sense of the US Congress and President is doomed in the long run. And there isn't a better political solution on offer either. Finding a technical mechanism that reduces the dependence on the political/policy dimension makes it much easier to address that layer. If it is possible it is always far easier to eliminate a single point of failure than to work out policy level controls to prevent abuse. >> Depending on your application, this might not matter. But if you want >> to try hooking an enterprise PKI off a DNSSEC system then this matters >> a great deal. I am sure that Google would not want to find that >> VeriSign could direct their infrastructure to change configuration by >> issuing a fraudulent DNSSEC signed zone. > > A large, competent enterprise (if that's not an oxymoron) can run its own > PKI w/o using DNSSEC. This seems like a red herring. If they already have a PKI then they are probably not interested in DNSSEC at all because that problem is already solved and DNSSEC is the red herring. Unless that is there is an interesting way to use DNSSEC as an extension of the enterprise PKI. In which case it is critical that the DNSSEC PKI does not introduce a new point of failure. >> Don't think of CT in this case being something to solve a problem >> faced by DNSSEC users, instead think of it as something that enables >> use for problems where it is otherwise unsuited. > > That's a very confusing last phrase. DNSSEC is still raw technology. Saying that it does not need feature X before the full set of potential applications is premature. We don't know what it is useful for yet. That is what we should find out. >> The other major advantage is that it provides a tool to avoid some of >> the cryptographic lock in problems that are causing certain countries >> to cause issues in ICANN. You don't have to agree with their analysis >> to find value in addressing the concerns. > > I understand their concerns. But the lack of a well-articulated architecture > for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether > this is a good idea. I find that looking at an additional field of application is often a very good way to improve an underspecified architecture. Trans is rather too closely designed to solve one problem and it is not even clear that it does that particularly well. There is a lot of fuzziness in the process by which a relying party decides that a particular value is the true Merkle tree apex of a particular log. From nobody Thu May 22 14:24:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0F51A02DE for ; Thu, 22 May 2014 14:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 Tvj1PWBqDKYG for ; Thu, 22 May 2014 14:24:11 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 724331A0283 for ; Thu, 22 May 2014 14:24:11 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 44D5D2007F005 for ; Thu, 22 May 2014 14:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=V5e1aKLBo4y6GJN3B+KF v0pGq7o=; b=ytkehfbvg8yEEWQK3TMs+CL8mO7mxDX4xSveTnXVeoMCJu1L3wod N3XJNFLarJ5zLUQtNnv23M61qZgbKhKgwWWmFKohKKi/ImZUhHm+0SxSg1GNcSgu gemm3Fo7LrnZIi1vsC+Bxy/09lOuIaLSpFutOgrlE8MeeQ/oXPXKC7g= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id E83B22007F004 for ; Thu, 22 May 2014 14:24:09 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so3904237wgh.28 for ; Thu, 22 May 2014 14:24:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.186.8 with SMTP id fg8mr18488693wic.39.1400793848812; Thu, 22 May 2014 14:24:08 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 22 May 2014 14:24:08 -0700 (PDT) In-Reply-To: <537E467C.7010405@bbn.com> References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> <537E467C.7010405@bbn.com> Date: Thu, 22 May 2014 16:24:08 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/lkq9VpK8Q8b7WPs6vz5PaPn7bKY Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:24:12 -0000 On Thu, May 22, 2014 at 1:48 PM, Stephen Kent wrote: >> > That's a very confusing last phrase. >> >> I had no problem reading it. >> > a literal reading of it is as sarcasm. If that's PHB's intent, fine, but > I just wanted to verify that there was no typo. I saw no sarcasm in it. >> In other words, your concern is about CT in general, not DNSSEC in >> particular. Sounds like a separable issue to me. But if CT makes sense then >> it makes sense for DNSSEC. >> > yes, my complaint about a lack of a doc describing CT architecture is not > specific to the CT for DNSSEC discussion. We agree. > CT may be appropriate for the Web PKI, w/o being a great idea for DNSSEC. I take it you concede that lack of name constraints isn't the only reason to want CT. I'll concede that CT for DNSSEC might not be a good idea. Did I ever say it is? I started the discussion with an inference: CT is for PKIs, DNSSEC is a PKI, therefore CT fits DNSSEC, discuss. > Until we have a doc that describes the architecture, we can't evaluate how > good > it is in either context. We have a doc; it's missing important things. I agree. But I think we can have some of this discussion given what we know now. Indeed, we've been having this discussion, and important things have come up (privacy protection, spam). Nico -- From nobody Fri May 23 03:17:57 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551151A03E5 for ; Fri, 23 May 2014 03:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 3REXn7hkaL83 for ; Fri, 23 May 2014 03:17:54 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBDB1A016E for ; Fri, 23 May 2014 03:17:54 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id eb12so5342590oac.22 for ; Fri, 23 May 2014 03:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sP5dGBFyrii7UvU7Gs3ICgq42z4iLG2bF/Rk4LGb8BQ=; b=V8HbiJnHJkncVBp5kYD3c3zmeCc9joZoRX0Z3YDTgdqi/1GR7fYQaA9QlX5GrZ022c 1lYKq1nzVsxpahz2BGVDzEFF7V+0eR2FaJJEsZjIfFXj0lR+FtQw0UJQpiBjXGBRFEAX sw6wupByT7dFVyi0yAwwBYR5vAgIVdTa1SnlVJV8962r2ff0uzsoGi8qFHgacR//mZ3n 1M868II+LfV9B8x9aJdUIiN3hfLjvtQL2z6fHmt6PZ0a1uG6y+5Z/xOTnLLR9S/q3kSq 6cKKYgAJOlzhrMEhdstWNEY/GNlU+ExBPvgY2orKik4NH7rqxgR04O8PBbycRJmqZeHT wOLA== 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=sP5dGBFyrii7UvU7Gs3ICgq42z4iLG2bF/Rk4LGb8BQ=; b=WPbEBc+qMdJBHWNCQTzSUAnox/NCLDqGvkBzv3R0I3kpz8VaWC46bubP+PD2HVK3I1 UvWHqJZv5x/Tv6n8XLVNf/s/DIqa9QWjkDVs/tLGzU0VEffxKjgOIG6xAwHPtjbr1G5/ Yf+X/JrZ0IyzcMiPI+nvnU18CNJfMYgIWd7tn16X4N0QDRyiZxlmF5KQRj4OkrGKfSf1 TuI1J+Q/j22RwXsgmtIHO8TWSYn4pxcEwskC7QXL4SGDQCOl6N7JQVOTkBN+Q2EZ8R+N c/IAgsMzuEO6WrzxbIJHL0sf/03+L+rVXKmM4rBS3c0HltGAizkWWVu3oppZpElqs2Fk y67w== X-Gm-Message-State: ALoCoQm88xl85PnR4Y1cKvMASFGtHKoHdAMmi0Gm64cAVSDk/FemfZq3nEvCsBIYHy+1tjXevwRN MIME-Version: 1.0 X-Received: by 10.182.200.131 with SMTP id js3mr3866480obc.0.1400840272817; Fri, 23 May 2014 03:17:52 -0700 (PDT) Received: by 10.182.93.141 with HTTP; Fri, 23 May 2014 03:17:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 May 2014 11:17:52 +0100 Message-ID: From: Eran Messeri To: Ben Laurie Content-Type: multipart/alternative; boundary=001a11c23aead9475604fa0e8a89 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-EJ-NyIfLCv0Nx6_7nUYa05J10c Cc: Phillip Hallam-Baker , "trans@ietf.org" Subject: Re: [Trans] Trans content types 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, 23 May 2014 10:17:56 -0000 --001a11c23aead9475604fa0e8a89 Content-Type: text/plain; charset=UTF-8 Note that the repository holding the I-D has moved to: https://github.com/google/certificate-transparency-rfcs On Wed, May 21, 2014 at 11:13 AM, Ben Laurie wrote: > On 21 May 2014 01:22, Phillip Hallam-Baker wrote: > > If we are going to do trans in Internet apps we need to have a > > content-type for trans data. > > When you say "trans data", do you mean the leaves? > > If we want to allow for general content, then there are some other > variables, too - e.g. do you get an SCT (Signed _Content_ Timestamp > :-) or a proof of inclusion (STH + Merkle Proof) on submission? > > Also, you need to specify where content types are included. > > If you want to submit a patch for review against the I-D, you can find it > here: > > > https://github.com/google/certificate-transparency/blob/master/doc/rfc6962-bis.xml > > > 5.1. Content-Type Identifiers > > > > The following content identifiers are defined elsewhere and repeated > > here for the convenience of implementers. > > > > application/ocsp-response > > OCSP Response token as specified in [RFC6090]. > > > > application/pkix-cert > > A single DER encoded PKIX Certificate as specified in > > [RFC5280]. > > > > TBS > > A Certificate Transparency notary chain as specified in > > [RFC6962]. > > > > application/pkcs-12 > > A PKCS#12 encrypted private key. > > > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > > > -- > Certificate Transparency is hiring! Let me know if you're interested. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11c23aead9475604fa0e8a89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note that the repository holding the I-D has moved to:https:= //github.com/google/certificate-transparency-rfcs



On Wed,= May 21, 2014 at 11:13 AM, Ben Laurie <benl@google.com> wrote:=
On 21 May 2014 01:22, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> If we are going to do trans in Internet apps we need to have a
> content-type for trans data.

When you say "trans data", do you mean the leaves?

If we want to allow for general content, then there are some other
variables, too - e.g. do you get an SCT (Signed _Content_ Timestamp
:-) or a proof of inclusion (STH + Merkle Proof) on submission?

Also, you need to specify where content types are included.

If you want to submit a patch for review against the I-D, you can find it h= ere:

https://github.com/google/certificate= -transparency/blob/master/doc/rfc6962-bis.xml

> 5.1. Content-Type Identifiers
>
> =C2=A0 =C2=A0The following content identifiers are defined elsewhere a= nd repeated
> =C2=A0 =C2=A0here for the convenience of implementers.
>
> =C2=A0 =C2=A0 =C2=A0 application/ocsp-response
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OCSP Response token as specified in = [RFC6090].
>
> =C2=A0 =C2=A0 =C2=A0 application/pkix-cert
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A single DER encoded PKIX Certificat= e as specified in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC5280].
>
> =C2=A0 =C2=A0 =C2=A0 TBS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A Certificate Transparency notary ch= ain as specified in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6962].
>
> =C2=A0 =C2=A0 =C2=A0 application/pkcs-12
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A PKCS#12 encrypted private key.
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans



--
Certificate Transparency is hiring! Let me know if you're interested.

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

--001a11c23aead9475604fa0e8a89-- From nobody Fri May 23 06:00:18 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C4B1A046D for ; Fri, 23 May 2014 06:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 ToxL89yss8SR for ; Fri, 23 May 2014 06:00:10 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c: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 28A701A046B for ; Fri, 23 May 2014 06:00:10 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hq11so384364vcb.22 for ; Fri, 23 May 2014 06:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P+VQxHFwT046YbLQXqgafh8DfivCVTIqQHjhfWRFzLY=; b=QW4jgpuMK841PbgIS4DSsjngunOA2PfWuZv+12c+MwD/dgpc2gDiWXIZtUDZiBcQK/ sg80DKClQh2dTQeaN0C4fSd61nyyRnGIm1UN7xmUSMCTlkv6AmSbnVUmtFKOPC1i+n4W 3UjlSC//Yit1+Z1Th6TEbdMSQtGmLmgNdu1j0+7voa36GifW+ZsSWX3xLY2GvSfnUHwQ /MvnXdWpMCNQ564u7NO2nDu/mVnKFbXH4qJrVldy8acl2zSgRwd3fqIosmO0lAXcSDw8 oHodUjpNWvvbSdLdaQZqYmy1Fpsn34uVTcChASseetPw90iHODP0qZJoZGJhwBHbxgHG 5HcA== 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=P+VQxHFwT046YbLQXqgafh8DfivCVTIqQHjhfWRFzLY=; b=aIM0L/NNZhZKjty/9pKBynS1d3Mf/NR6h4hdouBqHBJftSTgGmhiWUv+FkQEnaGoCL +gk8OpXlIA2UomiN0IK7BFg8GKDzUOo3BR8T1pxvofNgb5dEjrwSO2D+bGSToo16JGha q/f33a56QKatFM9GMOhm1zvmmPXRpG+iJ347NtYWftpV+/9Mu0wIZf+z/8cS1Ykqdtwt 3m+3YoTqMzDrx9LgOJZIBHgjmNU0lZvg1MtcXz2szCji6WG3zRHMfpsrnxoC+X/Hfmyy n2rFfeU2KlYLSZogznFdpNvHF2rCHkLMrh5iIbBuJFN+k0f3XE+QIm1p/LkOmnz1RbQD NSqg== X-Gm-Message-State: ALoCoQnCUXkWKDSeV/E3vMvBedwBJ5YOEmrb1yz95pmlMVkWoRu875fdGM8CBlSIOqDl3St+vZ6X MIME-Version: 1.0 X-Received: by 10.52.164.237 with SMTP id yt13mr3382668vdb.18.1400850007829; Fri, 23 May 2014 06:00:07 -0700 (PDT) Received: by 10.52.107.132 with HTTP; Fri, 23 May 2014 06:00:07 -0700 (PDT) In-Reply-To: <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com> References: <537E3229.4070402@bbn.com> <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com> Date: Fri, 23 May 2014 14:00:07 +0100 Message-ID: From: Ben Laurie To: "Osterweil, Eric" Content-Type: multipart/alternative; boundary=001a11c2c1d219cc4704fa10cfd5 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/0Ckwa6rrZnNez5cbvU-jQxMce1w Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:00:14 -0000 --001a11c2c1d219cc4704fa10cfd5 Content-Type: text/plain; charset=UTF-8 On 22 May 2014 18:32, Osterweil, Eric wrote: > > On May 22, 2014, at 1:21 PM, Stephen Kent > wrote: > > > Nico, > >> DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. > > agreed. > >> It stands to reason that DNSSEC should have similar trust problems as > >> PKIX. I believe it does indeed. > > PKIX, per se, does not have the trust problems that seem to motivate > > CT; the Web PKI does. That PKI has always had a serious problem because > > any TA can issue a cert for any Subject, irrespective of the Subject > name. > > because DNSSEC intrinsically incorporate the equivalent of PKIX Name > > Constraints, it does not suffer from that specific problem. That's not to > > say that mis-issuance is not possible in DNSSEC, but rather that its > > effects are more limited. > >> It follows that things like CT that we're applying to PKIX should be > >> applied to DNSSEC as well, where possible. > > maybe. > >> I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it > >> should be done. > > I'll defer to DNS experts on that. > > Without implying an presumption of expertise on DNS, I would argue that > DNSSEC avoids the problems CT seems to be trying to solve by coupling its > key learning (and verification) methods to the hierarchical namespace. As > Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT > seem to be focused more on the latter. I don't think there is a key > learning/verification dilemma in DNSSEC that CT is appropriate for. > I disagree: the purpose of CT is to ensure that those who can mess with the signing chain are monitored for correct behaviour. How people get into the signing chain does not alter the need to monitor their correct behaviour. > > Eric > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > -- Certificate Transparency is hiring! Let me know if you're interested. --001a11c2c1d219cc4704fa10cfd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 22 May 2014 18:32, Osterweil, Eric <eosterweil@verisign.c= om> wrote:

On May 22, 2014, at 1:21 PM, Stephen Kent <kent@bbn.com>
=C2=A0wrote:

> Nico,
>> DNSSEC is a PKI [of sorts; please, no need to pick nits about that= ].
> agreed.
>> It stands to reason that DNSSEC should have similar trust problems= as
>> PKIX. =C2=A0I believe it does indeed.
> PKIX, per se, does not have the trust problems that seem to motivate > CT; the Web PKI does. That PKI has always had a serious problem becaus= e
> any TA can issue a cert for any Subject, irrespective of the Subject n= ame.
> because DNSSEC intrinsically incorporate the equivalent of PKIX Name > Constraints, it does not suffer from that specific problem. That's= not to
> say that mis-issuance is not possible in DNSSEC, but rather that its > effects are more limited.
>> It follows that things like CT that we're applying to PKIX sho= uld be
>> applied to DNSSEC as well, where possible.
> maybe.
>> I don't see any reason why CT couldn't be extended to DNSS= EC. =C2=A0IMO, it
>> should be done.
> I'll defer to DNS experts on that.

Without implying an presumption of expertise on DNS, I would argue th= at DNSSEC avoids the problems CT seems to be trying to solve by coupling it= s key learning (and verification) methods to the hierarchical namespace. = =C2=A0As Steve said (I believe) PKIX !=3D Web PKI, and the problems address= ed by CT seem to be focused more on the latter. =C2=A0I don't think the= re is a key learning/verification dilemma in DNSSEC that CT is appropriate = for.

I disagree: the purpose of CT is to ensure= that those who can mess with the signing chain are monitored for correct b= ehaviour. How people get into the signing chain does not alter the need to = monitor their correct behaviour.

=C2=A0

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




--
Certific= ate Transparency is hiring! Let me know if you're interested.
--001a11c2c1d219cc4704fa10cfd5-- From nobody Fri May 23 06:01:45 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1BA1A01C4 for ; Fri, 23 May 2014 06:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 Wt-KS70dm1z8 for ; Fri, 23 May 2014 06:01:41 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0201A01C0 for ; Fri, 23 May 2014 06:01:40 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hq11so422589vcb.5 for ; Fri, 23 May 2014 06:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jF2JgHYLrHke0DwKI2F5daOUccGm8B0+Gff9u0EvwZI=; b=YcuRs5XveBui0fa0Ppwaf1ZazwHxzHjFcpCz35xAGfu713VOtmwuts7ZbN3x5cKwDU OSZ754pBhUPcdOFU+PvnmKjpOSF16OCreOXkqX3X26Teh7fots4ftICPFBpS0kCxGLCr hQAAgZa2KG+H3umjhV5UV4huZhkx5tNwH5T7qC0+6CVGDWMkKysBgZ8jtPzlMiUy1uGy U97KOIZ7/J4ne1G/QWPfzeIY/JnlziQuDsjsaY9zRSKikk6eaQPk50e0ijhRWsr4+EQm 1nnEMOa2e7xaoaGUDMghIGFlz+QLt2sXTIJKklDvvMdqE4nx18pmVofnrYP+kli8GFRn W40A== 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=jF2JgHYLrHke0DwKI2F5daOUccGm8B0+Gff9u0EvwZI=; b=V9UrIDFwEHZxEPFuDjfGJa4X3ElLfNPUD5lJVByS+VmMghzQRVel/G+jxP+JBJIwye EmfKbd9uENL9eANz4ChSI3KgeLnclUiOPBbArAK/ndqOp6l93F5Ap0De8Hbi+gnFefKu HogLanaF1k06RnX2kh+lV5BM6nABpCgr+Vs5Uk0HjZ/xoe6r+DsRnB5wXk3RkZYm1OgY rZXoKQTNNsT8R3A8OuEeC4fd/N/T56IcULPEj+r15po2zOM+W9IIxnCJ2d4VrIXDIqho xXC2tGzcDmiUA15zdnXT88+eyfN+rrNVUTJyjmleS1umex0H7mMXoappaCRUgStvIAOg QccA== X-Gm-Message-State: ALoCoQnFSZvyHHKZ2/89No+E38FFybjsKrDW/Pa3tjnAs8bej66hKppazRF5v/a4jB03yx/KlmrM MIME-Version: 1.0 X-Received: by 10.58.126.135 with SMTP id my7mr4036301veb.27.1400850098756; Fri, 23 May 2014 06:01:38 -0700 (PDT) Received: by 10.52.107.132 with HTTP; Fri, 23 May 2014 06:01:38 -0700 (PDT) In-Reply-To: References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> Date: Fri, 23 May 2014 14:01:38 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7b675e5285387e04fa10d417 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/n7VPP-Zuh0nOdAgNFe_pGBVj9XI Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:01:42 -0000 --047d7b675e5285387e04fa10d417 Content-Type: text/plain; charset=UTF-8 On 22 May 2014 21:45, Phillip Hallam-Baker wrote: > Trans is rather too closely designed to solve one problem and it is > not even clear that it does that particularly well. There is a lot of > fuzziness in the process by which a relying party decides that a > particular value is the true Merkle tree apex of a particular log. > FWIW, I plan to explain more clearly our plans in this area shortly (which are actually quite solid, but not yet documented usefully). -- Certificate Transparency is hiring! Let me know if you're interested. --047d7b675e5285387e04fa10d417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 22 May 2014 21:45, Phillip Hallam-Baker <ietf@hallambaker.co= m> wrote:
Trans is rather too closely = designed to solve one problem and it is
not even clear that it does that particularly well. There is a lot of
fuzziness in the process by which a relying party decides that a
particular value is the true Merkle tree apex of a particular log.

FWIW, I plan to explain more clearly our plans = in this area shortly (which are actually quite solid, but not yet documente= d usefully).

--=C2=A0
Certificate Transparency is hir= ing! Let me know if you're interested.
--047d7b675e5285387e04fa10d417-- From nobody Fri May 23 06:12:33 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF4F1A01CD for ; Fri, 23 May 2014 06:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4wRoMJ6sdEP for ; Fri, 23 May 2014 06:12:20 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBA11A01C0 for ; Fri, 23 May 2014 06:12:20 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so4717413wgh.15 for ; Fri, 23 May 2014 06:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KPqdZ9qjfIYqC81s98X+YSwJ98cWs+3smmJMDnYaNho=; b=P6durWyGtWl7NstBC4iZ3sgo9KIvliPlkjPhPasw0qPF5w2CzoTRredIXH0Rrr9LbS FUoDiyeQ4fDa7LIf+Ww6RRQEBLlBjEOPZywsBAw5NI9Vt2tYu8uolb1mvT1Hkve/2B3P kXmtEYri5s+DshKderzzL1nXL8Svb+RWSoLRl2n9WrdOYiZGpa08t4O7lInnsSMyej0y tK7miUSAzgPampGY6tdp206z2oZscYeLJSr8kbNYkwUHBIMRpW5siff52lD25OY6AEaS rvHhszfMo2ef+/CGPhl3VQwvn+F3F0qH0l5MZXjbqDBtkR0sH97NUvTsaDNAt4F+9tQM w4QA== MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr2100861wjr.76.1400850737483; Fri, 23 May 2014 06:12:17 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 23 May 2014 06:12:17 -0700 (PDT) In-Reply-To: References: <537E3229.4070402@bbn.com> <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com> Date: Fri, 23 May 2014 09:12:17 -0400 X-Google-Sender-Auth: wJ_fL1_dIuf5jk3P5DiJdVfQMqA Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/LNfZQBBgGNJCm4iXnmFHbRLxkSU Cc: "trans@ietf.org" , "Osterweil, Eric" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:12:30 -0000 But Ben, DNSSEC is predicated on the article of faith that DNS Registrars will never ever make mistakes, get hacked or be run by the Russian or Ukrainian mafia. The fact that we have more examples of all of those than CAs being breached is not going to affect an ideological commitment. On Fri, May 23, 2014 at 9:00 AM, Ben Laurie wrote: > > > > On 22 May 2014 18:32, Osterweil, Eric wrote: >> >> >> On May 22, 2014, at 1:21 PM, Stephen Kent >> wrote: >> >> > Nico, >> >> DNSSEC is a PKI [of sorts; please, no need to pick nits about that]. >> > agreed. >> >> It stands to reason that DNSSEC should have similar trust problems as >> >> PKIX. I believe it does indeed. >> > PKIX, per se, does not have the trust problems that seem to motivate >> > CT; the Web PKI does. That PKI has always had a serious problem because >> > any TA can issue a cert for any Subject, irrespective of the Subject >> > name. >> > because DNSSEC intrinsically incorporate the equivalent of PKIX Name >> > Constraints, it does not suffer from that specific problem. That's not >> > to >> > say that mis-issuance is not possible in DNSSEC, but rather that its >> > effects are more limited. >> >> It follows that things like CT that we're applying to PKIX should be >> >> applied to DNSSEC as well, where possible. >> > maybe. >> >> I don't see any reason why CT couldn't be extended to DNSSEC. IMO, it >> >> should be done. >> > I'll defer to DNS experts on that. >> >> Without implying an presumption of expertise on DNS, I would argue that >> DNSSEC avoids the problems CT seems to be trying to solve by coupling its >> key learning (and verification) methods to the hierarchical namespace. As >> Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT >> seem to be focused more on the latter. I don't think there is a key >> learning/verification dilemma in DNSSEC that CT is appropriate for. > > > I disagree: the purpose of CT is to ensure that those who can mess with the > signing chain are monitored for correct behaviour. How people get into the > signing chain does not alter the need to monitor their correct behaviour. > > >> >> >> Eric >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > > > -- > Certificate Transparency is hiring! Let me know if you're interested. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Tue May 27 07:32:55 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA561A0366 for ; Tue, 27 May 2014 07:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c6KPlxYTaaz for ; Tue, 27 May 2014 07:32:51 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262031A034E for ; Tue, 27 May 2014 07:32:51 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id z6so7483535yhz.11 for ; Tue, 27 May 2014 07:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CIWXjjy1wyn/o1PgF4CsQMBHwx1ujmbyvU7Xink6qpk=; b=OXr7Hvkg8IdI41JqEDXpe1/t0A6d8XsrNeArlnDVQ/7IC7qCNTYeCNJZecgap+c6i6 n0bbeYxXeDuSPDCLoGbCMZjR6X33+C8E2cgbq3+PTDQ3bbXoib7yvfhs8IBFTCWq0qZg rd/WpCRO5YNmx2iVAYx0osxGhdru4u1DEUk3VTO8lN4Qhzcvu4ncdwHvUorBdAychBjv w6QBRLeWB+UDO9BJwiX1QNDWEhO2SC2Rt6GyvcNiBwTWiwsdv58Nz6/FHUtSHBOXXERQ o+f73wItRVo0XXKEdjtw8UCNQGE/hB66/ZWTvQWy2GGWnmRyykKUL8/eswoj4WIOvJDi i39Q== MIME-Version: 1.0 X-Received: by 10.236.93.195 with SMTP id l43mr47294920yhf.40.1401201167535; Tue, 27 May 2014 07:32:47 -0700 (PDT) Received: by 10.170.91.85 with HTTP; Tue, 27 May 2014 07:32:47 -0700 (PDT) In-Reply-To: <537E3E13.30709@bbn.com> References: <5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> Date: Tue, 27 May 2014 18:32:47 +0400 Message-ID: From: Dmitry Belyavsky To: Stephen Kent Content-Type: multipart/alternative; boundary=20cf3010e34dd9968e04fa629102 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/1jtHK9kdMjJKps_awJ6tz2tEERs Cc: "trans@ietf.org" Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:32:53 -0000 --20cf3010e34dd9968e04fa629102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Stephen, Here is my understanding of the question you asked. Let Ben or Rob fix me if I'm wrong. 1. Anybody is allowed to operate log. But there should be a procedure (similar to CA/Browser forum) which is determined to register log as =E2=80=9Cimportant=E2=80=9D (we need a better word). There should be not= many =E2=80=9Cimportant=E2=80=9D log servers, I suppose =E2=80=94 otherwise we are to get the same proble= m as we have with many CAs. 2. Any log-server can select the list of acceptable CAs. I think that =E2=80=9Cimportant logs=E2=80=9D should cover all the CAs supported by m= ajor browsers. 3. Any log server can select the algorithm of hash for Merkle Tree and for its key signing the SCTs. 4. Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of =E2=80=9Cimportant=E2=80=9D logs. 5. Each CA can be accepted by more than one log. 6. Browsers should 1. allow user to accept the cert without CT providing warning about absence of CT 2. allow user to specify absence of log for this or that domain (non-public suffix) 3. allow user to a particular log for this or that domain and return an error if there is no SCT for id provided by this log. 4. there should be a procedure of report about log misbehaviour in case of invalid log records 7. I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated. On Thu, May 22, 2014 at 10:12 PM, Stephen Kent wrote: > Dimitry, > > Thanks for posting the list below. > > I have become very concerned that the doc we're working on describes a > mechanism, > but we seem to lack a good description of the architectural context in > which CT > is supposed to work. The intro text for the I-D is not at all adequate fo= r > this. > Maybe the charter for this WG would have included the need to publish a > doc of > this sort if we had gone through the usual BoF process :-). > > I'd like to see a doc that addresses a number of points that are now > beginning to > be raised by several folks: > - who is expected to operate logs, does every log cover all CAs, is o= ne > log per CA (even if operated by someone else) adequate, how are users > supposed to > select logs (what the UI like?), etc. > - how are browsers expected to deal with missing SCTs, missing or > non-matching > log entries, (crypto) invalid log entries, etc. are browser actions > supposed to be > effect in real time or is this deferred activity model? > - hard fail vs. warnings for CT "exceptions?" > - how are browsers expected to deal with certs from CAs that are not > part of the Web PKI? > - what are the fallback plans if some number of the Web PKI CAs elect > to not > participate? > - same question for major browser vendors? > - what are the plans for alg aglity, for logs? > > CT is a system, not just a handful of mechanisms. It needs to be describe= d > that way. > > Although not perfect, I suggest the set of RFCs that describe the RPKI is > illustrative > of the many aspects of a global system (with PKI aspects) that need to be > documented. > > Steve > > >> > Here are my ideas about "strict" behaviour of the TLS client: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > TLS clients supporting CT are supposed to have a preconfigured set of > logs and > their public keys. > > In addition to normal validation of the certificate and its chain, they > should > validate the SCTs received during the TLS connection. > > The client fully conforming to the specification SHOULD perform the > following > steps before establishing the connection for every certificate in the > chain: > > 1. If no SCTs are provided, the client SHOULD reject the connection. > > 2. The client MUST ignore all the SCTs provided by unknown logs. > > 3. TLS clients MUST reject SCTs whose timestamp is in the future. > > 4. If no SCTs has left after steps 2-3, the client SHOULD reject the > connection. > > 5. If any of SCTs left after steps 2-3 has invalid signature, the client > SHOULD reject the connection. > > Client MAY check whether the certificate is present in the log > corresponding to the passed SCT. > If the certificate is not present in the log, the connection MUST be > rejected. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Can it be a starting point or you want something else? > > -- > SY, Dmitry Belyavsky > > > _______________________________________________ > Trans mailing listTrans@ietf.orghttps://www.ietf.org/mailman/listinfo/tra= ns > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --=20 SY, Dmitry Belyavsky --20cf3010e34dd9968e04fa629102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Stephen,

Here is my understan= ding of the question you asked.
Let Ben or Rob fix me if I'm w= rong.

  1. = Anybody is allowed to operat= e log. But there should be a procedure (similar to CA/Browser forum) which = is determined to register log as =E2=80=9Cimportant=E2=80=9D (we need a bet= ter word). There should be not many =E2=80=9Cimportant=E2=80=9D log servers= , I suppose =E2=80=94 otherwise we are to get the same problem as we have w= ith many CAs.

  2. = Any log-server can select th= e list of acceptable CAs. I think that =E2=80=9Cimportant logs=E2=80=9D sho= uld cover all the CAs supported by major browsers.

  3. = Any log server can select th= e algorithm of hash for Merkle Tree and for its key signing the SCTs.

  4. = Each browser should provide = an editable way of managing logs. By default it should be a reasonable subs= et of =E2=80=9Cimportant=E2=80=9D logs.

  5. = Each CA can be accepted by m= ore than one log.

  6. = Browsers should

    1. = allow user to accept the cer= t without CT providing warning about absence of CT

    2. = allow user to specify absenc= e of log for this or that domain (non-public suffix)

    3. = allow user to a particular l= og for this or that domain and return an error if there is no SCT for id pr= ovided by this log.

    4. = there should be a procedure = of report about log misbehaviour in case of invalid log records

  7. = I think that warning is acce= ptable in case of an absence of SCTs, but in case of cryptographic errors t= he error should be generated.





On Thu, May 22, 2014 at 10:12 PM, Stephen Kent <kent@bbn.com>= wrote:
=20 =20 =20
Dimitry,

Thanks for posting the list below.

I have become very concerned that the doc we're working on describe= s a mechanism,
but we seem to lack a good description of the architectural context in which CT
is supposed to work. The intro text for the I-D is not at all adequate for this.
Maybe the charter for this WG would have included the need to publish a doc of
this sort if we had gone through the usual BoF process :-).

I'd like to see a doc that addresses a number of points that are no= w beginning to
be raised by several folks:
=C2=A0=C2=A0=C2=A0 - who is expected to operate logs, does every log co= ver all CAs, is one
log per CA (even if operated by someone else) adequate, how are users supposed to
select logs (what the UI like?), etc.
=C2=A0=C2=A0=C2=A0 - how are browsers expected to deal with missing SCT= s, missing or non-matching
log entries, (crypto) invalid log entries, etc. are browser actions supposed to be
effect in real time or is this deferred activity model?
=C2=A0=C2=A0=C2=A0 - hard fail vs. warnings for CT "exceptions?&qu= ot;
=C2=A0=C2=A0=C2=A0 - how are browsers expected to deal with certs from = CAs that are not
part of the Web PKI?
=C2=A0=C2=A0=C2=A0 - what are the fallback plans if some number of the = Web PKI CAs elect to not
participate?
=C2=A0=C2=A0=C2=A0 - same question for major browser vendors?
=C2=A0=C2=A0=C2=A0 - what are the plans for alg aglity, for logs?

CT is a system, not just a handful of mechanisms. It needs to be described that way.

Although not perfect, I suggest the set of RFCs that describe the RPKI is illustrative
of the many aspects of a global system (with PKI aspects) that need to be documented.

Steve


Here are my ideas about "strict" behaviour of th= e TLS client:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
TLS clients supporting CT are supposed to have a preconfigured set of logs and
their public keys.

In addition to normal validation of the certificate and its chain, they should
validate the SCTs received during the TLS connection.

The client fully conforming to the specification SHOULD perform the following
steps before establishing the connection for every certificate in the chain:

1. If no SCTs are provided, the client SHOULD reject the connection.

2. The client MUST ignore all the SCTs provided by unknown logs.

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

4. If no SCTs has left after steps 2-3, the client SHOULD reject the connection.

5. If any of SCTs left after steps 2-3 has invalid signature, the client SHOULD reject the connection.

Client MAY check whether the certificate is present in the log corresponding to the passed SCT.
If the certificate is not present in the log, the connection MUST be rejected.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=C2=A0

Can it be a starting point or you want something else?

--
SY, Dmitry Belyavsky 


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


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




--
SY, Dmitry Belyavsk= y
--20cf3010e34dd9968e04fa629102-- From nobody Tue May 27 07:48:44 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADE71A0470 for ; Tue, 27 May 2014 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 xkKb_DROV3Ae for ; Tue, 27 May 2014 07:48:25 -0700 (PDT) Received: from ektmail1iron2.euskaltel.es (ektmail1iron2.euskaltel.es [212.142.144.27]) by ietfa.amsl.com (Postfix) with ESMTP id 701B71A0445 for ; Tue, 27 May 2014 07:47:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EAHykhFPUNwgN/2dsb2JhbABZgkKBF4NCqmCNFgGHOQEZgQt0giYBAQQBAQECHgIIAQINDQgcCxACAQgdAQEBAgYQAQYBAgICAQEFEAEOAR8RAQEFEQEGAgaIOAEIsC+Fa58XEwSJM4IQAYJdLQQGAYJ1NoEVAQOEXgKMbIE7hmyTJ4M6gW0k X-IPAS-Result: Ar0EAHykhFPUNwgN/2dsb2JhbABZgkKBF4NCqmCNFgGHOQEZgQt0giYBAQQBAQECHgIIAQINDQgcCxACAQgdAQEBAgYQAQYBAgICAQEFEAEOAR8RAQEFEQEGAgaIOAEIsC+Fa58XEwSJM4IQAYJdLQQGAYJ1NoEVAQOEXgKMbIE7hmyTJ4M6gW0k X-IronPort-AV: E=Sophos;i="4.98,919,1392159600"; d="png'150?scan'150,208,217,150";a="168148295" Received: from ektmail1mta2.euskaltel.es (HELO correo.euskaltel.es) ([212.55.8.13]) by ektmail1iron2.euskaltel.es with ESMTP; 27 May 2014 16:32:20 +0200 Received: from ejlp023.ejgv ([212.55.29.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0N6800FCFMF1PK60@ektmail1mta2.euskaltel.es> for trans@ietf.org; Tue, 27 May 2014 16:47:25 +0200 (CEST) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id s4RElPrP017194; Tue, 27 May 2014 16:47:25 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 May 2014 16:47:24 +0200 Date: Tue, 27 May 2014 16:47:23 +0200 From: i-barreira@izenpe.net In-reply-to: To: beldmit@gmail.com, kent@bbn.com Message-id: <763539E260C37C46A0D6B340B5434C3B09854BEA@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/related; boundary="Boundary_(ID_d+wXSMpV/FUOoHz1dApj9Q)"; type="multipart/alternative" Content-class: urn:content-classes:message Thread-topic: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) Thread-index: Ac95uI3cnUZq5SgcQhCKVW8JH8bKcAAAZOvg X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> X-OriginalArrivalTime: 27 May 2014 14:47:24.0713 (UTC) FILETIME=[9294B190:01CF79BA] Archived-At: http://mailarchive.ietf.org/arch/msg/trans/M5n_TYotFsFa0wn7sjPPQy-T_eI Cc: trans@ietf.org Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:48:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_d+wXSMpV/FUOoHz1dApj9Q) Content-type: multipart/alternative; boundary="Boundary_(ID_0vPvzw7W3ZvUqzXYT91KXA)" --Boundary_(ID_0vPvzw7W3ZvUqzXYT91KXA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGksDQoNCiANCg0KSSBoYXZlIHNvbWUgb3RoZXIgcXVlc3Rpb25zDQoNCi0gICAgICAgICAgV2hh dCBpZiBhIENBIGNhbsK0dCBiZWxvbmcgb3IgaXTCtHMgbm90IGFjY2VwdGVkIGluIGFueSBsb2cg c2VydmVyPyANCg0KLSAgICAgICAgICBXaGF0IGlmIHlvdSBuZWVkIDMgbG9ncyBmb3IgYW4gRVYg YW5kIG9ubHkgZ2V0IDIgZm9yIHdoYXRldmVyIHJlYXNvbnM/DQoNCi0gICAgICAgICAgV2hvwrRz IG1hbmFnaW5nIHRoYXQgcHJvY2VkdXJlIHRvIGFjY2VwdCBsb2cgc2VydmVycz8gR29vZ2xlPyBB cmUgdGhleSBnb2luZyB0byBiZSByZWdpc3RlcmVkL3B1YmxpY2x5IGF2YWlsYWJsZSBmb3IgQ0Fz IHRvIGNob29zZT8NCg0KIA0KDQpSZWdhcmRzDQoNCiANCg0KIA0KDQpJw7FpZ28gQmFycmVpcmEN ClJlc3BvbnNhYmxlIGRlbCDDgXJlYSB0w6ljbmljYQ0KaS1iYXJyZWlyYUBpemVucGUubmV0DQoN Cjk0NTA2NzcwNQ0KDQogDQoNCiANCg0KRVJORSEgQmFsaXRla2UgbWV6dSBob25lbiB6YXRpcmVu IGJhdCBlZG8gbWV6dSBvc29hIGxlZ2V6IGJhYmVzdHV0YSBlZ290ZWEuIE1lenVhIGJhZHUgYmVy ZSBoYXJ0emFpbGVhLiBPa2VycmVrbyBoZWxiaWRlcmEgaGVsZHUgYmFkYSAoaGVsYmlkZWEgZ2Fp emtpIGlkYXR6aSwgdHJhbnNtaXNpb2FrIGh1dHMgZWdpbikgZW1hbiBhYmlzdSBpZ29ybGVhcmks IGtvcnJlbyBob25pIGVyYW50enVuYS4gS09OVFVaIQ0KQVRFTkNJT04hIEVzdGUgbWVuc2FqZSBj b250aWVuZSBpbmZvcm1hY2lvbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgYSBsYSBxdWUg c29sbyB0aWVuZSBkZXJlY2hvIGEgYWNjZWRlciBlbCBkZXN0aW5hdGFyaW8uIFNpIHVzdGVkIGxv IHJlY2liZSBwb3IgZXJyb3IgbGUgYWdyYWRlY2VyaWFtb3MgcXVlIG5vIGhpY2llcmEgdXNvIGRl IGxhIGluZm9ybWFjaW9uIHkgcXVlIHNlIHB1c2llc2UgZW4gY29udGFjdG8gY29uIGVsIHJlbWl0 ZW50ZS4NCg0KIA0KDQpEZTogVHJhbnMgW21haWx0bzp0cmFucy1ib3VuY2VzQGlldGYub3JnXSBF biBub21icmUgZGUgRG1pdHJ5IEJlbHlhdnNreQ0KRW52aWFkbyBlbDogbWFydGVzLCAyNyBkZSBt YXlvIGRlIDIwMTQgMTY6MzMNClBhcmE6IFN0ZXBoZW4gS2VudA0KQ0M6IHRyYW5zQGlldGYub3Jn DQpBc3VudG86IFJlOiBbVHJhbnNdIFZvbHVudGVlciBvcHBvcnR1bml0eSEgKHdhcyBSZTogRE5T U0VDIGFsc28gbmVlZHMgQ1QpDQoNCiANCg0KSGVsbG8gU3RlcGhlbiwNCg0KSGVyZSBpcyBteSB1 bmRlcnN0YW5kaW5nIG9mIHRoZSBxdWVzdGlvbiB5b3UgYXNrZWQuDQoNCkxldCBCZW4gb3IgUm9i IGZpeCBtZSBpZiBJJ20gd3JvbmcuDQoNCg0KDQoNCjEuICAgIEFueWJvZHkgaXMgYWxsb3dlZCB0 byBvcGVyYXRlIGxvZy4gQnV0IHRoZXJlIHNob3VsZCBiZSBhIHByb2NlZHVyZSAoc2ltaWxhciB0 byBDQS9Ccm93c2VyIGZvcnVtKSB3aGljaCBpcyBkZXRlcm1pbmVkIHRvIHJlZ2lzdGVyIGxvZyBh cyDigJxpbXBvcnRhbnTigJ0gKHdlIG5lZWQgYSBiZXR0ZXIgd29yZCkuIFRoZXJlIHNob3VsZCBi ZSBub3QgbWFueSDigJxpbXBvcnRhbnTigJ0gbG9nIHNlcnZlcnMsIEkgc3VwcG9zZSDigJQgb3Ro ZXJ3aXNlIHdlIGFyZSB0byBnZXQgdGhlIHNhbWUgcHJvYmxlbSBhcyB3ZSBoYXZlIHdpdGggbWFu eSBDQXMuDQoNCjIuICAgIEFueSBsb2ctc2VydmVyIGNhbiBzZWxlY3QgdGhlIGxpc3Qgb2YgYWNj ZXB0YWJsZSBDQXMuIEkgdGhpbmsgdGhhdCDigJxpbXBvcnRhbnQgbG9nc+KAnSBzaG91bGQgY292 ZXIgYWxsIHRoZSBDQXMgc3VwcG9ydGVkIGJ5IG1ham9yIGJyb3dzZXJzLg0KDQozLiAgICBBbnkg bG9nIHNlcnZlciBjYW4gc2VsZWN0IHRoZSBhbGdvcml0aG0gb2YgaGFzaCBmb3IgTWVya2xlIFRy ZWUgYW5kIGZvciBpdHMga2V5IHNpZ25pbmcgdGhlIFNDVHMuDQoNCjQuICAgIEVhY2ggYnJvd3Nl ciBzaG91bGQgcHJvdmlkZSBhbiBlZGl0YWJsZSB3YXkgb2YgbWFuYWdpbmcgbG9ncy4gQnkgZGVm YXVsdCBpdCBzaG91bGQgYmUgYSByZWFzb25hYmxlIHN1YnNldCBvZiDigJxpbXBvcnRhbnTigJ0g bG9ncy4NCg0KNS4gICAgRWFjaCBDQSBjYW4gYmUgYWNjZXB0ZWQgYnkgbW9yZSB0aGFuIG9uZSBs b2cuIA0KDQo2LiAgICBCcm93c2VycyBzaG91bGQNCg0KYS4gICAgYWxsb3cgdXNlciB0byBhY2Nl cHQgdGhlIGNlcnQgd2l0aG91dCBDVCBwcm92aWRpbmcgd2FybmluZyBhYm91dCBhYnNlbmNlIG9m IENUDQoNCmIuICAgIGFsbG93IHVzZXIgdG8gc3BlY2lmeSBhYnNlbmNlIG9mIGxvZyBmb3IgdGhp cyBvciB0aGF0IGRvbWFpbiAobm9uLXB1YmxpYyBzdWZmaXgpDQoNCmMuICAgIGFsbG93IHVzZXIg dG8gYSBwYXJ0aWN1bGFyIGxvZyBmb3IgdGhpcyBvciB0aGF0IGRvbWFpbiBhbmQgcmV0dXJuIGFu IGVycm9yIGlmIHRoZXJlIGlzIG5vIFNDVCBmb3IgaWQgcHJvdmlkZWQgYnkgdGhpcyBsb2cuDQoN CmQuICAgIHRoZXJlIHNob3VsZCBiZSBhIHByb2NlZHVyZSBvZiByZXBvcnQgYWJvdXQgbG9nIG1p c2JlaGF2aW91ciBpbiBjYXNlIG9mIGludmFsaWQgbG9nIHJlY29yZHMNCg0KNy4gICAgSSB0aGlu ayB0aGF0IHdhcm5pbmcgaXMgYWNjZXB0YWJsZSBpbiBjYXNlIG9mIGFuIGFic2VuY2Ugb2YgU0NU cywgYnV0IGluIGNhc2Ugb2YgY3J5cHRvZ3JhcGhpYyBlcnJvcnMgdGhlIGVycm9yIHNob3VsZCBi ZSBnZW5lcmF0ZWQuDQoNCiANCg0KIA0KDQpPbiBUaHUsIE1heSAyMiwgMjAxNCBhdCAxMDoxMiBQ TSwgU3RlcGhlbiBLZW50IDxrZW50QGJibi5jb20+IHdyb3RlOg0KDQpEaW1pdHJ5LA0KDQpUaGFu a3MgZm9yIHBvc3RpbmcgdGhlIGxpc3QgYmVsb3cuDQoNCkkgaGF2ZSBiZWNvbWUgdmVyeSBjb25j ZXJuZWQgdGhhdCB0aGUgZG9jIHdlJ3JlIHdvcmtpbmcgb24gZGVzY3JpYmVzIGEgbWVjaGFuaXNt LA0KYnV0IHdlIHNlZW0gdG8gbGFjayBhIGdvb2QgZGVzY3JpcHRpb24gb2YgdGhlIGFyY2hpdGVj dHVyYWwgY29udGV4dCBpbiB3aGljaCBDVA0KaXMgc3VwcG9zZWQgdG8gd29yay4gVGhlIGludHJv IHRleHQgZm9yIHRoZSBJLUQgaXMgbm90IGF0IGFsbCBhZGVxdWF0ZSBmb3IgdGhpcy4NCk1heWJl IHRoZSBjaGFydGVyIGZvciB0aGlzIFdHIHdvdWxkIGhhdmUgaW5jbHVkZWQgdGhlIG5lZWQgdG8g cHVibGlzaCBhIGRvYyBvZg0KdGhpcyBzb3J0IGlmIHdlIGhhZCBnb25lIHRocm91Z2ggdGhlIHVz dWFsIEJvRiBwcm9jZXNzIDotKS4NCg0KSSdkIGxpa2UgdG8gc2VlIGEgZG9jIHRoYXQgYWRkcmVz c2VzIGEgbnVtYmVyIG9mIHBvaW50cyB0aGF0IGFyZSBub3cgYmVnaW5uaW5nIHRvDQpiZSByYWlz ZWQgYnkgc2V2ZXJhbCBmb2xrczoNCiAgICAtIHdobyBpcyBleHBlY3RlZCB0byBvcGVyYXRlIGxv Z3MsIGRvZXMgZXZlcnkgbG9nIGNvdmVyIGFsbCBDQXMsIGlzIG9uZQ0KbG9nIHBlciBDQSAoZXZl biBpZiBvcGVyYXRlZCBieSBzb21lb25lIGVsc2UpIGFkZXF1YXRlLCBob3cgYXJlIHVzZXJzIHN1 cHBvc2VkIHRvDQpzZWxlY3QgbG9ncyAod2hhdCB0aGUgVUkgbGlrZT8pLCBldGMuDQogICAgLSBo b3cgYXJlIGJyb3dzZXJzIGV4cGVjdGVkIHRvIGRlYWwgd2l0aCBtaXNzaW5nIFNDVHMsIG1pc3Np bmcgb3Igbm9uLW1hdGNoaW5nDQpsb2cgZW50cmllcywgKGNyeXB0bykgaW52YWxpZCBsb2cgZW50 cmllcywgZXRjLiBhcmUgYnJvd3NlciBhY3Rpb25zIHN1cHBvc2VkIHRvIGJlDQplZmZlY3QgaW4g cmVhbCB0aW1lIG9yIGlzIHRoaXMgZGVmZXJyZWQgYWN0aXZpdHkgbW9kZWw/DQogICAgLSBoYXJk IGZhaWwgdnMuIHdhcm5pbmdzIGZvciBDVCAiZXhjZXB0aW9ucz8iDQogICAgLSBob3cgYXJlIGJy b3dzZXJzIGV4cGVjdGVkIHRvIGRlYWwgd2l0aCBjZXJ0cyBmcm9tIENBcyB0aGF0IGFyZSBub3QN CnBhcnQgb2YgdGhlIFdlYiBQS0k/DQogICAgLSB3aGF0IGFyZSB0aGUgZmFsbGJhY2sgcGxhbnMg aWYgc29tZSBudW1iZXIgb2YgdGhlIFdlYiBQS0kgQ0FzIGVsZWN0IHRvIG5vdA0KcGFydGljaXBh dGU/DQogICAgLSBzYW1lIHF1ZXN0aW9uIGZvciBtYWpvciBicm93c2VyIHZlbmRvcnM/DQogICAg LSB3aGF0IGFyZSB0aGUgcGxhbnMgZm9yIGFsZyBhZ2xpdHksIGZvciBsb2dzPw0KDQpDVCBpcyBh IHN5c3RlbSwgbm90IGp1c3QgYSBoYW5kZnVsIG9mIG1lY2hhbmlzbXMuIEl0IG5lZWRzIHRvIGJl IGRlc2NyaWJlZCB0aGF0IHdheS4NCg0KQWx0aG91Z2ggbm90IHBlcmZlY3QsIEkgc3VnZ2VzdCB0 aGUgc2V0IG9mIFJGQ3MgdGhhdCBkZXNjcmliZSB0aGUgUlBLSSBpcyBpbGx1c3RyYXRpdmUNCm9m IHRoZSBtYW55IGFzcGVjdHMgb2YgYSBnbG9iYWwgc3lzdGVtICh3aXRoIFBLSSBhc3BlY3RzKSB0 aGF0IG5lZWQgdG8gYmUgZG9jdW1lbnRlZC4NCg0KU3RldmUNCg0KDQoNCgkgDQoNCiANCg0KSGVy ZSBhcmUgbXkgaWRlYXMgYWJvdXQgInN0cmljdCIgYmVoYXZpb3VyIG9mIHRoZSBUTFMgY2xpZW50 Og0KDQogDQoNCj09PT09PT09PT09PT09DQoNClRMUyBjbGllbnRzIHN1cHBvcnRpbmcgQ1QgYXJl IHN1cHBvc2VkIHRvIGhhdmUgYSBwcmVjb25maWd1cmVkIHNldCBvZiBsb2dzIGFuZA0KDQp0aGVp ciBwdWJsaWMga2V5cy4NCg0KIA0KDQpJbiBhZGRpdGlvbiB0byBub3JtYWwgdmFsaWRhdGlvbiBv ZiB0aGUgY2VydGlmaWNhdGUgYW5kIGl0cyBjaGFpbiwgdGhleSBzaG91bGQNCg0KdmFsaWRhdGUg dGhlIFNDVHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBUTFMgY29ubmVjdGlvbi4NCg0KIA0KDQpUaGUg Y2xpZW50IGZ1bGx5IGNvbmZvcm1pbmcgdG8gdGhlIHNwZWNpZmljYXRpb24gU0hPVUxEIHBlcmZv cm0gdGhlIGZvbGxvd2luZw0KDQpzdGVwcyBiZWZvcmUgZXN0YWJsaXNoaW5nIHRoZSBjb25uZWN0 aW9uIGZvciBldmVyeSBjZXJ0aWZpY2F0ZSBpbiB0aGUgY2hhaW46DQoNCiANCg0KMS4gSWYgbm8g U0NUcyBhcmUgcHJvdmlkZWQsIHRoZSBjbGllbnQgU0hPVUxEIHJlamVjdCB0aGUgY29ubmVjdGlv bi4NCg0KIA0KDQoyLiBUaGUgY2xpZW50IE1VU1QgaWdub3JlIGFsbCB0aGUgU0NUcyBwcm92aWRl ZCBieSB1bmtub3duIGxvZ3MuDQoNCiANCg0KMy4gVExTIGNsaWVudHMgTVVTVCByZWplY3QgU0NU cyB3aG9zZSB0aW1lc3RhbXAgaXMgaW4gdGhlIGZ1dHVyZS4NCg0KIA0KDQo0LiBJZiBubyBTQ1Rz IGhhcyBsZWZ0IGFmdGVyIHN0ZXBzIDItMywgdGhlIGNsaWVudCBTSE9VTEQgcmVqZWN0IHRoZSBj b25uZWN0aW9uLg0KDQogDQoNCjUuIElmIGFueSBvZiBTQ1RzIGxlZnQgYWZ0ZXIgc3RlcHMgMi0z IGhhcyBpbnZhbGlkIHNpZ25hdHVyZSwgdGhlIGNsaWVudCBTSE9VTEQgcmVqZWN0IHRoZSBjb25u ZWN0aW9uLg0KDQogDQoNCkNsaWVudCBNQVkgY2hlY2sgd2hldGhlciB0aGUgY2VydGlmaWNhdGUg aXMgcHJlc2VudCBpbiB0aGUgbG9nIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHBhc3NlZCBTQ1QuDQoN CklmIHRoZSBjZXJ0aWZpY2F0ZSBpcyBub3QgcHJlc2VudCBpbiB0aGUgbG9nLCB0aGUgY29ubmVj dGlvbiBNVVNUIGJlIHJlamVjdGVkLg0KDQo9PT09PT09PT09PT09IA0KDQogDQoNCkNhbiBpdCBi ZSBhIHN0YXJ0aW5nIHBvaW50IG9yIHlvdSB3YW50IHNvbWV0aGluZyBlbHNlPw0KDQoNCiANCg0K LS0gDQpTWSwgRG1pdHJ5IEJlbHlhdnNreSANCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVHJhbnMgbWFpbGluZyBsaXN0DQpUcmFuc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFucw0KDQogDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRyYW5z IG1haWxpbmcgbGlzdA0KVHJhbnNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJhbnMNCg0KDQoNCg0KLS0gDQpTWSwgRG1pdHJ5IEJlbHlhdnNreSANCg0K --Boundary_(ID_0vPvzw7W3ZvUqzXYT91KXA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIGNvbiBmb3JtYXRvIHByZXZpbyBDYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiVGV4dG8gZGUgZ2xvYm8gQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MY29uZm9y bWF0b3ByZXZpb0Nhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBjb24gZm9ybWF0byBwcmV2aW8g Q2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgY29u IGZvcm1hdG8gcHJldmlvIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFUzt9DQpzcGFuLkVzdGlsb0NvcnJlbzIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLlRleHRvZGVnbG9ib0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dG8g ZGUgZ2xvYm8gQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlRleHRvIGRlIGdsb2JvIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RVM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMy4wY20gNzAuODVwdCAzLjBjbTt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM1OTY2NjY3NzsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTEwODg3Njc0Mjg7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTQ5MDE2OTk3 NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NjY5 Mjg2MDQgLTM2NTM2NjU1NiAyMDE5ODE5NTUgMjAxOTgxOTU3IDIwMTk4MTk1MyAyMDE5ODE5NTUg MjAxOTgxOTU3IDIwMTk4MTk1MyAyMDE5ODE5NTUgMjAxOTgxOTU3O30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDIgbGZvMg0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtbnVtYmVyaW5nOmNvbnRp bnVlOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDowY207DQoJdGV4dC1pbmRlbnQ6MGNtO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24x PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+SSBoYXZlIHNvbWUgb3RoZXIgcXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4g c3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoYXQgaWYgYSBDQSBj YW7CtHQgYmVsb25nIG9yIGl0wrRzIG5vdCBhY2NlcHRlZCBpbiBhbnkgbG9nIHNlcnZlcj8gPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxp c3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPldoYXQgaWYgeW91IG5lZWQgMyBsb2dzIGZvciBhbiBFViBhbmQgb25seSBnZXQgMiBmb3Ig d2hhdGV2ZXIgcmVhc29ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZv Myc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hvwrRzIG1hbmFnaW5nIHRoYXQgcHJvY2VkdXJlIHRv IGFjY2VwdCBsb2cgc2VydmVycz8gR29vZ2xlPyBBcmUgdGhleSBnb2luZyB0byBiZSByZWdpc3Rl cmVkL3B1YmxpY2x5IGF2YWlsYWJsZSBmb3IgQ0FzIHRvIGNob29zZT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbGluZS1oZWlnaHQ6OS43NXB0Jz48Yj48c3BhbiBsYW5nPUVTLVRSQUQg c3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPknDsWlnbyBCYXJyZWlyYTwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FUy1UUkFE IHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrJz48YnI+UmVzcG9uc2FibGUgZGVsIMOBcmVhIHTDqWNuaWNhPGJyPjxhIGhy ZWY9Im1haWx0bzppLWJhcnJlaXJhQGl6ZW5wZS5uZXQiPmktYmFycmVpcmFAaXplbnBlLm5ldDwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RVMt VFJBRCBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+OTQ1MDY3NzA1PC9zcGFuPjxzcGFuIGxhbmc9RVMtVFJBRCBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FUy1UUkFEIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxpbWcgYm9yZGVy PTAgd2lkdGg9NTg1IGhlaWdodD0xMTEgaWQ9IkltYWdlbl94MDAyMF8xIiBzcmM9ImNpZDppbWFn ZTAwMS5wbmdAMDFDRjc5Q0IuNTU2QTg1NDAiIGFsdD0iRGVzY3JpcGNpw7NuOiBjaWQ6aW1hZ2Uw MDEucG5nQDAxQ0UzMTUyLkI0ODA0RUIwIj48L3NwYW4+PHNwYW4gbGFuZz1FUy1UUkFEIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbGluZS1oZWlnaHQ6OS43NXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjojODg4ODg4O21zby1mYXJlYXN0LWxh bmd1YWdlOkVTLVRSQUQnPkVSTkUhIEJhbGl0ZWtlIG1lenUgaG9uZW4gemF0aXJlbiBiYXQgZWRv IG1lenUgb3NvYSBsZWdleiBiYWJlc3R1dGEgZWdvdGVhLiBNZXp1YSBiYWR1IGJlcmUgaGFydHph aWxlYS4gT2tlcnJla28gaGVsYmlkZXJhIGhlbGR1IGJhZGEgKGhlbGJpZGVhIGdhaXpraSBpZGF0 emksIHRyYW5zbWlzaW9hayBodXRzIGVnaW4pIGVtYW4gYWJpc3UgaWdvcmxlYXJpLCBrb3JyZW8g aG9uaSBlcmFudHp1bmEuIEtPTlRVWiE8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojODg4ODg4O21zby1m YXJlYXN0LWxhbmd1YWdlOkVTLVRSQUQnPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6Izg4ODg4ODtt c28tZmFyZWFzdC1sYW5ndWFnZTpFUy1UUkFEJz5BVEVOQ0lPTiEgRXN0ZSBtZW5zYWplIGNvbnRp ZW5lIGluZm9ybWFjaW9uIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCBhIGxhIHF1ZSBzb2xv IHRpZW5lIGRlcmVjaG8gYSBhY2NlZGVyIGVsIGRlc3RpbmF0YXJpby4gU2kgdXN0ZWQgbG8gcmVj aWJlIHBvciBlcnJvciBsZSBhZ3JhZGVjZXJpYW1vcyBxdWUgbm8gaGljaWVyYSB1c28gZGUgbGEg aW5mb3JtYWNpb24geSBxdWUgc2UgcHVzaWVzZSBlbiBjb250YWN0byBjb24gZWwgcmVtaXRlbnRl Ljwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpuYXZ5O21zby1mYXJlYXN0LWxhbmd1YWdlOkVTLVRSQUQnPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RGU6PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPiBUcmFucyBbbWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmddIDxiPkVu IG5vbWJyZSBkZSA8L2I+RG1pdHJ5IEJlbHlhdnNreTxicj48Yj5FbnZpYWRvIGVsOjwvYj4gbWFy dGVzLCAyNyBkZSBtYXlvIGRlIDIwMTQgMTY6MzM8YnI+PGI+UGFyYTo8L2I+IFN0ZXBoZW4gS2Vu dDxicj48Yj5DQzo8L2I+IHRyYW5zQGlldGYub3JnPGJyPjxiPkFzdW50bzo8L2I+IFJlOiBbVHJh bnNdIFZvbHVudGVlciBvcHBvcnR1bml0eSEgKHdhcyBSZTogRE5TU0VDIGFsc28gbmVlZHMgQ1Qp PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz5IZWxsbyBTdGVwaGVuLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5IZXJlIGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHF1ZXN0aW9uIHlvdSBhc2tl ZC48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+TGV0IEJlbiBvciBSb2Ig Zml4IG1lIGlmIEknbSB3cm9uZy48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNt O21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSc+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxzcGFuIHN0eWxlPSdtc28tbGlz dDpJZ25vcmUnPjEuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPkFueWJvZHkgaXMgYWxsb3dlZCB0byBvcGVyYXRlIGxvZy4gQnV0IHRoZXJlIHNo b3VsZCBiZSBhIHByb2NlZHVyZSAoc2ltaWxhciB0byBDQS9Ccm93c2VyIGZvcnVtKSB3aGljaCBp cyBkZXRlcm1pbmVkIHRvIHJlZ2lzdGVyIGxvZyBhcyDigJxpbXBvcnRhbnTigJ0gKHdlIG5lZWQg YSBiZXR0ZXIgd29yZCkuIFRoZXJlIHNob3VsZCBiZSBub3QgbWFueSDigJxpbXBvcnRhbnTigJ0g bG9nIHNlcnZlcnMsIEkgc3VwcG9zZSDigJQgb3RoZXJ3aXNlIHdlIGFyZSB0byBnZXQgdGhlIHNh bWUgcHJvYmxlbSBhcyB3ZSBoYXZlIHdpdGggbWFueSBDQXMuPG86cD48L286cD48L3NwYW4+PC9w PjxwIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xO3ZlcnRpY2FsLWFsaWduOmJh c2VsaW5lJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Mi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+QW55IGxvZy1zZXJ2ZXIgY2FuIHNlbGVjdCB0aGUgbGlzdCBv ZiBhY2NlcHRhYmxlIENBcy4gSSB0aGluayB0aGF0IOKAnGltcG9ydGFudCBsb2dz4oCdIHNob3Vs ZCBjb3ZlciBhbGwgdGhlIENBcyBzdXBwb3J0ZWQgYnkgbWFqb3IgYnJvd3NlcnMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206 LjAwMDFwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xO3ZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+QW55IGxvZyBzZXJ2ZXIgY2FuIHNlbGVj dCB0aGUgYWxnb3JpdGhtIG9mIGhhc2ggZm9yIE1lcmtsZSBUcmVlIGFuZCBmb3IgaXRzIGtleSBz aWduaW5nIHRoZSBTQ1RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1s ZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDEgbGZvMTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSc+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUn PjQuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PkVhY2ggYnJvd3NlciBzaG91bGQgcHJvdmlkZSBhbiBlZGl0YWJsZSB3YXkgb2YgbWFuYWdpbmcg bG9ncy4gQnkgZGVmYXVsdCBpdCBzaG91bGQgYmUgYSByZWFzb25hYmxlIHN1YnNldCBvZiDigJxp bXBvcnRhbnTigJ0gbG9ncy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4t bGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzE7dmVydGljYWwtYWxpZ246YmFzZWxpbmUnPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl Jz41LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5FYWNoIENBIGNhbiBiZSBhY2NlcHRlZCBieSBtb3JlIHRoYW4gb25lIGxvZy4gPG86cD48L286 cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206 LjAwMDFwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xO3ZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Ni48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+QnJvd3NlcnMgc2hvdWxkPG86cD48L286 cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6NzIuMHB0O21hcmdpbi1ib3R0b206 LjAwMDFwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yO3ZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+YS48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+YWxsb3cgdXNlciB0byBhY2NlcHQgdGhl IGNlcnQgd2l0aG91dCBDVCBwcm92aWRpbmcgd2FybmluZyBhYm91dCBhYnNlbmNlIG9mIENUPG86 cD48L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6NzIuMHB0O21hcmdpbi1i b3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8y O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yi48c3BhbiBzdHlsZT0nZm9u dDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+YWxsb3cgdXNlciB0byBzcGVj aWZ5IGFic2VuY2Ugb2YgbG9nIGZvciB0aGlzIG9yIHRoYXQgZG9tYWluIChub24tcHVibGljIHN1 ZmZpeCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDow Y207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDo3Mi4wcHQ7 bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2 ZWwyIGxmbzI7dmVydGljYWwtYWxpZ246YmFzZWxpbmUnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5jLjxzcGFuIHN0 eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5hbGxvdyB1c2Vy IHRvIGEgcGFydGljdWxhciBsb2cgZm9yIHRoaXMgb3IgdGhhdCBkb21haW4gYW5kIHJldHVybiBh biBlcnJvciBpZiB0aGVyZSBpcyBubyBTQ1QgZm9yIGlkIHByb3ZpZGVkIGJ5IHRoaXMgbG9nLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjcyLjBwdDttYXJnaW4t Ym90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZv Mjt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmQuPHNwYW4gc3R5bGU9J2Zv bnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPnRoZXJlIHNob3VsZCBiZSBh IHByb2NlZHVyZSBvZiByZXBvcnQgYWJvdXQgbG9nIG1pc2JlaGF2aW91ciBpbiBjYXNlIG9mIGlu dmFsaWQgbG9nIHJlY29yZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4t bGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246YmFzZWxpbmUnPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl Jz43LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5JIHRoaW5rIHRoYXQgd2FybmluZyBpcyBhY2NlcHRhYmxlIGluIGNhc2Ugb2YgYW4gYWJzZW5j ZSBvZiBTQ1RzLCBidXQgaW4gY2FzZSBvZiBjcnlwdG9ncmFwaGljIGVycm9ycyB0aGUgZXJyb3Ig c2hvdWxkIGJlIGdlbmVyYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48 bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBUaHUsIE1heSAy MiwgMjAxNCBhdCAxMDoxMiBQTSwgU3RlcGhlbiBLZW50ICZsdDs8YSBocmVmPSJtYWlsdG86a2Vu dEBiYm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2VudEBiYm4uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RGltaXRyeSw8YnI+PGJyPlRoYW5r cyBmb3IgcG9zdGluZyB0aGUgbGlzdCBiZWxvdy48YnI+PGJyPkkgaGF2ZSBiZWNvbWUgdmVyeSBj b25jZXJuZWQgdGhhdCB0aGUgZG9jIHdlJ3JlIHdvcmtpbmcgb24gZGVzY3JpYmVzIGEgbWVjaGFu aXNtLDxicj5idXQgd2Ugc2VlbSB0byBsYWNrIGEgZ29vZCBkZXNjcmlwdGlvbiBvZiB0aGUgYXJj aGl0ZWN0dXJhbCBjb250ZXh0IGluIHdoaWNoIENUPGJyPmlzIHN1cHBvc2VkIHRvIHdvcmsuIFRo ZSBpbnRybyB0ZXh0IGZvciB0aGUgSS1EIGlzIG5vdCBhdCBhbGwgYWRlcXVhdGUgZm9yIHRoaXMu PGJyPk1heWJlIHRoZSBjaGFydGVyIGZvciB0aGlzIFdHIHdvdWxkIGhhdmUgaW5jbHVkZWQgdGhl IG5lZWQgdG8gcHVibGlzaCBhIGRvYyBvZjxicj50aGlzIHNvcnQgaWYgd2UgaGFkIGdvbmUgdGhy b3VnaCB0aGUgdXN1YWwgQm9GIHByb2Nlc3MgOi0pLjxicj48YnI+SSdkIGxpa2UgdG8gc2VlIGEg ZG9jIHRoYXQgYWRkcmVzc2VzIGEgbnVtYmVyIG9mIHBvaW50cyB0aGF0IGFyZSBub3cgYmVnaW5u aW5nIHRvPGJyPmJlIHJhaXNlZCBieSBzZXZlcmFsIGZvbGtzOjxicj4mbmJzcDsmbmJzcDsmbmJz cDsgLSB3aG8gaXMgZXhwZWN0ZWQgdG8gb3BlcmF0ZSBsb2dzLCBkb2VzIGV2ZXJ5IGxvZyBjb3Zl ciBhbGwgQ0FzLCBpcyBvbmU8YnI+bG9nIHBlciBDQSAoZXZlbiBpZiBvcGVyYXRlZCBieSBzb21l b25lIGVsc2UpIGFkZXF1YXRlLCBob3cgYXJlIHVzZXJzIHN1cHBvc2VkIHRvPGJyPnNlbGVjdCBs b2dzICh3aGF0IHRoZSBVSSBsaWtlPyksIGV0Yy48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gaG93 IGFyZSBicm93c2VycyBleHBlY3RlZCB0byBkZWFsIHdpdGggbWlzc2luZyBTQ1RzLCBtaXNzaW5n IG9yIG5vbi1tYXRjaGluZzxicj5sb2cgZW50cmllcywgKGNyeXB0bykgaW52YWxpZCBsb2cgZW50 cmllcywgZXRjLiBhcmUgYnJvd3NlciBhY3Rpb25zIHN1cHBvc2VkIHRvIGJlPGJyPmVmZmVjdCBp biByZWFsIHRpbWUgb3IgaXMgdGhpcyBkZWZlcnJlZCBhY3Rpdml0eSBtb2RlbD88YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0gaGFyZCBmYWlsIHZzLiB3YXJuaW5ncyBmb3IgQ1QgJnF1b3Q7ZXhjZXB0 aW9ucz8mcXVvdDs8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gaG93IGFyZSBicm93c2VycyBleHBl Y3RlZCB0byBkZWFsIHdpdGggY2VydHMgZnJvbSBDQXMgdGhhdCBhcmUgbm90PGJyPnBhcnQgb2Yg dGhlIFdlYiBQS0k/PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAtIHdoYXQgYXJlIHRoZSBmYWxsYmFj ayBwbGFucyBpZiBzb21lIG51bWJlciBvZiB0aGUgV2ViIFBLSSBDQXMgZWxlY3QgdG8gbm90PGJy PnBhcnRpY2lwYXRlPzxicj4mbmJzcDsmbmJzcDsmbmJzcDsgLSBzYW1lIHF1ZXN0aW9uIGZvciBt YWpvciBicm93c2VyIHZlbmRvcnM/PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAtIHdoYXQgYXJlIHRo ZSBwbGFucyBmb3IgYWxnIGFnbGl0eSwgZm9yIGxvZ3M/PGJyPjxicj5DVCBpcyBhIHN5c3RlbSwg bm90IGp1c3QgYSBoYW5kZnVsIG9mIG1lY2hhbmlzbXMuIEl0IG5lZWRzIHRvIGJlIGRlc2NyaWJl ZCB0aGF0IHdheS48YnI+PGJyPkFsdGhvdWdoIG5vdCBwZXJmZWN0LCBJIHN1Z2dlc3QgdGhlIHNl dCBvZiBSRkNzIHRoYXQgZGVzY3JpYmUgdGhlIFJQS0kgaXMgaWxsdXN0cmF0aXZlPGJyPm9mIHRo ZSBtYW55IGFzcGVjdHMgb2YgYSBnbG9iYWwgc3lzdGVtICh3aXRoIFBLSSBhc3BlY3RzKSB0aGF0 IG5lZWQgdG8gYmUgZG9jdW1lbnRlZC48YnI+PGJyPlN0ZXZlPGJyPjxicj48bzpwPjwvbzpwPjwv cD48ZGl2PjxkaXY+PGRpdj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IZXJlIGFyZSBt eSBpZGVhcyBhYm91dCAmcXVvdDtzdHJpY3QmcXVvdDsgYmVoYXZpb3VyIG9mIHRoZSBUTFMgY2xp ZW50OjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPj09PT09PT09PT09PT09 PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UTFMgY2xp ZW50cyBzdXBwb3J0aW5nIENUIGFyZSBzdXBwb3NlZCB0byBoYXZlIGEgcHJlY29uZmlndXJlZCBz ZXQgb2YgbG9ncyBhbmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD50aGVpciBwdWJsaWMga2V5cy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5JbiBhZGRpdGlvbiB0byBub3JtYWwgdmFsaWRhdGlvbiBvZiB0aGUgY2VydGlmaWNhdGUgYW5k IGl0cyBjaGFpbiwgdGhleSBzaG91bGQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD52YWxpZGF0ZSB0aGUgU0NUcyByZWNlaXZlZCBkdXJpbmcgdGhlIFRMUyBjb25u ZWN0aW9uLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBjbGllbnQg ZnVsbHkgY29uZm9ybWluZyB0byB0aGUgc3BlY2lmaWNhdGlvbiBTSE9VTEQgcGVyZm9ybSB0aGUg Zm9sbG93aW5nPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c3Rl cHMgYmVmb3JlIGVzdGFibGlzaGluZyB0aGUgY29ubmVjdGlvbiBmb3IgZXZlcnkgY2VydGlmaWNh dGUgaW4gdGhlIGNoYWluOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjEu IElmIG5vIFNDVHMgYXJlIHByb3ZpZGVkLCB0aGUgY2xpZW50IFNIT1VMRCByZWplY3QgdGhlIGNv bm5lY3Rpb24uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Mi4gVGhlIGNs aWVudCBNVVNUIGlnbm9yZSBhbGwgdGhlIFNDVHMgcHJvdmlkZWQgYnkgdW5rbm93biBsb2dzLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjMuIFRMUyBjbGllbnRzIE1VU1Qg cmVqZWN0IFNDVHMgd2hvc2UgdGltZXN0YW1wIGlzIGluIHRoZSBmdXR1cmUuPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+NC4gSWYgbm8gU0NUcyBoYXMgbGVmdCBhZnRlciBz dGVwcyAyLTMsIHRoZSBjbGllbnQgU0hPVUxEIHJlamVjdCB0aGUgY29ubmVjdGlvbi48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD41LiBJZiBhbnkgb2YgU0NUcyBsZWZ0IGFm dGVyIHN0ZXBzIDItMyBoYXMgaW52YWxpZCBzaWduYXR1cmUsIHRoZSBjbGllbnQgU0hPVUxEIHJl amVjdCB0aGUgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5DbGllbnQgTUFZIGNoZWNrIHdoZXRoZXIgdGhlIGNlcnRpZmljYXRlIGlzIHByZXNlbnQgaW4g dGhlIGxvZyBjb3JyZXNwb25kaW5nIHRvIHRoZSBwYXNzZWQgU0NULjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklmIHRoZSBjZXJ0aWZpY2F0ZSBpcyBub3QgcHJl c2VudCBpbiB0aGUgbG9nLCB0aGUgY29ubmVjdGlvbiBNVVNUIGJlIHJlamVjdGVkLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPj09PT09PT09PT09PT0m bmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Q2FuIGl0IGJlIGEg c3RhcnRpbmcgcG9pbnQgb3IgeW91IHdhbnQgc29tZXRoaW5nIGVsc2U/PGJyIGNsZWFyPWFsbD48 bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LS0gPGJyPlNZLCBEbWl0cnkgQmVseWF2c2t5IDxv OnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHByZT5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w cmU+PHByZT5UcmFucyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0i bWFpbHRvOlRyYW5zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHJhbnNAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJhbnMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW5zPC9hPjxvOnA+PC9vOnA+PC9wcmU+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5UcmFucyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0i bWFpbHRvOlRyYW5zQGlldGYub3JnIj5UcmFuc0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFucyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnM8L2E+PG86cD48L286 cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnIgY2xlYXI9YWxsPjxicj4tLSA8 YnI+U1ksIERtaXRyeSBCZWx5YXZza3kgPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= --Boundary_(ID_0vPvzw7W3ZvUqzXYT91KXA)-- --Boundary_(ID_d+wXSMpV/FUOoHz1dApj9Q) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.png Content-description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAkkAAABvCAIAAAB3iMNhAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAASlZJREFUeF7tXQd4HNXVndned7XqvViSZcm9yLiC7RgwNtWAA0looSUhBUJI QjUtTk8I+UO3DQSMjQEbN9yrbElWsXrvva2k7bNl5j9vV5ZFM8Je2RDe++z9dmfmvXlzZjVn7333 nssKgsB8/eZEF55h3AwjYRgMgH9442IYOcNgH17x3r8Lh0m/ZBftNRIoigZFg/6l0OcGfYp+jlNY JyNXfG2WYkfDbV5e6Lc7KlsGdxY1HK5rKWjocnJ2xmxj5DKG9zAMyzAiRvAwUilj5xi1gnFyjFTG eD2MyLfL42FkUobjGKWCcXCMjPaiaNDvBv1Loc8N+jwcHTsYDXqFPD0uaGZs3NWzkiZFG0PVCrFI dHa6+2puy2vo3phTtvFkZVePOUynzkgwZiYnxwWLtHIDy/JiMetyE8tPLmPdboEXWJYR5HLW6RQY lpVJsIXxeLFNUCpZh4NsFIsE2ouiQb8b9C+FPjfo8/Ar2QHWUb/d1tlrzaprruswt1sHNFrNbTPT blswaWpc2Fno7Wzc1tRvfetQ4Yu7i9Qa8YqpKddMTZmTFqeR4NcWbRQBigBFgCJAEbigCMB6OlLV vr2k7uPcSpPd8ZPFk++7dFZ8iPYLJ/Gl3La/ouFX/z3Y0Wv5xbJZP1g4aZzxi/tf0CujJ6MIUAQo AhSB7zwCzf3mV/YU/mdfXnhYyJ9XzrlmeurnIfkCbnN5mN9/tO+F3afunJ9+/2UzZyScze77zoNM AaAIUAQoAhSBi4BAcXP3K0fL1h48efe8SU/fssSokI2cxGe5DVGNd7+8fd3BvH/df9MDi9JZEidC G0WAIkARoAhQBL6JCKzPKb/31Y/vWjDt5TuuGDm/z4aaPLclZ93+ovd+e8vPF2VQYvsm3kk6J4oA RYAiQBE4jcAds9M/eODGd46XP78950u5bX9l4592ZP3nZ9etmj6eQkcRoAhQBCgCFIFvPgJXT0v+ /fK5j288sKe6eXi2Z+y2xr7BX7y2Y2VG3I/npX3zL4bOkCJAEaAIUAQoAn4EfnXljGvSU+7524eN Xf3+LUPcxvP8S3tOdbvFD96wUCYVU7woAhQBigBFgCLwbUFAJZf8+a6lvEL63NYTbg/iRk5zW3Zt x2t78x5dMWPaWbPhvi3XSedJEaAIUAQoAt8pBMaH65+6Yd4bh/Nz63uGuM3DCxvza0KD1DdmUm/k d+rLQC+WIkARoAj87yDwo4WTJsdE/emT40Pc1mNzfpBbsWxmcqyBJmj/79xmeiUUAYoAReA7hYCc FX9/Yfq2E5Vmp4ustxW29pp6rCumJo8WBbeHqalg6uuZ+hqmvo6pryVvqqtH250eRxGgCFAEKAIU gTFA4ObMCQwv7K5oIbnbD75zcEt+TcUff6yQjSKKZNDiWvM009PA8HJGyjMeXxYchnF65NNmMA/+ zqf9TxtFgCJAEaAIfLMQQP2cxh6ryW4XeN7LeyVSqZtzyRRyvOK91+th0RiRb5fk07u8vl2sl/ec Wy+xRCpnhHC9IVwvH2tN4omPvj4jJZJw28yn3o4O02z92fWjuQ+ubR/ya551qFVKGSO4Ga8YEv+M FJUAxAzXO6h77Q12yuzhcewe3mrj7Dy/v7xOyogUMklUsGFKbOjewpp+jnN7RIvS4iQ8o9LKInVK zu1tNNkTQpQnqjpru3qlUtHl0yZEqqVHG1qrG828IATrFAvSIkM1qtHMkx5DEaAIUAQoAn4EPsiv eS+7orStx+L0eJwO1NcUJAzr4XiJVOQWC1Iv6/EIYjzTWVZwCWKW9Uh5qSByOQWpgvWwgtiNYpys IBHE596LlcnlUqlep8pMCnvkiktTojRjdHd++c6+A5WNxCdZ2TEwOzpqlKeRoU6bRKLQGRhWyar1 YolaItcwSi0jUko1WqbPPnKcqq7+LUW1LsGjlqvUWvmJ2u5nP86q7jOvz6mWyFWMSGRUqd4rrLzp Xx+jV7+DeyentKDR9H5upc3NdNtdN/xrA7a/erC022pXaFivIEjB/bRRBCgCFAGKwOgQQIHNm1/e fuOfN2w+VlzZ0tPW2dPlcHV53N2Dli6X0MN5ujxcd7+1y8t0u9zdNmuX3d3N8V1eV0/fYBcv6na6 ujhHt8XR7eLPq5db6OwdbDLbMInXd5Ze8vjrj24/6hJIsH7AW2ZCbGOfU4Qq2TbOEWL8ijpvw6fn nC4YaazT4ZXxTpeTFcMp6ea8Lnxk3S5G/SmHpEQQBm12NSv6/szklZNTiuo6V1+7kPe6p40LvT0z 5f5LM0L1Up1CUd7S2tFnlqGwm8DwIiEyXHPdrJTfXD7zkrio9cfKgsTiX62Y+aPM9JtmJRvko/Ca BhwqOiBFgCJAEfgWInCkplV9+5r39+SSpSIlnIJeUhoajIKa0goF4/UyYjGD5zacYR5YZnDBiRmx r2asy8XoNAznYsSgBvSCUcGTctPn3MvjZfQaxolhlYzcY/I417y2O+P3r1WbLAHHNTRE7bDbRaR4 6IA5wmAc5QnkSgUpP6pQil3wMcoFrxh4yMUyfBRQ99v22WHkKFQqIoT0QXGNSMrMSQzlHF67xc3x /IAdxMqIJbKfXj3rxSNFGplUIfASN8/yEouD7OowWydE6txyRVNXv83psnFueCZHOU96GEWAIkAR +C4jsD6natFj77i8DBNsYFRKQlRgJgmWkWCdiAhpKRWM3UF24ZkOhyQITyIl5OfmUGyaQIcDnHgf oF42B6PGuUSMBIMLTJC2tqpt2u9eKu40BfY2GZUK1MMGP+M6FU7XaG1DF7lUhsMrCSRx8WLg4WG8 bkYiuMD/n44jwSe32836DM8/vJ/9n3uW4o3g5neeqrl37Z6fvHugvt86YLX+aNbktgFHSYtJLpcw SqGso2vdkVP3vLkjMSRo9rjY9o6uhzYee+DNQy/sLTT56JA2igBFgCJAETgLAltO1f7m9S08lpDA ZLDPQGyw2ziOQZS7CKaYwMCQwmMcZANDAgfgQS6W4nlNLDZYaTiM58eyl4SYiXqVvdN+2ZP/bekP pPXGC5yE2J5ShpG4Ry+zJZFJGSejkEkFD+sVS8U8iyARr0gCY1culjCiT9lV+CCTyvRa1eotWdfO Sk01BuFm8DLm6ksy3rz7yg13X5UUpOFcLjfPPLZs7t/25Mrwk4EXJ+h1105Pe+GHl6+56VIcL1fK X7/jynX3Xf7oiswQ3AnaKAIUAYoAReDLETjZ0v3wO/t6BznGoGBgMLjceBDDiGHgQoOlAW6TSAif +W04qZTwHLb4Q9xJpCTLSC9IL5w9XNff27v87+8H9H6S6EYRXKm4YO9ozTaGd3KCl/C8AHcm70Xo DOhXEMhH8qNACwTPNOyQidiS1p681t4nVwzFT3o8vFjkHj4Isah9DmdqhEYiEo5XNklYiUohjwnS qfAjwtc8do9aRZfZAnrr6WAUAYrA/ygCHoH/KLesrrEDJgiDStMeD7HY8AqbDOQFryN57yFsBwbA Rthn8ECC3rARy29gPmy8YL1gJmpVJSdrcxo6AndDwNt+PUmXMPqUNMmM6bKISM4+yFo5iZPz2hwe h13sdLEDNiEhgUn6lGqXVCLVKqRbT1bwHuHVrOK/78t783jloM2JcJ0XDxT+ZfdJBFIGBSlEWPNj mFvmT7HbPSqpWAnQQZmnm1ot++OO4y/uK1qfVdpt+dyCXuDwoCNRBCgCFIFvOwLtfZaDBc2MSMZI fL7HoYWizz/jTxfo/OKnv3/rhekF/57qiQ/3Bw55Mm3W7uZVN67+4Kkf3jAtZbRDnyrgOmolXgWA E8QkukOEYEmsTCYmiiZMHAmG3eUZdHD9VnuP2Sng14DHo1bK4oO0DT2DLp73ePn0qFCs2ukVKr1S xnn5mnZTYri+x+oI16mUsJF9rbitu3PQLhZEMoVoSnSoTkHTAEZ7o+hxFAGKwHcNgQM1LUueeZf4 HhHxCH8jzDL4JPEGj2hYZtiO9+A8/8IbHrMw0eC4gxMS3ki8R7vwvewusUzW8OIvYvUBeLznNnXP Xb2etTt51e3Pb/r1qptmjZrbvmtfFnq9FAGKAEXg24CAIPB/3JX76Kt7GQNYTSAeSDgYsa4GJoOL EhElWHLDchoYDvGK8EPCVEAsCYiN5ANIGCwzwVrx+y0RhcG5P9sLrj6/uxJhfYQCfb1IUgE/dC7/ Qh05l5twJzkXsr6RKfa5XsPnwgxxrj7zusduvyMzADSU29Q2b/U7IkbGMi6OEDltFAGKAEWAIvBt RsDh5suasHCFOHYZieZ3cYTYsIqGFTUHQtwhlAgCAxWxjMnB9FuZzh6G8zB9g0hzZvrNjMXOWJ2M aYAZsDAdVkaOyEHXmV5YvMJooENE8yM9gIwsYWx2ZsBKuvf1Mw4X09NPBuzuZ+wcM2hlzDYyFI7H BIZ7gV+RKgfWOTNDCSOTnKhuDQj2LBLoiE/SxqtuXfPeozeuykwNyLh0EIoARYAiQBG4KAggEfiq v27MLqkn6djgMHAPgjXAQ4RXENmPXGwpY7YyCuk1C6atSI9PDg0TWAQxIP4c2WD+kD3E+kmru3r3 VzVt3JFLtqkUQ8YZLDB0B1/6B0RgRG9/9ITEe+ZNzEwOV0hUAtHyQgbb0IAsK7E57SebetceLGqt qmUiw0nWAfoi6hDjsKBYDHh6hmbrtUtmbrlv+fnjltvUMnf1BtbOC6obHt+y+vZrpwTAGDz/adER KAIUAYoAReDcEBh0uK7/50cHT1YzOoRB+kL54Q+02gnVgZncSHTj5s9M2Xz/1eEa9VefQmCu/dtH H2efIj5GJfhPIA5MGFtwNrrcRqVk3S+vuyZ9VAVk/rQv/3drd/kSw92ELP0hmohV8c/QZmO8yitn x+166OavntVXHZHb1Dd39VoRwwlIO4cbdowaLsFFAjLPqxEcvDzPC17fv/Maa3Sd/WdEbXIEvIyu xzf3KDvngRTnyPmRpEy42mmjCFAE/rcQwHqbC6oiImRnnU7QBhuB2KA/gnUyzrny0qnbf75yVMQG ZFhm68PXP7zqMkKKMLnAE/60bs4drpbnP3fvKIkNI/32ezN2PvEDpt9JolcwFAYBpflTyDFDtZoR rJCwCtDdcPIMghex0uZ0gzvHotncnl0VzRtO1mwsqG7sM5/9FOCsL+OtTgf3fn7duyfK3swuP9nU 5/J+Nb15BOFYXY/5rE9wkGV1d38XXMyfa302bkd5y5bCxnePVxyu6RwLcL5yzD6rM6+ho7C5K7+x s23AimRBdLFy7n44xL+q2d0eCxzlvrajuHnXqfrhHg09ls25de+frPmgtMHs9EDJ7GjDWS8QIp9I YvyqM9L9FAGKwMVHAH5ARILwPkmt4QRt/PnCf2h3Th8X9ddVC/VYRRvROgZt3WZ754AdT8JOi717 0IbfviPbU9fMv3beJLJ+hkASf1q3zb7nydsSQnUjDxu0uzoG7N0Wu/+1a9BuR1DJiLZsQuKfHljG mJxDHk6sAp6ZITnuU0efF5TDudvM18jd/lpnrG437cipcjrcDa1997+15+x9TzWbaroGvvAY3ut1 OJx7ShqOV7WzrFc0Ivvty8Z0ssLRyqZPy6R89liRiN1Z3Fjc3P35QQQkpyNjQcVuKak9WHGGGL7W 5Z/nwV1m54Gq9uyGjr/tztmLUnss2z5ge2pb9sHytrOPbOFcL+4vOFRDFmb7nEKf0/pRbgXsc387 WNW0u7JWLhHvK2z61678+h77q3uLzjKgyeo8UX9x2P08AaTdKQLfOQTwS9QvqeHPxfYnaCOD2+2R KmT3L5mZYNQPY1LR3vvsjtx7Xt9x76u77n5t172vk3/3vbbzyQ+PFLee0XjUyKU3Zo6XoMwLFKRg /FlsC6amTI4MHh4HysDrskp/sW7f3a9+ct+ru+7BUK+Q10c2Hny/oBq/noePfGTprEmTEhkU2flM CjlhQcRKBuonNGqvMeLHnnzq+S2HV82flB51Zq6B+kK0DliR+Xb/ZZPnj49ds+Xoz5bOhKn0YW5N YUtvhE6tkon3V7TsKqmNC9GrxLKf/ndPTYfpsvT4xr6BD/KqBjh3Yojeny2nk0mnJ4T32byT40KW TojrHrRvzqssazdNjgn1er2Hq1uza9ttnKekpa+4tXd8hMHs4t84VCBiJZMiDQqp9HB12yflDRzn jTJowGcYEDbQ7uKmo9VtNZ29U2NCgvXqDdllBQ2dGTHhYt8Barl0QqQxTK0+UtH4k0XT4biu7eoP 16vbzJbOQWe/3XmsprW0rRf3YmtxHVSegzXKwubujwuq+51cfIiupd9W0tp9qKplamzYiYbOnPp2 EnDrZrYUVhe19iSGojyfpKyj/8O8ig6LQyWDNCe/rajmWE17lEGrhWvb10K1innJUbMSIvrM9ilx EVEGdZ/N9cax4vHhQVPjQs9yjwYcrvdzKsJ16imxYbnVHV1ms5uVTk4I1/pqz5Y0d6eGByN0aPq4 yDUfHF0+PaW4u/uq9IR3TlScau2JNGhw7QXNnTmN7Sdq26bFhX9UUPXXHTmzk6PNTuf2wvpTTZ2T 4sJpAdpA/Y3QcSgCAUTA6fZuOFHRDPVhSG2Rspo+kS24fAQmKcz47x8vQ7kV/+mK2nrufWnL24dL auo7qtpNNW0dVc291c3dla3dR8tqD5R1XDMzzaAasvDkEtGJqub23gFCQFbnYzctnZEU5h/H6Xb/ 7eOch97eV1TTikEqW/tqWtur2kzVrR0na9o/zq9XKWQzkyIkRMSSNJgmu3IrSdikv8CNf4bEOcmk xgbfOifj/NFoG7S9cahIRBLPBRSkO/8Bv2AEhVxa2Nzz5MfHb/i/j+5aPBNHHChv6rU5OI9n66l6 VGhDBrdepXrqg+MiCVYrxWqFvMVk+aCgTiWXbS2oyhrhDHS6vEj9hjWFQf59IE+ukFV3mtZlVZjd 3rezKixu70sHC9vNtl2ldbW91rYBW6IhKCJEufZEaVl7T259e7RRZ/bwWELzz3J3WeuWUw06tcKG 7wIrXpdVolaonYL373vyRl7Ga8cqEsODUyOC9pY17ipowK78ut7dJfUbcyoq2vvzm3v/vPukQa9c e6wMuwbsrgidNqe2s7LN9EFu6dvZJSFBpPje3z/JaewdDNEoe6xOvVLR3NMP2sD2pz/ICtFqTzZ0 bjpZbXF7QGlegX05q+wz/r8KMKiYjQsmC78JwZofzkjjEF901hauVV4+McmABVuGidBr2gfMYoHt s1pPd2Lz6rq2F9c+8eGRmxdmiNRSKS8ARqlE3GtxbC2pxWF/2HXSw/KNXeb1x4vDdBqNVCEXifvs HH4clHda3s6uGJOvCx2UIkAROE8EiBik72lOPH6++jV4ZIJIXK6kSKNmhHDw/+0vOVHfRXyMBi1j UJE1OY2MMagZgwYRGNUVtX/Zmzs8lzCtJj40iJiDWJ9QiqaMixjeVdza9+bxMgEx/VoZ1LOYIBWj 1TAgRZTI0ao4u/3/9uTWdw8MHz9zXIwvYRxZd5IzM0SMCfSxvkAG5dzgYH2aW0gE8IyVTxI/F3Ry 0ezYyO/PmJDV2Fbd278xrzqvsaugpePjkgqHy33FxPhIvWoXIlYZZl5y5KyEYIvFFqSQ/vCS9MtS YuFJ8y8yobFiVpCyuF9Hqto5QXTdtNSnr5u79lARFqUmxQVfOTEuRKO+NDUmOdxQ3WXKCNdNjw9F hdnSlj6T2dnYPRCr1y9Lj1XKyLoiCuVsPVV99fTolTPGTRsXU9LUtyWr4lR9W/uA88VD2cNYVnaa Kto6l8GCxiqXx9vvJBn7cPdZHA6pVHLZhLjp0eFqlfzGScmNbcSruSA5Jik0BHexpm+g085dnpqw fEI8AmAYr/TGmWkoFz4x1jg9LooXRB0D5u0FLcF62Y0zUzKTwnud9jidZnZCRJBacrCoAabtyPuZ 29gG1g/RDgU1sWLvSEerh/cWtfbtLmnsRaTviCaWoDA8+ZwWrbv3smk/XTwpKUjr3y8SC5Aua+q3 Ls8Y99PFU+wDVt7jMcglizPiUAk9v7bd6RvqhsnjV05LOV7eOTEmZPb46CijNjM+fHyckefdB6vq zu0bR3tRBCgCY4uAIOCZ4JP59eVTw1/kD+VjWZPL+UkpftM37ihs3Jhbvb+igezF2ptfi4QczJJX HA+m0auOFJ/5M5eKWZnSF9BIzC+JUXsm6KO139yA/DYilI9z4aHD+tLAfeclYvmi1g4TftYPX7VB haB/n8olSbMbMcPTKQiBwAclbsBtyN1mXGMUS+LkXLEG3ZyUyJsvSVs4Lur/duWzvOyni2f+etms N398NeS4fvPegT6HEI4gGQDGimRyKQgsNFiFjwmhIYMCB3Paf6kQZsbTWiqS9NmcCcFqCDUDRJ6V WLzexGAdUgr1CrlMxEvEknCtauOJmr8fLtGgBLpIesn42FVz0188lP/UtmN+zy/IY9BsnxZPSMuo kjf2D85MTrhr4aQ756cXPHbXMLK7SlumxAXPSAjHFjEnUfrKrqo1ChaVDTQajUwiEbGRGgM2aoOV +Pr8cW/W3qo6vUqOSeK8GfEx5FwCo1WwMfhlxDBvZVf8N6dEJVEaNZqipq65afHYGKLVqFn50er2 f+wpQd6IUacY+tnlm0froL2m154YHDz8VZIpZaSE63Bjmazy5o+Lapq6PhWqg+IK7Omgo3ijPiZY oyZC4KR5eNGcCQl3zJ10w4wkOArc+L0AB0X74D935bFSXieXOwUmLAhfXlau12CVzu3xSiS8WCp6 aV/p+3mVBq1OTKoX0kYRoAh84xDAX70MqWOCmNAG0fiHQwyp1iQHIK+0+drVb928eu0Nz6794ZqN 9XVtREAEaWqIfoROL0LPkNwNtRHyz4E/e9PpYDTy+BWLPHiWIaCx3wEvpA1xiKebAxyGHANkbaMj hkLyHDriPUbDeW1Eo9lNCloPNbHLF40y5Cw9PUO7nWHVqI4aIEBleGD6cgBUSm7EuQM0OhlGjB/5 HrdCSp7MB6pap8SFJ0UoecGVGKSXK8QbcstmxcXdPD0BhgsOcHi8bt7rcXlqGwfwMa+tOUIm9/lM fU0QcQ6R3emKVMuKajvhIjORSNTBUIm81+5wcW6bA1GWYthkfeaBZ7Zm/fPG+UsmJ3V2dOO3waUp 0W/8aOmxivbGASK1jCW34BDt4fIGl9tbUNcapVX0W7kYoy4p2NB1Opgzp6qlsrntmtMamzK5t7+f TDKnspGz2bycEwSJ1MBBX4yl1cFUtvSX1fU+tHRGmFFts7nABzZfqTmyjotPLndFZ9/JqpaV05LT EoNaBhxLp8e+l008mQW1La3dvXvLaq6YGL18crzV2o+YkeFbUNrcgV9BMxPOeACsNpz2zC2SsOL7 l0598dbvzYgJGXnjCPIItP2ir4qXd3k9nOK0291ud+CLmlfTdP2MlDkJEVavC6UbLD3kunANWDwG pKwgFHf0lHV2/3j2pJgg5GMG8DtCh6IIUAQChgBsAKeHY1iiy+Ez3XyEhOUJu1Mil4ZEaUPHhRkT w4JjDHHRoRGJhoT4yPAQfXx8eESCMTYyJDoyJCohOD4+VBVmiI8dWlEjjwKvN0ynDooKDUsKU0WF GKRnao0ZJLKI2IjQZCN6RYQZEmIjwxP18THhEeHG2PiQ0JRQY1Q4nvZnrlBGMpAYjy80f3iGKJoq 2OUB80k68Az15W5f//iWp8ckd7uhz7p6S3aDyQSv748WpP904USTy3P7S9s9Hs+9Syddlprw8zf3 hQYpTtX2PHT1PGQC/n7ToZfvuOpYQ8f6I4Xjw0NeuW2JjEhZk4Z8rJ1ljYgMWTQ+7p0TVf89WTbY 5zz+9K39LndeVduUhIiPSxquSI9DTOOs5KR+c899Gw4vTkq0elwTgoNq+00VnabbF2TcNmuCxFcE vN/tuevlHbDrkmJ0v7xsckWr+S+7822841dXzbt5UhwO+Ki4ds22Y9FaTb8NBeTY7Q+svH39ToSQ ZEQbZiXGKKXyjHBtfb+ta8Dxw9mpf9ya/7trZzyxLaegpjUyWJkOmhGYG6ZPSTDKkZX3l70nf3nF LCUj+iC/9rX9pWnRxi6bdcO9V72UVb6toCI5WJ8YGjw3OfL57cdTooJyansfW5G5LIOYdCab/cO8 2snREZnJZ75kO2vbXAP262Z+RaL9/oomsVR+WfIZUhz+bm0rqBHJJFdNTPRTaHWf45Oi8sVpyb98 d2daWEhbv+OBZVNPNQ88/L3JLQ772p35D14166H3DlyaluR1uT7Ir8yIi95fVH/42R+qAvZFDNgf Nh2IIvAdR2DQ6brhHx8dQO62b4WecUA9REaMpEHz9ZdO/fBn1110fGr6LKkP/AtuOlIE/NMzvHLO xF0P3nj+M0SeWObqtazdzqtu+cPGx26++VullUzUNb/tGpg+CdHdpY3Hazuevm7O+d9ROgJFgCLw HUdgwOZc/rdNx4uhuaUc0i8mdbSlcC5dOyd9SyCY4zwRruo1p937d1SyJhEufoXlQM8wt6l13up3 sd5GVpPGaL3tPFE4S/dvO7F5Be9fPjm5v6Jrb0nLorSosQOKjkwRoAh8hxAQsTKwBUQ54DvCijvC IH1BkoiVDNxq1nnBKcdaILgWkxzDGcpJ2To7x6t+9Oz7v7kFMXvnNWXa+WsisKWwpr7TOislfEEy 5baviR09nCJAEfgiBJBGffXfNx8rrEOgo281yxcAiXCSQfPVcyZ+fNpuwyL6J+VIR3KK5V7GJWGk WACDqD/CT7BKh6B0xup2hml0109J8p8Eays5TZ3VbYPY5fHwN89I1qqGCq01mayHq1pxIhHEQDwQ uvIP6CXvhwZEdU98RE6CFyrMNV29T711gLhJFSKSePclMzyf25vb1DF79dus3cWrbnpm85O3rpxO ue188KR9KQIUAYrARUZgwM5d+/fNRwprScoamMPjC2iE6TZoXjFn4rbT3Nbv4OY8v6GqspmwDgvf Hewc/MPB/qAPD+P0RCbEtP/zfv/1mJ3c3Wt3vL+3kJR/4xxF/3l48mn5iLdyq27/2yafor+/u28d X4BcpF/I0ReuibQEF9yP/txdMaNRkHQCEqH9pTM8Hxxzmzpnr37LH4c4Vrnb5zM/2pciQBGgCFAE vh4CJECQ/CepZiA2f7lthEwzipECHVqF3KCC5YQMARVRMIE5BjkkBHeQfGoJkfxnJSGqM8GQIhZW GawxKemiVJOc69NNDSUn+BiROixXkkFAXQocpiQH+0YTySW3Xj770TuueGTV8j/cd80vr188JFCL 5IFPzzBwsrW4HuQAIDNLLj5vpf6vh3/gjg5UPsRnZ9TQPQC54cDNk45EEaAIUATGHgEUAiC52/78 M5AFUaD3UZFnwHZG3gFRipemxJAoSn+pUhKjLxCbDDtgbnkh1e+869IJw9NFMhD0K3zyXTIoVTpH PBtTwg0TooNJZhuGwumQmo0z4r0IryLG6poYEf7E8kuev37+H1bO+f0VmbcunMxAXmqIaT81Q3HA Qq/9udtSVPseq9xtQHOqyXTfm7sf25w1DBMSqE81dfk/muzcw5uP/Pj1Hf6Pg07u8a0nHn4vq91E BKJAXD99d/997+xr7hvKqHJ5+A3ZtY29Q3nK339l97bCutxGIgtyFpbbUVy/Kb9mlKV2HG7vrzYf e+iDw797/1hVe//Zvox+O35EO1HX8WpWmcVFy8eM/d8wPQNFgCLwOQSQuy1B7jbqAMBmIsXSUIwU 615iRimt6+jrsp95ND1xzbxFs1OZ5rahlG0UzrbaSM410le7e5YszvzJkunDw3db7U3dZiypEepi +P0VZyRLIOr78PLZUqTQdQyQmt1IBkfWNjK4rRzTZZHo5Y+vnJsWZcRQPpUIpqC+mXAqaNJfd9s/ Q8yWyHAFpiE5HHaJL3ebV3DuMTGArHZ+Z3ntg1fM8Iq5B7ceIezl4H767t5txU3+i/jt1sPLp8fP TYn9wb8Jvb18sCgkSD0x0fjvA4X4BXD/mzsXp4y7Zcq4n67b5j8e6W5N3abWfvIDpM3haWzunD8l Lsao3FfU9Elh9ZcBkxEdMjHaKDmdrXx2/HaXVIdIRB/95NrV182PCzV82cH7SlvX5pRy/Kdsu1i9 JjM6yi9JTBtFgCJAEbjACMBqcyF3GzYTBB4RHkki7N3ESOK4botl04lTw/PRyGX7H/rRvx+/c2pG 3LSUuGlpUdPGx01LjZk6If7x+6/Z+ouroec+fHBxc2tRYxMxB8FJbsnmvKEHuP+AOxdM3vLrm5ct mTEtPWpaasK0CZF4nTEp5raVc7Ofvuum2WfsPxy87kAJI0iJQBdkt4Zn6LMShqJTzhsygeF8uiQK lmEdCqK8Ffh2orEpVK2JNwb98frF2SVEa1giEUfodUoI3zMMZOb1jHJGZOSPL53c63U299p6zI67 Z6TeOC1ZJBV3DFp7+l0LJkcumJiogWv4dAsOUpS2NePTh1lFV88bHySSmjjPa9mlGwpQIc5p8XBP bT/61pFyHABl5K1F9e/mVJocriijXiSwb+VU/WzDXovjS7WGEQ60s7Bp1ZzJ6G6EOpaULe80Pbbl KESTsQVG+Xs5Tc9tOV7bP1De1vWfT0rKWgax/bWjFc/sPGF2C0atMsKoPtna84+9eS8cKnphT37g MaUjUgQoAhSBL0GAFYsUUgXDQ1zflwMA7Qssm8Eg06o9Ds8/9xU195wR50O0x88WTip8+q6C5+4o ePaegmfvLHjux4XP3PnsdXNRDGT4DD0253+zqiAcxSgV4EgmXF1wtKC0zTJyCldNSdr50HUFz95b 8OxtBc/eV/Dc7Xmr737zx8v8moXD7d9ZlbmFZUyYdsiBOTxDqHOxGmfANLeUYDWf3aZQYsJj0SCN D5FHqU9bxCBTW5yCWipZNStFpSSKkU19VqNRKfaZU4la9e6KZhkr1qgVKBkDkSeocjyz6pLbXtq2 4oUPf79i8fD0UkNDyhsGcONQO+bWSybuLGk8XtaSFhUUHSxDZdnfbjoyPiTkUFX9uydLUWTvF2s/ jtAr86tb3jl8qtpkgT94UXLcz9bvHB4N0lkuLz9clhrDtlndoQZ5vcla2NaHwzrN9kVpSeuPlByu 6vmkquW93MIFE+PtVhfczvHBsjCNYv3xytKWrkiN9jfv7D5R077+0CnBI6TGhH6SV7fuRNVYoErH pAhQBCgCX4iA4OWdI+tuo142xCE1auJp1Cjr61p/+Oq2yk7yZBtlQ5XRx98/sOtICaNTE1sQdbdh CBrU0594JbtxaGlplEN9VFzz8zVvk3GcTiKX7K+77Z+hv+52wNbbHFjH8623OTjpUMmwUU5y1Ifx ZE3Pv2w46HXwWKjEOiUCaXyVexRysdynVUiGk0gFkdcnPEkaZEdQj62x17FkQvx1k1L+cyCbKHX6 2qVpUW4JW9lhNlmsiUatyytKjNDNT4tdlJxQ3tQXqpB/P3P82ntWvH6w3OkWvj9v6uK0eI1GIVap orTK6UnhvEwYgHzn6YYiaq8cLjpc2+U+XWtWLfe6Ge/RmuZfv71ve2Hd3ITwUIMqWCOqbOtJNKiN aqXI45kcGzY9KuLyjJSYEPWftp8I1ytMDqtepe60OhUqcWZ86IzIsIggzYnffX/USNEDKQIUAYrA eSPgz90mdbf9Va09ZFkLz1iSwe2GsOTRUzVL12zacLwCJbZtLvywR/AJeRzjDakBgDdkg2BzeWAb bCmtm/3cf1/ddpLRKocMQSSDIypSKkXFsTlPrPvte0fKOgcHHBycZHhAk9GIGrtvKDIOKIzvtzlR pvK2V3fc8NibDFZ51Kqhutv+mEz/DH3tU6VMzgMJ5KvjiuD0JGLRYxQnGaxTOTxO6GxinlY7q/f5 bz1uVGEg3Bam1nSYYYqSjbUd3QuSovs5j8XjtnAeXHKjyfb2gbJHrph13+JJTq+wq6Jx+GIzonX/ 3nti9rgEbBEkgsvjdjggR4xCbB5BKuNZFuVoZLwgJfn5ZHSxIChFzFtZpRuPl6cHh8AsHB5KBA+y 282jPoCPOsHCkUFQTLbdPjv9uqkpvQ7nkx8ebWzrSYkIt7tsGVHGJ5bP2lXcuO5oCQro+O4jvi3S XyyZ8esrMv9884IYg9IliEyc9w87cm+dk6yE1DNtFAGKAEXggiGAGjd43qIOFlazYCIgWAMPW7zH PwToI4RSpWzt6r31Xx+u+OvmhzYdeGZH9l925qzZnfeH7Tlrtp9csyt3za6Tz+/I+fWmQzf8bfP1 T73diLg/NQwqX3UbPDgRIQmOVMoJ1THCnzfuWfj8unvX7nlm6/E1u/P/gKH25K/Znr1me94fduX8 cVfe0x8cv+eNXQueWff2zhNMmGFoViBT1MTB9IZniDfETRmYBmMQQ/nrbh9ctWBy+oga4YE5A577 MkVBU9egw721sDbJYFiUQcq+NPcPNvcMzk2ODter9lQ1upzuwgYUlHbfsSCjrMt0sr6ztLVDJZEt nTAuq75VKRHVdfVXtffdNDfNIB9aaxTEkl9tOvLUtZfEG7WlTQMyiRixMCjDPT8t8Uhlq0xgNmSX XzI+ZlxU8JHKpmWTk04196JYTk1377hwQ1JYyMuHTt42b6rMZ0SGaVWoKJ0UpveX20Z9GTfL7Cys cXj4HWX1UTptR99gZkrk4fI2u5uZGhfW1G+WyST9DrdRr0SJ0Zmx4TaPs8XE4UtT3zsIi6/XbCtq 62wdsE+LC2vrs0WjHM8YFX4N1E2i41AEKAL/Kwig1jIqJzd1jKi7jUsDvWHpByH+/sI3kClh+Y62 /vyatsMVzfvyqw8U1B8srT1QWn8wv/ZgYe3B8sb80oaWHgsKdJGD/b0wgr/AGx6VMAqJfcKC5BwW Z3l925HShgPF9QdP1R7Iqz9YXHOgouFgXu2BU3VHK+sqmjodoC4s+yEV4cxQECXxjeCPniQEzKbE GgNUd9uOuts+bvvgMLhtwhhwm0YukQni4yRGn31gyVSlL4AQV6FVKeONGtBJUoguu767y2x/6MoZ KDwdE6Sp7BgURMKKKUmJodowgyq3uqPTbr9mRuqkiDM1XLDKBSfm92eOE6NcjUQcqlPrldKmXvPM hLCYIFVBY69CJdw3fwpuJYqtpUQYvIIoyqhbkBJV0ABD3B1u0MSG6ELIIF/Q4oy6um5Lh8mCVdAr 0uOD9JqSzr4pMSFQpEHh2kNlLbC1l00ZNyEyqLS9M0itXTlj/N5TzR0WS5RelxCq0ysUUrEINdwG 7Z66voH5ydH/K3819DooAhSBbzoCTo/3vRM+boMmFkjIH1cPhyRyzuD98xfjhg0HllIjU9sXcgJ7 juRZg2YgLywj1UpR2hRdNPJP9YI5CCej33+I1TI8XmFoYVj0QowJHJXohS1YkEP1NFgKGAEHY50J r8QsIQ7K070wFHIAxL5oSf8M5QxnT40Nv3VO+vlD3DZoe/VQEWt38qpVz216/Ps3jZmeJByPQWrF cMEwn1uWxO/4W5+NQ5FPvXJoxc/OeeBHVPsKZJO9FgeW54JHZMj7txMpzBEYACizg1NiAU8i6bY4 gkg4CuFRn9Q+yRTEXcbxA04Osi8oYsp5PMO1Oj8PpcsrWB2c8TT59docIWplv80VpJah0hsGCoKR TvIZHCKRVCuXWJ0eq5OLQDl238zwBbByTi8v4nh3xOl62ed/w+gIFAGKAEXg7AgQPcm/vX/sFPQk 1UNGEknNlpGcMz+TEesNWdg+loKDkRTL9hI+w7oMnpL4iF1EJSsQvUClpPr2aM71WcXL87nRuU3t s1f/1xdLwrgD5un8ohlF6lTDxIb9ON8wseFjsFo+TGz4qJJLhomN7NUqP09s/kFGNtwRg1ruT8gI 0yJ0fyhnwO8ORJlo//EGhVyjlINKz0JsOEwmZoeJDR9BbHgFsZFXjdxPbGh6pRLEhjcahWSI2Hwz w2R0SgWOp8R2Pl9Q2pciQBH4ugigsrEES1kIpCAE5lvDgkWFjGxYUXg8IjDeH7uBjcgtI0nTPvML lbJ9ESJnqnUHpBcMxNGey8GwKk/AcgBgEvpzt5VyCKbQRhGgCFAEKALfagQQm+jyuHyaW6frbuPh jjUzVN+G/QQRENCbP8wEFEjSuhmiNumnOiTwovlrYY/sBbfhBeglOGUBywHgfJpbyN12OHDttFEE KAIUAYrAtxqBM7nb/lUul4+34L9SKkScOzg0TARbjYQ4wmMn9qV120lQPnxNUOoi6WtYbxvRC0pa YD5IJ2ORyN8Ldt5Y9MIEGD5QWda4WqwoQiIaM1bCJB2LVtk5uCm3eltJ3TvHKrMbPpXoZ3MJdT02 x1mlF5Ez0WFzmuAIHtE8Xh7b/RvsLne/jesZcJGw10+3TgfXZMLC6tCRgiD0OFwNJnIoDjQ7Xd0O F+qvm5zYcEamBGH9/Xau1+myOhG/SdLgkLHRMmButTpIsgZZwBNMdkfbgGV4DmOBGx2TIkARoAic AwK+3G0nI/ISywySHP5Ua9CSzRERGfz3m+cnhgQRxyM8lk43Y7ER7X9oP+JZhyBvWHLogkxq8BzW 5/CoxAFwZvpTrYnsMhIAPIQOETwyaCHj+HvhgKFeThJMYR7RC9dAtLXcRBvF3wvPan8vWIrDMyRR l6JAWVgC4wAVix97ZvXzm/f9YNGUtIjgc4Dy7F26zdaD5W1vHC4OM+pDg6Tjgg3Dxxe39a7NKkiL CEI29BcOggXNP+zI33iiKKuibXpyvBaxN772jz0Fpe2+wEWR6JqXNufU9ZS39QVr5RF6zfA45W39 T3x05HB5bV2PZU5yFHzQW4vrX9iRl1XdHIxoxmDtC3sLP86rO1rf+sqB4nC1MjkiyN+33eFY/dHx /Iau9cdLK9oG5qfE5rf0rD9U/EFeRWOPeW5KdJ/d+caJ0tcOFNf2WifHhijHdKEy4PeDDkgRoAj8 TyPAeb3v51Y3QuRd7ltygpmFgA5ieykgUn+iormt34w1sPBgfTgCHYw6nYjR4FUqsvisA6nARgcH GY3qUJ0mCKF5MpkValhiiZgV9GqVXq0MD9FGRoSGaJQSVrBayDIetJkNKnmQVmM0kF4GvVonl8Jq 4WE4CXgRh6sVocGKUIM+SKPRKcRWuxupx0NZBERz6/QMBXlSjOEHczLO//60DXJvHDolfuzRp57f mrVyzsSMqMBzW6hWNT7a0G6x/X7ZjAnhwTB8sqpbId4RpVea7K7y9u4ZceF+bsMuiO6LRCLl6QjJ rcW1p2ra3rh7uVcie/VQ/tWTSQXY6u7BVw+cNCqV81KjwW3rDhZt/tl1i9JjRhIbDrvlpQ//dfvl d8ydtLuivs/mFouE7YW1z69csGr2hOggLUJL5qVEXTUlYWJEcKfZmpkcGQEZGF/TSaXLJyd9b0Kc ye5B6tv0BNxE0dVTUlbOHH/Huo9vWzjJKFfOGxe9KjNtY3ZFnFGD0c7/TtARKAIUAYpAQBCAt+md rNLmThNJr8ZjlVRx85L3DmeIUfPbKy8pa+zgnK5rZ46/anpqWrghOTrkj9fPnzQ+esuBEhEv+sHC CTfNnRhjUMcFGyclRfxgzrQu62Brc++4SOPjKy9bkhY3NdY4NSJ4bkL0nd+bcbKxs6+9JypI+9iq Sy9Li0kI0k6IDJ2ZGHHdnAytUlVUA21lFrJQ9yyZnhRqjDEaMsJDr5uXGmEIKiivJ15Q4of0Bc2T GcL5aZ0QG35LYHIABl89VIwTMAyHUt8BAfYLBnG4ebeHh4AW9r15smJHUf3ekvqdpU1yZIGJpOzp gEaIFL9xpLSwpXd4CN7J8D4pMKNcVtbSjjfwFubUdk6PjY4I1vs1QeBK3VhYuSG3qsdiH+7Y7eTE MmmcjrDOgtSklh5zTUdvuF53sqFzU245bPXhI7Nr24JVikkxZzLn/LvqekyNPb0Lx0fivQEF91jm YFXL1NhILebDMv02x1vZ5UkRxoQQw1ihRselCFAEKALngACK3CDKH88pv5IIAkMQ2e/LvEacf0ZC hFKu4FyejScqHn1rz7ObjsHAsrj5t6HNz3smRBtunT+lsq13Q1bprtLa1w8UuAT+sRsug3aVQa6a Fh9W1NDxyIajj7x38IF/b3FwnjsWTmTsHo1ckRxqzClvXLP5+F8/Ob763cOv7MlZNWc8HJsKiWjV 3Axeym7KrdxZUvVW7qnjZV1PXjdPq9OQqBY/vfln6GtfqmH/tXEgcfJDnDYmFW6GJkTG9sfiP7Pp UEyI3uly7Str8V/W8JzFLHtTZnJaxBm2WDIpQSRyv7jvZFZ9cxAWMxnmYEUjFkTnpMbZOZcfjWsz M7RiWWlbz9sniE6/vyERTQcvs68p4UD2egfc/MmG9n6b/VSr6e87h7T5uwat5W2mqfER/tLjZ5rA FLf0aVWyxFC9f+Oeypa3jhaj3JHvhwBjcbqrugYHOLdf5Zk2igBFgCLwTUHAFxVAJkOqWnsZ8nNc RFa2kFktSBFcQDQWeZ4bNCul4jW3Xf69ifF3vLR134lSOCohqaGUKVOiQn64cMrtcyb+ZGlm96Al v74bGcZilq/pGjhW1eC12wU4vjg+q645GDW7BbgrmdYecwWU5XmvlyfBmdnVbYNWm1Qk0kilSoUi WKm6MTP99rnTHlg8My5Eu6OkXuVXmBo5Q6LW7zM0A9R8DlmMJhf7tIvHppH0aaJlhTMoRdJ5KXGX jY/9yWWTOYRw8EM6yTgxlsQykyKj/enPvgapkd8tuyQ9KmTJxOQwJVlLK2zo+eRU7TvHimB0Q5oL W359xdSrJietmpnW3DvQT+qmkxahVvdZSWlTtD6HRyoWq8QiENX1M9Oeum7u5pyhMm913WaO9c5N /axuSL/VkV3dcmk6cYGi5Ta27z5V+5urLpkUHerfEmvUPXZVJqr0HK5qRWjJ2KBGR6UIUAQoAueA AHSKySPX14jko08lC2lt5BGPD2A6kFBcTNhzty7tHbDe9df3G8rq/OLFkDjusVn251a+uTV73bbD /91y/L3s0rKWbpAQj6wCAX42sJwvzFJJHG68XGDEPE8UmMVihJ9YOGbQzJjtYlakUcncgtsjCFDJ OFbZtHZ7zrqPj6/7OHv93uysqmabg6hHDk1veIZE4DlQpdb8dbchteJxk2y/MWq82GGD7eQlNo5S MjUmaElGItjb6+IEr0cqYRv7Lf0AhWFQKc2M6gwjWnywfkl6YlZZS2w44bb7Fk95dMWcmSkRc1Mi E/xGlY9ZOqwcFCaDTucx6BUis5NF0Ad2najtjA1BBQAdIlPcXg/E/lHqHNuxrHqwoi01MmiEbPLQ iQdcnFytmne67NDGo5W3LZycfnoxEoJbsEFVUjEv8tq8nE+KmTaKAEWAIvDNQIDkbkN5hCWZ2kgD gMUGYiPv4WZyG5Qq1isYDfq37l8xPzUa0d4rF8741R1X3LAkg5GzVV19iDS5aX76ghnjMqelz5ge 8+KtyxKjtAwrkYskGgUp6U1YkAiaCDoUKmMhRo+4SUdUkObBK+bevjzztuXzV10xY8Mvr23tQ+wl D5GU/Mb2KyYlXzM7bc701IkTYp68+XvXTkuzEocktKl82eL+GRIpL19geiCav+62+LHfPfX8+ydu mJeRER34WBLME4tktQPmOUlRKpk0WKP6887c7Jp2nUYRrFOignZmYtRrh8rsEnZCqP5v2wuRcTEu bChkEX3fOFH+0sEiKc89fcOl+KhTQhNEYXF71ChvHRcmEYn+ceDU2zlF7b3W++ZPhILJMCzzJ0Y9 ueHI7oqmlDDNnfMmxQZrW3ttbxwt3Zxf/fBVs5NCdb0Wx6HKhp8vnYFBRoKJXzyHyjtTQnXjwoYc kqjyUN3Ul93UdqS4dda4GIeHe/lI8SsHi4L1ypump2pPyzcH4o7QMSgCFAGKwHkhgJymt7NKWrpN PrFHFAQQ+7T2EdOPOH0xXF/1PSb8Lm8csBU19jldFkEkQY6Vzemt7uriXCwezr0WZ7ABQQZimVa+ 7Vjl+8eLvWJ2gBVKWzrqOk1OlEUjCeCKeou1rLWzvc8cGmLIiIs4VN9idjslrEStkRwoqV9/pNSF 0H+JtKSxs6bfFKRXgHP1Wump1r6X9ubaHXZCtyRJHDalb4bgNo7LiA37fmBiSfrXHiph7byguv7x LU/ffu2UlPMCdXSdYWjB9Tv6PIY+hx3u2i8bGy7BAY4LQorGF7UBDpEgZ3ZYOI7ITBKb/Gs32IAk DdDXD7GyuIQvTlz42gPTDhQBigBFIGAIIGf3+n98dPBkNWK+SYUvEnbOktwylCcluiQektmGH/T+ jOZhtxMIBmnaaMj15uAahNkD7X+BlAzFMfjJT6RJEJ8CfUhf3RyMAFpCDpxYOjk85OGb5v1nW042 oh9J4gGelUpGzDFyBTkYvXCu4ROR/G+kHeCRDulkeCZPz9BmY7zKKy+J3/XgTeePRW5T39zVa325 2yqlE8pbF6QReeivc6KzEBu5NSz7ZcSGvSOJDR9hY50bsaEvbvswmeHuUWL7OveQHksRoAhcIARO 5277lP5hGHl4X91tFYM0NX/Ktn/9CUGTkCOB8QTOA7EhSQB2HZFORvEUosJIDtNqhpS6QGz4SAb0 kmRwyHGB9hDfADr0cO22wfeyyluQ5a3zFR3FgCA2xPRD+gujkSe+lFGdPhf8pejlcAzV3R6eISYj WBUBW2/z192Ws1DSlMvowtEF+vLR01AEKAIUgTFCQCyRGBFhD28kaAYGFmgJDklYLghHgJ1EFJN9 phXcV4g19+tMgsnAW6SSM9bAsJzm7+WjQOz6fC+Si+ZjL/RSKHptzp0FUMswE+L098Kw4D//uUjF li8/1/AMwWq8oAWbBqKdrrvtxsllAVvFC8TM6BgUAYoARYAicA4IoFxarAEeP58gMsI0QFSkchvS en11t7G25q9r46+gDQaCFYVXHDxcC/vr9gIpkgoDiHw8j3ORyuDu1NAzwRbncO3DXfx1tyGRiZIz Y5i7fc5THHRyZpt/nYs2igBFgCJAEfhqBBRSySXjExnU3iLpSb4MbkTtI9GNlLc+XZ7tTNK0L/gA 1pW/xOhQDvW59fJlMZ/buVDzzOFFrdQFk2K++gpHdYTYp+tMEDiTZzaqjhfkoN2lTQdrIK9MnaUX BG56EooAReB/AoHMuPDk2HBiq4G0EIII3oLFBrMM3kWwF2wsYiT507qRhQ0lZV+NbKzMwZIjhbkR CXlhe2Eh0CnEx4VfmvTZbONzvSFYGPRzmxvFwL9xbUZc2JS4z6phBXCWPll/2igCFAGKwP8UAjEh mvmpsUPK/SQAxPekIwndvuiSM54wxFv4Fbn8G/0Z39joP/JC9mIYh+XhKzMDdxvI5MWPPfXU8xsP 3roYdQCMgRt6aKR9VS2QH8lv7DbZuWiD5qUjFSaHU6VQnGru7LPZLS7vidr2uq6BlIigN7KKtBIF 0qsPVzSnRpKZFHf0CQIfqVM/8Obhg9UNW0saY3XqYJ3q9azSF3bn67W6xGDNwcr2t44WbSlscri9 EyKD0HdLcdXLB4pYqRQyoChP8+qRitcP5aukssTT+WoYuY/jf/n2riNlnXqVPMaoWX+i7B978hAu Oikq2OJintxyZE9JU2lH95Ha9l2lzROjQjSI86GNIkARoAh8GxCQS8RYYdtW2ODhvIxCSvyECNZH RAnxPUKZBBabb+NwWjcuCiYdiezHAajWjdRn6PRfqF4IP3Fw8hD9x7+4IVDotpudrx06hZR1JEWL TLZAlYX71PSa+war2vu2FNTvLK5r6TXXNHR63WxxS+vOkrqcus6C2lYHLxyra0Sfl3YXn2xoqe42 t5jM/iFO1XXkljfjzZPXzbpsUnJeQxPkibfm1Tis3IPLL3l6y2Hs2llaVdPdd/v8tKO1TYNOx66i OruTf3TF/Gc2HcDeY5XdFW3dP14ydUthdWHjmepxv1q/Y8GEcb+/bta0pPBtxXV9Zvufb1y48ViZ yeo2WxzHqtpumTEhp7Jtaky4x+Eoae0PFOJ0HIoARYAicAEQuHJSys1zJ5HqaHD3+UMW/YH7IDZE LRIhR7gf4ZzER59bEmSGjGxSRG1E3e0L0AtZdAjX77P++cbFAYTF7XSLBEaEBHSpTD+I5IYxaOND DW0Wp0orqOSS/cXti2fFZSYH9dk5o0zBu4XWfm5eQkSITn2sqS0zOabVYms3mTNihmQbYUTzPsnj ML3qrQP5f73pCo1Mktvac7yhd/vxSrUv2FSpVC6fkgqLUCGSmm0ejUExe1x8agRURaJqBu0Hqmpq 2/q35tU5iL7LmZRtqUpz2yXjQzQKuYit6bCkhhrC9ZpFE6M/PFku14umRxvjItXJMUGZcRGhQSqR aGzKto4B2nRIigBFgCIABFQy8R9XLVo0P4PpMpMFNhhhJIONI5VIhypowzhDWpuCpHWjyhiW2URS X+j/iLrbCDkhxXHGoBep8e07F+zIrq67b7nsF1dOC+CN6+I4qRz5bQyTGmc4UdIWwKGHh5qSGNVm GpgdnSCTSrZUVq2YME7OSvPru8JD9Danq2XApFaIp0ZF/nNH/m2zx7tcfF5j+7SkqKHuyJdmHXh/ yyufXDktaUFypM3JoYbez5dOfOLGuTt/RQxYq82G9G2ILoN/3Iju4VgF0vWIb9mqRAKiTHzvorTn rp/32q2XT4sJhYiJX9rYbrcNz5BlUKSWdOnutSnVagF71AqvF3n5yD/kkPvh5b9WrvlYoEjHpAhQ BCgCXw+BCL38wEM3PXDHUsY8QNbebA6SduZE0rTPVhuZ1o062qSCtutTtbBh52HtDaq8hN4+l2qN ZPDz6YW0bkicICWO8f7nqVtfu3PZ17u2rzr6YH5jmtFIuG16dOSp7p6vOv5c9mskIq+Tjw/VRqmD OrqtIBHI/3ea7BFKmU6pUIvVKpl8TnrsgYKmS8ZHIWyTF0kHbM6/7MlFARo5L9ZLNGYH39RnWT4x rarLppTIJ0YHQ30/v7EH9bIxIa1Y6wanMV6ZCFrMLIovFFT3HqhsHXAwMQbVpWmJW0415TWYNkFG ze54L7fqT/tz0MugVj7/cV5tv7l1wDopMaKh25LT3FnRNbhyerzJ7ZGSEuxeidfndRazHmq3ncud p30oAhSBi4/AizctfOf3d4YrZYS9LDAVfKJZsORgM5E1Nl9aNzHp4LeUD6VaI8AQASYw6ZCChew3 EtkvJd3PvxeCFxGxSVTsSQDnlPTYw0/f/ZP5gbTY/IifaG5OiQ8Rr1692up2bjxQfsWM5Cj9mRIz gbotKo08NUxnVKvSEkLGhxlgZoUoFRNjQ8NQpDUmOFqvQh0CvU49MyHMYNSmBmsNKpmL45PDjBqd NCbMKIiZ7sHBwubOorbOEJ3q0tTYlkHbrqLqWXERyRFBvJjJiA4J0SrVcnVKuOFkTUu9ydRmGvzz LYsQABITpPYy3h2FtRkxwVOiQuwer4KRpEUal4xP2F9dn1/XnhIRPCchomvQ/HFB7T2XzYSGMu8R gvRqFMRRq6RJQahFKkoJN+pxP2ijCFAEKALfQgQmRQfftWhy7SCqXjK8y84hYBKx/ojydyPWH7qR UM9yMV5wHjK4kSfgk+kiq3Qc44WXEit2EH7E8TD1zq8XySXnJWIBK0hpUaEPLJ/z8h3LUk/XyAwg ribO++C6XfcvnYnMNqG2Z2DKU28/tWLmI1fNCeA5LvxQv99yZEVG0ryUQCUAXvgroGekCFAEKAJj gkBNjym7obeipat90AqigRdSIpK4vW6ZWObi3VIWviovbA+s7Xh53y7BLRPJXF63VCzBFpLRjQUg +LTOqZeIlUil3rSwsJQw3YK0pFDNWAWfr8sqveuFzQ0vP0S4DWURbn91R7NpYM8jt2oRM/qtbW9l l82MjUyPDnwyw7cWEjpxigBFgCLwHUJgyfPvWThX7jO3kfU2hUxy9+Kp1R3964+WfasxWDktNTXC 8K2+BDp5igBFgCJAETg3BDZmlx8ra37ixsvQfSgyfkFqzPLpKf/cm1PT/S1O51LLEf1xLuXZzg1H 2osiQBGgCFAEviEI9Frsf92StXR6yvfSiXbXEBMoJOL7Fk23DLrePHCKyhN/Q24VnQZFgCJAEaAI jBKB57edKG/vf/SaTKWvjs8ZK2decuTvbpjzwpGigpZvsek2ShToYRQBigBFgCLwP4PArpLmf+7M eeyWS+emDgkuf8qD99AVM5emR899dn2TmSRN00YRoAhQBCgCFIFvOAINXf33vfjBylkTH142e3iq n12devXOayeFG9MfeWFfdec3/Hro9CgCFAGKAEXgO47AyfreBX/dlJIUuf6nK0ZmIn+W20LUspPP 3rF8etrSX7+4evOxfkiQ0UYRoAhQBCgCFIFvGAJWzvP89uzMR/41JTzoowdv1KDo+IhG8tu+cMJ/ 3Z33u7X7p2ZE/uMHSzMTIuRiWiP0G3Zj6XQoAhQBisB3EgFopxyuaX1u0+FDpQ1Prlz05M3zSPTI p9uXchsO+6S06U9bj6H62vXTk6+ZPn52amRMkPY7iSS9aIoARYAiQBG4+Ah0Wux5DR1bsyveya2Z Gq57ctX3rpwc/4XTOhu3oYPF6V5/tGhDVml5tyVep5oyLnparCE5NjJMrlAoJR6PRyxCoRxi+4lE Iq/HI5FJ3ZxbKvPvkvh28SKR2OvxSmQSN+eSymS0F0WDfjfoXwp9btDn4WjYQSqTujh3l9lZ2dZT 0dZb2Nxd3d0/MVx/95Lp189KN6q+VEjrK7jNz4fQyy9s7Dla3ZTT0NljcXAOHjnSXqmb9/AsL2XI 4B7WzfIiiUjK826PiJfwEhGLQjEelCeHUBnP8x6RR8yLJSIx7UXRoN8N+pdCnxv0eThadvBC09kj 0cnFWrV0dmLM3KSIzNTomCDN2a3IUXGbfwivIPTbnLDknE6XVRAkDO9mWGKasSxexLzgFolkjIDg ExkPjWkWB8Ceg0UnZgU32ShwIjGq0dFeFA363aB/KfS5QZ+Ho2cHrUislktUcmmQWgm7aTS+0a/B baMZjh5DEaAIUAQoAhSBi44AVV+86LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+ C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQ BCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAE AowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG67 6LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiK AEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoA RSDACPw/jRlMVUNEDuMAAAAASUVORK5CYII= --Boundary_(ID_d+wXSMpV/FUOoHz1dApj9Q)-- From nobody Wed May 28 04:12:50 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27EC1A0942 for ; Wed, 28 May 2014 04:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 LSabooJ4Akaj for ; Wed, 28 May 2014 04:12:44 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF911A0952 for ; Wed, 28 May 2014 04:12:01 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hq11so6404994vcb.19 for ; Wed, 28 May 2014 04:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wIM71FiIrksKhyp5p2EQel4ycu/MVukzCWLiwkBLcMA=; b=baRKLSDJSSTKFL+j+BAelrsTwrIAZWrgRjNzSYtvsHCeC2qOWjdlsfRRTe7UfQ593e d8rn5MRJSDnbs/KpibjQgiYdil6l4H1LoRPQpMy3C4VsTLA9fNlHhSzQqWajeaLM3pEA Kwq08UPzLecWR7HngrD2LAoUX0zNhCWCNej2NZAY1r6DQk7vyT1plJD4GEkvtAsOkeji fUAHaQadawTqQEPMnLSsV//+zENzrIxG/eLsPw/o14Ui8aHboBD1ahe+4gefnT8z6kqQ ey1R1CpE+A9eD0Mm5wu9etVbAYfEywaYcqMJQEcLHeqtjURwO0s1HH8nATfTkJznJrgT uFrQ== 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=wIM71FiIrksKhyp5p2EQel4ycu/MVukzCWLiwkBLcMA=; b=G8eT8QiXl6jBOhuMHUpvaUcUKJxKG/VYACrkTi2kpdURP3+Tm1qQRug/h9KwfdE+A9 I9J1VtkYCZvlRRyYSyF9+B2TKRF4y+P7+ZhS0EyOxp/J/7McU3YUU2JyS2bVecp3aAlo OuIRhJNlZTfDF1KHXjUoLPSdDTOZ8vsEAEmUzgQ1g8GBov1PQ0AEVa60SU4WM0Gj6sMd ql6JAdjM2fL3OA2cmLr1NuWYRTEjxencat5hTf8Ttbrpa09LQPqK+9K+wrjKkghzSMdF efC0ZpxPTE083FsetZofY7GJ8mo1tm/vKQm8AB7odfgC1mvw9xLcbvKlUfsn7GhoxznZ u1kg== X-Gm-Message-State: ALoCoQmr4nljOr3lpbBEJGLPyS4iXaiKBtyr5itJm2Sz5albjeUXFLW6Ng/gaIXE4lLb6ISSf2e6 MIME-Version: 1.0 X-Received: by 10.58.74.38 with SMTP id q6mr32457485vev.7.1401275517258; Wed, 28 May 2014 04:11:57 -0700 (PDT) Received: by 10.52.107.132 with HTTP; Wed, 28 May 2014 04:11:57 -0700 (PDT) In-Reply-To: References: <5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> Date: Wed, 28 May 2014 12:11:57 +0100 Message-ID: From: Ben Laurie To: Dmitry Belyavsky Content-Type: multipart/alternative; boundary=047d7bacbedc706d0804fa73e19c Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RA6KXbv6h2D4GOLXXOetX4qatoc Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:12:48 -0000 --047d7bacbedc706d0804fa73e19c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27 May 2014 15:32, Dmitry Belyavsky wrote: > Hello Stephen, > > Here is my understanding of the question you asked. > Let Ben or Rob fix me if I'm wrong. > > > 1. > > Anybody is allowed to operate log. But there should be a procedure > (similar to CA/Browser forum) which is determined to register log as > =E2=80=9Cimportant=E2=80=9D (we need a better word). There should be n= ot many =E2=80=9Cimportant=E2=80=9D > log servers, I suppose =E2=80=94 otherwise we are to get the same prob= lem as we > have with many CAs. > 2. > > Any log-server can select the list of acceptable CAs. I think that > =E2=80=9Cimportant logs=E2=80=9D should cover all the CAs supported by= major browsers. > 3. > > Any log server can select the algorithm of hash for Merkle Tree and > for its key signing the SCTs. > 4. > > Each browser should provide an editable way of managing logs. By > default it should be a reasonable subset of =E2=80=9Cimportant=E2=80= =9D logs. > 5. > > Each CA can be accepted by more than one log. > 6. > > Browsers should > 1. > > allow user to accept the cert without CT providing warning about > absence of CT > 2. > > allow user to specify absence of log for this or that domain > (non-public suffix) > 3. > > allow user to a particular log for this or that domain and return > an error if there is no SCT for id provided by this log. > 4. > > there should be a procedure of report about log misbehaviour in > case of invalid log records > 7. > > I think that warning is acceptable in case of an absence of SCTs, but > in case of cryptographic errors the error should be generated. > > Google will be publishing its log inclusion policy soon, which covers some of these points. We have already published our EV/CT plan ( https://docs.google.com/a/google.com/viewer?a=3Dv&pid=3Dsites&srcid=3DZGVmY= XVsdGRvbWFpbnxjZXJ0aWZpY2F0ZXRyYW5zcGFyZW5jeXxneDo1ZjkwYzYwMjVhYTRmZjY3), which covers some others. I am not at all convinced that any of them are in scope for standardisation, though. > > > On Thu, May 22, 2014 at 10:12 PM, Stephen Kent wrote: > >> Dimitry, >> >> Thanks for posting the list below. >> >> I have become very concerned that the doc we're working on describes a >> mechanism, >> but we seem to lack a good description of the architectural context in >> which CT >> is supposed to work. The intro text for the I-D is not at all adequate >> for this. >> Maybe the charter for this WG would have included the need to publish a >> doc of >> this sort if we had gone through the usual BoF process :-). >> >> I'd like to see a doc that addresses a number of points that are now >> beginning to >> be raised by several folks: >> - who is expected to operate logs, does every log cover all CAs, is >> one >> log per CA (even if operated by someone else) adequate, how are users >> supposed to >> select logs (what the UI like?), etc. >> - how are browsers expected to deal with missing SCTs, missing or >> non-matching >> log entries, (crypto) invalid log entries, etc. are browser actions >> supposed to be >> effect in real time or is this deferred activity model? >> - hard fail vs. warnings for CT "exceptions?" >> - how are browsers expected to deal with certs from CAs that are not >> part of the Web PKI? >> - what are the fallback plans if some number of the Web PKI CAs elec= t >> to not >> participate? >> - same question for major browser vendors? >> - what are the plans for alg aglity, for logs? >> >> CT is a system, not just a handful of mechanisms. It needs to be >> described that way. >> >> Although not perfect, I suggest the set of RFCs that describe the RPKI i= s >> illustrative >> of the many aspects of a global system (with PKI aspects) that need to b= e >> documented. >> >> Steve >> >> >>> >> Here are my ideas about "strict" behaviour of the TLS client: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> TLS clients supporting CT are supposed to have a preconfigured set of >> logs and >> their public keys. >> >> In addition to normal validation of the certificate and its chain, they >> should >> validate the SCTs received during the TLS connection. >> >> The client fully conforming to the specification SHOULD perform the >> following >> steps before establishing the connection for every certificate in the >> chain: >> >> 1. If no SCTs are provided, the client SHOULD reject the connection. >> >> 2. The client MUST ignore all the SCTs provided by unknown logs. >> >> 3. TLS clients MUST reject SCTs whose timestamp is in the future. >> >> 4. If no SCTs has left after steps 2-3, the client SHOULD reject the >> connection. >> >> 5. If any of SCTs left after steps 2-3 has invalid signature, the >> client SHOULD reject the connection. >> >> Client MAY check whether the certificate is present in the log >> corresponding to the passed SCT. >> If the certificate is not present in the log, the connection MUST be >> rejected. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Can it be a starting point or you want something else? >> >> -- >> SY, Dmitry Belyavsky >> >> >> _______________________________________________ >> Trans mailing listTrans@ietf.orghttps://www.ietf.org/mailman/listinfo/tr= ans >> >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --=20 Certificate Transparency is hiring! Let me know if you're interested. --047d7bacbedc706d0804fa73e19c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 27 May 2014 15:32, Dmitry Belyavsky <beldmit@gmail.com><= /span> wrote:
Hello Stephen,

Her= e is my understanding of the question you asked.
Let Ben or Rob fix me if I'm wrong.

  1. = Anybody is allowed to operat= e log. But there should be a procedure (similar to CA/Browser forum) which = is determined to register log as =E2=80=9Cimportant=E2=80=9D (we need a bet= ter word). There should be not many =E2=80=9Cimportant=E2=80=9D log servers= , I suppose =E2=80=94 otherwise we are to get the same problem as we have w= ith many CAs.

  2. = Any log-server can select th= e list of acceptable CAs. I think that =E2=80=9Cimportant logs=E2=80=9D sho= uld cover all the CAs supported by major browsers.

  3. = Any log server can select th= e algorithm of hash for Merkle Tree and for its key signing the SCTs.

  4. = Each browser should provide = an editable way of managing logs. By default it should be a reasonable subs= et of =E2=80=9Cimportant=E2=80=9D logs.

  5. = Each CA can be accepted by m= ore than one log.

  6. = Browsers should

    1. = allow user to accept the cer= t without CT providing warning about absence of CT

    2. = allow user to specify absenc= e of log for this or that domain (non-public suffix)

    3. = allow user to a particular l= og for this or that domain and return an error if there is no SCT for id pr= ovided by this log.

    4. = there should be a procedure = of report about log misbehaviour in case of invalid log records

  7. = I think that warning is acce= ptable in case of an absence of SCTs, but in case of cryptographic errors t= he error should be generated.


Google will be publishing = its log inclusion policy soon, which covers some of these points. We have a= lready published our EV/CT plan (https://docs.google.com/a= /google.com/viewer?a=3Dv&pid=3Dsites&srcid=3DZGVmYXVsdGRvbWFpbnxjZX= J0aWZpY2F0ZXRyYW5zcGFyZW5jeXxneDo1ZjkwYzYwMjVhYTRmZjY3), which covers s= ome others.

I am not at all convinced that any of them are in scope= for standardisation, though.




On Thu, May 22, 2014 at 10:12 PM, Step= hen Kent <kent@bbn.com> wrote:
=20 =20 =20
Dimitry,

Thanks for posting the list below.

I have become very concerned that the doc we're working on describe= s a mechanism,
but we seem to lack a good description of the architectural context in which CT
is supposed to work. The intro text for the I-D is not at all adequate for this.
Maybe the charter for this WG would have included the need to publish a doc of
this sort if we had gone through the usual BoF process :-).

I'd like to see a doc that addresses a number of points that are no= w beginning to
be raised by several folks:
=C2=A0=C2=A0=C2=A0 - who is expected to operate logs, does every log co= ver all CAs, is one
log per CA (even if operated by someone else) adequate, how are users supposed to
select logs (what the UI like?), etc.
=C2=A0=C2=A0=C2=A0 - how are browsers expected to deal with missing SCT= s, missing or non-matching
log entries, (crypto) invalid log entries, etc. are browser actions supposed to be
effect in real time or is this deferred activity model?
=C2=A0=C2=A0=C2=A0 - hard fail vs. warnings for CT "exceptions?&qu= ot;
=C2=A0=C2=A0=C2=A0 - how are browsers expected to deal with certs from = CAs that are not
part of the Web PKI?
=C2=A0=C2=A0=C2=A0 - what are the fallback plans if some number of the = Web PKI CAs elect to not
participate?
=C2=A0=C2=A0=C2=A0 - same question for major browser vendors?
=C2=A0=C2=A0=C2=A0 - what are the plans for alg aglity, for logs?

CT is a system, not just a handful of mechanisms. It needs to be described that way.

Although not perfect, I suggest the set of RFCs that describe the RPKI is illustrative
of the many aspects of a global system (with PKI aspects) that need to be documented.

Steve


Here are my ideas about "strict" behaviour of th= e TLS client:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
TLS clients supporting CT are supposed to have a preconfigured set of logs and
their public keys.

In addition to normal validation of the certificate and its chain, they should
validate the SCTs received during the TLS connection.

The client fully conforming to the specification SHOULD perform the following
steps before establishing the connection for every certificate in the chain:

1. If no SCTs are provided, the client SHOULD reject the connection.

2. The client MUST ignore all the SCTs provided by unknown logs.

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

4. If no SCTs has left after steps 2-3, the client SHOULD reject the connection.

5. If any of SCTs left after steps 2-3 has invalid signature, the client SHOULD reject the connection.

Client MAY check whether the certificate is present in the log corresponding to the passed SCT.
If the certificate is not present in the log, the connection MUST be rejected.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=C2=A0

Can it be a starting point or you want something else?

--
SY, Dmitry Belyavsky 


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


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




--
SY, Dmitry Belyavsky

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




--
Certific= ate Transparency is hiring! Let me know if you're interested.
--047d7bacbedc706d0804fa73e19c-- From nobody Wed May 28 04:16:44 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD871A0084 for ; Wed, 28 May 2014 04:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYJT8JLb-DUR for ; Wed, 28 May 2014 04:16:39 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B4A1A0080 for ; Wed, 28 May 2014 04:16:38 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ij19so12122724vcb.14 for ; Wed, 28 May 2014 04:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0OyO1YMz9bM2VS7WjWzY0AdSVuKvwTNyTWhJYl3Tvzc=; b=o5rjN+1OvgUm7UbbCN+YdX5bZ5qDUMyH28qIxLdsMJi2czFKAN+xoVl7kwjLYeMFrq HQWKAAWXJRZefSXAyTI0xIUqO0xhz6CTQ4IwiUMHtj/2qBZc1zE2w5d2zHYxbSjrdi63 MHG7Fvv/G9ZoQ6uBhNfjw8eCLgsHRVG2u4bABSoS8NQdbfMRSgXpTQEV2jO5o0n9TQhY tD7KryAfqGzq4jH5+ba2to/Dn8tqhaQKdWMWwjtDvYdXoukNv5yvPA1NxqMBlXqRs8yE N3GNRC8Rhx1vXUJm23xLksU7aGdqE0YyNKAdXIW/WEEzmPTKtwOpA4L2dEQ6cWvE20kk bZXQ== 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=0OyO1YMz9bM2VS7WjWzY0AdSVuKvwTNyTWhJYl3Tvzc=; b=IypIeGB4+6660aJhXWvpMQ7V5VRHhsc6hcClYCyyls8J1SfbE0c5fTE3sNI79eQrdl lvIMo484O7rsGQkA3csKStUueVxKg9dXh59yMY/dYF9GV5V/B5Uf249gdXVGHJ/qQUul 3j0hNO2CXXQqUzNJ+2/yosG7P9PSxXiO5Iw0PD8GwZzLXhmh+UsGnblZ+6A/R9gmCi8F aCVj2r3Rt+1wTOEwCugVu8wP7De1KJfId/7Pmis+NHaOBnfWbM3pVVpUawMQ33i+pb1d HsC3wRpwceFUX+BuJEvbdfYCjvw2ty1F8xfOn0U2yDF6keLf+0tKgd8qJToNmsqyHEwp Ufkw== X-Gm-Message-State: ALoCoQlOlTtp91PCHG/bZWz10MxNXZiNpKJjrttLIZqQeyyT4FRfLIMLMC0q5EQIKJu8qMZDEpHz MIME-Version: 1.0 X-Received: by 10.52.138.14 with SMTP id qm14mr797199vdb.49.1401275794758; Wed, 28 May 2014 04:16:34 -0700 (PDT) Received: by 10.52.107.132 with HTTP; Wed, 28 May 2014 04:16:34 -0700 (PDT) In-Reply-To: <763539E260C37C46A0D6B340B5434C3B09854BEA@AEX06.ejsarea.net> References: <5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> <763539E260C37C46A0D6B340B5434C3B09854BEA@AEX06.ejsarea.net> Date: Wed, 28 May 2014 12:16:34 +0100 Message-ID: From: Ben Laurie To: =?UTF-8?Q?Barreira_Iglesias=2C_I=C3=B1igo?= Content-Type: multipart/related; boundary=bcaec51b1daffae51e04fa73f153 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/vLcjqARWeeOGpq7sSNfVLmMltMU Cc: "trans@ietf.org" , Dmitry Belyavsky , Stephen Kent Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:16:41 -0000 --bcaec51b1daffae51e04fa73f153 Content-Type: multipart/alternative; boundary=bcaec51b1daffae51a04fa73f152 --bcaec51b1daffae51a04fa73f152 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27 May 2014 15:47, wrote: > Hi, > > > > I have some other questions > > - What if a CA can=C2=B4t belong or it=C2=B4s not accepted in an= y log > server? > I would assume that in the very worst case CAs could agree with each other to log in each other's servers. But I strongly suspect this is not going to be a problem. > - What if you need 3 logs for an EV and only get 2 for whatever > reasons? > Then you had better get a third. > - Who=C2=B4s managing that procedure to accept log servers? Goog= le? > For Chrome: yes, Google will. > Are they going to be registered/publicly available for CAs to choose? > Yes. > > > Regards > > > > > > *I=C3=B1igo Barreira* > Responsable del =C3=81rea t=C3=A9cnica > i-barreira@izenpe.net > > 945067705 > > > > [image: Descripci=C3=B3n: cid:image001.png@01CE3152.B4804EB0] > > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta > egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbid= ea > gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi > erantzuna. KONTUZ! > ATENCION! Este mensaje contiene informacion privilegiada o confidencial a > la que solo tiene derecho a acceder el destinatario. Si usted lo recibe p= or > error le agradeceriamos que no hiciera uso de la informacion y que se > pusiese en contacto con el remitente. > > > > *De:* Trans [mailto:trans-bounces@ietf.org] *En nombre de *Dmitry > Belyavsky > *Enviado el:* martes, 27 de mayo de 2014 16:33 > *Para:* Stephen Kent > *CC:* trans@ietf.org > *Asunto:* Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs > CT) > > > > Hello Stephen, > > Here is my understanding of the question you asked. > > Let Ben or Rob fix me if I'm wrong. > > > 1. Anybody is allowed to operate log. But there should be a procedure > (similar to CA/Browser forum) which is determined to register log as > =E2=80=9Cimportant=E2=80=9D (we need a better word). There should be not = many =E2=80=9Cimportant=E2=80=9D > log servers, I suppose =E2=80=94 otherwise we are to get the same problem= as we > have with many CAs. > > 2. Any log-server can select the list of acceptable CAs. I think that > =E2=80=9Cimportant logs=E2=80=9D should cover all the CAs supported by ma= jor browsers. > > 3. Any log server can select the algorithm of hash for Merkle Tree and > for its key signing the SCTs. > > 4. Each browser should provide an editable way of managing logs. By > default it should be a reasonable subset of =E2=80=9Cimportant=E2=80=9D l= ogs. > > 5. Each CA can be accepted by more than one log. > > 6. Browsers should > > a. allow user to accept the cert without CT providing warning about > absence of CT > > b. allow user to specify absence of log for this or that domain > (non-public suffix) > > c. allow user to a particular log for this or that domain and return > an error if there is no SCT for id provided by this log. > > d. there should be a procedure of report about log misbehaviour in > case of invalid log records > > 7. I think that warning is acceptable in case of an absence of SCTs, > but in case of cryptographic errors the error should be generated. > > > > > > On Thu, May 22, 2014 at 10:12 PM, Stephen Kent wrote: > > Dimitry, > > Thanks for posting the list below. > > I have become very concerned that the doc we're working on describes a > mechanism, > but we seem to lack a good description of the architectural context in > which CT > is supposed to work. The intro text for the I-D is not at all adequate fo= r > this. > Maybe the charter for this WG would have included the need to publish a > doc of > this sort if we had gone through the usual BoF process :-). > > I'd like to see a doc that addresses a number of points that are now > beginning to > be raised by several folks: > - who is expected to operate logs, does every log cover all CAs, is o= ne > log per CA (even if operated by someone else) adequate, how are users > supposed to > select logs (what the UI like?), etc. > - how are browsers expected to deal with missing SCTs, missing or > non-matching > log entries, (crypto) invalid log entries, etc. are browser actions > supposed to be > effect in real time or is this deferred activity model? > - hard fail vs. warnings for CT "exceptions?" > - how are browsers expected to deal with certs from CAs that are not > part of the Web PKI? > - what are the fallback plans if some number of the Web PKI CAs elect > to not > participate? > - same question for major browser vendors? > - what are the plans for alg aglity, for logs? > > CT is a system, not just a handful of mechanisms. It needs to be describe= d > that way. > > Although not perfect, I suggest the set of RFCs that describe the RPKI is > illustrative > of the many aspects of a global system (with PKI aspects) that need to be > documented. > > Steve > > > > > > Here are my ideas about "strict" behaviour of the TLS client: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > TLS clients supporting CT are supposed to have a preconfigured set of log= s > and > > their public keys. > > > > In addition to normal validation of the certificate and its chain, they > should > > validate the SCTs received during the TLS connection. > > > > The client fully conforming to the specification SHOULD perform the > following > > steps before establishing the connection for every certificate in the > chain: > > > > 1. If no SCTs are provided, the client SHOULD reject the connection. > > > > 2. The client MUST ignore all the SCTs provided by unknown logs. > > > > 3. TLS clients MUST reject SCTs whose timestamp is in the future. > > > > 4. If no SCTs has left after steps 2-3, the client SHOULD reject the > connection. > > > > 5. If any of SCTs left after steps 2-3 has invalid signature, the client > SHOULD reject the connection. > > > > Client MAY check whether the certificate is present in the log > corresponding to the passed SCT. > > If the certificate is not present in the log, the connection MUST be > rejected. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Can it be a starting point or you want something else? > > > > -- > SY, Dmitry Belyavsky > > > > _______________________________________________ > > 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 > > > > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --=20 Certificate Transparency is hiring! Let me know if you're interested. --bcaec51b1daffae51a04fa73f152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 27 May 2014 15:47, <i-barreira@izenpe.net> w= rote:

Hi,

=C2=A0

I have some other q= uestions

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 What if a CA can=C2=B4t belong or it=C2=B4s not accepted in= any log server?

I would assume that in the very worst case CA= s could agree with each other to log in each other's servers. But I str= ongly suspect this is not going to be a problem.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = What if you = need 3 logs for an EV and only get 2 for whatever reasons?

Then you had better get a third.
= =C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Who=C2=B4s managing that procedure to accept log servers? G= oogle?

For Chrome: yes, Google will.
<= p> Are they going to be registere= d/publicly available for CAs to choose?

Yes.
=C2=A0

=C2= =A0

Regards

=C2= =A0

=C2=A0

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

945067705

= =C2=A0

<= img border=3D"0" width=3D"585" height=3D"111" src=3D"cid:image001.png@01CF7= 9CB.556A8540" alt=3D"Descripci=C3=B3n: cid:image001.png@01CE3152.B4804EB0">=


ATENCION! Este mensaje contiene informacion= privilegiada o confidencial a la que solo tiene derecho a acceder el desti= natario. Si usted lo recibe por error le agradeceriamos que no hiciera uso = de la informacion y que se pusiese en contacto con el remitente.

=C2=A0

De: Tran= s [mailto:trans= -bounces@ietf.org] En nombre de Dmitry Belyavsky
Enviado el: martes, 27 de mayo de 2014 16:33
Para: Stephen= Kent
CC: tra= ns@ietf.org
Asunto: Re: [Trans] Volunteer opportunity! (was R= e: DNSSEC also needs CT)

=C2=A0

Hello Stephen,<= /u>

Here is my understanding of the = question you asked.

Let Ben or Rob fix me if I'm wrong.

<= span style=3D"font-size:11.5pt;font-family:"Arial","sans-ser= if";color:black">1.=C2=A0=C2=A0=C2=A0 Anybody is allowed to operate log. But there should be a procedure (si= milar to CA/Browser forum) which is determined to register log as =E2=80=9C= important=E2=80=9D (we need a better word). There should be not many =E2=80= =9Cimportant=E2=80=9D log servers, I suppose =E2=80=94 otherwise we are to = get the same problem as we have with many CAs.

2= .=C2=A0=C2=A0=C2=A0 = Any log-server can selec= t the list of acceptable CAs. I think that =E2=80=9Cimportant logs=E2=80=9D= should cover all the CAs supported by major browsers.=

3= .=C2=A0=C2=A0=C2=A0 = Any log server can selec= t the algorithm of hash for Merkle Tree and for its key signing the SCTs.

4= .=C2=A0=C2=A0=C2=A0 = Each browser should prov= ide an editable way of managing logs. By default it should be a reasonable = subset of =E2=80=9Cimportant=E2=80=9D logs.

5= .=C2=A0=C2=A0=C2=A0 = Each CA can be accepted = by more than one log.

6= .=C2=A0=C2=A0=C2=A0 = Browsers should

a= .=C2=A0=C2=A0=C2=A0 = allow user to accept the= cert without CT providing warning about absence of CT=

b= .=C2=A0=C2=A0=C2=A0 = allow user to specify ab= sence of log for this or that domain (non-public suffix)

c= .=C2=A0=C2=A0=C2=A0 = allow user to a particul= ar log for this or that domain and return an error if there is no SCT for i= d provided by this log.

d= .=C2=A0=C2=A0=C2=A0 = there should be a proced= ure of report about log misbehaviour in case of invalid log records<= u>

7= .=C2=A0=C2=A0=C2=A0 = I think that warning is = acceptable in case of an absence of SCTs, but in case of cryptographic erro= rs the error should be generated.

=C2=A0<= /p>

=C2=A0

On Thu,= May 22, 2014 at 10:12 PM, Stephen Kent <kent@bbn.com> wrote:

Dimitry,

Thanks for posting the list bel= ow.

I have become very concerned that the doc we're working on d= escribes a mechanism,
but we seem to lack a good description of the arch= itectural context in which CT
is supposed to work. The intro text for the I-D is not at all adequate for = this.
Maybe the charter for this WG would have included the need to publ= ish a doc of
this sort if we had gone through the usual BoF process :-).=

I'd like to see a doc that addresses a number of points that are no= w beginning to
be raised by several folks:
=C2=A0=C2=A0=C2=A0 - who i= s expected to operate logs, does every log cover all CAs, is one
log per= CA (even if operated by someone else) adequate, how are users supposed to<= br> select logs (what the UI like?), etc.
=C2=A0=C2=A0=C2=A0 - how are brows= ers expected to deal with missing SCTs, missing or non-matching
log entr= ies, (crypto) invalid log entries, etc. are browser actions supposed to be<= br>effect in real time or is this deferred activity model?
=C2=A0=C2=A0=C2=A0 - hard fail vs. warnings for CT "exceptions?"<= br>=C2=A0=C2=A0=C2=A0 - how are browsers expected to deal with certs from C= As that are not
part of the Web PKI?
=C2=A0=C2=A0=C2=A0 - what are th= e fallback plans if some number of the Web PKI CAs elect to not
participate?
=C2=A0=C2=A0=C2=A0 - same question for major browser vendor= s?
=C2=A0=C2=A0=C2=A0 - what are the plans for alg aglity, for logs?
=
CT is a system, not just a handful of mechanisms. It needs to be descri= bed that way.

Although not perfect, I suggest the set of RFCs that d= escribe the RPKI is illustrative
of the many aspects of a global system (with PKI aspects) that need to be d= ocumented.

Steve

=C2=A0

=C2=A0

He= re are my ideas about "strict" behaviour of the TLS client:

=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

TLS clients supporting CT are supposed t= o have a preconfigured set of logs and

their public keys.

=C2=A0

In addition to normal validation of the certificate and its cha= in, they should

validate the SCTs received during the TLS= connection.

=C2= =A0

The client fully conforming= to the specification SHOULD perform the following

steps before establishing the connection = for every certificate in the chain:

=C2=A0

1. If= no SCTs are provided, the client SHOULD reject the connection.

=C2=A0

2. The client MUST ignore all the SCTs provided by unknown= logs.

=C2=A0<= /u>

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

=C2=A0

4. If no SCTs has left= after steps 2-3, the client SHOULD reject the connection.

=C2=A0

5. If any of SCTs left after steps 2-3 has invalid signatu= re, the client SHOULD reject the connection.

=C2=A0

Client MAY check = whether the certificate is present in the log corresponding to the passed S= CT.

If the certificate i= s not present in the log, the connection MUST be rejected.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=C2=A0

=C2=A0

Can it be a starting point = or you want something else?

=C2=A0

--
SY, Dmitry Belyavsky

=C2=A0<= u>

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

=C2=A0


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




--
SY, Dmitry Belyavsky =


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




--
Certific= ate Transparency is hiring! Let me know if you're interested.
--bcaec51b1daffae51a04fa73f152-- --bcaec51b1daffae51e04fa73f153 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 98870aeb44af4f7c_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAkkAAABvCAIAAAB3iMNhAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAASlZJREFUeF7tXQd4HNXVndned7XqvViSZcm9yLiC7RgwNtWAA0looSUhBUJI QjUtTk8I+UO3DQSMjQEbN9yrbElWsXrvva2k7bNl5j9vV5ZFM8Je2RDe++z9dmfmvXlzZjVn7333 nssKgsB8/eZEF55h3AwjYRgMgH9442IYOcNgH17x3r8Lh0m/ZBftNRIoigZFg/6l0OcGfYp+jlNY JyNXfG2WYkfDbV5e6Lc7KlsGdxY1HK5rKWjocnJ2xmxj5DKG9zAMyzAiRvAwUilj5xi1gnFyjFTG eD2MyLfL42FkUobjGKWCcXCMjPaiaNDvBv1Loc8N+jwcHTsYDXqFPD0uaGZs3NWzkiZFG0PVCrFI dHa6+2puy2vo3phTtvFkZVePOUynzkgwZiYnxwWLtHIDy/JiMetyE8tPLmPdboEXWJYR5HLW6RQY lpVJsIXxeLFNUCpZh4NsFIsE2ouiQb8b9C+FPjfo8/Ar2QHWUb/d1tlrzaprruswt1sHNFrNbTPT blswaWpc2Fno7Wzc1tRvfetQ4Yu7i9Qa8YqpKddMTZmTFqeR4NcWbRQBigBFgCJAEbigCMB6OlLV vr2k7uPcSpPd8ZPFk++7dFZ8iPYLJ/Gl3La/ouFX/z3Y0Wv5xbJZP1g4aZzxi/tf0CujJ6MIUAQo AhSB7zwCzf3mV/YU/mdfXnhYyJ9XzrlmeurnIfkCbnN5mN9/tO+F3afunJ9+/2UzZyScze77zoNM AaAIUAQoAhSBi4BAcXP3K0fL1h48efe8SU/fssSokI2cxGe5DVGNd7+8fd3BvH/df9MDi9JZEidC G0WAIkARoAhQBL6JCKzPKb/31Y/vWjDt5TuuGDm/z4aaPLclZ93+ovd+e8vPF2VQYvsm3kk6J4oA RYAiQBE4jcAds9M/eODGd46XP78950u5bX9l4592ZP3nZ9etmj6eQkcRoAhQBCgCFIFvPgJXT0v+ /fK5j288sKe6eXi2Z+y2xr7BX7y2Y2VG3I/npX3zL4bOkCJAEaAIUAQoAn4EfnXljGvSU+7524eN Xf3+LUPcxvP8S3tOdbvFD96wUCYVU7woAhQBigBFgCLwbUFAJZf8+a6lvEL63NYTbg/iRk5zW3Zt x2t78x5dMWPaWbPhvi3XSedJEaAIUAQoAt8pBMaH65+6Yd4bh/Nz63uGuM3DCxvza0KD1DdmUm/k d+rLQC+WIkARoAj87yDwo4WTJsdE/emT40Pc1mNzfpBbsWxmcqyBJmj/79xmeiUUAYoAReA7hYCc FX9/Yfq2E5Vmp4ustxW29pp6rCumJo8WBbeHqalg6uuZ+hqmvo6pryVvqqtH250eRxGgCFAEKAIU gTFA4ObMCQwv7K5oIbnbD75zcEt+TcUff6yQjSKKZNDiWvM009PA8HJGyjMeXxYchnF65NNmMA/+ zqf9TxtFgCJAEaAIfLMQQP2cxh6ryW4XeN7LeyVSqZtzyRRyvOK91+th0RiRb5fk07u8vl2sl/ec Wy+xRCpnhHC9IVwvH2tN4omPvj4jJZJw28yn3o4O02z92fWjuQ+ubR/ya551qFVKGSO4Ga8YEv+M FJUAxAzXO6h77Q12yuzhcewe3mrj7Dy/v7xOyogUMklUsGFKbOjewpp+jnN7RIvS4iQ8o9LKInVK zu1tNNkTQpQnqjpru3qlUtHl0yZEqqVHG1qrG828IATrFAvSIkM1qtHMkx5DEaAIUAQoAn4EPsiv eS+7orStx+L0eJwO1NcUJAzr4XiJVOQWC1Iv6/EIYjzTWVZwCWKW9Uh5qSByOQWpgvWwgtiNYpys IBHE596LlcnlUqlep8pMCnvkiktTojRjdHd++c6+A5WNxCdZ2TEwOzpqlKeRoU6bRKLQGRhWyar1 YolaItcwSi0jUko1WqbPPnKcqq7+LUW1LsGjlqvUWvmJ2u5nP86q7jOvz6mWyFWMSGRUqd4rrLzp Xx+jV7+DeyentKDR9H5upc3NdNtdN/xrA7a/erC022pXaFivIEjB/bRRBCgCFAGKwOgQQIHNm1/e fuOfN2w+VlzZ0tPW2dPlcHV53N2Dli6X0MN5ujxcd7+1y8t0u9zdNmuX3d3N8V1eV0/fYBcv6na6 ujhHt8XR7eLPq5db6OwdbDLbMInXd5Ze8vjrj24/6hJIsH7AW2ZCbGOfU4Qq2TbOEWL8ijpvw6fn nC4YaazT4ZXxTpeTFcMp6ea8Lnxk3S5G/SmHpEQQBm12NSv6/szklZNTiuo6V1+7kPe6p40LvT0z 5f5LM0L1Up1CUd7S2tFnlqGwm8DwIiEyXHPdrJTfXD7zkrio9cfKgsTiX62Y+aPM9JtmJRvko/Ca BhwqOiBFgCJAEfgWInCkplV9+5r39+SSpSIlnIJeUhoajIKa0goF4/UyYjGD5zacYR5YZnDBiRmx r2asy8XoNAznYsSgBvSCUcGTctPn3MvjZfQaxolhlYzcY/I417y2O+P3r1WbLAHHNTRE7bDbRaR4 6IA5wmAc5QnkSgUpP6pQil3wMcoFrxh4yMUyfBRQ99v22WHkKFQqIoT0QXGNSMrMSQzlHF67xc3x /IAdxMqIJbKfXj3rxSNFGplUIfASN8/yEouD7OowWydE6txyRVNXv83psnFueCZHOU96GEWAIkAR +C4jsD6natFj77i8DBNsYFRKQlRgJgmWkWCdiAhpKRWM3UF24ZkOhyQITyIl5OfmUGyaQIcDnHgf oF42B6PGuUSMBIMLTJC2tqpt2u9eKu40BfY2GZUK1MMGP+M6FU7XaG1DF7lUhsMrCSRx8WLg4WG8 bkYiuMD/n44jwSe32836DM8/vJ/9n3uW4o3g5neeqrl37Z6fvHugvt86YLX+aNbktgFHSYtJLpcw SqGso2vdkVP3vLkjMSRo9rjY9o6uhzYee+DNQy/sLTT56JA2igBFgCJAETgLAltO1f7m9S08lpDA ZLDPQGyw2ziOQZS7CKaYwMCQwmMcZANDAgfgQS6W4nlNLDZYaTiM58eyl4SYiXqVvdN+2ZP/bekP pPXGC5yE2J5ShpG4Ry+zJZFJGSejkEkFD+sVS8U8iyARr0gCY1culjCiT9lV+CCTyvRa1eotWdfO Sk01BuFm8DLm6ksy3rz7yg13X5UUpOFcLjfPPLZs7t/25Mrwk4EXJ+h1105Pe+GHl6+56VIcL1fK X7/jynX3Xf7oiswQ3AnaKAIUAYoAReDLETjZ0v3wO/t6BznGoGBgMLjceBDDiGHgQoOlAW6TSAif +W04qZTwHLb4Q9xJpCTLSC9IL5w9XNff27v87+8H9H6S6EYRXKm4YO9ozTaGd3KCl/C8AHcm70Xo DOhXEMhH8qNACwTPNOyQidiS1p681t4nVwzFT3o8vFjkHj4Isah9DmdqhEYiEo5XNklYiUohjwnS qfAjwtc8do9aRZfZAnrr6WAUAYrA/ygCHoH/KLesrrEDJgiDStMeD7HY8AqbDOQFryN57yFsBwbA Rthn8ECC3rARy29gPmy8YL1gJmpVJSdrcxo6AndDwNt+PUmXMPqUNMmM6bKISM4+yFo5iZPz2hwe h13sdLEDNiEhgUn6lGqXVCLVKqRbT1bwHuHVrOK/78t783jloM2JcJ0XDxT+ZfdJBFIGBSlEWPNj mFvmT7HbPSqpWAnQQZmnm1ot++OO4y/uK1qfVdpt+dyCXuDwoCNRBCgCFIFvOwLtfZaDBc2MSMZI fL7HoYWizz/jTxfo/OKnv3/rhekF/57qiQ/3Bw55Mm3W7uZVN67+4Kkf3jAtZbRDnyrgOmolXgWA E8QkukOEYEmsTCYmiiZMHAmG3eUZdHD9VnuP2Sng14DHo1bK4oO0DT2DLp73ePn0qFCs2ukVKr1S xnn5mnZTYri+x+oI16mUsJF9rbitu3PQLhZEMoVoSnSoTkHTAEZ7o+hxFAGKwHcNgQM1LUueeZf4 HhHxCH8jzDL4JPEGj2hYZtiO9+A8/8IbHrMw0eC4gxMS3ki8R7vwvewusUzW8OIvYvUBeLznNnXP Xb2etTt51e3Pb/r1qptmjZrbvmtfFnq9FAGKAEXg24CAIPB/3JX76Kt7GQNYTSAeSDgYsa4GJoOL EhElWHLDchoYDvGK8EPCVEAsCYiN5ANIGCwzwVrx+y0RhcG5P9sLrj6/uxJhfYQCfb1IUgE/dC7/ Qh05l5twJzkXsr6RKfa5XsPnwgxxrj7zusduvyMzADSU29Q2b/U7IkbGMi6OEDltFAGKAEWAIvBt RsDh5suasHCFOHYZieZ3cYTYsIqGFTUHQtwhlAgCAxWxjMnB9FuZzh6G8zB9g0hzZvrNjMXOWJ2M aYAZsDAdVkaOyEHXmV5YvMJooENE8yM9gIwsYWx2ZsBKuvf1Mw4X09NPBuzuZ+wcM2hlzDYyFI7H BIZ7gV+RKgfWOTNDCSOTnKhuDQj2LBLoiE/SxqtuXfPeozeuykwNyLh0EIoARYAiQBG4KAggEfiq v27MLqkn6djgMHAPgjXAQ4RXENmPXGwpY7YyCuk1C6atSI9PDg0TWAQxIP4c2WD+kD3E+kmru3r3 VzVt3JFLtqkUQ8YZLDB0B1/6B0RgRG9/9ITEe+ZNzEwOV0hUAtHyQgbb0IAsK7E57SebetceLGqt qmUiw0nWAfoi6hDjsKBYDHh6hmbrtUtmbrlv+fnjltvUMnf1BtbOC6obHt+y+vZrpwTAGDz/adER KAIUAYoAReDcEBh0uK7/50cHT1YzOoRB+kL54Q+02gnVgZncSHTj5s9M2Xz/1eEa9VefQmCu/dtH H2efIj5GJfhPIA5MGFtwNrrcRqVk3S+vuyZ9VAVk/rQv/3drd/kSw92ELP0hmohV8c/QZmO8yitn x+166OavntVXHZHb1Dd39VoRwwlIO4cbdowaLsFFAjLPqxEcvDzPC17fv/Maa3Sd/WdEbXIEvIyu xzf3KDvngRTnyPmRpEy42mmjCFAE/rcQwHqbC6oiImRnnU7QBhuB2KA/gnUyzrny0qnbf75yVMQG ZFhm68PXP7zqMkKKMLnAE/60bs4drpbnP3fvKIkNI/32ezN2PvEDpt9JolcwFAYBpflTyDFDtZoR rJCwCtDdcPIMghex0uZ0gzvHotncnl0VzRtO1mwsqG7sM5/9FOCsL+OtTgf3fn7duyfK3swuP9nU 5/J+Nb15BOFYXY/5rE9wkGV1d38XXMyfa302bkd5y5bCxnePVxyu6RwLcL5yzD6rM6+ho7C5K7+x s23AimRBdLFy7n44xL+q2d0eCxzlvrajuHnXqfrhHg09ls25de+frPmgtMHs9EDJ7GjDWS8QIp9I YvyqM9L9FAGKwMVHAH5ARILwPkmt4QRt/PnCf2h3Th8X9ddVC/VYRRvROgZt3WZ754AdT8JOi717 0IbfviPbU9fMv3beJLJ+hkASf1q3zb7nydsSQnUjDxu0uzoG7N0Wu/+1a9BuR1DJiLZsQuKfHljG mJxDHk6sAp6ZITnuU0efF5TDudvM18jd/lpnrG437cipcjrcDa1997+15+x9TzWbaroGvvAY3ut1 OJx7ShqOV7WzrFc0Ivvty8Z0ssLRyqZPy6R89liRiN1Z3Fjc3P35QQQkpyNjQcVuKak9WHGGGL7W 5Z/nwV1m54Gq9uyGjr/tztmLUnss2z5ge2pb9sHytrOPbOFcL+4vOFRDFmb7nEKf0/pRbgXsc387 WNW0u7JWLhHvK2z61678+h77q3uLzjKgyeo8UX9x2P08AaTdKQLfOQTwS9QvqeHPxfYnaCOD2+2R KmT3L5mZYNQPY1LR3vvsjtx7Xt9x76u77n5t172vk3/3vbbzyQ+PFLee0XjUyKU3Zo6XoMwLFKRg /FlsC6amTI4MHh4HysDrskp/sW7f3a9+ct+ru+7BUK+Q10c2Hny/oBq/noePfGTprEmTEhkU2flM CjlhQcRKBuonNGqvMeLHnnzq+S2HV82flB51Zq6B+kK0DliR+Xb/ZZPnj49ds+Xoz5bOhKn0YW5N YUtvhE6tkon3V7TsKqmNC9GrxLKf/ndPTYfpsvT4xr6BD/KqBjh3Yojeny2nk0mnJ4T32byT40KW TojrHrRvzqssazdNjgn1er2Hq1uza9ttnKekpa+4tXd8hMHs4t84VCBiJZMiDQqp9HB12yflDRzn jTJowGcYEDbQ7uKmo9VtNZ29U2NCgvXqDdllBQ2dGTHhYt8Barl0QqQxTK0+UtH4k0XT4biu7eoP 16vbzJbOQWe/3XmsprW0rRf3YmtxHVSegzXKwubujwuq+51cfIiupd9W0tp9qKplamzYiYbOnPp2 EnDrZrYUVhe19iSGojyfpKyj/8O8ig6LQyWDNCe/rajmWE17lEGrhWvb10K1innJUbMSIvrM9ilx EVEGdZ/N9cax4vHhQVPjQs9yjwYcrvdzKsJ16imxYbnVHV1ms5uVTk4I1/pqz5Y0d6eGByN0aPq4 yDUfHF0+PaW4u/uq9IR3TlScau2JNGhw7QXNnTmN7Sdq26bFhX9UUPXXHTmzk6PNTuf2wvpTTZ2T 4sJpAdpA/Y3QcSgCAUTA6fZuOFHRDPVhSG2Rspo+kS24fAQmKcz47x8vQ7kV/+mK2nrufWnL24dL auo7qtpNNW0dVc291c3dla3dR8tqD5R1XDMzzaAasvDkEtGJqub23gFCQFbnYzctnZEU5h/H6Xb/ 7eOch97eV1TTikEqW/tqWtur2kzVrR0na9o/zq9XKWQzkyIkRMSSNJgmu3IrSdikv8CNf4bEOcmk xgbfOifj/NFoG7S9cahIRBLPBRSkO/8Bv2AEhVxa2Nzz5MfHb/i/j+5aPBNHHChv6rU5OI9n66l6 VGhDBrdepXrqg+MiCVYrxWqFvMVk+aCgTiWXbS2oyhrhDHS6vEj9hjWFQf59IE+ukFV3mtZlVZjd 3rezKixu70sHC9vNtl2ldbW91rYBW6IhKCJEufZEaVl7T259e7RRZ/bwWELzz3J3WeuWUw06tcKG 7wIrXpdVolaonYL373vyRl7Ga8cqEsODUyOC9pY17ipowK78ut7dJfUbcyoq2vvzm3v/vPukQa9c e6wMuwbsrgidNqe2s7LN9EFu6dvZJSFBpPje3z/JaewdDNEoe6xOvVLR3NMP2sD2pz/ICtFqTzZ0 bjpZbXF7QGlegX05q+wz/r8KMKiYjQsmC78JwZofzkjjEF901hauVV4+McmABVuGidBr2gfMYoHt s1pPd2Lz6rq2F9c+8eGRmxdmiNRSKS8ARqlE3GtxbC2pxWF/2HXSw/KNXeb1x4vDdBqNVCEXifvs HH4clHda3s6uGJOvCx2UIkAROE8EiBik72lOPH6++jV4ZIJIXK6kSKNmhHDw/+0vOVHfRXyMBi1j UJE1OY2MMagZgwYRGNUVtX/Zmzs8lzCtJj40iJiDWJ9QiqaMixjeVdza9+bxMgEx/VoZ1LOYIBWj 1TAgRZTI0ao4u/3/9uTWdw8MHz9zXIwvYRxZd5IzM0SMCfSxvkAG5dzgYH2aW0gE8IyVTxI/F3Ry 0ezYyO/PmJDV2Fbd278xrzqvsaugpePjkgqHy33FxPhIvWoXIlYZZl5y5KyEYIvFFqSQ/vCS9MtS YuFJ8y8yobFiVpCyuF9Hqto5QXTdtNSnr5u79lARFqUmxQVfOTEuRKO+NDUmOdxQ3WXKCNdNjw9F hdnSlj6T2dnYPRCr1y9Lj1XKyLoiCuVsPVV99fTolTPGTRsXU9LUtyWr4lR9W/uA88VD2cNYVnaa Kto6l8GCxiqXx9vvJBn7cPdZHA6pVHLZhLjp0eFqlfzGScmNbcSruSA5Jik0BHexpm+g085dnpqw fEI8AmAYr/TGmWkoFz4x1jg9LooXRB0D5u0FLcF62Y0zUzKTwnud9jidZnZCRJBacrCoAabtyPuZ 29gG1g/RDgU1sWLvSEerh/cWtfbtLmnsRaTviCaWoDA8+ZwWrbv3smk/XTwpKUjr3y8SC5Aua+q3 Ls8Y99PFU+wDVt7jMcglizPiUAk9v7bd6RvqhsnjV05LOV7eOTEmZPb46CijNjM+fHyckefdB6vq zu0bR3tRBCgCY4uAIOCZ4JP59eVTw1/kD+VjWZPL+UkpftM37ihs3Jhbvb+igezF2ptfi4QczJJX HA+m0auOFJ/5M5eKWZnSF9BIzC+JUXsm6KO139yA/DYilI9z4aHD+tLAfeclYvmi1g4TftYPX7VB haB/n8olSbMbMcPTKQiBwAclbsBtyN1mXGMUS+LkXLEG3ZyUyJsvSVs4Lur/duWzvOyni2f+etms N398NeS4fvPegT6HEI4gGQDGimRyKQgsNFiFjwmhIYMCB3Paf6kQZsbTWiqS9NmcCcFqCDUDRJ6V WLzexGAdUgr1CrlMxEvEknCtauOJmr8fLtGgBLpIesn42FVz0188lP/UtmN+zy/IY9BsnxZPSMuo kjf2D85MTrhr4aQ756cXPHbXMLK7SlumxAXPSAjHFjEnUfrKrqo1ChaVDTQajUwiEbGRGgM2aoOV +Pr8cW/W3qo6vUqOSeK8GfEx5FwCo1WwMfhlxDBvZVf8N6dEJVEaNZqipq65afHYGKLVqFn50er2 f+wpQd6IUacY+tnlm0froL2m154YHDz8VZIpZaSE63Bjmazy5o+Lapq6PhWqg+IK7Omgo3ijPiZY oyZC4KR5eNGcCQl3zJ10w4wkOArc+L0AB0X74D935bFSXieXOwUmLAhfXlau12CVzu3xSiS8WCp6 aV/p+3mVBq1OTKoX0kYRoAh84xDAX70MqWOCmNAG0fiHQwyp1iQHIK+0+drVb928eu0Nz6794ZqN 9XVtREAEaWqIfoROL0LPkNwNtRHyz4E/e9PpYDTy+BWLPHiWIaCx3wEvpA1xiKebAxyGHANkbaMj hkLyHDriPUbDeW1Eo9lNCloPNbHLF40y5Cw9PUO7nWHVqI4aIEBleGD6cgBUSm7EuQM0OhlGjB/5 HrdCSp7MB6pap8SFJ0UoecGVGKSXK8QbcstmxcXdPD0BhgsOcHi8bt7rcXlqGwfwMa+tOUIm9/lM fU0QcQ6R3emKVMuKajvhIjORSNTBUIm81+5wcW6bA1GWYthkfeaBZ7Zm/fPG+UsmJ3V2dOO3waUp 0W/8aOmxivbGASK1jCW34BDt4fIGl9tbUNcapVX0W7kYoy4p2NB1Opgzp6qlsrntmtMamzK5t7+f TDKnspGz2bycEwSJ1MBBX4yl1cFUtvSX1fU+tHRGmFFts7nABzZfqTmyjotPLndFZ9/JqpaV05LT EoNaBhxLp8e+l008mQW1La3dvXvLaq6YGL18crzV2o+YkeFbUNrcgV9BMxPOeACsNpz2zC2SsOL7 l0598dbvzYgJGXnjCPIItP2ir4qXd3k9nOK0291ud+CLmlfTdP2MlDkJEVavC6UbLD3kunANWDwG pKwgFHf0lHV2/3j2pJgg5GMG8DtCh6IIUAQChgBsAKeHY1iiy+Ez3XyEhOUJu1Mil4ZEaUPHhRkT w4JjDHHRoRGJhoT4yPAQfXx8eESCMTYyJDoyJCohOD4+VBVmiI8dWlEjjwKvN0ynDooKDUsKU0WF GKRnao0ZJLKI2IjQZCN6RYQZEmIjwxP18THhEeHG2PiQ0JRQY1Q4nvZnrlBGMpAYjy80f3iGKJoq 2OUB80k68Az15W5f//iWp8ckd7uhz7p6S3aDyQSv748WpP904USTy3P7S9s9Hs+9Syddlprw8zf3 hQYpTtX2PHT1PGQC/n7ToZfvuOpYQ8f6I4Xjw0NeuW2JjEhZk4Z8rJ1ljYgMWTQ+7p0TVf89WTbY 5zz+9K39LndeVduUhIiPSxquSI9DTOOs5KR+c899Gw4vTkq0elwTgoNq+00VnabbF2TcNmuCxFcE vN/tuevlHbDrkmJ0v7xsckWr+S+7822841dXzbt5UhwO+Ki4ds22Y9FaTb8NBeTY7Q+svH39ToSQ ZEQbZiXGKKXyjHBtfb+ta8Dxw9mpf9ya/7trZzyxLaegpjUyWJkOmhGYG6ZPSTDKkZX3l70nf3nF LCUj+iC/9rX9pWnRxi6bdcO9V72UVb6toCI5WJ8YGjw3OfL57cdTooJyansfW5G5LIOYdCab/cO8 2snREZnJZ75kO2vbXAP262Z+RaL9/oomsVR+WfIZUhz+bm0rqBHJJFdNTPRTaHWf45Oi8sVpyb98 d2daWEhbv+OBZVNPNQ88/L3JLQ772p35D14166H3DlyaluR1uT7Ir8yIi95fVH/42R+qAvZFDNgf Nh2IIvAdR2DQ6brhHx8dQO62b4WecUA9REaMpEHz9ZdO/fBn1110fGr6LKkP/AtuOlIE/NMzvHLO xF0P3nj+M0SeWObqtazdzqtu+cPGx26++VullUzUNb/tGpg+CdHdpY3Hazuevm7O+d9ROgJFgCLw HUdgwOZc/rdNx4uhuaUc0i8mdbSlcC5dOyd9SyCY4zwRruo1p937d1SyJhEufoXlQM8wt6l13up3 sd5GVpPGaL3tPFE4S/dvO7F5Be9fPjm5v6Jrb0nLorSosQOKjkwRoAh8hxAQsTKwBUQ54DvCijvC IH1BkoiVDNxq1nnBKcdaILgWkxzDGcpJ2To7x6t+9Oz7v7kFMXvnNWXa+WsisKWwpr7TOislfEEy 5baviR09nCJAEfgiBJBGffXfNx8rrEOgo281yxcAiXCSQfPVcyZ+fNpuwyL6J+VIR3KK5V7GJWGk WACDqD/CT7BKh6B0xup2hml0109J8p8Eays5TZ3VbYPY5fHwN89I1qqGCq01mayHq1pxIhHEQDwQ uvIP6CXvhwZEdU98RE6CFyrMNV29T711gLhJFSKSePclMzyf25vb1DF79dus3cWrbnpm85O3rpxO ue188KR9KQIUAYrARUZgwM5d+/fNRwprScoamMPjC2iE6TZoXjFn4rbT3Nbv4OY8v6GqspmwDgvf Hewc/MPB/qAPD+P0RCbEtP/zfv/1mJ3c3Wt3vL+3kJR/4xxF/3l48mn5iLdyq27/2yafor+/u28d X4BcpF/I0ReuibQEF9yP/txdMaNRkHQCEqH9pTM8Hxxzmzpnr37LH4c4Vrnb5zM/2pciQBGgCFAE vh4CJECQ/CepZiA2f7lthEwzipECHVqF3KCC5YQMARVRMIE5BjkkBHeQfGoJkfxnJSGqM8GQIhZW GawxKemiVJOc69NNDSUn+BiROixXkkFAXQocpiQH+0YTySW3Xj770TuueGTV8j/cd80vr188JFCL 5IFPzzBwsrW4HuQAIDNLLj5vpf6vh3/gjg5UPsRnZ9TQPQC54cDNk45EEaAIUATGHgEUAiC52/78 M5AFUaD3UZFnwHZG3gFRipemxJAoSn+pUhKjLxCbDDtgbnkh1e+869IJw9NFMhD0K3zyXTIoVTpH PBtTwg0TooNJZhuGwumQmo0z4r0IryLG6poYEf7E8kuev37+H1bO+f0VmbcunMxAXmqIaT81Q3HA Qq/9udtSVPseq9xtQHOqyXTfm7sf25w1DBMSqE81dfk/muzcw5uP/Pj1Hf6Pg07u8a0nHn4vq91E BKJAXD99d/997+xr7hvKqHJ5+A3ZtY29Q3nK339l97bCutxGIgtyFpbbUVy/Kb9mlKV2HG7vrzYf e+iDw797/1hVe//Zvox+O35EO1HX8WpWmcVFy8eM/d8wPQNFgCLwOQSQuy1B7jbqAMBmIsXSUIwU 615iRimt6+jrsp95ND1xzbxFs1OZ5rahlG0UzrbaSM410le7e5YszvzJkunDw3db7U3dZiypEepi +P0VZyRLIOr78PLZUqTQdQyQmt1IBkfWNjK4rRzTZZHo5Y+vnJsWZcRQPpUIpqC+mXAqaNJfd9s/ Q8yWyHAFpiE5HHaJL3ebV3DuMTGArHZ+Z3ntg1fM8Iq5B7ceIezl4H767t5txU3+i/jt1sPLp8fP TYn9wb8Jvb18sCgkSD0x0fjvA4X4BXD/mzsXp4y7Zcq4n67b5j8e6W5N3abWfvIDpM3haWzunD8l Lsao3FfU9Elh9ZcBkxEdMjHaKDmdrXx2/HaXVIdIRB/95NrV182PCzV82cH7SlvX5pRy/Kdsu1i9 JjM6yi9JTBtFgCJAEbjACMBqcyF3GzYTBB4RHkki7N3ESOK4botl04lTw/PRyGX7H/rRvx+/c2pG 3LSUuGlpUdPGx01LjZk6If7x+6/Z+ouroec+fHBxc2tRYxMxB8FJbsnmvKEHuP+AOxdM3vLrm5ct mTEtPWpaasK0CZF4nTEp5raVc7Ofvuum2WfsPxy87kAJI0iJQBdkt4Zn6LMShqJTzhsygeF8uiQK lmEdCqK8Ffh2orEpVK2JNwb98frF2SVEa1giEUfodUoI3zMMZOb1jHJGZOSPL53c63U299p6zI67 Z6TeOC1ZJBV3DFp7+l0LJkcumJiogWv4dAsOUpS2NePTh1lFV88bHySSmjjPa9mlGwpQIc5p8XBP bT/61pFyHABl5K1F9e/mVJocriijXiSwb+VU/WzDXovjS7WGEQ60s7Bp1ZzJ6G6EOpaULe80Pbbl KESTsQVG+Xs5Tc9tOV7bP1De1vWfT0rKWgax/bWjFc/sPGF2C0atMsKoPtna84+9eS8cKnphT37g MaUjUgQoAhSBL0GAFYsUUgXDQ1zflwMA7Qssm8Eg06o9Ds8/9xU195wR50O0x88WTip8+q6C5+4o ePaegmfvLHjux4XP3PnsdXNRDGT4DD0253+zqiAcxSgV4EgmXF1wtKC0zTJyCldNSdr50HUFz95b 8OxtBc/eV/Dc7Xmr737zx8v8moXD7d9ZlbmFZUyYdsiBOTxDqHOxGmfANLeUYDWf3aZQYsJj0SCN D5FHqU9bxCBTW5yCWipZNStFpSSKkU19VqNRKfaZU4la9e6KZhkr1qgVKBkDkSeocjyz6pLbXtq2 4oUPf79i8fD0UkNDyhsGcONQO+bWSybuLGk8XtaSFhUUHSxDZdnfbjoyPiTkUFX9uydLUWTvF2s/ jtAr86tb3jl8qtpkgT94UXLcz9bvHB4N0lkuLz9clhrDtlndoQZ5vcla2NaHwzrN9kVpSeuPlByu 6vmkquW93MIFE+PtVhfczvHBsjCNYv3xytKWrkiN9jfv7D5R077+0CnBI6TGhH6SV7fuRNVYoErH pAhQBCgCX4iA4OWdI+tuo142xCE1auJp1Cjr61p/+Oq2yk7yZBtlQ5XRx98/sOtICaNTE1sQdbdh CBrU0594JbtxaGlplEN9VFzz8zVvk3GcTiKX7K+77Z+hv+52wNbbHFjH8623OTjpUMmwUU5y1Ifx ZE3Pv2w46HXwWKjEOiUCaXyVexRysdynVUiGk0gFkdcnPEkaZEdQj62x17FkQvx1k1L+cyCbKHX6 2qVpUW4JW9lhNlmsiUatyytKjNDNT4tdlJxQ3tQXqpB/P3P82ntWvH6w3OkWvj9v6uK0eI1GIVap orTK6UnhvEwYgHzn6YYiaq8cLjpc2+U+XWtWLfe6Ge/RmuZfv71ve2Hd3ITwUIMqWCOqbOtJNKiN aqXI45kcGzY9KuLyjJSYEPWftp8I1ytMDqtepe60OhUqcWZ86IzIsIggzYnffX/USNEDKQIUAYrA eSPgz90mdbf9Va09ZFkLz1iSwe2GsOTRUzVL12zacLwCJbZtLvywR/AJeRzjDakBgDdkg2BzeWAb bCmtm/3cf1/ddpLRKocMQSSDIypSKkXFsTlPrPvte0fKOgcHHBycZHhAk9GIGrtvKDIOKIzvtzlR pvK2V3fc8NibDFZ51Kqhutv+mEz/DH3tU6VMzgMJ5KvjiuD0JGLRYxQnGaxTOTxO6GxinlY7q/f5 bz1uVGEg3Bam1nSYYYqSjbUd3QuSovs5j8XjtnAeXHKjyfb2gbJHrph13+JJTq+wq6Jx+GIzonX/ 3nti9rgEbBEkgsvjdjggR4xCbB5BKuNZFuVoZLwgJfn5ZHSxIChFzFtZpRuPl6cHh8AsHB5KBA+y 282jPoCPOsHCkUFQTLbdPjv9uqkpvQ7nkx8ebWzrSYkIt7tsGVHGJ5bP2lXcuO5oCQro+O4jvi3S XyyZ8esrMv9884IYg9IliEyc9w87cm+dk6yE1DNtFAGKAEXggiGAGjd43qIOFlazYCIgWAMPW7zH PwToI4RSpWzt6r31Xx+u+OvmhzYdeGZH9l925qzZnfeH7Tlrtp9csyt3za6Tz+/I+fWmQzf8bfP1 T73diLg/NQwqX3UbPDgRIQmOVMoJ1THCnzfuWfj8unvX7nlm6/E1u/P/gKH25K/Znr1me94fduX8 cVfe0x8cv+eNXQueWff2zhNMmGFoViBT1MTB9IZniDfETRmYBmMQQ/nrbh9ctWBy+oga4YE5A577 MkVBU9egw721sDbJYFiUQcq+NPcPNvcMzk2ODter9lQ1upzuwgYUlHbfsSCjrMt0sr6ztLVDJZEt nTAuq75VKRHVdfVXtffdNDfNIB9aaxTEkl9tOvLUtZfEG7WlTQMyiRixMCjDPT8t8Uhlq0xgNmSX XzI+ZlxU8JHKpmWTk04196JYTk1377hwQ1JYyMuHTt42b6rMZ0SGaVWoKJ0UpveX20Z9GTfL7Cys cXj4HWX1UTptR99gZkrk4fI2u5uZGhfW1G+WyST9DrdRr0SJ0Zmx4TaPs8XE4UtT3zsIi6/XbCtq 62wdsE+LC2vrs0WjHM8YFX4N1E2i41AEKAL/Kwig1jIqJzd1jKi7jUsDvWHpByH+/sI3kClh+Y62 /vyatsMVzfvyqw8U1B8srT1QWn8wv/ZgYe3B8sb80oaWHgsKdJGD/b0wgr/AGx6VMAqJfcKC5BwW Z3l925HShgPF9QdP1R7Iqz9YXHOgouFgXu2BU3VHK+sqmjodoC4s+yEV4cxQECXxjeCPniQEzKbE GgNUd9uOuts+bvvgMLhtwhhwm0YukQni4yRGn31gyVSlL4AQV6FVKeONGtBJUoguu767y2x/6MoZ KDwdE6Sp7BgURMKKKUmJodowgyq3uqPTbr9mRuqkiDM1XLDKBSfm92eOE6NcjUQcqlPrldKmXvPM hLCYIFVBY69CJdw3fwpuJYqtpUQYvIIoyqhbkBJV0ABD3B1u0MSG6ELIIF/Q4oy6um5Lh8mCVdAr 0uOD9JqSzr4pMSFQpEHh2kNlLbC1l00ZNyEyqLS9M0itXTlj/N5TzR0WS5RelxCq0ysUUrEINdwG 7Z66voH5ydH/K3819DooAhSBbzoCTo/3vRM+boMmFkjIH1cPhyRyzuD98xfjhg0HllIjU9sXcgJ7 juRZg2YgLywj1UpR2hRdNPJP9YI5CCej33+I1TI8XmFoYVj0QowJHJXohS1YkEP1NFgKGAEHY50J r8QsIQ7K070wFHIAxL5oSf8M5QxnT40Nv3VO+vlD3DZoe/VQEWt38qpVz216/Ps3jZmeJByPQWrF cMEwn1uWxO/4W5+NQ5FPvXJoxc/OeeBHVPsKZJO9FgeW54JHZMj7txMpzBEYACizg1NiAU8i6bY4 gkg4CuFRn9Q+yRTEXcbxA04Osi8oYsp5PMO1Oj8PpcsrWB2c8TT59docIWplv80VpJah0hsGCoKR TvIZHCKRVCuXWJ0eq5OLQDl238zwBbByTi8v4nh3xOl62ed/w+gIFAGKAEXg7AgQPcm/vX/sFPQk 1UNGEknNlpGcMz+TEesNWdg+loKDkRTL9hI+w7oMnpL4iF1EJSsQvUClpPr2aM71WcXL87nRuU3t s1f/1xdLwrgD5un8ohlF6lTDxIb9ON8wseFjsFo+TGz4qJJLhomN7NUqP09s/kFGNtwRg1ruT8gI 0yJ0fyhnwO8ORJlo//EGhVyjlINKz0JsOEwmZoeJDR9BbHgFsZFXjdxPbGh6pRLEhjcahWSI2Hwz w2R0SgWOp8R2Pl9Q2pciQBH4ugigsrEES1kIpCAE5lvDgkWFjGxYUXg8IjDeH7uBjcgtI0nTPvML lbJ9ESJnqnUHpBcMxNGey8GwKk/AcgBgEvpzt5VyCKbQRhGgCFAEKALfagQQm+jyuHyaW6frbuPh jjUzVN+G/QQRENCbP8wEFEjSuhmiNumnOiTwovlrYY/sBbfhBeglOGUBywHgfJpbyN12OHDttFEE KAIUAYrAtxqBM7nb/lUul4+34L9SKkScOzg0TARbjYQ4wmMn9qV120lQPnxNUOoi6WtYbxvRC0pa YD5IJ2ORyN8Ldt5Y9MIEGD5QWda4WqwoQiIaM1bCJB2LVtk5uCm3eltJ3TvHKrMbPpXoZ3MJdT02 x1mlF5Ez0WFzmuAIHtE8Xh7b/RvsLne/jesZcJGw10+3TgfXZMLC6tCRgiD0OFwNJnIoDjQ7Xd0O F+qvm5zYcEamBGH9/Xau1+myOhG/SdLgkLHRMmButTpIsgZZwBNMdkfbgGV4DmOBGx2TIkARoAic AwK+3G0nI/ISywySHP5Ua9CSzRERGfz3m+cnhgQRxyM8lk43Y7ER7X9oP+JZhyBvWHLogkxq8BzW 5/CoxAFwZvpTrYnsMhIAPIQOETwyaCHj+HvhgKFeThJMYR7RC9dAtLXcRBvF3wvPan8vWIrDMyRR l6JAWVgC4wAVix97ZvXzm/f9YNGUtIjgc4Dy7F26zdaD5W1vHC4OM+pDg6Tjgg3Dxxe39a7NKkiL CEI29BcOggXNP+zI33iiKKuibXpyvBaxN772jz0Fpe2+wEWR6JqXNufU9ZS39QVr5RF6zfA45W39 T3x05HB5bV2PZU5yFHzQW4vrX9iRl1XdHIxoxmDtC3sLP86rO1rf+sqB4nC1MjkiyN+33eFY/dHx /Iau9cdLK9oG5qfE5rf0rD9U/EFeRWOPeW5KdJ/d+caJ0tcOFNf2WifHhijHdKEy4PeDDkgRoAj8 TyPAeb3v51Y3QuRd7ltygpmFgA5ieykgUn+iormt34w1sPBgfTgCHYw6nYjR4FUqsvisA6nARgcH GY3qUJ0mCKF5MpkValhiiZgV9GqVXq0MD9FGRoSGaJQSVrBayDIetJkNKnmQVmM0kF4GvVonl8Jq 4WE4CXgRh6sVocGKUIM+SKPRKcRWuxupx0NZBERz6/QMBXlSjOEHczLO//60DXJvHDolfuzRp57f mrVyzsSMqMBzW6hWNT7a0G6x/X7ZjAnhwTB8sqpbId4RpVea7K7y9u4ZceF+bsMuiO6LRCLl6QjJ rcW1p2ra3rh7uVcie/VQ/tWTSQXY6u7BVw+cNCqV81KjwW3rDhZt/tl1i9JjRhIbDrvlpQ//dfvl d8ydtLuivs/mFouE7YW1z69csGr2hOggLUJL5qVEXTUlYWJEcKfZmpkcGQEZGF/TSaXLJyd9b0Kc ye5B6tv0BNxE0dVTUlbOHH/Huo9vWzjJKFfOGxe9KjNtY3ZFnFGD0c7/TtARKAIUAYpAQBCAt+md rNLmThNJr8ZjlVRx85L3DmeIUfPbKy8pa+zgnK5rZ46/anpqWrghOTrkj9fPnzQ+esuBEhEv+sHC CTfNnRhjUMcFGyclRfxgzrQu62Brc++4SOPjKy9bkhY3NdY4NSJ4bkL0nd+bcbKxs6+9JypI+9iq Sy9Li0kI0k6IDJ2ZGHHdnAytUlVUA21lFrJQ9yyZnhRqjDEaMsJDr5uXGmEIKiivJ15Q4of0Bc2T GcL5aZ0QG35LYHIABl89VIwTMAyHUt8BAfYLBnG4ebeHh4AW9r15smJHUf3ekvqdpU1yZIGJpOzp gEaIFL9xpLSwpXd4CN7J8D4pMKNcVtbSjjfwFubUdk6PjY4I1vs1QeBK3VhYuSG3qsdiH+7Y7eTE MmmcjrDOgtSklh5zTUdvuF53sqFzU245bPXhI7Nr24JVikkxZzLn/LvqekyNPb0Lx0fivQEF91jm YFXL1NhILebDMv02x1vZ5UkRxoQQw1ihRselCFAEKALngACK3CDKH88pv5IIAkMQ2e/LvEacf0ZC hFKu4FyejScqHn1rz7ObjsHAsrj5t6HNz3smRBtunT+lsq13Q1bprtLa1w8UuAT+sRsug3aVQa6a Fh9W1NDxyIajj7x38IF/b3FwnjsWTmTsHo1ckRxqzClvXLP5+F8/Ob763cOv7MlZNWc8HJsKiWjV 3Axeym7KrdxZUvVW7qnjZV1PXjdPq9OQqBY/vfln6GtfqmH/tXEgcfJDnDYmFW6GJkTG9sfiP7Pp UEyI3uly7Str8V/W8JzFLHtTZnJaxBm2WDIpQSRyv7jvZFZ9cxAWMxnmYEUjFkTnpMbZOZcfjWsz M7RiWWlbz9sniE6/vyERTQcvs68p4UD2egfc/MmG9n6b/VSr6e87h7T5uwat5W2mqfER/tLjZ5rA FLf0aVWyxFC9f+Oeypa3jhaj3JHvhwBjcbqrugYHOLdf5Zk2igBFgCLwTUHAFxVAJkOqWnsZ8nNc RFa2kFktSBFcQDQWeZ4bNCul4jW3Xf69ifF3vLR134lSOCohqaGUKVOiQn64cMrtcyb+ZGlm96Al v74bGcZilq/pGjhW1eC12wU4vjg+q645GDW7BbgrmdYecwWU5XmvlyfBmdnVbYNWm1Qk0kilSoUi WKm6MTP99rnTHlg8My5Eu6OkXuVXmBo5Q6LW7zM0A9R8DlmMJhf7tIvHppH0aaJlhTMoRdJ5KXGX jY/9yWWTOYRw8EM6yTgxlsQykyKj/enPvgapkd8tuyQ9KmTJxOQwJVlLK2zo+eRU7TvHimB0Q5oL W359xdSrJietmpnW3DvQT+qmkxahVvdZSWlTtD6HRyoWq8QiENX1M9Oeum7u5pyhMm913WaO9c5N /axuSL/VkV3dcmk6cYGi5Ta27z5V+5urLpkUHerfEmvUPXZVJqr0HK5qRWjJ2KBGR6UIUAQoAueA AHSKySPX14jko08lC2lt5BGPD2A6kFBcTNhzty7tHbDe9df3G8rq/OLFkDjusVn251a+uTV73bbD /91y/L3s0rKWbpAQj6wCAX42sJwvzFJJHG68XGDEPE8UmMVihJ9YOGbQzJjtYlakUcncgtsjCFDJ OFbZtHZ7zrqPj6/7OHv93uysqmabg6hHDk1veIZE4DlQpdb8dbchteJxk2y/MWq82GGD7eQlNo5S MjUmaElGItjb6+IEr0cqYRv7Lf0AhWFQKc2M6gwjWnywfkl6YlZZS2w44bb7Fk95dMWcmSkRc1Mi E/xGlY9ZOqwcFCaDTucx6BUis5NF0Ad2najtjA1BBQAdIlPcXg/E/lHqHNuxrHqwoi01MmiEbPLQ iQdcnFytmne67NDGo5W3LZycfnoxEoJbsEFVUjEv8tq8nE+KmTaKAEWAIvDNQIDkbkN5hCWZ2kgD gMUGYiPv4WZyG5Qq1isYDfq37l8xPzUa0d4rF8741R1X3LAkg5GzVV19iDS5aX76ghnjMqelz5ge 8+KtyxKjtAwrkYskGgUp6U1YkAiaCDoUKmMhRo+4SUdUkObBK+bevjzztuXzV10xY8Mvr23tQ+wl D5GU/Mb2KyYlXzM7bc701IkTYp68+XvXTkuzEocktKl82eL+GRIpL19geiCav+62+LHfPfX8+ydu mJeRER34WBLME4tktQPmOUlRKpk0WKP6887c7Jp2nUYRrFOignZmYtRrh8rsEnZCqP5v2wuRcTEu bChkEX3fOFH+0sEiKc89fcOl+KhTQhNEYXF71ChvHRcmEYn+ceDU2zlF7b3W++ZPhILJMCzzJ0Y9 ueHI7oqmlDDNnfMmxQZrW3ttbxwt3Zxf/fBVs5NCdb0Wx6HKhp8vnYFBRoKJXzyHyjtTQnXjwoYc kqjyUN3Ul93UdqS4dda4GIeHe/lI8SsHi4L1ypump2pPyzcH4o7QMSgCFAGKwHkhgJymt7NKWrpN PrFHFAQQ+7T2EdOPOH0xXF/1PSb8Lm8csBU19jldFkEkQY6Vzemt7uriXCwezr0WZ7ABQQZimVa+ 7Vjl+8eLvWJ2gBVKWzrqOk1OlEUjCeCKeou1rLWzvc8cGmLIiIs4VN9idjslrEStkRwoqV9/pNSF 0H+JtKSxs6bfFKRXgHP1Wump1r6X9ubaHXZCtyRJHDalb4bgNo7LiA37fmBiSfrXHiph7byguv7x LU/ffu2UlPMCdXSdYWjB9Tv6PIY+hx3u2i8bGy7BAY4LQorGF7UBDpEgZ3ZYOI7ITBKb/Gs32IAk DdDXD7GyuIQvTlz42gPTDhQBigBFIGAIIGf3+n98dPBkNWK+SYUvEnbOktwylCcluiQektmGH/T+ jOZhtxMIBmnaaMj15uAahNkD7X+BlAzFMfjJT6RJEJ8CfUhf3RyMAFpCDpxYOjk85OGb5v1nW042 oh9J4gGelUpGzDFyBTkYvXCu4ROR/G+kHeCRDulkeCZPz9BmY7zKKy+J3/XgTeePRW5T39zVa325 2yqlE8pbF6QReeivc6KzEBu5NSz7ZcSGvSOJDR9hY50bsaEvbvswmeHuUWL7OveQHksRoAhcIARO 5277lP5hGHl4X91tFYM0NX/Ktn/9CUGTkCOB8QTOA7EhSQB2HZFORvEUosJIDtNqhpS6QGz4SAb0 kmRwyHGB9hDfADr0cO22wfeyyluQ5a3zFR3FgCA2xPRD+gujkSe+lFGdPhf8pejlcAzV3R6eISYj WBUBW2/z192Ws1DSlMvowtEF+vLR01AEKAIUgTFCQCyRGBFhD28kaAYGFmgJDklYLghHgJ1EFJN9 phXcV4g19+tMgsnAW6SSM9bAsJzm7+WjQOz6fC+Si+ZjL/RSKHptzp0FUMswE+L098Kw4D//uUjF li8/1/AMwWq8oAWbBqKdrrvtxsllAVvFC8TM6BgUAYoARYAicA4IoFxarAEeP58gMsI0QFSkchvS en11t7G25q9r46+gDQaCFYVXHDxcC/vr9gIpkgoDiHw8j3ORyuDu1NAzwRbncO3DXfx1tyGRiZIz Y5i7fc5THHRyZpt/nYs2igBFgCJAEfhqBBRSySXjExnU3iLpSb4MbkTtI9GNlLc+XZ7tTNK0L/gA 1pW/xOhQDvW59fJlMZ/buVDzzOFFrdQFk2K++gpHdYTYp+tMEDiTZzaqjhfkoN2lTQdrIK9MnaUX BG56EooAReB/AoHMuPDk2HBiq4G0EIII3oLFBrMM3kWwF2wsYiT507qRhQ0lZV+NbKzMwZIjhbkR CXlhe2Eh0CnEx4VfmvTZbONzvSFYGPRzmxvFwL9xbUZc2JS4z6phBXCWPll/2igCFAGKwP8UAjEh mvmpsUPK/SQAxPekIwndvuiSM54wxFv4Fbn8G/0Z39joP/JC9mIYh+XhKzMDdxvI5MWPPfXU8xsP 3roYdQCMgRt6aKR9VS2QH8lv7DbZuWiD5qUjFSaHU6VQnGru7LPZLS7vidr2uq6BlIigN7KKtBIF 0qsPVzSnRpKZFHf0CQIfqVM/8Obhg9UNW0saY3XqYJ3q9azSF3bn67W6xGDNwcr2t44WbSlscri9 EyKD0HdLcdXLB4pYqRQyoChP8+qRitcP5aukssTT+WoYuY/jf/n2riNlnXqVPMaoWX+i7B978hAu Oikq2OJintxyZE9JU2lH95Ha9l2lzROjQjSI86GNIkARoAh8GxCQS8RYYdtW2ODhvIxCSvyECNZH RAnxPUKZBBabb+NwWjcuCiYdiezHAajWjdRn6PRfqF4IP3Fw8hD9x7+4IVDotpudrx06hZR1JEWL TLZAlYX71PSa+war2vu2FNTvLK5r6TXXNHR63WxxS+vOkrqcus6C2lYHLxyra0Sfl3YXn2xoqe42 t5jM/iFO1XXkljfjzZPXzbpsUnJeQxPkibfm1Tis3IPLL3l6y2Hs2llaVdPdd/v8tKO1TYNOx66i OruTf3TF/Gc2HcDeY5XdFW3dP14ydUthdWHjmepxv1q/Y8GEcb+/bta0pPBtxXV9Zvufb1y48ViZ yeo2WxzHqtpumTEhp7Jtaky4x+Eoae0PFOJ0HIoARYAicAEQuHJSys1zJ5HqaHD3+UMW/YH7IDZE LRIhR7gf4ZzER59bEmSGjGxSRG1E3e0L0AtZdAjX77P++cbFAYTF7XSLBEaEBHSpTD+I5IYxaOND DW0Wp0orqOSS/cXti2fFZSYH9dk5o0zBu4XWfm5eQkSITn2sqS0zOabVYms3mTNihmQbYUTzPsnj ML3qrQP5f73pCo1Mktvac7yhd/vxSrUv2FSpVC6fkgqLUCGSmm0ejUExe1x8agRURaJqBu0Hqmpq 2/q35tU5iL7LmZRtqUpz2yXjQzQKuYit6bCkhhrC9ZpFE6M/PFku14umRxvjItXJMUGZcRGhQSqR aGzKto4B2nRIigBFgCIABFQy8R9XLVo0P4PpMpMFNhhhJIONI5VIhypowzhDWpuCpHWjyhiW2URS X+j/iLrbCDkhxXHGoBep8e07F+zIrq67b7nsF1dOC+CN6+I4qRz5bQyTGmc4UdIWwKGHh5qSGNVm GpgdnSCTSrZUVq2YME7OSvPru8JD9Danq2XApFaIp0ZF/nNH/m2zx7tcfF5j+7SkqKHuyJdmHXh/ yyufXDktaUFypM3JoYbez5dOfOLGuTt/RQxYq82G9G2ILoN/3Iju4VgF0vWIb9mqRAKiTHzvorTn rp/32q2XT4sJhYiJX9rYbrcNz5BlUKSWdOnutSnVagF71AqvF3n5yD/kkPvh5b9WrvlYoEjHpAhQ BCgCXw+BCL38wEM3PXDHUsY8QNbebA6SduZE0rTPVhuZ1o062qSCtutTtbBh52HtDaq8hN4+l2qN ZPDz6YW0bkicICWO8f7nqVtfu3PZ17u2rzr6YH5jmtFIuG16dOSp7p6vOv5c9mskIq+Tjw/VRqmD OrqtIBHI/3ea7BFKmU6pUIvVKpl8TnrsgYKmS8ZHIWyTF0kHbM6/7MlFARo5L9ZLNGYH39RnWT4x rarLppTIJ0YHQ30/v7EH9bIxIa1Y6wanMV6ZCFrMLIovFFT3HqhsHXAwMQbVpWmJW0415TWYNkFG ze54L7fqT/tz0MugVj7/cV5tv7l1wDopMaKh25LT3FnRNbhyerzJ7ZGSEuxeidfndRazHmq3ncud p30oAhSBi4/AizctfOf3d4YrZYS9LDAVfKJZsORgM5E1Nl9aNzHp4LeUD6VaI8AQASYw6ZCChew3 EtkvJd3PvxeCFxGxSVTsSQDnlPTYw0/f/ZP5gbTY/IifaG5OiQ8Rr1692up2bjxQfsWM5Cj9mRIz gbotKo08NUxnVKvSEkLGhxlgZoUoFRNjQ8NQpDUmOFqvQh0CvU49MyHMYNSmBmsNKpmL45PDjBqd NCbMKIiZ7sHBwubOorbOEJ3q0tTYlkHbrqLqWXERyRFBvJjJiA4J0SrVcnVKuOFkTUu9ydRmGvzz LYsQABITpPYy3h2FtRkxwVOiQuwer4KRpEUal4xP2F9dn1/XnhIRPCchomvQ/HFB7T2XzYSGMu8R gvRqFMRRq6RJQahFKkoJN+pxP2ijCFAEKALfQgQmRQfftWhy7SCqXjK8y84hYBKx/ojydyPWH7qR UM9yMV5wHjK4kSfgk+kiq3Qc44WXEit2EH7E8TD1zq8XySXnJWIBK0hpUaEPLJ/z8h3LUk/XyAwg ribO++C6XfcvnYnMNqG2Z2DKU28/tWLmI1fNCeA5LvxQv99yZEVG0ryUQCUAXvgroGekCFAEKAJj gkBNjym7obeipat90AqigRdSIpK4vW6ZWObi3VIWviovbA+s7Xh53y7BLRPJXF63VCzBFpLRjQUg +LTOqZeIlUil3rSwsJQw3YK0pFDNWAWfr8sqveuFzQ0vP0S4DWURbn91R7NpYM8jt2oRM/qtbW9l l82MjUyPDnwyw7cWEjpxigBFgCLwHUJgyfPvWThX7jO3kfU2hUxy9+Kp1R3964+WfasxWDktNTXC 8K2+BDp5igBFgCJAETg3BDZmlx8ra37ixsvQfSgyfkFqzPLpKf/cm1PT/S1O51LLEf1xLuXZzg1H 2osiQBGgCFAEviEI9Frsf92StXR6yvfSiXbXEBMoJOL7Fk23DLrePHCKyhN/Q24VnQZFgCJAEaAI jBKB57edKG/vf/SaTKWvjs8ZK2decuTvbpjzwpGigpZvsek2ShToYRQBigBFgCLwP4PArpLmf+7M eeyWS+emDgkuf8qD99AVM5emR899dn2TmSRN00YRoAhQBCgCFIFvOAINXf33vfjBylkTH142e3iq n12devXOayeFG9MfeWFfdec3/Hro9CgCFAGKAEXgO47AyfreBX/dlJIUuf6nK0ZmIn+W20LUspPP 3rF8etrSX7+4evOxfkiQ0UYRoAhQBCgCFIFvGAJWzvP89uzMR/41JTzoowdv1KDo+IhG8tu+cMJ/ 3Z33u7X7p2ZE/uMHSzMTIuRiWiP0G3Zj6XQoAhQBisB3EgFopxyuaX1u0+FDpQ1Prlz05M3zSPTI p9uXchsO+6S06U9bj6H62vXTk6+ZPn52amRMkPY7iSS9aIoARYAiQBG4+Ah0Wux5DR1bsyveya2Z Gq57ctX3rpwc/4XTOhu3oYPF6V5/tGhDVml5tyVep5oyLnparCE5NjJMrlAoJR6PRyxCoRxi+4lE Iq/HI5FJ3ZxbKvPvkvh28SKR2OvxSmQSN+eSymS0F0WDfjfoXwp9btDn4WjYQSqTujh3l9lZ2dZT 0dZb2Nxd3d0/MVx/95Lp189KN6q+VEjrK7jNz4fQyy9s7Dla3ZTT0NljcXAOHjnSXqmb9/AsL2XI 4B7WzfIiiUjK826PiJfwEhGLQjEelCeHUBnP8x6RR8yLJSIx7UXRoN8N+pdCnxv0eThadvBC09kj 0cnFWrV0dmLM3KSIzNTomCDN2a3IUXGbfwivIPTbnLDknE6XVRAkDO9mWGKasSxexLzgFolkjIDg ExkPjWkWB8Ceg0UnZgU32ShwIjGq0dFeFA363aB/KfS5QZ+Ho2cHrUislktUcmmQWgm7aTS+0a/B baMZjh5DEaAIUAQoAhSBi44AVV+86LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+ C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQ BCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAE AowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG67 6LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiK AEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoA RSDACPw/jRlMVUNEDuMAAAAASUVORK5CYII= --bcaec51b1daffae51e04fa73f153-- From nobody Wed May 28 14:42:48 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2961A0272 for ; Wed, 28 May 2014 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 714QHec2cszq for ; Wed, 28 May 2014 14:42:44 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 EB3D51A0261 for ; Wed, 28 May 2014 14:42:43 -0700 (PDT) Received: (qmail 18866 invoked by uid 1000); 28 May 2014 21:42:38 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 28 May 2014 22:42:38 +0100 Message-ID: <5386584E.5040806@comodo.com> Date: Wed, 28 May 2014 22:42:38 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Nm_OIY8ZA7Qf1zf0n9NLOQqvQpY Subject: [Trans] Trac isn't well X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:42:46 -0000 Whilst closing http://trac.tools.ietf.org/wg/trans/trac/ticket/18 just now I saw the messages below. Does anybody know who we need to prod to fix it? Warning: Can't synchronise with repository "(default)" (The repository directory has changed, you should resynchronize the repository with: trac-admin $ENV repository resync '(default)'). Look in the Trac log for more information. Can't synchronise with repository "(default)" (The repository directory has changed, you should resynchronize the repository with: trac-admin $ENV repository resync '(default)'). Look in the Trac log for more information. The change has been saved, but an error occurred while sending notifications: {u'trans@ietf.org': (550, 'Sender verification failed'), u'rob.stradling@comodo.com': (550, 'Verification failed for \nUnknown user\nSender verification failed'), u'benl@google.com': (550, 'Sender verification failed')} -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed May 28 14:44:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31781A0261 for ; Wed, 28 May 2014 14:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzyxchqNJUrd for ; Wed, 28 May 2014 14:44:09 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2608D1A0272 for ; Wed, 28 May 2014 14:44:09 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so11886239pbb.33 for ; Wed, 28 May 2014 14:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ewp5x0GDIcFYFHhG9rjzGzvOi5CyZ2m1CSA6qDw5cuk=; b=XQD/aBsYx47RqV6xuOvzbZEOsA3QEJ2INFT6ECjRh2kgqdrLRP4YIDOY/hVlLkmGSY BpkvwmQ2jYH2ccznBnhJ1zYVHBEh7GcWV59My4kQvkDhFuW71fpUhYvnAYZDowhKTfoL d2n5UqVqlFImbD2XGG23hYP9aPnocDAQCOn2AFWZOOgGbKtDpciKcdcpao2OtNe+LYGj Zo2GY23d+xeiN3ELOb9cFDydaUFaNFmNJm0JG7nws0/CyQFlapvcAUWS9EkAfW7YjdBU 7LEb0Xn0L1Zplu8Whme3HrPzHjsATKOULhHmvxvihwstsIUBN5WRjfV8c5xFJpzwrRwG sCAw== X-Received: by 10.66.254.198 with SMTP id ak6mr3119354pad.156.1401313445597; Wed, 28 May 2014 14:44:05 -0700 (PDT) Received: from spandex.local (209-193-54-118-rb2.fai.dsl.dynamic.acsalaska.net. [209.193.54.118]) by mx.google.com with ESMTPSA id dz4sm49735492pab.47.2014.05.28.14.44.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 14:44:05 -0700 (PDT) Message-ID: <538658A3.3040206@gmail.com> Date: Wed, 28 May 2014 13:44:03 -0800 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: <5386584E.5040806@comodo.com> In-Reply-To: <5386584E.5040806@comodo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/VvN_adUDtlUxBGGnGTGBfTK2huM Subject: Re: [Trans] Trac isn't well X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:44:11 -0000 On 5/28/14 1:42 PM, Rob Stradling wrote: > Whilst closing http://trac.tools.ietf.org/wg/trans/trac/ticket/18 just > now I saw the messages below. Does anybody know who we need to prod to > fix it? > > Warning: > Can't synchronise with repository "(default)" (The repository directory > has changed, you should resynchronize the repository with: trac-admin > $ENV repository resync '(default)'). Look in the Trac log for more > information. > Can't synchronise with repository "(default)" (The repository directory > has changed, you should resynchronize the repository with: trac-admin > $ENV repository resync '(default)'). Look in the Trac log for more > information. > The change has been saved, but an error occurred while sending > notifications: {u'trans@ietf.org': (550, 'Sender verification failed'), > u'rob.stradling@comodo.com': (550, 'Verification failed for > \nUnknown user\nSender verification failed'), > u'benl@google.com': (550, 'Sender verification failed')} > I'll get after them. We've had a number of problems with IETF tools. Melinda From nobody Thu May 29 07:46:15 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBAF1A6F72 for ; Thu, 29 May 2014 07:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rlyo6vDWfQZ for ; Thu, 29 May 2014 07:46:12 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4887D1A0980 for ; Thu, 29 May 2014 07:46:03 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id ma3so490555pbc.10 for ; Thu, 29 May 2014 07:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ugzHDuIp49nkhikhklKz0XDlRxJp7a/cuRn3q+BA550=; b=f1IOR/M2iSi1AwoyAj1oku6+oy4XW1sB70Pzs75+aDRhDgLNke4iULeaE65Uak+8tC zCD7+3/be4kUuaZDRhJKNRg24gMtZCNOVTXcYgU24XrYQagNQsMHieaNQc8sxGI/E88S JWLJ8xX349P/FH3lb/tCQk/4E+CmAzSUAk0308wSdxke4au4//n91lGB8OY8AFkgtELv QKQLLvM0j9/zj3IJ0V5t08jRLxP5QSD97UCnaL7/EsBZj9IBNO6g4TJWnkWOXv/wZs5c 0XCywYTxcK3qHzHx3sR5sJpoDn8Yri25QWungLdNk5ahbqyogkdiD2xwAbb71fo8eTmJ aD1A== X-Received: by 10.68.193.193 with SMTP id hq1mr9202005pbc.107.1401374759437; Thu, 29 May 2014 07:45:59 -0700 (PDT) Received: from spandex.local (63-140-95-253.dynamic.dsl.acsalaska.net. [63.140.95.253]) by mx.google.com with ESMTPSA id nf5sm1587153pbc.77.2014.05.29.07.45.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 07:45:58 -0700 (PDT) Message-ID: <53874825.1000203@gmail.com> Date: Thu, 29 May 2014 06:45:57 -0800 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: Rob Stradling , "trans@ietf.org" References: <5386584E.5040806@comodo.com> In-Reply-To: <5386584E.5040806@comodo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hSk9lwMCUU4YGENDu_TFmCZgDcs Subject: Re: [Trans] Trac isn't well X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:46:13 -0000 On 5/28/14 1:42 PM, Rob Stradling wrote: > Whilst closing http://trac.tools.ietf.org/wg/trans/trac/ticket/18 just > now I saw the messages below. Does anybody know who we need to prod to > fix it? They've taken care of the resync. Let us know ASAP if there are further problems. Melinda From nobody Thu May 29 10:59:22 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C111A01B4 for ; Thu, 29 May 2014 10:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 Z8hRwiH093VL for ; Thu, 29 May 2014 10:59:18 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8DBD1A01A9 for ; Thu, 29 May 2014 10:59:17 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 040111C20D6 for ; Thu, 29 May 2014 19:59:13 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id DA4341FE00F3; Thu, 29 May 2014 19:59:12 +0200 (CEST) Date: Thu, 29 May 2014 19:59:12 +0200 From: Kurt Roeckx To: trans@ietf.org Message-ID: <20140529175912.GB15165@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/2bTZ5uvLievSUpgd4ZuSc_G9X9Q Subject: [Trans] Parsing existing logs entries. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:59:21 -0000 Hi, I've been tryint to parse the existing log file based on the description in RFC 6962. I'm using Google's pilot log as example. The RFC says that GET will give you: leaf_input: The base64-encoded MerkleTreeLeaf structure. extra_data: The base64-encoded unsigned data pertaining to the log entry. In the case of an X509ChainEntry, this is the "certificate_chain". In the case of a PrecertChainEntry, this is the whole "PrecertChainEntry". With MerkleTreeLeaf: struct { Version version; MerkleLeafType leaf_type; select (leaf_type) { case timestamped_entry: TimestampedEntry; } } MerkleTreeLeaf; Which uses the following types: enum { v1(0), (255) } Version; enum { timestamped_entry(0), (255) } MerkleLeafType; struct { uint64 timestamp; LogEntryType entry_type; select(entry_type) { case x509_entry: ASN.1Cert; case precert_entry: PreCert; } signed_entry; CtExtensions extensions; } TimestampedEntry; enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; opaque ASN.1Cert<1..2^24-1>; opaque CtExtensions<0..2^16-1>; So after base64 decoding things, and turning it to hex, I see: 0000000 00 00 00 00 01 3d a4 07 ab d0 00 00 00 05 09 30 0000020 82 05 05 30 82 03 ed a0 03 02 01 02 02 11 00 91 So my guess of parsing it is: MerkleTreeLeaf { version = 00 (v1) leaf_type = 00 (timestamped_entry) TimestampedEntry { timestamp = 00 00 01 3d a4 07 ab d0 (1364256598992, 2013-03-26 00:09:58.992) entry_type = 00 00 (x509_entry) ASN.1Cert = 00 05 09 30 82 05 05 30 [...] And I seem to have been gotton lost somewhere. That doesn't look like a valid X509 certificate, nor do I have any idea how long it is. If I had to guess "00 05 09" would be a length, and that might work since it's limited to 2^24-1 bytes, so let's just assume that's the case for now. Now let's try to look at the extra_data. That is: struct { ASN.1Cert leaf_certificate; ASN.1Cert certificate_chain<0..2^24-1>; } X509ChainEntry; And we have this hex data: 0000000 00 09 29 00 04 e9 30 82 04 e5 30 82 03 cd a0 03 0000020 02 01 02 02 10 07 6f 12 46 81 45 9c 28 d5 48 d6 So with what we learned from the previous attempt, it looks like we need to parse it like: certificate_chain { length = 00 09 29 (2345) ASN.1Cert { length = 00 04 e9 (1257) data = 30 82 04 e5 30 82 03 cd a0 03 [...] } ASN.1Cert { [...] I think the RFC needs some clarifications on how to parse things, so that I don't have to guess. This definition is also confusing: extra_data: The base64-encoded unsigned data pertaining to the log entry. In the case of an X509ChainEntry, this is the "certificate_chain". In the case of a PrecertChainEntry, this is the whole "PrecertChainEntry". So the X509ChainEntry is not used, you need to directly go to it's member certificate_chain. The LogEntry also isn't used anywhere. Kurt From nobody Thu May 29 13:18:51 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D4E1A09ED for ; Thu, 29 May 2014 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANc2fgtWOzXw for ; Thu, 29 May 2014 13:18:45 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 160291A06A4 for ; Thu, 29 May 2014 13:18:44 -0700 (PDT) Received: (qmail 16935 invoked by uid 1000); 29 May 2014 20:18:38 -0000 Received: from nigel.brad.office.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, 29 May 2014 21:18:38 +0100 Message-ID: <5387961D.1010503@comodo.com> Date: Thu, 29 May 2014 21:18:37 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kurt Roeckx , trans@ietf.org References: <20140529175912.GB15165@roeckx.be> In-Reply-To: <20140529175912.GB15165@roeckx.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/40j6PhAr7PkAdakTjb8P1sQfX0I Subject: Re: [Trans] Parsing existing logs entries. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:18:47 -0000 Kurt, RFC6962 says... "1.2. Data Structures Data structures are defined according to the conventions laid out in Section 4 of [RFC5246]." So you shouldn't have to guess. Just read RFC5246 Section 4. On 29/05/14 18:59, Kurt Roeckx wrote: > Hi, > > I've been tryint to parse the existing log file based on the > description in RFC 6962. I'm using Google's pilot log as example. > > The RFC says that GET will give you: > leaf_input: The base64-encoded MerkleTreeLeaf structure. > > extra_data: The base64-encoded unsigned data pertaining to the > log entry. In the case of an X509ChainEntry, this is the > "certificate_chain". In the case of a PrecertChainEntry, > this is the whole "PrecertChainEntry". > > With MerkleTreeLeaf: > struct { > Version version; > MerkleLeafType leaf_type; > select (leaf_type) { > case timestamped_entry: TimestampedEntry; > } > } MerkleTreeLeaf; > > Which uses the following types: > enum { v1(0), (255) } > Version; > > enum { timestamped_entry(0), (255) } > MerkleLeafType; > > struct { > uint64 timestamp; > LogEntryType entry_type; > select(entry_type) { > case x509_entry: ASN.1Cert; > case precert_entry: PreCert; > } signed_entry; > CtExtensions extensions; > } TimestampedEntry; > > enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; > > opaque ASN.1Cert<1..2^24-1>; > > opaque CtExtensions<0..2^16-1>; > > So after base64 decoding things, and turning it to hex, I see: > 0000000 00 00 00 00 01 3d a4 07 ab d0 00 00 00 05 09 30 > 0000020 82 05 05 30 82 03 ed a0 03 02 01 02 02 11 00 91 > > So my guess of parsing it is: > MerkleTreeLeaf { > version = 00 (v1) > leaf_type = 00 (timestamped_entry) > TimestampedEntry { > timestamp = 00 00 01 3d a4 07 ab d0 (1364256598992, 2013-03-26 00:09:58.992) > entry_type = 00 00 (x509_entry) > ASN.1Cert = 00 05 09 30 82 05 05 30 [...] > > And I seem to have been gotton lost somewhere. That doesn't look > like a valid X509 certificate, nor do I have any idea how long it > is. > > If I had to guess "00 05 09" would be a length, and that might > work since it's limited to 2^24-1 bytes, so let's just assume > that's the case for now. > > > Now let's try to look at the extra_data. That is: > struct { > ASN.1Cert leaf_certificate; > ASN.1Cert certificate_chain<0..2^24-1>; > } X509ChainEntry; > > And we have this hex data: > 0000000 00 09 29 00 04 e9 30 82 04 e5 30 82 03 cd a0 03 > 0000020 02 01 02 02 10 07 6f 12 46 81 45 9c 28 d5 48 d6 > > So with what we learned from the previous attempt, it looks like > we need to parse it like: > certificate_chain { > length = 00 09 29 (2345) > ASN.1Cert { > length = 00 04 e9 (1257) > data = 30 82 04 e5 30 82 03 cd a0 03 [...] } > ASN.1Cert { [...] > > I think the RFC needs some clarifications on how to parse things, > so that I don't have to guess. > > This definition is also confusing: > extra_data: The base64-encoded unsigned data pertaining to the > log entry. In the case of an X509ChainEntry, this is the > "certificate_chain". In the case of a PrecertChainEntry, > this is the whole "PrecertChainEntry". > > So the X509ChainEntry is not used, you need to directly go to it's > member certificate_chain. The LogEntry also isn't used anywhere. > > > > Kurt > > _______________________________________________ > 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 May 29 13:34:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DD61A0684 for ; Thu, 29 May 2014 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 wHpT4YCOmqI0 for ; Thu, 29 May 2014 13:34:09 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AB91A066D for ; Thu, 29 May 2014 13:34:09 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 791851C20D6; Thu, 29 May 2014 22:34:04 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 50DA81FE00F3; Thu, 29 May 2014 22:34:04 +0200 (CEST) Date: Thu, 29 May 2014 22:34:04 +0200 From: Kurt Roeckx To: Rob Stradling Message-ID: <20140529203404.GA20394@roeckx.be> References: <20140529175912.GB15165@roeckx.be> <5387961D.1010503@comodo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5387961D.1010503@comodo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/GvgljLM29fKc3YOIODfjVS6c0lk Cc: trans@ietf.org Subject: Re: [Trans] Parsing existing logs entries. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:34:11 -0000 On Thu, May 29, 2014 at 09:18:37PM +0100, Rob Stradling wrote: > Kurt, RFC6962 says... > > "1.2. Data Structures > > Data structures are defined according to the conventions laid out in > Section 4 of [RFC5246]." > > So you shouldn't have to guess. Just read RFC5246 Section 4. Thanks, I seems to have overlooked that section. Anyway, I really don't understand why this is such a mixture of josn and base64 encoded things. Why isn't this all just json with just the certificate in base64? Kurt From nobody Fri May 30 03:17:31 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E055F1A0893 for ; Fri, 30 May 2014 03:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMhhi-f-8bpY for ; Fri, 30 May 2014 03:17:28 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 B483D1A03E3 for ; Fri, 30 May 2014 03:17:26 -0700 (PDT) Received: (qmail 11261 invoked by uid 1000); 30 May 2014 10:17:20 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 30 May 2014 11:17:20 +0100 Message-ID: <53885AB0.6060107@comodo.com> Date: Fri, 30 May 2014 11:17:20 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kurt Roeckx References: <20140529175912.GB15165@roeckx.be> <5387961D.1010503@comodo.com> <20140529203404.GA20394@roeckx.be> In-Reply-To: <20140529203404.GA20394@roeckx.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/xpqfeQM2K36bHQOqyPxXugldDWY Cc: trans@ietf.org Subject: Re: [Trans] Parsing existing logs entries. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 10:17:30 -0000 On 29/05/14 21:34, Kurt Roeckx wrote: > On Thu, May 29, 2014 at 09:18:37PM +0100, Rob Stradling wrote: >> Kurt, RFC6962 says... >> >> "1.2. Data Structures >> >> Data structures are defined according to the conventions laid out in >> Section 4 of [RFC5246]." >> >> So you shouldn't have to guess. Just read RFC5246 Section 4. > > Thanks, I seems to have overlooked that section. > > Anyway, I really don't understand why this is such a mixture of > josn and base64 encoded things. Why isn't this all just json with > just the certificate in base64? Personal preference of the authors of RFC6962? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri May 30 03:19:05 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3C1A03F9 for ; Fri, 30 May 2014 03:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 NOonH_TUHub6 for ; Fri, 30 May 2014 03:19:03 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90AE1A03E3 for ; Fri, 30 May 2014 03:19:02 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hy4so1825064vcb.39 for ; Fri, 30 May 2014 03:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jl96ZLM6uJ8jalXHsSKW4Gioymz+c+w/e+UNgYXbdjk=; b=Llg98sBVTUr1io/dD5P+LqMTJt/xB96vNU4U/zetyynGHYat71fCwil4CFkSTQ3wXa +Fe8XyYIVQR91z941Wb4ZmmeZtBg1tDmYqFlhAR+8Z8WRAq2ewsOAKEztZBXQOjDOYDs eZREEdYV+H0PRM38HuG7noFVATmA3mbRo9Qe1qI3ceNyx10ow+C6GCrDigOUp+1lrHQh TG8TIqWbEg4l4iYo97d8HE3bahwZ5kQg7U+fR8Mn5d7bcL4gsgp2yK30F2LJa7itwBCw Q2LGubzcdmAScjo1+Vz0xHqSJ4GoeKfIfsDgB9fH5UcKgYSLHQwVx3Hln2uLyYlQ7vMw 9g5g== 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=Jl96ZLM6uJ8jalXHsSKW4Gioymz+c+w/e+UNgYXbdjk=; b=DEo1F597TwmMi4YHP7FFXBZpdtNiVGja/nePUhHZK7aySefZREVuKOT2ghmKMsa6HI 8hEuaMUd4GbY+XQsPy3w4F3Lm9wU1oMuXSNyRoZ7fxEWqMbMspN7MEH3Vd2KsRbQTPiJ l1ko6c63zHBWNT31ZF97inJ+ZWkdNqe+c9JQIpYOEKPuN3bxPxJpcKcgltf0IeCVsv09 jXtf0LVJ6TUCqnRkw7VGLQ8KLFCYA8Q4amFMGboPvgG93NRrZ/qjUksT3tbIYiorCuEP KEGw/AMY6TsnUAneP3jeqWyQa7H5SzeVkiAypml+6fu/aWCPFHX9biooQF7Co//EQGtG fhCQ== X-Gm-Message-State: ALoCoQn3CTxsbQ2G4tjSTrd/xeVpC1TIsopXTMbAVRB1//O4seqTBCB8MUmhScZ3t/Kw32YlrKSd MIME-Version: 1.0 X-Received: by 10.53.13.133 with SMTP id ey5mr10742656vdd.8.1401445138131; Fri, 30 May 2014 03:18:58 -0700 (PDT) Received: by 10.52.107.132 with HTTP; Fri, 30 May 2014 03:18:58 -0700 (PDT) In-Reply-To: <20140529203404.GA20394@roeckx.be> References: <20140529175912.GB15165@roeckx.be> <5387961D.1010503@comodo.com> <20140529203404.GA20394@roeckx.be> Date: Fri, 30 May 2014 11:18:58 +0100 Message-ID: From: Ben Laurie To: Kurt Roeckx Content-Type: multipart/alternative; boundary=001a1134cd1ea18d5204fa9b5f33 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_fTIHhAbie9WVzE4-cBntdaKBnw Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Parsing existing logs entries. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 10:19:04 -0000 --001a1134cd1ea18d5204fa9b5f33 Content-Type: text/plain; charset=UTF-8 On 29 May 2014 21:34, Kurt Roeckx wrote: > On Thu, May 29, 2014 at 09:18:37PM +0100, Rob Stradling wrote: > > Kurt, RFC6962 says... > > > > "1.2. Data Structures > > > > Data structures are defined according to the conventions laid out in > > Section 4 of [RFC5246]." > > > > So you shouldn't have to guess. Just read RFC5246 Section 4. > > Thanks, I seems to have overlooked that section. > > Anyway, I really don't understand why this is such a mixture of > josn and base64 encoded things. Why isn't this all just json with > just the certificate in base64? > This has come up before. The data appears in multiple contexts. Each of those contexts has an "obvious" encoding - namely, DER, TLS structure encoding and JSON. In general, we tried to pick the most natural encodings depending on the context the data is really "for". Possibly we didn't get it exactly right. I'm sure whatever we do, someone will be unhappy. -- Certificate Transparency is hiring! Let me know if you're interested. --001a1134cd1ea18d5204fa9b5f33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 29 May 2014 21:34, Kurt Roeckx <kurt@roeckx.be> wrot= e:
On Thu, May 29, 2014 at 09:18:37PM +0100, Rob Stradling wro= te:
> Kurt, RFC6962 says...
>
> "1.2. =C2=A0Data Structures
>
> =C2=A0 =C2=A0Data structures are defined according to the conventions = laid out in
> =C2=A0 =C2=A0Section 4 of [RFC5246]."
>
> So you shouldn't have to guess. =C2=A0Just read RFC5246 Section 4.=

Thanks, I seems to have overlooked that section.

Anyway, I really don't understand why this is such a mixture of
josn and base64 encoded things. =C2=A0Why isn't this all just json with=
just the certificate in base64?

This ha= s come up before. The data appears in multiple contexts. Each of those cont= exts has an "obvious" encoding - namely, DER, TLS structure encod= ing and JSON. In general, we tried to pick the most natural encodings depen= ding on the context the data is really "for". Possibly we didn= 9;t get it exactly right. I'm sure whatever we do, someone will be unha= ppy.
=C2=A0
--
Certificate Transparency is hiring! Let me kn= ow if you're interested.
--001a1134cd1ea18d5204fa9b5f33--