< draft-ietf-jose-json-web-encryption-33.txt		draft-ietf-jose-json-web-encryption-34.txt >
	JOSE Working Group M. Jones		JOSE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track J. Hildebrand		Intended status: Standards Track J. Hildebrand
	Expires: March 29, 2015 Cisco		Expires: April 17, 2015 Cisco
	September 25, 2014		October 14, 2014
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	draft-ietf-jose-json-web-encryption-33		draft-ietf-jose-json-web-encryption-34
	Abstract		Abstract
	JSON Web Encryption (JWE) represents encrypted content using		JSON Web Encryption (JWE) represents encrypted content using
	JavaScript Object Notation (JSON) based data structures.		JavaScript Object Notation (JSON) based data structures.
	Cryptographic algorithms and identifiers for use with this		Cryptographic algorithms and identifiers for use with this
	specification are described in the separate JSON Web Algorithms (JWA)		specification are described in the separate JSON Web Algorithms (JWA)
	specification and IANA registries defined by that specification.		specification and IANA registries defined by that specification.
	Related digital signature and MAC capabilities are described in the		Related digital signature and MAC capabilities are described in the
	separate JSON Web Signature (JWS) specification.		separate JSON Web Signature (JWS) specification.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 29, 2015.		This Internet-Draft will expire on April 17, 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 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	10.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 24		10.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 24
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 26		11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26		11.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26
	11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . . 27		11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . . 27
	11.3. Using Matching Algorithm Strengths . . . . . . . . . . . . 27		11.3. Using Matching Algorithm Strengths . . . . . . . . . . . . 27
	11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 27		11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 27
	11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 27		11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 28		12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	12.2. Informative References . . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 29		Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 30
	A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 30		A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 30
	A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 30		A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 30
	A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 30		A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 30
	A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 30		A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 31
	A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 32		A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 32
	A.1.5. Additional Authenticated Data . . . . . . . . . . . . 32		A.1.5. Additional Authenticated Data . . . . . . . . . . . . 32
	A.1.6. Content Encryption . . . . . . . . . . . . . . . . . . 32		A.1.6. Content Encryption . . . . . . . . . . . . . . . . . . 32
	A.1.7. Complete Representation . . . . . . . . . . . . . . . 33		A.1.7. Complete Representation . . . . . . . . . . . . . . . 33
	A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . . 33		A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . . 33
	A.2. Example JWE using RSAES-PKCS1-V1_5 and		A.2. Example JWE using RSAES-PKCS1-V1_5 and
	AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 33		AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 33
	A.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 34		A.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 34
	A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 34		A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 34
	A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 34		A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 34
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 40 ¶
	1.1. Notational Conventions		1.1. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in Key		"OPTIONAL" in this document are to be interpreted as described in Key
	words for use in RFCs to Indicate Requirement Levels [RFC2119]. If		words for use in RFCs to Indicate Requirement Levels [RFC2119]. If
	these words are used without being spelled in uppercase then they are		these words are used without being spelled in uppercase then they are
	to be interpreted with their normal natural language meanings.		to be interpreted with their normal natural language meanings.
	BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per		BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
	Section 2.		Section 2 of [JWS].
	UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation		UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
	of STRING.		of STRING.
	ASCII(STRING) denotes the octets of the ASCII [USASCII]		ASCII(STRING) denotes the octets of the ASCII [USASCII]
	representation of STRING.		representation of STRING.
	The concatenation of two values A and B is denoted as A || B.		The concatenation of two values A and B is denoted as A || B.
	2. Terminology		2. Terminology
	These terms defined by the JSON Web Signature (JWS) [JWS]		These terms defined by the JSON Web Signature (JWS) [JWS]
	specification are incorporated into this specification: "JSON Web		specification are incorporated into this specification: "JSON Web
	Signature (JWS)", "Base64url Encoding", "Collision-Resistant Name",		Signature (JWS)", "Base64url Encoding", "Collision-Resistant Name",
	"Header Parameter", "JOSE Header", and "StringOrURI".		"Header Parameter", "JOSE Header", and "StringOrURI".
			These terms defined by the Internet Security Glossary, Version 2
			[RFC4949] are incorporated into this specification: "Ciphertext" and
			"Plaintext".
	These terms are defined by this specification:		These terms are defined by this specification:
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	A data structure representing an encrypted and integrity protected		A data structure representing an encrypted and integrity protected
	message.		message.
	Authenticated Encryption with Associated Data (AEAD)		Authenticated Encryption with Associated Data (AEAD)
	An AEAD algorithm is one that encrypts the Plaintext, allows		An AEAD algorithm is one that encrypts the Plaintext, allows
	Additional Authenticated Data to be specified, and provides an		Additional Authenticated Data to be specified, and provides an
	integrated content integrity check over the Ciphertext and		integrated content integrity check over the Ciphertext and
	Additional Authenticated Data. AEAD algorithms accept two inputs,		Additional Authenticated Data. AEAD algorithms accept two inputs,
	the Plaintext and the Additional Authenticated Data value, and		the Plaintext and the Additional Authenticated Data value, and
	produce two outputs, the Ciphertext and the Authentication Tag		produce two outputs, the Ciphertext and the Authentication Tag
	value. AES Galois/Counter Mode (GCM) is one such algorithm.		value. AES Galois/Counter Mode (GCM) is one such algorithm.
	Plaintext
	The sequence of octets to be encrypted -- a.k.a., the message.
	The plaintext can contain an arbitrary sequence of octets.
	Ciphertext
	An encrypted representation of the Plaintext.
	Additional Authenticated Data (AAD)		Additional Authenticated Data (AAD)
	An input to an AEAD operation that is integrity protected but not		An input to an AEAD operation that is integrity protected but not
	encrypted.		encrypted.
	Authentication Tag		Authentication Tag
	An output of an AEAD operation that ensures the integrity of the		An output of an AEAD operation that ensures the integrity of the
	Ciphertext and the Additional Authenticated Data. Note that some		Ciphertext and the Additional Authenticated Data. Note that some
	algorithms may not use an Authentication Tag, in which case this		algorithms may not use an Authentication Tag, in which case this
	value is the empty octet sequence.		value is the empty octet sequence.
	skipping to change at page 9, line 19 ¶		skipping to change at page 9, line 19 ¶
	JWE utilizes authenticated encryption to ensure the confidentiality		JWE utilizes authenticated encryption to ensure the confidentiality
	and integrity of the Plaintext and the integrity of the JWE Protected		and integrity of the Plaintext and the integrity of the JWE Protected
	Header and the JWE AAD.		Header and the JWE AAD.
	This document defines two serializations for JWE objects: a compact,		This document defines two serializations for JWE objects: a compact,
	URL-safe serialization called the JWE Compact Serialization and a		URL-safe serialization called the JWE Compact Serialization and a
	JSON serialization called the JWE JSON Serialization. In both		JSON serialization called the JWE JSON Serialization. In both
	serializations, the JWE Protected Header, JWE Encrypted Key, JWE		serializations, the JWE Protected Header, JWE Encrypted Key, JWE
	Initialization Vector, JWE Ciphertext, and JWE Authentication Tag are		Initialization Vector, JWE Ciphertext, and JWE Authentication Tag are
	base64url encoded for transmission, since JSON lacks a way to		base64url encoded, since JSON lacks a way to directly represent
	directly represent arbitrary octet sequences. When present, the JWE		arbitrary octet sequences. When present, the JWE AAD is also
	AAD is also base64url encoded for transmission.		base64url encoded.
	3.1. JWE Compact Serialization Overview		3.1. JWE Compact Serialization Overview
	In the JWE Compact Serialization, no JWE Shared Unprotected Header or		In the JWE Compact Serialization, no JWE Shared Unprotected Header or
	JWE Per-Recipient Unprotected Header are used. In this case, the		JWE Per-Recipient Unprotected Header are used. In this case, the
	JOSE Header and the JWE Protected Header are the same.		JOSE Header and the JWE Protected Header are the same.
	In the JWE Compact Serialization, a JWE object is represented as the		In the JWE Compact Serialization, a JWE object is represented as the
	concatenation:		concatenation:
	BASE64URL(UTF8(JWE Protected Header)) || '.' ||		BASE64URL(UTF8(JWE Protected Header)) || '.' ||
	BASE64URL(JWE Encrypted Key) || '.' ||		BASE64URL(JWE Encrypted Key) || '.' ||
	BASE64URL(JWE Initialization Vector) || '.' ||		BASE64URL(JWE Initialization Vector) || '.' ||
	BASE64URL(JWE Ciphertext) || '.' ||		BASE64URL(JWE Ciphertext) || '.' ||
	BASE64URL(JWE Authentication Tag)		BASE64URL(JWE Authentication Tag)
			See Section 7.1 for more information about the JWE Compact
			Serialization.
	3.2. JWE JSON Serialization Overview		3.2. JWE JSON Serialization Overview
	In the JWE JSON Serialization, one or more of the JWE Protected		In the JWE JSON Serialization, one or more of the JWE Protected
	Header, JWE Shared Unprotected Header, and JWE Per-Recipient		Header, JWE Shared Unprotected Header, and JWE Per-Recipient
	Unprotected Header MUST be present. In this case, the members of the		Unprotected Header MUST be present. In this case, the members of the
	JOSE Header are the combination of the members of the JWE Protected		JOSE Header are the union of the members of the JWE Protected Header,
	Header, JWE Shared Unprotected Header, and JWE Per-Recipient		JWE Shared Unprotected Header, and JWE Per-Recipient Unprotected
	Unprotected Header values that are present.		Header values that are present.
	In the JWE JSON Serialization, a JWE object is represented as the		In the JWE JSON Serialization, a JWE object is represented as the
	combination of these eight values,		combination of these eight values,
	BASE64URL(UTF8(JWE Protected Header)),		BASE64URL(UTF8(JWE Protected Header)),
	JWE Shared Unprotected Header,		JWE Shared Unprotected Header,
	JWE Per-Recipient Unprotected Header,		JWE Per-Recipient Unprotected Header,
	BASE64URL(JWE Encrypted Key),		BASE64URL(JWE Encrypted Key),
	BASE64URL(JWE Initialization Vector),		BASE64URL(JWE Initialization Vector),
	BASE64URL(JWE Ciphertext),		BASE64URL(JWE Ciphertext),
	BASE64URL(JWE Authentication Tag), and		BASE64URL(JWE Authentication Tag), and
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 29 ¶
	Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV		Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
	mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8		mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
	1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi		1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
	6UklfCpIMfIjf7iGdXKHzg.		6UklfCpIMfIjf7iGdXKHzg.
	48V1_ALb6US04U3b.		48V1_ALb6US04U3b.
	5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji		5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
	SdiwkIr3ajwQzaBtQD_A.		SdiwkIr3ajwQzaBtQD_A.
	XFBoMYUZodetZdvTiFvSkQ		XFBoMYUZodetZdvTiFvSkQ
	See Appendix A.1 for the complete details of computing this JWE. See		See Appendix A.1 for the complete details of computing this JWE. See
	other parts of Appendix A for additional examples.		other parts of Appendix A for additional examples, including an
			example using the JWE JSON Serialization in Appendix A.4.
	4. JOSE Header		4. JOSE Header
	For a JWE object, the members of the JSON object(s) representing the		For a JWE object, the members of the JSON object(s) representing the
	JOSE Header describe the encryption applied to the Plaintext and		JOSE Header describe the encryption applied to the Plaintext and
	optionally additional properties of the JWE. The Header Parameter		optionally additional properties of the JWE. The Header Parameter
	names within the JOSE Header MUST be unique, just as described in		names within the JOSE Header MUST be unique, just as described in
	Section 4 of [JWS]. The rules about handling Header Parameters that		Section 4 of [JWS]. The rules about handling Header Parameters that
	are not understood by the implementation are also the same. The		are not understood by the implementation are also the same. The
	classes of Header Parameter names are likewise the same.		classes of Header Parameter names are likewise the same.
	skipping to change at page 16, line 27 ¶		skipping to change at page 16, line 27 ¶
	10. Compute the encoded initialization vector value BASE64URL(JWE		10. Compute the encoded initialization vector value BASE64URL(JWE
	Initialization Vector).		Initialization Vector).
	11. If a "zip" parameter was included, compress the Plaintext using		11. If a "zip" parameter was included, compress the Plaintext using
	the specified compression algorithm and let M be the octet		the specified compression algorithm and let M be the octet
	sequence representing the compressed Plaintext; otherwise, let M		sequence representing the compressed Plaintext; otherwise, let M
	be the octet sequence representing the Plaintext.		be the octet sequence representing the Plaintext.
	12. Create the JSON object(s) containing the desired set of Header		12. Create the JSON object(s) containing the desired set of Header
	Parameters, which together comprise the JOSE Header: the JWE		Parameters, which together comprise the JOSE Header: if the JWE
	Protected Header, and if the JWE JSON Serialization is being		Compact Serialization is being used, the JWE Protected Header,
	used, the JWE Shared Unprotected Header and the JWE Per-		or if the JWE JSON Serialization is being used, one or more of
	Recipient Unprotected Header.		the JWE Protected Header, the JWE Shared Unprotected Header, and
			the JWE Per-Recipient Unprotected Header.
	13. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE		13. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE
	Protected Header)). If the JWE Protected Header is not present		Protected Header)). If the JWE Protected Header is not present
	(which can only happen when using the JWE JSON Serialization and		(which can only happen when using the JWE JSON Serialization and
	no "protected" member is present), let this value be the empty		no "protected" member is present), let this value be the empty
	string.		string.
	14. Let the Additional Authenticated Data encryption parameter be		14. Let the Additional Authenticated Data encryption parameter be
	ASCII(Encoded Protected Header). However if a JWE AAD value is		ASCII(Encoded Protected Header). However if a JWE AAD value is
	present (which can only be the case when using the JWE JSON		present (which can only be the case when using the JWE JSON
	skipping to change at page 17, line 8 ¶		skipping to change at page 17, line 10 ¶
	Additional Authenticated Data value using the specified content		Additional Authenticated Data value using the specified content
	encryption algorithm to create the JWE Ciphertext value and the		encryption algorithm to create the JWE Ciphertext value and the
	JWE Authentication Tag (which is the Authentication Tag output		JWE Authentication Tag (which is the Authentication Tag output
	from the encryption operation).		from the encryption operation).
	16. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).		16. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).
	17. Compute the encoded authentication tag value BASE64URL(JWE		17. Compute the encoded authentication tag value BASE64URL(JWE
	Authentication Tag).		Authentication Tag).
	18. The five encoded values are used in both the JWE Compact		18. If a JWE AAD value is present, compute the encoded AAD value
	Serialization and the JWE JSON Serialization representations.
	19. If a JWE AAD value is present, compute the encoded AAD value
	BASE64URL(JWE AAD).		BASE64URL(JWE AAD).
	20. Create the desired serialized output. The Compact Serialization		19. Create the desired serialized output. The Compact Serialization
	of this result is the string BASE64URL(UTF8(JWE Protected		of this result is the string BASE64URL(UTF8(JWE Protected
	Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' ||		Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' ||
	BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE		BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE
	Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The		Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The
	JWE JSON Serialization is described in Section 7.2.		JWE JSON Serialization is described in Section 7.2.
	5.2. Message Decryption		5.2. Message Decryption
	The message decryption process is the reverse of the encryption		The message decryption process is the reverse of the encryption
	process. The order of the steps is not significant in cases where		process. The order of the steps is not significant in cases where
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 5 ¶
	Serialization, these components also include the base64url		Serialization, these components also include the base64url
	encoded representation of the JWE AAD and the unencoded JWE		encoded representation of the JWE AAD and the unencoded JWE
	Shared Unprotected Header and JWE Per-Recipient Unprotected		Shared Unprotected Header and JWE Per-Recipient Unprotected
	Header values. When using the JWE Compact Serialization, the		Header values. When using the JWE Compact Serialization, the
	JWE Protected Header, the JWE Encrypted Key, the JWE		JWE Protected Header, the JWE Encrypted Key, the JWE
	Initialization Vector, the JWE Ciphertext, and the JWE		Initialization Vector, the JWE Ciphertext, and the JWE
	Authentication Tag are represented as base64url encoded values		Authentication Tag are represented as base64url encoded values
	in that order, separated by four period ('.') characters. The		in that order, separated by four period ('.') characters. The
	JWE JSON Serialization is described in Section 7.2.		JWE JSON Serialization is described in Section 7.2.
	2. The encoded representations of the JWE Protected Header, the JWE		2. Base64url decode the encoded representations of the JWE
	Encrypted Key, the JWE Initialization Vector, the JWE		Protected Header, the JWE Encrypted Key, the JWE Initialization
	Ciphertext, the JWE Authentication Tag, and the JWE AAD MUST be		Vector, the JWE Ciphertext, the JWE Authentication Tag, and the
	successfully base64url decoded following the restriction that no		JWE AAD, following the restriction that no line breaks, white
	padding characters have been used.		space, or other additional characters have been used.
	3. The octet sequence resulting from decoding the encoded JWE		3. Verify that the octet sequence resulting from decoding the
	Protected Header MUST be a UTF-8 encoded representation of a		encoded JWE Protected Header is a UTF-8 encoded representation
	completely valid JSON object conforming to RFC 7159 [RFC7159],		of a completely valid JSON object conforming to RFC 7159
	which is the JWE Protected Header.		[RFC7159]; let the JWE Protected Header be this JSON object.
	4. If using the JWE Compact Serialization, let the JOSE Header be		4. If using the JWE Compact Serialization, let the JOSE Header be
	the JWE Protected Header. Otherwise, when using the JWE JSON		the JWE Protected Header. Otherwise, when using the JWE JSON
	Serialization, let the JOSE Header be the union of the members		Serialization, let the JOSE Header be the union of the members
	of the JWE Protected Header, the JWE Shared Unprotected Header		of the JWE Protected Header, the JWE Shared Unprotected Header
	and the corresponding JWE Per-Recipient Unprotected Header, all		and the corresponding JWE Per-Recipient Unprotected Header, all
	of which must be completely valid JSON objects.		of which must be completely valid JSON objects. During this
			step, verify that the resulting JOSE Header does not contain
	5. The resulting JOSE Header MUST NOT contain duplicate Header		duplicate Header Parameter names. When using the JWE JSON
	Parameter names. When using the JWE JSON Serialization, this		Serialization, this restriction includes that the same Header
	restriction includes that the same Header Parameter name also		Parameter name also MUST NOT occur in distinct JSON object
	MUST NOT occur in distinct JSON object values that together		values that together comprise the JOSE Header.
	comprise the JOSE Header.
	6. Verify that the implementation understands and can process all		5. Verify that the implementation understands and can process all
	fields that it is required to support, whether required by this		fields that it is required to support, whether required by this
	specification, by the algorithms being used, or by the "crit"		specification, by the algorithms being used, or by the "crit"
	Header Parameter value, and that the values of those parameters		Header Parameter value, and that the values of those parameters
	are also understood and supported.		are also understood and supported.
	7. Determine the Key Management Mode employed by the algorithm		6. Determine the Key Management Mode employed by the algorithm
	specified by the "alg" (algorithm) Header Parameter.		specified by the "alg" (algorithm) Header Parameter.
	8. Verify that the JWE uses a key known to the recipient.		7. Verify that the JWE uses a key known to the recipient.
	9. When Direct Key Agreement or Key Agreement with Key Wrapping are		8. When Direct Key Agreement or Key Agreement with Key Wrapping are
	employed, use the key agreement algorithm to compute the value		employed, use the key agreement algorithm to compute the value
	of the agreed upon key. When Direct Key Agreement is employed,		of the agreed upon key. When Direct Key Agreement is employed,
	let the Content Encryption Key (CEK) be the agreed upon key.		let the Content Encryption Key (CEK) be the agreed upon key.
	When Key Agreement with Key Wrapping is employed, the agreed		When Key Agreement with Key Wrapping is employed, the agreed
	upon key will be used to decrypt the JWE Encrypted Key.		upon key will be used to decrypt the JWE Encrypted Key.
	10. When Key Wrapping, Key Encryption, or Key Agreement with Key		9. When Key Wrapping, Key Encryption, or Key Agreement with Key
	Wrapping are employed, decrypt the JWE Encrypted Key to produce		Wrapping are employed, decrypt the JWE Encrypted Key to produce
	the Content Encryption Key (CEK). The CEK MUST have a length		the Content Encryption Key (CEK). The CEK MUST have a length
	equal to that required for the content encryption algorithm.		equal to that required for the content encryption algorithm.
	Note that when there are multiple recipients, each recipient		Note that when there are multiple recipients, each recipient
	will only be able decrypt any JWE Encrypted Key values that were		will only be able decrypt any JWE Encrypted Key values that were
	encrypted to a key in that recipient's possession. It is		encrypted to a key in that recipient's possession. It is
	therefore normal to only be able to decrypt one of the per-		therefore normal to only be able to decrypt one of the per-
	recipient JWE Encrypted Key values to obtain the CEK value.		recipient JWE Encrypted Key values to obtain the CEK value.
	Also, see Section 11.5 for security considerations on mitigating		Also, see Section 11.5 for security considerations on mitigating
	timing attacks.		timing attacks.
	11. When Direct Key Agreement or Direct Encryption are employed,		10. When Direct Key Agreement or Direct Encryption are employed,
	verify that the JWE Encrypted Key value is empty octet sequence.		verify that the JWE Encrypted Key value is empty octet sequence.
	12. When Direct Encryption is employed, let the Content Encryption		11. When Direct Encryption is employed, let the Content Encryption
	Key (CEK) be the shared symmetric key.		Key (CEK) be the shared symmetric key.
	13. Record whether the CEK could be successfully determined for this		12. Record whether the CEK could be successfully determined for this
	recipient or not.		recipient or not.
	14. If the JWE JSON Serialization is being used, repeat this process		13. If the JWE JSON Serialization is being used, repeat this process
	(steps 4-13) for each recipient contained in the representation.		(steps 4-12) for each recipient contained in the representation.
	15. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE		14. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE
	Protected Header)). If the JWE Protected Header is not present		Protected Header)). If the JWE Protected Header is not present
	(which can only happen when using the JWE JSON Serialization and		(which can only happen when using the JWE JSON Serialization and
	no "protected" member is present), let this value be the empty		no "protected" member is present), let this value be the empty
	string.		string.
	16. Let the Additional Authenticated Data encryption parameter be		15. Let the Additional Authenticated Data encryption parameter be
	ASCII(Encoded Protected Header). However if a JWE AAD value is		ASCII(Encoded Protected Header). However if a JWE AAD value is
	present (which can only be the case when using the JWE JSON		present (which can only be the case when using the JWE JSON
	Serialization), instead let the Additional Authenticated Data		Serialization), instead let the Additional Authenticated Data
	encryption parameter be ASCII(Encoded Protected Header || '.' ||		encryption parameter be ASCII(Encoded Protected Header || '.' ||
	BASE64URL(JWE AAD)).		BASE64URL(JWE AAD)).
	17. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization		16. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization
	Vector, the Additional Authenticated Data value, and the JWE		Vector, the Additional Authenticated Data value, and the JWE
	Authentication Tag (which is the Authentication Tag input to the		Authentication Tag (which is the Authentication Tag input to the
	calculation) using the specified content encryption algorithm,		calculation) using the specified content encryption algorithm,
	returning the decrypted plaintext and validating the JWE		returning the decrypted plaintext and validating the JWE
	Authentication Tag in the manner specified for the algorithm,		Authentication Tag in the manner specified for the algorithm,
	rejecting the input without emitting any decrypted output if the		rejecting the input without emitting any decrypted output if the
	JWE Authentication Tag is incorrect.		JWE Authentication Tag is incorrect.
	18. If a "zip" parameter was included, uncompress the decrypted		17. If a "zip" parameter was included, uncompress the decrypted
	plaintext using the specified compression algorithm.		plaintext using the specified compression algorithm.
	19. If there was no recipient for which all of the decryption steps		18. If there was no recipient for which all of the decryption steps
	succeeded, then the JWE MUST be rejected. Otherwise, output the		succeeded, then the JWE MUST be rejected. Otherwise, output the
	Plaintext. In the JWE JSON Serialization case, also return a		Plaintext. In the JWE JSON Serialization case, also return a
	result to the application indicating for which of the recipients		result to the application indicating for which of the recipients
	the decryption succeeded and failed.		the decryption succeeded and failed.
	Finally, note that it is an application decision which algorithms are		Finally, note that it is an application decision which algorithms may
	acceptable in a given context. Even if a JWE can be successfully		be used in a given context. Even if a JWE can be successfully
	decrypted, unless the algorithms used in the JWE are acceptable to		decrypted, unless the algorithms used in the JWE are acceptable to
	the application, it SHOULD reject the JWE.		the application, it SHOULD reject the JWE.
	5.3. String Comparison Rules		5.3. String Comparison Rules
	The string comparison rules for this specification are the same as		The string comparison rules for this specification are the same as
	those defined in Section 5.3 of [JWS].		those defined in Section 5.3 of [JWS].
	6. Key Identification		6. Key Identification
	skipping to change at page 21, line 52 ¶		skipping to change at page 21, line 52 ¶
	BASE64URL(JWE Ciphertext).		BASE64URL(JWE Ciphertext).
	tag		tag
	The "tag" member MUST be present and contain the value		The "tag" member MUST be present and contain the value
	BASE64URL(JWE Authentication Tag) when the JWE Authentication Tag		BASE64URL(JWE Authentication Tag) when the JWE Authentication Tag
	value is non-empty; otherwise, it MUST be absent.		value is non-empty; otherwise, it MUST be absent.
	recipients		recipients
	The "recipients" member value MUST be an array of JSON objects.		The "recipients" member value MUST be an array of JSON objects.
	Each object contains information specific to a single recipient.		Each object contains information specific to a single recipient.
	This member MUST be present, even if the array elements contain		This member MUST be present with exactly one array element per
	only the empty JSON object "{}" (which can happen when all Header		recipient, even if some or all of the array element values are the
	Parameter values are shared between all recipients and when no		empty JSON object "{}" (which can happen when all Header Parameter
	encrypted key is used, such as when doing Direct Encryption).		values are shared between all recipients and when no encrypted key
			is used, such as when doing Direct Encryption).
	The following members are defined for use in the JSON objects that		The following members are defined for use in the JSON objects that
	are elements of the "recipients" array:		are elements of the "recipients" array:
	header		header
	The "header" member MUST be present and contain the value JWE Per-		The "header" member MUST be present and contain the value JWE Per-
	Recipient Unprotected Header when the JWE Per-Recipient		Recipient Unprotected Header when the JWE Per-Recipient
	Unprotected Header value is non-empty; otherwise, it MUST be		Unprotected Header value is non-empty; otherwise, it MUST be
	absent. This value is represented as an unencoded JSON object,		absent. This value is represented as an unencoded JSON object,
	rather than as a string. These Header Parameter values are not		rather than as a string. These Header Parameter values are not
	skipping to change at page 27, line 52 ¶		skipping to change at page 27, line 52 ¶
	means, for instance, that if the key is marked as being for		means, for instance, that if the key is marked as being for
	"RSA-OAEP" only, any attempt to decrypt a message using the "RSA1_5"		"RSA-OAEP" only, any attempt to decrypt a message using the "RSA1_5"
	algorithm with that key should fail immediately due to invalid use of		algorithm with that key should fail immediately due to invalid use of
	the key.		the key.
	11.5. Timing Attacks		11.5. Timing Attacks
	To mitigate the attacks described in RFC 3218 [RFC3218], the		To mitigate the attacks described in RFC 3218 [RFC3218], the
	recipient MUST NOT distinguish between format, padding, and length		recipient MUST NOT distinguish between format, padding, and length
	errors of encrypted keys. It is strongly recommended, in the event		errors of encrypted keys. It is strongly recommended, in the event
	of receiving an improperly formatted key, that the receiver		of receiving an improperly formatted key, that the recipient
	substitute a randomly generated CEK and proceed to the next step, to		substitute a randomly generated CEK and proceed to the next step, to
	mitigate timing attacks.		mitigate timing attacks.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[JWA] Jones, M., "JSON Web Algorithms (JWA)",		[JWA] Jones, M., "JSON Web Algorithms (JWA)",
	draft-ietf-jose-json-web-algorithms (work in progress),		draft-ietf-jose-json-web-algorithms (work in progress),
	September 2014.		October 2014.
	[JWK] Jones, M., "JSON Web Key (JWK)",		[JWK] Jones, M., "JSON Web Key (JWK)",
	draft-ietf-jose-json-web-key (work in progress),		draft-ietf-jose-json-web-key (work in progress),
	September 2014.		October 2014.
	[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", draft-ietf-jose-json-web-signature (work		Signature (JWS)", draft-ietf-jose-json-web-signature (work
	in progress), September 2014.		in progress), October 2014.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, May 1996.		version 1.3", RFC 1951, May 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
			[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
			RFC 4949, August 2007.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014.		Interchange Format", RFC 7159, March 2014.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	skipping to change at page 46, line 19 ¶		skipping to change at page 46, line 19 ¶
	Rescorla for co-authoring many drafts of this specification.		Rescorla for co-authoring many drafts of this specification.
	Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund		Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund
	Jay for validating the examples in this specification.		Jay for validating the examples in this specification.
	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:
	Richard Barnes, John Bradley, Brian Campbell, Breno de Medeiros, Dick		Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de
	Hardt, Jeff Hodges, Russ Housley, Edmund Jay, Scott Kelly, Stephen		Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley,
	Kent, James Manger, Matt Miller, Kathleen Moriarty, Tony Nadalin,		Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger,
	Hideki Nara, Axel Nennker, Emmanuel Raviart, Eric Rescorla, Nat		Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel
	Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.		Nennker, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura,
			Jim Schaad, Hannes Tschofenig, and Sean Turner.
	Jim Schaad and Karen O'Donoghue chaired the JOSE working group and		Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
	Sean Turner, Stephen Farrell, and Kathleen Moriarty served as		Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
	Security area directors during the creation of this specification.		Security area directors during the creation of this specification.
	Appendix D. Document History		Appendix D. 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 ]]
			-34
			o Addressed IESG review comments by Barry Leiba, Alissa Cooper, Pete
			Resnick, Stephen Farrell, and Richard Barnes.
	-33		-33
	o Noted that certificate thumbprints are also sometimes known as		o Noted that certificate thumbprints are also sometimes known as
	certificate fingerprints.		certificate fingerprints.
	o Changed to use the term "authenticated encryption" instead of		o Changed to use the term "authenticated encryption" instead of
	"encryption", where appropriate.		"encryption", where appropriate.
	o Acknowledged additional contributors.		o Acknowledged additional contributors.
End of changes. 41 change blocks.
	76 lines changed or deleted		84 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/