From nobody Mon Apr 3 12:45:10 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6A1129515; Mon, 3 Apr 2017 12:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14c1DmycaWMb; Mon, 3 Apr 2017 12:45:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1801294C3; Mon, 3 Apr 2017 12:45:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vxjHg4cHRzCvC; Mon, 3 Apr 2017 21:45:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491248703; bh=Tu0tHCk+qnP2VLTZep4I6cCNKs67wfa2G2aUOAXXkCM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HYj5CKjhcn/KnfPX6LoYq9SvyRivwYTBJgWk1q/xICsINN8FXkzBe0IN5tRtngRu9 FTB0J+24Jv8adHk3EEHOu6fUU2G+ueqkTxzwRHciTG4Bs+xkT1T+HluctT5mQinR3X 5XULvi+f4Th/3thU8s9ZBBONVDBGSEu9TuPoHwu4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Me1BQHzcV7ZS; Mon, 3 Apr 2017 21:45:01 +0200 (CEST) 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 mx.nohats.ca (Postfix) with ESMTPS; Mon, 3 Apr 2017 21:45:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 852C73943A4; Mon, 3 Apr 2017 15:44:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 852C73943A4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 60EC74000880; Mon, 3 Apr 2017 15:44:59 -0400 (EDT) Date: Mon, 3 Apr 2017 15:44:59 -0400 (EDT) From: Paul Wouters To: Viktor Dukhovni cc: trans@ietf.org, dane@ietf.org In-Reply-To: Message-ID: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 03 Apr 2017 19:45:09 -0000 On Wed, 29 Mar 2017, Viktor Dukhovni wrote: >> Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS? > > This is not needed, the NSEC/NSEC3 RRs already serve that role. > > For NSEC records (RFC4034), an unsigned delegation looks like: > > example.com. IN NS ns1.example.com. > example.com. IN NSEC examplf.com NS > example.com. IN RRSIG NSEC ... > > this proves that NS (or other depending on the content of the type > bitmap of the NSEC record) records exist for example.com, but DS > records do not. I don't think so? Because this is the parental NS RRset for the child, which the parent does not sign. The NSEC only covers the existance of the DS record, not of the glue records. And those glue records can still be maliciously pointing elsewhere. Or the zone cut can be temporarilly removed at the parent to sign the child's TLSA record directly. You really need to find the NSEC(3) record that proves the parent has no DS record for the child zone, and really have to find and submit the TLSA record and RRSIG. That way the logs can tell who signed the DS and/or TLSA record. Checking the child APEX is of no use because the parent might be overriding the delegation briefly. Eg remove the DS record and/or NS records, publish a childzone TLSA record as "without a zone cut", and then restoring the DS/NS chain again. The only way out I see is to log the TLSA records, so you know which key signed it. If this is done, we clearly need a ratelimit and/or some method of finding conflicting overlapping-in-time records. > With NSEC3 (rfc5155), and the "opt-out" bit the situation can be > more complex because the answer may not establish the existence of > example.com. Instead we may get an existence proof for the closest > encloser (ancestor domain) and proof that "example.com" is not signed, > but no proof of its existence. This means that to avoid spam, a log > might want to independently verify the existence of the insecure > delegation by repeating the query, so as to avoid storing data for > non-existent domains with the insecure NXDOMAIN modified to NOERROR > with made up NS records. Repeating the query is not a real solution, as the malicious parent could open a small time window for the attack and close it again. Clients really need to submit state their validation reached. This cannot include any unsigned state as that cannot be trusted itself, but should include the signatures proving the unsigned state. Paul From nobody Tue Apr 4 02:51:44 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6BF126DC2; Tue, 4 Apr 2017 02:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zj3PaK9Ty4V; Tue, 4 Apr 2017 02:51:33 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 80705128896; Tue, 4 Apr 2017 02:51:33 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59388) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cvL7X-000Z0o-80 (Exim 4.89) (return-path ); Tue, 04 Apr 2017 10:51:27 +0100 Date: Tue, 4 Apr 2017 10:51:27 +0100 From: Tony Finch To: Paul Wouters cc: Viktor Dukhovni , trans@ietf.org, dane@ietf.org In-Reply-To: Message-ID: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 04 Apr 2017 09:51:36 -0000 Paul Wouters wrote: > > Because this is the parental NS RRset for the child, which the parent > does not sign. Right. > The NSEC only covers the existance of the DS record, not of the glue > records. Not quite. A delegation NSEC record lists NS NSEC RRSIG and maybe DS, even though NS isn't signed. (You are right that glue records aren't in the NSEC chain, though.) > You really need to find the NSEC(3) record that proves the parent has > no DS record for the child zone, and really have to find and submit > the TLSA record and RRSIG. That way the logs can tell who signed the > DS and/or TLSA record. Yes. Should probably log the whole DS/DNSKEY/RRSIG chain. You don't need to log NSEC(3) unless you need to log a proof of nonexistence - maybe to prove lack of delegation points if there are intermediate labels? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fitzroy: Northerly veering northeasterly 4 or 5, increasing 5 to 7 in east. Rough or very rough. Drizzle. Moderate or good. From nobody Wed Apr 5 09:28:07 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C2129487 for ; Wed, 5 Apr 2017 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=office365stanford.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x0MteYYBnz9 for ; Wed, 5 Apr 2017 09:28:03 -0700 (PDT) Received: from mx0a-00000d04.pphosted.com (mx0a-00000d04.pphosted.com [148.163.149.245]) (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 67BF21286CA for ; Wed, 5 Apr 2017 09:28:03 -0700 (PDT) Received: from pps.filterd (m0102889.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35GNHNm016071; Wed, 5 Apr 2017 09:28:00 -0700 Received: from mx0a-00000d03.pphosted.com (mx0a-00000d03.pphosted.com [148.163.149.244]) by mx0a-00000d04.pphosted.com with ESMTP id 29n14qgy38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 09:28:00 -0700 Received: from pps.filterd (m0102880.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35GQjmG006231; Wed, 5 Apr 2017 09:27:59 -0700 Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9]) by mx0a-00000d03.pphosted.com with ESMTP id 29jb0xcrqa-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Wed, 05 Apr 2017 09:27:59 -0700 Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen7.stanford.edu (Postfix) with ESMTP id 4747B4B; Wed, 5 Apr 2017 09:27:17 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) by codegreen7.stanford.edu (Postfix) with ESMTP id D999751; Wed, 5 Apr 2017 09:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=office365stanford.onmicrosoft.com; s=selector1-stanford-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GOvjF/vdNXtU3pDWfL/3m8GTNf9cG02YCXuztdkadMs=; b=p/4ZBNQwkVc3Wy159NSIdh5Q5IeZSrl6OoBzyia795nzodkc+BCCbucw0nnPSEf9Y3YMJao2vYdQqSuxnbqCDqj1Gy3dRMw2mwGs/RDsAUT/ZCnoXSw+aLlyWhonHp7B5kUxLEyRTWmoV6QfS58dG9kwQvDdnFUimLIukx7U/1g= Received: from MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) by MWHPR02MB2862.namprd02.prod.outlook.com (10.175.50.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Wed, 5 Apr 2017 16:27:57 +0000 Received: from MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) by MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) with mapi id 15.01.1019.019; Wed, 5 Apr 2017 16:27:57 +0000 From: Saba Eskandarian To: Ben Laurie CC: "trans@ietf.org" Thread-Topic: [Trans] Privacy-preserving proof of sct exclusion Thread-Index: AQHSpbii8uKV+c47g06WvQijP+zFvqGnVY2AgAC8FcqAAGFqgIAOkm1v Date: Wed, 5 Apr 2017 16:27:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=stanford.edu; x-originating-ip: [25.175.226.132] x-microsoft-exchange-diagnostics: 1; MWHPR02MB2862; 7:0BW3Ff4KeRdTrAL2189cdRVJoRlhUFgQzXoY70cxFGI6D0GHOdZPGmlPIZrkQ4f/b444Y653eSVbvuTqzsAHKUj5oglnLiArjdx+ToFOvJHseZ3l82FzM34vZ+vNaVx63BKA+iL4iwz7QbSNmnCTsmDlKnNdI+dnaZBA9PWBjLH3e1oVYochQ3N+dfAgbiqCsVM/9jMo/2vcamSziPHZfq7/pREPz4eO8d76PFJBDH2JmmKE+Fq6vMGDMOBZIH/Vntzu+yFgTkTUzARn/xwwzDyVuz5537kUXmala3WQEgQMyt5crDOv7dL+cGwByP+5Q1lccBVy1Cp1mmi3b1+5uw== x-ms-office365-filtering-correlation-id: fb72c8af-bf3d-44de-ff5d-08d47c40b81a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR02MB2862; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(127643986962959)(192374486261705)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR02MB2862; BCL:0; PCL:0; RULEID:; SRVR:MWHPR02MB2862; x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(51914003)(24454002)(69226001)(63696002)(74876001)(74706001)(33656001)(76786001)(76796001)(81542001)(54356001)(93136001)(92566001)(46102001)(76576001)(81342001)(92726001)(15975445006)(15188155005)(59766001)(16236675002)(56816005)(66066001)(76482001)(74316001)(90146001)(65816001)(87936001)(56776001)(54316002)(74366001)(87266001)(54206007)(16799955002)(4396001)(47976001)(50986001)(95666003)(49866001)(47736001)(75432001)(51856001)(79102001)(85852003)(83072002)(97336001)(94946001)(93516002)(95416001)(94316002)(86362001)(97186001)(80976001)(81686001)(83322001)(81816001)(31966008)(74662001)(19580395003)(53806001)(74502001)(47446002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR02MB2862; H:MWHPR02MB2861.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_" MIME-Version: 1.0 X-OriginatorOrg: stanford.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2017 16:27:57.1708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 396573cb-f378-4b68-9bc8-15755c0c51f3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2862 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_13:, , signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704050141 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 05 Apr 2017 16:28:06 -0000 --_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Since there wasn't time to present these privacy preserving proofs at the m= eeting last week, I thought it might be of interest to the list that I'll b= e presenting the idea at Stanford's annual security workshop next Monday. I= believe it will be streamed on youtube, and you may find the other present= ations interesting as well (http://forum.stanford.edu/events/2017security.p= hp). The workshop is aimed at a non-specialist audience, but I still hope t= o get to much of the content I meant to present at ietf. thanks, ~saba ________________________________ From: Ben Laurie Sent: Monday, March 27, 2017 2:48:11 AM To: Saba Eskandarian Cc: trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion On 27 March 2017 at 05:16, Saba Eskandarian > wrote: Thanks for the prompt feedback! I'll make sure to address these comments in= my talk, and I'm looking forward to discussing design options in person. I= suspect that the flexibility of the tools and techniques we use as well as= the associated engineering and privacy tradeoffs will make for an interest= ing discussion. Afraid I won't be there, but looking forward to hearing more. Thanks, ~saba ________________________________ From: Ben Laurie > Sent: Sunday, March 26, 2017 9:46:21 AM To: Saba Eskandarian Cc: trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion On 25 March 2017 at 22:39, Saba Eskandarian > wrote: Hello, I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago). My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxiv.org/abs/1703.02209 Thanks and looking forward to meeting you all next week! Cool, but I immediately see a problem - you require logs to be in timestamp= order, but they aren't. I can't immediately think of a way to get that pro= perty without also considerably increasing time to inclusion in the log. That seems undesirable - in fact, we're trying to go the other way, i.e. re= duce time to inclusion, in general. Also, engineering reality doesn't change, so increasing time to inclusion i= s also likely to increase MMD. Secondly, its interesting, but doesn't seem particularly useful: when an SC= T corresponds to a cert that has not been included, you want to reveal the = cert, not hide it. What you want to hide is who is revealing it. ~saba _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Since there wasn't time to present these privacy preserving proof= s at the meeting last week, I thought it might be of interest to the list t= hat I'll be presenting the idea at Stanford's annual security workshop next Monday. I believe it will be stre= amed on youtube, and you may find the other presentations interesting as we= ll (http://f= orum.stanford.edu/events/2017security.php). The workshop is aimed at a non-specialist audience, but I still hope to ge= t to much of the content I meant to present at ietf. 

thanks,
~saba
From: Ben Laurie <benl@g= oogle.com>
Sent: Monday, March 27, 2017 2:48:11 AM
To: Saba Eskandarian
Cc: trans@ietf.org
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 


On 27 March 2017 at 05:16, Saba Eskandarian <sabae@stanford.= edu> wrote:

Thanks for the prompt feedback! I'll make sure to address these comments in my talk, and I'm looking forwa= rd to discussing design options in person. I suspect that the flexibility o= f the tools and techniques we use as well as the associated engineering and privacy tradeoffs will make for a= n interesting discussion.


Afraid I won't be there, but looking forward to hearing more.
 


Thanks,

~saba

From:= Ben Laurie <benl@g= oogle.com>
Sent: Sunday, March 26, 2017 9:46:21 AM
To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 


On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.= edu> wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxi= v.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!


Cool, but I immediately see a problem - you require logs to be in time= stamp order, but they aren't. I can't immediately think of a way to get tha= t property without also considerably increasing time to inclusion in the lo= g.

That seems undesirable - in fact, we're trying to go the other way, i.= e. reduce time to inclusion, in general.

Also, engineering reality doesn't change, so increasing time to inclus= ion is also likely to increase MMD.

Secondly, its interesting, but doesn't seem particularly useful: when = an SCT corresponds to a cert that has not been included, you want to reveal= the cert, not hide it. What you want to hide is who is revealing it.

~saba


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



--_000_MWHPR02MB28615FB4FD70E67AB884B7A6C30A0MWHPR02MB2861namp_-- From nobody Thu Apr 6 03:15:55 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BA21293FB for ; Thu, 6 Apr 2017 03:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZyy2_pqTVdg for ; Thu, 6 Apr 2017 03:15:51 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E434C126C23 for ; Thu, 6 Apr 2017 03:15:49 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 19so2142815itj.1 for ; Thu, 06 Apr 2017 03:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=8p4hFJ1u2APigZQziWS0mM26suFgn9zHj0LoQUjKdWQ=; b=M451hjxR09qy30sjGcYhfv1qp3KCg7NaJtrvgj4plZaTNrlMsoD3E7FD+dXfW7QCAU /h99fnHRt9mj3ZXP/ixb68r37Z/W1FqK3Z8A3+NWo9b2LTm9NvYTHV30LyXzoW5mio4p GOa8P88NREr9KsYhwftDTfJwB1u2HPuH/KPwKLvqlsf/AdebdNTy7ErORFIED6mrI2gC brA07rHJWl2IaGuQiFY2/JL4p6JSAOZAvbygZTgnwSBXpQCrPBmn6x8/5TXawHiinMJx T0prxH1BLAEm536czNxl/koP7YJexlibV8WEvvCm6YYEOROrir2zj8+WbSzPVN2BNzZJ bGLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=8p4hFJ1u2APigZQziWS0mM26suFgn9zHj0LoQUjKdWQ=; b=An0KI7kBRXUsRwOINwG30nYyV0fshsaHblIeQ4+wF/qYkoWEftq3xEgACi+mxL8ttL hRTgE7HtUY7rhqn7O4rdWL8BH4JHIIwyg9EmO0xIGWpRRQSL6RphvxqhsDmYUoOQIwqQ ZnZ7yD3pnq+cie/YMPI7q+oyaMKw9owg/ygyOOBsAVG7KvGHFYqm4h7XnNqo/0Zi/n7+ EBMa6Xhz2NzwkB8Y8zcipor5ee0uZTqX0D9Pi0o8w7zg8HJLSFrdzv2T1z3bNqwHlfst orP3/Fp5JPrqm8ZCJSzl6sdEI9pOSWqT12h+2vZYU6RYhdL/9gFD5uhsvhhOT714lXp7 37Qg== X-Gm-Message-State: AFeK/H2PLCNPaGQ5XvbDswHCw0lpMS0HhFWm2qgEYQlxUmIiReaj43YxpdjCjDCJqxeObVjJzooLZ90cvKgtOJ/y X-Received: by 10.36.153.134 with SMTP id a128mr26087722ite.90.1491473749076; Thu, 06 Apr 2017 03:15:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Thu, 6 Apr 2017 03:15:18 -0700 (PDT) From: Eran Messeri Date: Thu, 6 Apr 2017 11:15:18 +0100 Message-ID: To: "trans@ietf.org" Cc: Richard Barnes Content-Type: multipart/alternative; boundary=94eb2c08cd4401c598054c7ccb63 Archived-At: Subject: [Trans] 6962-bis: Getting rid of SCTWithProofDataV2 (issue 172) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Apr 2017 10:15:53 -0000 --94eb2c08cd4401c598054c7ccb63 Content-Type: text/plain; charset=UTF-8 Richard Barnes proposed, and I support, removing the SCTWithProofDataV2 structure from 6962-bis. This structure was used to hold a combination of SCT + STH + inclusion proof to that STH. The same functionality can be achieved with a TransItemList that contains each of those, so it makes sense to remove it (as it would simplify parsing of TransItems without affecting functionality). The change was reviewed and merged in https://github.com/google/certificate-transparency-rfcs/pull/225. Also updated in https://trac.ietf.org/trac/trans/ticket/172. Eran --94eb2c08cd4401c598054c7ccb63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Richard Barnes proposed, and I support, removing the SCTWi= thProofDataV2 structure from 6962-bis.

This structure wa= s used to hold a combination of SCT + STH + inclusion proof to that STH.
The same functionality can be achieved with a TransItemList that co= ntains each of those, so it makes sense to remove it (as it would simplify = parsing of TransItems without affecting functionality).
--94eb2c08cd4401c598054c7ccb63-- From nobody Thu Apr 6 05:28:32 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74161294C0 for ; Thu, 6 Apr 2017 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO-Y8xmtiiKr for ; Thu, 6 Apr 2017 05:28:29 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4D5129471 for ; Thu, 6 Apr 2017 05:28:29 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 19so3803128itj.1 for ; Thu, 06 Apr 2017 05:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/Aiif0dxFvv5+zUtDLaI2oXSjhF1S+pxo4ncqsoWEmM=; b=MkpP2EpOQ+3eSfvg57QIuJ4I0ppv7BJXbb4LIu6BP3XqimDmbq766eGAzHQO9AqraG VRqt40gIFafQbitL5bz6eI1uvAQbkLO1WB/jzbl+yz2qovjihCIPPntAPfsUsxzLe6++ Q35EuPI3OZzh9jOJlSDOL98d4v7jai/23/ziHbFnuyimeHlQPwj61G1rFgkRR8xFHfsM G9M/LhFhSlC9B2G89hqAeKRzjfSYOpsHCPRzoiqIXYOFatMOWvRmNFZ0PvZceiWjBibc CayCD/suhcBShjGIY6SCg5ujXk8CBticc9oukb4taU/+JYxU+vOGUJ6TQIdplWkkA2qt RbdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/Aiif0dxFvv5+zUtDLaI2oXSjhF1S+pxo4ncqsoWEmM=; b=bWo9+/udEjkaN5QnBvu/svpS7CRoveXkWYWqLlLae7NAup9n7VfLsu1rCqV2wVWkfr 6mUKgHLcfBBvjeLhfb7Hqg/F51okdLsOdR3nTLtvA1T5JSh+tvG3Q2zCunJUm/tMqt3J 62h5Zhx9pEiTJGPrW1yFvpyDn+zd7ZMxPPmH7f8OHx7oY+6rF6AgwuIVBIaF/o61EwsL JUelfWmDZLeYWIClAKjXrEpBp1MdITkzbborD6ITQMduxBm71yc5KRYoBoxnb7AcUL4V EXRWa+exK9LBrYLiTnSMffvFkbwus64jZajFqutphKEuEDz4JzYxIKnikAWVrnkLZi+V sajw== X-Gm-Message-State: AFeK/H0OsNiO7TRuCrFHaMxyEz7eQZrnFaPayJTbbxlvY8wVdpWAOTvxxpSomsD6N9TyV+Mbr3LQl8RBcQE5aJCY X-Received: by 10.36.153.134 with SMTP id a128mr26597091ite.90.1491481707845; Thu, 06 Apr 2017 05:28:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Thu, 6 Apr 2017 05:27:57 -0700 (PDT) From: Eran Messeri Date: Thu, 6 Apr 2017 13:27:57 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c08cd44630c0e054c7ea571 Archived-At: Subject: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Apr 2017 12:28:31 -0000 --94eb2c08cd44630c0e054c7ea571 Content-Type: text/plain; charset=UTF-8 I intend to adopt Richard's suggestion of merging the extension types for SCTs and STHs. Currently there doesn't seem to be a good reason to separate the two - since the extensions are typed, it'd be easy to differentiate between the two, and there may be extensions which are shared between SCTs and STHs. This has been reviewed in https://github.com/google/certificate-transparency-rfcs/pull/224, rationale updated in https://trac.ietf.org/trac/trans/ticket/173. Eran --94eb2c08cd44630c0e054c7ea571 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I intend to adopt Richard's suggestion of merging the = extension types for SCTs and STHs.

Currently there doesn= 't seem to be a good reason to separate the two - since the extensions = are typed, it'd be easy to differentiate between the two, and there may= be extensions which are shared between SCTs and STHs.

=

Eran
--94eb2c08cd44630c0e054c7ea571-- From nobody Thu Apr 6 06:09:12 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F34A1294EF for ; Thu, 6 Apr 2017 06:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8BaX7x7I8TK for ; Thu, 6 Apr 2017 06:08:58 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0991294EE for ; Thu, 6 Apr 2017 06:08:54 -0700 (PDT) Received: (qmail 23992 invoked by uid 1004); 6 Apr 2017 13:08:52 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 06 Apr 2017 14:08:52 +0100 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201704061408526538; Thu, 06 Apr 2017 14:08:52 +0100 To: Eran Messeri , "trans@ietf.org" References: Cc: Richard Barnes From: Rob Stradling Message-ID: <4aefc38b-9345-cc11-2aeb-f98a0f6a4dcf@comodo.com> Date: Thu, 6 Apr 2017 14:08:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] 6962-bis: Getting rid of SCTWithProofDataV2 (issue 172) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Apr 2017 13:09:11 -0000 On 06/04/17 11:15, Eran Messeri wrote: > Richard Barnes proposed, and I support, removing the SCTWithProofDataV2 > structure from 6962-bis. > > This structure was used to hold a combination of SCT + STH + inclusion > proof to that STH. > The same functionality can be achieved with a TransItemList that > contains each of those, so it makes sense to remove it (as it would > simplify parsing of TransItems without affecting functionality). > > The change was reviewed and merged > in https://github.com/google/certificate-transparency-rfcs/pull/225. > Also updated in https://trac.ietf.org/trac/trans/ticket/172. I support this too. Note: I just did some editorial follow-up work in https://github.com/google/certificate-transparency-rfcs/pull/243 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Apr 6 06:12:54 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB60128D69 for ; Thu, 6 Apr 2017 06:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8s-h6GvQNQj for ; Thu, 6 Apr 2017 06:12:48 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE4E1294EE for ; Thu, 6 Apr 2017 06:12:48 -0700 (PDT) Received: (qmail 24414 invoked by uid 1004); 6 Apr 2017 13:12:46 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 06 Apr 2017 14:12:46 +0100 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201704061412468901; Thu, 06 Apr 2017 14:12:46 +0100 To: Eran Messeri , "trans@ietf.org" References: From: Rob Stradling Message-ID: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> Date: Thu, 6 Apr 2017 14:12:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Apr 2017 13:12:50 -0000 On 06/04/17 13:27, Eran Messeri wrote: > I intend to adopt Richard's suggestion of merging the extension types > for SCTs and STHs. > > Currently there doesn't seem to be a good reason to separate the two - > since the extensions are typed, it'd be easy to differentiate between > the two, and there may be extensions which are shared between SCTs and STHs. > > This has been reviewed > in https://github.com/google/certificate-transparency-rfcs/pull/224, > rationale updated in https://trac.ietf.org/trac/trans/ticket/173. I support this too. Note: I just did some editorial follow-up work in https://github.com/google/certificate-transparency-rfcs/pull/244 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Apr 6 06:48:06 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0181294F6 for ; Thu, 6 Apr 2017 06:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlna9U29aMsz for ; Thu, 6 Apr 2017 06:48:02 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A27A1294F0 for ; Thu, 6 Apr 2017 06:48:02 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id r69so40978610vke.2 for ; Thu, 06 Apr 2017 06:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6aStv4Yf8n9m/EEgKrLXRZ48/vlNfl6xk0D57sJw5xw=; b=SkZSFFuiyS29zvnFahxDoXyOge19lhcwcdojEAJOzV72xeJw/Z0HBPOix29yzMGfYj Y95R0oO9LRWM6hpem15KgrsSB1ono9bGiaoPJNFkqqcWuxIFQgEnvhx+6g4EhcVhP9W7 P+7MjtmBBeitADW6BfN9XYium1i4f9NnDGUn8RcgFbCfI8oYDSVIRzmI2TWsWq5lvtRT uh0/XITT8pr7Wwv+z5jlY9+rbVLhN2TVTl4moZZFXLgt4WlD2vvi61Oh6v8fW+QE6wb6 2InR463TGPpXsM2LZJSzGrpWWak5xx4hEc8B0lRQFDIOasZ1qdaeFL1FN9haPyVc2p0C Frdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6aStv4Yf8n9m/EEgKrLXRZ48/vlNfl6xk0D57sJw5xw=; b=klp3k7vGEcallUJDwHTkyJs8PyZgJQFkcUtspYZi4IraLJk685aFGktLTLpp2NhOpi 0Jl7qmkGS+il5bwf9RCYWh6vL6Ez0TyJFsP2qKGTDsw4Hohziolh5ADS74+DMGGbWNby fm+Po0Ms+uoL6Wicwr7QgjSyoRJyGyctAqmM0lC49X89oEjyS6JJ0MkUWvJWT9lBeh/E PKomRB+k0wVXr2bWuIHNpRtkkWU99YhNh1khhGoEDp5TlmEXFpo7dC1yAoP/QwE7kZm1 Pzs0FKhWCN08sjNWnqEkeRZQLz30poHG2OC0ka3gdMwFsbsBjVYcZpkuk0CQUa/fUm/v 1+lQ== X-Gm-Message-State: AFeK/H1a8OWoNeiydwyDk7pQPx0K+XSD3Rx+EycNODgyuU/oEh0ooOHpj3P2zBLlxB91HcWrvctW60GCxdKcyFaJ X-Received: by 10.31.235.198 with SMTP id j189mr13303803vkh.75.1491486481192; Thu, 06 Apr 2017 06:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.201 with HTTP; Thu, 6 Apr 2017 06:48:00 -0700 (PDT) In-Reply-To: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> References: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> From: Ben Laurie Date: Thu, 6 Apr 2017 14:48:00 +0100 Message-ID: To: Rob Stradling Cc: Eran Messeri , "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0929c8e6a8f7054c7fc18b Archived-At: Subject: Re: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Apr 2017 13:48:04 -0000 --94eb2c0929c8e6a8f7054c7fc18b Content-Type: text/plain; charset=UTF-8 On 6 April 2017 at 14:12, Rob Stradling wrote: > On 06/04/17 13:27, Eran Messeri wrote: > >> I intend to adopt Richard's suggestion of merging the extension types >> for SCTs and STHs. >> >> Currently there doesn't seem to be a good reason to separate the two - >> since the extensions are typed, it'd be easy to differentiate between >> the two, and there may be extensions which are shared between SCTs and >> STHs. >> >> This has been reviewed >> in https://github.com/google/certificate-transparency-rfcs/pull/224, >> rationale updated in https://trac.ietf.org/trac/trans/ticket/173. >> > > I support this too. > > Note: I just did some editorial follow-up work in > https://github.com/google/certificate-transparency-rfcs/pull/244 Really? I am confused by this plan - surely the extensions for STHs and SCTs will be different? So what's the value of allowing the wrong ones to be included? --94eb2c0929c8e6a8f7054c7fc18b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 6 April 2017 at 14:12, Rob Stradling <rob.stradling@comodo.com> wrote:
<= span class=3D"gmail-">On 06/04/17 13:27, Eran Messeri wrote:
I intend to adopt Richard's suggestion of merging the extension types for SCTs and STHs.

Currently there doesn't seem to be a good reason to separate the two -<= br> since the extensions are typed, it'd be easy to differentiate between the two, and there may be extensions which are shared between SCTs and STHs= .

This has been reviewed
in https://github.com/google/certificate-transparency-rfcs/pull/224,
rationale updated in https://trac.ietf.org/trac/tran= s/ticket/173.

I support this too.

Note: I just did some editorial follow-up work in https://github.com/google/certificate-transparency-rfcs/= pull/244

Really? I am confused by = this plan - surely the extensions for STHs and SCTs will be different? So w= hat's the value of allowing the wrong ones to be included?
--94eb2c0929c8e6a8f7054c7fc18b-- From nobody Thu Apr 6 06:51:36 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475941294FF for ; Thu, 6 Apr 2017 06:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz3F2Wz2E0Md for ; Thu, 6 Apr 2017 06:51:32 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49511287A0 for ; Thu, 6 Apr 2017 06:51:31 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id z13so29905472iof.2 for ; Thu, 06 Apr 2017 06:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iqJG34moDj/kIFuJisWK7bFvMyHl1D9uZaeF6QBQu+o=; b=QKwZzMKDTypu5EStgZRQZAIimZHTEItR3rucd4/DrH8ZdvwYOPAp2pY1wfnFc+koKZ gNicgC2sJwaamT13HXNeo215DEGkn8bgmFNp8TOLpO3xys/4KK8D+Zz/Fj4KcRMd0ZnL 33bXQ11HXd5j3rYIuUQ1B0y2TEyyqx+K0ZWauUQdGsMqI7KhJqLoKdis3ZvPdcIq9BcR 6La5Sh1hClU/7iLR/kxwhb4H5RZNh7wCBNY5aRnc1VBe4WZaAhjkG1KliDO+369u/oEK z1UnSnb1CtOeo8B+i2fQwi4WX0aSWQZq0dYjXHteW0KtcAn0wRLA5ArERoSPcsybVLX1 kBkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iqJG34moDj/kIFuJisWK7bFvMyHl1D9uZaeF6QBQu+o=; b=AY5eunabvi1vAKPnirSkXxJrDCsz26/qrr+t6cO6Nu2cZ0okFeWK8aHhNv901uRGcz TfkN0XluETW2xnSya14v1EnzU0OwV4dzlxDXho7naHuFC4xd3/Mw/Nu9vcVv4Z2seAwu RSNnQxOlwbZSqKC5dT4Rf9ROHnvZqFMcWKBW6Yf5V9HbTUop4XvUupawVGWkx/koPw7A ipsz4kKV0ILGrXxZy42526jdGBlBe1G4L2XolX9bqD5c3Gcl70MkFB2FSDQ/E0uP0sD2 zd+EvbIney6JpfOwgMqgKZOEyrjx5yix8L81n6aVJHhx2eyThN8aJhSlxWXe4HfLy6fg 4rNA== X-Gm-Message-State: AFeK/H3V3SdU9OY8LzVpPBTzrt7Fg0cKaO1fx4bAH5ZHdBVJ/NHtsKdUdSnC9eed2vBpnUmt0RHcyMFydq1uwb3c X-Received: by 10.107.142.139 with SMTP id q133mr31174476iod.99.1491486691264; Thu, 06 Apr 2017 06:51:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Thu, 6 Apr 2017 06:51:00 -0700 (PDT) In-Reply-To: References: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> From: Eran Messeri Date: Thu, 6 Apr 2017 14:51:00 +0100 Message-ID: To: Ben Laurie Cc: Rob Stradling , "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05ae466be97c054c7fce27 Archived-At: Subject: Re: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Apr 2017 13:51:34 -0000 --94eb2c05ae466be97c054c7fce27 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie wrote: > > On 6 April 2017 at 14:12, Rob Stradling wrote: > >> On 06/04/17 13:27, Eran Messeri wrote: >> >>> I intend to adopt Richard's suggestion of merging the extension types >>> for SCTs and STHs. >>> >>> Currently there doesn't seem to be a good reason to separate the two - >>> since the extensions are typed, it'd be easy to differentiate between >>> the two, and there may be extensions which are shared between SCTs and >>> STHs. >>> >>> This has been reviewed >>> in https://github.com/google/certificate-transparency-rfcs/pull/224, >>> rationale updated in https://trac.ietf.org/trac/trans/ticket/173. >>> >> >> I support this too. >> >> Note: I just did some editorial follow-up work in >> https://github.com/google/certificate-transparency-rfcs/pull/244 > > > Really? I am confused by this plan - surely the extensions for STHs and > SCTs will be different? So what's the value of allowing the wrong ones to > be included? > We don't know yet, as no extension has been defined - but for each extension, it must be specified whether it should go in the SCT, STH or both. So we'd simply have a single extensions repository, rather than two. --94eb2c05ae466be97c054c7fce27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie <benl@google.com> wrote:

On 6 April 201= 7 at 14:12, Rob Stradling <rob.stradling@comodo.com> = wrote:
On 06/04/17 13:27, Eran Messeri wrote:
I intend to adopt Richard's suggestion of merging the extension types for SCTs and STHs.

Currently there doesn't seem to be a good reason to separate the two -<= br> since the extensions are typed, it'd be easy to differentiate between the two, and there may be extensions which are shared between SCTs and STHs= .

This has been reviewed
in https://github.com/google/certificate-transparency-rfcs/pull/224,
rationale updated in https://trac.ietf.org/trac/tran= s/ticket/173.

 I support this too.

Note: I just did some editorial follow-up work in https://github.com/google/certificate-transparency-rfcs/= pull/244

Really? I am confu= sed by this plan - surely the extensions for STHs and SCTs will be differen= t? So what's the value of allowing the wrong ones to be included?
=
We don't know yet, as no extension = has been defined - but for each extension, it must be specified whether it = should go in the SCT, STH or both.=C2=A0
So we'd simply have = a single extensions repository, rather than two.=C2=A0

--94eb2c05ae466be97c054c7fce27-- From nobody Thu Apr 6 09:30:35 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B281129562 for ; Thu, 6 Apr 2017 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5qYvUZYukPn for ; Thu, 6 Apr 2017 09:30:31 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBF8129552 for ; Thu, 6 Apr 2017 09:30:28 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id r69so47069677vke.2 for ; Thu, 06 Apr 2017 09:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PPTn6qWeFjmetOLQ4MA3IuQmh7SzHrLJvYQGKT0QLQQ=; b=M7zEILPA/mVgfVEsalxShoLM/iRvM7jBHv+6XB4V4K9wW6Wmw6JWv4Gzizhls5iSw9 yP2fggRULxFkTzht2fLSkeyzDYntx2IoGehWoHqg9YWmSg+7JVGdL/W7CU7Fl21t8SHW xOr6RpS+Pc2OvRQPkRUWCl7CShTXVcxnfTuZpxVtAq8tVAqtLQtsrJziqbxSb1v5dc6+ p+GixPPY2SCfByTXnbhKDfOY9MsHqZa86wlf/RLBvrz6k79Gjvo1SpbHYUdbaAoGh5FC IdqQ81IBJiSPqPDCdwN1+h9fx6dcVS6kjn3mJuiVX7PVQfT9ZZ0sH6jNrR59IZEPILLu tfBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PPTn6qWeFjmetOLQ4MA3IuQmh7SzHrLJvYQGKT0QLQQ=; b=rL+atIbSVRny3KtJAhK9ShlvBqkwv+4WdqL3q7AXA83Gy/m592toXokTizHazFCfav bn4J3JZVvyY6X/jahbNw5Vh3j73OJHw6oRphFSX19skrzhlr6t8fAuFSdqpBQ1Av0dKr 2CMlZiF4YZBUUnry4/Q+py4na8PCf5deG3gKA8hGwSOsB2DyJUPK3H+xQ+R9VzFGO/Bd LyjKWz4dyPOVGJgVA38+KfRoE5vnd/WJopyRnpUDhPllhN21WcKUpUHgXGUoh8yL27tn h3W9RJ+dGz1gThkDVuQ1ZY/ONZ9tXcSksQBGr4JsVOtakD/EtXE5UBFUDtXhkyn+sW6J aTbA== X-Gm-Message-State: AFeK/H3ideSiccngN8oRch/iIyFaEJlx9/btNNGJ/naYAuXo4WkjRwAoYrt35aSt6YihSWNkjF2QgEuLDsv/2/7H X-Received: by 10.31.235.198 with SMTP id j189mr13650917vkh.75.1491496227605; Thu, 06 Apr 2017 09:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.201 with HTTP; Thu, 6 Apr 2017 09:30:27 -0700 (PDT) In-Reply-To: References: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> From: Ben Laurie Date: Thu, 6 Apr 2017 17:30:27 +0100 Message-ID: To: Eran Messeri Cc: Rob Stradling , "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0929c8d55dde054c820627 Archived-At: Subject: Re: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 06 Apr 2017 16:30:34 -0000 --94eb2c0929c8d55dde054c820627 Content-Type: text/plain; charset=UTF-8 OK, but it seems to me you've exchanged two lists for one list with a bunch of flags. Not sure why this is in any way an improvement? On 6 April 2017 at 14:51, Eran Messeri wrote: > > > On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie wrote: > >> >> On 6 April 2017 at 14:12, Rob Stradling wrote: >> >>> On 06/04/17 13:27, Eran Messeri wrote: >>> >>>> I intend to adopt Richard's suggestion of merging the extension types >>>> for SCTs and STHs. >>>> >>>> Currently there doesn't seem to be a good reason to separate the two - >>>> since the extensions are typed, it'd be easy to differentiate between >>>> the two, and there may be extensions which are shared between SCTs and >>>> STHs. >>>> >>>> This has been reviewed >>>> in https://github.com/google/certificate-transparency-rfcs/pull/224, >>>> rationale updated in https://trac.ietf.org/trac/trans/ticket/173. >>>> >>> >>> I support this too. >>> >>> Note: I just did some editorial follow-up work in >>> https://github.com/google/certificate-transparency-rfcs/pull/244 >> >> >> Really? I am confused by this plan - surely the extensions for STHs and >> SCTs will be different? So what's the value of allowing the wrong ones to >> be included? >> > We don't know yet, as no extension has been defined - but for each > extension, it must be specified whether it should go in the SCT, STH or > both. > So we'd simply have a single extensions repository, rather than two. > > --94eb2c0929c8d55dde054c820627 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, but it seems to me you've exchanged two lists for = one list with a bunch of flags. Not sure why this is in any way an improvem= ent?

On 6 Ap= ril 2017 at 14:51, Eran Messeri <eranm@google.com> wrote:
=


On Thu, Apr 6, 20= 17 at 2:48 PM, Ben Laurie <benl@google.com> wrote:

On 6 April 2017 at 14:12, Rob Stradling <rob.stradling@comodo.com> wrote:
On 06/04/17 13:27, Eran Messeri wrote:
I intend to adopt Richard's suggestion of merging the extension types for SCTs and STHs.

Currently there doesn't seem to be a good reason to separate the two -<= br> since the extensions are typed, it'd be easy to differentiate between the two, and there may be extensions which are shared between SCTs and STHs= .

This has been reviewed
in https://github.com/google/certificate-transparency-rfcs/pull/224,
rationale updated in https://trac.ietf.org/trac/tran= s/ticket/173.

 I support this too.

Note: I just did some editorial follow-up work in https://github.com/google/certificate-transparency-rfcs/= pull/244

Really? I am confu= sed by this plan - surely the extensions for STHs and SCTs will be differen= t? So what's the value of allowing the wrong ones to be included?
=
We don't know yet, as n= o extension has been defined - but for each extension, it must be specified= whether it should go in the SCT, STH or both.=C2=A0
So we'd = simply have a single extensions repository, rather than two.=C2=A0


--94eb2c0929c8d55dde054c820627-- From nobody Fri Apr 7 01:48:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99C01292AE for ; Fri, 7 Apr 2017 01:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX7ppL92mkDw for ; Fri, 7 Apr 2017 01:48:16 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC127128ACA for ; Fri, 7 Apr 2017 01:48:16 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id y18so115592534itc.0 for ; Fri, 07 Apr 2017 01:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d8THDKMf8xT9olefRFxwNpKKMATRDpTRTpnxn9IYLhs=; b=n+wFrUP5ZtDu2BacZHjmz8K61zO0rKNBEIhnmVDga4RAED6OmJgHnpTcCHdWNoVrHW h0lrJO6+zJCr4bs9iedD9Bv9jSmJyEdbTEKIOeQbiBbui2aSqBA/K50A+QvfbkXwuziQ 9Nlw/Goa58chAu3qwIijZMiBoPuPEbd0FaOBlTtIVIG2fDv7kYI4UOIKHgSw1UIo49JZ RDUVPO/tuPtV5xd9twIIIRMd4zVng2SmgRhqtZyhaJ5ANKkenXdJT3QSnNxGnW+HaKJq msiBkTMF7+a4HZIcD6CJNT8/0ffvkUxGh57bvpYbBJWgfI2xWe2CKiOdU9VRzWk65/1r Of3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d8THDKMf8xT9olefRFxwNpKKMATRDpTRTpnxn9IYLhs=; b=AAgBI3Qz0Jr987d1Ti9EjWAkyjgoRg/aSEbSg0io1k1XoqSmNzKx+1clwOifrhMhzS gNaFzRl9ucEwTUXxKnLb2vH25+VHR3+Yn2RADeUhV6D8GIuLyU45Ny/k4TFWQdyQOTA4 f+cylSkfP/0Ph3CIBK7G5jEwMrFZ+R5e39Wul7YpNzwHP7buywsA5o2xXzSqdOk+KxkR OoXPKZLkWh+wpPj4sFa8PApNYSfyEkrE/TyZxUjthaLBYJwKA0lJ+IeDqal5Q9mnEtwH W/y+Te2zMmiDdHu/i4643JZC9Nyd/ZU6U7KjaSRiI3o3FDfrniX/X/FzwKaNIoIAJ2D1 DTag== X-Gm-Message-State: AFeK/H3J0zqmdlvrf5zxTan6ugVfb2/ESZGTMCGTG+fp+bEKnJBAbali rqCHOl1bjHodO7f2dqVrb/DudHyI6mOx X-Received: by 10.36.124.85 with SMTP id a82mr31504141itd.90.1491554895992; Fri, 07 Apr 2017 01:48:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Fri, 7 Apr 2017 01:47:45 -0700 (PDT) From: Eran Messeri Date: Fri, 7 Apr 2017 09:47:45 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a114aa74abd7d7f054c8fafcf Archived-At: Subject: [Trans] 6962-bis: Empty consistency proof for trees of equal size X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Apr 2017 08:48:19 -0000 --001a114aa74abd7d7f054c8fafcf Content-Type: text/plain; charset=UTF-8 In ticket 188 I propose explicitly stating that a call to get-sth-consistency with equal first, second parameters (two identical trees) should yield an empty consistency proof (i.e. that is a valid request to the log and the only valid response is an empty consistency proof). That issue came up when compliance monitoring one of the V1 logs, which returned an HTTP 400 error for this request. Since the proof checking algorithm specifies behaviour for an empty proof, I see no reason for the log not to return it in this (appropriate) case. The document change is out for review in https://github.com/google/certificate-transparency-rfcs/pull/245. Eran --001a114aa74abd7d7f054c8fafcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In ticket 188 I propose explicitly stating that a call to get-sth-consist= ency with equal first, second parameters (two identical trees) should yield= an empty consistency proof (i.e. that is a valid request to the log and th= e only valid response is an empty consistency proof).

Th= at issue came up when compliance monitoring one of the V1 logs, which retur= ned an HTTP 400 error for this request. Since the proof checking algorithm = specifies behaviour for an empty proof, I see no reason for the log not to = return it in this (appropriate) case.

The document= change is out for review in=C2=A0https://github.com/google/certificate-t= ransparency-rfcs/pull/245.

Eran

=
--001a114aa74abd7d7f054c8fafcf-- From nobody Fri Apr 7 02:06:11 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7B3126C22 for ; Fri, 7 Apr 2017 02:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE8WTv0tGrVq for ; Fri, 7 Apr 2017 02:06:07 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D01124281 for ; Fri, 7 Apr 2017 02:06:07 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id z13so45860546iof.2 for ; Fri, 07 Apr 2017 02:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7lT8ppOqlhC+TFRL+Yq9RuM5fP8tjXjdvRxNCD5aoAY=; b=Hm6Olo0Ji/mWXJFlS8VJz7JP8HUJrc6YnQTR/gJIVYwH/gzS3cj7QUst1lclmzlu+f J7ECHWrkAzftucsA8/58OR66O/56NoRKiOJOqanftcTVvVsoLnHi4ARAbc0Z4PyOciTc SbDCQRyCrN1iG5cGruVUL2f7sao0kpJxtMP8Vu5akqIDLLNuo7qGaUqOD8NAIF1RP2uV Yf8IYny46r5W5WPD15QcPjSuI0o5Hcz6mkWLXFr7CQMT5ALhwbkagiW6QzFcAxYLDHrM pvtfh8Fclo2k9ICmIivW/knBUVMArGpLNC2iEJLTabDfmj2lG91ZhjSST34c3PfV6zQL WQwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7lT8ppOqlhC+TFRL+Yq9RuM5fP8tjXjdvRxNCD5aoAY=; b=hlGCY8xVKCivSMSxgiwKR5jYc7vZKWFT5MqgyqoOTOZxh8PQ1vPGjMdaIcQq4p0xS5 lAmZ+FZ5cOsrQ8bp3vmMZ1Si8FiTjJW/wTRtYSPnxuKE92gcg7SoJI7toLwPVK4dAcTQ R9gLpxGQio0xARllhJX2FqdJ8cHg9bMsvhPdSE7f6jJUExj2hIQO2sN9CSh7wAeZHt2L 6c5Sq8AJ8C3T5JRznbDDd9AoEfcnypPTqAyHd7CLe/CMsT1GA51/HTa3U9g/9eKhv4Ix uL3NiWacdaBVI/alPmfB+txxlBurMIL+28ERVxF6MW9n2KSv8UEMBUzS8HxurvmjkADN et2w== X-Gm-Message-State: AFeK/H2DjFVK3RoOItFx7s4MMArfGVTS/b8I6imFyqM31EL7MNPIz1Wc+0QXdRKzerCchI81eiTdsSeX3MkI7c1B X-Received: by 10.107.85.2 with SMTP id j2mr43395695iob.165.1491555966653; Fri, 07 Apr 2017 02:06:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Fri, 7 Apr 2017 02:05:36 -0700 (PDT) In-Reply-To: References: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> From: Eran Messeri Date: Fri, 7 Apr 2017 10:05:36 +0100 Message-ID: To: "trans@ietf.org" Cc: Melinda Shore , martin.thomson@gmail.com Content-Type: multipart/alternative; boundary=94eb2c1c5f808e7c57054c8fef07 Archived-At: Subject: Re: [Trans] RFC 7320 and draft-ietf-trans-rfc6962-bis-24 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Apr 2017 09:06:10 -0000 --94eb2c1c5f808e7c57054c8fef07 Content-Type: text/plain; charset=UTF-8 >From discussing in-person with Richard Barnes, and the trans wg meeting, it seems there's consensus on not having a 'directory' endpoint for dynamic discovery of all the methods the log exposes. Instead, we could: (1) Clarify why BCP 190 may not apply here (based on experience deploying V1 logs) (2) Remove the 'ct/v2' portion from all the URIs. Any preferences? Mine would be for (2), but it's not a strong preference. On Mon, Mar 20, 2017 at 2:50 PM, Eran Messeri wrote: > FYI this has been documented in https://trac.ietf.org/trac/ > trans/ticket/185. > > On Wed, Mar 15, 2017 at 8:46 PM, Melinda Shore > wrote: > >> On 3/15/17 12:29 PM, Martin Thomson wrote: >> > I am not following this work, but this and the original RFC 6962 both >> > run afoul of the (good) guidance in RFC 7320. >> > >> > Has the working group solicited feedback from the HTTP community on >> > the use of HTTP in this protocol? >> >> No, we haven't. >> >> For what it's worth, 6962 reflects implementation and >> deployment prior to CT having been brought to the IETF >> for standardization, so any concerns regarding URL >> syntax or HTTP transport in the work being done by this >> working group are necessarily limited to the -bis and >> related documents. >> >> To be honest, I'm personally not convinced of the applicability >> of 7320 in this case but if there's a specific problem it does >> need to be discussed. >> >> Melinda >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > --94eb2c1c5f808e7c57054c8fef07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From discussing in-person with Richard Barnes, and the tra= ns wg meeting, it seems there's consensus on not having a 'director= y' endpoint for dynamic discovery of all the methods the log exposes.
Instead, we could:
(1) Clarify why BCP 190 may = not apply here (based on experience deploying V1 logs)
(2) Remove= the 'ct/v2' portion from all the URIs.

An= y preferences? Mine would be for (2), but it's not a strong preference.=

On Mo= n, Mar 20, 2017 at 2:50 PM, Eran Messeri <eranm@google.com> w= rote:
FYI this has been = documented in=C2=A0https://trac.ietf.org/trac/trans/ticket/185.

On Wed, Mar 15, 2017 at 8:46 PM, Melinda Shore &l= t;melinda.shor= e@gmail.com> wrote:
On 3/15/17 12:29 PM, Martin Thomson wrote= :
> I am not following this work, but this and the original RFC 6962 both<= br> > run afoul of the (good) guidance in RFC 7320.
>
> Has the working group solicited feedback from the HTTP community on > the use of HTTP in this protocol?

No, we haven't.

For what it's worth, 6962 reflects implementation and
deployment prior to CT having been brought to the IETF
for standardization, so any concerns regarding URL
syntax or HTTP transport in the work being done by this
working group are necessarily limited to the -bis and
related documents.

To be honest, I'm personally not convinced of the applicability
of 7320 in this case but if there's a specific problem it does
need to be discussed.

Melinda


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



--94eb2c1c5f808e7c57054c8fef07-- From nobody Fri Apr 7 06:17:27 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE906126557 for ; Fri, 7 Apr 2017 06:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7pPNq8IH7an for ; Fri, 7 Apr 2017 06:17:24 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0A8127977 for ; Fri, 7 Apr 2017 06:17:23 -0700 (PDT) Received: (qmail 3985 invoked by uid 1004); 7 Apr 2017 13:17:22 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 07 Apr 2017 14:17:22 +0100 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201704071417216011; Fri, 07 Apr 2017 14:17:21 +0100 To: Ben Laurie References: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> Cc: Eran Messeri , "trans@ietf.org" From: Rob Stradling Message-ID: <007fba99-77c6-fa69-32e6-3701ffe27c6f@comodo.com> Date: Fri, 7 Apr 2017 14:17:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Apr 2017 13:17:27 -0000 On 06/04/17 17:30, Ben Laurie wrote: > OK, but it seems to me you've exchanged two lists for one list with a > bunch of flags. Not sure why this is in any way an improvement? Do you consider it to be a deprovement? I think it: 1. simplifies the document a bit. 2. facilitates the writing of one set of code (rather than two sets) to support SCT extensions and STH extensions. 3. provides a generic extension mechanism for other sorts of transparency log objects to use in the future, should the need arise. > On 6 April 2017 at 14:51, Eran Messeri wrote: > > > > On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie > wrote: > > > On 6 April 2017 at 14:12, Rob Stradling > > wrote: > > On 06/04/17 13:27, Eran Messeri wrote: > > I intend to adopt Richard's suggestion of merging the > extension types > for SCTs and STHs. > > Currently there doesn't seem to be a good reason to > separate the two - > since the extensions are typed, it'd be easy to > differentiate between > the two, and there may be extensions which are shared > between SCTs and STHs. > > This has been reviewed > in > https://github.com/google/certificate-transparency-rfcs/pull/224 > , > rationale updated in > https://trac.ietf.org/trac/trans/ticket/173 > . > > > I support this too. > > Note: I just did some editorial follow-up work in > https://github.com/google/certificate-transparency-rfcs/pull/244 > > > > Really? I am confused by this plan - surely the extensions for > STHs and SCTs will be different? So what's the value of allowing > the wrong ones to be included? > > We don't know yet, as no extension has been defined - but for each > extension, it must be specified whether it should go in the SCT, STH > or both. > So we'd simply have a single extensions repository, rather than two. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Apr 7 06:32:45 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0561294A1 for ; Fri, 7 Apr 2017 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enEs6S4fsqXZ for ; Fri, 7 Apr 2017 06:32:40 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E430D1242EA for ; Fri, 7 Apr 2017 06:32:35 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id t20so108251665wra.1 for ; Fri, 07 Apr 2017 06:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2dh22V5Wcz7dqBOa/qdYajCl7M/nGT7axEM7Vmv2sys=; b=ZXl9I0jAohQ9xKnn+gfclCPKrD/PnwWHLjzZZWc4cI1As6hSj4+KmOuYChlskKsu87 0iwMYDm/TjrCvOak0ZtHVcc0o1M4a347qoI9WCceiWW6aLwGAsEz3MFWzMMwmGx3QP+c OjPRzqGyRsHHK5MviyZtEatk661ge6+rMQ7WjpH5HNMe3x9iy08IbIizRAJl7FIAjX4v 9WSt7SilNsHwJH/kjo/ZYDFDlKfgADacbq4TjY+u0Zg3oZIw1CG09ukh/OlyceLiBd/9 OnGET3DjOEbz1oZGUUChlj4NBMitjKiib6dKD+ZKPmptaYc3CLrXLv5RywyT9y0OZpeE XD6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2dh22V5Wcz7dqBOa/qdYajCl7M/nGT7axEM7Vmv2sys=; b=KlcZxhcqUEvvleuB6z8nP625/6XwgcrM3H6WORIlhK8e+7QJgQc7YDPFn3oK0qM8ZD g0CavZ8aOn9Y5S+CZQAPY5dqZkmgkeQuUajiyLG8xwseJ8AJ6gN5+kMh2g+USAlHo3o4 N+tX15du0FQDn4OwOabKUDvNZLxv2oobYjYZVdhV4rqxgGtKvK4IY2vModN4jxTxyNj+ MzFwb6FbzDqHJmQk/mEj7wgvPya+Wqi/h+VUlzgGDLV2SF1C+aGguHwI+RMRFNuwuVTs 6ziSohk+VUsye4pKAtA1f0J/y89l9fpGUjnhq7AsiOob7zvPgoZRhwn1pavsew5JMEV5 lixw== X-Gm-Message-State: AFeK/H2wBJKzCDbGpXVqY69xjTcLmWaPs0FPkgxiBNzEBERl6tCqXSA2gy3fPJCD7bkgFvloKt+Nc4nZO2Z65g== X-Received: by 10.28.113.73 with SMTP id m70mr29635540wmc.12.1491571954241; Fri, 07 Apr 2017 06:32:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Fri, 7 Apr 2017 06:32:33 -0700 (PDT) In-Reply-To: <007fba99-77c6-fa69-32e6-3701ffe27c6f@comodo.com> References: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> <007fba99-77c6-fa69-32e6-3701ffe27c6f@comodo.com> From: Richard Barnes Date: Fri, 7 Apr 2017 09:32:33 -0400 Message-ID: To: Rob Stradling Cc: Ben Laurie , Eran Messeri , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a114791f27d6eb7054c93a89f Archived-At: Subject: Re: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Apr 2017 13:32:43 -0000 --001a114791f27d6eb7054c93a89f Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 9:17 AM, Rob Stradling wrote: > On 06/04/17 17:30, Ben Laurie wrote: > >> OK, but it seems to me you've exchanged two lists for one list with a >> bunch of flags. Not sure why this is in any way an improvement? >> > > Do you consider it to be a deprovement? > > I think it: > 1. simplifies the document a bit. > 2. facilitates the writing of one set of code (rather than two sets) to > support SCT extensions and STH extensions. > 3. provides a generic extension mechanism for other sorts of transparency > log objects to use in the future, should the need arise. > Yeah, it's syntactically one thing, so you should only write one encoder / decoder, and the declared syntax should reflect that. One reason I think it's an improvement is that it removes the illusion that the type system will help you distinguish STH and SCT extensions -- with the current definitions, you can just as well shove an STH extn in an SCT and vice versa, since they have the same syntax. If we declare them to have the same syntax, then it's clear to devs that they need to explicitly check that the extn types are allowed. Note that there's prior art here in TLS: > > On 6 April 2017 at 14:51, Eran Messeri wrote: >> >> >> >> On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie > > wrote: >> >> >> On 6 April 2017 at 14:12, Rob Stradling >> > >> wrote: >> >> On 06/04/17 13:27, Eran Messeri wrote: >> >> I intend to adopt Richard's suggestion of merging the >> extension types >> for SCTs and STHs. >> >> Currently there doesn't seem to be a good reason to >> separate the two - >> since the extensions are typed, it'd be easy to >> differentiate between >> the two, and there may be extensions which are shared >> between SCTs and STHs. >> >> This has been reviewed >> in >> https://github.com/google/cert >> ificate-transparency-rfcs/pull/224 >> > tificate-transparency-rfcs/pull/224>, >> rationale updated in >> https://trac.ietf.org/trac/trans/ticket/173 >> . >> >> >> I support this too. >> >> Note: I just did some editorial follow-up work in >> https://github.com/google/certificate-transparency-rfcs/pull >> /244 >> > l/244> >> >> >> Really? I am confused by this plan - surely the extensions for >> STHs and SCTs will be different? So what's the value of allowing >> the wrong ones to be included? >> >> We don't know yet, as no extension has been defined - but for each >> extension, it must be specified whether it should go in the SCT, STH >> or both. >> So we'd simply have a single extensions repository, rather than two. >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114791f27d6eb7054c93a89f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 7, 2017 at 9:17 AM, Rob Stradling <rob.stradling@co= modo.com> wrote:
On 06/04/17 17:30, Ben Laurie wrote:
OK, but it seems to me you've exchanged two lists for one list with a bunch of flags. Not sure why this is in any way an improvement?

 Do you consider it to be a deprovement?

I think it:
1. simplifies the document a bit.
2. facilitates the writing of one set of code (rather than two sets) to sup= port SCT extensions and STH extensions.
3. provides a generic extension mechanism for other sorts of transparency l= og objects to use in the future, should the need arise.

Yeah, it's syntactically one thing, so you should only= write one encoder / decoder, and the declared syntax should reflect that.<= /div>

One reason I think it's an improvement is that= it removes the illusion that the type system will help you distinguish STH= and SCT extensions -- with the current definitions, you can just as well s= hove an STH extn in an SCT and vice versa, since they have the same syntax.= =C2=A0 If we declare them to have the same syntax, then it's clear to d= evs that they need to explicitly check that the extn types are allowed.
=

Note that there's prior art here in TLS:


=C2=A0

On 6 April 2017 at 14:51, Eran Messeri wrote:



=C2=A0 =C2=A0 On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie <benl@google.com
 =C2=A0 =C2=A0 <mailto:benl@google.com>> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 6 April 2017 at 14:12, Rob Stradling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rob.stradling@comodo.com <mailto:rob.stradling@comodo.com= >> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 06/04/17 13:27, Eran Messeri w= rote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I intend to adopt R= ichard's suggestion of merging the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 extension types
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for SCTs and STHs.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Currently there doe= sn't seem to be a good reason to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 separate the two -<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since the extension= s are typed, it'd be easy to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 differentiate betwe= en
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the two, and there = may be extensions which are shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 between SCTs and ST= Hs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This has been revie= wed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/google/certificate-transparency= -rfcs/pull/224
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://github.com/google/certificate-transpar= ency-rfcs/pull/224>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rationale updated i= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://trac.ietf.org/trac/trans/ticket/173
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://trac.ietf.org/trac/trans/ticket/173>.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I support this too.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note: I just did some editorial f= ollow-up work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/google/certificate-transparency-rfcs/pull/244
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://github.com/google/certificate-transparency-rfcs/pu= ll/244>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Really? I am confused by this plan - surely the= extensions for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STHs and SCTs will be different? So what's = the value of allowing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the wrong ones to be included?

=C2=A0 =C2=A0 We don't know yet, as no extension has been defined - but= for each
=C2=A0 =C2=A0 extension, it must be specified whether it should go in the S= CT, STH
=C2=A0 =C2=A0 or both.
=C2=A0 =C2=A0 So we'd simply have a single extensions repository, rathe= r than two.

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

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

--001a114791f27d6eb7054c93a89f-- From nobody Fri Apr 7 06:33:08 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E911294BC for ; Fri, 7 Apr 2017 06:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP_iOQD4X8Oi for ; Fri, 7 Apr 2017 06:33:01 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA8B1242EA for ; Fri, 7 Apr 2017 06:32:53 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id t20so108263738wra.1 for ; Fri, 07 Apr 2017 06:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B9H8fAD+f1ZtNxOR9uyqC4PYjivk9kAzJa3CrwjUww4=; b=kmo9Cj9qJIAMbg1gZk5xmsF5p4O+ASYt7Q4+VsYSixlUWI3A7Y8DH+VvVYmHmQEgp2 Myhoa/Uh2RK7Mg/TjFcYXI6smouR5mm7Jw4CgLHWa4uYnEUrsTCUvNqn0IayemEF09hr ARIXHVcDRVI0do1KIwrhN6liPrAxhgIKLKl70RhGtZ8j4b4n2YFLtI+MaggKsYuKGtwi 5zVBPQLjFnZeqgjAKWDW18ZJeZmnTXBjZwxZEPs6UEjPBk1GF7bEtZcoXp2dWSNzahZM QH8wN6fa0y5nw50vz7mree1/bPgFZvN9I6wPmKGlCrQoqGN8iCFUroCwBMEi8T2AI5T5 WyWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B9H8fAD+f1ZtNxOR9uyqC4PYjivk9kAzJa3CrwjUww4=; b=qV52U3/Mn5FQDVdg/XRu3VMDKmQIWk03MgUK7EXmkpJLPRYFNFuKMAdhT7vrEe2mFb j+BmZ9I+xwzW7eCJMSlgldvf9S7sUIh0AK8JFTV8F3CRAk618iEaIOVLLHW3yWiKtzSy qRX0v7q786TDyK3X1svexEBHxCmVSkN3NpTzrLhjeOw6d22Qpn4jFItBm1B8YSQSOVbI tNSpUKgSE+9j4pUTAaBAJhYG7lqsgvK65pG4Ntk+VysUe54L+cDUwO5n+zonQ1gVqN6v aEXrCNu3adwTIGnB7FeI/Ai4YeC9uivtq5eSMsN+vsw8AkIhRG4wfwze+JsqxDRXLHZe jz4Q== X-Gm-Message-State: AFeK/H0iljxtXWbyqNt5ih8emanHj0GnNVuJvwQgYeSsirrjFZbFRzwTH/eNNnZMpji29sUyABIiL94vE3lv1A== X-Received: by 10.223.169.70 with SMTP id u64mr33609749wrc.187.1491571971842; Fri, 07 Apr 2017 06:32:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.65 with HTTP; Fri, 7 Apr 2017 06:32:51 -0700 (PDT) In-Reply-To: References: <50f609c4-fed8-358b-e684-363cad9e8212@comodo.com> <007fba99-77c6-fa69-32e6-3701ffe27c6f@comodo.com> From: Richard Barnes Date: Fri, 7 Apr 2017 09:32:51 -0400 Message-ID: To: Rob Stradling Cc: Ben Laurie , Eran Messeri , "trans@ietf.org" Content-Type: multipart/alternative; boundary=f403045cf46e89ff5e054c93a945 Archived-At: Subject: Re: [Trans] 6962-bis: Merging the STH and SCT extension types (issue 173) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 07 Apr 2017 13:33:04 -0000 --f403045cf46e89ff5e054c93a945 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 9:32 AM, Richard Barnes wrote: > > > On Fri, Apr 7, 2017 at 9:17 AM, Rob Stradling > wrote: > >> On 06/04/17 17:30, Ben Laurie wrote: >> >>> OK, but it seems to me you've exchanged two lists for one list with a >>> bunch of flags. Not sure why this is in any way an improvement? >>> >> >> Do you consider it to be a deprovement? >> >> I think it: >> 1. simplifies the document a bit. >> 2. facilitates the writing of one set of code (rather than two sets) to >> support SCT extensions and STH extensions. >> 3. provides a generic extension mechanism for other sorts of transparency >> log objects to use in the future, should the need arise. >> > > Yeah, it's syntactically one thing, so you should only write one encoder / > decoder, and the declared syntax should reflect that. > > One reason I think it's an improvement is that it removes the illusion > that the type system will help you distinguish STH and SCT extensions -- > with the current definitions, you can just as well shove an STH extn in an > SCT and vice versa, since they have the same syntax. If we declare them to > have the same syntax, then it's clear to devs that they need to explicitly > check that the extn types are allowed. > > Note that there's prior art here in TLS: > Sorry, hit "send" too soon: https://tlswg.github.io/tls13-spec/#rfc.section.4.2 > > > > >> >> On 6 April 2017 at 14:51, Eran Messeri wrote: >>> >>> >>> >>> On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie >> > wrote: >>> >>> >>> On 6 April 2017 at 14:12, Rob Stradling >>> > >>> wrote: >>> >>> On 06/04/17 13:27, Eran Messeri wrote: >>> >>> I intend to adopt Richard's suggestion of merging the >>> extension types >>> for SCTs and STHs. >>> >>> Currently there doesn't seem to be a good reason to >>> separate the two - >>> since the extensions are typed, it'd be easy to >>> differentiate between >>> the two, and there may be extensions which are shared >>> between SCTs and STHs. >>> >>> This has been reviewed >>> in >>> https://github.com/google/cert >>> ificate-transparency-rfcs/pull/224 >>> >> tificate-transparency-rfcs/pull/224>, >>> rationale updated in >>> https://trac.ietf.org/trac/trans/ticket/173 >>> . >>> >>> >>> I support this too. >>> >>> Note: I just did some editorial follow-up work in >>> https://github.com/google/certificate-transparency-rfcs/pull >>> /244 >>> >> l/244> >>> >>> >>> Really? I am confused by this plan - surely the extensions for >>> STHs and SCTs will be different? So what's the value of allowing >>> the wrong ones to be included? >>> >>> We don't know yet, as no extension has been defined - but for each >>> extension, it must be specified whether it should go in the SCT, STH >>> or both. >>> So we'd simply have a single extensions repository, rather than two. >>> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > --f403045cf46e89ff5e054c93a945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 7, 2017 at 9:32 AM, Richard Barnes <rlb@ipv.sx> wro= te:
<= br>

On Fri, Apr 7, 2017 at 9:17 AM, Rob Stradling &l= t;rob.stradli= ng@comodo.com> wrote:
On 06/04/17 17:30, Ben Laurie wrote:
OK, but it seems to me you've exchanged two lists for one list with a bunch of flags. Not sure why this is in any way an improvement?

 Do you consider it to be a deprovement?

I think it:
1. simplifies the document a bit.
2. facilitates the writing of one set of code (rather than two sets) to sup= port SCT extensions and STH extensions.
3. provides a generic extension mechanism for other sorts of transparency l= og objects to use in the future, should the need arise.

Yeah, it's syntactically one thing, so you shou= ld only write one encoder / decoder, and the declared syntax should reflect= that.

One reason I think it's an improvement = is that it removes the illusion that the type system will help you distingu= ish STH and SCT extensions -- with the current definitions, you can just as= well shove an STH extn in an SCT and vice versa, since they have the same = syntax.=C2=A0 If we declare them to have the same syntax, then it's cle= ar to devs that they need to explicitly check that the extn types are allow= ed.

Note that there's prior art here in TL= S:

Sorry, hit "= ;send" too soon:

=C2=A0


=C2=A0

On 6 April 2017 at 14:51, Eran Messeri wrote:



=C2=A0 =C2=A0 On Thu, Apr 6, 2017 at 2:48 PM, Ben Laurie <benl@google.com
 =C2=A0 =C2=A0 <mailto:benl@google.com>> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 6 April 2017 at 14:12, Rob Stradling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rob.stradling@comodo.com <mailto:rob.stradling@comodo.com= >> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 06/04/17 13:27, Eran Messeri w= rote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I intend to adopt R= ichard's suggestion of merging the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 extension types
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for SCTs and STHs.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Currently there doe= sn't seem to be a good reason to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 separate the two -<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since the extension= s are typed, it'd be easy to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 differentiate betwe= en
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the two, and there = may be extensions which are shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 between SCTs and ST= Hs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This has been revie= wed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/google/certificate-transparency= -rfcs/pull/224
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://github.com/google/certificate-transpar= ency-rfcs/pull/224>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rationale updated i= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://trac.ietf.org/trac/trans/ticket/173
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://trac.ietf.org/trac/trans/ticket/173>.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I support this too.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note: I just did some editorial f= ollow-up work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/google/certificate-transparency-rfcs/pull/244
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://github.com/google/certificate-transparency-rfcs/pu= ll/244>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Really? I am confused by this plan - surely the= extensions for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 STHs and SCTs will be different? So what's = the value of allowing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the wrong ones to be included?

=C2=A0 =C2=A0 We don't know yet, as no extension has been defined - but= for each
=C2=A0 =C2=A0 extension, it must be specified whether it should go in the S= CT, STH
=C2=A0 =C2=A0 or both.
=C2=A0 =C2=A0 So we'd simply have a single extensions repository, rathe= r than two.

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

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


--f403045cf46e89ff5e054c93a945-- From nobody Fri Apr 7 09:25:39 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2942B1293D6 for ; Fri, 7 Apr 2017 08:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PllgWS7Qg-Eb; Fri, 7 Apr 2017 08:55:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7E5129415; Fri, 7 Apr 2017 08:55:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 07 Apr 2017 15:55:18 -0000 Reply-To: trac@localhost.amsl.com X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/51#comment:5 Message-ID: <047.fcfb7302bef3fd8dd97541f923e893fc@ietf.org> References: <032.aebf161e44524b4c9180f0f5165a6064@ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <032.aebf161e44524b4c9180f0f5165a6064@ietf.org> Archived-At: X-Mailman-Approved-At: Fri, 07 Apr 2017 09:25:39 -0700 Subject: Re: [Trans] [Public Notary Transparency Wiki] #51: Test, please disregard X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:55:19 -0000 #51: Test, please disregard -------------------------+--------------------- Reporter: henrik@… | Owner: henrik Type: defect | Status: closed Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------- Comment (by henrik@…): Test -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Mon Apr 10 12:15:26 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED27129AB6 for ; Mon, 10 Apr 2017 12:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1vQtb7yYIJr for ; Mon, 10 Apr 2017 12:15:22 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134D9126DED for ; Mon, 10 Apr 2017 12:15:22 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id s16so37614842pfs.0 for ; Mon, 10 Apr 2017 12:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=JKQgrr++xEGikWDuWgtldlFFvdGfs0y1jaoxgE10Nn4=; b=F/q3KtoVpZ3oVgGl0dHDkXIzRigo41EOhsmml4vGVzv1mBNMyIBB5KbLhiREJOJNz0 u5ExjymmQDBH+obfQb6NjykIHX2rEUOfTIL6Fpw50THxOSnzZJbag2sWBAnQcf/FWpay 8cukRbVO6ArAg9TLE92CQ8fJqO2ZP8NTI2mLngl5uOGJKRm5JSGcsGldYVvBvvY6JoVZ yjAPiQMfEqwmBVnBj09LkmvR0Zr/2te4OyrjoVYClbDb4ej97F2U1SSHKI5izhJ3H3zm 0PTah1buHNzFh/36R2PUvDVJi2xmg5Mg4z9+Hi1m2/ekfYaBIoSp5enGoB3OP+B7oO5B CRdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=JKQgrr++xEGikWDuWgtldlFFvdGfs0y1jaoxgE10Nn4=; b=RNtRbTJs38rrxQvUtf41vD4VupLCFIq+mDNxwxOadRTQUmLoIx3S46f7nzZAKraQ+0 k+tRE3M37CPbeIsC8E1GlcfcRU+tuvhmJhNtCN9FWYYm+ZRf7LbOCjo6i4IwGn6N7MBL 5HLTuv1qmNUTVPxTFuuC4oKO0WEo+1v+FVw6qdOOEurjyibzcRKxli+BMdjCVPz9DeP8 7C9+jl+kzIT1x8KyAn21GwECiZbssZHvtjO0cVqAGDJN8gHheBsU91hmZNLm67cZUema rQOPOzQWyRLKiDbEtqxUSf6YKRUKOeGnaMGxEtk8goEVKF8+9RWUbUUH505r4aopBF2C mnCw== X-Gm-Message-State: AFeK/H0CEAohvnKjOvGY1rQAHQUEZ9/x0onwER93g9T7WoXNJDBJyldPpp3OFoSmIudavg== X-Received: by 10.98.107.194 with SMTP id g185mr57292524pfc.22.1491851721322; Mon, 10 Apr 2017 12:15:21 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (63-140-86-208-radius.dynamic.acsalaska.net. [63.140.86.208]) by smtp.gmail.com with ESMTPSA id f84sm26082281pfa.127.2017.04.10.12.15.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 12:15:20 -0700 (PDT) To: Eran Messeri , "trans@ietf.org" References: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> Cc: martin.thomson@gmail.com From: Melinda Shore Message-ID: Date: Mon, 10 Apr 2017 11:15:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="awSvN47BqoQEFiBM01QmbFB6KjJtNJv4v" Archived-At: Subject: Re: [Trans] RFC 7320 and draft-ietf-trans-rfc6962-bis-24 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Apr 2017 19:15:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --awSvN47BqoQEFiBM01QmbFB6KjJtNJv4v Content-Type: multipart/mixed; boundary="UxXVIA62s0oJC1TR7O9wC7FUbBMt86v5m"; protected-headers="v1" From: Melinda Shore To: Eran Messeri , "trans@ietf.org" Cc: martin.thomson@gmail.com Message-ID: Subject: Re: [Trans] RFC 7320 and draft-ietf-trans-rfc6962-bis-24 References: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> In-Reply-To: --UxXVIA62s0oJC1TR7O9wC7FUbBMt86v5m Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/7/17 1:05 AM, Eran Messeri wrote: > Instead, we could: > (1) Clarify why BCP 190 may not apply here (based on experience > deploying V1 logs) > (2) Remove the 'ct/v2' portion from all the URIs. >=20 > Any preferences? Mine would be for (2), but it's not a strong preferenc= e. I think that in general, when there's a deviation from a BCP it's a good idea to document why it's inapplicable - the question is very likely to come up at some point during the review process. I don't think that removing the ct/v2 portion would be sufficient to resolve the conflict with BCP 190, although it may be desirable for other reasons. Melinda --UxXVIA62s0oJC1TR7O9wC7FUbBMt86v5m-- --awSvN47BqoQEFiBM01QmbFB6KjJtNJv4v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY69nGAAoJELiGRpM6HoEuD/EP/i1OrODRtJBBlIX4DXtc8vEG ndJNpj1679Na6manpqswhrEKJFH6PCDJg5PpZ1uR5zTj+3xFXdZv7jxcz86ij4HK JowxbLLnEdIxyrOQ6kuHFmtKXPuQMD2YWQea1W4dgxoD2DMaUjlNnECrlimoY9Rb 3xkykaDoKGXPS8Frs/ErEbPd6m/4ft1qcs51OdLs46APS5+pCmNGBeppFlak8/Ul 351VtOZBy+nY6yLghMik1uiB2cnbs886Lk8Oys4b9nXxwFQFKJgyATSgylU/Wngs W401GjXxVR39uhbiH2VL41I5zF2IgshwjjxYY+6KKi9UHKh7AJGTjwXFhitE0wKI J7YaJ0hL1NiyZ2IvQ7F7oSMidUkdj1tzla1NswjRBds4TFemOJSDV6Op7/uElAuz QJqZm5V8BakiiSc/xoGe8Tlbfs+IPlw0S08RYPdHH4/ATdrBcmKryFoQoWaWXUdr yQ6HoISyuzH0FI3KcMe0U4Eag5kaolrDfh9vFMvkUBSLfDv53Ie70PUyhQuxoVkb sMtzeLmYsPXOCLdbF1ginpEoU60p+XHYTXmmnSalWO9q+6KurICSNEyZbLDEPE8P STmGXH5cXSd7e8IJeb7kV/b16fNeTbX9kdLqiwk8HP1FkH0Hng8zhxWgNewCb8Kc vXIpSbgClAoj0FikJKiK =cCB0 -----END PGP SIGNATURE----- --awSvN47BqoQEFiBM01QmbFB6KjJtNJv4v-- From nobody Mon Apr 10 16:34:44 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5C3127871 for ; Mon, 10 Apr 2017 16:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaHUCkU2PjNt for ; Mon, 10 Apr 2017 16:34:40 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98FD127011 for ; Mon, 10 Apr 2017 16:34:39 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id h125so78493471lfe.0 for ; Mon, 10 Apr 2017 16:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KeQ0X1DIPFqgZkMgchNCOZZnIQz3zunJCdlJ6JFBf+8=; b=dJ0f8hR5IccjoFWOTh295xmWkujnSd5cJMH2GbICQtCPJ4OQ+MCbh/ixlG6BlZciBn CYgTJmSYx1B2JWPUilKzYprSXnCjvn80f0tn8LcjLo5Fy/ha84BF/yUvjOrw60+psgZe qRxJRdQWCh+y5JV5pk8ViQyWBfIpthrckWmDA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KeQ0X1DIPFqgZkMgchNCOZZnIQz3zunJCdlJ6JFBf+8=; b=SXasiHfSOloKfLNmZGtM7XrhY7O1Am+YAJLb95irZPHuOFUPiqDnnjZ3XIbUIWS7Gp nSrYDAAC5klNZCeZ1R/0RVGiNPB+ay/Trod+RwxrePdPsZyYfnu53EG5nK8WYRdkbnfX 5G0Ccedpq5t5szDVBaIpp+wI6Qxl4vhM4XP9snpy/fJNhN1ESgTe/Z9ADjyJ0oIBFKg9 CVM17YMUsfEvVoWEbt2JRJ7fWiCZvRXd6NLfAkX3ZuDbGCXccKlN2tVNU41/ASsgfWRV YSe4uRGFMdGUDhrGuu0L6kBg+M7icvPWbVdYlzWWrUE9Fn0IlWD+V0KYKElpoHA/s9Uz KbMA== X-Gm-Message-State: AFeK/H1y+huDP3GcbgPSfXCrulxoO9ndXiJyl+SaFJ0gBYFwJrJ0LjSfcpAUD+MZPlWpAtr0mNfvImebD4ggdBiH X-Received: by 10.25.43.205 with SMTP id r196mr16248578lfr.116.1491867277721; Mon, 10 Apr 2017 16:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.9 with HTTP; Mon, 10 Apr 2017 16:34:37 -0700 (PDT) In-Reply-To: References: From: George Tankersley Date: Mon, 10 Apr 2017 19:34:37 -0400 Message-ID: To: Saba Eskandarian Cc: Ben Laurie , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11410dd4241cb9054cd86bd9 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Apr 2017 23:34:42 -0000 --001a11410dd4241cb9054cd86bd9 Content-Type: text/plain; charset=UTF-8 Hey Saba, Read this paper with interest. Thanks for sharing! Am I correct that the range proof signatures are completely unrelated to normal log operation? That is, the ordinary log behavior continue to use commonly supported algorithms (RSA-PKCS1v15 or ECDSA) with only the intermediate range values being signed to admit proofs of signatures under commitment? On Wed, Apr 5, 2017 at 12:27 PM, Saba Eskandarian wrote: > Since there wasn't time to present these privacy preserving proofs at the > meeting last week, I thought it might be of interest to the list that I'll > be presenting the idea at Stanford's annual security workshop next Monday. > I believe it will be streamed on youtube, and you may find the other > presentations interesting as well (http://forum.stanford.edu/ > events/2017security.php). The workshop is aimed at a non-specialist > audience, but I still hope to get to much of the content I meant to present > at ietf. > > thanks, > ~saba > ------------------------------ > *From:* Ben Laurie > *Sent:* Monday, March 27, 2017 2:48:11 AM > > *To:* Saba Eskandarian > *Cc:* trans@ietf.org > *Subject:* Re: [Trans] Privacy-preserving proof of sct exclusion > > > > On 27 March 2017 at 05:16, Saba Eskandarian wrote: > >> Thanks for the prompt feedback! I'll make sure to address these comments >> in my talk, and I'm looking forward to discussing design options in person. >> I suspect that the flexibility of the tools and techniques we use as well >> as the associated engineering and privacy tradeoffs will make for an >> interesting discussion. >> > > Afraid I won't be there, but looking forward to hearing more. > > >> >> Thanks, >> >> ~saba >> ------------------------------ >> *From:* Ben Laurie >> *Sent:* Sunday, March 26, 2017 9:46:21 AM >> *To:* Saba Eskandarian >> *Cc:* trans@ietf.org >> *Subject:* Re: [Trans] Privacy-preserving proof of sct exclusion >> >> >> >> On 25 March 2017 at 22:39, Saba Eskandarian wrote: >> >>> Hello, >>> >>> I'm on the agenda for Tuesday's meeting to share a privacy-preserving >>> proof of sct exclusion from a log (I think Eran alluded to this work in a >>> message a while ago). >>> >>> My posted slides will not include many words, so I wanted to share a >>> link to the preprint of our academic paper on the subject in case anyone >>> wants to read the details there. The paper is targeted at a somewhat >>> different audience, but it can be found here: >>> https://arxiv.org/abs/1703.02209 >>> >>> Thanks and looking forward to meeting you all next week! >>> >> >> Cool, but I immediately see a problem - you require logs to be in >> timestamp order, but they aren't. I can't immediately think of a way to get >> that property without also considerably increasing time to inclusion in the >> log. >> >> That seems undesirable - in fact, we're trying to go the other way, i.e. >> reduce time to inclusion, in general. >> >> Also, engineering reality doesn't change, so increasing time to inclusion >> is also likely to increase MMD. >> >> Secondly, its interesting, but doesn't seem particularly useful: when an >> SCT corresponds to a cert that has not been included, you want to reveal >> the cert, not hide it. What you want to hide is who is revealing it. >> >> ~saba >>> >>> _______________________________________________ >>> 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 > > --001a11410dd4241cb9054cd86bd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Saba,

Read this paper with interest= . Thanks for sharing!

Am I correct that the range = proof signatures are completely unrelated to normal log operation? That is,= the ordinary log behavior continue to use commonly supported algorithms (R= SA-PKCS1v15 or ECDSA) with only the intermediate range values being signed = to admit proofs of signatures under commitment?

On Wed, Apr 5, 2017 at 12:27 PM, = Saba Eskandarian <sabae@stanford.edu> wrote:
Since there wasn't time to present these privacy preserving proofs a= t the meeting last week, I thought it might be of interest to the list that= I'll be presenting the idea at Stanford's annual security workshop next Monday. I believe it will be = streamed on youtube, and you may find the other presentations interesting a= s well (http://forum.stanford.edu/events/2017security= .php). The workshop is aimed at a non-specialist audience, but I still hope to ge= t to much of the content I meant to present at ietf.=C2=A0

thanks,
~saba
From: = Ben Laurie <benl@go= ogle.com>
Sent: Monday, March 27, 2017 2:48:11 AM

To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
=
=C2=A0


On 27 March 2017 at 05:16, Saba Eskandarian <sabae@stanford.= edu> wrote:

Thanks for the prompt=C2=A0feedback!=C2=A0I'll make sure to address these comments in my talk, and I'm looki= ng forward to discussing design options in person. I suspect that the flexi= bility of the=C2=A0tools and techniques we use as well as the=C2=A0associated engineering and privacy tradeoffs=C2=A0will make for a= n interesting discussion.


Afraid I won't be there, but looking forward to hearing more.
=C2=A0


Thanks,

~saba

From: Ben Laurie <benl@google.com>
Sent: Sunday, March 26, 2017 9:46:21 AM
To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
=C2=A0


On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.= edu> wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preservi= ng proof of sct exclusion from a log (I think Eran alluded to this work in = a message a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxi= v.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!


Cool, but I immediately see a problem - you require logs to be in time= stamp order, but they aren't. I can't immediately think of a way to= get that property without also considerably increasing time to inclusion i= n the log.

That seems undesirable - in fact, we're trying to go the other way= , i.e. reduce time to inclusion, in general.

Also, engineering reality doesn't change, so increasing time to in= clusion is also likely to increase MMD.

Secondly, its interesting, but doesn't seem particularly useful: w= hen an SCT corresponds to a cert that has not been included, you want to re= veal the cert, not hide it. What you want to hide is who is revealing it.

~saba


_______________________________________________
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


--001a11410dd4241cb9054cd86bd9-- From nobody Mon Apr 10 19:02:54 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CE1129AB5 for ; Mon, 10 Apr 2017 19:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=office365stanford.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrruWJdDsNIw for ; Mon, 10 Apr 2017 19:02:44 -0700 (PDT) Received: from mx0a-00000d04.pphosted.com (mx0a-00000d04.pphosted.com [148.163.149.245]) (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 252DB12878D for ; Mon, 10 Apr 2017 19:02:44 -0700 (PDT) Received: from pps.filterd (m0102890.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3B1wJNK012735; Mon, 10 Apr 2017 19:02:40 -0700 Received: from mx0b-00000d03.pphosted.com (mx0b-00000d03.pphosted.com [148.163.153.234]) by mx0a-00000d04.pphosted.com with ESMTP id 29rfevsv1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Apr 2017 19:02:39 -0700 Received: from pps.filterd (m0102883.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3B22BNH009474; Mon, 10 Apr 2017 19:02:38 -0700 Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9]) by mx0a-00000d03.pphosted.com with ESMTP id 29rkb79jk6-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Apr 2017 19:02:38 -0700 Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen7.stanford.edu (Postfix) with ESMTP id 1FDBC42; Mon, 10 Apr 2017 19:01:47 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0183.outbound.protection.outlook.com [216.32.181.183]) by codegreen7.stanford.edu (Postfix) with ESMTP id E669842; Mon, 10 Apr 2017 19:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=office365stanford.onmicrosoft.com; s=selector1-stanford-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ahe0BCgZVM6euIWDmazFQDhysptzG1fpbWwXju0oZ94=; b=xL+39yHCzKyQUQCSyAtg0O1qw2PqGm+XYXHyaE1n3GpTvzyJhXkv3Y+zbb3L4hGkHOpWMKcMB/ogqyPN8KnxhwbGnedtGevHvAt5dWVhRecxOS1WfJE6brs1jw5Jw+5VN+N5sB+yX+G6nDBqMsR30xNHXph8RO5F5r002bCxlrQ= Received: from MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) by MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Tue, 11 Apr 2017 02:02:35 +0000 Received: from MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) by MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) with mapi id 15.01.1019.025; Tue, 11 Apr 2017 02:02:35 +0000 From: Saba Eskandarian To: George Tankersley CC: Ben Laurie , "trans@ietf.org" Thread-Topic: [Trans] Privacy-preserving proof of sct exclusion Thread-Index: AQHSpbii8uKV+c47g06WvQijP+zFvqGnVY2AgAC8FcqAAGFqgIAOkm1vgAhVHoCAACci+A== Date: Tue, 11 Apr 2017 02:02:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cloudflare.com; dkim=none (message not signed) header.d=none;cloudflare.com; dmarc=none action=none header.from=stanford.edu; x-originating-ip: [25.175.226.132] x-microsoft-exchange-diagnostics: 1; MWHPR02MB2861; 7:q7nxlAj3ly+VSiuyMJgSzSXnyK3DO5/4dyfBuQjuKnRhtk4PHZ4/9YqPqTQWeHXuTU3s5A4D+wo6NCtJ/VV4BJdt95vTp1ifmfkYUxzsBayR/gWZbTku9aDORZlAJIFAFPOIW9A/U9OQLqZ70nu/wPBxsPoDlH11ZceV1bdXRbBXOo0ocGcsZSWW6z3PbofFbetLCoe1U51s6+ZyD9ciqFuJGEg6hEEsuzn73xWvrbV4FfyV3RKmU0JU2RHsm+I2VZ3REWrG/giF7LQDE5HlX0I+riXXIDx8nWCgi4RrxIYQRwwPkntbuBoIxMY8v4a5m26PQqKuDmZQDDovMspYZQ== x-ms-office365-filtering-correlation-id: ab2d5369-94d6-4f01-2229-08d4807ed2b4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR02MB2861; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(127643986962959)(192374486261705)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:MWHPR02MB2861; BCL:0; PCL:0; RULEID:; SRVR:MWHPR02MB2861; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39450400003)(39840400002)(24454002)(377454003)(51914003)(189998001)(229853002)(75432002)(236005)(16799955002)(53546009)(8936002)(88552002)(25786009)(122556002)(606005)(15188155005)(5660300001)(8676002)(66066001)(53936002)(3660700001)(54896002)(9686003)(6306002)(6246003)(19627405001)(4326008)(6116002)(3280700002)(102836003)(110136004)(38730400002)(7696004)(6506006)(77096006)(6436002)(3846002)(86362001)(99286003)(55016002)(54906002)(50986999)(54356999)(76176999)(7906003)(7736002)(81166006)(93886004)(74316002)(6916009)(33656002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR02MB2861; H:MWHPR02MB2861.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_" MIME-Version: 1.0 X-OriginatorOrg: stanford.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2017 02:02:35.3726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 396573cb-f378-4b68-9bc8-15755c0c51f3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2861 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-11_01:, , signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-11_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704110015 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Apr 2017 02:02:51 -0000 --_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, Thanks for reading the paper! Yes, the signatures we use in our scheme are completely unrelated to the no= rmal operation of the log and only come into play in the event of log misbe= havior. Ordinary log behavior can continue to use standard signatures. The important property of the signatures we use in our scheme is the "proof= of knowledge of a signature." The idea is to use this proof to show that w= e have committed values that actually correspond to objects on the log. We = then use range proofs and other simpler zero knowledge proofs on commitment= s to show that they fulfill the relationships required to complete the proo= f. thanks and let me know if you have any more questions, ~saba ________________________________ From: George Tankersley Sent: Monday, April 10, 2017 4:34:37 PM To: Saba Eskandarian Cc: Ben Laurie; trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion Hey Saba, Read this paper with interest. Thanks for sharing! Am I correct that the range proof signatures are completely unrelated to no= rmal log operation? That is, the ordinary log behavior continue to use comm= only supported algorithms (RSA-PKCS1v15 or ECDSA) with only the intermediat= e range values being signed to admit proofs of signatures under commitment? On Wed, Apr 5, 2017 at 12:27 PM, Saba Eskandarian > wrote: Since there wasn't time to present these privacy preserving proofs at the m= eeting last week, I thought it might be of interest to the list that I'll b= e presenting the idea at Stanford's annual security workshop next Monday. I= believe it will be streamed on youtube, and you may find the other present= ations interesting as well (http://forum.stanford.edu/events/2017security.p= hp). The workshop is aimed at a non-specialist audience, but I still hope t= o get to much of the content I meant to present at ietf. thanks, ~saba ________________________________ From: Ben Laurie > Sent: Monday, March 27, 2017 2:48:11 AM To: Saba Eskandarian Cc: trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion On 27 March 2017 at 05:16, Saba Eskandarian > wrote: Thanks for the prompt feedback! I'll make sure to address these comments in= my talk, and I'm looking forward to discussing design options in person. I= suspect that the flexibility of the tools and techniques we use as well as= the associated engineering and privacy tradeoffs will make for an interest= ing discussion. Afraid I won't be there, but looking forward to hearing more. Thanks, ~saba ________________________________ From: Ben Laurie > Sent: Sunday, March 26, 2017 9:46:21 AM To: Saba Eskandarian Cc: trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion On 25 March 2017 at 22:39, Saba Eskandarian > wrote: Hello, I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago). My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxiv.org/abs/1703.02209 Thanks and looking forward to meeting you all next week! Cool, but I immediately see a problem - you require logs to be in timestamp= order, but they aren't. I can't immediately think of a way to get that pro= perty without also considerably increasing time to inclusion in the log. That seems undesirable - in fact, we're trying to go the other way, i.e. re= duce time to inclusion, in general. Also, engineering reality doesn't change, so increasing time to inclusion i= s also likely to increase MMD. Secondly, its interesting, but doesn't seem particularly useful: when an SC= T corresponds to a cert that has not been included, you want to reveal the = cert, not hide it. What you want to hide is who is revealing it. ~saba _______________________________________________ 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 --_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi George,


Thanks for reading the paper!


Yes, the signatures we use in our scheme are completely unrelated to the= normal operation of the log and only come into play in the event of log mi= sbehavior. Ordinary log behavior can continue to use standard signatures.


The important property of the signatures we use in our scheme is the &qu= ot;proof of knowledge of a signature." The idea is to use this proof t= o show that we have committed values that actually correspond to objects on= the log. We then use range proofs and other simpler zero knowledge proofs on commitments to show that they fulfill the= relationships required to complete the proof.


thanks and let me know if you have any more questions,

~saba

From: George Tankersley <= ;gtank@cloudflare.com>
Sent: Monday, April 10, 2017 4:34:37 PM
To: Saba Eskandarian
Cc: Ben Laurie; trans@ietf.org
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 
Hey Saba,

Read this paper with interest. Thanks for sharing!

Am I correct that the range proof signatures are completely unrelated = to normal log operation? That is, the ordinary log behavior continue to use= commonly supported algorithms (RSA-PKCS1v15 or ECDSA) with only the interm= ediate range values being signed to admit proofs of signatures under commitment?

On Wed, Apr 5, 2017 at 12:27 PM, Saba Eskandaria= n <sabae@stanford.= edu> wrote:
Since there wasn't time to present these privacy preserving proofs at th= e meeting last week, I thought it might be of interest to the list that I'l= l be presenting the idea at Stanford's annual security workshop next Monday. I believe it will be streamed on you= tube, and you may find the other presentations interesting as well (= http://forum.stanford.edu/events/2017security.php). The workshop is aimed at a non-specialist audience, but I still hope to ge= t to much of the content I meant to present at ietf. 

thanks,
~saba
From: = Ben Laurie <benl@go= ogle.com>
Sent: Monday, March 27, 2017 2:48:11 AM

To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 


On 27 March 2017 at 05:16, Saba Eskandarian <sabae@stanford.= edu> wrote:

Thanks for the prompt feedback! I'll make sure to address these comments in my talk, and I'm looking forwa= rd to discussing design options in person. I suspect that the flexibility o= f the tools and techniques we use as well as the associated engineering and privacy tradeoffs will make for a= n interesting discussion.


Afraid I won't be there, but looking forward to hearing more.
 


Thanks,

~saba

From: Ben Laurie <benl@google.com>
Sent: Sunday, March 26, 2017 9:46:21 AM
To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 


On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.= edu> wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxi= v.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!


Cool, but I immediately see a problem - you require logs to be in time= stamp order, but they aren't. I can't immediately think of a way to get tha= t property without also considerably increasing time to inclusion in the lo= g.

That seems undesirable - in fact, we're trying to go the other way, i.= e. reduce time to inclusion, in general.

Also, engineering reality doesn't change, so increasing time to inclus= ion is also likely to increase MMD.

Secondly, its interesting, but doesn't seem particularly useful: when = an SCT corresponds to a cert that has not been included, you want to reveal= the cert, not hide it. What you want to hide is who is revealing it.

~saba


_______________________________________________
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


--_000_MWHPR02MB28619C1224630613F7A2B1C4C3000MWHPR02MB2861namp_-- From nobody Wed Apr 12 09:49:09 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E7A12EAAC for ; Wed, 12 Apr 2017 09:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvtgTSQbKJ9I for ; Wed, 12 Apr 2017 09:48:57 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32836129540 for ; Wed, 12 Apr 2017 09:48:57 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id r69so16609954vke.2 for ; Wed, 12 Apr 2017 09:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tK1MoNgtVTdhR4H9gHT6TpNNf9iB+h0iolL7Vtm1arg=; b=DShj8PKjh9kkCkqc+zpCEreR0SMcZnPVbBqF+s9MBSFrpBHhJ1aW138OS9uF8eddpI OkV71yBowuTZVWLdh5ZU3zUS3v5ssyAa6s9KkatExYh1hIt4Xj816BxurcSkck6giTee 1n1YutsZwgb72ugRSS2DdM+HFh0dshfm4rC7+12QHAmKNNNDNaGGkHxdIKEZ/BPwsFuQ /P3oGe+AjpGKiQ7yAfA3NJf7n24LhluwBZOYFN2ep0Mwn6ECt2oRyT/C2KKSnV86pk44 Cyn/znMJ01SvvrkIn6AOmz2lJoAzxn7nqfUn5NVU4Cv0qo7VcBiMsCFYFW1Y1W0Um/SO on4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tK1MoNgtVTdhR4H9gHT6TpNNf9iB+h0iolL7Vtm1arg=; b=kHYBTKGO7m6lYjqWe7VbZwJWVR9u1O8w/SLnh6O3+LdMkjsrPwex5/EduwQHMhBciX 9DdpX32xoGWceeewym8GSvurOcSnBoD5O28RYZq3UlxJJH4xPjT+hKaGi2HAuseIs5Uv GR9AFl5t9WtLtxIqLnqTONYgwW1S+QejEWmycW4QQQvaKbNIhzeQ3kzDHHLliyVOTvf6 m1gMjW1+vLNdFazYZV2AbsZInERfCgioa6M82FEWc/vz2NP+3qUr7q1x3+2YnCcer0fl HUItGRmWNd82TAuhOrKv1lVXLviZaGi7Pp4mvsKfa3YspU+q4Z65eimFiAeR0R8yvpI/ /Dyg== X-Gm-Message-State: AN3rC/59syrvwgK9haqDPnRP5UKc6Y5iw+6bB/gOyjxBmvNH5rW75MQftEu8LL62zTAzIWBovhVi25wqsux44Qr2 X-Received: by 10.31.222.132 with SMTP id v126mr1421648vkg.128.1492015736027; Wed, 12 Apr 2017 09:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.22 with HTTP; Wed, 12 Apr 2017 09:48:55 -0700 (PDT) In-Reply-To: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> From: Wei Chuang Date: Wed, 12 Apr 2017 09:48:55 -0700 Message-ID: To: Viktor Dukhovni Cc: trans@ietf.org, IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07b1dcf85f70054cfafbcb" Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Apr 2017 16:49:00 -0000 --94eb2c07b1dcf85f70054cfafbcb Content-Type: multipart/alternative; boundary=94eb2c07b1dcf26945054cfafb85 --94eb2c07b1dcf26945054cfafb85 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 8:11 AM, Viktor Dukhovni wrote: > > > On Mar 29, 2017, at 10:33 AM, Wei Chuang wrote: > > > > Why not create an explicit Non-existence of DS (NDS) RR that gets logged > along with DS and NS? > > This is not needed, the NSEC/NSEC3 RRs already serve that role. > > For NSEC records (RFC4034), an unsigned delegation looks like: > > example.com. IN NS ns1.example.com. > example.com. IN NSEC examplf.com NS > example.com. IN RRSIG NSEC ... > > this proves that NS (or other depending on the content of the type > bitmap of the NSEC record) records exist for example.com, but DS > records do not. > > With NSEC3 (rfc5155), and the "opt-out" bit the situation can be > more complex because the answer may not establish the existence of > example.com. Instead we may get an existence proof for the closest > encloser (ancestor domain) and proof that "example.com" is not signed, > but no proof of its existence. This means that to avoid spam, a log > might want to independently verify the existence of the insecure > delegation by repeating the query, so as to avoid storing data for > non-existent domains with the insecure NXDOMAIN modified to NOERROR > with made up NS records. > > Sorry this reply is coming late. Your response helped a lot (thanks!) but I had nagging concern that couldn't make concrete till now. When a DOE lookup occurs on DNSSEC, the authoritative nameserver services the request and determines to respond with what you describe above (the NSEC and its RRSIG). The complication occurs with CT. While we may log the NSEC or NSEC3 record and these records will be present for lookups in CT of existing records, there isn't an online server to assist with lookups in CT of non-existing records. I suppose it may be possible to replicate the state of the authoritative nameserver but consider that this likely doesn't scale as CT servers are servicing a scope potentially much larger than the authoritative nameservers. The approach I describe earlier with an explict Non-existence of DS (NDS) should allow for direct lookup of NDS entry. Also agreed with later comments suggesting that the entire key signing chain needs to be CT logged with its proofs and non-existance records for this to work. -Wei > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --94eb2c07b1dcf26945054cfafb85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 29, 2017 at 8:11 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:

> On Mar 29, 2017, at 10:33 AM, Wei Chuang <weihaw@google.com> wrote:
>
> Why not create an explicit Non-existence of DS (NDS) RR that gets logg= ed along with DS and NS?

This is not needed, the NSEC/NSEC3 RRs already serve that role.

For NSEC records (RFC4034), an unsigned delegation looks like:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 example.com. IN NS ns1.example.com.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 example.com. IN NSEC examplf.com NS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 example.com. IN RRSIG NSEC ...

this proves that NS (or other depending on the content of the type
bitmap of the NSEC record) records exist for example.com, but DS
records do not.

With NSEC3 (rfc5155), and the "opt-out" bit the situation can be<= br> more complex because the answer may not establish the existence of
example= .com.=C2=A0 Instead we may get an existence proof for the closest
encloser (ancestor domain) and proof that "example.com" is not signe= d,
but no proof of its existence.=C2=A0 This means that to avoid spam, a log might want to independently verify the existence of the insecure
delegation by repeating the query, so as to avoid storing data for
non-existent domains with the insecure NXDOMAIN modified to NOERROR
with made up NS records.


Sorry this reply is coming late.=C2=A0 Your re= sponse helped a lot (thanks!) but I had nagging concern that couldn't m= ake concrete till now.

When a DOE lookup occurs on= DNSSEC, the authoritative nameserver services the request and determines t= o respond with what you describe above (the NSEC and its RRSIG).=C2=A0 The = complication occurs with CT.=C2=A0 While we may log the NSEC or NSEC3 recor= d and these records will be present for lookups in CT of existing records, = there isn't an online server to assist with lookups in CT of non-existi= ng records.=C2=A0 I suppose it may be possible to replicate the state of th= e authoritative nameserver but consider that this likely doesn't scale = as CT servers are servicing a scope potentially much larger than the author= itative nameservers.=C2=A0 The approach I describe earlier with an explict= =C2=A0Non-existence of DS (NDS) should all= ow for direct lookup of NDS entry.=C2=A0

Also= agreed with later comments suggesting that the entire key signing chain ne= eds to be CT logged with its proofs and non-existance records for this to w= ork.

-Wei
=C2=A0
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--94eb2c07b1dcf26945054cfafb85-- --94eb2c07b1dcf85f70054cfafbcb Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC2PFhZAwdUCfUiLMrsQOCn XkC1dY8eJXROh3CGsB0bmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA0MTIxNjQ4NTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEArizjkGPGaoSSjcriTPQgeq+VZI4Kcrac21iws+L7 ZD8nJb1V6voECRxUnxWUzZMLAl/ZhDedoKRA2Jbya7HYDO4y0JfEeS6eYxudYrR2iYfVa/Ld95H2 2zSS2vtM7poH2ypLirQZv22A8Ukc1pHPMmlWJLOjNQYtDkGVRuPGDnuYwIvuHfnZsD+z1Lqxne2z qMh6xft9UbItsWBBLfHWs2Rkyr4ys9F8w7GeTQuTpEmE4EN2w4MgrCEg4X1xy7tI+ucO067EVnsg 3bh1Sj7SsXm0fOqXCFDlve7q8DF6QFYBpi3GYdLgETuHbBqB35J5EVQpv8/wd+XKcHxyqxAkXQ== --94eb2c07b1dcf85f70054cfafbcb-- From nobody Mon Apr 17 06:42:35 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D2812778D; Mon, 17 Apr 2017 06:42:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149243655376.17696.15268230922026515965@ietfa.amsl.com> Date: Mon, 17 Apr 2017 06:42:33 -0700 Archived-At: Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-11.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 13:42:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Attack and Threat Model for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-11.txt Pages : 30 Date : 2017-04-17 Abstract: This document describes an attack model and discusses threats for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates are being developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-11 https://datatracker.ietf.org/doc/html/draft-ietf-trans-threat-analysis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-11 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 Apr 17 18:37:13 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A21200C5; Mon, 17 Apr 2017 18:37:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: trans-chairs@ietf.org, pwouters@redhat.com, trans@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149247943116.17676.15464001801348378185.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 18:37:11 -0700 Archived-At: Subject: [Trans] trans - New Meeting Session Request for IETF 99 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:37:11 -0000 A new meeting session request has just been submitted by Paul Wouters, a Chair of the trans working group. --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Paul Wouters Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ipsecme tls dnsop Second Priority: curdle People who must be present: Eric Rescorla Melinda Shore Paul Wouters Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Apr 20 22:30:37 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B646127B52 for ; Thu, 20 Apr 2017 22:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds8sfla2UKJx for ; Thu, 20 Apr 2017 22:30:35 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23738124BFA for ; Thu, 20 Apr 2017 22:30:35 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r16so99618175ioi.2 for ; Thu, 20 Apr 2017 22:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=SEfxiZ5JRBcDEPLwmUFO45Jjv8x1nylHz5mu9cVNRSE=; b=OltblPHHMhK6JBdBO/gJaSZWui9Li1Ro9JT13N51rJewWakABsI3Ypa+BOgRKSJxsH 7gzO7jpQTL7j6iBRBrkRAouFkdOBCw0MkW+DZ3DJOafLwZKN1bTVwVy0pMU5CkR7Mv7q HM7iuEqVKjre7XyJBZRDVPZ7FsK0nKy/IFbCYRm4+quBAAxSpY74NHAtHyhQMZlpOeHM ur5fWCd1hWwBoNzvmayrOjZJQ5InZV5e521s/vHQapXTi1jTtAbGPevaRm2cjZLMfCTs 0FbnURLZVRQZ/Qg+YSiS2P92akufIlbtpMkTZWppazCL+V1jeTNJWhYTTP+MyhRL/TJp 6O1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=SEfxiZ5JRBcDEPLwmUFO45Jjv8x1nylHz5mu9cVNRSE=; b=XXJuf+M8J0aIRnG3D1FN8n2jHPP2TxdSL6+iwuKfyX7MFGUbUUGDUuy7X621p9mTVQ MUZgKMJzYOssw4ysoR+Tmh4rywtc3IMhl+1wkqN5wobKSfLbThofbnCcHm6yiYwY6X7r 1VTeYKgS0uIQSpQOsow96algIhlO/cQ7K7CH1STKoSdiccbqAGQ3I0vUMad6qvKpOEit ti7NmHVxF5WYCfy30bDx5heziA+1vgEfeNlqnWw8ufgahDJR0jZJ+yhHpX0uiQO9LEHH eE1ej55/iCxtywy8SUyTdYxV3NiEky6wWEzDt1DfEcp1gHwhX4NDK1nBabhCALnUWV3i PxWA== X-Gm-Message-State: AN3rC/7XLqg/j9l1bKnpGyQksy5reNQIZiVEROrdSsdVLUAAN4BTiURg +SlrXqTosO7IbCR/B/w= X-Received: by 10.99.164.26 with SMTP id c26mr10735396pgf.89.1492752633054; Thu, 20 Apr 2017 22:30:33 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (209-112-209-61-radius.dynamic.acsalaska.net. [209.112.209.61]) by smtp.gmail.com with ESMTPSA id p68sm13358645pfp.104.2017.04.20.22.30.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 22:30:32 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <28e477fa-0e10-bfdb-3447-f410554f53a0@gmail.com> Date: Thu, 20 Apr 2017 21:30:27 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cuwF1SUJinuRbpB9Gkt8BbW4jMaIsVrIq" Archived-At: Subject: [Trans] Minutes from IETF 98 uploaded X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Apr 2017 05:30:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cuwF1SUJinuRbpB9Gkt8BbW4jMaIsVrIq Content-Type: multipart/mixed; boundary="hHklFO2nXFFN5bF6O46GWd2Hc6LPMF6w6"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <28e477fa-0e10-bfdb-3447-f410554f53a0@gmail.com> Subject: Minutes from IETF 98 uploaded --hHklFO2nXFFN5bF6O46GWd2Hc6LPMF6w6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://www.ietf.org/proceedings/98/minutes/minutes-98-trans-00 Please send corrections, etc., and we'll be working with authors on follow-up from the meeting. Melinda --hHklFO2nXFFN5bF6O46GWd2Hc6LPMF6w6-- --cuwF1SUJinuRbpB9Gkt8BbW4jMaIsVrIq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY+ZjzAAoJELiGRpM6HoEud9wQAKqtiyimzyEtiwniqmy26dNy xM1EBUbw7z+SJNplbc9YCpaT8RGPjfCZH079iKq0zc/vVKQe30sLKKmU5BPaCDJv DLWpLnN9yRv+/Hv++Dkngbvkg34J89L3owynjdjLnyh49QqvbLD8Ufc3rMFdwYce iSchKoL4d8dsnJowb0+FfAa97bYSOtGg7ZQ5WQikdhWYxrNFlefHOfjSocTyiorp h7Uieya1sxCCbmuFAYgtgMqdJLXemr/76pd302oiejDPRWiFY69ZFgKlZI3blvmB sCxemCI5cIMD/ob6cAnlE68MbIgzudp4oNctTOTNJMiGqbJ9aYu7oMk33zIhQkbc UrXcXu8wtQ/9ehPzk3DsNNSMnKjKalVxMrQxs/W0ZSG2+yP4Lt+kaW+NgXxrgvt4 UwwJeN6V1CIZBU9u3v14ubYGFtT0EOB3Jk0vY+BQMQ9KpNjn5FmyUrsSf63Ot1SL aHtnbX0xDMbPHfpp12nTZIMK47iwYVDj3WaEp76e75iVpby7PtzWWjomjIadfwN8 OQJI/EY5XSE7lXPU/M0U/EO9jnht9aAfqWhqMSsjGj9QcDVbMpfRVx09i3M40neU 8iCAfxELVrXgQJb2YBal4RZRVacqkNLIXRpddhn6ye6Z/8F29Dq3jMrGAGvyB7uP E6xmoRU5513wctf/2Ae4 =zUJO -----END PGP SIGNATURE----- --cuwF1SUJinuRbpB9Gkt8BbW4jMaIsVrIq-- From nobody Tue Apr 25 08:17:18 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7039B131630 for ; Tue, 25 Apr 2017 08:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhgUXjF3q0BR; Tue, 25 Apr 2017 08:17:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58434131567; Tue, 25 Apr 2017 08:16:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 25 Apr 2017 15:16:58 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/162#comment:2 Message-ID: <037.05f30efd4768f19c2b53afc67afcb682@ietf.org> References: <022.7212bc2ce646972ebd8eb69407a1fe1b@ietf.org> X-Trac-Ticket-ID: 162 In-Reply-To: <022.7212bc2ce646972ebd8eb69407a1fe1b@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #162: Bound the set of artifacts a log is expected to produce X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 15:17:16 -0000 #162: Bound the set of artifacts a log is expected to produce ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Comment (by eranm@…): Related random thought: If get-proof-by-hash / get-all-by-hash was modified to return a list of TransItems, then it'd be possible to limit the set of artifacts that the log produces. Rather than providing an inclusion proof to the tree size provided by the user, the log could provide an inclusion proof to the STH that covers the desired entry, and then a chain of consistency proofs between that STH and following STHs, up to the tree size provided by the user. -- Ticket URL: Public Notary Transparency Wiki My example project