draft-ietf-jose-json-web-key-32.txt   draft-ietf-jose-json-web-key-33.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track September 23, 2014 Intended status: Standards Track September 25, 2014
Expires: March 27, 2015 Expires: March 29, 2015
JSON Web Key (JWK) JSON Web Key (JWK)
draft-ietf-jose-json-web-key-32 draft-ietf-jose-json-web-key-33
Abstract Abstract
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data
structure that represents a cryptographic key. This specification structure that represents a cryptographic key. This specification
also defines a JSON Web Key Set (JWK Set) JSON data structure that also defines a JSON Web Key Set (JWK Set) JSON data structure that
represents a set of JWKs. Cryptographic algorithms and identifiers represents a set of JWKs. Cryptographic algorithms and identifiers
for use with this specification are described in the separate JSON for use with this specification are described in the separate JSON
Web Algorithms (JWA) specification and IANA registries defined by Web Algorithms (JWA) specification and IANA registries defined by
that specification. that specification.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 27, 2015. This Internet-Draft will expire on March 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Example JWK . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Example JWK . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. JSON Web Key (JWK) Format . . . . . . . . . . . . . . . . . . 5 4. JSON Web Key (JWK) Format . . . . . . . . . . . . . . . . . . 5
4.1. "kty" (Key Type) Parameter . . . . . . . . . . . . . . . . 6 4.1. "kty" (Key Type) Parameter . . . . . . . . . . . . . . . . 6
4.2. "use" (Public Key Use) Parameter . . . . . . . . . . . . . 6 4.2. "use" (Public Key Use) Parameter . . . . . . . . . . . . . 6
4.3. "key_ops" (Key Operations) Parameter . . . . . . . . . . . 7 4.3. "key_ops" (Key Operations) Parameter . . . . . . . . . . . 7
4.4. "alg" (Algorithm) Parameter . . . . . . . . . . . . . . . 7 4.4. "alg" (Algorithm) Parameter . . . . . . . . . . . . . . . 8
4.5. "kid" (Key ID) Parameter . . . . . . . . . . . . . . . . . 8 4.5. "kid" (Key ID) Parameter . . . . . . . . . . . . . . . . . 8
4.6. "x5u" (X.509 URL) Parameter . . . . . . . . . . . . . . . 8 4.6. "x5u" (X.509 URL) Parameter . . . . . . . . . . . . . . . 8
4.7. "x5c" (X.509 Certificate Chain) Parameter . . . . . . . . 8 4.7. "x5c" (X.509 Certificate Chain) Parameter . . . . . . . . 9
4.8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter . . . 9 4.8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter . . . 9
4.9. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) 4.9. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 9 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 9
5. JSON Web Key Set (JWK Set) Format . . . . . . . . . . . . . . 9 5. JSON Web Key Set (JWK Set) Format . . . . . . . . . . . . . . 10
5.1. "keys" Parameter . . . . . . . . . . . . . . . . . . . . . 10 5.1. "keys" Parameter . . . . . . . . . . . . . . . . . . . . . 10
6. String Comparison Rules . . . . . . . . . . . . . . . . . . . 10 6. String Comparison Rules . . . . . . . . . . . . . . . . . . . 10
7. Encrypted JWK and Encrypted JWK Set Formats . . . . . . . . . 10 7. Encrypted JWK and Encrypted JWK Set Formats . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. JSON Web Key Parameters Registry . . . . . . . . . . . . . 12 8.1. JSON Web Key Parameters Registry . . . . . . . . . . . . . 12
8.1.1. Registration Template . . . . . . . . . . . . . . . . 12 8.1.1. Registration Template . . . . . . . . . . . . . . . . 12
8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13
8.2. JSON Web Key Use Registry . . . . . . . . . . . . . . . . 14 8.2. JSON Web Key Use Registry . . . . . . . . . . . . . . . . 15
8.2.1. Registration Template . . . . . . . . . . . . . . . . 15 8.2.1. Registration Template . . . . . . . . . . . . . . . . 15
8.2.2. Initial Registry Contents . . . . . . . . . . . . . . 15 8.2.2. Initial Registry Contents . . . . . . . . . . . . . . 15
8.3. JSON Web Key Operations Registry . . . . . . . . . . . . . 15 8.3. JSON Web Key Operations Registry . . . . . . . . . . . . . 16
8.3.1. Registration Template . . . . . . . . . . . . . . . . 16 8.3.1. Registration Template . . . . . . . . . . . . . . . . 16
8.3.2. Initial Registry Contents . . . . . . . . . . . . . . 16 8.3.2. Initial Registry Contents . . . . . . . . . . . . . . 16
8.4. JSON Web Key Set Parameters Registry . . . . . . . . . . . 17 8.4. JSON Web Key Set Parameters Registry . . . . . . . . . . . 17
8.4.1. Registration Template . . . . . . . . . . . . . . . . 17 8.4.1. Registration Template . . . . . . . . . . . . . . . . 18
8.4.2. Initial Registry Contents . . . . . . . . . . . . . . 18 8.4.2. Initial Registry Contents . . . . . . . . . . . . . . 18
8.5. Media Type Registration . . . . . . . . . . . . . . . . . 18 8.5. Media Type Registration . . . . . . . . . . . . . . . . . 18
8.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 8.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Key Provenance and Trust . . . . . . . . . . . . . . . . . 19 9.1. Key Provenance and Trust . . . . . . . . . . . . . . . . . 20
9.2. Preventing Disclosure of Non-Public Key Information . . . 20 9.2. Preventing Disclosure of Non-Public Key Information . . . 20
9.3. RSA Private Key Representations and Blinding . . . . . . . 20 9.3. RSA Private Key Representations and Blinding . . . . . . . 20
9.4. Key Entropy and Random Values . . . . . . . . . . . . . . 20 9.4. Key Entropy and Random Values . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Example JSON Web Key Sets . . . . . . . . . . . . . . 23 Appendix A. Example JSON Web Key Sets . . . . . . . . . . . . . . 23
A.1. Example Public Keys . . . . . . . . . . . . . . . . . . . 23 A.1. Example Public Keys . . . . . . . . . . . . . . . . . . . 23
A.2. Example Private Keys . . . . . . . . . . . . . . . . . . . 23 A.2. Example Private Keys . . . . . . . . . . . . . . . . . . . 24
A.3. Example Symmetric Keys . . . . . . . . . . . . . . . . . . 25 A.3. Example Symmetric Keys . . . . . . . . . . . . . . . . . . 26
Appendix B. Example Use of "x5c" (X.509 Certificate Chain) Appendix B. Example Use of "x5c" (X.509 Certificate Chain)
Parameter . . . . . . . . . . . . . . . . . . . . . . 25 Parameter . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Example Encrypted RSA Private Key . . . . . . . . . . 26 Appendix C. Example Encrypted RSA Private Key . . . . . . . . . . 27
C.1. Plaintext RSA Private Key . . . . . . . . . . . . . . . . 27 C.1. Plaintext RSA Private Key . . . . . . . . . . . . . . . . 28
C.2. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 30 C.2. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 31
C.3. Content Encryption Key (CEK) . . . . . . . . . . . . . . . 30 C.3. Content Encryption Key (CEK) . . . . . . . . . . . . . . . 31
C.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 31 C.4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 32
C.5. Key Encryption . . . . . . . . . . . . . . . . . . . . . . 31 C.5. Key Encryption . . . . . . . . . . . . . . . . . . . . . . 32
C.6. Initialization Vector . . . . . . . . . . . . . . . . . . 31 C.6. Initialization Vector . . . . . . . . . . . . . . . . . . 32
C.7. Additional Authenticated Data . . . . . . . . . . . . . . 32 C.7. Additional Authenticated Data . . . . . . . . . . . . . . 33
C.8. Content Encryption . . . . . . . . . . . . . . . . . . . . 32 C.8. Content Encryption . . . . . . . . . . . . . . . . . . . . 33
C.9. Complete Representation . . . . . . . . . . . . . . . . . 35 C.9. Complete Representation . . . . . . . . . . . . . . . . . 36
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 37
Appendix E. Document History . . . . . . . . . . . . . . . . . . 37 Appendix E. Document History . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) [RFC7159] A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) [RFC7159]
data structure that represents a cryptographic key. This data structure that represents a cryptographic key. This
specification also defines a JSON Web Key Set (JWK Set) JSON data specification also defines a JSON Web Key Set (JWK Set) JSON data
structure that represents a set of JWKs. Cryptographic algorithms structure that represents a set of JWKs. Cryptographic algorithms
and identifiers for use with this specification are described in the and identifiers for use with this specification are described in the
separate JSON Web Algorithms (JWA) [JWA] specification and IANA separate JSON Web Algorithms (JWA) [JWA] specification and IANA
registries defined by that specification. registries defined by that specification.
skipping to change at page 5, line 41 skipping to change at page 5, line 41
4. JSON Web Key (JWK) Format 4. JSON Web Key (JWK) Format
A JSON Web Key (JWK) is a JSON object that represents a cryptographic A JSON Web Key (JWK) is a JSON object that represents a cryptographic
key. The members of the object represent properties of the key, key. The members of the object represent properties of the key,
including its value. This JSON object MAY contain white space and/or including its value. This JSON object MAY contain white space and/or
line breaks. This document defines the key parameters that are not line breaks. This document defines the key parameters that are not
algorithm specific, and thus common to many keys. algorithm specific, and thus common to many keys.
In addition to the common parameters, each JWK will have members that In addition to the common parameters, each JWK will have members that
are specific to the kind of key being represented. These members are key type-specific. These members represent the parameters of the
represent the parameters of the key. Section 6 of the JSON Web key. Section 6 of the JSON Web Algorithms (JWA) [JWA] specification
Algorithms (JWA) [JWA] specification defines multiple kinds of defines multiple kinds of cryptographic keys and their associated
cryptographic keys and their associated members. members.
The member names within a JWK MUST be unique; recipients MUST either The member names within a JWK MUST be unique; recipients MUST either
reject JWKs with duplicate member names or use a JSON parser that reject JWKs with duplicate member names or use a JSON parser that
returns only the lexically last duplicate member name, as specified returns only the lexically last duplicate member name, as specified
in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].
Additional members can be present in the JWK; if not understood by Additional members can be present in the JWK; if not understood by
implementations encountering them, they MUST be ignored. Member implementations encountering them, they MUST be ignored. Member
names used for representing key parameters for different keys types names used for representing key parameters for different keys types
need not be distinct. Any new member name should either be need not be distinct. Any new member name should either be
skipping to change at page 6, line 33 skipping to change at page 6, line 33
Algorithms (JWA) [JWA] specification. Algorithms (JWA) [JWA] specification.
The key type definitions include specification of the members to be The key type definitions include specification of the members to be
used for those key types. Additional members used with "kty" values used for those key types. Additional members used with "kty" values
can also be found in the IANA JSON Web Key Parameters registry can also be found in the IANA JSON Web Key Parameters registry
defined in Section 8.1. defined in Section 8.1.
4.2. "use" (Public Key Use) Parameter 4.2. "use" (Public Key Use) Parameter
The "use" (public key use) member identifies the intended use of the The "use" (public key use) member identifies the intended use of the
public key. The "use" parameter is intended for use cases in which public key. The "use" parameter is employed to indicate whether a
it is useful to distinguish between public signing keys and public public key is used for encrypting data or verifying the signature on
encryption keys. data.
Values defined by this specification are: Values defined by this specification are:
o "sig" (signature) o "sig" (signature)
o "enc" (encryption) o "enc" (encryption)
Other values MAY be used. Public Key Use values can be registered in Other values MAY be used. The "use" value is a case-sensitive
the IANA JSON Web Key Use registry defined in Section 8.2. The "use" string. Use of the "use" member is OPTIONAL, unless the application
value is a case-sensitive string. Use of the "use" member is requires its presence.
OPTIONAL, unless the application requires its presence.
When a key is used to wrap another key and a key use designation for When a key is used to wrap another key and a Public Key Use
the first key is desired, the "enc" (encryption) key use value SHOULD designation for the first key is desired, the "enc" (encryption) key
be used, since key wrapping is a kind of encryption. The "enc" value use value is used, since key wrapping is a kind of encryption. The
SHOULD also be used for public keys used for key agreement "enc" value is also be used for public keys used for key agreement
operations. (The "alg" member can be used to specify the particular operations.
cryptographic operation to be performed, when desired.)
Additional Public Key Use values can be registered in the IANA JSON
Web Key Use registry defined in Section 8.2. Registering any
extension values used is highly recommended when this specification
is used in open environments, in which multiple organizations need to
have a common understanding of any extensions used. However,
unregistered extension values can be used in closed environments, in
which the producing and consuming organization will always be the
same.
4.3. "key_ops" (Key Operations) Parameter 4.3. "key_ops" (Key Operations) Parameter
The "key_ops" (key operations) member identifies the operation(s) The "key_ops" (key operations) member identifies the operation(s)
that the key is intended to be used for. The "key_ops" parameter is that the key is intended to be used for. The "key_ops" parameter is
intended for use cases in which public, private, or symmetric keys intended for use cases in which public, private, or symmetric keys
may be present. may be present.
Its value is an array of key operation values. Values defined by Its value is an array of key operation values. Values defined by
this specification are: this specification are:
skipping to change at page 7, line 28 skipping to change at page 7, line 35
o "decrypt" (decrypt content and validate decryption, if applicable) o "decrypt" (decrypt content and validate decryption, if applicable)
o "wrapKey" (encrypt key) o "wrapKey" (encrypt key)
o "unwrapKey" (decrypt key and validate decryption, if applicable) o "unwrapKey" (decrypt key and validate decryption, if applicable)
o "deriveKey" (derive key) o "deriveKey" (derive key)
o "deriveBits" (derive bits not to be used as a key) o "deriveBits" (derive bits not to be used as a key)
(Note that the "key_ops" values intentionally match the "KeyUsage" (Note that the "key_ops" values intentionally match the "KeyUsage"
values defined in the Web Cryptography API [WebCrypto] values defined in the Web Cryptography API [WebCrypto]
specification.) specification.)
Other values MAY be used. Key operation values can be registered in Other values MAY be used. The key operation values are case-
the IANA JSON Web Key Operations registry defined in Section 8.3. sensitive strings. Duplicate key operation values MUST NOT be
The key operation values are case-sensitive strings. Duplicate key present in the array. Use of the "key_ops" member is OPTIONAL,
operation values MUST NOT be present in the array. unless the application requires its presence.
Use of the "key_ops" member is OPTIONAL, unless the application
requires its presence.
Multiple unrelated key operations SHOULD NOT be specified for a key Multiple unrelated key operations SHOULD NOT be specified for a key
because of the potential vulnerabilities associated with using the because of the potential vulnerabilities associated with using the
same key with multiple algorithms. Thus, the combinations "sign" same key with multiple algorithms. Thus, the combinations "sign"
with "verify", "encrypt" with "decrypt", and "wrapKey" with with "verify", "encrypt" with "decrypt", and "wrapKey" with
"unwrapKey" are permitted, but other combinations SHOULD NOT be used. "unwrapKey" are permitted, but other combinations SHOULD NOT be used.
Additional Key Operations values can be registered in the IANA JSON
Web Key Operations registry defined in Section 8.3. The same
considerations about registering extension values apply to the
"key_ops" member as do for the "use" member.
The "use" and "key_ops" JWK members SHOULD NOT be used together. The "use" and "key_ops" JWK members SHOULD NOT be used together.
Applications should specify which of these members they use, if Applications should specify which of these members they use, if
either is to be used by the application. either is to be used by the application.
4.4. "alg" (Algorithm) Parameter 4.4. "alg" (Algorithm) Parameter
The "alg" (algorithm) member identifies the algorithm intended for The "alg" (algorithm) member identifies the algorithm intended for
use with the key. The values used should either be registered in the use with the key. The values used should either be registered in the
IANA JSON Web Signature and Encryption Algorithms registry defined in IANA JSON Web Signature and Encryption Algorithms registry defined in
[JWA] or be a value that contains a Collision-Resistant Name. Use of [JWA] or be a value that contains a Collision-Resistant Name. Use of
this member is OPTIONAL. this member is OPTIONAL.
skipping to change at page 8, line 7 skipping to change at page 8, line 18
4.4. "alg" (Algorithm) Parameter 4.4. "alg" (Algorithm) Parameter
The "alg" (algorithm) member identifies the algorithm intended for The "alg" (algorithm) member identifies the algorithm intended for
use with the key. The values used should either be registered in the use with the key. The values used should either be registered in the
IANA JSON Web Signature and Encryption Algorithms registry defined in IANA JSON Web Signature and Encryption Algorithms registry defined in
[JWA] or be a value that contains a Collision-Resistant Name. Use of [JWA] or be a value that contains a Collision-Resistant Name. Use of
this member is OPTIONAL. this member is OPTIONAL.
4.5. "kid" (Key ID) Parameter 4.5. "kid" (Key ID) Parameter
The "kid" (key ID) member can be used to match a specific key. This The "kid" (key ID) member is used to match a specific key. This is
can be used, for instance, to choose among a set of keys within a JWK used, for instance, to choose among a set of keys within a JWK Set
Set during key rollover. The structure of the "kid" value is during key rollover. The structure of the "kid" value is
unspecified. When "kid" values are used within a JWK Set, different unspecified. When "kid" values are used within a JWK Set, different
keys within the JWK Set SHOULD use distinct "kid" values. (One keys within the JWK Set SHOULD use distinct "kid" values. (One
example in which different keys might use the same "kid" value is if example in which different keys might use the same "kid" value is if
they have different "kty" (key type) values but are considered to be they have different "kty" (key type) values but are considered to be
equivalent alternatives by the application using them.) The "kid" equivalent alternatives by the application using them.) The "kid"
value is a case-sensitive string. Use of this member is OPTIONAL. value is a case-sensitive string. Use of this member is OPTIONAL.
When used with JWS or JWE, the "kid" value is used to match a JWS or When used with JWS or JWE, the "kid" value is used to match a JWS or
JWE "kid" Header Parameter value. JWE "kid" Header Parameter value.
skipping to change at page 8, line 34 skipping to change at page 8, line 45
[RFC5280]. The identified resource MUST provide a representation of [RFC5280]. The identified resource MUST provide a representation of
the certificate or certificate chain that conforms to RFC 5280 the certificate or certificate chain that conforms to RFC 5280
[RFC5280] in PEM encoded form [RFC1421]. The key in the first [RFC5280] in PEM encoded form [RFC1421]. The key in the first
certificate MUST match the public key represented by other members of certificate MUST match the public key represented by other members of
the JWK. The protocol used to acquire the resource MUST provide the JWK. The protocol used to acquire the resource MUST provide
integrity protection; an HTTP GET request to retrieve the certificate integrity protection; an HTTP GET request to retrieve the certificate
MUST use TLS [RFC2818, RFC5246]; the identity of the server MUST be MUST use TLS [RFC2818, RFC5246]; the identity of the server MUST be
validated, as per Section 6 of RFC 6125 [RFC6125]. Use of this validated, as per Section 6 of RFC 6125 [RFC6125]. Use of this
member is OPTIONAL. member is OPTIONAL.
While there is no requirement that members other than those While there is no requirement that optional JWK members providing key
representing the public key be populated when an "x5u" member is usage, algorithm, or other information be present when the "x5u"
present, doing so may improve interoperability for applications that member is used, doing so may improve interoperability for
do not handle PKIX certificates. If other members are present, the applications that do not handle PKIX certificates. If other members
contents of those members MUST be semantically consistent with the are present, the contents of those members MUST be semantically
related fields in the first certificate. For instance, if the "use" consistent with the related fields in the first certificate. For
member is present, then it needs to allow for only a subset of the instance, if the "use" member is present, then it MUST correspond to
usages that are permitted by the certificate. Similarly, if the the usage that is specified in the certificate, when it includes this
"alg" member is present, it should represent an algorithm that the information. Similarly, if the "alg" member is present, it MUST
certificate allows. correspond to the algorithm specified in the certificate.
4.7. "x5c" (X.509 Certificate Chain) Parameter 4.7. "x5c" (X.509 Certificate Chain) Parameter
The "x5c" (X.509 Certificate Chain) member contains a chain of one or The "x5c" (X.509 Certificate Chain) member contains a chain of one or
more PKIX certificates [RFC5280]. The certificate chain is more PKIX certificates [RFC5280]. The certificate chain is
represented as a JSON array of certificate value strings. Each represented as a JSON array of certificate value strings. Each
string in the array is a base64 encoded ([RFC4648] Section 4 -- not string in the array is a base64 encoded ([RFC4648] Section 4 -- not
base64url encoded) DER [ITU.X690.1994] PKIX certificate value. The base64url encoded) DER [ITU.X690.1994] PKIX certificate value. The
PKIX certificate containing the key value MUST be the first PKIX certificate containing the key value MUST be the first
certificate. This MAY be followed by additional certificates, with certificate. This MAY be followed by additional certificates, with
each subsequent certificate being the one used to certify the each subsequent certificate being the one used to certify the
previous one. The key in the first certificate MUST match the public previous one. The key in the first certificate MUST match the public
key represented by other members of the JWK. Use of this member is key represented by other members of the JWK. Use of this member is
OPTIONAL. OPTIONAL.
As with the "x5u" member, members other than those representing the As with the "x5u" member, optional JWK members providing key usage,
public key may also be populated when an "x5c" member is present. If algorithm, or other information MAY also be present when the "x5c"
other members are present, the contents of those members MUST be member is used. If other members are present, the contents of those
semantically consistent with the related fields in the first members MUST be semantically consistent with the related fields in
certificate. See the last paragraph of Section 4.6 for additional the first certificate. See the last paragraph of Section 4.6 for
guidance on this. additional guidance on this.
4.8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter 4.8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter
The "x5t" (X.509 Certificate SHA-1 Thumbprint) member is a base64url The "x5t" (X.509 Certificate SHA-1 Thumbprint) member is a base64url
encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an
X.509 certificate [RFC5280]. The key in the certificate MUST match X.509 certificate [RFC5280]. Note that certificate thumbprints are
the public key represented by other members of the JWK. Use of this also sometimes known as certificate fingerprints. The key in the
member is OPTIONAL. certificate MUST match the public key represented by other members of
the JWK. Use of this member is OPTIONAL.
As with the "x5u" member, members other than those representing the As with the "x5u" member, optional JWK members providing key usage,
public key may also be populated when an "x5t" member is present. If algorithm, or other information MAY also be present when the "x5t"
other members are present, the contents of those members MUST be member is used. If other members are present, the contents of those
semantically consistent with the related fields in the referenced members MUST be semantically consistent with the related fields in
certificate. See the last paragraph of Section 4.6 for additional the referenced certificate. See the last paragraph of Section 4.6
guidance on this. for additional guidance on this.
4.9. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Parameter 4.9. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Parameter
The "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) member is a The "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) member is a
base64url encoded SHA-256 thumbprint (a.k.a. digest) of the DER base64url encoded SHA-256 thumbprint (a.k.a. digest) of the DER
encoding of an X.509 certificate [RFC5280]. The key in the encoding of an X.509 certificate [RFC5280]. Note that certificate
certificate MUST match the public key represented by other members of thumbprints are also sometimes known as certificate fingerprints.
the JWK. Use of this member is OPTIONAL. The key in the certificate MUST match the public key represented by
other members of the JWK. Use of this member is OPTIONAL.
As with the "x5u" member, members other than those representing the As with the "x5u" member, optional JWK members providing key usage,
public key may also be populated when an "x5t#S256" member is algorithm, or other information MAY also be present when the
present. If other members are present, the contents of those members "x5t#S256" member is used. If other members are present, the
MUST be semantically consistent with the related fields in the contents of those members MUST be semantically consistent with the
referenced certificate. See the last paragraph of Section 4.6 for related fields in the referenced certificate. See the last paragraph
additional guidance on this. of Section 4.6 for additional guidance on this.
5. JSON Web Key Set (JWK Set) Format 5. JSON Web Key Set (JWK Set) Format
A JSON Web Key Set (JWK Set) is a JSON object that represents a set A JSON Web Key Set (JWK Set) is a JSON object that represents a set
of JWKs. The JSON object MUST have a "keys" member, which is an of JWKs. The JSON object MUST have a "keys" member, which is an
array of JWK objects. This JSON object MAY contain white space array of JWK objects. This JSON object MAY contain white space
and/or line breaks. and/or line breaks.
The member names within a JWK Set MUST be unique; recipients MUST The member names within a JWK Set MUST be unique; recipients MUST
either reject JWK Sets with duplicate member names or use a JSON either reject JWK Sets with duplicate member names or use a JSON
skipping to change at page 11, line 26 skipping to change at page 11, line 39
omitted. omitted.
See Appendix C for an example encrypted JWK. See Appendix C for an example encrypted JWK.
8. IANA Considerations 8. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC5226] basis
after a two-week review period on the [TBD]@ietf.org mailing list, on after a three-week review period on the [TBD]@ietf.org mailing list,
the advice of one or more Designated Experts. However, to allow for on the advice of one or more Designated Experts. However, to allow
the allocation of values prior to publication, the Designated for the allocation of values prior to publication, the Designated
Expert(s) may approve registration once they are satisfied that such Expert(s) may approve registration once they are satisfied that such
a specification will be published. a 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 the RFC Editor: The name for access token type: example"). [[ Note to the RFC Editor: The name
of the mailing list should be determined in consultation with the of the mailing list should be determined in consultation with the
IESG 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
skipping to change at page 19, line 36 skipping to change at page 20, line 7
9. Security Considerations 9. Security Considerations
All of the security issues that are pertinent to any cryptographic All of the security issues that are pertinent to any cryptographic
application must be addressed by JWS/JWE/JWK agents. Among these application must be addressed by JWS/JWE/JWK agents. Among these
issues are protecting the user's asymmetric private and symmetric issues are protecting the user's asymmetric private and symmetric
secret keys and employing countermeasures to various attacks. secret keys and employing countermeasures to various attacks.
9.1. Key Provenance and Trust 9.1. Key Provenance and Trust
One should place no more trust in the data associated with a key than One should place no more trust in the data cryptographically secured
in than the method by which it was obtained and in the by a key than in the method by which it was obtained and in the
trustworthiness of the entity asserting an association with the key. trustworthiness of the entity asserting an association with the key.
Any data associated with a key that is obtained in an untrusted Any data associated with a key that is obtained in an untrusted
manner should be treated with skepticism. See Section 10.3 of [JWS] manner should be treated with skepticism. See Section 10.3 of [JWS]
for security considerations on key origin authentication. for security considerations on key origin authentication.
The security considerations in Section 12.3 of XML DSIG 2.0 The security considerations in Section 12.3 of XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411] about the strength of a signature [W3C.NOTE-xmldsig-core2-20130411] about the strength of a signature
depending upon all the links in the security chain also apply to this depending upon all the links in the security chain also apply to this
specification. specification.
The TLS Requirements in Section 8 of [JWS] also apply to this The TLS Requirements in Section 8 of [JWS] also apply to this
specification. specification.
9.2. Preventing Disclosure of Non-Public Key Information 9.2. Preventing Disclosure of Non-Public Key Information
Private and symmetric keys MUST be protected from disclosure to Private and symmetric keys MUST be protected from disclosure to
unintended parties. One recommended means of doing so is to encrypt unintended parties. One recommended means of doing so is to encrypt
JWKs or JWK Sets containing them by using the JWK or JWK Set value as JWKs or JWK Sets containing them by using the JWK or JWK Set value as
the plaintext of a JWE. the plaintext of a JWE. Of course, this requires that there be a
secure way to obtain the key used to encrypt the non-public key
information to the intended party and a secure way for that party to
obtain the corresponding decryption key.
The security considerations in RFC 3447 [RFC3447] and RFC 6030 The security considerations in RFC 3447 [RFC3447] and RFC 6030
[RFC6030] about protecting private and symmetric keys, key usage, and [RFC6030] about protecting private and symmetric keys, key usage, and
information leakage also apply to this specification. information leakage also apply to this specification.
9.3. RSA Private Key Representations and Blinding 9.3. RSA Private Key Representations and Blinding
The RSA Key blinding operation [Kocher], which is a defense against The RSA Key blinding operation [Kocher], which is a defense against
some timing attacks, requires all of the RSA key values "n", "e", and some timing attacks, requires all of the RSA key values "n", "e", and
"d". However, some RSA private key representations do not include "d". However, some RSA private key representations do not include
skipping to change at page 27, line 7 skipping to change at page 28, line 7
This example encrypts an RSA private key to the recipient using This example encrypts an RSA private key to the recipient using
"PBES2-HS256+A128KW" for key encryption and "A128CBC+HS256" for "PBES2-HS256+A128KW" for key encryption and "A128CBC+HS256" for
content encryption. content encryption.
NOTE: Unless otherwise indicated, all line breaks are included solely NOTE: Unless otherwise indicated, all line breaks are included solely
for readability. for readability.
C.1. Plaintext RSA Private Key C.1. Plaintext RSA Private Key
The following RSA key is the plaintext for the encryption operation, The following RSA key is the plaintext for the authenticated
formatted as a JWK object: encryption operation, formatted as a JWK object:
{ {
"kty":"RSA", "kty":"RSA",
"kid":"juliet@capulet.lit", "kid":"juliet@capulet.lit",
"use":"enc", "use":"enc",
"n":"t6Q8PWSi1dkJj9hTP8hNYFlvadM7DflW9mWepOJhJ66w7nyoK1gPNqFMSQRy "n":"t6Q8PWSi1dkJj9hTP8hNYFlvadM7DflW9mWepOJhJ66w7nyoK1gPNqFMSQRy
O125Gp-TEkodhWr0iujjHVx7BcV0llS4w5ACGgPrcAd6ZcSR0-Iqom-QFcNP O125Gp-TEkodhWr0iujjHVx7BcV0llS4w5ACGgPrcAd6ZcSR0-Iqom-QFcNP
8Sjg086MwoqQU_LYywlAGZ21WSdS_PERyGFiNnj3QQlO8Yns5jCtLCRwLHL0 8Sjg086MwoqQU_LYywlAGZ21WSdS_PERyGFiNnj3QQlO8Yns5jCtLCRwLHL0
Pb1fEv45AuRIuUfVcPySBWYnDyGxvjYGDSM-AqWS9zIQ2ZilgT-GqUmipg0X Pb1fEv45AuRIuUfVcPySBWYnDyGxvjYGDSM-AqWS9zIQ2ZilgT-GqUmipg0X
OC0Cc20rgLe2ymLHjpHciCKVAbY5-L32-lSeZO-Os6U15_aXrk9Gw8cPUaX1 OC0Cc20rgLe2ymLHjpHciCKVAbY5-L32-lSeZO-Os6U15_aXrk9Gw8cPUaX1
skipping to change at page 30, line 21 skipping to change at page 31, line 21
The following example JWE Protected Header declares that: The following example JWE Protected Header declares that:
o the Content Encryption Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
PSE2-HS256+A128KW algorithm to produce the JWE Encrypted Key, PSE2-HS256+A128KW algorithm to produce the JWE Encrypted Key,
o the Salt Input ("p2s") value is [217, 96, 147, 112, 150, 117, 70, o the Salt Input ("p2s") value is [217, 96, 147, 112, 150, 117, 70,
247, 127, 8, 155, 137, 174, 42, 80, 215], 247, 127, 8, 155, 137, 174, 42, 80, 215],
o the Iteration Count ("p2c") value is 4096, o the Iteration Count ("p2c") value is 4096,
o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 o authenticated encryption is performed on the Plaintext using the
algorithm to produce the Ciphertext, and AES_128_CBC_HMAC_SHA_256 algorithm to produce the Ciphertext and
the Authentication Tag, and
o the content type is application/jwk+json. o the content type is application/jwk+json.
{ {
"alg":"PBES2-HS256+A128KW", "alg":"PBES2-HS256+A128KW",
"p2s":"2WCTcJZ1Rvd_CJuJripQ1w", "p2s":"2WCTcJZ1Rvd_CJuJripQ1w",
"p2c":4096, "p2c":4096,
"enc":"A128CBC-HS256", "enc":"A128CBC-HS256",
"cty":"jwk+json" "cty":"jwk+json"
} }
skipping to change at page 32, line 24 skipping to change at page 33, line 24
[123, 34, 97, 108, 103, 34, 58, 34, 80, 66, 69, 83, 50, 45, 72, 83, [123, 34, 97, 108, 103, 34, 58, 34, 80, 66, 69, 83, 50, 45, 72, 83,
50, 53, 54, 43, 65, 49, 50, 56, 75, 87, 34, 44, 34, 112, 50, 115, 34, 50, 53, 54, 43, 65, 49, 50, 56, 75, 87, 34, 44, 34, 112, 50, 115, 34,
58, 34, 50, 87, 67, 84, 99, 74, 90, 49, 82, 118, 100, 95, 67, 74, 58, 34, 50, 87, 67, 84, 99, 74, 90, 49, 82, 118, 100, 95, 67, 74,
117, 74, 114, 105, 112, 81, 49, 119, 34, 44, 34, 112, 50, 99, 34, 58, 117, 74, 114, 105, 112, 81, 49, 119, 34, 44, 34, 112, 50, 99, 34, 58,
52, 48, 57, 54, 44, 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67, 52, 48, 57, 54, 44, 34, 101, 110, 99, 34, 58, 34, 65, 49, 50, 56, 67,
66, 67, 45, 72, 83, 50, 53, 54, 34, 44, 34, 99, 116, 121, 34, 58, 34, 66, 67, 45, 72, 83, 50, 53, 54, 34, 44, 34, 99, 116, 121, 34, 58, 34,
106, 119, 107, 43, 106, 115, 111, 110, 34, 125] 106, 119, 107, 43, 106, 115, 111, 110, 34, 125]
C.8. Content Encryption C.8. Content Encryption
Encrypt the Plaintext with AES_128_CBC_HMAC_SHA_256 using the CEK as Perform authenticated encryption on the Plaintext with the
the encryption key, the JWE Initialization Vector, and the Additional AES_128_CBC_HMAC_SHA_256 algorithm using the CEK as the encryption
Authenticated Data value above. The resulting Ciphertext is: key, the JWE Initialization Vector, and the Additional Authenticated
Data value above. The resulting Ciphertext is:
[3, 8, 65, 242, 92, 107, 148, 168, 197, 159, 77, 139, 25, 97, 42, [3, 8, 65, 242, 92, 107, 148, 168, 197, 159, 77, 139, 25, 97, 42,
131, 110, 199, 225, 56, 61, 127, 38, 64, 108, 91, 247, 167, 150, 98, 131, 110, 199, 225, 56, 61, 127, 38, 64, 108, 91, 247, 167, 150, 98,
112, 122, 99, 235, 132, 50, 28, 46, 56, 170, 169, 89, 220, 145, 38, 112, 122, 99, 235, 132, 50, 28, 46, 56, 170, 169, 89, 220, 145, 38,
157, 148, 224, 66, 140, 8, 169, 146, 117, 222, 54, 242, 28, 31, 11, 157, 148, 224, 66, 140, 8, 169, 146, 117, 222, 54, 242, 28, 31, 11,
129, 227, 226, 169, 66, 117, 133, 254, 140, 216, 115, 203, 131, 60, 129, 227, 226, 169, 66, 117, 133, 254, 140, 216, 115, 203, 131, 60,
60, 47, 233, 132, 121, 13, 35, 188, 53, 19, 172, 77, 59, 54, 211, 60, 47, 233, 132, 121, 13, 35, 188, 53, 19, 172, 77, 59, 54, 211,
158, 172, 25, 60, 111, 0, 80, 201, 158, 160, 210, 68, 55, 12, 67, 158, 172, 25, 60, 111, 0, 80, 201, 158, 160, 210, 68, 55, 12, 67,
136, 130, 87, 216, 197, 95, 62, 20, 155, 205, 5, 140, 27, 168, 221, 136, 130, 87, 216, 197, 95, 62, 20, 155, 205, 5, 140, 27, 168, 221,
65, 114, 78, 157, 254, 46, 206, 182, 52, 135, 87, 239, 3, 34, 186, 65, 114, 78, 157, 254, 46, 206, 182, 52, 135, 87, 239, 3, 34, 186,
skipping to change at page 37, line 16 skipping to change at page 38, line 16
Thanks to Matt Miller for creating the encrypted key example and to Thanks to Matt Miller for creating the encrypted key example and to
Edmund Jay and Brian Campbell for validating the example. Edmund Jay and Brian Campbell for validating the example.
This specification is the work of the JOSE Working Group, which This specification is the work of the JOSE Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that influenced this specification: that influenced this specification:
Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de
Medeiros, Joe Hildebrand, Edmund Jay, Ben Laurie, James Manger, Matt Medeiros, Joe Hildebrand, Edmund Jay, Stephen Kent, Ben Laurie, James
Miller, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Manger, Matt Miller, Kathleen Moriarty, Chuck Mortimore, Tony
Eric Rescorla, Nat Sakimura, Jim Schaad, Ryan Sleevi, Paul Tarjan, Nadalin, Axel Nennker, John Panzer, Eric Rescorla, Nat Sakimura, Jim
Hannes Tschofenig, and Sean Turner. Schaad, Ryan Sleevi, Paul Tarjan, Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors during the creation of this specification.
Appendix E. Document History Appendix E. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-33
o Addressed secdir review comments by Stephen Kent for which
resolutions had mistakenly been omitted in the previous draft.
o Acknowledged additional contributors.
-32 -32
o Addressed Gen-ART review comments by Russ Housley. o Addressed Gen-ART review comments by Russ Housley.
o Addressed secdir review comments by Stephen Kent. o Addressed secdir review comments by Stephen Kent.
-31 -31
o No changes were made, other than to the version number and date. o No changes were made, other than to the version number and date.
 End of changes. 36 change blocks. 
109 lines changed or deleted 133 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/