From nobody Mon May 2 10:32:38 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B707412D122 for ; Mon, 2 May 2016 10:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIuR_yjI8Eyn for ; Mon, 2 May 2016 10:32:35 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E7CC212D10F for ; Mon, 2 May 2016 10:32:34 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 4D0E4F24041; Mon, 2 May 2016 13:32:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Nc0bnuf3WiZV; Mon, 2 May 2016 13:16:20 -0400 (EDT) Received: from [5.5.33.72] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 064C8F2402E; Mon, 2 May 2016 13:32:32 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> Date: Mon, 2 May 2016 13:32:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: curdle@ietf.org Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 17:32:36 -0000 Jim Schaad sent me some comments on this document. Since I have asked = this working group to adopt this draft, I have gotten Jim=92s permission to = respond to the comments on list. > 1. I am not sure that I see a great deal of benefits for doing both = the > pre-hash version and pure version of EdDSA. Specifically, the use of = the > pre-hash version really only seems to make sense if one does not use = signed > attributes. However, I think that this is a case which would never = occur > for this signature algorithm. Right. Since signed attributes are the most common use with CMS, it is probably better to just make use of PureEdDSA. I suggest adding this text to Section 2 of the document: One of the parameters of the EdDSA algorithm is the "prehash" function. This may be the identity function, resulting in an algorithm called PureEdDSA, or a collision-resistant hash function, resulting in an algorithm called HashEdDSA. In most situations the CMS SignedData includes signed attributes, including the message digest of the content. Since HashEdDSA offers no benefit when signed attributes are present, only PureEdDSA is used with the CMS. And, then change Section 2.1 like this: When the id-EdDSAPublicKey onject identifier is used, the AlgorithmIdentifier parameters field MUST contain EdDSAParameters to specify a particular set of EdDSA parameters: EdDSAParameters ::=3D ENUMERATED { ed25519 (1), -- PureEdDSA ed25519ph (2), -- HashEdDSA; not used in the CMS ed448 (3), -- PureEdDSA ed448ph (4) } -- HashEdDSA; not used in the CMS > 2. We need to get a definition of how to use SHAKE256 from someplace = if we > are going to say use the same hash algorithm throughout as that is = what > Ed448 uses. It would be worthwhile to specify what hash algorithms = should > be used with each of the different signature algorithms given that it = is not > clear from the name of the algorithm identifier. This document references draft-irtf-cfrg-eddsa-05, and that document includes this reference for SHAKE256: [FIPS202] National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS 202, August 2015. I=92m not sure what more you think is needed. > 3. In section 3 para 2: This sentence does not necessarily make sense = for > the pure version of EdDSA. In some sense there is no hash function = which is > used on the signedAttribute value. I don't know that it needs to be = fixed, > but it might be somewhat confusing. You are talking about this paragraph: The same one-way hash function SHOULD be used for computing the message digest on both the eContent and the signedAttributes value if signedAttributes are present. I think the principle is correct. I=92m not sure how to address your = comment. > 4. In section 4, the problem with EdDSA is worse for the use of = different > algorithms than what you are stating. It is possible to do some = interesting > forgeries if you cross between the pre-hash and not pre-hash versions = with > the Ed25519 curve since there is no context difference between them. = This > has to be forbidden not just strongly suggested. Does the removal of HashEdDSA resolve this one? Russ From nobody Mon May 2 11:45:37 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B66F12D5DC for ; Mon, 2 May 2016 11:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWpwZne_baEH for ; Mon, 2 May 2016 11:45:33 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F72012D5E8 for ; Mon, 2 May 2016 11:45:29 -0700 (PDT) Received: from hebrews (augustcellars.com [50.45.239.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id DB28F38F10; Mon, 2 May 2016 11:45:28 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> In-Reply-To: <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> Date: Mon, 2 May 2016 11:45:19 -0700 Message-ID: <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfBLXiu/ETDZDECg/NZrmdRKtKuwH6YJMHnvtjoBA= Content-Language: en-us Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 18:45:36 -0000 Russ, Comments inline. jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, May 02, 2016 10:32 AM To: Jim Schaad Cc: curdle@ietf.org Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures Jim Schaad sent me some comments on this document. Since I have asked this working group to adopt this draft, I have gotten Jim's permission to respond to the comments on list. > 1. I am not sure that I see a great deal of benefits for doing both the > pre-hash version and pure version of EdDSA. Specifically, the use of the > pre-hash version really only seems to make sense if one does not use > signed attributes. However, I think that this is a case which would > never occur for this signature algorithm. Right. Since signed attributes are the most common use with CMS, it is probably better to just make use of PureEdDSA. I suggest adding this text to Section 2 of the document: One of the parameters of the EdDSA algorithm is the "prehash" function. This may be the identity function, resulting in an algorithm called PureEdDSA, or a collision-resistant hash function, resulting in an algorithm called HashEdDSA. In most situations the CMS SignedData includes signed attributes, including the message digest of the content. Since HashEdDSA offers no benefit when signed attributes are present, only PureEdDSA is used with the CMS. And, then change Section 2.1 like this: When the id-EdDSAPublicKey onject identifier is used, the AlgorithmIdentifier parameters field MUST contain EdDSAParameters to specify a particular set of EdDSA parameters: EdDSAParameters ::= ENUMERATED { ed25519 (1), -- PureEdDSA ed25519ph (2), -- HashEdDSA; not used in the CMS ed448 (3), -- PureEdDSA ed448ph (4) } -- HashEdDSA; not used in the CMS [JLS] Both of those changes look very reasonable. > 2. We need to get a definition of how to use SHAKE256 from someplace > if we are going to say use the same hash algorithm throughout as that > is what > Ed448 uses. It would be worthwhile to specify what hash algorithms > should be used with each of the different signature algorithms given > that it is not clear from the name of the algorithm identifier. This document references draft-irtf-cfrg-eddsa-05, and that document includes this reference for SHAKE256: [FIPS202] National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS 202, August 2015. I'm not sure what more you think is needed. [JLS] To start with, I think we need to get a reference for an OID for the SHAKE256 algorithm from NIST (or internally) since that is needed as one of the authenticated attributes. I worry that since we have changed this set of identifiers from saying X with Y to just saying X that there is going to be a degree of people missing which algorithm is being used as a hash algorithm for this. A second worry is that SHAK256 is defined as being an XOF function and not a hash function. I think it might make more sense to say that we should be using SHA3-256 rather than SHAKE256. In any event the OID assigned on the NIST web site does not make any statements about the size of output of SHAKE256 and if we are going to use it as a hash algorithm here we need to do that. Suffice it to say that I don't think that using SHAKE256 as a hash algorithm here is sufficiently defined. > 3. In section 3 para 2: This sentence does not necessarily make sense > for the pure version of EdDSA. In some sense there is no hash > function which is used on the signedAttribute value. I don't know > that it needs to be fixed, but it might be somewhat confusing. You are talking about this paragraph: The same one-way hash function SHOULD be used for computing the message digest on both the eContent and the signedAttributes value if signedAttributes are present. I think the principle is correct. I'm not sure how to address your comment. [JLS] Yeah, I am not sure how to address my comment here either. The problem as stated above is that there is no explicit hash function that is used as a pre-hash to the signature so people might not know what hash algorithm to be using here. > 4. In section 4, the problem with EdDSA is worse for the use of > different algorithms than what you are stating. It is possible to do > some interesting forgeries if you cross between the pre-hash and not > pre-hash versions with the Ed25519 curve since there is no context > difference between them. This has to be forbidden not just strongly suggested. Does the removal of HashEdDSA resolve this one? [JLS] Yes that would deal with this issue. However, given that currently the difference is just a field in the enumeration it should probably have a security consideration about it. If we can change the PKXI draft so that the pre-hash and pure versions using different OID identifiers, then this because much cleaner and less of a worry. It would currently be potentially necessary to make a RFC 2119 statement about the enumeration which is not proposed above. Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue May 3 08:39:35 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EB612D966 for ; Tue, 3 May 2016 08:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs75CVEKPOXQ for ; Tue, 3 May 2016 08:39:31 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0123.outbound.protection.outlook.com [23.103.200.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D14112D529 for ; Tue, 3 May 2016 08:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YcMFl+UNUHWSMqyK7ECmceU8Q/0zwXY9qg2c+4aTefQ=; b=sE3UC07y5fZxJN66v9OxfMpLBEOv2zpXmBwqCpQWZ/RYG8+cbrQu1MfMIycndnrHkJ5z9DjMERbJSaigHZH83X+e5ATY8VinkREtDz7SDp13lJaE4HdK7KJ1eRB4+DbULKmtUp6ZJrllM+6DxNItLWK4a1iSrgAzMO8xMxxJ9sI= 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.477.8; Tue, 3 May 2016 15:39:29 +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.0477.015; Tue, 3 May 2016 15:39:29 +0000 From: "Dang, Quynh (Fed)" To: Jim Schaad , 'Russ Housley' Thread-Topic: [Curdle] Comments on draft-housley-cms-eddsa-signatures Thread-Index: AQHRpJiiUMFvavyrw02yfEgwrMzH1p+l/FuAgAFU+4E= Date: Tue, 3 May 2016 15:39:29 +0000 Message-ID: References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com>, <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> In-Reply-To: <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; augustcellars.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.218.45] x-ms-office365-filtering-correlation-id: a1f75076-427c-48d4-794f-08d373691db9 x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:gcX3sI62mRxo8FdACi74EI+7BBT7gZQ54j3kt+4/zW1f3zWFuZrSJN3t1elRwx4RH1eYfXGhe59EdcSNOVWclN35YwNWSn4D084yuUqXXmDH8zlBbCzm2k7MoJct0V5LO0CKkMIFgPcigiHrpq29dg==; 24:B+57NkAAYwFaBvEwgfrv5qJwAeX0kHPCPxkcHLBBtniQQjHHvXPIJ2XldmhZiXinofwsjmMFxraZMRi+BzpsoDdhDHw+qzI5ND40uxTxSrg=; 7:0atPzlpKAR0otcCjlRdDUPdPUN1oq2lyr/1ydmtWnKAxUwimUcZMqSF/MaONbtjzLih+nkaKpRhRG1V6E/UDhiuZUyiQqOvLk+FHt64Mu3g/WNQDIN6F5SZpboFi0EixyklwkyJ++iW6re4PAteHF0vp3T++Zdk198HvTFNnSOLRZCUFybmYN+9qVRsz+5pJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521096)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(1220700001)(5001770100001)(102836003)(3846002)(6116002)(19580405001)(19580395003)(106116001)(10400500002)(54356999)(5004730100002)(33656002)(92566002)(99286002)(122556002)(230783001)(81166005)(87936001)(5008740100001)(189998001)(586003)(86362001)(4326007)(5002640100001)(3280700002)(9686002)(50986999)(5003600100002)(76176999)(76576001)(15975445007)(77096005)(74316001)(11100500001)(8936002)(5890100001)(66066001)(2950100001)(3660700001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2016 15:39:29.0732 (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: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:39:34 -0000 Hi Jim, Russ and all, NIST currently plans to allow the SHAKEs to be used. Please see the documen= t attached to the email John Kelsey sent out on 4/8/2016 with the email tit= led Customized shake. The uses of SHAKE256 in the EdDSA with Ed448 are good= (prehash and without prehash versions). SHAKE256 is used as a prf in the PureEdDSA with ed448 and a prf produces di= fferent output sizes depending on the needs. If an OID for SHAKE256 with some specific output length is needed, NIST can= help, just let us know! Regards, Quynh. ________________________________________ From: Curdle on behalf of Jim Schaad Sent: Monday, May 2, 2016 2:45:19 PM To: 'Russ Housley' Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures Russ, Comments inline. jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, May 02, 2016 10:32 AM To: Jim Schaad Cc: curdle@ietf.org Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures Jim Schaad sent me some comments on this document. Since I have asked this working group to adopt this draft, I have gotten Jim's permission to respon= d to the comments on list. > 1. I am not sure that I see a great deal of benefits for doing both the > pre-hash version and pure version of EdDSA. Specifically, the use of th= e > pre-hash version really only seems to make sense if one does not use > signed attributes. However, I think that this is a case which would > never occur for this signature algorithm. Right. Since signed attributes are the most common use with CMS, it is probably better to just make use of PureEdDSA. I suggest adding this text to Section 2 of the document: One of the parameters of the EdDSA algorithm is the "prehash" function. This may be the identity function, resulting in an algorithm called PureEdDSA, or a collision-resistant hash function, resulting in an algorithm called HashEdDSA. In most situations the CMS SignedData includes signed attributes, including the message digest of the content. Since HashEdDSA offers no benefit when signed attributes are present, only PureEdDSA is used with the CMS. And, then change Section 2.1 like this: When the id-EdDSAPublicKey onject identifier is used, the AlgorithmIdentifier parameters field MUST contain EdDSAParameters to specify a particular set of EdDSA parameters: EdDSAParameters ::=3D ENUMERATED { ed25519 (1), -- PureEdDSA ed25519ph (2), -- HashEdDSA; not used in the CMS ed448 (3), -- PureEdDSA ed448ph (4) } -- HashEdDSA; not used in the CMS [JLS] Both of those changes look very reasonable. > 2. We need to get a definition of how to use SHAKE256 from someplace > if we are going to say use the same hash algorithm throughout as that > is what > Ed448 uses. It would be worthwhile to specify what hash algorithms > should be used with each of the different signature algorithms given > that it is not clear from the name of the algorithm identifier. This document references draft-irtf-cfrg-eddsa-05, and that document includes this reference for SHAKE256: [FIPS202] National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS 202, August 2015. I'm not sure what more you think is needed. [JLS] To start with, I think we need to get a reference for an OID for the SHAKE256 algorithm from NIST (or internally) since that is needed as one of the authenticated attributes. I worry that since we have changed this set of identifiers from saying X with Y to just saying X that there is going to be a degree of people missin= g which algorithm is being used as a hash algorithm for this. A second worry is that SHAK256 is defined as being an XOF function and not = a hash function. I think it might make more sense to say that we should be using SHA3-256 rather than SHAKE256. In any event the OID assigned on the NIST web site does not make any statements about the size of output of SHAKE256 and if we are going to use it as a hash algorithm here we need to do that. Suffice it to say that I don't think that using SHAKE256 as a has= h algorithm here is sufficiently defined. > 3. In section 3 para 2: This sentence does not necessarily make sense > for the pure version of EdDSA. In some sense there is no hash > function which is used on the signedAttribute value. I don't know > that it needs to be fixed, but it might be somewhat confusing. You are talking about this paragraph: The same one-way hash function SHOULD be used for computing the message digest on both the eContent and the signedAttributes value if signedAttributes are present. I think the principle is correct. I'm not sure how to address your comment= . [JLS] Yeah, I am not sure how to address my comment here either. The problem as stated above is that there is no explicit hash function that is used as a pre-hash to the signature so people might not know what hash algorithm to be using here. > 4. In section 4, the problem with EdDSA is worse for the use of > different algorithms than what you are stating. It is possible to do > some interesting forgeries if you cross between the pre-hash and not > pre-hash versions with the Ed25519 curve since there is no context > difference between them. This has to be forbidden not just strongly suggested. Does the removal of HashEdDSA resolve this one? [JLS] Yes that would deal with this issue. However, given that currently the difference is just a field in the enumeration it should probably have a security consideration about it. If we can change the PKXI draft so that the pre-hash and pure versions using different OID identifiers, then this because much cleaner and less of a worry. It would currently be potentiall= y necessary to make a RFC 2119 statement about the enumeration which is not proposed above. Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue May 3 13:12:17 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9112D884 for ; Tue, 3 May 2016 13:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGRAC9liSW6q for ; Tue, 3 May 2016 13:12:14 -0700 (PDT) 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 0B7A712D881 for ; Tue, 3 May 2016 13:12:14 -0700 (PDT) Received: from hebrews (static-50-39-87-30.bvtn.or.frontiernet.net [50.39.87.30]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 4170C38F0C; Tue, 3 May 2016 13:12:13 -0700 (PDT) From: "Jim Schaad" To: "'Dang, Quynh \(Fed\)'" , "'Russ Housley'" References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com>, <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> In-Reply-To: Date: Tue, 3 May 2016 13:12:11 -0700 Message-ID: <0dcb01d1a578$149e9210$3ddbb630$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfBLXiu/ETDZDECg/NZrmdRKtKuwH6YJMHAx0dd7oCTeVVx57Ru1dg Content-Language: en-us Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:12:16 -0000 Quynh, I see that NIST has assigned an OID for SHA256, when they assigned it did they have ideas on when and where it was going to be used. Or did they just assign one because it didn't have one without thinking about it? Jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Dang, Quynh (Fed) Sent: Tuesday, May 03, 2016 8:39 AM To: Jim Schaad ; 'Russ Housley' Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures Hi Jim, Russ and all, NIST currently plans to allow the SHAKEs to be used. Please see the document attached to the email John Kelsey sent out on 4/8/2016 with the email titled Customized shake. The uses of SHAKE256 in the EdDSA with Ed448 are good (prehash and without prehash versions). SHAKE256 is used as a prf in the PureEdDSA with ed448 and a prf produces different output sizes depending on the needs. If an OID for SHAKE256 with some specific output length is needed, NIST can help, just let us know! Regards, Quynh. ________________________________________ From: Curdle on behalf of Jim Schaad Sent: Monday, May 2, 2016 2:45:19 PM To: 'Russ Housley' Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures Russ, Comments inline. jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, May 02, 2016 10:32 AM To: Jim Schaad Cc: curdle@ietf.org Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures Jim Schaad sent me some comments on this document. Since I have asked this working group to adopt this draft, I have gotten Jim's permission to respond to the comments on list. > 1. I am not sure that I see a great deal of benefits for doing both the > pre-hash version and pure version of EdDSA. Specifically, the use of the > pre-hash version really only seems to make sense if one does not use > signed attributes. However, I think that this is a case which would > never occur for this signature algorithm. Right. Since signed attributes are the most common use with CMS, it is probably better to just make use of PureEdDSA. I suggest adding this text to Section 2 of the document: One of the parameters of the EdDSA algorithm is the "prehash" function. This may be the identity function, resulting in an algorithm called PureEdDSA, or a collision-resistant hash function, resulting in an algorithm called HashEdDSA. In most situations the CMS SignedData includes signed attributes, including the message digest of the content. Since HashEdDSA offers no benefit when signed attributes are present, only PureEdDSA is used with the CMS. And, then change Section 2.1 like this: When the id-EdDSAPublicKey onject identifier is used, the AlgorithmIdentifier parameters field MUST contain EdDSAParameters to specify a particular set of EdDSA parameters: EdDSAParameters ::= ENUMERATED { ed25519 (1), -- PureEdDSA ed25519ph (2), -- HashEdDSA; not used in the CMS ed448 (3), -- PureEdDSA ed448ph (4) } -- HashEdDSA; not used in the CMS [JLS] Both of those changes look very reasonable. > 2. We need to get a definition of how to use SHAKE256 from someplace > if we are going to say use the same hash algorithm throughout as that > is what > Ed448 uses. It would be worthwhile to specify what hash algorithms > should be used with each of the different signature algorithms given > that it is not clear from the name of the algorithm identifier. This document references draft-irtf-cfrg-eddsa-05, and that document includes this reference for SHAKE256: [FIPS202] National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS 202, August 2015. I'm not sure what more you think is needed. [JLS] To start with, I think we need to get a reference for an OID for the SHAKE256 algorithm from NIST (or internally) since that is needed as one of the authenticated attributes. I worry that since we have changed this set of identifiers from saying X with Y to just saying X that there is going to be a degree of people missing which algorithm is being used as a hash algorithm for this. A second worry is that SHAK256 is defined as being an XOF function and not a hash function. I think it might make more sense to say that we should be using SHA3-256 rather than SHAKE256. In any event the OID assigned on the NIST web site does not make any statements about the size of output of SHAKE256 and if we are going to use it as a hash algorithm here we need to do that. Suffice it to say that I don't think that using SHAKE256 as a hash algorithm here is sufficiently defined. > 3. In section 3 para 2: This sentence does not necessarily make sense > for the pure version of EdDSA. In some sense there is no hash > function which is used on the signedAttribute value. I don't know > that it needs to be fixed, but it might be somewhat confusing. You are talking about this paragraph: The same one-way hash function SHOULD be used for computing the message digest on both the eContent and the signedAttributes value if signedAttributes are present. I think the principle is correct. I'm not sure how to address your comment. [JLS] Yeah, I am not sure how to address my comment here either. The problem as stated above is that there is no explicit hash function that is used as a pre-hash to the signature so people might not know what hash algorithm to be using here. > 4. In section 4, the problem with EdDSA is worse for the use of > different algorithms than what you are stating. It is possible to do > some interesting forgeries if you cross between the pre-hash and not > pre-hash versions with the Ed25519 curve since there is no context > difference between them. This has to be forbidden not just strongly suggested. Does the removal of HashEdDSA resolve this one? [JLS] Yes that would deal with this issue. However, given that currently the difference is just a field in the enumeration it should probably have a security consideration about it. If we can change the PKXI draft so that the pre-hash and pure versions using different OID identifiers, then this because much cleaner and less of a worry. It would currently be potentially necessary to make a RFC 2119 statement about the enumeration which is not proposed above. Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Wed May 4 04:46:43 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A515C12D569 for ; Wed, 4 May 2016 04:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEE6qmEvAv6K for ; Wed, 4 May 2016 04:46:39 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0117.outbound.protection.outlook.com [23.103.200.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD2812B017 for ; Wed, 4 May 2016 04:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PwGqQVrovrvT1GSXs59Fp070VTKb+ULdbgdN9lw2VZo=; b=pf+mtZzjYg3oVILnkYqNW7u6iG38+TqPnahu8hfUa7V2V30EE/O3srJpv/vWvXrjmL9AfHPpO0hjSF1APfVb+HRq6e7drCejBtWLNS5F3y3PrzAtgKc53vB/fpoqULYMNjcDelOVLJXz3hgTCR+O/IpYSKGE/3u78683Ltns1vY= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB121.namprd09.prod.outlook.com (10.255.200.145) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 4 May 2016 11:46:36 +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.0477.016; Wed, 4 May 2016 11:46:36 +0000 From: "Dang, Quynh (Fed)" To: Jim Schaad , 'Russ Housley' Thread-Topic: [Curdle] Comments on draft-housley-cms-eddsa-signatures Thread-Index: AQHRpJiiUMFvavyrw02yfEgwrMzH1p+l/FuAgAFU+4GAAFWfgIAA+Por Date: Wed, 4 May 2016 11:46:36 +0000 Message-ID: References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com>, <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> , <0dcb01d1a578$149e9210$3ddbb630$@augustcellars.com> In-Reply-To: <0dcb01d1a578$149e9210$3ddbb630$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: e69f65d7-61f7-4053-b9b7-08d37411bf9f x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:NY+5GgMhEG6IIbwfmAvQJ2/JYh/ayrrRLhaU+H0I0yHQozuiPiz7A/PtkCKBmUmCGL2YK31KjoA9VBJXHjz5xGMGLVYj+hUCjvsAgNJAk9jCPjk6ygsV8WsOmTS4nKxkWCLCtjcyBAtPZUxGNGvX3Q==; 24:JN+glQQVPQY6caIwW/OJ5g7LL79+AB+clG4P02zyzWp4IuJ7TyaPLzeu3bTQ/t7J8lOtSgix+dS1yvUe1H21phOCFbUZWqpgUjVOpnncx5Q=; 7:jTVS6nhBR/B7KTU9Q/mAxno09ApMsEd+9mogJ+jOskorheqbrZCD5eDBB/MJkrYPxB0eASmBLUV1luZU4643fPJExo86GGkLp7zTYkEtfNQ/sCoqOgfp/OOjaa0Q5HKKkzqGjKQZsnQBPn9GmWVaGDY6OpxdId2usUwvCtLcNtJZMPBkY6hiMXGoDsWk1lYY x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101528026)(9101521098)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121; x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51444003)(106116001)(99286002)(10400500002)(33656002)(19580395003)(5002640100001)(76176999)(54356999)(50986999)(77096005)(86362001)(15975445007)(2950100001)(2900100001)(74316001)(87936001)(230783001)(19580405001)(3280700002)(3660700001)(76576001)(189998001)(81166005)(5008740100001)(102836003)(3846002)(6116002)(92566002)(5004730100002)(4326007)(586003)(1220700001)(2906002)(5001770100001)(11100500001)(122556002)(5890100001)(8936002)(9686002)(66066001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2016 11:46:36.1147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 11:46:42 -0000 Hi Jim, There are at least two obvious uses. The first one is for full-domain hash = RSA signatures. Either SHAKE128 or SHAKE256 can produce a hash value of the= size equal to any RSA modulus size naturally (at two different security st= rength levels: 128 and 256 bits). The size of a hash output is determined b= y the size of the RSA modulus. Therefore, in a full-domain hash RSA signatu= re standard, one can just identify which function to be used. So, the OIDs = for the SHAKE128 and SHAKE256 are useful here.=20 The second use is in RSASSA-PSS where a new MGF can be defined as a SHAKE a= nd the size of an output from this new MGF is determined by the RSA modulus= size and the size of a salt. Therefore, only the OIDs of the SHAKEs are ne= eded in this situation. The SHAKEs produce variable-length outputs in a nat= ural way instead of using some mode of operations with SHA2s and HMAC.=20 Also, the SHAKEs do not rehash/reprocess input when more output bits are ne= eded. They are efficient construction (Sponge), not like SHA2s and HMAC.=20 Regards, Quynh.=20 ________________________________________ From: Jim Schaad Sent: Tuesday, May 3, 2016 4:12 PM To: Dang, Quynh (Fed); 'Russ Housley' Cc: curdle@ietf.org Subject: RE: [Curdle] Comments on draft-housley-cms-eddsa-signatures Quynh, I see that NIST has assigned an OID for SHA256, when they assigned it did they have ideas on when and where it was going to be used. Or did they jus= t assign one because it didn't have one without thinking about it? Jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Dang, Quynh (Fed= ) Sent: Tuesday, May 03, 2016 8:39 AM To: Jim Schaad ; 'Russ Housley' Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures Hi Jim, Russ and all, NIST currently plans to allow the SHAKEs to be used. Please see the documen= t attached to the email John Kelsey sent out on 4/8/2016 with the email title= d Customized shake. The uses of SHAKE256 in the EdDSA with Ed448 are good (prehash and without prehash versions). SHAKE256 is used as a prf in the PureEdDSA with ed448 and a prf produces different output sizes depending on the needs. If an OID for SHAKE256 with some specific output length is needed, NIST can help, just let us know! Regards, Quynh. ________________________________________ From: Curdle on behalf of Jim Schaad Sent: Monday, May 2, 2016 2:45:19 PM To: 'Russ Housley' Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures Russ, Comments inline. jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Monday, May 02, 2016 10:32 AM To: Jim Schaad Cc: curdle@ietf.org Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures Jim Schaad sent me some comments on this document. Since I have asked this working group to adopt this draft, I have gotten Jim's permission to respon= d to the comments on list. > 1. I am not sure that I see a great deal of benefits for doing both the > pre-hash version and pure version of EdDSA. Specifically, the use of th= e > pre-hash version really only seems to make sense if one does not use > signed attributes. However, I think that this is a case which would > never occur for this signature algorithm. Right. Since signed attributes are the most common use with CMS, it is probably better to just make use of PureEdDSA. I suggest adding this text to Section 2 of the document: One of the parameters of the EdDSA algorithm is the "prehash" function. This may be the identity function, resulting in an algorithm called PureEdDSA, or a collision-resistant hash function, resulting in an algorithm called HashEdDSA. In most situations the CMS SignedData includes signed attributes, including the message digest of the content. Since HashEdDSA offers no benefit when signed attributes are present, only PureEdDSA is used with the CMS. And, then change Section 2.1 like this: When the id-EdDSAPublicKey onject identifier is used, the AlgorithmIdentifier parameters field MUST contain EdDSAParameters to specify a particular set of EdDSA parameters: EdDSAParameters ::=3D ENUMERATED { ed25519 (1), -- PureEdDSA ed25519ph (2), -- HashEdDSA; not used in the CMS ed448 (3), -- PureEdDSA ed448ph (4) } -- HashEdDSA; not used in the CMS [JLS] Both of those changes look very reasonable. > 2. We need to get a definition of how to use SHAKE256 from someplace > if we are going to say use the same hash algorithm throughout as that > is what > Ed448 uses. It would be worthwhile to specify what hash algorithms > should be used with each of the different signature algorithms given > that it is not clear from the name of the algorithm identifier. This document references draft-irtf-cfrg-eddsa-05, and that document includes this reference for SHAKE256: [FIPS202] National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS 202, August 2015. I'm not sure what more you think is needed. [JLS] To start with, I think we need to get a reference for an OID for the SHAKE256 algorithm from NIST (or internally) since that is needed as one of the authenticated attributes. I worry that since we have changed this set of identifiers from saying X with Y to just saying X that there is going to be a degree of people missin= g which algorithm is being used as a hash algorithm for this. A second worry is that SHAK256 is defined as being an XOF function and not = a hash function. I think it might make more sense to say that we should be using SHA3-256 rather than SHAKE256. In any event the OID assigned on the NIST web site does not make any statements about the size of output of SHAKE256 and if we are going to use it as a hash algorithm here we need to do that. Suffice it to say that I don't think that using SHAKE256 as a has= h algorithm here is sufficiently defined. > 3. In section 3 para 2: This sentence does not necessarily make sense > for the pure version of EdDSA. In some sense there is no hash > function which is used on the signedAttribute value. I don't know > that it needs to be fixed, but it might be somewhat confusing. You are talking about this paragraph: The same one-way hash function SHOULD be used for computing the message digest on both the eContent and the signedAttributes value if signedAttributes are present. I think the principle is correct. I'm not sure how to address your comment= . [JLS] Yeah, I am not sure how to address my comment here either. The problem as stated above is that there is no explicit hash function that is used as a pre-hash to the signature so people might not know what hash algorithm to be using here. > 4. In section 4, the problem with EdDSA is worse for the use of > different algorithms than what you are stating. It is possible to do > some interesting forgeries if you cross between the pre-hash and not > pre-hash versions with the Ed25519 curve since there is no context > difference between them. This has to be forbidden not just strongly suggested. Does the removal of HashEdDSA resolve this one? [JLS] Yes that would deal with this issue. However, given that currently the difference is just a field in the enumeration it should probably have a security consideration about it. If we can change the PKXI draft so that the pre-hash and pure versions using different OID identifiers, then this because much cleaner and less of a worry. It would currently be potentiall= y necessary to make a RFC 2119 statement about the enumeration which is not proposed above. Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Wed May 4 06:05:51 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AB712D1D4 for ; Wed, 4 May 2016 06:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW9WFENo4QwS for ; Wed, 4 May 2016 06:05:48 -0700 (PDT) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (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 3450512D112 for ; Wed, 4 May 2016 06:05:48 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from thunderbird-2.linux.ds.cam.ac.uk ([131.111.9.24]:38927) by ppsw-43.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:AES128-SHA:128) id 1axwUs-0001Gv-pH (Exim 4.86_36-e07b163) for curdle@ietf.org (return-path ); Wed, 04 May 2016 14:05:46 +0100 Received: from bjh21 (helo=localhost) by thunderbird-2.linux.ds.cam.ac.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1axwUs-0005XL-RC for curdle@ietf.org; Wed, 04 May 2016 14:05:46 +0100 Date: Wed, 4 May 2016 14:05:46 +0100 (BST) From: Ben Harris To: curdle@ietf.org Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: "B.J. Harris" Archived-At: Subject: [Curdle] ssh-ed25519 finally uploaded for adoption X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:05:49 -0000 I wrote draft-bjh21-ssh-ed25519 months ago, and then got distracted by something else. I'm finally paying attention to SSH again, and have discovered that this working group was interested in adopting it. I've just updated it and re-uploaded it as draft-ietf-curdle-ssh-ed25519 and it's awaiting the WG chairs' approval. I'm sorry it took me so long to do this. -- Ben Harris From nobody Wed May 4 06:07:26 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC1012B03D; Wed, 4 May 2016 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSFVlkfL7oXM; Wed, 4 May 2016 06:07:22 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 1D3BB12D112; Wed, 4 May 2016 06:07:22 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id a17so93255097wme.0; Wed, 04 May 2016 06:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=3BND+XzYBpoq0AnBxGVEnVPxLaSgUU3LWFfKvqDJKLM=; b=BPXHh5DPaO4h2QsxWFb2NndIqXybhjzk/A5YWtEJLbyXH7wWUozoJzKxYu4a7+qLWR P7QZBbk/MzeDtj7gpnPpMa5p1oy8ot6qLHxcVdYIoGp2bkOF07TIhsftgWZcSJbcAcvN FGJ2MwkTkQGBJmkFrHiqI0T/DqA7JFZ0EGCGTJYop+q+e1+GotxQgBLcpV5n41uA7Btt zySGrSUCvSBC5+/Tkgfq4zdOpSpy4QJXf1vL+aZWKHKVdJPlIEKC1VSXSe1jeXUCXKUw yfQa+twMeUJp4TDVVAlMLnrJ25eEngoLDfupjz/WtJ9U8g9I36fEXic0G8bbteU/G+aa 4VSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3BND+XzYBpoq0AnBxGVEnVPxLaSgUU3LWFfKvqDJKLM=; b=TLMNe6Jz4vD3fmLS79/Gj+hiy0bL9PV5b2coXmubrUWF/f0B3cmBsRPwXDmeTVVal+ TzxIya2oZgAOQE4zO+1W8nWMNB1Z1ed+h+hDFWN/dtlLGS8YFidSZBm5hA/FCg0f0ZOn m1DR5tGuwCJKVIXKDUUS8VqGbLwE9Hb5uwlXGRbKp7V6fIWrwWH4lAjQpeDXmsbgazW5 eel1/O4f0ZS4qSElzW34lIatmgN/M/+TlzuIV3oiO9MlfRGdVPWIUWejc1ZrQSi1tNbv wBZp9RlZlO1nBCRfBUV+a2tvT6J5YcqQ3T31m3OyKIa0ibqczbcS3d+h4N3aB3nhj96E Khng== X-Gm-Message-State: AOPr4FU8Ke3OaTMAm4hdcMXKzGkUoD9lEziCo0QSKs5LFnWlWy2JdY9dCUyCNm8DSygpvmItx2cnMmm+E0N+OQ== MIME-Version: 1.0 X-Received: by 10.28.150.142 with SMTP id y136mr30847904wmd.28.1462367240601; Wed, 04 May 2016 06:07:20 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.163 with HTTP; Wed, 4 May 2016 06:07:20 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C11224A680@eusaamb107.ericsson.se> References: <2DD56D786E600F45AC6BDE7DA4E8A8C11224A680@eusaamb107.ericsson.se> Date: Wed, 4 May 2016 09:07:20 -0400 X-Google-Sender-Auth: z3zvnqNddv7CdOys2k2oF9Vlipw Message-ID: From: Daniel Migault To: "curdle@ietf.org" Content-Type: multipart/related; boundary=001a114b3f6ae87201053203e7bf Archived-At: Cc: Russ Housley , curdle-chairs Subject: Re: [Curdle] Call for Adoption for draft-housley-cms-chacha20-poly1305-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:07:24 -0000 --001a114b3f6ae87201053203e7bf Content-Type: multipart/alternative; boundary=001a114b3f6ae871fe053203e7be --001a114b3f6ae871fe053203e7be Content-Type: text/plain; charset=UTF-8 Hi, The draft draft-housley-cms-chacha20-poly1305 has been adopted as WG document. BR, Rich and Daniel On Sun, Apr 17, 2016 at 1:04 PM, Daniel Migault wrote: > Hi, > > > > As mentioned last week, this is a call for adoption for > draft-housley-cms-chacha20-poly1305-00.txt. > > > > This starts a Call for Adoption for "Using ChaCha20-Poly1305 Authenticated > Encryption in the Cryptographic Message Syntax (CMS)" > > > > The document is available here: > > https://tools.ietf.org/id/draft-housley-cms-chacha20-poly1305-00.txt > > > > Please review this draft to see if you think it is suitable for adoption > by CURLDE, and comment to the list, clearly stating your view. *Speak Up* > if you have strong opposition to this work. > > > > This call for adoption ends on May 2. > > > > BR, > > Rich and Daniel > > > > > > > > [image: Ericsson] > > *DANIEL MIGAULT * > Researcher > Research > > > *Ericsson* > 8500 Boulevard Decarie > H4P 2N2 Montreal, Canada > Phone +1 514 345 7900 46628 > Mobile +1 514 452 2160 > daniel.migault@ericsson.com > www.ericsson.com > > > > [image: http://www.ericsson.com/current_campaign] > > > > > Legal entity: Ericsson Canada Inc., registered office in Montreal. This > Communication is Confidential. We only send and receive email on the basis > of the terms set out at www.ericsson.com/email_disclaimer > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a114b3f6ae871fe053203e7be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The draft draft-housley-cms-chacha20= -poly1305 has been adopted as WG document.


BR,
Rich and Daniel

On Sun, Apr 17, 2016 at 1:04 PM, Daniel = Migault <daniel.migault@ericsson.com> wrote:

Hi,

=C2=A0

As mentioned last week, this is a call for adoption for draft-housley-cm= s-chacha20-poly1305-00.txt.

=C2=A0

This starts a Call for Adoption for "Using ChaCha20-Poly1305 Authen= ticated Encryption in the Cryptographic Message Syntax (CMS)"

=C2=A0

The document is available here:

https://tools.ietf.org/id/draft-housley-cms-chac= ha20-poly1305-00.txt

=C2=A0

Please review this draft to see if you think it is suitable for adoption= by CURLDE, and comment to the list, clearly stating your view.=C2=A0 *Spea= k Up* if you have strong opposition to this work.

=C2=A0

This call for adoption ends on May 2.

=C2=A0

BR,

Rich and Daniel

=C2=A0

=C2=A0

=C2=A0



DANIEL MIGAULT
Researcher
Research


Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
daniel.mig= ault@ericsson.com
www.ericsson.com =



3D"http://www.ericsson.com/current_campaign"

=C2=A0

Legal entity: Ericsson Canad= a Inc., registered office in Montreal. This Communication is Confidential. = We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer


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


--001a114b3f6ae871fe053203e7be-- --001a114b3f6ae87201053203e7bf Content-Type: image/gif; name="image002.gif" Content-Disposition: inline; filename="image002.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 85d17867a6ac90c7_0.0.2 R0lGODlh9AFQAPcAAGY7JTMiGptoRahyTFtYU67q6g9vjmlIMcXFxWy3ylc3JI25xS6wzIRcQ6nG ygKWuC2RriBYa0dEQBkXFWdCLCcmI9KzrbaPb1dSS9jj40yzzHNKMWZjXLfU2N3d3eWssjYpJACs zM+OkygaE2pqamBbVezRzvX19XhXROLj48Pl5kZBOnFDKolhRzo3Mp2dnQW31LTKzEglFrSZg1FL RKqqq3PB08vc273Nzenp6QMCAnx8e9d6iI54a3HU5UE8NSzC3gKBpYnd52mqvTcxLLmjkQCiw4mt ta/e4p3j5xmqyNzCtovH002bssvV07m5uZrByIRaPKp4eOW3votcPUQzK1XN5D9odnpUOReXue3t 7TIdE7PHyprL09econNSPYVnVeKKlo2NjaCGcJJhQajU2qXM01IpGCQUDtTc3HpQNAKyz4NTNQGd v5rY31gyH8rRzxeKqOedp9vKw9Xa1RYRD1WnvwwLChMLCZ55XVxDNXZzbMmnmnKIi5RcPcPc3U+J mcLT09Pg33NPNIFVOkfF3hwjI+ri3eXy8mA0IdbW1mlTSe7p5KO+xLSAWRK82PLu5wutytLX0uLo 6H1YPpBmTkIrIDAXDkEeEC2EnwGOsbTP0a26tRmwzM3g4DmivxtBTVFcX8TOzRl/nLSqnorT356T iNja1yoyMQYEBHlqYOzm4t/O0lQuHsGypoG/zgwUFl8+K8lsd3peT1M7LYpTNNXX02VMPgCpyaSM gYiWmZifo4tVQm1NOMbt7kpSVoxYOM/Y1gCmx4FOMSEeHE0vHo9tXX1OQK/FyB4OCQ+gwgQJC9HV 1WBqb4SMjvDw8ACuzxccHIZXN2d2ewkICH6Cf55wTTdNVwcOEDAtKXxOMBIQD4ZOMTIOBf///wgG Bg8PDtHR0QIGB8DY2QuPse/r5z4+OycqKdPV0TExMJdaWm1tZGJfWCafv+bn5tzs71BPShWQstvz 865lcs/z8wmpyLrJzOPZ1JpTMo+iobaXmpOTjOvr6+/r7+/u7QAAACH/C1hNUCBEYXRhWE1QPD94 cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1w bWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS42 LWMxMTEgNzkuMTU4MzI1LCAyMDE1LzA5LzEwLTAxOjEwOjIwICAgICAgICAiPiA8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv MS4wLyIgeG1wTU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOmE4YWU0MjY1LWM5MGItNDZm My1hZDI4LWZiODE4YmVhZjcyYiIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDoyNTk5NzcwNEY4 MEExMUU1OUQxQzg2MzZGQUZDRjk3MyIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDoyNTk5Nzcw M0Y4MEExMUU1OUQxQzg2MzZGQUZDRjk3MyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3No b3AgQ0MgMjAxNSAoTWFjaW50b3NoKSI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOjI0YjIyZDk0LTFmNTctNDY1MC1hNDViLWM3NzQ1OGVmNWMxNiIgc3RSZWY6 ZG9jdW1lbnRJRD0iYWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOjFhNTdiMTBlLTE2MDQtMTE3OS1hNjk3 LTlkNDcwNzU4ZWEwNiIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0 YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk4+Lh4N/e 3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayrqqmop6al pKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNycXBvbm1s a2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5ODc2NTQz MjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEAACH5BAAA AAAALAAAAAD0AVAAAAj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWFOjJmFMeR47KPy7CFxEaS JKyTKGFFUxnNkMtzMFGhSofKRToXLszl3Imzp88fLn4IFbrix4qjRyUolUCjKTx4GKKWYMdh3bo9 WHdgNZYnjzUyFA4c6EVFgFky1i6ovSCAygBHF4q44oTMQSMoCxxscoJOkd9THgJ7SEE4hbsciHPw 8/esceMTJ+YY6yV27JdBWLBQ2syZEqHMn0FLIyStNBs1arQNQp35S69eFPTQAjGCGAgiFQxV2E3M kDlywkIIHw6t+Jo1MDoBuci8ufPn0KNLn15R48aO4kB+LMkdFjaU0cK7/zQEszyqbOnSz6TJHj36 dETgE/H5M+hQo0hXKG3qNCqBqVVhldUequQxRh4CbKDGF1iQYZYAZOQxw4QzfPXWBXyQQpcDeC0A xSZw+KXIKYAJVpg7KCbGjxb+MPYMZCcsMZlYvQyCmWaUNNAZJZphERohQLIhpJDaFDnIBkh+oeQg lN1ShSW3gUAMbxVMQIwLQbRhxHDEQXMcDI90Qt2YZJZp5ploTmSdDthlp91IJYEXnni6VXCOneWV Z+ee2cCUzZ+AZkOEoPIRMd98Pd2X31JM0fCUfyVwUNVVAu7Rw4ECRKFZFA4OAOEYExZRBIJwxTVX I6gu4OFeIpIo2GCEof94mGIs+lMOYyc8c0geX1TWi5Jf5NjAsJ1lthkhm0VRmjRDqrGBNkgesIGN g7jWyy16WBIACBUQc44hxIRrCCpx4CIMLlyGYBwMkYCZ5rvwxivvvA9ZJw6bHb3Z3TawTOBvNMQA 3FtuvYVr8JRT7qbwwtlUEGighkacqKJI7ecUVJBKalWlxoxxYAuagWFNVx6LarIjAjgCFx9FcNII h6p+yNdfJQZWmGGJ0WrrY7vKRoseY1ESLBYNzNICsZxhEUUUOS5NRRRULEuIGp8dqUa1Nv56LS0B BCAuuAanM4q56arrJXLu0qv22my3Dd2abYJ0B0ng8FsHLHVM0O8E0fj/67eVVgp8cLjdFr4wwxAL KjFOQxW1aKOO+ocBAVRNKuClB/ZgTA+mvHCpKTPUwAkpoqKs8gUzaPgyFHiZAWJff716YoqIrVjO Ko1Bog/X21bx82tKojBsC8QjTQnTDRxNRQtPS7P00jp2xuRrW9MWAMC8eUuEAdCcCw2XxZ2NnNvk l2/++QXZ2xE1y1Bzxx3gxF/3NvTXv00def+tPzFWDk54wofjFggSZygXzEco9sGPfiAXuahMDkBW 2Vg1Ote5fbygBjWYBgmmsYMLmiIXufDK6eLiMgdwCApdwAEcmEEz2Z1IRSxiBCMawwoUBGAEExjB CHpHC1ocIFjDOxqx/6IwvOQxrwVRAJJnMsPEzWCBeq/RAxHQ4K+EhQsmo1gD2b7XpS/BAH1gDKMY 0WQvNn1DHNRI4/vWCD/4yY9+dajfBPKWP/0Bzn/dmlIAdtMwhwEqYgVkHMWSsgL+NDBjk7qKM17A yBrsYheObMYvfsGOHVSDAyWYSh5Olzq61IVDroMD7Ebkwli5YxKotF05ngEJUkjRElUAwbZg2UM9 fAEFwivisJLHS6Zt5kjSOgAFKBCLWAyzF5qh3gFu8YMAoOF/V8zGKL4XnHQZB21jzKY2t2mRNaXi m9/4RhrHycY2vrF+ccQf/uzIPzwS7nAVAME5/qg4AzLOPo5LCg0gh/8x/1CuKpNaZCMhuQtnhIKS oZgGPHZSyFls8gIaQgYXYtAFFG5CFCwcUc1gRZgMoHISOdCCFg4xw3uMQQ8oXSYtfuC7n90CBcHL UfF0+UTKEFMBxXhS1wJgiZ4W4wBYUFIUZ5NHsJGnAgbQIi7QZU0vcvOpUI3qQTSSCh18MxXhHCc5 y+nG+aFTnezs3+AMtxtuxfNhgJxY4yrGwH4+kB3r4AAJ1rEDge5CDAWVZDPYMY1QpONPMEmHOSRQ gh7sgy4xqAvrNhGIjLqqlDirnRZWIdI59OAWt7hWjQ4gm5T+SkkyRSLSniiWWNBCAT3Vlg7RsEOe /hRYW6sCEbgVsIH/BSCpwhAGF8G3hnZ9UarADe4YvXlVrIZTnFtlIzi6+tU52vGOYwWgwuSJ1kAK cq360QMDHejPykVwBzvQhRhIsIODHpSv5shjb9ajlF9U4wjIiAFeoGCGQMzssYHJwM1mtaKRPqMc 98gFjYBn05TewjUoENawfElaYZ42p8UohiwDsIUdQikAb/ihkm5BCyJUoWEFa4k017Cl3QpHfOMT ropX7LY1WdWq4DyuVrnKXHRuw7n7E+vBDLfHshLQuglUoAQKyU/uPlBSGrtKNfr6C3P8Ah6/kGQe rVSBdJzjJjcxBwH64CEPua6xGi2RIDhKO1rN0B/3AAPQKsPm2Iyl/0a5PB6PMjOI0sZCAXjGczEU UMw7K4AWxdAWLXoB0y/QApa4yY1LHBaH3JpYXeo6TopZTOlKw8vFxTVuVtVYzuXGz8brrGMVdfw/ eFL3TwOUGKKC/Djt8sfI/0FyXNcxVwJIwCaDPWg2/ranPJXHHM3owxFexlgnOEERaUh2slPgAf3S bkWMWAVjiiAW2QR6z8VcM2V6IaxjYeFqdSamn/Mci2CyWTYBeC1MpWgobo3nHKgghxGYak3x/dbS +M73mLwJ4xgjl9PK/bT96PjcdkYXng4b4B8NVYV7DnKBhnTrfyqnMRKwAx7pvYlS0sG/KnaLb+KJ SU1+MY18fCgQ9v8NRjBOkexmC8LZs1JMDla5ijwM8w0X3mkxjEmjQTTteK0BZp8BgGdjsuAAR6fA BqRFmUDbEqa3AIElBtWtllSAXFsKAb1P7KVItEvfYA+7czBdXBnPWLk1BquoR41HU58V1YpbNasr ZsimwJpy3o1rCRY6z/Sko0qj1l9LviVyFzTjCGboQMqDoWxBvJwwk5BVfxkzhwboIRY6leWELVHu sVRrM8P6zGWWLu5YEB0AwwQA6lUflrHooRhPR8EiYjmfgOnGENcgRxvOha6t9xabYg++8CHC77Kb 3X1cFbiNccxOd8Lzx4ube1IYSAPuEmDiHKD43l2wsI7TEX94y1//Swwx/peE4ghlWDzj0+B4QcwO pCtijAUGgXlnTqBKqbiDhbWtmV1qykbCVHoAEAtv8AYRVgyt0ApvgHpHdwA+dEu4VAXbkg22pxvX 0Aa7x3tbF2lrICbD94EgiBDEdVXHl1zmpHxq13wHtzDcUl3Rpyj4wRTbBWtTQXHZRwPcFy7+gj91 41VxVD/9QifjEQoJsBcq13iOB3mRJ1nT5oABUAcuQADmcAfRgAepUAfpVhk+t2A6ggVLV0x8RoAy sAVb0DWYsAWXIAOtkAjDJEyEhgKzMAt6MIHiEg3nEAFGsHtLtVTCQW/Q8HUhGIgh6GL9pmn/BnAn 6FX3c2Nr5zfO/xdAEFNAcodd0xdxd8cOmIhkF/cDgIc/9YMH8hOK8wNy5ecS1zAEHaByN5AGNyAI nuB+sQJDLZILsWAJyUAEzbAOxAAOhgAO1JAKaGAJsREWx1M8lABMRHdnxUCGUpdaT3IJmLCAYUEB bxiHi9A1CDN+1yAMWrKH3th7HRgJgjiOw0d2xneIyQc/9gNHzMd2bceCfhSJ9HEfQuZqr2Z911eD lcMOGMCJE7CI9QMOePA+53Q/ekOKLtES1/AKqXgDDumKGaBfS0grIsUIk6EHOIgBHEAMsGAIyxBO O1Ru5aY0DkIGDYAFdZZnY4gJ2PgNWJUMlkALWyADbBgWEBiHs/9ABAdjdRGAgUZwLsPhjSHgdR5I jkapb4SYaSWIfAGniHC0To5IagZDVvEUj39iXUBBj2xVd9WHj/pIFRe3Aufgicq3jsuXN0I4HlfQ BTcQDA75ii/nbLXTX+7gCq6gCPewCD2kcHiQDHiwRz4EAEAVBS0gAJVABlSgBgdwZ28gAzckARxQ Act1B1U1AsUgA2/QehDYAmAwC7RQG/xjhxUQAcLwAD9Jb0LZCQygAUfZmvlmjv52dmgniqL4lH/z iArTMNmgcGl1XURhFEuxT/folZiYiWF5Dv84cOnkiep0P3U0J4M3LkMwDg55A57wihGZAiDFhI/x DK7QAtbiMzj/FWgiSQFqIA0OAiFME26tQIYYsA97oBLY8A2wcAd4EIytIJg/lGCzAAZg8AM6aCUw EQG48AC5FZRahwv1sJo2YAOu+aCUBpuaJps0dgdalVwCV0c7Jl1WOSi9+XAQV3cORACT8x+ZpI8Y sAK75pzpxKLq9H3h9zd0QgwRwATVeZ2u6H7ucAiHgBgs0hhaYAFgYBm9QgFhCDTDNEyDgJ4l+TSX cQAycAk/wAH7sAPnEA1WZSVEkAyXcAaJIC1fUDScCQZcM0fjRwR4+AB8GJSRoAQMkAA2wARmAKF0 KlyweVybBnDjdFyZppTIRZAGKVYKs0fypHBxN4k/YA6PQ33W/1eiJ5pJmIgBErCizPlVT0lH7Og3 ffMvhgAISPCWr+gJGYAiJnAPq0BZWvAMq8AHDVBMwzRufBaASboBbEAFiEkFT4OSpacHt8AOLkAM 9lkHICCBW3AGCkABmEEJY6oKelAldRAeV3cFbWCaTIUubqoBCfAKTFAGHVCn3ipVI2iIh0gN4XRV hEhVfYpValQ3+fNODhOPHgpkREFIwdko8NCV/nR9JlqDkkoE/yiQ2xA/eBCwZnk39FM3sMCI/MIS oMAEf/CWj4ci91CqlEV5xkBMSRoL2tYLSxeAB6AGJYmYUJMZsmpnCtBSKHV5pscCWzgLleCfK4BD aAlvozCtu/+ndSHAAG+arV2wCR1wA98atNxkHVVFgnhKruVaVecarun6p+DQrgmzmwuHlUKhqNNH ffg6OSW6rxNnazoJigMZtvYJigH7RvGjjkBokOHhqdYpqvqlnSZgAnNwCD8qI1czYJdxGc7isYNQ FgJgDW2Bq5qCBYuZCAqQCMZEAai3AVpjI8airJxpDGAQs85FHrk3rQ+wewuKrdraBYnnkEIbumJU fFglrt+0tOearn2aVerYP7sxT1P7E/O6QBZjSPiYj//RtThIDC8qtmj3u2gLhP1So38Al9m5Ckuw BPfgDiIFCawwBi0gDd+WGleDGnsrFkvaKZ5CBtwruISwAUb/moBvcLiqN4AHsIVC1AKVUAmSWwUy yzeocAVxkLnkoAzXmq1M4LkdQJ2CQBGM9L8A/L8C0UEBzEgEUBAVIAb/KwEFcX0JsQMVMBAV8AIM fBAVsAMGIQEK/AJiUMEE4cALQQL/SwIKQcAvcMADQQIefBAQzMIFbMAFIcKMRMIGYcL/i8IMIQH/ KwYRbMEmjMMGccE3fBAFTMP/QLrgVLpKi7qpq7qr6z51Q2Xw+oIUYzHU10/6aqImyg4lQAM/QBsj QEVogD8D+T5MCbxOeRKGMJ04KqqEsQQmwAjlUCusUASOYAx+EDXAIA2oIb3hNgicQgYDMMhfEbK4 mpiKmwit/4CA4nusg0AIRjQs62sMs1AF3kcMRDALPdAE7dAOn4CtNqCtrrO/D0kRJ+ANqJzKqnwC /0AAqvzKL0AQL3DKqlwDBBEO4ZAQ3hDLAoEA3nACKzwQL+ANBTHLq8zLA4HLCkEA4fDK4QDEAkEC OeDMFewBOdDDBjHMGNzAr6zKyMzMzgzErtzN3uAB0IzANfDKJ4DMA7ED06zKT4DN7fzOqRzPskzO 63zERFuIp8vETOzEq8u6T0s4U7tqVStktftqWIy7JTBxJZCiE1ZhOjQBY7wNA/kNFmqhZ+w+Znl/ V+AGxXudEXkIcDwHIdUiJD0DjlDIiGkaRxILX2AM3CsAg/+8vel501TwvRvAAoprekqHGoQANcSz vuw7C5aQQ3kTAAfgGcbQBBowBEPQuWaQeONAna3YHMocw95gxAiRzgiAwhLgy0+QzLmMELuczDlw AmVdzMQ8EE/gDQhQwWHtDWNN1glBAJAhBgMhBpABxDtQztucwJDBwK681gRBAnB9EIjN1QaB1yeg 1wLB1yeAw4tdEO58AvJcEB6wyxVMAL5sy3tdzjQ8weUsz2Ig2gJB2h6AzcMcw2/tAfqMruaaEQLh z0tbtABttOIUxVNylfJKiQkNFVm7tZnk0JIqgTvVNToUxvhzB+N6xsF7f8RgDgnwByH9tnMgAo4g UoxxCBb/cAFecRbdSzzERAoVQtNvMQAsnZ4P0tJsQBqloSzPszxDPclgAAJ1EMYjcKy1mAh98AoA vgCu47OKB7FYbdjRvNUKgdh1TRDpvM1ZfRBnLRC4PMzsLBCtPcATfs/b/A8RbhAegNkIfAKwndok ntl4XdanDdoDIQEnrtgKnhAhntkVQOIpHOMfvOFsDdkE8dY07OII/g+IzeJAbhBDLsxtXRCn/QLm qBEEYdtJidu5HWNQTGXzFH0JtKj8ca9GRtwNTTkPfWvJPeZhjAYDibSyCcX0Ey6wcA5DgATFW7wZ QNICUAT95d0XoN6AC7jqmQcXoAC5AAkXYA1voTIrzb2I/8neDyLei869LeDoZEDUlTALT6hzxYAJ mL4HHsI6ibe/4xAID9m/zPHhCc7YBREOOYAQHlDXpE4QG67M4QDMbD0Q1owQOVDiHh7kGs7jBHHa 2zzM5/wPYoDrb83jFRDiwS7kOF7D3sDrob3NlQ3iul7jCGDBHrDN6RzMAvHWPZztB8HtGJ7kBfEE J4BpTp4+UI7EU26I1PC0AHOVsju7EGevXb61WZxJKYrcY05hxMDcFl2C5XRjvGslgADS1q0CEckH +GAB/MAPjPDd1hDxEg8hZBAFg9ADLeAKfDDIjsDxXtG9uKq9NI3ehOwp7X2Ykk7JT7gFPZVumI4J qgAFev/hAFwwDvvrBNX5cgdu5MuOwDpOENjc6gPx6rlc5Pec2j+P5D0s9P9QA6yMECcA2uGA6wuB 7NvuDR3O86Y+EE6fEFFf6gch9Iid9ape7QfhytvsAWbf2Fgf7lO12IQ4VenexOsem3eQN1MCH/Eu ZEQ2nI2qr4563PtOYRRW5nWAB3jgkuqKiPNDR1dQCnCOBCrgCSmg8HOwGKzAFmax5xQvDRswA3PQ FV6h55sPIW1RGsCgvTW9+qR/FpL+sjaEBukmAzEpA5i+AzK/CZsQA1Vt1avoeDvPzcmu7Ft/6rou EEQf7uyc4dGu9RR+/Eyf68jP4gtR49ds4Qve87d8/NL/T/xB/PXZ7A2ZLeEX7uq8nPRDz8sZTv4u JoJzH+V1b7QcTWXZkChZfrW2e3dZnI8PDRA0qoDYEiBAwS1bRigcgaZOHTx4qH2jSM3iHYx3wIHb NmFCKCZIRKrwNMkRvns5DvERQEbAS2styUQZNGiMgChRyFjjScbPTwHWBlijomYYMJcDlDpiqlQp z5eVBFSq1KISmF4Ht1iyROGApUtnekBp5KBDjA7jxv25ccOTIEH/5M6lW9cu3XDh7hJ40ddv3wr/ JJyQcLduXr5//Xp7MTevYwR0X3iTS8IbCcOWMf97fLezZ73/GBveeyKctyek574g0do1CQJyP9vt rLlu/4Un3mLbnax67mjDwIHfBd47+AsdyZP7/qfc+XPoylNNp17denWKFcFNIFYhmwvwP8T/WFFe wnka6dNjYM+eAAYC8eWXKEGAxg+DCbUeHNG/YTKIJKrooow46oiYK2xAogw3VFDBgwHw8YCfOfJo oQWXXiKDCmk22EANLBSQQQEsqKiEDGCAqYWbWpIiYwNthvHjpaUGYMoRp6Aio6qrLrwlAEtGkCEW PXqhpRsZnIGCLDPQ6iCttdqKiznmZpvLA2+y1DLLHeTqsspwathyzMZkC00uvlaj7B/b7mrTSsfO pC204f7ZYcsTAqNLDG880FO13MbMsjA446ysz7zCef+hAgS8EcMw467cssw66xKuTOLKjNQuxpyj MjpQoZtOh+tKxS47au6YIBrvwhuvvBXQU4+G9tyTL7766GPHPlpA0Aoh//xDY9iH8ECVQIw48ihB N9woQ4UMMhiAl0NWqoQKMrI9UZphNvDqgFjO2AINS9SghJAYWUjkjFZYqIWKDVjQRpqknLLxXqim murCWWbRAwRMLrlEhjd60QOTVvpIYIEFoDDDjDI2KUMttjyhEky7LPvSzcswPs7QufjUdM02M+6Y MznxSlllueqswK/cNqOr0r0Ye6213Qo181APEu0TNtI2ZdOvHOjElFNKj7Z0ZNI6Xe7TUKN2LhVS TTX/FdU76mD1u1dhPU+CWWmAp1b4CKDv7BI4KIGGFQjSaqEtLukPjYYaGjaib1L5JtU7+FZ2gmts aBYJTwpnZY5D5hgjpwZaoCIKNrwFgAIWDjhAAcyLUcBDbRLBBI9UkjmDBXUT2UAaoOxVPaaWeGyh AX8t2aKbbi7B5I1YMFEAkCFeYZgJJrroAmIo/7jYNzhLtosARz3OFGTHCPvHOOZlrsuynFeWCwHt ZYvsnxO+N9n6lpXmmHy6uCctnO9L5lP8uybbbU65TjD/tzLtb5rpuyTwZoenQU1qA6ya1UqFNa21 SjywihXYZkW2W6FNVyXAQK/elhD/yI1uc3NIHSai/ze+FWgCdYiA4ErRoMJN4h734EMe1ECIKBCC EGooHQAOsIFBqIECCogFuChAuVacQQYyaMUbjAgAALCgRDMSgL2a+JKo7IhfKECBHhRwCdoNDAC5 wwAgmjCEISTgFa8A3vCe9KTjqSZ5JzPMCVJzlx1sRmeiwZSVBqOXSHmjBoYRE/TqMpk/0aUCwEHA CTKjG6QxR3l/9EYg5zLIMilPTPdDE828JxsPGOZOcswkHE8mtJB5ozBpbA4Bo2ZAVFYka1tzAXm8 Jiv1jK09EUQbOyjYtl8xRG4j2CXd0DABh0hkOt/IiEbAUYdtXKEQbihFKRyUAXessAgt+BAWIkeB N/+0IhYUwKEaBuHDA/TiAD9EIhIT8YYkxoubbACGH/ABRXi2pCUXuhAVv2BFTNCuG5hIBAvOEAoI eHEIdkhAAmxAxoeVoQxmIKVh1og+uuRmfnPx3xvnOBw4TaYva/rHE/Jklwq40Y908d/9JjNKkd3F o8/zzSJJasmTHop8p4GoXHKQA0cKBjh8gmg4chDKnv5ULqD8RwWK1lC5mFJqqLSaKjvSKnO8kgYO FBut3FM2s9XylpZ4WwZ5WbdhDQuYEKEGCJOlkTpMIAJWaJbgoOWBGSxhBijwkBo2AIBWDMkrOcTC Ny13Q3GOEwCJICwAPBQvFlBgXrX4CT5+8lgq+IH/DA2gQuNmYc9YKOAMWNyn6RJxBUBAoAl2aIIG DGqD4A2vC0xAKv2ux8a7hNQDo5RLBTwgPZTtb6SycSNHB+MnQd6WtnMU06P2pEe8nIB8KU1kS2Fr l+LWhU97lOltcvBRjj0hkLbF7j9uO9GO/o8u361LbjYGSglgCbzHU+pSmXpAitxhG6xKhwui+rWp qgcDVrVVVrWKAQlU4VfCaogGwyrWEd4hb3szprIMUIgTMhMJKlDcEnJBiQ3cMFyYKAblDjCIvvo1 sH8d7BsUMDkWwEgbd2WBGthQi1qkyA8pSpE0KsuLBjTAnrfY5ob3qQAWcCATmYAABEirAdOiFnhM /7CBDVp7mJVZ5gmK6cv8CHACN8axBlg2bm4/tjO7DCZLe8JyDSRgji2fYGOcyQGVX9ClCpwmHI8S g5xvg6Un0Pk0b2yualwqSDnr2RtycumVO3kXPrX5zGmeKAFygBoSvOzRSnM0pCVdJ0D+5TRq1kFr 23vK98I3VfOtABFc0EBYpkeWWPVvLTGgBwEnRCG75KUv7ebLEeJBwWbdBjjwoFYgNNMNSVDBJFyR BwuMAQU3vKsMihGLXnxzENGuSU3G+a0f7hULMmSDNrSBxBQPYxjcIDeMa8EGNsiQELDbMQUSQYHc 7RMAWIDAA0ZR5CZ8wrQFPegrmlyIJ9OlBtQNrv+gskRwwXhUSwiY6MBJ44GNORzRIiVpbjb6BNrK hU8GP7QYrjuYHHRZkC94NPPa/PA1G0YCOci4YTxOmBOEvC4rb7nGu5uxRr2gUQwH6QtMY5lwQPRl Px80+XYAcS2ZZlEBL+WnoxNqUcuXvuRBD1XhwV+sSlBX+x2IrBfy1WD5coMNIeuAjsmRCDDABkIY NhIyYIoNuEIKX7DcBmJh4g9brhfU/gIWvqCGXmxg7zkcBAwbRwUOaUNd4Fb8uMX9+GFg4RiUuCwK vtALALyBXTLgpxo4kIU2ELnI+kbyvm2AZAYwXfUkrenqXf962Mde9rOnfdOdLh2ow5eYpE7HffP/ q19Z0rKW7FiEQAgia4Uk/+t16w8xRkAMNGxDwU7dBh5AUQ8ID7sLKtjEHvgwBrofQBvwjsU2MUeB XnxB/V/YwDEal+Ntw/BC2XIcG9R1RNKRrlsrXvEx1EBFy/uCHyqGM6AASgi8L8iEB8iCIsO3dmCA 0isECGSAR6g9C7xADMxADdxADbw93Mu9q2GwOugO+0q19ZglXNG6XTE+5AuW/sAg/yiICgiAEZgA cBiQVEEmUGiDQvCBUkgCZ/GFDBAF8Ks7b8msYrAEHoI3BWiFVlCARDAs0jGsF5KhnEA8dMm8N4jC /OtCDxkE97OnL+inG5KGWbirZsiCB1CCIWsH/wh4QAZggE6IQzpMPQ68QzzMQz3cQwvsNA8kleQA wetQpRE8h1OjKlWrlflQQV4BAQ4CprCKQYYIgAoAAUuEvolIlVQ5JlDQBCCwgh9MglKImHEowhsa BG8REbnZAkywBEyQgVtAgVi4BT3IpnNCpxZLNzXQBlQssVZIoiTqwhTTBiyAnS9YBAqQgX4aBkKo og3IBE1QhiwgMjfMgnpQAiXoBG3UxjjkQ2/8RnAMR3G0vU+jmgKiGkEckKwxhO8wQQhKwVwpAVui ARcIAIiovoiIiDoAkGSYgP4wiACwxEs0FgLBg20AhQfohB4UAiRIApHIgFwIPxzShgMAAAUAi/9v CIBFQIFZGIMZMIYxyIVjOABjwAoeerfKYQEUQyJcFEbS8RDKs7xekIEzKKcNwIpQiANyYMA4yAQG zAJhiIRt1Eah7IRxPEqkTEqlfLI/xL0PBEGzmwDv+AFEvDoUbLVcmccqIIZ8vIN8/Mp9rIMRoESB tMQA2Ia9GTWDREgYAIK1c4MCILZ3IIXwOwA1sCsK2CIFCABi2ANTMIUZUIUxcAVXCEl9MIU86AFj iAUnJKwt3CJwc8kUaz9esKdFoMn804YWUIVMiAfRiwMIiAcIyAJciIRs7AQliISiXErWbE3XXEo/ bEp0PEfqoE1Rs4jtKDVzqEpFhMesWsEf4Mr/fNxHfkwGNEgG5BTLgLREIrDECYgvatgG6URIaPhE HxAChyyAAuCCZbOcHPKWbFOAYqiCHuAA2ZkBBEAAUnAFBHCFXHjPflkETEgIzcnLFJPMFAvDL0CB K7iGM4hCAACGFgitePBMz4wDBG2DoMRG1cSFejDN14xQCZ3QPGxKUYHKY4lOVjk1/eKv94hHrboP e8QD5DzOAzvRsQQBIrAEFQWBCbAIatDHaIgATcAFGOjBH5wwB+mBb2G2D8uwHWqFgdCDLeiBIiiC MVhPV+gBS7gFWgCDRUg+E5scb+vCYMxPSjiGY2CHUTCAIPpPbpgGBoQAcsiEOBgFchiFB2gD/yN4 UNVUgnqIUyWgUDqtUzt1vdi00Kd8r+zAmm0gBkN0oP2apazTKnjAj7AEEIcwTuOMxBRl0eZ0UYnA CIOEBRoVhuq0Ah8YtgJQAV+ogXH6qwzDoWmDtx9aBK6ghWKQAT2golZ4xVagxfKzHMqBEXmx0pfU UhQghCvo0iu4gl+4BUDIAtCMBwQdhVEIgjhoA2UQBgd9UyVgAGx8MjHoMjFAgJxSDUYJh2y9jdbT OEVRvQrAjGo9ngrYMm+QObmQgCcIhzUjgEbxBp77hxpIlDDp1tUjgJq709jLUz21TabqU0I0hN4D m1XrLxW8JRflx4coTuRs1EtYThAYCBDgyv+9MUg8MAQD0AQjWINHWMgkIDZf+AN22KYf+quaoKL2 01Je0FKXXVleiNmYVbdBqNVbncIrXdlj4ABkRdZeHdadNFZj7dkHMAJlwAWkxYVohUAke7K+sLn1 8g2d+9bVoKTf2IF9JaWnfdqLeQHtYpMc2Iw22wHcWjnj8rnAUBTXUB/aCzp+zcB/nRqAHUSBVSWp 7L0TvEqsZAd2wIC2SYbhHKFFJdES/UfmHAiu7BuDxAZQMIAHEIYQWAPrxM5O9YVdKD+THado+wIw aAGWjVl1UAcyCF2ZxZANyQlpGL/7zD9gDEaYvYIgCIJ40IRrENMHIId4IAdyONNR6ExlaFP/OI1T CCyognLaxhCDE5ifOkMAzNiB3WiNuSCBvHiUHeCer50e9tHXvMCMF8heyWAMCRCDHQjX5d0M1kjP lwlXitreF6iB7q0BPSnfw5AZ6AWfwPCA3ZgyyegSt/0N6ereSOtejGOTHahXTJHffxADAM6BAR4q M3vbfiXHf+VTitAbvdkbcIiGQBWb3sRKeezbtpkAXfNKX9NHACFcuikIELAEIiACYpC+6MSDGQ0C No3cj73OkC0AX0CCReAhPaDVDytGqrgQXsAQP4jZGJOsE9kQKgCGyEksYSwn19XSWUBTZc2CdlBD 3SUHTQgCTUDWeGiHdljaODStMSIjKDBe/+SdnxeAOLIlATF4I/yN3uklATUjAQRIjTYmAZ8jgO0V Aw/gY6EaKvANh0DmY4hDXsyANARoMxLwgC6TAPa1GQ/YozbegTeWjDYDL0DO47nArfldjUFumSfA 2vTk4zzxOdbwgMa4ZEUWjVL2uAYuKlmOWghmyridmlSqYOzIGmLIht082LJRwb6VACIQ4TtIhWWA hb2RThIlzhRezipwYYjwtWUwhAigYSPABWhoS02lXE/NBwWghW0Cl3DCAkrAEKoYYsTjBT+gAl6I rMcBBmnotngpJ5WU4iTipl44hmnQBE3A3TfMAjUE6NhFVk3Igk/4BAb4BDsw41dwGDMYHv+nva3k nQuW0zjtaqTB+KPGkIDNqLN/yGg7eZlWDofYaLk1cVebQqnUECU26SSuHapWfiPpHWmX/iMsObmi eoKj8l/P2BKUtpTAWLm5yDOdW9efIuk4Fg096d/raddb7tdcFkTqIKa7XQEPjY9FOBtb0hV9rQLu IIZUUJVUIYYAQAOvjEQVZuGtvMdjqgBzuIZR2OYQgIEbxs4k0GEkKAEeugVx+uEvoAQqcJzGaQF1 4zY2kAbGZuxuIx1yUkkAlWIWOIZemIVMwF2FbgLRyuIH8OLYjYMHUIZ2WOiC8h0mcIBN2IQYWG2n TV4SwKmWEep/QAAF5jOa7umd1guOym3/RklXpVnpzeComyaZ0Jjp6WnlSOJt2gYpj2uMcIXkp705 x8AMR1svkiGTmaYM4ubt6g6zNrbaqUaquEVHq9YODXYBCVg1eJSgFdzK7tiGsv6GOrDERa2DFFbh iSWCCqgDjhjBgwgACYgDyF2DG/3mvdbhI+ChjRQnCgCxKLiQBogCyppwaYgCaaBnNnCxYVA8nDUn wiqsyaEALd2DOAjjT2gCFVfxIgsCLgbo0VaCdti31DaDTQgEHMdx4x2qN8KuCgiM5U25p32CJ4iN m8YuEpCAp/3xCljjmZGNzcCuaxWNyjjuo9na5bbf2gokbp2L8aXyosIyzLDtPdmj/j06/0daEwI4 tMJo39oyJCmPDI6C6n8gAJ8WufFmOgu16qbaPWLA2/7y4LRZGxeogOebAAX7tRpU1BcESK6Y5gCw wY6gwRKNgHrg5rZcSMr1BRUgAVroBTCYhb3DIUqIAsQr7MI+Xccehl30ECsN8RAfrCQ6hg1QB0CI B4W2AzAagiNQ8U/IYi4ebTHWt95xgBjAgUBwAmVX9h2XC0juKO1ilMYYpFHObQT46J6B9gpYOT7e IyIvqhyYKOGWCyLf9mc37txeDUvO8nKX9vThM4cL1/RqntjejSvDDKi+dkvB6I8O2z7GDW/XrvR6 lDlfM0zOczz9Q/Pm86tJFalU7+Brb/+vXpsfcNEOeoh9jIhhKQiABBIimGYX3YYRHIGHTQZzIAdM /1gE105fgAI9uIWSnAUs8CYQMfVswZZscexua3UrHSxYF3EKuIVjMIbRbAddX5gjWIAjGCg7+ITR NAKjZYAZFyPVXvZgCAYnCIZmF4xwx40sud4ngJ/crrQcqIGf8nr9sWPt2rTghvLayg39AfObTm66 UHuuvWmvR43t8im+D4w48wb7cTQgN41wOAHjguqQyjiO8mPAb+VG1vuebvyWURM8R/iG6jQJNkcC Mu+5vWA+145fNgdaWcQJmiAMqHiyO06IeNhoBhIgWeEqGIgR4o6ST4ZsiANuNvAbxmH/lncGPTAG Y5B5mrd5eZKJd+YWnlencvr5yXbZHYCAhW6ChWGYRmCYI0iAIci3emBTZmWAIUhtUbD6q9d6DCRz y585oKGS1sDXNELu85c9pdL8ARoVA8oOho+vbaiAdFjvQgWIEgIFciiBYQWREWgWMmS4ZUsATAEC WAoAwhKRKiCIjSC2UGGyZOdG4YK2BgYMIFZ8CBFS4GWZW7OMtcAySA2hKGTICOgpwM9OP9JqsdFm dAMLAEoTMW2aSCkLCsfA7IDQpImdIwugNOoKZcGCBEM0tFNm5Gy7BAsc4IDjJFgwOnRO/atr9y7e vHr1kqiRYy/gwIIHEy5s+DBivC9e/yRu7PgxZME6JlOubPkyZsupNnPu3PnbN8+iR28G/Y0auAnn XNDAgIEAgYHsZLNbtKLKiNy6R1wa8RCiRBkUMVbRyPEjxBHJAowK4fzkI5Usk7ws0OcWmFk2KbHR yVMATyp+/AADRnTYURZJAThlqvTYrWNTAVm1M2Rr1/yNwC4Yq6wNgGm9wpZbwUgiVxqRDSbBCxIo +CCEEUpIAgkSWnhhZJlpuCFmpIkWmochlgYaNdsQk84K8MA2UAmzCcQOOxjQUMUWu9X4W0Q5TgTC RVW4AEJHyeCRDBoPoZFNHMLgEsJJKa3UEnUFHKEHCij0MggW0uhUCRnikeEHFeWxMf8mekitx157 AFAQ1QbHGGPHJ00MkcARXCGjHzIOhJXAJ/+1oYQda7XlxFtz0YUhookquiijjTpq14abUZbKZJRy OKmHlXFWqQ4ijgbaHaqx9lpsL9K2yIwB3PjbQzlKJFEAMvRo3Ah14PENkQ+ZE4QwSjKJknRCRNmF HnosQkEvamARRQtdUvFsedKwgZ5R6qmnFJqJvNGUUlIdU80R9mm1QFcONIIMunl+lQCcyijTzhAD 2hNIgYY+ei+++eq7L4YcWtrppQEL7OlnqZBoIorwYMBiiy9yQIAeP1jCKsVbSISjRSAUB0IFyuHx MR4QXUOOEb2GAA0MjzzypEu+IFH/ggKxxELBBjflJA0VWpJplDbWJpWUU29s656aG6DgzCtHKI1f uk1z4QAUUCTA7ief3NeIPXC4deBc/Hr9Ndhh86tDXWQLfDbamnZKMGemhVrBqCs2/OJsNNBSEY4Q VYzjRRkBCdLHRFpyTRZtlKwkytE9+RI9O5xRDC0zH7DBBmpYbrk2ZlqL7VJMndHKGYm08lS3MukC 1lflIsOF03lCve4QcwqqtROS2CKX2Lnrvjvv+FJ2V9qXse3hwcSgkmKpDMO4CAYSu6oqJqxessX0 O2rMYwDKhTTkCJZc8YDhJZcE7OK+yLOLJcUU84YCFLh/gHpmAnDmUmiCfgb+oI8e/wtTyM6iT34c IEAuxIB16OICAWMQg9ctYFxQQAYORLE1W9yudxa8IAYz+Jjgfco0HhweiUK1mtYkz0UlKAgNVlCR ibxKetR7oUUsoZGNAG5Il/Ae+M4ivsSpRFi+QAQyaFEMSzxOAaSjAOfq1x78MZGJrRjd6BKhB+x4 4QlmKODqCmjAAyowBptYYNTA0gguRNAtzLDdoTSoxjWycXcDE5EHTUONOBIsNAczRDokoCLZDKQg B6nCq1Slqt9MzzfVAwERLIE97S3kEpeoggEAFL6ShSBlQPCBD5LwwwzcQn1DLMYThdaepzSFiTKQ ASZOKYMmfi4RM9ODMbwwhS52Ef+BBkRgF7+4QHM5ABkxEIUE4SCJA6WxjcY8JjIldDZKgTCOphkR aJpJDRGaozUMa5Ef9VAFFkaEYtMrJEQuwiMQBAANyYCII7cwMkmepVfjW1kmzfcMVXjSkzKwxCof 98RQtgKVmPjnP1Gpyny6kgIz04ccpoAAX9pDgbZcHS5jYA9dLjBPXLAHMLU2TFsUM5ke/ShI8RI8 zQyvpHUE1TbgJoHX8BGbGJBAFYQzSOk58pvhTCT2FqK3RxrgAeCbJOJSVoh4IuIE+6hnPe/pT4Ay tamp/Cf+tgUAmbXCGB+QwwcsUEsCIhCiBGzoJhpaQAcQEAdlhAM6bEeHkLK1rW3/HClc0WZSOYIj Gtkwh4pKNRsY1WZGIKhYTQPrG4qMU5EKQQNvQBABcoAvh+0Uxq8uiQR6IOIZT2iFAtaH1GLIgLOv cupTTxlVolGgFcfwAlY/MAV72LK1rItoDMy6VYmeNa0cdStuc6tbs8U1M51ZGxxPQ40JwM2afGTH w+w204d8s6Zo6M0WCjtOVf01ANcYhU9/Gj5foawQpUDCD5+BgFisL7ObfdxA06vK0RINAK3ghRdE EIYPeOEDc3Coa20Z29iG1aEKtEdt0XFb3RK4wB7l7cACxky2kQg1J0Iei2DEAVT9YLnNdW5uwqnI i4STFgq4riay2wbHmmwNDLBB/yn+8I6iekEPCnjxGzbrycfhb5X5ZC/plFIMFnjBCzxA7QdUiwAt 5veisTUrDiSqZABnNBySQMdaDSzlKYNtMiKN66b8BdzghlA11VxYhOumEZo69xLPHYH1EFlONASg GAQYhSZC7FN2ii8SDEgAE8qgghXnwAsb8HAxXhzo9Qmt0Oqjsf5EmWMdU+DHYehxfacgaSJ3tbUA RjIO7NFQTWNUa+EQsC2oLOpRP+p3wKvMP+SaZd+WNI53qINKWSobFNICBIEN7HNzDRGLEDYd53gI La5AjjiLGEDtxEUnEmADM4zDE+94hgekoIdYvFjQ1WYftt/QCm2HUqrswVYiiv8BAB5YIAzzfXSk pzCH1WnatZrGNJLfHUEJfpqCpL43vvtFNkhZJtXLXLVmKtVquj5Y1n0sAQ0qbOZcm7nhH7nERDJm iQhQnOKZiLOc5xw+XNjZBl3owB8ygAhEsEIE0672tV8MACMqoNCF5hbnwn2MeYiAB+eWgxfOrVrW srbSRoY30INZ71Dnu+hG3+C+y9bvSV3qt5FaMINBZddqJq9Fs7lFhRuS624wxMyD5ZEMI2CAsRsg CEHAeLHPsiQNeLwDzhaEBabghVtQG+Uoj8VUVw6AobUXWzHmxY9FMA85yOHRhs+5HBCwxXR9Nehm BWaTQX30yVOeMFbmN6ub/i//zTfzbaNiGAfYAY+sh4RIuUYD18+8ax6Zo+xkPzvaNa72SGjgFWZw OwKkoA+5zyJyMbs73vGe90Un8e+y+EAYAs+DD4gA5zwofH21BgfIZ5qW8BZFpjMKh6FXvvveP/Wp M69lBZvUYKdJqQtWGuHQNy8AtgoJ6heS+kbu2hKDK7vZzY5xYv9U7SFguxlswhNIAc3JnSpYQrXV XczIDBIhURLF3Bm8QSXYHOIVngjIF+HlHPPJgQlI2hSYAAiaACuEQ6bJWwTNm9Chg4B9HwtW3uUp nfgJHMBISoIJXNR9wzYYAhGoX5g1TwUEDpEEYUik3mBZhDmIXf7l3/7JHiVpu8AR7II+SIE6zAOk SYH92d2LyYyaOKACJJG2nAEtqIMsiMAH2NwUmBsfyALhYVUYEF6Q8QActmG6iWA4ANPj4QACaN+n rWAL9mHRvaC/+VZvkRTTgVBdEQGE9REHHMQPDknpwZ/pndlE3B/+JeES9p8w1EMT5IIUdOI8TKE+ BJk+6AEaBFrKGVHwDR/LaZsMUEAezIMU+FgYTIHNlaEIaGBCtaEJJB8c8kDzuWHhBVlCzQErTN9Z 7aEtBAQAOw== --001a114b3f6ae87201053203e7bf Content-Type: image/gif; name="image001.gif" Content-Disposition: inline; filename="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 85d17867a6ac90c7_0.0.1 R0lGODlhRAA8APcAAAIVTgAWUwAWVAQWTwUWUAcXUQkYUgAbUwAbVAoZUwAcVQEdVgMeVwQeWAYf WQAhWQAiWgggWgAjWwAjXAAkXQAlXgEmXwInYAAoYAQnYQApYQAqYQArYgArYwAsZAAuZg0sYA4t YRAtYREuYgQyZAUyZRMvYwczZhQwZAk0ZxYxZQs1aA42ahE3axI4bBQ5bQY9cBU6bgk+cRc7bxg8 cBo9cRo/bRw/bh1Abx5BcB9CcSFDciJEcyNFdCRGdSVHdiZHdylJeStLeyxMfC1NfS5Ofi9Pfy5Q ejBQgC9RezBSfDhQfDFTfTJUfjNUfzRVgDVWgTZXgjdYgzlZhDpahTtbhjxchz1diD5eiT9fikVe hUZfhkFhjEdgh0hhiEljiUtki0xljE1mjU5njk9oj1BpkFFqkVJrklNsk1VulVZvlk9xl1dwl1hx mF1xlFdzlFh0lV9zlll1lmB0l1p2l2F1mGJ2mV56m2V5nF97nGB8nWF9nmJ+n2N/oGSAoWWBomaC o2eDpGyDoG6CpmiEpW2EoW6Fom+Go3aFo3CHpHGIpXKJpnOKp3SMqHWNqXePrHiQrXmRrnqSr3uT sHyUsX6Ws3+XtISYr4easoibs4mctIqdtYueto2guI6huY+iupCjvJKlvZOmvpSnwJmou5WpwZqp vJuqvZyrvp2sv56twJ+uwaCvwqGww6KxxaOyxqS0x6W1yKa2yai4y6m5zKu6zay7zq28z7C8yq69 0bG9y6++0rK+zLO/zbTAzrXBz7bC0LjD0bnE0rrG07vH1bzI1r3J177K2L/L2cDM2sHN28PP3cfP 18TQ3sjQ2MbS4MrS28fT4cvT3MzV3c3W3s7X38/Y4NDZ4dLa4tPb5NTc5dXd5tbe59fg6Nni6trj 69vk7N/k5t3l7uDl6OHm6eLn6uPo6+Tp7OXq7ebs7uft7+nu8Orv8uvw8+zx9O3y9e7z9u/19/D2 +PL3+fP4+/T5/PX6/fb7/vn7+Pz6/vr8+ff9//v9+vn+//z/+/7//CH+EUNyZWF0ZWQgd2l0aCBH SU1QACwAAAAARAA8AAAI/gD/CRxIsKDBgwgN8tOnb1/ChxAjSjR4792vMyAaBLllb6LHjxDtvau2 SMYBCRYsSHAwSx/IlyD5ufMWCkqDBihTppQghB3MnxDhgbPVhsNJnUhTHigHtCnBeuCMKcpRAGfS qxLMOW1qTpmmKQ+OXr16oIu7rS/fPSOlhsQBB2OxPmiAwxg/tB6xtfLTo4HYuDolHOBQZI4xvBPf XYpiNCfgnQ0e5FDDyRniifUuSbD6OKWDAyPAVArW7rJHcSMcAxYcwUkjW99Mf9xnrMDjzQVw8JGF jR5BcrFMKZP90BmBuBEKcCCTSprPgfhs6VFCw8UOQfCIH0SX4wFSwQ2Y/lxqppWgNEdOaHCQwB7l Jd/aCe7D1fhBgheBjJWDL5AdqCo1iMBeUhLIoE58Bd3TjB9VuCELOfEUpEsaNJCgEmAFMIVgQfPA I49LA1mDSA4krNeZBBycs+FD7ISCxAgcdIbUAXRkt2JB9ghjhoUyJuWAEN7cONA+2zByg2o9pkSE J+/849CN6tDhAJKdZcCBDH5UIyRB8exxQJIpgeACGLR0tCVB3nh3ogQeuLBEJuQQdI+ZQvIzjG1x sZeBC0EEMtxA/LCjVyjGPHejNF8SyF4KQLARC53/vIONLGp8UMABB7wxjpDvQCHWSh70EEYnQQ5k Tze9HLLDAZxZMIAi/vPcyE8yRGxw0g1bOIJMQeQIcwkVglEpwQjobIlNJHksQstZA7mDzCdosFDA lBhqeCZB/FBTyh1A3EQlgSykc+1A5LQSyBMctHrbAZLwJ2Q9vjSiRQsOUHuiAwWQ8EexW5pjSRg7 WKDuaic5QckvTW5JDRMj2HuiXzQAYss29Vz7DhYD53nABmawgg2z41rTgIybHZDEJtio8+S4//Aj TKIasyAIM+tUzHJB3IyMFU5j0MKOuzcT9M4aMKv04ybl2HNX0AmZ4wVOErTQxzT5MD3RPWsFI4/V XHft9ddghy322GSX7dEywQijtjDBxDlN2mofwy87vhyjokDY0GLK/iq9lOPQpHsHc6A+zrRSCivI xPqPOr2ggoovB0aaTDDBiPvP29XwM0YOO8hQgwwvrPKPHTjkUEMNQZiRzD/HvOBELf+0s8kUKTwg QQqb/GPKFCVE1kMw9GxSRGNRxKYMG0dKcMMbu2KTBQ41bFIxHTfwYY8QDYiQRRVURGHLP1oc0AIX UWz2xD++DMACK/9cwgEBOdThhxOVYEMvEIoYQscww3DgQBSM4MMdypEOKEwpDnBYyRTQQY0c+GUH 0vhHFQ4ghnoYwQFGqAc60GGOefDDCwcAAzbScYSU/OMXBXCBLKghgwJQIRjskNQ5VpEBC/xBIOpg hycEMAJR/OMe/kzJBAcisAh1nCMRBxCBJrbhgwgIZhL/6IIDyGDBCMhAE5SQhCa48Q8QXoF/MpAA E05YgBe04hVfCkVBlIGSHNhhFaVhBQEyIIRA3EIgX9iABO7mDfaYoRs94MALOHADcnxhihZ0TNRg 5wUHiEAGNLAAEbpBxhekAhQDeEEuCqIPQfglaleYRjrQgKkNvKAN9mCCBFjwJHfAoAFYwEYg8xAF AnwCChGgohGixgc7zAEQ0+jiA1RghBiNQEUoNGMqBAACWRjkHccgxAxs54Z/rMMWcuhdA4YBhZSY yR0ecAAXACmBVFRCAjt4gQR0+YAx3uMeDtkHCKngDVGs5xJk/lRh/xrABkMRxB7heIEDoECQVdCA AKawAwgcsMl/7GIwg+jGDspJjiRIIAPrTKQLAKEHPcBBGF08QBbaUQ8VWAAI+WyFPNxgGydcYhWH +MQ3xtAJW1BCJWrABhlKYYs0cGAAtaBGCSQAg1UYVAIzkAY2JjqKf0ACBBLIZT2w1x4JFIAT/8gC Aaqwjn+kQQIbUEYw1Ce6bogBJ1ZyAB6SwYG2YvQG1ODFANq6gQR8IU6mWE9bh3WKfzijO2osRxFu UsFWcKITiO3EJYLJikasIlbSmMQkhvENRmRCS/+wxzAKcQYy+MEY6thEHMighkyo6BuRaMMY4rAK kHXDEWY4FUMkKPkPc3giEtEQyC4o4YhX3CMgAAA7 --001a114b3f6ae87201053203e7bf-- From nobody Wed May 4 06:08:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDA112D1E4 for ; Wed, 4 May 2016 06:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbYJEaf2TVRk for ; Wed, 4 May 2016 06:08:22 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 7EACD12D1CC for ; Wed, 4 May 2016 06:08:21 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n129so188087085wmn.1 for ; Wed, 04 May 2016 06:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=irr9OOr0f68X0hN3oD26EFd/owhodeJxVSlp0yTQlsQ=; b=FpgKLJk/cYOdw3PcfSO/zoIWJ64Qn9pfQXZgqjj0K2N8HD5fxKdGYpYdYVwr/X01OS 2kEGcsBdScShmCMX1pCzglBgzaJnGvmCHIM99/E41MXdwhT0PHm6kdjCAbU/ko2yV1MV RncTy2AxsliCcPpPZrJXZ3l9QnzGQAh/8oYYXK6l5Ox/DUnIb64UHZaRgxgnHt9pNm1W PgDkKiCAM/JVQfiqN143bEorI8fVxVHMm/26noYWSAnyLR3mRgbSxy2mVx068bm/1u5t Gv7DcNrrga/1B8XOVIrx0ycJwppUzytU0dymS4Lg3IzTqcUXkA2158MV4L7vZpD8MRXI Kayw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=irr9OOr0f68X0hN3oD26EFd/owhodeJxVSlp0yTQlsQ=; b=DCBLMn3l+JcNyQF9eNcprjSXtb7yem1kPSHxkcATBtzbfABLufkv7S9XSuNTs92QvZ MzBH9j7h6s9l0aedJ3aJLX8Hv5BBUtFY/QEQMlASunjCuzuVhmL+DdH6jmA5L0aeQBLd 4Rj9GVAPBPp4WZO5rcStHVC7uQSP9Vh4LtP67sSlcgvSyePHM4L8usRLti0PmZLTUZJ+ /wdLbOM8aI6rNpUaUP6a6QYNl6kBv59/GWirLF1SsaHWYXXTAYrOVvOxRZLekT9p01DL qv4AjUkT9DAOX3r8BYw3q/Ex/MQXmqg0+mZM4nkKQbziWYqtcSf22sevYkXosCchnui3 56iA== X-Gm-Message-State: AOPr4FVeWA6Lg8g4HbMk6f0INHlH7A3FL3toMT9bZ1cnaZAXT/6QBmKOdF2mESQ320NwejMhuh8zs170ZanlyQ== MIME-Version: 1.0 X-Received: by 10.195.6.65 with SMTP id cs1mr8130478wjd.8.1462367300144; Wed, 04 May 2016 06:08:20 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.163 with HTTP; Wed, 4 May 2016 06:08:20 -0700 (PDT) In-Reply-To: <090b01d198e3$72cde7b0$5869b710$@augustcellars.com> References: <2DD56D786E600F45AC6BDE7DA4E8A8C1122418FD@eusaamb107.ericsson.se> <090b01d198e3$72cde7b0$5869b710$@augustcellars.com> Date: Wed, 4 May 2016 09:08:20 -0400 X-Google-Sender-Auth: g4bIli5GaijWqghCeldmwpYDCZY Message-ID: From: Daniel Migault To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11c296ae74d345053203eb9a Archived-At: Cc: curdle@ietf.org, Russ Housley Subject: Re: [Curdle] Call for Adoption for draft-housley-cms-ecdh-new-curves-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:08:24 -0000 --001a11c296ae74d345053203eb9a Content-Type: text/plain; charset=UTF-8 Hi, The draft draft-housley-cms-ecdh-new-curves has been adopted as WG document. BR, Rich and Daniel On Sun, Apr 17, 2016 at 3:57 PM, Jim Schaad wrote: > I have reviewed early drafts of this document and feel that it should be > adopted by the working group. I have some issues with some parts of the > document, but that is normal for documents adopted into a working group. > > Jim > > > > -----Original Message----- > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel > Migault > > Sent: Friday, April 15, 2016 2:52 PM > > To: Russ Housley ; curdle@ietf.org > > Subject: [Curdle] Call for Adoption for > draft-housley-cms-ecdh-new-curves- > > 00.txt > > > > Hi, > > > > As mentioned last week, this is a call for adoption for > draft-housley-cms-ecdh- > > new-curves-00.txt. > > > > This starts a Call for Adoption for "Use of the Elliptic Curve > Diffie-Hellman Key > > Agreement Algorithm with > > Curve 25519 and Curve 448 in the Cryptographic Message Syntax (CMS)" > > > > The document is available here: > > https://www.ietf.org/id/draft-housley-cms-ecdh-new-curves-00.txt > > > > Please review this draft to see if you think it is suitable for adoption > by CURLDE, > > and comment to the list, clearly stating your view. *Speak Up* if you > have > > strong opposition to this work. > > > > This call for adoption ends on April 29. > > > > BR, > > Rich and Daniel > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a11c296ae74d345053203eb9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The draft draft-housley-cms-ecdh-new= -curves has been adopted as WG document.


BR,
Ric= h and Daniel

On Sun, Apr 17, 2016 at 3:57 PM, Jim Schaad <ietf@augustcellars.com= > wrote:
I have reviewed ea= rly drafts of this document and feel that it should be
adopted by the working group.=C2=A0 I have some issues with some parts of t= he
document, but that is normal for documents adopted into a working group.
Jim


> -----Original Message-----
> From: Curdle [mailto:curdle= -bounces@ietf.org] On Behalf Of Daniel Migault
> Sent: Friday, April 15, 2016 2:52 PM
> To: Russ Housley <housley@v= igilsec.com>; curdle@ietf.org=
> Subject: [Curdle] Call for Adoption for draft-housley-cms-ecdh-new-cur= ves-
> 00.txt
>
> Hi,
>
> As mentioned last week, this is a call for adoption for
draft-housley-cms-ecdh-
> new-curves-00.txt.
>
> This starts a Call for Adoption for "Use of the Elliptic Curve Diffie-Hellman Key
> Agreement Algorithm with
>=C2=A0 =C2=A0Curve 25519 and Curve 448 in the Cryptographic Message Syn= tax (CMS)"
>
> The document is available here:
> https://www.ietf.org/id/draft-h= ousley-cms-ecdh-new-curves-00.txt
>
> Please review this draft to see if you think it is suitable for adopti= on
by CURLDE,
> and comment to the list, clearly stating your view.=C2=A0 *Speak Up* i= f you
have
> strong opposition to this work.
>
> This call for adoption ends on April 29.
>
> BR,
> Rich and Daniel
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a11c296ae74d345053203eb9a-- From nobody Wed May 4 06:28:05 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB35812D112; Wed, 4 May 2016 06:28:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504132802.8340.62906.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 06:28:02 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:28:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Ed25519 public key algorithm for the Secure Shell (SSH) protocol Author : Ben Harris Filename : draft-ietf-curdle-ssh-ed25519-00.txt Pages : 4 Date : 2016-05-04 Abstract: This document describes the use of the Ed25519 digital signature algorithm in the Secure Shell (SSH) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ed25519/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 07:14:14 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E049912D1ED for ; Wed, 4 May 2016 07:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuCVKWcFWKPB for ; Wed, 4 May 2016 07:14:11 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id CB6E412B058 for ; Wed, 4 May 2016 07:14:09 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 83206F24013 for ; Wed, 4 May 2016 10:14:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id fXE+bzr-Z7Q6 for ; Wed, 4 May 2016 09:57:36 -0400 (EDT) Received: from [5.5.33.76] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 36BBFF2401F for ; Wed, 4 May 2016 10:13:56 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_2965531E-2349-4809-80EA-A9F6D9798A6A" Message-Id: <18FD37A0-3B69-4231-95D6-9BF5F68F1E28@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 4 May 2016 10:13:54 -0400 References: <2DD56D786E600F45AC6BDE7DA4E8A8C1122418FD@eusaamb107.ericsson.se> <090b01d198e3$72cde7b0$5869b710$@augustcellars.com> To: curdle@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] Call for Adoption for draft-housley-cms-ecdh-new-curves-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:14:14 -0000 --Apple-Mail=_2965531E-2349-4809-80EA-A9F6D9798A6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The current document includes this placeholder =85 2.2. HKDF {{{ Should we specify a way to use HKDF from RFC 5869? }}} if ukm is provided, then salt =3D ukm, else salt =3D zero PRK =3D HKDF-Extract(salt, K) KEK =3D HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeOf(KEK)) One person said that they would like to see this done. I have not heard = anyone speak against. If you do not think this is desirable, please speak now. Otherwise, I = will work on this text before posting the WG version of the document. Russ On May 4, 2016, at 9:08 AM, Daniel Migault = wrote: > Hi,=20 >=20 > The draft draft-housley-cms-ecdh-new-curves has been adopted as WG = document. >=20 >=20 > BR,=20 > Rich and Daniel >=20 > On Sun, Apr 17, 2016 at 3:57 PM, Jim Schaad = wrote: > I have reviewed early drafts of this document and feel that it should = be > adopted by the working group. I have some issues with some parts of = the > document, but that is normal for documents adopted into a working = group. >=20 > Jim >=20 >=20 > > -----Original Message----- > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault > > Sent: Friday, April 15, 2016 2:52 PM > > To: Russ Housley ; curdle@ietf.org > > Subject: [Curdle] Call for Adoption for = draft-housley-cms-ecdh-new-curves- > > 00.txt > > > > Hi, > > > > As mentioned last week, this is a call for adoption for > draft-housley-cms-ecdh- > > new-curves-00.txt. > > > > This starts a Call for Adoption for "Use of the Elliptic Curve > Diffie-Hellman Key > > Agreement Algorithm with > > Curve 25519 and Curve 448 in the Cryptographic Message Syntax = (CMS)" > > > > The document is available here: > > https://www.ietf.org/id/draft-housley-cms-ecdh-new-curves-00.txt > > > > Please review this draft to see if you think it is suitable for = adoption > by CURLDE, > > and comment to the list, clearly stating your view. *Speak Up* if = you > have > > strong opposition to this work. > > > > This call for adoption ends on April 29. > > > > BR, > > Rich and Daniel > > > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_2965531E-2349-4809-80EA-A9F6D9798A6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = current document includes this placeholder = =85

2.2. =  HKDF

   {{{ Should we specify a = way to use HKDF from RFC 5869? }}}

  =     if ukm is provided, then salt =3D ukm, else salt =3D = zero
      PRK =3D HKDF-Extract(salt, = K)

      KEK =3D = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), = SizeOf(KEK))

One person said that they would = like to see this done.  I have not heard anyone speak = against.

If you do not think this is desirable, = please speak now.  Otherwise, I will work on this text before = posting the WG version of the = document.

Russ


On May 4, 2016, at 9:08 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

The draft = draft-housley-cms-ecdh-new-curves has been adopted as WG = document.


BR,
Rich and Daniel

On Sun, Apr 17, = 2016 at 3:57 PM, Jim Schaad <ietf@augustcellars.com> = wrote:
I have reviewed early = drafts of this document and feel that it should be
adopted by the working group.  I have some issues with some parts = of the
document, but that is normal for documents adopted into a working = group.

Jim


> -----Original Message-----
> From: Curdle [mailto:curdle-bounces@ietf.org] On = Behalf Of Daniel Migault
> Sent: Friday, April 15, 2016 2:52 PM
> To: Russ Housley <housley@vigilsec.com>; curdle@ietf.org
> Subject: [Curdle] Call for Adoption for = draft-housley-cms-ecdh-new-curves-
> 00.txt
>
> Hi,
>
> As mentioned last week, this is a call for adoption for
draft-housley-cms-ecdh-
> new-curves-00.txt.
>
> This starts a Call for Adoption for "Use of the Elliptic Curve
Diffie-Hellman Key
> Agreement Algorithm with
>   Curve 25519 and Curve 448 in the Cryptographic Message = Syntax (CMS)"
>
> The document is available here:
> https://www.ietf.org/id/draft-housley-cms-ecdh-new-curve= s-00.txt
>
> Please review this draft to see if you think it is suitable for = adoption
by CURLDE,
> and comment to the list, clearly stating your view.  *Speak = Up* if you
have
> strong opposition to this work.
>
> This call for adoption ends on April 29.
>
> BR,
> Rich and Daniel
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle

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

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

= --Apple-Mail=_2965531E-2349-4809-80EA-A9F6D9798A6A-- From nobody Wed May 4 07:23:38 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC38012D6C5; Wed, 4 May 2016 07:23:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160504142337.8366.37995.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2016 07:23:37 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:23:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) Author : Russell Housley Filename : draft-ietf-curdle-cms-chacha20-poly1305-00.txt Pages : 8 Date : 2016-05-04 Abstract: This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is a construction of the ChaCha stream cipher and Poly1305 authenticator. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-chacha20-poly1305-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 4 08:01:17 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCFD12D508 for ; Wed, 4 May 2016 08:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqJbKpb3SybQ for ; Wed, 4 May 2016 08:01:09 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 25BCB12D6B9 for ; Wed, 4 May 2016 08:00:57 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f89so56539156ioi.0 for ; Wed, 04 May 2016 08:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8PYmWdD0xJ7ejuBFw3UgpZ6ld2Ip0VNXWuD8/Cmr79g=; b=VuLaOZYZ9kuo1WW/vd5sIrwQ08CSfRbjxa0JqUN5xDMmElbG4U5zSThfwB5nWd4X/m DcGmAd88I0BaYz4Ur+Gp4lqRO1gdI3EN4TQ8XR/6jSaZNQ+PAkyf1VEz/4LNOVbT8ZKm jMnUCKpEm6JlVLYEzfHLclWb/yH45TmsJcLzz8m4+8ahbblFXe2CVW3TJv+c6/BG+5ca yiqeGS1j2hX289BhXtxu5mwWx8GOyhY5goly/EW091UF1NXNevtBBCjvg5o12xyv4eZ3 7UYZ7Ur68Q9jqeBL/qeLQ3DmyMQdtl3jILTCG2XY3bT1m35uI4NpapwlOohHkrYvKNRD HFjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8PYmWdD0xJ7ejuBFw3UgpZ6ld2Ip0VNXWuD8/Cmr79g=; b=mWc1IzhHot78hp+UOy9RzyIQULns1vg9i4GO3Mxf24BhqLCJDAPotAamfzVPmWh9aF z5I3QRYnpHNM3eQc4TRdDpzesj0BKYBah30k+wgmvzOeru6iC/VIxUSYab8nVdPqayXI lqPNd6QXSPEa8Xbua2crixHTYDn6hcHZDpQ+sLTvJCh/EwM7DC9haXUXCaE7bTzbEzWR K3g/7UaDkAmIZrz3pmL8NpfAwtpyFQSWMl5k7S/RkkTIEWKbUbsCglmx0K8gRaOYO3bH FIUXe3kGDpGbwvfLLtgovJZtD/cJYCtmI+SJrb930si5zfItrvGxBIdrTLq32VDJHtVk S9bQ== X-Gm-Message-State: AOPr4FUJnHKHQgUqCuQVhrkFMp9kKMd4X4yQpuTTGf0Of8x1c++Fyi6cpwYj488CyXCjh/jnzToJQ3kqBfD1EA== MIME-Version: 1.0 X-Received: by 10.107.136.76 with SMTP id k73mr11668775iod.100.1462374056578; Wed, 04 May 2016 08:00:56 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 4 May 2016 08:00:56 -0700 (PDT) In-Reply-To: <18FD37A0-3B69-4231-95D6-9BF5F68F1E28@vigilsec.com> References: <2DD56D786E600F45AC6BDE7DA4E8A8C1122418FD@eusaamb107.ericsson.se> <090b01d198e3$72cde7b0$5869b710$@augustcellars.com> <18FD37A0-3B69-4231-95D6-9BF5F68F1E28@vigilsec.com> Date: Thu, 5 May 2016 01:00:56 +1000 Message-ID: From: Martin Thomson To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Call for Adoption for draft-housley-cms-ecdh-new-curves-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:01:16 -0000 On 5 May 2016 at 00:13, Russ Housley wrote: > If you do not think this is desirable, please speak now. Otherwise, I will > work on this text before posting the WG version of the document. I agree with that person. We're using HKDF lots more now. In particular, the API is much better than the alternatives that I've seen. From nobody Wed May 4 08:17:56 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D8412D754; Wed, 4 May 2016 08:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96HtUJdm5lPS; Wed, 4 May 2016 08:17:53 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF9A12D704; Wed, 4 May 2016 08:15:36 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id bi2so150751832igb.0; Wed, 04 May 2016 08:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oUT7VHMLWYMBTbBfHYtAW5fDFpSLNDqS0X2wQ1Cexeo=; b=mF1PB9VRLXv8wfuh+j8tSpvyHwRCI30bFI6DD9JAzUlOH6bWJ6DHMEShDFgC2wy1zT IxXs9sPIj+Awurv6YM/HVIatqO27yLivLOdk0913sAKA4cZUgzdxwVMW+mfpGs6H+aTK M7CADV3fNenC0PSRrACkxRT074h3svjUPE4O06klVElaDNkBEB9wARRqYaNhR9guc+nU j16aB9wHSTJweMBsSpCJR/TN27tZlL7s8pEa399UjGqJjVwgkm2HgUyfa2V8+uLo/Yrr 4Ktk6HImkx69QCWigxrSAuLMwfoQidEr7dQ1SU4MICaP0DrlDQfYX86IIRJ8sqjqPAdc Qv+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oUT7VHMLWYMBTbBfHYtAW5fDFpSLNDqS0X2wQ1Cexeo=; b=G5BHpI/JBaOy0ovK6R8AscglIvnISxDI6rInuvw0NKNEs5uPPgI71u0eG/mMxEsKf/ 56aNA4pUxXOVCG2p/7DDLhyQgeE5POC9wtLWdT71L+EriEHgmJWbhTIClbp8PS+ijg0z JXPYFefXn5p/dRwfldcjblud+ddFjGU05E2JBFLdQf4AHU6KFrZ0UzLon0e7tBye4OiK qIKpRIpkadvG84q0VxVp/DYcAf2e60fi/q6lq5lBw4ZiZ2rvgE+EOnopePA4z/bTKH8u 4vlleFXUNvRC57AMtALkf4c5MdOaRfmqI3ivv9VLgjs/e4r8nOyceUChfCiCVPFscHu7 Kbvg== X-Gm-Message-State: AOPr4FUybLQ2QlHmvw7Q5484/jmMEmRnkh6seGW08X2NBRW57RWqnNXTTABIvCzmwUK8lALa3LZvJNAAz4nETA== MIME-Version: 1.0 X-Received: by 10.50.183.7 with SMTP id ei7mr12007751igc.77.1462374936271; Wed, 04 May 2016 08:15:36 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 4 May 2016 08:15:36 -0700 (PDT) In-Reply-To: <20160504132802.8340.62906.idtracker@ietfa.amsl.com> References: <20160504132802.8340.62906.idtracker@ietfa.amsl.com> Date: Thu, 5 May 2016 01:15:36 +1000 Message-ID: From: Martin Thomson To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: curdle@ietf.org, i-d-announce@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:17:54 -0000 On 4 May 2016 at 23:28, wrote: > Filename : draft-ietf-curdle-ssh-ed25519-00.txt Fastest call for adoption ever. Did I miss it? (Yes, I think we should adopt this.) From nobody Thu May 5 07:42:52 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7881C12DB19; Thu, 5 May 2016 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyIqt12qG3UE; Thu, 5 May 2016 07:42:49 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C8712D1E1; Thu, 5 May 2016 07:35:33 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id g17so31172447wme.1; Thu, 05 May 2016 07:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=qIG807cviZSQNpiZkkA02fbsY/5ULdWkw0uyODT6G7Q=; b=z55A/FY8ZKobrNhbVlNtPjSQT3GvjZrh94hE9Fdb0nwboWiM2XRiSftmuevSW7bh0t MWEnUqWDucvmi0KnUXfCGNEafPI6cVcPeJp2qwgLik+c5ofGMJCWZIEM81MVXOD+s987 ufWFXX/S3TtR7pOOGMabU0o1RFeothLonCCRbIwLdK2NEE9RyNdE7jd8Ze3ed8iii4Tz An6wcVjPHGE3Hg+cGXxYs6tYm9x8oFfBmylvofu9ehUWW0qWjlexuQnxIVWkZOD2irE+ b2v0BxglSsf49hinH7USZ0MBWzndl6SIPERnigFA6K0GW5zZaEi9zhns9slVnqIj3hZy upcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc; bh=qIG807cviZSQNpiZkkA02fbsY/5ULdWkw0uyODT6G7Q=; b=Hx9aCw8noK+Qo+qDYXRrAGa3R8plDOHticPKTZcM11tKtIAzURCxr9gx5JETlZ5tlP RLRKAKb6WUys5ofWS6HFP59upjNBE0CslQu+7Cg11XpiIIxFcH6GDPz0Eqzu7DzwX1kA jkJWTBHAJhGm1XlsmsLd8I6lqZGjnEG9wrTknhMRpjAnyc5t+kmvVHDVblMoZR/xDTUL L4YpYOATzA6F6qyCxTw33/vfzY6vRl80O3n/tyJ1nAaI1Tza2ti2ZbwyfYkv7eXQWl7j 8ZOdHJRSHqrPM1ECMzIq6Wn46g3HIRvqKtQTTny63uTZd+V7tWj6uOYNcip7rhJ+D5ns a6mQ== X-Gm-Message-State: AOPr4FVLV5rKeukBPF0rUk4ni3Oiet3i9MQrJYZQ0J/T04TgK65iwHdfDy9gP/i83k8kQYOYiYp1fC3mpO3vOQ== MIME-Version: 1.0 X-Received: by 10.28.2.67 with SMTP id 64mr3702860wmc.70.1462458931670; Thu, 05 May 2016 07:35:31 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.163 with HTTP; Thu, 5 May 2016 07:35:31 -0700 (PDT) Date: Thu, 5 May 2016 10:35:31 -0400 X-Google-Sender-Auth: S1yw6mbfJ8R3Uo4NHYyUP7AsPS8 Message-ID: From: Daniel Migault To: curdle@ietf.org Content-Type: multipart/alternative; boundary=001a113c81e21ef82105321941b2 Archived-At: Cc: curdle-chairs Subject: [Curdle] Call for adoption of draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:42:51 -0000 --001a113c81e21ef82105321941b2 Content-Type: text/plain; charset=UTF-8 Hi, This starts a Call for Adoption for "Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)" The document is available here: https://www.ietf.org/id/draft-housley-cms-eddsa-signatures-00.txt Please review this draft to see if you think it is suitable for adoption by CURLDE, and comment to the list, clearly stating your view. *Speak Up* if you have strong opposition to this work. This call for adoption ends on May 20. BR, Rich and Daniel --001a113c81e21ef82105321941b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

This starts a Call for Adoption for &quo= t;Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)"

The document is available here:

https:/= /www.ietf.org/id/draft-housley-cms-eddsa-signatures-00.txt

Please review this draft to see if you think it is suitable for adopt= ion by CURLDE, and comment to the list, clearly stating your view.=C2=A0 *Spea= k=20 Up* if you have strong opposition to this work.

This call for adoption ends on May 20.

BR,
Rich and Daniel

--001a113c81e21ef82105321941b2-- From nobody Thu May 5 08:01:39 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F31DA12DACF; Thu, 5 May 2016 08:01:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505150137.20600.23176.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 08:01:37 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 15:01:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-00.txt Pages : 13 Date : 2016-05-05 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellamn (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 11:00:41 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923CF12D6BC; Thu, 5 May 2016 11:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hy5-_8TvYFl; Thu, 5 May 2016 11:00:30 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C7312B049; Thu, 5 May 2016 10:52:59 -0700 (PDT) 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: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4F0172CA00; Thu, 5 May 2016 10:52:59 -0700 (PDT) From: "Jim Schaad" To: "'Daniel Migault'" , References: In-Reply-To: Date: Thu, 5 May 2016 10:52:58 -0700 Message-ID: <103e01d1a6f6$f648b220$e2da1660$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_103F_01D1A6BC.49EA9D70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHmjN9uO/liCJk3pYKAOfL0r6oeEJ+A1BDw Content-Language: en-us Archived-At: Cc: 'curdle-chairs' Subject: Re: [Curdle] Call for adoption of draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:00:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_103F_01D1A6BC.49EA9D70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support adoption of this draft, I have reviewed it and will continue = to do so while it progresses. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault Sent: Thursday, May 05, 2016 7:36 AM To: curdle@ietf.org Cc: curdle-chairs Subject: [Curdle] Call for adoption of = draft-housley-cms-eddsa-signatures =20 Hi, This starts a Call for Adoption for "Use of EdDSA Signatures in the = Cryptographic Message Syntax (CMS)" The document is available here: https://www.ietf.org/id/draft-housley-cms-eddsa-signatures-00.txt Please review this draft to see if you think it is suitable for adoption = by CURLDE, and comment to the list, clearly stating your view. *Speak = Up* if you have strong opposition to this work. This call for adoption ends on May 20. BR, Rich and Daniel ------=_NextPart_000_103F_01D1A6BC.49EA9D70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I support = adoption of this draft, I have reviewed it and will continue to do so = while it progresses.

 

Jim

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault
Sent: Thursday, May 05, 2016 7:36 AM
To: = curdle@ietf.org
Cc: curdle-chairs = <curdle-chairs@ietf.org>
Subject: [Curdle] Call for = adoption of draft-housley-cms-eddsa-signatures

 

Hi,

This starts a Call for Adoption for "Use of EdDSA Signatures = in the Cryptographic Message Syntax (CMS)"

The document is available here:

https://www.ietf.org/id/draft-housley-cms-eddsa-signatures-00.txt

Please review this draft to see if you think it is suitable for = adoption by CURLDE, and comment to the list, clearly stating your = view.  *Speak Up* if you have strong opposition to this = work.

This call for adoption ends on May 20.

BR,
Rich = and Daniel

------=_NextPart_000_103F_01D1A6BC.49EA9D70-- From nobody Thu May 5 12:34:05 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C970412D812 for ; Thu, 5 May 2016 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvDyvTwLQRi2 for ; Thu, 5 May 2016 12:34:02 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCA112D813 for ; Thu, 5 May 2016 12:34:02 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id B5989F2402E for ; Thu, 5 May 2016 15:34:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id XagPhrR2na5I for ; Thu, 5 May 2016 15:17:36 -0400 (EDT) Received: from [5.5.33.82] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 19A11F24013 for ; Thu, 5 May 2016 15:34:00 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <9A95C6C5-2985-4BD4-93C0-EC7EFE443CAB@vigilsec.com> Date: Thu, 5 May 2016 15:33:54 -0400 To: curdle@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Curdle] Algorithm identifiers in draft-ietf-curdle-pkix-eddsa-00 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 19:34:04 -0000 draft-ietf-curdle-pkix-eddsa-00 says: The id-EdDSASignature OID is used for identifying EdDSA signatures. id-EdDSASignature OBJECT IDENTIFIER ::=3D { 1 3 101 101 } The id-EdDSASignature OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field MUST be absent. To further clarify how to encode the parameters field, due to historical misunderstandings in this area, it MUST NOT have an ASN.1 type NULL. Historically, we have assigned OIDs for a combination of signature = algorithm and one-way hash function. The hash function used with EdDSA depends on the curve that is being = used. Curve25519 uses SHA-512, and Curve448 uses SHAKE256. Wouldn=92t it be better to have two OIDs here? Russ= From nobody Thu May 5 13:05:40 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F161412D514 for ; Thu, 5 May 2016 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYbynKWr5V9N for ; Thu, 5 May 2016 13:05:37 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA2212D51B for ; Thu, 5 May 2016 13:05:35 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 1D121F2402E; Thu, 5 May 2016 16:05:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id iyiDMwpWTIk9; Thu, 5 May 2016 15:49:08 -0400 (EDT) Received: from [5.5.33.88] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id ECE49F24013; Thu, 5 May 2016 16:05:33 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> Date: Thu, 5 May 2016 16:05:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 20:05:39 -0000 Jim: > Jim Schaad sent me some comments on this document. Since I have asked = this > working group to adopt this draft, I have gotten Jim's permission to = respond > to the comments on list. Dropping items 1 and 3 since they seem to be resolved. See below for the continued discussion of items 2 and 4. >> 2. We need to get a definition of how to use SHAKE256 from someplace=20= >> if we are going to say use the same hash algorithm throughout as that=20= >> is what >> Ed448 uses. It would be worthwhile to specify what hash algorithms=20= >> should be used with each of the different signature algorithms given=20= >> that it is not clear from the name of the algorithm identifier. >=20 > This document references draft-irtf-cfrg-eddsa-05, and that document > includes this reference for SHAKE256: >=20 > [FIPS202] National Institute of Standards and Technology, U.S. > Department of Commerce, "SHA-3 Standard: = Permutation-Based > Hash and Extendable-Output Functions", FIPS 202, August > 2015. >=20 > I'm not sure what more you think is needed. >=20 > [JLS] To start with, I think we need to get a reference for an OID for = the > SHAKE256 algorithm from NIST (or internally) since that is needed as = one of > the authenticated attributes. Based on other traffic on this list, I hope that NIST will assign the = OID. > I worry that since we have changed this set of identifiers from saying = X > with Y to just saying X that there is going to be a degree of people = missing > which algorithm is being used as a hash algorithm for this. We need to do the same thing with this document and = draft-ietf-curdle-pkix-eddsa. I have started a separate thread on this mail list. Let=92s have the = discussion on that thread, and then put the conclusion in both = documents. > A second worry is that SHAK256 is defined as being an XOF function and = not a > hash function. I think it might make more sense to say that we should = be > using SHA3-256 rather than SHAKE256. In any event the OID assigned on = the > NIST web site does not make any statements about the size of output of > SHAKE256 and if we are going to use it as a hash algorithm here we = need to > do that. Suffice it to say that I don't think that using SHAKE256 as = a hash > algorithm here is sufficiently defined. Doesn=92t this need to be addressed in draft-irtf-cfrg-eddsa? >> 4. In section 4, the problem with EdDSA is worse for the use of=20 >> different algorithms than what you are stating. It is possible to do=20= >> some interesting forgeries if you cross between the pre-hash and not=20= >> pre-hash versions with the Ed25519 curve since there is no context=20 >> difference between them. This has to be forbidden not just strongly >> suggested. >=20 > Does the removal of HashEdDSA resolve this one? >=20 > [JLS] Yes that would deal with this issue. However, given that = currently > the difference is just a field in the enumeration it should probably = have a > security consideration about it. If we can change the PKXI draft so = that > the pre-hash and pure versions using different OID identifiers, then = this > because much cleaner and less of a worry. It would currently be = potentially > necessary to make a RFC 2119 statement about the enumeration which is = not > proposed above. Hopefully the direction for this will emerge from the discussion on the = other thread. Russ From nobody Thu May 5 13:47:17 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1FD12D0DA for ; Thu, 5 May 2016 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFYfvHuwd_po for ; Thu, 5 May 2016 13:47:14 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A20512D0C0 for ; Thu, 5 May 2016 13:47:14 -0700 (PDT) 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: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5587338F16; Thu, 5 May 2016 13:47:13 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> In-Reply-To: Date: Thu, 5 May 2016 13:47:12 -0700 Message-ID: <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfBLXiu/ETDZDECg/NZrmdRKtKuwH6YJMHAx0dd7oCqvUie57R+7PA Content-Language: en-us Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 20:47:16 -0000 -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, May 05, 2016 1:05 PM To: Jim Schaad Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures Jim: >> 2. We need to get a definition of how to use SHAKE256 from someplace >> if we are going to say use the same hash algorithm throughout as that >> is what >> Ed448 uses. It would be worthwhile to specify what hash algorithms >> should be used with each of the different signature algorithms given >> that it is not clear from the name of the algorithm identifier. > > This document references draft-irtf-cfrg-eddsa-05, and that document > includes this reference for SHAKE256: > > [FIPS202] National Institute of Standards and Technology, U.S. > Department of Commerce, "SHA-3 Standard: Permutation-Based > Hash and Extendable-Output Functions", FIPS 202, August > 2015. > > I'm not sure what more you think is needed. > > [JLS] To start with, I think we need to get a reference for an OID for > the > SHAKE256 algorithm from NIST (or internally) since that is needed as > one of the authenticated attributes. Based on other traffic on this list, I hope that NIST will assign the OID. [JLS] They have assigned an OID for SHAKE256, I just don't know if it was done "correctly" for our purposes. We will need to work that out. I still need to look at and think about Quynh's response to my message. > I worry that since we have changed this set of identifiers from saying > X with Y to just saying X that there is going to be a degree of people > missing which algorithm is being used as a hash algorithm for this. We need to do the same thing with this document and draft-ietf-curdle-pkix-eddsa. I have started a separate thread on this mail list. Let's have the discussion on that thread, and then put the conclusion in both documents. > A second worry is that SHAK256 is defined as being an XOF function and > not a hash function. I think it might make more sense to say that we > should be using SHA3-256 rather than SHAKE256. In any event the OID > assigned on the NIST web site does not make any statements about the > size of output of > SHAKE256 and if we are going to use it as a hash algorithm here we > need to do that. Suffice it to say that I don't think that using > SHAKE256 as a hash algorithm here is sufficiently defined. Doesn't this need to be addressed in draft-irtf-cfrg-eddsa? [JLS] No, I am not worried about how SHAKE256 is being used in the EdDSA process (it is fully defined there), I am looking at the use of SHAKE256 when it is placed in the digestAlgorithm attribute of the SignerInfo structure. In this case the length of the output needs to be specified (i.e. how long is the message digest signed attribute). This is defined for hash algorithms, but is not defined for XOF functions. Russ From nobody Thu May 5 17:08:21 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D393312D10C for ; Thu, 5 May 2016 17:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL9RJGprw91N for ; Thu, 5 May 2016 17:08:19 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA7812D0AE for ; Thu, 5 May 2016 17:08:14 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id E49BDF2402A; Thu, 5 May 2016 20:08:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 0D5OEsWWcH-V; Thu, 5 May 2016 19:51:35 -0400 (EDT) Received: from russellsleysmbp.home (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 62220F24013; Thu, 5 May 2016 20:08:01 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com> Date: Thu, 5 May 2016 20:08:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com> References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 00:08:21 -0000 On May 5, 2016, at 4:47 PM, Jim Schaad wrote: >> A second worry is that SHAK256 is defined as being an XOF function = and=20 >> not a hash function. I think it might make more sense to say that we=20= >> should be using SHA3-256 rather than SHAKE256. In any event the OID=20= >> assigned on the NIST web site does not make any statements about the=20= >> size of output of >> SHAKE256 and if we are going to use it as a hash algorithm here we=20 >> need to do that. Suffice it to say that I don't think that using=20 >> SHAKE256 as a hash algorithm here is sufficiently defined. >=20 > Doesn't this need to be addressed in draft-irtf-cfrg-eddsa? >=20 > [JLS] No, I am not worried about how SHAKE256 is being used in the = EdDSA > process (it is fully defined there), I am looking at the use of = SHAKE256 > when it is placed in the digestAlgorithm attribute of the SignerInfo > structure. In this case the length of the output needs to be = specified > (i.e. how long is the message digest signed attribute). This is = defined for > hash algorithms, but is not defined for XOF functions. I was not understanding you issue until now=85 You are worried about this: Compute SHAKE256(dom(F, C) || prefix || M, 114), where M is the message to be signed, =85 Maybe we just make M =3D SHA512(ValueOnly(DER(SignedAttrs))) Russ From nobody Thu May 5 17:39:58 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04CE12D522 for ; Thu, 5 May 2016 17:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_6wbNDNJa2H for ; Thu, 5 May 2016 17:39:55 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E6712D51F for ; Thu, 5 May 2016 17:39:54 -0700 (PDT) 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: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7718A38F1A; Thu, 5 May 2016 17:39:54 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com> <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com> In-Reply-To: <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com> Date: Thu, 5 May 2016 17:39:53 -0700 Message-ID: <10a001d1a72f$cece40a0$6c6ac1e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfBLXiu/ETDZDECg/NZrmdRKtKuwH6YJMHAx0dd7oCqvUiewJXg3G6AjjTr8Serbx7IA== Content-Language: en-us Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 00:39:57 -0000 -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, May 05, 2016 5:08 PM To: Jim Schaad Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures On May 5, 2016, at 4:47 PM, Jim Schaad wrote: >> A second worry is that SHAK256 is defined as being an XOF function >> and not a hash function. I think it might make more sense to say >> that we should be using SHA3-256 rather than SHAKE256. In any event >> the OID assigned on the NIST web site does not make any statements >> about the size of output of >> SHAKE256 and if we are going to use it as a hash algorithm here we >> need to do that. Suffice it to say that I don't think that using >> SHAKE256 as a hash algorithm here is sufficiently defined. > > Doesn't this need to be addressed in draft-irtf-cfrg-eddsa? > > [JLS] No, I am not worried about how SHAKE256 is being used in the > EdDSA process (it is fully defined there), I am looking at the use of > SHAKE256 when it is placed in the digestAlgorithm attribute of the > SignerInfo structure. In this case the length of the output needs to > be specified (i.e. how long is the message digest signed attribute). > This is defined for hash algorithms, but is not defined for XOF functions. I was not understanding you issue until now. You are worried about this: Compute SHAKE256(dom(F, C) || prefix || M, 114), where M is the message to be signed, . Maybe we just make M = SHA512(ValueOnly(DER(SignedAttrs))) Russ [JLS] No that is not what I am worried about. What I am worried about is SignerInfo ::= SEQUENCE { version CMSVersion, -- == 1 or 3 sid SignerIdentifier, -- Identifier of the signer digestAlgorithm DigestAlgorithmIdentifier, --- AlgorithmIdentifier( {hashAlgs 12}, absent ) signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, { contains Attribute{ aa-messageDigest, SET OF { OCTET STRING { SHAKE256(Message Body) }} signatureAlgorithm SignatureAlgorithmIdentifier, -- id-edDSA signature SignatureValue, -- cryptographic result of eddsa with -- SHAKE256(dom(F, C) || prefix || DER(SignedAttrs), 114) -- where DER(SignedAttrs) = M just as would be expected. unsignedAttrs [1] IMPLICIT Attributes {{UnsignedAttributes}} OPTIONAL } The length of SHAKE256(Message Body) is not defined nor is there any place for it to be specified by a parameter. Specifically one needs to be able to say that the messageDigest = SHAKE256(Message Body, 114) (Or maybe just 57? If you want to do some type of size matching since the EdDSA uses a double width hash algorithm internally) Jim From nobody Fri May 6 00:32:43 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C4112D59D; Fri, 6 May 2016 00:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkSN9VdJymyP; Fri, 6 May 2016 00:32:41 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231CF12D1C9; Fri, 6 May 2016 00:32:40 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u467WWVl000557 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 6 May 2016 09:32:34 +0200 From: Simon Josefsson To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= References: <20160418194050.11122.84238.idtracker@ietfa.amsl.com> <114014258.1350.1461091070803.JavaMail.zimbra@nic.cz> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:160506:dnsop@ietf.org::t09u5oERu5a8z2cI:47Du X-Hashcash: 1:22:160506:ondrej.sury@nic.cz::LYWnOJMlh/sn/YAU:JFeT X-Hashcash: 1:22:160506:curdle@ietf.org::dNGeJHTglt2p0pFY:uM08 Date: Fri, 06 May 2016 09:32:31 +0200 In-Reply-To: <114014258.1350.1461091070803.JavaMail.zimbra@nic.cz> (=?iso-8859-2?Q?=22Ond=F8ej=09Sur=FD=22's?= message of "Tue, 19 Apr 2016 20:37:50 +0200 (CEST)") Message-ID: <874mabvdyo.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: dnsop@ietf.org, curdle@ietf.org Subject: Re: [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:32:43 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Ond=F8ej Sur=FD writes: > Dear colleagues, > > a new EdDSA for DNSSEC draft has been posted in CURDLE WG and is in > need of more reviewers ;). > > I merged Ed25519 and Ed448 drafts into one, removed reasoning why > EdDSA is superior for RFC and I-D in Normative references (thanks goes > to Paul Hoffman's review), and introduced using Signature Context[1] > in the signatures (thanks dkg for introducing me this idea) <-- this > one needs more work, because using Context is defined just for Ed448 > and we want to have it also for Ed25519. Thank you for this work! I suggest to add text repeating the established best practice to not re-use keys for different purposes -- that solves the cross-protocol/domain problem better than contexts in my opinion. There may not be harm of using Ed448's contexts in your draft, but it sets an example that doing so is good enough to protect against that generic class of attacks when it isn't (see DJB's post on CFRG explaining how it isn't sufficient). /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJXLEiQAAoJEIYLf7sy+BGdYAMIALVo7s8OqHKyc5G6WKMwgNMP wewG3uSg9kOgYxJ7l85+dRBG3DxhsD12V2Dt1mqgOm2VkBZ101oa9ohW9QeQ+fFo vI2b4V4Qy/rOpKoA7fcBkbBGQKKGksTuSRG/SFZzULTOsWZ8+3lOrLn1O7gmMWJw H+dqa0kBYF9OabzHRbeml+R7xq5JW+gYz4lt6FsY8TG9bllDy/ceP1p1Zg03E6so zbfxlqhlLH351u1roI6Xa/mUyUH0jpG6cHerxGKVwhQYn+9N7AN+A0MnisIQz8LD 9K5Hvf85lur7U+St1k0Yd6QO8Q9JKnIVmaFZayBU6G9mcLa6l/4N0FdvE1NRhZM= =Dur4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 6 03:53:50 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C7712D66E for ; Fri, 6 May 2016 03:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1uFiJnOp7uK for ; Fri, 6 May 2016 03:53:46 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AC712D5A1 for ; Fri, 6 May 2016 03:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FCexG8hE/uZIAjI9lvIo5U5MGAQq0JnhLMjQCzFNRvQ=; b=si3tSswVLQesd1O0DAelMVcxdekqyn0vXoKjfj0i/ocyacJ2ylH3WIzKrA0r7tsqUYqmA4Zr7JrAWIY+P51UpNzmyK4ICWiuKooQq1Bl8XubgJOfWWxfVYEA7aIrVwuvt4653u3Le9CURkDsh3VfmbJFYShoVG+UJA8ek5UvMLU= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.477.8; Fri, 6 May 2016 10:53:43 +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.0477.017; Fri, 6 May 2016 10:53:43 +0000 From: "Dang, Quynh (Fed)" To: Russ Housley , Jim Schaad Thread-Topic: [Curdle] Comments on draft-housley-cms-eddsa-signatures Thread-Index: AQHRpJiiUMFvavyrw02yfEgwrMzH1p+l/FuAgATNYQCAAAurAIAAOBsAgACzsgE= Date: Fri, 6 May 2016 10:53:43 +0000 Message-ID: References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com>, <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com> In-Reply-To: <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [74.96.246.53] x-ms-office365-filtering-correlation-id: 13ce6a77-8a08-4349-0ee8-08d3759cb126 x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:JVdjx6Vty1Lp66A6P842gmKzRWDuFhn42Cl5peukDDgjXcGMAhbLipBmHET85+fOfsk0M9Fd7w1FFw3dCoaX5wA9iz1CERg8lQPiDEFf1hMa4UXXr8bVxTFh2qsmxKIKNGJLSF/vUJuFyP+Oidzwkw==; 24:s7/tw2aE75jzDUmW8UHbfz4taGnx8eKGmmwLus3VqxvleszqVc3FPb/5JRdsgz1oRi3jDLtDesZ9AlxSGL8tSygA9Qs6ewtUJykJnE0lpnQ=; 7:wjLmWIH4O284XRIAecPjWDl78W1MIOe7mxDgA3XlnGDkoqOCiTfPBxt9Tmo98v9z+l09rD3EF9xuQVXXrtdovX5ZNd+MqDmBO2dfK09q+Frb2bNWPkYQK7A03z8Rf4LM8Vt7BWToMApK2RlS1sO22HoQD1r3CCbO1kJDhvwTBPPMow3zHa3Ggn1LfwnZMU9f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(66066001)(15975445007)(77096005)(92566002)(33656002)(74316001)(87936001)(93886004)(54356999)(9686002)(50986999)(76176999)(122556002)(5004730100002)(86362001)(81166005)(10400500002)(11100500001)(2950100001)(5008740100001)(3280700002)(3660700001)(3900700001)(2900100001)(5003600100002)(5001770100001)(4326007)(76576001)(189998001)(106116001)(2906002)(8936002)(99286002)(586003)(19580405001)(19580395003)(3846002)(5002640100001)(102836003)(6116002)(230783001)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 06 May 2016 10:53:43.5375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 10:53:49 -0000 Hi Russ, Since SHAKE256 is used in the function, one just goes with SHAKE256/512 ins= tead of SHA512 and just needs to allocate on OID for SHAKE256/512. Regards, Quynh.=20 ________________________________________ From: Curdle on behalf of Russ Housley Sent: Thursday, May 5, 2016 8:08 PM To: Jim Schaad Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures On May 5, 2016, at 4:47 PM, Jim Schaad wrote: >> A second worry is that SHAK256 is defined as being an XOF function and >> not a hash function. I think it might make more sense to say that we >> should be using SHA3-256 rather than SHAKE256. In any event the OID >> assigned on the NIST web site does not make any statements about the >> size of output of >> SHAKE256 and if we are going to use it as a hash algorithm here we >> need to do that. Suffice it to say that I don't think that using >> SHAKE256 as a hash algorithm here is sufficiently defined. > > Doesn't this need to be addressed in draft-irtf-cfrg-eddsa? > > [JLS] No, I am not worried about how SHAKE256 is being used in the EdDSA > process (it is fully defined there), I am looking at the use of SHAKE256 > when it is placed in the digestAlgorithm attribute of the SignerInfo > structure. In this case the length of the output needs to be specified > (i.e. how long is the message digest signed attribute). This is defined = for > hash algorithms, but is not defined for XOF functions. I was not understanding you issue until now=85 You are worried about this: Compute SHAKE256(dom(F, C) || prefix || M, 114), where M is the message to be signed, =85 Maybe we just make M =3D SHA512(ValueOnly(DER(SignedAttrs))) Russ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Fri May 6 04:16:22 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F052A12D5A1 for ; Fri, 6 May 2016 04:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoFdKMXURd6S for ; Fri, 6 May 2016 04:16:18 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0133.outbound.protection.outlook.com [23.103.200.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C076612D0F7 for ; Fri, 6 May 2016 04:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zsYXAGHoV61TdBymi3oxHHMvH+FoRKRhz2NIX8YiRKo=; b=1pgycgO/NLIjBOPTKr2WZLs9U+fMAZGHil1zQVXqEjHmyf5iyNUBJMBUCmi1JHZhOI32D9ByTWHQQwitECdt83dPoeeyM2EG1z2vn2Rt0FCX1YZurfZOzClf1AQ2qB/wHZhMfi4bKAgFrGoFVykjG+nHvFBG8o9EQZ91A6L94qQ= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.477.8; Fri, 6 May 2016 11:16:15 +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.0477.017; Fri, 6 May 2016 11:16:15 +0000 From: "Dang, Quynh (Fed)" To: Jim Schaad , 'Russ Housley' Thread-Topic: [Curdle] Comments on draft-housley-cms-eddsa-signatures Thread-Index: AQHRpJiiUMFvavyrw02yfEgwrMzH1p+l/FuAgATNYQCAAAurAIAAOBsAgAAI6ICAAKy1OA== Date: Fri, 6 May 2016 11:16:15 +0000 Message-ID: References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com> <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com>, <10a001d1a72f$cece40a0$6c6ac1e0$@augustcellars.com> In-Reply-To: <10a001d1a72f$cece40a0$6c6ac1e0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [74.96.246.53] x-ms-office365-filtering-correlation-id: db04bb65-5364-431e-faff-08d3759fd6e3 x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:iZrnP8ej/39XWv0iL1U51ZsaxxxW5dnX3pIt5EYCuLC9V2SEbczbsIgl8PdTYRAlqTSPTJs1qJGxeP6ZhVIVBDfyrbqbay1SnrRH5D8xxclpi55B8xN+VQwT8evnxk9h7kRg6xJ3fxLR66xwVO7xMQ==; 24:yw+COtm6ft5UaAdeU+Avs3jMFJyCVzAqR/o1KZm190WZL9kOLNUTa8bUL65avsXe9ZpB1qZ2teDIKzHOeXQEAzB72k11xTYgrgNmxEWt/6A=; 7:OHSGTx/d0bIRmKE1C9zIo9CPiz820urnun5cYjxWlHJ0OwDZKsRbSEXtmTKrsILrerbhOhc6pnTKEDnaXIZ9xpfyZLm9VKAjY7vSl8mteZFbcLAKZ9J3aTGHJY0SNpJmDHIlr6t23U5LZTGaTdgA51GSDwJGwb5o9VAIDZczjiUWuGCnWXv0S3HiiqIpIv7e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(15975445007)(2950100001)(10400500002)(5008740100001)(230783001)(77096005)(54356999)(2900100001)(19580395003)(50986999)(76176999)(19580405001)(122556002)(11100500001)(5004730100002)(66066001)(3280700002)(106116001)(99286002)(3660700001)(3900700001)(92566002)(76576001)(1220700001)(9686002)(102836003)(586003)(3846002)(6116002)(93886004)(86362001)(5002640100001)(5003600100002)(74316001)(8936002)(81166005)(87936001)(4326007)(2906002)(33656002)(5001770100001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2016 11:16:15.1449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 11:16:21 -0000 Hi Jim, To hash the signedAttributes value, SHAKE256/512 would be great. For ed25519 and ed448 EdDSA signatures, hash algorithm OID should be null/a= bsent. For ed25519ph and ed448ph, the hash algorithm is the prehash functio= n: SHA512 for ed25519ph and SHAKE256/512 for ed448ph.=20 Regards, Quynh.=20 ________________________________________ From: Curdle on behalf of Jim Schaad Sent: Thursday, May 5, 2016 8:39 PM To: 'Russ Housley' Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, May 05, 2016 5:08 PM To: Jim Schaad Cc: curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures On May 5, 2016, at 4:47 PM, Jim Schaad wrote: >> A second worry is that SHAK256 is defined as being an XOF function >> and not a hash function. I think it might make more sense to say >> that we should be using SHA3-256 rather than SHAKE256. In any event >> the OID assigned on the NIST web site does not make any statements >> about the size of output of >> SHAKE256 and if we are going to use it as a hash algorithm here we >> need to do that. Suffice it to say that I don't think that using >> SHAKE256 as a hash algorithm here is sufficiently defined. > > Doesn't this need to be addressed in draft-irtf-cfrg-eddsa? > > [JLS] No, I am not worried about how SHAKE256 is being used in the > EdDSA process (it is fully defined there), I am looking at the use of > SHAKE256 when it is placed in the digestAlgorithm attribute of the > SignerInfo structure. In this case the length of the output needs to > be specified (i.e. how long is the message digest signed attribute). > This is defined for hash algorithms, but is not defined for XOF functions= . I was not understanding you issue until now. You are worried about this: Compute SHAKE256(dom(F, C) || prefix || M, 114), where M is the message to be signed, . Maybe we just make M =3D SHA512(ValueOnly(DER(SignedAttrs))) Russ [JLS] No that is not what I am worried about. What I am worried about is SignerInfo ::=3D SEQUENCE { version CMSVersion, -- =3D=3D 1 or 3 sid SignerIdentifier, -- Identifier of the signer digestAlgorithm DigestAlgorithmIdentifier, --- AlgorithmIdentifier( {hashAlgs 12}, absent ) signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, { contains Attribute{ aa-messageDigest, SET OF { OCTET STRING { SHAKE256(Message Body) }} signatureAlgorithm SignatureAlgorithmIdentifier, -- id-edDSA signature SignatureValue, -- cryptographic result of eddsa with -- SHAKE256(dom(F, C) || prefix || DER(SignedAttrs), 114) -- where DER(SignedAttrs) =3D M just as would be expected. unsignedAttrs [1] IMPLICIT Attributes {{UnsignedAttributes}} OPTIONAL } The length of SHAKE256(Message Body) is not defined nor is there any place for it to be specified by a parameter. Specifically one needs to be able to say that the messageDigest =3D SHAKE256(Message Body, 114) (Or maybe ju= st 57? If you want to do some type of size matching since the EdDSA uses a double width hash algorithm internally) Jim _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Sun May 8 18:23:33 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7412D13C for ; Sun, 8 May 2016 18:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5B-wnwKWFnJ for ; Sun, 8 May 2016 18:23:29 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 B8F0A12D101 for ; Sun, 8 May 2016 18:23:29 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id u10so92022958igr.1 for ; Sun, 08 May 2016 18:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JCyPq7jEDmyQwPfSl0oXbebz/FCYGrsVnG2yId+8Y8c=; b=H967ABWR3pY12SuFjld9zHXTUNXIyGPvg6wUv5OAFm8OBmpg5c/4fzoHllEETFsvc6 UzQmmvhkY20TK1n11a5SLOzWvEhSCRkySO+ZtLOq4aO+HAqFD7fIxkkDs7F+Wfcp3GH+ ya4Ns3wezJ7p7tTYMQ4VDEiAEyRX1BgXuXuZo34lB3mDR+AA32BFmVF6dubgNUF1v+C9 zzgMzhNh2ZzPAWmBOqTZuvqYd5HAi6NBU5YNXZIru1QWPoocN8ph10Bh5v9CAMUBL7nL BEA9UAslmgnHQ2ljdmLr8CxvBGF7/2Ci2KA+Sb4tKzGDSfGTIMj8FJOVPf5A7Z61R9zZ +7CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JCyPq7jEDmyQwPfSl0oXbebz/FCYGrsVnG2yId+8Y8c=; b=mpsB5kysDgjB2grsa1Hy0wZrTozPylEAO19kcQG1q0H60TBAhuCohfpnr1J/ndD1qa JKLWNDp4NUOjDQ4dFkuxoZKh2dqVvczU6/HqmnuUr1jhX3U9nB8HcPWu5Hv377SfsYm2 7cxh2icUvAMPa074iOZ+18kCQgRGs1h6wrq79z3QdoXx5/fZ3blpG8wSL4ug3D5uXKRF 0DdCmdZQ4uOU0Z3VlTn7HZ43EfZTZWtv36nizB+sY5UsswJQOvWw6Z0TVsl4g61tIEUN xESmaThY7xsY9IWpHidY9hfKPITCYio1BdShMLWckSYsluNoFEemX/E85HrCkbxJb/iG phYQ== X-Gm-Message-State: AOPr4FXdjwDTW9yaOhSVEa/O/qbJCPZR40J71Yljg4lJqcNO4A7VynOl4Ayif/1VYMmoYi6/QLfSwOh7h32aHg== MIME-Version: 1.0 X-Received: by 10.50.59.211 with SMTP id b19mr8655055igr.58.1462757009044; Sun, 08 May 2016 18:23:29 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Sun, 8 May 2016 18:23:28 -0700 (PDT) In-Reply-To: References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com> <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com> <10a001d1a72f$cece40a0$6c6ac1e0$@augustcellars.com> Date: Mon, 9 May 2016 11:23:28 +1000 Message-ID: From: Martin Thomson To: "Dang, Quynh (Fed)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jim Schaad , Russ Housley , "curdle@ietf.org" Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 01:23:32 -0000 On 6 May 2016 at 21:16, Dang, Quynh (Fed) wrote: > For ed25519 and ed448 EdDSA signatures, hash algorithm OID should be null/absent. For ed25519ph and ed448ph, the hash algorithm is the prehash function: SHA512 for ed25519ph and SHAKE256/512 for ed448ph. The decision in TLS was to treat signature and hash as a single primitive, rather than a composable one, since these are not composable anyway. And Russ has suggested to drop the *ph versions, which is a good idea. That suggests no need to identify SHAKE* with respect to the signatures, only to use in other parts of the CMS that need hashes. And only where you want the hashes to be consistent throughout. Could Jim's concern about size be addressed by defining different OIDs for different output sizes? From nobody Sun May 8 20:07:31 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0E12D1BE for ; Sun, 8 May 2016 20:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9HSZXcrK8O6 for ; Sun, 8 May 2016 20:07:29 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8AA12D1B6 for ; Sun, 8 May 2016 20:07:29 -0700 (PDT) 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: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 5AF222CA2B; Sun, 8 May 2016 20:07:28 -0700 (PDT) From: "Jim Schaad" To: "'Martin Thomson'" , "'Dang, Quynh \(Fed\)'" References: <086701d1a0e4$965f2320$c31d6960$@augustcellars.com> <9458BE75-3657-4726-949C-6C9D7511AF21@vigilsec.com> <0c7301d1a4a2$cc47a680$64d6f380$@augustcellars.com> <106f01d1a70f$4d5c07c0$e8141740$@augustcellars.com> <549A2D33-98AF-4935-98A3-2EF475904B78@vigilsec.com> <10a001d1a72f$cece40a0$6c6ac1e0$@augustcellars.com> In-Reply-To: Date: Sun, 8 May 2016 20:07:27 -0700 Message-ID: <127501d1a99f$eb6787e0$c23697a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIfBLXiu/ETDZDECg/NZrmdRKtKuwH6YJMHAx0dd7oCqvUiewJXg3G6AjjTr8QBi+TJAAJD4AFYANSuehOejXw/4A== Content-Language: en-us Archived-At: Cc: curdle@ietf.org, 'Russ Housley' Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 03:07:31 -0000 This would definitely be one approach to solving my issue. The second would be to define a new OID which takes an integer parameter which is the size of the desired output. Jim -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Sunday, May 08, 2016 6:23 PM To: Dang, Quynh (Fed) Cc: Jim Schaad ; Russ Housley ; curdle@ietf.org Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures On 6 May 2016 at 21:16, Dang, Quynh (Fed) wrote: > For ed25519 and ed448 EdDSA signatures, hash algorithm OID should be null/absent. For ed25519ph and ed448ph, the hash algorithm is the prehash function: SHA512 for ed25519ph and SHAKE256/512 for ed448ph. The decision in TLS was to treat signature and hash as a single primitive, rather than a composable one, since these are not composable anyway. And Russ has suggested to drop the *ph versions, which is a good idea. That suggests no need to identify SHAKE* with respect to the signatures, only to use in other parts of the CMS that need hashes. And only where you want the hashes to be consistent throughout. Could Jim's concern about size be addressed by defining different OIDs for different output sizes? _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Mon May 9 07:55:35 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB6412B054 for ; Mon, 9 May 2016 07:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgvC8Q_4db1g for ; Mon, 9 May 2016 07:55:33 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6A12B007 for ; Mon, 9 May 2016 07:55:27 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 9EF9E9A4002 for ; Mon, 9 May 2016 10:55:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 2LrGscB9U4o4 for ; Mon, 9 May 2016 10:38:46 -0400 (EDT) Received: from [10.128.112.181] (unknown [207.43.147.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 4C2DB9A4001 for ; Mon, 9 May 2016 10:55:26 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <4B09DEBB-BE94-4DA7-A08D-B92EE0F3AB42@vigilsec.com> Date: Mon, 9 May 2016 10:55:25 -0400 To: curdle@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Curdle] https://www.ietf.org/proceedings/95/minutes/minutes-95-curdle X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 14:55:35 -0000 I=92d like to point out two problems with the minutes: (1) It contains some non-ASCII characters, so it does not always = display properly. (2) The last sentence is not correct. Simon did the PKIX-related = Internet-Drafts, and I did the CMS-related ones. There are three = CMS-related Internet-Drafts. Russ From nobody Mon May 9 08:23:31 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FE312D529 for ; Mon, 9 May 2016 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exEhsOcIVbmT for ; Mon, 9 May 2016 08:23:24 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17512D530 for ; Mon, 9 May 2016 08:23:24 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6EEB9433437; Mon, 9 May 2016 15:23:23 +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 57793433403; Mon, 9 May 2016 15:23:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1462807403; bh=y4sj4ksFZ/6B8M5h9ukKgCdrUGVQFF6hRwntwvzQqao=; l=367; h=From:To:Date:References:In-Reply-To:From; b=SkzYyQMmgYTMbBRuoqx3fzRKQ8TUjsKXp7kJvcaxT2n3pea4NicUGh5cIKRPZxpfv qWDOcEL8aWcV1ObiIC4ZpfbypoMXtWL2Y07XjHYgm1IUsNnlWFeSqkVY4sL4Gsn2Gy DIYyLeCbASqwgjCZPIIZVeX321M+ZN7I7weUusUg= 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 52D5F1FCA5; Mon, 9 May 2016 15:23:23 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 9 May 2016 11:23:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 9 May 2016 11:23:22 -0400 From: "Salz, Rich" To: Russ Housley , "curdle@ietf.org" Thread-Topic: [Curdle] https://www.ietf.org/proceedings/95/minutes/minutes-95-curdle Thread-Index: AQHRqgLZ+pdS12UpBUmGk+wcmwJTiZ+wuV5w Date: Mon, 9 May 2016 15:23:22 +0000 Message-ID: References: <4B09DEBB-BE94-4DA7-A08D-B92EE0F3AB42@vigilsec.com> In-Reply-To: <4B09DEBB-BE94-4DA7-A08D-B92EE0F3AB42@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.120] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] https://www.ietf.org/proceedings/95/minutes/minutes-95-curdle X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 15:23:30 -0000 > I=92d like to point out two problems with the minutes: >=20 > (1) It contains some non-ASCII characters, so it does not always display > properly. >=20 > (2) The last sentence is not correct. Simon did the PKIX-related Intern= et- > Drafts, and I did the CMS-related ones. There are three CMS-related > Internet-Drafts. Thank you! New version uploaded. From nobody Tue May 17 00:37:47 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF3812D0FB for ; Tue, 17 May 2016 00:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwTJk1EiX-D0 for ; Tue, 17 May 2016 00:37:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8165512B00A for ; Tue, 17 May 2016 00:37:44 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1562115565 for ; Tue, 17 May 2016 07:37:44 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.205]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4H7bg2p027086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 17 May 2016 03:37:43 -0400 Message-ID: <1463470661.2914.4.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "curdle@ietf.org" Date: Tue, 17 May 2016 09:37:41 +0200 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 17 May 2016 07:37:44 +0000 (UTC) Archived-At: Subject: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 07:37:45 -0000 Hi,  I've sent it already to Simon, but forwarding here for wider audience. The current draft-ietf-curdle-pkix-00 uses two identifiers for Ed25519 curve. When identifying the curve parameters in the public key, it is identified by an enumerated field as in: EdDSAParameters ::= ENUMERATED { ed25519   (1) ... While when identifying the private key parameters the following object identifier is used: id-Curve25519   OBJECT IDENTIFIER ::= { 1.3.101.110 } This there are two identifiers in the same draft for the same curve parameters and that leads to more complexity in implementations. Why not simply define EdDSAParameters ::= OBJECT IDENTIFIER, and use the object identifier everywhere? regards, Nikos From nobody Tue May 17 07:20:48 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AB12D635 for ; Tue, 17 May 2016 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvS-NdoJHsss for ; Tue, 17 May 2016 07:20:45 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 2BB3212B063 for ; Tue, 17 May 2016 07:20:45 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id s8so10508586ign.0 for ; Tue, 17 May 2016 07:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8bomCEjweXR4cv1IcGqPmyYNwAptaTjEQrVozPVg/qo=; b=FbOc5yVp+hpzcnG+7S/WzCfFtdROxpyoUpvIzPaljv3X+LrNIwIKar92g9X/1Hpn1J UhyIVJ9itKOnZ+6Ko0QHUfcmD4Jv1JYmKQ4uUBV2GOhfhr3m6Nt5qgIhKpsb7fma2P5G gJ9H4C6OjjyPK6Nf3e6mNBuoHK0BCoau4YOYM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8bomCEjweXR4cv1IcGqPmyYNwAptaTjEQrVozPVg/qo=; b=cToZy1F/jjPiH3EHOxNyIW5vfx/gftDBIY+/i+nPeYpB1p5v2qUnqTEYS8Xeg/lBbO NqKkK4n+xGFgUm47BIMfZDq/eH2FWrWzKF1YgaK4DzDepl2+ZghQh/xdfQrET6ze0Z7A xi3GPy2Rv7Jz7l0B/0/YXM6ht5rfz7GznyuiBAZ9X9QI/D0Uz8nDOI0Ze7uNmbpQGyKM EBtBQaat4Pk+V1Aw7nyaMavVH/K97is68rpvc7GSs+X/BSs9Br33DfCuy7hXEENavjcL 4eyL2nvK8sSEG4gq/hy+4xQYMmHlVC4YZMeTMI6CBBGyIK5RdwA9ZYrvjtgvOVq8Xjux 46HQ== X-Gm-Message-State: AOPr4FWu4/oVc5FDIQOv1r0EOYBRdyNvPMPsRIsDUlNIk2Fnp3+tmOvXaFvij8iQw1PBNEuGsLKvbLcJk6gHRXEo X-Received: by 10.50.32.133 with SMTP id j5mr1238972igi.51.1463494844344; Tue, 17 May 2016 07:20:44 -0700 (PDT) MIME-Version: 1.0 References: <1463470661.2914.4.camel@redhat.com> In-Reply-To: <1463470661.2914.4.camel@redhat.com> From: David Benjamin Date: Tue, 17 May 2016 14:20:35 +0000 Message-ID: To: Nikos Mavrogiannopoulos , "curdle@ietf.org" Content-Type: multipart/alternative; boundary=bcaec50827d2544f4505330a7226 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 14:20:47 -0000 --bcaec50827d2544f4505330a7226 Content-Type: text/plain; charset=UTF-8 I would actually advocate a different change. I sent this message earlier: https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html Rather than use parameters, allocate new algorithm OIDs for everything. I don't think we actually gain anything by exposing the relations and parameterizations between these algorithms. When implementing, they are great for sharing code. But when consuming, exposing it makes parsing more complex, and it increases the risk of reusing keys between related algorithms. We can get the best of both worlds by separating entry-points and sharing internals. It's also more future-proof. Suppose SHA-512 broke. Maybe we'd define Ed25519v2 using SHA3-512 instead. But Ed25519 and Ed25519v2 keys shouldn't be mixed. Top-level algorithm OIDs makes extending this natural, while trying to classify by curve, etc., means we need more moving parts. This also aligns with how signatures work in TLS 1.3: https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.1 (Though my advocating for this is not surprising. The TLS 1.3 change is my fault. Though it seems to have had consensus.) David On Tue, May 17, 2016 at 3:37 AM Nikos Mavrogiannopoulos wrote: > Hi, > I've sent it already to Simon, but forwarding here for wider audience. > The current draft-ietf-curdle-pkix-00 uses two identifiers for Ed25519 > curve. > > When identifying the curve parameters in the public key, it is > identified by an enumerated field as in: > EdDSAParameters ::= ENUMERATED { ed25519 (1) ... > > > While when identifying the private key parameters the following object > identifier is used: > id-Curve25519 OBJECT IDENTIFIER ::= { 1.3.101.110 } > > This there are two identifiers in the same draft for the same curve > parameters and that leads to more complexity in implementations. > > Why not simply define EdDSAParameters ::= OBJECT IDENTIFIER, and use > the object identifier everywhere? > > regards, > Nikos > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --bcaec50827d2544f4505330a7226 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would actually advocate a different change. I sent this = message earlier:

Rather than use parameters, a= llocate new algorithm OIDs for everything. I don't think we actually ga= in anything by exposing the relations and parameterizations between these a= lgorithms. When implementing, they are great for sharing code. But when con= suming, exposing it makes parsing more complex, and it increases the risk o= f reusing keys between related algorithms. We can get the best of both worl= ds by separating entry-points and sharing internals.

It's also more future-proof. Suppose SHA-512 broke. Maybe we'd d= efine Ed25519v2 using SHA3-512 instead. But Ed25519 and Ed25519v2 keys shou= ldn't be mixed. Top-level algorithm OIDs makes extending this natural, = while trying to classify by curve, etc., means we need more moving parts.

This also aligns with how signatures work in TLS 1.= 3:
h= ttps://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.1
(Thoug= h my advocating for this is not surprising. The TLS 1.3 change is my fault.= Though it seems to have had consensus.)

David
=
On Tue, May 17, 2016 at 3:3= 7 AM Nikos Mavrogiannopoulos <nmav@re= dhat.com> wrote:
Hi,
=C2=A0I've sent it already to Simon, but forwarding here for wider audi= ence.
The current=C2=A0draft-ietf-curdle-pkix-00 uses two identifiers for Ed25519=
curve.

When identifying the curve parameters in the public key, it is
identified by an enumerated field as in:
EdDSAParameters ::=3D ENUMERATED { ed25519=C2=A0=C2=A0=C2=A0(1) ...


While when identifying the private key parameters the following object
identifier is used:
id-Curve25519=C2=A0=C2=A0=C2=A0OBJECT IDENTIFIER ::=3D { 1.3.101.110 }

This there are two identifiers in the same draft for the same curve
parameters and that leads to more complexity in implementations.

Why not simply define EdDSAParameters ::=3D OBJECT IDENTIFIER, and use
the object identifier everywhere?

regards,
Nikos

_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--bcaec50827d2544f4505330a7226-- From nobody Thu May 19 01:40:30 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6312B02B for ; Thu, 19 May 2016 01:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpZx4vLiYSnO for ; Thu, 19 May 2016 01:40:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542D012B03F for ; Thu, 19 May 2016 01:40:27 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DB06E800AF; Thu, 19 May 2016 08:40:26 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.205]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4J8eOYd013734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 May 2016 04:40:26 -0400 Message-ID: <1463647224.3558.14.camel@redhat.com> From: Nikos Mavrogiannopoulos To: David Benjamin , "curdle@ietf.org" Date: Thu, 19 May 2016 10:40:24 +0200 In-Reply-To: References: <1463470661.2914.4.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 19 May 2016 08:40:26 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 08:40:29 -0000 On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > I would actually advocate a different change. I sent this message > earlier: > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > > Rather than use parameters, allocate new algorithm OIDs for > everything. I don't think we actually gain anything by exposing the > relations and parameterizations between these algorithms. When > implementing, they are great for sharing code. But when consuming, > exposing it makes parsing more complex, and it increases the risk of > reusing keys between related algorithms. We can get the best of both > worlds by separating entry-points and sharing internals. On your referenced message I am confused on the issue you raise on section 3. As I read section 3, I do not see anything that allows having id-ecPublicKey as an algorithm identifier for these keys. Other than this part, you raise a very good point. It may be much simpler to use a common OID and move it up. Unlike the NIST curves the constructions we have under the eddsa OID umbrella are quite distinct. I was concerned about future extensibility and the fact that pureEdDSA and PrehashedEdDSA could be with separate algorithm OIDs, but after thinking it further, I think what you suggest is much neater, as having a single OID to identify scheme+curve will also restrict private keys to a single purpose which is a good thing. +1 regards, Nikos From nobody Thu May 19 07:41:42 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0094812B024 for ; Thu, 19 May 2016 07:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZRqZCVoj8XL for ; Thu, 19 May 2016 07:41:40 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0808127058 for ; Thu, 19 May 2016 07:41:39 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id t40so17418070ioi.0 for ; Thu, 19 May 2016 07:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FMlPTyfEFX9IiM6zEXV/VrapiTAss0MMZvv2JmposxY=; b=kmgQdsXTpMowkoez5/PxhlRomC5CHS4XjT5Beo20T47uZcBTRBMH0aiddLy4UVMfOu hRX3d4nuFmanYBvPp/sDB/KdmXve9iCjQuPJQ1K8KT5UOd1zMgjaSW7f9uUUtyyhFv2y Vxi+KTyIv1duV8xfskfRI6gSlr1g5WIAzKsXw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FMlPTyfEFX9IiM6zEXV/VrapiTAss0MMZvv2JmposxY=; b=FP3/c/pNYu/8LN2FWvBNnt8B+DipeBh6XnCzUwBMdnOMzRtIXzA0tKytRkyTMdRs+o RNfwfqJez8sCb0FvaSa9cY1vS79k5i6Bq6Rdc4VPnTJoL0iTKWJ2QOmZEFY9Q68GP3Cs o7xPGpGS58YwBVULx9N6cQe6lXGCpdi9w+l2Byh41fia/VPw/l6qoH1dye03/pC3IjdJ 3A8x1lwPih/1nmc74CBgVHkMCLrbqLmxpTIlwA/XqFZI6MRmVxVn/r3yZTOl1reiEG+c my5NOfq9KppO/79x8bRrd7YEy7luQl0vzg6tE/I1nOj5VtDvcd6J7AcZAnye1AVNzsY7 jeTA== X-Gm-Message-State: AOPr4FV0kWk8a8GjlGGz2hlpmMztf+7isVEqrLRINHvKL2jCkQSEW+QoSS2n6WW87srB6RNWWoB2AeQ2jdDqKvm5 X-Received: by 10.36.11.84 with SMTP id 81mr3377279itd.76.1463668899212; Thu, 19 May 2016 07:41:39 -0700 (PDT) MIME-Version: 1.0 References: <1463470661.2914.4.camel@redhat.com> <1463647224.3558.14.camel@redhat.com> In-Reply-To: <1463647224.3558.14.camel@redhat.com> From: David Benjamin Date: Thu, 19 May 2016 14:41:28 +0000 Message-ID: To: Nikos Mavrogiannopoulos , "curdle@ietf.org" Content-Type: multipart/alternative; boundary=001a1140c338cec863053332f87a Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-pkix-00: a simplification proposal X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 14:41:42 -0000 --001a1140c338cec863053332f87a Content-Type: text/plain; charset=UTF-8 On Thu, May 19, 2016 at 4:40 AM Nikos Mavrogiannopoulos wrote: > On Tue, 2016-05-17 at 14:20 +0000, David Benjamin wrote: > > I would actually advocate a different change. I sent this message > > earlier: > > https://www.ietf.org/mail-archive/web/curdle/current/msg00203.html > > > > Rather than use parameters, allocate new algorithm OIDs for > > everything. I don't think we actually gain anything by exposing the > > relations and parameterizations between these algorithms. When > > implementing, they are great for sharing code. But when consuming, > > exposing it makes parsing more complex, and it increases the risk of > > reusing keys between related algorithms. We can get the best of both > > worlds by separating entry-points and sharing internals. > > On your referenced message I am confused on the issue you raise on > section 3. As I read section 3, I do not see anything that allows > having id-ecPublicKey as an algorithm identifier for these keys. > It's certainly possible I'm misunderstanding what section 3 was for. I was kind of confused why there were two encodings. I was getting id-ecPublicKey from: """ Section 2.3.5 of [RFC3279] describe ECDSA/ECDH public keys, specifying the id-ecPublicKey OID. This OID has the associated EcpkParameters parameters structure, which contains the namedCurve CHOICE. Here we introduce two [I think this should be four] new OIDs for use in the namedCurve field. """ Anyway, if we go with top-level OIDs for everything, this is all moot. David > Other than this part, you raise a very good point. It may be much > simpler to use a common OID and move it up. Unlike the NIST curves the > constructions we have under the eddsa OID umbrella are quite distinct. > > I was concerned about future extensibility and the fact that pureEdDSA > and PrehashedEdDSA could be with separate algorithm OIDs, but after > thinking it further, I think what you suggest is much neater, as having > a single OID to identify scheme+curve will also restrict private keys > to a single purpose which is a good thing. > > +1 > > regards, > Nikos > > --001a1140c338cec863053332f87a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 19= , 2016 at 4:40 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
https://www.ietf.org/mail-arc= hive/web/curdle/current/msg00203.html
>
> Rather than use parameters, allocate new algorithm OIDs for
> everything. I don't think we actually gain anything by exposing th= e
> relations and parameterizations between these algorithms. When
> implementing, they are great for sharing code. But when consuming,
> exposing it makes parsing more complex, and it increases the risk of > reusing keys between related algorithms. We can get the best of both > worlds by separating entry-points and sharing internals.

On your referenced message I am confused on the issue you raise on
section 3. As I read section 3, I do not see anything that allows
having=C2=A0id-ecPublicKey as an algorithm identifier for these keys.

It's certainly possible I'm misunder= standing what section 3 was for. I was kind of confused why there were two = encodings. I was getting=C2=A0id-ecPublicKey from:

"""
=C2=A0 =C2=A0Section 2.3.5 of [RFC3279]<= /div>
=C2=A0 =C2=A0describe ECDSA/ECDH public keys, specifying the id-e= cPublicKey OID.
=C2=A0 =C2=A0This OID has the associated EcpkPara= meters parameters structure,
=C2=A0 =C2=A0which contains the name= dCurve CHOICE.=C2=A0 Here we introduce two [I think this should be four] ne= w OIDs
=C2=A0 =C2=A0for use in the namedCurve field.
"&qu= ot;"

Anyway, if we go with top-level OIDs for everything, this = is all moot.

David
=C2=A0
Other than this part, you raise a very good point. It may be much
simpler to use a common OID and move it up. Unlike the NIST curves the
constructions we have under the eddsa OID umbrella are quite distinct.

I was concerned about future extensibility and the fact that pureEdDSA
and PrehashedEdDSA could be with separate algorithm OIDs, but after
thinking it further, I think what you suggest is much neater, as having
a single OID to identify scheme+curve will also restrict private keys
to a single purpose which is a good thing.

+1

regards,
Nikos

--001a1140c338cec863053332f87a-- From nobody Wed May 25 00:44:04 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A92A12D575 for ; Wed, 25 May 2016 00:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nt31QdswBp4 for ; Wed, 25 May 2016 00:44:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A4D12D527 for ; Wed, 25 May 2016 00:44:00 -0700 (PDT) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 6A6A860985 for ; Wed, 25 May 2016 09:43:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464162238; bh=cj80yxtOpafZMDeibCcgZpOViGxoYpfjXVXF5W9ivcc=; h=Date:From:To; b=CEtZKQoExxvuLdl415dNBhPCsQFjLiJay/CjbbtPeOIVrMXlAzdrfOukCF+zIItGt 123kLdMo7kwNkVBSskr8SIhPaXQs1UJ5ME80h3l4zwy8cpM+NJhSITzpfXk9auuq7f w21nPsJsb6XlTdnTH5i4Gat1fF2QBjTMM17cShcs= Date: Wed, 25 May 2016 09:43:58 +0200 (CEST) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: curdle@ietf.org Message-ID: <271160767.1519.1464162238402.JavaMail.zimbra@nic.cz> In-Reply-To: <20160418194050.11122.84238.idtracker@ietfa.amsl.com> References: <20160418194050.11122.84238.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - GC50 (Linux)/8.6.0_GA_1178) Thread-Topic: I-D Action: draft-ietf-curdle-dnskey-eddsa-00.txt Thread-Index: CmUeR7eoyeLnPuLdRotMDcVGVhzM+g== X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 07:44:02 -0000 Dear WG members, I would like to proceed with the draft and we got sort-of stuck because of = the Context. So here I would like to ask the WG, if they have any opinion on how should = we push this forward. There are several options we might take: 1. drop the Contexts 2. drop the Contexts from ed25519 and keep it for ed448 (sort of useless si= nce ed25519 is the one we expect everybody will use) 3. keep the Contexts and clarify the usage for ed25519 4. wait for Simon's eddsa draft to specify ed25519ctx (and ed448ctx) Thoughts? Opinions? Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: curdle@ietf.org > Sent: Monday, April 18, 2016 9:40:50 PM > Subject: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the CURves, Deprecating and a Little more > Encryption of the IETF. >=20 > Title : EdDSA for DNSSEC > Authors : Ondrej Sury > Robert Edmonds >=09Filename : draft-ietf-curdle-dnskey-eddsa-00.txt >=09Pages : 8 >=09Date : 2016-04-18 >=20 > Abstract: > This document describes how to specify EdDSA keys and signatures in > DNS Security (DNSSEC). It uses the Edwards-curve Digital Security > Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue May 31 07:46:10 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A5A12B061; Tue, 31 May 2016 07:46:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531144609.18716.22720.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 07:46:09 -0700 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, mglt.ietf@gmail.com, stephen.farrell@cs.tcd.ie Subject: [Curdle] curdle - New Meeting Session Request for IETF 96 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:46:09 -0000 A new meeting session request has just been submitted by Daniel Migault, a Chair of the curdle working group. --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: tls i2nsf ipsecme saag 6lo tcpinc sacm trans Special Requests: --------------------------------------------------------- From nobody Tue May 31 07:48:14 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0103F12D605; Tue, 31 May 2016 07:48:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531144812.18732.17532.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 07:48:12 -0700 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, mglt.ietf@gmail.com, stephen.farrell@cs.tcd.ie Subject: [Curdle] curdle - Update to a Meeting Session Request for IETF 96 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:48:13 -0000 An update to a meeting session request has just been submitted by Daniel Migault, a Chair of the curdle working group. --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: tls ipsecme saag 6lo cfrg Second Priority: i2nsf tcpinc sacm trans Special Requests: ---------------------------------------------------------