< draft-ietf-jose-json-web-encryption-13.txt		draft-ietf-jose-json-web-encryption-14.txt >
	JOSE Working Group M. Jones		JOSE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track E. Rescorla		Intended status: Standards Track E. Rescorla
	Expires: January 16, 2014 RTFM		Expires: January 30, 2014 RTFM
	J. Hildebrand		J. Hildebrand
	Cisco		Cisco
	July 15, 2013		July 29, 2013
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	draft-ietf-jose-json-web-encryption-13		draft-ietf-jose-json-web-encryption-14
	Abstract		Abstract
	JSON Web Encryption (JWE) is a means of representing encrypted		JSON Web Encryption (JWE) is a means of representing encrypted
	content using JavaScript Object Notation (JSON) based data		content using JavaScript Object Notation (JSON) based data
	structures. Cryptographic algorithms and identifiers for use with		structures. Cryptographic algorithms and identifiers for use with
	this specification are described in the separate JSON Web Algorithms		this specification are described in the separate JSON Web Algorithms
	(JWA) specification. Related digital signature and MAC capabilities		(JWA) specification. Related digital signature and MAC capabilities
	are described in the separate JSON Web Signature (JWS) specification.		are described in the separate JSON Web Signature (JWS) specification.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 January 16, 2014.		This Internet-Draft will expire on January 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 14, line 30 ¶		skipping to change at page 14, line 30 ¶
	When used with a JWK, the "kid" value can be used to match a JWK		When used with a JWK, the "kid" value can be used to match a JWK
	"kid" parameter value.		"kid" parameter value.
	4.1.10. "typ" (Type) Header Parameter		4.1.10. "typ" (Type) Header Parameter
	The "typ" (type) header parameter MAY be used to declare the type of		The "typ" (type) header parameter MAY be used to declare the type of
	this complete JWE object in an application-specific manner in		this complete JWE object in an application-specific manner in
	contexts where this is useful to the application. This parameter has		contexts where this is useful to the application. This parameter has
	no effect upon the JWE processing. The type value "JOSE" MAY be used		no effect upon the JWE processing. The type value "JOSE" MAY be used
	to indicate that this object is a JWS or JWE using the JWS Compact		by applications to indicate that this object is a JWS or JWE using
	Serialization or the JWE Compact Serialization. The type value		the JWS Compact Serialization or the JWE Compact Serialization. The
	"JOSE+JSON" MAY be used to indicate that this object is a JWS or JWE		type value "JOSE+JSON" MAY be used by applications to indicate that
	using the JWS JSON Serialization or the JWE JSON Serialization.		this object is a JWS or JWE using the JWS JSON Serialization or the
	Other type values MAY be used, and if not understood, SHOULD be		JWE JSON Serialization. Other type values MAY be used, and if not
	ignored. The "typ" value is a case sensitive string. Use of this		understood, SHOULD be ignored. The "typ" value is a case sensitive
	header parameter is OPTIONAL.		string. Use of this header parameter is OPTIONAL.
	MIME Media Type [RFC2046] values MAY be used as "typ" values.		MIME Media Type [RFC2046] values MAY be used as "typ" values.
	"typ" values SHOULD either be registered in the IANA JSON Web		"typ" values SHOULD either be registered in the IANA JSON Web
	Signature and Encryption Type Values registry [JWS] or be a value		Signature and Encryption Type Values registry [JWS] or be a value
	that contains a Collision Resistant Namespace.		that contains a Collision Resistant Namespace.
	4.1.11. "cty" (Content Type) Header Parameter		4.1.11. "cty" (Content Type) Header Parameter
	The "cty" (content type) header parameter MAY be used to declare the		The "cty" (content type) header parameter MAY be used to declare the
	skipping to change at page 19, line 28 ¶		skipping to change at page 19, line 28 ¶
	10. When Key Wrapping, Key Encryption, or Key Agreement with Key		10. 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. To		recipient JWE Encrypted Key values to obtain the CEK value. To
	mitigate against attacks described in RFC 3218 [RFC3218], the		mitigate the attacks described in RFC 3218 [RFC3218], the
	recipient MUST NOT distinguish between format, padding, and		recipient MUST NOT distinguish between format, padding, and
	length errors of encrypted keys. It is strongly recommended, in		length errors of encrypted keys. It is strongly recommended, in
	the event of receiving an improperly formatted key, that the		the event of receiving an improperly formatted key, that the
	receiver substitute a randomly generated CEK and proceed to the		receiver substitute a randomly generated CEK and proceed to the
	next step, to mitigate timing attacks.		next step, to mitigate timing attacks.
	11. Otherwise, when Direct Key Agreement or Direct Encryption are		11. Otherwise, when Direct Key Agreement or Direct Encryption are
	employed, verify that the JWE Encrypted Key value is empty octet		employed, verify that the JWE Encrypted Key value is empty octet
	sequence.		sequence.
	skipping to change at page 21, line 36 ¶		skipping to change at page 21, line 36 ¶
	Serialization:		Serialization:
	o Values in the JWE JSON Serialization are represented as members of		o Values in the JWE JSON Serialization are represented as members of
	a JSON object, rather than as base64url encoded strings separated		a JSON object, rather than as base64url encoded strings separated
	by period ('.') characters. (However binary values and values		by period ('.') characters. (However binary values and values
	that are integrity protected are still base64url encoded.)		that are integrity protected are still base64url encoded.)
	o The Encoded JWE Header value, if non-empty, is stored in the		o The Encoded JWE Header value, if non-empty, is stored in the
	"protected" member.		"protected" member.
	o The Encoded JWE Initialization Vector value is stored in the "iv"		o The Encoded JWE Initialization Vector value, if non-empty, is
	member.		stored in the "iv" member.
	o The Encoded JWE Ciphertext value is stored in the "ciphertext"		o The Encoded JWE Ciphertext value is stored in the "ciphertext"
	member.		member.
	o The Encoded JWE Authentication Tag value is stored in the "tag"		o The Encoded JWE Authentication Tag value, if non-empty, is stored
	member.		in the "tag" member.
	o The JWE can be encrypted to multiple recipients, rather than just		o The JWE can be encrypted to multiple recipients, rather than just
	one. A JSON array in the "recipients" member is used to hold		one. A JSON array in the "recipients" member is used to hold
	values that are specific to a particular recipient, with one array		values that are specific to a particular recipient, with one array
	element per recipient represented. These array elements are JSON		element per recipient represented. These array elements are JSON
	objects.		objects.
	o Each Encoded JWE Encrypted Key value is stored in the		o Each Encoded JWE Encrypted Key value, if non-empty, is stored in
	"encrypted_key" member of a JSON object that is an element of the		the "encrypted_key" member of a JSON object that is an element of
	"recipients" array.		the "recipients" array.
	o Some header parameter values, such as the "alg" value and		o Some header parameter values, such as the "alg" value and
	parameters used for selecting keys, can also differ for different		parameters used for selecting keys, can also differ for different
	recipient computations. Per-recipient header parameter values are		recipient computations. Per-recipient header parameter values, if
	stored in the "header" members of the same JSON objects that are		present, are stored in the "header" members of the same JSON
	elements of the "recipients" array.		objects that are elements of the "recipients" array.
	o Some header parameters, including the "alg" parameter, can be		o Some header parameters, including the "alg" parameter, can be
	shared among all recipient computations. These header parameters		shared among all recipient computations. These header parameters
	are stored in either of two top-level member(s) of the JSON		are stored in either of two top-level member(s) of the JSON
	object: the "protected" member and the "unprotected" member. The		object: the "protected" member and the "unprotected" member. The
	values of these members are JSON Text Objects containing Header		values of these members, if present, are JSON Text Objects
	Parameters.		containing Header Parameters.
	o Not all header parameters are integrity protected. The shared		o Not all header parameters are integrity protected. The shared
	header parameters in the "protected" member are integrity		header parameters in the "protected" member are integrity
	protected, and are base64url encoded. The per-recipient header		protected, and are base64url encoded. The per-recipient header
	parameters in the "header" array element members and the shared		parameters in the "header" array element members and the shared
	header parameters in the "unprotected" member are not integrity		header parameters in the "unprotected" member are not integrity
	protected. These JSON Text Objects containing header parameters		protected. These JSON Text Objects containing header parameters
	that are not integrity protected are not base64url encoded.		that are not integrity protected are not base64url encoded.
	o The header parameter values used when creating or validating per-		o The header parameter values used when creating or validating per-
	skipping to change at page 23, line 5 ¶		skipping to change at page 22, line 47 ¶
	of these sets of header parameters comprises the JWE Header. The		of these sets of header parameters comprises the JWE Header. The
	header parameter names in the three locations MUST be disjoint.		header parameter names in the three locations MUST be disjoint.
	o An "aad" (Additional Authenticated Data) member can be included to		o An "aad" (Additional Authenticated Data) member can be included to
	supply a base64url encoded value to be integrity protected but not		supply a base64url encoded value to be integrity protected but not
	encrypted. (Note that this can also be achieved when using either		encrypted. (Note that this can also be achieved when using either
	serialization by including the AAD value as a protected header		serialization by including the AAD value as a protected header
	parameter value, but at the cost of the value being double		parameter value, but at the cost of the value being double
	base64url encoded.)		base64url encoded.)
			o The "recipients" array MUST always be present, even if the array
			elements contain only the empty JSON object "{}" (which can happen
			when all header parameter values are shared between all recipients
			and when no encrypted key is used, such as when doing Direct
			Encryption).
	The syntax of a JWE using the JWE JSON Serialization is as follows:		The syntax of a JWE using the JWE JSON Serialization is as follows:
	{"protected":<integrity-protected shared header contents>",		{"protected":<integrity-protected shared header contents>",
	"unprotected":<non-integrity-protected shared header contents>",		"unprotected":<non-integrity-protected shared header contents>",
	"recipients":[		"recipients":[
	{"header":"<per-recipient unprotected header 1 contents>",		{"header":"<per-recipient unprotected header 1 contents>",
	"encrypted_key":"<encrypted key 1 contents>"},		"encrypted_key":"<encrypted key 1 contents>"},
	...		...
	{"header":"<per-recipient unprotected header N contents>",		{"header":"<per-recipient unprotected header N contents>",
	"encrypted_key":"<encrypted key N contents>"}],		"encrypted_key":"<encrypted key N contents>"}],
	skipping to change at page 40, line 20 ¶		skipping to change at page 40, line 20 ¶
	not repeated here.		not repeated here.
	The Plaintext, the Content Encryption Key (CEK), Initialization		The Plaintext, the Content Encryption Key (CEK), Initialization
	Vector, and JWE Protected Header are shared by all recipients (which		Vector, and JWE Protected Header are shared by all recipients (which
	must be the case, since the Ciphertext and Authentication Tag are		must be the case, since the Ciphertext and Authentication Tag are
	also shared).		also shared).
	A.4.1. JWE Per-Recipient Unprotected Headers		A.4.1. JWE Per-Recipient Unprotected Headers
	The first recipient uses the RSAES-PKCS1-V1_5 algorithm to encrypt		The first recipient uses the RSAES-PKCS1-V1_5 algorithm to encrypt
	the Content Encryption Key (CEK). The second uses RSAES OAEP to		the Content Encryption Key (CEK). The second uses AES Key Wrap to
	encrypt the CEK. Key ID values are supplied for both keys. The two		encrypt the CEK. Key ID values are supplied for both keys. The two
	per-recipient header values used to represent these algorithms and		per-recipient header values used to represent these algorithms and
	Key IDs are:		Key IDs are:
	{"alg":"RSA1_5","kid":"2011-04-29"}		{"alg":"RSA1_5","kid":"2011-04-29"}
	and:		and:
	{"alg":"A128KW","kid":"7"}		{"alg":"A128KW","kid":"7"}
	skipping to change at page 45, line 41 ¶		skipping to change at page 45, line 41 ¶
	Hannes Tschofenig, and Sean Turner.		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 and Stephen Farrell served as Security area directors		Sean Turner and Stephen Farrell served as Security area directors
	during the creation of this specification.		during the creation of this specification.
	Appendix 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 ]]
			-14
			o Clarified that the "protected", "unprotected", "header", "iv",
			"tag", and "encrypted_key" parameters are to be omitted in the JWE
			JSON Serialization when their values would be empty. Stated that
			the "recipients" array must always be present.
	-13		-13
	o Added an "aad" (Additional Authenticated Data) member for the JWE		o Added an "aad" (Additional Authenticated Data) member for the JWE
	JSON Serialization, enabling Additional Authenticated Data to be		JSON Serialization, enabling Additional Authenticated Data to be
	supplied that is not double base64url encoded, addressing issue		supplied that is not double base64url encoded, addressing issue
	#29.		#29.
	-12		-12
	o Clarified that the "typ" and "cty" header parameters are used in		o Clarified that the "typ" and "cty" header parameters are used in
End of changes. 14 change blocks.
	25 lines changed or deleted		38 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/