Hi, There is a thread on the SAAG list about possibly handling drafts like this in a new WG: https://mailarchive.ietf.org/arch/search/?email_list=saag
That's an option too. Kathleen On Tue, Nov 10, 2015 at 12:55 PM, Ilari Liusvaara <[email protected]> wrote: > I cooked up a pre-draft (already circulated privately) about using CFRG > ECC work in JOSE. Encompasses both ECDH and signatures. > > > Comments (before I attempt to submit this as an I-D)? > > > ----------------------------------------------------------------------- > Network Working Group I. Liusvaara > Internet-Draft Independent > Intended status: Standards Track October 17, 2015 > Expires: April 19, 2016 > > > CFRG curves and signatures in JOSE > draft-liusvaara-jose-cfrg-curves > > Abstract > > This document defines how to use curves and algorithms from IRTF CFRG > elliptic curves work (Diffie-Hellman and signatures) in JOSE. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on April 19, 2016. > > Copyright Notice > > Copyright (c) 2015 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > > > > Liusvaara Expires April 19, 2016 [Page 1] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 2 > 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 3 > 2.1.1. Curves . . . . . . . . . . . . . . . . . . . . . . . 3 > 2.1.2. Algorithms . . . . . . . . . . . . . . . . . . . . . 3 > 2.1.3. Signing . . . . . . . . . . . . . . . . . . . . . . . 4 > 2.1.4. Verification . . . . . . . . . . . . . . . . . . . . 4 > 2.2. ECDH-ES . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2.2.1. Parameters . . . . . . . . . . . . . . . . . . . . . 4 > 2.2.2. Performing the ECDH operation . . . . . . . . . . . . 5 > 3. Security considerations . . . . . . . . . . . . . . . . . . . 5 > 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 > 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 > 6.2. Informative References . . . . . . . . . . . . . . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 > > 1. Introduction > > Internet Research Task Force (IRTF) Crypto Forum Research Group > (CFRG) selected new elliptic curves and signature algorithms for > asymmetric key cryptography. This document defines how those curves > and algorithms are to be used in JOSE in interoperable manner. > > This extends [RFC7517] and [RFC7518] > > 1.1. Requirements Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > 1.2. Notation > > All inputs to and outputs from the the ECDH and signature functions > are defined to be octet strings, with the exception of output of > verfication function, which is a boolean. > > 2. Algorithms > > > > > > > > Liusvaara Expires April 19, 2016 [Page 2] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > 2.1. Signatures > > 2.1.1. Curves > > The following curves are defined for the algorithms are defined here > (to be applied as values of "crv" parameter): > > crv value: The curve: > E255 Edwards25519 > E448 Edwards448 > > For each of these curves: > > 1. The parameter "kty" MUST be "EC". > > 2. The parameter "crv" MUST be set to appropriate value. > > 3. The parameter "alg" MUST be set to appropriate value. > > 4. The parameter "x" is the base64url [RFC4648] encoded public key > octet string (note: this is not the same as sec1 encoding). This > MUST be present for both public and private keys. > > 5. The parameter "y" MUST NOT be present. These curves only have > one public key component. > > 6. The parameter "d" is the base64url encoded private key octet > string. This MUST be present for private keys, and MUST NOT be > present for public keys. > > 7. These curves MUST NOT be used for ECDH-ES. > > 8. If key is private key, and thus both "x" and "d" are present, > then "x" MUST be the public key corresponding to private key "d". > > 2.1.2. Algorithms > > The following signature algorithms are defined here (to be applied as > values of "alg" parameter): > > alg value: crv: The algorithm: > Ed25519 E255 Ed25519 > Ed25519ph E255 Ed25519ph > Ed448 E448 Ed448 > Ed448ph E448 Ed448ph > > > > > > > Liusvaara Expires April 19, 2016 [Page 3] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > The key type for these algorithms MUST be "EC", "alg" parameter MUST > be present and "crv" parameter MUST match the indicated one for each > algorithm. > > 2.1.3. Signing > > Signing for these is preformed by applying the signing algorithm > defined in [I-D.irtf-cfrg-eddsa] to the private key (as private key), > public key (as public key) and the JWS Signing Input (as message). > The resulting signature is the JWS Signature value. All inputs and > outputs are octet strings. > > 2.1.4. Verification > > Verification is performed by applying the verification algorithm > defined in [I-D.irtf-cfrg-eddsa] to the public key (as public key), > the JWS Signing Input (as message) and the JWS Signature value (as > signature). All inputs are octet strings. If the algorithm accepts, > the signature is valid, otherwise it is invalid. > > 2.2. ECDH-ES > > The following curves are defined for the algorithms are defined here > (to be applied as values of "crv" parameter): > > crv value: The curve: > X255 X25519 > X448 X448 > > The key type used with these keys is "EC". > > These curves MUST NOT be used for signatures. > > 2.2.1. Parameters > > For each of these curves: > > 1. The "x" parameter is base64url encoding of point octet string > (note: This is not SEC1 encoding). This parameter MUST be > present in both public and private keys. > > 2. The "y" parameter MUST NOT be present. These functions only have > one public key component. > > 3. The "d" parameter is base64url encoding of scalar octet string. > This parameter MUST be present in private keys, and it MUST NOT > be present in public keys. > > > > > Liusvaara Expires April 19, 2016 [Page 4] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > 4. If key is private key, and thus both "x" and "d" are present, > then "x" MUST be the output of applying ECDH function to the > value of "d" (as scalar input) and the standard basepoint (as > u-coordinate input). > > 2.2.2. Performing the ECDH operation > > The "x" parameter of "epk" field is set as follows: > > Apply the appropriate ECDH function to the ephemeral private key (as > scalar input) and the standard basepoint (as u-coordinate input). > The output is the value for "x" parameter of "epk" field. All inputs > and outputs are octet strings. > > The Z value (raw key agreement output) for key agreement is > determined as follows: > > Apply the appropriate ECDH function to the ephemeral private key (as > scalar input) and receiver public key (as u-coordinate input). The > output is the Z value. All inputs and outputs are octet strings. > > 3. Security considerations > > Security considerations from [I-D.irtf-cfrg-curves] and > [I-D.irtf-cfrg-eddsa] apply here. > > The same key MUST NOT be used with multiple algorithms, since some of > the algorithms defined here interact in bad ways. For this reason > "alg" parameters for signature keys are REQUIRED. > > Do not assume that signature also binds the key used for signing, it > does not (there are also other widespread signature algorithms where > this binding fails, as such binding is not part of the definition of > secure signature primitive). As an example of such failure, the > Ed25519ph signature of X under key (Ed25519ph,Y) is identical to > Ed25519 signature of SHA512(X) under key (Ed25519,Y). And often it > takes only setting a few bits of message (easy to do by brute force) > to make the message valid enough to be processed in some very > surprising way. > > If key generation or batch signature verification is performed, a > well-seed cryptographical random number generator is REQUIRED. > Signing and non-batch signature verification are deterministic > operations do not need random numbers of any kind. > > > > > > > > Liusvaara Expires April 19, 2016 [Page 5] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > 4. Acknowledgements > > Mike Jones for comments on initial pre-draft. > > 5. IANA considerations > > The following is added to JSON Web Signature and Encryption > Algorithms Registry: > > o Algorithm Name: "Ed25519" > > o Algorithm Description: Ed25519 signature algorithm > > o Algorithm Usage Location(s): "alg" > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > o Specification Document(s): Section 2.1 of [RFC-THIS] > > o Algorithm Analysis Documents(s): n/a > > > o Algorithm Name: "Ed25519ph" > > o Algorithm Description: Ed25519 signature algorithm with prehash > > o Algorithm Usage Location(s): "alg" > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > o Specification Document(s): Section 2.1 of [RFC-THIS] > > o Algorithm Analysis Documents(s): n/a > > > o Algorithm Name: "Ed448" > > o Algorithm Description: Ed448 signature algorithm > > o Algorithm Usage Location(s): "alg" > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > > > Liusvaara Expires April 19, 2016 [Page 6] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > o Specification Document(s): Section 2.1 of [RFC-THIS] > > o Algorithm Analysis Documents(s): n/a > > > o Algorithm Name: "Ed448ph" > > o Algorithm Description: Ed448 signature algorithm with prehash > > o Algorithm Usage Location(s): "alg" > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > o Specification Document(s): Section 2.1 of [RFC-THIS] > > o Algorithm Analysis Documents(s): n/a > > > The following is added to JSON Web Key Elliptic Curve Registry: > > o Curve Name: "X25519" > > o Curve Description: The X25519 function > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > o Specification Document(s): Section 2.2 of [RFC-THIS] > > > o Curve Name: "X448" > > o Curve Description: The X448 function > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > o Specification Document(s): Section 2.2 of [RFC-THIS] > > > o Curve Name: "Ed25519" > > o Curve Description: The Edwards25519 curve > > > > > Liusvaara Expires April 19, 2016 [Page 7] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > o Specification Document(s): Section 2.1 of [RFC-THIS] > > > o Curve Name: "Ed448" > > o Curve Description: The Edwards448 curve > > o JOSE Implementation Requirements: Optional > > o Change Controller: IESG > > o Specification Document(s): Section 2.2 of [RFC-THIS] > > > 6. References > > 6.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ > RFC2119, March 1997, > <http://www.rfc-editor.org/info/rfc2119>. > > [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data > Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, > <http://www.rfc-editor.org/info/rfc4648>. > > [I-D.irtf-cfrg-curves] > Langley, A. and M. Hamburg, "Elliptic Curves for > Security", draft-irtf-cfrg-curves-09 (work in progress), > September 2015. > > [I-D.irtf-cfrg-eddsa] > Josefsson, S. and I. Liusvaara, "Edwards-curve Digital > Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-00 > (work in progress), October 2015. > > 6.2. Informative References > > [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/ > RFC7517, May 2015, > <http://www.rfc-editor.org/info/rfc7517>. > > > > > > Liusvaara Expires April 19, 2016 [Page 8] > > Internet-Draft CFRG curves and signatures in JOSE October 2015 > > > [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI > 10.17487/RFC7518, May 2015, > <http://www.rfc-editor.org/info/rfc7518>. > > Author's Address > > Ilari Liusvaara > Independent > > Email: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Liusvaara Expires April 19, 2016 [Page 9] > > ----------------------------------------------------------------------- > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
