From nobody Tue Dec 1 00:32:11 2015 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 D53D81B3376; Mon, 30 Nov 2015 15:52:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151130235242.13834.89824.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 15:52:42 -0800 Archived-At: X-Mailman-Approved-At: Tue, 01 Dec 2015 00:32:09 -0800 Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-02: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 30 Nov 2015 23:52:43 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-curdle-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-curdle/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't get what it means for Kerberos and JSON to be "potentially" in scope. It seems to me that they are in scope. If the WG chooses not to pursue the work related to them that's ok, but they're still in the scope of the charter. From nobody Tue Dec 1 00:33:44 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B8A1A9009; Tue, 1 Dec 2015 00:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0A05TpXqt42; Tue, 1 Dec 2015 00:33:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745191A9004; Tue, 1 Dec 2015 00:33:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 79C7EBE2F; Tue, 1 Dec 2015 08:33:38 +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 z7jAYEwvZXAE; Tue, 1 Dec 2015 08:33:37 +0000 (GMT) Received: from [10.36.40.84] (unknown [193.190.253.144]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8BEFDBDD0; Tue, 1 Dec 2015 08:33:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1448958817; bh=4SaCmE1KznW7toab87+yUTs2g67FiPUswQ3xtTowbgk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZLbhsun04On+/ErTsIlqLf5pkDOH0PGtiF0xZB/5gJT0tVy61F//ScMnzxnOhNcmg xid5bZ+OsqG1lcFhpUAfcRQ7kXmP9By7zXnqypSEPaH2leHatIQMycR5bArbOvbcJ5 SGl3U3fRrURlM6iBT3pp6sbA3YQM/RYNMEHrSzus= To: Alissa Cooper , The IESG References: <20151130235242.13834.89824.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565D5B60.8080208@cs.tcd.ie> Date: Tue, 1 Dec 2015 08:33:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151130235242.13834.89824.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-02: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 08:33:43 -0000 Hi Alissa, On 30/11/15 23:52, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-curdle-00-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-curdle/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I don't get what it means for Kerberos and JSON to be "potentially" in > scope. It seems to me that they are in scope. If the WG chooses not to > pursue the work related to them that's ok, but they're still in the scope > of the charter. "potentially" here just means that if the kitten (for Kerberos) or jose (for JSON) WGs preferred to do the work, then that work would not be done in curdle. There's a paragraph about that in the charter, Cheers, S. > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From nobody Tue Dec 1 12:29:56 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E51F1B35BB for ; Tue, 1 Dec 2015 12:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7H9wTK7sZyV for ; Tue, 1 Dec 2015 12:29:50 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653181B35B7 for ; Tue, 1 Dec 2015 12:29:50 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C7BD120C80 for ; Tue, 1 Dec 2015 15:29:48 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 01 Dec 2015 15:29:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=mFrLDu5Y3/8y7Pa3A641bYae/RY=; b=t6ocuy RvdyA4OqoEUQCeWYKuA3gbSkuEqTMY8fQQqyahnK/IC7fSRW/5mijWrjJ69cj9Tz +jcd0akR+mu1r61N7g4XJ7NR7QZyvSxXiYmvPdzVIeUq76KbNIWv3Tfz8GaGO416 knnE2yh6MNvktGzibAS24zOwI8XVv7TzLdjKg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=mFrLDu5Y3/8y7Pa 3A641bYae/RY=; b=mTLUtbhdkdJNFt+3W+yBh0uXKqfkiRzzUj7Z3jmk2iZWht0 MXp/nGPkg0F2aRPb35KNcTH/Gj3qJNVNi8nIJFNLtrSGp8/Fm7zXlqcwrOxUD1G5 z3Mg3/ojRL/MBAsoQSMoll9gR0svBs8XPbMsrL0A8yqPN6gRjYYdCDUb48rk= X-Sasl-enc: 7CuEo3LEA+hAFaAh/Xpm9HDLZ6q9+HLKxpCWPaWxqyam 1449001788 Received: from dhcp-171-68-20-161.cisco.com (dhcp-171-68-20-161.cisco.com [171.68.20.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 191BCC016F4; Tue, 1 Dec 2015 15:29:47 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <565D5B60.8080208@cs.tcd.ie> Date: Tue, 1 Dec 2015 12:29:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8B5B85E0-4172-4BEE-B312-8238397997C6@cooperw.in> References: <20151130235242.13834.89824.idtracker@ietfa.amsl.com> <565D5B60.8080208@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, IESG Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-02: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 20:29:52 -0000 > On Dec 1, 2015, at 12:33 AM, Stephen Farrell = wrote: >=20 >=20 > Hi Alissa, >=20 > On 30/11/15 23:52, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> charter-ietf-curdle-00-02: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-curdle/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I don't get what it means for Kerberos and JSON to be "potentially" = in >> scope. It seems to me that they are in scope. If the WG chooses not = to >> pursue the work related to them that's ok, but they're still in the = scope >> of the charter. >=20 > "potentially" here just means that if the kitten (for Kerberos) or > jose (for JSON) WGs preferred to do the work, then that work would > not be done in curdle. There's a paragraph about that in the charter, I understand, but the main point of writing a charter is to say what is = out of scope and in scope, not to guarantee that everything in scope = will definitely be worked on. If the sentence said =E2=80=9CTo be = concrete, the protocols the WG intends to work on are =E2=80=A6=E2=80=9D = that would be more accurate I think. Alissa >=20 > Cheers, > S. >=20 >=20 >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >>=20 From nobody Tue Dec 1 15:42:15 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0081B2A92; Tue, 1 Dec 2015 15:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdTItnBAoWtG; Tue, 1 Dec 2015 15:42:11 -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 AD1131B2A8D; Tue, 1 Dec 2015 15:42:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B181ABE7C; Tue, 1 Dec 2015 23:42:09 +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 58q-DKJ6UTak; Tue, 1 Dec 2015 23:42:07 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F3C1EBE77; Tue, 1 Dec 2015 23:42:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449013327; bh=Gzti+TATfhlFX6rKTr7I3+aRRgGIyNihADtCfsuDZNg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=3aiOeTkd/JaReWV4oqdXhrafdkr7ywban+tuioZLJOEAHC4DZ3BTkZL76ljn7ZAgQ Rq2E8KlVwkDISpfNP1sxoU0UtZ3I03ncSNgBndPoArTvyiU1xUpWD5QoOVTZRRTjwY wC7oniNoPg4tExrn9VJCEpjcUYAPuxUSYKgyXqLk= To: Alissa Cooper References: <20151130235242.13834.89824.idtracker@ietfa.amsl.com> <565D5B60.8080208@cs.tcd.ie> <8B5B85E0-4172-4BEE-B312-8238397997C6@cooperw.in> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565E304D.6050308@cs.tcd.ie> Date: Tue, 1 Dec 2015 23:42:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8B5B85E0-4172-4BEE-B312-8238397997C6@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, IESG Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-02: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 23:42:14 -0000 On 01/12/15 20:29, Alissa Cooper wrote: > >> On Dec 1, 2015, at 12:33 AM, Stephen Farrell >> wrote: >> >> >> Hi Alissa, >> >> On 30/11/15 23:52, Alissa Cooper wrote: >>> Alissa Cooper has entered the following ballot position for >>> charter-ietf-curdle-00-02: No Objection >>> >>> When responding, please keep the subject line intact and reply to >>> all email addresses included in the To and CC lines. (Feel free >>> to cut this introductory paragraph, however.) >>> >>> >>> >>> The document, along with other ballot positions, can be found >>> here: https://datatracker.ietf.org/doc/charter-ietf-curdle/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> I don't get what it means for Kerberos and JSON to be "potentially" in >>> scope. It seems to me that they are in scope. If the WG chooses >>> not to pursue the work related to them that's ok, but they're >>> still in the scope of the charter. >> >> "potentially" here just means that if the kitten (for Kerberos) or >> jose (for JSON) WGs preferred to do the work, then that work would >> not be done in curdle. There's a paragraph about that in the >> charter, > > I understand, but the main point of writing a charter is to say what > is out of scope and in scope, not to guarantee that everything in > scope will definitely be worked on. If the sentence said “To be > concrete, the protocols the WG intends to work on are …” that would > be more accurate I think. That'd be fine I reckon. Is [1] the right change? Ta, S. [1] https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-03.txt > > Alissa > >> >> Cheers, S. >> >> >>> >>> >>> _______________________________________________ Curdle mailing >>> list Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>> > > From nobody Wed Dec 2 04:37:01 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09081A8989 for ; Wed, 2 Dec 2015 04:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6xJCdOOYhJF for ; Wed, 2 Dec 2015 04:36:57 -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 76FE81A8987 for ; Wed, 2 Dec 2015 04:36:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 05D29BE53 for ; Wed, 2 Dec 2015 12:36:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77Q5uak4l_BK for ; Wed, 2 Dec 2015 12:36:54 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 31742BE4D for ; Wed, 2 Dec 2015 12:36:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449059814; bh=3sW4Sfb5LaEcxEdHVdQlMg+0wgeNUQvL/yCAPNvpeaQ=; h=To:From:Subject:Date:From; b=BBndHl0Fp70ZjdKLBDc8v0a5JS2aE3jrf2nav0wyh8enqu2M8g1Dk6tfMXz2frCGO 57mCoKewgtkhutgyOD+hH9+kY5bClvMh+7wltaaSuoRyD4TK5kcLEjr9E6jiXsQUMA c9iKKpd9TxFSCadFgyB0HL1qLE8dgfg+YwDt0CbU= To: curdle@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565EE5E6.70003@cs.tcd.ie> Date: Wed, 2 Dec 2015 12:36:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Curdle] getting started with curdling... X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2015 12:36:59 -0000 Hiya, There're 30 people subscribed to this list now, so we may as well get started - that is, please feel free to start discussion about the planned work now. Process-wise, this is on tomorrow's IESG agenda for initial consideration, all going well, it'll go out for external review for 2 weeks after that (that mail goes to ietf@ietf.org and to a bunch of other SDOs to see if they care), and if nothing turns up we may be able to formally charter the WG on the Dec 17th IESG call. We did get some fine folks volunteering to help with chairing this, but if you didn't send a mail to me and Kathleen about that, there's still time to do so. (Send that offlist please, in the next week or so.) If folks want to discuss the charter text [1] please do that too. (I still have to process Joel's comments on that, but will try get to that later today.) I have a scope question myself that I'll ask in a separate thread. Please do also start talking about the drafts that the WG will consider for adoption (also listed in [1]) and about their contents - there's no need to wait for the process stuff to get going with the work. Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ From nobody Wed Dec 2 04:49:00 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C78D1A899F for ; Wed, 2 Dec 2015 04:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6ZwQsY00r-W for ; Wed, 2 Dec 2015 04:48:56 -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 5C6CA1A8978 for ; Wed, 2 Dec 2015 04:48:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0D617BE53; Wed, 2 Dec 2015 12:48:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5m9sibWsjHu; Wed, 2 Dec 2015 12:48:54 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26A4CBE4D; Wed, 2 Dec 2015 12:48:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449060534; bh=1Q9b8DcqGwGlzzB2//OsQ3HUHRbsbwFVEwqqFCHk1XM=; h=To:Cc:From:Subject:Date:From; b=UDnFUfAPIVnT16diFT59+jmauocz41dBYCnO1bDan7fP2cqTg7Ev77HwS3tll0S1o ROpv1HOVuJXYSgPSShdn6oGutY1jqxjwRjr8G1869M+BrU6HZA41dmTRBTMfdjBzQb vk28kBaMJyWyd89a22vhIVwDMxDPVwC/gqHDvjLw= To: curdle@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565EE8B6.2010903@cs.tcd.ie> Date: Wed, 2 Dec 2015 12:48:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Mark Nottingham , Wendy Seltzer Subject: [Curdle] should we include xmldsig and xmlenc? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2015 12:48:58 -0000 Hiya, I was at a thing with some w3c folks yesterday and mentioned curdle. It is conceivable that W3C may want to add codepoints to xmldsig and xmlenc for the new curves, just like we do. So far though, I've not seen anyone ask specifically for that. xmldsig was a joint bit of work between the IETF and W3C but that was a bit of a process-pain, so xmlenc was just done as a W3C thing. OTOH, Don Eastlake did write up an RFC for some additional algorithms for those as RFC6931 as well. [1] I guess that amicable divorce wasn't ever fully finalised:-) So, questions: 1. is there interest to define how to use the new curves for xmldsig and xmlenc? 2. if 1==yes, do we have volunteers to do the editing work? 3. if 1==yes and 2==yes, is curdle the right place to do that or should we just leave that to W3C to handle as and when they want? FWIW, I've no strong opinions on this, but if this group felt that the answers to all 3 questions are yes, then we should probably sort that out with W3C (one way or another) while we're chartering curdle. If any of the answers is no, then we're good as-is and there's nothing else we need do for now. Cheers, S. PS: mnot and Wendy are cc'd as they're the relevant liaison folks between the IETF and W3C. [1] https://tools.ietf.org/html/rfc6931 From nobody Wed Dec 2 05:14:31 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350C41A8A68 for ; Wed, 2 Dec 2015 05:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC1j97YWQ9jz for ; Wed, 2 Dec 2015 05:14:28 -0800 (PST) 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 CDE3D1A8A63 for ; Wed, 2 Dec 2015 05:14:27 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tB2DE7h0006547 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 2 Dec 2015 14:14:08 +0100 From: Simon Josefsson To: Stephen Farrell References: <565EE8B6.2010903@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151202:stephen.farrell@cs.tcd.ie::jLRvnujrdsBqThVB:1ZjX X-Hashcash: 1:22:151202:wseltzer@w3.org::/IANmtNqV3W7Iajm:60wz X-Hashcash: 1:22:151202:curdle@ietf.org::yvB5fogiCW3LBR5d:71um X-Hashcash: 1:22:151202:mnot@mnot.net::rgw6boLyVj1YWeQT:DLz1 Date: Wed, 02 Dec 2015 14:14:06 +0100 In-Reply-To: <565EE8B6.2010903@cs.tcd.ie> (Stephen Farrell's message of "Wed, 2 Dec 2015 12:48:54 +0000") Message-ID: <87io4h2dsx.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.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: curdle@ietf.org, Wendy Seltzer , Mark Nottingham Subject: Re: [Curdle] should we include xmldsig and xmlenc? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2015 13:14:30 -0000 --=-=-= Content-Type: text/plain XML Digital Signatures is mentioned in the curdle charter text. I suggest to add XML Encryption too. Incidentally, I approached Wendy and Frederick Hirsch about this last month, and their recommendation (IIUC) was that since the W3C group is in maintenance mode it would be preferrable to announce work on this to their list and then go from there. I have an Ed25519/Ed448-for-XMLDigSig document sitting on my disk, but it is pending feedback from implementers. I don't believe it would be useful to approach this as a prescriptive work. I can post the document as an I-D if that would help get implementations going, but I don't think we should adopt this if nobody is interested in implementing it. I'm hesitant about burning energy on corner-cases since it will delay publishing the documents that implementers deployed years ago. Another option may be for the IETF to recognize reality and recommend against further use of XMLDigSig/XMLEnc completely. I.e., "XML Security Considered Harmful". A compromise would be to say that it is OK to use for existing use-cases, but don't use it in new protocols. I believe that reflect the general thinking among implementers about XML Security in general. /Simon Stephen Farrell writes: > Hiya, > > I was at a thing with some w3c folks yesterday and mentioned > curdle. It is conceivable that W3C may want to add codepoints > to xmldsig and xmlenc for the new curves, just like we do. So > far though, I've not seen anyone ask specifically for that. > > xmldsig was a joint bit of work between the IETF and W3C but > that was a bit of a process-pain, so xmlenc was just done as > a W3C thing. OTOH, Don Eastlake did write up an RFC for some > additional algorithms for those as RFC6931 as well. [1] I > guess that amicable divorce wasn't ever fully finalised:-) > > So, questions: > > 1. is there interest to define how to use the new curves for > xmldsig and xmlenc? > 2. if 1==yes, do we have volunteers to do the editing work? > 3. if 1==yes and 2==yes, is curdle the right place to do that > or should we just leave that to W3C to handle as and when > they want? > > FWIW, I've no strong opinions on this, but if this group > felt that the answers to all 3 questions are yes, then we > should probably sort that out with W3C (one way or another) > while we're chartering curdle. If any of the answers is no, > then we're good as-is and there's nothing else we need do > for now. > > Cheers, > S. > > PS: mnot and Wendy are cc'd as they're the relevant liaison > folks between the IETF and W3C. > > [1] https://tools.ietf.org/html/rfc6931 > > _______________________________________________ > 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 iQEcBAEBCAAGBQJWXu6eAAoJEIYLf7sy+BGd5K8IAJ8WYMPvPoMcuX8N7B0R6qbp mjYN97Gdco+OfnBcjVLTO3Pk9ZJdYRfSP1XFnzlCo73yNuqKjCV0H9apX9N0Kftf nbXjb1gTnEVJvh02W92rC0P1n/zASsrbTNbKxL5KZ1mDwokQ4xZseg0Xzm0y04rF 6jESquwskVED4mE6xR5Zz8Med/G6JfGZSUWtRCZPlpXpOI06T3gkfkzfqvQmYXze 4bML+fcX90B1+PDrjLW1sCfukXPOz5GGTsea/D7+53QjcLhJKhF2QSHFw/+wR/NA xDVthUhG8GmCappwFtKsriVNWHH5yX8b2m/xaAKWDA4a8feHqMGRZer9BwjKbHE= =Edvc -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 2 05:24:14 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563441A8AAA for ; Wed, 2 Dec 2015 05:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woAyOin1lQ6l for ; Wed, 2 Dec 2015 05:24:12 -0800 (PST) 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 1BC8C1A8AA9 for ; Wed, 2 Dec 2015 05:24:11 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tB2DNxOX008123 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 2 Dec 2015 14:24:00 +0100 X-Hashcash: 1:22:151202:curdle@ietf.org::FUtWYiP/2lKd/UT3:1Kcq From: Simon Josefsson To: curdle@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Wed, 02 Dec 2015 14:23:58 +0100 Message-ID: <87egf52dch.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.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [Curdle] SSH protocol work X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2015 13:24:13 -0000 --=-=-= Content-Type: text/plain Hi. Here are pointers to ongoing work related to SSH. Ben Harris work on Ed25519 signatures: https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 Aris Adamantiadis work on X25519/X448 key exchange: https://tools.ietf.org/html/draft-josefsson-ssh-curves-03 Damien Millers work on ChaCha20-Poly1305 cipher: https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00 These documents have been discussed on the ietf-ssh mailing list where the SSH experts hang out: http://news.gmane.org/gmane.ietf.secsh For completeness, compare the already published RFC 7479 on the Ed25519 SSHFP DNS resource record: https://tools.ietf.org/html/rfc7479 If anyone here has feedback on the documents, that would be welcome. Please change the subject line if you have comments on one particular document only. There are known open issues, so let's see if you spot them. :-) /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWXvDuAAoJEIYLf7sy+BGdbDMH/jZ8ZAlW/d98OudXWjcjN1VR uTAiDjcgXMzU3hYx7bum6Mv6rsd7HgO6FNGrjv1PqeAJLxa8iClKJ45d3tcXPm5m E0RpVVDSrD8iI1qF7vlsZX/6qbOMVZnFBN6/5oC9Tjf8CdSDdZzSLEkFqu9o352k NDnTtYh2K/GrFOmItmqsCMzg+Gk9UopjC58Zjxjsvgh5VuOWbFLBS1V/3EXMZaQm fHgzAhD3j9duw+myW3ePQ3NzQV6VwPz6+k2STbaALiABwhMGJZBPdFee3So6Rvcw UOjw54IXxoHJG2oEpPliw1fg76juzzLJQHrWuQpA3xtloQrKObWQYS++y8Xkubs= =d7BT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 2 05:46:30 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586CE1A8BC4 for ; Wed, 2 Dec 2015 05:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtAoc5T0ZsPd for ; Wed, 2 Dec 2015 05:46:26 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108A21A8BC5 for ; Wed, 2 Dec 2015 05:46:24 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6C020203F5 for ; Wed, 2 Dec 2015 08:46:23 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 02 Dec 2015 08:46:23 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=J44CVhhRtwG4Uz7Rd6dB3l3RnJw=; b=cLePzk kbdF6kd48vSPKYuirHOQAxVK/GEavgQZ0YdjtohaOcFOD+Qn54KZPeFdoNhKN9CQ 9EYShtxfJGFoxfYYd1ZpDrj25FSCzoIIEDFGiyWGw11NfX41UvmcFIR03BwCms44 dGguujEC1Q+Q70c14XEZZ0B6WZ0OlryY8aZcA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=J44CVhhRtwG4Uz7 Rd6dB3l3RnJw=; b=i4zrAgibXyMEQ1wDowYSpkzyeUIFdxH5tEQsoF7Dhw6TQ/o unyX6hxm1/o6kUlTl1UUtaNS/impGi3TkD5n94SuCT2QtzQ8V9USGL+NmUmkd09x 63pS5EqG5hTpj2+JA1/RvkO7LYIbnryw8MChVFTEK91tQthn7AqZH1sGzmWE= X-Sasl-enc: J8WXCQal9LxTmIzgX+WGoUFmEPhyr01XM8t0BtS3Ku62 1449063983 Received: from [192.168.1.203] (c-24-6-61-198.hsd1.ca.comcast.net [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id A675EC016C4; Wed, 2 Dec 2015 08:46:22 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <565E304D.6050308@cs.tcd.ie> Date: Wed, 2 Dec 2015 05:46:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151130235242.13834.89824.idtracker@ietfa.amsl.com> <565D5B60.8080208@cs.tcd.ie> <8B5B85E0-4172-4BEE-B312-8238397997C6@cooperw.in> <565E304D.6050308@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, IESG Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-02: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2015 13:46:27 -0000 > On Dec 1, 2015, at 3:42 PM, Stephen Farrell = wrote: >>>>=20 >>>>=20 > I don't get what it means for Kerberos and JSON to be "potentially" in >>>> scope. It seems to me that they are in scope. If the WG chooses >>>> not to pursue the work related to them that's ok, but they're >>>> still in the scope of the charter. >>>=20 >>> "potentially" here just means that if the kitten (for Kerberos) or=20= >>> jose (for JSON) WGs preferred to do the work, then that work would=20= >>> not be done in curdle. There's a paragraph about that in the >>> charter, >>=20 >> I understand, but the main point of writing a charter is to say what >> is out of scope and in scope, not to guarantee that everything in >> scope will definitely be worked on. If the sentence said =E2=80=9CTo = be >> concrete, the protocols the WG intends to work on are =E2=80=A6=E2=80=9D= that would >> be more accurate I think. >=20 > That'd be fine I reckon. Is [1] the right change? Yes, thanks. Alissa > Ta, > S. >=20 > [1] > = https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fd= oc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=3Dhttps%3A%2F%2Fd= atatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-03.txt= >=20 >>=20 >> Alissa >>=20 >>>=20 >>> Cheers, S. >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ Curdle mailing >>>> list Curdle@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/curdle >>>>=20 >>=20 >>=20 From nobody Wed Dec 2 06:20:04 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D81A9094 for ; Wed, 2 Dec 2015 06:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEE8RmwOc5jJ for ; Wed, 2 Dec 2015 06:20:01 -0800 (PST) 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 DFDEB1A9081 for ; Wed, 2 Dec 2015 06:20:00 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tB2EJkfi016761 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 2 Dec 2015 15:19:47 +0100 Date: Wed, 2 Dec 2015 15:19:39 +0100 From: Simon Josefsson To: Stephen Farrell Message-ID: <20151202151939.37f9ea18@latte.josefsson.org> In-Reply-To: <87io4h2dsx.fsf@latte.josefsson.org> References: <565EE8B6.2010903@cs.tcd.ie> <87io4h2dsx.fsf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/s_8ZC/9QqRKxY3NwM3.uWVx"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: curdle@ietf.org, Wendy Seltzer , Mark Nottingham Subject: Re: [Curdle] should we include xmldsig and xmlenc? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2015 14:20:02 -0000 --Sig_/s_8ZC/9QqRKxY3NwM3.uWVx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > I have an Ed25519/Ed448-for-XMLDigSig document sitting on my disk No need to keep it there, I have pushed it, and include it below. https://gitlab.com/jas/ietf-xmldsig-curves/blob/master/draft-josefsson-xmld= igsig-curves.md /Simon EdDSA Ed25519/Ed448 for XML Digital Signatures =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We describe how EdDSA digital signatures (Ed25519 and Ed448) [EDDSA] can be used in XML Digital Signatures [XMLDSIG]. Approach =3D=3D=3D=3D=3D=3D=3D=3D EdDSA is used in XML Digital Signatures through the Elliptic Curve Digital Signature Algorithm (ECDSA) framework described in [XMLECDSA]. While EdDSA is different from ECDSA, we have chosen to re-use existing elements and specify semantic conventions specific to EdDSA, rather than to describe a new mechanism. The remaining sections describe how use of EdDSA differs from use of other ECDSA schemes in the [XMLECDSA] framework. Namespace and Identifiers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The XML namespace URI that MUST be used by implementations of this specification is: http://josefsson.org/2015/12/xmldsig-eddsa# Elements in the namespace of the [XMLDSIG] specification are marked by using the namespace prefix "dsig" in the remaining sections of this document. The URI Identifiers used to identify the algorithms we describe are for Ed25519 and Ed448 respectively: http://josefsson.org/2015/12/xmldsig-eddsa#ed25519 http://josefsson.org/2015/12/xmldsig-eddsa#ed448 EdDSA Key Values =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D EdDSA public keys are encoded using the new element EdDSAKeyValue. Include the element inside dsig:KeyValue similar to dsig:RSAKeyValue, dsig:ECDSAKeyValue. The EdDSA public keys are binary strings as described in [EDDSA], here encoded as base64. DTD Replacement --------------- The following definition amends the entity Key.ANY Schema definition ----------------- The element consists of the base64 encoded public key. DTD Definition: EdDSA Signatures ---------------- Similar to RFC 4050, the input to the EdDSA algorithm is the canonicalized representation of the dsig:SignedInfo element as specified in Section 3 of [XMLDSIG]. The output of the EdDSA algorithm is a binary string. The signature value (text value of element dsig:SignatureValue - see section 4.2 of [XMLDSIG]) consists of the base64 encoding of the binary EdDSA output. Security Considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D See [EDDSA], [XMLDSIG], and [XMLECDSA] XML is by design prone to implementation flaws. References =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [EDDSA] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa [XMLDSIG] RFC 3275 [XMLECDSA] RFC 4050 Appendix =3D=3D=3D=3D=3D=3D=3D=3D Aggregate XML Schema -------------------- Aggregate DTD ------------- --Sig_/s_8ZC/9QqRKxY3NwM3.uWVx Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWXv37AAoJEIYLf7sy+BGdZcgH/RLi2wniO442oeQS9Hcxsv3B HkVb8/Jvoo6OpQHdlF2GFSumVAkKmaOLMHRBfi2dqM4oVX+E6vcbd9nKrB3iN68H Ooi/8H7tY0LacQdx5rFICGmkLiRv24PtYIQ2YAFGUWQvyyKGml6z66a2Bo5vH6eg i7zFmdlRx/PzC97RXLFwA6LcVeTQaqtBd/4FwHmV5CkfD/wnRsy0a0l6FAnRWzUM LspBI6OMUCIp/0lfYNIMwjSqlqLN+xqOj/63tCPgSoA+j8EmrjHEPlxARocXihgK uFy5FziZ5JvNm++E8XnbdNWh3CF7LswD/3tL4j34HTGbnIkJLx0pIIsllSi5lIE= =TyUL -----END PGP SIGNATURE----- --Sig_/s_8ZC/9QqRKxY3NwM3.uWVx-- From nobody Thu Dec 3 08:03:33 2015 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 9977E1A009E; Wed, 2 Dec 2015 15:01:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151202230118.31538.43294.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 15:01:18 -0800 Archived-At: X-Mailman-Approved-At: Thu, 03 Dec 2015 08:03:32 -0800 Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: [Curdle] Ben Campbell's No Objection on charter-ietf-curdle-00-03: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2015 23:01:18 -0000 Ben Campbell has entered the following ballot position for charter-ietf-curdle-00-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-curdle/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Alissa's and Joel's comments. From nobody Thu Dec 3 09:45:02 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17241B3350; Thu, 3 Dec 2015 09:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5NSNCe5b5KD; Thu, 3 Dec 2015 09:44:59 -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 7B97E1A8A76; Thu, 3 Dec 2015 09:44:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D791BE55; Thu, 3 Dec 2015 17:44:47 +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 pXnkUftpe7Qy; Thu, 3 Dec 2015 17:44:46 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1D296BE4D; Thu, 3 Dec 2015 17:44:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449164686; bh=8xdrzHIQkzl6u4cG3QgH4Gyfcz5SqxYXfJSVNkwACfI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=GrajpsUUvAlQJNSzcID2hG7NnPGGOF7ZYG3DsOLRGnPmz/zcoCDxMycWyVmn1Nltl sig04O1SP6rvC1HMWJwGBn/9FTzwmZKjheEuPsVUZjpUdw4nnKRo6NqK/QVihFiht9 5ptt5r8CXteOo2r8uioxlE3H9Wkzh9rikUrZlFLk= To: Joel Jaeggli , The IESG References: <20151128004026.32154.34180.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56607F8C.2040107@cs.tcd.ie> Date: Thu, 3 Dec 2015 17:44:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151128004026.32154.34180.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: Re: [Curdle] Joel Jaeggli's No Objection on charter-ietf-curdle-00-02: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:45:02 -0000 Hi Joel, I've made those edits. Let me know if there's any glitches. Thanks, S. [1] https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-03.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-04.txt On 28/11/15 00:40, Joel Jaeggli wrote: > Joel Jaeggli has entered the following ballot position for > charter-ietf-curdle-00-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-curdle/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > seems like: > > The relevant IETF protocols are primarily those protocols that are > standardized > through the IETF and that do not have an active working group, or where > the > working group decides to not take on the work. To be concrete, the > protocols in > scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML Digital Signatures > and > potentially Kerberos and JSON. > > can be simplified to > > The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML > Digital Signatures and > potentially Kerberos and JSON. > > also > > As the CURDLE working group will be handling changes to protocols and > registries some of which include what are now considered outdated > algorithm > options, the working group can also choose to propose deprecation of > such > algorithms. > > The CURDLE working group will be handling changes to protocols and > registries some of which include what are now considered outdated > algorithm > options, and may propose deprecation of such algorithms. > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From nobody Thu Dec 3 09:48:39 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD671B2C57 for ; Thu, 3 Dec 2015 09:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hglui0636uaM for ; Thu, 3 Dec 2015 09:48:37 -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 EA9111A8A76 for ; Thu, 3 Dec 2015 09:48:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B5255BE3F for ; Thu, 3 Dec 2015 17:48:35 +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 YitQ8ZuTy63d for ; Thu, 3 Dec 2015 17:48:34 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C779EBDF9 for ; Thu, 3 Dec 2015 17:48:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449164914; bh=upTqCjw+BaIOynzWUqMmwV7CejIwsFmDXnYS+uG7PRY=; h=To:From:Subject:Date:From; b=vQE+ogHOgpnTt8hO/I/QIHlDwWYmio5baU+e2VD7M0Q4ZDJ+Z4bzXySxRQiiMb3AC uGxLiDrit029DnrTgrr4jxJGxfOLBqHoX6fWrTZ0BNBsIZ6cEKeHkmkLPgD5uQ91/h HBImOZrCr0JSLq9fl3e+Gcetji+ffK+0k8gjHmgQ= To: curdle@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56608071.6080707@cs.tcd.ie> Date: Thu, 3 Dec 2015 17:48:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Curdle] process stuff status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:48:38 -0000 Hiya, The IESG today approved sending the charter for external review. [1] That'll go out to ietf@ietf.org and elsewhere early next week. If no problems arise, (as I expect) the charter will be back on the IESG telechat on Dec 17 to formally approve creation of the WG. In the meantime, please do discuss the drafts on the list. Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ From nobody Thu Dec 3 09:56:44 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1265D1ACD48; Thu, 3 Dec 2015 09:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKwlpzqK862C; Thu, 3 Dec 2015 09:56:41 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 A0DE51A8A77; Thu, 3 Dec 2015 09:56:40 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:20b8:df12:b8ce:94a8]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tB3HuX8X054032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Dec 2015 17:56:33 GMT (envelope-from joelja@bogus.com) To: Stephen Farrell , The IESG References: <20151128004026.32154.34180.idtracker@ietfa.amsl.com> <56607F8C.2040107@cs.tcd.ie> From: joel jaeggli Message-ID: <56608250.4000402@bogus.com> Date: Thu, 3 Dec 2015 09:56:32 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: <56607F8C.2040107@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KmuoCLm7s6sVAvs4A5vC9rwlLLi82s9om" Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: Re: [Curdle] Joel Jaeggli's No Objection on charter-ietf-curdle-00-02: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:56:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KmuoCLm7s6sVAvs4A5vC9rwlLLi82s9om Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All good On 12/3/15 9:44 AM, Stephen Farrell wrote: >=20 > Hi Joel, >=20 > I've made those edits. Let me know if there's any glitches. >=20 > Thanks, > S. >=20 > [1] > https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%= 2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-03.txt&url2=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-0= 4.txt >=20 > On 28/11/15 00:40, Joel Jaeggli wrote: >> Joel Jaeggli has entered the following ballot position for >> charter-ietf-curdle-00-02: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-curdle/ >> >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> seems like: >> >> The relevant IETF protocols are primarily those protocols that are >> standardized >> through the IETF and that do not have an active working group, or wher= e >> the >> working group decides to not take on the work. To be concrete, the >> protocols in >> scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML Digital Signature= s >> and >> potentially Kerberos and JSON. >> >> can be simplified to >> >> The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML >> Digital Signatures and >> potentially Kerberos and JSON. >> >> also >> >> As the CURDLE working group will be handling changes to protocols and= >> registries some of which include what are now considered outdated=20 >> algorithm >> options, the working group can also choose to propose deprecation of >> such >> algorithms. >> >> The CURDLE working group will be handling changes to protocols and >> registries some of which include what are now considered outdated=20 >> algorithm >> options, and may propose deprecation of such algorithms. >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >=20 --KmuoCLm7s6sVAvs4A5vC9rwlLLi82s9om Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlZgglEACgkQ8AA1q7Z/VrJpxACfV8U0KAfHrGGdNczeLylY2mwo OQAAnRrMG26pMOyyMYAxfygDvOUzdyau =ysRg -----END PGP SIGNATURE----- --KmuoCLm7s6sVAvs4A5vC9rwlLLi82s9om-- From nobody Fri Dec 4 09:08:47 2015 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 9F4651A8AA9; Fri, 4 Dec 2015 09:05:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151204170540.7382.2502.idtracker@ietfa.amsl.com> Date: Fri, 04 Dec 2015 09:05:40 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 09:08:47 -0800 Subject: [Curdle] ID Tracker State Update Notice: X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:05:41 -0000 State changed to External review. ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-curdle/ From nobody Fri Dec 4 09:08:49 2015 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 2B6E61A8AA5; Fri, 4 Dec 2015 09:05:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "The IESG" , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151204170550.441.14352.idtracker@ietfa.amsl.com> Date: Fri, 04 Dec 2015 09:05:50 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 04 Dec 2015 09:08:47 -0800 Subject: [Curdle] Telechat update notice: X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:05:50 -0000 Telechat date has been changed to 2015-12-17 from 2015-12-03 ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-curdle/ From nobody Wed Dec 9 10:10:34 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC791B2B89 for ; Wed, 9 Dec 2015 10:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cFjD_zfspb0 for ; Wed, 9 Dec 2015 10:10:25 -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 EAA2F1B2BB8 for ; Wed, 9 Dec 2015 10:10:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 361B0BE79 for ; Wed, 9 Dec 2015 18:01:04 +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 kHnSWBE1Utxi for ; Wed, 9 Dec 2015 18:01:01 +0000 (GMT) Received: from [10.0.10.19] (unknown [212.76.224.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 30573BDCC for ; Wed, 9 Dec 2015 18:01:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449684061; bh=kWPVnwAFi7FKBxQDwIPrmVzCDrTxPvRpf1VR2fWBsR0=; h=Subject:References:To:From:Date:In-Reply-To:From; b=bXZzxwHagJO19iSz7Qa7+vZ6ZWOhASOrEaMV6zllbvebaFyu046fLkum8xk8q/Pom 6oF1hvb2RZ70Ar4aSwemDoIrHMalZ60mZ3SNckqS3uWb+/WXHXVKvkDh/hvqjTAZFW By8fXySpiEBjev7PbWwicWsW4VgDap/9Nk67PJYU= References: <56686C32.6090400@cs.tcd.ie> To: curdle@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <56686C32.6090400@cs.tcd.ie> Message-ID: <56686C5C.8030801@cs.tcd.ie> Date: Wed, 9 Dec 2015 18:01:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56686C32.6090400@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Curdle] Fwd: code points for brainpool curves for DNSSEC X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2015 18:10:29 -0000 -------- Forwarded Message -------- Subject: code points for brainpool curves for DNSSEC Date: Wed, 9 Dec 2015 18:00:18 +0000 From: Stephen Farrell To: saag@ietf.org Hiya, The brainpool folks have written an I-D [1] that they are pushing through the rfc editor's independent stream. [2] That I-D wants to register code points for using their curves for DNSSEC. For documents that come through the independent stream, the IESG does an RFC 5742 [3] conflict review. The purpose of that review is to check that the RFC doesn't conflict with ongoing work in the IETF. If you have thoughts on this, please let me know before Dec 17th. I'll forward this to the dnsop, cfrg and curdle mailing lists to check there too. Apologies if you get >1 copy of this. Please try follow up on the saag list if you can. Thanks, Stephen. [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec [2] https://www.rfc-editor.org/pubprocess/ [3] https://tools.ietf.org/html/rfc5742 From nobody Wed Dec 9 13:42:08 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD8F1B2E18; Wed, 9 Dec 2015 13:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYx9eLQgr5iF; Wed, 9 Dec 2015 13:42:02 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 9FE2E1B2E1B; Wed, 9 Dec 2015 13:42:01 -0800 (PST) Received: by lbpu9 with SMTP id u9so38288690lbp.2; Wed, 09 Dec 2015 13:41:59 -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:date:message-id:subject :from:to:cc:content-type; bh=1XKaVUIvW0jvU0X8xFgIC4Fk9AKBggDj8DHgCtUNHww=; b=ayXMOzp+FuSNEw8402UmbtBSCaVq6qNxI2Uqdu4LRYsuJ/055s0EY/CJwoL6qHJGcy ZtPCLcHzsnM+xz0pSh8NW2f3af2UbNgiYU9Y8eB9QneMeYk2Bg0nr6FtCKNS3/zQnnTK kIvInLTMyiYdpQdHexmbEblCKgrWMeM8wfiiG4jmj6zxSqrEB3cCGttqDu8squazcBwc ohUUrLZ6byuoPjSaQJFX33oOd5NAvF6XOnRTCLu6ovyEVr7quEEhir0Y4Bxwp20ouS7T GVL9yFoy2dgNeVx05BPzT5gp1wWfFCu3RvY1kkq8dnP1oe7MPtPi/KioDkwdmJVVvGvq vviQ== MIME-Version: 1.0 X-Received: by 10.112.182.8 with SMTP id ea8mr3551829lbc.114.1449697319726; Wed, 09 Dec 2015 13:41:59 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Wed, 9 Dec 2015 13:41:59 -0800 (PST) In-Reply-To: <56686C32.6090400@cs.tcd.ie> References: <56686C32.6090400@cs.tcd.ie> Date: Wed, 9 Dec 2015 16:41:59 -0500 X-Google-Sender-Auth: IzXVcHPLh7qbKiA86bqRa-2g8y4 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell , "dnsop@ietf.org" , curdle@ietf.org Content-Type: multipart/alternative; boundary=001a11c37320c6392d05267df5ea Archived-At: Cc: "saag@ietf.org" Subject: Re: [Curdle] [saag] code points for brainpool curves for DNSSEC X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2015 21:42:04 -0000 --001a11c37320c6392d05267df5ea Content-Type: text/plain; charset=UTF-8 Objections so far * The approach is dated (not fast prime rigid) and the randomness isn't established to be rigid. * DNSSEC requires a single algorithm for interop * The code points are 8 bit and thus scarce * We should do Curdle first. I am opposed to Brainpool for all the above and in addition, I am opposed because the biggest problem with ECC has been too many choices. If people are given one choice, they will do it. If they have two then they will probably do both. With ECC we were given 16 choices by NIST and then the same again from Brainpool and a few other folks. So what a lot of people did was to conclude ECC wasn't mature enough to implement right now and adopted a wait-and-see approach. Brainpool was a good idea at the time it was proposed but the world moved on and the effort is counterproductive now. Since ACME and Lets Encrypt have been proposed, we can hopefully get away from the bogus idea that the mission of DNSSEC was 'free' certs. The utility of DNSSEC lies in being able to sign and distribute security policy information so that applications can achieve 'secure on first contact' security rather than 'secure after first contact'. For that to work, DNSSEC has to be using the same set of algorithms that the applications are using. The other area we might potentially leverage DNSSEC is to allow encryption of the initial exchange in a TLS/2 by putting a 'host key' in the DNS. This would allow the SNI and certificate exchanges to be encrypted. For this to be practical, DNSSEC and TLS have to converge on the same algorithm and curve. --001a11c37320c6392d05267df5ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Objections so far

* The approach is d= ated (not fast prime rigid) and the randomness isn't established to be = rigid.
* DNSSEC requires a single algorithm= for interop
* The code points are 8 bit an= d thus scarce
* We should do Curdle first.<= /div>

I am o= pposed to Brainpool for all the above and in addition, I am opposed because= the biggest problem with ECC has been too many choices. If people are give= n one choice, they will do it. If they have two then they will probably do = both.=C2=A0

With ECC we were given 16 choices by NIST and then the same again fro= m Brainpool and a few other folks. So what a lot of people did was to concl= ude ECC wasn't mature enough to implement right now and adopted a wait-= and-see approach.

Brainpool was a good idea at the time it was proposed but the w= orld moved on and the effort is counterproductive now.


Since ACME and Lets Encrypt have been proposed, we can hopefully= get away from the bogus idea that the mission of DNSSEC was 'free'= certs. The utility of DNSSEC lies in being able to sign and distribute sec= urity policy information so that applications can achieve 'secure on fi= rst contact' security rather than 'secure after first contact'.= For that to work, DNSSEC has to be using the same set of algorithms that t= he applications are using.

The other area we might potentially leverage DNSSEC is= to allow encryption of the initial exchange in a TLS/2 by putting a 'h= ost key' in the DNS. This would allow the SNI and certificate exchanges= to be encrypted. For this to be practical, DNSSEC and TLS have to converge= on the same algorithm and curve.

--001a11c37320c6392d05267df5ea-- From nobody Wed Dec 9 20:21:46 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF59E1B30A0 for ; Wed, 9 Dec 2015 20:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ueK6vDBb9X5 for ; Wed, 9 Dec 2015 20:21:43 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9E01B3093 for ; Wed, 9 Dec 2015 20:21:43 -0800 (PST) Received: by lbpu9 with SMTP id u9so42246476lbp.2 for ; Wed, 09 Dec 2015 20:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=zQaFUxYCPU0ZodPJJX9SlL71ps0JNM7mjOGLrAdr2k4=; b=aaGJl9fcjciF13wfd8PwHyCxGG8ClOtPecJNpZ5Ae4OH8MZJnYJoF1T8Z2/H4TI3IU nF7eiwQGZNuSsQ/YW7E6QIISUykRJAHcd5p4X4mCi8fmcdufDvoWhYSoZhodvHttelO9 s3pV85SpfLrQSTLwRee2WzFM1QS9bjhwHqzbp2r0RZYXZDSrKLeksgGc5Fr6/NHx/Z8j dpi7+166GisQkIsa0GldaXpJUqJAul3A0sC+f6ozwybpE+rAkQhTH0LIgBPDEGkg3ce2 c5iUUa+xo8ViBf3mBHSEHYxZoecf+VopZDNaS7EzJG63Bqp9wcEGNaqqrjiM91eINxee +Gvw== MIME-Version: 1.0 X-Received: by 10.112.170.194 with SMTP id ao2mr4110169lbc.142.1449721301425; Wed, 09 Dec 2015 20:21:41 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Wed, 9 Dec 2015 20:21:41 -0800 (PST) Date: Wed, 9 Dec 2015 23:21:41 -0500 X-Google-Sender-Auth: ZaFZDwn2yiR3L3NVwx0yS-k6LVw Message-ID: From: Phillip Hallam-Baker To: curdle@ietf.org Content-Type: multipart/alternative; boundary=001a11c3695631e2810526838b23 Archived-At: Subject: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 04:21:45 -0000 --001a11c3695631e2810526838b23 Content-Type: text/plain; charset=UTF-8 Whether or not we decide we should be using SHA2 or SHA3 across the board, we should make sure every application supports both: * The additional effort of doing SHA3 in CURDLE is minimal. * If we don't do SHA3 in CURDLE, people will write a series of separate drafts. This will be more work for the Security AD, IESG, IANA and the RFC Editor and the result is not likely to be as consistent or as good. * We should aim to have exactly two algorithms for each cryptographic primitive. A preferred algorithms that applications can expect to be supported and a 'hot spare' that applications should implement wherever possible in case of need. The hot spare should ideally be based on a different principle to the preferred. Right now SHA2 is the preferred digest function and I don't expect that to change. But the SHA1->SHA2 transition was a lot harder than it should have been and left a lot more broken gear than the MD5->SHA1 transition. The difference was that for MD5 we had a hot spare but a lot of vendors didn't even start to think about implementing SHA2 until the first compromise of SHA1 was announced. I do not see this as a slippery slope as the primary and hot-spare slots for every other algorithm are already filled. For public key we have RSA and the CFRG-ECC schemes. For symmetric encryption we have AES and CHA-CHA20. This is just rounding things out for digest functions so we have two options there. RSA is going to be the preferred algorithm until the CFRG work is complete and has seen significant deployment. That is still at least 5 years off which is a pity because it is cutting it awfully close. My expectation is that as soon as CFRG is done with the ECC curve work, the next focus of attention will be public key systems that are quantum resistant, (if we can convince ourselves such schemes actually exist). So by the time we are phasing RSA out, I expect that we will be looking at algorithms that have not been invented yet to replace it. Adding SHA3 to CURDLE is not a slippery slope. --001a11c3695631e2810526838b23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Whether or not we decide we should be using SHA2 or SHA3 a= cross the board, we should make sure every application supports both:
<= br>
* The additional effort of doing SHA3 in CURDLE is minimal.

* If we don't do SHA3 in CURDLE, people will wr= ite a series of separate drafts. This will be more work for the Security AD= , IESG, IANA and the RFC Editor and the result is not likely to be as consi= stent or as good.

* We should aim to have exactly = two algorithms for each cryptographic primitive. A preferred algorithms tha= t applications can expect to be supported and a 'hot spare' that ap= plications should implement wherever possible in case of need. The hot spar= e should ideally be based on a different principle to the preferred.
<= div>
Right now SHA2 is the preferred digest function and I do= n't expect that to change. But the SHA1->SHA2 transition was a lot h= arder than it should have been and left a lot more broken gear than the MD5= ->SHA1 transition. The difference was that for MD5 we had a hot spare bu= t a lot of vendors didn't even start to think about implementing SHA2 u= ntil the first compromise of SHA1 was announced.

<= br>
I do not see this as a slippery slope as the primary and hot-= spare slots for every other algorithm are already filled. For public key we= have RSA and the CFRG-ECC schemes. For symmetric encryption we have AES an= d CHA-CHA20. This is just rounding things out for digest functions so we ha= ve two options there.

RSA is going to be the prefe= rred algorithm until the CFRG work is complete and has seen significant dep= loyment. That is still at least 5 years off which is a pity because it is c= utting it awfully close. My expectation is that as soon as CFRG is done wit= h the ECC curve work, the next focus of attention will be public key system= s that are quantum resistant, (if we can convince ourselves such schemes ac= tually exist).

So by the time we are phasing RSA o= ut, I expect that we will be looking at algorithms that have not been inven= ted yet to replace it. Adding SHA3 to CURDLE is not a slippery slope.
=

--001a11c3695631e2810526838b23-- From nobody Wed Dec 9 20:50:23 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79FE1B30D0 for ; Wed, 9 Dec 2015 20:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFVKOOx2I8Wh for ; Wed, 9 Dec 2015 20:50:20 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 12B261B2EFA for ; Wed, 9 Dec 2015 20:50:20 -0800 (PST) Received: by wmec201 with SMTP id c201so8596001wme.1 for ; Wed, 09 Dec 2015 20:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WIDX49rz+qGfE5yhd/N/DfkFaFI2yCg+q3vMQxj4q+w=; b=psDYueQ9zKlk//la7eEWuuuozLTXMg8PEZgVbMFPCDUsbeJjtS6iCwszrMEBV+ZMX0 PE0WHiVSIvlFnR2ZxgwRCy0QCHkqTs5ot4W+0SEst27U/FQgm0T5TaBhS5gdvAnvgVsR ySYtzWfcqRa8Ne6a0bMzD8Uw3W9oZ6Gh8/glnkPHgfAhLk7SvC5cdcmEmChMLdAUBXCe AJ/QGQLkwFdpIqonYLII2QyiSfWvamxj1fMDeH1IbZtdLItbWpdPZBfE/q5B4nS/HBdb HDYk3mLyICxLFab63ri18Ew6ra/GKcfnXyWyXi/3JyomyqeDJ3Rfp26WMoJJZCj+bMwE is3Q== X-Received: by 10.28.215.209 with SMTP id o200mr14620689wmg.31.1449723018705; Wed, 09 Dec 2015 20:50:18 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id z66sm29185471wmz.7.2015.12.09.20.50.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Dec 2015 20:50:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Thu, 10 Dec 2015 06:50:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F153E13-AD63-4535-BC3A-D93C8E681C99@gmail.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3112) Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 04:50:22 -0000 Hi, Phil Not against this, but consider that SHA3 has been available for a while, = and I haven=E2=80=99t heard of any IETF group beginning work on = standardizing it. Compare and contrast with Curve25519, = ChaCha20/Poly1305 and EdDSA that had and have drafts in several working = groups even before the final documents were published. The only group that is considering SHA3 is CFRG (for EdDSA-448). I have = heard some people on other lists expressing a preference to ignore SHA3 = and standardize instead on Blake2 as the hot spare or even the primary. I don=E2=80=99t think the ADs want Curdle to shove a hot spare down into = a bunch of protocols, especially when there are active working groups = for these protocols (such as TLS or IPsecME). Yoav > On 10 Dec 2015, at 6:21 AM, Phillip Hallam-Baker = wrote: >=20 > Whether or not we decide we should be using SHA2 or SHA3 across the = board, we should make sure every application supports both: >=20 > * The additional effort of doing SHA3 in CURDLE is minimal. >=20 > * If we don't do SHA3 in CURDLE, people will write a series of = separate drafts. This will be more work for the Security AD, IESG, IANA = and the RFC Editor and the result is not likely to be as consistent or = as good. >=20 > * We should aim to have exactly two algorithms for each cryptographic = primitive. A preferred algorithms that applications can expect to be = supported and a 'hot spare' that applications should implement wherever = possible in case of need. The hot spare should ideally be based on a = different principle to the preferred. >=20 > Right now SHA2 is the preferred digest function and I don't expect = that to change. But the SHA1->SHA2 transition was a lot harder than it = should have been and left a lot more broken gear than the MD5->SHA1 = transition. The difference was that for MD5 we had a hot spare but a lot = of vendors didn't even start to think about implementing SHA2 until the = first compromise of SHA1 was announced. >=20 >=20 > I do not see this as a slippery slope as the primary and hot-spare = slots for every other algorithm are already filled. For public key we = have RSA and the CFRG-ECC schemes. For symmetric encryption we have AES = and CHA-CHA20. This is just rounding things out for digest functions so = we have two options there. >=20 > RSA is going to be the preferred algorithm until the CFRG work is = complete and has seen significant deployment. That is still at least 5 = years off which is a pity because it is cutting it awfully close. My = expectation is that as soon as CFRG is done with the ECC curve work, the = next focus of attention will be public key systems that are quantum = resistant, (if we can convince ourselves such schemes actually exist). >=20 > So by the time we are phasing RSA out, I expect that we will be = looking at algorithms that have not been invented yet to replace it. = Adding SHA3 to CURDLE is not a slippery slope. >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Dec 9 21:57:09 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D374F1B3168 for ; Wed, 9 Dec 2015 21:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N_66HKGHB-Z for ; Wed, 9 Dec 2015 21:57:06 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6171B3162 for ; Wed, 9 Dec 2015 21:57:06 -0800 (PST) Received: by lbblt2 with SMTP id lt2so43559653lbb.3 for ; Wed, 09 Dec 2015 21:57:04 -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:date:message-id:subject :from:to:cc:content-type; bh=yr8ZubH4k0E3EPnKe3mRx1H6SAYUTegZPYbVqUqhddM=; b=ToSOpxMN5Rp5QtzTdXPnInDeWxSODJg+XFwjeiMh+9svFAQxsBAMYyVOwJ50dJDN1B +Yhxi6pSfT5jbVk5zP4f2rXvnEHIncn6zO6QUp25mAtZsLT8Ecwu5chmy0m5Rt3/qxNT YTEEMJwjD/MOCjIoKZxgPcbRs+SpnEGv05bUrQ3Jwwsh7rNQbEBm3hRgd64rYwOdypNd Sbf7x/JPABAwH0cSjGvsg7qbJDOUE8N5YfiupxcbRtgDSahp65+dzyiplNjnzhS2SQ1/ UZjC8dgkeMFJV9RMxThSFKzq5D8gcbul3ulIDr8R3ZqRJ7vo6JEgDzfSBBptg4Yfo6qO wfsQ== MIME-Version: 1.0 X-Received: by 10.112.16.135 with SMTP id g7mr4538499lbd.80.1449727024258; Wed, 09 Dec 2015 21:57:04 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Wed, 9 Dec 2015 21:57:04 -0800 (PST) In-Reply-To: <2F153E13-AD63-4535-BC3A-D93C8E681C99@gmail.com> References: <2F153E13-AD63-4535-BC3A-D93C8E681C99@gmail.com> Date: Thu, 10 Dec 2015 00:57:04 -0500 X-Google-Sender-Auth: zruANmCsvirfJldrNHT4wO5LMpQ Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c3c7784d6466052684e0b3 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 05:57:08 -0000 --001a11c3c7784d6466052684e0b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 9, 2015 at 11:50 PM, Yoav Nir wrote: > Hi, Phil > > Not against this, but consider that SHA3 has been available for a while, > and I haven=E2=80=99t heard of any IETF group beginning work on standardi= zing it. > Compare and contrast with Curve25519, ChaCha20/Poly1305 and EdDSA that ha= d > and have drafts in several working groups even before the final documents > were published. > The standard was only published on 15th August 2015. And even though everyone knew what it was going to say, we could hardly begin a standards effort until the FIPS was published. > The only group that is considering SHA3 is CFRG (for EdDSA-448). I have > heard some people on other lists expressing a preference to ignore SHA3 a= nd > standardize instead on Blake2 as the hot spare or even the primary. > I can't see that flying. Blake was an entrant in the SHA3 competition. Blake2 has only been published 3 years and has not received anything like the attention the competition entries did. It hasn't even received as much attention as Blake. I don=E2=80=99t think the ADs want Curdle to shove a hot spare down into a = bunch of > protocols, especially when there are active working groups for these > protocols (such as TLS or IPsecME). > As I pointed out when CFRG was asked to pick curves 'for TLS', these would inevitably become the defaults for everything else. There isn't exactly a high bar for adding suites to either TLS or IPSEC. I am a simple soul. I don't get into hypotheticals about what decisions a WG might make. If someone wants to make the case that their application is so special it should not be able to use the same crypto suite as pretty much everything else then let them say so and give their reasons in public. >From a process point of view, I expect that what is going to happen is that work will begin in CURDLE on the applications that don't have a current WG and then people involved in CURDLE are going to propose whatever is necessary to the WGs that do exist to align things nicely. --001a11c3c7784d6466052684e0b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 9, 2015 at 11:50 PM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:
Hi, Phil

Not against this, but consider that SHA3 has been available for a while, an= d I haven=E2=80=99t heard of any IETF group beginning work on standardizing= it. Compare and contrast with Curve25519, ChaCha20/Poly1305 and EdDSA that= had and have drafts in several working groups even before the final docume= nts were published.

The standard was on= ly published on 15th August 2015. And even though everyone knew what it was= going to say, we could hardly begin a standards effort until the FIPS was = published.

=C2=A0
The only group that is considering SHA3 is CFRG (for EdDSA-448). I have hea= rd some people on other lists expressing a preference to ignore SHA3 and st= andardize instead on Blake2 as the hot spare or even the primary.

I can't see that flying. Blake was an entran= t in the SHA3 competition. Blake2 has only been published 3 years and has n= ot received anything like the attention the competition entries did. It has= n't even received as much attention as Blake.

=
I don=E2=80=99t think the ADs want Curdle to shove a hot spare down into a = bunch of protocols, especially when there are active working groups for the= se protocols (such as TLS or IPsecME).

= As I pointed out when CFRG was asked to pick curves 'for TLS', thes= e would inevitably become the defaults for everything else. There isn't= exactly a high bar for adding suites to either TLS or IPSEC.=C2=A0

I am a simple soul. I don't get into hypotheticals ab= out what decisions a WG might make. If someone wants to make the case that = their application is so special it should not be able to use the same crypt= o suite as pretty much everything else then let them say so and give their = reasons in public.

From a p= rocess point of view, I expect that what is going to happen is that work wi= ll begin in CURDLE on the applications that don't have a current WG and= then people involved in CURDLE are going to propose whatever is necessary = to the WGs that do exist to align things nicely.

--001a11c3c7784d6466052684e0b3-- From nobody Thu Dec 10 01:43:29 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF811A873B for ; Thu, 10 Dec 2015 01:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMSDBfWf_YPc for ; Thu, 10 Dec 2015 01:43:26 -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 27F951A8863 for ; Thu, 10 Dec 2015 01:43:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CB62CBE54 for ; Thu, 10 Dec 2015 09:43:24 +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 OCbkV4qoUY0d for ; Thu, 10 Dec 2015 09:43:23 +0000 (GMT) Received: from [10.0.10.19] (unknown [212.76.224.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A2CDBE64 for ; Thu, 10 Dec 2015 09:43:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449740603; bh=jWmhiB9J2dlhE2H/Ku5j1ZI1AUb7X8M142QJX1ASxWI=; h=From:Subject:To:References:Date:In-Reply-To:From; b=iKRXA2gSiDHVhOKd0OzrxPqg38VNJEbLvdc7PurcdjVemppgCAGecUX95FOzBC5Fm 0ZOvFoh3yGEeiIGbu2FeOjgaE4Q75wpm1b9EoG6oYIvIxU7G0hCnUpakD9CB/+hJpl SwWJVoTPJ/PU/u6zh12zTXC0hNHq/AoD7wOVHkZE= From: Stephen Farrell To: curdle@ietf.org References: <56694845.4000102@cs.tcd.ie> Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5669493A.3050401@cs.tcd.ie> Date: Thu, 10 Dec 2015 09:43:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56694845.4000102@cs.tcd.ie> Content-Type: multipart/mixed; boundary="------------090604050607080007060308" Archived-At: Subject: [Curdle] Fwd: Re: [saag] [DNSOP] code points for brainpool curves for DNSSEC X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 09:43:28 -0000 This is a multi-part message in MIME format. --------------090604050607080007060308 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit FYI. Please continue to follow up on the saag list for now so the discussion (if more is needed) is in one place. (And thanks for doing that so far.) S. -------- Forwarded Message -------- Subject: Re: [saag] [DNSOP] code points for brainpool curves for DNSSEC Date: Thu, 10 Dec 2015 09:39:17 +0000 From: Stephen Farrell To: saag@ietf.org Thanks all, that's sufficient feedback for me to propose to the IESG that we return a "potentially disrupts, so please do not publish now" 5742 response so I have proposed that to the IESG. Additional discussion of reasons to not do this allocation now may therefore be redundant. Discussion of what to do in future is still welcome, and if that doesn't happen I at least will raise the issue on the list for the in-formation curdle WG. [1] The text I've proposed is at [2], feel free to suggest edits, but that can be done offlist. Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ [2] https://datatracker.ietf.org/doc/conflict-review-schmidt-brainpool-dnssec/ On 10/12/15 09:15, Patrik Fältström wrote: > I have nothing to add to what Ólafur wrote below. I agree with his statement. > > Patrik > > On 10 Dec 2015, at 1:33, Ólafur Guðmundsson wrote: > >> Stephen, >> >> Sorry for being so blunt below. >> >> The document totally content free as to why this makes any sense in an operational context. >> DNSSEC algorithms should not be given out lightly as there is a significant COST to deploy support for each additional algorithm. >> >> While I strongly support having better ECC algorithm that the currently specified curves, adding a new ones SHOULD take place via a performance oriented process. >> Thus I strongly advocate that this publication be held up until we can compare this curve with other curves being proposed. >> >> Background I'm currently fighting an multifaceted battle to have various entities adding support for ECDSAP256, specified over 3 years ago. >> >> Adding and deploying a new DNSKEY algorithm does not just require changes to >> -- DNS servers, libraries and resolvers. >> >> That is just the top of the iceberg, but also to >> - DNS provisioning systems, DNSSEC signing systems, DNS testing tools, - user interfaces for registrars, hosting providers, third party DNS operators, CDN's, etc. >> - TLD and ccTLD policy documents, EPP implementations, plus in some cases security evaluations, >> - not to mention firewalls, network monitoring tools .... >> and number of other things I had no idea existed and majority of which is not maintained anymore. >> >> There are only so many times that one can get everyone's attention to upgrade DNS stuff, thus requiring the change process to be run should not be taken lightly. >> If on the other hand if the editors are only interested in vanity algorithm assignment without any deployment then ........... >> >> Olafur >> >> >> On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell >> wrote: >> >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: code points for brainpool curves for DNSSEC >>> Date: Wed, 9 Dec 2015 18:00:18 +0000 >>> From: Stephen Farrell >>> To: saag@ietf.org >>> >>> >>> Hiya, >>> >>> The brainpool folks have written an I-D [1] that they are pushing >>> through the rfc editor's independent stream. [2] >>> >>> That I-D wants to register code points for using their curves for >>> DNSSEC. >>> >>> For documents that come through the independent stream, the IESG >>> does an RFC 5742 [3] conflict review. The purpose of that review >>> is to check that the RFC doesn't conflict with ongoing work in >>> the IETF. >>> >>> If you have thoughts on this, please let me know before Dec 17th. >>> I'll forward this to the dnsop, cfrg and curdle mailing lists >>> to check there too. Apologies if you get >1 copy of this. Please >>> try follow up on the saag list if you can. >>> >>> Thanks, >>> Stephen. >>> >>> >>> [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec >>> [2] https://www.rfc-editor.org/pubprocess/ >>> [3] https://tools.ietf.org/html/rfc5742 >>> >>> >>> >>> _______________________________________________ >>> 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 --------------090604050607080007060308 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBt YWlsaW5nIGxpc3QKc2FhZ0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NhYWcKCg== --------------090604050607080007060308-- From nobody Thu Dec 10 01:46:38 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159F41A8873 for ; Thu, 10 Dec 2015 01:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2-A7uL_NDlC for ; Thu, 10 Dec 2015 01:46:33 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949601A887D for ; Thu, 10 Dec 2015 01:46:32 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-54-566949f6c6a2 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4C.A2.04914.6F949665; Thu, 10 Dec 2015 10:46:30 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.72]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Thu, 10 Dec 2015 10:46:29 +0100 From: John Mattsson To: Phillip Hallam-Baker , "curdle@ietf.org" Thread-Topic: [Curdle] SHA3 should be in scope. Thread-Index: AQHRMwJKi627BQYvcUmiMbCdPvC7757D+UEA Date: Thu, 10 Dec 2015 09:46:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_D28F008642096johnmattssonericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2J7lO43z8wwgwfLZSy2LpzFbDHxw2xG ByaPC6u/MnksWfKTKYApissmJTUnsyy1SN8ugSvj6O01TAV7/jJXvOhcwtLAOPcDcxcjJ4eE gIlEz56zULaYxIV769m6GLk4hAQOM0o8a//GCuEsZpTo2neaFaSKTcBAYu6eBjYQW0QgXKJz 6gJGEFtYQE9iwsZzLBBxfYmrKy6zQthGEss3rQazWQRUJaZNeA7Uy8HBK2AuMXuaGUhYSCBA YvaGz+wgNqdAoMSubS/ADmIEOuj7qTVMIDazgLjErSfzmSAOFZBYsuc81NGiEi8f/wMbLwp0 wsFPK1kh4koSi25/huqNkThy+AhYPa+AoMTJmU9YJjCKzkIydhaSsllIymYBXcosoCmxfpc+ RImixJTuh+wQtoZE65y5ULa1xORfS1iR1Sxg5FjFKFqcWlycm25krJdalJlcXJyfp5eXWrKJ ERiJB7f81t3BuPq14yFGAQ5GJR7eD0qZYUKsiWXFlbmHGCU4mJVEeNe4AYV4UxIrq1KL8uOL SnNSiw8xSnOwKInztjA9CBUSSE8sSc1OTS1ILYLJMnFwSjUwxnqX/539ff9s263TGHgfJ5yb YlfBJby+/FO0TZH4ehHjptCpJtfPbNYKXOT+aNY2k/dfNT9uOnDhj4WA4pRtxk871x7oYss/ aXJnLteq/e26Zvt75LllzS9Ee2yaEb5dL+j2X+52cWZFL9tlHPPjFVr02RSLzkzxnjE1JEDr niGXs2ZPzppTSizFGYmGWsxFxYkAMMmMF8ACAAA= Archived-At: Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 09:46:36 -0000 --_000_D28F008642096johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGRvaW5nIFNIQS0zIGluIENVUkRMRSBmb3IgdGhlIHJlYXNvbnMgYWxyZWFkeSBs YWlkIGRvd24gYnkgUGhpbGxpcC4gU3RyaXZpbmcgZm9yIDIgZGlmZmVyZW50IGhhc2ggYWxnb3Jp dGhtcyBtYWtlIHZlcnkgbXVjaCBzZW5zZS4gSGlzdG9yaWNhbGx5IG5vdCBvbmx5IGltcGxlbWVu dGVycyBidXQgYWxzbyBTRE9zIGhhdmUgYmVlbiBmYXIgdG9vIHNsb3cgdG8gYWRvcHQgbmV3IGFs Z29yaXRobXMuDQoNClNIQS0zIGlzIGFuIGV4Y2VsbGVudCBjaG9pY2UgYXMgaXQgaGFzIGEgdmVy eSBkaWZmZXJlbnQgY29uc3RydWN0aW9uIGZyb20gU0hBLTIuIEl0IGlzIGFscmVhZHkgdXNlZCBp biBvdGhlciBzdGFuZGFyZHMgYXMgRVRTSSBTQUdFIGNob3NlIGlmIGFzIHRoZSBiYXNpcyBmb3Ig dGhlIG5ldyBhdXRoZW50aWNhdGlvbiBhbmQga2V5IGdlbmVyYXRpb24gc2V0IFRVQUsuDQoNCldl IHNob3VsZCBub3QgZW5kIHVwIGluIGEgc2l0dWF0aW9uIHdoZXJlIHdlIGRvIG5vdCBldmVuIHRo aW5rIGFib3V0IGFkZGluZyBTSEEtMyB0byBwcm90b2NvbHMgYmVmb3JlIGFueSBTSEEtMiBjb21w cm9taXNlcyBhcmUgYW5ub3VuY2VkLg0KDQovSm9obg0KDQpGcm9tOiBDdXJkbGUgPGN1cmRsZS1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFs ZiBvZiBQaGlsbGlwIEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFrZXIuY29tPG1haWx0bzpw aGlsbEBoYWxsYW1iYWtlci5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTAgRGVjZW1iZXIgMjAxNSAw NToyMQ0KVG86ICJjdXJkbGVAaWV0Zi5vcmc8bWFpbHRvOmN1cmRsZUBpZXRmLm9yZz4iIDxjdXJk bGVAaWV0Zi5vcmc8bWFpbHRvOmN1cmRsZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbQ3VyZGxlXSBT SEEzIHNob3VsZCBiZSBpbiBzY29wZS4NCg0KV2hldGhlciBvciBub3Qgd2UgZGVjaWRlIHdlIHNo b3VsZCBiZSB1c2luZyBTSEEyIG9yIFNIQTMgYWNyb3NzIHRoZSBib2FyZCwgd2Ugc2hvdWxkIG1h a2Ugc3VyZSBldmVyeSBhcHBsaWNhdGlvbiBzdXBwb3J0cyBib3RoOg0KDQoqIFRoZSBhZGRpdGlv bmFsIGVmZm9ydCBvZiBkb2luZyBTSEEzIGluIENVUkRMRSBpcyBtaW5pbWFsLg0KDQoqIElmIHdl IGRvbid0IGRvIFNIQTMgaW4gQ1VSRExFLCBwZW9wbGUgd2lsbCB3cml0ZSBhIHNlcmllcyBvZiBz ZXBhcmF0ZSBkcmFmdHMuIFRoaXMgd2lsbCBiZSBtb3JlIHdvcmsgZm9yIHRoZSBTZWN1cml0eSBB RCwgSUVTRywgSUFOQSBhbmQgdGhlIFJGQyBFZGl0b3IgYW5kIHRoZSByZXN1bHQgaXMgbm90IGxp a2VseSB0byBiZSBhcyBjb25zaXN0ZW50IG9yIGFzIGdvb2QuDQoNCiogV2Ugc2hvdWxkIGFpbSB0 byBoYXZlIGV4YWN0bHkgdHdvIGFsZ29yaXRobXMgZm9yIGVhY2ggY3J5cHRvZ3JhcGhpYyBwcmlt aXRpdmUuIEEgcHJlZmVycmVkIGFsZ29yaXRobXMgdGhhdCBhcHBsaWNhdGlvbnMgY2FuIGV4cGVj dCB0byBiZSBzdXBwb3J0ZWQgYW5kIGEgJ2hvdCBzcGFyZScgdGhhdCBhcHBsaWNhdGlvbnMgc2hv dWxkIGltcGxlbWVudCB3aGVyZXZlciBwb3NzaWJsZSBpbiBjYXNlIG9mIG5lZWQuIFRoZSBob3Qg c3BhcmUgc2hvdWxkIGlkZWFsbHkgYmUgYmFzZWQgb24gYSBkaWZmZXJlbnQgcHJpbmNpcGxlIHRv IHRoZSBwcmVmZXJyZWQuDQoNClJpZ2h0IG5vdyBTSEEyIGlzIHRoZSBwcmVmZXJyZWQgZGlnZXN0 IGZ1bmN0aW9uIGFuZCBJIGRvbid0IGV4cGVjdCB0aGF0IHRvIGNoYW5nZS4gQnV0IHRoZSBTSEEx LT5TSEEyIHRyYW5zaXRpb24gd2FzIGEgbG90IGhhcmRlciB0aGFuIGl0IHNob3VsZCBoYXZlIGJl ZW4gYW5kIGxlZnQgYSBsb3QgbW9yZSBicm9rZW4gZ2VhciB0aGFuIHRoZSBNRDUtPlNIQTEgdHJh bnNpdGlvbi4gVGhlIGRpZmZlcmVuY2Ugd2FzIHRoYXQgZm9yIE1ENSB3ZSBoYWQgYSBob3Qgc3Bh cmUgYnV0IGEgbG90IG9mIHZlbmRvcnMgZGlkbid0IGV2ZW4gc3RhcnQgdG8gdGhpbmsgYWJvdXQg aW1wbGVtZW50aW5nIFNIQTIgdW50aWwgdGhlIGZpcnN0IGNvbXByb21pc2Ugb2YgU0hBMSB3YXMg YW5ub3VuY2VkLg0KDQoNCkkgZG8gbm90IHNlZSB0aGlzIGFzIGEgc2xpcHBlcnkgc2xvcGUgYXMg dGhlIHByaW1hcnkgYW5kIGhvdC1zcGFyZSBzbG90cyBmb3IgZXZlcnkgb3RoZXIgYWxnb3JpdGht IGFyZSBhbHJlYWR5IGZpbGxlZC4gRm9yIHB1YmxpYyBrZXkgd2UgaGF2ZSBSU0EgYW5kIHRoZSBD RlJHLUVDQyBzY2hlbWVzLiBGb3Igc3ltbWV0cmljIGVuY3J5cHRpb24gd2UgaGF2ZSBBRVMgYW5k IENIQS1DSEEyMC4gVGhpcyBpcyBqdXN0IHJvdW5kaW5nIHRoaW5ncyBvdXQgZm9yIGRpZ2VzdCBm dW5jdGlvbnMgc28gd2UgaGF2ZSB0d28gb3B0aW9ucyB0aGVyZS4NCg0KUlNBIGlzIGdvaW5nIHRv IGJlIHRoZSBwcmVmZXJyZWQgYWxnb3JpdGhtIHVudGlsIHRoZSBDRlJHIHdvcmsgaXMgY29tcGxl dGUgYW5kIGhhcyBzZWVuIHNpZ25pZmljYW50IGRlcGxveW1lbnQuIFRoYXQgaXMgc3RpbGwgYXQg bGVhc3QgNSB5ZWFycyBvZmYgd2hpY2ggaXMgYSBwaXR5IGJlY2F1c2UgaXQgaXMgY3V0dGluZyBp dCBhd2Z1bGx5IGNsb3NlLiBNeSBleHBlY3RhdGlvbiBpcyB0aGF0IGFzIHNvb24gYXMgQ0ZSRyBp cyBkb25lIHdpdGggdGhlIEVDQyBjdXJ2ZSB3b3JrLCB0aGUgbmV4dCBmb2N1cyBvZiBhdHRlbnRp b24gd2lsbCBiZSBwdWJsaWMga2V5IHN5c3RlbXMgdGhhdCBhcmUgcXVhbnR1bSByZXNpc3RhbnQs IChpZiB3ZSBjYW4gY29udmluY2Ugb3Vyc2VsdmVzIHN1Y2ggc2NoZW1lcyBhY3R1YWxseSBleGlz dCkuDQoNClNvIGJ5IHRoZSB0aW1lIHdlIGFyZSBwaGFzaW5nIFJTQSBvdXQsIEkgZXhwZWN0IHRo YXQgd2Ugd2lsbCBiZSBsb29raW5nIGF0IGFsZ29yaXRobXMgdGhhdCBoYXZlIG5vdCBiZWVuIGlu dmVudGVkIHlldCB0byByZXBsYWNlIGl0LiBBZGRpbmcgU0hBMyB0byBDVVJETEUgaXMgbm90IGEg c2xpcHBlcnkgc2xvcGUuDQoNCg== --_000_D28F008642096johnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlRpdGxlIiBjb250ZW50PSIi Pg0KPG1ldGEgbmFtZT0iS2V5d29yZHMiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJQcm9nSWQi IGNvbnRlbnQ9IldvcmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNCI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iZmlsZTovL2xv Y2FsaG9zdC9Vc2Vycy9lbWFuam9uL0xpYnJhcnkvQ2FjaGVzL1RlbXBvcmFyeUl0ZW1zL21zb2Ns aXAvMC9jbGlwX2ZpbGVsaXN0LnhtbCI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86RG9j dW1lbnRQcm9wZXJ0aWVzPg0KICA8bzpSZXZpc2lvbj4wPC9vOlJldmlzaW9uPg0KICA8bzpUb3Rh bFRpbWU+MDwvbzpUb3RhbFRpbWU+DQogIDxvOlBhZ2VzPjE8L286UGFnZXM+DQogIDxvOldvcmRz PjY3PC9vOldvcmRzPg0KICA8bzpDaGFyYWN0ZXJzPjM4MjwvbzpDaGFyYWN0ZXJzPg0KICA8bzpD b21wYW55PkVyaWNzc29uIEFCPC9vOkNvbXBhbnk+DQogIDxvOkxpbmVzPjM8L286TGluZXM+DQog IDxvOlBhcmFncmFwaHM+MTwvbzpQYXJhZ3JhcGhzPg0KICA8bzpDaGFyYWN0ZXJzV2l0aFNwYWNl cz40NDg8L286Q2hhcmFjdGVyc1dpdGhTcGFjZXM+DQogIDxvOlZlcnNpb24+MTQuMDwvbzpWZXJz aW9uPg0KIDwvbzpEb2N1bWVudFByb3BlcnRpZXM+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5n cz4NCiAgPG86QWxsb3dQTkcvPg0KIDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+ PCFbZW5kaWZdLS0+PGxpbmsgcmVsPSJ0aGVtZURhdGEiIGhyZWY9ImZpbGU6Ly9sb2NhbGhvc3Qv VXNlcnMvZW1hbmpvbi9MaWJyYXJ5L0NhY2hlcy9UZW1wb3JhcnlJdGVtcy9tc29jbGlwLzAvY2xp cF90aGVtZWRhdGEueG1sIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1l bnQ+DQogIDx3OlZpZXc+Tm9ybWFsPC93OlZpZXc+DQogIDx3Olpvb20+MDwvdzpab29tPg0KICA8 dzpUcmFja01vdmVzLz4NCiAgPHc6VHJhY2tGb3JtYXR0aW5nLz4NCiAgPHc6UHVuY3R1YXRpb25L ZXJuaW5nLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQogIDx3OlNhdmVJZlhNTElu dmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCiAgPHc6SWdub3JlTWl4ZWRDb250ZW50 PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCiAgPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVy VGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KICA8dzpEb05vdFByb21v dGVRRi8+DQogIDx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCiAgPHc6 TGlkVGhlbWVBc2lhbj5KQTwvdzpMaWRUaGVtZUFzaWFuPg0KICA8dzpMaWRUaGVtZUNvbXBsZXhT Y3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCiAgPHc6Q29tcGF0aWJpbGl0 eT4NCiAgIDx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQogICA8dzpTbmFwVG9HcmlkSW5DZWxsLz4N CiAgIDx3OldyYXBUZXh0V2l0aFB1bmN0Lz4NCiAgIDx3OlVzZUFzaWFuQnJlYWtSdWxlcy8+DQog ICA8dzpEb250R3Jvd0F1dG9maXQvPg0KICAgPHc6U3BsaXRQZ0JyZWFrQW5kUGFyYU1hcmsvPg0K ICAgPHc6RW5hYmxlT3BlblR5cGVLZXJuaW5nLz4NCiAgIDx3OkRvbnRGbGlwTWlycm9ySW5kZW50 cy8+DQogICA8dzpPdmVycmlkZVRhYmxlU3R5bGVIcHMvPg0KICAgPHc6VXNlRkVMYXlvdXQvPg0K ICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPG06bWF0aFByPg0KICAgPG06bWF0aEZvbnQgbTp2YWw9 IkNhbWJyaWEgTWF0aCIvPg0KICAgPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCiAgIDxtOmJy a0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQogICA8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0K ICAgPG06ZGlzcERlZi8+DQogICA8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQogICA8bTpyTWFyZ2lu IG06dmFsPSIwIi8+DQogICA8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCiAgIDxtOndy YXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCiAgIDxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQog ICA8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCiAgPC9tOm1hdGhQcj48L3c6V29yZERvY3Vt ZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6TGF0 ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUi DQogIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0i OTkiDQogIExhdGVudFN0eWxlQ291bnQ9IjI3NiI+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDMiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5 IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJoZWFkaW5nIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzOSIgTmFtZT0idG9jIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDQiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDYiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDci Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0i dG9jIDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBOYW1lPSJEZWZhdWx0IFBhcmFn cmFwaCBGb250Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjIyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJQ bGFjZWhvbGRlciBUZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFG b3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlz dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwg U2hhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQg MSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM0IiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQ YXJhZ3JhcGgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIy OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IlF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2Vu dCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNj ZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj ZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwg R3JpZCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQg MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB Y2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlk IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJM aWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2Vu dCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAzIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNj ZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IFNoYWRpbmcgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIg QWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDMgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQg NSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hh ZGluZyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl bnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBB Y2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcw IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFy ayBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTkiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJTdWJ0bGUgRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIyMSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVu Y2UiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzciIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KIDwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtl bmRpZl0tLT48c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToi77yt77yzIOaYjuacnSI7DQoJbXNvLWZvbnQtY2hhcnNldDo3ODsN Cgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxl Ow0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDE3OTE0OTE1NzkgMTggMCAxMzEyMzEg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmlj LWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQt c2lnbmF0dXJlOi01MzY4NzAxNDUgMTEwNzMwNTcyNyAwIDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0K CW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1z by1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDkyOTI5IDEw NzM3ODYxMTEgOSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0K CW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDEwNzM3NDMxMDMgMCAwIDQxNSAwO30NCiAv KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsN Cgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJ bXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Iu+8re+8syDmmI7mnJ0iOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItZmFyZWFz dDsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FtYnJpYTsNCgltc28taGFuc2ktdGhlbWUtZm9u dDptaW5vci1sYXRpbjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsN Cgltc28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJpZGk7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQt ZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFz Y2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Iu+8 re+8syDmmI7mnJ0iOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItZmFyZWFzdDsNCglt c28taGFuc2ktZm9udC1mYW1pbHk6Q2FtYnJpYTsNCgltc28taGFuc2ktdGhlbWUtZm9udDptaW5v ci1sYXRpbjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28t YmlkaS10aGVtZS1mb250Om1pbm9yLWJpZGk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7DQoJ bXNvLWhlYWRlci1tYXJnaW46MzUuNHB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjM1LjRwdDsNCglt c28tcGFwZXItc291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6 IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxl LWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowY20gNS40 cHQgMGNtIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowY207DQoJbXNvLXBhcmEtbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNh bWJyaWE7DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWhhbnNpLWZv bnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWhhbnNpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47fQ0K PC9zdHlsZT4NCjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2PjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOkRvY3VtZW50UHJvcGVydGllcz4NCiAgPG86UmV2aXNpb24+MDwvbzpS ZXZpc2lvbj4NCiAgPG86VG90YWxUaW1lPjA8L286VG90YWxUaW1lPg0KICA8bzpQYWdlcz4xPC9v OlBhZ2VzPg0KICA8bzpXb3Jkcz42NzwvbzpXb3Jkcz4NCiAgPG86Q2hhcmFjdGVycz4zODI8L286 Q2hhcmFjdGVycz4NCiAgPG86Q29tcGFueT5Fcmljc3NvbiBBQjwvbzpDb21wYW55Pg0KICA8bzpM aW5lcz4zPC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjE8L286UGFyYWdyYXBocz4NCiAgPG86 Q2hhcmFjdGVyc1dpdGhTcGFjZXM+NDQ4PC9vOkNoYXJhY3RlcnNXaXRoU3BhY2VzPg0KICA8bzpW ZXJzaW9uPjE0LjA8L286VmVyc2lvbj4NCiA8L286RG9jdW1lbnRQcm9wZXJ0aWVzPg0KIDxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQogIDxvOkFsbG93UE5HLz4NCiA8L286T2ZmaWNlRG9jdW1l bnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDx3OldvcmREb2N1bWVudD4NCiAgPHc6Vmlldz5Ob3JtYWw8L3c6Vmlldz4NCiAgPHc6Wm9vbT4w PC93Olpvb20+DQogIDx3OlRyYWNrTW92ZXMvPg0KICA8dzpUcmFja0Zvcm1hdHRpbmcvPg0KICA8 dzpQdW5jdHVhdGlvbktlcm5pbmcvPg0KICA8dzpWYWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCiAg PHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KICA8dzpJZ25v cmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250ZW50Pg0KICA8dzpBbHdheXNT aG93UGxhY2Vob2xkZXJUZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQog IDx3OkRvTm90UHJvbW90ZVFGLz4NCiAgPHc6TGlkVGhlbWVPdGhlcj5FTi1VUzwvdzpMaWRUaGVt ZU90aGVyPg0KICA8dzpMaWRUaGVtZUFzaWFuPkpBPC93OkxpZFRoZW1lQXNpYW4+DQogIDx3Okxp ZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KICA8 dzpDb21wYXRpYmlsaXR5Pg0KICAgPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCiAgIDx3OlNuYXBU b0dyaWRJbkNlbGwvPg0KICAgPHc6V3JhcFRleHRXaXRoUHVuY3QvPg0KICAgPHc6VXNlQXNpYW5C cmVha1J1bGVzLz4NCiAgIDx3OkRvbnRHcm93QXV0b2ZpdC8+DQogICA8dzpTcGxpdFBnQnJlYWtB bmRQYXJhTWFyay8+DQogICA8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KICAgPHc6RG9udEZs aXBNaXJyb3JJbmRlbnRzLz4NCiAgIDx3Ok92ZXJyaWRlVGFibGVTdHlsZUhwcy8+DQogICA8dzpV c2VGRUxheW91dC8+DQogIDwvdzpDb21wYXRpYmlsaXR5Pg0KICA8bTptYXRoUHI+DQogICA8bTpt YXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQogICA8bTpicmtCaW4gbTp2YWw9ImJlZm9y ZSIvPg0KICAgPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCiAgIDxtOnNtYWxsRnJhYyBt OnZhbD0ib2ZmIi8+DQogICA8bTpkaXNwRGVmLz4NCiAgIDxtOmxNYXJnaW4gbTp2YWw9IjAiLz4N CiAgIDxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCiAgIDxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91 cCIvPg0KICAgPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KICAgPG06aW50TGltIG06dmFs PSJzdWJTdXAiLz4NCiAgIDxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KICA8L206bWF0aFBy PjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVX aGVuVXNlZD0idHJ1ZSINCiAgRGVmU2VtaUhpZGRlbj0idHJ1ZSIgRGVmUUZvcm1hdD0iZmFsc2Ui IERlZlByaW9yaXR5PSI5OSINCiAgTGF0ZW50U3R5bGVDb3VudD0iMjc2Ij4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFsIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijki IFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNyIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgOCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2Mg NSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBOYW1lPSJ0b2MgNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgOCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM1IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRs ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIE5hbWU9 IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhh c2lzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJUYWJsZSBH cmlkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExp c3QgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iRGFyayBMaXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAx Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlJldmlz aW9uIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzQiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjI5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUXVvdGUiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNj ZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBB Y2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2Nl bnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2Vu dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAzIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAz Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAx IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDMi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDQiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNj ZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBB Y2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcz IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgR3JpZCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg NSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMiBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA1Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2Vu dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBHcmlkIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu dCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAy IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdy aWQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIxOSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3Jt YXQ9InRydWUiIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMxIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i U3VidGxlIFJlZmVyZW5jZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjMyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgTmFtZT0iQmli bGlvZ3JhcGh5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQogPC93OkxhdGVudFN0eWxl cz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyAxMF0+DQo8c3R5bGU+DQogLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1u YW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRz dHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGNt IDUuNHB0IDBjbSA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGNtOw0KCW1zby1wYXJhLW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseTpDYW1icmlhOw0KCW1zby1hc2NpaS1mb250LWZhbWls eTpDYW1icmlhOw0KCW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTpDYW1icmlhOw0KCW1zby1oYW5zaS10aGVtZS1mb250Om1pbm9yLWxhdGlu O30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48IS0tU3RhcnRGcmFnbWVudC0tPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGZvbnQgc2l6 ZT0iMyI+SSBzdXBwb3J0IGRvaW5nIFNIQS0zIGluIENVUkRMRSBmb3IgdGhlIHJlYXNvbnMgYWxy ZWFkeSBsYWlkIGRvd24gYnkgUGhpbGxpcC4gU3RyaXZpbmcgZm9yIDIgZGlmZmVyZW50IGhhc2gg YWxnb3JpdGhtcyBtYWtlIHZlcnkgbXVjaCBzZW5zZS4gSGlzdG9yaWNhbGx5IG5vdCBvbmx5IGlt cGxlbWVudGVycyBidXQgYWxzbw0KIFNET3MgaGF2ZSBiZWVuIGZhciB0b28gc2xvdyB0byBhZG9w dCBuZXcgYWxnb3JpdGhtcy48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGZvbnQgc2l6 ZT0iMyI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij48Zm9udCBzaXplPSIzIj5TSEEtMyBpcyBh biBleGNlbGxlbnQgY2hvaWNlIGFzIGl0IGhhcyBhIHZlcnkgZGlmZmVyZW50IGNvbnN0cnVjdGlv biBmcm9tIFNIQS0yLiBJdCBpcyBhbHJlYWR5IHVzZWQgaW4gb3RoZXIgc3RhbmRhcmRzIGFzIEVU U0kgU0FHRSBjaG9zZSBpZiBhcyB0aGUgYmFzaXMgZm9yIHRoZSBuZXcmbmJzcDthdXRoZW50aWNh dGlvbiBhbmQNCiBrZXkgZ2VuZXJhdGlvbiBzZXQgVFVBSy48bzpwPjwvbzpwPjwvZm9udD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpOyI+PGZvbnQgc2l6ZT0iMyI+PGJyPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7Ij48Zm9udCBz aXplPSIzIj5XZSBzaG91bGQgbm90IGVuZCB1cCBpbiBhIHNpdHVhdGlvbiB3aGVyZSB3ZSBkbyBu b3QgZXZlbiB0aGluayBhYm91dCBhZGRpbmcgU0hBLTMgdG8gcHJvdG9jb2xzIGJlZm9yZSBhbnkg U0hBLTIgY29tcHJvbWlzZXMgYXJlIGFubm91bmNlZC48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsiPjxmb250IHNpemU9IjMiPi9Kb2huPC9mb250Pjwv c3Bhbj48Zm9udCBzaXplPSIzIj48bzpwPjwvbzpwPjwvZm9udD48L3A+DQo8IS0tRW5kRnJhZ21l bnQtLT48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPjxicj4NCjwvZGl2Pg0K PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1h bGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRF Ui1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAw aW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJP UkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5DdXJkbGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZyI+Y3VyZGxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OyBvbiBiZWhhbGYgb2YgUGhpbGxpcCBIYWxsYW0tQmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsbEBoYWxsYW1iYWtlci5jb20iPnBoaWxsQGhhbGxhbWJha2VyLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSAxMCBE ZWNlbWJlciAyMDE1IDA1OjIxPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmN1cmRsZUBpZXRmLm9yZyI+Y3VyZGxlQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmN1cmRsZUBpZXRmLm9yZyI+Y3Vy ZGxlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U3ViamVjdDogPC9zcGFuPltDdXJkbGVdIFNIQTMgc2hvdWxkIGJlIGluIHNjb3BlLjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+V2hl dGhlciBvciBub3Qgd2UgZGVjaWRlIHdlIHNob3VsZCBiZSB1c2luZyBTSEEyIG9yIFNIQTMgYWNy b3NzIHRoZSBib2FyZCwgd2Ugc2hvdWxkIG1ha2Ugc3VyZSBldmVyeSBhcHBsaWNhdGlvbiBzdXBw b3J0cyBib3RoOg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+KiBUaGUgYWRkaXRpb25hbCBlZmZv cnQgb2YgZG9pbmcgU0hBMyBpbiBDVVJETEUgaXMgbWluaW1hbC48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PiogSWYgd2UgZG9uJ3QgZG8gU0hBMyBpbiBDVVJETEUsIHBlb3BsZSB3aWxs IHdyaXRlIGEgc2VyaWVzIG9mIHNlcGFyYXRlIGRyYWZ0cy4gVGhpcyB3aWxsIGJlIG1vcmUgd29y ayBmb3IgdGhlIFNlY3VyaXR5IEFELCBJRVNHLCBJQU5BIGFuZCB0aGUgUkZDIEVkaXRvciBhbmQg dGhlIHJlc3VsdCBpcyBub3QgbGlrZWx5IHRvIGJlIGFzIGNvbnNpc3RlbnQgb3IgYXMgZ29vZC48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiogV2Ugc2hvdWxkIGFpbSB0byBoYXZlIGV4 YWN0bHkgdHdvIGFsZ29yaXRobXMgZm9yIGVhY2ggY3J5cHRvZ3JhcGhpYyBwcmltaXRpdmUuIEEg cHJlZmVycmVkIGFsZ29yaXRobXMgdGhhdCBhcHBsaWNhdGlvbnMgY2FuIGV4cGVjdCB0byBiZSBz dXBwb3J0ZWQgYW5kIGEgJ2hvdCBzcGFyZScgdGhhdCBhcHBsaWNhdGlvbnMgc2hvdWxkIGltcGxl bWVudCB3aGVyZXZlciBwb3NzaWJsZSBpbiBjYXNlIG9mIG5lZWQuIFRoZSBob3Qgc3BhcmUgc2hv dWxkDQogaWRlYWxseSBiZSBiYXNlZCBvbiBhIGRpZmZlcmVudCBwcmluY2lwbGUgdG8gdGhlIHBy ZWZlcnJlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJpZ2h0IG5vdyBTSEEyIGlz IHRoZSBwcmVmZXJyZWQgZGlnZXN0IGZ1bmN0aW9uIGFuZCBJIGRvbid0IGV4cGVjdCB0aGF0IHRv IGNoYW5nZS4gQnV0IHRoZSBTSEExLSZndDtTSEEyIHRyYW5zaXRpb24gd2FzIGEgbG90IGhhcmRl ciB0aGFuIGl0IHNob3VsZCBoYXZlIGJlZW4gYW5kIGxlZnQgYSBsb3QgbW9yZSBicm9rZW4gZ2Vh ciB0aGFuIHRoZSBNRDUtJmd0O1NIQTEgdHJhbnNpdGlvbi4gVGhlIGRpZmZlcmVuY2Ugd2FzIHRo YXQgZm9yIE1ENSB3ZQ0KIGhhZCBhIGhvdCBzcGFyZSBidXQgYSBsb3Qgb2YgdmVuZG9ycyBkaWRu J3QgZXZlbiBzdGFydCB0byB0aGluayBhYm91dCBpbXBsZW1lbnRpbmcgU0hBMiB1bnRpbCB0aGUg Zmlyc3QgY29tcHJvbWlzZSBvZiBTSEExIHdhcyBhbm5vdW5jZWQuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBz bGlwcGVyeSBzbG9wZSBhcyB0aGUgcHJpbWFyeSBhbmQgaG90LXNwYXJlIHNsb3RzIGZvciBldmVy eSBvdGhlciBhbGdvcml0aG0gYXJlIGFscmVhZHkgZmlsbGVkLiBGb3IgcHVibGljIGtleSB3ZSBo YXZlIFJTQSBhbmQgdGhlIENGUkctRUNDIHNjaGVtZXMuIEZvciBzeW1tZXRyaWMgZW5jcnlwdGlv biB3ZSBoYXZlIEFFUyBhbmQgQ0hBLUNIQTIwLiBUaGlzIGlzIGp1c3Qgcm91bmRpbmcgdGhpbmdz DQogb3V0IGZvciBkaWdlc3QgZnVuY3Rpb25zIHNvIHdlIGhhdmUgdHdvIG9wdGlvbnMgdGhlcmUu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SU0EgaXMgZ29pbmcgdG8gYmUgdGhlIHBy ZWZlcnJlZCBhbGdvcml0aG0gdW50aWwgdGhlIENGUkcgd29yayBpcyBjb21wbGV0ZSBhbmQgaGFz IHNlZW4gc2lnbmlmaWNhbnQgZGVwbG95bWVudC4gVGhhdCBpcyBzdGlsbCBhdCBsZWFzdCA1IHll YXJzIG9mZiB3aGljaCBpcyBhIHBpdHkgYmVjYXVzZSBpdCBpcyBjdXR0aW5nIGl0IGF3ZnVsbHkg Y2xvc2UuIE15IGV4cGVjdGF0aW9uIGlzIHRoYXQgYXMgc29vbiBhcyBDRlJHIGlzIGRvbmUgd2l0 aA0KIHRoZSBFQ0MgY3VydmUgd29yaywgdGhlIG5leHQgZm9jdXMgb2YgYXR0ZW50aW9uIHdpbGwg YmUgcHVibGljIGtleSBzeXN0ZW1zIHRoYXQgYXJlIHF1YW50dW0gcmVzaXN0YW50LCAoaWYgd2Ug Y2FuIGNvbnZpbmNlIG91cnNlbHZlcyBzdWNoIHNjaGVtZXMgYWN0dWFsbHkgZXhpc3QpLjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U28gYnkgdGhlIHRpbWUgd2UgYXJlIHBoYXNpbmcg UlNBIG91dCwgSSBleHBlY3QgdGhhdCB3ZSB3aWxsIGJlIGxvb2tpbmcgYXQgYWxnb3JpdGhtcyB0 aGF0IGhhdmUgbm90IGJlZW4gaW52ZW50ZWQgeWV0IHRvIHJlcGxhY2UgaXQuIEFkZGluZyBTSEEz IHRvIENVUkRMRSBpcyBub3QgYSBzbGlwcGVyeSBzbG9wZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D28F008642096johnmattssonericssoncom_-- From nobody Thu Dec 10 08:46:29 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10A71A89FF for ; Thu, 10 Dec 2015 08:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z74t2D8yCZKa for ; Thu, 10 Dec 2015 08:46:26 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 384971A899A for ; Thu, 10 Dec 2015 08:46:26 -0800 (PST) Received: by lbpu9 with SMTP id u9so48309873lbp.2 for ; Thu, 10 Dec 2015 08:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=1gkwasJO9RDiZS8whjj/zxqJtMvskwu4vwXVVWSrGJ4=; b=ogs+7abnwc0tEYicWysX2qZnf0O6hcRr0KUVks+KyNVhxpaG29U1bJZumHhNWfLDf+ StGsglu9xZnxubI2qZT421F2PYbjfU3k1fAjoDbjxf+AE2nE6YOpPyPd2XPP1L4mn76Q F9yN3ekAd8TZSwsPTzFb8Hm6HxxUQXKyFQm0ux7PvqmIjhVggPvh7x+eI5HX0yyb7rOo UGRlcUxdy/V6vtrk/A96TD1lVLpEqnDWln/En56a8j8qKJ+gec17NCmjW3UQ63gZmKKY 6r4iMUyLw/8Af3Q67jgMl5O/DIGOMwQtQnxOaJX0N93erb3Il7uoJu85mJS5fdad7fia wiYw== MIME-Version: 1.0 X-Received: by 10.112.184.45 with SMTP id er13mr5684187lbc.133.1449765984394; Thu, 10 Dec 2015 08:46:24 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Thu, 10 Dec 2015 08:46:24 -0800 (PST) Date: Thu, 10 Dec 2015 11:46:24 -0500 X-Google-Sender-Auth: d5Wqb-Akn_PeiuvMYQ4cWRSplOs Message-ID: From: Phillip Hallam-Baker To: curdle@ietf.org Content-Type: multipart/alternative; boundary=001a1133f45081e61f05268df2fe Archived-At: Subject: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 16:46:27 -0000 --001a1133f45081e61f05268df2fe Content-Type: text/plain; charset=UTF-8 Was just rejigging some OID management stuff in a library and noticed that I hadn't put them in yet. While I don't expect to make much use of SHA3 with RSA, that is all I have that is testable at present. I don't think the CFRG process is at the stage where we would want to cut OIDs. --001a1133f45081e61f05268df2fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Was just rejigging some OID management stuff in a library = and noticed that I hadn't put them in yet.=C2=A0

Whi= le I don't expect to make much use of SHA3 with RSA, that is all I have= that is testable at present. I don't think the CFRG process is at the = stage where we would want to cut OIDs.
--001a1133f45081e61f05268df2fe-- From nobody Thu Dec 10 09:10:47 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4331C1A89F5 for ; Thu, 10 Dec 2015 09:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO57iU8fhTJ7 for ; Thu, 10 Dec 2015 09:10:44 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D71C1A1BB8 for ; Thu, 10 Dec 2015 09:10:44 -0800 (PST) Received: by lfaz4 with SMTP id z4so61358751lfa.0 for ; Thu, 10 Dec 2015 09:10:42 -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:date:message-id:subject :from:to:cc:content-type; bh=OC60+/Hpypqyf7Ftn1+Zz8+I0dNsBywy6mucNLbPuGY=; b=gGYqgC7sPST3trAJfR9h0yxTif6iJ5Tp74rxtIRBLEIbRCFYU676TKP9sDLXcUKEjs hYNWvYvxRgM/7FkJQZ/PBRxlK4dtn70GfdTBFp/UZntIC3b/mx7r2olWuyr+Jiu0hBec 8OVUoMVD0lhxl4B7RydJyXiZQTJANhIs2YkevGmFzOAQYdAjcyrEhAndM25kKSDceNCO B+ywoMXKhXeWZVlsLF+DpEAGqH8iutqwRzZ2o/lLhJ0e4VkaC5U3wjQhCWSWjXk68GUm ohEFRV1xdnvP9gb+cjJoLMhfKBHPoDmcQO4o27dxvLS6XjB7IyLweKZlgfavGcT3b+8r J5Tg== MIME-Version: 1.0 X-Received: by 10.25.208.206 with SMTP id h197mr5782719lfg.153.1449767442552; Thu, 10 Dec 2015 09:10:42 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Thu, 10 Dec 2015 09:10:42 -0800 (PST) In-Reply-To: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> Date: Thu, 10 Dec 2015 12:10:42 -0500 X-Google-Sender-Auth: kpnwegJCU0ZXVonAgWSQCR12XSw Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1140118e6b9feb05268e4990 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 17:10:46 -0000 --001a1140118e6b9feb05268e4990 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 10, 2015 at 12:00 PM, Paul Hoffman wrote: > The working group is less than a week old, and already we're discussing > items explicitly outside the charter. Yuck. > > Note that the charter not only prohibits discussing hashes, but it also > limits the WG to which the CURDLE work applies. > > If you actually care about getting the SHA3 work started (I don't), start > a new WG that is focused on it, and that applies to all WGs in the IETF, > particularly TLS. > > --Paul Hoffman > >From the announcement: "A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-12-14." The WG has not been formed yet. We are in charter discussion. Therefore nothing is out of scope. My proposal is to refine the charter scope. I raised the proposal here because that is what the Area Director told me to do. Creating a separate working group would mean double the work for the IESG, IANA and RFC Editor. Independent drafts are likely to be worse. Getting SHA2 consistently supported in IETF protocols took Russ at least three years. The cost of implementing crypto code is negligible. It is qualifying and testing that takes the time. Each time we touch one of our systems we have to go through QA again or risk something bad happening. That is why we greatly prefer to do all the changes at once. --001a1140118e6b9feb05268e4990 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 10, 2015 at 12:00 PM, Paul Hoffman <paul.hoffman@vpnc.= org> wrote:
The working group is less tha= n a week old, and already we're discussing items explicitly outside the= charter. Yuck.

Note that the charter not only prohibits discussing hashes, but it also lim= its the WG to which the CURDLE work applies.

If you actually care about getting the SHA3 work started (I don't), sta= rt a new WG that is focused on it, and that applies to all WGs in the IETF,= particularly TLS.

--Paul Hoffman

From = the announcement:

"A new IETF working group= has been proposed in the Security Area. The IESG
has not made any determination yet. The following dra= ft charter was
submitted, and is provided for informational purposes only. Pleas= e send
your comments to the IESG mailing list (iesg at=C2=A0ietf.org) by=C2=A02015-12-14."


<= /span>
The WG has not been forme= d yet. We are in charter discussion. Therefore nothing is out of scope. My = proposal is to refine the charter scope.

I ra= ised the proposal here because that is what the Area Director told me to do= .

<= span style=3D"font-size:12.8px">Creating a separate working group would mea= n double the work for the IESG, IANA and RFC Editor. Independent drafts are= likely to be worse. Getting SHA2 consistently supported in IETF protocols = took Russ at least three years.


The cost of implementing crypto c= ode is negligible. It is qualifying and testing that takes the time. Each t= ime we touch one of our systems we have to go through QA again or risk some= thing bad happening. That is why we greatly prefer to do all the changes at= once.

<= /div> --001a1140118e6b9feb05268e4990-- From nobody Thu Dec 10 09:19:55 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03CF1A8AE2 for ; Thu, 10 Dec 2015 09:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FsiaIhFUuMN for ; Thu, 10 Dec 2015 09:00:17 -0800 (PST) Received: from hoffman.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 C8F281A6F0E for ; Thu, 10 Dec 2015 09:00:14 -0800 (PST) Received: from [10.32.60.165] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tBAH09d2038734 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2015 10:00:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.165] From: "Paul Hoffman" To: "Phillip Hallam-Baker" Date: Thu, 10 Dec 2015 09:00:12 -0800 Message-ID: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: X-Mailman-Approved-At: Thu, 10 Dec 2015 09:19:53 -0800 Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 17:00:17 -0000 The working group is less than a week old, and already we're discussing items explicitly outside the charter. Yuck. Note that the charter not only prohibits discussing hashes, but it also limits the WG to which the CURDLE work applies. If you actually care about getting the SHA3 work started (I don't), start a new WG that is focused on it, and that applies to all WGs in the IETF, particularly TLS. --Paul Hoffman From nobody Thu Dec 10 09:20:21 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56A31A8F45 for ; Thu, 10 Dec 2015 09:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF64nQvRTKxO for ; Thu, 10 Dec 2015 09:20:15 -0800 (PST) Received: from hoffman.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 2B4A91A8F39 for ; Thu, 10 Dec 2015 09:20:15 -0800 (PST) Received: from [10.32.60.165] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tBAHKBsU039651 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2015 10:20:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.165] From: "Paul Hoffman" To: "Phillip Hallam-Baker" Date: Thu, 10 Dec 2015 09:20:14 -0800 Message-ID: In-Reply-To: References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 17:20:16 -0000 On 10 Dec 2015, at 9:10, Phillip Hallam-Baker wrote: > The WG has not been formed yet. We are in charter discussion. > Therefore > nothing is out of scope. My proposal is to refine the charter scope. Whoops, my mistake. I got ahead of myself. Just to be clear then, you are proposing to add SHA3 to the charter *and* to widen the WGs covered to all groups that use crypto? It would be weird to only do the first but to be discussing the use of SHA3 in TLS, for example. > Creating a separate working group would mean double the work for the > IESG, > IANA and RFC Editor. Independent drafts are likely to be worse. > Getting > SHA2 consistently supported in IETF protocols took Russ at least three > years. The flip side of the "double the work of the IESG" argument is that there is a lot of interest in working on the new curves and, so far, almost none for SHA3. Therefore, overlapping the two will make this WG harder to manage. Having one or two WGs would not affect the work for the IANA or RFC Editor. Fully agree about independent drafts: if there is a move towards SHA3, it should be done in the various WGs, or in a collection WG. > The cost of implementing crypto code is negligible. It is qualifying > and > testing that takes the time. Each time we touch one of our systems we > have > to go through QA again or risk something bad happening. That is why we > greatly prefer to do all the changes at once. Fully agree. However, I disagree that it should be done in CURDLE. If it spun up as a separate WG, it would be easier for those folks to focus on which bits of SHA3 we want to use, which we don't, and the whole BLAKE2 question (which I know you reject, but others embrace). --Paul Hoffman From nobody Thu Dec 10 09:49:08 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C4A1A90B2 for ; Thu, 10 Dec 2015 09:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfNIAvjk6e2n for ; Thu, 10 Dec 2015 09:49:05 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 C5AB11A90A9 for ; Thu, 10 Dec 2015 09:49:04 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id w144so34365156wmw.1 for ; Thu, 10 Dec 2015 09:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9wbmB0z7GWbx1DqI5Xrfbyg5fAtVxMBV9LiRvj3WplM=; b=WYTL37yNEDtuTbz+DD+I+SU8e2NGI3EzBusJ6YOq9kR3w6wLSaoESz5MEp8GI9rlAT /Ve6vi/okwNof2pwkBg/V03GdijyLm9WDULH+Us0eJ/X5oLkp5jz2Q20r9lKW4bEmx98 VnBT4IKoxVWMCDRuaxH0ULNYMrQn442JWK7RmjjoOcXX3DQMyUdSHywCzGrTJs4L1X3J lCMqhGt9yyA934mLyzfWibsBAG+dAHc71GL/W0k/PRJ80uWQ/BswsH7i53oBmP8kJag8 coiV6jHreM6P42hj7+zsC5L2LMRMPau3D51ZyLTtPIlXXw/qc9U8k3AP++5YJ8aOn8u4 v/XA== X-Received: by 10.28.7.8 with SMTP id 8mr353295wmh.45.1449769743446; Thu, 10 Dec 2015 09:49:03 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id bv1sm4919968wjc.24.2015.12.10.09.49.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 09:49:02 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_20209F80-B217-47BA-A674-FFEFF8A2E7E8" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Thu, 10 Dec 2015 19:49:01 +0200 Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3112) Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 17:49:07 -0000 --Apple-Mail=_20209F80-B217-47BA-A674-FFEFF8A2E7E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Dec 2015, at 6:46 PM, Phillip Hallam-Baker = > wrote: >=20 > Was just rejigging some OID management stuff in a library and noticed = that I hadn't put them in yet.=20 >=20 > While I don't expect to make much use of SHA3 with RSA, that is all I = have that is testable at present. I don't think the CFRG process is at = the stage where we would want to cut OIDs. Looking in oid-info.com , I see this: = http://oid-info.com/get/1.2.840.113549.1.1 = No one has bothered to register SHA-3 here, which I take as further = evidence that people don=E2=80=99t care about SHA-3. Yoav= --Apple-Mail=_20209F80-B217-47BA-A674-FFEFF8A2E7E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 10 Dec 2015, at 6:46 PM, Phillip = Hallam-Baker <phill@hallambaker.com> wrote:

Was just rejigging some OID management stuff in a library and = noticed that I hadn't put them in yet. 

While I don't expect to make much use = of SHA3 with RSA, that is all I have that is testable at present. I = don't think the CFRG process is at the stage where we would want to cut = OIDs.


No one has bothered to register SHA-3 here, which I take as = further evidence that people don=E2=80=99t care about SHA-3.

Yoav
= --Apple-Mail=_20209F80-B217-47BA-A674-FFEFF8A2E7E8-- From nobody Thu Dec 10 09:57:49 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B981A8A87 for ; Thu, 10 Dec 2015 09:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcPjYtxnBuFA for ; Thu, 10 Dec 2015 09:57:41 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38ADD1A9111 for ; Thu, 10 Dec 2015 09:57:38 -0800 (PST) Received: by lbblt2 with SMTP id lt2so56467503lbb.3 for ; Thu, 10 Dec 2015 09:57:36 -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:date:message-id:subject :from:to:cc:content-type; bh=e59XqKCT4MH13E5fkQqgtv6/hFNJaZVv2kORxtgtEk8=; b=sS8i7dr4CHSAbpB3ijVo16ntxSOvb0c2b9Pnn1uQ1w4S81RaSSBqqgG4/e4Do7KCJ/ 7F/nJ6iM1kNDUmuBiRDBIj6gmPeXf2+ql+n9Ehc9hk27ogV8RAQME+K5+Wk66eWoNJkG 2LaXhf08kzKNTNX8BpHqa81c4VWMifAwoDmXybKKNSgXHz6XZbcMW9nRn49OuIuUUk4X Kz5LD7yEq9DdkF5ggPHQdB+hg5B8XQnYVvzmEaSKlaX19naI0Xcj7COqCDBBmcMUeN/Q meJ/cBLNkfy1wiIy9uwq4UenXV2FVSipSTFXnKE/0eBoOSx6oXr1VzmhCoukTYrE7U+8 3J6w== MIME-Version: 1.0 X-Received: by 10.112.184.45 with SMTP id er13mr5831070lbc.133.1449770256265; Thu, 10 Dec 2015 09:57:36 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Thu, 10 Dec 2015 09:57:36 -0800 (PST) In-Reply-To: References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> Date: Thu, 10 Dec 2015 12:57:36 -0500 X-Google-Sender-Auth: XAou5JJAZijdT_8J09VeKNRrQNA Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1133f45021799b05268ef15d Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 17:57:45 -0000 --001a1133f45021799b05268ef15d Content-Type: text/plain; charset=UTF-8 On Thu, Dec 10, 2015 at 12:20 PM, Paul Hoffman wrote: > On 10 Dec 2015, at 9:10, Phillip Hallam-Baker wrote: > > The WG has not been formed yet. We are in charter discussion. Therefore >> nothing is out of scope. My proposal is to refine the charter scope. >> > > Whoops, my mistake. I got ahead of myself. > > Just to be clear then, you are proposing to add SHA3 to the charter *and* > to widen the WGs covered to all groups that use crypto? It would be weird > to only do the first but to be discussing the use of SHA3 in TLS, for > example. No, just add SHA3 to the scope. We currently have three sets of protocols that use crypto 1) Stuff nobody uses (PEM, MOSS, etc.) 2) Protocols that are in active use but don't have an active WG 3) Protocols that have an active WG. The point of CURDLE is to address group 2. I don't think anyone is proposing to add the CFRG curves for use in PEM. What happens on 3 is really up to the relevant WG chairs and the responsible AD. I don't see any need to assume that this is going to be a massive turf war. There are only two current protocol WGs that define crypto algs directly, IPSECME and TLS. TLS has cipher suites which is a big complication because you end up with the x*y*z combinatorial explosion. IPSEC doesn't have that issue. There is obviously going to need to be protocol specific input for every one of the protocols affected. Introducing new signature and encryption algorithms introduces a lot of complexity. Swapping SHA2 for SHA3 isn't anywhere near as complex. Creating a separate working group would mean double the work for the IESG, >> IANA and RFC Editor. Independent drafts are likely to be worse. Getting >> SHA2 consistently supported in IETF protocols took Russ at least three >> years. >> > > The flip side of the "double the work of the IESG" argument is that there > is a lot of interest in working on the new curves and, so far, almost none > for SHA3. Therefore, overlapping the two will make this WG harder to manage. > There are two reasons for the lack of interest in SHA3 to date. The first was the lack of a FIPS till three months ago. But the bigger one was knowing that a new set of Elliptic Curves were on their way. > Having one or two WGs would not affect the work for the IANA or RFC Editor. > It will mean more documents and more sets of code point requests and more people to interact with. > Fully agree about independent drafts: if there is a move towards SHA3, it > should be done in the various WGs, or in a collection WG. > > The cost of implementing crypto code is negligible. It is qualifying and >> testing that takes the time. Each time we touch one of our systems we have >> to go through QA again or risk something bad happening. That is why we >> greatly prefer to do all the changes at once. >> > > Fully agree. However, I disagree that it should be done in CURDLE. If it > spun up as a separate WG, it would be easier for those folks to focus on > which bits of SHA3 we want to use, which we don't, and the whole BLAKE2 > question (which I know you reject, but others embrace). So far, nobody has stated they support BLAKE2 themselves, only that 'others' like it. Until someone is prepared to put their name to the proposal and back it up with arguments, BLAKE2 isn't even on the table. Getting consistent support for SHA3 is an achievable goal. Getting consistent support for a new proposal by one of the groups that entered the competition and didn't win is not very likely. The other reason for choosing SHA3 is that it helps strengthen the case for getting NIST to support the new CFRG algorithms in place of their existing curves. NIST has already taken a step back from them. The NIST objective has been to persuade the industry to move to ECC. The plethora of curves is obviously an obstacle at this point, moving to CFRG curves is a win for all concerned. But persuading a large bureaucracy on that point is not easy. Recognizing their SHA3 effort makes the case a lot easier. --001a1133f45021799b05268ef15d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 10, 2015 at 12:20 PM, Paul Hoffman <paul.hoffman@vpnc.org&= gt; wrote:
On 10 = Dec 2015, at 9:10, Phillip Hallam-Baker wrote:

The WG has not been formed yet. We are in charter discussion. Therefore
nothing is out of scope. My proposal is to refine the charter scope.

 Whoops, my mistake. I got ahead of myself.

Just to be clear then, you are proposing to add SHA3 to the charter *and* t= o widen the WGs covered to all groups that use crypto? It would be weird to= only do the first but to be discussing the use of SHA3 in TLS, for example= .

No, just add SHA3 to the scope.

We currently have three sets of protocols that use crypto

1) Stuff nobody uses (PEM, MOSS, etc.)
2)= Protocols that are in active use but don't have an active WG
3) Protocols that have an active WG.

The point of= CURDLE is to address group 2. I don't think anyone is proposing to add= the CFRG curves for use in PEM.=C2=A0

What happen= s on 3 is really up to the relevant WG chairs and the responsible AD. I don= 't see any need to assume that this is going to be a massive turf war. = There are only two current protocol WGs that define crypto algs directly, I= PSECME and TLS.=C2=A0

TLS has cipher suites which = is a big complication because you end up with the x*y*z combinatorial explo= sion. IPSEC doesn't have that issue.

There is = obviously going to need to be protocol specific input for every one of the = protocols affected. Introducing new signature and encryption algorithms int= roduces a lot of complexity. Swapping SHA2 for SHA3 isn't anywhere near= as complex.


Creating a separate wor= king group would mean double the work for the IESG,
IANA and RFC Editor. Independent drafts are likely to be worse. Getting
SHA2 consistently supported in IETF protocols took Russ at least three
years.

 The flip side of the "double the work of the IESG" argument is th= at there is a lot of interest in working on the new curves and, so far, alm= ost none for SHA3. Therefore, overlapping the two will make this WG harder = to manage.

There are two reasons for th= e lack of interest in SHA3 to date. The first was the lack of a FIPS till t= hree months ago. But the bigger one was knowing that a new set of Elliptic = Curves were on their way.

=C2=A0
Having one or two WGs would not affect the work for the IANA or RFC Editor.=

It will mean more documents and more s= ets of code point requests and more people to interact with.

=
=C2=A0
Fully agree about independent drafts: if there is a move towards SHA3, it s= hould be done in the various WGs, or in a collection WG.
The cost of implementing crypto code is negligible. It is qualifying and testing that takes the time. Each time we touch one of our systems we have<= br> to go through QA again or risk something bad happening. That is why we
greatly prefer to do all the changes at once.

 Fully agree. However, I disagree that it should be done in CURDLE. If it sp= un up as a separate WG, it would be easier for those folks to focus on whic= h bits of SHA3 we want to use, which we don't, and the whole BLAKE2 que= stion (which I know you reject, but others embrace).

<= /div>
So far, nobody has stated they support BLAKE2 themselves, only th= at 'others' like it. Until someone is prepared to put their name to= the proposal and back it up with arguments, BLAKE2 isn't even on the t= able.

Getting consistent support for SHA3 is an ac= hievable goal. Getting consistent support for a new proposal by one of the = groups that entered the competition and didn't win is not very likely.= =C2=A0

The other reason for choosing SHA3 is that = it helps strengthen the case for getting NIST to support the new CFRG algor= ithms in place of their existing curves. NIST has already taken a step back= from them. The NIST objective has been to persuade the industry to move to= ECC. The plethora of curves is obviously an obstacle at this point, moving= to CFRG curves is a win for all concerned. But persuading a large bureaucr= acy on that point is not easy. Recognizing their SHA3 effort makes the case= a lot easier.=C2=A0
--001a1133f45021799b05268ef15d-- From nobody Thu Dec 10 10:47:47 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014A1ACD30 for ; Thu, 10 Dec 2015 10:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y7umFUZ_rbK for ; Thu, 10 Dec 2015 10:47:43 -0800 (PST) Received: from welho-filter1.welho.com (unknown [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA2501ACC91 for ; Thu, 10 Dec 2015 10:47:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 3213255C; Thu, 10 Dec 2015 20:47:27 +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 nCtl6kOxy6iH; Thu, 10 Dec 2015 20:47:26 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D67F0AC; Thu, 10 Dec 2015 20:47:26 +0200 (EET) Date: Thu, 10 Dec 2015 20:47:23 +0200 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 18:47:45 -0000 On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wrote: > > > There are two reasons for the lack of interest in SHA3 to date. The first > was the lack of a FIPS till three months ago. But the bigger one was > knowing that a new set of Elliptic Curves were on their way. In my opinion, there are two reasons: 1) SHA-2 is good enough. 2) SHA-3 has no real advantages over SHA-2. It seems the goal of NIST was to get something strong that is as different from SHA-2 as possible, so it is maximally unlikely that whatever could bring down SHA-2 would also take SHA-3 with it. > > Fully agree. However, I disagree that it should be done in CURDLE. If it > > spun up as a separate WG, it would be easier for those folks to focus on > > which bits of SHA3 we want to use, which we don't, and the whole BLAKE2 > > question (which I know you reject, but others embrace). > > > So far, nobody has stated they support BLAKE2 themselves, only that > 'others' like it. Until someone is prepared to put their name to the > proposal and back it up with arguments, BLAKE2 isn't even on the table. The second reason I gave above would be false for BLAKE2. For this reason, it seems to be getting much more real-world use than SHA-3. Also, there is RFC about Blake2, and AFAIK not one even in process for SHA-3, nevermind that I consider FIPS202 pretty unreadable due to dealing with cases nobody really cares about. > Getting consistent support for SHA3 is an achievable goal. Getting > consistent support for a new proposal by one of the groups that entered the > competition and didn't win is not very likely. As of currently, I don't consider TLS 1.3 draft currently capable of taking any ciphersuite that doesn't have SHA2-256 or SHA2-384 PRF. Not SHA-3, not BLAKE2. > The other reason for choosing SHA3 is that it helps strengthen the case for > getting NIST to support the new CFRG algorithms in place of their existing > curves. NIST has already taken a step back from them. The NIST objective > has been to persuade the industry to move to ECC. The plethora of curves is > obviously an obstacle at this point, moving to CFRG curves is a win for all > concerned. But persuading a large bureaucracy on that point is not easy. > Recognizing their SHA3 effort makes the case a lot easier. I don't see why this is the case. Also, PKIX has problems one hits if one tries to use SHA-3 (outside black-box settings like some Ed448 hash proposals)... -Ilari From nobody Thu Dec 10 11:04:44 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FEC1AC417 for ; Thu, 10 Dec 2015 11:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue6VmWa5_nbs for ; Thu, 10 Dec 2015 11:04:43 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 801471ACDB1 for ; Thu, 10 Dec 2015 11:02:18 -0800 (PST) Received: by lfaz4 with SMTP id z4so63420614lfa.0 for ; Thu, 10 Dec 2015 11:02:16 -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:date:message-id:subject :from:to:cc:content-type; bh=BOJYqHbbontOMe5KjdXfqoRSH8KLTCJh2e65WcC6yfA=; b=XTwWFOxWn6ZQ+WBQH+LMMi4EeUD70O0pASbQqWYyKkjNpss5VOUusLYsxziQF7RGvP 2P7VxaEcrvO8O6mvSrNBNb6oGX0Ke9cBJCefENDP1WeEKMIrLO94qo/RAaVCz7+2CvyA mNOLVOXNm+Zyr389vZzwS4hqIeTQcMxYi6LWjKw8fenX7K6PN+D8TONKf3SlxGkyoziB x3CLTr51EAypQZvpAC2SQzmOA/crB+NIAPaJb+0wwCFYhAtKmwJ8uLfwmMed1OqKKm/e YoFDFW38hphxeub6FcMZGHxsvChDxieK3ri4JCXSPBMa2uiW+hXwVZikV7rrQKfy9HYS jFNQ== MIME-Version: 1.0 X-Received: by 10.25.42.208 with SMTP id q199mr6099561lfq.67.1449774136580; Thu, 10 Dec 2015 11:02:16 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Thu, 10 Dec 2015 11:02:16 -0800 (PST) In-Reply-To: <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 10 Dec 2015 14:02:16 -0500 X-Google-Sender-Auth: vOhp0x_pX8hhZNWHOxhtAh706Hc Message-ID: From: Phillip Hallam-Baker To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11410bfa6a61a805268fd847 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 19:04:44 -0000 --001a11410bfa6a61a805268fd847 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 10, 2015 at 1:47 PM, Ilari Liusvaara wrote: > On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wrote: > > I don't see why this is the case. Also, PKIX has problems one hits if > one tries to use SHA-3 (outside black-box settings like some Ed448 hash > proposals).. > Could you specify them? PKIX uses an algorithm ID that conflates the digest and the public key algorithm. But that is all. Every crypto lib I have used allows for a choice of digest function. The RSA message format has to be configured to ensure the digest OID is embedded but that is straightforward. --001a11410bfa6a61a805268fd847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 10, 2015 at 1:47 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wrote:
I don't see why this is the case. Also, PKIX has problems one hi= ts if
one tries to use SHA-3 (outside black-box settings like some Ed448 hash
proposals)..

Could you specify them?

PKIX uses an algorithm ID that conflates the digest = and the public key algorithm. But that is all. Every crypto lib I have used= allows for a choice of digest function. The RSA message format has to be c= onfigured to ensure the digest OID is embedded but that is straightforward.=

=C2=A0
--001a11410bfa6a61a805268fd847-- From nobody Thu Dec 10 11:15:12 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CF11ACDCC for ; Thu, 10 Dec 2015 11:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYvTue_-akqB for ; Thu, 10 Dec 2015 11:15:07 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6761ACD82 for ; Thu, 10 Dec 2015 11:15:06 -0800 (PST) Received: from BY2PR09MB126.namprd09.prod.outlook.com (10.242.37.156) by BY2PR09MB125.namprd09.prod.outlook.com (10.242.37.155) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 10 Dec 2015 19:15:04 +0000 Received: from BY2PR09MB126.namprd09.prod.outlook.com ([10.242.37.156]) by BY2PR09MB126.namprd09.prod.outlook.com ([10.242.37.156]) with mapi id 15.01.0331.023; Thu, 10 Dec 2015 19:15:04 +0000 From: "Dang, Quynh" To: "ilariliusvaara@welho.com" , "curdle@ietf.org" Thread-Topic: [Curdle] SHA3 should be in scope. Thread-Index: AQHRM36lP6i8IhqYRUmDFux0z90eQp7Ellrl Date: Thu, 10 Dec 2015 19:15:03 +0000 Message-ID: References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi>, 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=quynh.dang@nist.gov; x-originating-ip: [129.6.223.8] x-microsoft-exchange-diagnostics: 1; BY2PR09MB125; 5:EfP+UpCbKZX9OifYlUc6QU3/HGPTf64Z1qO1a5tXBjWBSjy0C7tw8YOeV1oYkNHuPWBVnbLOB18ZCBui9mBbPsZx6xw+qyX/dYQQobC+FPBMu7qMkde4udjnz1Rl3AibsbuUPdRATCCOg8KuxFD98g==; 24:/6PFhtq3O0fo//9P7mJ3YZA1nBkwuWY/tI2tFCMAMcTwV2xxJhOYuxgBwn1xlUCAZrVK1+Bp7Q6QhySJ/T//ZgDGT/syCjJdkfu0MchEo2o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB125; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY2PR09MB125; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB125; x-forefront-prvs: 078693968A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(504964003)(24454002)(199003)(189002)(377454003)(5001770100001)(93886004)(101416001)(54356999)(105586002)(5002640100001)(33656002)(81156007)(77096005)(2900100001)(97736004)(2950100001)(19617315012)(15975445007)(16236675004)(74316001)(76576001)(87936001)(92566002)(76176999)(19625215002)(107886002)(50986999)(5001960100002)(86362001)(106356001)(106116001)(561944003)(10400500002)(99286002)(19627405001)(2501003)(6116002)(40100003)(5008740100001)(189998001)(3846002)(19580405001)(122556002)(11100500001)(586003)(1096002)(102836003)(66066001)(5003600100002)(5004730100002)(19580395003)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR09MB125; H:BY2PR09MB126.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR09MB1268A41A704C8C7EA7A8E9AF3E90BY2PR09MB126namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2015 19:15:03.0899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB125 Archived-At: Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 19:15:11 -0000 --_000_BY2PR09MB1268A41A704C8C7EA7A8E9AF3E90BY2PR09MB126namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ilari, Could you please explain this "FIPS202 pretty unreadable due to dealing with cases nobody really cares about." ? Thank you in advance! Quynh. From: Ilari Liusvaara > Date: Thu, Dec 10, 2015 at 1:47 PM Subject: Re: [Curdle] SHA3 should be in scope. To: Phillip Hallam-Baker > Cc: curdle@ietf.org On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wrote: > > > There are two reasons for the lack of interest in SHA3 to date. The first > was the lack of a FIPS till three months ago. But the bigger one was > knowing that a new set of Elliptic Curves were on their way. In my opinion, there are two reasons: 1) SHA-2 is good enough. 2) SHA-3 has no real advantages over SHA-2. It seems the goal of NIST was to get something strong that is as different from SHA-2 as possible, so it is maximally unlikely that whatever could bring down SHA-2 would also take SHA-3 with it. > > Fully agree. However, I disagree that it should be done in CURDLE. If i= t > > spun up as a separate WG, it would be easier for those folks to focus o= n > > which bits of SHA3 we want to use, which we don't, and the whole BLAKE2 > > question (which I know you reject, but others embrace). > > > So far, nobody has stated they support BLAKE2 themselves, only that > 'others' like it. Until someone is prepared to put their name to the > proposal and back it up with arguments, BLAKE2 isn't even on the table. The second reason I gave above would be false for BLAKE2. For this reason, it seems to be getting much more real-world use than SHA-3. Also, there is RFC about Blake2, and AFAIK not one even in process for SHA-3, nevermind that I consider FIPS202 pretty unreadable due to dealing with cases nobody really cares about. > Getting consistent support for SHA3 is an achievable goal. Getting > consistent support for a new proposal by one of the groups that entered t= he > competition and didn't win is not very likely. As of currently, I don't consider TLS 1.3 draft currently capable of taking any ciphersuite that doesn't have SHA2-256 or SHA2-384 PRF. Not SHA-3, not BLAKE2. > The other reason for choosing SHA3 is that it helps strengthen the case f= or > getting NIST to support the new CFRG algorithms in place of their existin= g > curves. NIST has already taken a step back from them. The NIST objective > has been to persuade the industry to move to ECC. The plethora of curves = is > obviously an obstacle at this point, moving to CFRG curves is a win for a= ll > concerned. But persuading a large bureaucracy on that point is not easy. > Recognizing their SHA3 effort makes the case a lot easier. I don't see why this is the case. Also, PKIX has problems one hits if one tries to use SHA-3 (outside black-box settings like some Ed448 hash proposals)... -Ilari _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --_000_BY2PR09MB1268A41A704C8C7EA7A8E9AF3E90BY2PR09MB126namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ilari,


Could you please explain this "FIPS202 pretty unreadable due to
dealing with cases nobody really ca= res about." ?


Thank you in advance!


Quynh. 




From: Ilari Liusva= ara <ilariliusvaara@welho.com>
Date: Thu, Dec 10, 2015 at 1:47 PM
Subject: Re: [Curdle] SHA3 should be in scope.
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: curdle@ietf.org


On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-B= aker wrote:
>
>
> There are two reasons for the lack of interest in SHA3 to date. The fi= rst
> was the lack of a FIPS till three months ago. But the bigger one was > knowing that a new set of Elliptic Curves were on their way.

In my opinion, there are two reasons:
1) SHA-2 is good enough.
2) SHA-3 has no real advantages over SHA-2.

It seems the goal of NIST was to get something strong that is as
different from SHA-2 as possible, so it is maximally unlikely that
whatever could bring down SHA-2 would also take SHA-3 with it.

> > Fully agree. However, I disagree that it should be done in CURDLE= . If it
> > spun up as a separate WG, it would be easier for those folks to f= ocus on
> > which bits of SHA3 we want to use, which we don't, and the whole = BLAKE2
> > question (which I know you reject, but others embrace).
>
>
> So far, nobody has stated they support BLAKE2 themselves, only that > 'others' like it. Until someone is prepared to put their name to the > proposal and back it up with arguments, BLAKE2 isn't even on the table= .

The second reason I gave above would be false for BLAKE2. For this r= eason,
it seems to be getting much more real-world use than SHA-3.

Also, there is RFC about Blake2, and AFAIK not one even in process for
SHA-3, nevermind that I consider FIPS202 pretty unreadable due to
dealing with cases nobody really cares about.

> Getting consistent support for SHA3 is an achievable goal. Getting
> consistent support for a new proposal by one of the groups that entere= d the
> competition and didn't win is not very likely.

As of currently, I don't consider TLS 1.3 draft currently capable of= taking
any ciphersuite that doesn't have SHA2-256 or SHA2-384 PRF. Not SHA-3,
not BLAKE2.

> The other reason for choosing SHA3 is that it helps strengthen the cas= e for
> getting NIST to support the new CFRG algorithms in place of their exis= ting
> curves. NIST has already taken a step back from them. The NIST objecti= ve
> has been to persuade the industry to move to ECC. The plethora of curv= es is
> obviously an obstacle at this point, moving to CFRG curves is a win fo= r all
> concerned. But persuading a large bureaucracy on that point is not eas= y.
> Recognizing their SHA3 effort makes the case a lot easier.

I don't see why this is the case. Also, PKIX has problems one hits i= f
one tries to use SHA-3 (outside black-box settings like some Ed448 hash
proposals)...


-Ilari

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

--_000_BY2PR09MB1268A41A704C8C7EA7A8E9AF3E90BY2PR09MB126namprd_-- From nobody Thu Dec 10 11:35:30 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F721A0856 for ; Thu, 10 Dec 2015 11:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGvMJUyYl2FI for ; Thu, 10 Dec 2015 11:35:19 -0800 (PST) Received: from welho-filter2.welho.com (unknown [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBD91AC44E for ; Thu, 10 Dec 2015 11:35:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EBE07645; Thu, 10 Dec 2015 21:35:15 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 23_xE1kMvPrY; Thu, 10 Dec 2015 21:35:15 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id AECDCA6; Thu, 10 Dec 2015 21:35:15 +0200 (EET) Date: Thu, 10 Dec 2015 21:35:12 +0200 From: Ilari Liusvaara To: "Dang, Quynh" Message-ID: <20151210193512.GA28760@LK-Perkele-V2.elisa-laajakaista.fi> References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 19:35:21 -0000 On Thu, Dec 10, 2015 at 07:15:03PM +0000, Dang, Quynh wrote: > Hi Ilari, > > > Could you please explain this "FIPS202 pretty unreadable due to > dealing with cases nobody really cares about." ? The bit-level representation due to supporting things like: - Lane width not 64. - Round count not 24. - Bit-length inputs (these are rarely implemented). If one omits those, one can get much much compact and understandable description. -Ilari From nobody Thu Dec 10 11:37:46 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1DD1AD367 for ; Thu, 10 Dec 2015 11:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7dBqX8ScjqC for ; Thu, 10 Dec 2015 11:37:44 -0800 (PST) Received: from welho-filter1.welho.com (unknown [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id E544B1AD35D for ; Thu, 10 Dec 2015 11:37:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 0B020693; Thu, 10 Dec 2015 21:37:43 +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 x3n_0xXOIZ18; Thu, 10 Dec 2015 21:37:42 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C7218AD; Thu, 10 Dec 2015 21:37:42 +0200 (EET) Date: Thu, 10 Dec 2015 21:37:40 +0200 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20151210193739.GB28760@LK-Perkele-V2.elisa-laajakaista.fi> References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 19:37:45 -0000 On Thu, Dec 10, 2015 at 02:02:16PM -0500, Phillip Hallam-Baker wrote: > On Thu, Dec 10, 2015 at 1:47 PM, Ilari Liusvaara > wrote: > > > On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wrote: > > > > I don't see why this is the case. Also, PKIX has problems one hits if > > one tries to use SHA-3 (outside black-box settings like some Ed448 hash > > proposals).. > > > > Could you specify them? > > PKIX uses an algorithm ID that conflates the digest and the public key > algorithm. But that is all. Every crypto lib I have used allows for a > choice of digest function. The RSA message format has to be configured to > ensure the digest OID is embedded but that is straightforward. Oh yeah, it would work fine with RSA. It is the ECDSA that runs into trouble. Basically, you for good crypto practice, you need to either fix the algorithms at key level or have solid indication in the output itself. Neither is easily possible with ECDSA in PKIX. -Ilari From nobody Thu Dec 10 12:08:58 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CB31B2A2F for ; Thu, 10 Dec 2015 12:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jexDOuO3rsUe for ; Thu, 10 Dec 2015 12:08:56 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 2DE101B2A51 for ; Thu, 10 Dec 2015 12:08:55 -0800 (PST) Received: by lffu14 with SMTP id u14so64784607lff.1 for ; Thu, 10 Dec 2015 12:08:54 -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:date:message-id:subject :from:to:cc:content-type; bh=QP5RCrbN/NezFSS8wDkcycORr8kzQLHYHywFF9o1+bc=; b=zBqASgtQkjASyOfTfrEigftG4nN4WilnXzwY9hAeYTFQH2mjP08FwOasooLt4RAXjU EZA7Q1YQR765xiskwCGOldgHsicfklzUg85vcOOMAhGYxFXjfAx20MiuTmdjsngOW9GG yIt73RhS6fmd0itbOva/8PqwoATVZT8sElSBEwBN79PFa3EjfQO7NY3K5at/4C+76l/j nsFia/trWMwo/cEHD2CP863Vm0FfYyPnNqXIAbowBkbtLKrwCW12ZQUeFEfYdz5PLufL ++GE5IHnznE3GO6JBTiq1sW7O/fm2r9dZey+i5H2vOR2R/VJsCbwnXkxJXlYzjq9VLad kVPQ== MIME-Version: 1.0 X-Received: by 10.25.208.206 with SMTP id h197mr6133243lfg.153.1449778133989; Thu, 10 Dec 2015 12:08:53 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Thu, 10 Dec 2015 12:08:53 -0800 (PST) In-Reply-To: <20151210193739.GB28760@LK-Perkele-V2.elisa-laajakaista.fi> References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> <20151210193739.GB28760@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 10 Dec 2015 15:08:53 -0500 X-Google-Sender-Auth: GBuU0DiMQbMBAsGiAboPBQK-mj0 Message-ID: From: Phillip Hallam-Baker To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1140118eadff29052690c6d9 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 20:08:58 -0000 --001a1140118eadff29052690c6d9 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 10, 2015 at 2:37 PM, Ilari Liusvaara wrote: > On Thu, Dec 10, 2015 at 02:02:16PM -0500, Phillip Hallam-Baker wrote: > > On Thu, Dec 10, 2015 at 1:47 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wrote: > > > > > > I don't see why this is the case. Also, PKIX has problems one hits if > > > one tries to use SHA-3 (outside black-box settings like some Ed448 hash > > > proposals).. > > > > > > > Could you specify them? > > > > PKIX uses an algorithm ID that conflates the digest and the public key > > algorithm. But that is all. Every crypto lib I have used allows for a > > choice of digest function. The RSA message format has to be configured to > > ensure the digest OID is embedded but that is straightforward. > > Oh yeah, it would work fine with RSA. It is the ECDSA that runs into > trouble. Basically, you for good crypto practice, you need to either fix > the algorithms at key level or have solid indication in the output > itself. Neither is easily possible with ECDSA in PKIX. > That is a CFRG issue. There is a poll at present. --001a1140118eadff29052690c6d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 10, 2015 at 2:37 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Thu, Dec 10, 2015 at 02:02:16PM -0500, = Phillip Hallam-Baker wrote:
> On Thu, Dec 10, 2015 at 1:47 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wr= ote:
> >
> > I don't see why this is the case. Also, PKIX has problems one= hits if
> > one tries to use SHA-3 (outside black-box settings like some Ed44= 8 hash
> > proposals)..
> >
>
> Could you specify them?
>
> PKIX uses an algorithm ID that conflates the digest and the public key=
> algorithm. But that is all. Every crypto lib I have used allows for a<= br> > choice of digest function. The RSA message format has to be configured= to
> ensure the digest OID is embedded but that is straightforward.

Oh yeah, it would work fine with RSA. It is the ECDSA that runs= into
trouble. Basically, you for good crypto practice, you need to either fix the algorithms at key level or have solid indication in the output
itself. Neither is easily possible with ECDSA in PKIX.

That is a CFRG issue. There is a poll at present.

=C2=A0
--001a1140118eadff29052690c6d9-- From nobody Thu Dec 10 12:29:20 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48331B2ABD for ; Thu, 10 Dec 2015 12:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnUO8nD4elNw for ; Thu, 10 Dec 2015 12:29:18 -0800 (PST) Received: from welho-filter1.welho.com (unknown [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4538C1B2ABA for ; Thu, 10 Dec 2015 12:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 61910535; Thu, 10 Dec 2015 22:29:17 +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 6J3cH1gPby-7; Thu, 10 Dec 2015 22:29:17 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 216F497; Thu, 10 Dec 2015 22:29:17 +0200 (EET) Date: Thu, 10 Dec 2015 22:29:14 +0200 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20151210202914.GA28943@LK-Perkele-V2.elisa-laajakaista.fi> References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> <20151210193739.GB28760@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 20:29:20 -0000 On Thu, Dec 10, 2015 at 03:08:53PM -0500, Phillip Hallam-Baker wrote: > On Thu, Dec 10, 2015 at 2:37 PM, Ilari Liusvaara > wrote: > > > > Oh yeah, it would work fine with RSA. It is the ECDSA that runs into > > trouble. Basically, you for good crypto practice, you need to either fix > > the algorithms at key level or have solid indication in the output > > itself. Neither is easily possible with ECDSA in PKIX. > > > > That is a CFRG issue. There is a poll at present. The way current drafts are written, would not be a problem with EdDSA, even if one defined multiple signature primitives sharing a curve (however, there is alternative proposal for PKIX that does suffer from multi-hash problems). (The algorithms do black-box encapsulation of hashes or possibly indicate it). -Ilari From nobody Thu Dec 10 14:05:53 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28661B2C6F for ; Thu, 10 Dec 2015 14:05:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umstOnyUZmfX for ; Thu, 10 Dec 2015 14:05:50 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2345A1B2C45 for ; Thu, 10 Dec 2015 14:05:49 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 7B9EB38F12; Thu, 10 Dec 2015 14:05:48 -0800 (PST) From: "Jim Schaad" To: "'Ilari Liusvaara'" , "'Phillip Hallam-Baker'" References: <6EE5D26D-BB22-4D06-B491-9487F2607A28@vpnc.org> <20151210184723.GA28479@LK-Perkele-V2.elisa-laajakaista.fi> <20151210193739.GB28760@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20151210193739.GB28760@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 10 Dec 2015 14:03:03 -0800 Message-ID: <020301d13396$8aeb6a50$a0c23ef0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQH5rqcUAbtmKs/6eVb/M+r/8TyyfgHiS9+4Aa0wKjwB2gDligGspeuoAqc6jBECwVanVwJ5AtJ0nfwRy4A= Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] SHA3 should be in scope. X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2015 22:05:52 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Thursday, December 10, 2015 11:38 AM > To: Phillip Hallam-Baker > Cc: curdle@ietf.org > Subject: Re: [Curdle] SHA3 should be in scope. > > On Thu, Dec 10, 2015 at 02:02:16PM -0500, Phillip Hallam-Baker wrote: > > On Thu, Dec 10, 2015 at 1:47 PM, Ilari Liusvaara > > > > wrote: > > > > > On Thu, Dec 10, 2015 at 12:57:36PM -0500, Phillip Hallam-Baker wrote: > > > > > > I don't see why this is the case. Also, PKIX has problems one hits > > > if one tries to use SHA-3 (outside black-box settings like some > > > Ed448 hash proposals).. > > > > > > > Could you specify them? > > > > PKIX uses an algorithm ID that conflates the digest and the public key > > algorithm. But that is all. Every crypto lib I have used allows for a > > choice of digest function. The RSA message format has to be configured > > to ensure the digest OID is embedded but that is straightforward. > > Oh yeah, it would work fine with RSA. It is the ECDSA that runs into trouble. > Basically, you for good crypto practice, you need to either fix the algorithms at > key level or have solid indication in the output itself. Neither is easily possible > with ECDSA in PKIX. I would hope that we would not be defining new PKCS v1.5 signature algorithms. If it is PSS then the algorithm is not fixed and is potentially, but probably not, a problem. > > > -Ilari > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Dec 16 06:36:37 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B951B2DE3 for ; Wed, 16 Dec 2015 06:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA6v3Tk_etzU for ; Wed, 16 Dec 2015 06:36:29 -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 0040B1B2DDB for ; Wed, 16 Dec 2015 06:36:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52FCCBE73; Wed, 16 Dec 2015 14:36:26 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWPP_m9BEh4B; Wed, 16 Dec 2015 14:36:26 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9AD12BE3E; Wed, 16 Dec 2015 14:36:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450276586; bh=NgBF4bq6491AuPG8vabU1Zbsa48XYiq95EcWVJEMV9Y=; h=To:Cc:From:Subject:Date:From; b=wAHnir6kgwgfjm8DTeiVZnyf/Eo9u/tA7t5iJSTWXSkEH0In2bFIXkSVcORF4z8Sv QtAH6JLsfV8/Hyqig+ZkA7USI//QV37im5/gEv+QyZzGulU3oaOUm4R0un9+8KuUw+ 74+m4vxjYXWYelKaZJ6T+S7qvznqJ0nYqLHjC8AY= To: curdle@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <567176E8.6040700@cs.tcd.ie> Date: Wed, 16 Dec 2015 14:36:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Salz, Rich" , Daniel Migault Subject: [Curdle] chairs and status X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 14:36:35 -0000 Hi all, Thanks to everyone who volunteered to co-chair this effort. There was no shortage of qualified volunteers which is good to see. Rich Salz and Daniel Migault (cc'd on this) have agreed to be our chairs, so special thanks to Rich and Daniel. I believe they'll be sending some mail to bottom out on a few things in the next few days. Other than that, the charter is on tomorrow's IESG call for approval, and if that goes ok, then we may have the wg formally chartered by next week and ready to kick off work in earnest in the new year. Cheers, S. From nobody Wed Dec 16 06:36:48 2015 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 2FDF61A89F0; Wed, 16 Dec 2015 06:36:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216143647.13800.99321.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 06:36:47 -0800 From: IETF Secretariat Archived-At: Subject: [Curdle] ID Tracker State Update Notice: X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 14:36:47 -0000 State changed to IESG review. ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-curdle/ From nobody Wed Dec 16 08:54:21 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EA81A21BA for ; Wed, 16 Dec 2015 08:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmiJjbkUEPRp for ; Wed, 16 Dec 2015 08:54:18 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 D94F31A1B27 for ; Wed, 16 Dec 2015 08:54:09 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id 21so38844104qgx.1 for ; Wed, 16 Dec 2015 08:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YU+GgyvDQ6kftb0wa1FkVBEOykklUHmiPMJqe7CMsN8=; b=dp7+HJrCwnnx5b7sjbMYssMVAPuEf3jkfnc8Erprl5m4OCMSiakCf5/g62DpP9EGky WeKsf7lVYmgChCOMoFljTdMnlp9eYzMS4QjqneEtTQy4amUN/gzMyUNGBZy4CswihhVu yZIR3JtRfu0A92h0iX+qBAsT0KGKtVNKYex64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=YU+GgyvDQ6kftb0wa1FkVBEOykklUHmiPMJqe7CMsN8=; b=DoSe2Fm3fW1IGaVAazRTF9PqFkTNSb2uImXe8Qxd8134irY/ImalSaaSlkdsLplqhm eAbvhJ+V/Znk1TH5Nc8PcRfcMgKV1z1QWlcwn1EktE0kUg0UXdOtrsd5T6R+UnA8srAy eMuqTiNT1ikNbcGaGIWCGMwL2qOqCFKhQJtV8JKL3l2qRhho6wakosrO4/tJ1iDdglkc CZsq95irzxCAB207hzTXiN10JWW42P9L0lqPEoBEoYdkqNCzK6v/8gKjniHWUfv7bLC+ Tpr+33AJ8q0nmga6loi5mjUXlEAGMbKqbplZRfQPGI/KH33FXj0Uh+yAckQOsDLuSW6a 491g== X-Gm-Message-State: ALoCoQlAGvo9ZP3Q/yUgDKyaLcyUduFsc2ctai3XC7opWoVnjMme09kLZ72iXhvzwvk8Shn4f7a6jDwp5LChQHuel+0EAZSj8Q== X-Received: by 10.140.86.38 with SMTP id o35mr39455038qgd.56.1450284848877; Wed, 16 Dec 2015 08:54:08 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id i141sm2902351qhc.18.2015.12.16.08.54.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Dec 2015 08:54:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: Date: Wed, 16 Dec 2015 11:54:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C88DEEA-F6F2-425A-B456-AFFEDE5840CA@sn3rd.com> References: To: curdle@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 16:54:20 -0000 On Dec 10, 2015, at 12:49, Yoav Nir wrote: >=20 >=20 >> On 10 Dec 2015, at 6:46 PM, Phillip Hallam-Baker = wrote: >>=20 >> Was just rejigging some OID management stuff in a library and noticed = that I hadn't put them in yet.=20 >>=20 >> While I don't expect to make much use of SHA3 with RSA, that is all I = have that is testable at present. I don't think the CFRG process is at = the stage where we would want to cut OIDs. >=20 > Looking in oid-info.com, I see this: = http://oid-info.com/get/1.2.840.113549.1.1 >=20 > No one has bothered to register SHA-3 here, which I take as further = evidence that people don=E2=80=99t care about SHA-3. >=20 > Yoav I haven=E2=80=99t seen any OIDs for SHA-3 with RSA but the standalone = SHA-3 OIDs can be found here: http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html spt From nobody Wed Dec 16 09:31:13 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58C1A1BAF for ; Wed, 16 Dec 2015 09:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wlr4zarUbANv for ; Wed, 16 Dec 2015 09:31:10 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837E61A1ADF for ; Wed, 16 Dec 2015 09:31:10 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id yq9so10989246lbb.3 for ; Wed, 16 Dec 2015 09:31:10 -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:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=b2PijcWwNf5nZoa8BSobqOJgD2ee82Ol8WEqbi1O7nU=; b=kqzFnIW1iafZo3Qj3fWrrSjX2gTTZl+eXW9AqwylHScDegS6WHEux04T84LI/EmIpJ 4KXt7O0yaRzZKExRi6w885HMrqOxICjaij3fyXv8qbzyOSCh0lMHwn5rlOv1gRQaUvjf ihs2K0bU3WZLeHDK1TCUGKkmXZZAX46ZBjk4aBso1UQK5kCOIzmUm7CsbWoOMIz32Lmi KJNfqLAHDxqyhYym2nfuWBeCuXXRVrkSFywTRTB+5JefdsN1LD67nMklmRBcwFvecH35 Wnk74kmEBjEikINkQ/hspC4sh+u8/6npHWShRdFlPzmFWU3ErcT5T0xCozxAsh1H8z9m gBmQ== MIME-Version: 1.0 X-Received: by 10.112.199.194 with SMTP id jm2mr15597216lbc.109.1450287068708; Wed, 16 Dec 2015 09:31:08 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Wed, 16 Dec 2015 09:31:08 -0800 (PST) In-Reply-To: <1C88DEEA-F6F2-425A-B456-AFFEDE5840CA@sn3rd.com> References: <1C88DEEA-F6F2-425A-B456-AFFEDE5840CA@sn3rd.com> Date: Wed, 16 Dec 2015 12:31:08 -0500 X-Google-Sender-Auth: t24ln6-Xtu53KOe4dzlcg87B46c Message-ID: From: Phillip Hallam-Baker To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:31:12 -0000 On Wed, Dec 16, 2015 at 11:54 AM, Sean Turner wrote: > On Dec 10, 2015, at 12:49, Yoav Nir wrote: >> >> >>> On 10 Dec 2015, at 6:46 PM, Phillip Hallam-Baker wrote: >>> >>> Was just rejigging some OID management stuff in a library and noticed t= hat I hadn't put them in yet. >>> >>> While I don't expect to make much use of SHA3 with RSA, that is all I h= ave that is testable at present. I don't think the CFRG process is at the s= tage where we would want to cut OIDs. >> >> Looking in oid-info.com, I see this: http://oid-info.com/get/1.2.840.113= 549.1.1 >> >> No one has bothered to register SHA-3 here, which I take as further evid= ence that people don=E2=80=99t care about SHA-3. >> >> Yoav > > I haven=E2=80=99t seen any OIDs for SHA-3 with RSA but the standalone SHA= -3 OIDs can be found here: > > http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html I saw those. What I want to know is if anyone has cut some OIDs for RSA and if so what they are. Otherwise I would like some cut on the IETF arc because I want to be able to use SHA3-512 as my backup digest scheme to SHA2-512. But I do not want the IETF to cut any if there are plans to do that elsewhe= re. A draft should be very short, basically, do exactly what you would for SHA2 with SHA3 instead. From nobody Wed Dec 16 09:44:59 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860DA1A1EF7 for ; Wed, 16 Dec 2015 09:44:58 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjiEv96OOgVE for ; Wed, 16 Dec 2015 09:44:54 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049FE1A6FFC for ; Wed, 16 Dec 2015 09:44:37 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.355.16; Wed, 16 Dec 2015 17:44:10 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0355.012; Wed, 16 Dec 2015 17:44:12 +0000 From: "Dang, Quynh" To: Sean Turner , "curdle@ietf.org" Thread-Topic: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? Thread-Index: AQHROCJrALeMBOsGsEWIzyYyEkkA957N4GZ1 Date: Wed, 16 Dec 2015 17:44:12 +0000 Message-ID: References: , <1C88DEEA-F6F2-425A-B456-AFFEDE5840CA@sn3rd.com> In-Reply-To: <1C88DEEA-F6F2-425A-B456-AFFEDE5840CA@sn3rd.com> 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=quynh.dang@nist.gov; x-originating-ip: [129.6.222.126] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:et6IQjvg7Otlq76JGHyJYk0UFHOYCMIA7sVhXYBHevEFS+S0QLaUYoDKJQLWJIKM8+Z5X9o3Tjmj6OPPQ0tSSnCYLtf6CuoIvt3bRukrVxwfQ0noV1cxgi9L0tg/uowIM07o0Qx3eucNOxdTAlHrfg==; 24:dlhCv+dNAUPISb7wACWtEpeWsInIXi07yWNXBs+enclM76sXxfxj9Zbg93NRwKf8qXKuPM/E7t+5z36iyAKBiX7/fhzZcHIKiW7bnkkfuec= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(377454003)(2501003)(54356999)(102836003)(3846002)(2950100001)(2900100001)(50986999)(15975445007)(77096005)(106116001)(99286002)(106356001)(76176999)(105586002)(1096002)(5008740100001)(76576001)(6116002)(586003)(1220700001)(92566002)(5004730100002)(86362001)(15188555004)(10400500002)(101416001)(87936001)(40100003)(189998001)(81156007)(122556002)(74316001)(107886002)(97736004)(5001960100002)(5001770100001)(19580395003)(33656002)(19580405001)(66066001)(5003600100002)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2015 17:44:12.5667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:44:58 -0000 Hi Sean, On our website at http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.htm= l, we stated that "The XOFs can be specialized to hash functions, subject t= o additional security considerations. Guideline for using the XOFs will be = provided in the future." The XOFs are the SHAKE128 and SHAKE256. We are working on a guideline for t= he SHAKEs when being used as hash functions.=20 Quynh.=20 ________________________________________ From: Curdle on behalf of Sean Turner Sent: Wednesday, December 16, 2015 11:54 AM To: curdle@ietf.org Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with RSA E= ncryption? On Dec 10, 2015, at 12:49, Yoav Nir wrote: > > >> On 10 Dec 2015, at 6:46 PM, Phillip Hallam-Baker = wrote: >> >> Was just rejigging some OID management stuff in a library and noticed th= at I hadn't put them in yet. >> >> While I don't expect to make much use of SHA3 with RSA, that is all I ha= ve that is testable at present. I don't think the CFRG process is at the st= age where we would want to cut OIDs. > > Looking in oid-info.com, I see this: http://oid-info.com/get/1.2.840.1135= 49.1.1 > > No one has bothered to register SHA-3 here, which I take as further evide= nce that people don=92t care about SHA-3. > > Yoav I haven=92t seen any OIDs for SHA-3 with RSA but the standalone SHA-3 OIDs = can be found here: http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html spt _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle= From nobody Wed Dec 16 12:04:57 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67F61A8965 for ; Wed, 16 Dec 2015 12:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSK5YJLWcKRj for ; Wed, 16 Dec 2015 12:04:54 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E841A8989 for ; Wed, 16 Dec 2015 12:03:12 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B1CD738F03; Wed, 16 Dec 2015 12:03:11 -0800 (PST) From: "Jim Schaad" To: "'Phillip Hallam-Baker'" , "'Sean Turner'" References: <1C88DEEA-F6F2-425A-B456-AFFEDE5840CA@sn3rd.com> In-Reply-To: Date: Wed, 16 Dec 2015 12:00:27 -0800 Message-ID: <001a01d1383c$68bc0200$3a340600$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGqAgvE/HnVjX/fJFE3HZBJIZmmPwFaQdGSAdpB3qQCMt4EnZ7xOOgw Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 20:04:56 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Phillip = Hallam- > Baker > Sent: Wednesday, December 16, 2015 9:31 AM > To: Sean Turner > Cc: curdle@ietf.org > Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with = RSA > Encryption? >=20 > On Wed, Dec 16, 2015 at 11:54 AM, Sean Turner wrote: > > On Dec 10, 2015, at 12:49, Yoav Nir wrote: > >> > >> > >>> On 10 Dec 2015, at 6:46 PM, Phillip Hallam-Baker = > wrote: > >>> > >>> Was just rejigging some OID management stuff in a library and = noticed that I > hadn't put them in yet. > >>> > >>> While I don't expect to make much use of SHA3 with RSA, that is = all I have > that is testable at present. I don't think the CFRG process is at the = stage where > we would want to cut OIDs. > >> > >> Looking in oid-info.com, I see this: > >> http://oid-info.com/get/1.2.840.113549.1.1 > >> > >> No one has bothered to register SHA-3 here, which I take as further = evidence > that people don=E2=80=99t care about SHA-3. > >> > >> Yoav > > > > I haven=E2=80=99t seen any OIDs for SHA-3 with RSA but the = standalone SHA-3 OIDs can > be found here: > > > > = http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html >=20 > I saw those. >=20 > What I want to know is if anyone has cut some OIDs for RSA and if so = what they > are. Otherwise I would like some cut on the IETF arc because I want to = be able > to use SHA3-512 as my backup digest scheme to SHA2-512. Why would one every need to cut any RSA OIDs. They are not needed for = PSS and we should not be using SHA3 with v1.5 signatures. Jim >=20 > But I do not want the IETF to cut any if there are plans to do that = elsewhere. >=20 > A draft should be very short, basically, do exactly what you would for > SHA2 with SHA3 instead. >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Dec 16 12:39:21 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30A51A8A0B for ; Wed, 16 Dec 2015 12:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMxEmK4LU1sf for ; Wed, 16 Dec 2015 12:39:19 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 CCC921A8A04 for ; Wed, 16 Dec 2015 12:39:18 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id 21so44785490qgx.1 for ; Wed, 16 Dec 2015 12:39:18 -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:date:message-id:subject :from:to:cc:content-type; bh=EKi5GLfRce2rCtB83BGBYGXe1KadYUxgMcGS+kAuiTk=; b=jMuwec/ukROGr3l5vfrUxTzuzaSO8gNx46L8SFr5cv6WZrf8m5KS6kjSkVdX+zguS7 OVdZ/U4ratACljHvbjr7sqckLUXqapp8of4VPYCsPq12lkOSikiJl/V1gIDOxDLswzax 8oVbs2RPqMnoVkxgI9uQShbp2l1FheN9WUiFQJ4DKMNI4Y63r3eYvJwteYmitsqAQL7a V2GEZeDWZsI/MsZIosul5lZLai2OEwabK4eaizfTXuWRT8Ob3GUrFMDy2yuOn5kunARr m6+S1/mQ8ZQnqbfupTiddUkbp5EY4WTC0VgyYYfN9eRrxp4nuCz9gH+Jt4oLFXDMs5S4 BsVg== MIME-Version: 1.0 X-Received: by 10.140.84.40 with SMTP id k37mr62476229qgd.33.1450298357986; Wed, 16 Dec 2015 12:39:17 -0800 (PST) Sender: hallam@gmail.com Received: by 10.140.101.174 with HTTP; Wed, 16 Dec 2015 12:39:17 -0800 (PST) In-Reply-To: <001a01d1383c$68bc0200$3a340600$@augustcellars.com> References: <1C88DEEA-F6F2-425A-B456-AFFEDE5840CA@sn3rd.com> <001a01d1383c$68bc0200$3a340600$@augustcellars.com> Date: Wed, 16 Dec 2015 15:39:17 -0500 X-Google-Sender-Auth: gI2ZM1oVhnfi_ZLCOEossjIOV1k Message-ID: From: Phillip Hallam-Baker To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: curdle@ietf.org, Sean Turner Subject: Re: [Curdle] Does anyone have the one true OID for SHA3 with RSA Encryption? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 20:39:19 -0000 On Wed, Dec 16, 2015 at 3:00 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Phillip >> What I want to know is if anyone has cut some OIDs for RSA and if so what they >> are. Otherwise I would like some cut on the IETF arc because I want to be able >> to use SHA3-512 as my backup digest scheme to SHA2-512. > > Why would one every need to cut any RSA OIDs. They are not needed for PSS and we should not be using SHA3 with v1.5 signatures. Ah right, RSASSA-PSS-params has the slot for the digest algorithm so the combo OIDs are no longer needed! That simplifies things. From nobody Wed Dec 16 12:59:07 2015 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 8BC741A8A1E; Wed, 16 Dec 2015 12:59:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 12:59:06 -0800 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 20:59:06 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-curdle-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-curdle/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The change I had discussed with Stephen when we reviewed this last time doesn't seem to have been made. https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-03.txt From nobody Wed Dec 16 13:15:12 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FFD1A8A75; Wed, 16 Dec 2015 13:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ5eEunB05e6; Wed, 16 Dec 2015 13:15:06 -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 E841A1A8A4C; Wed, 16 Dec 2015 13:15:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B3D6CBE7C; Wed, 16 Dec 2015 21:15:00 +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 219l5kK8AZmc; Wed, 16 Dec 2015 21:14:59 +0000 (GMT) Received: from [127.0.0.1] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BE8D4BE7B; Wed, 16 Dec 2015 21:14:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450300499; bh=Js6JZ1uA35IUxHcgTlU9LaWH7HdNlAsqHYzPde5CspY=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=XfZDXNyW5S+Gm0Qm2PZuKrrgjquII2+KZRKEm6HqqhEdZNk01nelJOXZ9AMiFL4Jc PyauApP6U+pAFPVN7JWuZ32m06MaZxr+dGEkdma4L01xtMLtfZ471Mazo6lodCud7p uG/Az5Ry5AQ7vDqTRNQ35XLW16uNfQ/zg8kVCEBI= X-Priority: 3 To: alissa@cooperw.in From: stephen.farrell@cs.tcd.ie In-Reply-To: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> References: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 16 Dec 2015 21:14:55 +0000 Message-ID: <6bmzm7.nzgz0y.2vaeqj-qmf@mercury.scss.tcd.ie> MIME-Version: 1.0 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, iesg@ietf.org Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 21:15:08 -0000 DQoNCk9uIFdlZCBEZWMgMTYgMjA6NTk6MDYgMjAxNSBHTVQsIEFsaXNzYSBDb29wZXIgd3JvdGU6 DQo+IEFsaXNzYSBDb29wZXIgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yDQo+IGNoYXJ0ZXItaWV0Zi1jdXJkbGUtMDAtMDQ6IE5vIE9iamVjdGlvbg0KPiANCj4g V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KPiANCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIg YmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1jdXJkbGUvDQo+IA0KPiANCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhlIGNoYW5nZSBJ IGhhZCBkaXNjdXNzZWQgd2l0aCBTdGVwaGVuIHdoZW4gd2UgcmV2aWV3ZWQgdGhpcyBsYXN0IHRp bWUNCj4gZG9lc24ndCBzZWVtIHRvIGhhdmUgYmVlbiBtYWRlLg0KDQpTb3JyeSB0aG91Z2h0IEkg aGFkLiBXaWxsIGNoZWNrIGxhdGVyLg0KUy4NCg0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMT1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGY2hh cnRlci1pZXRmLWN1cmRsZSUyRndpdGhtaWxlc3RvbmVzLTAwLTAyLnR4dCZ1cmwyPWh0dHBzJTNB JTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZjaGFydGVyLWlldGYtY3VyZGxlJTJG d2l0aG1pbGVzdG9uZXMtMDAtMDMudHh0DQo+IA0KPiANCj4= From nobody Wed Dec 16 13:51:29 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE121A8BC2; Wed, 16 Dec 2015 13:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRezg5rr9SEV; Wed, 16 Dec 2015 13:51:22 -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 366251A8BB7; Wed, 16 Dec 2015 13:51:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7EF44BE7C; Wed, 16 Dec 2015 21:51:20 +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 wZsd2Fr4hlm6; Wed, 16 Dec 2015 21:51:19 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65F25BE51; Wed, 16 Dec 2015 21:51:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450302679; bh=uKKshBKmgpxDL8jsoZahW4ISLxnsJpXyCZvep80LjWQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=obuMDIJtdgvUlxYv69/b3ER3e9NlE+2BnbtMCMnWyjSIBLIWdfrkG9LVLCO9VPvkY KFn1Is4sXGmlu5lUSrkZvdCOrrWdug+A16HH+v4IArzcwKY2w7qO8zcfADR9e07uT+ fRLsjQhT7wwoEfB73GeBLL4aNHCwhITePgi+K18I= To: Alissa Cooper , The IESG References: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5671DCD5.8090808@cs.tcd.ie> Date: Wed, 16 Dec 2015 21:51:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 21:51:24 -0000 On 16/12/15 20:59, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-curdle-00-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-curdle/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The change I had discussed with Stephen when we reviewed this last time > doesn't seem to have been made. Hmm - the diff below is 02 vs 03 which is the one you thought was ok on Dec 2nd. [2] Can you check 02 v. 04 [1] 'cause I think that does have the change. But still happy to do more improve if that's needed. Cheers, S. [1] https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-04.txt [2] https://mailarchive.ietf.org/arch/msg/curdle/UsDZaLVUYoEu9mTOr4KLqpYpj1c > https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-03.txt > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From nobody Wed Dec 16 14:08:15 2015 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 362011A8F40; Wed, 16 Dec 2015 14:06:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216220658.6391.64610.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 14:06:58 -0800 Archived-At: X-Mailman-Approved-At: Wed, 16 Dec 2015 14:08:14 -0800 Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: [Curdle] Spencer Dawkins' Yes on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 22:06:58 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-curdle-00-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-curdle/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The more we discuss this charter, the more I think we should do it. That could be a good sign :-) From nobody Wed Dec 16 14:13:47 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC71A8FD3 for ; Wed, 16 Dec 2015 14:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y--FTmeFwrSW for ; Wed, 16 Dec 2015 14:13:45 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A49C1A8F4B for ; Wed, 16 Dec 2015 14:13:45 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8C09D2189B for ; Wed, 16 Dec 2015 17:07:12 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 16 Dec 2015 17:07:12 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=crg1K A6pBUOA7cCBN7EodguEdOQ=; b=zqkMYMmUox2pXXz1qUWSCy1n82/u1jvulSzqA nZd2XRPq+ifGnXC3yf5L2i2bd7ZzA+hkFA+jFTDAuakp2JolemGnTaxRWyfmYkyQ 8f07uvf+vf+6B0TNfx9BGZl5ju5ThN963cwZd71cXLj7b3PjGdSiPKrfCUfAQm9w 8UBkdE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=crg1KA6pBUOA7cCBN7EodguEdOQ=; b=UtvIo 2FQR1crU/ViOfdWLrcPTzxll4DhSWvDmVaNEcAbd1TIxMa5wzdlmZtajuCf+qyXj MEr1F2BR+Q5J7TWytjBsT+uYchBrSljr4CAYX6914iNgpnfybEbh7T77XR2nDhwW OHfuL1Xb/Vj0oVSLCdFdUsrFFcotsovkfit7w4= X-Sasl-enc: eopggoSoWTAu52A2x1WHQRZJKvGCvwlX9c1Hhyaf5xzN 1450303618 Received: from dhcp-10-150-9-247.cisco.com (unknown [173.38.117.88]) by mail.messagingengine.com (Postfix) with ESMTPA id 6525DC016C4; Wed, 16 Dec 2015 17:06:53 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BD74EE13-E8A0-4836-9E1C-435227EBE609" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <5671DCD5.8090808@cs.tcd.ie> Date: Wed, 16 Dec 2015 17:06:44 -0500 Message-Id: References: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> <5671DCD5.8090808@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, IESG Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 22:13:46 -0000 --Apple-Mail=_BD74EE13-E8A0-4836-9E1C-435227EBE609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 16, 2015, at 4:51 PM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 16/12/15 20:59, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> charter-ietf-curdle-00-04: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-curdle/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> The change I had discussed with Stephen when we reviewed this last = time >> doesn't seem to have been made. >=20 > Hmm - the diff below is 02 vs 03 which is the one you thought was ok = on > Dec 2nd. [2] Can you check 02 v. 04 [1] 'cause I think that does have > the change. But still happy to do more improve if that's needed. The -04 says The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML = Digital Signatures and potentially Kerberos and JSON. which is almost the same text that I found problematic in the -02.=09 >=20 > Cheers, > S. >=20 > [1] > = https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fd= oc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=3Dhttps%3A%2F%2Fd= atatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-04.txt= > [2] = https://mailarchive.ietf.org/arch/msg/curdle/UsDZaLVUYoEu9mTOr4KLqpYpj1c >=20 >> = https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fd= oc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=3Dhttps%3A%2F%2Fd= atatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-03.txt= >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >>=20 --Apple-Mail=_BD74EE13-E8A0-4836-9E1C-435227EBE609 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Dec 16, 2015, at 4:51 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



On 16/12/15 20:59, Alissa Cooper wrote:
Alissa Cooper has = entered the following ballot position for
charter-ietf-curdle-00-04: No Objection

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)



The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-curdle/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

The change I had discussed with = Stephen when we reviewed this last time
doesn't seem to = have been made.

Hmm - the diff = below is 02 vs 03 which is the one you thought was ok on
Dec= 2nd. [2] Can you check 02 v. 04 [1] 'cause I think that does have
the change. But still happy to do more improve if that's = needed.

The -04 says

The protocols in scope are Secure Shell (SSH), =
DNSSEC, PKIX, CMS, XML Digital
Signatures and potentially Kerberos and JSON.
which = is almost the same text that I found problematic in the -02. =


Cheers,
S.

[1]
https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=3D= https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmiles= tones-00-04.txt
[2] = https://mailarchive.ietf.org/arch/msg/curdle/UsDZaLVUYoEu9mTOr4KLqpYpj1c
https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.i= etf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-02.txt&url2=3D= https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmiles= tones-00-03.txt


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


= --Apple-Mail=_BD74EE13-E8A0-4836-9E1C-435227EBE609-- From nobody Wed Dec 16 14:28:00 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58ACB1A9028; Wed, 16 Dec 2015 14:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNOzocqJdPQz; Wed, 16 Dec 2015 14:27:54 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA6C1A9026; Wed, 16 Dec 2015 14:27:53 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id p203so40117296lfa.0; Wed, 16 Dec 2015 14:27:53 -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:date:message-id:subject :from:to:cc:content-type; bh=QONSQsDYOCkATceMTOkf5mDJSr/WCBncJ5+qjLBRurw=; b=nI8L4gdvhupICZo17i6uO6CB9prbQXUOlFzi6cJsVAHSJtKj01ezH4/alarNaaIwO6 ycc/oNp3QkAkMiJYHaZvaI5a5PStUwen7csg3/G+ESelhbioJwepQtNn3jbbKCIl9wZy G7SLawzBGy2bQTbeNqq80kEHKX9AgbNZWHtBb9bZ8qVeqq/MRP1NZGPprnCP63WgZJc+ c2M0LGV619jqRyvB4cY4+OEQH9BsIVy00G1wm27XtMapYyDGzRtu0aEOnuJvUJFadSoM 2403fsXVYqLoaWsAPV3SSTQjsukyVvyf3skgv0eQ09VWoXV59m4S2Ss+facKs73cpaXQ Lw+w== MIME-Version: 1.0 X-Received: by 10.25.156.73 with SMTP id f70mr19970433lfe.70.1450304871884; Wed, 16 Dec 2015 14:27:51 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Wed, 16 Dec 2015 14:27:51 -0800 (PST) In-Reply-To: References: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> <5671DCD5.8090808@cs.tcd.ie> Date: Wed, 16 Dec 2015 17:27:51 -0500 X-Google-Sender-Auth: FUa3lZtfqybatax17NM_TneUe4E Message-ID: From: Phillip Hallam-Baker To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, IESG , Stephen Farrell Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 22:27:55 -0000 On Wed, Dec 16, 2015 at 5:06 PM, Alissa Cooper wrote: > > On Dec 16, 2015, at 4:51 PM, Stephen Farrell > wrote: > > > > On 16/12/15 20:59, Alissa Cooper wrote: > > Alissa Cooper has entered the following ballot position for > charter-ietf-curdle-00-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-curdle/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The change I had discussed with Stephen when we reviewed this last time > doesn't seem to have been made. > > > Hmm - the diff below is 02 vs 03 which is the one you thought was ok on > Dec 2nd. [2] Can you check 02 v. 04 [1] 'cause I think that does have > the change. But still happy to do more improve if that's needed. > > > The -04 says > > The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML > Digital > Signatures and potentially Kerberos and JSON. > > which is almost the same text that I found problematic in the -02. I agree. Stating the scope should be separate from stating priorities: The WG scope is limited to the following protocols: Secure Shell (SSH), DNSSEC, PKIX, CMS, XML Digital Signatures, Kerberos and JSON. The WG is not required to address every protocol in scope nor is it required to address every possible combination of protocol and algorithm. From nobody Wed Dec 16 14:30:01 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B6F1A9027; Wed, 16 Dec 2015 14:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mtzP_QLrmp6; Wed, 16 Dec 2015 14:29:59 -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 EF9F31A8AD2; Wed, 16 Dec 2015 14:29:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3AA8BE7D; Wed, 16 Dec 2015 22:29:56 +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 K_o6Qxv3GOOY; Wed, 16 Dec 2015 22:29:56 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 41F95BE7C; Wed, 16 Dec 2015 22:29:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450304995; bh=zEwKZC5x34rzaRxnTxfr6SPFKOivw2C4ETaMzlkbUOo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=sNzWMjSc+xREKGa9fG7WqICvaDa5DhEVZBTr5EHFkOVwATHSVvk8N3LgxShU+LYsl v5uOKikde7gDCk5AATFyLCZLW9rm3PWDzSFKyfbmfBsdKkUsFhcSKtUWx48kdtsHwn XMpqZUW30H24xhcepA6AjlX23DwvvRLnNpdrW4tg= To: Phillip Hallam-Baker , Alissa Cooper References: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> <5671DCD5.8090808@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5671E5E2.2080203@cs.tcd.ie> Date: Wed, 16 Dec 2015 22:29:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, IESG Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 22:30:01 -0000 Thanks for the text Phil. On 16/12/15 22:27, Phillip Hallam-Baker wrote: > The WG scope is limited to the following protocols: Secure Shell > (SSH), DNSSEC, PKIX, CMS, XML Digital Signatures, Kerberos and JSON. > > The WG is not required to address every protocol in scope nor is it > required to address every possible combination of protocol and > algorithm. I'd be fine with adding the above. Would that fix your issue Alissa? Ta, S. From nobody Wed Dec 16 14:32:40 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784021A903C; Wed, 16 Dec 2015 14:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scKXOicx79dH; Wed, 16 Dec 2015 14:31:09 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 34E431A903B; Wed, 16 Dec 2015 14:31:09 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C016C200009; Wed, 16 Dec 2015 22:31:08 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id AA1A5200001; Wed, 16 Dec 2015 22:31:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1450305068; bh=Pst44VnfxF4//cj45sBv8GIUeHoUlsP4CkGbgsZNRmI=; l=654; h=From:To:CC:Date:References:In-Reply-To:From; b=DrKLTHjgfbwZAgvQdyIO+v8ycoLCQ7IPhXqV4Vr+Gqjfxw6worq8jIjxRH4j+hulR u+pjR6avZTq4BGKoZ8+uS+3xu7VOR14kN7gcB5LACXtX1kbdi7BMpCsMmBX520SzIX fhyhTE0qnJ9BHG2i62L+HXItnxpXhnk9kKainRe8= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 911F51E07C; Wed, 16 Dec 2015 22:31:08 +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.1076.9; Wed, 16 Dec 2015 17:31:07 -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.1076.000; Wed, 16 Dec 2015 17:31:07 -0500 From: "Salz, Rich" To: Stephen Farrell , Phillip Hallam-Baker , Alissa Cooper Thread-Topic: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) Thread-Index: AQHROESbHfisaqGSiUyvTomWz3+4E57OexCAgAAEUQCAAAXmgIAAAJMA//+sX3A= Date: Wed, 16 Dec 2015 22:31:07 +0000 Message-ID: References: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> <5671DCD5.8090808@cs.tcd.ie> <5671E5E2.2080203@cs.tcd.ie> In-Reply-To: <5671E5E2.2080203@cs.tcd.ie> 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.32.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 16 Dec 2015 14:32:38 -0800 Cc: "curdle@ietf.org" , "curdle-chairs@ietf.org" , IESG Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 22:31:10 -0000 PiBPbiAxNi8xMi8xNSAyMjoyNywgUGhpbGxpcCBIYWxsYW0tQmFrZXIgd3JvdGU6DQo+ID4gVGhl IFdHIHNjb3BlIGlzIGxpbWl0ZWQgdG8gdGhlIGZvbGxvd2luZyBwcm90b2NvbHM6IFNlY3VyZSBT aGVsbA0KPiA+IChTU0gpLCBETlNTRUMsIFBLSVgsIENNUywgWE1MIERpZ2l0YWwgU2lnbmF0dXJl cywgS2VyYmVyb3MgYW5kIEpTT04uDQoNCkFuZCAiWE1MIEVuY3J5cHRpb24iDQoNCj4gPg0KPiA+ IFRoZSBXRyBpcyBub3QgcmVxdWlyZWQgdG8gYWRkcmVzcyBldmVyeSBwcm90b2NvbCBpbiBzY29w ZSBub3IgaXMgaXQNCj4gPiByZXF1aXJlZCB0byBhZGRyZXNzIGV2ZXJ5IHBvc3NpYmxlIGNvbWJp bmF0aW9uIG9mIHByb3RvY29sIGFuZA0KPiA+IGFsZ29yaXRobS4NCj4gDQo+IEknZCBiZSBmaW5l IHdpdGggYWRkaW5nIHRoZSBhYm92ZS4gV291bGQgdGhhdCBmaXggeW91ciBpc3N1ZSBBbGlzc2E/ DQo+IA0KPiBUYSwNCj4gUy4NCg== From nobody Wed Dec 16 16:12:41 2015 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 DBE501A92EA; Wed, 16 Dec 2015 16:12:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217001240.31458.76538.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 16:12:40 -0800 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org Subject: [Curdle] Ben Campbell's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 00:12:41 -0000 Ben Campbell has entered the following ballot position for charter-ietf-curdle-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-curdle/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also would like to see Alissa's previous comment addressed (about why Kerberos and JSON are only "potentially" in scope.) From nobody Wed Dec 16 19:39:23 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569EE1AC429 for ; Wed, 16 Dec 2015 19:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49Qm9usylEbe for ; Wed, 16 Dec 2015 19:39:16 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68D61AC424 for ; Wed, 16 Dec 2015 19:39:16 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9A1A120379 for ; Wed, 16 Dec 2015 22:39:15 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 16 Dec 2015 22:39:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=iVTb3jrOyQu65ZQNoB/gAorrtqE=; b=sbpn0G DqHtvj/0toxOVrUaGE4nnYE9RbiK8kvBzPS0fTShwuJY5ZwejKmacYL4saUaJVAZ +AtqJdyNPYqjiz7C2IGKjfNSVGGwMHS0QBDxmPQaTzbTk7VilBYz6UXpFrcGMni5 6xsaN1toL9RB0bSzzG/vospApDI6zny4pxWu0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=iVTb3jrOyQu65ZQ NoB/gAorrtqE=; b=p+yJyUaIeeapJuNbOI2KfrSS35PX/sq3ofI5qJoeVUK/xP1 tmkzjnma+DwId9m1RPDp2j+xTF3bRBsV1osqYFwQs9q1UtIYDVHiLCmQ+3s7pm+t FDM1ZuCTL4nbmct/6qo0bDyjO84MVSrfWHuelB8KXb9AnT45FHZsLo2b+sY0= X-Sasl-enc: RVDPocfPKMe5xedL3IhgV2dtElnvThLxjemjc1zPiplC 1450323554 Received: from [10.24.94.61] (unknown [128.107.241.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 5DB2E6800F8; Wed, 16 Dec 2015 22:39:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <5671E5E2.2080203@cs.tcd.ie> Date: Wed, 16 Dec 2015 22:35:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6673A71E-F21B-4FE1-9334-20BC4EDDF255@cooperw.in> References: <20151216205906.25944.74787.idtracker@ietfa.amsl.com> <5671DCD5.8090808@cs.tcd.ie> <5671E5E2.2080203@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: curdle@ietf.org, Phillip Hallam-Baker , curdle-chairs@ietf.org, IESG Subject: Re: [Curdle] Alissa Cooper's No Objection on charter-ietf-curdle-00-04: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 03:39:18 -0000 > On Dec 16, 2015, at 5:29 PM, Stephen Farrell = wrote: >=20 >=20 > Thanks for the text Phil. >=20 > On 16/12/15 22:27, Phillip Hallam-Baker wrote: >> The WG scope is limited to the following protocols: Secure Shell >> (SSH), DNSSEC, PKIX, CMS, XML Digital Signatures, Kerberos and JSON. >>=20 >> The WG is not required to address every protocol in scope nor is it >> required to address every possible combination of protocol and >> algorithm. >=20 > I'd be fine with adding the above. Would that fix your issue Alissa? Yes. Or if you want to go back to the -03 text it would look like: OLD The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML = Digital Signatures and potentially Kerberos and JSON. NEW The protocols the WG intends to work on are Secure Shell (SSH), DNSSEC, = PKIX, CMS, XML Digital Signatures and potentially Kerberos and JSON. >=20 > Ta, > S. From nobody Thu Dec 17 06:12:25 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95AF1B2DF9; Thu, 17 Dec 2015 06:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2HsJoPn3NHR; Thu, 17 Dec 2015 06:12: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 6F8E61B2B40; Thu, 17 Dec 2015 06:12:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3865BEA4; Thu, 17 Dec 2015 14:12: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 FjHjlXQtPZ9o; Thu, 17 Dec 2015 14:12:06 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DD0C1BEA1; Thu, 17 Dec 2015 14:12:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450361526; bh=ps2ev09fcVO5IUsfVUH0rUKbwqhMtHE4p/tqWlmD0eM=; h=To:Cc:From:Subject:Date:From; b=JSpaEuBPFBiVEX+6o1siiWTtErr0PYpwTeeUPIWvJK/9FQWx+orXK58D2IvXyudiW WxcZHb7t9KxZ5Sg0blQafe9KAwvv8yapvemqYQkWIcTomb9qlNzGkr7tg87lUrY9gL XlP67OaEGZiWLzEoQXBiuPOxWI6R6C27kuZNoyNA= To: IESG From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5672C2B5.2070301@cs.tcd.ie> Date: Thu, 17 Dec 2015 14:12:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: curdle@ietf.org Subject: [Curdle] Updated charter text X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 14:12:17 -0000 Hiya, I've updated the charter text based on IESG comments and one from co-chair Rich. Changes are: - Alissa's clarification done. - All but one of Benoit's changes (I think his suggestion for the one I didn't adopt would be less clear to this Irish-English speaker:-) - Added a mention of XML encryption and that we need to check with W3C before doing stuff on that or xmldsig. (I know that Simon has been in touch with Wendy before but we should formalise that in some mail that goes to the WG list.) Hopefully this is good to go now, assuming the WG do not decide to adopt SHA3 work as suggested by Phil. My take so far is that there is not support for adding SHA3 work to this charter at this point. (If the chairs tell me there's an upwelling of support for doing SHA3 work now, we can handle that but I don't expect it to happen.) Latest diff is at [1]. Cheers, S. [1] https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-04.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-curdle%2Fwithmilestones-00-05.txt From nobody Fri Dec 18 08:54:28 2015 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 7F96D1B371A; Fri, 18 Dec 2015 08:52:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151218165200.24085.7127.idtracker@ietfa.amsl.com> Date: Fri, 18 Dec 2015 08:52:00 -0800 Archived-At: X-Mailman-Approved-At: Fri, 18 Dec 2015 08:54:27 -0800 Cc: curdle@ietf.org, curdle-chairs@ietf.org, The IESG Subject: [Curdle] WG Action: Formed CURves, Deprecating and a Little more Encryption (curdle) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2015 16:52:00 -0000 A new IETF working group has been formed in the Security Area. For additional information please contact the Area Directors or the WG Chairs. CURves, Deprecating and a Little more Encryption (curdle) ------------------------------------------------ Current Status: Proposed WG Chairs: Daniel Migault Rich Salz Assigned Area Director: Stephen Farrell Mailing list Address: curdle@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/curdle Archive: https://mailarchive.ietf.org/arch/browse/curdle/ Charter: CURDLE - CURves, Deprecating and a Little more Encryption The CURDLE working group is chartered to add a small set of cryptographic mechanisms to some IETF protocols, and to make implementation requirements including deprecation of old algorithms where there is IETF consensus to do so. The focus with regards to adding mechanisms is for those mechanisms that enjoy broad support from implementers. The set of cryptographic mechanisms that can be introduced are limited to key agreement (ECDH) and digital signatures (EdDSA) with Curve25519 and Curve448 as defined by CFRG [1] [2], and the AEAD mode ciphers consisting of ChaCha20 and Poly1305 also defined by CFRG [3]. Other variants of mechanisms, such as the ChaCha20-Poly1305 construct deployed for SSH, may also be considered as well as AES-CCM[4] and AES-GCM [5] where those are not already defined and where there is implementer interest. Related specifications such as private and public key formats are also within scope. The protocols the WG intends to work on are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML Digital Signatures and potentially XML Encryption, Kerberos and JSON. Where initial drafts for this work have been produced those will be immediately considered for adoption as working group documents. These include, for SSH, Curve25519/Curve448 digital signatures [6] and key exchange [7]; for DNSSEC, Ed25519 [8] and Curve448 [9]; for PKIX, Curve25519/448 NamedCurve [10] and EdDSA signatures [11]; for JSON curves and signatures [12]. The CURDLE working group will be handling changes to protocols and registries some of which include what are now considered outdated algorithm options, and may propose deprecation of such algorithms. Such deprecation needs to be done with care, ensuring that interoperability and the needs of existing implementers and deployments are properly considered. Where deprecation is practical, the working group is encouraged to deprecate. Where there is an IETF working group or area group with expertise in a relevant topic the CURDLE working group will defer to the consensus of the more specific working group as to where work will be done. For example, the TLS, OpenPGP and IPSECME WGs are actively considering some of these topics. The CURDLE working group will liaise with W3C to ensure that XML digital signature and XML encryption work does not conflict with W3C. The CURDLE working group is expected to be a short-lived working group that may not need to ever meet face-to-face. Once the work on the initially adopted set of drafts has completed the working group will close or re-charter. The CURDLE working group is not chartered to consider allocating new codepoints for any algorithms or modes other than those mentioned above. Should someone wish to propose such work, a re-charter will be required. At this time, there is no expectation that such a re-charter will be requested. [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves [2] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 [3] RFC 7539 [4] RFC 3610 [5] RFC5288 [6] https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 [7] https://tools.ietf.org/html/draft-josefsson-ssh-curves-00 [8] https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03 [9] https://tools.ietf.org/html/draft-sury-dnskey-ed448-00 [10] https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 [11] https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 [12] http://www.ietf.org/mail-archive/web/jose/current/msg05357.html Milestones: Jan 2016 - Decision on which drafts to adopt Jun 2016 - Send last draft to IESG From nobody Fri Dec 18 08:57:09 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A4E1B3745 for ; Fri, 18 Dec 2015 08:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWMeE56O88Jx for ; Fri, 18 Dec 2015 08:57:06 -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 1A8431B3746 for ; Fri, 18 Dec 2015 08:57:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0E71EBEDB for ; Fri, 18 Dec 2015 16:57:02 +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 LyeiDgYw-DtU for ; Fri, 18 Dec 2015 16:56:59 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.22.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6D4E1BE51 for ; Fri, 18 Dec 2015 16:56:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450457819; bh=2XF8YSqM4+TXUJRjwBbN9i345RQ2szC+lawM5j+VunQ=; h=Subject:References:To:From:Date:In-Reply-To:From; b=hpsWFtlGOnvKTiSl90xgAUEwvhFKtWCOfgKq4CufkCNp227kLLhVhwNZGwTkH5zRJ 33kEiz85f4R8G6Z0azU9B4sgqXsWUR+c2zEhqzttI4I4fwdpyPBooysA3BGM+3bWDn EgztyIHvRqE9BUeP77k+BwjHqmK7TXMuQSrduY80= References: <20151218165200.24085.7127.idtracker@ietfa.amsl.com> To: curdle@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56743AD9.6@cs.tcd.ie> Date: Fri, 18 Dec 2015 16:56:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151218165200.24085.7127.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Curdle] WG Action: Formed CURves, Deprecating and a Little more Encryption (curdle) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2015 16:57:09 -0000 Thanks all for the help with writing docs and the charter to get this going. And now off you go to get the work done! Cheers, S. On 18/12/15 16:52, The IESG wrote: > A new IETF working group has been formed in the Security Area. For > additional information please contact the Area Directors or the WG > Chairs. > > CURves, Deprecating and a Little more Encryption (curdle) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Daniel Migault > Rich Salz > > Assigned Area Director: > Stephen Farrell > > Mailing list > Address: curdle@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/curdle > Archive: https://mailarchive.ietf.org/arch/browse/curdle/ > > Charter: > > CURDLE - CURves, Deprecating and a Little more Encryption > > The CURDLE working group is chartered to add a small set of cryptographic > mechanisms to some IETF protocols, and to make implementation > requirements including deprecation of old algorithms where there is IETF > consensus to do so. The focus with regards to adding mechanisms is for > those mechanisms that enjoy broad support from implementers. > > The set of cryptographic mechanisms that can be introduced are limited to > key agreement (ECDH) and digital signatures (EdDSA) with Curve25519 and > Curve448 as defined by CFRG [1] [2], and the AEAD mode ciphers consisting > of ChaCha20 and Poly1305 also defined by CFRG [3]. Other variants of > mechanisms, such as the ChaCha20-Poly1305 construct deployed for SSH, may > also be considered as well as AES-CCM[4] and AES-GCM [5] where those are > not already defined and where there is implementer interest. Related > specifications such as private and public key formats are also within > scope. > > The protocols the WG intends to work on are Secure Shell (SSH), DNSSEC, > PKIX, CMS, XML Digital Signatures and potentially XML Encryption, > Kerberos and JSON. > > Where initial drafts for this work have been produced those will be > immediately considered for adoption as working group documents. These > include, for SSH, Curve25519/Curve448 digital signatures [6] and key > exchange [7]; for DNSSEC, Ed25519 [8] and Curve448 [9]; for PKIX, > Curve25519/448 NamedCurve [10] and EdDSA signatures [11]; for JSON curves > and signatures [12]. > > The CURDLE working group will be handling changes to protocols and > registries some of which include what are now considered outdated > algorithm options, and may propose deprecation of such algorithms. Such > deprecation needs to be done with care, ensuring that interoperability > and the needs of existing implementers and deployments are properly > considered. Where deprecation is practical, the working group is > encouraged to deprecate. > > Where there is an IETF working group or area group with expertise in a > relevant topic the CURDLE working group will defer to the consensus of > the more specific working group as to where work will be done. For > example, the TLS, OpenPGP and IPSECME WGs are actively considering some > of these topics. > > The CURDLE working group will liaise with W3C to ensure that XML digital > signature and XML encryption work does not conflict with W3C. > > The CURDLE working group is expected to be a short-lived working group > that may not need to ever meet face-to-face. Once the work on the > initially adopted set of drafts has completed the working group will > close or re-charter. > > The CURDLE working group is not chartered to consider allocating new > codepoints for any algorithms or modes other than those mentioned above. > Should someone wish to propose such work, a re-charter will be required. > At this time, there is no expectation that such a re-charter will be > requested. > > [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves > [2] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00 > [3] RFC 7539 > [4] RFC 3610 > [5] RFC5288 > [6] https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 > [7] https://tools.ietf.org/html/draft-josefsson-ssh-curves-00 > [8] https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03 > [9] https://tools.ietf.org/html/draft-sury-dnskey-ed448-00 > [10] https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 > [11] https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 > [12] http://www.ietf.org/mail-archive/web/jose/current/msg05357.html > > > Milestones: > Jan 2016 - Decision on which drafts to adopt > Jun 2016 - Send last draft to IESG > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From nobody Tue Dec 22 08:54:12 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFBE1A8792 for ; Tue, 22 Dec 2015 08:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehhcI8uDMBwy for ; Tue, 22 Dec 2015 08:54:09 -0800 (PST) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) by ietfa.amsl.com (Postfix) with ESMTP id 032E21A874B for ; Tue, 22 Dec 2015 08:54:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 49A9E1C854 for ; Tue, 22 Dec 2015 17:54:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from :received:received; s=mimas; t=1450803248; x=1468992609; bh=8kMU QdnIzIDzoXof1IMiPkOrKqd1YlSJ1y/CE52lLFE=; b=LajuFfkyTBemBGJOs5JW /fvLt0inXBiP5qiSC1z0kbCBFFmcvfKos+YClDKAJCmEIoIT9sgpNUgBvKS3H0qU 1V2CYgKg7zb4TGl1fykr9odUSZ6fAD3HjMCM5hit+9ut71iA1uxAOIsUgz6vs68D WfV/j4hpogkgbBWHeATcbUnb0QBVCKcYI7ZSem+enxSzG13+VVTwSvq2o4mUk8D9 nKAEeCv7NzidTWNpHrGQuOzeJnWO+AgQ5AdFSOlGRhdKWUkHJaxEEKRqUOC7n6zj 2leDcIolxIGAQ/LNEPtvHmM4UJVmZfSkhJXQdx8smI/IJV3tvK7JxhzN8OS5Yr/i Vg== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 4vd9Oq6sUUXY for ; Tue, 22 Dec 2015 17:54:08 +0100 (CET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 0745D1C0D7 for ; Tue, 22 Dec 2015 17:54:07 +0100 (CET) To: curdle@ietf.org From: Hugo Landau Message-ID: <5679802F.2000106@devever.net> Date: Tue, 22 Dec 2015 16:54:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 16:54:10 -0000 Does this WG intend to provide a storage format for EdDSA private keys? Such a format will certainly be needed. The existing EC ASN.1 format could probably be reused. It is: ECPrivateKey ::= SEQUENCE { version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), privateKey OCTET STRING, parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, publicKey [1] BIT STRING OPTIONAL } Since draft-josefsson-pkix-newcurves has allocated named curve OIDs for the CFRG curves, these OIDs could be used here. On the other hand, since this is essentially an overloading of the semantics of ECPrivateKey, NamedCurve, etc., there could be issues adding support to existing implementations that would be prefer to treat EdDSA substantially differently to NIST ECDSA. Another issue is what it means for a key to be Ed25519 vs. Ed25519ph. Must an Ed25519ph key only be used for prehashed data? The issue, I suppose, is that if you allow the same key to be used for non-prehashed data and prehashed data, you create the potential issue that a signature generated over 64 bytes (assuming SHA512) via Ed25519 could be passed off as an Ed25519ph signature by an attacker. The 'namespaces' conflict. On the other hand, one won't necessarily know, when generating a key, whether prehashing will be used. If a key is used with more than one application, prehashing might be used for one and not the other. From nobody Wed Dec 23 06:45:17 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5DE1A0120 for ; Wed, 23 Dec 2015 06:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMLv_EVec9bp for ; Wed, 23 Dec 2015 06:45:14 -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 4D8991A011D for ; Wed, 23 Dec 2015 06:45:13 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EF6044DE55; Wed, 23 Dec 2015 14:45:12 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id D4B2B4DE4C; Wed, 23 Dec 2015 14:45:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1450881912; bh=sLpoe1KnLjSFl1AiYrZZ/1WCpKIliy2Nbft94NaMwmk=; l=495; h=From:To:Date:References:In-Reply-To:From; b=lEbvFzbvmCjSoahEkyPR6d2wHoEVvxfZRooImQ9FJ0c1zJ8zD/vAGmif1ydsHM8RF e4AD1p5GYFCZXvAh6jmuJfdOMd9Pb078bYj1rDd4SfokrzO7YVkWMXKYDAkO3dUFFz w1N1KblzYENa2HPlUeR/YIRV0+8p4bmtXvSIq4+Q= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id D12332027; Wed, 23 Dec 2015 14:45:12 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 23 Dec 2015 06:45:12 -0800 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.1076.000; Wed, 23 Dec 2015 09:45:12 -0500 From: "Salz, Rich" To: Hugo Landau , "curdle@ietf.org" Thread-Topic: [Curdle] DER/PEM storage format for EdDSA private keys Thread-Index: AQHRPNlkEzyY9fNvckyeyNmSo1icdJ7YpuEA Date: Wed, 23 Dec 2015 14:45:11 +0000 Message-ID: <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5679802F.2000106@devever.net> In-Reply-To: <5679802F.2000106@devever.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.96] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 14:45:16 -0000 The IETF generally doesn't do storage formats. BUT we do define ASN.1, and then it's easy to specify a storage format. An= d we need to define ASN.1 because the intent is that these things are trans= mitted as bytes on the wire. I'd be interested in a non-normative appendix that says things like "base64= encode the DER of ECPrivateKey" as one MAY format, and so on. Does that make sense? -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed Dec 23 07:57:25 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77121A1B1D for ; Wed, 23 Dec 2015 07:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEBM5YjTpHVY for ; Wed, 23 Dec 2015 07:57:23 -0800 (PST) Received: from hoffman.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 475111A1AE1 for ; Wed, 23 Dec 2015 07:57:23 -0800 (PST) Received: from [10.32.60.87] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tBNFvM5H014757 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Dec 2015 08:57:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.87] From: "Paul Hoffman" To: "curdle@ietf.org" Date: Wed, 23 Dec 2015 07:57:26 -0800 Message-ID: <627BE113-2226-4E66-AB1B-77CCA586B844@vpnc.org> In-Reply-To: <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5679802F.2000106@devever.net> <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 15:57:24 -0000 On 23 Dec 2015, at 6:45, Salz, Rich wrote: > The IETF generally doesn't do storage formats. > > BUT we do define ASN.1, and then it's easy to specify a storage > format. And we need to define ASN.1 because the intent is that these > things are transmitted as bytes on the wire. > > I'd be interested in a non-normative appendix that says things like > "base64 encode the DER of ECPrivateKey" as one MAY format, and so on. > > Does that make sense? Yes, and it sounds like a good idea. Other binary formats might MAY-level as well. --Paul Hoffman From nobody Wed Dec 23 09:13:33 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30111A1EB7 for ; Wed, 23 Dec 2015 09:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tXudoBe-Rrp for ; Wed, 23 Dec 2015 09:13:30 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 526521A1E0B for ; Wed, 23 Dec 2015 09:13:30 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id p130so200291204yka.1 for ; Wed, 23 Dec 2015 09:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kW0EuC0C8tI+5fa3dtltLSKti1pCwx9+kctgDc5FNLE=; b=j9LNbRXUvUPJ3jE8zgxKjKGbqq1il0puEh76CVH+/MOv2cOd5bEysgE0MLYn0C1s+W QI80Bgze6lnWGYFOOn2i/PfIP2UiQ+BPNrxslLAymaq4mZGk9gxP1zS91a9iLFGi5yJT TX9D6RAlBL1Kx62yZZTrw+vIquTTw+DXOxoRlOTlOSZup7gC/+ibONFb1BwnALbYaDYR b07rQXgW9YkfQz6/mglSSKlBYT2Xz9HjLPzVvWRT9PUvCu83agWmisT6u8MbRQuCLrZR /T7cubKMWRQ2ExvSy0sPPpETlAt8erNEdSHck0/Uwdv261q/fbd2OUVoQ3w1foprO1xp LIDA== MIME-Version: 1.0 X-Received: by 10.13.229.71 with SMTP id o68mr24904139ywe.326.1450890809510; Wed, 23 Dec 2015 09:13:29 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 23 Dec 2015 09:13:29 -0800 (PST) In-Reply-To: <627BE113-2226-4E66-AB1B-77CCA586B844@vpnc.org> References: <5679802F.2000106@devever.net> <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> <627BE113-2226-4E66-AB1B-77CCA586B844@vpnc.org> Date: Wed, 23 Dec 2015 12:13:29 -0500 Message-ID: From: Watson Ladd To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:13:32 -0000 Why do we need to base64 encode the DER, instead of storing a string of bytes? It's a string of bytes: I'm sure you can store it in all sort of weird ways, but you really don't need to. On Wed, Dec 23, 2015 at 10:57 AM, Paul Hoffman wrote: > On 23 Dec 2015, at 6:45, Salz, Rich wrote: > >> The IETF generally doesn't do storage formats. >> >> BUT we do define ASN.1, and then it's easy to specify a storage format. >> And we need to define ASN.1 because the intent is that these things are >> transmitted as bytes on the wire. >> >> I'd be interested in a non-normative appendix that says things like >> "base64 encode the DER of ECPrivateKey" as one MAY format, and so on. >> >> Does that make sense? > > > Yes, and it sounds like a good idea. Other binary formats might MAY-level as > well. > > --Paul Hoffman > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 23 09:52:13 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F185B1A6F11 for ; Wed, 23 Dec 2015 09:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En_iIvThVLUr for ; Wed, 23 Dec 2015 09:52:11 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 C84101A6EE6 for ; Wed, 23 Dec 2015 09:52:10 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id p130so201277506yka.1 for ; Wed, 23 Dec 2015 09:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5AVUTMwpSD5E2kuNLPXaK5kw37wK2hiAM1dMyJTGO+Q=; b=iIS7lNmQIruGa2byfj/yVLOr16n7pXtRP8vcbzM6RrEoLif+2/GUj3RumAIu78RsJq SJ+sSxOIY4GB+dlBQNy6zsdhLd872+qPe1O+Jsn0/ObYyytRk5GVhlkQO1cynOI3q/1O 3MI8tRNvzYZWQt8Fo13BKCDC4f/jLl0tzP5pSMNr1x7oEaQ7OYeAMI8ObNcAqk9TgYyZ Ad1rlsMkcyWgjfeNnBx5cC1rD0byFS7DZ3fYGR7iFWwVVJK272rCwCOjK3zyNlsbjZA8 hHJVtwIxPnn7RifIltP6PlPcjtwohVuDMevMpS/fAEL4TlL2MaGtrprfBoXWYbY0D8+4 9T6w== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr23918400ywa.244.1450893130110; Wed, 23 Dec 2015 09:52:10 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 23 Dec 2015 09:52:10 -0800 (PST) In-Reply-To: <5aea45d9c8404ab3b47e9d1ab83c7be9@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5679802F.2000106@devever.net> <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> <627BE113-2226-4E66-AB1B-77CCA586B844@vpnc.org> <5aea45d9c8404ab3b47e9d1ab83c7be9@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 23 Dec 2015 12:52:10 -0500 Message-ID: From: Watson Ladd To: curdle@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 17:52:12 -0000 On Wed, Dec 23, 2015 at 12:20 PM, Salz, Rich wrote: > >> Why do we need to base64 encode the DER, instead of storing a string of >> bytes? It's a string of bytes: I'm sure you can store it in all sort of weird ways, >> but you really don't need to. > > For compatibility with existing tools, such as OpenSSH's authorized_keys file, etc. > authorized_keys can take a base-64 encoded blob, without any DER structure. From nobody Wed Dec 23 10:00:13 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFC21A6F40 for ; Wed, 23 Dec 2015 10:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02BHoed0Qf0h for ; Wed, 23 Dec 2015 10:00:06 -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 1B4931A6F32 for ; Wed, 23 Dec 2015 10:00:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 619F04DE3E; Wed, 23 Dec 2015 18:00:05 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 526BE4DE24; Wed, 23 Dec 2015 18:00:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1450893605; bh=Q2Jp9BQ2WjlGzmIxF5MPo2XvgUUDMUlMPzJ8swhptJQ=; l=203; h=From:To:Date:References:In-Reply-To:From; b=0OSoL3Xp5PZTYNbIa5WH2L163Slllp9BzHEiRp21y0SVfmtir6g0NCkzAT/DEWJWs 0plSKPAumIKGKp4xSBBlTGhGVdZDkmLJJcS4aTE77ysVqDk/SQYesVIckFY1rdObid FBTv6srXulucFFTcp6qbqUBd9Mm4VeeITPYvY3pI= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 4EAA72036; Wed, 23 Dec 2015 18:00:05 +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.1076.9; Wed, 23 Dec 2015 13:00:04 -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.1076.000; Wed, 23 Dec 2015 13:00:04 -0500 From: "Salz, Rich" To: Watson Ladd , "curdle@ietf.org" Thread-Topic: [Curdle] DER/PEM storage format for EdDSA private keys Thread-Index: AQHRPNlkEzyY9fNvckyeyNmSo1icdJ7YpuEAgABoegCAABU/gP//reZQgABc6QD//640UA== Date: Wed, 23 Dec 2015 18:00:04 +0000 Message-ID: References: <5679802F.2000106@devever.net> <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> <627BE113-2226-4E66-AB1B-77CCA586B844@vpnc.org> <5aea45d9c8404ab3b47e9d1ab83c7be9@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.96] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 18:00:09 -0000 > authorized_keys can take a base-64 encoded blob, without any DER > structure. It was an example, perhaps not a good one. The main clause "for compatibil= ity with existing tools" is important. From nobody Wed Dec 23 10:13:56 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E741A6F53 for ; Wed, 23 Dec 2015 10:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zek0BbQY8Wk for ; Wed, 23 Dec 2015 10:13:50 -0800 (PST) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0886B1A1BDD for ; Wed, 23 Dec 2015 10:13:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 1E43F1C854; Wed, 23 Dec 2015 19:13:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1450894429; x=1469083790; bh=2FUkx4QEb3b0B4YMXt3I23Dv3zigW5mwUChF+rItdWs=; b= mnsshcMnb9kW8zUYudIa2Fo6usQGtU5aOBW1J3+9kBkWQsTS91GCV1oqpXsC5SMP 7Brsh4ilgPkJ/XqA+a+7muMcikiqei+dLY3kKs4O5BbANDIlyss7VaRpQsl+pMaR gC4FJDdZPJhVVQiKeBgMfxaq0t6+H5gfVo+g3R0Xn2pNUjIPYDXv3kaFI4k6118v zpvzC9HbUJ9PCbvSzywrdwigBQEK6lpQFVk9A9XIUvxCL/jRk4aZ9R0mLRCjnZ2T yaB0Bp2BIbhsxTVNqllYLwWvZufQHKkwSKh3rcF2iYmSLRSyySi7ab9Tnnqv5Na8 XafS9lBtWlTp+yifKK7mUA== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id X77Vi0yJJXC1; Wed, 23 Dec 2015 19:13:49 +0100 (CET) Received: from andover (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id DBF431C0D7; Wed, 23 Dec 2015 19:13:48 +0100 (CET) Date: Wed, 23 Dec 2015 18:13:48 +0000 From: Hugo Landau To: "Salz, Rich" Message-ID: <20151223181348.GA23582@andover> References: <5679802F.2000106@devever.net> <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 18:13:55 -0000 That may be the case in theory, but RFC5915 basically spells out the PEM-style encoding for its preferred DER representation of private keys. So specifying a DER format (whether using some existing format or not) and having an appendix which basically says "if you PEM-armour this, you should probably use a banner of 'EdDSA PRIVATE KEY'" sounds good. (My use of the term 'PEM' here seems to be technically incorrect, but there doesn't seem to be any reasonable way of referring specifically to the habit of placing line-wrapped base64 data between -----BEGIN x----- and -----END x-----, or any independent document describing the format.) On Wed, Dec 23, 2015 at 02:45:11PM +0000, Salz, Rich wrote: > The IETF generally doesn't do storage formats. > > BUT we do define ASN.1, and then it's easy to specify a storage format. And we need to define ASN.1 because the intent is that these things are transmitted as bytes on the wire.n > > I'd be interested in a non-normative appendix that says things like "base64 encode the DER of ECPrivateKey" as one MAY format, and so on. > > Does that make sense? > > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz > > > From nobody Wed Dec 23 10:18:22 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093B1A6F6E for ; Wed, 23 Dec 2015 10:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwYYgWieA--I for ; Wed, 23 Dec 2015 10:18:20 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC81A6F0E for ; Wed, 23 Dec 2015 10:18:20 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 15BD6433413; Wed, 23 Dec 2015 18:18:20 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id F3925433403; Wed, 23 Dec 2015 18:18:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1450894700; bh=lsKioCk5hb2IF6NFW80pw2FFz9OaeLMgikNPij10vK0=; l=702; h=From:To:CC:Date:References:In-Reply-To:From; b=lc7u12Z3hy7AyhSoMdaxpicBuT2FkB+FVzKCZapPqmlqlYR9dDdkkOi4duB+lQOuh 6gyqZrWkQK269IpGouOBK8ni6Fv04DGuTfazd23Fz9Gb3UUowheF+Y/l+iwsJNUuT9 S3GrHTM4ONzF0BuwL0tJMLH0RTBvATo4jz556Kxw= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id F13E62030; Wed, 23 Dec 2015 18:18:19 +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.1076.9; Wed, 23 Dec 2015 13:18:19 -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.1076.000; Wed, 23 Dec 2015 13:18:19 -0500 From: "Salz, Rich" To: Hugo Landau Thread-Topic: [Curdle] DER/PEM storage format for EdDSA private keys Thread-Index: AQHRPNlkEzyY9fNvckyeyNmSo1icdJ7YpuEAgACOlAD//60scA== Date: Wed, 23 Dec 2015 18:18:19 +0000 Message-ID: References: <5679802F.2000106@devever.net> <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> <20151223181348.GA23582@andover> In-Reply-To: <20151223181348.GA23582@andover> 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.34.96] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 18:18:21 -0000 > So specifying a DER format (whether using some existing format or not) an= d > having an appendix which basically says "if you PEM-armour this, you shou= ld > probably use a banner of 'EdDSA PRIVATE KEY'" sounds good. Glad we agree. =20 > (My use of the term 'PEM' here seems to be technically incorrect, but the= re > doesn't seem to be any reasonable way of referring specifically to the ha= bit > of placing line-wrapped base64 data between -----BEGIN x----- and -----EN= D > x-----, or any independent document describing the format.) It comes from the old Privacy-Enhanced Mail RFC's. I think SSLeay (the pre= decessor to OpenSSL) made it very popular and coined the term. From nobody Wed Dec 23 18:20:49 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86C1A8A0E for ; Wed, 23 Dec 2015 16:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWngavFJV81A for ; Wed, 23 Dec 2015 16:19:19 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A451A8A11 for ; Wed, 23 Dec 2015 16:19:19 -0800 (PST) Received: by mail-pa0-x236.google.com with SMTP id jx14so113009828pad.2 for ; Wed, 23 Dec 2015 16:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=AX/qqMxl8TpM5vpE651kjefcu/mY/HxVhGu4USrwMNI=; b=DiqYXipZFIMBNfw1qAMoQk2WVWsSYfthihS/LW7ubUpJOuYKGAC+JFXKRV5Z+7uDHe otWpqYl2C6Zkj9tsYuGfU13IpuIjti3HEulFCj7wYGPiLPuAPk+OVB33H/0UFERYlZfC LPdhZuPB2A6KYBcNMRntgG/t3h7ZazeVEVdZJpnGgzahWn8RkSeeoIBcwG4OWH/6YBV3 oaJfEX4INHiZv4Iw+QLfHTRp/VZF1OSD+xzPZGTYIsc+CqLE+pj0fj75ELc6/uZxs6If qQ5IvmknSfTnGBtgKMKDGrWFmOIHxOGRGuyQ+iSjIqbVp56em7p7HC5MngvwLdg7Dfcs hMBw== X-Received: by 10.66.100.198 with SMTP id fa6mr6079144pab.123.1450916359000; Wed, 23 Dec 2015 16:19:19 -0800 (PST) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id xz6sm54946612pab.42.2015.12.23.16.19.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Dec 2015 16:19:15 -0800 (PST) Date: Thu, 24 Dec 2015 00:19:14 +0000 (UTC) From: Phillip Hallam-Baker To: "Salz, Rich" , Hugo Landau Message-ID: <994C5976EA09B556.20D7FB95-1F6D-4759-94F9-67B253FC91F1@mail.outlook.com> In-Reply-To: References: <5679802F.2000106@devever.net> <4d998bd15d2c43d7a21bd38b978ca79c@usma1ex-dag1mb1.msg.corp.akamai.com> <20151223181348.GA23582@andover> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_448_57913100.1450916354959" X-Mailer: Outlook for iOS and Android Archived-At: X-Mailman-Approved-At: Wed, 23 Dec 2015 18:20:48 -0800 Cc: curdle@ietf.org Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 00:19:21 -0000 ------=_Part_448_57913100.1450916354959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't care what the IETF 'does' Not specifying the private key format means we ended up with three flavored= of SSH an an unnecessary incompatibility Specify everything that needs to be said to make things work.=C2=A0 Sent from Outlook Mobile On Wed, Dec 23, 2015 at 10:18 AM -0800, "Salz, Rich" wro= te: > So specifying a DER format (whether using some existing format or not) an= d > having an appendix which basically says "if you PEM-armour this, you shou= ld > probably use a banner of 'EdDSA PRIVATE KEY'" sounds good. Glad we agree. =20 > (My use of the term 'PEM' here seems to be technically incorrect, but the= re > doesn't seem to be any reasonable way of referring specifically to the ha= bit > of placing line-wrapped base64 data between -----BEGIN x----- and -----EN= D > x-----, or any independent document describing the format.) It comes from the old Privacy-Enhanced Mail RFC's. I think SSLeay (the pre= decessor to OpenSSL) made it very popular and coined the term. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_Part_448_57913100.1450916354959 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I don't care what the IETF 'does'

Not specifying the private key format means we ended up with three flavored of SSH an an unnecessary incompatibility

Specify everything that needs to be said to make things work. 

Sent from Outlook Mobile




On Wed, Dec 23, 2015 at 10:18 AM -0800, "Salz, Rich" <rsalz@akamai.com> wrote:

> So specifying a DER format (whether using some existing format or not) and
> having an appendix which basically says "if you PEM-armour this, you should
> probably use a banner of 'EdDSA PRIVATE KEY'" sounds good.

Glad we agree.
 
> (My use of the term 'PEM' here seems to be technically incorrect, but there
> doesn't seem to be any reasonable way of referring specifically to the habit
> of placing line-wrapped base64 data between -----BEGIN x----- and -----END
> x-----, or any independent document describing the format.)

It comes from the old Privacy-Enhanced Mail RFC's.  I think SSLeay (the predecessor to OpenSSL) made it very popular and coined the term.


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_Part_448_57913100.1450916354959-- From nobody Wed Dec 23 18:29:41 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7054D1AD0D2; Wed, 23 Dec 2015 18:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJzSnywlQcnq; Wed, 23 Dec 2015 18:29:39 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 B7E671AD0D7; Wed, 23 Dec 2015 18:29:36 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id p187so164421241wmp.0; Wed, 23 Dec 2015 18:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=xG7ZRq0G3KH7yDitweWNEueyJuHJ/NiW0BJGPGaNH4E=; b=BBKif/Y2MpOItzOzLTHO0oOpasQCFCRxBtWWx1896+lyac/Z8vfnJHRGm5C+5Vz1f7 AB7pxfWgpG/IYKRBshRnhR+qnkRE931CGCwV8qXyO821UZA1iz3fMsQidK2Cj1ytIeek 5OMhA8yrS1DS3orfJG9VgRP1VLviwNJ4ruWkl9edFqx5h9wIDDIx39b5k4aBMPulWFpC AibHxgQ5jppPB4NfusLhlq86GebIXSlK+WMBf570OJ1hKmEnqyv9sVECZT59VKAk8vzk 5gmfrMYMr/UObjJSMy8HBBEwhg6W7Mwz5dQXSjtMtDmWk/B05vtOm3nZ7WWLsiIPbZAe BJiw== MIME-Version: 1.0 X-Received: by 10.28.132.146 with SMTP id g140mr35789807wmd.70.1450924175304; Wed, 23 Dec 2015 18:29:35 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.250.6 with HTTP; Wed, 23 Dec 2015 18:29:35 -0800 (PST) Date: Wed, 23 Dec 2015 21:29:35 -0500 X-Google-Sender-Auth: D3-S9ca-ZCXqja09eGIhhk2Dtc4 Message-ID: From: Daniel Migault To: curdle@ietf.org Content-Type: multipart/alternative; boundary=001a1144231410ba1605279b9c27 Archived-At: Cc: curdle-chairs@ietf.org Subject: [Curdle] Call for Drafts: Jan 15 2016 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 02:29:40 -0000 --001a1144231410ba1605279b9c27 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, In consultation with our area directors, we think that the best way to move forward is to work in =E2=80=9Cbatches,=E2=80=9D rather than have individua= l documents and protocols trickle in one at a time. Therefore, we=E2=80=99re putting out a= n initial call for drafts for the WG to consider in January. If you=E2=80=99d like to see a particular protocol adopt the new curves, or= if you would like to see cryptographic recommendations for a specific protocol, or you are writing a draft that does this, or you think we should adopt a draft that already exists, PLEASE POST TO THE LIST, IDEALLY BY MID-JANUARY. We know there are several documents out there already, either individual submissions or perhaps in other WG=E2=80=99s that would be willi= ng to relinquish control. Thanks, and happy holidays and new year. Daniel and Rich --001a1144231410ba1605279b9c27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,


In consultation with our area directors, we think that the best way to move forward is to work in =E2=80=9Cbatches,=E2=80=9D rather th= an have individual documents and protocols trickle in one at a time.=C2=A0 Therefore, we=E2=80= =99re putting out an initial call for drafts for the WG to consider in January.=C2=A0

If you=E2=80=99d like to see a particular protocol a= dopt the new curves, or if you would like to see cryptographic recommendations for a spe= cific protocol, or you are writing a draft that does this, or you think we = should adopt a draft that already exists, PLEASE POST TO THE LIST, IDEALLY BY MID-JANUARY.=C2=A0 We know there are several documents out there already, either individual submissions or perhaps in other WG=E2=80=99s that would b= e willing to relinquish control.

=C2=A0

Thanks, and happy holidays and new year.


Daniel and Rich

--001a1144231410ba1605279b9c27-- From nobody Wed Dec 23 21:28:15 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487801A0222 for ; Wed, 23 Dec 2015 21:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZj__JOg8a6e for ; Wed, 23 Dec 2015 21:28:10 -0800 (PST) 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 5C8561A0218 for ; Wed, 23 Dec 2015 21:28:10 -0800 (PST) Received: from android-d7bdb37305f05cf4 (m176-68-126-37.cust.tele2.se [176.68.126.37]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tBO5Rf8p022590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Dec 2015 06:27:55 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <5679802F.2000106@devever.net> References: <5679802F.2000106@devever.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Simon Josefsson Date: Thu, 24 Dec 2015 12:21:34 +0700 To: Hugo Landau , curdle@ietf.org Message-ID: X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [Curdle] DER/PEM storage format for EdDSA private keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 05:28:13 -0000 We looked into reusing that structure but it is not a good fit for eddsa. See draft-josefsson-pkix for an example eddsa private key in PEM-format. It is implemented in GnuTLS. There are known problems with it - I'll update the draft in January with an updated version. I believe the charter covers doing private key formats. The IETF defines them for all other algs. /Simon Hugo Landau skrev: (22 december 2015 23:54:07 GMT+07:00) >Does this WG intend to provide a storage format for EdDSA private keys? >Such a format will certainly be needed. > >The existing EC ASN.1 format could probably be reused. It is: > > ECPrivateKey ::= SEQUENCE { > version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), > privateKey OCTET STRING, > parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, > publicKey [1] BIT STRING OPTIONAL > } > >Since draft-josefsson-pkix-newcurves has allocated named curve OIDs for >the CFRG curves, these OIDs could be used here. > >On the other hand, since this is essentially an overloading of the >semantics of ECPrivateKey, NamedCurve, etc., there could be issues >adding support to existing implementations that would be prefer to >treat >EdDSA substantially differently to NIST ECDSA. > >Another issue is what it means for a key to be Ed25519 vs. Ed25519ph. >Must an Ed25519ph key only be used for prehashed data? The issue, I >suppose, is that if you allow the same key to be used for non-prehashed >data and prehashed data, you create the potential issue that a >signature >generated over 64 bytes (assuming SHA512) via Ed25519 could be passed >off as an Ed25519ph signature by an attacker. The 'namespaces' >conflict. >On the other hand, one won't necessarily know, when generating a key, >whether prehashing will be used. If a key is used with more than one >application, prehashing might be used for one and not the other. > >_______________________________________________ >Curdle mailing list >Curdle@ietf.org >https://www.ietf.org/mailman/listinfo/curdle -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. From nobody Mon Dec 28 11:26:21 2015 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972411AC3BF for ; Mon, 28 Dec 2015 11:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcjY0oLvKGUn for ; Mon, 28 Dec 2015 11:26:17 -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 272511AC3BB for ; Mon, 28 Dec 2015 11:26:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EB942BE53 for ; Mon, 28 Dec 2015 19:26:14 +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 kBmv6Aos5ITp for ; Mon, 28 Dec 2015 19:26:13 +0000 (GMT) Received: from [10.87.48.83] (unknown [86.42.26.37]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B1162BE2D for ; Mon, 28 Dec 2015 19:26:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1451330773; bh=LptMoRcRC8D+1OQuNzHO9m7vXlJa8IpW4RuOg8xU2LY=; h=Subject:References:To:From:Date:In-Reply-To:From; b=c958lwzudjErAPokWCZQ5Io1ZHd66+XQrm9m8uG/zedZ+1UE62Oj1EWmREcUy4GQT L5Wr8xKXoyakr5Asdx6ayM2KRaNWN4D3vEM08C1/CQg9pkZAYPCGMn1/Jfnr7uwwb1 Z+sbZrLpa7Vv3VVBNOfhZtQjfqpJQNNTaCv/nSZI= References: <20151228192334.GA5684@LK-Perkele-V2.elisa-laajakaista.fi> To: curdle@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <20151228192334.GA5684@LK-Perkele-V2.elisa-laajakaista.fi> Message-ID: <56818CD3.60003@cs.tcd.ie> Date: Mon, 28 Dec 2015 19:26:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151228192334.GA5684@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Curdle] Fwd: Re: [jose] I-D Action: draft-ietf-jose-cfrg-curves-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2015 19:26:19 -0000 FYI, it seems like the JOSE wg want to do the curvaceous stuff themselves rather than offload to here. So please do review, but please try post reviews to the jose list. [1] (Here is also ok, as they won't get lost, but the jost list is better.) Cheers, S. [1] https://www.ietf.org/mailman/listinfo/jose -------- Forwarded Message -------- Subject: Re: [jose] I-D Action: draft-ietf-jose-cfrg-curves-00.txt Date: Mon, 28 Dec 2015 21:23:34 +0200 From: Ilari Liusvaara To: jose@ietf.org On Mon, Dec 28, 2015 at 11:20:57AM -0800, 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 Javascript Object Signing and Encryption Working Group of the IETF. > > Title : CFRG ECDH and signatures in JOSE > Author : Ilari Liusvaara > Filename : draft-ietf-jose-cfrg-curves-00.txt > Pages : 14 > Date : 2015-12-28 > > Abstract: > This document defines how to use Diffie-Hellman algorithms "X25519" > and "X448" as well as signature algorithms "Ed25519", "Ed25519ph", > "Ed448" and "Ed448ph" from IRTF CFRG elliptic curves work in JOSE. Submitted as WG-00. Some editorial changes based on feedback and some TBD notes inserted based on feedback. No normative changes. -Ilari _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose