< 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.
	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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/