draft-ietf-jose-json-web-algorithms-15.txt   draft-ietf-jose-json-web-algorithms-16.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track September 3, 2013 Intended status: Standards Track September 15, 2013
Expires: March 7, 2014 Expires: March 19, 2014
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-15 draft-ietf-jose-json-web-algorithms-16
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 March 7, 2014. This Internet-Draft will expire on March 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terms Incorporated from the JWS Specification . . . . . . 5 2.1. Terms Incorporated from the JWS Specification . . . . . . 5
2.2. Terms Incorporated from the JWE Specification . . . . . . 6 2.2. Terms Incorporated from the JWE Specification . . . . . . 6
2.3. Terms Incorporated from the JWK Specification . . . . . . 9 2.3. Terms Incorporated from the JWK Specification . . . . . . 9
2.4. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 9
3. Cryptographic Algorithms for JWS . . . . . . . . . . . . . . . 9 3. Cryptographic Algorithms for Digital Signatures and MACs . . . 9
3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 9 3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 9
3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 10 3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 10
3.3. Digital Signature with RSASSA-PKCS1-V1_5 . . . . . . . . . 11 3.3. Digital Signature with RSASSA-PKCS1-V1_5 . . . . . . . . . 11
3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . . 12 3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . . 12
3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 14 3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 14
3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 15 3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 15
4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 15 4. Cryptographic Algorithms for Encryption . . . . . . . . . . . 15
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 15 4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 15
4.2. "enc" (Encryption Method) Header Parameter Values for 4.2. "enc" (Encryption Method) Header Parameter Values for
JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 21 4.3. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 21
4.4. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 21 4.4. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 21
4.5. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 21 4.5. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 21
4.6. Direct Encryption with a Shared Symmetric Key . . . . . . 21 4.6. Direct Encryption with a Shared Symmetric Key . . . . . . 21
4.7. Key Agreement with Elliptic Curve Diffie-Hellman 4.7. Key Agreement with Elliptic Curve Diffie-Hellman
Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 21 Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 22
4.7.1. Header Parameters Used for ECDH Key Agreement . . . . 22 4.7.1. Header Parameters Used for ECDH Key Agreement . . . . 22
4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 22 4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 22
4.7.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 22 4.7.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 23
4.7.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 23 4.7.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 23
4.7.2. Key Derivation for ECDH Key Agreement . . . . . . . . 23 4.7.2. Key Derivation for ECDH Key Agreement . . . . . . . . 23
4.8. Key Encryption with AES GCM . . . . . . . . . . . . . . . 24 4.8. Key Encryption with AES GCM . . . . . . . . . . . . . . . 24
4.8.1. Header Parameters Used for AES GCM Key Encryption . . 25 4.8.1. Header Parameters Used for AES GCM Key Encryption . . 25
4.8.1.1. "iv" (Initialization Vector) Header Parameter . . 25 4.8.1.1. "iv" (Initialization Vector) Header Parameter . . 25
4.8.1.2. "tag" (Authentication Tag) Header Parameter . . . 25 4.8.1.2. "tag" (Authentication Tag) Header Parameter . . . 25
4.9. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 25 4.9. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 25
4.9.1. Header Parameters Used for PBES2 Key Encryption . . . 25 4.9.1. Header Parameters Used for PBES2 Key Encryption . . . 26
4.9.1.1. "p2s" (PBES2 salt) Parameter . . . . . . . . . . . 25 4.9.1.1. "p2s" (PBES2 salt) Parameter . . . . . . . . . . . 26
4.9.1.2. "p2c" (PBES2 count) Parameter . . . . . . . . . . 26 4.9.1.2. "p2c" (PBES2 count) Parameter . . . . . . . . . . 26
4.10. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 26 4.10. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 26
4.10.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 26 4.10.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 27
4.10.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 27 4.10.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 27
4.10.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 27 4.10.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 27
4.10.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 28 4.10.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 29
4.10.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 29 4.10.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 29
4.10.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . . 29 4.10.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . . 30
4.10.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 30 4.10.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 30
4.10.6. Plaintext Encryption with AES_CBC_HMAC_SHA2 . . . . . 30 4.10.6. Plaintext Encryption with AES_CBC_HMAC_SHA2 . . . . . 30
4.11. Plaintext Encryption with AES GCM . . . . . . . . . . . . 30 4.11. Plaintext Encryption with AES GCM . . . . . . . . . . . . 31
5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 31 5. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 31
5.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 31 5.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 31
5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 32 5.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . . 32
5.2.1. JWK Parameters for Elliptic Curve Public Keys . . . . 32 5.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 32
5.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 32 5.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 32
5.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 32 5.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 33
5.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 32 5.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 33
5.2.2. JWK Parameters for Elliptic Curve Private Keys . . . . 32 5.2.2. Parameters for Elliptic Curve Private Keys . . . . . . 33
5.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 33 5.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 33
5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 33 5.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 33
5.3.1. JWK Parameters for RSA Public Keys . . . . . . . . . . 33 5.3.1. Parameters for RSA Public Keys . . . . . . . . . . . . 33
5.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 33 5.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 33
5.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 33 5.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 34
5.3.2. JWK Parameters for RSA Private Keys . . . . . . . . . 33 5.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 34
5.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 34 5.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 34
5.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 34 5.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 34
5.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 34 5.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 34
5.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 34 5.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 35
5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 34 5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 35
5.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 34 5.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 35
5.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 35 5.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 35
5.4. JWK Parameters for Symmetric Keys . . . . . . . . . . . . 35 5.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 36
5.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 35 5.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 36
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
6.1. JSON Web Signature and Encryption Algorithms Registry . . 36 6.1. JSON Web Signature and Encryption Algorithms Registry . . 37
6.1.1. Template . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.1. Template . . . . . . . . . . . . . . . . . . . . . . . 38
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 37 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 38
6.2. JSON Web Key Types Registry . . . . . . . . . . . . . . . 42 6.2. JWE Header Parameter Names Registration . . . . . . . . . 43
6.2.1. Registration Template . . . . . . . . . . . . . . . . 42 6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 43
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 43 6.3. JSON Web Encryption Compression Algorithms Registry . . . 44
6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 43 6.3.1. Registration Template . . . . . . . . . . . . . . . . 44
6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 43 6.3.2. Initial Registry Contents . . . . . . . . . . . . . . 45
6.4. Registration of JWE Header Parameter Names . . . . . . . . 45 6.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 45
6.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 45 6.4.1. Registration Template . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 6.4.2. Initial Registry Contents . . . . . . . . . . . . . . 46
7.1. Reusing Key Material when Encrypting Keys . . . . . . . . 47 6.5. JSON Web Key Parameters Registration . . . . . . . . . . . 46
7.2. Password Considerations . . . . . . . . . . . . . . . . . 47 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 46
8. Internationalization Considerations . . . . . . . . . . . . . 48 6.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . . 48
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.6.1. Registration Template . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . . 48 6.6.2. Initial Registry Contents . . . . . . . . . . . . . . 49
9.2. Informative References . . . . . . . . . . . . . . . . . . 50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 49
7.1. Algorithms and Key Sizes will be Deprecated . . . . . . . 50
7.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 50
7.3. RSAES-PKCS1-v1_5 Security Considerations . . . . . . . . . 50
7.4. AES GCM Security Considerations . . . . . . . . . . . . . 50
7.5. Plaintext JWS Security Considerations . . . . . . . . . . 51
7.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 51
7.7. Reusing Key Material when Encrypting Keys . . . . . . . . 52
7.8. Password Considerations . . . . . . . . . . . . . . . . . 52
8. Internationalization Considerations . . . . . . . . . . . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . . 53
9.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Digital Signature/MAC Algorithm Identifier Appendix A. Digital Signature/MAC Algorithm Identifier
Cross-Reference . . . . . . . . . . . . . . . . . . . 51 Cross-Reference . . . . . . . . . . . . . . . . . . . 56
Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 54 Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 57
Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 57 Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 58
C.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 58 C.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 59
C.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 59 C.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 60
C.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 60 C.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 61
Appendix D. Example ECDH-ES Key Agreement Computation . . . . . . 61 Appendix D. Example ECDH-ES Key Agreement Computation . . . . . . 62
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 63 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 64
Appendix F. Document History . . . . . . . . . . . . . . . . . . 64 Appendix F. Document History . . . . . . . . . . . . . . . . . . 65
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 72
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) [RFC4627] based data structures. This specification Notation (JSON) [RFC4627] 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 5, line 31 skipping to change at page 5, line 31
document. document.
Names defined by this specification are short because a core goal is Names defined by this specification are short because a core goal is
for the resulting representations to be compact. for the resulting representations to be compact.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in Key words for use in document are to be interpreted as described in Key words for use in
RFCs to Indicate Requirement Levels [RFC2119]. RFCs to Indicate Requirement Levels [RFC2119]. If these words are
used without being spelled in uppercase then they are to be
interpreted with their normal natural language meanings.
2. Terminology 2. Terminology
2.1. Terms Incorporated from the JWS Specification 2.1. Terms Incorporated from the JWS Specification
These terms defined by the JSON Web Signature (JWS) [JWS] These terms defined by the JSON Web Signature (JWS) [JWS]
specification are incorporated into this specification: specification are incorporated into this specification:
JSON Web Signature (JWS) A data structure representing a digitally JSON Web Signature (JWS) A data structure representing a digitally
signed or MACed message. The structure represents three values: signed or MACed message. The structure represents three values:
skipping to change at page 6, line 34 skipping to change at page 6, line 39
Encoded JWS Header Base64url encoding of the JWS Protected Header. Encoded JWS Header Base64url encoding of the JWS Protected Header.
Encoded JWS Payload Base64url encoding of the JWS Payload. Encoded JWS Payload Base64url encoding of the JWS Payload.
Encoded JWS Signature Base64url encoding of the JWS Signature. Encoded JWS Signature Base64url encoding of the JWS Signature.
JWS Signing Input The concatenation of the Encoded JWS Header, a JWS Signing Input The concatenation of the Encoded JWS Header, a
period ('.') character, and the Encoded JWS Payload. period ('.') character, and the Encoded JWS Payload.
Collision Resistant Namespace A namespace that allows names to be
allocated in a manner such that they are highly unlikely to
collide with other names. Examples of Collision Resistant
Namespaces include: Domain Names, Object Identifiers (OIDs) as
defined in the ITU-T X.660 and X.670 Recommendation series, and
Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an
administratively delegated namespace, the definer of a name needs
to take reasonable precautions to ensure they are in control of
the portion of the namespace they use to define the name.
2.2. Terms Incorporated from the JWE Specification 2.2. Terms Incorporated from the JWE Specification
These terms defined by the JSON Web Encryption (JWE) [JWE] These terms defined by the JSON Web Encryption (JWE) [JWE]
specification are incorporated into this specification: specification are incorporated into this specification:
JSON Web Encryption (JWE) A data structure representing an encrypted JSON Web Encryption (JWE) A data structure representing an encrypted
message. The structure represents five values: the JWE Header, message. The structure represents five values: the JWE Header,
the JWE Encrypted Key, the JWE Initialization Vector, the JWE the JWE Encrypted Key, the JWE Initialization Vector, the JWE
Ciphertext, and the JWE Authentication Tag. Ciphertext, and the JWE Authentication Tag.
skipping to change at page 9, line 33 skipping to change at page 9, line 29
Header Parameter A name/value pair that is member of a JWS Header or Header Parameter A name/value pair that is member of a JWS Header or
JWE Header. JWE Header.
Header Parameter Name The name of a member of a JSON object Header Parameter Name The name of a member of a JSON object
representing a JWS Header or JWE Header. representing a JWS Header or JWE Header.
Header Parameter Value The value of a member of a JSON object Header Parameter Value The value of a member of a JSON object
representing a JWS Header or JWE Header. representing a JWS Header or JWE Header.
3. Cryptographic Algorithms for JWS 3. Cryptographic Algorithms for Digital Signatures and MACs
JWS uses cryptographic algorithms to digitally sign or create a JWS uses cryptographic algorithms to digitally sign or create a
Message Authentication Codes (MAC) of the contents of the JWS Header Message Authentication Codes (MAC) of the contents of the JWS Header
and the JWS Payload. and the JWS Payload.
3.1. "alg" (Algorithm) Header Parameter Values for JWS 3.1. "alg" (Algorithm) Header Parameter Values for JWS
The table below is the set of "alg" (algorithm) header parameter The table below is the set of "alg" (algorithm) header parameter
values defined by this specification for use with JWS, each of which values defined by this specification for use with JWS, each of which
is explained in more detail in the following sections: is explained in more detail in the following sections:
skipping to change at page 10, line 34 skipping to change at page 10, line 34
| | hash algorithm | | | | hash algorithm | |
| PS256 | RSASSA-PSS using SHA-256 hash | Optional | | PS256 | RSASSA-PSS using SHA-256 hash | Optional |
| | algorithm and MGF1 mask generation | | | | algorithm and MGF1 mask generation | |
| | function with SHA-256 | | | | function with SHA-256 | |
| PS384 | RSASSA-PSS using SHA-384 hash | Optional | | PS384 | RSASSA-PSS using SHA-384 hash | Optional |
| | algorithm and MGF1 mask generation | | | | algorithm and MGF1 mask generation | |
| | function with SHA-384 | | | | function with SHA-384 | |
| PS512 | RSASSA-PSS using SHA-512 hash | Optional | | PS512 | RSASSA-PSS using SHA-512 hash | Optional |
| | algorithm and MGF1 mask generation | | | | algorithm and MGF1 mask generation | |
| | function with SHA-512 | | | | function with SHA-512 | |
| none | No digital signature or MAC value | Required | | none | No digital signature or MAC value | Optional |
| | included | | | | included | |
+-----------+--------------------------------------+----------------+ +-----------+--------------------------------------+----------------+
The use of "+" in the Implementation Requirements indicates that the The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of requirement strength is likely to be increased in a future version of
the specification. the specification.
See Appendix A for a table cross-referencing the digital signature See Appendix A for a table cross-referencing the digital signature
and MAC "alg" (algorithm) values used in this specification with the and MAC "alg" (algorithm) values used in this specification with the
equivalent identifiers used by other standards and software packages. equivalent identifiers used by other standards and software packages.
skipping to change at page 13, line 13 skipping to change at page 13, line 13
signature, respectively. signature, respectively.
The ECDSA P-256 SHA-256 digital signature is generated as follows: The ECDSA P-256 SHA-256 digital signature is generated as follows:
1. Generate a digital signature of the octets of the ASCII 1. Generate a digital signature of the octets of the ASCII
representation of the JWS Signing Input using ECDSA P-256 SHA-256 representation of the JWS Signing Input using ECDSA P-256 SHA-256
with the desired private key. The output will be the pair (R, with the desired private key. The output will be the pair (R,
S), where R and S are 256 bit unsigned integers. S), where R and S are 256 bit unsigned integers.
2. Turn R and S into octet sequences in big endian order, with each 2. Turn R and S into octet sequences in big endian order, with each
array being be 32 octets long. The array representations MUST array being be 32 octets long. The octet sequence
NOT be shortened to omit any leading zero octets contained in the representations MUST NOT be shortened to omit any leading zero
values. octets contained in the values.
3. Concatenate the two octet sequences in the order R and then S. 3. Concatenate the two octet sequences in the order R and then S.
(Note that many ECDSA implementations will directly produce this (Note that many ECDSA implementations will directly produce this
concatenation as their output.) concatenation as their output.)
4. Base64url encode the resulting 64 octet sequence. 4. Base64url encode the resulting 64 octet sequence.
The output is the Encoded JWS Signature for the JWS. The output is the Encoded JWS Signature for the JWS.
The ECDSA P-256 SHA-256 digital signature for a JWS is validated as The ECDSA P-256 SHA-256 digital signature for a JWS is validated as
skipping to change at page 15, line 10 skipping to change at page 15, line 10
Signing with the RSASSA-PSS SHA-384 and RSASSA-PSS SHA-512 algorithms Signing with the RSASSA-PSS SHA-384 and RSASSA-PSS SHA-512 algorithms
is performed identically to the procedure for RSASSA-PSS SHA-256 - is performed identically to the procedure for RSASSA-PSS SHA-256 -
just using the alternative hash algorithm in both roles. just using the alternative hash algorithm in both roles.
3.6. Using the Algorithm "none" 3.6. Using the Algorithm "none"
JWSs MAY also be created that do not provide integrity protection. JWSs MAY also be created that do not provide integrity protection.
Such a JWS is called a "Plaintext JWS". Plaintext JWSs MUST use the Such a JWS is called a "Plaintext JWS". Plaintext JWSs MUST use the
"alg" value "none", and are formatted identically to other JWSs, but "alg" value "none", and are formatted identically to other JWSs, but
with the empty string for its JWS Signature value. with the empty string for its JWS Signature value. See Section 7.5
for security considerations associated with using this algorithm.
4. Cryptographic Algorithms for JWE 4. Cryptographic Algorithms for Encryption
JWE uses cryptographic algorithms to encrypt the Content Encryption JWE uses cryptographic algorithms to encrypt the Content Encryption
Key (CEK) and the Plaintext. Key (CEK) and the Plaintext.
4.1. "alg" (Algorithm) Header Parameter Values for JWE 4.1. "alg" (Algorithm) Header Parameter Values for JWE
The table below is the set of "alg" (algorithm) header parameter The table below is the set of "alg" (algorithm) header parameter
values that are defined by this specification for use with JWE. values that are defined by this specification for use with JWE.
These algorithms are used to encrypt the CEK, producing the JWE These algorithms are used to encrypt the CEK, producing the JWE
Encrypted Key, or to use key agreement to agree upon the CEK. Encrypted Key, or to use key agreement to agree upon the CEK.
skipping to change at page 21, line 19 skipping to change at page 21, line 19
"RSA1_5" is used in this case. "RSA1_5" is used in this case.
A key of size 2048 bits or larger MUST be used with this algorithm. A key of size 2048 bits or larger MUST be used with this algorithm.
An example using this algorithm is shown in Appendix A.2 of [JWE]. An example using this algorithm is shown in Appendix A.2 of [JWE].
4.4. Key Encryption with RSAES OAEP 4.4. Key Encryption with RSAES OAEP
This section defines the specifics of encrypting a JWE CEK with RSAES This section defines the specifics of encrypting a JWE CEK with RSAES
using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with
the default parameters specified by RFC 3447 in Section A.2.1. The the default parameters specified by RFC 3447 in Section A.2.1.
"alg" header parameter value "RSA-OAEP" is used in this case. (Those default parameters are using a hash function of SHA-1 and a
mask generation function of MGF1 with SHA-1.) The "alg" header
parameter value "RSA-OAEP" is used in this case.
A key of size 2048 bits or larger MUST be used with this algorithm. A key of size 2048 bits or larger MUST be used with this algorithm.
An example using this algorithm is shown in Appendix A.1 of [JWE]. An example using this algorithm is shown in Appendix A.1 of [JWE].
4.5. Key Wrapping with AES Key Wrap 4.5. Key Wrapping with AES Key Wrap
This section defines the specifics of encrypting a JWE CEK with the This section defines the specifics of encrypting a JWE CEK with the
Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
the default initial value specified in Section 2.2.3.1 using 128, the default initial value specified in Section 2.2.3.1 using 128,
skipping to change at page 21, line 45 skipping to change at page 21, line 47
4.6. Direct Encryption with a Shared Symmetric Key 4.6. Direct Encryption with a Shared Symmetric Key
This section defines the specifics of directly performing symmetric This section defines the specifics of directly performing symmetric
key encryption without performing a key wrapping step. In this case, key encryption without performing a key wrapping step. In this case,
the shared symmetric key is used directly as the Content Encryption the shared symmetric key is used directly as the Content Encryption
Key (CEK) value for the "enc" algorithm. An empty octet sequence is Key (CEK) value for the "enc" algorithm. An empty octet sequence is
used as the JWE Encrypted Key value. The "alg" header parameter used as the JWE Encrypted Key value. The "alg" header parameter
value "dir" is used in this case. value "dir" is used in this case.
Refer to the security considerations on key lifetimes in Section 7.2
and AES GCM in Section 7.4 when considering utilizing direct
encryption.
4.7. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static 4.7. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static
(ECDH-ES) (ECDH-ES)
This section defines the specifics of key agreement with Elliptic This section defines the specifics of key agreement with Elliptic
Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with
the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]. The the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]. The
key agreement result can be used in one of two ways: key agreement result can be used in one of two ways:
1. directly as the Content Encryption Key (CEK) for the "enc" 1. directly as the Content Encryption Key (CEK) for the "enc"
algorithm, in the Direct Key Agreement mode, or algorithm, in the Direct Key Agreement mode, or
skipping to change at page 22, line 29 skipping to change at page 22, line 37
this case, the empty octet sequence is used as the JWE Encrypted Key this case, the empty octet sequence is used as the JWE Encrypted Key
value. In the Key Agreement with Key Wrapping case, the output of value. In the Key Agreement with Key Wrapping case, the output of
the Concat KDF MUST be a key of the length needed for the specified the Concat KDF MUST be a key of the length needed for the specified
key wrapping algorithm, one of 128, 192, or 256 bits respectively. key wrapping algorithm, one of 128, 192, or 256 bits respectively.
A new ephemeral public key value MUST be generated for each key A new ephemeral public key value MUST be generated for each key
agreement operation. agreement operation.
4.7.1. Header Parameters Used for ECDH Key Agreement 4.7.1. Header Parameters Used for ECDH Key Agreement
The following Header Parameter Names are reserved and are used for The following Header Parameter Names are used for key agreement as
key agreement as defined below. defined below.
4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter 4.7.1.1. "epk" (Ephemeral Public Key) Header Parameter
The "epk" (ephemeral public key) value created by the originator for The "epk" (ephemeral public key) value created by the originator for
the use in key agreement algorithms. This key is represented as a the use in key agreement algorithms. This key is represented as a
JSON Web Key [JWK] public key value. It MUST contain only public key JSON Web Key [JWK] public key value. It MUST contain only public key
parameters and SHOULD contain only the minimum JWK parameters parameters and SHOULD contain only the minimum JWK parameters
necessary to represent the key; other JWK parameters included can be necessary to represent the key; other JWK parameters included can be
checked for consistency and honored or can be ignored. This Header checked for consistency and honored or can be ignored. This Header
Parameter is REQUIRED and MUST be understood and processed by Parameter is REQUIRED and MUST be understood and processed by
skipping to change at page 23, line 32 skipping to change at page 23, line 41
The Concat KDF parameters are set as follows: The Concat KDF parameters are set as follows:
Z This is set to the representation of the shared secret Z as an Z This is set to the representation of the shared secret Z as an
octet sequence. octet sequence.
keydatalen This is set to the number of bits in the desired output keydatalen 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" key. For "ECDH-ES", this is length of the key used by the "enc"
algorithm. For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and algorithm. For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and
"ECDH-ES+A256KW", this is 128, 192, and 256, respectively. "ECDH-ES+A256KW", this is 128, 192, and 256, respectively.
AlgorithmID In the Direct Key Agreement case, this is set to the AlgorithmID The AlgorithmID value is of the form Datalen || Data,
octets of the UTF-8 representation of the "enc" header parameter where Data is a variable-length string of zero or more octets, and
value. In the Key Agreement with Key Wrapping case, this is set Datalen is a fixed-length, big endian 32 bit counter that
to the octets of the UTF-8 representation of the "alg" header indicates the length (in octets) of Data, with || being
parameter value. concatenation. In the Direct Key Agreement case, Data is set to
the octets of the UTF-8 representation of the "enc" header
parameter value. In the Key Agreement with Key Wrapping case,
Data is set to the octets of the UTF-8 representation of the "alg"
header parameter value.
PartyUInfo The PartyUInfo value is of the form Datalen || Data, PartyUInfo The PartyUInfo value is of the form Datalen || Data,
where Data is a variable-length string of zero or more octets, and where Data is a variable-length string of zero or more octets, and
Datalen is a fixed-length, big endian 32 bit counter that Datalen is a fixed-length, big endian 32 bit counter that
indicates the length (in octets) of Data, with || being indicates the length (in octets) of Data, with || being
concatenation. If an "apu" (agreement PartyUInfo) header concatenation. 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
the empty octet sequence. the empty octet sequence.
skipping to change at page 24, line 14 skipping to change at page 24, line 30
parameter is present, Data is set to the result of base64url parameter is present, Data is set to the result of base64url
decoding the "apv" value and Datalen is set to the number of decoding the "apv" 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
the empty octet sequence. the empty octet sequence.
SuppPubInfo This is set to the keydatalen represented as a 32 bit SuppPubInfo This is set to the keydatalen represented as a 32 bit
big endian integer. big endian integer.
SuppPrivInfo This is set to the empty octet sequence. SuppPrivInfo This is set to the empty octet sequence.
Applications MUST specify what values should be used in the "apu" and
"apv" parameters. The "apu" and "apv" values MUST be distinct.
Applications wishing to conform to [NIST.800-56A] need to provide
values that meet the requirements of that document, e.g., by using
values that identify the sender and recipient. Alternatively,
applications MAY conduct key derivation in a manner similar to The
Diffie-Hellman Key Agreement Method [RFC2631]: In that case, the
"apu" field MAY either be omitted or represent a random 512-bit value
(analogous to PartyAInfo in Ephemeral-Static mode in [RFC2631]) and
the "apv" field should not be present.
See Appendix D for an example key agreement computation using this See Appendix D for an example key agreement computation using this
method. method.
Note: The Diffie-Hellman Key Agreement Method [RFC2631] uses a key
derivation function similar to the Concat KDF, but with fewer
parameters. Rather than having separate PartyUInfo and PartyVInfo
parameters, it uses a single PartyAInfo parameter, which is a random
string provided by the sender, that contains 512 bits of information,
when provided. It has no SuppPrivInfo parameter. Should it be
appropriate for the application, key agreement can be performed in a
manner akin to RFC 2631 by using the PartyAInfo value as the "apu"
(Agreement PartyUInfo) header parameter value, when provided, and by
using no "apv" (Agreement PartyVInfo) header parameter.
4.8. Key Encryption with AES GCM 4.8. Key Encryption with AES GCM
This section defines the specifics of encrypting a JWE Content This section defines the specifics of encrypting a JWE Content
Encryption Key (CEK) with Advanced Encryption Standard (AES) in Encryption Key (CEK) with Advanced Encryption Standard (AES) in
Galois/Counter Mode (GCM) [AES] [NIST.800-38D] using 128, 192, or 256 Galois/Counter Mode (GCM) [AES] [NIST.800-38D] using 128, 192, or 256
bit keys. The "alg" header parameter values "A128GCMKW", bit keys. The "alg" header parameter values "A128GCMKW",
"A192GCMKW", or "A256GCMKW" are respectively used in this case. "A192GCMKW", or "A256GCMKW" are respectively used in this case.
Use of an Initialization Vector of size 96 bits is REQUIRED with this Use of an Initialization Vector of size 96 bits is REQUIRED with this
algorithm. The Initialization Vector is represented in base64url algorithm. The Initialization Vector is represented in base64url
skipping to change at page 25, line 42 skipping to change at page 26, line 8
specified in Section 6.2 of [RFC2898]. specified in Section 6.2 of [RFC2898].
These algorithms use HMAC SHA-2 algorithms as the Pseudo-Random These algorithms use HMAC SHA-2 algorithms as the Pseudo-Random
Function (PRF) for the PBKDF2 key derivation and AES Key Wrap Function (PRF) for the PBKDF2 key derivation and AES Key Wrap
[RFC3394] for the encryption scheme. The salt MUST be provided as [RFC3394] for the encryption scheme. The salt MUST be provided as
the "p2s" header parameter value, and MUST be base64url decoded to the "p2s" header parameter value, and MUST be base64url decoded to
obtain the value. The iteration count parameter MUST be provided as obtain the value. The iteration count parameter MUST be provided as
the "p2c" header parameter value. The algorithms respectively use the "p2c" header parameter value. The algorithms respectively use
HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 as the PRF and use 128, HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 as the PRF and use 128,
192, and 256 bit AES Key Wrap keys. Their derived-key lengths 192, and 256 bit AES Key Wrap keys. Their derived-key lengths
(dkLen) respectively are 16, 24, and 32 octets. respectively are 16, 24, and 32 octets.
4.9.1. Header Parameters Used for PBES2 Key Encryption 4.9.1. Header Parameters Used for PBES2 Key Encryption
The following Header Parameters are used for Key Encryption with The following Header Parameters are used for Key Encryption with
PBES2. PBES2.
4.9.1.1. "p2s" (PBES2 salt) Parameter 4.9.1.1. "p2s" (PBES2 salt) Parameter
The "p2s" (PBES2 salt) header parameter contains the PBKDF2 salt The "p2s" (PBES2 salt) header parameter contains the PBKDF2 salt
value, encoded using base64url. This Header Parameter is REQUIRED value, encoded using base64url. This Header Parameter is REQUIRED
skipping to change at page 31, line 22 skipping to change at page 31, line 35
The requested size of the Authentication Tag output MUST be 128 bits, The requested size of the Authentication Tag output MUST be 128 bits,
regardless of the key size. regardless of the key size.
The JWE Authentication Tag is set to be the Authentication Tag value The JWE Authentication Tag is set to be the Authentication Tag value
produced by the encryption. During decryption, the received JWE produced by the encryption. During decryption, the received JWE
Authentication Tag is used as the Authentication Tag value. Authentication Tag is used as the Authentication Tag value.
An example using this algorithm is shown in Appendix A.1 of [JWE]. An example using this algorithm is shown in Appendix A.1 of [JWE].
5. Cryptographic Algorithms for JWK 5. Cryptographic Algorithms for Keys
A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a
cryptographic key. These keys can be either asymmetric or symmetric. cryptographic key. These keys can be either asymmetric or symmetric.
They can hold both public and private information about the key. They can hold both public and private information about the key.
This section defines the parameters for keys using the algorithms This section defines the parameters for keys using the algorithms
specified by this document. specified by this document.
5.1. "kty" (Key Type) Parameter Values 5.1. "kty" (Key Type) Parameter Values
The table below is the set of "kty" (key type) parameter values that The table below is the set of "kty" (key type) parameter values that
skipping to change at page 32, line 5 skipping to change at page 32, line 20
| EC | Elliptic Curve [DSS] | Recommended+ | | EC | Elliptic Curve [DSS] | Recommended+ |
| RSA | RSA [RFC3447] | Required | | RSA | RSA [RFC3447] | Required |
| oct | Octet sequence (used to | Required | | oct | Octet sequence (used to | Required |
| | represent symmetric keys) | | | | represent symmetric keys) | |
+--------------+--------------------------------+-------------------+ +--------------+--------------------------------+-------------------+
The use of "+" in the Implementation Requirements indicates that the The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of requirement strength is likely to be increased in a future version of
the specification. the specification.
5.2. JWK Parameters for Elliptic Curve Keys 5.2. Parameters for Elliptic Curve Keys
JWKs can represent Elliptic Curve [DSS] keys. In this case, the JWKs can represent Elliptic Curve [DSS] keys. In this case, the
"kty" member value MUST be "EC". "kty" member value MUST be "EC".
5.2.1. JWK Parameters for Elliptic Curve Public Keys 5.2.1. Parameters for Elliptic Curve Public Keys
The following members MUST be present for Elliptic Curve public keys. An elliptic curve public key is represented by a pair of coordinates
drawn from a finite field, which together define a point on an
elliptic curve. The following members MUST be present for elliptic
curve public keys:
o "crv"
o "x"
o "y"
5.2.1.1. "crv" (Curve) Parameter 5.2.1.1. "crv" (Curve) Parameter
The "crv" (curve) member identifies the cryptographic curve used with The "crv" (curve) member identifies the cryptographic curve used with
the key. Curve values from [DSS] used by this specification are: the key. Curve values from [DSS] used by this specification are:
o "P-256" o "P-256"
o "P-384" o "P-384"
o "P-521" o "P-521"
Additional "crv" values MAY be used, provided they are understood by These values are registered in the IANA JSON Web Key Elliptic Curve
implementations using that Elliptic Curve key. The "crv" value is a registry defined in Section 6.6. Additional "crv" values MAY be
case sensitive string. used, provided they are understood by implementations using that
Elliptic Curve key. The "crv" value is a case sensitive string.
5.2.1.2. "x" (X Coordinate) Parameter 5.2.1.2. "x" (X Coordinate) Parameter
The "x" (x coordinate) member contains the x coordinate for the The "x" (x coordinate) member contains the x coordinate for the
elliptic curve point. It is represented as the base64url encoding of elliptic curve point. It is represented as the base64url encoding of
the coordinate's big endian representation as an octet sequence. The the octet string representation of the coordinate, as defined in
array representation MUST NOT be shortened to omit any leading zero Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST
octets contained in the value. For instance, when representing 521 be the full size of a coordinate for the curve specified in the "crv"
bit integers, the octet sequence to be base64url encoded MUST contain parameter. For example, if the value of "crv" is "P-521", the octet
66 octets, including any leading zero octets. string must be 66 octets long.
5.2.1.3. "y" (Y Coordinate) Parameter 5.2.1.3. "y" (Y Coordinate) Parameter
The "y" (y coordinate) member contains the y coordinate for the The "y" (y coordinate) member contains the y coordinate for the
elliptic curve point. It is represented as the base64url encoding of elliptic curve point. It is represented as the base64url encoding of
the coordinate's big endian representation as an octet sequence. The the octet string representation of the coordinate, as defined in
array representation MUST NOT be shortened to omit any leading zero Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST
octets contained in the value. For instance, when representing 521 be the full size of a coordinate for the curve specified in the "crv"
bit integers, the octet sequence to be base64url encoded MUST contain parameter. For example, if the value of "crv" is "P-521", the octet
66 octets, including any leading zero octets. string must be 66 octets long.
5.2.2. JWK Parameters for Elliptic Curve Private Keys 5.2.2. Parameters for Elliptic Curve Private Keys
In addition to the members used to represent Elliptic Curve public In addition to the members used to represent Elliptic Curve public
keys, the following member MUST be present to represent Elliptic keys, the following member MUST be present to represent Elliptic
Curve private keys. Curve private keys.
5.2.2.1. "d" (ECC Private Key) Parameter 5.2.2.1. "d" (ECC Private Key) Parameter
The "d" (ECC private key) member contains the Elliptic Curve private The "d" (ECC private key) member contains the Elliptic Curve private
key value. It is represented as the base64url encoding of the key value. It is represented as the base64url encoding of the octet
value's unsigned big endian representation as an octet sequence. The string representation of the private key value, as defined in
array representation MUST NOT be shortened to omit any leading zero Sections C.4 and 2.3.7 of SEC1 [SEC1]. The length of this octet
octets. For instance, when representing 521 bit integers, the octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order
sequence to be base64url encoded MUST contain 66 octets, including of the curve).
any leading zero octets.
5.3. JWK Parameters for RSA Keys 5.3. Parameters for RSA Keys
JWKs can represent RSA [RFC3447] keys. In this case, the "kty" JWKs can represent RSA [RFC3447] keys. In this case, the "kty"
member value MUST be "RSA". member value MUST be "RSA".
5.3.1. JWK Parameters for RSA Public Keys 5.3.1. Parameters for RSA Public Keys
The following members MUST be present for RSA public keys. The following members MUST be present for RSA public keys.
5.3.1.1. "n" (Modulus) Parameter 5.3.1.1. "n" (Modulus) Parameter
The "n" (modulus) member contains the modulus value for the RSA The "n" (modulus) member contains the modulus value for the RSA
public key. It is represented as the base64url encoding of the public key. It is represented as the base64url encoding of the
value's unsigned big endian representation as an octet sequence. The value's unsigned big endian representation as an octet sequence. The
array representation MUST NOT be shortened to omit any leading zero octet sequence MUST utilize the minimum number of octets to represent
octets. For instance, when representing 2048 bit integers, the octet the value.
sequence to be base64url encoded MUST contain 256 octets, including
any leading zero octets.
5.3.1.2. "e" (Exponent) Parameter 5.3.1.2. "e" (Exponent) Parameter
The "e" (exponent) member contains the exponent value for the RSA The "e" (exponent) member contains the exponent value for the RSA
public key. It is represented as the base64url encoding of the public key. It is represented as the base64url encoding of the
value's unsigned big endian representation as an octet sequence. The value's unsigned big endian representation as an octet sequence. The
array representation MUST utilize the minimum number of octets to octet sequence MUST utilize the minimum number of octets to represent
represent the value. For instance, when representing the value the value. For instance, when representing the value 65537, the
65537, the octet sequence to be base64url encoded MUST consist of the octet sequence to be base64url encoded MUST consist of the three
three octets [1, 0, 1]. octets [1, 0, 1].
5.3.2. JWK Parameters for RSA Private Keys 5.3.2. Parameters for RSA Private Keys
In addition to the members used to represent RSA public keys, the In addition to the members used to represent RSA public keys, the
following members are used to represent RSA private keys. The following members are used to represent RSA private keys. The
parameter "d" is REQUIRED for RSA private keys. The others enable parameter "d" is REQUIRED for RSA private keys. The others enable
optimizations and are RECOMMENDED. If any of the others are present optimizations and SHOULD be included by producers of JWKs
then all MUST be present, with the exception of "oth", which MUST representing RSA private keys. If the producer includes any of the
only be present when more than two prime factors were used. other private key parameters, then all of the others MUST be present,
with the exception of "oth", which MUST only be present when more
than two prime factors were used. The consumer of a JWK MAY choose
to accept an RSA private key that does not contain a complete set of
the private key parameters other than "d", including JWKs in which
"d" is the only RSA private key parameter included.
5.3.2.1. "d" (Private Exponent) Parameter 5.3.2.1. "d" (Private Exponent) Parameter
The "d" (private exponent) member contains the private exponent value The "d" (private exponent) member contains the private exponent value
for the RSA private key. It is represented as the base64url encoding for the RSA private key. It is represented as the base64url encoding
of the value's unsigned big endian representation as an octet of the value's unsigned big endian representation as an octet
sequence. The array representation MUST NOT be shortened to omit any sequence. The octet sequence MUST utilize the minimum number of
leading zero octets. For instance, when representing 2048 bit octets to represent the value.
integers, the octet sequence to be base64url encoded MUST contain 256
octets, including any leading zero octets.
5.3.2.2. "p" (First Prime Factor) Parameter 5.3.2.2. "p" (First Prime Factor) Parameter
The "p" (first prime factor) member contains the first prime factor, The "p" (first prime factor) member contains the first prime factor,
a positive integer. It is represented as the base64url encoding of a positive integer. It is represented as the base64url encoding of
the value's unsigned big endian representation as an octet sequence. the value's unsigned big endian representation as an octet sequence.
The octet sequence MUST utilize the minimum number of octets to
represent the value.
5.3.2.3. "q" (Second Prime Factor) Parameter 5.3.2.3. "q" (Second Prime Factor) Parameter
The "q" (second prime factor) member contains the second prime The "q" (second prime factor) member contains the second prime
factor, a positive integer. It is represented as the base64url factor, a positive integer. It is represented as the base64url
encoding of the value's unsigned big endian representation as an encoding of the value's unsigned big endian representation as an
octet sequence. octet sequence. The octet sequence MUST utilize the minimum number
of octets to represent the value.
5.3.2.4. "dp" (First Factor CRT Exponent) Parameter 5.3.2.4. "dp" (First Factor CRT Exponent) Parameter
The "dp" (first factor CRT exponent) member contains the Chinese The "dp" (first factor CRT exponent) member contains the Chinese
Remainder Theorem (CRT) exponent of the first factor, a positive Remainder Theorem (CRT) exponent of the first factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the
value.
5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter 5.3.2.5. "dq" (Second Factor CRT Exponent) Parameter
The "dq" (second factor CRT exponent) member contains the Chinese The "dq" (second factor CRT exponent) member contains the Chinese
Remainder Theorem (CRT) exponent of the second factor, a positive Remainder Theorem (CRT) exponent of the second factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the
value.
5.3.2.6. "qi" (First CRT Coefficient) Parameter 5.3.2.6. "qi" (First CRT Coefficient) Parameter
The "dp" (first CRT coefficient) member contains the Chinese The "dp" (first CRT coefficient) member contains the Chinese
Remainder Theorem (CRT) coefficient of the second factor, a positive Remainder Theorem (CRT) coefficient of the second factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the
value.
5.3.2.7. "oth" (Other Primes Info) Parameter 5.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. Each array elements MUST be the number of primes used minus two. Each
array element MUST be an object with the following members: array element MUST be an object with the following members:
5.3.2.7.1. "r" (Prime Factor) 5.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, a positive represents the value of a subsequent prime factor, a positive
integer. It is represented as the base64url encoding of the value's integer. It is represented as the base64url encoding of the value's
unsigned big endian representation as an octet sequence. unsigned big endian representation as an octet sequence. The octet
sequence MUST utilize the minimum number of octets to represent the
value.
5.3.2.7.2. "d" (Factor CRT Exponent) 5.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
represents the CRT exponent of the corresponding prime factor, a represents the CRT exponent of the corresponding prime factor, a
positive integer. It is represented as the base64url encoding of the positive integer. It is represented as the base64url encoding of the
value's unsigned big endian representation as an octet sequence. value's unsigned big endian representation as an octet sequence. The
octet sequence MUST utilize the minimum number of octets to represent
the value.
5.3.2.7.3. "t" (Factor CRT Coefficient) 5.3.2.7.3. "t" (Factor CRT Coefficient)
The "t" (factor CRT coefficient) parameter within an "oth" array The "t" (factor CRT coefficient) parameter within an "oth" array
member represents the CRT coefficient of the corresponding prime member represents the CRT coefficient of the corresponding prime
factor, a positive integer. It is represented as the base64url factor, a positive integer. It is represented as the base64url
encoding of the value's unsigned big endian representation as an encoding of the value's unsigned big endian representation as an
octet sequence. octet sequence. The octet sequence MUST utilize the minimum number
of octets to represent the value.
5.4. JWK Parameters for Symmetric Keys 5.4. Parameters for Symmetric Keys
When the JWK "kty" member value is "oct" (octet sequence), the When the JWK "kty" member value is "oct" (octet sequence), the member
following member is used to represent a symmetric key (or another key "k" is used to represent a symmetric key (or another key whose value
whose value is a single octet sequence): is a single octet sequence). An "alg" member SHOULD also be present
to identify the algorithm intended to be used with the key, unless
the application uses another means or convention to determine the
algorithm used.
5.4.1. "k" (Key Value) Parameter 5.4.1. "k" (Key Value) Parameter
The "k" (key value) member contains the value of the symmetric (or The "k" (key value) member contains the value of the symmetric (or
other single-valued) key. It is represented as the base64url other single-valued) key. It is represented as the base64url
encoding of the octet sequence containing the key value. encoding of the octet sequence containing the key value.
6. IANA Considerations 6. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
skipping to change at page 36, line 14 skipping to change at page 37, line 4
Values are registered with a Specification Required [RFC5226] after a Values are registered with a Specification Required [RFC5226] after a
two-week review period on the [TBD]@ietf.org mailing list, on the two-week review period on the [TBD]@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for access token type: example"). [[ Note to RFC-EDITOR: The name of for access token type: example"). [[ Note to the RFC Editor: The name
the mailing list should be determined in consultation with the IESG of the mailing list should be determined in consultation with the
and IANA. Suggested name: jose-reg-review. ]] IESG and IANA. Suggested name: jose-reg-review. ]]
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. successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the
iesg@iesg.org mailing list) for resolution.
Criteria that should be applied by the Designated Expert(s) includes
determining whether the proposed registration duplicates existing
functionality, determining whether it is likely to be of general
applicability or whether it is useful only for a single application,
and whether the registration makes sense.
IANA must only accept registry updates from the Designated Expert(s) IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using
this specification, in order to enable broadly-informed review of
registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other
Expert(s).
6.1. JSON Web Signature and Encryption Algorithms Registry 6.1. JSON Web Signature and Encryption Algorithms Registry
This specification establishes the IANA JSON Web Signature and This specification establishes the IANA JSON Web Signature and
Encryption Algorithms registry for values of the JWS and JWE "alg" Encryption Algorithms registry for values of the JWS and JWE "alg"
(algorithm) and "enc" (encryption method) header parameters. The (algorithm) and "enc" (encryption method) header parameters. The
registry records the algorithm name, the algorithm usage locations registry records the algorithm name, the algorithm usage locations
from the set "alg" and "enc", implementation requirements, and a from the set "alg" and "enc", implementation requirements, and a
reference to the specification that defines it. The same algorithm reference to the specification that defines it. The same algorithm
name MAY be registered multiple times, provided that the sets of name MAY be registered multiple times, provided that the sets of
usage locations are disjoint. usage locations are disjoint.
It is suggested that when algorithms can use keys of different
lengths, that the length of the key be included in the algorithm
name. This allows readers of the JSON text to easily make security
consideration decisions.
The implementation requirements of an algorithm MAY be changed over The implementation requirements of an algorithm MAY be changed over
time by the Designated Experts(s) as the cryptographic landscape time by the Designated Experts(s) as the cryptographic landscape
evolves, for instance, to change the status of an algorithm to evolves, for instance, to change the status of an algorithm to
Deprecated, or to change the status of an algorithm from Optional to Deprecated, or to change the status of an algorithm from Optional to
Recommended+ or Required. Changes of implementation requirements are Recommended+ or Required. Changes of implementation requirements are
only permitted on a Specification Required basis, with the new only permitted on a Specification Required basis, with the new
specification defining the revised implementation requirements level. specification defining the revised implementation requirements level.
6.1.1. Template 6.1.1. Template
Algorithm Name: Algorithm Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names may not match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
Algorithm Usage Location(s): Algorithm Usage Location(s):
The algorithm usage, which must be one or more of the values "alg" The algorithm usage, which must be one or more of the values "alg"
or "enc". or "enc".
Implementation Requirements: Implementation Requirements:
The algorithm implementation requirements, which must be one the The algorithm implementation requirements, which must be one the
words Required, Recommended, Optional, or Deprecated. Optionally, words Required, Recommended, Optional, or Deprecated. Optionally,
the word can be followed by a "+" or "-". The use of "+" the word can be followed by a "+" or "-". The use of "+"
indicates that the requirement strength is likely to be increased indicates that the requirement strength is likely to be increased
in a future version of the specification. The use of "-" in a future version of the specification. The use of "-"
indicates that the requirement strength is likely to be decreased indicates that the requirement strength is likely to be decreased
in a future version of the specification. in a future version of the specification.
Change Controller: Change Controller:
For Standards Track RFCs, state "IETF". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
6.1.2. Initial Registry Contents 6.1.2. Initial Registry Contents
o Algorithm Name: "HS256" o Algorithm Name: "HS256"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "HS384" o Algorithm Name: "HS384"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "HS512" o Algorithm Name: "HS512"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RS256" o Algorithm Name: "RS256"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RS384" o Algorithm Name: "RS384"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RS512" o Algorithm Name: "RS512"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "ES256" o Algorithm Name: "ES256"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended+ o Implementation Requirements: Recommended+
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "ES384" o Algorithm Name: "ES384"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "ES512" o Algorithm Name: "ES512"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "PS256" o Algorithm Name: "PS256"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "PS384" o Algorithm Name: "PS384"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "PS512" o Algorithm Name: "PS512"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "none" o Algorithm Name: "none"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Required o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this document ]] o Specification Document(s): Section 3.1 of [[ this document ]]
o Algorithm Name: "RSA1_5" o Algorithm Name: "RSA1_5"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "RSA-OAEP" o Algorithm Name: "RSA-OAEP"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A128KW" o Algorithm Name: "A128KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A192KW" o Algorithm Name: "A192KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A256KW" o Algorithm Name: "A256KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "dir" o Algorithm Name: "dir"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES" o Algorithm Name: "ECDH-ES"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended+ o Implementation Requirements: Recommended+
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES+A128KW" o Algorithm Name: "ECDH-ES+A128KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES+A192KW" o Algorithm Name: "ECDH-ES+A192KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "ECDH-ES+A256KW" o Algorithm Name: "ECDH-ES+A256KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A128GCMKW" o Algorithm Name: "A128GCMKW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.8 of [[ this document ]] o Specification Document(s): Section 4.8 of [[ this document ]]
o Algorithm Name: "A192GCMKW" o Algorithm Name: "A192GCMKW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.8 of [[ this document ]] o Specification Document(s): Section 4.8 of [[ this document ]]
o Algorithm Name: "A256GCMKW" o Algorithm Name: "A256GCMKW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.8 of [[ this document ]] o Specification Document(s): Section 4.8 of [[ this document ]]
o Algorithm Name: "PBES2-HS256+A128KW" o Algorithm Name: "PBES2-HS256+A128KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.9 of [[ this document ]] o Specification Document(s): Section 4.9 of [[ this document ]]
o Algorithm Name: "PBES2-HS384+A192KW" o Algorithm Name: "PBES2-HS384+A192KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.9 of [[ this document ]] o Specification Document(s): Section 4.9 of [[ this document ]]
o Algorithm Name: "PBES2-HS512+A256KW" o Algorithm Name: "PBES2-HS512+A256KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.9 of [[ this document ]] o Specification Document(s): Section 4.9 of [[ this document ]]
o Algorithm Name: "A128CBC-HS256" o Algorithm Name: "A128CBC-HS256"
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
o Algorithm Name: "A192CBC-HS384" o Algorithm Name: "A192CBC-HS384"
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
o Algorithm Name: "A256CBC-HS512" o Algorithm Name: "A256CBC-HS512"
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
o Algorithm Name: "A128GCM" o Algorithm Name: "A128GCM"
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
o Algorithm Name: "A192GCM" o Algorithm Name: "A192GCM"
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Optional o Implementation Requirements: Optional
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
o Algorithm Name: "A256GCM" o Algorithm Name: "A256GCM"
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
o Implementation Requirements: Recommended o Implementation Requirements: Recommended
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this document ]] o Specification Document(s): Section 4.2 of [[ this document ]]
6.2. JSON Web Key Types Registry 6.2. JWE Header Parameter Names Registration
This specification registers the Header Parameter Names defined in
Section 4.7.1, Section 4.8.1, and Section 4.9.1 in the IANA JSON Web
Signature and Encryption Header Parameters registry defined in [JWS].
6.2.1. Registry Contents
o Header Parameter Name: "epk"
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.7.1.1 of [[ this document ]]
o Header Parameter Name: "apu"
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.7.1.2 of [[ this document ]]
o Header Parameter Name: "apv"
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.7.1.3 of [[ this document ]]
o Header Parameter Name: "iv"
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.8.1.1 of [[ this document ]]
o Header Parameter Name: "tag"
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.8.1.2 of [[ this document ]]
o Header Parameter Name: "p2s"
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.9.1.1 of [[ this document ]]
o Header Parameter Name: "p2c"
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.9.1.2 of [[ this document ]]
6.3. JSON Web Encryption Compression Algorithms Registry
This specification establishes the IANA JSON Web Encryption
Compression Algorithms registry for JWE "zip" member values. The
registry records the compression algorithm value and a reference to
the specification that defines it.
6.3.1. Registration Template
Compression Algorithm Value:
The name requested (e.g., "example"). Because a core goal of this
specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included.
Specification Document(s):
Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also
be included but is not required.
6.3.2. Initial Registry Contents
o Compression Algorithm Value: "DEF"
o Change Controller: IESG
o Specification Document(s): JSON Web Encryption (JWE) [JWE]
6.4. JSON Web Key Types Registry
This specification establishes the IANA JSON Web Key Types registry This specification establishes the IANA JSON Web Key Types registry
for values of the JWK "kty" (key type) parameter. The registry for values of the JWK "kty" (key type) parameter. The registry
records the "kty" value, implementation requirements, and a reference records the "kty" value, implementation requirements, and a reference
to the specification that defines it. to the specification that defines it.
The implementation requirements of a key type MAY be changed over The implementation requirements of a key type MAY be changed over
time by the Designated Experts(s) as the cryptographic landscape time by the Designated Experts(s) as the cryptographic landscape
evolves, for instance, to change the status of a key type to evolves, for instance, to change the status of a key type to
Deprecated, or to change the status of a key type from Optional to Deprecated, or to change the status of a key type from Optional to
Recommended+ or Required. Changes of implementation requirements are Recommended+ or Required. Changes of implementation requirements are
only permitted on a Specification Required basis, with the new only permitted on a Specification Required basis, with the new
specification defining the revised implementation requirements level. specification defining the revised implementation requirements level.
6.2.1. Registration Template 6.4.1. Registration Template
"kty" Parameter Value: "kty" Parameter Value:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). Because a core goal of this
sensitive. Names that match other registered names in a case specification is for the resulting representations to be compact,
insensitive manner SHOULD NOT be accepted. it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
Change Controller: Change Controller:
For Standards Track RFCs, state "IETF". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Implementation Requirements: Implementation Requirements:
The key type implementation requirements, which must be one the The key type implementation requirements, which must be one the
words Required, Recommended, Optional, or Deprecated. Optionally, words Required, Recommended, Optional, or Deprecated. Optionally,
the word can be followed by a "+" or "-". The use of "+" the word can be followed by a "+" or "-". The use of "+"
indicates that the requirement strength is likely to be increased indicates that the requirement strength is likely to be increased
in a future version of the specification. The use of "-" in a future version of the specification. The use of "-"
indicates that the requirement strength is likely to be decreased indicates that the requirement strength is likely to be decreased
in a future version of the specification. in a future version of the specification.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
6.2.2. Initial Registry Contents 6.4.2. Initial Registry Contents
This specification registers the values defined in Section 5.1. This specification registers the values defined in Section 5.1.
o "kty" Parameter Value: "EC" o "kty" Parameter Value: "EC"
o Implementation Requirements: Recommended+ o Implementation Requirements: Recommended+
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.2 of [[ this document ]] o Specification Document(s): Section 5.2 of [[ this document ]]
o "kty" Parameter Value: "RSA" o "kty" Parameter Value: "RSA"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3 of [[ this document ]] o Specification Document(s): Section 5.3 of [[ this document ]]
o "kty" Parameter Value: "oct" o "kty" Parameter Value: "oct"
o Implementation Requirements: Required o Implementation Requirements: Required
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.4 of [[ this document ]] o Specification Document(s): Section 5.4 of [[ this document ]]
6.3. JSON Web Key Parameters Registration 6.5. JSON Web Key Parameters Registration
This specification registers the parameter names defined in Sections This specification registers the parameter names defined in Sections
5.2, 5.3, and 5.4 in the IANA JSON Web Key Parameters registry [JWK]. 5.2, 5.3, and 5.4 in the IANA JSON Web Key Parameters registry
defined in [JWK].
6.3.1. Registry Contents 6.5.1. Registry Contents
o Parameter Name: "crv" o Parameter Name: "crv"
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.2.1.1 of [[ this document ]] o Specification Document(s): Section 5.2.1.1 of [[ this document ]]
o Parameter Name: "x" o Parameter Name: "x"
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.2.1.2 of [[ this document ]] o Specification Document(s): Section 5.2.1.2 of [[ this document ]]
o Parameter Name: "y" o Parameter Name: "y"
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.2.1.3 of [[ this document ]] o Specification Document(s): Section 5.2.1.3 of [[ this document ]]
o Parameter Name: "d" o Parameter Name: "d"
o Used with "kty" Value(s): "EC"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.2.2.1 of [[ this document ]] o Specification Document(s): Section 5.2.2.1 of [[ this document ]]
o Parameter Name: "n" o Parameter Name: "n"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.1.1 of [[ this document ]] o Specification Document(s): Section 5.3.1.1 of [[ this document ]]
o Parameter Name: "e" o Parameter Name: "e"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Public o Parameter Information Class: Public
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.1.2 of [[ this document ]] o Specification Document(s): Section 5.3.1.2 of [[ this document ]]
o Parameter Name: "d" o Parameter Name: "d"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.2.1 of [[ this document ]] o Specification Document(s): Section 5.3.2.1 of [[ this document ]]
o Parameter Name: "p" o Parameter Name: "p"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.2.2 of [[ this document ]] o Specification Document(s): Section 5.3.2.2 of [[ this document ]]
o Parameter Name: "q" o Parameter Name: "q"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.2.3 of [[ this document ]] o Specification Document(s): Section 5.3.2.3 of [[ this document ]]
o Parameter Name: "dp" o Parameter Name: "dp"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.2.4 of [[ this document ]] o Specification Document(s): Section 5.3.2.4 of [[ this document ]]
o Parameter Name: "dq" o Parameter Name: "dq"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.2.5 of [[ this document ]] o Specification Document(s): Section 5.3.2.5 of [[ this document ]]
o Parameter Name: "qi" o Parameter Name: "qi"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.2.6 of [[ this document ]] o Specification Document(s): Section 5.3.2.6 of [[ this document ]]
o Parameter Name: "oth" o Parameter Name: "oth"
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.3.2.7 of [[ this document ]] o Specification Document(s): Section 5.3.2.7 of [[ this document ]]
o Parameter Name: "k" o Parameter Name: "k"
o Used with "kty" Value(s): "oct"
o Parameter Information Class: Private o Parameter Information Class: Private
o Change Controller: IETF o Change Controller: IESG
o Specification Document(s): Section 5.4.1 of [[ this document ]] o Specification Document(s): Section 5.4.1 of [[ this document ]]
6.4. Registration of JWE Header Parameter Names 6.6. JSON Web Key Elliptic Curve Registry
This specification registers the Header Parameter Names defined in This specification establishes the IANA JSON Web Key Elliptic Curve
Section 4.7.1, Section 4.8.1, and Section 4.9.1 in the IANA JSON Web registry for JWK "crv" member values. The registry records the curve
Signature and Encryption Header Parameters registry [JWS]. name, implementation requirements, and a reference to the
specification that defines it. This specification registers the
parameter names defined in Section 5.2.1.1.
6.4.1. Registry Contents The implementation requirements of a curve MAY be changed over time
by the Designated Experts(s) as the cryptographic landscape evolves,
for instance, to change the status of a curve to Deprecated, or to
change the status of a curve from Optional to Recommended+ or
Required. Changes of implementation requirements are only permitted
on a Specification Required basis, with the new specification
defining the revised implementation requirements level.
o Header Parameter Name: "epk" 6.6.1. Registration Template
o Header Parameter Usage Location(s): JWE
o Change Controller: IETF
o Specification Document(s): Section 4.7.1.1 of [[ this document ]]
o Header Parameter Name: "apu" Curve Name:
o Header Parameter Usage Location(s): JWE The name requested (e.g., "example"). Because a core goal of this
o Change Controller: IETF specification is for the resulting representations to be compact,
o Specification Document(s): Section 4.7.1.2 of [[ this document ]] it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
o Header Parameter Name: "apv" Implementation Requirements:
o Header Parameter Usage Location(s): JWE The curve implementation requirements, which must be one the words
o Change Controller: IETF Required, Recommended, Optional, or Deprecated. Optionally, the
o Specification Document(s): Section 4.7.1.3 of [[ this document ]] word can be followed by a "+" or "-". The use of "+" indicates
that the requirement strength is likely to be increased in a
future version of the specification. The use of "-" indicates
that the requirement strength is likely to be decreased in a
future version of the specification.
o Header Parameter Name: "iv" Change Controller:
o Header Parameter Usage Location(s): JWE For Standards Track RFCs, state "IESG". For others, give the name
o Change Controller: IETF of the responsible party. Other details (e.g., postal address,
o Specification Document(s): Section 4.8.1.1 of [[ this document ]] email address, home page URI) may also be included.
o Header Parameter Name: "tag" Specification Document(s):
o Header Parameter Usage Location(s): JWE Reference to the document(s) that specify the parameter,
o Change Controller: IETF preferably including URI(s) that can be used to retrieve copies of
o Specification Document(s): Section 4.8.1.2 of [[ this document ]] the document(s). An indication of the relevant sections may also
be included but is not required.
o Header Parameter Name: "p2s" 6.6.2. Initial Registry Contents
o Header Parameter Usage Location(s): JWE
o Change Controller: IETF o Curve Name: "P-256"
o Specification Document(s): Section 4.9.1.1 of [[ this document ]] o Implementation Requirements: Recommended+
o Header Parameter Name: "p2c" o Change Controller: IESG
o Header Parameter Usage Location(s): JWE o Specification Document(s): Section 5.2.1.1 of [[ this document ]]
o Change Controller: IETF
o Specification Document(s): Section 4.9.1.2 of [[ this document ]] o Curve Name: "P-384"
o Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 5.2.1.1 of [[ this document ]]
o Curve Name: "P-521"
o Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 5.2.1.1 of [[ this document ]]
7. Security Considerations 7. Security Considerations
All of the security issues faced by any cryptographic application All of the security issues faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are must be faced by a JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's private and symmetric keys, preventing various
attacks, and helping the user avoid mistakes such as inadvertently attacks, and helping the user avoid mistakes such as inadvertently
encrypting a message for the wrong recipient. The entire list of encrypting a message for the wrong recipient. The entire list of
security considerations is beyond the scope of this document, but security considerations is beyond the scope of this document, but
some significant considerations are listed here. some significant considerations are listed here.
The security considerations in [AES], [DSS], [JWE], [JWK], [JWS], The security considerations in [AES], [DSS], [JWE], [JWK], [JWS],
[NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394], [NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394],
[RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this
specification. specification.
Algorithms of matching strengths should be used together whenever
possible. For instance, when AES Key Wrap is used with a given key
size, using the same key size is recommended when AES GCM is also
used.
7.1. Algorithms and Key Sizes will be Deprecated
Eventually the algorithms and/or key sizes currently described in Eventually the algorithms and/or key sizes currently described in
this specification will no longer be considered sufficiently secure this specification will no longer be considered sufficiently secure
and will be removed. Therefore, implementers and deployments must be and will be removed. Therefore, implementers and deployments must be
prepared for this eventuality. prepared for this eventuality.
7.2. Key Lifetimes
Many algorithms have associated security considerations related to Many algorithms have associated security considerations related to
key lifetimes and/or the number of times that a key may be used. key lifetimes and/or the number of times that a key may be used.
Those security considerations continue to apply when using those Those security considerations continue to apply when using those
algorithms with JOSE data structures. algorithms with JOSE data structures.
Algorithms of matching strengths should be used together whenever 7.3. RSAES-PKCS1-v1_5 Security Considerations
possible. For instance, when AES Key Wrap is used with a given key
size, using the same key size is recommended when AES GCM is also
used.
While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not
to adopt RSASSA-PKCS-v1_5 for new applications and instead requests to adopt RSASSA-PKCS-v1_5 for new applications and instead requests
that people transition to RSASSA-PSS, this specification does include that people transition to RSASSA-PSS, this specification does include
RSASSA-PKCS-v1_5, for interoperability reasons, because it commonly RSASSA-PKCS-v1_5, for interoperability reasons, because it commonly
implemented. implemented.
Keys used with RSAES-PKCS1-v1_5 must follow the constraints in Keys used with RSAES-PKCS1-v1_5 must follow the constraints in
Section 7.2 of RFC 3447 [RFC3447]. In particular, keys with a low Section 7.2 of RFC 3447 [RFC3447]. In particular, keys with a low
public key exponent value must not be used. public key exponent value must not be used.
7.4. AES GCM Security Considerations
Keys used with AES GCM must follow the constraints in Section 8.3 of Keys used with AES GCM must follow the constraints in Section 8.3 of
[NIST.800-38D], which states: "The total number of invocations of the [NIST.800-38D], which states: "The total number of invocations of the
authenticated encryption function shall not exceed 2^32, including authenticated encryption function shall not exceed 2^32, including
all IV lengths and all instances of the authenticated encryption all IV lengths and all instances of the authenticated encryption
function with the given key". In accordance with this rule, AES GCM function with the given key". In accordance with this rule, AES GCM
MUST NOT be used with the same key encryption key or with the same MUST NOT be used with the same key value more than 2^32 times.
direct encryption key more than 2^32 times.
An Initialization Vector value MUST never be used multiple times with
the same AES GCM key. One way to prevent this is to store a counter
with the key and increment it with every use. The counter can also
be used to prevent exceeding the 2^32 limit above.
This security consideration does not apply to the composite AES-CBC
HMAC SHA-2 or AES Key Wrap algorithms.
7.5. Plaintext JWS Security Considerations
Plaintext JWSs (JWSs that use the "alg" value "none") provide no Plaintext JWSs (JWSs that use the "alg" value "none") provide no
integrity protection. Thus, they must only be used in contexts where integrity protection. Thus, they must only be used in contexts where
the payload is secured by means other than a digital signature or MAC the payload is secured by means other than a digital signature or MAC
value, or need not be secured. value, or need not be secured.
Implementations that support plaintext JWS objects MUST NOT accept
such objects as valid unless the application specifies that it is
acceptable for a specific object to not be integrity-protected.
Implementations MUST NOT accept plaintext JWS objects by default.
For example, the "verify" method of a hypothetical JWS software
library might have a Boolean "acceptUnsigned" parameter that
indicates "none" is an acceptable "alg" value. As another example,
the "verify" method might take a list of algorithms that are
acceptable to the application as a parameter and would reject
plaintext JWS values if "none" is not in that list.
In order to mitigate downgrade attacks, applications MUST NOT signal
acceptance of plaintext JWS objects at a global level, and SHOULD
signal acceptance on a per-object basis. For example, suppose an
application accepts JWS objects over two channels, (1) HTTP and (2)
HTTPS with client authentication. It requires a JWS signature on
objects received over HTTP, but accepts plaintext JWS objects over
HTTPS. If the application were to globally indicate that "none" is
acceptable, then an attacker could provide it with an unsigned object
over HTTP and still have that object successfully validate. Instead,
the application needs to indicate acceptance of "none" for each
object received over HTTPS (e.g., by setting "acceptUnsigned" to
"true" for the first hypothetical JWS software library above), but
not for each object received over HTTP.
7.6. Denial of Service Attacks
Receiving agents that validate signatures and sending agents that Receiving agents that validate signatures and sending agents that
encrypt messages need to be cautious of cryptographic processing encrypt messages need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could larger than those mandated in this specification. An attacker could
send certificates with keys that would result in excessive send certificates with keys that would result in excessive
cryptographic processing, for example, keys larger than those cryptographic processing, for example, keys larger than those
mandated in this specification, which could swamp the processing mandated in this specification, which could swamp the processing
element. Agents that use such keys without first validating the element. Agents that use such keys without first validating the
certificate to a trust anchor are advised to have some sort of certificate to a trust anchor are advised to have some sort of
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
7.1. Reusing Key Material when Encrypting Keys 7.7. Reusing Key Material when Encrypting Keys
It is NOT RECOMMENDED to reuse the same key material (Key Encryption It is NOT RECOMMENDED to reuse the same key material (Key Encryption
Key, Content Encryption Key, Initialization Vector, etc.) to encrypt Key, Content Encryption Key, Initialization Vector, etc.) to encrypt
multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK
Set object multiple times. One suggestion for preventing re-use is Set object multiple times. One suggestion for preventing re-use is
to always generate a new set key material for each encryption to always generate a new set key material for each encryption
operation, based on the considerations noted in this document as well operation, based on the considerations noted in this document as well
as from [RFC4086]. as from [RFC4086].
7.2. Password Considerations 7.8. Password Considerations
While convenient for end users, passwords are vulnerable to a number While convenient for end users, passwords are vulnerable to a number
of attacks. To help mitigate some of these limitations, this of attacks. To help mitigate some of these limitations, this
document applies principles from [RFC2898] to derive cryptographic document applies principles from [RFC2898] to derive cryptographic
keys from user-supplied passwords. keys from user-supplied passwords.
However, the strength of the password still has a significant impact. However, the strength of the password still has a significant impact.
A high-entry password has greater resistance to dictionary attacks. A high-entry password has greater resistance to dictionary attacks.
[NIST-800-63-1] contains guidelines for estimating password entropy, [NIST-800-63-1] contains guidelines for estimating password entropy,
which can help applications and users generate stronger passwords. which can help applications and users generate stronger passwords.
skipping to change at page 50, line 12 skipping to change at page 54, line 41
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. Curve Cryptography Algorithms", RFC 6090, February 2011.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", May 2009.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-3, October 2008. Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
9.2. Informative References 9.2. Informative References
[CanvasApp] [CanvasApp]
skipping to change at page 50, line 41 skipping to change at page 55, line 27
Miller, M., "Using JavaScript Object Notation (JSON) Web Miller, M., "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK) Encryption (JWE) for Protecting JSON Web Key (JWK)
Objects", draft-miller-jose-jwe-protected-jwk-02 (work in Objects", draft-miller-jose-jwe-protected-jwk-02 (work in
progress), June 2013. progress), June 2013.
[I-D.rescorla-jsms] [I-D.rescorla-jsms]
Rescorla, E. and J. Hildebrand, "JavaScript Message Rescorla, E. and J. Hildebrand, "JavaScript Message
Security Format", draft-rescorla-jsms-00 (work in Security Format", draft-rescorla-jsms-00 (work in
progress), March 2011. progress), March 2011.
[JCA] Oracle, "Java Cryptography Architecture", 2011. [JCA] Oracle, "Java Cryptography Architecture", 2013.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple [JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", September 2010. Encryption", September 2010.
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign",
September 2010. September 2010.
[MagicSignatures] [MagicSignatures]
Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011. Signatures", January 2011.
skipping to change at page 51, line 21 skipping to change at page 56, line 6
RFC 2631, June 1999. RFC 2631, June 1999.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002. March 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P.,
Hirsch, F., Cantor, S., and T. Roessler, "XML Signature Hirsch, F., Cantor, S., and T. Roessler, "XML Signature
Syntax and Processing Version 2.0", World Wide Web Syntax and Processing Version 2.0", World Wide Web
Consortium CR CR-xmldsig-core2-20120124, January 2012, Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
[W3C.CR-xmlenc-core1-20120313] [W3C.CR-xmlenc-core1-20120313]
Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,
"XML Encryption Syntax and Processing Version 1.1", World "XML Encryption Syntax and Processing Version 1.1", World
skipping to change at page 52, line 4 skipping to change at page 56, line 33
xmlenc-core-20021210, December 2002, xmlenc-core-20021210, December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>. <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
Appendix A. Digital Signature/MAC Algorithm Identifier Cross-Reference Appendix A. Digital Signature/MAC Algorithm Identifier Cross-Reference
This appendix contains a table cross-referencing the digital This appendix contains a table cross-referencing the digital
signature and MAC "alg" (algorithm) values used in this specification signature and MAC "alg" (algorithm) values used in this specification
with the equivalent identifiers used by other standards and software with the equivalent identifiers used by other standards and software
packages. See XML DSIG [RFC3275], XML DSIG 2.0 packages. See XML DSIG [RFC3275], XML DSIG 2.0
[W3C.CR-xmldsig-core2-20120124], and Java Cryptography Architecture [W3C.CR-xmldsig-core2-20120124], and Java Cryptography Architecture
[JCA] for more information about the names defined by those [JCA] for more information about the names defined by those
documents. documents.
+---------+----+---------------------------+----------+-------------+ +-----+---------------------------------+-----------+---------------+
| Algorit | JW | XML DSIG | JCA | OID | | JWS | XML DSIG | JCA | OID |
| hm | S | | | | +-----+---------------------------------+-----------+---------------+
+---------+----+---------------------------+----------+-------------+ | HS2 | http://www.w3.org/2001/04/xmlds | HmacSHA25 | 1.2.840.11354 |
| HMAC | HS | http://www.w3.org/2001/04 | HmacSHA2 | 1.2.840.113 | | 56 | ig-more#hmac-sha256 | 6 | 9.2.9 |
| using | 25 | /xmldsig-more#hmac-sha256 | 56 | 549.2.9 | | HS3 | http://www.w3.org/2001/04/xmlds | HmacSHA38 | 1.2.840.11354 |
| SHA-256 | 6 | | | | | 84 | ig-more#hmac-sha384 | 4 | 9.2.10 |
| hash | | | | | | HS5 | http://www.w3.org/2001/04/xmlds | HmacSHA51 | 1.2.840.11354 |
| algorit | | | | | | 12 | ig-more#hmac-sha512 | 2 | 9.2.11 |
| hm | | | | | | RS2 | http://www.w3.org/2001/04/xmlds | SHA256wit | 1.2.840.11354 |
| HMAC | HS | http://www.w3.org/2001/04 | HmacSHA3 | 1.2.840.113 | | 56 | ig-more#rsa-sha256 | hRSA | 9.1.1.11 |
| using | 38 | /xmldsig-more#hmac-sha384 | 84 | 549.2.10 | | RS3 | http://www.w3.org/2001/04/xmlds | SHA384wit | 1.2.840.11354 |
| SHA-384 | 4 | | | | | 84 | ig-more#rsa-sha384 | hRSA | 9.1.1.12 |
| hash | | | | | | RS5 | http://www.w3.org/2001/04/xmlds | SHA512wit | 1.2.840.11354 |
| algorit | | | | | | 12 | ig-more#rsa-sha512 | hRSA | 9.1.1.13 |
| hm | | | | | | ES2 | http://www.w3.org/2001/04/xmlds | SHA256wit | 1.2.840.10045 |
| HMAC | HS | http://www.w3.org/2001/04 | HmacSHA5 | 1.2.840.113 | | 56 | ig-more#ecdsa-sha256 | hECDSA | .4.3.2 |
| using | 51 | /xmldsig-more#hmac-sha512 | 12 | 549.2.11 | | ES3 | http://www.w3.org/2001/04/xmlds | SHA384wit | 1.2.840.10045 |
| SHA-512 | 2 | | | | | 84 | ig-more#ecdsa-sha384 | hECDSA | .4.3.3 |
| hash | | | | | | ES5 | http://www.w3.org/2001/04/xmlds | SHA512wit | 1.2.840.10045 |
| algorit | | | | | | 12 | ig-more#ecdsa-sha512 | hECDSA | .4.3.4 |
| hm | | | | | | PS2 | http://www.w3.org/2007/05/xmlds | | 1.2.840.11354 |
| RSASSA- | RS | http://www.w3.org/2001/04 | SHA256wi | 1.2.840.113 | | 56 | ig-more#sha256-rsa-MGF1 | | 9.1.1.10 |
| PKCS-v1 | 25 | /xmldsig-more#rsa-sha256 | thRSA | 549.1.1.11 | | PS3 | http://www.w3.org/2007/05/xmlds | | 1.2.840.11354 |
| _5using | 6 | | | | | 84 | ig-more#sha384-rsa-MGF1 | | 9.1.1.10 |
| SHA-2 | | | | | | PS5 | http://www.w3.org/2007/05/xmlds | | 1.2.840.11354 |
| 56hash | | | | | | 12 | ig-more#sha512-rsa-MGF1 | | 9.1.1.10 |
| algor | | | | | +-----+---------------------------------+-----------+---------------+
| ithm | | | | |
| RSASSA- | RS | http://www.w3.org/2001/04 | SHA384wi | 1.2.840.113 |
| PKCS-v1 | 38 | /xmldsig-more#rsa-sha384 | thRSA | 549.1.1.12 |
| _5using | 4 | | | |
| SHA-3 | | | | |
| 84hash | | | | |
| algor | | | | |
| ithm | | | | |
| RSASSA- | RS | http://www.w3.org/2001/04 | SHA512wi | 1.2.840.113 |
| PKCS-v1 | 51 | /xmldsig-more#rsa-sha512 | thRSA | 549.1.1.13 |
| _5using | 2 | | | |
| SHA-5 | | | | |
| 12hash | | | | |
| algor | | | | |
| ithm | | | | |
| ECDSA | ES | http://www.w3.org/2001/04 | SHA256wi | 1.2.840.100 |
| using | 25 | /xmldsig-more#ecdsa-sha25 | thECDSA | 45.4.3.2 |
| P-256 | 6 | 6 | | |
| curve | | | | |
| and | | | | |
| SHA-256 | | | | |
| hash | | | | |
| algorit | | | | |
| hm | | | | |
| ECDSA | ES | http://www.w3.org/2001/04 | SHA384wi | 1.2.840.100 |
| using | 38 | /xmldsig-more#ecdsa-sha38 | thECDSA | 45.4.3.3 |
| P-384 | 4 | 4 | | |
| curve | | | | |
| and | | | | |
| SHA-384 | | | | |
| hash | | | | |
| algorit | | | | |
| hm | | | | |
| ECDSA | ES | http://www.w3.org/2001/04 | SHA512wi | 1.2.840.100 |
| using | 51 | /xmldsig-more#ecdsa-sha51 | thECDSA | 45.4.3.4 |
| P-521 | 2 | 2 | | |
| curve | | | | |
| and | | | | |
| SHA-512 | | | | |
| hash | | | | |
| algorit | | | | |
| hm | | | | |
| RSASSA- | PS | | | |
| PSS | 25 | | | |
| using | 6 | | | |
| SHA-25 | | | | |
| 6hash | | | | |
| algori | | | | |
| thm and | | | | |
| MGF1 | | | | |
| mask | | | | |
| gener | | | | |
| ation | | | | |
| func | | | | |
| tionwit | | | | |
| h SHA | | | | |
| -256 | | | | |
| RSASSA- | PS | | | |
| PSS | 38 | | | |
| using | 4 | | | |
| SHA-38 | | | | |
| 4hash | | | | |
| algori | | | | |
| thm and | | | | |
| MGF1 | | | | |
| mask | | | | |
| gener | | | | |
| ation | | | | |
| func | | | | |
| tionwit | | | | |
| h SHA | | | | |
| -384 | | | | |
| RSASSA- | PS | | | |
| PSS | 51 | | | |
| using | 2 | | | |
| SHA-51 | | | | |
| 2hash | | | | |
| algori | | | | |
| thm and | | | | |
| MGF1 | | | | |
| mask | | | | |
| gener | | | | |
| ation | | | | |
| func | | | | |
| tionwit | | | | |
| h SHA | | | | |
| -512 | | | | |
+---------+----+---------------------------+----------+-------------+
Appendix B. Encryption Algorithm Identifier Cross-Reference Appendix B. Encryption Algorithm Identifier Cross-Reference
This appendix contains a table cross-referencing the "alg" This appendix contains a table cross-referencing the "alg"
(algorithm) and "enc" (encryption method) values used in this (algorithm) and "enc" (encryption method) values used in this
specification with the equivalent identifiers used by other standards specification with the equivalent identifiers used by other standards
and software packages. See XML Encryption and software packages. See XML Encryption
[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1 [W3C.REC-xmlenc-core-20021210], XML Encryption 1.1
[W3C.CR-xmlenc-core1-20120313], and Java Cryptography Architecture [W3C.CR-xmlenc-core1-20120313], and Java Cryptography Architecture
[JCA] for more information about the names defined by those [JCA] for more information about the names defined by those
documents. documents.
For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and
"A256CBC-HS512", the corresponding AES CBC algorithm identifiers are "A256CBC-HS512", the corresponding AES CBC algorithm identifiers are
listed. listed.
+----------+--------+--------------------------+--------------------+ +--------+-----------------------+-------------------+--------------+
| Algorith | JWE | XML ENC | JCA | | JWE | XML ENC | JCA | OID |
| m | | | | +--------+-----------------------+-------------------+--------------+
+----------+--------+--------------------------+--------------------+ | RSA1_5 | http://www.w3.org/200 | RSA/ECB/PKCS1Padd | 1.2.840.1135 |
| RSAES-PK | RSA1_5 | http://www.w3.org/2001/0 | RSA/ECB/PKCS1Paddi | | | 1/04/xmlenc#rsa-1_5 | ing | 49.1.1.1 |
| CS1-V1_5 | | 4/xmlenc#rsa-1_5 | ng | | RSA-OA | http://www.w3.org/200 | RSA/ECB/OAEPWithS | 1.2.840.1135 |
| RSAES | RSA-OA | http://www.w3.org/2001/0 | RSA/ECB/OAEPWithSH | | EP | 1/04/xmlenc#rsa-oaep- | HA-1AndMGF1Paddin | 49.1.1.7 |
| using | EP | 4/xmlenc#rsa-oaep-mgf1p | A-1AndMGF1Padding | | | mgf1p | g | |
| Optimal | | | | | ECDH-E | http://www.w3.org/200 | | 1.3.132.1.12 |
| Asymmetr | | | | | S | 9/xmlenc11#ECDH-ES | | |
| ic | | | | | A128KW | http://www.w3.org/200 | | 2.16.840.1.1 |
| Encrypt | | | | | | 1/04/xmlenc#kw-aes128 | | 01.3.4.1.5 |
| ion | | | | | A192KW | http://www.w3.org/200 | | 2.16.840.1.1 |
| Paddin | | | | | | 1/04/xmlenc#kw-aes192 | | 01.3.4.1.25 |
| g (OAEP) | | | | | A256KW | http://www.w3.org/200 | | 2.16.840.1.1 |
| Elliptic | ECDH-E | http://www.w3.org/2009/x | | | | 1/04/xmlenc#kw-aes256 | | 01.3.4.1.45 |
| Curve | S | mlenc11#ECDH-ES | | | A128CB | http://www.w3.org/200 | AES/CBC/PKCS5Padd | 2.16.840.1.1 |
| Diffie-H | | | | | C-HS25 | 1/04/xmlenc#aes128-cb | ing | 01.3.4.1.2 |
| ellman | | | | | 6 | c | | |
| Ephemer | | | | | A192CB | http://www.w3.org/200 | AES/CBC/PKCS5Padd | 2.16.840.1.1 |
| alStatic | | | | | C-HS38 | 1/04/xmlenc#aes192-cb | ing | 01.3.4.1.22 |
| Advanced | A128KW | http://www.w3.org/2001/0 | | | 4 | c | | |
| Encrypti | | 4/xmlenc#kw-aes128 | | | A256CB | http://www.w3.org/200 | AES/CBC/PKCS5Padd | 2.16.840.1.1 |
| on | | | | | C-HS51 | 1/04/xmlenc#aes256-cb | ing | 01.3.4.1.42 |
| Standar | | | | | 2 | c | | |
| d(AES) | | | | | A128GC | http://www.w3.org/200 | AES/GCM/NoPadding | 2.16.840.1.1 |
| Key Wra | | | | | M | 9/xmlenc11#aes128-gcm | | 01.3.4.1.6 |
| pAlgorit | | | | | A192GC | http://www.w3.org/200 | AES/GCM/NoPadding | 2.16.840.1.1 |
| hmusing | | | | | M | 9/xmlenc11#aes192-gcm | | 01.3.4.1.26 |
| 128 bi | | | | | A256GC | http://www.w3.org/200 | AES/GCM/NoPadding | 2.16.840.1.1 |
| t keys | | | | | M | 9/xmlenc11#aes256-gcm | | 01.3.4.1.46 |
| AES Key | A192KW | http://www.w3.org/2001/0 | | +--------+-----------------------+-------------------+--------------+
| Wrap | | 4/xmlenc#kw-aes192 | |
| Algorith | | | |
| musing | | | |
| 192 bit | | | |
| keys | | | |
| AES Key | A256KW | http://www.w3.org/2001/0 | |
| Wrap | | 4/xmlenc#kw-aes256 | |
| Algorith | | | |
| musing | | | |
| 256 bit | | | |
| keys | | | |
| AES in | A128CB | http://www.w3.org/2001/0 | AES/CBC/PKCS5Paddi |
| Cipher | C-HS25 | 4/xmlenc#aes128-cbc | ng |
| Block | 6 | | |
| Chaining | | | |
| (CBC) | | | |
| mode | | | |
| with | | | |
| PKCS #5 | | | |
| padding | | | |
| using | | | |
| 128 bit | | | |
| keys | | | |
| AES in | A192CB | http://www.w3.org/2001/0 | AES/CBC/PKCS5Paddi |
| CBC mode | C-HS38 | 4/xmlenc#aes192-cbc | ng |
| with | 4 | | |
| PKCS #5 | | | |
| padding | | | |
| using | | | |
| 192 bit | | | |
| keys | | | |
| AES in | A256CB | http://www.w3.org/2001/0 | AES/CBC/PKCS5Paddi |
| CBC mode | C-HS51 | 4/xmlenc#aes256-cbc | ng |
| with | 2 | | |
| PKCS #5 | | | |
| padding | | | |
| using | | | |
| 256 bit | | | |
| keys | | | |
| AES in | A128GC | http://www.w3.org/2009/x | AES/GCM/NoPadding |
| Galois/C | M | mlenc11#aes128-gcm | |
| ounter | | | |
| Mode | | | |
| (GCM) | | | |
| using | | | |
| 128 bit | | | |
| keys | | | |
| AES GCM | A192GC | http://www.w3.org/2009/x | AES/GCM/NoPadding |
| using | M | mlenc11#aes192-gcm | |
| 192 bit | | | |
| keys | | | |
| AES GCM | A256GC | http://www.w3.org/2009/x | AES/GCM/NoPadding |
| using | M | mlenc11#aes256-gcm | |
| 256 bit | | | |
| keys | | | |
+----------+--------+--------------------------+--------------------+
Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms Appendix C. Test Cases for AES_CBC_HMAC_SHA2 Algorithms
The following test cases can be used to validate implementations of The following test cases can be used to validate implementations of
the AES_CBC_HMAC_SHA2 algorithms defined in Section 4.10. They are the AES_CBC_HMAC_SHA2 algorithms defined in Section 4.10. They are
also intended to correspond to test cases that may appear in a future also intended to correspond to test cases that may appear in a future
version of [I-D.mcgrew-aead-aes-cbc-hmac-sha2], demonstrating that version of [I-D.mcgrew-aead-aes-cbc-hmac-sha2], demonstrating that
the cryptographic computations performed are the same. the cryptographic computations performed are the same.
The variable names are those defined in Section 4.10. All values are The variable names are those defined in Section 4.10. All values are
skipping to change at page 62, line 30 skipping to change at page 63, line 30
often not directly exposed by libraries, due to NIST security often not directly exposed by libraries, due to NIST security
requirements, and only serves as an input to a KDF.) In this requirements, and only serves as an input to a KDF.) In this
example, Z is the octet sequence: example, Z is the octet sequence:
[158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, [158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132,
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 This value is 128 - the number of bits in the desired keydatalen This value is 128 - the number of bits in the desired
output key (because "A128GCM" uses a 128 bit key). output key (because "A128GCM" uses a 128 bit key).
AlgorithmID This is set to the octets representing the UTF-8 string AlgorithmID This is set to the octets representing the 32 bit big
"A128GCM" - [65, 49, 50, 56, 71, 67, 77]. endian value 7 - [0, 0, 0, 7] - the number of octets in the
AlgorithmID content "A128GCM", followed, by the octets
representing the UTF-8 string "A128GCM" - [65, 49, 50, 56, 71, 67,
77].
PartyUInfo This is set to the octets representing the 32 bit big PartyUInfo This is set to the octets representing the 32 bit big
endian value 5 - [0, 0, 0, 5] - the number of octets in the endian value 5 - [0, 0, 0, 5] - the number of octets in the
PartyUInfo content "Alice", followed, by the octets representing PartyUInfo content "Alice", followed, by the octets representing
the UTF-8 string "Alice" - [65, 108, 105, 99, 101]. the UTF-8 string "Alice" - [65, 108, 105, 99, 101].
PartyVInfo This is set to the octets representing the 32 bit big PartyVInfo This is set to the octets representing the 32 bit big
endian value 3 - [0, 0, 0, 3] - the number of octets in the endian value 3 - [0, 0, 0, 3] - the number of octets in the
PartyUInfo content "Bob", followed, by the octets representing the PartyUInfo content "Bob", followed, by the octets representing the
UTF-8 string "Bob" - [66, 111, 98]. UTF-8 string "Bob" - [66, 111, 98].
SuppPubInfo This is set to the octets representing the 32 bit big SuppPubInfo This is set to the octets representing the 32 bit big
endian value 128 - [0, 0, 0, 128] - the keydatalen value. endian value 128 - [0, 0, 0, 128] - the keydatalen value.
SuppPrivInfo This is set to the empty octet sequence. SuppPrivInfo This is set to the empty octet sequence.
Concatenating the parameters AlgorithmID through SuppPubInfo results Concatenating the parameters AlgorithmID through SuppPubInfo results
in an otherInfo value of: in an OtherInfo value of:
[65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0,
0, 3, 66, 111, 98, 0, 0, 0, 128] [0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105,
Concatenating the round number 1 ([0, 0, 0, 1]), Z, and the otherInfo 99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
Concatenating the round number 1 ([0, 0, 0, 1]), Z, and the OtherInfo
value results in the Concat KDF round 1 hash input of: value results in the Concat KDF round 1 hash input of:
[0, 0, 0, 1, [0, 0, 0, 1,
158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38,
156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140,
254, 144, 196, 254, 144, 196,
65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0, 0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99,
0, 3, 66, 111, 98, 0, 0, 0, 128] 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
The resulting derived key, which is the first 128 bits of the round 1 The resulting derived key, which is the first 128 bits of the round 1
hash output is: hash output is:
[186, 193, 41, 192, 82, 2, 254, 170, 230, 4, 76, 103, 180, 92, 49, [86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
48] 26]
The base64url encoded representation of this derived key is: The base64url encoded representation of this derived key is:
usEpwFIC_qrmBExntFwxMA usEpwFIC_qrmBExntFwxMA
Appendix E. Acknowledgements Appendix E. Acknowledgements
Solutions for signing and encrypting JSON content were previously Solutions for signing and encrypting JSON content were previously
explored by Magic Signatures [MagicSignatures], JSON Simple Sign explored by Magic Signatures [MagicSignatures], JSON Simple Sign
[JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE], [JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE],
skipping to change at page 64, line 12 skipping to change at page 65, line 15
Manger, Matt Miller, Tony Nadalin, Axel Nennker, John Panzer, Manger, Matt Miller, Tony Nadalin, Axel Nennker, John Panzer,
Emmanuel Raviart, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Emmanuel Raviart, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and
Sean Turner. 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 and Stephen Farrell served as Security area directors Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix F. Document History Appendix F. 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 ]]
-16
o Added a DataLen prefix to the AlgorithmID value in the Concat KDF
computation.
o Added OIDs for encryption algorithms, additional signature
algorithm OIDs, and additional XML DSIG/ENC URIs in the algorithm
cross-reference tables.
o Changes to address editorial and minor issues #28, #36, #39, #52,
#53, #55, #127, #128, #136, #137, #141, #150, #151, #152, and
#155.
-15 -15
o Changed statements about rejecting JWSs to statements about o Changed statements about rejecting JWSs to statements about
validation failing, addressing issue #35. validation failing, addressing issue #35.
o Stated that changes of implementation requirements are only o Stated that changes of implementation requirements are only
permitted on a Specification Required basis, addressing issue #38. permitted on a Specification Required basis, addressing issue #38.
o Made "oct" a required key type, addressing issue #40. o Made "oct" a required key type, addressing issue #40.
o Updated the example ECDH-ES key agreement values. o Updated the example ECDH-ES key agreement values.
o Changes to address editorial and minor issues #34, #37, #49, #123, o Changes to address editorial and minor issues #34, #37, #49, #63,
#124, #125, #130, #132, #133, #138, #139, #140, #142, #143, #144, #123, #124, #125, #130, #132, #133, #138, #139, #140, #142, #143,
#145, #148, #149, #150, and #162. #144, #145, #148, #149, #150, and #162.
-14 -14
o Removed "PBKDF2" key type and added "p2s" and "p2c" header o Removed "PBKDF2" key type and added "p2s" and "p2c" header
parameters for use with the PBES2 algorithms. parameters for use with the PBES2 algorithms.
o Made the RSA private key parameters that are there to enable o Made the RSA private key parameters that are there to enable
optimizations be RECOMMENDED rather than REQUIRED. optimizations be RECOMMENDED rather than REQUIRED.
o Added algorithm identifiers for AES algorithms using 192 bit keys o Added algorithm identifiers for AES algorithms using 192 bit keys
 End of changes. 174 change blocks. 
487 lines changed or deleted 590 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/