From nobody Tue Nov 1 02:00:09 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE912995C; Tue, 1 Nov 2016 02:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 68Rq3EfvuWeH; Tue, 1 Nov 2016 02:00:02 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 E5285129955; Tue, 1 Nov 2016 02:00:01 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id uA18xmfd024640 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 1 Nov 2016 09:59:49 +0100 From: Simon Josefsson To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= References: <147610720658.31424.9172801361589123946.idtracker@ietfa.amsl.com> <1345867837.3524.1476107445205.JavaMail.zimbra@nic.cz> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:161101:ondrej.sury@nic.cz::tNyug9fc+FqYB3Fa:6tLF X-Hashcash: 1:22:161101:curdle@ietf.org::ul+lO1wQuL8yPUek:4Cw3 X-Hashcash: 1:22:161101:dnsop@ietf.org::KpSyTTZIc3YQLpMA:EyQl Date: Tue, 01 Nov 2016 09:59:47 +0100 In-Reply-To: <1345867837.3524.1476107445205.JavaMail.zimbra@nic.cz> (=?iso-8859-2?Q?=22Ond=F8ej=09Sur=FD=22's?= message of "Mon, 10 Oct 2016 15:50:45 +0200 (CEST)") Message-ID: <87k2cn3798.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: dnsop , curdle@ietf.org Subject: Re: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 09:00:05 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Hello. I have reviewed this document, and it looks to be in good shape. Two minor comments: 1) The security considerations should reference draft-irtf-cfrg-eddsa for security considerations. Both CFRG-EDDSA and RFC 7748 refer to the expected security level of Ed25519 as "around 128-bit" which reads somewhat better than "slightly under" in my mind. Citing only the security level characteristics (incorrectly) give the reader an impression that Ed448 is "more secure" than Ed25519. More, or less, context is required to give the reader a proper understanding. I suggest to reword the entire security considerations as follows. The third paragraph below is a direct quote from CFRG-EDDSA. Ed25519 and Ed448 offers improved security properties and implementation characteristics compared to RSA and ECDSA algorithms, and the introduction of these algorithms are thus expected to improve security of DNSSEC. The security considerations of [CFRG-EDDSA] and [RFC7748] are inherited in the usage of Ed25519 and Ed448 in DNSSEC. Ed25519 is intended to operate at around the 128-bit security level, and Ed448 at around the 224-bit security level. A sufficiently large quantum computer would be able to break both. Reasonable projections of the abilities of classical computers conclude that Ed25519 is perfectly safe. Ed448 is provided for those applications with relaxed performance requirements and where there is a desire to hedge against analytical attacks on elliptic curves. These assessments could, of course, change in the future if new attacks that work better than the ones known today are found. 2) Section 9 "Implementation Status" does not seem useful. Thanks, /Simon Ond=F8ej Sur=FD writes: > Dear colleagues, > > this is just a refresh to keep the draft going > as we are still waiting for irtf-cfrg-eddsa, but > that looks like it's in IESG Review, so it might > be a good time to have a final look and send the > comments to /me or Robert or curdle WG mailing list. > > 1. https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/ > > Cheers, > -- > Ond=F8ej Sur=FD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Forwarded Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: curdle@ietf.org > Sent: Monday, 10 October, 2016 15:46:46 > Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the CURves, Deprecating and a Little more En= cryption of the IETF. > > Title : EdDSA for DNSSEC > Authors : Ondrej Sury > Robert Edmonds > Filename : draft-ietf-curdle-dnskey-eddsa-01.txt > Pages : 8 > Date : 2016-10-10 > > Abstract: > This document describes how to specify EdDSA keys and signatures in > DNS Security (DNSSEC). It uses the Edwards-curve Digital Security > Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-dnskey-eddsa-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJYGFmDAAoJEIYLf7sy+BGdd9oH/RU3Af4M4dEOl9imccC1EmzX YIMW2kSHCTxBPvIAg+s6C4W4W9Rh3wIO7uyAPoqOBZ/otphoe1QMPHlI9cBaZVdO h/I/oGBxLMIlN606OblMBCAdarkSjGdacYgBe/FyJl1i1PPWe290CPvN8ae246bR Cbqm6JbjzUXMwpjBimKq7fOIRIKaGNzj6wJ6wUSuQOHrnMIW3KY6PEqMhSl9ndwS WGurkKVIwdWjLSt97rJ3SxUYQRHPcWzFwpw8Gn8VygGk5CIizGdUsmUoh77153ws +Zq+yBM6uJtIec9LiDfthKnEAKg1wlfLmQSX1DF5WsoqPIlWI/4FkKXlUnV2JEc= =4RSS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 1 07:48:33 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209DD129706; Tue, 1 Nov 2016 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 9q8aS1MeuCMO; Tue, 1 Nov 2016 07:48:28 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 597801294C5; Tue, 1 Nov 2016 07:48:28 -0700 (PDT) Received: from [10.32.60.19] (50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id uA1EmOgJ015582 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Nov 2016 07:48:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-99-230.dsl.dynamic.fusionbroadband.com [50.1.99.230] claimed to be [10.32.60.19] From: "Paul Hoffman" To: curdle@ietf.org Date: Tue, 01 Nov 2016 07:48:29 -0700 Message-ID: <06414D87-E6CD-4C8F-A670-1A3280D25DAD@vpnc.org> In-Reply-To: <87k2cn3798.fsf@latte.josefsson.org> References: <147610720658.31424.9172801361589123946.idtracker@ietfa.amsl.com> <1345867837.3524.1476107445205.JavaMail.zimbra@nic.cz> <87k2cn3798.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: dnsop Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 14:48:29 -0000 I agree with both of Simon's points. His new wording for the Security Considerations is quite close to what we have in the other documents, and we might as well remove Section 9 because we're advancing the document regardless of implementations. --Paul Hoffman From nobody Wed Nov 2 18:07:52 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1626F129409; Wed, 2 Nov 2016 18:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUccsre7xABl; Wed, 2 Nov 2016 18:07:50 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 71564129859; Wed, 2 Nov 2016 18:02:04 -0700 (PDT) X-AuditID: c6180641-e73ff70000000a0b-20-581a3822467f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 78.7A.02571.2283A185; Wed, 2 Nov 2016 20:01:56 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 21:02:01 -0400 From: Daniel Migault To: Simon Josefsson , =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= Thread-Topic: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt Thread-Index: AQHSNB5rPG94hlGEhk+F5NnGNqetx6DGb8Zw Date: Thu, 3 Nov 2016 01:02:00 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117FD362E@eusaamb107.ericsson.se> References: <147610720658.31424.9172801361589123946.idtracker@ietfa.amsl.com> <1345867837.3524.1476107445205.JavaMail.zimbra@nic.cz> <87k2cn3798.fsf@latte.josefsson.org> In-Reply-To: <87k2cn3798.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPoK6KhVSEwYpfhhZbF85itrj75jKL RctyF4t7Wy6xO7B4LFnyk8lj5pmL7B6bLt9hDGCO4rJJSc3JLEst0rdL4Mrof3edveC3WsXu ruAGxpnyXYycHBICJhK7Nu9m62Lk4hASWM8ocej2QSYIZxmjxIkLM9lAqtgEjCTaDvWzdzFy cIgIJElMWq8OEmYWsJc4ue00WImwgI/E+odToUp8JaYviwIJiwB19nVtZQQJswioSMyYaAES 5gWq+DPvE9TatUBrj05jBUlwChhKXNi5B8xmFBCT+H5qDRPEKnGJW0/mM0HcLCCxZM95Zghb VOLl43+sELaSxJzX15gh6vUknp2axQJha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYh aVnAyLKKkaO0uCAnN93IcBMjMEqOSbA57mDc2+t5iFGAg1GJh9fguGSEEGtiWXFl7iFGCQ5m JRHeX51SEUK8KYmVValF+fFFpTmpxYcYpTlYlMR5r4fcDxcSSE8sSc1OTS1ILYLJMnFwSjUw xqziWlMxL2P+/2liZy9vENN8cLFR8N3SFdPfTr6Qom/hO9Nllm2e7231LN7UOZOPza9fsm/9 /gTX1Aytv48n2SbvfNJ9+6OkN/vnNYyX+mYs9dvR6610VFRy9XEFqZKVaSox23lvyRfrGUse 5ClgztK+mn7m289XPwvrWB6faBFe2ry8o/vxKyWW4oxEQy3mouJEAKeQYSWOAgAA Archived-At: Cc: dnsop , "curdle@ietf.org" Subject: Re: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 01:07:52 -0000 Hi,=20 Thank you for the reviews. Looks we are almost ready for LC. Please take a = few minute and review the document. =20 I have a minor comment. It has been suggested that IPv6 was used in the exa= mple. Does anyone object using only IPv6 example versus IPv4/IPv6 or IPv4 o= nly?=20 Yours,=20 Rich and Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Simon Josefsson Sent: Tuesday, November 01, 2016 5:00 AM To: Ond=F8ej Sur=FD Cc: dnsop ; curdle@ietf.org Subject: Re: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.tx= t Hello. I have reviewed this document, and it looks to be in good shape. Two minor comments: 1) The security considerations should reference draft-irtf-cfrg-eddsa for s= ecurity considerations. Both CFRG-EDDSA and RFC 7748 refer to the expected= security level of Ed25519 as "around 128-bit" which reads somewhat better = than "slightly under" in my mind. Citing only the security level character= istics (incorrectly) give the reader an impression that Ed448 is "more secu= re" than Ed25519. More, or less, context is required to give the reader a = proper understanding. I suggest to reword the entire security considerations as follows. The thi= rd paragraph below is a direct quote from CFRG-EDDSA. Ed25519 and Ed448 offers improved security properties and implementation characteristics compared to RSA and ECDSA algorithms, and the introduction of these algorithms are thus expected to improve security of DNSSEC. The security considerations of [CFRG-EDDSA] and [RFC7748] are inherited in the usage of Ed25519 and Ed448 in DNSSEC. Ed25519 is intended to operate at around the 128-bit security level, and Ed448 at around the 224-bit security level. A sufficiently large quantum computer would be able to break both. Reasonable projections of the abilities of classical computers conclude that Ed25519 is perfectly safe. Ed448 is provided for those applications with relaxed performance requirements and where there is a desire to hedge against analytical attacks on elliptic curves. These assessments could, of course, change in the future if new attacks that work better than the ones known today are found. 2) Section 9 "Implementation Status" does not seem useful. Thanks, /Simon Ond=F8ej Sur=FD writes: > Dear colleagues, > > this is just a refresh to keep the draft going as we are still waiting=20 > for irtf-cfrg-eddsa, but that looks like it's in IESG Review, so it=20 > might be a good time to have a final look and send the comments to /me=20 > or Robert or curdle WG mailing list. > > 1. https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/ > > Cheers, > -- > Ond=F8ej Sur=FD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Forwarded Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: curdle@ietf.org > Sent: Monday, 10 October, 2016 15:46:46 > Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the CURves, Deprecating and a Little more En= cryption of the IETF. > > Title : EdDSA for DNSSEC > Authors : Ondrej Sury > Robert Edmonds > Filename : draft-ietf-curdle-dnskey-eddsa-01.txt > Pages : 8 > Date : 2016-10-10 > > Abstract: > This document describes how to specify EdDSA keys and signatures in > DNS Security (DNSSEC). It uses the Edwards-curve Digital Security > Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-dnskey-eddsa-01 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Nov 2 20:55:17 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DA4129435; Wed, 2 Nov 2016 20:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 WGGOlr1RA--T; Wed, 2 Nov 2016 20:55:11 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 5326012940F; Wed, 2 Nov 2016 20:55:11 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 128so59760052oih.0; Wed, 02 Nov 2016 20:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=NAM599oN+jxtWTVBAQcZ8Nq2LgByxQzZRALSmISmXsY=; b=iLmbzeDZ39PlGbaf4zCluNTgzIk+W4qXmnk+Ii2bg2njyQ8PYFejpCve1FQSaSaoYs gZsV28ozieSG4rdQVqZHMXVtB6qvfNTG6w3LhABENA5puUgRpi2Xqx8g6QgF6BkyN3gY jOYrcoynnkS+qxKEZfzpaiMZFPDc+doMQpK+uctKVVs9+oLlZn7AMPw47W5DCNSYdikR ZHpEa1y3af5npq1XEHkYjKLJetxUPaNTJvkMBLWDmdRsBlaolaKEbN67MYc4SfkmOHtd wnQbMtU9cFWoNfXmDhG/2+lu26B34Gk8W0mHx1jiFlewOF/YCRTFW4VXgOWZDrnfItQf J31g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=NAM599oN+jxtWTVBAQcZ8Nq2LgByxQzZRALSmISmXsY=; b=Hsf9w0Li/Y9kbvJqu39FeB0MVNcIkXUGS/PpODS1XrrQKHT9JnXsaEyz0TTqDS8V/J IASQQhVJqt7VVPYgHBbtmwHnIOxgnWouO+eWXanVSBTaEua6YdruHxI1SI9PzSyESG7g iWCAojStAvWr1/qRYbyeUw/1lH5NFlWsyIGEPJAQuZ8nakuxAB3h90ojy3H2fs0gzuBH 8NrWYc/ty1VNdMhm0erg9LvbOKSedDugKrYJlPClbrofuosIzOA2/3NozjCyYEkvBfQn f6tJW7OR2dBEDXRi/bpn1kEc2JLbQSWsFqVUbbuV60gJabm75sfDNZ/Ir6ntthnoZerx B6Ew== X-Gm-Message-State: ABUngvfVQ1ZQFfdXm+e/U1H0rK53KDQYAykF/HPgcUL8N1fTOWJFgjcYsV7gTTevRcucKFGIs97/keZUIapZPQ== X-Received: by 10.107.28.148 with SMTP id c142mr6833412ioc.45.1478145310521; Wed, 02 Nov 2016 20:55:10 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Wed, 2 Nov 2016 20:55:10 -0700 (PDT) From: Daniel Migault Date: Wed, 2 Nov 2016 23:55:10 -0400 X-Google-Sender-Auth: l1-Y1Y7qt_qUl-LjI8rvgGjansc Message-ID: To: curdle@ietf.org, dnsop Content-Type: multipart/alternative; boundary=001a113fd4b828fe1d05405d8629 Archived-At: Subject: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 03:55:13 -0000 --001a113fd4b828fe1d05405d8629 Content-Type: text/plain; charset=UTF-8 Hi, This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-dnskey-eddsa-01. The version to be reviewed is https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 Please send your comments, questions, and edit proposals to the WG mail list until November 16th, 2016. If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this. Yours, Rich and Daniel --001a113fd4b828fe1d05405d8629 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This message starts a Working Group Last Call (WGL= C) for draft-ietf-curdle-dnskey-eddsa-01.

The version to be reviewed is https://tools.ietf.org/html/draft-ietf-curdle-= dnskey-eddsa-01

Please send your comments, questions, and edit proposals to the WG mail=20 list until November 16th, 2016.=C2=A0 If you believe that the document is= =20 ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.

Yours,

Rich and Daniel

--001a113fd4b828fe1d05405d8629-- From nobody Wed Nov 2 20:55:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA808129894 for ; Wed, 2 Nov 2016 20:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5WDmxkB_KON for ; Wed, 2 Nov 2016 20:55:23 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 D2E1B1296C9 for ; Wed, 2 Nov 2016 20:55:22 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id x4so59359883oix.2 for ; Wed, 02 Nov 2016 20:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=JD11XDQScEgb5C9rEfZLR2AqGvOWVcW8KTf6gCi+nfY=; b=I+Prspp+KrRcSgGpNyEobYHgSUzCKG718dSzysv4s2iMFwABt7N4hWHZKdhjWQ11a+ S7oRimvQiyzYzWwcDGHyPPJl0ACYjH6fWA1Dh1abLD3v8701lHz3XqojkF2uKtHAwYzt Rycz6rB/1s3ntrOgkIxfCRD3XYp6IcyX7p8gCTzEfIF2k4CdomOBIm6FGhLiqYvhKHx3 5IsXDyZA6Xt1G7wHXnqwCLZiyMV2ftYuH3kQHbUAB3CGrXfH+HO94QN3GQ1yYZ0RsgWc 7ktZm63YbLW3oSb58Sz/QK+HlnnlkU5GUyqnc5vXxaG6IRcw4GhsdOycR9ZNsZR+rGPk 92zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=JD11XDQScEgb5C9rEfZLR2AqGvOWVcW8KTf6gCi+nfY=; b=ZlEbdFlYdNWVZni9uyfs/LjiOf03rSaTS4rIqQETlDf6iQiI4zdr3t2785TaFEyIwS XoBcRrdxRPqLtaDutjr1w5YKJyFHRLctOIBOXOYaZxtp2qT3i4lbt7DvtrnNf96ct1jB 8zlVhWZQEf94FMGVBfMuu6ophBVdQPrRWE0PIQM9e1K1+kTMorGb87jcstNv5czW1xVw Z1yUJU4abKde7M2NlahSlL+EJQdEzIp/lOoSwVHWjMY4w1OnY91Bf8NN+C3tkyjADl7r mwXw0GY8Uh47xd1mjVZtbPw4O/J4OlUGQs5gmDqhDXvUpfN7g4ufVwU3wkdddiBKxlYs ymuw== X-Gm-Message-State: ABUngve3FEChDRNQsfVzctNxMiJqcjhjnqSlFBsrm4IjHXuzFd6516VyYLq9N+eqTxtUJDEn+lbsSMS164gNAA== X-Received: by 10.107.179.195 with SMTP id c186mr6975334iof.35.1478145322111; Wed, 02 Nov 2016 20:55:22 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Wed, 2 Nov 2016 20:55:21 -0700 (PDT) From: Daniel Migault Date: Wed, 2 Nov 2016 23:55:21 -0400 X-Google-Sender-Auth: jtoWb-4IprpdOUb7XaiSxlF3df8 Message-ID: To: curdle@ietf.org Content-Type: multipart/alternative; boundary=001a11484830d9ec4005405d86b3 Archived-At: Subject: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 03:55:26 -0000 --001a11484830d9ec4005405d86b3 Content-Type: text/plain; charset=UTF-8 Hi, This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-pkix-02. The version to be reviewed is https://tools.ietf.org/html/draft-ietf-curdle-pkix-02 Please send your comments, questions, and edit proposals to the WG mail list until November 16th, 2016. If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this. Yours, Rich and Daniel --001a11484830d9ec4005405d86b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11484830d9ec4005405d86b3-- From nobody Wed Nov 2 21:10:08 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7572D12957B; Wed, 2 Nov 2016 21:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lVAf5erfBUB; Wed, 2 Nov 2016 21:10:06 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 339101294F8; Wed, 2 Nov 2016 21:10:06 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id p16so21374833qta.0; Wed, 02 Nov 2016 21:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BXU2/78YhEqTXQWFIrzguVdiBz5Fk22VD0mncy9cLbo=; b=HT5ZvO76FJTABEXoTV9cnXkLty8srciThp3tKjhlgjounibNHuw463cmb574lah5DY GqFYOKuM7xd52U3Tbm9ktLo6PGG6QFNB7HD8D/nwEM0XDIymMGBgVexJRgzhGO0lYeEm 2u4uWnB4Ka5TvLqu35bpn3pTIoc10T2ZjVymiY8EU47RnpcreieC4OnhFAtYO8nL/BWQ 4/H7tNa46RoQRQbqfwcx+GBCmMATc2COUfgHPbs4JRFs3J8n2G20b7sEvZJDMGUGkVsv CpwDya5Pr1gI4Am7BeEC6F4Wfq/ZSuE3fGozbbCLuggukMbBPprpmaF5CN08IIlhai/e 94mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BXU2/78YhEqTXQWFIrzguVdiBz5Fk22VD0mncy9cLbo=; b=BAaPraCbGiWrslh1hk0yuOdHWI6JpBeUT3xJy36GVUTOiW5f7WPjB4CfUUyY9oE8cO PKhNIhrbwFWK6aRPRfZQrOGo/HxrdXL+hbOwaiiWiVEwdKKY43hLsBaORw1NvvZJVtyB 6joZ5+IX6sqnT+RTXSOmPodUNZYyvr69a6Q7QwKMJcJU3W/cjRS3pajZRY7RZjhQT+aB KWAsA3y1D51Zkt1Z5xJ9BHplK2AgcuCOEGmo+gSOQ4x/CD0/nkHBXLgvdzMfHZolDTKy +EbHrjithn5+dD6ZTEQq4wToQbS7tIjuc5oy88o8dRo3S1h9pq5YNiBO+Y/ZRuj57F0x 8vYw== X-Gm-Message-State: ABUngvfgRwrCvHA1ud7XTsUntiBXbZaXo6ivpUXFBe8Rk+hSnSjlsstPpOzWD2fOwwoKx03R5jONQW+UecMffQ== X-Received: by 10.200.50.227 with SMTP id a32mr6227019qtb.32.1478146205415; Wed, 02 Nov 2016 21:10:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 21:10:04 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 3 Nov 2016 15:10:04 +1100 Message-ID: To: Daniel Migault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: curdle@ietf.org, dnsop Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 04:10:07 -0000 On 3 November 2016 at 14:55, Daniel Migault wrote: > The version to be reviewed is > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 Does this use Ed25519 or Ed25519ctx? It describes a context string, which Ed25519 throws away. From nobody Thu Nov 3 02:15:32 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97A71293FC; Thu, 3 Nov 2016 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd8fOLtU0dJy; Thu, 3 Nov 2016 02:15:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D1F12983F; Thu, 3 Nov 2016 02:15:24 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 2FF3D61E0A; Thu, 3 Nov 2016 10:15:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1478164523; bh=1PAz7oF2HjQmrkFrZRLusx2T3kYoQyuUBU+dp3R+b44=; h=Date:From:To; b=m5642+CxWDGbCps7wH3zqFFieAQTGzrYdMvqtZQWgzNpXjuLGiu7C5d2bDFk9UYEd heTkCv+7ljnFE3i6IBc/Uohfphsevc2Av1AO/jB17742bqkBTEgj6B/kor2tqg/dBM hNz+lt1aanmFxKSE6ZgRHF7TIpkGEs4aKctJS5/E= Date: Thu, 3 Nov 2016 10:15:23 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Daniel Migault Message-ID: <262535437.14802.1478164523021.JavaMail.zimbra@nic.cz> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C117FD362E@eusaamb107.ericsson.se> References: <147610720658.31424.9172801361589123946.idtracker@ietfa.amsl.com> <1345867837.3524.1476107445205.JavaMail.zimbra@nic.cz> <87k2cn3798.fsf@latte.josefsson.org> <2DD56D786E600F45AC6BDE7DA4E8A8C117FD362E@eusaamb107.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt Thread-Index: AQHSNB5rPG94hlGEhk+F5NnGNqetx6DGb8ZwH1n+XU0= X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: dnsop , curdle Subject: Re: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:15:27 -0000 It's just a DNS record. It doesn't matter what's inside, so I'll replace the example with something neutral like MX. O. -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Daniel Migault" > To: "Simon Josefsson" , "Ond=C5=99ej Sur=C3=BD" > Cc: "dnsop" , "curdle" > Sent: Thursday, 3 November, 2016 02:02:00 > Subject: RE: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.= txt > Hi, >=20 > Thank you for the reviews. Looks we are almost ready for LC. Please take = a few > minute and review the document. >=20 > I have a minor comment. It has been suggested that IPv6 was used in the e= xample. > Does anyone object using only IPv6 example versus IPv4/IPv6 or IPv4 only? >=20 > Yours, >=20 > Rich and Daniel >=20 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Simon Josefsso= n > Sent: Tuesday, November 01, 2016 5:00 AM > To: Ond=C5=99ej Sur=C3=BD > Cc: dnsop ; curdle@ietf.org > Subject: Re: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.= txt >=20 > Hello. I have reviewed this document, and it looks to be in good shape. > Two minor comments: >=20 > 1) The security considerations should reference draft-irtf-cfrg-eddsa for > security considerations. Both CFRG-EDDSA and RFC 7748 refer to the expec= ted > security level of Ed25519 as "around 128-bit" which reads somewhat better= than > "slightly under" in my mind. Citing only the security level characterist= ics > (incorrectly) give the reader an impression that Ed448 is "more secure" t= han > Ed25519. More, or less, context is required to give the reader a proper > understanding. >=20 > I suggest to reword the entire security considerations as follows. The t= hird > paragraph below is a direct quote from CFRG-EDDSA. >=20 > Ed25519 and Ed448 offers improved security properties and > implementation characteristics compared to RSA and ECDSA algorithms, > and the introduction of these algorithms are thus expected to improve > security of DNSSEC. >=20 > The security considerations of [CFRG-EDDSA] and [RFC7748] are > inherited in the usage of Ed25519 and Ed448 in DNSSEC. >=20 > Ed25519 is intended to operate at around the 128-bit security level, > and Ed448 at around the 224-bit security level. A sufficiently large > quantum computer would be able to break both. Reasonable projections > of the abilities of classical computers conclude that Ed25519 is > perfectly safe. Ed448 is provided for those applications with > relaxed performance requirements and where there is a desire to hedge > against analytical attacks on elliptic curves. >=20 > These assessments could, of course, change in the future if new > attacks that work better than the ones known today are found. >=20 > 2) Section 9 "Implementation Status" does not seem useful. >=20 > Thanks, > /Simon >=20 > Ond=C5=99ej Sur=C3=BD writes: >=20 >> Dear colleagues, >> >> this is just a refresh to keep the draft going as we are still waiting >> for irtf-cfrg-eddsa, but that looks like it's in IESG Review, so it >> might be a good time to have a final look and send the comments to /me >> or Robert or curdle WG mailing list. >> >> 1. https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/ >> >> Cheers, >> -- >> Ond=C5=99ej Sur=C3=BD -- Technical Fellow >> -------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >> Milesovska 5, 130 00 Praha 3, Czech Republic >> mailto:ondrej.sury@nic.cz https://nic.cz/ >> -------------------------------------------- >> >> ----- Forwarded Message ----- >> From: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> Cc: curdle@ietf.org >> Sent: Monday, 10 October, 2016 15:46:46 >> Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the CURves, Deprecating and a Little more >> Encryption of the IETF. >> >> Title : EdDSA for DNSSEC >> Authors : Ondrej Sury >> Robert Edmonds >> =09Filename : draft-ietf-curdle-dnskey-eddsa-01.txt >> =09Pages : 8 >> =09Date : 2016-10-10 >> >> Abstract: >> This document describes how to specify EdDSA keys and signatures in >> DNS Security (DNSSEC). It uses the Edwards-curve Digital Security >> Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-dnskey-eddsa-01 >> >> >> 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.ie= tf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Nov 3 02:36:53 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D941297C5; Thu, 3 Nov 2016 02:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9FGfMNJ5y2H; Thu, 3 Nov 2016 02:36:46 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0082.outbound.protection.outlook.com [104.47.33.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEA61297BD; Thu, 3 Nov 2016 02:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EcH+oK5PnMfDPHQPksMs11Bqa+hiPjhxwFnDSgWe/YQ=; b=bXLDbe611dlk9HXtcYg0xueG8DjQoUKkefR7GO4ZIcg+B7KisVlOBXQpOuEjOY7AEQcMfNZYckROXxEPaIduzsxr2DwfhEU7NnXbh+3iJrZ8ItEl7RNSAbz+CMjjqGVn9Vmj0uJaLsHnOIaRYdLpmWBlQAtHXYKtIZC/aFEdwW8= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Thu, 3 Nov 2016 09:36:43 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.0693.016; Thu, 3 Nov 2016 09:36:43 +0000 From: Dan York To: Daniel Migault Thread-Topic: [DNSOP] WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: AQHSNYYYL1YS2EziZ0qqFE0aSlRXoqDHAIVI Date: Thu, 3 Nov 2016 09:36:42 +0000 Message-ID: <402D3EB2-3F06-4039-A4E3-D457B3082E19@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-ms-office365-filtering-correlation-id: 6164e9d4-453e-4929-5357-08d403ccebe0 x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1657; 7:rDgO+drp4Cons0war7ZXRwjBZDwLX3O9cQh181dHDCRyqniJQaD6FzPgk6cmXYlthFzTBQG4IPHrdipJsSSCxFvjBGlbxBOCaPuA0+v/0nDmePlP4IgnoKHoAj9STl3aJ7FTO11w/vOCiw/+cZ3tsX4S1aQPy4N9lM7d4SBsV0SGCRkD3dR6xWv4uKiHp5M0z5TwaZrs+NP+m1btbELOImeepeuQJuoUlpVabCWVMSyHFr7ev7+m3iUtSsp3odOmkXbx8fpWL0R74INZ2iU8pa0uL9+cQSmPs6AZV8JtKEwTu2ku3nuEO+w+C/mzYQLY1byqs8aD3xAEyk/CwNMwpaQ2sZEvX3Ih+fE3l/GtVo8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1657; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0601MB1657; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1657; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(24454002)(377454003)(11100500001)(19580405001)(36756003)(102836003)(6116002)(3846002)(76176999)(50986999)(54356999)(586003)(97736004)(6916009)(2906002)(4326007)(2950100002)(33656002)(16236675004)(19580395003)(68736007)(122556002)(10400500002)(19617315012)(81166006)(81156014)(101416001)(8676002)(5002640100001)(106356001)(106116001)(105586002)(8936002)(99286002)(82746002)(77096005)(66066001)(110136003)(83716003)(15975445007)(230783001)(92566002)(7906003)(7846002)(86362001)(3280700002)(7736002)(2900100001)(3660700001)(5660300001)(189998001)(87936001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1657; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_402D3EB23F064039A4E3D457B3082E19isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 09:36:42.3023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1657 Archived-At: Cc: "curdle@ietf.org" , dnsop Subject: Re: [Curdle] [DNSOP] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:36:48 -0000 --_000_402D3EB23F064039A4E3D457B3082E19isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daniel, On Nov 2, 2016, at 11:55 PM, Daniel Migault > wrote: If you believe that the document is ready to be submitted to the IESG for c= onsideration as a Standards Track RFC please send a short message stating t= his. >From a DNS perspective I support the draft as it seems very much in line wi= th other similar drafts and RFCs specifying DNSSEC algorithms. I believe th= is adds useful capabilities to DNSSEC and should proceed. That said, I will need to defer to others to confirm the details of the EdD= SA usage as I do not have experience with those crypto algorithms. One minor editorial nit. In section 4 there are multiple references to the = "Chapter" of another draft. Example: ---- The Ed25519 signature algorithm is described in Chapter 5.1.6 in [I-D.irtf-cfrg-eddsa]. ---- In US English a "chapter" is typically reserved for a "book". I think the b= etter term here might be "Section", but I don't know if there is specific g= uidance anywhere on what to call areas of another I-D. Thank you to the authors for moving this forward. Dan --_000_402D3EB23F064039A4E3D457B3082E19isocorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Daniel,

On Nov 2, 2016, at 11:55 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
If you believe that the document is ready to be submitted to the IESG for c= onsideration as a Standards Track RFC please send a short message stating t= his.
From a DNS perspective I support the draft as it seems very much in li= ne with other similar drafts and RFCs specifying DNSSEC algorithms. I belie= ve this adds useful capabilities to DNSSEC and should proceed. 

That said, I will need to defer to others to confirm the details of th= e EdDSA usage as I do not have experience with those crypto algorithms.&nbs= p;

One minor editorial nit. In section 4 there are multiple references to= the "Chapter" of another draft. Example:
----
The Ed25519 =
signature algorithm is described in Chapter
   5.1.6 in [I-D.irtf-cfrg-eddsa].=

----<=
/font>

<=
/font>
In US Englis=
h a "chapter" is typically reserved for a "book". I thi=
nk the better term here might be "Section", but I don't know if t=
here is specific guidance anywhere on what to call areas of another I-D.

<=
/font>
Thank you to=
 the authors for moving this forward. 

<=
/font>
Dan
--_000_402D3EB23F064039A4E3D457B3082E19isocorg_-- From nobody Thu Nov 3 06:57:48 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA82D129A35 for ; Thu, 3 Nov 2016 06:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] 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 wWKDfFCcBtSK for ; Thu, 3 Nov 2016 06:57:44 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 17E6D129A18 for ; Thu, 3 Nov 2016 06:57:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 63400119EF; Thu, 3 Nov 2016 15:57:42 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id SrdeXFlyPNA2; Thu, 3 Nov 2016 15:57:41 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C79EB21C; Thu, 3 Nov 2016 15:57:41 +0200 (EET) Date: Thu, 3 Nov 2016 15:57:39 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20161103135739.GA10408@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: Daniel Migault , curdle@ietf.org Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:57:47 -0000 On Thu, Nov 03, 2016 at 03:10:04PM +1100, Martin Thomson wrote: > On 3 November 2016 at 14:55, Daniel Migault wrote: > > The version to be reviewed is > > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 > > Does this use Ed25519 or Ed25519ctx? It describes a context string, > which Ed25519 throws away. Well, if it has context, it can't be Ed25519 (because that can't have context)... Dunno if that is wanted (note that Ed25519ctx can't be computed with standard issue Ed25519 code (white-box changes aren't great). Also, even if I seemed to have come up with the idea, I don't like it now (due to usage difficulty). -Ilari From nobody Thu Nov 3 08:28:55 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C8D12944B for ; Thu, 3 Nov 2016 08:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssPuHxYQAkbP for ; Thu, 3 Nov 2016 08:28:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C64129504 for ; Thu, 3 Nov 2016 08:28:26 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 9F11D61284; Thu, 3 Nov 2016 16:28:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1478186905; bh=k1Jj5GYEYa7RXJs+QTklaHGZKsJkhJublZpSMPEgYEs=; h=Date:From:To; b=HhCq0JMwH2M4/o4Kpv6JGgAs4FL9qslWoPPMicz8+Zr+sDTbjMh0AToyIyUj3LceD aDEK3wL6LwwgXhKnNC9KdEXg6TMrTu0jWTFHcijCxQQlkTXMNwQXhzVMbPjrNhgqGY aOXbcNfY54EnzKZLzBRsyVedKJJWZcp40abP3cSs= Date: Thu, 3 Nov 2016 16:28:25 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Ilari Liusvaara Message-ID: <1519267046.15113.1478186905413.JavaMail.zimbra@nic.cz> In-Reply-To: <20161103135739.GA10408@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161103135739.GA10408@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: y/WJhRc0gPjB6xlCjLNlGk377zn4gw== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Daniel Migault , Martin Thomson , curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:28:54 -0000 Ilari and rest of WG, I also think it would be easier from implementation perspective for Ed25519= . What about Ed448? Should I keep the context there or drop it as well? Cheers, Ondrej -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Ilari Liusvaara" > To: "Martin Thomson" > Cc: "Daniel Migault" , "curdle" > Sent: Thursday, 3 November, 2016 14:57:39 > Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > On Thu, Nov 03, 2016 at 03:10:04PM +1100, Martin Thomson wrote: >> On 3 November 2016 at 14:55, Daniel Migault wrote: >> > The version to be reviewed is >> > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 >>=20 >> Does this use Ed25519 or Ed25519ctx? It describes a context string, >> which Ed25519 throws away. >=20 > Well, if it has context, it can't be Ed25519 (because that can't have > context)... Dunno if that is wanted (note that Ed25519ctx can't be > computed with standard issue Ed25519 code (white-box changes aren't > great). >=20 > Also, even if I seemed to have come up with the idea, I don't like > it now (due to usage difficulty). >=20 >=20 > -Ilari >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Nov 3 08:46:15 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CCF129A7F; Thu, 3 Nov 2016 08:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRCAL2Kori6K; Thu, 3 Nov 2016 08:45:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0E7129A66; Thu, 3 Nov 2016 08:45:55 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 5141260B32; Thu, 3 Nov 2016 16:45:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1478187954; bh=V++cZOzd9t8MHPjk0SlUtzGtG5twt+7HZVKetCiXVE0=; h=Date:From:To; b=G6YoIQJrmftZFukFZmkloY9LHtral1ThT82oV3eE9yMZZDNzWZwW1bifugGtHi4j1 iFyXwoFNRQ0CRh3bQ3LJiEtV0km5i7MIcu+gKC0aKgQAl4jVuUuVWFFkah0pfcD4fT RqwiozcNo/j9ERJbvoZOi6JhzfLTntXB1awkhHYA= Date: Thu, 3 Nov 2016 16:45:54 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Daniel Migault Message-ID: <1202447570.15121.1478187954183.JavaMail.zimbra@nic.cz> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: dUuMIxd8z1F/FoZ0/66sY+okvCY8JQ== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: curdle , dnsop Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:45:58 -0000 Dear all, I have incorporated the comments from Simon changing Security Considerations and removing the Section about Implementations. I have also clarified usage of context. The context label is used only for Ed448. I have also updated the example for Ed25519, but I would really appreciate if somebody could review the script used to generate the examples:=20 https://gitlab.labs.nic.cz/labs/ietf/blob/master/dnskey.py The updated drafts can't be uploaded, but I uploaded the last version to our gitlab: XML: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dnsk= ey-eddsa.xml TXT: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dnsk= ey-eddsa.txt HTML: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dns= key-eddsa.html O. -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Daniel Migault" > To: "curdle" , "dnsop" > Sent: Thursday, 3 November, 2016 04:55:10 > Subject: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > Hi, >=20 > This message starts a Working Group Last Call ( WGLC ) for > draft-ietf-curdle-dnskey-eddsa-01. >=20 > The version to be reviewed is [ > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 | > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 ] >=20 > Please send your comments, questions, and edit proposals to the WG mail l= ist > until November 16th, 2016. If you believe that the document is ready to b= e > submitted to the IESG for consideration as a Standards Track RFC please s= end a > short message stating this. >=20 > Yours, >=20 > Rich and Daniel >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Nov 3 14:02:08 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138801298AD; Thu, 3 Nov 2016 14:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 k2RSWwqaEZs3; Thu, 3 Nov 2016 14:02:01 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 2269E129952; Thu, 3 Nov 2016 14:01:54 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id uA3L1dMv026761 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 3 Nov 2016 22:01:41 +0100 From: Simon Josefsson To: Daniel Migault References: OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:161103:dnsop@ietf.org::d1ybCHGpVbu2Mk8Q:2fd4 X-Hashcash: 1:22:161103:curdle@ietf.org::VNYeE8bSLlHjODcE:5TgS X-Hashcash: 1:22:161103:daniel.migault@ericsson.com::DQMejCETarR7dDi8:6Lf2 Date: Thu, 03 Nov 2016 22:01:38 +0100 In-Reply-To: (Daniel Migault's message of "Wed, 2 Nov 2016 23:55:10 -0400") Message-ID: <87zilgnuq5.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: curdle@ietf.org, dnsop Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 21:02:05 -0000 --=-=-= Content-Type: text/plain Daniel Migault writes: > Hi, > > This message starts a Working Group Last Call (WGLC) for > draft-ietf-curdle-dnskey-eddsa-01. > > The version to be reviewed is > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 Hello again. Since my last review of -01, I have re-read the document again, and noticed the text regarding signature contexts. I believe the use of contexts is in general ill-advised, and its presence in the document highlights a need for a security consideration to address the problem that context attempts to mitigate but does not succeed with: don't re-use private keys for other purposes. If this best practice advice is followed, contexts is unwanted complexity instead of something good. If a private key is used for other purposes, contexts won't save you -- DJB explained this on the CFRG list some time ago in a way that convinced me. Thus, allow me to suggest that 1) The draft is modified to not use signature contexts. 2) The security consideration has a new paragraph that reads: A private key used for a DNSSEC zone MUST NOT be used for any other purpose than for that zone. Otherwise cross-protocol or cross-application attacks are possible. Perhaps this text is better suited in the Introduction section, but it bears repeating in the security consideration anyway. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJYG6WyAAoJEIYLf7sy+BGdHMwH/jNbURAyekmFJoGWB6UsFdeH 8kUkm5gT3FVEI870qNsAhvaYo8DdzhOb8NTzfvYEmq4hE2Af4tQP3LZX7v/48nle TIC9grB4NnonT52v8TeibjDxBjmfNYJOtZL+3cDHg5GgstY4YvZFAqfydt/hQtmi e7poTTq3HpRt85UXZ4YBADzoFDz7Bs6DFKiILmIUr+4CNftLfmjooEBD0E0Mg0lV v0tp1OYbbEVTRtuqVpCN8m2QEhjJRfpv1UkspqifNwWZzZ0kWy4NQ9bn1hgYLYv4 q26J34AC0jRvPSVNCrmKFRW7a33fqHzLwpbyEnE41yDffBkBpk1LFjtS0TtvaoM= =PVQW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 3 15:11:26 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F3112956B; Thu, 3 Nov 2016 15:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eixy6_6afTDq; Thu, 3 Nov 2016 15:11:09 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1BA129405; Thu, 3 Nov 2016 15:11:09 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 93681496C73; Thu, 3 Nov 2016 22:11:08 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7D599496C2E; Thu, 3 Nov 2016 22:11:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478211068; bh=PCTlWLyH40mPvgBuY5g37uHL/XWO1Kt8bownaXhUNgo=; l=397; h=From:To:CC:Date:References:In-Reply-To:From; b=HNm7Aaiylh29zc857AoQPV1Dg48oCpAappLscuDMMqZjHUFR0f58Z2Ro3/R8SxlbJ 5yfUUg5rHBTIa+UZMcLOIPr4p9uaJ0NNogaTlsr5ZUyT3SrVipOOKZ5IDzR8QZAipF fpijrNxEwbkhmvDwiJymPX+Ot3pzykquWG7NrV14= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 6465A98082; Thu, 3 Nov 2016 22:11:08 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 3 Nov 2016 18:11:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 3 Nov 2016 18:11:07 -0400 From: "Salz, Rich" To: Simon Josefsson , Daniel Migault Thread-Topic: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: AQHSNYYjslvZ6PbNrEGf5NMB7BwQK6DHwBz5gAAS+MA= Date: Thu, 3 Nov 2016 22:11:06 +0000 Message-ID: <7579ec9d5f3b46e5bfbf868eb35e4204@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87zilgnuq5.fsf@latte.josefsson.org> In-Reply-To: <87zilgnuq5.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.0] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" , dnsop Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:11:13 -0000 I think the issue about signature contexts first, and mainly, came up with= TLS which generates a variety of private key material based on shared secr= et info, and the concern that those different keys could be used for cross= -protocol attacks. But I could be wrong. :) -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Nov 3 16:31:09 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028F4129453; Thu, 3 Nov 2016 16:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntr9RR1vF2gF; Thu, 3 Nov 2016 16:31:03 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 83A12127A90; Thu, 3 Nov 2016 16:31:03 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id v84so118958012oie.3; Thu, 03 Nov 2016 16:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lfgPN6Gm0YKDc8sm4H4bpd4SOyh3hDQDfvLrUbQ9pLY=; b=OdZd/e0G+Jx/jI/HVLxEdv61sSnTzGYa3+iV6bOdw1DSutHf/weSbD4gifAn5yBbi9 BEqJ3oj33Dv5S+iFHa7wEDfOC1EGeGNB093tSVQ4xfnD0JmJzyWccEsOZ1hJ6W7TUfCI FxkP2POaVH6L97w90qS33Vecs+lfePA14QlY+wsgYpssWxOy77pv1XE0pO/f0QJlON/t VM3z1jSj6FpGXwVBCIccLsMN7UH5oC0bSDpG+R9kcPYo3BNeMzJnZQuAqfp+YwcLdJj2 Pz+4y2yJRy7rJjMXCXXxbmkS0tXh5hlXDcAl8kTda40nSzOBYIOyvycrVy0xDNzry0L4 OMaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lfgPN6Gm0YKDc8sm4H4bpd4SOyh3hDQDfvLrUbQ9pLY=; b=Vs2J12FV/zl+bXp12Rf2YoHGVOt8ZQgli52459IVVQNY01D4KCZk8p/FBjnsiIle/y Oa4wKkZ8SH21DUU3RqEYy24q/jzfq2dIVcDfb3Y8denlC1OTn3xsCpHhN/6c5dTawtur 5jsdFjFqKNYgX10JoXBW3/bMS/lv12RUWCBnC3NvW+apuXyyLp4cI+MDDo12eznzGVke TBvOEIXJkmcb+HJsh7eEwiQvWaiJwsK/LOuuKOS/YP3XJHvZH+gDCJRtnCmXOHSjLVig ix81nXIB31AWZRixob5G8x3bBOQTFyiw3OWvIllOden2q+WtgivANoPhGq1dE4Bzsab1 sXEQ== X-Gm-Message-State: ABUngveKFy/8LeLuEzX57NnVfWl+uvb8DCXrYtMhawZCs039464CGvL3ukWDzYWLMoX5gvWtABEfJvSjUJrOfw== X-Received: by 10.36.95.2 with SMTP id r2mr222290itb.48.1478215862769; Thu, 03 Nov 2016 16:31:02 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Thu, 3 Nov 2016 16:31:02 -0700 (PDT) In-Reply-To: <7579ec9d5f3b46e5bfbf868eb35e4204@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87zilgnuq5.fsf@latte.josefsson.org> <7579ec9d5f3b46e5bfbf868eb35e4204@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Thu, 3 Nov 2016 19:31:02 -0400 X-Google-Sender-Auth: RGUJJvyPB0IC70bPQ9epVsyWgpU Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11448ce066deb605406df3ce Archived-At: Cc: Simon Josefsson , "curdle@ietf.org" , dnsop Subject: Re: [Curdle] [DNSOP] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 23:31:05 -0000 --001a11448ce066deb605406df3ce Content-Type: text/plain; charset=UTF-8 This is also my understanding. but I might be wrong as well. Yours, Daniel On Thu, Nov 3, 2016 at 6:11 PM, Salz, Rich wrote: > I think the issue about signature contexts first, and mainly, came up > with TLS which generates a variety of private key material based on shared > secret info, and the concern that those different keys could be used for > cross-protocol attacks. > > But I could be wrong. :) > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a11448ce066deb605406df3ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is also my understanding. but I might be wr= ong as well.

Yours,
Daniel

On Thu, Nov 3, 2016 at 6:11 PM, S= alz, Rich <rsalz@akamai.com> wrote:
I think the issue about signature=C2=A0 contexts first, and mainl= y, came up with TLS which generates a variety of private key material based= on shared secret info, and the concern that those different keys could be = used for=C2=A0 cross-protocol attacks.

But I could be wrong. :)

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: R= ichSalz

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

--001a11448ce066deb605406df3ce-- From nobody Thu Nov 3 18:03:21 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958861295FA; Thu, 3 Nov 2016 18:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcVVD0mgYg9b; Thu, 3 Nov 2016 18:03:19 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4911294FD; Thu, 3 Nov 2016 18:03:19 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id p16so39550038qta.0; Thu, 03 Nov 2016 18:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wu1tsOs1QBuUqRYcGQrQJrxZ1TtrSmjNwZsRGoV6Mu8=; b=DPDvTg5BaCbQQQ75l4lV0ZPMFZHw3BkWjPh1u9gePyws8+rdkDDHNYdifj2wpqrqgs J1TvzQ2EltkARhVPAQl8aBIs4m/cr0dHXRf3QrxJ6f7N8pRCuLK7zsgvuH20TFhgOkYU HmE1nTTzuRNsYc9uPN+itn6dsElC0ZC+M+5mLQayYJUhy92XfI1Sqrin+ykPTbAzS0ns H1ZE65FYZmXOYbzjsZAppybpddR5OfVDPChUNG60lMpUQ5K6QGp/IvmxqQqrtd+uAJiI n0b9CYq2mDr9e5pc54rLtt6QXUP48MVABal3lsGTmtOVAwRuNvrJTwlmlktvVZSuePsX heGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wu1tsOs1QBuUqRYcGQrQJrxZ1TtrSmjNwZsRGoV6Mu8=; b=CSpWxPQ+nISvnTDuD/R/q0yRhyc65LmR2xhvLR4OLi/nl+lv6AwxzoRjquyItAUa/L 2YJE0aKep77bB24Jh95//libUMGnEcVMsrkNBVmcFUhr4/zy8ntM8V8FaQ9l1RDMic5A ADNYAhgp8JE/TX7ulyEEwoALKnxs3IaFe45/yNHlHVqLbTGZwFh3Qn7H2AsMW8RgWiTQ iBrTvToktDHvdmqJDNH3iZHLSbszKVaz6d4mXWjOwRXeGaaJj8AARpc8ZB69gnIGvgmH 3LlPDMWxANdykxZngCKTf4zGLi62qOsQ4Jvh5T6G/Q8cXiXNybZd0uAoNIRQsaCjS4rs ocKA== X-Gm-Message-State: ABUngvfQOYmKkGtij8l/cwJjQV595nujULbnY2RePsSxcv0fpJnSWYOh57yMY0Ek8OZ0Fvg/dJC1BLDRdzyM/A== X-Received: by 10.200.56.27 with SMTP id q27mr11759135qtb.116.1478221398355; Thu, 03 Nov 2016 18:03:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 3 Nov 2016 18:03:17 -0700 (PDT) In-Reply-To: <7579ec9d5f3b46e5bfbf868eb35e4204@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87zilgnuq5.fsf@latte.josefsson.org> <7579ec9d5f3b46e5bfbf868eb35e4204@usma1ex-dag1mb1.msg.corp.akamai.com> From: Martin Thomson Date: Fri, 4 Nov 2016 12:03:17 +1100 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dnsop , Simon Josefsson , Daniel Migault , "curdle@ietf.org" Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:03:20 -0000 On 4 November 2016 at 09:11, Salz, Rich wrote: > I think the issue about signature contexts first, and mainly, came up with TLS which generates a variety of private key material based on shared secret info, and the concern that those different keys could be used for cross-protocol attacks. There are a lot of ways that keys (particularly those in certificates) might be used. Context strings reduce the chances that those keys are misused such that data from one context can be transplanted into another. Simon's proposal works better in this context. If only all keys were so single-minded. From nobody Fri Nov 4 03:45:42 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DEC129C06; Fri, 4 Nov 2016 03:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRkagRYceSLG; Fri, 4 Nov 2016 03:45:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3CD129C0A; Fri, 4 Nov 2016 03:45:15 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 52AFB61043; Fri, 4 Nov 2016 11:45:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1478256314; bh=IxM47DT3khhgiUK86XOEy242WxLZJS1iJY9eg/uUe2g=; h=Date:From:To; b=cc1qaIP2n+/uux7bPSIsWe82GpAOwBQycqBGno0O12D954E3b+HaX6/I4QhViqf1O cCwCHlo9SrAA0TuPeQBQ2Urkr//2omMH1a/yHW/vUp2b1vwpMH2sfG+7xVAf0Woa2n CMAW/1Q0U9rvQERFlSb3H51zytQocl24EfDTsqIs= Date: Fri, 4 Nov 2016 11:45:14 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Simon Josefsson Message-ID: <409432402.15443.1478256314166.JavaMail.zimbra@nic.cz> In-Reply-To: <87zilgnuq5.fsf@latte.josefsson.org> References: <87zilgnuq5.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: aM+oNBSVy5iq3yXU9rbrQu0xyoxNxQ== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: dnsop , Daniel Migault , curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 10:45:41 -0000 Simon, thanks for all the comments, I have now culled all the context usage from t= he draft and the git version should be up to date and ready for -2 upload. Cheers, Ondrej -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Simon Josefsson" > To: "Daniel Migault" > Cc: "curdle" , "dnsop" > Sent: Thursday, 3 November, 2016 22:01:38 > Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > Daniel Migault writes: >=20 >> Hi, >> >> This message starts a Working Group Last Call (WGLC) for >> draft-ietf-curdle-dnskey-eddsa-01. >> >> The version to be reviewed is >> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 >=20 > Hello again. Since my last review of -01, I have re-read the document > again, and noticed the text regarding signature contexts. I believe the > use of contexts is in general ill-advised, and its presence in the > document highlights a need for a security consideration to address the > problem that context attempts to mitigate but does not succeed with: > don't re-use private keys for other purposes. If this best practice > advice is followed, contexts is unwanted complexity instead of something > good. If a private key is used for other purposes, contexts won't save > you -- DJB explained this on the CFRG list some time ago in a way that > convinced me. >=20 > Thus, allow me to suggest that >=20 > 1) The draft is modified to not use signature contexts. >=20 > 2) The security consideration has a new paragraph that reads: >=20 > A private key used for a DNSSEC zone MUST NOT be used for any other > purpose than for that zone. Otherwise cross-protocol or > cross-application attacks are possible. >=20 > Perhaps this text is better suited in the Introduction section, but it > bears repeating in the security consideration anyway. >=20 > /Simon >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Nov 4 04:59:28 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BD9129995; Fri, 4 Nov 2016 04:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J-MPGWIiK9L; Fri, 4 Nov 2016 04:59:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A3D129983; Fri, 4 Nov 2016 04:59:23 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 2A30861145; Fri, 4 Nov 2016 12:59:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1478260762; bh=QAIUjYZce9SlqjiGBkDsXyEcOlk9l+tcmrPmZrQyCj4=; h=Date:From:To; b=SA74NuizYA4mDeF3pKX8svYAEiZqhDlh9OxaAmtb+/ugMVnJToNMjRQRog155VWRJ qdywYMBoO63te0flJ+jxVtGneyPaVwKPWsdF/VrbpxX8QpHIPGdPme3UxZrMKUu5Uq duONlt01U6/yX552288G4qVTKecatyQA0z38Lx0E= Date: Fri, 4 Nov 2016 12:59:22 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Simon Josefsson Message-ID: <1916626070.15450.1478260762132.JavaMail.zimbra@nic.cz> In-Reply-To: <409432402.15443.1478256314166.JavaMail.zimbra@nic.cz> References: <87zilgnuq5.fsf@latte.josefsson.org> <409432402.15443.1478256314166.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: aM+oNBSVy5iq3yXU9rbrQu0xyoxNxXkdqIkM X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: dnsop , Daniel Migault , curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 11:59:26 -0000 And now the examples section contains Ed448 examples as well generated using eddsa2.py from [CFRG-EDDSA] draft. I think now the draft is as good as it gets. Thanks all for providing guidance. O. -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Ond=C5=99ej Sur=C3=BD" > To: "Simon Josefsson" > Cc: "Daniel Migault" , "curdle" , "dnsop" > Sent: Friday, 4 November, 2016 11:45:14 > Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > Simon, >=20 > thanks for all the comments, I have now culled all the context usage from= the > draft and the git version should be up to date and ready for -2 upload. >=20 > Cheers, > Ondrej >=20 > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- >=20 > ----- Original Message ----- >> From: "Simon Josefsson" >> To: "Daniel Migault" >> Cc: "curdle" , "dnsop" >> Sent: Thursday, 3 November, 2016 22:01:38 >> Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 >=20 >> Daniel Migault writes: >>=20 >>> Hi, >>> >>> This message starts a Working Group Last Call (WGLC) for >>> draft-ietf-curdle-dnskey-eddsa-01. >>> >>> The version to be reviewed is >>> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 >>=20 >> Hello again. Since my last review of -01, I have re-read the document >> again, and noticed the text regarding signature contexts. I believe the >> use of contexts is in general ill-advised, and its presence in the >> document highlights a need for a security consideration to address the >> problem that context attempts to mitigate but does not succeed with: >> don't re-use private keys for other purposes. If this best practice >> advice is followed, contexts is unwanted complexity instead of something >> good. If a private key is used for other purposes, contexts won't save >> you -- DJB explained this on the CFRG list some time ago in a way that >> convinced me. >>=20 >> Thus, allow me to suggest that >>=20 >> 1) The draft is modified to not use signature contexts. >>=20 >> 2) The security consideration has a new paragraph that reads: >>=20 >> A private key used for a DNSSEC zone MUST NOT be used for any other >> purpose than for that zone. Otherwise cross-protocol or >> cross-application attacks are possible. >>=20 >> Perhaps this text is better suited in the Introduction section, but it >> bears repeating in the security consideration anyway. >>=20 >> /Simon >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Nov 4 18:00:38 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8423312940B; Fri, 4 Nov 2016 18:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 myKTThqu63hC; Fri, 4 Nov 2016 18:00:30 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 4A5461293E0; Fri, 4 Nov 2016 18:00:30 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m138so12641369itm.1; Fri, 04 Nov 2016 18:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=j3vSHQ5v0KwHgszQvxxc11BecI//4peG9JDvaY0kJSA=; b=wR9q70r16xB3sK4AI9y814bE4aaYoZekEIOGGfKnKnl2YXMSlekpJcDEixC6ZOzovc kikELgw2dSb22DxcqkMbMqvqrOyGhfr0+8DtHFV/UMLz++iDHqCVy2GAtntXl4RzTrJU f2OFyQ0d9y8OmRrdeFFfIxJC02wd4OBUgXq/4CRDSIh/mr3/S/77Em6z3G2uwBfIos97 l+uz4NBm2qmM8JuRFTd3+BSrPH9T54Yefr0z5Il7QsMh+mxWMr555pudHEg9xEA3vQwN rgWBmdBaQh3O3/SOLFtkJUkI0cDMRBbpecMMQWIQssMsy626GdfHeLXxA3EGldXtfnA5 B9Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=j3vSHQ5v0KwHgszQvxxc11BecI//4peG9JDvaY0kJSA=; b=N97Rvl+147a5yS2AVktFF9/ZX/x8pMvaTpIEOwoCiPsgtcqQVuVQBE0/qOs3Q2M8+9 rBnC2e+FUz5pN5wI18H3SbdHuAeONHQSGC5imL64ACewwTMBBMxvcnGuJA4mAUxs/e3f iW8VCf5HpZcjP1EcOYWBE1epphqvgLXcywsWQnofSxIqXZ90xn7U7vyEspGjLL3N5oIU 3polHcdqWCSmbNiLu3fcEx+ZVtubfsbw2UZ9ak4AvJNxvRpGRWBYOlqT0MSW8ZslMdPJ Y+f9n1arDo3rSLTo9m87xxU2Ll5YiE4N6R4AaRaDdeyynHOJHHCsJ9j1FHQKp4iuBFCg 1wmg== X-Gm-Message-State: ABUngve1jIZP0j5V04FxrKrM46x618Egm0AlFQfdKkoc4EhpP0bxHvEZYh8hFM5X5RLAQtt0nMkHAL9z+JWEqw== X-Received: by 10.107.179.195 with SMTP id c186mr15399736iof.35.1478307629560; Fri, 04 Nov 2016 18:00:29 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Fri, 4 Nov 2016 18:00:29 -0700 (PDT) In-Reply-To: <1916626070.15450.1478260762132.JavaMail.zimbra@nic.cz> References: <87zilgnuq5.fsf@latte.josefsson.org> <409432402.15443.1478256314166.JavaMail.zimbra@nic.cz> <1916626070.15450.1478260762132.JavaMail.zimbra@nic.cz> From: Daniel Migault Date: Fri, 4 Nov 2016 21:00:29 -0400 X-Google-Sender-Auth: Oo9SQTShh1P1F8PdLtGWqJy9qDs Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001a1148483020f6c905408351a6 Archived-At: Cc: Simon Josefsson , dnsop , curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 01:00:32 -0000 --001a1148483020f6c905408351a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the update. I think that woudl be helpful to have some text that provides some rational for using Ed25519 versus Ed25519ph and Ed25519ctx as well as Ed448 versus Ed448ph. I belive that is collision resilience as well as offline signing in which case double path does not really matter. Yours, Daniel On Fri, Nov 4, 2016 at 7:59 AM, Ond=C5=99ej Sur=C3=BD = wrote: > And now the examples section contains Ed448 examples as well > generated using eddsa2.py from [CFRG-EDDSA] draft. > > I think now the draft is as good as it gets. Thanks all for > providing guidance. > > O. > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "Ond=C5=99ej Sur=C3=BD" > > To: "Simon Josefsson" > > Cc: "Daniel Migault" , "curdle" < > curdle@ietf.org>, "dnsop" > > Sent: Friday, 4 November, 2016 11:45:14 > > Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > > > Simon, > > > > thanks for all the comments, I have now culled all the context usage > from the > > draft and the git version should be up to date and ready for -2 upload. > > > > Cheers, > > Ondrej > > > > -- > > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > > -------------------------------------------- > > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > > Milesovska 5, 130 00 Praha 3, Czech Republic > > mailto:ondrej.sury@nic.cz https://nic.cz/ > > -------------------------------------------- > > > > ----- Original Message ----- > >> From: "Simon Josefsson" > >> To: "Daniel Migault" > >> Cc: "curdle" , "dnsop" > >> Sent: Thursday, 3 November, 2016 22:01:38 > >> Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > > > >> Daniel Migault writes: > >> > >>> Hi, > >>> > >>> This message starts a Working Group Last Call (WGLC) for > >>> draft-ietf-curdle-dnskey-eddsa-01. > >>> > >>> The version to be reviewed is > >>> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 > >> > >> Hello again. Since my last review of -01, I have re-read the document > >> again, and noticed the text regarding signature contexts. I believe t= he > >> use of contexts is in general ill-advised, and its presence in the > >> document highlights a need for a security consideration to address the > >> problem that context attempts to mitigate but does not succeed with: > >> don't re-use private keys for other purposes. If this best practice > >> advice is followed, contexts is unwanted complexity instead of somethi= ng > >> good. If a private key is used for other purposes, contexts won't sav= e > >> you -- DJB explained this on the CFRG list some time ago in a way that > >> convinced me. > >> > >> Thus, allow me to suggest that > >> > >> 1) The draft is modified to not use signature contexts. > >> > >> 2) The security consideration has a new paragraph that reads: > >> > >> A private key used for a DNSSEC zone MUST NOT be used for any other > >> purpose than for that zone. Otherwise cross-protocol or > >> cross-application attacks are possible. > >> > >> Perhaps this text is better suited in the Introduction section, but it > >> bears repeating in the security consideration anyway. > >> > >> /Simon > >> > >> _______________________________________________ > >> Curdle mailing list > >> Curdle@ietf.org > > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1148483020f6c905408351a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the update.

I think= that woudl be helpful to have some text that provides some rational for us= ing Ed25519 versus Ed25519ph and Ed25519ctx as well as Ed448 versus Ed448ph= . I belive that is collision resilience as well as offline signing in which= case double path does not really matter.

Yours,
Da= niel=C2=A0

On Fri, Nov 4, 2016 at 7:59 AM, Ond=C5=99ej Sur=C3=BD <ondrej.sury@ni= c.cz> wrote:
And now the ex= amples section contains Ed448 examples as well
generated using eddsa2.py from [CFRG-EDDSA] draft.

I think now the draft is as good as it gets.=C2=A0 Thanks all for
providing guidance.

O.
--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Technical Fellow
=C2=A0--------------------------------------------
=C2=A0CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e C= Z.NIC
=C2=A0Milesovska 5, 130 00 Praha 3, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz= =C2=A0 =C2=A0 https://nic.cz/
=C2=A0--------------------------------------------

----- Original Message -----
> From: "Ond=C5=99ej= Sur=C3=BD" <ondrej.sury@nic.= cz>
> To: "Simon Josefsson" <simon@josefsson.org>
> Cc: "Daniel Migault" <daniel.migault@ericsson.com>, "curdle" <curdle@ietf.org>, "dnsop" = <dnsop@ietf.org>
> Sent: Friday, 4 November, 2016 11:45:14
> Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01
> Simon,
>
> thanks for all the comments, I have now culled all the context usage f= rom the
> draft and the git version should be up to date and ready for -2 upload= .
>
> Cheers,
> Ondrej
>
> --
> Ond=C5=99ej Sur=C3=BD -- Technical Fellow
> --------------------------------------------
> CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e CZ= .NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.sury@nic.cz=C2= =A0 =C2=A0 https://nic.cz/
> --------------------------------------------
>
> ----- Original Message -----
>> From: "Simon Josefsson" <simon@josefsson.org>
>> To: "Daniel Migault" <daniel.migault@ericsson.com>
>> Cc: "curdle" <curd= le@ietf.org>, "dnsop" <dnsop@ietf.org>
>> Sent: Thursday, 3 November, 2016 22:01:38
>> Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-= 01
>
>> Daniel Migault <= daniel.migault@ericsson.com> writes:
>>
>>> Hi,
>>>
>>> This message starts a Working Group Last Call (WGLC) for
>>> draft-ietf-curdle-dnskey-eddsa-01.
>>>
>>> The version to be reviewed is
>>> https://tools.ietf.org/htm= l/draft-ietf-curdle-dnskey-eddsa-01
>>
>> Hello again.=C2=A0 Since my last review of -01, I have re-read the= document
>> again, and noticed the text regarding signature contexts.=C2=A0 I = believe the
>> use of contexts is in general ill-advised, and its presence in the=
>> document highlights a need for a security consideration to address= the
>> problem that context attempts to mitigate but does not succeed wit= h:
>> don't re-use private keys for other purposes.=C2=A0 If this be= st practice
>> advice is followed, contexts is unwanted complexity instead of som= ething
>> good.=C2=A0 If a private key is used for other purposes, contexts = won't save
>> you -- DJB explained this on the CFRG list some time ago in a way = that
>> convinced me.
>>
>> Thus, allow me to suggest that
>>
>> 1) The draft is modified to not use signature contexts.
>>
>> 2) The security consideration has a new paragraph that reads:
>>
>>=C2=A0 =C2=A0A private key used for a DNSSEC zone MUST NOT be used = for any other
>>=C2=A0 =C2=A0purpose than for that zone.=C2=A0 Otherwise cross-prot= ocol or
>>=C2=A0 =C2=A0cross-application attacks are possible.
>>
>> Perhaps this text is better suited in the Introduction section, bu= t it
>> bears repeating in the security consideration anyway.
>>
>> /Simon
>>
>> _______________________________________________
>> Curdle mailing list
>> Curdle@ietf.org
> > https://www.ietf.org/mailman/listinfo/cur= dle

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

--001a1148483020f6c905408351a6-- From nobody Sat Nov 5 04:52:06 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7661298BD for ; Sat, 5 Nov 2016 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZdOSvMf4asH for ; Sat, 5 Nov 2016 04:52:02 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 6D33E129880 for ; Sat, 5 Nov 2016 04:52:02 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id e187so24288301itc.0 for ; Sat, 05 Nov 2016 04:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=PIpAJgQoQf66fwlze2srDBz9BNsC/FWKSVeeAjQUZGQ=; b=T7+JzBhwc3WWNeV2pRV3uPVgQKtEqmALxzYnW2YUxVb9e+yYOfwS/BqiN/vZ0D8OnD E/1pZHW+QGHvxQbIORdF2jVo8KLwNhMOrulbLtPb3k1r3JWOnXRRNXmvh+BHOGzd4sUG xUqNMfp9ZCKMZAiBrOrrjK8MCY1I7nmJN8SHjoClIhmDHQR42zD+ulYvjdgZFiqn0sUB ZU1pYEziw4f/rmLCmuNXnRkRc4rTPPnz88wrOrfraqkjBNkjmJ5zHBaNSMYCQTsHVt2F ykXmVitdBD3t3Ety22ucgcFLHrHPRcpZDkEF2zHIVZZlGOvAAcqP1Fxr9PKvUv3jtKuo 2DPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=PIpAJgQoQf66fwlze2srDBz9BNsC/FWKSVeeAjQUZGQ=; b=R8L0jeeiPsQnt8v7gxoDQG3bFxFgBee1Lrkx5oWgy/wVJXUHzJtQ+2CSs9mAbzcc2B WOxdht0yIA/GA9phuKdjtfqDMU6c/mX1VJ1ybHpBgztszSxQJSpXKQow133HtVHR0UCn 95/0+w2yCGgm3pylTTyfNxjUgZZWKpntu6rF7etnNRjU4oKnz89TtKxu/VlLC0rkvDg0 kpSCuL2dxq4Xy8In5e5xvWW9aotLFqbIgvV9qH0rXAzwNfJj98kpqT24zT1bQggDONiW IPyrsSVUxhKA9icl2g3v9CtvtrA0hOM0Q3p4yeXnVJessKdqppKAOtBugAvEHwCVMedT WpsQ== X-Gm-Message-State: ABUngvcrYiJTSQBSzcigH4ESfC5un/JO7KRZWHJdIcWjjUpHR7FkNrOI+UbtM8w6H51B3AvEhMHvG2dwFdNDnQ== X-Received: by 10.107.29.21 with SMTP id d21mr17718385iod.10.1478346721474; Sat, 05 Nov 2016 04:52:01 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Sat, 5 Nov 2016 04:52:01 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Sat, 5 Nov 2016 07:52:01 -0400 X-Google-Sender-Auth: STDTyUfOkQsHSIuy8VVtcEmTPp8 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a1140a4fa303e5505408c6b58 Archived-At: Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 11:52:05 -0000 --001a1140a4fa303e5505408c6b58 Content-Type: text/plain; charset=UTF-8 Hi, I reviewed the current version of the draft. Most comments are editorial, but I have two questions or clarifications. One concerns the use of ctx and the other the restriction to non prehash signatures for CA. Please find my comments/questions on the current draft below. Yours, Daniel 1. Introduction In [I-D.irtf-cfrg-eddsa] the elliptic curve signature system Edwards- curve Digital Signature Algorithm (EdDSA) is described along with a recommendation for the use of the Curve25519 and Curve448. EdDSA has defined two modes, the PureEdDSA mode without pre-hashing, and the HashEdDSA mode with pre-hashing. The Ed25519ph and Ed448ph algorithm definitions specify the one-way hash function that is used for pre- hashing. The convention used for identifying the algorithm/curve Josefsson & Schaad Expires May 4, 2017 [Page 2] Internet-Draft Safe curves for X.509 October 2016 combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode, with Ed25519ph and Ed448ph for the HashEdDSA mode. The use of the OIDs is described for public keys, private keys and signatures. MGLT: The paragraph starts with a reference to [I-D.irtf-cfrg-eddsa] but the current draft does not not seeem to consider Ed25519ctx in HashEdDSA mode? OK the explanation is in section 6. Maybe that would worth mentioning Ed25515ctx has not been ignored or forgotten. I understand the motivation for not OIDzing Ed25515ctx now, but it looks to me strange that we only partially standardize OIDs for EdDSA, by not considering context either in Ed448 or Ed25515ctx. Would it be unreasonable to add id-Ed448ctx and id-Ed25519ctx while leaving id-Ed448 with null context ? 3. Curve25519 and Curve448 Algorithm Identifiers In this document we defined six new OIDs for identifying the different curve/algorithm pairs. The curves being Curve25519 and Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in pre-hash mode. For all of the OIDs, the parameters MUST be absent. Implementations SHOULD NOT accept a parameters value of NULL. MGLT: ECDH has not been defined earlier. Introduction talks about Diffie Hellamn. Maybe we could introduce ECDH in the intro while presenting the X* notations. 4. Subject Public Key Fields Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public key value as being a byte string. It should be noted that the public key is computed differently for each of these documents, thus the same private key will not produce the same public key. MGLT: Reading the text it looks to me the document are incompatible. Maybe some text could clarify this situation. Even though the curves remains the same in both document the described usage are different DH [RFC7748] or signature [I-D.irtf-cfrg-eddsa]. In this case, this leads to different public key associated to the same private key. 5. Key Usage Bits CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of certificates or CRLs. This is implied by the fact that those algorithms are not listed in the previous paragraph. Additionally OCSP responders SHOULD NOT use the pre-hash versions of the EdDSA algorithms when generating OCSP responses. No restriction is placed on generation of OCSP requests. AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of attribute certificates or attribute CRLs [RFC5755]. MGLT: Just for clarification. We do not use the prehash version because the signature input must be the key, and prehash considers the hash as outside the signature scheme ? It looks to me that the constraint on CA is inspired from the recommendations of RFC5755. Am I correct ? 6. EdDSA Signatures In [I-D.irtf-cfrg-eddsa], a parameter was defined for a context value, specific to an application, to be provided to the signing operation. This value is used to force different signatures to be generated for different applications. Along with the defintion of MGLT: s/defintion/definition 13. Security Considerations In the original design of Ed25519 signatures, there was a known attack between the pure and the pre-hash version of the signatures. This has sense been corrected in the final version of the design. MGLT: s/sense/since On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault wrote: > Hi, > > This message starts a Working Group Last Call (WGLC) for > draft-ietf-curdle-pkix-02. > > The version to be reviewed is https://tools.ietf.org/html/ > draft-ietf-curdle-pkix-02 > > Please send your comments, questions, and edit proposals to the WG mail > list until November 16th, 2016. If you believe that the document is ready > to be submitted to the IESG for consideration as a Standards Track RFC > please send a short message stating this. > > Yours, > > Rich and Daniel > --001a1140a4fa303e5505408c6b58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I reviewed the current ve= rsion of the draft. Most comments are editorial, but I have two questions o= r clarifications. One concerns the use of ctx and the other the restriction= to non prehash signatures for CA.

Please find my comments/question= s on the current draft below.=C2=A0

Yours,

Dani= el


1.=C2=A0 Introduction


=C2=A0=C2=A0 In [I= -D.irtf-cfrg-eddsa] the elliptic curve signature system Edwards-
=C2=A0= =C2=A0 curve Digital Signature Algorithm (EdDSA) is described along with a<= br>=C2=A0=C2=A0 recommendation for the use of the Curve25519 and Curve448.= =C2=A0 EdDSA has
=C2=A0=C2=A0 defined two modes, the PureEdDSA mode with= out pre-hashing, and the
=C2=A0=C2=A0 HashEdDSA mode with pre-hashing.= =C2=A0 The Ed25519ph and Ed448ph algorithm
=C2=A0=C2=A0 definitions spec= ify the one-way hash function that is used for pre-
=C2=A0=C2=A0 hashing= .=C2=A0 The convention used for identifying the algorithm/curve


=
Josefsson & Schaad=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Expires May 4, 2017=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 2]
=0C
Interne= t-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S= afe curves for X.509=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 October 2016


=C2=A0=C2=A0 combinations are to= use the Ed25519 and Ed448 for the PureEdDSA mode,
=C2=A0=C2=A0 with Ed2= 5519ph and Ed448ph for the HashEdDSA mode.=C2=A0 The use of the
=C2=A0= =C2=A0 OIDs is described for public keys, private keys and signatures.
<= br>=C2=A0=C2=A0 MGLT: The paragraph starts with a reference to [I-D.irtf-cf= rg-eddsa] but the current draft does not not seeem to consider Ed25519ctx i= n HashEdDSA mode?
=C2=A0=C2=A0 OK the explanation is in section 6. Maybe= that would worth mentioning Ed25515ctx has not been ignored or forgotten. = I understand the motivation for not OIDzing Ed25515ctx now, but it looks to= me strange that we only partially standardize OIDs for EdDSA, by not consi= dering context either in Ed448 or Ed25515ctx. Would it be unreasonable to= =C2=A0 add id-Ed448ctx and id-Ed25519ctx while leaving id-Ed448 with null c= ontext ?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
3.=C2=A0 Curve25519 and Cur= ve448 Algorithm Identifiers

=C2=A0=C2=A0 In this document we defined= six new OIDs for identifying the
=C2=A0=C2=A0 different curve/algorithm= pairs.=C2=A0 The curves being Curve25519 and
=C2=A0=C2=A0 Curve448.=C2= =A0 The algorithms being ECDH, EdDSA in pure mode and EdDSA in
=C2=A0=C2= =A0 pre-hash mode.=C2=A0 For all of the OIDs, the parameters MUST be absent= .
=C2=A0=C2=A0 Implementations SHOULD NOT accept a parameters value of N= ULL.

MGLT: ECDH has not been defined earlier. Introduction talks abo= ut Diffie Hellamn. Maybe we could introduce ECDH in the intro while present= ing the X* notations.
=C2=A0
4.=C2=A0 Subject Public Key Fields
<= br>=C2=A0=C2=A0 Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public = key value
=C2=A0=C2=A0 as being a byte string.=C2=A0 It should be noted = that the public key is
=C2=A0=C2=A0 computed differently for each of the= se documents, thus the same
=C2=A0=C2=A0 private key will not produce th= e same public key.

MGLT: Reading the text it looks to me the documen= t are incompatible. Maybe some text could clarify this situation. Even thou= gh the curves remains the same in both document the described usage are dif= ferent DH [RFC7748] or signature [I-D.irtf-cfrg-eddsa]. In this case, this = leads to different public key associated to the same private key.=C2=A0=C2= =A0

5.=C2=A0 Key Usage Bits

=C2=A0=C2=A0 CAs MUST NOT use th= e pre-hash versions of the EdDSA algorithms for
=C2=A0=C2=A0 the creatio= n of certificates or CRLs.=C2=A0 This is implied by the fact
=C2=A0=C2= =A0 that those algorithms are not listed in the previous paragraph.
=C2= =A0=C2=A0 Additionally OCSP responders SHOULD NOT use the pre-hash versions= of
=C2=A0=C2=A0 the EdDSA algorithms when generating OCSP responses.=C2= =A0 No restriction
=C2=A0=C2=A0 is placed on generation of OCSP requests= .

=C2=A0=C2=A0 AAs MUST NOT use the pre-hash versions of the EdDSA a= lgorithms for
=C2=A0=C2=A0 the creation of attribute certificates or att= ribute CRLs [RFC5755].

MGLT: Just for clarification. We do not use t= he prehash version because the signature input must be the key, and prehash= considers the hash as outside the signature scheme ? It looks to me that t= he constraint on CA is inspired from the recommendations of RFC5755. Am I c= orrect ?
=C2=A0
6.=C2=A0 EdDSA Signatures

=C2=A0=C2=A0 In [I-D= .irtf-cfrg-eddsa], a parameter was defined for a context
=C2=A0=C2=A0 va= lue, specific to an application, to be provided to the signing
=C2=A0=C2= =A0 operation.=C2=A0 This value is used to force different signatures to be=
=C2=A0=C2=A0 generated for different applications.=C2=A0 Along with the= defintion of
=C2=A0
=C2=A0MGLT: s/defintion/definition

13.=C2= =A0 Security Considerations

=C2=A0=C2=A0 In the original design of E= d25519 signatures, there was a known
=C2=A0=C2=A0 attack between the pur= e and the pre-hash version of the signatures.
=C2=A0=C2=A0 This has sens= e been corrected in the final version of the design.

=C2=A0MGLT: s/s= ense/since



On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-pkix-02.

The version to be reviewed is https://tools.ietf.org/html/dra= ft-ietf-curdle-pkix-02

Please send your comments, questions, and edit proposals to the WG mail=20 list until November 16th, 2016.=C2=A0 If you believe that the document is= =20 ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.

Yours,

Rich and Daniel

--001a1140a4fa303e5505408c6b58-- From nobody Mon Nov 7 19:43:11 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD45F12948F for ; Mon, 7 Nov 2016 19:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (2048-bit key) header.d=briansmith-org.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 xYoxon2_EYXX for ; Mon, 7 Nov 2016 19:43:08 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 6969C12943E for ; Mon, 7 Nov 2016 19:43:08 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id u205so177515787itc.0 for ; Mon, 07 Nov 2016 19:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yzLSgY8wD205+MQYiVJDtqZgcUcZIITFqLeqTy5J4ok=; b=yqrqq+c2kk1w/gBeMTsmzAc2VXRbACEonNx6Dyv+M0t2dktDVB/KuHikDhSYr7fbdb 76TSSpJUVGTlT0JSzkBqFSWNDyR0LKGOsKVKu3U2x7ahtr6lpVWM2472mjCGBhLW8pGh ozi4kY6wyd3SeunSwJMAb31HPXJKU98YNjA/JPTSYavS/eHajmdf33eJKEbo75DzHoFQ l1BMSe1GRieEW81xP7aVacj+nbVYUU21t1ND+dxKMdQGnE0/vxKo5ol3mMM3PQPylsJ9 I1sNXr+E+x47eTg2nV0yKy7TutFSzx8aETqnkLDg7tiWh1uyzDPaDarhPr4/0iGSjxPK oI2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yzLSgY8wD205+MQYiVJDtqZgcUcZIITFqLeqTy5J4ok=; b=Dv95M1djoGn5OIpfIYlImwIeHAdNjp63EZDrfehmzkWkBrVlXttxuaofrliSzYflyr xsP51c72BmOSSv/uSfxltVwXA87yYhlo/mWwPbeK3Kp+EvDgX9BF6Qia2ilt1++SAMu9 j/ITvq1TmXojCtwUsfsIwy0liQVrQjLThVYmfyigkIU5Ed/fpGPuEevhC1e1G6hNm2fi Jn5tP1LFppcVjGT7G0qTzZIa5oglz4A39z7e9NUthd/7UuP0E9t5voqztOs3HgvRrBM7 IEA+BRxJuF8UKyNNXN9hweT8DAtYMowGy5yW0XwrSqNzBAPeHeN1nh6rQkrjM0TjV/jU p1Gw== X-Gm-Message-State: ABUngvdE6nZSiXoru2a96/R1lXvwdQI1kuEjJHpP46yO6t/qkdbjj6CmwxT+zPS4A23JS+IawEL4MWRdKafbUQ== X-Received: by 10.107.7.96 with SMTP id 93mr13451952ioh.136.1478576587668; Mon, 07 Nov 2016 19:43:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Mon, 7 Nov 2016 19:43:06 -0800 (PST) In-Reply-To: References: From: Brian Smith Date: Mon, 7 Nov 2016 17:43:06 -1000 Message-ID: To: Daniel Migault Content-Type: multipart/alternative; boundary=001a113ec7d04817140540c1f0da Archived-At: Cc: curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 03:43:10 -0000 --001a113ec7d04817140540c1f0da Content-Type: text/plain; charset=UTF-8 Daniel Migault wrote: > 5. Key Usage Bits > > CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for > the creation of certificates or CRLs. This is implied by the fact > that those algorithms are not listed in the previous paragraph. > Additionally OCSP responders SHOULD NOT use the pre-hash versions of > the EdDSA algorithms when generating OCSP responses. No restriction > is placed on generation of OCSP requests. > This doesn't make sense to me. Isn't the goal of the prehash scheme was to support the signing of large things on systems without large amounts of memory? Why would CRLs (which may be large) be MUST NOT while OCSP responses are SHOULD NOT? It seems like the MUST NOT should be on certificates and OCSP responses and OCSP requests, which are all small. IIRC, there was some debate on whether CRLs should be allowed to use the prehash variants since CRLs could be large. I personally thing all of the cases mentioned in this paragraph should be MUST NOT. Cheers, Brian -- https://briansmith.org/ --001a113ec7d04817140540c1f0da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dani= el Migault <daniel.migault@ericsson.com> wrote:
5.=C2=A0 Ke= y Usage Bits

=C2=A0=C2=A0 CAs MUST NOT u= se the pre-hash versions of the EdDSA algorithms for
=C2=A0=C2=A0 the cr= eation of certificates or CRLs.=C2=A0 This is implied by the fact
=C2=A0= =C2=A0 that those algorithms are not listed in the previous paragraph.
= =C2=A0=C2=A0 Additionally OCSP responders SHOULD NOT use the pre-hash versi= ons of
=C2=A0=C2=A0 the EdDSA algorithms when generating OCSP responses.= =C2=A0 No restriction
=C2=A0=C2=A0 is placed on generation of OCSP reque= sts.

This doesn't= make sense to me. Isn't the goal of the prehash scheme was to support = the signing of large things on systems without large amounts of memory? Why= would CRLs (which may be large) be MUST NOT while OCSP responses are SHOUL= D NOT? It seems like the MUST NOT should be on certificates and OCSP respon= ses and OCSP requests, which are all small. IIRC, there was some debate on = whether CRLs should be allowed to use the prehash variants since CRLs could= be large. I personally thing all of the cases mentioned in this paragraph = should be MUST NOT.

Cheers,
Brian
<= /div>--
--001a113ec7d04817140540c1f0da-- From nobody Mon Nov 7 20:08:41 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAA1129583 for ; Mon, 7 Nov 2016 20:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tToY9K2afkQE for ; Mon, 7 Nov 2016 20:08:38 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC511294C4 for ; Mon, 7 Nov 2016 20:08:37 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 20:26:01 -0800 From: Jim Schaad To: 'Brian Smith' , 'Daniel Migault' References: In-Reply-To: Date: Mon, 7 Nov 2016 20:08:23 -0800 Message-ID: <002f01d23975$c13182d0$43948870$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01D23932.B3103EA0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGAWKY219/NXai3eEt9BAwJpSshJwCppyDZAyFA3yGhU+EDQA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'curdle' Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 04:08:40 -0000 ------=_NextPart_000_0030_01D23932.B3103EA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Brian Smith Sent: Monday, November 07, 2016 7:43 PM To: Daniel Migault Cc: curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 =20 Daniel Migault > wrote: 5. Key Usage Bits CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of certificates or CRLs. This is implied by the fact that those algorithms are not listed in the previous paragraph. Additionally OCSP responders SHOULD NOT use the pre-hash versions of the EdDSA algorithms when generating OCSP responses. No restriction is placed on generation of OCSP requests. =20 This doesn't make sense to me. Isn't the goal of the prehash scheme was = to support the signing of large things on systems without large amounts = of memory? Why would CRLs (which may be large) be MUST NOT while OCSP = responses are SHOULD NOT? It seems like the MUST NOT should be on = certificates and OCSP responses and OCSP requests, which are all small. = IIRC, there was some debate on whether CRLs should be allowed to use the = prehash variants since CRLs could be large. I personally thing all of = the cases mentioned in this paragraph should be MUST NOT. =20 [JLS] There was a discussion on this. In my opinion, there was not a = consensus that was reached at that time. I have been busy getting wine = done so I did not ever get back to trying a third time to figure out a = consensus for this. It will definitely be on the discussion list for = the F2F but I am more than willing to start a discussion here again. =20 The reason that CRLs are current a MUST NOT is that certificates and = CRLs are almost always generated using the same key as the certificate = is. We do not want to be in the situation where the same key is used = with different algorithms, so allowing pre-hash schemes on CRLs also = allows pre-hash schemes on certificates. =20 I could go either way for OCSP responses. =20 Jim =20 =20 Cheers, Brian --=20 https://briansmith.org/ =20 ------=_NextPart_000_0030_01D23932.B3103EA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Brian = Smith
Sent: Monday, November 07, 2016 7:43 PM
To: = Daniel Migault <daniel.migault@ericsson.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] WGLC on = draft-ietf-curdle-pkix-02

 

Daniel Migault <daniel.migault@ericsson.com> = wrote:

5.  Key Usage = Bits


   CAs MUST NOT use the pre-hash = versions of the EdDSA algorithms for
   the creation of = certificates or CRLs.  This is implied by the fact
   = that those algorithms are not listed in the previous = paragraph.
   Additionally OCSP responders SHOULD NOT use = the pre-hash versions of
   the EdDSA algorithms when = generating OCSP responses.  No restriction
   is = placed on generation of OCSP = requests.

 

This doesn't make sense to me. Isn't the goal of the = prehash scheme was to support the signing of large things on systems = without large amounts of memory? Why would CRLs (which may be large) be = MUST NOT while OCSP responses are SHOULD NOT? It seems like the MUST NOT = should be on certificates and OCSP responses and OCSP requests, which = are all small. IIRC, there was some debate on whether CRLs should be = allowed to use the prehash variants since CRLs could be large. I = personally thing all of the cases mentioned in this paragraph should be = MUST NOT.

 

[JLS] There = was a discussion on this.=C2=A0 In my opinion, there was not a consensus = that was reached at that time.=C2=A0 I have been busy getting wine done = so I did not ever get back to trying a third time to figure out a = consensus for this.=C2=A0 It will definitely be on the discussion list = for the F2F but I am more than willing to start a discussion here = again.

 

The reason = that CRLs are current a MUST NOT is that certificates and CRLs are = almost always generated using the same key as the certificate is.=C2=A0 = We do not want to be in the situation where the same key is used with = different algorithms, so allowing pre-hash schemes on CRLs also allows = pre-hash schemes on certificates.

 

I could go = either way for OCSP responses.

 

Jim

 

 

Cheers,

Brian

-- =

------=_NextPart_000_0030_01D23932.B3103EA0-- From nobody Mon Nov 7 20:23:42 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9C012985B for ; Mon, 7 Nov 2016 20:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h-aI_8ffUA0 for ; Mon, 7 Nov 2016 20:23:38 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4A41297E4 for ; Mon, 7 Nov 2016 20:23:38 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Nov 2016 20:41:08 -0800 From: Jim Schaad To: 'Daniel Migault' , 'curdle' References: In-Reply-To: Date: Mon, 7 Nov 2016 20:23:29 -0800 Message-ID: <003901d23977$dd9f45e0$98ddd1a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01D23934.CF861800" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGAWKY219/NXai3eEt9BAwJpSshJwCppyDZoWztEUA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 04:23:41 -0000 ------=_NextPart_000_003A_01D23934.CF861800 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Comments are in-line =20 One question below for you to answer about public keys. =20 There should be an open discussion on contexts and if we should punt or = do. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault Sent: Saturday, November 05, 2016 4:52 AM To: curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 =20 Hi,=20 I reviewed the current version of the draft. Most comments are = editorial, but I have two questions or clarifications. One concerns the = use of ctx and the other the restriction to non prehash signatures for = CA.=20 Please find my comments/questions on the current draft below. =20 Yours,=20 Daniel 1. Introduction In [I-D.irtf-cfrg-eddsa] the elliptic curve signature system Edwards- curve Digital Signature Algorithm (EdDSA) is described along with a recommendation for the use of the Curve25519 and Curve448. EdDSA has defined two modes, the PureEdDSA mode without pre-hashing, and the HashEdDSA mode with pre-hashing. The Ed25519ph and Ed448ph algorithm definitions specify the one-way hash function that is used for pre- hashing. The convention used for identifying the algorithm/curve Josefsson & Schaad Expires May 4, 2017 [Page 2] Internet-Draft Safe curves for X.509 October 2016 combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode, with Ed25519ph and Ed448ph for the HashEdDSA mode. The use of the OIDs is described for public keys, private keys and signatures. MGLT: The paragraph starts with a reference to [I-D.irtf-cfrg-eddsa] = but the current draft does not not seeem to consider Ed25519ctx in = HashEdDSA mode? OK the explanation is in section 6. Maybe that would worth mentioning = Ed25515ctx has not been ignored or forgotten. I understand the = motivation for not OIDzing Ed25515ctx now, but it looks to me strange = that we only partially standardize OIDs for EdDSA, by not considering = context either in Ed448 or Ed25515ctx. Would it be unreasonable to add = id-Ed448ctx and id-Ed25519ctx while leaving id-Ed448 with null context ? = [JLS] I do not think it would be reasonable at this time to create the = OIDs for having contexts for a couple of reasons. 1) I don=E2=80=99t = think we understand how they should be used and thus if we should assign = a different OID for each different context or if there should be one OID = for all contexts. 2) It is not clear that using contexts is actually = going to deliver on what was promised =E2=80=93 see the discussion by = Ilari about the use of contexts for DNSSEC. I would agree that it makes sense to pull the text from section 6 to = this location so that it is dealt with upfront. =20 3. Curve25519 and Curve448 Algorithm Identifiers In this document we defined six new OIDs for identifying the different curve/algorithm pairs. The curves being Curve25519 and Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in pre-hash mode. For all of the OIDs, the parameters MUST be absent. Implementations SHOULD NOT accept a parameters value of NULL. MGLT: ECDH has not been defined earlier. Introduction talks about Diffie = Hellamn. Maybe we could introduce ECDH in the intro while presenting the = X* notations.=20 [JLS] it makes sense to use that as part of the introduction of DH. =20 4. Subject Public Key Fields Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public key value as being a byte string. It should be noted that the public key is computed differently for each of these documents, thus the same private key will not produce the same public key. MGLT: Reading the text it looks to me the document are incompatible. = Maybe some text could clarify this situation. Even though the curves = remains the same in both document the described usage are different DH = [RFC7748] or signature [I-D.irtf-cfrg-eddsa]. In this case, this leads = to different public key associated to the same private key. =20 [JLS] I am not really clear what you think needs to be added here. I = think that what you are asking for is basically what the text says. Are = you just asking for some expanded text or some different text? 5. Key Usage Bits CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of certificates or CRLs. This is implied by the fact that those algorithms are not listed in the previous paragraph. Additionally OCSP responders SHOULD NOT use the pre-hash versions of the EdDSA algorithms when generating OCSP responses. No restriction is placed on generation of OCSP requests. AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of attribute certificates or attribute CRLs [RFC5755]. MGLT: Just for clarification. We do not use the prehash version because = the signature input must be the key, and prehash considers the hash as = outside the signature scheme ? It looks to me that the constraint on CA = is inspired from the recommendations of RFC5755. Am I correct ? [JLS] The big reason for this is no longer a true statement following = some changes to the document in the July/August timeframe. However, = there are still recommendations in [RFC-EdDSA] that inspire this = recommendation. Use of pre-hash allows for two attack points rather = than a single attack point. =20 6. EdDSA Signatures In [I-D.irtf-cfrg-eddsa], a parameter was defined for a context value, specific to an application, to be provided to the signing operation. This value is used to force different signatures to be generated for different applications. Along with the defintion of =20 MGLT: s/defintion/definition [JLS] Will do 13. Security Considerations In the original design of Ed25519 signatures, there was a known attack between the pure and the pre-hash version of the signatures. This has sense been corrected in the final version of the design. MGLT: s/sense/since [JLS] Will do =20 On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault = > = wrote: Hi, This message starts a Working Group Last Call (WGLC) for = draft-ietf-curdle-pkix-02.=20 The version to be reviewed is = https://tools.ietf.org/html/draft-ietf-curdle-pkix-02 Please send your comments, questions, and edit proposals to the WG mail = list until November 16th, 2016. If you believe that the document is = ready to be submitted to the IESG for consideration as a Standards Track = RFC please send a short message stating this. Yours,=20 Rich and Daniel =20 ------=_NextPart_000_003A_01D23934.CF861800 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Comments are = in-line

 

One question = below for you to answer about public keys.

 

There should = be an open discussion on contexts and if we should punt or = do.

 

Jim

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault
Sent: Saturday, November 05, 2016 4:52 = AM
To: curdle <curdle@ietf.org>
Subject: Re: = [Curdle] WGLC on = draft-ietf-curdle-pkix-02

 

Hi, =

I reviewed the current version = of the draft. Most comments are editorial, but I have two questions or = clarifications. One concerns the use of ctx and the other the = restriction to non prehash signatures for CA.

Please find my = comments/questions on the current draft below. 

Yours, =


Daniel



1.  = Introduction


   In [I-D.irtf-cfrg-eddsa] the = elliptic curve signature system Edwards-
   curve Digital = Signature Algorithm (EdDSA) is described along with a
   = recommendation for the use of the Curve25519 and Curve448.  EdDSA = has
   defined two modes, the PureEdDSA mode without = pre-hashing, and the
   HashEdDSA mode with = pre-hashing.  The Ed25519ph and Ed448ph algorithm
   = definitions specify the one-way hash function that is used for = pre-
   hashing.  The convention used for identifying = the algorithm/curve



Josefsson & = Schaad         Expires May 4, = 2017           &nb= sp;      [Page = 2]

Internet-Draft        &= nbsp;   Safe curves for = X.509           &n= bsp; October 2016


   combinations are to use the = Ed25519 and Ed448 for the PureEdDSA mode,
   with Ed25519ph = and Ed448ph for the HashEdDSA mode.  The use of the
   = OIDs is described for public keys, private keys and = signatures.

   MGLT: The paragraph starts with a = reference to [I-D.irtf-cfrg-eddsa] but the current draft does not not = seeem to consider Ed25519ctx in HashEdDSA mode?
   OK the = explanation is in section 6. Maybe that would worth mentioning = Ed25515ctx has not been ignored or forgotten. I understand the = motivation for not OIDzing Ed25515ctx now, but it looks to me strange = that we only partially standardize OIDs for EdDSA, by not considering = context either in Ed448 or Ed25515ctx. Would it be unreasonable to  = add id-Ed448ctx and id-Ed25519ctx while leaving id-Ed448 with null = context ?

[JLS] I do = not think it would be reasonable at this time to create the OIDs for = having contexts for a couple of reasons.=C2=A0 1) I don=E2=80=99t think = we understand how they should be used and thus if we should assign a = different OID for each different context or if there should be one OID = for all contexts.=C2=A0 2) It is not clear that using contexts is = actually going to deliver on what was promised =E2=80=93 see the = discussion by Ilari about the use of contexts for = DNSSEC.

I would = agree that it makes sense to pull the text from section 6 to this = location so that it is dealt with upfront.


      =
3.  Curve25519 and Curve448 Algorithm = Identifiers

   In this document we defined six new OIDs = for identifying the
   different curve/algorithm = pairs.  The curves being Curve25519 and
   = Curve448.  The algorithms being ECDH, EdDSA in pure mode and EdDSA = in
   pre-hash mode.  For all of the OIDs, the = parameters MUST be absent.
   Implementations SHOULD NOT = accept a parameters value of NULL.

MGLT: ECDH has not been = defined earlier. Introduction talks about Diffie Hellamn. Maybe we could = introduce ECDH in the intro while presenting the X* notations. =

[JLS] it = makes sense to use that as part of the introduction of = DH.


 
4.  Subject Public Key = Fields

   Both [RFC7748] and [I-D.irtf-cfrg-eddsa] = define the public key value
   as being a byte = string.  It should be noted that the public key is
   = computed differently for each of these documents, thus the = same
   private key will not produce the same public = key.

MGLT: Reading the text it looks to me the document are = incompatible. Maybe some text could clarify this situation. Even though = the curves remains the same in both document the described usage are = different DH [RFC7748] or signature [I-D.irtf-cfrg-eddsa]. In this case, = this leads to different public key associated to the same private = key.  

[JLS] I am = not really clear what you think needs to be added here.=C2=A0 I think = that what you are asking for is basically what the text says.=C2=A0 Are = you just asking for some expanded text or some different = text?



5.  Key Usage = Bits

   CAs MUST NOT use the pre-hash versions of the = EdDSA algorithms for
   the creation of certificates or = CRLs.  This is implied by the fact
   that those = algorithms are not listed in the previous paragraph.
   = Additionally OCSP responders SHOULD NOT use the pre-hash versions = of
   the EdDSA algorithms when generating OCSP = responses.  No restriction
   is placed on generation = of OCSP requests.

   AAs MUST NOT use the pre-hash = versions of the EdDSA algorithms for
   the creation of = attribute certificates or attribute CRLs [RFC5755].

MGLT: Just = for clarification. We do not use the prehash version because the = signature input must be the key, and prehash considers the hash as = outside the signature scheme ? It looks to me that the constraint on CA = is inspired from the recommendations of RFC5755. Am I correct = ?

[JLS] The = big reason for this is no longer a true statement following some changes = to the document in the July/August timeframe. =C2=A0=C2=A0However, there = are still recommendations in [RFC-EdDSA] that inspire this = recommendation.=C2=A0 Use of pre-hash allows for two attack points = rather than a single attack point.
 
6.  EdDSA = Signatures

   In [I-D.irtf-cfrg-eddsa], a parameter was = defined for a context
   value, specific to an application, = to be provided to the signing
   operation.  This = value is used to force different signatures to be
   = generated for different applications.  Along with the defintion = of
 
 MGLT: s/defintion/definition

[JLS] Will = do

13.  Security Considerations

   = In the original design of Ed25519 signatures, there was a = known
   attack between the pure and the pre-hash version = of the signatures.
   This has sense been corrected in the = final version of the design.

 MGLT: s/sense/since

[JLS] Will = do

------=_NextPart_000_003A_01D23934.CF861800-- From nobody Mon Nov 7 21:35:12 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFA6129539 for ; Mon, 7 Nov 2016 21:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQQFckUGJ1vS for ; Mon, 7 Nov 2016 21:35:09 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 5025B128E19 for ; Mon, 7 Nov 2016 21:35:09 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id u205so182779757itc.0 for ; Mon, 07 Nov 2016 21:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GcmMSMV/bthG2vYTxFj7Na0uOxfFYVa687zm7TRIEm0=; b=AUkGyOw/mgmYQ9DPFPNZ0LQzZ2NaFuxbo3jK7iVqWb+NL8kByjnba8IjGYaRxQLa7w R+9Uhcl5Ww8oHtxDktthOTdfGbMlgcJEiRcHCNbhKUi0utSjKaqqOszbsA5RZteV8VNU ntkQTBzsD4jnZ9uPKxrVjCcCXKQGHhpHcO1P+1LoFX1PLIdA5491MR+CvutyL23tJmog X6l9AgohYBxBNbCK9+J8BZW2zlFvJY3QUlEtetP4LB9h1ZX28ezbTY3CE2Qq7f2sK0rC GYaQCgAtTVMA4uoqT5dHFWNS1iaqcqDAXb6HKpK3dIb2rqIn5vpJavEAmk6HWI6/Sh/T hjDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GcmMSMV/bthG2vYTxFj7Na0uOxfFYVa687zm7TRIEm0=; b=CXvLCAzf5hQKU52JHcfM/IrJl5uaSKsFb0WVwlJTB/v8LaUTO0Oe1MhNWUrIXABHpx deKs/hgMBillIi3t1H1WSMMCsvKX/MdWyHXvOns63l2zyzB0fYBGiPx6XqHaQtc9idpp Nk93L/eUX1g+BM7WcKhNBqacVeMYiIbscCcxWPJ9S/S/cb6SIV17znik3JW/SdAhGCDg f1u5wNGObMBOoxJI4919zGNGA4EKACRt67rEHT77ih/zsPJG1fRrDVN9bfWJsQPkHtIQ QHhO8xhTJyxlr45+I1PqexyPs7DVVvLE/7Dpf7ge998u264MRZpqyGATsmnkSsxHcF1/ mL0g== X-Gm-Message-State: ABUngvcg0Y3sj7uwlXtt9iu1RzcPnJYZ8tSApiVNfCbZ7RGG2tPjRQ8RR+mCIM8MqzWPsw2l8+kIw+oHEvnRfw== X-Received: by 10.107.179.195 with SMTP id c186mr10895699iof.35.1478583308551; Mon, 07 Nov 2016 21:35:08 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 7 Nov 2016 21:35:08 -0800 (PST) In-Reply-To: <003901d23977$dd9f45e0$98ddd1a0$@augustcellars.com> References: <003901d23977$dd9f45e0$98ddd1a0$@augustcellars.com> From: Daniel Migault Date: Tue, 8 Nov 2016 00:35:08 -0500 X-Google-Sender-Auth: 09lKv8zRmBT5leiU15-7PDvrMQw Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11484830e0a42f0540c3809b Archived-At: Cc: curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 05:35:11 -0000 --001a11484830e0a42f0540c3809b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Thanks for the response and clarifications. I come also with the conclusion that is is not clear how ctx would be useful with X509. In DNSSEC there even has been a consensus to not use it. So I am fine not having IOD for Ed25519ctx and Ed448ctx. If anyone see a real need for creating Ed25519ctx and Ed448ctx please inform the WG. nits: Section 4. I cannot figure out what confused me, the text looks clear to me. Section 5: The following sentence is really clarifying. "Use of pre-hash allows for two attack points rather than a single attack point." On Mon, Nov 7, 2016 at 11:23 PM, Jim Schaad wrote: > Comments are in-line > > > > One question below for you to answer about public keys. > > > > There should be an open discussion on contexts and if we should punt or d= o. > > > > Jim > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Saturday, November 05, 2016 4:52 AM > *To:* curdle > *Subject:* Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 > > > > Hi, > > I reviewed the current version of the draft. Most comments are editorial, > but I have two questions or clarifications. One concerns the use of ctx a= nd > the other the restriction to non prehash signatures for CA. > > Please find my comments/questions on the current draft below. > > Yours, > > > Daniel > > > > 1. Introduction > > > In [I-D.irtf-cfrg-eddsa] the elliptic curve signature system Edwards- > curve Digital Signature Algorithm (EdDSA) is described along with a > recommendation for the use of the Curve25519 and Curve448. EdDSA has > defined two modes, the PureEdDSA mode without pre-hashing, and the > HashEdDSA mode with pre-hashing. The Ed25519ph and Ed448ph algorithm > definitions specify the one-way hash function that is used for pre- > hashing. The convention used for identifying the algorithm/curve > > > > Josefsson & Schaad Expires May 4, 2017 [Page 2] > > Internet-Draft Safe curves for X.509 October 2016 > > > combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode, > with Ed25519ph and Ed448ph for the HashEdDSA mode. The use of the > OIDs is described for public keys, private keys and signatures. > > MGLT: The paragraph starts with a reference to [I-D.irtf-cfrg-eddsa] > but the current draft does not not seeem to consider Ed25519ctx in > HashEdDSA mode? > OK the explanation is in section 6. Maybe that would worth mentioning > Ed25515ctx has not been ignored or forgotten. I understand the motivation > for not OIDzing Ed25515ctx now, but it looks to me strange that we only > partially standardize OIDs for EdDSA, by not considering context either i= n > Ed448 or Ed25515ctx. Would it be unreasonable to add id-Ed448ctx and > id-Ed25519ctx while leaving id-Ed448 with null context ? > > [JLS] I do not think it would be reasonable at this time to create the > OIDs for having contexts for a couple of reasons. 1) I don=E2=80=99t thi= nk we > understand how they should be used and thus if we should assign a differe= nt > OID for each different context or if there should be one OID for all > contexts. 2) It is not clear that using contexts is actually going to > deliver on what was promised =E2=80=93 see the discussion by Ilari about = the use of > contexts for DNSSEC. > > I would agree that it makes sense to pull the text from section 6 to this > location so that it is dealt with upfront. > > > > 3. Curve25519 and Curve448 Algorithm Identifiers > > In this document we defined six new OIDs for identifying the > different curve/algorithm pairs. The curves being Curve25519 and > Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in > pre-hash mode. For all of the OIDs, the parameters MUST be absent. > Implementations SHOULD NOT accept a parameters value of NULL. > > MGLT: ECDH has not been defined earlier. Introduction talks about Diffie > Hellamn. Maybe we could introduce ECDH in the intro while presenting the = X* > notations. > > [JLS] it makes sense to use that as part of the introduction of DH. > > > > 4. Subject Public Key Fields > > Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public key value > as being a byte string. It should be noted that the public key is > computed differently for each of these documents, thus the same > private key will not produce the same public key. > > MGLT: Reading the text it looks to me the document are incompatible. Mayb= e > some text could clarify this situation. Even though the curves remains th= e > same in both document the described usage are different DH [RFC7748] or > signature [I-D.irtf-cfrg-eddsa]. In this case, this leads to different > public key associated to the same private key. > > [JLS] I am not really clear what you think needs to be added here. I > think that what you are asking for is basically what the text says. Are > you just asking for some expanded text or some different text? > > > > 5. Key Usage Bits > > CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for > the creation of certificates or CRLs. This is implied by the fact > that those algorithms are not listed in the previous paragraph. > Additionally OCSP responders SHOULD NOT use the pre-hash versions of > the EdDSA algorithms when generating OCSP responses. No restriction > is placed on generation of OCSP requests. > > AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for > the creation of attribute certificates or attribute CRLs [RFC5755]. > > MGLT: Just for clarification. We do not use the prehash version because > the signature input must be the key, and prehash considers the hash as > outside the signature scheme ? It looks to me that the constraint on CA i= s > inspired from the recommendations of RFC5755. Am I correct ? > > [JLS] The big reason for this is no longer a true statement following som= e > changes to the document in the July/August timeframe. However, there ar= e > still recommendations in [RFC-EdDSA] that inspire this recommendation. U= se > of pre-hash allows for two attack points rather than a single attack poin= t. > > 6. EdDSA Signatures > > In [I-D.irtf-cfrg-eddsa], a parameter was defined for a context > value, specific to an application, to be provided to the signing > operation. This value is used to force different signatures to be > generated for different applications. Along with the defintion of > > MGLT: s/defintion/definition > > [JLS] Will do > > 13. Security Considerations > > In the original design of Ed25519 signatures, there was a known > attack between the pure and the pre-hash version of the signatures. > This has sense been corrected in the final version of the design. > > MGLT: s/sense/since > > [JLS] Will do > > > > On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > > Hi, > > This message starts a Working Group Last Call (WGLC) for > draft-ietf-curdle-pkix-02. > > The version to be reviewed is https://tools.ietf.org/html/ > draft-ietf-curdle-pkix-02 > > Please send your comments, questions, and edit proposals to the WG mail > list until November 16th, 2016. If you believe that the document is read= y > to be submitted to the IESG for consideration as a Standards Track RFC > please send a short message stating this. > > Yours, > > Rich and Daniel > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a11484830e0a42f0540c3809b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jim,

Thanks for the response and clarifications= .=C2=A0 I come also with the conclusion that is is not clear how ctx would = be useful with X509. In DNSSEC there even has been a consensus to not use i= t. So I am fine not having IOD for Ed25519ctx and Ed448ctx. If anyone see a= real need for creating=C2=A0 Ed25519ctx and Ed448ctx please inform the WG.=

nits:
Section 4. I cannot figure out what confused me, the text= looks clear to me.

Section 5: The following sentence is really cla= rifying. "Use of pre-hash allows for two attack points rather than a s= ingle attack point."



<= div class=3D"gmail_quote">On Mon, Nov 7, 2016 at 11:23 PM, Jim Schaad <ietf@augustcellars.com> wrote:

Comments are in-lin= e

=C2=A0

One question below for you to answer about pu= blic keys.

=C2=A0=

There should be an open discussion o= n contexts and if we should punt or do.

=C2=A0

Jim<= /u>

=C2=A0

=C2=A0

From: Curdle [mailto:curdle-bounces@ietf.or= g] On Behalf Of Daniel Migault
Sent: Saturday, Novembe= r 05, 2016 4:52 AM
To: curdle <curdle@ietf.org>
Subjec= t: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02<= /span>

=C2=A0

<= div>

Hi, =

I reviewed the= current version of the draft. Most comments are editorial, but I have two = questions or clarifications. One concerns the use of ctx and the other the = restriction to non prehash signatures for CA.

Please find my commen= ts/questions on the current draft below.=C2=A0

Yours,


Daniel

=



1.=C2=A0 Introduction


=C2=A0=C2=A0 In [I-D.irtf-cf= rg-eddsa] the elliptic curve signature system Edwards-
=C2=A0=C2=A0 curv= e Digital Signature Algorithm (EdDSA) is described along with a
=C2=A0= =C2=A0 recommendation for the use of the Curve25519 and Curve448.=C2=A0 EdD= SA has
=C2=A0=C2=A0 defined two modes, the PureEdDSA mode without pre-ha= shing, and the
=C2=A0=C2=A0 HashEdDSA mode with pre-hashing.=C2=A0 The E= d25519ph and Ed448ph algorithm
=C2=A0=C2=A0 definitions specify the one-= way hash function that is used for pre-
=C2=A0=C2=A0 hashing.=C2=A0 The = convention used for identifying the algorithm/curve



Josefsso= n & Schaad=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expires May = 4, 2017=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 2]

Internet-Draft=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Safe curves fo= r X.509=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 October 2016


=C2=A0=C2=A0 combinations are to use the Ed2= 5519 and Ed448 for the PureEdDSA mode,
=C2=A0=C2=A0 with Ed25519ph and E= d448ph for the HashEdDSA mode.=C2=A0 The use of the
=C2=A0=C2=A0 OIDs is= described for public keys, private keys and signatures.

=C2=A0=C2= =A0 MGLT: The paragraph starts with a reference to [I-D.irtf-cfrg-eddsa] bu= t the current draft does not not seeem to consider Ed25519ctx in HashEdDSA = mode?
=C2=A0=C2=A0 OK the explanation is in section 6. Maybe that would = worth mentioning Ed25515ctx has not been ignored or forgotten. I understand= the motivation for not OIDzing Ed25515ctx now, but it looks to me strange = that we only partially standardize OIDs for EdDSA, by not considering conte= xt either in Ed448 or Ed25515ctx. Would it be unreasonable to=C2=A0 add id-= Ed448ctx and id-Ed25519ctx while leaving id-Ed448 with null context ?

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= [JLS] I do not think it would be reasonable at this time to create the OIDs= for having contexts for a couple of reasons.=C2=A0 1) I don=E2=80=99t thin= k we understand how they should be used and thus if we should assign a diff= erent OID for each different context or if there should be one OID for all = contexts.=C2=A0 2) It is not clear that using contexts is actually going to= deliver on what was promised =E2=80=93 see the discussion by Ilari about t= he use of contexts for DNSSEC.

I would agree that it makes sense to pul= l the text from section 6 to this location so that it is dealt with upfront= .


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
3.=C2=A0 Curve= 25519 and Curve448 Algorithm Identifiers

=C2=A0=C2=A0 In this docume= nt we defined six new OIDs for identifying the
=C2=A0=C2=A0 different cu= rve/algorithm pairs.=C2=A0 The curves being Curve25519 and
=C2=A0=C2=A0 = Curve448.=C2=A0 The algorithms being ECDH, EdDSA in pure mode and EdDSA in<= br>=C2=A0=C2=A0 pre-hash mode.=C2=A0 For all of the OIDs, the parameters MU= ST be absent.
=C2=A0=C2=A0 Implementations SHOULD NOT accept a parameter= s value of NULL.

MGLT: ECDH has not been defined earlier. Introducti= on talks about Diffie Hellamn. Maybe we could introduce ECDH in the intro w= hile presenting the X* notations.

[JLS] it makes sense to use that as = part of the introduction of DH.


=C2=A0
4.=C2=A0 = Subject Public Key Fields

=C2=A0=C2=A0 Both [RFC7748] and [I-D.irtf-= cfrg-eddsa] define the public key value
=C2=A0=C2=A0 as being a byte str= ing.=C2=A0 It should be noted that the public key is
=C2=A0=C2=A0 comput= ed differently for each of these documents, thus the same
=C2=A0=C2=A0 p= rivate key will not produce the same public key.

MGLT: Reading the t= ext it looks to me the document are incompatible. Maybe some text could cla= rify this situation. Even though the curves remains the same in both docume= nt the described usage are different DH [RFC7748] or signature [I-D.irtf-cf= rg-eddsa]. In this case, this leads to different public key associated to t= he same private key.=C2=A0=C2=A0

[JLS] I am not really clear what you = think needs to be added here.=C2=A0 I think that what you are asking for is= basically what the text says.=C2=A0 Are you just asking for some expanded = text or some different text?



5.=C2=A0 Key Usage= Bits

=C2=A0=C2=A0 CAs MUST NOT use the pre-hash versions of the EdD= SA algorithms for
=C2=A0=C2=A0 the creation of certificates or CRLs.=C2= =A0 This is implied by the fact
=C2=A0=C2=A0 that those algorithms are n= ot listed in the previous paragraph.
=C2=A0=C2=A0 Additionally OCSP resp= onders SHOULD NOT use the pre-hash versions of
=C2=A0=C2=A0 the EdDSA al= gorithms when generating OCSP responses.=C2=A0 No restriction
=C2=A0=C2= =A0 is placed on generation of OCSP requests.

=C2=A0=C2=A0 AAs MUST = NOT use the pre-hash versions of the EdDSA algorithms for
=C2=A0=C2=A0 t= he creation of attribute certificates or attribute CRLs [RFC5755].

M= GLT: Just for clarification. We do not use the prehash version because the = signature input must be the key, and prehash considers the hash as outside = the signature scheme ? It looks to me that the constraint on CA is inspired= from the recommendations of RFC5755. Am I correct ?

[JLS] The big reas= on for this is no longer a true statement following some changes to the doc= ument in the July/August timeframe. =C2=A0=C2=A0However, there are still re= commendations in [RFC-EdDSA] that inspire this recommendation.=C2=A0 Use of= pre-hash allows for two attack points rather than a single attack point.
=C2=A0
6.=C2=A0 EdDSA Signatures

=C2=A0= =C2=A0 In [I-D.irtf-cfrg-eddsa], a parameter was defined for a context
= =C2=A0=C2=A0 value, specific to an application, to be provided to the signi= ng
=C2=A0=C2=A0 operation.=C2=A0 This value is used to force different s= ignatures to be
=C2=A0=C2=A0 generated for different applications.=C2=A0= Along with the defintion of
=C2=A0
=C2=A0MGLT: s/defintion/definitio= n

[JLS] Will do

13.=C2=A0 Security Consi= derations

=C2=A0=C2=A0 In the original design of Ed25519 signatures,= there was a known
=C2=A0=C2=A0 attack between the pure and the pre-hash= version of the signatures.
=C2=A0=C2=A0 This has sense been corrected i= n the final version of the design.

=C2=A0MGLT: s/sense/since=

[JLS] Will do

=C2=A0

On Wed, Nov 2, 2016 at 11:55 PM, Daniel Migault <daniel.migault@ericsson.c= om> wrote:

Hi,

This message starts a Working Group Last Call (WGLC) for draft-i= etf-curdle-pkix-02.

The version to be reviewed is https://= tools.ietf.org/html/draft-ietf-curdle-pkix-02

Please send y= our comments, questions, and edit proposals to the WG mail list until Novem= ber 16th, 2016.=C2=A0 If you believe that the document is ready to be submi= tted to the IESG for consideration as a Standards Track RFC please send a s= hort message stating this.

Yours,

Rich and Daniel

=C2=A0


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

--001a11484830e0a42f0540c3809b-- From nobody Fri Nov 11 23:04:35 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DC31299BD for ; Fri, 11 Nov 2016 23:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 pzkoZ2YfDW_v for ; Fri, 11 Nov 2016 23:04:31 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70561299A7 for ; Fri, 11 Nov 2016 23:04:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1BBFF300AC2 for ; Sat, 12 Nov 2016 02:04:31 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kLjWTUf8cBda for ; Sat, 12 Nov 2016 02:04:30 -0500 (EST) Received: from dhcp-8c4e.meeting.ietf.org (dhcp-8c4e.meeting.ietf.org [31.133.140.78]) by mail.smeinc.net (Postfix) with ESMTPSA id 2DE33300A49 for ; Sat, 12 Nov 2016 02:04:28 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <077D538E-5BA1-49AD-B0C6-26A31FF3607A@vigilsec.com> Date: Sat, 12 Nov 2016 02:04:24 -0500 To: curdle@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Curdle] draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 07:04:33 -0000 Section 3 says: For all of the OIDs, the parameters MUST be absent. Implementations SHOULD NOT accept a parameters value of NULL. I strongly agree that the parameters MUST be absent. If no one generates parameters, why do we need any discussion of NULL = parameters? Russ From nobody Mon Nov 14 14:50:01 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C11A1294DC for ; Mon, 14 Nov 2016 14:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 fMkDj5RzdnTg for ; Mon, 14 Nov 2016 14:49:59 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 360CB1293E9 for ; Mon, 14 Nov 2016 14:49:59 -0800 (PST) Received: from [10.32.60.216] ([211.44.215.72]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id uAEMnkYI077931 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Nov 2016 15:49:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host [211.44.215.72] claimed to be [10.32.60.216] From: "Paul Hoffman" To: curdle@ietf.org Date: Tue, 15 Nov 2016 07:49:55 +0900 Message-ID: <141AEF7B-1853-4EB8-8A7E-5226B67D2761@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 22:50:00 -0000 The draft is in good shape. I agree with Simon that we should drop the context string and add the security consideration. If the WG agrees, it would be good for us to have another week to review the revised document (and for people who have running code to re-run the test vectors.) I have a concern not with the draft, but with the comments others have made during the WG Last Call. In specific, I do not agree with: On 5 Nov 2016, at 10:00, Daniel Migault wrote: > I think that woudl be helpful to have some text that provides some > rational > for using Ed25519 versus Ed25519ph and Ed25519ctx as well as Ed448 > versus > Ed448ph. I belive that is collision resilience as well as offline > signing > in which case double path does not really matter. The discussion of those other formats in draft-irtf-cfrg-eddsa seems good enough to me. I have a concern that adding the rationale will in fact confuse developers into looking at the other formats. Our spec should be "this is the format", not "and here are other things we considered and didn't adopt". --Paul Hoffman From nobody Mon Nov 14 15:10:19 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E71A12962F; Mon, 14 Nov 2016 15:10:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147916501531.919.1356911194907095952.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2016 15:10:15 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 23:10:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : EdDSA for DNSSEC Authors : Ondrej Sury Robert Edmonds Filename : draft-ietf-curdle-dnskey-eddsa-02.txt Pages : 8 Date : 2016-11-14 Abstract: This document describes how to specify EdDSA keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-dnskey-eddsa-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 14 15:16:47 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D0F129637 for ; Mon, 14 Nov 2016 15:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_3wfdq7lYXl for ; Mon, 14 Nov 2016 15:16:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708E9129632 for ; Mon, 14 Nov 2016 15:16:38 -0800 (PST) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 077EA60D7D; Tue, 15 Nov 2016 00:16:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1479165397; bh=rMN/Pk+/g+Lbx0puDMal5N0RQvufZfvhSXSJbHvA4aw=; h=Date:From:To; b=HhqLq2mbdCKX9sGC24qUXSBbeGFBcllS6Prw4kW+Qz3/BWF2UqNPCUs50+onueU1J JLZDKOaKVluju1H/y2rAAib1q4wQ6lu9Q8vBP6eMvPjrd4J/vSc21BxNsM/YthrndY grUAmd5RF188/MjRbB4WLZ+0+I+2kYL8pAPtKT1k= Date: Tue, 15 Nov 2016 00:16:36 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Paul Hoffman Message-ID: <1249672855.512.1479165396790.JavaMail.zimbra@nic.cz> In-Reply-To: <141AEF7B-1853-4EB8-8A7E-5226B67D2761@vpnc.org> References: <141AEF7B-1853-4EB8-8A7E-5226B67D2761@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: hARurFlx5Fdq9JZrQAZmGa6Xv3JnfA== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 23:16:47 -0000 Paul, thanks for the comment. I have just submitted an updated version of the draft where I resolved all the comments except this particular one. I also have feeling that we don't have to explain *in the draft* why we picked this particular algorithm. Here's the side by side diff for WG convenience: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-curdle-dnskey-eddsa-01&url2= =3Ddraft-ietf-curdle-dnskey-eddsa-02 Cheers, Ondrej -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Paul Hoffman" > To: "curdle" > Sent: Monday, 14 November, 2016 23:49:55 > Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 > The draft is in good shape. I agree with Simon that we should drop the > context string and add the security consideration. If the WG agrees, it > would be good for us to have another week to review the revised document > (and for people who have running code to re-run the test vectors.) >=20 > I have a concern not with the draft, but with the comments others have > made during the WG Last Call. In specific, I do not agree with: >=20 > On 5 Nov 2016, at 10:00, Daniel Migault wrote: >=20 >> I think that woudl be helpful to have some text that provides some >> rational >> for using Ed25519 versus Ed25519ph and Ed25519ctx as well as Ed448 >> versus >> Ed448ph. I belive that is collision resilience as well as offline >> signing >> in which case double path does not really matter. >=20 > The discussion of those other formats in draft-irtf-cfrg-eddsa seems > good enough to me. I have a concern that adding the rationale will in > fact confuse developers into looking at the other formats. Our spec > should be "this is the format", not "and here are other things we > considered and didn't adopt". >=20 > --Paul Hoffman >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Nov 14 15:19:42 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C219D12941C for ; Mon, 14 Nov 2016 15:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9PiKanIEznx for ; Mon, 14 Nov 2016 15:19:40 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5F129426 for ; Mon, 14 Nov 2016 15:19:40 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 24E15496C52; Mon, 14 Nov 2016 23:19:40 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 0F35F496C0D; Mon, 14 Nov 2016 23:19:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479165580; bh=4yJiN/m4Pw+rkASmzZtF7HXKMbrLvoJq/bRWfTnUzIU=; l=428; h=From:To:CC:Date:References:In-Reply-To:From; b=svtasY0oXjCh9vYjtW+ojyPh9K68Sv6j6H1o5hvJ4u2ZO6o1ujtgjs+iK7IuSLBa4 FYO+7F5El4Skt7NIiZMpTjHdNYI96iwhZoZ6J+5GRFcJB8jBl1l6gAPIQ0C/jR1d91 ElbX4nbdC1RISwgj5hxK3i6k7vwuPU2RfwUq8uKk= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id E7BFC98082; Mon, 14 Nov 2016 23:19:39 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 14 Nov 2016 18:19:39 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 14 Nov 2016 18:19:39 -0500 From: "Salz, Rich" To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , Paul Hoffman Thread-Topic: WGLC on draft-ietf-curdle-dnskey-eddsa-01 Thread-Index: AQHSPs0u8UNQ+eQ3EECzhtTzXext+KDZHT7w Date: Mon, 14 Nov 2016 23:19:38 +0000 Message-ID: <026cf48fcc404ef998e7dabc905f35f5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <141AEF7B-1853-4EB8-8A7E-5226B67D2761@vpnc.org> <1249672855.512.1479165396790.JavaMail.zimbra@nic.cz> In-Reply-To: <1249672855.512.1479165396790.JavaMail.zimbra@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 23:19:42 -0000 DQo+IEkgYWxzbyBoYXZlIGZlZWxpbmcgdGhhdCB3ZSBkb24ndCBoYXZlIHRvIGV4cGxhaW4gKmlu IHRoZSBkcmFmdCogd2h5IHdlDQo+IHBpY2tlZCB0aGlzIHBhcnRpY3VsYXIgYWxnb3JpdGhtLg0K DQpNdWNoIGFzIEkgZG9uJ3QgbGlrZSB0byBkaXNhZ3JlZSB3aXRoIG15IGNvLWNoYWlyIDopIEkg YWdyZWUgd2l0aCB5b3UuICBSRkMncyB0eXBpY2FsbHkgc2F5ICJob3cgdG8gZG8gaXQuIiAgUmF0 aW9uYWxlJ3MgYXJlIHVzdWFsbHkgbGVmdCBmb3IgdGhlIFdHIG1haWxpbmcgbGlzdCBvciBwZXJo YXBzIGNvbmZlcmVuY2UgcGFwZXJzIDopIA0K From nobody Tue Nov 15 06:24:44 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F58129636 for ; Tue, 15 Nov 2016 06:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC-Si5S1kwsp for ; Tue, 15 Nov 2016 06:24:41 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 EFCBF129577 for ; Tue, 15 Nov 2016 06:24:40 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id c20so152085985itb.0 for ; Tue, 15 Nov 2016 06:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RXhtWthWgTDlPBofWvIhIYDCt8yFubXiiSH5XkaObAw=; b=ic20PdJk0gJUiyz2Ujyf9J0s7vcrsI32s+7y/PcB/5h1dcidQjj6x9OqAggoS1fCRb goqwBYtjBxaETgA3pPeTk5U0UwFDgS/1eZX90YhyEhsRJhx1DEFmSh/8wCn0dDo5ZjRh 2tlCAYoA2ZFYGFvmcL74tYvZSu9r05LB3Riadflav5/fR8uAcGJpZqq18kK64todSkAG IN3sGOIgGM//6usPSE/1lp7gBQTo4RrsEMCRe2NzZUk7cwbYnGEJrRH8DjGjtVkmnHJ6 lFkJCJ0ubIbZq4KB/gMAVnbFBPJgnN9zQ4JoHFC+CDPVLZ6N55QIeXPu2f03KRHq0Ctx 5gyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RXhtWthWgTDlPBofWvIhIYDCt8yFubXiiSH5XkaObAw=; b=eLFEDQcgbkB8Gj67Fto3L42P/rJBxtY4kawrjJEAquc+Xc4evLifslmNjKtgkSAHKn Qui1cp/E5TTbOkpz33WCT0PI+GdzZiRADvrPomJbTeBWu3Q55nThZptcLO2I8/TVxR8X wuzqITJm2ST4NHy0Ojk7CbZZdtcaJcQe3/V8Twr5VZNpyDHXuRDZFUQSdpme0tpDYu5I ZAGcqosFe+V9u2ptiZN6VP/j09wbCHLSEcwnt6CzSpdFmOPL0erXKIq3ijhOKVNYU7mc fOfscKd0MF3NRTtGsD0TYcKlqH95glGEqY2K0ey1sM2t6HDoKDchYbvXKvqrxDowwczn Hohw== X-Gm-Message-State: ABUngvdhxuWmTwTfrWCQLPXe7SQDXD6Cz+MCwXYnuVh0vb3tI+iQOAlMa1A+M9wL2rBWDUMvbAaRMtmG1EWRJA== X-Received: by 10.107.18.39 with SMTP id a39mr29416325ioj.45.1479219879695; Tue, 15 Nov 2016 06:24:39 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Tue, 15 Nov 2016 06:24:39 -0800 (PST) In-Reply-To: <026cf48fcc404ef998e7dabc905f35f5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <141AEF7B-1853-4EB8-8A7E-5226B67D2761@vpnc.org> <1249672855.512.1479165396790.JavaMail.zimbra@nic.cz> <026cf48fcc404ef998e7dabc905f35f5@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Tue, 15 Nov 2016 09:24:39 -0500 X-Google-Sender-Auth: obz9veSJm1J_JROIO0-hA1F79ps Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a113ff17c795c15054157b797 Archived-At: Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , curdle , Paul Hoffman Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 14:24:42 -0000 --001a113ff17c795c15054157b797 Content-Type: text/plain; charset=UTF-8 Sounds like cross mailing list consensus ;-) For those that have not yet reviewed the document, the WGLC is almost ending, so please provide your comments by the end of the week... or on your way back! Yours Daniel On Mon, Nov 14, 2016 at 6:19 PM, Salz, Rich wrote: > > > I also have feeling that we don't have to explain *in the draft* why we > > picked this particular algorithm. > > Much as I don't like to disagree with my co-chair :) I agree with you. > RFC's typically say "how to do it." Rationale's are usually left for the > WG mailing list or perhaps conference papers :) > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113ff17c795c15054157b797 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds like cross mailing list consensus ;-= )

For those that have not yet reviewed the document, the WGLC = is almost ending, so please provide your comments by the end of the week...= or on your way back!

Yours

Daniel

On Mon, Nov 14, 2016 = at 6:19 PM, Salz, Rich <rsalz@akamai.com> wrote:

> I also have feeling that we don't have to explain *in the draft* w= hy we
> picked this particular algorithm.

Much as I don't like to disagree with my co-chair :) I agree wit= h you.=C2=A0 RFC's typically say "how to do it."=C2=A0 Ration= ale's are usually left for the WG mailing list or perhaps conference pa= pers :)
______________________________= _________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a113ff17c795c15054157b797-- From nobody Tue Nov 15 20:45:24 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1B91294FC; Tue, 15 Nov 2016 20:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxKpMtSII1_C; Tue, 15 Nov 2016 20:45:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5427F129457; Tue, 15 Nov 2016 20:45:16 -0800 (PST) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 0C60C61FFB; Wed, 16 Nov 2016 05:45:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1479271515; bh=OmVXWG3lju7x3zxIqoZjr4zsVoGB4t5X4E2zsKzWN20=; h=Date:From:To; b=Mb8sNCH0onEFuhO/385KaeAOOBhHEe81hyAyrah6umo2Lx1JpZYoJeWJtSAiBIRLs UhIj72MKEWg7eFQ8Q8JfY4OhYyobbvefav9QVcWxSQeia8gqY+lHOU7MsBqKK6Mos5 zmwCr4gmNbWH4yGmJZI9lQKuoY+HFdzHdVEwAIKg= Date: Wed, 16 Nov 2016 05:45:15 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Daniel Migault Message-ID: <1320631198.1957.1479271514994.JavaMail.zimbra@nic.cz> In-Reply-To: References: <147916501531.919.1356911194907095952.idtracker@ietfa.amsl.com> <1045632662.533.1479165738709.JavaMail.zimbra@nic.cz> <1765127159.1826.1479229557011.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF49 (Linux)/8.7.0_GA_1659) Thread-Topic: I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt Thread-Index: A0aaP+zMrFj5PZ70sjlELuPgtyQMdQ== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: dnsop , curdle Subject: Re: [Curdle] [DNSOP] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 04:45:19 -0000 draft-irft-cfrg-eddsa states in Section 5.2: Value of context is set by signer and verifier (maximum of 255 octets, the default is empty string) and has to match octet by octet for verification to be successful. So in fact, the default context for Ed448 is "empty string". Cheers, Ondrej -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Daniel Migault" > To: "Dick Franks" > Cc: "dnsop" , "Ond=C5=99ej Sur=C3=BD" > Sent: Wednesday, 16 November, 2016 05:23:23 > Subject: Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-e= ddsa-02.txt > my understanding is that ed448 does not specify default values for the > context and i have not seen in the current draft a specification of the > context. Shouldn't we explicitly mention that the context is empty? > Yours, > daniel >=20 > On Nov 16, 2016 2:44 AM, "Dick Franks" wrote: >=20 >> My mistake. Apologies. >> >> I also had draft-wouters-sury-dnsop-algorithm-update-02 >> on screen. That has the registry table with same TBDs. >> Starting at 04:30 dulls the brain. >> >> >> Dick Franks >> ________________________ >> >> >> On 15 November 2016 at 17:05, Ond=C5=99ej Sur=C3=BD = wrote: >> >>> The IANA Considerations Sections says: >>> >>> This document updates the IANA registry "Domain Name System Security >>> (DNSSEC) Algorithm Numbers". >>> >>> And I believe that's the correct language according to >>> https://tools.ietf.org/html/rfc5226#section-5.1 >>> >>> Cheers, >>> Ondrej >>> >>> -- >>> Ond=C5=99ej Sur=C3=BD -- Technical Fellow >>> -------------------------------------------- >>> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >>> Milesovska 5, 130 00 Praha 3, Czech Republic >>> mailto:ondrej.sury@nic.cz https://nic.cz/ >>> -------------------------------------------- >>> >>> ----- Original Message ----- >>> > From: "Dick Franks" >>> > To: "Ond=C5=99ej Sur=C3=BD" >>> > Cc: "dnsop" >>> > Sent: Tuesday, 15 November, 2016 17:51:56 >>> > Subject: Re: [DNSOP] Fwd: [Curdle] I-D Action: >>> draft-ietf-curdle-dnskey-eddsa-02.txt >>> >>> > Ondrej >>> > >>> > The document calls up two TBD code points for the EDDSA algorithms, b= ut >>> the >>> > IANA Considerations section places no action on IANA to assign these = and >>> > add them to the registry. >>> > >>> > Other than that, seems ok. >>> > >>> > >>> > Dick Franks >>> > ________________________ >>> > >>> > >>> > On 14 November 2016 at 23:22, Ond=C5=99ej Sur=C3=BD wrote: >>> > >>> >> Dear all, >>> >> >>> >> a new version of EDDSA for DNSSEC has been posted >>> >> that resolves most if not all comments received >>> >> during WGLC in curdle. This is one last chance >>> >> to review the document, so don't miss it! :) >>> >> >>> >> Cheers, >>> >> -- >>> >> Ond=C5=99ej Sur=C3=BD -- Technical Fellow >>> >> -------------------------------------------- >>> >> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >>> >> Milesovska 5, 130 00 Praha 3, Czech Republic >>> >> mailto:ondrej.sury@nic.cz https://nic.cz/ >>> >> -------------------------------------------- >>> >> >>> >> ----- Forwarded Message ----- >>> >> From: internet-drafts@ietf.org >>> >> To: i-d-announce@ietf.org >>> >> Cc: "curdle" >>> >> Sent: Tuesday, 15 November, 2016 00:10:15 >>> >> Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt >>> >> >>> >> A New Internet-Draft is available from the on-line Internet-Drafts >>> >> directories. >>> >> This draft is a work item of the CURves, Deprecating and a Little mo= re >>> >> Encryption of the IETF. >>> >> >>> >> Title : EdDSA for DNSSEC >>> >> Authors : Ondrej Sury >>> >> Robert Edmonds >>> >> Filename : draft-ietf-curdle-dnskey-eddsa-02.txt >>> >> Pages : 8 >>> >> Date : 2016-11-14 >>> >> >>> >> Abstract: >>> >> This document describes how to specify EdDSA keys and signatures = in >>> >> DNS Security (DNSSEC). It uses the Edwards-curve Digital Securit= y >>> >> Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed44= 8. >>> >> >>> >> >>> >> The IETF datatracker status page for this draft is: >>> >> https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ >>> >> >>> >> There's also a htmlized version available at: >>> >> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-02 >>> >> >>> >> A diff from the previous version is available at: >>> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-dnskey-eddsa-0= 2 >>> >> >>> >> >>> >> 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/ >>> >> >>> >> _______________________________________________ >>> >> Curdle mailing list >>> >> Curdle@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/curdle >>> >> >>> >> _______________________________________________ >>> >> DNSOP mailing list >>> >> DNSOP@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> From nobody Tue Nov 15 21:02:09 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C8B12964E; Tue, 15 Nov 2016 21:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdG3_834KuAL; Tue, 15 Nov 2016 21:02:00 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 1FDDD1294F7; Tue, 15 Nov 2016 21:02:00 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id c20so191319769itb.0; Tue, 15 Nov 2016 21:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OSo5iEEsjRvMVPj0JOn1RQL1h9JETRDf28crLwS6/uA=; b=Gj8LxqzClg71lFe/vWlDldzvUzRpou5MDv9ip/Upu9SdDlhGUKpXMLRQVSXF1Wc0p1 z+nVlv+nY/r84e+kaUVUW6SxZdpIsK6i0RhT0xfrWKHNJwOQBxfJNfQduyje39lJuUVI 9ELpwLLJPFw9Oz1Ku1zC2BWGeoeSGrhC2B3cHTi5WfCIwzCgkAlJ0002eCVeZWAnghco 5VcE/YEYLMJZ8cnWbF1yuh69cEMjIg1knAVmSTO1fBm0doDTx6vuYSAHjj2k7L9SHSaT hh17niVrb/pn5pLxBKHDVVzgL/C8vOvjKudFITkqzPAi52KRvKT91itjzMUqknRzUmKI Lu5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OSo5iEEsjRvMVPj0JOn1RQL1h9JETRDf28crLwS6/uA=; b=Xp+l27nMeWpc/HI+Y1nw0guf4J8qBQlmG8qGeK8on5kcr/oXsDT1Ip45pt2bNjfDjM YAo3xC08eL5djmL4Lma4dWcUwKr7JaeaSfreUP2KHE1+l21hMeTEsEMz5UzUF238jlWx yZrPkc4bzEUHex20MZsf04j0DZ6i4/R8t3enWC+E9cBKXvUU0pfRQl1SIQC0XdnVoEZm XWcSboFWGsIWh9fszi80S5gwCMVOpXUzJL/PVcXM6+72IJdGtJGOyS09Yn+0hhhPpIPN ooOqVIJlaSDpvmOYBUZk1aL0y93Dqmp5/iQq2aOjpr0YD6u73EW3oas4/EMIoIN5vfNd aFCQ== X-Gm-Message-State: ABUngvcUU8MopqjZEun072OEKbo0vUwx5o+nbCDobuVR+bk6vZSJY8EAL4EnP6GCfjeU2wEpaKOlG8azfypqcQ== X-Received: by 10.107.12.214 with SMTP id 83mr1208406iom.10.1479272519466; Tue, 15 Nov 2016 21:01:59 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Tue, 15 Nov 2016 21:01:58 -0800 (PST) Received: by 10.107.32.10 with HTTP; Tue, 15 Nov 2016 21:01:58 -0800 (PST) In-Reply-To: <1320631198.1957.1479271514994.JavaMail.zimbra@nic.cz> References: <147916501531.919.1356911194907095952.idtracker@ietfa.amsl.com> <1045632662.533.1479165738709.JavaMail.zimbra@nic.cz> <1765127159.1826.1479229557011.JavaMail.zimbra@nic.cz> <1320631198.1957.1479271514994.JavaMail.zimbra@nic.cz> From: Daniel Migault Date: Wed, 16 Nov 2016 00:01:58 -0500 X-Google-Sender-Auth: o5Fr8Ju-k1ZdZK2Uj-QLrhKHIro Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001a113fc0ee0c84ee054163f964 Archived-At: Cc: curdle , dnsop Subject: Re: [Curdle] [DNSOP] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 05:02:03 -0000 --001a113fc0ee0c84ee054163f964 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, i did not saw it. This is explicitely mentioned. Yours, Daniel On Nov 16, 2016 1:45 PM, "Ond=C5=99ej Sur=C3=BD" wrote= : > draft-irft-cfrg-eddsa states in Section 5.2: > > Value of context is set by signer and verifier (maximum of 255 > octets, the default is empty string) and has to match octet by octet > for verification to be successful. > > So in fact, the default context for Ed448 is "empty string". > > Cheers, > Ondrej > > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "Daniel Migault" > > To: "Dick Franks" > > Cc: "dnsop" , "Ond=C5=99ej Sur=C3=BD" > > Sent: Wednesday, 16 November, 2016 05:23:23 > > Subject: Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey= - > eddsa-02.txt > > > my understanding is that ed448 does not specify default values for the > > context and i have not seen in the current draft a specification of the > > context. Shouldn't we explicitly mention that the context is empty? > > Yours, > > daniel > > > > On Nov 16, 2016 2:44 AM, "Dick Franks" wrote: > > > >> My mistake. Apologies. > >> > >> I also had draft-wouters-sury-dnsop-algorithm-update-02 > >> on screen. That has the registry table with same TBDs. > >> Starting at 04:30 dulls the brain. > >> > >> > >> Dick Franks > >> ________________________ > >> > >> > >> On 15 November 2016 at 17:05, Ond=C5=99ej Sur=C3=BD wrote: > >> > >>> The IANA Considerations Sections says: > >>> > >>> This document updates the IANA registry "Domain Name System Security > >>> (DNSSEC) Algorithm Numbers". > >>> > >>> And I believe that's the correct language according to > >>> https://tools.ietf.org/html/rfc5226#section-5.1 > >>> > >>> Cheers, > >>> Ondrej > >>> > >>> -- > >>> Ond=C5=99ej Sur=C3=BD -- Technical Fellow > >>> -------------------------------------------- > >>> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > >>> Milesovska 5, 130 00 Praha 3, Czech Republic > >>> mailto:ondrej.sury@nic.cz https://nic.cz/ > >>> -------------------------------------------- > >>> > >>> ----- Original Message ----- > >>> > From: "Dick Franks" > >>> > To: "Ond=C5=99ej Sur=C3=BD" > >>> > Cc: "dnsop" > >>> > Sent: Tuesday, 15 November, 2016 17:51:56 > >>> > Subject: Re: [DNSOP] Fwd: [Curdle] I-D Action: > >>> draft-ietf-curdle-dnskey-eddsa-02.txt > >>> > >>> > Ondrej > >>> > > >>> > The document calls up two TBD code points for the EDDSA algorithms, > but > >>> the > >>> > IANA Considerations section places no action on IANA to assign thes= e > and > >>> > add them to the registry. > >>> > > >>> > Other than that, seems ok. > >>> > > >>> > > >>> > Dick Franks > >>> > ________________________ > >>> > > >>> > > >>> > On 14 November 2016 at 23:22, Ond=C5=99ej Sur=C3=BD > wrote: > >>> > > >>> >> Dear all, > >>> >> > >>> >> a new version of EDDSA for DNSSEC has been posted > >>> >> that resolves most if not all comments received > >>> >> during WGLC in curdle. This is one last chance > >>> >> to review the document, so don't miss it! :) > >>> >> > >>> >> Cheers, > >>> >> -- > >>> >> Ond=C5=99ej Sur=C3=BD -- Technical Fellow > >>> >> -------------------------------------------- > >>> >> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > >>> >> Milesovska 5, 130 00 Praha 3, Czech Republic > >>> >> mailto:ondrej.sury@nic.cz https://nic.cz/ > >>> >> -------------------------------------------- > >>> >> > >>> >> ----- Forwarded Message ----- > >>> >> From: internet-drafts@ietf.org > >>> >> To: i-d-announce@ietf.org > >>> >> Cc: "curdle" > >>> >> Sent: Tuesday, 15 November, 2016 00:10:15 > >>> >> Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.tx= t > >>> >> > >>> >> A New Internet-Draft is available from the on-line Internet-Drafts > >>> >> directories. > >>> >> This draft is a work item of the CURves, Deprecating and a Little > more > >>> >> Encryption of the IETF. > >>> >> > >>> >> Title : EdDSA for DNSSEC > >>> >> Authors : Ondrej Sury > >>> >> Robert Edmonds > >>> >> Filename : draft-ietf-curdle-dnskey-eddsa-02.txt > >>> >> Pages : 8 > >>> >> Date : 2016-11-14 > >>> >> > >>> >> Abstract: > >>> >> This document describes how to specify EdDSA keys and signature= s > in > >>> >> DNS Security (DNSSEC). It uses the Edwards-curve Digital > Security > >>> >> Algorithm (EdDSA) with the choice of two curves, Ed25519 and > Ed448. > >>> >> > >>> >> > >>> >> The IETF datatracker status page for this draft is: > >>> >> https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ > >>> >> > >>> >> There's also a htmlized version available at: > >>> >> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-02 > >>> >> > >>> >> A diff from the previous version is available at: > >>> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-dnskey-eddsa= -02 > >>> >> > >>> >> > >>> >> Please note that it may take a couple of minutes from the time of > >>> >> submission > >>> >> until the htmlized version and diff are available at tools.ietf.or= g > . > >>> >> > >>> >> Internet-Drafts are also available by anonymous FTP at: > >>> >> ftp://ftp.ietf.org/internet-drafts/ > >>> >> > >>> >> _______________________________________________ > >>> >> Curdle mailing list > >>> >> Curdle@ietf.org > >>> >> https://www.ietf.org/mailman/listinfo/curdle > >>> >> > >>> >> _______________________________________________ > >>> >> DNSOP mailing list > >>> >> DNSOP@ietf.org > >>> >> https://www.ietf.org/mailman/listinfo/dnsop > >>> > >>> _______________________________________________ > >>> DNSOP mailing list > >>> DNSOP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dnsop > >>> > >> > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a113fc0ee0c84ee054163f964 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks, i did not saw it. This is explicitely mentioned.
Yours,
Daniel


On Nov 16, 2016 1= :45 PM, "Ond=C5=99ej Sur=C3=BD" <ondrej.sury@nic.cz> wrote:
draft-irft-cfrg-eddsa states in Section 5.2:

=C2=A0 =C2=A0Value of context is set by signer and verifier (maximum of 255=
=C2=A0 =C2=A0octets, the default is empty string) and has to match octet by= octet
=C2=A0 =C2=A0for verification to be successful.

So in fact, the default context for Ed448 is "empty string".

Cheers,
Ondrej

--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Technical Fellow
=C2=A0--------------------------------------------
=C2=A0CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e C= Z.NIC
=C2=A0Milesovska 5, 130 00 Praha 3, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz= =C2=A0 =C2=A0 https://nic.cz/
=C2=A0--------------------------------------------

----- Original Message -----
> From: "Daniel Migault" <daniel.migault@ericsson.com>
> To: "Dick Franks" <rw= franks@acm.org>
> Cc: "dnsop" <dnsop@ietf= .org>, "Ond=C5=99ej Sur=C3=BD" <ondrej.sury@nic.cz>
> Sent: Wednesday, 16 November, 2016 05:23:23
> Subject: Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnske= y-eddsa-02.txt

> my understanding is that ed448 does not specify default values for the=
> context and i have not seen in the current draft a specification of th= e
> context. Shouldn't we explicitly mention that the context is empty= ?
> Yours,
> daniel
>
> On Nov 16, 2016 2:44 AM, "Dick Franks" <rwfranks@acm.org> wrote:
>
>> My mistake. Apologies.
>>
>> I also had draft-wouters-sury-dnsop-algorithm-update-02
>> on screen. That has the registry table with same TBDs.
>> Starting at 04:30 dulls the brain.
>>
>>
>> Dick Franks
>> ________________________
>>
>>
>> On 15 November 2016 at 17:05, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
>>
>>> The IANA Considerations Sections says:
>>>
>>> This document updates the IANA registry "Domain Name Syst= em Security
>>> (DNSSEC) Algorithm Numbers".
>>>
>>> And I believe that's the correct language according to
>>> https://tools.ietf.org/html/rfc5226= #section-5.1
>>>
>>> Cheers,
>>> Ondrej
>>>
>>> --
>>>=C2=A0 Ond=C5=99ej Sur=C3=BD -- Technical Fellow
>>>=C2=A0 --------------------------------------------
>>>=C2=A0 CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Labo= rato=C5=99e CZ.NIC
>>>=C2=A0 Milesovska 5, 130 00 Praha 3, Czech Republic
>>>=C2=A0 mailto:ondrej.sury= @nic.cz=C2=A0 =C2=A0 https://nic.cz/
>>>=C2=A0 --------------------------------------------
>>>
>>> ----- Original Message -----
>>> > From: "Dick Franks" <rwfranks@acm.org>
>>> > To: "Ond=C5=99ej Sur=C3=BD" <ondrej.sury@nic.cz>
>>> > Cc: "dnsop" <dnsop@ietf.org>
>>> > Sent: Tuesday, 15 November, 2016 17:51:56
>>> > Subject: Re: [DNSOP] Fwd: [Curdle] I-D Action:
>>> draft-ietf-curdle-dnskey-eddsa-02.txt
>>>
>>> > Ondrej
>>> >
>>> > The document calls up two TBD code points for the EDDSA a= lgorithms, but
>>> the
>>> > IANA Considerations section places no action on IANA to a= ssign these and
>>> > add them to the registry.
>>> >
>>> > Other than that, seems ok.
>>> >
>>> >
>>> > Dick Franks
>>> > ________________________
>>> >
>>> >
>>> > On 14 November 2016 at 23:22, Ond=C5=99ej Sur=C3=BD <<= a href=3D"mailto:ondrej.sury@nic.cz">ondrej.sury@nic.cz> wrote:
>>> >
>>> >> Dear all,
>>> >>
>>> >> a new version of EDDSA for DNSSEC has been posted
>>> >> that resolves most if not all comments received
>>> >> during WGLC in curdle.=C2=A0 This is one last chance<= br> >>> >> to review the document, so don't miss it! :)
>>> >>
>>> >> Cheers,
>>> >> --
>>> >>=C2=A0 Ond=C5=99ej Sur=C3=BD -- Technical Fellow
>>> >>=C2=A0 ------------------------------------------= --
>>> >>=C2=A0 CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 = =C2=A0Laborato=C5=99e CZ.NIC
>>> >>=C2=A0 Milesovska 5, 130 00 Praha 3, Czech Republic >>> >>=C2=A0 mailto:on= drej.sury@nic.cz=C2=A0 =C2=A0 https://nic.cz/
>>> >>=C2=A0 ------------------------------------------= --
>>> >>
>>> >> ----- Forwarded Message -----
>>> >> From: int= ernet-drafts@ietf.org
>>> >> To: i-d-anno= unce@ietf.org
>>> >> Cc: "curdle" <curdle@ietf.org>
>>> >> Sent: Tuesday, 15 November, 2016 00:10:15
>>> >> Subject: [Curdle] I-D Action: draft-ietf-curdle-dnske= y-eddsa-02.txt
>>> >>
>>> >> A New Internet-Draft is available from the on-line In= ternet-Drafts
>>> >> directories.
>>> >> This draft is a work item of the CURves, Deprecating = and a Little more
>>> >> Encryption of the IETF.
>>> >>
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: EdDSA for DNSSEC
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: Ondrej Sury
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Robert Edmonds
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2= =A0 =C2=A0 =C2=A0 : draft-ietf-curdle-dnskey-eddsa-02.txt
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: 8
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-11-14
>>> >>
>>> >> Abstract:
>>> >>=C2=A0 =C2=A0 This document describes how to specify E= dDSA keys and signatures in
>>> >>=C2=A0 =C2=A0 DNS Security (DNSSEC).=C2=A0 It uses the= Edwards-curve Digital Security
>>> >>=C2=A0 =C2=A0 Algorithm (EdDSA) with the choice of two= curves, Ed25519 and Ed448.
>>> >>
>>> >>
>>> >> The IETF datatracker status page for this draft is: >>> >> https://datatr= acker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/
>>> >>
>>> >> There's also a htmlized version available at:
>>> >> https://tools.iet= f.org/html/draft-ietf-curdle-dnskey-eddsa-02
>>> >>
>>> >> A diff from the previous version is available at:
>>> >> https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-dnskey-eddsa-02<= br> >>> >>
>>> >>
>>> >> Please note that it may take a couple of minutes from= the time of
>>> >> submission
>>> >> until the htmlized version and diff are available at = tool= s.ietf.org.
>>> >>
>>> >> Internet-Drafts are also available by anonymous FTP a= t:
>>> >> ftp://ftp.ietf.org/internet-drafts/<= /a>
>>> >>
>>> >> _______________________________________________<= br> >>> >> Curdle mailing list
>>> >> Curdle@ietf.org
>>> >> https://www.ietf.org/mailman/= listinfo/curdle
>>> >>
>>> >> _______________________________________________<= br> >>> >> DNSOP mailing list
>>> >> DNSOP@ietf.org<= br> >>> >> https://www.ietf.org/mailman/l= istinfo/dnsop
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/d= nsop
>>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop=
>>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--001a113fc0ee0c84ee054163f964-- From nobody Thu Nov 17 04:08:12 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC95129415 for ; Thu, 17 Nov 2016 04:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78bDUAWXwxuA for ; Thu, 17 Nov 2016 04:08:10 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE5B129781 for ; Thu, 17 Nov 2016 04:08:08 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CFCD4462B10 for ; Thu, 17 Nov 2016 12:08:07 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id B8AE4462B0C for ; Thu, 17 Nov 2016 12:08:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479384487; bh=cJk3pVZD1yLAF5UnzTE3foSpTekrtpf9tEKIYX36i0Q=; l=7150; h=From:To:Date:From; b=imB2lHK5f+wjFLNaTZAeuGD7fez7xUYXhJrJRgUT3ONTE9CQqJkXKKt3wCh7h9oYI xtIas1xNbQeLuvquG4EjHQFfv/PHAWH1rPnE5PsheHeQRw6dY/8er3G/xgGaiyjqOs Y/CQiE6BeG4XXwhaYfSmpuxLeqapxT2sTvLpvlvc= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A75BD1FC8B for ; Thu, 17 Nov 2016 12:08:07 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 17 Nov 2016 07:08:07 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 17 Nov 2016 07:08:06 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 17 Nov 2016 07:08:07 -0500 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Agenda / draft status Thread-Index: AdJAygfB0gQ0cVbdT2u1pzC9+6glpA== Date: Thu, 17 Nov 2016 12:08:06 +0000 Message-ID: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.126] Content-Type: multipart/alternative; boundary="_000_1a84efb68dad4227b505a1501966c379usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 12:08:12 -0000 --_000_1a84efb68dad4227b505a1501966c379usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We'll go over the documents, hopefully move some along. If you have any fe= edback, or in particular a *blocking item* to bring up, please reply here. draft-ietf-curdle-cms-chacha20-poly1305-03 - pub requested draft-ietf-curdle-cms-ecdh-new-curves-01 - ready for WGLC? Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algo= rithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) draft-ietf-curdle-cms-eddsa-signatures-00 - ready for WGLC? Use of EdDSA Signatures in the Cryptographic Message Syntax= (CMS) draft-ietf-curdle-dnskey-eddsa-02 EdDSA for DNSSEC draft-ietf-curdle-pkix-02 - ready for WGLC? Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448p= h, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure draft-ietf-curdle-rsa-sha2-02 - ready for WGLC? Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Have we properly divided/rationalized the following three? draft-ietf-curdle-ssh-ext-info-01 Extension Negotiation in Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-05 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH= ) draft-ietf-curdle-ssh-modp-dh-sha2-01 More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Grou= ps for Secure Shell (SSH) Overall consistency and "style" issues to discuss SHA256 v SHA512 - do we have an opinion/ recommendation? No contexts in signature (empty context where the sig format has one. Ok? --_000_1a84efb68dad4227b505a1501966c379usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ll go over the documents, hopefully move so= me along.  If you have any feedback, or in particular a *blocking i= tem* to bring up, please reply here.

        &nbs= p;      

draft-ietf-curdle-cms-chacha20-poly1305-03 – p= ub requested

draft-ietf-curdle-cms-ecdh-new-curves-01 – rea= dy for WGLC?

        &nbs= p;       Use of the Elliptic Curve Diffie-Hel= lamn Key Agreement Algorithm with X25519 and X448 in the Cryptographic Mess= age Syntax (CMS)

 

draft-ietf-curdle-cms-eddsa-signatures-00 – re= ady for WGLC?

        &nbs= p;       Use of EdDSA Signatures in the Crypt= ographic Message Syntax (CMS)

 

draft-ietf-curdle-dnskey-eddsa-02

        &nbs= p;       EdDSA for DNSSEC

 

draft-ietf-curdle-pkix-02 – ready for WGLC?

        &nbs= p;       Algorithm Identifiers for Ed25519, E= d25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Pub= lic Key Infrastructure

 

draft-ietf-curdle-rsa-sha2-02 – ready for WGLC= ?

Use of RSA Keys with SHA-= 2 256 and 512 in Secure Shell (SSH)

 

Have we properly divided/rationalized the following = three?

 

draft-ietf-curdle-ssh-ext-info-01

Extension Negotiation in = Secure Shell (SSH)

 

draft-ietf-curdle-ssh-kex-sha2-05

Key Exchange (KEX) Method= Updates and Recommendations for Secure Shell (SSH)

        &nbs= p;      

draft-ietf-curdle-ssh-modp-dh-sha2-01

More Modular Exponential = (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)=

 

Overall consistency and “style” issues t= o discuss

 

SHA256 v SHA512 – do we have an opinion/ recom= mendation?

 

No contexts in signature (empty context where the si= g format has one.  Ok?

 

--_000_1a84efb68dad4227b505a1501966c379usma1exdag1mb1msgcorpak_-- From nobody Thu Nov 17 06:30:24 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C42112996D for ; Thu, 17 Nov 2016 06:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Ykh_Gk866kIt for ; Thu, 17 Nov 2016 06:30:20 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6248F129468 for ; Thu, 17 Nov 2016 06:30:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8EAF0300AEB for ; Thu, 17 Nov 2016 09:20:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KrDD4sbpJ7m1 for ; Thu, 17 Nov 2016 09:20:00 -0500 (EST) Received: from dhcp-9bff.meeting.ietf.org (dhcp-9bff.meeting.ietf.org [31.133.155.255]) by mail.smeinc.net (Postfix) with ESMTPSA id 9EC8C30040E; Thu, 17 Nov 2016 09:19:58 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0227A4AF-AC69-4B4C-B7F3-00F739E9C8CD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 17 Nov 2016 09:19:33 -0500 Message-Id: <0BF13362-BCE7-42D0-81FD-AF98DB516CB5@vigilsec.com> References: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 14:30:22 -0000 --Apple-Mail=_0227A4AF-AC69-4B4C-B7F3-00F739E9C8CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Each of these need one more rev to align with curdle-pkix, and then they = will be ready for WGLC. On Nov 17, 2016, at 7:08 AM, Salz, Rich wrote: > draft-ietf-curdle-cms-ecdh-new-curves-01 =96 ready for WGLC? > Use of the Elliptic Curve Diffie-Hellamn Key Agreement = Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) > =20 > draft-ietf-curdle-cms-eddsa-signatures-00 =96 ready for WGLC? > Use of EdDSA Signatures in the Cryptographic Message = Syntax (CMS) --Apple-Mail=_0227A4AF-AC69-4B4C-B7F3-00F739E9C8CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Each = of these need one more rev to align with curdle-pkix, and then they will = be ready for WGLC.


On Nov 17, 2016, at = 7:08 AM, Salz, Rich <rsalz@akamai.com> = wrote:

draft-ietf-curdle-cms-ecdh-new-curves-01 =96 ready for = WGLC?
           &n= bsp;    Use of the Elliptic Curve Diffie-Hellamn Key = Agreement Algorithm with X25519 and X448 in the Cryptographic Message = Syntax (CMS)
 
draft-ietf-curdle-cms-eddsa-signatures-00 =96 ready for = WGLC?
           &n= bsp;    Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS)

= --Apple-Mail=_0227A4AF-AC69-4B4C-B7F3-00F739E9C8CD-- From nobody Fri Nov 18 20:06:28 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304D01294CC for ; Fri, 18 Nov 2016 20:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592] 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 yXWijp7nLyRh for ; Fri, 18 Nov 2016 20:06:25 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B56B31293F9 for ; Fri, 18 Nov 2016 20:06:25 -0800 (PST) Received: from fifthhorseman.net (unknown [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id DBAD4F99F for ; Fri, 18 Nov 2016 23:00:08 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0531621688; Sat, 19 Nov 2016 09:00:21 +0900 (KST) From: Daniel Kahn Gillmor To: Russ Housley , curdle@ietf.org In-Reply-To: <077D538E-5BA1-49AD-B0C6-26A31FF3607A@vigilsec.com> References: <077D538E-5BA1-49AD-B0C6-26A31FF3607A@vigilsec.com> Date: Fri, 18 Nov 2016 19:00:21 -0500 Message-ID: <87bmxcfiei.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 04:06:26 -0000 On Sat 2016-11-12 02:04:24 -0500, Russ Housley wrote: > Section 3 says: > > For all of the OIDs, the parameters MUST be absent. > Implementations SHOULD NOT accept a parameters value of NULL. > > I strongly agree that the parameters MUST be absent. > > If no one generates parameters, why do we need any discussion of NULL parameters? Or, better, make that SHOULD NOT into: Implementaions MUST NOT accept any of these OIDs with the parameters field present, even if parameters has a value of NULL. If we can convince the early implementations to hard-fail on that, we can discourage anyone from generating those values in newer implementations. --dkg From nobody Fri Nov 18 20:32:14 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BCA1295C8 for ; Fri, 18 Nov 2016 20:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCGJMHdlD70r for ; Fri, 18 Nov 2016 20:32:12 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6BA12949E for ; Fri, 18 Nov 2016 20:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479529931; x=1511065931; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3rMcgUcjeAOx5t2Xn9adm4QoqTAaznrKxXINj/q74XY=; b=b8owEO71sPRBknWoYPQaRTjsZY+RnvKlUr3VYZJUfWj8LwcLn85RZPvy w2CT2xZ/nkDifKQhGwAJ0kYXGSLRzIipm9FhBqsU6bvUDvxpe+6UZrJma vhaXFrZhgUYO2KabY3VE1xaaepxP/TNg4aRAEUTVcAjY8N1jigk0Za6oZ 3Gu9BWHBOIhXe4+u1eQoIohpdyftFoz3DUDo8UXL6avYHu3YCClzeUFJ3 2nk6n+Y89Crg2mUKxrjNp0CeyRKqT2jhw6nreJYbIi+W9P1cCeiyAuA2q CuEKimmSjO27OPplmmWvS8reJ3BwS9UZnjNDLhnoaR9eEeZrBfHUBlQ9B Q==; X-IronPort-AV: E=Sophos;i="5.31,513,1473076800"; d="scan'208";a="115902148" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Nov 2016 17:32:09 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 19 Nov 2016 17:32:03 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 19 Nov 2016 17:32:03 +1300 From: Peter Gutmann To: Daniel Kahn Gillmor , Russ Housley , "curdle@ietf.org" Thread-Topic: [Curdle] draft-ietf-curdle-pkix-02 Thread-Index: AQHSPLMIHDDbXgpVTEi6EXf76s2J/KDenIKAgAElvcs= Date: Sat, 19 Nov 2016 04:32:02 +0000 Message-ID: <1479529912550.49165@cs.auckland.ac.nz> References: <077D538E-5BA1-49AD-B0C6-26A31FF3607A@vigilsec.com>, <87bmxcfiei.fsf@alice.fifthhorseman.net> In-Reply-To: <87bmxcfiei.fsf@alice.fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 04:32:13 -0000 Daniel Kahn Gillmor writes:=0A= =0A= > Implementaions MUST NOT accept any of these OIDs with the parameters=0A= > field present, even if parameters has a value of NULL.=0A= >=0A= >If we can convince the early implementations to hard-fail on that, we can= =0A= >discourage anyone from generating those values in newer implementations.= =0A= =0A= +1. For once there's no argument for supporting existing broken=0A= implementations, we can get it right from the start.=0A= =0A= Peter.=0A= From nobody Sat Nov 19 04:37:09 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83558129879; Sat, 19 Nov 2016 04:37:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147955902853.30682.16172256951551668366.idtracker@ietfa.amsl.com> Date: Sat, 19 Nov 2016 04:37:08 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 12:37:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-eddsa-signatures-01.txt Pages : 7 Date : 2016-11-19 Abstract: This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatures-01 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 Sat Nov 19 04:38:57 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB8C12987A for ; Sat, 19 Nov 2016 04:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 hlgRiRYGS7g5 for ; Sat, 19 Nov 2016 04:38:54 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F34129879 for ; Sat, 19 Nov 2016 04:38:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 006E9300ADE for ; Sat, 19 Nov 2016 07:28:36 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id THQiXAosC79d for ; Sat, 19 Nov 2016 07:28:36 -0500 (EST) Received: from [10.35.131.136] (unknown [58.123.138.206]) by mail.smeinc.net (Postfix) with ESMTPSA id 2CCAE300A3C for ; Sat, 19 Nov 2016 07:28:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <147955902853.30682.16172256951551668366.idtracker@ietfa.amsl.com> Date: Sat, 19 Nov 2016 07:38:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147955902853.30682.16172256951551668366.idtracker@ietfa.amsl.com> To: curdle@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 12:38:56 -0000 This document is aligned with the current draft-ietf-curdle-pkix = document. I believe that it is ready for WG Last Call. Russ On Nov 19, 2016, at 7:37 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-eddsa-signatures-01.txt > Pages : 7 > Date : 2016-11-19 >=20 > Abstract: > This document specifies the conventions for using Edwards-curve > Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in > the Cryptographic Message Syntax (CMS). For each curve, EdDSA > defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA > mode is not used with the CMS. In addition, no context string is > used with the CMS. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -01 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 21 06:57:19 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BFD129AA7 for ; Mon, 21 Nov 2016 06:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcfybsruukIg for ; Mon, 21 Nov 2016 06:57:16 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B119129AB4 for ; Mon, 21 Nov 2016 06:57:15 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id n13so41629633ioe.2 for ; Mon, 21 Nov 2016 06:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=OvgwgytIE8n1rRa4lKInWmWpEICunzPhUBENG5WZ/0o=; b=dxb7uhAKYksxT/uWr54yt2NoRnmnHuN0m6hSu26ICLvEy8aA+HCzlUscVGgunJ5QuD i93gIu6mFQno+PH+WLmK8VKxbPUjRD1Axdnbpxo5MaKhhYBbFRk9ekxUHPAdiCxnUH+Z NGoAzLhSzyb1veb4p9QAp8vgCJwN8F65fOHBUrth6gSjBNPTrBw0OP+7ihey8HHdRmZH 4YA9cfqjqQ7LLqMZLqPInT970gtGjsgvEGHuqdj+dDM0wPl5I9ZaQuFoyj91hJygMV4K hw9dHZ5D8Fb2IwJEyZK5VRKCHoucUhJ91kvxd809bsaoZGyhuaPryN9ZjPLlIupLwraq gi/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=OvgwgytIE8n1rRa4lKInWmWpEICunzPhUBENG5WZ/0o=; b=LDjWOqUTl7Ys2DiQCfwNYnO3H8XOPcZM2npgssjohwSZQmYJPtsSC6XmL0/5zFcE5c E4nGgTvuDiOcw0FyW2zqvGakRK1ef9fexjMvmEMtPUmHKt/kR7xJ0b9NLcKlGx8vhY9K 0YsozrVMxTc2zRLFo7SyV4pduEmfyOvpdyzKzI8dhMeahBwunFfnBbgD5Ia6jfZt8O7/ aY8nIt9djlf47LAQnOEIq1a2b5TJYmh7H7DnQxaF5tp+nOaqlSEXYLtzeJUkuhrhku8z 5snZXpSnPx6Bm9eSVzdXkyPUbNKgip9xoYAxA0YMKz0dIQhNyWRKwtrw9NuRywHmhvxp HDzw== X-Gm-Message-State: AKaTC01QQMXnJQCMfKkSMn55QzWQe6gk4FL4aznoOHW8+mNqA8AJ4FQzxoS3WIM7NpeFbgEVTHfo8/ZKVtOcGg== X-Received: by 10.107.18.39 with SMTP id a39mr10594462ioj.45.1479740234475; Mon, 21 Nov 2016 06:57:14 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Mon, 21 Nov 2016 06:57:14 -0800 (PST) From: Daniel Migault Date: Mon, 21 Nov 2016 09:57:14 -0500 X-Google-Sender-Auth: rmJcE1tV08FVscMe882lSRnFIuw Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a113ff17c092e170541d0dff7 Archived-At: Subject: [Curdle] WGLC draft-ietf-curdle-cms-eddsa-signatures-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 14:57:17 -0000 --001a113ff17c092e170541d0dff7 Content-Type: text/plain; charset=UTF-8 Hi, This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-cms-eddsa-signatures-01. The version to be reviewed is https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ Please send your comments, questions, and edit proposals to the WG mail list until December 5, 2016. If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this. Yours, Rich and Daniel --001a113ff17c092e170541d0dff7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-cms-eddsa-signatures-01.

The version to be reviewed is https://datatracker.ietf.org= /doc/draft-ietf-curdle-cms-eddsa-signatures/

Please send your comments, questions, and edit proposals to the WG mail=20 list until December 5, 2016.=C2=A0 If you believe that the document is=20 ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.
=C2=A0
Yours,

Rich and Daniel

=
--001a113ff17c092e170541d0dff7-- From nobody Mon Nov 21 07:07:06 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0132D129AA0 for ; Mon, 21 Nov 2016 07:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjnS_Pb3BFNZ for ; Mon, 21 Nov 2016 07:07:03 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 30A6D1296CB for ; Mon, 21 Nov 2016 07:07:03 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id c20so88105386itb.0 for ; Mon, 21 Nov 2016 07:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HO4k2euLGp3mBURBKJpaNYnUIh/N3d+HYnFnlxukxgU=; b=hq4l8SUQNpeXaIiJDSyRHdoWQzhvvSF7LX7/lkG947jpNao0WEVKAT9o5fLIrwmEM2 2Kn5swDK1QQEJcd0oAwBT7kD7onhNIES2m7B/HLfqH69ZUeh+tlomPP1uTvx46RhMywG dFtC8dU2c1V+woRCQedZh6hOuerPHRNr6IP+oUcAouUqMpEHoijTzeEs23JWYRqEs2GP 7UasTEkW6uo6yUQ5sXlljrgj3umtxesKH34yvMPEZ0ZnumTPNx5Ippt1fgIyC9BPDqQu cHqRzE3FplwxuqU/pbDffS2+Xan+OMroDmCZUCr6EPwfFC69J5fk+5vwwddLSbOCaKRZ zLlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HO4k2euLGp3mBURBKJpaNYnUIh/N3d+HYnFnlxukxgU=; b=YQ0hNDhyuqD0h3OcgK6IiBPRtF9g9Ris5iJYLEbV2Z78KUA2nVbTT6jPw7vu3Bqrw+ R91fUojQlg2NkUThKZrRlhVFcQGKzHG02T2AKgistJZXVqbyPIPp0rRZdYFR8MwuAv6l esHcmL7ccIN9d+UYC2kfamh09btmddTi0UNvW+mnOtsk8GPcjAKEbJP8+vwuGtW5Cv1/ aZu+DihJj9SHS/hDGXNaC34ETTnpTnYRAmVHoihJhqssfCbTkUG9WGnTe9vYW4IR2kWm 0zQZ+wOboZDHeYxWcdgbA4JukRLP/1Pl30OzqC2lHpFsk4ssnp3RT+iWrD+pUtLU2U+6 wMww== X-Gm-Message-State: AKaTC00i/FxCOkN+SZgrxrZnJp6VKNy+Q91RX0Zshx7jRf3UwqPS100FuBM/Ndy6YlRBsiCxMaBWs5kEIH0I+g== X-Received: by 10.36.89.6 with SMTP id p6mr10006533itb.48.1479740822529; Mon, 21 Nov 2016 07:07:02 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Mon, 21 Nov 2016 07:07:01 -0800 (PST) In-Reply-To: <002f01d23975$c13182d0$43948870$@augustcellars.com> References: <002f01d23975$c13182d0$43948870$@augustcellars.com> From: Daniel Migault Date: Mon, 21 Nov 2016 10:07:01 -0500 X-Google-Sender-Auth: AG4c58BP2aXcux26TfHKBpqv4SE Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11445bf8162cdb0541d1020e Archived-At: Cc: curdle , Brian Smith Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 15:07:05 -0000 --001a11445bf8162cdb0541d1020e Content-Type: text/plain; charset=UTF-8 Hi, My interpretation is that there is a consensus the CRL MUST NOT use prehash scheme. Do we have any consensus for 1) OCSP request and 2) OCSP response ? Yours , Daniel On Mon, Nov 7, 2016 at 11:08 PM, Jim Schaad wrote: > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Brian Smith > *Sent:* Monday, November 07, 2016 7:43 PM > *To:* Daniel Migault > *Cc:* curdle > *Subject:* Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 > > > > Daniel Migault wrote: > > 5. Key Usage Bits > > > CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for > the creation of certificates or CRLs. This is implied by the fact > that those algorithms are not listed in the previous paragraph. > Additionally OCSP responders SHOULD NOT use the pre-hash versions of > the EdDSA algorithms when generating OCSP responses. No restriction > is placed on generation of OCSP requests. > > > > This doesn't make sense to me. Isn't the goal of the prehash scheme was to > support the signing of large things on systems without large amounts of > memory? Why would CRLs (which may be large) be MUST NOT while OCSP > responses are SHOULD NOT? It seems like the MUST NOT should be on > certificates and OCSP responses and OCSP requests, which are all small. > IIRC, there was some debate on whether CRLs should be allowed to use the > prehash variants since CRLs could be large. I personally thing all of the > cases mentioned in this paragraph should be MUST NOT. > > > > [JLS] There was a discussion on this. In my opinion, there was not a > consensus that was reached at that time. I have been busy getting wine > done so I did not ever get back to trying a third time to figure out a > consensus for this. It will definitely be on the discussion list for the > F2F but I am more than willing to start a discussion here again. > > > > The reason that CRLs are current a MUST NOT is that certificates and CRLs > are almost always generated using the same key as the certificate is. We > do not want to be in the situation where the same key is used with > different algorithms, so allowing pre-hash schemes on CRLs also allows > pre-hash schemes on certificates. > > > > I could go either way for OCSP responses. > > > > Jim > > > > > > Cheers, > > Brian > > -- > > https://briansmith.org/ > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a11445bf8162cdb0541d1020e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

My interpretation is that ther= e is a consensus the CRL MUST NOT use prehash scheme. Do we have any consen= sus for 1) OCSP request and 2) OCSP response ?

Yours ,
Daniel




On Mon, Nov 7, 2016 at 11:08 PM, Ji= m Schaad <ietf@augustcellars.com> wrote:

=C2=A0

=C2=A0

From: Curd= le [mailto:cur= dle-bounces@ietf.org] On Behalf Of Brian Smith
Sent:<= /b> Monday, November 07, 2016 7:43 PM
To: Daniel Migault <daniel.migault= @ericsson.com>
Cc: curdle <curdle@ietf.org>
Subject: Re: [Cu= rdle] WGLC on draft-ietf-curdle-pkix-02

=C2=A0

Daniel Migault <daniel.migault@ericsson.com> w= rote:

=

5.=C2=A0 Key Usage Bits


=C2=A0=C2= =A0 CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for
= =C2=A0=C2=A0 the creation of certificates or CRLs.=C2=A0 This is implied by= the fact
=C2=A0=C2=A0 that those algorithms are not listed in the previ= ous paragraph.
=C2=A0=C2=A0 Additionally OCSP responders SHOULD NOT use = the pre-hash versions of
=C2=A0=C2=A0 the EdDSA algorithms when generati= ng OCSP responses.=C2=A0 No restriction
=C2=A0=C2=A0 is placed on genera= tion of OCSP requests.

=C2=A0

This doesn't make sense to me. Isn't= the goal of the prehash scheme was to support the signing of large things = on systems without large amounts of memory? Why would CRLs (which may be la= rge) be MUST NOT while OCSP responses are SHOULD NOT? It seems like the MUS= T NOT should be on certificates and OCSP responses and OCSP requests, which= are all small. IIRC, there was some debate on whether CRLs should be allow= ed to use the prehash variants since CRLs could be large. I personally thin= g all of the cases mentioned in this paragraph should be MUST NOT.

=C2=A0

[JLS] There was a discussion on this.=C2=A0 In my opini= on, there was not a consensus that was reached at that time.=C2=A0 I have b= een busy getting wine done so I did not ever get back to trying a third tim= e to figure out a consensus for this.=C2=A0 It will definitely be on the di= scussion list for the F2F but I am more than willing to start a discussion = here again.

=C2=A0

The reason that CRLs are current a = MUST NOT is that certificates and CRLs are almost always generated using th= e same key as the certificate is.=C2=A0 We do not want to be in the situati= on where the same key is used with different algorithms, so allowing pre-ha= sh schemes on CRLs also allows pre-hash schemes on certificates.<= /u>

=C2=A0

I could go either way for OCSP responses.

=C2=A0

Jim

=C2= =A0

=C2=A0=

Cheers,

<= p class=3D"MsoNormal">Brian

--


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

--001a11445bf8162cdb0541d1020e-- From nobody Mon Nov 21 10:24:51 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FFE129B3E for ; Mon, 21 Nov 2016 10:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0vXPFW9TUEy for ; Mon, 21 Nov 2016 10:24:48 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66AA129603 for ; Mon, 21 Nov 2016 10:24:47 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 21 Nov 2016 10:42:22 -0800 From: Jim Schaad To: 'Daniel Migault' References: <002f01d23975$c13182d0$43948870$@augustcellars.com> In-Reply-To: Date: Mon, 21 Nov 2016 10:24:39 -0800 Message-ID: <072301d24424$86e93eb0$94bbbc10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0724_01D243E1.78C82190" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGAWKY219/NXai3eEt9BAwJpSshJwCppyDZAyFA3yEBzzKJHgEZets0oVH4uOA= X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'curdle' Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 18:24:50 -0000 ------=_NextPart_000_0724_01D243E1.78C82190 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think that we cannot do a restriction on OCSP requests. One cannot = know in advance what the algorithm that a client wants to use. Allowing = both here is not a big problem for key usages. =20 The question on OCSP responses has to do with if you think that the OCSP = responder is going to be using the same key as the CA or is = independently operated. In the first case the restriction to pure is = justified. In the second case the only reason for it is to restrict the = set of things that must be implemented. When I wrote the text I assumed = that the first case was more often the case, but I have no data to back = that up. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault Sent: Monday, November 21, 2016 7:07 AM To: Jim Schaad Cc: curdle ; Brian Smith Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 =20 Hi,=20 My interpretation is that there is a consensus the CRL MUST NOT use = prehash scheme. Do we have any consensus for 1) OCSP request and 2) OCSP = response ? Yours , Daniel =20 =20 On Mon, Nov 7, 2016 at 11:08 PM, Jim Schaad > wrote: =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of Brian Smith Sent: Monday, November 07, 2016 7:43 PM To: Daniel Migault > Cc: curdle > Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 =20 Daniel Migault > wrote: 5. Key Usage Bits CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of certificates or CRLs. This is implied by the fact that those algorithms are not listed in the previous paragraph. Additionally OCSP responders SHOULD NOT use the pre-hash versions of the EdDSA algorithms when generating OCSP responses. No restriction is placed on generation of OCSP requests. =20 This doesn't make sense to me. Isn't the goal of the prehash scheme was = to support the signing of large things on systems without large amounts = of memory? Why would CRLs (which may be large) be MUST NOT while OCSP = responses are SHOULD NOT? It seems like the MUST NOT should be on = certificates and OCSP responses and OCSP requests, which are all small. = IIRC, there was some debate on whether CRLs should be allowed to use the = prehash variants since CRLs could be large. I personally thing all of = the cases mentioned in this paragraph should be MUST NOT. =20 [JLS] There was a discussion on this. In my opinion, there was not a = consensus that was reached at that time. I have been busy getting wine = done so I did not ever get back to trying a third time to figure out a = consensus for this. It will definitely be on the discussion list for = the F2F but I am more than willing to start a discussion here again. =20 The reason that CRLs are current a MUST NOT is that certificates and = CRLs are almost always generated using the same key as the certificate = is. We do not want to be in the situation where the same key is used = with different algorithms, so allowing pre-hash schemes on CRLs also = allows pre-hash schemes on certificates. =20 I could go either way for OCSP responses. =20 Jim =20 =20 Cheers, Brian --=20 https://briansmith.org/ =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 ------=_NextPart_000_0724_01D243E1.78C82190 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I think that = we cannot do a restriction on OCSP requests.=C2=A0 One cannot know in = advance what the algorithm that a client wants to use.=C2=A0 Allowing = both here is not a big problem for key usages.

 

The question = on OCSP responses has to do with if you think that the OCSP responder is = going to be using the same key as the CA or is independently = operated.=C2=A0 In the first case the restriction to pure is = justified.=C2=A0 In the second case the only reason for it is to = restrict the set of things that must be implemented.=C2=A0 When I wrote = the text I assumed that the first case was more often the case, but I = have no data to back that up.

 

Jim

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault
Sent: Monday, November 21, 2016 7:07 AM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: curdle = <curdle@ietf.org>; Brian Smith = <brian@briansmith.org>
Subject: Re: [Curdle] WGLC on = draft-ietf-curdle-pkix-02

 

Hi,

My interpretation is = that there is a consensus the CRL MUST NOT use prehash scheme. Do we = have any consensus for 1) OCSP request and 2) OCSP response = ?

Yours = ,

Daniel

 

 

On Mon, = Nov 7, 2016 at 11:08 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 =

 =

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Brian = Smith
Sent: Monday, November 07, 2016 7:43 PM
To: = Daniel Migault <daniel.migault@ericsson.com>
Cc: = curdle <curdle@ietf.org>
Subject: Re: = [Curdle] WGLC on = draft-ietf-curdle-pkix-02

 <= /o:p>

Daniel = Migault <daniel.migault@ericsson.com> = wrote:

5.  = Key Usage Bits


 &n= bsp; CAs MUST NOT use the pre-hash versions of the EdDSA algorithms = for
   the creation of certificates or CRLs.  This is = implied by the fact
   that those algorithms are not listed = in the previous paragraph.
   Additionally OCSP responders = SHOULD NOT use the pre-hash versions of
   the EdDSA = algorithms when generating OCSP responses.  No = restriction
   is placed on generation of OCSP = requests.

 <= /o:p>

This = doesn't make sense to me. Isn't the goal of the prehash scheme was to = support the signing of large things on systems without large amounts of = memory? Why would CRLs (which may be large) be MUST NOT while OCSP = responses are SHOULD NOT? It seems like the MUST NOT should be on = certificates and OCSP responses and OCSP requests, which are all small. = IIRC, there was some debate on whether CRLs should be allowed to use the = prehash variants since CRLs could be large. I personally thing all of = the cases mentioned in this paragraph should be MUST = NOT.

 =

[JLS] There = was a discussion on this.  In my opinion, there was not a consensus = that was reached at that time.  I have been busy getting wine done = so I did not ever get back to trying a third time to figure out a = consensus for this.  It will definitely be on the discussion list = for the F2F but I am more than willing to start a discussion here = again.

 =

The reason = that CRLs are current a MUST NOT is that certificates and CRLs are = almost always generated using the same key as the certificate is.  = We do not want to be in the situation where the same key is used with = different algorithms, so allowing pre-hash schemes on CRLs also allows = pre-hash schemes on certificates.

 =

I could go = either way for OCSP responses.

 =

Jim

 =

 <= /o:p>

Cheers,=

Brian

-- =


______________________________________= _________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

 

------=_NextPart_000_0724_01D243E1.78C82190-- From nobody Tue Nov 22 03:08:41 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2648C1295A7 for ; Tue, 22 Nov 2016 03:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3dw-6WAbbKE for ; Tue, 22 Nov 2016 03:08:37 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9319E129532 for ; Tue, 22 Nov 2016 03:08:37 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3DA3F3B3C7; Tue, 22 Nov 2016 11:08:37 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.184]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAMB8Yg4011616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Nov 2016 06:08:36 -0500 Message-ID: <1479812914.31825.25.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" , "curdle@ietf.org" Date: Tue, 22 Nov 2016 12:08:34 +0100 In-Reply-To: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 22 Nov 2016 11:08:37 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 11:08:39 -0000 On Thu, 2016-11-17 at 12:08 +0000, Salz, Rich wrote: > We’ll go over the documents, hopefully move some along.  If you have > any feedback, or in particular a *blocking item* to bring up, please > reply here.   > draft-ietf-curdle-cms-eddsa-signatures-00 – ready for WGLC? >                 Use of EdDSA Signatures in the Cryptographic > Message   > draft-ietf-curdle-dnskey-eddsa-02 >                 EdDSA for DNSSEC > draft-ietf-curdle-pkix-02 – ready for WGLC? >                 Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, > Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key > Infrastructure Are there any implementations of the above drafts? regards, Nikos From nobody Tue Nov 22 08:47:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCE2129509 for ; Tue, 22 Nov 2016 08:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] 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 Oize1apsYd1Q for ; Tue, 22 Nov 2016 08:47:24 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 973CA127ABE for ; Tue, 22 Nov 2016 08:47:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id D769E143BD; Tue, 22 Nov 2016 18:47:22 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Dpv1mxN5Hyv7; Tue, 22 Nov 2016 18:47:22 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 91F342310; Tue, 22 Nov 2016 18:47:22 +0200 (EET) Date: Tue, 22 Nov 2016 18:47:17 +0200 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20161122164717.GA27974@LK-Perkele-V2.elisa-laajakaista.fi> References: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> <1479812914.31825.25.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1479812914.31825.25.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "Salz, Rich" , "curdle@ietf.org" Subject: Re: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 16:47:26 -0000 On Tue, Nov 22, 2016 at 12:08:34PM +0100, Nikos Mavrogiannopoulos wrote: > On Thu, 2016-11-17 at 12:08 +0000, Salz, Rich wrote: >   > > draft-ietf-curdle-pkix-02 – ready for WGLC? > >                 Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, > > Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key > > Infrastructure > > Are there any implementations of the above drafts? I have an implemntation of the PKIX one (Ed25519 and Ed448 only, no pre- hash variants). -Ilari From nobody Tue Nov 22 09:06:06 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2319C129645 for ; Tue, 22 Nov 2016 09:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd3I1ZxSFzS3 for ; Tue, 22 Nov 2016 09:06:02 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D44127A90 for ; Tue, 22 Nov 2016 09:06:02 -0800 (PST) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id CC2866098C; Tue, 22 Nov 2016 18:06:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1479834360; bh=8refwDxKXhL24ecRDtT8+frx2VQFrvaqF3f+5IASpw4=; h=Date:From:To; b=h+Zhrz5StVAAAnTnjrXFAYkYoX0yuIWtN5XkQ3K3dykMQaOY7JxIlbqUvlNK+k+4V bg62LV3ZOXKaofH1j7yCBSeFKJYDiQ5Jc0Zdw57w6KzcCtK6PLqwm5wt9HnW1DMHM/ TCdHF0/gEQxTNGwgbOp89Z/xPB5wnqsQnvrf8d+c= Date: Tue, 22 Nov 2016 18:06:00 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Nikos Mavrogiannopoulos Message-ID: <948865652.6192.1479834360718.JavaMail.zimbra@nic.cz> In-Reply-To: <1479812914.31825.25.camel@redhat.com> References: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> <1479812914.31825.25.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF50 (Linux)/8.7.0_GA_1659) Thread-Topic: Agenda / draft status Thread-Index: qNDVSZeED/850oBDVP/ryBHdKBKncw== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "Salz, Rich" , curdle Subject: Re: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 17:06:05 -0000 PowerDNS has a preliminary implementation of Ed25519 support using SUPERCOP= . And I have written crude RRSIG generator to generate examples in DNSKEY dra= ft using python3 library from cfrg-eddsa draft: https://gitlab.labs.nic.cz/labs/ietf/blob/master/dnskey.py Cheers, Ondrej -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Nikos Mavrogiannopoulos" > To: "Salz, Rich" , "curdle" > Sent: Tuesday, 22 November, 2016 12:08:34 > Subject: Re: [Curdle] Agenda / draft status > On Thu, 2016-11-17 at 12:08 +0000, Salz, Rich wrote: >> We=E2=80=99ll go over the documents, hopefully move some along.=C2=A0 If= you have >> any feedback, or in particular a *blocking item* to bring up, please >> reply here. >=C2=A0 >> draft-ietf-curdle-cms-eddsa-signatures-00 =E2=80=93 ready for WGLC? >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Use of EdDSA Signatures in the Cryptographic >> Message >> draft-ietf-curdle-dnskey-eddsa-02 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 EdDSA for DNSSEC >> draft-ietf-curdle-pkix-02 =E2=80=93 ready for WGLC? >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, >> Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key >> Infrastructure >=20 > Are there any implementations of the above drafts? >=20 > regards, > Nikos >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Nov 22 11:17:43 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21F129E96 for ; Tue, 22 Nov 2016 11:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3FsjazCrnBU for ; Tue, 22 Nov 2016 11:17:40 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 12B6F129E97 for ; Tue, 22 Nov 2016 11:17:14 -0800 (PST) X-AuditID: c6180641-2580a98000000a0b-29-583445508114 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id 68.44.02571.05544385; Tue, 22 Nov 2016 14:17:04 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Tue, 22 Nov 2016 14:17:12 -0500 From: Daniel Migault To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= , "Nikos Mavrogiannopoulos" Thread-Topic: Agenda / draft status Thread-Index: AQHSROK5zEC3v7HVUEysSPRe0mBZUqDlYB7A Date: Tue, 22 Nov 2016 19:17:11 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117FE15CC@eusaamb107.ericsson.se> References: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> <1479812914.31825.25.camel@redhat.com> <948865652.6192.1479834360718.JavaMail.zimbra@nic.cz> In-Reply-To: <948865652.6192.1479834360718.JavaMail.zimbra@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHTzfA1STCoGOmqcXWhbOYLX4c3cpi 0bLcxeL/lk4WBxaPyUcWMHssWfKTyWPT5TuMHu/3XWULYInisklJzcksSy3St0vgyvj+wKzg i3jF3Ja/zA2MS8S7GDk5JARMJPbu/cDUxcjFISSwnlHi6/wOZghnOaNEx9cFzCBVbAJGEm2H +tlBbBGBDIn5e2aygNjMArYSR5bsBYsLCyhJtHzeDWRzANUoS0yeFgdRbiTx7F4bK4jNIqAq 8fdNF5jNK+ArceLVPqhdmxklutYtAJvDKeAk0Tf3FJjNKCAm8f3UGiaIXeISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YIWxFiX3908FuYBbQlFi/Sx+iVVFiSvdDdoi9ghInZz5hmcAoOgvJ1FkI HbOQdMxC0rGAkWUVI0dpcUFObrqR4SZGYLwck2Bz3MG4t9fzEKMAB6MSD6+BqkmEEGtiWXFl 7iFGCQ5mJRHeeZOBQrwpiZVVqUX58UWlOanFhxilOViUxHmvh9wPFxJITyxJzU5NLUgtgsky cXBKNTDOs5jb38csVz+38ZTTJHP+IvYpgcrrmjnt5c8W8ClJqa1n/LdXPOeZnR3n81qODcKd 0//3GST35lzm1GmMn8/x6/hkf9Nq8f72U7JfjA+uVL49ffW5bv9mjgKu1XPfiSXr+v54eeFF ybXbB362cSYtjnxp0HFlZrWh4GJ2EfWsVt1/z87XVSixFGckGmoxFxUnAgB0TPHPkwIAAA== Archived-At: Cc: "Salz, Rich" , curdle Subject: Re: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 19:17:42 -0000 SGkgT25kcmVqLCANCg0KVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24hDQoNCllvdXJzLCANCkRh bmllbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ3VyZGxlIFttYWlsdG86 Y3VyZGxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPbmRyZWogU3Vyw70NClNlbnQ6 IFR1ZXNkYXksIE5vdmVtYmVyIDIyLCAyMDE2IDEyOjA2IFBNDQpUbzogTmlrb3MgTWF2cm9naWFu bm9wb3Vsb3MgPG5tYXZAcmVkaGF0LmNvbT4NCkNjOiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWku Y29tPjsgY3VyZGxlIDxjdXJkbGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0N1cmRsZV0gQWdl bmRhIC8gZHJhZnQgc3RhdHVzDQoNClBvd2VyRE5TIGhhcyBhIHByZWxpbWluYXJ5IGltcGxlbWVu dGF0aW9uIG9mIEVkMjU1MTkgc3VwcG9ydCB1c2luZyBTVVBFUkNPUC4NCg0KQW5kIEkgaGF2ZSB3 cml0dGVuIGNydWRlIFJSU0lHIGdlbmVyYXRvciB0byBnZW5lcmF0ZSBleGFtcGxlcyBpbiBETlNL RVkgZHJhZnQgdXNpbmcgcHl0aG9uMyBsaWJyYXJ5IGZyb20gY2ZyZy1lZGRzYSBkcmFmdDoNCmh0 dHBzOi8vZ2l0bGFiLmxhYnMubmljLmN6L2xhYnMvaWV0Zi9ibG9iL21hc3Rlci9kbnNrZXkucHkN Cg0KQ2hlZXJzLA0KT25kcmVqDQoNCi0tDQogT25kxZllaiBTdXLDvSAtLSBUZWNobmljYWwgRmVs bG93DQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBDWi5O SUMsIHoucy5wLm8uICAgIC0tICAgICBMYWJvcmF0b8WZZSBDWi5OSUMNCiBNaWxlc292c2thIDUs IDEzMCAwMCBQcmFoYSAzLCBDemVjaCBSZXB1YmxpYw0KIG1haWx0bzpvbmRyZWouc3VyeUBuaWMu Y3ogICAgaHR0cHM6Ly9uaWMuY3ovDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiTmlr b3MgTWF2cm9naWFubm9wb3Vsb3MiIDxubWF2QHJlZGhhdC5jb20+DQo+IFRvOiAiU2FseiwgUmlj aCIgPHJzYWx6QGFrYW1haS5jb20+LCAiY3VyZGxlIiA8Y3VyZGxlQGlldGYub3JnPg0KPiBTZW50 OiBUdWVzZGF5LCAyMiBOb3ZlbWJlciwgMjAxNiAxMjowODozNA0KPiBTdWJqZWN0OiBSZTogW0N1 cmRsZV0gQWdlbmRhIC8gZHJhZnQgc3RhdHVzDQoNCj4gT24gVGh1LCAyMDE2LTExLTE3IGF0IDEy OjA4ICswMDAwLCBTYWx6LCBSaWNoIHdyb3RlOg0KPj4gV2XigJlsbCBnbyBvdmVyIHRoZSBkb2N1 bWVudHMsIGhvcGVmdWxseSBtb3ZlIHNvbWUgYWxvbmcuwqAgSWYgeW91IGhhdmUgDQo+PiBhbnkg ZmVlZGJhY2ssIG9yIGluIHBhcnRpY3VsYXIgYSAqYmxvY2tpbmcgaXRlbSogdG8gYnJpbmcgdXAs IHBsZWFzZSANCj4+IHJlcGx5IGhlcmUuDQo+wqANCj4+IGRyYWZ0LWlldGYtY3VyZGxlLWNtcy1l ZGRzYS1zaWduYXR1cmVzLTAwIOKAkyByZWFkeSBmb3IgV0dMQz8NCj4+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBVc2Ugb2YgRWREU0EgU2lnbmF0dXJlcyBpbiB0aGUgQ3J5cHRvZ3Jh cGhpYyBNZXNzYWdlDQo+PiBkcmFmdC1pZXRmLWN1cmRsZS1kbnNrZXktZWRkc2EtMDINCj4+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBFZERTQSBmb3IgRE5TU0VDDQo+PiBkcmFmdC1p ZXRmLWN1cmRsZS1wa2l4LTAyIOKAkyByZWFkeSBmb3IgV0dMQz8NCj4+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBBbGdvcml0aG0gSWRlbnRpZmllcnMgZm9yIEVkMjU1MTksIEVkMjU1 MTlwaCwgRWQ0NDgsIA0KPj4gRWQ0NDhwaCwgWDI1NTE5IGFuZCBYNDQ4IGZvciB1c2UgaW4gdGhl IEludGVybmV0IFguNTA5IFB1YmxpYyBLZXkgDQo+PiBJbmZyYXN0cnVjdHVyZQ0KPiANCj4gQXJl IHRoZXJlIGFueSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIGFib3ZlIGRyYWZ0cz8NCj4gDQo+IHJl Z2FyZHMsDQo+IE5pa29zDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBDdXJkbGUgbWFpbGluZyBsaXN0DQo+IEN1cmRsZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ3VyZGxlIG1haWxpbmcg bGlzdA0KQ3VyZGxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2N1cmRsZQ0K From nobody Tue Nov 22 13:05:41 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8F1297AA for ; Tue, 22 Nov 2016 13:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM5hU0uPsbQv for ; Tue, 22 Nov 2016 13:05:38 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30BE129518 for ; Tue, 22 Nov 2016 13:05:37 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Nov 2016 13:23:00 -0800 From: Jim Schaad To: 'Nikos Mavrogiannopoulos' , "'Salz, Rich'" , References: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> <1479812914.31825.25.camel@redhat.com> In-Reply-To: <1479812914.31825.25.camel@redhat.com> Date: Tue, 22 Nov 2016 13:05:18 -0800 Message-ID: <08f601d24504$22921370$67b63a50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL7L2JQ82FfpJxOQ6jnPI3cdymY5wGYIwHpnoblTUA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 21:05:40 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos > Mavrogiannopoulos > Sent: Tuesday, November 22, 2016 3:09 AM > To: Salz, Rich ; curdle@ietf.org > Subject: Re: [Curdle] Agenda / draft status >=20 > On Thu, 2016-11-17 at 12:08 +0000, Salz, Rich wrote: > > We=E2=80=99ll go over the documents, hopefully move some along. If = you have > > any feedback, or in particular a *blocking item* to bring up, please > > reply here. >=20 > > draft-ietf-curdle-cms-eddsa-signatures-00 =E2=80=93 ready for WGLC? > > Use of EdDSA Signatures in the Cryptographic Message > > draft-ietf-curdle-dnskey-eddsa-02 > > EdDSA for DNSSEC > > draft-ietf-curdle-pkix-02 =E2=80=93 ready for WGLC? > > Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, > > Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key > > Infrastructure >=20 > Are there any implementations of the above drafts? What do you consider to be an implementation? =20 The certificate at the end of draft-ietf-curdle-pkix-02 is created by a = program that was generated in part from the ASN.1 module. The rest of = the examples were also generated in the same way, but this is not a CA = and I did not setup so that I could use the certificate in a browser or = email program. I have done a paper fill in the fields for the cms draft, which lead to = several changes in the draft over the last week as we tried to get = things correct, but I have not yet done the same thing in an ASN.1 = structure and then encoded it using a program. However, again this is = not going to be like it is an Email client implementing S/MIME. =20 Jim >=20 > regards, > Nikos >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Nov 23 00:32:26 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9878E129634 for ; Wed, 23 Nov 2016 00:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeB8gxlxrgkd for ; Wed, 23 Nov 2016 00:32:23 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDF61295D4 for ; Wed, 23 Nov 2016 00:32:23 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 57A9280F94; Wed, 23 Nov 2016 08:32:23 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.184]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAN8WKn6001262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 03:32:22 -0500 Message-ID: <1479889940.2563.17.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Date: Wed, 23 Nov 2016 09:32:20 +0100 In-Reply-To: <20161122164717.GA27974@LK-Perkele-V2.elisa-laajakaista.fi> References: <1a84efb68dad4227b505a1501966c379@usma1ex-dag1mb1.msg.corp.akamai.com> <1479812914.31825.25.camel@redhat.com> <20161122164717.GA27974@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 23 Nov 2016 08:32:23 +0000 (UTC) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Agenda / draft status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 08:32:24 -0000 On Tue, 2016-11-22 at 18:47 +0200, Ilari Liusvaara wrote: > On Tue, Nov 22, 2016 at 12:08:34PM +0100, Nikos Mavrogiannopoulos > wrote: > > > > On Thu, 2016-11-17 at 12:08 +0000, Salz, Rich wrote: > >   > > > > > > draft-ietf-curdle-pkix-02 – ready for WGLC? > > >                 Algorithm Identifiers for Ed25519, Ed25519ph, > > > Ed448, > > > Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key > > > Infrastructure > > > > Are there any implementations of the above drafts? > > I have an implemntation of the PKIX one (Ed25519 and Ed448 only, no > pre- > hash variants). Thanks, it is available somewhere? I am gathering references to carry interop testing once I have something more tangible for gnutls. regards, Nikos From nobody Wed Nov 23 12:13:15 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF68129B42 for ; Wed, 23 Nov 2016 12:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUNn0IJmw7ME for ; Wed, 23 Nov 2016 12:13:12 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 81BE012958F for ; Wed, 23 Nov 2016 12:13:12 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id j65so43921380iof.0 for ; Wed, 23 Nov 2016 12:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=2w1CPeznXKmWSPzo+l2NGIS4CuQtpp/b0+wadh9Q/WI=; b=iBWqVZCbJHnuYxzx6HNC9M9hHp4UviyO7FLc963WMnPNkPyw2AapsH55pfjh5b4kYZ qd1ZRPawbG+uvLxmQFbLq1DUfRjhCZu/im55/uFAqFwKbiMbTHc6xu58/KR7DZS6m4jl VtJGe9kH3kEHavf8WpKD5YGLYPWP273erulPcSkRCpSOM4l7zfkr3+q/1rzYM674GCOT EYjD67ChqmEktW+e2OgdO55JD9J9PiIaIqDu9PHtqwkFfsy3/dwpHT3jXfmeT4VFizI0 1AUg/QvZnvnkGUI+hxixVLRQcxSFaQnnu6AwPRxixegETI94wesBQjhKufs4LFalcFeb 37wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=2w1CPeznXKmWSPzo+l2NGIS4CuQtpp/b0+wadh9Q/WI=; b=Z7QnKpSZJycRGNbzmxW1GlPHFH10ZCjrElvpwDCpHwCDte5Dl45kkMy2hN7+wJNsw3 ymC6woheXXusqstb8lQCb9lKTmWKGGjXiPvaze8x4dmwsbsJ9EBDHJ/Fp4csm00sC+hH 3xItk1SNJoU5mZeCDW1wjFWZmiBNEPNLzPv9ouIV2RRcV6k8xnZ1do3uFpjxQdLX3CqM nUlPpObmTe0yBgCyPq3hVs3Y4U9vZR82QQYe2oFjLmijhEhGBBIJGzKfuWWoUu5C01q7 ixvMUgekyxnd/A3dov3LUQyXyLJOUJTxRFbsQA0UkW2gv1Gw5/x63951pJk3p7ZupXPf 3DXg== X-Gm-Message-State: AKaTC00FAbQaUgRRLMIlG7F9RzxkOmQ2lcoWWqvwIAdSjohKT9xtkRqREUAkhzhfVVxvaTFlAohkXWjypcWamA== X-Received: by 10.107.179.195 with SMTP id c186mr4582884iof.35.1479931991634; Wed, 23 Nov 2016 12:13:11 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.47.225 with HTTP; Wed, 23 Nov 2016 12:13:11 -0800 (PST) From: Daniel Migault Date: Wed, 23 Nov 2016 15:13:11 -0500 X-Google-Sender-Auth: ksnSJaopP9cyVeR0XzrJSuMMhtM Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11484830a7362e0541fd8407 Archived-At: Subject: [Curdle] Fwd: NomCom 2016-2017: LastCall for Feedback Nov 24: 23:59 UTC X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 20:13:14 -0000 --001a11484830a7362e0541fd8407 Content-Type: text/plain; charset=UTF-8 Hi, You are more than welcome to provide feedback for the current Nominees, especially since several involved folks are nominated here ! Yours, Daniel -------- Forwarded Message -------- Subject: NomCom 2016-2017: LastCall for Feedback Date: Tue, 22 Nov 2016 10:38:07 -0800 From: NomCom Chair 2016 Reply-To: ietf@ietf.org To: IETF Announcement List CC: ietf@ietf.org Just a reminder that feedback for the current Nominees for IETF and IAB leadership is due by 23:59 UTC on Thursday, November 24, 2016. You can view the list of nominees and enter feedback via the datatracker: https://datatracker.ietf.org/nomcom/2016/feedback/ or you can provide your input by sending email to: nomcom-2016 @ ietf.org You can also send general feedback about Areas, the IESG, The IAB, and the IAOC to the same email address. The NomCom is particularly interested in your feedback on the IAOC and the current nominees given the discussion of IASA 2.0 as outlined in plenary at IETF 97. We would also like to encourage feedback on all of the nominees. Please take a few moments to comment on the full range of nominees in areas where you are active. We have good responses for some but not all of our pool and would appreciate additional input. Lucy Lynch NomCom Chair 2016-2017 llynch @ civil-tongue.net --001a11484830a7362e0541fd8407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
<= div>

You are more than welcome to provide feedback for the cu= rrent Nominees, especially since several involved folks are nominated here !

Yours,

Daniel
-------- Forwarded Message --------
Subject: NomCom 2016-2017: LastCall for Feedback
Date: Tue, 22 Nov 2016 10:38:07 -0800
From: NomCom Chair 2016 <nomcom-chair-2016@ietf.org>
Reply-To: ietf@ietf.org<= /a>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: ietf@ietf.org
Just a reminder that feedback for the current Nominees for IETF and IAB lea= dership is due by 23:59 UTC on Thursday, November 24, 2016.

You can view the list of nominees and enter feedback via the datatracker:
https://datatracker.ietf.org/nomcom/2016/feed= back/

or you can provide your input by sending email to:

nomcom-2016 @ ietf.org

You can also send general feedback about Areas, the IESG, The IAB, and
the IAOC to the same email address.

The NomCom is particularly interested in your feedback on the IAOC and the = current nominees given the discussion of IASA 2.0 as outlined in
plenary at IETF 97. We would also like to encourage feedback on all of
the nominees. Please take a few moments to comment on the full range
of nominees in areas where you are active. We have good responses for some = but not all of our pool and would appreciate additional input.

Lucy Lynch
NomCom Chair 2016-2017
llynch @ civil-tongue.net



--001a11484830a7362e0541fd8407-- From nobody Wed Nov 23 13:16:31 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A717512978B; Wed, 23 Nov 2016 13:16:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147993578967.332.2487045591274823380.idtracker@ietfa.amsl.com> Date: Wed, 23 Nov 2016 13:16:29 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 21:16:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-03.txt Pages : 16 Date : 2016-11-23 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the Curve25519 and Curve448 curves. The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 23 13:26:23 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3078129785 for ; Wed, 23 Nov 2016 13:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Qtsm2o4A2x for ; Wed, 23 Nov 2016 13:26:21 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1949C126579 for ; Wed, 23 Nov 2016 13:26:21 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 23 Nov 2016 13:43:55 -0800 From: Jim Schaad To: References: <147993578984.332.5774111668235573858.idtracker@ietfa.amsl.com> In-Reply-To: <147993578984.332.5774111668235573858.idtracker@ietfa.amsl.com> Date: Wed, 23 Nov 2016 13:26:13 -0800 Message-ID: <016201d245d0$38eee4a0$aaccade0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHbgo+C5BSlAqrXK74Ah601qbgBlqDUmotg Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 21:26:23 -0000 I believe that this draft addresses all of the last call comments that = we have received todate. * The fact that we are not using contexts has been moved to the = introduction - along with some reasoning. * Use of NULL parameters is not a MUST NOT rather than a SHOULD NOT * Additional text on the use of Pure EdDSA for long CRLs and the use of = CRL distribution points to deal with it. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, November 23, 2016 1:16 PM > To: Simon Josefsson ; Jim Schaad > > Subject: New Version Notification for draft-ietf-curdle-pkix-03.txt >=20 >=20 > A new version of I-D, draft-ietf-curdle-pkix-03.txt has been = successfully > submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-curdle-pkix > Revision: 03 > Title: Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, > X25519 and X448 for use in the Internet X.509 Public Key = Infrastructure > Document date: 2016-11-23 > Group: curdle > Pages: 16 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-03 >=20 > Abstract: > This document specifies algorithm identifiers and ASN.1 encoding > formats for Elliptic Curve constructs using the Curve25519 and > Curve448 curves. The signature algorithms covered are Ed25519, > Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered > are X25519 and X448. The encoding for Public Key, Private Key and > EdDSA digital signature structures is provided. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Thu Nov 24 04:54:18 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97A71298C4 for ; Thu, 24 Nov 2016 04:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZyU60qmGpOs for ; Thu, 24 Nov 2016 04:54:10 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0994212950E for ; Thu, 24 Nov 2016 04:54:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2F021BE6F for ; Thu, 24 Nov 2016 12:54:07 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWoRSt5N2Aqa for ; Thu, 24 Nov 2016 12:54:05 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E583BE64 for ; Thu, 24 Nov 2016 12:54:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1479992044; bh=bavfMuRYYpQ1+L54gu7Je9bFgJIxhAvdrlq+XxSL6Mc=; h=To:From:Subject:Date:From; b=PnNVwNS4SfwTM+dwiZG0eOKNCKDITq2qwHjHxhyquLyV/AeEJf87q52grhqqzL67z CMsYJf1WVyqMBnoq08BLWY0ZF8vy2Ibv1DglXFqIciFlBaCLxk9qeCSbswHAM3XCmH 3aygQLZbBtwldbSOdvMzFMzBNKSO/5T3Z+B31+zc= To: "curdle@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 24 Nov 2016 12:54:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070006010709090209050705" Archived-At: Subject: [Curdle] AD review of draft-ietf-curdle-cms-chacha20-poly1305-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 12:54:17 -0000 This is a cryptographically signed message in MIME format. --------------ms070006010709090209050705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, My AD review of this draft is below. I think a revised I-D is needed before IETF LC for at least section 4, but please argue with me if I'm wrong about that. Cheers, S. (1) section 2: Is it correct to say that BCP107 is a MUST the way you do? I think you need to say that implementations MUST support some form(s) of AKM, but I don't think you can say "MUST use" as I can't see how that could be enforced at this level of the code. If it can't be enforced, then it's not worth the MUST you have here. (2) section 3: What does "content authenticated encryption" mean exactly? You use that phrase a lot, and I don't know what it means and it does not occur in [CMS]. Do we need a better term? (Apologies if I'm forgetting the WG discussing that.) (3) section 4: this is clearly not ready for publication - why not allocate the OID? But you at least need to write the text or get rid of the section. (4) I hope I remember to add the downref to the IETF LC:-) nits... - Is 1.1 really useful to have here? That text is basically part of [1] which is what an implementer would need to read anyway. So it may be better to omit 1.1 and just point at [1]. [1] https://tools.ietf.org/html/rfc7539#section-2.8 - section 2: "...destroys the security guarantees." That would be better with a reference to some paper that describes the issues. - typo: "I can be extremely..." - typo: "There is one algorithm identifiers..." - section 3: I'm not clear what is done with the "AuthEnvelopedData mac field" here. Given we've an AEAD, there's no real need for a separate MAC, so I find the text confusing. Can you explain? - section 6: This says "When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always the same size as the original plaintext. " What about the extra 128 bit authentication tag? --------------ms070006010709090209050705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMjQx MjU0MDRaMC8GCSqGSIb3DQEJBDEiBCB4ZCrlgWCubYFLtq9iC7tdkqnxfSwTx01geLtDJmJW wzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA1qzlXzcwSl9AzaG6FeFotbaA32Z6rdBWQtDOWWShhd+RHMVpH4ikw oApWwpw3CZNy5xKFdY61Wdv3lwZ8KI6FjdNcLyr15AyroetPhqi5iaDf9AxyKlPP4ifwHAQh X0+ZsvL2YCVzWkQwYLhEaxDcepqBFMpwxJMNkZWX0Np1QYiqVAY+vUR73zQ/9P7WblNymQ1m HGhQz3+OwUdRcfmooaC8dkHqM6jfCLKGn05eGj6lGsIIhBtKxKB31RG5eojo2LvDwTFwlVfd qwhrYeNEd7zKVywxADoc6TBpzO9Ntv8zqzWFiuZEcs6aVpUtWC4E6Dhf/3fn63Fzjoowj83m AAAAAAAA --------------ms070006010709090209050705-- From nobody Thu Nov 24 07:38:40 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDA11298C8 for ; Thu, 24 Nov 2016 07:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=docusign2com.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 VCpa-RFD30eo for ; Thu, 24 Nov 2016 07:38:35 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0125.outbound.protection.outlook.com [104.47.42.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162C71294E4 for ; Thu, 24 Nov 2016 07:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fPdh5v2WvwkNPfO+ApWQdn9JP1Bwmg13Uk9T68zI1tc=; b=rilxXsaTd0e0qOJMkctNaYhIJHrUoLvYfv+GgUdtNBBkkMnRdllIha8LouTQJla/x+NFuS7B+vC4KbfCL/6qrF5cTgoVzqL5pqUaodB2ao4DJl+4U726vDKFSFDcfFtjDPYG/NdVBQ2hS63jHnlwmV60Vr7Yg8AdxLHlaMm/OG0= Received: from DM5PR04MB0828.namprd04.prod.outlook.com (10.172.188.142) by DM5PR04MB0829.namprd04.prod.outlook.com (10.172.188.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Thu, 24 Nov 2016 15:38:28 +0000 Received: from DM5PR04MB0828.namprd04.prod.outlook.com ([10.172.188.142]) by DM5PR04MB0828.namprd04.prod.outlook.com ([10.172.188.142]) with mapi id 15.01.0734.014; Thu, 24 Nov 2016 15:38:28 +0000 From: Erwann Abalea To: Jim Schaad Thread-Topic: [Curdle] New Version Notification for draft-ietf-curdle-pkix-03.txt Thread-Index: AQHSRmjNMic90N8Uik6ZdqsyQRI8IQ== Date: Thu, 24 Nov 2016 15:38:28 +0000 Message-ID: <77A664E1-7ACD-4AE7-BDC4-2B72E4AD8A4A@docusign.com> References: <147993578984.332.5774111668235573858.idtracker@ietfa.amsl.com> <016201d245d0$38eee4a0$aaccade0$@augustcellars.com> In-Reply-To: <016201d245d0$38eee4a0$aaccade0$@augustcellars.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Erwann.Abalea@docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [84.14.125.226] x-microsoft-exchange-diagnostics: 1; DM5PR04MB0829; 7:c3tgDjEa6BgRFUNOu7HZN/GnBaV5FO97Ta3WWXhtwNWRN/rsqP4F9MfO3ViY9agFkPC7/hDwZNkO3GpL6OyjcyY2UzRfnn3+j1p7BjL/AbpvLI37TBK0DkBAIq3AA2/taOyiJVJaav3q6X2EB5ezW283R3pyksPNrie+Wmv1tivgxNftXCvUzhs39q3u5FxvBeewL1alliG6sLii2OCNwlKfd25ndFp24UXq2RN3LX5S14S8/uRz69liPaGZQzhbVJqvdI8/57EGaDQD5vjjK2fZv7WlSDoTcCVdMwhBVAQKSGVKxoOSPV5BkILJZUkrmkh8UmQWVC2IsZJ7izZEJr+9aKgPBKU7z7nptxjTqDE= x-ms-office365-filtering-correlation-id: ae3fd989-4b8f-4c2f-82ed-08d4147ff00f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR04MB0829; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6060326)(6040361)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(6061324)(20161123555025)(20161123564025)(20161123560025)(20161123562025); SRVR:DM5PR04MB0829; BCL:0; PCL:0; RULEID:; SRVR:DM5PR04MB0829; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377424004)(377454003)(13464003)(189002)(39410400001)(33656002)(82746002)(39380400001)(83716003)(54356999)(66066001)(106116001)(110136003)(15650500001)(122556002)(4001150100001)(7906003)(2420400007)(81166006)(5660300001)(7736002)(86362001)(68736007)(8936002)(4326007)(10710500007)(229853002)(81156014)(16601075003)(3660700001)(7110500001)(2906002)(92566002)(189998001)(76176999)(2950100002)(6116002)(7846002)(3280700002)(2900100001)(3846002)(77096005)(6916009)(50986999)(36756003)(97736004)(6512003)(230783001)(105586002)(99286002)(606004)(106356001)(101416001)(102836003)(6506003)(38730400001)(39400400001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR04MB0829; H:DM5PR04MB0828.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: docusign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_77A664E17ACD4AE7BDC42B72E4AD8A4Adocusigncom_" MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2016 15:38:28.6452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0829 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 15:38:39 -0000 --_000_77A664E17ACD4AE7BDC42B72E4AD8A4Adocusigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm9uam91ciwNCg0KU29tZSBjb21tZW50cyBvbiBzZWN0aW9uIDM6DQoNCg0KICAgVGhlIEFsZ29y aXRobUlkZW50aWZpZXIgdHlwZSwgd2hpY2ggaXMgaW5jbHVkZWQgZm9yIGNvbnZlbmllbmNlLCBp cw0KICAgZGVmaW5lZCBhcyBmb2xsb3dzOg0KDQogICBBbGdvcml0aG1JZGVudGlmaWVyICA6Oj0g IFNFUVVFTkNFICB7DQogICAgICAgYWxnb3JpdGhtICAgT0JKRUNUIElERU5USUZJRVIsDQogICAg ICAgcGFyYW1ldGVycyAgQU5ZIERFRklORUQgQlkgYWxnb3JpdGhtIE9QVElPTkFMDQogICB9DQoN Cg0KDQpUaGlzIGlzIGFuIEFTTi4xOjE5ODggbm90YXRpb24sIGFuZCB0aGUgcmVzdCBvZiB0aGUg ZHJhZnQgdXNlcyBhbiBBU04uMToxOTk0IG5vdGF0aW9uLCB0aGUgMiBhcmUgaW5jb21wYXRpYmxl IChBTlkgZG9lcyBub3QgZXhpc3QgYW55bW9yZSkuIFlvdSBjYW4gcmVwZWF0IHRoZSBkZWZpbml0 aW9uIGZyb20gUkZDNTkxMSBpZiB5b3Ugd2FudC4NCg0KDQogICBUaGUgZmllbGRzIGluIEFsZ29y aXRobUlkZW50aWZpZXIgaGF2ZSB0aGUgZm9sbG93aW5nIG1lYW5pbmdzOg0KDQogICBvICBhbGdv cml0aG0gaWRlbnRpZmllcyB0aGUgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG0gd2l0aCBhbiBvYmpl Y3QNCiAgICAgIGlkZW50aWZpZXIuICBUaGlzIGlzIG9uZSBvZiB0aGUgT0lEcyBkZWZpbmVkIGJl bG93Lg0KDQogICBvICBwYXJhbWV0ZXJzLCB3aGljaCBhcmUgb3B0aW9uYWwsIGFyZSB0aGUgYXNz b2NpYXRlZCBwYXJhbWV0ZXJzIGZvcg0KICAgICAgdGhlIGFsZ29yaXRobSBpZGVudGlmaWVyIGlu IHRoZSBhbGdvcml0aG0gZmllbGQuICBXaGVuIHRoZSAxOTk3DQogICAgICBzeW50YXggZm9yIEFs Z29yaXRobUlkZW50aWZpZXIgd2FzIGluaXRpYWxseSBkZWZpbmVkLCBpdCBvbWl0dGVkDQogICAg ICB0aGUgT1BUSU9OQUwga2V5IHdvcmQuICBUaGUgb3B0aW9uYWxpdHkgb2YgdGhlIHBhcmFtZXRl cnMgZmllbGQNCiAgICAgIHdhcyBsYXRlciByZWNvdmVyZWQgdmlhIGEgZGVmZWN0IHJlcG9ydCwg YnV0IGJ5IHRoZW4gbWFueSBwZW9wbGUNCiAgICAgIHRob3VnaHQgdGhhdCB0aGUgZmllbGQgd2Fz IG1hbmRhdG9yeS4gIEZvciB0aGlzIHJlYXNvbiwgYSBzbWFsbA0KICAgICAgbnVtYmVyIG9mIGlt cGxlbWVudGF0aW9ucyBtYXkgc3RpbGwgcmVxdWlyZSB0aGUgZmllbGQgdG8gYmUNCiAgICAgIHBy ZXNlbnQuDQoNCg0KVGhpcyBpcyBjb25mdXNlZCBhbmQgd3JvbmcuIFdoYXQgaXMgdGhpcyDCqyAx OTk3IMK7IHN1cHBvc2VkIHRvIG1lYW4/IFRoZXJlIGlzIGFuIEFTTi4xOjE5OTcgc3ludGF4IChp dCBpbnRyb2R1Y2VzIFVURjhTdHJpbmcgZm9yIGV4YW1wbGUpLCBhbiBYLjUwOSBlZGl0aW9uIDA4 Lzk3IChmaXJzdCBlZGl0aW9uIG9mIFguNTA5djMpLCBhbmQgdGhleSBhcmUgbm90IGNvbmNlcm5l ZCBieSB0aGlzIG9taXNzaW9uIG9mIE9QVElPTkFMIGhlcmU7IFguNTA5OjE5ODggKFguNTA5djEp IGFscmVhZHkgaGFkIHRoZSBwYXJhbWV0ZXJzIE9QVElPTkFMLCBhbmQgWC41MDk6MTk5MyAoWC41 MDl2Mikgc3dpdGNoZWQgdG8gdGhlIEFTTi4xOjE5OTQgc3ludGF4LiBSRkMyNDU5IHRvIDUyODAg c3RpbGwgdXNlIHRoZSBvYnNvbGV0ZSBBU04uMToxOTg4IHN5bnRheCBidXQgYWxsIGhhdmUgdGhl IE9QVElPTkFMIGtleXdvcmQuIElmIHNvbWUgcGVvcGxlIHRob3VnaHQgdGhlIGZpZWxkIHdhcyBt YW5kYXRvcnksIGl04oCZcyBmb3IgYW5vdGhlciByZWFzb24gdGhhdCB0aGUgb25lIGNsYWltZWQg aGVyZS4NCg0KDQogICBJbiB0aGlzIGRvY3VtZW50IHdlIGRlZmluZWQgc2l4IG5ldyBPSURzIGZv ciBpZGVudGlmeWluZyB0aGUNCiAgIGRpZmZlcmVudCBjdXJ2ZS9hbGdvcml0aG0gcGFpcnMuICBU aGUgY3VydmVzIGJlaW5nIEN1cnZlMjU1MTkgYW5kDQogICBDdXJ2ZTQ0OC4gIFRoZSBhbGdvcml0 aG1zIGJlaW5nIEVDREgsIEVkRFNBIGluIHB1cmUgbW9kZSBhbmQgRWREU0EgaW4NCiAgIHByZS1o YXNoIG1vZGUuICBGb3IgYWxsIG9mIHRoZSBPSURzLCB0aGUgcGFyYW1ldGVycyBNVVNUIGJlIGFi c2VudC4NCiAgIFJlZ2FyZGxlc3Mgb2YgdGhlIGRlZmVjdCBpbiB0aGUgb3JpZ2luYWwgMTk5NyBz eW50YXgsIGltcGxlbWVudGF0aW9ucw0KICAgTVVTVCBOT1QgYWNjZXB0IGEgcGFyYW1ldGVycyB2 YWx1ZSBvZiBOVUxMLg0KDQpBZ2FpbiwgdGhlcmXigJlzIG5vIGRlZmVjdCBpbiBzb21lIDE5OTcg c3ludGF4LiBUaGUgYWJzZW5jZSBvZiB0aGUgcGFyYW1ldGVycyBmaWVsZCBpcyBlbmZvcmNlZCBi eSB1c2luZyBhIHJlYWwgQVNOLjEgY29tcGlsZXIgYW5kIHRoZSBwcm9wZXIgdXNlIG9mIGNvbnN0 cmFpbnRzLg0KV2l0aCB0aGUgZGVmaW5pdGlvbnMgcHJvdmlkZWQgaW4gc2VjdGlvbiA5IGZvciBz YS1FZERTQSogb2JqZWN0cywgYXBwbGllZCB0byB0aGUgZGVmaW5pdGlvbiBvZiBTaWduYXR1cmVB bGdvcml0aG1JZGVudGlmaWVyIHRha2VuIGZyb20gUkZDNTkxMSwgaGF2aW5nIGFueSBwcmVzZW50 IHBhcmFtZXRlciAoZXZlbiBhIE5VTEwpIHdvdWxkIGJlIGludmFsaWQgaWYgdGhlIGFsZ29yaXRo bUlkZW50aWZpZXIgdGFrZXMgb25lIG9mIHRoZSBpZC1FZERTQSogdmFsdWVzIChiZWNhdXNlIG9m IHRoZSBjb25zdHJhaW50cykuDQoNCkNvcmRpYWxlbWVudCwNCkVyd2FubiBBYmFsZWENCg0KTGUg MjMgbm92LiAyMDE2IMOgIDIyOjI2LCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29t PG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gYSDDqWNyaXQgOg0KDQpJIGJlbGlldmUg dGhhdCB0aGlzIGRyYWZ0IGFkZHJlc3NlcyBhbGwgb2YgdGhlIGxhc3QgY2FsbCBjb21tZW50cyB0 aGF0IHdlIGhhdmUgcmVjZWl2ZWQgdG9kYXRlLg0KDQoqIFRoZSBmYWN0IHRoYXQgd2UgYXJlIG5v dCB1c2luZyBjb250ZXh0cyBoYXMgYmVlbiBtb3ZlZCB0byB0aGUgaW50cm9kdWN0aW9uIC0gYWxv bmcgd2l0aCBzb21lIHJlYXNvbmluZy4NCg0KKiBVc2Ugb2YgTlVMTCBwYXJhbWV0ZXJzIGlzIG5v dCBhIE1VU1QgTk9UIHJhdGhlciB0aGFuIGEgU0hPVUxEIE5PVA0KDQoqIEFkZGl0aW9uYWwgdGV4 dCBvbiB0aGUgdXNlIG9mIFB1cmUgRWREU0EgZm9yIGxvbmcgQ1JMcyBhbmQgdGhlIHVzZSBvZiBD UkwgZGlzdHJpYnV0aW9uIHBvaW50cyB0byBkZWFsIHdpdGggaXQuDQoNCkppbQ0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDIzLCAyMDE2IDE6MTYgUE0NClRvOiBT aW1vbiBKb3NlZnNzb24gPHNpbW9uQGpvc2Vmc3Nvbi5vcmc8bWFpbHRvOnNpbW9uQGpvc2Vmc3Nv bi5vcmc+PjsgSmltIFNjaGFhZA0KPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZA YXVndXN0Y2VsbGFycy5jb20+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkNCnN1 Ym1pdHRlZCBieSBKaW0gU2NoYWFkIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZTogZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeA0KUmV2aXNpb246IDAzDQpUaXRsZTogQWxn b3JpdGhtIElkZW50aWZpZXJzIGZvciBFZDI1NTE5LCBFZDI1NTE5cGgsIEVkNDQ4LCBFZDQ0OHBo LA0KWDI1NTE5IGFuZCBYNDQ4IGZvciB1c2UgaW4gdGhlIEludGVybmV0IFguNTA5IFB1YmxpYyBL ZXkgSW5mcmFzdHJ1Y3R1cmUNCkRvY3VtZW50IGRhdGU6IDIwMTYtMTEtMjMNCkdyb3VwOiBjdXJk bGUNClBhZ2VzOiAxNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY3VyZGxlLXBraXgv DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y3VyZGxlLXBraXgtMDMNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeC0wMw0KDQpBYnN0cmFjdDoNCiAgVGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgYWxnb3JpdGhtIGlkZW50aWZpZXJzIGFuZCBBU04uMSBlbmNvZGlu Zw0KICBmb3JtYXRzIGZvciBFbGxpcHRpYyBDdXJ2ZSBjb25zdHJ1Y3RzIHVzaW5nIHRoZSBDdXJ2 ZTI1NTE5IGFuZA0KICBDdXJ2ZTQ0OCBjdXJ2ZXMuICBUaGUgc2lnbmF0dXJlIGFsZ29yaXRobXMg Y292ZXJlZCBhcmUgRWQyNTUxOSwNCiAgRWQyNTUxOXBoLCBFZDQ0OCBhbmQgRWQ0NDhwaC4gIFRo ZSBrZXkgYWdyZWVtZW50IGFsZ29yaXRobSBjb3ZlcmVkDQogIGFyZSBYMjU1MTkgYW5kIFg0NDgu ICBUaGUgZW5jb2RpbmcgZm9yIFB1YmxpYyBLZXksIFByaXZhdGUgS2V5IGFuZA0KICBFZERTQSBk aWdpdGFsIHNpZ25hdHVyZSBzdHJ1Y3R1cmVzIGlzIHByb3ZpZGVkLg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkN1cmRsZSBtYWlsaW5nIGxpc3QNCkN1cmRsZUBpZXRmLm9yZzxtYWlsdG86 Q3VyZGxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j dXJkbGUNCg0KDQo= --_000_77A664E17ACD4AE7BDC42B72E4AD8A4Adocusigncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQm9uam91ciwNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNvbWUgY29tbWVudHMgb24g c2VjdGlvbiAzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4z MzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBvcnBoYW5zOiAyOyB3 aWRvd3M6IDI7Ij4gICBUaGUgQWxnb3JpdGhtSWRlbnRpZmllciB0eXBlLCB3aGljaCBpcyBpbmNs dWRlZCBmb3IgY29udmVuaWVuY2UsIGlzDQogICBkZWZpbmVkIGFzIGZvbGxvd3M6DQoNCiAgIEFs Z29yaXRobUlkZW50aWZpZXIgIDo6PSAgU0VRVUVOQ0UgIHsNCiAgICAgICBhbGdvcml0aG0gICBP QkpFQ1QgSURFTlRJRklFUiwNCiAgICAgICBwYXJhbWV0ZXJzICBBTlkgREVGSU5FRCBCWSBhbGdv cml0aG0gT1BUSU9OQUwNCiAgIH0NCg0KPC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHls ZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNz PSIiPlRoaXMgaXMgYW4gQVNOLjE6MTk4OCBub3RhdGlvbiwgYW5kIHRoZSByZXN0IG9mIHRoZSBk cmFmdCB1c2VzIGFuIEFTTi4xOjE5OTQgbm90YXRpb24sIHRoZSAyIGFyZSBpbmNvbXBhdGlibGUg KEFOWSBkb2VzIG5vdCBleGlzdCBhbnltb3JlKS4gWW91IGNhbiByZXBlYXQgdGhlIGRlZmluaXRp b24gZnJvbSBSRkM1OTExIGlmIHlvdSB3YW50LjwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9Im5l d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPjxiciBjbGFzcz0iIj48L3By ZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFy Z2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG9ycGhhbnM6IDI7IHdpZG93czogMjsi PiAgIFRoZSBmaWVsZHMgaW4gQWxnb3JpdGhtSWRlbnRpZmllciBoYXZlIHRoZSBmb2xsb3dpbmcg bWVhbmluZ3M6DQoNCiAgIG8gIGFsZ29yaXRobSBpZGVudGlmaWVzIHRoZSBjcnlwdG9ncmFwaGlj IGFsZ29yaXRobSB3aXRoIGFuIG9iamVjdA0KICAgICAgaWRlbnRpZmllci4gIFRoaXMgaXMgb25l IG9mIHRoZSBPSURzIGRlZmluZWQgYmVsb3cuDQoNCiAgIG8gIHBhcmFtZXRlcnMsIHdoaWNoIGFy ZSBvcHRpb25hbCwgYXJlIHRoZSBhc3NvY2lhdGVkIHBhcmFtZXRlcnMgZm9yDQogICAgICB0aGUg YWxnb3JpdGhtIGlkZW50aWZpZXIgaW4gdGhlIGFsZ29yaXRobSBmaWVsZC4gIFdoZW4gdGhlIDE5 OTcNCiAgICAgIHN5bnRheCBmb3IgQWxnb3JpdGhtSWRlbnRpZmllciB3YXMgaW5pdGlhbGx5IGRl ZmluZWQsIGl0IG9taXR0ZWQNCiAgICAgIHRoZSBPUFRJT05BTCBrZXkgd29yZC4gIFRoZSBvcHRp b25hbGl0eSBvZiB0aGUgcGFyYW1ldGVycyBmaWVsZA0KICAgICAgd2FzIGxhdGVyIHJlY292ZXJl ZCB2aWEgYSBkZWZlY3QgcmVwb3J0LCBidXQgYnkgdGhlbiBtYW55IHBlb3BsZQ0KICAgICAgdGhv dWdodCB0aGF0IHRoZSBmaWVsZCB3YXMgbWFuZGF0b3J5LiAgRm9yIHRoaXMgcmVhc29uLCBhIHNt YWxsDQogICAgICBudW1iZXIgb2YgaW1wbGVtZW50YXRpb25zIG1heSBzdGlsbCByZXF1aXJlIHRo ZSBmaWVsZCB0byBiZQ0KICAgICAgcHJlc2VudC4NCjxiciBjbGFzcz0iIj48L3ByZT4NCjxwcmUg Y2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw eDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIiBjbGFzcz0i Ij48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj5UaGlzIGlzIGNvbmZ1c2VkIGFuZCB3cm9uZy4gV2hh dCBpcyB0aGlzIMKrJm5ic3A7MTk5NyZuYnNwO8K7IHN1cHBvc2VkIHRvIG1lYW4/IFRoZXJlIGlz IGFuIEFTTi4xOjE5OTcgc3ludGF4IChpdCBpbnRyb2R1Y2VzIFVURjhTdHJpbmcgZm9yIGV4YW1w bGUpLCBhbiBYLjUwOSBlZGl0aW9uIDA4Lzk3IChmaXJzdCBlZGl0aW9uIG9mIFguNTA5djMpLCBh bmQgdGhleSBhcmUgbm90IGNvbmNlcm5lZCBieSB0aGlzIG9taXNzaW9uIG9mIE9QVElPTkFMIGhl cmU7IFguNTA5OjE5ODggKFguNTA5djEpIGFscmVhZHkgaGFkIHRoZSBwYXJhbWV0ZXJzIE9QVElP TkFMLCBhbmQgWC41MDk6MTk5MyAoWC41MDl2Mikgc3dpdGNoZWQgdG8gdGhlIEFTTi4xOjE5OTQg c3ludGF4LiBSRkMyNDU5IHRvIDUyODAgc3RpbGwgdXNlIHRoZSBvYnNvbGV0ZSBBU04uMToxOTg4 IHN5bnRheCBidXQgYWxsIGhhdmUgdGhlIE9QVElPTkFMIGtleXdvcmQuIElmIHNvbWUgcGVvcGxl IHRob3VnaHQgdGhlIGZpZWxkIHdhcyBtYW5kYXRvcnksIGl04oCZcyBmb3IgYW5vdGhlciByZWFz b24gdGhhdCB0aGUgb25lIGNsYWltZWQgaGVyZS48L2ZvbnQ+PC9mb250PjwvcHJlPg0KPHByZSBj bGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+DQogICBJbiB0 aGlzIGRvY3VtZW50IHdlIGRlZmluZWQgc2l4IG5ldyBPSURzIGZvciBpZGVudGlmeWluZyB0aGUN CiAgIGRpZmZlcmVudCBjdXJ2ZS9hbGdvcml0aG0gcGFpcnMuICBUaGUgY3VydmVzIGJlaW5nIEN1 cnZlMjU1MTkgYW5kDQogICBDdXJ2ZTQ0OC4gIFRoZSBhbGdvcml0aG1zIGJlaW5nIEVDREgsIEVk RFNBIGluIHB1cmUgbW9kZSBhbmQgRWREU0EgaW4NCiAgIHByZS1oYXNoIG1vZGUuICBGb3IgYWxs IG9mIHRoZSBPSURzLCB0aGUgcGFyYW1ldGVycyBNVVNUIGJlIGFic2VudC4NCiAgIFJlZ2FyZGxl c3Mgb2YgdGhlIGRlZmVjdCBpbiB0aGUgb3JpZ2luYWwgMTk5NyBzeW50YXgsIGltcGxlbWVudGF0 aW9ucw0KICAgTVVTVCBOT1QgYWNjZXB0IGEgcGFyYW1ldGVycyB2YWx1ZSBvZiBOVUxMLjwvcHJl Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5BZ2FpbiwgdGhlcmXigJlzIG5vIGRlZmVjdCBpbiBzb21lIDE5OTcgc3ludGF4LiBUaGUg YWJzZW5jZSBvZiB0aGUgcGFyYW1ldGVycyBmaWVsZCBpcyBlbmZvcmNlZCBieSB1c2luZyBhIHJl YWwgQVNOLjEgY29tcGlsZXIgYW5kIHRoZSBwcm9wZXIgdXNlIG9mIGNvbnN0cmFpbnRzLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5XaXRoIHRoZSBkZWZpbml0aW9ucyBwcm92aWRlZCBpbiBzZWN0aW9u IDkgZm9yIHNhLUVkRFNBKiBvYmplY3RzLCBhcHBsaWVkIHRvIHRoZSBkZWZpbml0aW9uIG9mIFNp Z25hdHVyZUFsZ29yaXRobUlkZW50aWZpZXIgdGFrZW4gZnJvbSBSRkM1OTExLCBoYXZpbmcgYW55 IHByZXNlbnQgcGFyYW1ldGVyIChldmVuIGEgTlVMTCkgd291bGQgYmUgaW52YWxpZCBpZiB0aGUg YWxnb3JpdGhtSWRlbnRpZmllciB0YWtlcyBvbmUgb2YNCiB0aGUgaWQtRWREU0EqIHZhbHVlcyAo YmVjYXVzZSBvZiB0aGUgY29uc3RyYWludHMpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5Db3JkaWFsZW1lbnQsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVyd2FubiBBYmFsZWE8L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5MZSAyMyBub3YuIDIwMTYgw6AgMjI6MjYsIEppbSBT Y2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIiBjbGFzcz0i Ij5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDsgYSDDqWNyaXQgOjwvZGl2Pg0KPGJyIGNs YXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+SSBiZWxpZXZl IHRoYXQgdGhpcyBkcmFmdCBhZGRyZXNzZXMgYWxsIG9mIHRoZSBsYXN0IGNhbGwgY29tbWVudHMg dGhhdCB3ZSBoYXZlIHJlY2VpdmVkIHRvZGF0ZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQoqIFRoZSBmYWN0IHRoYXQgd2UgYXJlIG5vdCB1c2luZyBjb250ZXh0cyBoYXMgYmVlbiBtb3Zl ZCB0byB0aGUgaW50cm9kdWN0aW9uIC0gYWxvbmcgd2l0aCBzb21lIHJlYXNvbmluZy48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqIFVzZSBvZiBOVUxMIHBhcmFtZXRlcnMgaXMgbm90IGEg TVVTVCBOT1QgcmF0aGVyIHRoYW4gYSBTSE9VTEQgTk9UPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KKiBBZGRpdGlvbmFsIHRleHQgb24gdGhlIHVzZSBvZiBQdXJlIEVkRFNBIGZvciBsb25n IENSTHMgYW5kIHRoZSB1c2Ugb2YgQ1JMIGRpc3RyaWJ1dGlvbiBwb2ludHMgdG8gZGVhbCB3aXRo IGl0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkppbTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyIGNsYXNzPSIiPg0KRnJvbTogPGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIg Y2xhc3M9IiI+bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyIGNsYXNzPSIi Pg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyMywgMjAxNiAxOjE2IFBNPGJyIGNsYXNzPSIi Pg0KVG86IFNpbW9uIEpvc2Vmc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpbW9uQGpvc2Vmc3Nv bi5vcmciIGNsYXNzPSIiPnNpbW9uQGpvc2Vmc3Nvbi5vcmc8L2E+Jmd0OzsgSmltIFNjaGFhZDxi ciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIg Y2xhc3M9IiI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4 LTAzLnR4dDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzLnR4dCBoYXMgYmVlbiBz dWNjZXNzZnVsbHk8YnIgY2xhc3M9IiI+DQpzdWJtaXR0ZWQgYnkgSmltIFNjaGFhZCBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K TmFtZTo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi PiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+ZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeDxiciBjbGFzcz0iIj4NClJldmlzaW9u OjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwv c3Bhbj4wMzxiciBjbGFzcz0iIj4NClRpdGxlOjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIg c3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5BbGdvcml0aG0gSWRlbnRpZmllcnMg Zm9yIEVkMjU1MTksIEVkMjU1MTlwaCwgRWQ0NDgsIEVkNDQ4cGgsPGJyIGNsYXNzPSIiPg0KWDI1 NTE5IGFuZCBYNDQ4IGZvciB1c2UgaW4gdGhlIEludGVybmV0IFguNTA5IFB1YmxpYyBLZXkgSW5m cmFzdHJ1Y3R1cmU8YnIgY2xhc3M9IiI+DQpEb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJBcHBs ZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj4yMDE2LTExLTIzPGJy IGNsYXNzPSIiPg0KR3JvdXA6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hp dGUtc3BhY2U6cHJlIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmN1cmRsZTxiciBjbGFzcz0iIj4NClBhZ2VzOjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj48 c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bh bj4xNjxiciBjbGFzcz0iIj4NClVSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDMudHh0IiBjbGFz cz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jdXJk bGUtcGtpeC0wMy50eHQ8L2E+PGJyIGNsYXNzPSIiPg0KU3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWN1cmRsZS1wa2l4LyIgY2xhc3M9IiI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeC88L2E+PGJy IGNsYXNzPSIiPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWN1cmRsZS1w a2l4LTAzIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j dXJkbGUtcGtpeC0wMzwvYT48YnIgY2xhc3M9IiI+DQpEaWZmOiAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeC0wMyIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY3VyZGxl LXBraXgtMDM8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYWxnb3JpdGhtIGlk ZW50aWZpZXJzIGFuZCBBU04uMSBlbmNvZGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2Zv cm1hdHMgZm9yIEVsbGlwdGljIEN1cnZlIGNvbnN0cnVjdHMgdXNpbmcgdGhlIEN1cnZlMjU1MTkg YW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Q3VydmU0NDggY3VydmVzLiAmbmJzcDtUaGUg c2lnbmF0dXJlIGFsZ29yaXRobXMgY292ZXJlZCBhcmUgRWQyNTUxOSw8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDtFZDI1NTE5cGgsIEVkNDQ4IGFuZCBFZDQ0OHBoLiAmbmJzcDtUaGUga2V5IGFn cmVlbWVudCBhbGdvcml0aG0gY292ZXJlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2FyZSBY MjU1MTkgYW5kIFg0NDguICZuYnNwO1RoZSBlbmNvZGluZyBmb3IgUHVibGljIEtleSwgUHJpdmF0 ZSBLZXkgYW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7RWREU0EgZGlnaXRhbCBzaWduYXR1 cmUgc3RydWN0dXJlcyBpcyBwcm92aWRlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uPGJyIGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIGNsYXNzPSIi Pg0KdG9vbHMuaWV0Zi5vcmc8L2E+LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBJ RVRGIFNlY3JldGFyaWF0PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgY2xhc3M9IiI+DQpDdXJkbGUgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOkN1cmRsZUBpZXRmLm9yZyIgY2xhc3M9IiI+Q3VyZGxlQGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y3VyZGxlPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_77A664E17ACD4AE7BDC42B72E4AD8A4Adocusigncom_-- From nobody Mon Nov 28 10:51:10 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E3F129F86; Mon, 28 Nov 2016 10:51:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148035906861.5378.17334401091666617776.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 10:51:08 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 18:51:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-eddsa-signatures-02.txt Pages : 7 Date : 2016-11-28 Abstract: This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatures-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 28 10:55:19 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5038F129497 for ; Mon, 28 Nov 2016 10:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 BjNKqJBAe2MC for ; Mon, 28 Nov 2016 10:55:15 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286E8129F8B for ; Mon, 28 Nov 2016 10:55:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7F9B2300AEE for ; Mon, 28 Nov 2016 13:44:56 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3j5HCDJfRIUS for ; Mon, 28 Nov 2016 13:44:55 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 767C3300A2C for ; Mon, 28 Nov 2016 13:44:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148035906861.5378.17334401091666617776.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 13:54:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <06F1427D-87E9-46F3-9AED-3962ADDA4CB9@vigilsec.com> References: <148035906861.5378.17334401091666617776.idtracker@ietfa.amsl.com> To: curdle@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 18:55:17 -0000 NIST just assigned the missing object identifier, so I updated the draft = to use it. Russ On Nov 28, 2016, at 1:51 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-eddsa-signatures-02.txt > Pages : 7 > Date : 2016-11-28 >=20 > Abstract: > This document specifies the conventions for using Edwards-curve > Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in > the Cryptographic Message Syntax (CMS). For each curve, EdDSA > defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA > mode is not used with the CMS. In addition, no context string is > used with the CMS. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -02 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 28 14:58:01 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A7712A0BE for ; Mon, 28 Nov 2016 14:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 HzKoQw2gJJPW for ; Mon, 28 Nov 2016 14:57:58 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F148012A0D9 for ; Mon, 28 Nov 2016 14:56:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 48F2A300AFD for ; Mon, 28 Nov 2016 17:46:15 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SbT4mxRmSFZB for ; Mon, 28 Nov 2016 17:46:13 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 53E2B300687; Mon, 28 Nov 2016 17:46:13 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_545C7A49-E8FD-4371-AA6D-26D396E6BB86"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 28 Nov 2016 17:56:29 -0500 Message-Id: <6E89FD59-D2DA-4697-AF37-5041B09F2035@vigilsec.com> References: To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] AD review of draft-ietf-curdle-cms-chacha20-poly1305-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 22:58:00 -0000 --Apple-Mail=_545C7A49-E8FD-4371-AA6D-26D396E6BB86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Stephen: > My AD review of this draft is below. I think > a revised I-D is needed before IETF LC for at > least section 4, but please argue with me if > I'm wrong about that. I do not think the changes are very big. However, I=92m pleased to make = them before IETF Last Call, assuming you agree with the direction laid = out below. > (1) section 2: Is it correct to say that BCP107 > is a MUST the way you do? I think you need to > say that implementations MUST support some > form(s) of AKM, but I don't think you can say > "MUST use" as I can't see how that could be > enforced at this level of the code. If it > can't be enforced, then it's not worth the > MUST you have here. I do not see this concern. The specification does not allow for the = AEAD_CHACHA20_POLY1305 key (that is, the = content-authenticated-encryption key) to be used for more that one CMS = object. A fresh one must be established, and there are four ways that = can be used to do so: Key Transport: the content-authenticated-encryption key is encrypted in the recipient's public key; Key Agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key, then the content-authenticated-encryption key is encrypted in the pairwise symmetric key; Symmetric Key-Encryption Keys: the content-authenticated- encryption key is encrypted in a previously distributed symmetric key-encryption key; and Passwords: the content-authenticated-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value. > (2) section 3: What does "content authenticated > encryption" mean exactly? You use that phrase > a lot, and I don't know what it means and it > does not occur in [CMS]. Do we need a better > term? (Apologies if I'm forgetting the WG > discussing that.) RFC 5083 uses the term "content-authenticated-encryption keys=94. I can = add the hyphens id that improves clarity. > (3) section 4: this is clearly not ready for > publication - why not allocate the OID? But > you at least need to write the text or get rid > of the section. Other S/MIME Capabilities just include the hex values of the attribute, = which is simply the DER encoding of the OID. I can put the words there, = but the hex string cannot be provided until the OID is assigned. > (4) I hope I remember to add the downref to > the IETF LC:-) For which document? > nits... >=20 > - Is 1.1 really useful to have here? That text > is basically part of [1] which is what an > implementer would need to read anyway. So it > may be better to omit 1.1 and just point > at [1]. >=20 > [1] https://tools.ietf.org/html/rfc7539#section-2.8 Sure. It can be reduced to a simple paragraph that contains a pointer, = much like the pointer to ASN.1 In section 1.3. > - section 2: "...destroys the security > guarantees." That would be better with a > reference to some paper that describes the > issues. This is explained in RFC 7539. It says: Consequences of repeating a nonce: If a nonce is repeated, then both the one-time Poly1305 key and the keystream are identical between the messages. This reveals the XOR of the plaintexts, because the XOR of the plaintexts is equal to the XOR of the ciphertexts. I=92m pleased to point to that. > - typo: "I can be extremely..." >=20 > - typo: "There is one algorithm identifiers...=94 I=92m pleased to correct those. > - section 3: I'm not clear what is done with > the "AuthEnvelopedData mac field" here. Given > we've an AEAD, there's no real need for a > separate MAC, so I find the text confusing. > Can you explain? RFC 7539 says: chacha20_aead_encrypt(aad, key, iv, constant, plaintext): nonce =3D constant | iv otk =3D poly1305_key_gen(key, nonce) ciphertext =3D chacha20_encrypt(key, 1, nonce, plaintext) mac_data =3D aad | pad16(aad) mac_data |=3D ciphertext | pad16(ciphertext) mac_data |=3D num_to_4_le_bytes(aad.length) mac_data |=3D num_to_4_le_bytes(ciphertext.length) tag =3D poly1305_mac(mac_data, otk) return (ciphertext, tag) This is where the authentication tag is carried. Authentication tag is = really another name for MAC. > - section 6: This says "When using > AEAD_CHACHA20_POLY1305, the resulting > ciphertext is always the same size as the > original plaintext. " What about the extra 128 > bit authentication tag? As above, the authentication tag is carried in the AuthEnvelopedData mac = field. Russ --Apple-Mail=_545C7A49-E8FD-4371-AA6D-26D396E6BB86 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85 Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl 4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjExMjgyMjU2MzBaMCMGCSqGSIb3DQEJBDEWBBS3PYTSs9y34B5EPe/o0HKjbca/jDCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQBofSwINuE3JSTi1KfnuKugx8PI19fhQMFlLKjViCuaDks8AtD+cmQYIsr/RzYF FEtslSRHR7sgzQonYkLfuGwOEzGM8NBtkoVm/C6bXSq9aCmJkv5McdmTIlV3P3a9u4Aht4KFya4F ZTQ0wuuO29piAXcm/MNBfh+Ss6zcKeWje1oSqUTOGdwuYD5a/zDm6UdNB6lhFJN35onchS+eqx2n wU2oqobIlQ0gwslXao0vvskdyQt7DBWx8eqhYSjLDdMvFADkrW7CjoPSmjK2thgykMFXcxomYgW7 9eKmiNB7RkWj51h2XO7OeCzDGE207bx4HF5F9E0nFRbFwVB2MVu3AAAAAAAA --Apple-Mail=_545C7A49-E8FD-4371-AA6D-26D396E6BB86-- From nobody Mon Nov 28 21:15:21 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B707D1295A5 for ; Mon, 28 Nov 2016 21:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQeu5fLKzhkx for ; Mon, 28 Nov 2016 21:15:18 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59620129401 for ; Mon, 28 Nov 2016 21:15:17 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 28 Nov 2016 21:32:49 -0800 From: Jim Schaad To: 'Erwann Abalea' References: <147993578984.332.5774111668235573858.idtracker@ietfa.amsl.com> <016201d245d0$38eee4a0$aaccade0$@augustcellars.com> <77A664E1-7ACD-4AE7-BDC4-2B72E4AD8A4A@docusign.com> In-Reply-To: <77A664E1-7ACD-4AE7-BDC4-2B72E4AD8A4A@docusign.com> Date: Mon, 28 Nov 2016 21:15:08 -0800 Message-ID: <06a901d249ff$8ef51440$acdf3cc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06AA_01D249BC.80D3D010" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHbgo+C5BSlAqrXK74Ah601qbgBlgGt4eU9AgX8p8Kgv1dgUA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 05:15:21 -0000 ------=_NextPart_000_06AA_01D249BC.80D3D010 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See in-line. =20 Jim =20 From: Erwann Abalea [mailto:Erwann.Abalea@docusign.com]=20 Sent: Thursday, November 24, 2016 7:38 AM To: Jim Schaad Cc: curdle@ietf.org Subject: Re: [Curdle] New Version Notification for = draft-ietf-curdle-pkix-03.txt =20 Bonjour,=20 =20 Some comments on section 3: =20 The AlgorithmIdentifier type, which is included for convenience, is defined as follows: =20 AlgorithmIdentifier ::=3D SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } =20 This is an ASN.1:1988 notation, and the rest of the draft uses an = ASN.1:1994 notation, the 2 are incompatible (ANY does not exist = anymore). You can repeat the definition from RFC5911 if you want. =20 [JLS] Doing this makes sense to me. I will do so. I just copied this = section from an existing RFC which used 1988 syntax. =20 =20 The fields in AlgorithmIdentifier have the following meanings: =20 o algorithm identifies the cryptographic algorithm with an object identifier. This is one of the OIDs defined below. =20 o parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field. When the 1997 syntax for AlgorithmIdentifier was initially defined, it omitted the OPTIONAL key word. The optionality of the parameters field was later recovered via a defect report, but by then many people thought that the field was mandatory. For this reason, a small number of implementations may still require the field to be present. =20 This is confused and wrong. What is this =C2=AB 1997 =C2=BB supposed to = mean? There is an ASN.1:1997 syntax (it introduces UTF8String for = example), an X.509 edition 08/97 (first edition of X.509v3), and they = are not concerned by this omission of OPTIONAL here; X.509:1988 = (X.509v1) already had the parameters OPTIONAL, and X.509:1993 (X.509v2) = switched to the ASN.1:1994 syntax. RFC2459 to 5280 still use the = obsolete ASN.1:1988 syntax but all have the OPTIONAL keyword. If some = people thought the field was mandatory, it=E2=80=99s for another reason = that the one claimed here. [JLS] This concerns the 1997 version of X.509. That is where = AlgorithmIdentifier is defined. =20 I think that you are being misled by the fact that the IETF does not = ever modify a document that has been published. This is not a true = statement for the ITU. When I go out to the ITU site and download the = version that is dated 08/97, the date at the bottom of the claims to be = =E2=80=9C1997 E=E2=80=9D. I read this as being the E-th revision of the = document. This means that the defect report referred to in the text was = rolled into the official ITU version of the document. The fact that you = can no longer see that the defect once existed does not mean that it was = never in the document. =20 In this document we defined six new OIDs for identifying the different curve/algorithm pairs. The curves being Curve25519 and Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in pre-hash mode. For all of the OIDs, the parameters MUST be absent. Regardless of the defect in the original 1997 syntax, implementations MUST NOT accept a parameters value of NULL. =20 Again, there=E2=80=99s no defect in some 1997 syntax. The absence of the = parameters field is enforced by using a real ASN.1 compiler and the = proper use of constraints. With the definitions provided in section 9 for sa-EdDSA* objects, = applied to the definition of SignatureAlgorithmIdentifier taken from = RFC5911, having any present parameter (even a NULL) would be invalid if = the algorithmIdentifier takes one of the id-EdDSA* values (because of = the constraints). =20 Cordialement, Erwann Abalea =20 Le 23 nov. 2016 =C3=A0 22:26, Jim Schaad > a =C3=A9crit : =20 I believe that this draft addresses all of the last call comments that = we have received todate. * The fact that we are not using contexts has been moved to the = introduction - along with some reasoning. * Use of NULL parameters is not a MUST NOT rather than a SHOULD NOT * Additional text on the use of Pure EdDSA for long CRLs and the use of = CRL distribution points to deal with it. Jim -----Original Message----- From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] Sent: Wednesday, November 23, 2016 1:16 PM To: Simon Josefsson >; = Jim Schaad > Subject: New Version Notification for draft-ietf-curdle-pkix-03.txt A new version of I-D, draft-ietf-curdle-pkix-03.txt has been = successfully submitted by Jim Schaad and posted to the IETF repository. Name: draft-ietf-curdle-pkix Revision: 03 Title: Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Document date: 2016-11-23 Group: curdle Pages: 16 URL: = https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-03 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-03 Abstract: This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the Curve25519 and Curve448 curves. The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered are X25519 and X448. The encoding for Public Key, Private Key and EdDSA digital signature structures is provided. 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 = . The IETF Secretariat _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 ------=_NextPart_000_06AA_01D249BC.80D3D010 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

See = in-line.

 

Jim

 

From:<= /b> = Erwann Abalea [mailto:Erwann.Abalea@docusign.com]
Sent: = Thursday, November 24, 2016 7:38 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = curdle@ietf.org
Subject: Re: [Curdle] New Version Notification = for draft-ietf-curdle-pkix-03.txt

 

Bonjour, =

 

Some comments on section = 3:

 

=C2=A0=C2=A0 The AlgorithmIdentifier type, which is =
included for convenience, is
=C2=A0=C2=A0 defined =
as =
follows:
 
=C2=A0=C2=A0 =
AlgorithmIdentifier=C2=A0 ::=3D=C2=A0 SEQUENCE=C2=A0 =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
algorithm=C2=A0=C2=A0 OBJECT =
IDENTIFIER,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
parameters=C2=A0 ANY DEFINED BY algorithm =
OPTIONAL
=C2=A0=C2=A0 =
}
 
This is =
an ASN.1:1988 notation, and the rest of the draft uses an ASN.1:1994 =
notation, the 2 are incompatible (ANY does not exist anymore). You can =
repeat the definition from RFC5911 if you =
want.
 
[JLS] Doing this makes sense to me.=C2=A0 I will do so.=C2=A0 I just =
copied this section from an existing RFC which used 1988 =
syntax.
 
 
=C2=A0=C2=A0 The fields in AlgorithmIdentifier have the following =
meanings:
 
=C2=A0=C2=A0 =
o=C2=A0 algorithm identifies the cryptographic algorithm with an =
object
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
identifier.=C2=A0 This is one of the OIDs defined =
below.
 
=C2=A0=C2=A0 =
o=C2=A0 parameters, which are optional, are the associated parameters =
for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the algorithm =
identifier in the algorithm field.=C2=A0 When the =
1997
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 syntax for =
AlgorithmIdentifier was initially defined, it =
omitted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the OPTIONAL =
key word.=C2=A0 The optionality of the parameters =
field
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was later =
recovered via a defect report, but by then many =
people
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 thought that =
the field was mandatory.=C2=A0 For this reason, a =
small
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 number of =
implementations may still require the field to =
be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
present.
 
This is confused and wrong. =
What is this =C2=AB 1997 =C2=BB supposed to mean? There is an =
ASN.1:1997 syntax (it introduces UTF8String for example), an X.509 =
edition 08/97 (first edition of X.509v3), and they are not concerned by =
this omission of OPTIONAL here; X.509:1988 (X.509v1) already had the =
parameters OPTIONAL, and X.509:1993 (X.509v2) switched to the ASN.1:1994 =
syntax. RFC2459 to 5280 still use the obsolete ASN.1:1988 syntax but all =
have the OPTIONAL keyword. If some people thought the field was =
mandatory, it=E2=80=99s for another reason that the one claimed =
here.
[JLS] This concerns the 1997 version of X.509.=C2=A0 That is where =
AlgorithmIdentifier is defined.
 
I think that you are being misled by the fact that the IETF does not =
ever modify a document that has been published.=C2=A0 This is not a true =
statement for the ITU.=C2=A0 When I go out to the ITU site and download =
the version that is dated 08/97, the date at the bottom of the claims to =
be =E2=80=9C1997 E=E2=80=9D.=C2=A0 I read this as being the E-th =
revision of the document.=C2=A0 This means that the defect report =
referred to in the text was rolled into the official ITU version of the =
document.=C2=A0 The fact that you can no longer see that the defect once =
existed does not mean that it was never in the =
document.
 
=C2=A0=C2=A0 In this document we defined =
six new OIDs for identifying the
=C2=A0=C2=A0 =
different curve/algorithm pairs.=C2=A0 The curves being Curve25519 =
and
=C2=A0=C2=A0 Curve448.=C2=A0 The algorithms =
being ECDH, EdDSA in pure mode and EdDSA =
in
=C2=A0=C2=A0 pre-hash mode.=C2=A0 For all of the =
OIDs, the parameters MUST be absent.
=C2=A0=C2=A0 =
Regardless of the defect in the original 1997 syntax, =
implementations
=C2=A0=C2=A0 MUST NOT accept a =
parameters value of NULL.

 

Again, there=E2=80=99s no defect in some 1997 syntax. = The absence of the parameters field is enforced by using a real ASN.1 = compiler and the proper use of constraints.

With the definitions provided in section 9 for = sa-EdDSA* objects, applied to the definition of = SignatureAlgorithmIdentifier taken from RFC5911, having any present = parameter (even a NULL) would be invalid if the algorithmIdentifier = takes one of the id-EdDSA* values (because of the = constraints).

 

Cordialement,

Erwann Abalea

 

Le 23 nov. 2016 =C3=A0 22:26, Jim Schaad <ietf@augustcellars.com> a = =C3=A9crit :

 

I = believe that this draft addresses all of the last call comments that we = have received todate.

* The fact that we are not using contexts = has been moved to the introduction - along with some reasoning.

* = Use of NULL parameters is not a MUST NOT rather than a SHOULD = NOT

* Additional text on the use of Pure EdDSA for long CRLs and = the use of CRL distribution points to deal with = it.

Jim



-----Original Message-----
From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org<= /a>]
Sent: Wednesday, November 23, 2016 1:16 PM
To: Simon = Josefsson <simon@josefsson.org>; Jim = Schaad
<ietf@augustcellars.com>
= Subject: New Version Notification for = draft-ietf-curdle-pkix-03.txt


A new version of I-D, = draft-ietf-curdle-pkix-03.txt has been successfully
submitted by Jim = Schaad and posted to the IETF repository.

Name: draft-ietf-curdle-pkix
Revision: 03
Title: = Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, = Ed448ph,
X25519 and X448 for use in the Internet X.509 Public Key = Infrastructure
Document date: = 2016-11-23
Group: = curdle
Pages: 16
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-03.txt=
Status:         https:/= /datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
Htmlized: =       https://to= ols.ietf.org/html/draft-ietf-curdle-pkix-03
Diff: =           ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-03

Ab= stract:
  This document specifies algorithm identifiers and = ASN.1 encoding
  formats for Elliptic Curve constructs = using the Curve25519 and
  Curve448 curves.  The = signature algorithms covered are Ed25519,
  Ed25519ph, = Ed448 and Ed448ph.  The key agreement algorithm = covered
  are X25519 and X448.  The encoding for = Public Key, Private Key and
  EdDSA digital signature = structures is provided.




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.

The IETF = Secretariat



__________________________________= _____________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.or= g/mailman/listinfo/curdle

 

------=_NextPart_000_06AA_01D249BC.80D3D010-- From nobody Tue Nov 29 04:09:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E497B129B9A for ; Tue, 29 Nov 2016 04:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRP56JO8nGRF for ; Tue, 29 Nov 2016 04:09:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29415129B76 for ; Tue, 29 Nov 2016 04:03:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B4B85BE58; Tue, 29 Nov 2016 12:03:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIhy-0McFbQR; Tue, 29 Nov 2016 12:03:22 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5ECC8BE4C; Tue, 29 Nov 2016 12:03:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480421002; bh=dfVo/MF3RGVr9EMNy/aeTOjJ3C8HrolfKzBJPNvjW/I=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Fd7cSNihqhIyfJXRf1xNK9uoIBxivbpShrAVNn3t07NtTyL9vwdnEmD0TFXNyT8+N mJVuZmdE4CUzqEpYv0yBuhIzeBzFtFTjIL1KqQOdYIw+Em6b2kdKD1FhXZrsGrCNzo tbTFCoZ9NWJn12B1JLqk/KzOTFFTPiPYDPSVahXs= To: Russ Housley References: <6E89FD59-D2DA-4697-AF37-5041B09F2035@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 29 Nov 2016 12:03:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6E89FD59-D2DA-4697-AF37-5041B09F2035@vigilsec.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010408050002030703020705" Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] AD review of draft-ietf-curdle-cms-chacha20-poly1305-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 12:09:27 -0000 This is a cryptographically signed message in MIME format. --------------ms010408050002030703020705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, On 28/11/16 22:56, Russ Housley wrote: > Stephen: >=20 >> My AD review of this draft is below. I think a revised I-D is >> needed before IETF LC for at least section 4, but please argue with >> me if I'm wrong about that. >=20 > I do not think the changes are very big. =20 Agreed. The only change that I think is really needed is to fix section 4 so that people have something to review at IETF LC. > However, I=E2=80=99m pleased to > make them before IETF Last Call, assuming you agree with the > direction laid out below. >=20 >=20 >> (1) section 2: Is it correct to say that BCP107 is a MUST the way >> you do? I think you need to say that implementations MUST support >> some form(s) of AKM, but I don't think you can say "MUST use" as I >> can't see how that could be enforced at this level of the code. If >> it can't be enforced, then it's not worth the MUST you have here. >=20 > I do not see this concern. The specification does not allow for the > AEAD_CHACHA20_POLY1305 key (that is, the > content-authenticated-encryption key) to be used for more that one > CMS object. A fresh one must be established, and there are four ways > that can be used to do so: >=20 > Key Transport: the content-authenticated-encryption key is encrypted > in the recipient's public key; >=20 > Key Agreement: the recipient's public key and the sender's private > key are used to generate a pairwise symmetric key, then the > content-authenticated-encryption key is encrypted in the pairwise > symmetric key; >=20 > Symmetric Key-Encryption Keys: the content-authenticated- encryption > key is encrypted in a previously distributed symmetric key-encryption > key; and >=20 > Passwords: the content-authenticated-encryption key is encrypted in > a key-encryption key that is derived from a password or other shared > secret value. Sure, that's all fine. My point though is that the person implementing this will likely not be in a position to try to enforce BCP107 in that same code base. And maybe they actually ought not try enforce that BCP while adding this. I think the current MUST is indicative of a layering violation and will be ignored, if it's not already satisfied by the overall system to which this construct is being added. To be clear, I'm fine that this not block LC. >=20 >=20 >> (2) section 3: What does "content authenticated encryption" mean >> exactly? You use that phrase a lot, and I don't know what it means >> and it does not occur in [CMS]. Do we need a better term? >> (Apologies if I'm forgetting the WG discussing that.) >=20 > RFC 5083 uses the term "content-authenticated-encryption keys=E2=80=9D.= I > can add the hyphens id that improves clarity. Personally, I think that term lacks clarity and adds confusion. I don't see why it's better than just saying "key" when you mean that, and "key+nonce" when that's meant. >=20 >=20 >> (3) section 4: this is clearly not ready for publication - why not >> allocate the OID? But you at least need to write the text or get >> rid of the section. >=20 > Other S/MIME Capabilities just include the hex values of the > attribute, which is simply the DER encoding of the OID. I can put > the words there, but the hex string cannot be provided until the OID > is assigned. Please. A section containing one TBD string is fine. An entirely blank section I think asks too much from folks reading this. (Separately, why not allocate the OID now? We can do early allocations.) >=20 >=20 >> (4) I hope I remember to add the downref to the IETF LC:-) >=20 > For which document? RFC 7539. That's an action on me for the LC text though, nothing there for you to do. >=20 >=20 >> nits... One comment below, otherwise what you say about all of these is fine. >>=20 >> - Is 1.1 really useful to have here? That text is basically part of >> [1] which is what an implementer would need to read anyway. So it=20 >> may be better to omit 1.1 and just point at [1]. >>=20 >> [1] https://tools.ietf.org/html/rfc7539#section-2.8 >=20 > Sure. It can be reduced to a simple paragraph that contains a > pointer, much like the pointer to ASN.1 In section 1.3. >=20 >> - section 2: "...destroys the security guarantees." That would be >> better with a reference to some paper that describes the issues. >=20 > This is explained in RFC 7539. It says: >=20 > Consequences of repeating a nonce: If a nonce is repeated, then both=20 > the one-time Poly1305 key and the keystream are identical between > the messages. This reveals the XOR of the plaintexts, because the > XOR of the plaintexts is equal to the XOR of the ciphertexts. >=20 > I=E2=80=99m pleased to point to that. >=20 >=20 >> - typo: "I can be extremely..." >>=20 >> - typo: "There is one algorithm identifiers...=E2=80=9D >=20 > I=E2=80=99m pleased to correct those. >=20 >=20 >> - section 3: I'm not clear what is done with the "AuthEnvelopedData >> mac field" here. Given we've an AEAD, there's no real need for a=20 >> separate MAC, so I find the text confusing. Can you explain? >=20 > RFC 7539 says: >=20 > chacha20_aead_encrypt(aad, key, iv, constant, plaintext): nonce =3D > constant | iv otk =3D poly1305_key_gen(key, nonce) ciphertext =3D > chacha20_encrypt(key, 1, nonce, plaintext) mac_data =3D aad | > pad16(aad) mac_data |=3D ciphertext | pad16(ciphertext) mac_data |=3D > num_to_4_le_bytes(aad.length) mac_data |=3D > num_to_4_le_bytes(ciphertext.length) tag =3D poly1305_mac(mac_data, > otk) return (ciphertext, tag) >=20 > This is where the authentication tag is carried. Authentication tag > is really another name for MAC. >=20 >=20 >> - section 6: This says "When using AEAD_CHACHA20_POLY1305, the >> resulting ciphertext is always the same size as the original >> plaintext. " What about the extra 128 bit authentication tag? >=20 > As above, the authentication tag is carried in the AuthEnvelopedData > mac field. I'd say adding a note to that effect somewhere would help the reader. (Though an implementer will get it right I guess.) Cheers, S. >=20 > Russ >=20 --------------ms010408050002030703020705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMjkx MjAzMjJaMC8GCSqGSIb3DQEJBDEiBCDM3r0xWOumEnv/cAWkS7KU7yBv1FgrZHEi3wcTEQBs QTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCtk5pAVPtAJ+WBrw4bPkDNATA4PtZUCHjk1ZganWhufLVDMrctgp34 RMWREqTEpSYCwsnssdclAJjwvYogV+ADcqRcFT81MSgZPMR5f7L5PpLlfM/8rM0OVgI/oKFm JBfMjapslvWTThLpEvbztQwWt2/fkgg4Lp3Mh2o4/HwyvBGoW4CKyPqopqGHIq3jdZ00WWgk zwVcbc2Y9h8UVmyOkGsuFkhxnNJ5PHZZvENMrQk69Asgffg9Ekdts6eVqyTw6q4EumGObV4t JhxAC+ujRT8UsnU9XHcwjMGfMT7v7vpiqx96ZuMNoTnzRPwgPIYgPnGZyZUMO6/qWAHAob5f AAAAAAAA --------------ms010408050002030703020705-- From nobody Tue Nov 29 09:44:20 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9417B129635 for ; Tue, 29 Nov 2016 09:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=docusign2com.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 THZQr2LAnsNf for ; Tue, 29 Nov 2016 09:44:09 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0125.outbound.protection.outlook.com [104.47.32.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04591294A3 for ; Tue, 29 Nov 2016 09:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7gdJzSUePBuEYOCKmWGwpD5tADOdd+0dnZosI3+zKSE=; b=k5GCzD4ZMOWzB/rvCvsk4L3vwPUHWDzEyUbxMYAzTiibAjjappIrFR97ipBZGMFF7kIErk23EkAMlQShu3JQhyqyKiemOV+YHcbi80caTzlLTJQ+CrvfPm9k3bt30aYecd4tt8bNkwmXP7TPsw9yxIhzOGc3ZHWgYl+3h6HHAh0= Received: from DM5PR04MB0828.namprd04.prod.outlook.com (10.172.188.142) by DM5PR04MB0829.namprd04.prod.outlook.com (10.172.188.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Tue, 29 Nov 2016 17:41:09 +0000 Received: from DM5PR04MB0828.namprd04.prod.outlook.com ([10.172.188.142]) by DM5PR04MB0828.namprd04.prod.outlook.com ([10.172.188.142]) with mapi id 15.01.0747.013; Tue, 29 Nov 2016 17:41:09 +0000 From: Erwann Abalea To: Jim Schaad Thread-Topic: [Curdle] New Version Notification for draft-ietf-curdle-pkix-03.txt Thread-Index: AQHSRmjOFYKofR7XJ0aPLgmwR2rPbQ== Date: Tue, 29 Nov 2016 17:41:09 +0000 Message-ID: References: <147993578984.332.5774111668235573858.idtracker@ietfa.amsl.com> <016201d245d0$38eee4a0$aaccade0$@augustcellars.com> <77A664E1-7ACD-4AE7-BDC4-2B72E4AD8A4A@docusign.com> <06a901d249ff$8ef51440$acdf3cc0$@augustcellars.com> In-Reply-To: <06a901d249ff$8ef51440$acdf3cc0$@augustcellars.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Erwann.Abalea@docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.93.124.97] x-ms-office365-filtering-correlation-id: fe7d21b1-6745-439d-3d16-08d4187ee78e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR04MB0829; x-microsoft-exchange-diagnostics: 1; DM5PR04MB0829; 7:HTKVH8qLes5u17Td/yJ9fIfCVPcigaywaGBjG/C6izCE2QdxFpll67iaAjEbTqFT4oQl+DXcklpv812lJfp5056T6t7edRX33hNfMJStaO71dv6h9lf2jLwvZPpu+jOz0UoPPCgKPEh5zvxNLe5wv0HPtj6uJAugwBENXE4XabIEy4Z5XyGNsBgzRfvGSpTgPMzJXFbJEtQTUOhfjbm7NiuJkacX0n8U56UC5Q/Um3iHNP4J5Yx+2/Tt5KpOyGAas7EmXxcFVWVv+PV2VXAR2jbPF13ZxBFNVAJEDozdLUUsFL2eeAuJowFYSoT2wksycSv1KrM/d9NvureKsUotp09xysqDxwmxwFR60ybzxRuqKX1j1VMRzHcxsovNOfUItGO02+YFaLMaza02s+YmGn+SL+pdgjFyObGHHKt/MZapJ7O5IlP0gaKjIXwVM2z5IORBq3xTvYO86CMMQ2JPMg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(58426504366037); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040361)(6045199)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(6061324)(20161123564025)(20161123562025)(20161123560025)(20161123555025); SRVR:DM5PR04MB0829; BCL:0; PCL:0; RULEID:; SRVR:DM5PR04MB0829; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(13464003)(51444003)(377424004)(189002)(199003)(377454003)(106116001)(15650500001)(66066001)(99286002)(7906003)(106356001)(81166006)(7846002)(6486002)(83716003)(105586002)(8936002)(229853002)(77096006)(86362001)(7736002)(36756003)(81156014)(6916009)(2950100002)(5660300001)(110136003)(82746002)(2420400007)(122556002)(92566002)(39450400002)(4326007)(10710500007)(50986999)(2900100001)(230783001)(76176999)(68736007)(3660700001)(101416001)(7110500001)(102836003)(6506003)(189998001)(39410400001)(3280700002)(6512003)(39380400001)(6116002)(93886004)(2906002)(3846002)(38730400001)(606004)(4001150100001)(39400400001)(33656002)(97736004)(54356999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR04MB0829; H:DM5PR04MB0828.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: docusign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B050E2C9CBC84BE78FB7AD04CC0EB426docusigncom_" MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2016 17:41:09.4896 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0829 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 17:44:19 -0000 --_000_B050E2C9CBC84BE78FB7AD04CC0EB426docusigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm9uam91ciwNCg0KwqsgMTk5NyBFIMK7IGRvZXMgbm90IG1lYW4gwqsgRS10aCByZXZpc2lvbiDC uywgaXQgbWVhbnMgaXTigJlzIHRoZSBFbmdsaXNoIHZlcnNpb24uIERvd25sb2FkIHRoZSBTcGFu aXNoIGFuZCBGcmVuY2ggdmVyc2lvbnMsIGFuZCB5b3XigJlsbCBzZWUgwqsgMTk5NyBTIMK7IGFu ZCDCqyAxOTk3IEYgwrssIHJlc3BlY3RpdmVseS4NCg0KWW91IGNhbiBmaW5kIG90aGVyIGZvcm1h dHMgb2YgcHJldmlvdXMgWC41MDkgc3RhbmRhcmQsIHN1Y2ggYXMgaHR0cDovL3d3dy5nYXRld2F5 Lm5hbWVmbG93Lm5ldC9ucC9kcy9vc2kvLiBUaGlzIGlzIFguNTA5djIgKFguNTA5OjE5OTMpLCB0 aGUgUG9zdHNjcmlwdCBmaWxlIHdhcyBjcmVhdGVkIGluIDE5OTQsIGFuZCB0aGUgd2ViIHNlcnZl ciBraW5kbHkgcmV0dXJucyBhIMKrIExhc3QtTW9kaWZpZWQ6IE1vbiwgMDQgU2VwIDE5OTUgMTE6 NTE6MDMgR01UIMK7IEhUVFAgaGVhZGVyLg0KDQpDb3JkaWFsZW1lbnQsDQpFcndhbm4gQWJhbGVh DQoNCkxlIDI5IG5vdi4gMjAxNiDDoCAwNjoxNSwgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+IGEgw6ljcml0IDoNCg0KU2Vl IGluLWxpbmUuDQoNCkppbQ0KDQpGcm9tOiBFcndhbm4gQWJhbGVhIFttYWlsdG86RXJ3YW5uLkFi YWxlYUBkb2N1c2lnbi5jb21dDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjQsIDIwMTYgNzoz OCBBTQ0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZA YXVndXN0Y2VsbGFycy5jb20+Pg0KQ2M6IGN1cmRsZUBpZXRmLm9yZzxtYWlsdG86Y3VyZGxlQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtDdXJkbGVdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeC0wMy50eHQNCg0KQm9uam91ciwNCg0KU29tZSBjb21t ZW50cyBvbiBzZWN0aW9uIDM6DQoNCg0KICAgVGhlIEFsZ29yaXRobUlkZW50aWZpZXIgdHlwZSwg d2hpY2ggaXMgaW5jbHVkZWQgZm9yIGNvbnZlbmllbmNlLCBpcw0KDQogICBkZWZpbmVkIGFzIGZv bGxvd3M6DQoNCg0KDQogICBBbGdvcml0aG1JZGVudGlmaWVyICA6Oj0gIFNFUVVFTkNFICB7DQoN CiAgICAgICBhbGdvcml0aG0gICBPQkpFQ1QgSURFTlRJRklFUiwNCg0KICAgICAgIHBhcmFtZXRl cnMgIEFOWSBERUZJTkVEIEJZIGFsZ29yaXRobSBPUFRJT05BTA0KDQogICB9DQoNCg0KDQpUaGlz IGlzIGFuIEFTTi4xOjE5ODggbm90YXRpb24sIGFuZCB0aGUgcmVzdCBvZiB0aGUgZHJhZnQgdXNl cyBhbiBBU04uMToxOTk0IG5vdGF0aW9uLCB0aGUgMiBhcmUgaW5jb21wYXRpYmxlIChBTlkgZG9l cyBub3QgZXhpc3QgYW55bW9yZSkuIFlvdSBjYW4gcmVwZWF0IHRoZSBkZWZpbml0aW9uIGZyb20g UkZDNTkxMSBpZiB5b3Ugd2FudC4NCg0KDQoNCltKTFNdIERvaW5nIHRoaXMgbWFrZXMgc2Vuc2Ug dG8gbWUuICBJIHdpbGwgZG8gc28uICBJIGp1c3QgY29waWVkIHRoaXMgc2VjdGlvbiBmcm9tIGFu IGV4aXN0aW5nIFJGQyB3aGljaCB1c2VkIDE5ODggc3ludGF4Lg0KDQoNCg0KDQoNCiAgIFRoZSBm aWVsZHMgaW4gQWxnb3JpdGhtSWRlbnRpZmllciBoYXZlIHRoZSBmb2xsb3dpbmcgbWVhbmluZ3M6 DQoNCg0KDQogICBvICBhbGdvcml0aG0gaWRlbnRpZmllcyB0aGUgY3J5cHRvZ3JhcGhpYyBhbGdv cml0aG0gd2l0aCBhbiBvYmplY3QNCg0KICAgICAgaWRlbnRpZmllci4gIFRoaXMgaXMgb25lIG9m IHRoZSBPSURzIGRlZmluZWQgYmVsb3cuDQoNCg0KDQogICBvICBwYXJhbWV0ZXJzLCB3aGljaCBh cmUgb3B0aW9uYWwsIGFyZSB0aGUgYXNzb2NpYXRlZCBwYXJhbWV0ZXJzIGZvcg0KDQogICAgICB0 aGUgYWxnb3JpdGhtIGlkZW50aWZpZXIgaW4gdGhlIGFsZ29yaXRobSBmaWVsZC4gIFdoZW4gdGhl IDE5OTcNCg0KICAgICAgc3ludGF4IGZvciBBbGdvcml0aG1JZGVudGlmaWVyIHdhcyBpbml0aWFs bHkgZGVmaW5lZCwgaXQgb21pdHRlZA0KDQogICAgICB0aGUgT1BUSU9OQUwga2V5IHdvcmQuICBU aGUgb3B0aW9uYWxpdHkgb2YgdGhlIHBhcmFtZXRlcnMgZmllbGQNCg0KICAgICAgd2FzIGxhdGVy IHJlY292ZXJlZCB2aWEgYSBkZWZlY3QgcmVwb3J0LCBidXQgYnkgdGhlbiBtYW55IHBlb3BsZQ0K DQogICAgICB0aG91Z2h0IHRoYXQgdGhlIGZpZWxkIHdhcyBtYW5kYXRvcnkuICBGb3IgdGhpcyBy ZWFzb24sIGEgc21hbGwNCg0KICAgICAgbnVtYmVyIG9mIGltcGxlbWVudGF0aW9ucyBtYXkgc3Rp bGwgcmVxdWlyZSB0aGUgZmllbGQgdG8gYmUNCg0KICAgICAgcHJlc2VudC4NCg0KDQoNClRoaXMg aXMgY29uZnVzZWQgYW5kIHdyb25nLiBXaGF0IGlzIHRoaXMgwqsgMTk5NyDCuyBzdXBwb3NlZCB0 byBtZWFuPyBUaGVyZSBpcyBhbiBBU04uMToxOTk3IHN5bnRheCAoaXQgaW50cm9kdWNlcyBVVEY4 U3RyaW5nIGZvciBleGFtcGxlKSwgYW4gWC41MDkgZWRpdGlvbiAwOC85NyAoZmlyc3QgZWRpdGlv biBvZiBYLjUwOXYzKSwgYW5kIHRoZXkgYXJlIG5vdCBjb25jZXJuZWQgYnkgdGhpcyBvbWlzc2lv biBvZiBPUFRJT05BTCBoZXJlOyBYLjUwOToxOTg4IChYLjUwOXYxKSBhbHJlYWR5IGhhZCB0aGUg cGFyYW1ldGVycyBPUFRJT05BTCwgYW5kIFguNTA5OjE5OTMgKFguNTA5djIpIHN3aXRjaGVkIHRv IHRoZSBBU04uMToxOTk0IHN5bnRheC4gUkZDMjQ1OSB0byA1MjgwIHN0aWxsIHVzZSB0aGUgb2Jz b2xldGUgQVNOLjE6MTk4OCBzeW50YXggYnV0IGFsbCBoYXZlIHRoZSBPUFRJT05BTCBrZXl3b3Jk LiBJZiBzb21lIHBlb3BsZSB0aG91Z2h0IHRoZSBmaWVsZCB3YXMgbWFuZGF0b3J5LCBpdOKAmXMg Zm9yIGFub3RoZXIgcmVhc29uIHRoYXQgdGhlIG9uZSBjbGFpbWVkIGhlcmUuDQoNCltKTFNdIFRo aXMgY29uY2VybnMgdGhlIDE5OTcgdmVyc2lvbiBvZiBYLjUwOS4gIFRoYXQgaXMgd2hlcmUgQWxn b3JpdGhtSWRlbnRpZmllciBpcyBkZWZpbmVkLg0KDQoNCg0KSSB0aGluayB0aGF0IHlvdSBhcmUg YmVpbmcgbWlzbGVkIGJ5IHRoZSBmYWN0IHRoYXQgdGhlIElFVEYgZG9lcyBub3QgZXZlciBtb2Rp ZnkgYSBkb2N1bWVudCB0aGF0IGhhcyBiZWVuIHB1Ymxpc2hlZC4gIFRoaXMgaXMgbm90IGEgdHJ1 ZSBzdGF0ZW1lbnQgZm9yIHRoZSBJVFUuICBXaGVuIEkgZ28gb3V0IHRvIHRoZSBJVFUgc2l0ZSBh bmQgZG93bmxvYWQgdGhlIHZlcnNpb24gdGhhdCBpcyBkYXRlZCAwOC85NywgdGhlIGRhdGUgYXQg dGhlIGJvdHRvbSBvZiB0aGUgY2xhaW1zIHRvIGJlIOKAnDE5OTcgReKAnS4gIEkgcmVhZCB0aGlz IGFzIGJlaW5nIHRoZSBFLXRoIHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudC4gIFRoaXMgbWVhbnMg dGhhdCB0aGUgZGVmZWN0IHJlcG9ydCByZWZlcnJlZCB0byBpbiB0aGUgdGV4dCB3YXMgcm9sbGVk IGludG8gdGhlIG9mZmljaWFsIElUVSB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4gIFRoZSBmYWN0 IHRoYXQgeW91IGNhbiBubyBsb25nZXIgc2VlIHRoYXQgdGhlIGRlZmVjdCBvbmNlIGV4aXN0ZWQg ZG9lcyBub3QgbWVhbiB0aGF0IGl0IHdhcyBuZXZlciBpbiB0aGUgZG9jdW1lbnQuDQoNCg0KDQog ICBJbiB0aGlzIGRvY3VtZW50IHdlIGRlZmluZWQgc2l4IG5ldyBPSURzIGZvciBpZGVudGlmeWlu ZyB0aGUNCg0KICAgZGlmZmVyZW50IGN1cnZlL2FsZ29yaXRobSBwYWlycy4gIFRoZSBjdXJ2ZXMg YmVpbmcgQ3VydmUyNTUxOSBhbmQNCg0KICAgQ3VydmU0NDguICBUaGUgYWxnb3JpdGhtcyBiZWlu ZyBFQ0RILCBFZERTQSBpbiBwdXJlIG1vZGUgYW5kIEVkRFNBIGluDQoNCiAgIHByZS1oYXNoIG1v ZGUuICBGb3IgYWxsIG9mIHRoZSBPSURzLCB0aGUgcGFyYW1ldGVycyBNVVNUIGJlIGFic2VudC4N Cg0KICAgUmVnYXJkbGVzcyBvZiB0aGUgZGVmZWN0IGluIHRoZSBvcmlnaW5hbCAxOTk3IHN5bnRh eCwgaW1wbGVtZW50YXRpb25zDQoNCiAgIE1VU1QgTk9UIGFjY2VwdCBhIHBhcmFtZXRlcnMgdmFs dWUgb2YgTlVMTC4NCg0KDQpBZ2FpbiwgdGhlcmXigJlzIG5vIGRlZmVjdCBpbiBzb21lIDE5OTcg c3ludGF4LiBUaGUgYWJzZW5jZSBvZiB0aGUgcGFyYW1ldGVycyBmaWVsZCBpcyBlbmZvcmNlZCBi eSB1c2luZyBhIHJlYWwgQVNOLjEgY29tcGlsZXIgYW5kIHRoZSBwcm9wZXIgdXNlIG9mIGNvbnN0 cmFpbnRzLg0KV2l0aCB0aGUgZGVmaW5pdGlvbnMgcHJvdmlkZWQgaW4gc2VjdGlvbiA5IGZvciBz YS1FZERTQSogb2JqZWN0cywgYXBwbGllZCB0byB0aGUgZGVmaW5pdGlvbiBvZiBTaWduYXR1cmVB bGdvcml0aG1JZGVudGlmaWVyIHRha2VuIGZyb20gUkZDNTkxMSwgaGF2aW5nIGFueSBwcmVzZW50 IHBhcmFtZXRlciAoZXZlbiBhIE5VTEwpIHdvdWxkIGJlIGludmFsaWQgaWYgdGhlIGFsZ29yaXRo bUlkZW50aWZpZXIgdGFrZXMgb25lIG9mIHRoZSBpZC1FZERTQSogdmFsdWVzIChiZWNhdXNlIG9m IHRoZSBjb25zdHJhaW50cykuDQoNCkNvcmRpYWxlbWVudCwNCkVyd2FubiBBYmFsZWENCg0KTGUg MjMgbm92LiAyMDE2IMOgIDIyOjI2LCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29t PG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gYSDDqWNyaXQgOg0KDQpJIGJlbGlldmUg dGhhdCB0aGlzIGRyYWZ0IGFkZHJlc3NlcyBhbGwgb2YgdGhlIGxhc3QgY2FsbCBjb21tZW50cyB0 aGF0IHdlIGhhdmUgcmVjZWl2ZWQgdG9kYXRlLg0KDQoqIFRoZSBmYWN0IHRoYXQgd2UgYXJlIG5v dCB1c2luZyBjb250ZXh0cyBoYXMgYmVlbiBtb3ZlZCB0byB0aGUgaW50cm9kdWN0aW9uIC0gYWxv bmcgd2l0aCBzb21lIHJlYXNvbmluZy4NCg0KKiBVc2Ugb2YgTlVMTCBwYXJhbWV0ZXJzIGlzIG5v dCBhIE1VU1QgTk9UIHJhdGhlciB0aGFuIGEgU0hPVUxEIE5PVA0KDQoqIEFkZGl0aW9uYWwgdGV4 dCBvbiB0aGUgdXNlIG9mIFB1cmUgRWREU0EgZm9yIGxvbmcgQ1JMcyBhbmQgdGhlIHVzZSBvZiBD UkwgZGlzdHJpYnV0aW9uIHBvaW50cyB0byBkZWFsIHdpdGggaXQuDQoNCkppbQ0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjMsIDIwMTYgMToxNiBQTQ0KVG86 IFNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9zZWZzc29uLm9yZzxtYWlsdG86c2ltb25Aam9zZWZz c29uLm9yZz4+OyBKaW0gU2NoYWFkDQo8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseQ0K c3VibWl0dGVkIGJ5IEppbSBTY2hhYWQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOiBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4DQpSZXZpc2lvbjogMDMNClRpdGxlOiBB bGdvcml0aG0gSWRlbnRpZmllcnMgZm9yIEVkMjU1MTksIEVkMjU1MTlwaCwgRWQ0NDgsIEVkNDQ4 cGgsDQpYMjU1MTkgYW5kIFg0NDggZm9yIHVzZSBpbiB0aGUgSW50ZXJuZXQgWC41MDkgUHVibGlj IEtleSBJbmZyYXN0cnVjdHVyZQ0KRG9jdW1lbnQgZGF0ZTogMjAxNi0xMS0yMw0KR3JvdXA6IGN1 cmRsZQ0KUGFnZXM6IDE2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDMudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jdXJkbGUtcGtp eC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jdXJkbGUtcGtpeC0wMw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzDQoNCkFic3RyYWN0Og0KICBUaGlz IGRvY3VtZW50IHNwZWNpZmllcyBhbGdvcml0aG0gaWRlbnRpZmllcnMgYW5kIEFTTi4xIGVuY29k aW5nDQogIGZvcm1hdHMgZm9yIEVsbGlwdGljIEN1cnZlIGNvbnN0cnVjdHMgdXNpbmcgdGhlIEN1 cnZlMjU1MTkgYW5kDQogIEN1cnZlNDQ4IGN1cnZlcy4gIFRoZSBzaWduYXR1cmUgYWxnb3JpdGht cyBjb3ZlcmVkIGFyZSBFZDI1NTE5LA0KICBFZDI1NTE5cGgsIEVkNDQ4IGFuZCBFZDQ0OHBoLiAg VGhlIGtleSBhZ3JlZW1lbnQgYWxnb3JpdGhtIGNvdmVyZWQNCiAgYXJlIFgyNTUxOSBhbmQgWDQ0 OC4gIFRoZSBlbmNvZGluZyBmb3IgUHVibGljIEtleSwgUHJpdmF0ZSBLZXkgYW5kDQogIEVkRFNB IGRpZ2l0YWwgc2lnbmF0dXJlIHN0cnVjdHVyZXMgaXMgcHJvdmlkZWQuDQoNCg0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4uDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkN1cmRsZSBtYWlsaW5nIGxpc3QNCkN1cmRsZUBpZXRmLm9yZzxtYWls dG86Q3VyZGxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jdXJkbGUNCg0KDQo= --_000_B050E2C9CBC84BE78FB7AD04CC0EB426docusigncom_ Content-Type: text/html; charset="utf-8" Content-ID: <1CFA0693537B7147B0741D072692AFA3@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Cb25qb3Vy LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCsKrIDE5OTcgRSZu YnNwO8K7IGRvZXMgbm90IG1lYW4gwqsmbmJzcDtFLXRoIHJldmlzaW9uIMK7LCBpdCBtZWFucyBp dOKAmXMgdGhlIEVuZ2xpc2ggdmVyc2lvbi4gRG93bmxvYWQgdGhlIFNwYW5pc2ggYW5kIEZyZW5j aCB2ZXJzaW9ucywgYW5kIHlvdeKAmWxsIHNlZSDCqyZuYnNwOzE5OTcgUyZuYnNwO8K7IGFuZCDC qyZuYnNwOzE5OTcgRiZuYnNwO8K7LCByZXNwZWN0aXZlbHkuPGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+WW91IGNhbiBmaW5kIG90aGVyIGZvcm1hdHMgb2YgcHJldmlvdXMgWC41MDkg c3RhbmRhcmQsIHN1Y2ggYXMmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmdhdGV3YXkubmFtZWZs b3cubmV0L25wL2RzL29zaS8iIGNsYXNzPSIiPmh0dHA6Ly93d3cuZ2F0ZXdheS5uYW1lZmxvdy5u ZXQvbnAvZHMvb3NpLzwvYT4uIFRoaXMgaXMgWC41MDl2MiAoWC41MDk6MTk5MyksIHRoZSBQb3N0 c2NyaXB0IGZpbGUgd2FzIGNyZWF0ZWQgaW4gMTk5NCwNCiBhbmQgdGhlIHdlYiBzZXJ2ZXIga2lu ZGx5IHJldHVybnMgYSDCqyBMYXN0LU1vZGlmaWVkOiBNb24sIDA0IFNlcCAxOTk1IDExOjUxOjAz IEdNVCZuYnNwO8K7IEhUVFAgaGVhZGVyLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNvcmRpYWxlbWVudCw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RXJ3YW5uIEFiYWxlYTwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPkxlIDI5IG5vdi4gMjAxNiDDoCAwNjoxNSwgSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iIGNsYXNzPSIiPmlldGZAYXVndXN0Y2VsbGFy cy5jb208L2E+Jmd0OyBhIMOpY3JpdCA6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIg c3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+U2VlIGluLWxpbmUuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5KaW08bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBi bHVlOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDRwdDsi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29s aWQgbm9uZSBub25lOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRl ci10b3Atd2lkdGg6IDFwdDsgcGFkZGluZzogM3B0IDBpbiAwaW47IiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Fcndhbm4gQWJhbGVhIFs8 YSBocmVmPSJtYWlsdG86RXJ3YW5uLkFiYWxlYUBkb2N1c2lnbi5jb20iIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1haWx0bzpFcndh bm4uQWJhbGVhQGRvY3VzaWduLmNvbTwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwg Tm92ZW1iZXIgMjQsIDIwMTYgNzozOCBBTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmltIFNj aGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmlldGZA YXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmN1cmRsZUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+Y3VyZGxlQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0N1cmRsZV0gTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzLnR4dDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkJvbmpvdXIs PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KU29tZSBjb21tZW50cyBvbiBzZWN0aW9uIDM6PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgVGhlIEFs Z29yaXRobUlkZW50aWZpZXIgdHlwZSwgd2hpY2ggaXMgaW5jbHVkZWQgZm9yIGNvbnZlbmllbmNl LCBpczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgZGVmaW5lZCBhcyBmb2xsb3dzOjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj48bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7IEFsZ29yaXRobUlkZW50aWZpZXImbmJzcDsgOjo9Jm5ic3A7IFNF UVVFTkNFJm5ic3A7IHs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFsZ29yaXRobSZuYnNwOyZuYnNwOyBPQkpFQ1QgSURFTlRJRklFUiw8bzpwIGNsYXNzPSIiPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcmFtZXRlcnMmbmJzcDsgQU5ZIERFRklORUQg QlkgYWxnb3JpdGhtIE9QVElPTkFMPG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyB9PG86cCBjbGFzcz0iIj48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IG9ycGhh bnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+VGhpcyBpcyBhbiBBU04uMToxOTg4IG5vdGF0 aW9uLCBhbmQgdGhlIHJlc3Qgb2YgdGhlIGRyYWZ0IHVzZXMgYW4gQVNOLjE6MTk5NCBub3RhdGlv biwgdGhlIDIgYXJlIGluY29tcGF0aWJsZSAoQU5ZIGRvZXMgbm90IGV4aXN0IGFueW1vcmUpLiBZ b3UgY2FuIHJlcGVhdCB0aGUgZGVmaW5pdGlvbiBmcm9tIFJGQzU5MTEgaWYgeW91IHdhbnQuPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDY4LCAxMTQsIDE5 Nik7IiBjbGFzcz0iIj5bSkxTXSBEb2luZyB0aGlzIG1ha2VzIHNlbnNlIHRvIG1lLiZuYnNwOyBJ IHdpbGwgZG8gc28uJm5ic3A7IEkganVzdCBjb3BpZWQgdGhpcyBzZWN0aW9uIGZyb20gYW4gZXhp c3RpbmcgUkZDIHdoaWNoIHVzZWQgMTk4OCBzeW50YXguPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYig2OCwgMTE0LCAxOTYpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IiBjbGFzcz0iIj48 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgVGhlIGZpZWxk cyBpbiBBbGdvcml0aG1JZGVudGlmaWVyIGhhdmUgdGhlIGZvbGxvd2luZyBtZWFuaW5nczo8bzpw IGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IGFsZ29yaXRobSBpZGVudGlmaWVz IHRoZSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSB3aXRoIGFuIG9iamVjdDxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWRlbnRpZmllci4mbmJzcDsgVGhpcyBpcyBvbmUgb2Yg dGhlIE9JRHMgZGVmaW5lZCBiZWxvdy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBv Jm5ic3A7IHBhcmFtZXRlcnMsIHdoaWNoIGFyZSBvcHRpb25hbCwgYXJlIHRoZSBhc3NvY2lhdGVk IHBhcmFtZXRlcnMgZm9yPG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0Nv dXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUg YWxnb3JpdGhtIGlkZW50aWZpZXIgaW4gdGhlIGFsZ29yaXRobSBmaWVsZC4mbmJzcDsgV2hlbiB0 aGUgMTk5NzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l dyc7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3ludGF4IGZvciBB bGdvcml0aG1JZGVudGlmaWVyIHdhcyBpbml0aWFsbHkgZGVmaW5lZCwgaXQgb21pdHRlZDxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0i Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIE9QVElPTkFMIGtleSB3b3JkLiZu YnNwOyBUaGUgb3B0aW9uYWxpdHkgb2YgdGhlIHBhcmFtZXRlcnMgZmllbGQ8bzpwIGNsYXNzPSIi PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdhcyBsYXRlciByZWNvdmVyZWQgdmlhIGEgZGVmZWN0 IHJlcG9ydCwgYnV0IGJ5IHRoZW4gbWFueSBwZW9wbGU8bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRob3VnaHQgdGhhdCB0aGUgZmllbGQgd2FzIG1hbmRhdG9yeS4mbmJzcDsg Rm9yIHRoaXMgcmVhc29uLCBhIHNtYWxsPG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBudW1iZXIgb2YgaW1wbGVtZW50YXRpb25zIG1heSBzdGlsbCByZXF1aXJlIHRoZSBmaWVs ZCB0byBiZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l dyc7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlc2VudC48bzpw IGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3Jzsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5UaGlzIGlzIGNvbmZ1c2Vk IGFuZCB3cm9uZy4gV2hhdCBpcyB0aGlzIMKrJm5ic3A7MTk5NyZuYnNwO8K7IHN1cHBvc2VkIHRv IG1lYW4/IFRoZXJlIGlzIGFuIEFTTi4xOjE5OTcgc3ludGF4IChpdCBpbnRyb2R1Y2VzIFVURjhT dHJpbmcgZm9yIGV4YW1wbGUpLCBhbiBYLjUwOSBlZGl0aW9uIDA4Lzk3IChmaXJzdCBlZGl0aW9u IG9mIFguNTA5djMpLCBhbmQgdGhleSBhcmUgbm90IGNvbmNlcm5lZCBieSB0aGlzIG9taXNzaW9u IG9mIE9QVElPTkFMIGhlcmU7IFguNTA5OjE5ODggKFguNTA5djEpIGFscmVhZHkgaGFkIHRoZSBw YXJhbWV0ZXJzIE9QVElPTkFMLCBhbmQgWC41MDk6MTk5MyAoWC41MDl2Mikgc3dpdGNoZWQgdG8g dGhlIEFTTi4xOjE5OTQgc3ludGF4LiBSRkMyNDU5IHRvIDUyODAgc3RpbGwgdXNlIHRoZSBvYnNv bGV0ZSBBU04uMToxOTg4IHN5bnRheCBidXQgYWxsIGhhdmUgdGhlIE9QVElPTkFMIGtleXdvcmQu IElmIHNvbWUgcGVvcGxlIHRob3VnaHQgdGhlIGZpZWxkIHdhcyBtYW5kYXRvcnksIGl04oCZcyBm b3IgYW5vdGhlciByZWFzb24gdGhhdCB0aGUgb25lIGNsYWltZWQgaGVyZS48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDY4LCAxMTQsIDE5Nik7IiBjbGFzcz0iIj5bSkxTXSBUaGlzIGNv bmNlcm5zIHRoZSAxOTk3IHZlcnNpb24gb2YgWC41MDkuJm5ic3A7IFRoYXQgaXMgd2hlcmUgQWxn b3JpdGhtSWRlbnRpZmllciBpcyBkZWZpbmVkLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEw cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoNjgsIDExNCwgMTk2KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDY4LCAxMTQsIDE5 Nik7IiBjbGFzcz0iIj5JIHRoaW5rIHRoYXQgeW91IGFyZSBiZWluZyBtaXNsZWQgYnkgdGhlIGZh Y3QgdGhhdCB0aGUgSUVURiBkb2VzIG5vdCBldmVyIG1vZGlmeSBhIGRvY3VtZW50IHRoYXQgaGFz IGJlZW4gcHVibGlzaGVkLiZuYnNwOyBUaGlzIGlzIG5vdCBhIHRydWUgc3RhdGVtZW50IGZvciB0 aGUgSVRVLiZuYnNwOyBXaGVuIEkgZ28gb3V0IHRvIHRoZSBJVFUgc2l0ZSBhbmQgZG93bmxvYWQg dGhlIHZlcnNpb24gdGhhdCBpcyBkYXRlZCAwOC85NywgdGhlIGRhdGUgYXQgdGhlIGJvdHRvbSBv ZiB0aGUgY2xhaW1zIHRvIGJlIOKAnDE5OTcgReKAnS4mbmJzcDsgSSByZWFkIHRoaXMgYXMgYmVp bmcgdGhlIEUtdGggcmV2aXNpb24gb2YgdGhlIGRvY3VtZW50LiZuYnNwOyBUaGlzIG1lYW5zIHRo YXQgdGhlIGRlZmVjdCByZXBvcnQgcmVmZXJyZWQgdG8gaW4gdGhlIHRleHQgd2FzIHJvbGxlZCBp bnRvIHRoZSBvZmZpY2lhbCBJVFUgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuJm5ic3A7IFRoZSBm YWN0IHRoYXQgeW91IGNhbiBubyBsb25nZXIgc2VlIHRoYXQgdGhlIGRlZmVjdCBvbmNlIGV4aXN0 ZWQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IHdhcyBuZXZlciBpbiB0aGUgZG9jdW1lbnQuPG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IG9y cGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsg SW4gdGhpcyBkb2N1bWVudCB3ZSBkZWZpbmVkIHNpeCBuZXcgT0lEcyBmb3IgaWRlbnRpZnlpbmcg dGhlPG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsi IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgY3VydmUvYWxnb3JpdGhtIHBhaXJzLiZu YnNwOyBUaGUgY3VydmVzIGJlaW5nIEN1cnZlMjU1MTkgYW5kPG86cCBjbGFzcz0iIj48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBD dXJ2ZTQ0OC4mbmJzcDsgVGhlIGFsZ29yaXRobXMgYmVpbmcgRUNESCwgRWREU0EgaW4gcHVyZSBt b2RlIGFuZCBFZERTQSBpbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdD b3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgcHJlLWhhc2ggbW9kZS4mbmJzcDsg Rm9yIGFsbCBvZiB0aGUgT0lEcywgdGhlIHBhcmFtZXRlcnMgTVVTVCBiZSBhYnNlbnQuPG86cCBj bGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIi PiZuYnNwOyZuYnNwOyBSZWdhcmRsZXNzIG9mIHRoZSBkZWZlY3QgaW4gdGhlIG9yaWdpbmFsIDE5 OTcgc3ludGF4LCBpbXBsZW1lbnRhdGlvbnM8bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IE1VU1QgTk9UIGFj Y2VwdCBhIHBhcmFtZXRlcnMgdmFsdWUgb2YgTlVMTC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KQWdhaW4sIHRoZXJl4oCZcyBubyBkZWZlY3QgaW4gc29tZSAxOTk3IHN5bnRh eC4gVGhlIGFic2VuY2Ugb2YgdGhlIHBhcmFtZXRlcnMgZmllbGQgaXMgZW5mb3JjZWQgYnkgdXNp bmcgYSByZWFsIEFTTi4xIGNvbXBpbGVyIGFuZCB0aGUgcHJvcGVyIHVzZSBvZiBjb25zdHJhaW50 cy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCldpdGggdGhlIGRl ZmluaXRpb25zIHByb3ZpZGVkIGluIHNlY3Rpb24gOSBmb3Igc2EtRWREU0EqIG9iamVjdHMsIGFw cGxpZWQgdG8gdGhlIGRlZmluaXRpb24gb2YgU2lnbmF0dXJlQWxnb3JpdGhtSWRlbnRpZmllciB0 YWtlbiBmcm9tIFJGQzU5MTEsIGhhdmluZyBhbnkgcHJlc2VudCBwYXJhbWV0ZXIgKGV2ZW4gYSBO VUxMKSB3b3VsZCBiZSBpbnZhbGlkIGlmIHRoZSBhbGdvcml0aG1JZGVudGlmaWVyIHRha2VzIG9u ZSBvZiB0aGUgaWQtRWREU0EqDQogdmFsdWVzIChiZWNhdXNlIG9mIHRoZSBjb25zdHJhaW50cyku PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KQ29yZGlhbGVtZW50LDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KRXJ3YW5uIEFiYWxlYTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xh c3M9IiIgdHlwZT0iY2l0ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkxlIDIzIG5vdi4gMjAxNiDDoCAyMjoyNiwgSmlt IFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmll dGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OyBhIMOpY3JpdCA6PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkkgYmVs aWV2ZSB0aGF0IHRoaXMgZHJhZnQgYWRkcmVzc2VzIGFsbCBvZiB0aGUgbGFzdCBjYWxsIGNvbW1l bnRzIHRoYXQgd2UgaGF2ZSByZWNlaXZlZCB0b2RhdGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KKiBUaGUgZmFjdCB0aGF0IHdlIGFyZSBub3QgdXNpbmcgY29udGV4dHMgaGFzIGJlZW4g bW92ZWQgdG8gdGhlIGludHJvZHVjdGlvbiAtIGFsb25nIHdpdGggc29tZSByZWFzb25pbmcuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBVc2Ugb2YgTlVMTCBwYXJhbWV0ZXJzIGlzIG5v dCBhIE1VU1QgTk9UIHJhdGhlciB0aGFuIGEgU0hPVUxEIE5PVDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCiogQWRkaXRpb25hbCB0ZXh0IG9uIHRoZSB1c2Ugb2YgUHVyZSBFZERTQSBmb3Ig bG9uZyBDUkxzIGFuZCB0aGUgdXNlIG9mIENSTCBkaXN0cmlidXRpb24gcG9pbnRzIHRvIGRlYWwg d2l0aCBpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpKaW08YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2lu LWJvdHRvbTogNXB0OyIgY2xhc3M9IiIgdHlwZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnIgY2xhc3M9IiI+DQpGcm9tOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiBzdHls ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5p bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPls8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl08YnIgY2xhc3M9IiI+ DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDIzLCAyMDE2IDE6MTYgUE08YnIgY2xhc3M9IiI+ DQpUbzogU2ltb24gSm9zZWZzc29uICZsdDs8YSBocmVmPSJtYWlsdG86c2ltb25Aam9zZWZzc29u Lm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+c2ltb25Aam9zZWZzc29uLm9yZzwvYT4mZ3Q7OyBKaW0gU2NoYWFkPGJyIGNsYXNz PSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIiBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5pZXRm QGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDMudHh0PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseTxi ciBjbGFzcz0iIj4NCnN1Ym1pdHRlZCBieSBKaW0gU2NoYWFkIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYW1lOjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7PC9zcGFuPmRyYWZ0LWlldGYtY3VyZGxlLXBraXg8 YnIgY2xhc3M9IiI+DQpSZXZpc2lvbjo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNw Ozwvc3Bhbj4wMzxiciBjbGFzcz0iIj4NClRpdGxlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7PC9zcGFuPkFsZ29yaXRobSBJZGVudGlmaWVycyBmb3IgRWQyNTUxOSwgRWQyNTUx OXBoLCBFZDQ0OCwgRWQ0NDhwaCw8YnIgY2xhc3M9IiI+DQpYMjU1MTkgYW5kIFg0NDggZm9yIHVz ZSBpbiB0aGUgSW50ZXJuZXQgWC41MDkgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZTxiciBjbGFz cz0iIj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDs8 L3NwYW4+MjAxNi0xMS0yMzxiciBjbGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7PC9zcGFuPmN1cmRsZTxiciBjbGFzcz0iIj4NClBhZ2VzOjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7PC9zcGFuPjE2PGJyIGNsYXNzPSIiPg0KVVJMOiAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1jdXJkbGUtcGtpeC0wMy50eHQiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzLnR4dDwvYT48YnIgY2xhc3M9IiI+ DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY3Vy ZGxlLXBraXgvIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWN1cmRsZS1wa2l4LzwvYT48YnIgY2xhc3M9IiI+DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDMiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAzPC9hPjxiciBjbGFzcz0iIj4NCkRpZmY6ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWN1cmRs ZS1wa2l4LTAzIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1jdXJkbGUtcGtpeC0wMzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFj dDo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbGdv cml0aG0gaWRlbnRpZmllcnMgYW5kIEFTTi4xIGVuY29kaW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Zm9ybWF0cyBmb3IgRWxsaXB0aWMgQ3VydmUgY29uc3RydWN0cyB1c2luZyB0aGUgQ3Vy dmUyNTUxOSBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtDdXJ2ZTQ0OCBjdXJ2ZXMuICZu YnNwO1RoZSBzaWduYXR1cmUgYWxnb3JpdGhtcyBjb3ZlcmVkIGFyZSBFZDI1NTE5LDxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwO0VkMjU1MTlwaCwgRWQ0NDggYW5kIEVkNDQ4cGguICZuYnNwO1Ro ZSBrZXkgYWdyZWVtZW50IGFsZ29yaXRobSBjb3ZlcmVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7YXJlIFgyNTUxOSBhbmQgWDQ0OC4gJm5ic3A7VGhlIGVuY29kaW5nIGZvciBQdWJsaWMgS2V5 LCBQcml2YXRlIEtleSBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtFZERTQSBkaWdpdGFs IHNpZ25hdHVyZSBzdHJ1Y3R1cmVzIGlzIHByb3ZpZGVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnRvb2xz LmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDEycHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgY2xhc3M9IiI+DQpDdXJkbGUgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOkN1cmRsZUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+Q3VyZGxlQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY3VyZGxlIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRs ZTwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_B050E2C9CBC84BE78FB7AD04CC0EB426docusigncom_-- From nobody Wed Nov 30 11:16:08 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD591294FA for ; Wed, 30 Nov 2016 11:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 Pw-mksffVm0i for ; Wed, 30 Nov 2016 11:16:03 -0800 (PST) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 7BE6B12996D for ; Wed, 30 Nov 2016 11:16:01 -0800 (PST) Received: by mail-io0-x243.google.com with SMTP id j92so4473788ioi.0 for ; Wed, 30 Nov 2016 11:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AC9kuPdHol5lAtjcH5GtKc3sqGIO2c0DbBTq+dDP0+w=; b=rukpLmbJowVS41HXOeqAcXP2VDSkfagCFfBjUD5iOzqIxWc1t+MJmCbDucbAN69Mne qCf18WywmaWijVVQcpUCWw0TJTdD+g8+Tqcp/4fbWiRwtS7YGO3Re448sHRgPvJmyqKr AVyYs4R3ZxGBgMxPeYC1luniWPF/qGbnFuOHFA7K2Myy4bbTGFVj3gGFy3owh/9PiXIN WmyNfVuvRraVBdBZRzoQwR+z4FzzYCtHLRx/oMjV07TDMNjtj55Nx4kbTGQXxTBrmPCm vDO4xQgNx+itc96v467Hjqh+3zo+YlM1H9V+YdfSISlusk0EYaUSzXwxyWTuEHOr5uiU 1kEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AC9kuPdHol5lAtjcH5GtKc3sqGIO2c0DbBTq+dDP0+w=; b=MO9LFMV8u0mk42X9jIPsH2JuoHoS7VVexLtC+DAFaRk7lDiPLSMfjD7asGWX3PI6T/ sFc743HPmLgaoWcaPORQYttOd/7cw+1ZGVhCGdd51fjZNOGgHxYmmevRj/LuaoI18TkO qhKJjf7JSlJd7eQofkjpSP8TXsmdPHSzLWQ/p+7LDxr0eH65uCG0CsuwUifPjbzBMGb+ TmL6cD8QdR7Y+r1hPTVITmYvOggcNoEmgZSdiPm87eTB9joDVpnVW/h+aZh5ARl30NSs EwDQl3pfTYBFuyWfrrdb3CUZsectC06n2UqGQdB5/5xI85wSg+aiykt44XBp0rAQlD3A 2x6g== X-Gm-Message-State: AKaTC02F0MBb0fuKTEaODXj/ZuGiNbGP06VICT4XBYfSziHQrkDORpTjZ0KNcYj17/0qDKiagwHOmwBZdAbx8w== X-Received: by 10.36.181.9 with SMTP id v9mr29960803ite.48.1480533359487; Wed, 30 Nov 2016 11:15:59 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.59.214 with HTTP; Wed, 30 Nov 2016 11:15:58 -0800 (PST) In-Reply-To: References: <141AEF7B-1853-4EB8-8A7E-5226B67D2761@vpnc.org> <1249672855.512.1479165396790.JavaMail.zimbra@nic.cz> <026cf48fcc404ef998e7dabc905f35f5@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Wed, 30 Nov 2016 14:15:58 -0500 X-Google-Sender-Auth: 3_wHU2NzO7H-ejcJJGygOWQavfw Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=f403045d9916f870400542898816 Archived-At: Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , curdle , Paul Hoffman Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 19:16:06 -0000 --f403045d9916f870400542898816 Content-Type: text/plain; charset=UTF-8 Hi, Thank you all for the reviews. My understanding is that these reviews have been considered in the new text and we are moving the document forward. Yours, Rich and Daniel On Tue, Nov 15, 2016 at 9:24 AM, Daniel Migault wrote: > Sounds like cross mailing list consensus ;-) > > For those that have not yet reviewed the document, the WGLC is almost > ending, so please provide your comments by the end of the week... or on > your way back! > > Yours > > Daniel > > On Mon, Nov 14, 2016 at 6:19 PM, Salz, Rich wrote: > >> >> > I also have feeling that we don't have to explain *in the draft* why we >> > picked this particular algorithm. >> >> Much as I don't like to disagree with my co-chair :) I agree with you. >> RFC's typically say "how to do it." Rationale's are usually left for the >> WG mailing list or perhaps conference papers :) >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > --f403045d9916f870400542898816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you all for the reviews. My un= derstanding is that these reviews have been considered in the new text and = we are moving the document forward.

Yours,
Rich and= Daniel

On Tue, Nov 15, 2016 at 9:24 AM, Daniel Migault <daniel.migault= @ericsson.com> wrote:
Sounds like cross mailing list consensus ;-)
=
For those that have not yet reviewed the document, the WGLC is al= most ending, so please provide your comments by the end of the week... or o= n your way back!

Yours

Daniel

On Mon, Nov 14= , 2016 at 6:19 PM, Salz, Rich <rsalz@akamai.com> wrote:

> I also have feeling that we don't have to explain *in the draft* w= hy we
> picked this particular algorithm.

Much as I don't like to disagree with my co-chair :) I agree wit= h you.=C2=A0 RFC's typically say "how to do it."=C2=A0 Ration= ale's are usually left for the WG mailing list or perhaps conference pa= pers :)
_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--f403045d9916f870400542898816-- From nobody Wed Nov 30 11:25:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1451112996A for ; Wed, 30 Nov 2016 11:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjUm-L49nivM for ; Wed, 30 Nov 2016 11:25:22 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974671293D8 for ; Wed, 30 Nov 2016 11:25:22 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id m5so229083502ioe.3 for ; Wed, 30 Nov 2016 11:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=XP0X9mTU+7lmhT9uKz4Zt3EKI1dm87yyRa7OHGEH8cs=; b=LgF+8KImk0TGUNzM/9w4RemvtkawYIqAUoN25E/9QVEqWEa17Xzy7zlOTFeZT30iyF gXPTqo/Zbv7D/dHn7w+eIr0f+5QI3bSmRs4IohX3+RDUddijG6DddAHH0Fe6bh+55PFI Y/LYzv1gTpuMvnKrA+Rl10dAXBtTVkeRKkGBCgWLuFn+u8olgoq4rwOAmrtE5qvYuGun 4z5CYLNGzh36JchEzmAlu1/uEqRnJ1vMD0AegNMP3PW0hprb3CphCUm8cYd6b3UNTZfx nbtqwdLVc4QDpFlRVz/kyovH1FT/QVTRWdrTgw582iPQk9DyoaPqIRWvZ65GN7h97KKF U6yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=XP0X9mTU+7lmhT9uKz4Zt3EKI1dm87yyRa7OHGEH8cs=; b=lFU97Lfem/IiYjbq9gm8Tnf7lX8SyZiqMX64bMLD9p/UDz1QiIBlvak3ABA/m21/Lr N+jucScb6sF6dI/4kk++wPo9alIudUecZVm5NlisyODO9FfkLOAMfBFd3gUwDgmGBer1 0/zkymXPcezIi78YDX1Vhe1/xq/oaEWssO/Nj2m82g9+zviA8ZagDITgPYyLkoshGojB 2SzFHnZZUrQXtkhu/b8FZp+jZs4aLz58DhCm5Xc36klBHxSpzqhs0Xo/fLBHdkj2qqWM vfnlpVK2U5/07BBriOffuxCSRAwm6LqTDtEQrPnPDwgmh8Mt8yM4HxTlv311mt4TMqVB N/6A== X-Gm-Message-State: AKaTC02PEA5CeKuUYAaEOj3W2urbh9RvqDR0248qyJjbH5uZFiHeZR5MNcVTgfYtDQwAj2sy0O/uOBYy+PpAWg== X-Received: by 10.36.181.9 with SMTP id v9mr29998697ite.48.1480533921776; Wed, 30 Nov 2016 11:25:21 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.59.214 with HTTP; Wed, 30 Nov 2016 11:25:21 -0800 (PST) From: Daniel Migault Date: Wed, 30 Nov 2016 14:25:21 -0500 X-Google-Sender-Auth: r-R5RUm3-pWuZYg6PUjdLxhrw2A Message-ID: To: curdle Content-Type: multipart/alternative; boundary=f403045d99167c48d8054289aa51 Archived-At: Subject: [Curdle] WGLC draft-ietf-curdle-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 19:25:25 -0000 --f403045d99167c48d8054289aa51 Content-Type: text/plain; charset=UTF-8 Hi, This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-cms-eddsa-signatures-02 The version to be reviewed is https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-02 Please send your comments, questions, and edit proposals to the WG mail list until December 15th, 2016. If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this. Yours, Rich and Daniel --f403045d99167c48d8054289aa51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This message starts a Working Group Last Call (WGLC) for draft-ietf-curdle-cms-eddsa-signatures-02

The version to be reviewed is https://tools.ietf.org/html/= draft-ietf-curdle-cms-eddsa-signatures-02

Please send your comments, questions, and edit proposals to the WG mail=20 list until December 15th, 2016.=C2=A0 If you believe that the document is= =20 ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.

Yours,

Rich and Daniel
--f403045d99167c48d8054289aa51-- From nobody Wed Nov 30 11:37:36 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79286129984 for ; Wed, 30 Nov 2016 11:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeEr6bS4BCv5 for ; Wed, 30 Nov 2016 11:37:24 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3E0129976 for ; Wed, 30 Nov 2016 11:37:24 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id a124so367389228ioe.2 for ; Wed, 30 Nov 2016 11:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Xc6gtampRujUaWKk7n5QxAi6SadFUaJZ3HHFYqEW3dM=; b=CsGKDcVmnKPJYBLUhdcaUzMkkYRITTupr8u8uw0H7NYi2PGn6zg++eiaqnZcIACy+g GfbWRmAvwDUQ0YCo7TLFHbE0Wruuj69k5O3dqowzchhUNROIgdqQ+KyE3Kb2IEgB/leh mnY+j8U6Gx3PvueL4WtOeKR7sNCsi0xLpb7vy+uIiibvXJWodQ49fo0B/PhqBvkYxk0l Q5Rou5ZI/AzXJaOrgtkhsPIh4DOM877Y1CzUhHAduOvucx7i224XxLUUi6AjrQtbPbdI +8dpUufmEtY2ePzO52RfgU/MIUNmaAuY87wpv7bikguuPu1LNWdm3ju7DI3moKJqPxfi s96g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Xc6gtampRujUaWKk7n5QxAi6SadFUaJZ3HHFYqEW3dM=; b=HKj5RjnPXw2WhipR+bG3QiAeOG66kzgQfSbS+eAOI1M+SAGZJtnePKykXBfWd91rg2 ODnj5EaD67kzXustTYYVxMI+p6F0W8/B1ggwIiipZL42I/F9Sjag2cnMax0tgrqOYqZ5 /XDgYaYfC6cg3GoZjmCIn+nkEitf6MfHG1R50ZUY4ESe38veFDT2b6RDLNqtGYAfnF/i gNOJIp81TT8tJK1zNndGxziTefTOWCSpHGu4IGkWjm7EalM4YX2PfJtTffHyT9dWFMUL Dyj2IWBvbpD67cMh4qnh+9av0vWOGcP0JYbOGve4rJdhLQlqsGkIhmDtwen+Xq2ihGCp YTng== X-Gm-Message-State: AKaTC030Gy8tKjPmklJ+U6JuW/OblOAgCY5ZsICGYZzXH9cCa25DgscXfU2zlEApXpwUia7psBZ+oOeeuKLl/w== X-Received: by 10.36.89.6 with SMTP id p6mr30059281itb.48.1480534643623; Wed, 30 Nov 2016 11:37:23 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.59.214 with HTTP; Wed, 30 Nov 2016 11:37:23 -0800 (PST) In-Reply-To: <072301d24424$86e93eb0$94bbbc10$@augustcellars.com> References: <002f01d23975$c13182d0$43948870$@augustcellars.com> <072301d24424$86e93eb0$94bbbc10$@augustcellars.com> From: Daniel Migault Date: Wed, 30 Nov 2016 14:37:23 -0500 X-Google-Sender-Auth: WY06IpNckyVKM_0Rsk_NjvDTyyM Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11445bf882cf31054289d5d1 Archived-At: Cc: curdle Subject: Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 19:37:32 -0000 --001a11445bf882cf31054289d5d1 Content-Type: text/plain; charset=UTF-8 Hi Jim, I was thinking the second way. Given the first possibility it might be wise to restrict the responses. The current version mentions SHOULD NOT. Does anyone wants to comment on it ? If so provide feed back by the end of the week please. """ CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of certificates or CRLs. This is implied by the fact that those algorithms are not listed in the previous paragraph. Additionally OCSP responders SHOULD NOT use the pre-hash versions of the EdDSA algorithms when generating OCSP responses. No restriction is placed on generation of OCSP requests. """ Yours, Daniel On Mon, Nov 21, 2016 at 1:24 PM, Jim Schaad wrote: > I think that we cannot do a restriction on OCSP requests. One cannot know > in advance what the algorithm that a client wants to use. Allowing both > here is not a big problem for key usages. > > > > The question on OCSP responses has to do with if you think that the OCSP > responder is going to be using the same key as the CA or is independently > operated. In the first case the restriction to pure is justified. In the > second case the only reason for it is to restrict the set of things that > must be implemented. When I wrote the text I assumed that the first case > was more often the case, but I have no data to back that up. > > > > Jim > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Monday, November 21, 2016 7:07 AM > *To:* Jim Schaad > *Cc:* curdle ; Brian Smith > > *Subject:* Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 > > > > Hi, > > My interpretation is that there is a consensus the CRL MUST NOT use > prehash scheme. Do we have any consensus for 1) OCSP request and 2) OCSP > response ? > > Yours , > > Daniel > > > > > > On Mon, Nov 7, 2016 at 11:08 PM, Jim Schaad > wrote: > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Brian Smith > *Sent:* Monday, November 07, 2016 7:43 PM > *To:* Daniel Migault > *Cc:* curdle > *Subject:* Re: [Curdle] WGLC on draft-ietf-curdle-pkix-02 > > > > Daniel Migault wrote: > > 5. Key Usage Bits > > > CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for > the creation of certificates or CRLs. This is implied by the fact > that those algorithms are not listed in the previous paragraph. > Additionally OCSP responders SHOULD NOT use the pre-hash versions of > the EdDSA algorithms when generating OCSP responses. No restriction > is placed on generation of OCSP requests. > > > > This doesn't make sense to me. Isn't the goal of the prehash scheme was to > support the signing of large things on systems without large amounts of > memory? Why would CRLs (which may be large) be MUST NOT while OCSP > responses are SHOULD NOT? It seems like the MUST NOT should be on > certificates and OCSP responses and OCSP requests, which are all small. > IIRC, there was some debate on whether CRLs should be allowed to use the > prehash variants since CRLs could be large. I personally thing all of the > cases mentioned in this paragraph should be MUST NOT. > > > > [JLS] There was a discussion on this. In my opinion, there was not a > consensus that was reached at that time. I have been busy getting wine > done so I did not ever get back to trying a third time to figure out a > consensus for this. It will definitely be on the discussion list for the > F2F but I am more than willing to start a discussion here again. > > > > The reason that CRLs are current a MUST NOT is that certificates and CRLs > are almost always generated using the same key as the certificate is. We > do not want to be in the situation where the same key is used with > different algorithms, so allowing pre-hash schemes on CRLs also allows > pre-hash schemes on certificates. > > > > I could go either way for OCSP responses. > > > > Jim > > > > > > Cheers, > > Brian > > -- > > https://briansmith.org/ > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a11445bf882cf31054289d5d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jim,

I was thinking the second way. G= iven the first possibility it might be wise to restrict the responses. The = current version mentions SHOULD NOT. Does anyone wants to comment on it ? I= f so provide feed back by the end of the week please.

""&q= uot;
   CAs MUST NOT use the pre-hash versi=
ons of the EdDSA algorithms for
   the creation of certificates or CRLs.  This is implied by the fact
   that those algorithms are not listed in the previous paragraph.
   Additionally OCSP responders SHOULD NOT use the pre-hash versions of
   the EdDSA algorithms when generating OCSP responses.  No restriction
   is placed on generation of OCSP requests.
=C2=A0"""<= br>
Yours,
Daniel

=C2=A0


________= _______________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a11445bf882cf31054289d5d1-- From nobody Wed Nov 30 12:40:29 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA2129A72 for ; Wed, 30 Nov 2016 12:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 ggJjKUrjx-Ks for ; Wed, 30 Nov 2016 12:40:25 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6552129A23 for ; Wed, 30 Nov 2016 12:37:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B00D43000A8 for ; Wed, 30 Nov 2016 15:27:33 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BLu9P2xiYaX1 for ; Wed, 30 Nov 2016 15:27:32 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C503C30009E for ; Wed, 30 Nov 2016 15:27:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148035906861.5378.17334401091666617776.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 13:54:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <06F1427D-87E9-46F3-9AED-3962ADDA4CB9@vigilsec.com> References: <148035906861.5378.17334401091666617776.idtracker@ietfa.amsl.com> To: curdle@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 20:40:27 -0000 NIST just assigned the missing object identifier, so I updated the draft = to use it. Russ On Nov 28, 2016, at 1:51 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-eddsa-signatures-02.txt > Pages : 7 > Date : 2016-11-28 >=20 > Abstract: > This document specifies the conventions for using Edwards-curve > Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in > the Cryptographic Message Syntax (CMS). For each curve, EdDSA > defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA > mode is not used with the CMS. In addition, no context string is > used with the CMS. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -02 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 30 12:56:19 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F31129AC9 for ; Wed, 30 Nov 2016 12:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 HhObKl1esDi2 for ; Wed, 30 Nov 2016 12:56:15 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708BE129AC8 for ; Wed, 30 Nov 2016 12:52:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 450743000A8 for ; Wed, 30 Nov 2016 15:42:23 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ksHMjmyMOFix for ; Wed, 30 Nov 2016 15:42:22 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1FE2F300086 for ; Wed, 30 Nov 2016 15:42:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <06F1427D-87E9-46F3-9AED-3962ADDA4CB9@vigilsec.com> Date: Wed, 30 Nov 2016 15:46:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148035906861.5378.17334401091666617776.idtracker@ietfa.amsl.com> <06F1427D-87E9-46F3-9AED-3962ADDA4CB9@vigilsec.com> To: curdle@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 20:56:17 -0000 I have just learned that I was given an incorrect object identifier. I = will update the document once again when the NIST website is actually = updated to show the assignment. Russ On Nov 28, 2016, at 1:54 PM, Russ Housley wrote: > NIST just assigned the missing object identifier, so I updated the = draft to use it. >=20 > Russ >=20 >=20 > On Nov 28, 2016, at 1:51 PM, internet-drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the CURves, Deprecating and a Little = more Encryption of the IETF. >>=20 >> Title : Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) >> Author : Russ Housley >> Filename : draft-ietf-curdle-cms-eddsa-signatures-02.txt >> Pages : 7 >> Date : 2016-11-28 >>=20 >> Abstract: >> This document specifies the conventions for using Edwards-curve >> Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in >> the Cryptographic Message Syntax (CMS). For each curve, EdDSA >> defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA >> mode is not used with the CMS. In addition, no context string is >> used with the CMS. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-02 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -02 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 30 14:43:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E27129BA9 for ; Wed, 30 Nov 2016 14:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 RUHkcT09loMO for ; Wed, 30 Nov 2016 14:43:22 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC7512957E for ; Wed, 30 Nov 2016 14:43:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 889683001A6 for ; Wed, 30 Nov 2016 17:33:05 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 35MLGodSZs48 for ; Wed, 30 Nov 2016 17:33:04 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 863EF300086; Wed, 30 Nov 2016 17:33:04 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Wed, 30 Nov 2016 17:41:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E89FD59-D2DA-4697-AF37-5041B09F2035@vigilsec.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] AD review of draft-ietf-curdle-cms-chacha20-poly1305-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 22:43:24 -0000 Responding only to the comment where we still have a disconnect. >>> (2) section 3: What does "content authenticated encryption" mean >>> exactly? You use that phrase a lot, and I don't know what it means >>> and it does not occur in [CMS]. Do we need a better term? >>> (Apologies if I'm forgetting the WG discussing that.) >>=20 >> RFC 5083 uses the term "content-authenticated-encryption keys=94. I >> can add the hyphens id that improves clarity. >=20 > Personally, I think that term lacks clarity and adds confusion. > I don't see why it's better than just saying "key" when you > mean that, and "key+nonce" when that's meant. No, that is not what is meant. This key is used to authenticate and encrypt the content. That is why = RFC 5083 calls it the "content-authenticated-encryption key=94. I have just re-read Section 3, and I am at a loss to see where this = confusion is coming from. Russ
On Mon, Nov 21, 2016 at 1:24 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I think that we c= annot do a restriction on OCSP requests.=C2=A0 One cannot know in advance w= hat the algorithm that a client wants to use.=C2=A0 Allowing both here is n= ot a big problem for key usages.

=C2=A0

The question o= n OCSP responses has to do with if you think that the OCSP responder is goi= ng to be using the same key as the CA or is independently operated.=C2=A0 I= n the first case the restriction to pure is justified.=C2=A0 In the second = case the only reason for it is to restrict the set of things that must be i= mplemented.=C2=A0 When I wrote the text I assumed that the first case was m= ore often the case, but I have no data to back that up.

=C2=A0

Jim

=C2=A0<= u>

=C2=A0

From: Curdle [mail= to:curdle-boun= ces@ietf.org] On Behalf Of Daniel Migault
Sent: M= onday, November 21, 2016 7:07 AM
To: Jim Schaad <ietf@augustcellars.com&g= t;
Cc: curdle <curdle@ietf.org>; Brian Smith <brian@briansmith.org>

<= div class=3D"h5">
Subject: Re: [Curdle] WGLC on draft-ietf-curdle= -pkix-02

=C2=A0

Hi,

My interpretation is that = there is a consensus the CRL MUST NOT use prehash scheme. Do we have any co= nsensus for 1) OCSP request and 2) OCSP response ?

<= div>

Yours ,

Daniel

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">On Mon, Nov 7, 2016 at 11:08 PM, Jim Schaad <ietf@augustcellars.c= om> wrote:

=C2=A0

=C2=A0

From: Curdle [mailto:curdle-bounces@ietf.o= rg] On Behalf Of Brian Smith
Sent: Monday, November 07= , 2016 7:43 PM
To: Daniel Migault <daniel.migault@ericsson.com>Cc: curdle <curdle@ietf.org>
Subject: Re: [Curdle] WGLC on draft-iet= f-curdle-pkix-02

=C2=A0

Daniel Migau= lt <dan= iel.migault@ericsson.com> wrote:

5.=C2=A0 Key Usage Bits


=C2=A0=C2=A0 C= As MUST NOT use the pre-hash versions of the EdDSA algorithms for
=C2=A0= =C2=A0 the creation of certificates or CRLs.=C2=A0 This is implied by the f= act
=C2=A0=C2=A0 that those algorithms are not listed in the previous pa= ragraph.
=C2=A0=C2=A0 Additionally OCSP responders SHOULD NOT use the pr= e-hash versions of
=C2=A0=C2=A0 the EdDSA algorithms when generating OCS= P responses.=C2=A0 No restriction
=C2=A0=C2=A0 is placed on generation o= f OCSP requests.

=C2=A0

This doesn't make sense to me. Isn't the goal of the prehash schem= e was to support the signing of large things on systems without large amoun= ts of memory? Why would CRLs (which may be large) be MUST NOT while OCSP re= sponses are SHOULD NOT? It seems like the MUST NOT should be on certificate= s and OCSP responses and OCSP requests, which are all small. IIRC, there wa= s some debate on whether CRLs should be allowed to use the prehash variants= since CRLs could be large. I personally thing all of the cases mentioned i= n this paragraph should be MUST NOT.

=C2=A0

[JLS] There was a= discussion on this.=C2=A0 In my opinion, there was not a consensus that wa= s reached at that time.=C2=A0 I have been busy getting wine done so I did n= ot ever get back to trying a third time to figure out a consensus for this.= =C2=A0 It will definitely be on the discussion list for the F2F but I am mo= re than willing to start a discussion here again.

<= p class=3D"MsoNormal">=C2=A0

The reason that CRLs are current a MUST NOT is that certificates and CRL= s are almost always generated using the same key as the certificate is.=C2= =A0 We do not want to be in the situation where the same key is used with d= ifferent algorithms, so allowing pre-hash schemes on CRLs also allows pre-h= ash schemes on certificates.

=C2=A0

I could go either = way for OCSP responses.

=C2= =A0

Jim

=C2=A0

=C2=A0

Cheers,

Brian

--


___________________________________= ____________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/l= istinfo/curdle