From nobody Mon Jan 2 03:40:23 2017 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 403351295BC; Mon, 2 Jan 2017 03:40:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148335721925.21908.10777829685328880113.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 03:40:19 -0800 Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Subject: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-curdle-dnskey-eddsa-03=3A_=28with_COMMENT=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 11:40:19 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-curdle-dnskey-eddsa-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am a little suprised to read this: "A sufficiently large quantum computer would be able to break both. " What's sufficiently large in terms of quantum comupting? Is it really already necessary to say this? And here: "Reasonable projections of the abilities of classical computers conclude that Ed25519 is perfectly safe." What's perfectly safe? However no need to change anything... was just wondering. From nobody Mon Jan 2 07:04:07 2017 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 028AE12962D; Mon, 2 Jan 2017 07:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bulkwpq06qtG; Mon, 2 Jan 2017 07:04:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32B9129637; Mon, 2 Jan 2017 07:04:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77ACCBE64; Mon, 2 Jan 2017 15:04:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0-f5Z_PhZA3; Mon, 2 Jan 2017 15:03:59 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 66975BE5D; Mon, 2 Jan 2017 15:03:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483369439; bh=WLmDhLwa8ont++LlJsTB9HTf/3lyO2i9ZDWzlqtLTBM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=otmiFuxYCUwwPSVfzL6VAWGWS3oWlqw1mrKZgTlksq5YCr3JP9Rh8eIJUcGi9ly9Y EEvjTvtq9rwuBAWIqZV7kPm+resdTO/h6oeXFlmq2VfTpdcn2IEWStd1pfg2j3oOqm 8TWnSesoIhxIXEdkOj78agnJl0uEjdLzE/glf31s= To: Mirja Kuehlewind , The IESG References: <148335721925.21908.10777829685328880113.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 2 Jan 2017 15:03:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148335721925.21908.10777829685328880113.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030307080001080900030600" Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Subject: Re: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-curdle-dnskey-eddsa-03=3A_=28with_COMMENT=29?= 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 Jan 2017 15:04:06 -0000 This is a cryptographically signed message in MIME format. --------------ms030307080001080900030600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 02/01/17 11:40, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-curdle-dnskey-eddsa-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I am a little suprised to read this: >=20 > "A sufficiently large > quantum computer would be able to break both. " > What's sufficiently large in terms of quantum comupting?=20 Enough qubits basically to run the relevant algorithms. I've not looked into the ECC/DL stuff in detail, but for an RSA modulus with 2048 bits, you'd need a bunch of qubit registers of that size. [1] I think the same would be true for eddsa so probably a QC with a bunch of 256 qubit registers would be needed. [1] https://en.wikipedia.org/wiki/Shor%27s_algorithm > Is it really > already necessary to say this?=20 >=20 > And here: > "Reasonable projections of the abilities of classical computers conclud= e > that Ed25519 is perfectly safe." > What's perfectly safe? Yeah, I guess "currently considered" would be ok. IIRC, the issue is that we don't want to encourage folks to all plump for 448 on the spurious basis that longer/stronger is always better and the language is trying to encourage people to ack that 25519 is just fine for all known cases. > However no need to change anything... was just wondering. I'll take a peek when all the comments are in, might well be worth a tweak or two. Cheers, S. >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 --------------ms030307080001080900030600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDIx NTAzNThaMC8GCSqGSIb3DQEJBDEiBCBA/yQ7gCQGM7iIXjXXEntL1Fha8JFHB9aYzG4HpHsv vjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB4LcWoSFON3U/sca8FgHObwpfz/GZFy7k57S5JptJgHSggb5n1CSrV bZwqdC3+fE9vNQvN2Emmw3EPC+7PUb0+Pl6Ms6Aq/0FJTntlZpqdOwaIJ0HQdBzs+EoJBSky HBs389MK/W4X09V+W0dF8oA1LcSbc+wyt4gY6UHW7B7F3d5VghRLwiHYA0t9C6N6nbVuQaSA XN8gn255dMLLB2sPRTqYTcvOXmbE/Ba6mnsBx9pb8BUD1nouYcZyDvSOYz8+q4xC6jy0Rs1Y 78CP6U+g/MhXQPiurMqD4jpCk0+DlfAxNSByeZ82tHs7mXOHxMxg5Idnbn/wJnA10kmt0mqg AAAAAAAA --------------ms030307080001080900030600-- From nobody Tue Jan 3 19:26:42 2017 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 F404D126BF6; Tue, 3 Jan 2017 19:26:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148350040099.28010.3999746102355596745.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 19:26:40 -0800 Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Subject: [Curdle] Terry Manderson's Yes on draft-ietf-curdle-dnskey-eddsa-03 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 Jan 2017 03:26:41 -0000 Terry Manderson has entered the following ballot position for draft-ietf-curdle-dnskey-eddsa-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ There are no remarks associated with this position. From nobody Thu Jan 5 03:58:32 2017 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 82BF7129442; Thu, 5 Jan 2017 03:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 yE5zf-bee5h7; Thu, 5 Jan 2017 03:58:30 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id F2DCF129418; Thu, 5 Jan 2017 03:58:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3EAD82D291; Thu, 5 Jan 2017 13:58:29 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-BNRSZnQDP3; Thu, 5 Jan 2017 13:58:28 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id D5A302D290; Thu, 5 Jan 2017 13:58:28 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A3AEACF8-70A5-4285-9F09-7DA38970BAA6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148268662863.28246.9120060465328322636.idtracker@ietfa.amsl.com> Date: Thu, 5 Jan 2017 13:58:28 +0200 Message-Id: <9A108C37-1BD5-4CDD-B623-68E9D80393E0@piuha.net> References: <148268662863.28246.9120060465328322636.idtracker@ietfa.amsl.com> To: Dan Romascanu X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-curdle-dnskey-eddsa.all@ietf.org, gen-art@ietf.org, curdle@ietf.org, ietf@ietf.org Subject: Re: [Curdle] Review of draft-ietf-curdle-dnskey-eddsa-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 11:58:31 -0000 --Apple-Mail=_A3AEACF8-70A5-4285-9F09-7DA38970BAA6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Dan & all: Thanks for the review, re-review, and changes! Jari --Apple-Mail=_A3AEACF8-70A5-4285-9F09-7DA38970BAA6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYbjTkAAoJEM80gCTQU46qOdsQAIEhHFo3t3FrHhmcAPKFh2BJ LMEWoHHzwEGHZ0y8aL5MHJ8l4l2Kx8AQEDGB7p0+AxhRhy3kI8KAH6vM7ucSAqgO BdncpQqaVUe5psk/DbZbSLs7QAqkAHuWsG/KJpHfVqHVGJU4bd31EaEFIIFPf7o+ IWA1F3sYbmfnOWxlLKaa67nkRS+mv1Z5yXz4K0PRJba3+N/Yti18noi2nXZK2gFe 2Vsb2AG20SAulHFqujX2u7zijyqjRKaZnLFvUwxl0bEzGhseJsvSPOzmRxnYcgzn rFOt6OFafCXHw2MJGWqfYu8fONoeB99R0sGJBEMoksgnJRB3gNLMZcQQash3hBTx zbSu1zTkZB6Zl/ZWgNQaQTjYmovdamQq+OfR7GjuGToRu1P/PjQ2V9n+pA4Bafns pUzRosSqXOh+9a+Sxb5AXXxWrqdD7YqCnXoR/kg8NR4djIsW+7NgrMbtpFB00V+o BqScVeozjvnRCekm7pMTXiN1rmg0dZZxtQZ6PFRZiETXTMqE/zms/o7k7/DV6ama oonDCKLNU+e5VhmDiDpVKoBcQfgPk/TSeHoBjC22yFyIMNvKE0zvsVgoVtfFDjAx vU9qySXCauAPTyZzexC35XsY35Lzn714aMzZahLQj9RmU4cNHFJod6uFNTR1NDEx IEOpJdJql3HY7Xjq892Z =sSOd -----END PGP SIGNATURE----- --Apple-Mail=_A3AEACF8-70A5-4285-9F09-7DA38970BAA6-- From nobody Fri Jan 6 07:54:10 2017 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 C93BE129459; Fri, 6 Jan 2017 07:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPpsaoXsxCQO; Fri, 6 Jan 2017 07:54:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EFD12956C; Fri, 6 Jan 2017 07:54:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1ABAEBE73; Fri, 6 Jan 2017 15:54:05 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFAQtOwPAWcn; Fri, 6 Jan 2017 15:54:04 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71DBBBE5D; Fri, 6 Jan 2017 15:54:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483718044; bh=F4RhEzymLATOSHZOsSjHt41y9jADaiEx3CErEughI3k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=IW/0NSsHHZYN4LIg8hhstj4KInZ6Cz3pZiPdDOypXSN7inJ55hR2cmsEIcvb8FtHh 86lDjhWbFNhdkWW5wrL+GNox6AJoIqLkmbOcoLxubZhqgkEnf5/gwmHOh3jQ+8ZoUk aQUgYVf0k+sVy7J2vUCAMtnXIKsrTatjwlsH2KBI= To: 'Yoav Nir' , draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> <0e1501d254c4$b542c1e0$1fc845a0$@augustcellars.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 6 Jan 2017 15:54:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <0e1501d254c4$b542c1e0$1fc845a0$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030800090004090405050901" Archived-At: Cc: Jim Schaad , curdle@ietf.org Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 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 Jan 2017 15:54:10 -0000 This is a cryptographically signed message in MIME format. --------------ms030800090004090405050901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I think we've one change pending from Yoav's review. There were also some nits from the opsdir review [1] posted over the holidays. Do we think we can have an update with those fixes in the next week? If so, I'll put this on the Jan 19th telechat for approval. (If it's somehow easier for these changes to be done as an RFC editor note, that's fine too - just send me the text for that.) Thanks, S. [1] https://datatracker.ietf.org/doc/review-ietf-curdle-cms-chacha20-poly1305= -04-opsdir-lc-comstedt-2016-12-24/ On 12/12/16 22:11, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Yoav Nir >> Sent: Sunday, December 11, 2016 5:14 AM >> To: secdir@ietf.org >> Cc: curdle@ietf.org; draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.= org; >> ietf@ietf.org >> Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04= >> >> Reviewer: Yoav Nir >> Review result: Has Nits >> >> Hi, >> >> I have reviewed this document as part of the security directorate's > ongoing >> effort to review all IETF documents being processed by the IESG. Thes= e >> comments were written primarily for the benefit of the security area > directors. >> Document editors and WG chairs should treat these comments just like a= ny >> other last call comments. >> >> Summary: Ready with nits. >> >> Introduction >> ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit k= ey >> and a 96-bit nonce. ChaCha20 is described in [FORIETF]. >> >> ChaCha20 is described in DJB's paper. RFC 7539 just repeats the defini= tion > with >> more detail, examples and test vectors. Same for >> Poly1305 in the next paragraph. >=20 > ChaCha20 was originally described in DJB's paper. There is still a com= plete > description of the algorithm in [FORIETF]. Once could argue that it is= a > more complete description since it includes examples and test vectors. >=20 >> >> Section 3 describes how to use AEAD_CHACHA20_POLY1305 with >> AuthEnvelopedData. The algorithm, as stated in section 1.1 has four >> inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, = and > an >> arbitrary length additional authenticated data (AAD). The key is gener= ated > by >> one of the methods in section 2 (Key Management); the nonce is generat= ed > by >> the sender. The text requires that it be unique, but does not mandate = of > suggest >> a way of doing this. This is fine. The plaintext according to section = 3 is > "the >> content located in the AuthEnvelopedData EncryptedContentInfo >> encryptedContent field". and the tag is stored in the AuthEnvelopedDat= a > mac >> field. >> >> What's missing is the AAD. I could not find what goes into the AAD. >> This is described in section 2.2 of RFC 5083, but it should be either > repeated here >> or referenced. It's jarring that the other inputs are described while = this > one is >> omitted. >=20 > That seems reasonable to add. >=20 > Jim >=20 >> >> The Security Considerations section seems fine. >> >> Yoav >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >=20 >=20 --------------ms030800090004090405050901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDYx NTU0MDRaMC8GCSqGSIb3DQEJBDEiBCAD7eYBaqnJe27aT1srw76EJ15Bjmm/LfBX31xYKmrD qjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCT/vFOf/JAU2afPfajCG1SFI/KdRYC6k46Tlq7WEcFH47Z45ZDmyV6 Y6yt+Gf8mHbwFDmxTOo7ZGseab6oi0Hwx6goRVbbYDQsI7JxCOPA4XmpAE+qR2HyOgpNzA4B c2T4/aGIB5e+HKPLpZxsRcrUe8xcQyI82gOzGzWeekrLlOCtUZIcoctZ4AbPKRStwr5GWr14 +7MkQGy1CtYUjE4ctUrwFhvHTYWKrmgaTH0c+srV44jYVagcExw1C7/uvZ5Qa/bLrwCjvcsN 24fXJkA3KuS6bwQ3NtpX6zzhXx1SyacYXMvV83r+G4FdEn29pe3IlGwyy4BmHxu3yeBBNbbt AAAAAAAA --------------ms030800090004090405050901-- From nobody Fri Jan 6 08:09:57 2017 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 13394129CEC; Fri, 6 Jan 2017 08:09:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148371899207.17470.11321927931109721253.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 08:09:52 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-05.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: Fri, 06 Jan 2017 16:09:52 -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-05.txt Pages : 8 Date : 2017-01-06 Abstract: This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-chacha20-poly1305-05 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 Fri Jan 6 08:12:13 2017 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 6C16A129B87 for ; Fri, 6 Jan 2017 08:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPUhnSMm3Gs2 for ; Fri, 6 Jan 2017 08:12:10 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE7D129B7C for ; Fri, 6 Jan 2017 08:12:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4E29130042D for ; Fri, 6 Jan 2017 11:01:54 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qHmCC2x8qkU7 for ; Fri, 6 Jan 2017 11:01:51 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 088D230024F; Fri, 6 Jan 2017 11:01:50 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_10292ECF-25D9-4CC9-B15D-5BD47434407A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 6 Jan 2017 11:12:04 -0500 Message-Id: References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> <0e1501d254c4$b542c1e0$1fc845a0$@augustcellars.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Jim Schaad , draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, curdle@ietf.org, Yoav Nir Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 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 Jan 2017 16:12:12 -0000 --Apple-Mail=_10292ECF-25D9-4CC9-B15D-5BD47434407A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Stephen: I had already tackled Yoav=92s comments in my working copy. I just did = one of the comments from the OPS Dir review. The other was moot because = the paragraph was rewritten to resolve Yoav=92s comments. Russ On Jan 6, 2017, at 10:54 AM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > I think we've one change pending from Yoav's review. There > were also some nits from the opsdir review [1] posted over > the holidays. >=20 > Do we think we can have an update with those fixes in the > next week? If so, I'll put this on the Jan 19th telechat > for approval. (If it's somehow easier for these changes to > be done as an RFC editor note, that's fine too - just > send me the text for that.) >=20 > Thanks, > S. >=20 > [1] > = https://datatracker.ietf.org/doc/review-ietf-curdle-cms-chacha20-poly1305-= 04-opsdir-lc-comstedt-2016-12-24/ >=20 > On 12/12/16 22:11, Jim Schaad wrote: >>=20 >>=20 >>> -----Original Message----- >>> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Yoav Nir >>> Sent: Sunday, December 11, 2016 5:14 AM >>> To: secdir@ietf.org >>> Cc: curdle@ietf.org; = draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org; >>> ietf@ietf.org >>> Subject: [Curdle] Review of = draft-ietf-curdle-cms-chacha20-poly1305-04 >>>=20 >>> Reviewer: Yoav Nir >>> Review result: Has Nits >>>=20 >>> Hi, >>>=20 >>> I have reviewed this document as part of the security directorate's >> ongoing >>> effort to review all IETF documents being processed by the IESG. = These >>> comments were written primarily for the benefit of the security area >> directors. >>> Document editors and WG chairs should treat these comments just like = any >>> other last call comments. >>>=20 >>> Summary: Ready with nits. >>>=20 >>> Introduction >>> ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit = key >>> and a 96-bit nonce. ChaCha20 is described in [FORIETF]. >>>=20 >>> ChaCha20 is described in DJB's paper. RFC 7539 just repeats the = definition >> with >>> more detail, examples and test vectors. Same for >>> Poly1305 in the next paragraph. >>=20 >> ChaCha20 was originally described in DJB's paper. There is still a = complete >> description of the algorithm in [FORIETF]. Once could argue that it = is a >> more complete description since it includes examples and test = vectors. >>=20 >>>=20 >>> Section 3 describes how to use AEAD_CHACHA20_POLY1305 with >>> AuthEnvelopedData. The algorithm, as stated in section 1.1 has four >>> inputs: a 256-bit key, a 96-bit nonce, an arbitrary length = plaintext, and >> an >>> arbitrary length additional authenticated data (AAD). The key is = generated >> by >>> one of the methods in section 2 (Key Management); the nonce is = generated >> by >>> the sender. The text requires that it be unique, but does not = mandate of >> suggest >>> a way of doing this. This is fine. The plaintext according to = section 3 is >> "the >>> content located in the AuthEnvelopedData EncryptedContentInfo >>> encryptedContent field". and the tag is stored in the = AuthEnvelopedData >> mac >>> field. >>>=20 >>> What's missing is the AAD. I could not find what goes into the AAD. >>> This is described in section 2.2 of RFC 5083, but it should be = either >> repeated here >>> or referenced. It's jarring that the other inputs are described = while this >> one is >>> omitted. >>=20 >> That seems reasonable to add. >>=20 >> Jim >>=20 >>>=20 >>> The Security Considerations section seems fine. >>>=20 >>> Yoav >>>=20 >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>=20 >>=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_10292ECF-25D9-4CC9-B15D-5BD47434407A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85 Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl 4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAxMDYxNjEyMDRaMCMGCSqGSIb3DQEJBDEWBBSDWYQeZVI47Ptb+Nx4QBOxshwjWzCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQDTdZbrfPps0EUMOUcasIhH3aik1QEpTL7R1kTtWhPR+wE620GJu7t9zmbzj+JS slGRvMkcKl02uEZzq5zRpfAAYzPu1FussaMO9Ax9aYaMwIwxFFPYNIEtsFATTqiXuEM8b2S7ToTK By3n0GNnFW3HJG/Pv2ws+gHZeuoumIzjPC6WUtZ38eZBVEI0Zvz5bjqm2Vg1VzAcvNkr7lBUNQDi FPDV9qtEiY/CYS2ovjl2qWrx/9AOwxx4LcWu895jRpdOUVgNQnoaEUMYlkdwAAGuirqWJPFyajt8 YK9myEaDGoyfMNBmB2TVD7oMQsFYIyCk2lRnjLDF8qYT9qTbR5p6AAAAAAAA --Apple-Mail=_10292ECF-25D9-4CC9-B15D-5BD47434407A-- From nobody Fri Jan 6 08:12:54 2017 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 27B0A129B7C; Fri, 6 Jan 2017 08:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dGck7OGpbj6; Fri, 6 Jan 2017 08:12:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72FC129B4F; Fri, 6 Jan 2017 08:12:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA5DEBE77; Fri, 6 Jan 2017 16:12:49 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI4kpVpU9OgG; Fri, 6 Jan 2017 16:12:49 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CFE63BE80; Fri, 6 Jan 2017 16:12:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483719169; bh=dy7VA9m5q/UpcmshCopVcp/W/CcOrPkBKnKg0Yr3mE8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=V1f28R7+3OO46/uX7dvH8YbB8gxq2TV7iI2+Y+f1VpUJ2W8rYUWp2aUHoWJzAs+0t G+4yhtGhV7r29L/pYkm12sKSvjTzQ812dJFS+m6LDQZJ1aX5GTdjffgIjRCWjF4kZR aTV+MtecnQ20VbNVf4ZodCwcc/yuf4KMXvx1br0w= To: Russ Housley References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> <0e1501d254c4$b542c1e0$1fc845a0$@augustcellars.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 6 Jan 2017 16:12:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010102040902050601080601" Archived-At: Cc: Jim Schaad , draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, curdle@ietf.org, Yoav Nir Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 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 Jan 2017 16:12:54 -0000 This is a cryptographically signed message in MIME format. --------------ms010102040902050601080601 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Excellent, I'll put it on the Jan 19th agenda. Thanks for the quick turnaround, S On 06/01/17 16:12, Russ Housley wrote: > Stephen: >=20 > I had already tackled Yoav=E2=80=99s comments in my working copy. I ju= st did one of the comments from the OPS Dir review. The other was moot b= ecause the paragraph was rewritten to resolve Yoav=E2=80=99s comments. >=20 > Russ >=20 >=20 > On Jan 6, 2017, at 10:54 AM, Stephen Farrell wrote: >=20 >> >> Hiya, >> >> I think we've one change pending from Yoav's review. There >> were also some nits from the opsdir review [1] posted over >> the holidays. >> >> Do we think we can have an update with those fixes in the >> next week? If so, I'll put this on the Jan 19th telechat >> for approval. (If it's somehow easier for these changes to >> be done as an RFC editor note, that's fine too - just >> send me the text for that.) >> >> Thanks, >> S. >> >> [1] >> https://datatracker.ietf.org/doc/review-ietf-curdle-cms-chacha20-poly1= 305-04-opsdir-lc-comstedt-2016-12-24/ >> >> On 12/12/16 22:11, Jim Schaad wrote: >>> >>> >>>> -----Original Message----- >>>> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Yoav Nir >>>> Sent: Sunday, December 11, 2016 5:14 AM >>>> To: secdir@ietf.org >>>> Cc: curdle@ietf.org; draft-ietf-curdle-cms-chacha20-poly1305.all@iet= f.org; >>>> ietf@ietf.org >>>> Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-= 04 >>>> >>>> Reviewer: Yoav Nir >>>> Review result: Has Nits >>>> >>>> Hi, >>>> >>>> I have reviewed this document as part of the security directorate's >>> ongoing >>>> effort to review all IETF documents being processed by the IESG. Th= ese >>>> comments were written primarily for the benefit of the security area= >>> directors. >>>> Document editors and WG chairs should treat these comments just like= any >>>> other last call comments. >>>> >>>> Summary: Ready with nits. >>>> >>>> Introduction >>>> ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit = key >>>> and a 96-bit nonce. ChaCha20 is described in [FORIETF]. >>>> >>>> ChaCha20 is described in DJB's paper. RFC 7539 just repeats the defi= nition >>> with >>>> more detail, examples and test vectors. Same for >>>> Poly1305 in the next paragraph. >>> >>> ChaCha20 was originally described in DJB's paper. There is still a c= omplete >>> description of the algorithm in [FORIETF]. Once could argue that it = is a >>> more complete description since it includes examples and test vectors= =2E >>> >>>> >>>> Section 3 describes how to use AEAD_CHACHA20_POLY1305 with >>>> AuthEnvelopedData. The algorithm, as stated in section 1.1 has four >>>> inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext= , and >>> an >>>> arbitrary length additional authenticated data (AAD). The key is gen= erated >>> by >>>> one of the methods in section 2 (Key Management); the nonce is gener= ated >>> by >>>> the sender. The text requires that it be unique, but does not mandat= e of >>> suggest >>>> a way of doing this. This is fine. The plaintext according to sectio= n 3 is >>> "the >>>> content located in the AuthEnvelopedData EncryptedContentInfo >>>> encryptedContent field". and the tag is stored in the AuthEnvelopedD= ata >>> mac >>>> field. >>>> >>>> What's missing is the AAD. I could not find what goes into the AAD. >>>> This is described in section 2.2 of RFC 5083, but it should be eithe= r >>> repeated here >>>> or referenced. It's jarring that the other inputs are described whil= e this >>> one is >>>> omitted. >>> >>> That seems reasonable to add. >>> >>> Jim >>> >>>> >>>> The Security Considerations section seems fine. >>>> >>>> Yoav >>>> >>>> _______________________________________________ >>>> 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 >=20 >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >=20 --------------ms010102040902050601080601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDYx NjEyNDhaMC8GCSqGSIb3DQEJBDEiBCCJeL1zNbZVMHhnpBwkOUaBu0UayPoVkAHrhJ7wuXph CDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAjhA/hzPXkv2FokcrTzWd1w9d/+XPm06fVLrgSZ/4dwRbA8U9Y7ygu hj4h4gh3DFaT2DSBJNFuS9GcXmSmsgeXieZmPx0IbMohH8zo6KvtefrnE6KA3X8rlF8OM5ya pmHaisNKZw9yWhrrgspFeyNtEKrfRavyMj3PBaVQHQQZr0Vp30Gr2lgIO6XUXJpyE5UEzmUe xRmqERmfv4eZiV6hBPJkJ2DA2PY614BlfSEGiU8IzFxcs/Qp0XtdKVAX80Wy3oXZ2oBIDnPL 69svA7D501B8Tzm8VRYwK75z+zzTILNYO5P4P8ZCpFJBgmjreUDq2Qfy/bRX7xG4ng4CovUf AAAAAAAA --------------ms010102040902050601080601-- From nobody Mon Jan 9 07:23:18 2017 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 9C478129D44; Mon, 9 Jan 2017 07:23:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148397538763.24980.3386719923727723156.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 07:23:07 -0800 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, Daniel Migault , draft-ietf-curdle-dnskey-eddsa@ietf.org, The IESG , stephen.farrell@cs.tcd.ie, rfc-editor@rfc-editor.org Subject: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard (draft-ietf-curdle-dnskey-eddsa-03.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:23:08 -0000 The IESG has approved the following document: - 'EdDSA for DNSSEC' (draft-ietf-curdle-dnskey-eddsa-03.txt) as Proposed Standard This document is the product of the CURves, Deprecating and a Little more Encryption Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/ Technical Summary 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. Working Group Summary The definition of the signature format was straight forward as it already exists in DNSSEC. In addition the computation and verification of the signature is defined in [I-D.irtf-cfrg-eddsa]. The only discussion was upon the use of using Ed25519ctx versus Ed25519, but the consensus was reached easily. The same discussion also occurred for draft-ietf-ipsecme-eddsa and draft-ietf-curdle-pkix with the same conclusion. The absence of context follows the recommendations of Section 10.3 of I-D.irtf-cfrg-eddsa and avoids unnecessarily complexity. Document Quality The document has been reviewed carefully. Examples have been generated with prototypes. Although no implementations have been reported in the document, there are ongoing effort. Personnel Document Shepherd: Daniel Migault, AD: Stephen Farrell From nobody Sun Jan 15 16:07:12 2017 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 3AE94129443; Sun, 15 Jan 2017 16:07:12 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148452523220.3227.14083780381909110364.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2017 16:07:12 -0800 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 98 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 00:07:12 -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: lamps acme trans sacm tcpinc saag ipsecme i2nsf tls radext Second Priority: dots Special Requests: --------------------------------------------------------- From nobody Tue Jan 17 12:33:19 2017 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 6924B12946E for ; Tue, 17 Jan 2017 12:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu-iRb0vNEgd for ; Tue, 17 Jan 2017 12:33:15 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092A31294A1 for ; Tue, 17 Jan 2017 12:33:15 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id l66so124526287ioi.1 for ; Tue, 17 Jan 2017 12:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zPrwQfqmjaBOmEaS/pR82SoeVp7bRqSMDiDYueDH7HE=; b=PRIjzj9lQMwBsgTflJjry0q97IxM/uDgCJFXt9tFv0I7RRFotMVMHE4+2PwZjXg1f3 K3xVLaGT4PaMlDw+BlkUJisjkIXvEVln/wk8VptGDETXGLemvQmVsSb8ko1ndnxYqDjo FHGt9M8v8XaKqXoKBIhvskhVX4G0UotCTJv6P3rvUgomCNAJVuGXspZQcsypVZvGOmx3 1kYzppbP1si5bqbIoLexH/VEo1oEpjd6TFRRZX6wuX72QzsFjUhjoXyuMpZ25qKztFgB 6Ow2xpZO/33bEesdtNCGMQlYjxfhQsvYkJoE0ZD7v/q76ZyT3d3CvaIKZ9CzTVGQeB/N t+yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zPrwQfqmjaBOmEaS/pR82SoeVp7bRqSMDiDYueDH7HE=; b=WjCzqFw2nLeN0QIiWE8p7QDPxDFGRaUfMdqlKBn8fbXkmnF6Ev4rxmfoFMDBHc3/1B wSzQVDJAAQVp1YpiW1d0/dU0ztHaiNVYbFAd4PVWtKyCQ8VlR5Xup4N8OP7OvFZdnufA tmMmJSh4H8TAkpoZVtN28uf8ETXvnrtG6mPGD6B1CIkTNilnQDp4YDb0qANY5U+OvRb+ eYBmQKxM9sly3//wcyTx9VLTjqM5Y8L75fjbcynmFGKn6fm/xSgoH/iew1Z4XBqzdBB6 israyhMgeOaNJ2KQ/zmW/b/CFrvHvJnyNfKMCMHcjn0RXD0RtTFFjPYZS08rpEu9URpu f2cw== X-Gm-Message-State: AIkVDXKT41QBqS3scs4BCWM5Vo1kYuO9NZjSPv1InXSHZY8D4LditRWrIC8d8FTQ0ptFoAwKJnxqywJh/PDLfA== X-Received: by 10.107.179.215 with SMTP id c206mr101762iof.35.1484685194078; Tue, 17 Jan 2017 12:33:14 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.5.201 with HTTP; Tue, 17 Jan 2017 12:33:13 -0800 (PST) In-Reply-To: <035701d25a3f$a46ca9f0$ed45fdd0$@augustcellars.com> References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <035701d25a3f$a46ca9f0$ed45fdd0$@augustcellars.com> From: Daniel Migault Date: Tue, 17 Jan 2017 15:33:13 -0500 X-Google-Sender-Auth: GTUd8YCPqiOt4bGzU9PpAy-PLEI Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1148576698b18c054650358e Archived-At: Cc: curdle , David Benjamin Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:33:17 -0000 --001a1148576698b18c054650358e Content-Type: text/plain; charset=UTF-8 Hi, Please indicate if the text added by Jim clarifies the previous confusion, and if we can close the thread. My understanding of the text is: """the private key is wrapped in an CurvePrivateKey object """ CurvePrivateKey = OCTET STRING ( private key) """and wrapped by the OCTET STRING of the 'privateKey' field.""" privateKey = OCTET STRING (OCTET STRING (private key)) Am I correct ? Yours, Daniel On Mon, Dec 19, 2016 at 4:34 PM, Jim Schaad wrote: > In my local version, I have done the following: > > > > 1. Changed EdPrivateKey to CurvePrivateKey. I hope that this will > not cause any confusion with the ECPrivateKey type defined in RFC5915. > > 2. I have changed the last sentence in the paragraph mentioned below > to > Thus when encoding a OneAsymmetricKey object, the private key is > wrapped in an CurvePrivateKey object and wrapped by the OCTET STRING of the > 'privateKey' field. > > 3. I have also expanded the appendix with the private key example to > have 1) the current PEM format, 2) an ASN.1 dump and 3) the value of the > private key. > > > > I debated using the OKP (Octet Key Pair) which was used in JOSE and COSE > but decided not to. > > > > Jim > > > > > > *From:* David Benjamin [mailto:davidben@chromium.org] > *Sent:* Thursday, December 15, 2016 11:18 PM > *To:* Jim Schaad > > *Cc:* curdle@ietf.org > *Subject:* Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 > > > > So we don't end up with two variants of this floating around (this thread > gives one data point of the current text being misinterpreted), What do you > think about these editorial changes? > > > > 1. In the paragraph beginning "For the keys defined in this document > [...]", add a sentence like "Note the opaque byte sequence is wrapped in > OCTET STRINGs twice in total." > > > > 2. EdPrivateKey sounds like this only applies to Ed* rather than both Ed* > and X*. It should probably be renamed. But the best name I can come up with > right now is PrivateKeyWrapper, which is terrible. Another option is to > avoid defining a type and just say: > > > > For the keys defined in this document, the private key is always an > > opaque byte sequence. This is encoded in a OneAsymmetricKey > > object by wrapping the sequence in an ASN.1 OCTET STRING > > and placing its DER encoding in the 'privateKey' field. Note that > > 'privateKey' is itself an OCTET STRING, so the original byte > > sequence is wrapped in OCTET STRINGs twice in total. > > > > David > > > > On Fri, Dec 16, 2016 at 1:56 AM David Benjamin > wrote: > > Ah, yes, I see OpenSSL has already shipped code which serializes X25519 in > this way, as early as OpenSSL 1.1.0 in September. That's unfortunate. It > would have been preferable to avoid this confusing double wrapper, but so > it goes I guess. > > > > David > > > > On Fri, Dec 16, 2016 at 12:53 AM Jim Schaad > wrote: > > I believe that the OpenSSL people would be sad if we changed this at this > time. I did some interop testing with their developers before the last > version was released and the OCTET STRING wrapper on the private key is > what we were doing at the time. > > Jim > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David Benjamin > Sent: Wednesday, December 14, 2016 5:23 AM > To: Ilari Liusvaara ; str4d > Cc: curdle@ietf.org > Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 > > On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara ilariliusvaara@welho.com> wrote: > On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > > Hello, > > > > I am currently updating my EdDSA Java library to implement the current > > spec for key encoding [0] (previously I used > > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > > PKCS#8 format for private keys). The example public key given in > > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > > private key [2] does not. > > > > It appears that the private key material within the example is 34 bytes, > > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > > AFAICT the present draft defers to for encoding), the private key is the > > b-bit seed k, which is 32 bytes. > > > > Am I missing something? If the example keys in the present draft are > > correct, it would be helpful to add a reference that clarifies their > > exact encoding. > > Apparently the key is wrapped in OCTET STRING twice for some reason, > so the length is actually 32 bytes (the first 2 are second OCTET STRING > header). > > Is it too late to change that / was there any particular reason for this? > Not that saving or using two bytes really matters, but it seems unnecessary > when we already have an OCTET-STRING-shaped hole to put our octet string in. > > > > David > > _______________________________________________ > 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 > > --001a1148576698b18c054650358e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please indicate if the te= xt added by Jim clarifies the previous confusion, and if we can close the t= hread.


My understanding of the text is:
""&qu= ot;the private key is wrapped in an CurvePrivateKey object ""&quo= t;
CurvePrivateKey =3D OCTET STRING ( private key)
= &= quot;""and wrapped by the OCTET STRING of the 'privateKey'= ; field."""
privateKey =3D OCTE= T STRING (OCTET STRING (private key))

Am I correct ?
<= br>
Yours,
Daniel
=C2=A0

On Mon, Dec 1= 9, 2016 at 4:34 PM, Jim Schaad <ietf@augustcellars.com>= wrote:

In my local version, I have done the following:=

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0Changed EdPrivateKey to CurvePrivateKey.= =C2=A0 I hope that this will not cause any confusion with the ECPrivateKey = type defined in RFC5915.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= u>I have changed the last sentence in the paragraph mentioned below to=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thus when encoding a OneAsym= metricKey object, the private key is wrapped in an CurvePrivateKey object a= nd wrapped by the OCTET STRING of the 'privateKey' field.=

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= 3.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 I have also expanded the ap= pendix with the private key example to have 1) the current PEM format, 2) a= n ASN.1 dump and 3) the value of the private key.

=

=C2=A0

I debated using the OKP (Octet Key Pair) which was used in JOSE and COS= E but decided not to.

=C2=A0

Jim<= /p>

=C2=A0

=C2=A0

From: David Benjamin [mailto:davidben@chromium.org]
Sent:= Thursday, December 15, 2016 11:18 PM
To: Jim Schaad <ietf@augustcellars.= com>


Cc: curdle@ietf.org
Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03

= =C2=A0

So we don't end u= p with two variants of this floating around (this thread gives one data poi= nt of the current text being misinterpreted), What do you think about these= editorial changes?

=C2= =A0

1. In the paragraph beginni= ng "For the keys defined in this document [...]", add a sentence = like "Note the opaque byte sequence is wrapped in OCTET STRINGs twice = in total."

= =C2=A0

2. EdPrivateKey sounds l= ike this only applies to Ed* rather than both Ed* and X*. It should probabl= y be renamed. But the best name I can come up with right now is PrivateKeyW= rapper, which is terrible. Another option is to avoid defining a type and j= ust say:

=C2=A0

=C2=A0 =C2=A0For the keys d= efined in this document, the private key is always an

=C2=A0 =C2=A0opaque byte sequence.=C2=A0 This= is encoded in a OneAsymmetricKey

=C2=A0 =C2=A0object by wrapping the sequence in an ASN.1 OCTET ST= RING

=C2=A0 =C2=A0and pl= acing its DER encoding in the 'privateKey' field. Note that<= u>

=C2=A0 =C2=A0'privateKey= 9; is itself an OCTET STRING, so the original byte

<= div>

=C2=A0 =C2=A0sequence is wrapped in OCTET STRING= s twice in total.

= =C2=A0

David<= u>

=C2=A0

= On Fri, Dec 16, 2016 at 1:56 AM David Benjamin <davidben@chromium.org> wrote:<= /u>

Ah, yes, I see OpenSSL has already shipped co= de which serializes X25519 in this way, as early as OpenSSL 1.1.0 in Septem= ber. That's unfortunate. It would have been preferable to avoid this co= nfusing double wrapper, but so it goes I guess.

=C2=A0

David

=C2=A0

On Fri,= Dec 16, 2016 at 12:53 AM Jim Schaad <ietf@augustcellars.com> wrote:

I believe that the OpenSSL people would be sad if we changed th= is at this time.=C2=A0 I did some interop testing with their developers bef= ore the last version was released and the OCTET STRING wrapper on the priva= te key is what we were doing at the time.

Jim

From: Curdle [m= ailto:curdle-b= ounces@ietf.org] On Behalf Of David Benjamin
Sent: Wednesday, D= ecember 14, 2016 5:23 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>; st= r4d <str4d@i2pmai= l.org>
Cc: c= urdle@ietf.org
Subject: Re: [Curdle] Key examples in draft-ietf-curd= le-pkix-03

On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara <mailt= o:ilariliusva= ara@welho.com> wrote:
On Wed, Dec 14, 2016 at 10:54:34AM +00= 00, str4d wrote:
> Hello,
>
> I am currently updating my = EdDSA Java library to implement the current
> spec for key encoding [= 0] (previously I used
> draft-josefsson-pkix-eddsa-04 for public keys= , and the equivalent in
> PKCS#8 format for private keys). The exampl= e public key given in
> draft-ietf-curdle-pkix-03 [1] passes my tests= , however the example
> private key [2] does not.
>
> It = appears that the private key material within the example is 34 bytes,
&g= t; but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which
&= gt; AFAICT the present draft defers to for encoding), the private key is th= e
> b-bit seed k, which is 32 bytes.
>
> Am I missing som= ething? If the example keys in the present draft are
> correct, it wo= uld be helpful to add a reference that clarifies their
> exact encodi= ng.

Apparently the key is wrapped in OCTET STRING twice for some rea= son,
so the length is actually 32 bytes (the first 2 are second OCTET ST= RING
header).

Is it too late to change that / was there any parti= cular reason for this? Not that saving or using two bytes really matters, b= ut it seems unnecessary when we already have an OCTET-STRING-shaped hole to= put our octet string in.



David

_____________________= __________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf= .org/mailman/listinfo/curdle

<= /div>

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

--001a1148576698b18c054650358e-- From nobody Tue Jan 17 13:07:03 2017 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 E78FE1294A1 for ; Tue, 17 Jan 2017 13:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 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=-3.199, 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 ScQALIvt8X-s for ; Tue, 17 Jan 2017 13:06:58 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB1E1294D3 for ; Tue, 17 Jan 2017 13:06:58 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v23so179955305qtb.0 for ; Tue, 17 Jan 2017 13:06:58 -0800 (PST) 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 :cc; bh=9tK9BN7mi6mOuUc5Ax/lqzS/1kzeG4NFwC3ecu9+A+Q=; b=PJFeTiDq5qF2M9tfQV36ufwsbB9fVG9RlKsUO0D7t3w/+oxRTBKzD1KvlBWH83sAfy mUWFdfT31hD27ljVxWq7QhG111wOWHmPdi0nu+9iKC+iGh5zXxPTL+xDOGFc1r5guBp8 c/nhaPZHJJcHtCXmJb/0qIUgTnImlBUtCyqeE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9tK9BN7mi6mOuUc5Ax/lqzS/1kzeG4NFwC3ecu9+A+Q=; b=geaJw4cCD9byew4/+A47g7+zila0pxzAC9KiIyyok/O1hxwvWLUzr162LoXueB45if 52YV3U07bNUF8CzjMRrobGwLlcqcTlw/jafCLBicv0EaWc8WJPpe6Dmv9xtkruJHSFaZ gWn4mj1nxccwYNUMR3rm8ywMBKqxV1AthOMqCfoGFVteyh+zItzw+uZIzk4tdOMRVUa7 6dGz8i1rOsegDbtFaWxER2TNmRBxAJKrHsN0O5D7odu9f3S07eM3/r7KzFXDsvWtGiKZ IMtqjxRi8AkNMGXFkJANi+1CJ610Rz4c2uA9R1F5WE2EfdsHtMab39cw2Sqo3fde8341 psPg== X-Gm-Message-State: AIkVDXJQjmPOt2aYEMZSsukQboFWJSL57UysB0zC0rZk6iAZ1Wj5J3MMR3Wivj9umZxQutKSB0ntawiVHibEHA2H X-Received: by 10.200.49.41 with SMTP id g38mr35367246qtb.175.1484687216909; Tue, 17 Jan 2017 13:06:56 -0800 (PST) MIME-Version: 1.0 References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <035701d25a3f$a46ca9f0$ed45fdd0$@augustcellars.com> In-Reply-To: From: David Benjamin Date: Tue, 17 Jan 2017 21:06:46 +0000 Message-ID: To: Daniel Migault , Jim Schaad Content-Type: multipart/alternative; boundary=001a113a2bec2b1db9054650ae6f Archived-At: Cc: curdle Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:07:02 -0000 --001a113a2bec2b1db9054650ae6f Content-Type: text/plain; charset=UTF-8 Jim's proposed text seems reasonable to me. CurvePrivateKey is a much better name than PrivateKeyWrapper! Maybe "and wrapped by the OCTET STRING" => "which is then wrapped by the OCTET STRING", but this is all nitpicks and I'm happy with whatever. On Tue, Jan 17, 2017 at 3:33 PM Daniel Migault wrote: > Hi, > > Please indicate if the text added by Jim clarifies the previous confusion, > and if we can close the thread. > > > My understanding of the text is: > > """the private key is wrapped in an CurvePrivateKey object """ > CurvePrivateKey = OCTET STRING ( private key) > """and wrapped by the OCTET STRING of the 'privateKey' field.""" > privateKey = OCTET STRING (OCTET STRING (private key)) > > Am I correct ? > > Yours, > Daniel > > > On Mon, Dec 19, 2016 at 4:34 PM, Jim Schaad > wrote: > > In my local version, I have done the following: > > > > 1. Changed EdPrivateKey to CurvePrivateKey. I hope that this will > not cause any confusion with the ECPrivateKey type defined in RFC5915. > > 2. I have changed the last sentence in the paragraph mentioned below > to > Thus when encoding a OneAsymmetricKey object, the private key is > wrapped in an CurvePrivateKey object and wrapped by the OCTET STRING of the > 'privateKey' field. > > 3. I have also expanded the appendix with the private key example to > have 1) the current PEM format, 2) an ASN.1 dump and 3) the value of the > private key. > > > > I debated using the OKP (Octet Key Pair) which was used in JOSE and COSE > but decided not to. > > > > Jim > > > > > > *From:* David Benjamin [mailto:davidben@chromium.org] > *Sent:* Thursday, December 15, 2016 11:18 PM > *To:* Jim Schaad > > *Cc:* curdle@ietf.org > *Subject:* Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 > > > > So we don't end up with two variants of this floating around (this thread > gives one data point of the current text being misinterpreted), What do you > think about these editorial changes? > > > > 1. In the paragraph beginning "For the keys defined in this document > [...]", add a sentence like "Note the opaque byte sequence is wrapped in > OCTET STRINGs twice in total." > > > > 2. EdPrivateKey sounds like this only applies to Ed* rather than both Ed* > and X*. It should probably be renamed. But the best name I can come up with > right now is PrivateKeyWrapper, which is terrible. Another option is to > avoid defining a type and just say: > > > > For the keys defined in this document, the private key is always an > > opaque byte sequence. This is encoded in a OneAsymmetricKey > > object by wrapping the sequence in an ASN.1 OCTET STRING > > and placing its DER encoding in the 'privateKey' field. Note that > > 'privateKey' is itself an OCTET STRING, so the original byte > > sequence is wrapped in OCTET STRINGs twice in total. > > > > David > > > > On Fri, Dec 16, 2016 at 1:56 AM David Benjamin > wrote: > > Ah, yes, I see OpenSSL has already shipped code which serializes X25519 in > this way, as early as OpenSSL 1.1.0 in September. That's unfortunate. It > would have been preferable to avoid this confusing double wrapper, but so > it goes I guess. > > > > David > > > > On Fri, Dec 16, 2016 at 12:53 AM Jim Schaad > wrote: > > I believe that the OpenSSL people would be sad if we changed this at this > time. I did some interop testing with their developers before the last > version was released and the OCTET STRING wrapper on the private key is > what we were doing at the time. > > Jim > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David Benjamin > Sent: Wednesday, December 14, 2016 5:23 AM > To: Ilari Liusvaara ; str4d > Cc: curdle@ietf.org > Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03 > > On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara ilariliusvaara@welho.com> wrote: > On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote: > > Hello, > > > > I am currently updating my EdDSA Java library to implement the current > > spec for key encoding [0] (previously I used > > draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in > > PKCS#8 format for private keys). The example public key given in > > draft-ietf-curdle-pkix-03 [1] passes my tests, however the example > > private key [2] does not. > > > > It appears that the private key material within the example is 34 bytes, > > but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which > > AFAICT the present draft defers to for encoding), the private key is the > > b-bit seed k, which is 32 bytes. > > > > Am I missing something? If the example keys in the present draft are > > correct, it would be helpful to add a reference that clarifies their > > exact encoding. > > Apparently the key is wrapped in OCTET STRING twice for some reason, > so the length is actually 32 bytes (the first 2 are second OCTET STRING > header). > > Is it too late to change that / was there any particular reason for this? > Not that saving or using two bytes really matters, but it seems unnecessary > when we already have an OCTET-STRING-shaped hole to put our octet string in. > > > > David > > _______________________________________________ > 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 > > > --001a113a2bec2b1db9054650ae6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim's proposed text seems reasonable to me. CurvePriva= teKey is a much better name than PrivateKeyWrapper! Maybe "and wrapped= by the OCTET STRING" =3D> "which is then wrapped by the OCTET= STRING", but this is all nitpicks and I'm happy with whatever.

On Tue, Ja= n 17, 2017 at 3:33 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

Please indicate if the text added = by Jim clarifies the previous confusion, and if we can close the thread.

My understanding of the text is:

= """the private key is wrapped in an CurvePrivateKey object &= quot;""
Cur= vePrivateKey =3D OCTET STRING ( private key)
=
"""and wrapped by the OCTET STRING of the 'priva= teKey' field."""
<= span style=3D"font-size:11pt;font-family:"calibri",sans-serif" cl= ass=3D"gmail_msg">
privateKey =3D OCTET STRING (OCTET STRING (private key))<= br class=3D"gmail_msg">
Am I correct ?

Yours,
Daniel
=C2=A0=
On Mon, Dec 19, = 2016 at 4:34 PM, Jim Schaad <= ietf@augustcellars.com> wrote:

In my local version, I have done the following:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Chang= ed EdPrivateKey to CurvePrivateKey.=C2=A0 I hope that this will not cause a= ny confusion with the ECPrivateKey type defined in RFC5915.

2.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 I have changed the last sentence in the paragraph mentioned below= to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thus = when encoding a OneAsymmetricKey object, the private key is wrapped in an C= urvePrivateKey object and wrapped by the OCTET STRING of the 'privateKe= y' field.<= /p>

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have also expanded the appendix with= the private key example to have 1) the current PEM format, 2) an ASN.1 dum= p and 3) the value of the private key.

=C2=A0

I debated using= the OKP (Octet Key Pair) which was used in JOSE and COSE but decided not t= o.

= =C2=A0

Jim

=C2=A0

= =C2=A0

From: David Benjamin [mailto:davidben@chromium.org]
Sent: Thursday, December 15, = 2016 11:18 PM
To: Jim Sch= aad <ietf@augustcellars.com>


Cc: curdle@ietf.org
Subject: Re: [Curdle] Key examples in draft-iet= f-curdle-pkix-03

=C2=A0

= So we don't end up with two variants of this floating around (this thre= ad gives one data point of the current text being misinterpreted), What do = you think about these editorial changes?

=C2=A0

1. In the paragr= aph beginning "For the keys defined in this document [...]", add = a sentence like "Note the opaque byte sequence is wrapped in OCTET STR= INGs twice in total."

=C2=A0

2. EdPrivateKey sounds l= ike this only applies to Ed* rather than both Ed* and X*. It should probabl= y be renamed. But the best name I can come up with right now is PrivateKeyW= rapper, which is terrible. Another option is to avoid defining a type and j= ust say:

=C2=A0

=

=C2=A0 =C2=A0For = the keys defined in this document, the private key is always an

=C2=A0 =C2=A0opaque byte sequence.=C2=A0= This is encoded in a OneAsymmetricKey

=C2=A0 =C2=A0object by wrapping the sequence in an ASN.1 OCTET = STRING

=C2=A0 =C2=A0and placi= ng its DER encoding in the 'privateKey' field. Note that

=C2=A0 =C2=A0'privateKey' is it= self an OCTET STRING, so the original byte

=C2=A0 =C2=A0sequence is wrapped in OCTET STRINGs twice in to= tal.

<= div class=3D"gmail_msg">

=C2=A0

David

=C2=A0

On Fri, Dec 16, 2016 at 1:56 AM David Benjamin &= lt;davidben@chromium.org> wrote:

Ah, yes, I see OpenSSL has already shi= pped code which serializes X25519 in this way, as early as OpenSSL 1.1.0 in= September. That's unfortunate. It would have been preferable to avoid = this confusing double wrapper, but so it goes I guess.

<= div class=3D"gmail_msg">

=C2=A0

David

=C2= =A0

On Fri, Dec 16, 2016 at 12:53 AM = Jim Schaad <ietf@augustcellars.com> wrote:

I believe that the OpenSSL people would be sad if we changed this at this = time.=C2=A0 I did some interop testing with their developers before the las= t version was released and the OCTET STRING wrapper on the private key is w= hat we were doing at the time.

Jim

From: Curdle [mailto:= curdle-bounces@ietf.org] On Behalf Of David Benjamin
Sent: Wednesday, December 14, 2016 5:23 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>; str4d &l= t;str4d@i2pmail.org>
Cc: curdle@ietf.orgSubject: Re: [Curdle] Key examples in draft-ietf-curdl= e-pkix-03

On Wed, Dec 14, 20= 16 at 7:15 AM Ilari Liusvaara <mailto:ilariliusvaara@welho.com> wrote:
On Wed, Dec 14, 2016 at 10:54:34AM +000= 0, str4d wrote:
> Hello,
&= gt;
> I am currently updating my EdDSA Java libra= ry to implement the current
> spec for key encodi= ng [0] (previously I used
> draft-josefsson-pkix-= eddsa-04 for public keys, and the equivalent in
>= PKCS#8 format for private keys). The example public key given in
> draft-ietf-curdle-pkix-03 [1] passes my tests, however = the example
> private key [2] does not.
>
> It appears that the private= key material within the example is 34 bytes,
> b= ut according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which
> AFAICT the present draft defers to for encoding), the p= rivate key is the
> b-bit seed k, which is 32 byt= es.
>
> Am I missing so= mething? If the example keys in the present draft are
> correct, it would be helpful to add a reference that clarifies their=
> exact encoding.

Apparently the key is wrapped in OCTET STRING twice for so= me reason,
so the length is actually 32 bytes (the f= irst 2 are second OCTET STRING
header).

Is it too late to change that / was ther= e any particular reason for this? Not that saving or using two bytes really= matters, but it seems unnecessary when we already have an OCTET-STRING-sha= ped hole to put our octet string in.



David

________________________________________= _______
Curdle mailing list
<= a href=3D"mailto:Curdle@ietf.org" class=3D"gmail_msg" target=3D"_blank">Cur= dle@ietf.org
https://www.iet= f.org/mailman/listinfo/curdle


____________= ___________________________________
Curdle mailing list
Cu= rdle@ietf.org
https://www.ietf.org/mailman/listinf= o/curdle


--001a113a2bec2b1db9054650ae6f-- From nobody Tue Jan 17 13:14:15 2017 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 2A5231295A5 for ; Tue, 17 Jan 2017 13:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyvvToVeVHN4 for ; Tue, 17 Jan 2017 13:14:12 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 323131294F8 for ; Tue, 17 Jan 2017 13:14:12 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id o138so16922355ito.3 for ; Tue, 17 Jan 2017 13:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WNvqaNgND+yFz0J2YJAb3fqQ25mX+40czlDxNsh5XoI=; b=u14E0DRTKCl974NmPj/Tto+qXSik/aUiik7fPUXasQFOzOAG+gCUAzKYVknEqyhbWh TRr5TiAX87cytAqfIo1xvHp8yU/AqprjypeILqY8r4zloM1SB9vP9zqkPuWMeVq1tt6q o+y61Skj2NHRW9ThcU8wnFL/G3I/Er8DFEaisERYGqQmd10rIOavVxxdeOSfmqeuv6jg UxvzjPXyeW43IcZOY5f1R2RtYCFudp0HclMIk3XetypUkY7EHJhVcrbFcD8VB4UP7JkM I8jalzsA9kl79yI4eGOE0CPCSaTbnkhgAfamB+cyh292k7lKECUAY7ra/S6NYx5vbzig EpoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WNvqaNgND+yFz0J2YJAb3fqQ25mX+40czlDxNsh5XoI=; b=W3oKcxNAGwv/mCb0PT/O+dq5So9t4Deb+/gMro1IfRHceGYDXohKMsn3B2RL8Fiv07 TMitB1x+bwtdNVUiDTMJ0JoNa+dbnz8ZVo5Tzfm6OagNUhH1BUETtgfSIcM80PSmeBxu jPa003MDFxj+lD1JTvc2Ou2+XLZEC7ShlbKv0E28OTkMa4fOjRK2h41K4TCKa0Skzb3H XIsMCeH6B6U/Nbl5kQz0aOZkvNfsUUsJGtpwWkTLC1DI1jF7kufK6AIgMOx0I6QbeCHd qT9A1NHZ5bf2eDNBpE/dlYFRUiFyfLUQuEfELVMAearYjXXvOOGPiy8nbB7g1lTXzLCr bqUw== X-Gm-Message-State: AIkVDXL9/OlLhiLousbhwMWuAAGGQOBwxDry/JvjntvWaTYPrTuwq6juXSYrEGZ8cPMm0BwrSuo4I44eCQxWXQ== X-Received: by 10.36.246.5 with SMTP id u5mr296183ith.48.1484687651457; Tue, 17 Jan 2017 13:14:11 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.5.201 with HTTP; Tue, 17 Jan 2017 13:14:10 -0800 (PST) In-Reply-To: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> From: Daniel Migault Date: Tue, 17 Jan 2017 16:14:10 -0500 X-Google-Sender-Auth: g-J28LplibepzaWwbRqPKGzW62I Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c034f1211697a054650c8bc Archived-At: Cc: Nikos Mavrogiannopoulos , "Dang, Quynh \(Fed\)" , Jim Schaad , Curdle , "Salz, Rich" Subject: Re: [Curdle] Some work for the group 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 Jan 2017 21:14:14 -0000 --94eb2c034f1211697a054650c8bc Content-Type: text/plain; charset=UTF-8 Hi, So it is not clear to me whether we have found consensus on that thread. My understanding is that there is not a clear consensus that pre-hash version of EdDSA MUST NOT be used by CA. Would it help moving the document forward by: - 1) enabling CA to use these versions in Section 5 and, - 2) bring the discussion of pre-hash usage by CA in the Security consideration section. Yours, Daniel On Thu, Dec 15, 2016 at 11:33 AM, Phillip Hallam-Baker < phill@hallambaker.com> wrote: > It looks to me as if in effect the prehash vs pure issue is going to > settle out into a situation where all signatures are pure signatures at the > specification level with an additional hash being introduced in the > packaging layer where bulk data is involved. > > I have implemented most of the popular packaging formats and most of my > API calls internally turn out to be for a 'sign and digest' operation > rather than Sign-this-digest. Most cases the bulk data is being put through > a digest that is then put into some other structure for signature. There is > almost always some sort of metadata you want in there in addition to the > content. > > Another way to look at this is that Ed255x is a drop in replacement for > RSA Signature that removes the restriction on the size of the input data to > be signed but not the requirement for it to be buffered. Most packaging > formats end up being a signature over a small chunk of static data which in > the case of streamed content are virtually always reference to external > data. > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c034f1211697a054650c8bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

So it is not clear to me whethe= r we have found consensus on that thread.

My understanding is= that there is not a clear consensus that pre-hash version of EdDSA MUST NO= T be used by CA.

Would it help moving the document forward by:
= =C2=A0 =C2=A0 - 1) enabling CA to use these versions in Section 5 and,
= =C2=A0 =C2=A0 - 2) bring the discussion of pre-hash usage by CA in the Secu= rity consideration section.

Yours,
Daniel
<= div>=C2=A0


On Thu, Dec 15, 2016 at 11:33 AM, Phillip Hallam-Baker <= span dir=3D"ltr"><phill@hallambaker.com> wrote:
It looks to me as if in effect the prehash vs pure issue is going to s= ettle out into a situation where all signatures are pure signatures at the = specification level with an additional hash being introduced in the packagi= ng layer where bulk data is involved.

I have implemented most of the popular packaging formats and m= ost of my API calls internally turn out to be for a 'sign and digest= 9; operation rather than Sign-this-digest. Most cases the bulk data is bein= g put through a digest that is then put into some other structure for signa= ture. There is almost always some sort of metadata you want in there in add= ition to the content.

Ano= ther way to look at this is that Ed255x is a drop in replacement for RSA Si= gnature that removes the restriction on the size of the input data to be si= gned but not the requirement for it to be buffered. Most packaging formats = end up being a signature over a small chunk of static data which in the cas= e of streamed content are virtually always reference to external data.


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

--94eb2c034f1211697a054650c8bc-- From nobody Wed Jan 18 03:41:02 2017 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 9407B12941E; Wed, 18 Jan 2017 03:40:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148473965859.21258.3388086913557624183.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 03:40:58 -0800 Archived-At: Cc: nco@comstedt.net, draft-ietf-curdle-cms-chacha20-poly1305@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Subject: [Curdle] Benoit Claise's No Objection on draft-ietf-curdle-cms-chacha20-poly1305-05: (with COMMENT) 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, 18 Jan 2017 11:40:58 -0000 Benoit Claise has entered the following ballot position for draft-ietf-curdle-cms-chacha20-poly1305-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As mentioned by Niclas in his OPS DIR review. - Section 3, change the 2nd must to all capitals in the following sentence "The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a AEADChaCha20Poly1305Nonce:” From nobody Wed Jan 18 07:01:50 2017 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 AB932129461 for ; Wed, 18 Jan 2017 07:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=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 UEKpk45GrAS2 for ; Wed, 18 Jan 2017 07:01:47 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E4C126D73 for ; Wed, 18 Jan 2017 07:01:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EB6B7300466 for ; Wed, 18 Jan 2017 09:46:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id di4lMkyKjw-U for ; Wed, 18 Jan 2017 09:46:07 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CE09D300254; Wed, 18 Jan 2017 09:46:06 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148473965859.21258.3388086913557624183.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 09:53:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <62E3C9AC-BEC0-4F00-89E2-7A4316CB5425@vigilsec.com> References: <148473965859.21258.3388086913557624183.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: nco@comstedt.net, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305@ietf.org, IESG Subject: Re: [Curdle] Benoit Claise's No Objection on draft-ietf-curdle-cms-chacha20-poly1305-05: (with COMMENT) 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, 18 Jan 2017 15:01:48 -0000 Benoit: Good catch. I=92m pleased to make that change. Russ On Jan 18, 2017, at 6:40 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-curdle-cms-chacha20-poly1305-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > As mentioned by Niclas in his OPS DIR review. >=20 > - Section 3, change the 2nd must to all capitals in the following > sentence=20 > "The AlgorithmIdentifier parameters field MUST be present, and the > parameters field must contain a AEADChaCha20Poly1305Nonce:=94 From nobody Wed Jan 18 17:38:41 2017 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 4775612948C; Wed, 18 Jan 2017 17:38:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Niclas Comstedt To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148478991628.2190.10916721959878443239.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 17:38:36 -0800 Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-05 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, 19 Jan 2017 01:38:36 -0000 Reviewer: Niclas Comstedt Review result: Has Nits Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-curdle-cms-chacha20-poly1305-05 Background: I reviewed 04 and found only minor nits. Summary: Minor nit and incorrect reference - Section 3, still need the 2nd must to all capitals in the following sentence "The AlgorithmIdentifier parameters field MUST be present, and the parameters field must contain a AEADChaCha20Poly1305Nonce:” - Section 6. First paragraph references RFC7534 as if its the same as [FORIETF]. I think the RFC is a typo (and that actual RFC is unrelated). So either needs the corrected RFC or remove that and keep referencing only [FORIETF]. /nco From nobody Thu Jan 19 06:30:29 2017 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 C8A8C12961C for ; Thu, 19 Jan 2017 06:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=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 pwsvSxomntO6 for ; Thu, 19 Jan 2017 06:30:27 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B717012961A for ; Thu, 19 Jan 2017 06:30:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7CEBF300290 for ; Thu, 19 Jan 2017 09:20:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R-gBlKZ1Ywly for ; Thu, 19 Jan 2017 09:20:08 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id C8E2230026A; Thu, 19 Jan 2017 09:20:07 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148478991628.2190.10916721959878443239.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 09:23:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148478991628.2190.10916721959878443239.idtracker@ietfa.amsl.com> To: Niclas Comstedt X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ops-dir@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, curdle@ietf.org Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-05 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 Jan 2017 14:30:28 -0000 Niclas: Thanks for taking that time to review the document. > Reviewer: Niclas Comstedt > Review result: Has Nits >=20 > Hi, >=20 > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written with the intent of improving the > operational aspects of the IETF drafts. Comments that are not > addressed in last call may be included in AD reviews during the IESG > review. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > Document reviewed: draft-ietf-curdle-cms-chacha20-poly1305-05 >=20 > Background: I reviewed 04 and found only minor nits. >=20 > Summary: Minor nit and incorrect reference >=20 > - Section 3, still need the 2nd must to all capitals in the following > sentence=20 > "The AlgorithmIdentifier parameters field MUST be present, and the > parameters field must contain a AEADChaCha20Poly1305Nonce:=94 Yes. I=92m pleased to make that change. > - Section 6. First paragraph references RFC7534 as if its the same as > [FORIETF]. I think the RFC is a typo (and that actual RFC is > unrelated). So either needs the corrected RFC or remove that and keep > referencing only [FORIETF]. I cannot find a reference to RFC 7534. I see a reference to RFC 7539, = which is the correct RFC. Russ= From nobody Thu Jan 19 07:30:12 2017 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 02E991293FD; Thu, 19 Jan 2017 07:30:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148483980700.10414.3737837127789023331.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 07:30:07 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-06.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, 19 Jan 2017 15:30:07 -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-06.txt Pages : 8 Date : 2017-01-19 Abstract: This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-chacha20-poly1305-06 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 Jan 19 07:31:55 2017 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 7B9BF129487 for ; Thu, 19 Jan 2017 07:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HfdhXJ2ouGz for ; Thu, 19 Jan 2017 07:31:52 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C151293FD for ; Thu, 19 Jan 2017 07:31:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 766C830043A for ; Thu, 19 Jan 2017 10:21:36 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3DH4wzgQ_Wbm for ; Thu, 19 Jan 2017 10:21:35 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 2C6F2300209 for ; Thu, 19 Jan 2017 10:21:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148483980700.10414.3737837127789023331.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 10:31:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <683A7DA1-6984-4982-8E40-23BFA5F1BB92@vigilsec.com> References: <148483980700.10414.3737837127789023331.idtracker@ietfa.amsl.com> To: curdle@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-chacha20-poly1305-06.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:31:54 -0000 This new version resolves the comments from the latest OPS Dire Review = and the IESG Evaluation. Russ On Jan 19, 2017, at 10:30 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Using ChaCha20-Poly1305 Authenticated = Encryption in the Cryptographic Message Syntax (CMS) > Author : Russell Housley > Filename : draft-ietf-curdle-cms-chacha20-poly1305-06.txt > Pages : 8 > Date : 2017-01-19 >=20 > Abstract: > This document describes the conventions for using ChaCha20-Poly1305 > Authenticated Encryption in the Cryptographic Message Syntax (CMS). > ChaCha20-Poly1305 is an authenticated encryption algorithm > constructed of the ChaCha stream cipher and Poly1305 authenticator. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-chacha20-poly1305-06 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-chacha20-poly130= 5-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Jan 23 08:08:23 2017 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 273EA12965F; Mon, 23 Jan 2017 08:08:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148518769515.29457.16886054773620285891.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2017 08:08:15 -0800 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, Daniel Migault , draft-ietf-curdle-cms-chacha20-poly1305@ietf.org, The IESG , stephen.farrell@cs.tcd.ie, rfc-editor@rfc-editor.org Subject: [Curdle] Protocol Action: 'Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)' to Proposed Standard (draft-ietf-curdle-cms-chacha20-poly1305-06.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 16:08:15 -0000 The IESG has approved the following document: - 'Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)' (draft-ietf-curdle-cms-chacha20-poly1305-06.txt) as Proposed Standard This document is the product of the CURves, Deprecating and a Little more Encryption Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ Technical Summary This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator. Working Group Summary The draft had no controversy. Reviews revealed minor nits that were corrected. Document Quality CMS is already deployed, and the draft describes how to use a specific authenticated encryption algorithm which is expected to be used in the future. The purpose of the draft is to keep CMS up to date with security, and thus deployed. Reviews did not end with important changes in the protocol. Personnel The Document Shepherd is Daniel Migault. The irresponsible Area Director is Stephen Farrell. From nobody Tue Jan 24 17:39:31 2017 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 6E1361295F6 for ; Tue, 24 Jan 2017 17:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNmh5902kkpl for ; Tue, 24 Jan 2017 17:39:28 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78281129601 for ; Tue, 24 Jan 2017 17:39:28 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id v96so3214845ioi.0 for ; Tue, 24 Jan 2017 17:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NH+NtjVESqHCE7nIA/L5i/x4tCRwznU4D5h0DIjAWCg=; b=BTVXqluF0nJW2oszfXJaXyaCCeYXSywIcQQgiXGFDhEROGLZx3aF1eDQ9rMK7779mN v1mdgsA+yPU3lVFg8dM/dec1LyMf2swSyOKG3QJrUfIUczfpJSzrF8wmvMOV1/NF1bKj EfZ1VXv1B8DsngVr6G9oM70ZdYt2EmW9o94QECNhiC/DZEw/y1S2wRU8gd0/mfVM4vrF eRWBZ9gZPC06Tdhpx2HuOctS6Mx9Tc0ycoFNa9Nui+jaRKkH/1/qNVPRZxSr3DmeJPlU 5pwjQntpW9lH9pkA4lJrBq49EZZgzoS+ZdF74feRry7ZeANG4YP+q3LMtS2ELZxvZO2+ 2oug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NH+NtjVESqHCE7nIA/L5i/x4tCRwznU4D5h0DIjAWCg=; b=SkyM6VWkC2RzclmuVThDXR/I347yORjw/9tBLKldPH6Tj9mqHzBFoWdvJzt3EJgW6J 97yn3LyWo9PJVgqEO53voCHtX6u5RLJqNykBl3cpxPYcAebW11G7pp7r3nIvNUQWDrbW rmhppo0D08A5zDrBABTVL0y4pMuBugwq1DAjFwqDR0gd6Jaqx/VAjTV4DWO8T18H0cxV qi52NPx+P55xWABeUReYP12aeE8XjulOouPCtTpOrAILyDFaJwLXjmpHihq581Y/9ETe uckADiLoldb+LIiO6A840PObaR33wYqO3DnzRzRgAbRRxFucSy1U4BGxxLtfoKXLWuc3 e3qw== X-Gm-Message-State: AIkVDXJM7cuaID6mHSlo8WZhrfpUI3O9aALT7PhvMzB5PFGs+xp1+QqVnyDG7euL2+fzwuoCjkVHmsmEWdHyEg== X-Received: by 10.107.18.230 with SMTP id 99mr30192165ios.45.1485308367739; Tue, 24 Jan 2017 17:39:27 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.5.201 with HTTP; Tue, 24 Jan 2017 17:39:27 -0800 (PST) In-Reply-To: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> From: Daniel Migault Date: Tue, 24 Jan 2017 20:39:27 -0500 X-Google-Sender-Auth: 81Cgys_a4MC_XVEHZrwF8C6uGco Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a113fd398a423700546e14dfb Archived-At: Cc: Nikos Mavrogiannopoulos , "Dang, Quynh \(Fed\)" , Jim Schaad , Curdle , "Salz, Rich" Subject: Re: [Curdle] Some work for the group 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 Jan 2017 01:39:30 -0000 --001a113fd398a423700546e14dfb Content-Type: text/plain; charset=UTF-8 Hi, As I have not seen any comments on that, should we consider that we have a rough consensus ? If you believe that is not the appropriate way to close this thread, please raise your opinion by the end of the week. Yours, Daniel On Tue, Jan 17, 2017 at 4:14 PM, Daniel Migault wrote: > Hi, > > So it is not clear to me whether we have found consensus on that thread. > > My understanding is that there is not a clear consensus that pre-hash > version of EdDSA MUST NOT be used by CA. > > Would it help moving the document forward by: > - 1) enabling CA to use these versions in Section 5 and, > - 2) bring the discussion of pre-hash usage by CA in the Security > consideration section. > > Yours, > Daniel > > > > On Thu, Dec 15, 2016 at 11:33 AM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> It looks to me as if in effect the prehash vs pure issue is going to >> settle out into a situation where all signatures are pure signatures at the >> specification level with an additional hash being introduced in the >> packaging layer where bulk data is involved. >> >> I have implemented most of the popular packaging formats and most of my >> API calls internally turn out to be for a 'sign and digest' operation >> rather than Sign-this-digest. Most cases the bulk data is being put through >> a digest that is then put into some other structure for signature. There is >> almost always some sort of metadata you want in there in addition to the >> content. >> >> Another way to look at this is that Ed255x is a drop in replacement for >> RSA Signature that removes the restriction on the size of the input data to >> be signed but not the requirement for it to be buffered. Most packaging >> formats end up being a signature over a small chunk of static data which in >> the case of streamed content are virtually always reference to external >> data. >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > --001a113fd398a423700546e14dfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As I have not seen any co= mments on that, should we consider that we have a rough consensus ?
If you believe that is not the appropriate way to close this thread,= please raise your opinion by the end of the week.

Yours,
Daniel=C2=A0

On Tue, Jan 17, 2017 at 4:14 PM, Daniel Migault <da= niel.migault@ericsson.com> wrote:
Hi,

So it is not clear to me= whether we have found consensus on that thread.

My understan= ding is that there is not a clear consensus that pre-hash version of EdDSA = MUST NOT be used by CA.

Would it help moving the document forward b= y:
=C2=A0 =C2=A0 - 1) enabling CA to use these versions in Section 5 and= ,
=C2=A0 =C2=A0 - 2) bring the discussion of pre-hash usage by CA in the= Security consideration section.

Yours,
Daniel
<= div>
=C2=A0


On Thu, Dec 15, 2016 at 11:3= 3 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote= :
It look= s to me as if in effect the prehash vs pure issue is going to settle out in= to a situation where all signatures are pure signatures at the specificatio= n level with an additional hash being introduced in the packaging layer whe= re bulk data is involved.

I have implemented most of the popular packaging formats and most of my AP= I calls internally turn out to be for a 'sign and digest' operation= rather than Sign-this-digest. Most cases the bulk data is being put throug= h a digest that is then put into some other structure for signature. There = is almost always some sort of metadata you want in there in addition to the= content.

<= /div>
Another way to = look at this is that Ed255x is a drop in replacement for RSA Signature that= removes the restriction on the size of the input data to be signed but not= the requirement for it to be buffered. Most packaging formats end up being= a signature over a small chunk of static data which in the case of streame= d content are virtually always reference to external data.


_____________________________________= __________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--001a113fd398a423700546e14dfb-- From nobody Wed Jan 25 09:21:27 2017 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 C687E129AA1 for ; Wed, 25 Jan 2017 09:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCAE9O5LqyBq for ; Wed, 25 Jan 2017 09:21:24 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81AC5129A2D for ; Wed, 25 Jan 2017 09:21:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B4CE630044B for ; Wed, 25 Jan 2017 12:21:23 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PDXI6KYx7Q94 for ; Wed, 25 Jan 2017 12:21:22 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A240C300249 for ; Wed, 25 Jan 2017 12:21:22 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2017 12:21:22 -0500 References: To: curdle@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Curdle] IANA assignments for draft-ietf-curdle-cms-chacha20-poly1305-06 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 Jan 2017 17:21:26 -0000 Just to keep the CURDLE WG in the loop... IANA made two assignments for this document. ACTION 1: The IANA Services Operator has added the following entry to the SMI = Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry: 18 id-alg-AEADChaCha20Poly1305 = [RFC-ietf-curdle-cms-chacha20-poly1305-06] ACTION 2: The IANA Services Operator has added the following entry to the SMI = Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) = registry: 66 id-mod-CMS-AEADChaCha20Poly1305 = [RFC-ietf-curdle-cms-chacha20-poly1305-06] Based on these assignments, the text in Section 4 also needed to be = updated. I sent the message below to the RFC Editor to accomplish that. Russ Begin forwarded message: > From: Russ Housley > Subject: Re: [RFC State] = has been added to the RFC Editor database > Date: January 25, 2017 at 11:12:40 AM EST > To: RFC Editor > Cc: "Salz, Rich" , Daniel Migault = , Stephen Farrell = >=20 > Dear RFC Editor: >=20 > IANA has just assigned the object identifiers for this document. As a = result, the text in Section 4 needs to be updated. >=20 > OLD: >=20 > 30 0c 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? >=20 > {{{ Correct above after IANA assigns the object identifier. }}} >=20 > NEW: >=20 > 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 12 >=20 > NOTE: This changes more than just the question marks. >=20 > Thanks, > Russ From nobody Thu Jan 26 13:06:00 2017 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 0D533129B9A; Thu, 26 Jan 2017 13:05:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148546475604.26943.4793998710816349936.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2017 13:05:56 -0800 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 21:05:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-eddsa-signatures-03.txt Pages : 8 Date : 2017-01-26 Abstract: This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatures-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 26 13:10:41 2017 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 18308129B8B for ; Thu, 26 Jan 2017 13:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKK18VNMXpiy for ; Thu, 26 Jan 2017 13:10:38 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE082129B3E for ; Thu, 26 Jan 2017 13:10:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 365603002AD for ; Thu, 26 Jan 2017 16:10:38 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id K_agvULpCt66 for ; Thu, 26 Jan 2017 16:10:36 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C3ECE300157 for ; Thu, 26 Jan 2017 16:10:36 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148546475604.26943.4793998710816349936.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2017 16:09:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <74E4544F-C4DC-4ABB-8B89-9CA38164D40F@vigilsec.com> References: <148546475604.26943.4793998710816349936.idtracker@ietfa.amsl.com> To: curdle@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-03.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 21:10:40 -0000 This is the big change in the document: OLD: id-shake256-len OBJECT IDENTIFIER ::=3D { hashAlgs 13 } NEW: id-shake256-len OBJECT IDENTIFIER ::=3D { hashAlgs 18 } NIST has posted the object identifier assignments on their website = , = and this correction is to align with the assignment that was actually = made. Russ On Jan 26, 2017, at 4:05 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-eddsa-signatures-03.txt > Pages : 8 > Date : 2017-01-26 >=20 > Abstract: > This document specifies the conventions for using Edwards-curve > Digital Signature Algorithm (EdDSA) for Curve25519 and Curve448 in > the Cryptographic Message Syntax (CMS). For each curve, EdDSA > defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA > mode is not used with the CMS. In addition, no context string is > used with the CMS. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 27 03:20:41 2017 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 AAEC21294AC for ; Fri, 27 Jan 2017 03:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.101 X-Spam-Level: X-Spam-Status: No, score=-10.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 EWTxLIf6CuWN for ; Fri, 27 Jan 2017 03:20:38 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F3A1294A4 for ; Fri, 27 Jan 2017 03:20:38 -0800 (PST) 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 4FA0BC04BD4A for ; Fri, 27 Jan 2017 11:20:39 +0000 (UTC) Received: from ovpn-204-202.brq.redhat.com (ovpn-204-202.brq.redhat.com [10.40.204.202]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0RBKaLc016404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 27 Jan 2017 06:20:38 -0500 Message-ID: <1485516034.3144.11.camel@redhat.com> From: Nikos Mavrogiannopoulos To: curdle@ietf.org Date: Fri, 27 Jan 2017 12:20:34 +0100 In-Reply-To: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.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.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 27 Jan 2017 11:20:39 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Some work for the group 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, 27 Jan 2017 11:20:39 -0000 On Tue, 2017-01-24 at 20:39 -0500, Daniel Migault wrote: > Hi,  > > As I have not seen any comments on that, should we consider that we > have a rough consensus ? > If you believe that is not the appropriate way to close this thread, > please raise your opinion by the end of the week.  I'm certainly fine with that. regards, Nikos From nobody Sat Jan 28 21:40:23 2017 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 85ADA129412 for ; Sat, 28 Jan 2017 21:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ammv59NYYQd8 for ; Sat, 28 Jan 2017 21:40:21 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E678129400 for ; Sat, 28 Jan 2017 21:40:21 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id j18so87949408ioe.2 for ; Sat, 28 Jan 2017 21:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jYhiyv9H+5xncKl701UtNzj61ug9+fuA/JcGenxlh+Y=; b=P9HpIkmre/QcFq29h89uUrmsmYG1giBjkqlEjU87gorFgRBm9XxJ8DH7jT0Zwweb7Q 8LjRXKzL3kwPp+Zp8CLkTJOLekQcWOvOngXDcPyUSf75un2cxDf0SXrw8uqCNg6FZn+W QKdf/MIa4rbovGWZ7Q4xdxVh5IjLQpqZgrOSx16wB8aOpWI5BpojpzbOzgZgeHeFEHtQ O200KSenqyOwn412M26p1xTSwOfjwfcaUL/DCrYX0MJkzDJpeZq1g9GN5hMHMw7Rry8B +RSefg4ZwYzR1IsyStPCCdel5/8ABC0pZBK0ozcwPBRbd4wD6ANj5wEcsMESGEgGdZiW kjOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jYhiyv9H+5xncKl701UtNzj61ug9+fuA/JcGenxlh+Y=; b=i+Pkh51UnJOYiXYJ636fiQLUa/rbcz2SNwtHoB5FFOs6lrw/6fG9vDM74j1uJ5ATlB k9UixhEwmrd3Rx9UKb2U9CvXrQb0LnyP5eXMMqQvMAXDfl3YW/57Us3uRrHciMBOR/b1 DTRyBuS85k+3phjVA4RXldrNyFXlh4J15dXOj02ZBoaNGqk28xleAfZMusbTiUlqxlPo +FQqB3F7plBsv7KikfsJcfLcaOJHOuRvpzfBIVwQ7c0tBy3zcQKVNBBDNiyc7EjB2jeE r8DDqv56Ua1Ef2DetLfr0WPfSNHC19d1KBM1+pDvqt2WBc31Lqx/I2Tl2WffH0YSWjBu +V1w== X-Gm-Message-State: AIkVDXIlcdBtgioplzU5UklNTSCt468yTVYvmBZBXwAoenp7KAi9UHbdpdPqj2Dg8nGa6pn4hdnOGTz6WOjM1w== X-Received: by 10.107.162.194 with SMTP id l185mr15475680ioe.184.1485668420673; Sat, 28 Jan 2017 21:40:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.65.206 with HTTP; Sat, 28 Jan 2017 21:40:20 -0800 (PST) In-Reply-To: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.camel@redhat.com> From: Brian Smith Date: Sat, 28 Jan 2017 19:40:20 -1000 Message-ID: To: Daniel Migault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Curdle , Phillip Hallam-Baker , "Salz, Rich" , Jim Schaad , "Dang, Quynh \(Fed\)" , Nikos Mavrogiannopoulos Subject: Re: [Curdle] Some work for the group 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: Sun, 29 Jan 2017 05:40:22 -0000 Daniel Migault wrote: > So it is not clear to me whether we have found consensus on that thread. > > My understanding is that there is not a clear consensus that pre-hash > version of EdDSA MUST NOT be used by CA. > > Would it help moving the document forward by: > - 1) enabling CA to use these versions in Section 5 and, > - 2) bring the discussion of pre-hash usage by CA in the Security > consideration section. I disagree that there's any kind of consensus to make that change. Besides the security issue, my understanding is that using the prehash variant would result in lots of interop failures as, AFAICT, there isn't going to be much support for it in verification libraries. Is there a list of implementations for this draft? Cheers, Brian From nobody Sun Jan 29 02:32:38 2017 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 6C79F12944E for ; Sun, 29 Jan 2017 02:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.121 X-Spam-Level: X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 NP4PoTSCqrij for ; Sun, 29 Jan 2017 02:32:36 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A7C12944A for ; Sun, 29 Jan 2017 02:32:36 -0800 (PST) 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 69E834E4E6; Sun, 29 Jan 2017 10:32:36 +0000 (UTC) Received: from ovpn-204-49.brq.redhat.com (ovpn-204-49.brq.redhat.com [10.40.204.49]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0TAWVcN015444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Jan 2017 05:32:33 -0500 Message-ID: <1485685950.1687.1.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Brian Smith , Daniel Migault Date: Sun, 29 Jan 2017 11:32:30 +0100 In-Reply-To: References: <1481295892.20432.16.camel@redhat.com> <0e1701d254c6$46509670$d2f1c350$@augustcellars.com> <1481788992.2779.15.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.38]); Sun, 29 Jan 2017 10:32:36 +0000 (UTC) Archived-At: Cc: "Dang, Quynh \(Fed\)" , "Salz, Rich" , Jim Schaad , Phillip Hallam-Baker , Curdle Subject: Re: [Curdle] Some work for the group 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: Sun, 29 Jan 2017 10:32:37 -0000 On Sat, 2017-01-28 at 19:40 -1000, Brian Smith wrote: > Daniel Migault wrote: > > So it is not clear to me whether we have found consensus on that > > thread. > > > > My understanding is that there is not a clear consensus that pre- > > hash > > version of EdDSA MUST NOT be used by CA. > > > > Would it help moving the document forward by: > >     - 1) enabling CA to use these versions in Section 5 and, > >     - 2) bring the discussion of pre-hash usage by CA in the > > Security > > consideration section. > > I disagree that there's any kind of consensus to make that change. > > Besides the security issue, my understanding is that using the > prehash > variant would result in lots of interop failures as, AFAICT, there > isn't going to be much support for it in verification libraries. Isn't that orthogonal to the question? If the prehash version is going to cause interop issues is not affected by the text quoted above. Your comment is on whether including the prehashed version at all. regards, Nikos