draft-ietf-jose-json-web-algorithms-36.txt   draft-ietf-jose-json-web-algorithms-37.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track October 24, 2014 Intended status: Standards Track November 19, 2014
Expires: April 27, 2015 Expires: May 23, 2015
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-36 draft-ietf-jose-json-web-algorithms-37
Abstract Abstract
The JSON Web Algorithms (JWA) specification registers cryptographic The JSON Web Algorithms (JWA) specification registers cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK)
specifications. It defines several IANA registries for these specifications. It defines several IANA registries for these
identifiers. identifiers.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2015. This Internet-Draft will expire on May 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 25 skipping to change at page 4, line 25
Cross-Reference . . . . . . . . . . . . . . . . . . . . . 57 Cross-Reference . . . . . . . . . . . . . . . . . . . . . 57
A.2. Key Management Algorithm Identifier Cross-Reference . . . 57 A.2. Key Management Algorithm Identifier Cross-Reference . . . 57
A.3. Content Encryption Algorithm Identifier Cross-Reference . 58 A.3. Content Encryption Algorithm Identifier Cross-Reference . 58
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 59 Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 59
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 60 B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 60
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 61 B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 61
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 62 B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 62
Appendix C. Example ECDH-ES Key Agreement Computation . . . . . . 63 Appendix C. Example ECDH-ES Key Agreement Computation . . . . . . 63
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 65 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 65
Appendix E. Document History . . . . . . . . . . . . . . . . . . 66 Appendix E. Document History . . . . . . . . . . . . . . . . . . 66
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
The JSON Web Algorithms (JWA) specification registers cryptographic The JSON Web Algorithms (JWA) specification registers cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK) (JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK)
[JWK] specifications. It defines several IANA registries for these [JWK] specifications. It defines several IANA registries for these
identifiers. All these specifications utilize JavaScript Object identifiers. All these specifications utilize JavaScript Object
Notation (JSON) [RFC7159] based data structures. This specification Notation (JSON) [RFC7159] based data structures. This specification
also describes the semantics and operations that are specific to also describes the semantics and operations that are specific to
skipping to change at page 18, line 30 skipping to change at page 18, line 30
This is set to the number of bits in the desired output key. For This is set to the number of bits in the desired output key. For
"ECDH-ES", this is length of the key used by the "enc" algorithm. "ECDH-ES", this is length of the key used by the "enc" algorithm.
For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this
is 128, 192, and 256, respectively. is 128, 192, and 256, respectively.
AlgorithmID AlgorithmID
The AlgorithmID value is of the form Datalen || Data, where Data The AlgorithmID value is of the form Datalen || Data, where Data
is a variable-length string of zero or more octets, and Datalen is is a variable-length string of zero or more octets, and Datalen is
a fixed-length, big endian 32 bit counter that indicates the a fixed-length, big endian 32 bit counter that indicates the
length (in octets) of Data. In the Direct Key Agreement case, length (in octets) of Data. In the Direct Key Agreement case,
Data is set to the octets of the UTF-8 representation of the "enc" Data is set to the octets of the ASCII representation of the "enc"
Header Parameter value. In the Key Agreement with Key Wrapping Header Parameter value. In the Key Agreement with Key Wrapping
case, Data is set to the octets of the UTF-8 representation of the case, Data is set to the octets of the ASCII representation of the
"alg" Header Parameter value. "alg" Header Parameter value.
PartyUInfo PartyUInfo
The PartyUInfo value is of the form Datalen || Data, where Data is The PartyUInfo value is of the form Datalen || Data, where Data is
a variable-length string of zero or more octets, and Datalen is a a variable-length string of zero or more octets, and Datalen is a
fixed-length, big endian 32 bit counter that indicates the length fixed-length, big endian 32 bit counter that indicates the length
(in octets) of Data. If an "apu" (agreement PartyUInfo) Header (in octets) of Data. If an "apu" (agreement PartyUInfo) Header
Parameter is present, Data is set to the result of base64url Parameter is present, Data is set to the result of base64url
decoding the "apu" value and Datalen is set to the number of decoding the "apu" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to octets in Data. Otherwise, Datalen is set to 0 and Data is set to
skipping to change at page 32, line 14 skipping to change at page 32, line 14
6.3.2.7. "oth" (Other Primes Info) Parameter 6.3.2.7. "oth" (Other Primes Info) Parameter
The "oth" (other primes info) member contains an array of information The "oth" (other primes info) member contains an array of information
about any third and subsequent primes, should they exist. When only about any third and subsequent primes, should they exist. When only
two primes have been used (the normal case), this parameter MUST be two primes have been used (the normal case), this parameter MUST be
omitted. When three or more primes have been used, the number of omitted. When three or more primes have been used, the number of
array elements MUST be the number of primes used minus two. For more array elements MUST be the number of primes used minus two. For more
information on this case, see the description of the OtherPrimeInfo information on this case, see the description of the OtherPrimeInfo
parameters in Section A.1.2 of RFC 3447 [RFC3447], upon which the parameters in Section A.1.2 of RFC 3447 [RFC3447], upon which the
following parameters are modelled. Each array element MUST be an following parameters are modelled. If the consumer of a JWK does not
object with the following members: support private keys with more than two primes and it encounters a
private key that includes the "oth" parameter, then it MUST either
reject the key or ignore all the private key parameters other than
"d". Each array element MUST be an object with the following
members:
6.3.2.7.1. "r" (Prime Factor) 6.3.2.7.1. "r" (Prime Factor)
The "r" (prime factor) parameter within an "oth" array member The "r" (prime factor) parameter within an "oth" array member
represents the value of a subsequent prime factor. It is represented represents the value of a subsequent prime factor. It is represented
as a Base64urlUInt encoded value. as a Base64urlUInt encoded value.
6.3.2.7.2. "d" (Factor CRT Exponent) 6.3.2.7.2. "d" (Factor CRT Exponent)
The "d" (Factor CRT Exponent) parameter within an "oth" array member The "d" (Factor CRT Exponent) parameter within an "oth" array member
skipping to change at page 33, line 19 skipping to change at page 33, line 19
Values are registered on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC5226] basis
after a three-week review period on the jose-reg-review@ietf.org after a three-week review period on the jose-reg-review@ietf.org
mailing list, on the advice of one or more Designated Experts. mailing list, on the advice of one or more Designated Experts.
However, to allow for the allocation of values prior to publication, However, to allow for the allocation of values prior to publication,
the Designated Expert(s) may approve registration once they are the Designated Expert(s) may approve registration once they are
satisfied that such a specification will be published. satisfied that such a specification will be published.
Registration requests must be sent to the jose-reg-review@ietf.org Registration requests must be sent to the jose-reg-review@ietf.org
mailing list for review and comment, with an appropriate subject mailing list for review and comment, with an appropriate subject
(e.g., "Request for access token type: example"). (e.g., "Request to register algorithm: example").
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the longer than 21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution. iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Expert(s) includes Criteria that should be applied by the Designated Expert(s) includes
skipping to change at page 35, line 5 skipping to change at page 35, line 5
time as the cryptographic landscape evolves, for instance, to change time as the cryptographic landscape evolves, for instance, to change
the status of an algorithm to Deprecated, or to change the status of the status of an algorithm to Deprecated, or to change the status of
an algorithm from Optional to Recommended+ or Required. Changes of an algorithm from Optional to Recommended+ or Required. Changes of
implementation requirements are only permitted on a Specification implementation requirements are only permitted on a Specification
Required basis after review by the Designated Experts(s), with the Required basis after review by the Designated Experts(s), with the
new specification defining the revised implementation requirements new specification defining the revised implementation requirements
level. level.
7.1.1. Registration Template 7.1.1. Registration Template
Algorithm Name: Algorithm Name:
The name requested (e.g., "HS256"). This name is case-sensitive. The name requested (e.g., "HS256"). This name is a case-sensitive
Names may not match other registered names in a case-insensitive ASCII string. Names may not match other registered names in a
manner unless the Designated Expert(s) state that there is a case-insensitive manner unless the Designated Expert(s) state that
compelling reason to allow an exception in this particular case. there is a compelling reason to allow an exception in this
particular case.
Algorithm Description: Algorithm Description:
Brief description of the Algorithm (e.g., "HMAC using SHA-256"). Brief description of the Algorithm (e.g., "HMAC using SHA-256").
Algorithm Usage Location(s): Algorithm Usage Location(s):
The algorithm usage location. This must be one or more of the The algorithm usage location. This must be one or more of the
values "alg" or "enc" if the algorithm is to be used with JWS or values "alg" or "enc" if the algorithm is to be used with JWS or
JWE. The value "JWK" is used if the algorithm identifier will be JWE. The value "JWK" is used if the algorithm identifier will be
used as a JWK "alg" member value, but will not be used with JWS or used as a JWK "alg" member value, but will not be used with JWS or
JWE; this could be the case, for instance, for non-authenticated JWE; this could be the case, for instance, for non-authenticated
skipping to change at page 53, line 15 skipping to change at page 53, line 15
[Boneh99] "Twenty years of attacks on the RSA cryptosystem", Notices [Boneh99] "Twenty years of attacks on the RSA cryptosystem", Notices
of the American Mathematical Society (AMS), Vol. 46, No. of the American Mathematical Society (AMS), Vol. 46, No.
2, pp. 203-213 http://crypto.stanford.edu/~dabo/pubs/ 2, pp. 203-213 http://crypto.stanford.edu/~dabo/pubs/
papers/RSA-survey.pdf, 1999. papers/RSA-survey.pdf, 1999.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4, July 2013. Signature Standard (DSS)", FIPS PUB 186-4, July 2013.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress), draft-ietf-jose-json-web-encryption (work in progress),
October 2014. November 2014.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), draft-ietf-jose-json-web-key (work in progress),
October 2014. November 2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), October 2014. in progress), November 2014.
[NIST.800-38A] [NIST.800-38A]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation", "Recommendation for Block Cipher Modes of Operation",
NIST PUB 800-38A, December 2001. NIST PUB 800-38A, December 2001.
[NIST.800-38D] [NIST.800-38D]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,
skipping to change at page 54, line 43 skipping to change at page 54, line 43
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", Version 2.0, May 2009. Elliptic Curve Cryptography", Version 2.0, May 2009.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, March 2012. Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
10.2. Informative References 10.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[I-D.ietf-precis-saslprepbis] [I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation, Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", Representing Usernames and Passwords",
draft-ietf-precis-saslprepbis-09 (work in progress), draft-ietf-precis-saslprepbis-09 (work in progress),
skipping to change at page 64, line 36 skipping to change at page 64, line 36
38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121,
140, 254, 144, 196]. 140, 254, 144, 196].
keydatalen keydatalen
This value is 128 - the number of bits in the desired output key This value is 128 - the number of bits in the desired output key
(because "A128GCM" uses a 128 bit key). (because "A128GCM" uses a 128 bit key).
AlgorithmID AlgorithmID
This is set to the octets representing the 32 bit big endian value This is set to the octets representing the 32 bit big endian value
7 - [0, 0, 0, 7] - the number of octets in the AlgorithmID content 7 - [0, 0, 0, 7] - the number of octets in the AlgorithmID content
"A128GCM", followed, by the octets representing the UTF-8 string "A128GCM", followed, by the octets representing the ASCII string
"A128GCM" - [65, 49, 50, 56, 71, 67, 77]. "A128GCM" - [65, 49, 50, 56, 71, 67, 77].
PartyUInfo PartyUInfo
This is set to the octets representing the 32 bit big endian value This is set to the octets representing the 32 bit big endian value
5 - [0, 0, 0, 5] - the number of octets in the PartyUInfo content 5 - [0, 0, 0, 5] - the number of octets in the PartyUInfo content
"Alice", followed, by the octets representing the UTF-8 string "Alice", followed, by the octets representing the UTF-8 string
"Alice" - [65, 108, 105, 99, 101]. "Alice" - [65, 108, 105, 99, 101].
PartyVInfo PartyVInfo
This is set to the octets representing the 32 bit big endian value This is set to the octets representing the 32 bit big endian value
skipping to change at page 66, line 29 skipping to change at page 66, line 29
Jim Schaad, Hannes Tschofenig, and Sean Turner. Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors during the creation of this specification.
Appendix E. Document History Appendix E. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-37
o Restricted algorithm names to using only ASCII characters.
o Added language about ignoring private keys with an "oth" parameter
when the implementation does not support private keys with more
than two primes.
o Updated the example IANA registration request subject line.
-36 -36
o Moved the normative "alg":"none" security considerations text into o Moved the normative "alg":"none" security considerations text into
the algorithm definition. the algorithm definition.
o Specified that registration reviews occur on the o Specified that registration reviews occur on the
jose-reg-review@ietf.org mailing list. jose-reg-review@ietf.org mailing list.
-35 -35
 End of changes. 15 change blocks. 
22 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/