< draft-ietf-jose-json-web-encryption-03.txt		draft-ietf-jose-json-web-encryption-04.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 7, 2013 RTFM		Expires: January 17, 2013 RTFM
	J. Hildebrand		J. Hildebrand
	Cisco		Cisco
	July 6, 2012		July 16, 2012
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	draft-ietf-jose-json-web-encryption-03		draft-ietf-jose-json-web-encryption-04
	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) data structures.		content using JavaScript Object Notation (JSON) 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. Related digital signature and MAC capabilities are		specification. Related digital signature and MAC capabilities are
	described in the separate JSON Web Signature (JWS) specification.		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 7, 2013.		This Internet-Draft will expire on January 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 26 ¶		skipping to change at page 2, line 26 ¶
	3.2. Example JWE with a Separate Integrity Check . . . . . . . 8		3.2. Example JWE with a Separate Integrity Check . . . . . . . 8
	4. JWE Header . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. JWE Header . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 10		4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 10
	4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 11		4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 11
	4.1.2. "enc" (Encryption Method) Header Parameter . . . . . . 11		4.1.2. "enc" (Encryption Method) Header Parameter . . . . . . 11
	4.1.3. "int" (Integrity Algorithm) Header Parameter . . . . . 11		4.1.3. "int" (Integrity Algorithm) Header Parameter . . . . . 11
	4.1.4. "kdf" (Key Derivation Function) Header Parameter . . . 12		4.1.4. "kdf" (Key Derivation Function) Header Parameter . . . 12
	4.1.5. "iv" (Initialization Vector) Header Parameter . . . . 12		4.1.5. "iv" (Initialization Vector) Header Parameter . . . . 12
	4.1.6. "epk" (Ephemeral Public Key) Header Parameter . . . . 12		4.1.6. "epk" (Ephemeral Public Key) Header Parameter . . . . 12
	4.1.7. "zip" (Compression Algorithm) Header Parameter . . . . 12		4.1.7. "zip" (Compression Algorithm) Header Parameter . . . . 12
	4.1.8. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 12		4.1.8. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 13
	4.1.9. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13		4.1.9. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13
	4.1.10. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 13		4.1.10. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 13
	4.1.11. "x5t" (X.509 Certificate Thumbprint) Header		4.1.11. "x5t" (X.509 Certificate Thumbprint) Header
	Parameter . . . . . . . . . . . . . . . . . . . . . . 13		Parameter . . . . . . . . . . . . . . . . . . . . . . 13
	4.1.12. "x5c" (X.509 Certificate Chain) Header Parameter . . . 14		4.1.12. "x5c" (X.509 Certificate Chain) Header Parameter . . . 14
	4.1.13. "kid" (Key ID) Header Parameter . . . . . . . . . . . 14		4.1.13. "kid" (Key ID) Header Parameter . . . . . . . . . . . 14
	4.1.14. "typ" (Type) Header Parameter . . . . . . . . . . . . 14		4.1.14. "typ" (Type) Header Parameter . . . . . . . . . . . . 14
	4.1.15. "cty" (Content Type) Header Parameter . . . . . . . . 15		4.1.15. "cty" (Content Type) Header Parameter . . . . . . . . 15
	4.2. Public Header Parameter Names . . . . . . . . . . . . . . 15		4.2. Public Header Parameter Names . . . . . . . . . . . . . . 15
	4.3. Private Header Parameter Names . . . . . . . . . . . . . . 15		4.3. Private Header Parameter Names . . . . . . . . . . . . . . 15
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	A.4.2. CIK Generation . . . . . . . . . . . . . . . . . . . . 40		A.4.2. CIK Generation . . . . . . . . . . . . . . . . . . . . 40
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 41		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 41
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 41		Appendix C. Document History . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	JSON Web Encryption (JWE) is a compact encryption format intended for		JSON Web Encryption (JWE) is a compact encryption format intended for
	space constrained environments such as HTTP Authorization headers and		space constrained environments such as HTTP Authorization headers and
	URI query parameters. It represents this content using JavaScript		URI query parameters. It represents this content using JavaScript
	Object Notation (JSON) [RFC4627] data structures. The JWE		Object Notation (JSON) [RFC4627] based data structures. The JWE
	cryptographic mechanisms encrypt and provide integrity protection for		cryptographic mechanisms encrypt and provide integrity protection for
	arbitrary sequences of bytes.		arbitrary sequences of bytes.
	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)
	[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) [JWS]		are described in the separate JSON Web Signature (JWS) [JWS]
	specification.		specification.
	1.1. Notational Conventions		1.1. Notational Conventions
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	a byte array, which is referred to as the JWE Encrypted Key.		a byte array, which is referred to as the JWE Encrypted Key.
	Otherwise, when key agreement is employed, the JWE Encrypted Key		Otherwise, when key agreement is employed, the JWE Encrypted Key
	is the empty byte array.		is the empty byte array.
	JWE Ciphertext A byte array containing the Ciphertext.		JWE Ciphertext A byte array containing the Ciphertext.
	JWE Integrity Value A byte array containing a MAC value that ensures		JWE Integrity Value A byte array containing a MAC value that ensures
	the integrity of the Ciphertext and the parameters used to create		the integrity of the Ciphertext and the parameters used to create
	it.		it.
			Base64url Encoding The URL- and filename-safe Base64 encoding
			described in RFC 4648 [RFC4648], Section 5, with the (non URL-
			safe) '=' padding characters omitted, as permitted by Section 3.2.
			(See Appendix C of [JWS] for notes on implementing base64url
			encoding without padding.)
	Encoded JWE Header Base64url encoding of the bytes of the UTF-8		Encoded JWE Header Base64url encoding of the bytes of the UTF-8
	[RFC3629] representation of the JWE Header.		[RFC3629] representation of the JWE Header.
	Encoded JWE Encrypted Key Base64url encoding of the JWE Encrypted		Encoded JWE Encrypted Key Base64url encoding of the JWE Encrypted
	Key.		Key.
	Encoded JWE Ciphertext Base64url encoding of the JWE Ciphertext.		Encoded JWE Ciphertext Base64url encoding of the JWE Ciphertext.
	Encoded JWE Integrity Value Base64url encoding of the JWE Integrity		Encoded JWE Integrity Value Base64url encoding of the JWE Integrity
	Value.		Value.
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 10 ¶
	concatenation of the Encoded JWE Header, the Encoded JWE Encrypted		concatenation of the Encoded JWE Header, the Encoded JWE Encrypted
	Key, the Encoded JWE Ciphertext, and the Encoded JWE Integrity		Key, the Encoded JWE Ciphertext, and the Encoded JWE Integrity
	Value in that order, with the four strings being separated by		Value in that order, with the four strings being separated by
	period ('.') characters.		period ('.') characters.
	AEAD Algorithm An Authenticated Encryption with Associated Data		AEAD Algorithm An Authenticated Encryption with Associated Data
	(AEAD) [RFC5116] encryption algorithm is one that provides an		(AEAD) [RFC5116] encryption algorithm is one that provides an
	integrated content integrity check. AES Galois/Counter Mode (GCM)		integrated content integrity check. AES Galois/Counter Mode (GCM)
	is one such algorithm.		is one such algorithm.
	Base64url Encoding For the purposes of this specification, this term
	always refers to the URL- and filename-safe Base64 encoding
	described in RFC 4648 [RFC4648], Section 5, with the (non URL-
	safe) '=' padding characters omitted, as permitted by Section 3.2.
	(See Appendix C of [JWS] for notes on implementing base64url
	encoding without padding.)
	Collision Resistant Namespace A namespace that allows names to be		Collision Resistant Namespace A namespace that allows names to be
	allocated in a manner such that they are highly unlikely to		allocated in a manner such that they are highly unlikely to
	collide with other names. For instance, collision resistance can		collide with other names. For instance, collision resistance can
	be achieved through administrative delegation of portions of the		be achieved through administrative delegation of portions of the
	namespace or through use of collision-resistant name allocation		namespace or through use of collision-resistant name allocation
	functions. Examples of Collision Resistant Namespaces include:		functions. Examples of Collision Resistant Namespaces include:
	Domain Names, Object Identifiers (OIDs) as defined in the ITU-T		Domain Names, Object Identifiers (OIDs) as defined in the ITU-T
	X.660 and X.670 Recommendation series, and Universally Unique		X.660 and X.670 Recommendation series, and Universally Unique
	IDentifiers (UUIDs) [RFC4122]. When using an administratively		IDentifiers (UUIDs) [RFC4122]. When using an administratively
	delegated namespace, the definer of a name needs to take		delegated namespace, the definer of a name needs to take
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 13 ¶
	specifications, its usage must be compatible between the		specifications, its usage must be compatible between the
	specifications.		specifications.
	4.1.1. "alg" (Algorithm) Header Parameter		4.1.1. "alg" (Algorithm) Header Parameter
	The "alg" (algorithm) header parameter identifies the cryptographic		The "alg" (algorithm) header parameter identifies the cryptographic
	algorithm used to encrypt or reach agreement upon the Content Master		algorithm used to encrypt or reach agreement upon the Content Master
	Key (CMK). The algorithm specified by the "alg" value MUST be		Key (CMK). The algorithm specified by the "alg" value MUST be
	supported by the implementation and there MUST be a key for use with		supported by the implementation and there MUST be a key for use with
	that algorithm associated with the intended recipient or the JWE MUST		that algorithm associated with the intended recipient or the JWE MUST
	be rejected. The "alg" value is case sensitive. Its value MUST be a		be rejected. "alg" values SHOULD either be registered in the IANA
	string containing a StringOrURI value. This header parameter is		JSON Web Signature and Encryption Algorithms registry [JWA] or be a
	REQUIRED.		URI that contains a Collision Resistant Namespace. The "alg" value
			is a case sensitive string containing a StringOrURI value. This
			header parameter is REQUIRED.
	A list of defined "alg" values for use with JWE is presented in		A list of defined "alg" values can be found in the IANA JSON Web
	Section 4.1 of the JSON Web Algorithms (JWA) [JWA] specification.		Signature and Encryption Algorithms registry [JWA]; the initial
	"alg" values SHOULD either be registered in the IANA JSON Web		contents of this registry is the values defined in Section 4.1 of the
	Signature and Encryption Algorithms registry [JWA] or be a URI that		JSON Web Algorithms (JWA) [JWA] specification.
	contains a Collision Resistant Namespace.
	4.1.2. "enc" (Encryption Method) Header Parameter		4.1.2. "enc" (Encryption Method) Header Parameter
	The "enc" (encryption method) header parameter identifies the		The "enc" (encryption method) header parameter identifies the
	symmetric encryption algorithm used to encrypt the Plaintext to		symmetric encryption algorithm used to encrypt the Plaintext to
	produce the Ciphertext. The algorithm specified by the "enc" value		produce the Ciphertext. The algorithm specified by the "enc" value
	MUST be supported by the implementation or the JWE MUST be rejected.		MUST be supported by the implementation or the JWE MUST be rejected.
	The "enc" value is case sensitive. Its value MUST be a string		"enc" values SHOULD either be registered in the IANA JSON Web
	containing a StringOrURI value. This header parameter is REQUIRED.		Signature and Encryption Algorithms registry [JWA] or be a URI that
			contains a Collision Resistant Namespace. The "enc" value is a case
			sensitive string containing a StringOrURI value. This header
			parameter is REQUIRED.
	A list of defined "enc" values is presented in Section 4.2 of the		A list of defined "enc" values can be found in the IANA JSON Web
	JSON Web Algorithms (JWA) [JWA] specification. "enc" values SHOULD		Signature and Encryption Algorithms registry [JWA]; the initial
	either be registered in the IANA JSON Web Signature and Encryption		contents of this registry is the values defined in Section 4.2 of the
	Algorithms registry [JWA] or be a URI that contains a Collision		JSON Web Algorithms (JWA) [JWA] specification.
	Resistant Namespace.
	4.1.3. "int" (Integrity Algorithm) Header Parameter		4.1.3. "int" (Integrity Algorithm) Header Parameter
	The "int" (integrity algorithm) header parameter identifies the		The "int" (integrity algorithm) header parameter identifies the
	cryptographic algorithm used to safeguard the integrity of the		cryptographic algorithm used to safeguard the integrity of the
	Ciphertext and the parameters used to create it. The "int" parameter		Ciphertext and the parameters used to create it. The "int" parameter
	uses the MAC subset of the algorithm values used by the JWS "alg"		uses the MAC subset of the algorithm values used by the JWS "alg"
	parameter. The "int" value is case sensitive. Its value MUST be a		parameter. "int" values SHOULD either be registered in the IANA JSON
	string containing a StringOrURI value. This header parameter is		Web Signature and Encryption Algorithms registry [JWA] or be a URI
	REQUIRED when an AEAD algorithm is not used to encrypt the Plaintext		that contains a Collision Resistant Namespace. The "int" value is a
	and MUST NOT be present when an AEAD algorithm is used.		case sensitive string containing a StringOrURI value. This header
			parameter is REQUIRED when an AEAD algorithm is not used to encrypt
			the Plaintext and MUST NOT be present when an AEAD algorithm is used.
	A list of defined "int" values is presented in Section 4.3 of the		A list of defined "int" values can be found in the IANA JSON Web
	JSON Web Algorithms (JWA) [JWA] specification. "int" values SHOULD		Signature and Encryption Algorithms registry [JWA]; the initial
	either be registered in the IANA JSON Web Signature and Encryption		contents of this registry is the values defined in Section 4.3 of the
	Algorithms registry [JWA] or be a URI that contains a Collision		JSON Web Algorithms (JWA) [JWA] specification.
	Resistant Namespace.
	4.1.4. "kdf" (Key Derivation Function) Header Parameter		4.1.4. "kdf" (Key Derivation Function) Header Parameter
	The "kdf" (key derivation function) header parameter identifies the		The "kdf" (key derivation function) header parameter identifies the
	cryptographic algorithm used to derive the CEK and CIK from the CMK.		cryptographic algorithm used to derive the CEK and CIK from the CMK.
	The "kdf" value is case sensitive. Its value MUST be a string		"kdf" values SHOULD either be registered in the IANA JSON Web
	containing a StringOrURI value. This header parameter is OPTIONAL		Signature and Encryption Algorithms registry [JWA] or be a URI that
	when an AEAD algorithm is not used to encrypt the Plaintext and MUST		contains a Collision Resistant Namespace. The "kdf" value is a case
	NOT be present when an AEAD algorithm is used.		sensitive string containing a StringOrURI value. This header
			parameter is OPTIONAL when an AEAD algorithm is not used to encrypt
			the Plaintext and MUST NOT be present when an AEAD algorithm is used.
	When an AEAD algorithm is not used and no "kdf" header parameter is		When an AEAD algorithm is not used and no "kdf" header parameter is
	present, the "CS256" KDF [JWA] SHALL be used.		present, the "CS256" KDF [JWA] SHALL be used.
	A list of defined "kdf" values is presented in Section 4.4 of the		A list of defined "kdf" values can be found in the IANA JSON Web
	JSON Web Algorithms (JWA) [JWA] specification. "kdf" values SHOULD		Signature and Encryption Algorithms registry [JWA]; the initial
	either be registered in the IANA JSON Web Signature and Encryption		contents of this registry is the values defined in Section 4.4 of the
	Algorithms registry [JWA] or be a URI that contains a Collision		JSON Web Algorithms (JWA) [JWA] specification.
	Resistant Namespace.
	4.1.5. "iv" (Initialization Vector) Header Parameter		4.1.5. "iv" (Initialization Vector) Header Parameter
	The "iv" (initialization vector) value for algorithms requiring it,		The "iv" (initialization vector) value for algorithms requiring it,
	represented as a base64url encoded string. This header parameter is		represented as a base64url encoded string. This header parameter is
	OPTIONAL, although its use is REQUIRED with some "enc" algorithms.		OPTIONAL, although its use is REQUIRED with some "enc" algorithms.
	4.1.6. "epk" (Ephemeral Public Key) Header Parameter		4.1.6. "epk" (Ephemeral Public Key) Header Parameter
	The "epk" (ephemeral public key) value created by the originator for		The "epk" (ephemeral public key) value created by the originator for
	skipping to change at page 14, line 43 ¶		skipping to change at page 14, line 47 ¶
	interpretation of the "kid" value is unspecified. Its value MUST be		interpretation of the "kid" value is unspecified. Its value MUST be
	a string. This header parameter is OPTIONAL.		a string. This header parameter is OPTIONAL.
	When used with a JWK, the "kid" value MAY be used to match a JWK		When used with a JWK, the "kid" value MAY be used to match a JWK
	"kid" parameter value.		"kid" parameter value.
	4.1.14. "typ" (Type) Header Parameter		4.1.14. "typ" (Type) Header Parameter
	The "typ" (type) header parameter is used to declare the type of this		The "typ" (type) header parameter is used to declare the type of this
	object. The type value "JWE" MAY be used to indicate that this		object. The type value "JWE" MAY be used to indicate that this
	object is a JWE. The "typ" value is case sensitive. Its value MUST		object is a JWE. The "typ" value is a case sensitive string. This
	be a string. This header parameter is OPTIONAL.		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 URI that		Signature and Encryption Type Values registry [JWS] or be a URI that
	contains a Collision Resistant Namespace.		contains a Collision Resistant Namespace.
	4.1.15. "cty" (Content Type) Header Parameter		4.1.15. "cty" (Content Type) Header Parameter
	The "cty" (content type) header parameter is used to declare the type		The "cty" (content type) header parameter is used to declare the type
	of the encrypted content (the Plaintext). The "cty" value is case		of the encrypted content (the Plaintext). The "cty" value is a case
	sensitive. Its value MUST be a string. This header parameter is		sensitive string. This header parameter is OPTIONAL.
	OPTIONAL.
	The values used for the "cty" header parameter come from the same		The values used for the "cty" header parameter come from the same
	value space as the "typ" header parameter, with the same rules		value space as the "typ" header parameter, with the same rules
	applying.		applying.
	4.2. Public Header Parameter Names		4.2. Public Header Parameter Names
	Additional header parameter names can be defined by those using JWEs.		Additional header parameter names can be defined by those using JWEs.
	However, in order to prevent collisions, any new header parameter		However, in order to prevent collisions, any new header parameter
	name SHOULD either be registered in the IANA JSON Web Signature and		name SHOULD either be registered in the IANA JSON Web Signature and
	skipping to change at page 23, line 35 ¶		skipping to change at page 23, line 35 ¶
	[[ to be removed by the RFC editor before publication as an RFC ]]		[[ to be removed by the RFC editor before publication as an RFC ]]
	The following items remain to be considered or done in this draft:		The following items remain to be considered or done in this draft:
	o Should we define an optional nonce and/or timestamp header		o Should we define an optional nonce and/or timestamp header
	parameter? (Use of a nonce is an effective countermeasure to some		parameter? (Use of a nonce is an effective countermeasure to some
	kinds of attacks.)		kinds of attacks.)
	o When doing key agreement, do we want to also use a separate CMK		o When doing key agreement, do we want to also use a separate CMK
	and encrypt the CMK with the agreed upon key or just use the		and encrypt the CMK with the agreed upon key or just use the
	agreed upon key directly as the CMK? Having a CMK would have		agreed upon key directly as the CMK? Or support both? Having a
	value in the multiple recipients case, as it would allow multiple		CMK would have value in the multiple recipients case, as it would
	recipients to share the same ciphertext even when key agreement is		allow multiple recipients to share the same ciphertext even when
	used, but it seems that it's just extra overhead in the single		key agreement is used, but it seems that it's just extra overhead
	recipient case.		in the single recipient case. (Also see the related open issue
			about performing symmetric encryption directly with a shared key,
			without using a CMK.)
	o Do we want to consolidate the combination of the "enc", "int", and		o Do we want to consolidate the combination of the "enc", "int", and
	"kdf" parameters into a single new "enc" parameter defining		"kdf" parameters into a single new "enc" parameter defining
	composite AEAD algorithms? For instance, we might define a		composite AEAD algorithms? For instance, we might define a
	composite algorithm A128CBC with HS256 and CS256 and another		composite algorithm A128CBC with HS256 and CS256 and another
	composite algorithm A256CBC with HS512 and CS512. A symmetry		composite algorithm A256CBC with HS512 and CS512. A symmetry
	argument for doing this is that the "int" and "kdf" parameters are		argument for doing this is that the "int" and "kdf" parameters are
	not used with AEAD algorithms. An argument against it is that in		not used with AEAD algorithms. An argument against it is that in
	some cases, integrity is not needed because it's provided by other		some cases, integrity is not needed because it's provided by other
	means, and so having the flexibility to not use an "int" algorithm		means, and so having the flexibility to not use an "int" algorithm
	skipping to change at page 25, line 23 ¶		skipping to change at page 25, line 25 ¶
	Encryption", RFC 5116, January 2008.		Encryption", RFC 5116, January 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[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.
			[W3C.CR-xmlenc-core1-20120313]
			Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
			"XML Encryption Syntax and Processing Version 1.1", World
			Wide Web Consortium CR CR-xmlenc-core1-20120313,
			March 2012,
			<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.
	13.2. Informative References		13.2. Informative References
	[I-D.rescorla-jsms]		[I-D.rescorla-jsms]
	Rescorla, E. and J. Hildebrand, "JavaScript Message		Rescorla, E. and J. Hildebrand, "JavaScript Message
	Security Format", draft-rescorla-jsms-00 (work in		Security Format", draft-rescorla-jsms-00 (work in
	progress), March 2011.		progress), March 2011.
	[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple		[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
	Encryption", September 2010.		Encryption", September 2010.
	[JWE-JS] Jones, M., "JSON Web Encryption JSON Serialization		[JWE-JS] Jones, M., "JSON Web Encryption JSON Serialization
	(JWE-JS)", July 2012.		(JWE-JS)", July 2012.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	July 2005.		July 2005.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, September 2009.		RFC 5652, September 2009.
	[W3C.CR-xmlenc-core1-20120313]
	Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
	"XML Encryption Syntax and Processing Version 1.1", World
	Wide Web Consortium CR CR-xmlenc-core1-20120313,
	March 2012,
	<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.
	Appendix A. JWE Examples		Appendix A. JWE Examples
	This section provides examples of JWE computations.		This section provides examples of JWE computations.
	A.1. Example JWE using RSAES OAEP and AES GCM		A.1. Example JWE using RSAES OAEP and AES GCM
	This example encrypts the plaintext "Live long and prosper." to the		This example encrypts the plaintext "Live long and prosper." to the
	recipient using RSAES OAEP and AES GCM. The AES GCM algorithm has an		recipient using RSAES OAEP and AES GCM. The AES GCM algorithm has an
	integrated integrity check. The representation of this plaintext is:		integrated integrity check. The representation of this plaintext is:
	skipping to change at page 41, line 34 ¶		skipping to change at page 41, line 34 ¶
	draft. This draft attempts to explicitly reuse as many of the		draft. This draft attempts to explicitly reuse as many of the
	relevant concepts from XML Encryption 1.1		relevant concepts from XML Encryption 1.1
	[W3C.CR-xmlenc-core1-20120313] and RFC 5652 [RFC5652] as possible,		[W3C.CR-xmlenc-core1-20120313] and RFC 5652 [RFC5652] as possible,
	while utilizing simple compact JSON-based data structures.		while utilizing simple compact JSON-based data structures.
	Special thanks are due to John Bradley and Nat Sakimura for the		Special thanks are due to John Bradley and Nat Sakimura for the
	discussions that helped inform the content of this specification and		discussions that helped inform the content of this specification and
	to Eric Rescorla and Joe Hildebrand for allowing the reuse of text		to Eric Rescorla and Joe Hildebrand for allowing the reuse of text
	from [I-D.rescorla-jsms] in this document.		from [I-D.rescorla-jsms] in this document.
	My thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and		Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund
	Edmund Jay for validating the examples in this specification.		Jay for validating the examples in this specification.
	Appendix C. Document History		Appendix C. 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 ]]
			-04
			o Refer to the registries as the primary sources of defined values
			and then secondarily reference the sections defining the initial
			contents of the registries.
			o Normatively reference XML Encryption 1.1
			[W3C.CR-xmlenc-core1-20120313] for its security considerations.
			o Reference draft-jones-jose-jwe-json-serialization instead of
			draft-jones-json-web-encryption-json-serialization.
			o Described additional open issues.
			o Applied editorial suggestions.
	-03		-03
	o Added the "kdf" (key derivation function) header parameter to		o Added the "kdf" (key derivation function) header parameter to
	provide crypto agility for key derivation. The default KDF		provide crypto agility for key derivation. The default KDF
	remains the Concat KDF with the SHA-256 digest function.		remains the Concat KDF with the SHA-256 digest function.
	o Reordered encryption steps so that the Encoded JWE Header is		o Reordered encryption steps so that the Encoded JWE Header is
	always created before it is needed as an input to the AEAD		always created before it is needed as an input to the AEAD
	"additional authenticated data" parameter.		"additional authenticated data" parameter.
End of changes. 23 change blocks.
	65 lines changed or deleted		86 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/