< draft-ietf-jose-json-web-encryption-31.txt		draft-ietf-jose-json-web-encryption-32.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: January 5, 2015 Cisco		Expires: March 27, 2015 Cisco
	July 4, 2014		September 23, 2014
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	draft-ietf-jose-json-web-encryption-31		draft-ietf-jose-json-web-encryption-32
	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 January 5, 2015.		This Internet-Draft will expire on March 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 14 ¶		skipping to change at page 2, line 14 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . . 8		3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . . 8
	3.1. JWE Compact Serialization Overview . . . . . . . . . . . . 10		3.1. JWE Compact Serialization Overview . . . . . . . . . . . . 9
	3.2. JWE JSON Serialization Overview . . . . . . . . . . . . . 10		3.2. JWE JSON Serialization Overview . . . . . . . . . . . . . 9
	3.3. Example JWE . . . . . . . . . . . . . . . . . . . . . . . 10		3.3. Example JWE . . . . . . . . . . . . . . . . . . . . . . . 10
	4. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Registered Header Parameter Names . . . . . . . . . . . . 12		4.1. Registered Header Parameter Names . . . . . . . . . . . . 11
	4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 12		4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 12
	4.1.2. "enc" (Encryption Algorithm) Header Parameter . . . . 12		4.1.2. "enc" (Encryption Algorithm) Header Parameter . . . . 12
	4.1.3. "zip" (Compression Algorithm) Header Parameter . . . . 13		4.1.3. "zip" (Compression Algorithm) Header Parameter . . . . 12
	4.1.4. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 13		4.1.4. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 13
	4.1.5. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13		4.1.5. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13
	4.1.6. "kid" (Key ID) Header Parameter . . . . . . . . . . . 13		4.1.6. "kid" (Key ID) Header Parameter . . . . . . . . . . . 13
	4.1.7. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 14		4.1.7. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 13
	4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter . . . 14		4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter . . . 13
	4.1.9. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header		4.1.9. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header
	Parameter . . . . . . . . . . . . . . . . . . . . . . 14		Parameter . . . . . . . . . . . . . . . . . . . . . . 14
	4.1.10. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)		4.1.10. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
	Header Parameter . . . . . . . . . . . . . . . . . . . 14		Header Parameter . . . . . . . . . . . . . . . . . . . 14
	4.1.11. "typ" (Type) Header Parameter . . . . . . . . . . . . 14		4.1.11. "typ" (Type) Header Parameter . . . . . . . . . . . . 14
	4.1.12. "cty" (Content Type) Header Parameter . . . . . . . . 15		4.1.12. "cty" (Content Type) Header Parameter . . . . . . . . 14
	4.1.13. "crit" (Critical) Header Parameter . . . . . . . . . . 15		4.1.13. "crit" (Critical) Header Parameter . . . . . . . . . . 14
	4.2. Public Header Parameter Names . . . . . . . . . . . . . . 15		4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14
	4.3. Private Header Parameter Names . . . . . . . . . . . . . . 15		4.3. Private Header Parameter Names . . . . . . . . . . . . . . 15
	5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . . 15		5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . . 15
	5.1. Message Encryption . . . . . . . . . . . . . . . . . . . . 15		5.1. Message Encryption . . . . . . . . . . . . . . . . . . . . 15
	5.2. Message Decryption . . . . . . . . . . . . . . . . . . . . 17		5.2. Message Decryption . . . . . . . . . . . . . . . . . . . . 17
	5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 20		5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 20
	6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 20		6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 20
	7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 20		7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1. JWE Compact Serialization . . . . . . . . . . . . . . . . 20		7.1. JWE Compact Serialization . . . . . . . . . . . . . . . . 20
	7.2. JWE JSON Serialization . . . . . . . . . . . . . . . . . . 21		7.2. JWE JSON Serialization . . . . . . . . . . . . . . . . . . 20
	8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 23		8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 23
	9. Distinguishing between JWS and JWE Objects . . . . . . . . . . 24		9. Distinguishing between JWS and JWE Objects . . . . . . . . . . 23
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	10.1. JSON Web Signature and Encryption Header Parameters		10.1. JSON Web Signature and Encryption Header Parameters
	Registration . . . . . . . . . . . . . . . . . . . . . . . 24		Registration . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 24		10.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 24
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 26		11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11.1. Using Matching Algorithm Strengths . . . . . . . . . . . . 27		11.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26
	11.2. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 27		11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . . 26
	11.3. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 27		11.3. Using Matching Algorithm Strengths . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 27
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 27		11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 27
			12. 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 . . . . . . . . . . . . . . . . . . . . 29
	A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 29		A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 29
	A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 29		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 . . . . . . . . . . . . . . . . . . . . 30
	A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 31		A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 32
	A.1.5. Additional Authenticated Data . . . . . . . . . . . . 31		A.1.5. Additional Authenticated Data . . . . . . . . . . . . 32
	A.1.6. Content Encryption . . . . . . . . . . . . . . . . . . 32		A.1.6. Content Encryption . . . . . . . . . . . . . . . . . . 32
	A.1.7. Complete Representation . . . . . . . . . . . . . . . 32		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 . . . . . . . . . . . . . . . . . . . . . 33		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
	A.2.4. Initialization Vector . . . . . . . . . . . . . . . . 35		A.2.4. Initialization Vector . . . . . . . . . . . . . . . . 35
	A.2.5. Additional Authenticated Data . . . . . . . . . . . . 35		A.2.5. Additional Authenticated Data . . . . . . . . . . . . 36
	A.2.6. Content Encryption . . . . . . . . . . . . . . . . . . 35		A.2.6. Content Encryption . . . . . . . . . . . . . . . . . . 36
	A.2.7. Complete Representation . . . . . . . . . . . . . . . 36		A.2.7. Complete Representation . . . . . . . . . . . . . . . 36
	A.2.8. Validation . . . . . . . . . . . . . . . . . . . . . . 36		A.2.8. Validation . . . . . . . . . . . . . . . . . . . . . . 37
	A.3. Example JWE using AES Key Wrap and		A.3. Example JWE using AES Key Wrap and
	AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 37		AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 37
	A.3.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 37		A.3.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 37
	A.3.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 37		A.3.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 38
	A.3.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 37		A.3.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 38
	A.3.4. Initialization Vector . . . . . . . . . . . . . . . . 38		A.3.4. Initialization Vector . . . . . . . . . . . . . . . . 38
	A.3.5. Additional Authenticated Data . . . . . . . . . . . . 38		A.3.5. Additional Authenticated Data . . . . . . . . . . . . 39
	A.3.6. Content Encryption . . . . . . . . . . . . . . . . . . 38		A.3.6. Content Encryption . . . . . . . . . . . . . . . . . . 39
	A.3.7. Complete Representation . . . . . . . . . . . . . . . 39		A.3.7. Complete Representation . . . . . . . . . . . . . . . 39
	A.3.8. Validation . . . . . . . . . . . . . . . . . . . . . . 39		A.3.8. Validation . . . . . . . . . . . . . . . . . . . . . . 40
	A.4. Example JWE using JWE JSON Serialization . . . . . . . . . 40		A.4. Example JWE using JWE JSON Serialization . . . . . . . . . 40
	A.4.1. JWE Per-Recipient Unprotected Headers . . . . . . . . 40		A.4.1. JWE Per-Recipient Unprotected Headers . . . . . . . . 40
	A.4.2. JWE Protected Header . . . . . . . . . . . . . . . . . 40		A.4.2. JWE Protected Header . . . . . . . . . . . . . . . . . 41
	A.4.3. JWE Unprotected Header . . . . . . . . . . . . . . . . 41		A.4.3. JWE Unprotected Header . . . . . . . . . . . . . . . . 41
	A.4.4. Complete JOSE Header Values . . . . . . . . . . . . . 41		A.4.4. Complete JOSE Header Values . . . . . . . . . . . . . 41
	A.4.5. Additional Authenticated Data . . . . . . . . . . . . 41		A.4.5. Additional Authenticated Data . . . . . . . . . . . . 41
	A.4.6. Content Encryption . . . . . . . . . . . . . . . . . . 41		A.4.6. Content Encryption . . . . . . . . . . . . . . . . . . 42
	A.4.7. Complete JWE JSON Serialization Representation . . . . 42		A.4.7. Complete JWE JSON Serialization Representation . . . . 42
	Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation . . . . 43		Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation . . . . 43
	B.1. Extract MAC_KEY and ENC_KEY from Key . . . . . . . . . . . 43		B.1. Extract MAC_KEY and ENC_KEY from Key . . . . . . . . . . . 43
	B.2. Encrypt Plaintext to Create Ciphertext . . . . . . . . . . 43		B.2. Encrypt Plaintext to Create Ciphertext . . . . . . . . . . 44
	B.3. 64 Bit Big Endian Representation of AAD Length . . . . . . 44		B.3. 64 Bit Big Endian Representation of AAD Length . . . . . . 44
	B.4. Initialization Vector Value . . . . . . . . . . . . . . . 44		B.4. Initialization Vector Value . . . . . . . . . . . . . . . 45
	B.5. Create Input to HMAC Computation . . . . . . . . . . . . . 44		B.5. Create Input to HMAC Computation . . . . . . . . . . . . . 45
	B.6. Compute HMAC Value . . . . . . . . . . . . . . . . . . . . 44		B.6. Compute HMAC Value . . . . . . . . . . . . . . . . . . . . 45
	B.7. Truncate HMAC Value to Create Authentication Tag . . . . . 45		B.7. Truncate HMAC Value to Create Authentication Tag . . . . . 45
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 45		Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 45
	Appendix D. Document History . . . . . . . . . . . . . . . . . . 45		Appendix D. Document History . . . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	JSON Web Encryption (JWE) represents encrypted content using		JSON Web Encryption (JWE) represents encrypted content using
	JavaScript Object Notation (JSON) [RFC7159] based data structures.		JavaScript Object Notation (JSON) [RFC7159] based data structures.
	The JWE cryptographic mechanisms encrypt and provide integrity		The JWE cryptographic mechanisms encrypt and provide integrity
	protection for an arbitrary sequence of octets.		protection for an arbitrary sequence of octets.
	Two closely related serializations for JWE objects are defined. The		Two closely related serializations for JWE objects are defined. The
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	symmetric key wrapping algorithm.		symmetric key wrapping algorithm.
	Direct Encryption		Direct Encryption
	A Key Management Mode in which the Content Encryption Key (CEK)		A Key Management Mode in which the Content Encryption Key (CEK)
	value used is the secret symmetric key value shared between the		value used is the secret symmetric key value shared between the
	parties.		parties.
	3. JSON Web Encryption (JWE) Overview		3. JSON Web Encryption (JWE) Overview
	JWE represents encrypted content using JSON data structures and		JWE represents encrypted content using JSON data structures and
	base64url encoding. A JWE represents these logical values:		base64url encoding. These JSON data structures MAY contain white
			space and/or line breaks. A JWE represents these logical values
	JOSE Header		(each of which is defined in Section 2):
	JSON object containing the parameters describing the cryptographic
	operations and parameters employed. For a JWE object, the JOSE
	Header members are the union of the members of the JWE Protected
	Header, the JWE Shared Unprotected Header, and the JWE Per-
	Recipient Unprotected Header, as described below.
	JWE Encrypted Key
	Encrypted Content Encryption Key (CEK) value.
	JWE Initialization Vector
	Initialization Vector value used when encrypting the plaintext.
	JWE AAD
	Additional value to be integrity protected by the authenticated
	encryption operation.
	JWE Ciphertext
	Ciphertext value resulting from authenticated encryption of the
	plaintext with additional authenticated data.
	JWE Authentication Tag
	Authentication Tag value resulting from authenticated encryption
	of the plaintext with additional authenticated data.
	For a JWE object, the JOSE Header represents the combination of these
	logical values:
	JWE Protected Header		o JOSE Header
	JSON object that contains the Header Parameters that are integrity		o JWE Encrypted Key
	protected by the authenticated encryption operation. These		o JWE Initialization Vector
	parameters apply to all recipients of the JWE.		o JWE AAD
			o JWE Ciphertext
			o JWE Authentication Tag
	JWE Shared Unprotected Header		For a JWE object, the JOSE Header members are the union of the
	JSON object that contains the Header Parameters that apply to all		members of these values (each of which is defined in Section 2):
	recipients of the JWE that are not integrity protected.
	JWE Per-Recipient Unprotected Header		o JWE Protected Header
	JSON object that contains Header Parameters that apply to a single		o JWE Shared Unprotected Header
	recipient of the JWE. These Header Parameter values are not		o JWE Per-Recipient Unprotected Header
	integrity protected.
	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 for transmission, since JSON lacks a way to
	directly represent octet sequences. When present, the JWE AAD is		directly represent arbitrary octet sequences. When present, the JWE
	also base64url encoded for transmission.		AAD is also base64url encoded for transmission.
	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
	combination of these five string values,		concatenation:
	BASE64URL(UTF8(JWE Protected Header)),
	BASE64URL(JWE Encrypted Key),		BASE64URL(UTF8(JWE Protected Header)) || '.' ||
	BASE64URL(JWE Initialization Vector),		BASE64URL(JWE Encrypted Key) || '.' ||
	BASE64URL(JWE Ciphertext), and		BASE64URL(JWE Initialization Vector) || '.' ||
	BASE64URL(JWE Authentication Tag),		BASE64URL(JWE Ciphertext) || '.' ||
	concatenated in that order, with the five strings being separated by		BASE64URL(JWE Authentication Tag)
	four period ('.') characters.
	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 combination of the members of the JWE Protected
	Header, JWE Shared Unprotected Header, and JWE Per-Recipient		Header, JWE Shared Unprotected Header, and JWE Per-Recipient
	Unprotected Header values that are present.		Unprotected Header values that are present.
	skipping to change at page 16, line 43 ¶		skipping to change at page 16, line 19 ¶
	9. Generate a random JWE Initialization Vector of the correct size		9. Generate a random JWE Initialization Vector of the correct size
	for the content encryption algorithm (if required for the		for the content encryption algorithm (if required for the
	algorithm); otherwise, let the JWE Initialization Vector be the		algorithm); otherwise, let the JWE Initialization Vector be the
	empty octet sequence.		empty octet sequence.
	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.		the specified compression algorithm and let M be the octet
			sequence representing the compressed Plaintext; otherwise, let M
	12. Serialize the (compressed) Plaintext into an octet sequence M.		be the octet sequence representing the Plaintext.
	13. 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: the JWE
	Protected Header, and if the JWE JSON Serialization is being		Protected Header, and if the JWE JSON Serialization is being
	used, the JWE Shared Unprotected Header and the JWE Per-		used, the JWE Shared Unprotected Header and the JWE Per-
	Recipient Unprotected Header.		Recipient Unprotected Header.
	14. 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.
	15. 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
	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)).
	16. Encrypt M using the CEK, the JWE Initialization Vector, and the		15. Encrypt M using the CEK, the JWE Initialization Vector, and the
	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).
	17. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).		16. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).
	18. Compute the encoded authentication tag value BASE64URL(JWE		17. Compute the encoded authentication tag value BASE64URL(JWE
	Authentication Tag).		Authentication Tag).
	19. The five encoded values are used in both the JWE Compact		18. The five encoded values are used in both the JWE Compact
	Serialization and the JWE JSON Serialization representations.		Serialization and the JWE JSON Serialization representations.
	20. If a JWE AAD value is present, compute the encoded AAD value		19. If a JWE AAD value is present, compute the encoded AAD value
	BASE64URL(JWE AAD).		BASE64URL(JWE AAD).
	21. Create the desired serialized output. The Compact Serialization		20. 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
	there are no dependencies between the inputs and outputs of the		there are no dependencies between the inputs and outputs of the
	steps. If any of these steps fails, the encrypted content cannot be		steps. If any of these steps fails, the encrypted content cannot be
	validated.		validated.
	It is an application decision which recipients' encrypted content		When there are multiple recipients, it is an application decision
	must successfully validate for the JWE to be accepted. In some		which of the recipients' encrypted content must successfully validate
	cases, encrypted content for all recipients must successfully		for the JWE to be accepted. In some cases, encrypted content for all
	validate or the JWE will be rejected. In other cases, only the		recipients must successfully validate or the JWE will be rejected.
	encrypted content for a single recipient needs to be successfully		In other cases, only the encrypted content for a single recipient
	validated. However, in all cases, the encrypted content for at least		needs to be successfully validated. However, in all cases, the
	one recipient MUST successfully validate or the JWE MUST be rejected.		encrypted content for at least one recipient MUST successfully
			validate or the JWE MUST be rejected.
	1. Parse the JWE representation to extract the serialized values		1. Parse the JWE representation to extract the serialized values
	for the components of the JWE. When using the JWE Compact		for the components of the JWE. When using the JWE Compact
	Serialization, these components are the base64url encoded		Serialization, these components are the base64url encoded
	representations of the JWE Protected Header, the JWE Encrypted		representations of the JWE Protected Header, the JWE Encrypted
	Key, the JWE Initialization Vector, the JWE Ciphertext, and the		Key, the JWE Initialization Vector, the JWE Ciphertext, and the
	JWE Authentication Tag, and when using the JWE JSON		JWE Authentication Tag, and when using the JWE JSON
	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
	skipping to change at page 19, line 28 ¶		skipping to change at page 19, line 5 ¶
	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.		recipient JWE Encrypted Key values to obtain the CEK value.
	Also, see Section 11.3 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,		11. 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		12. When Direct Encryption is employed, let the Content Encryption
	Key (CEK) be the shared symmetric key.		Key (CEK) be the shared symmetric key.
	13. If the JWE JSON Serialization is being used, repeat this process		13. Record whether the CEK could be successfully determined for this
	(steps 4-12) for each recipient contained in the representation		recipient or not.
	until the CEK value has been determined.
	14. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE		14. If the JWE JSON Serialization is being used, repeat this process
			(steps 4-13) for each recipient contained in the representation.
			15. 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.
	15. Let the Additional Authenticated Data encryption parameter be		16. 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)).
	16. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization		17. 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.
	17. If a "zip" parameter was included, uncompress the decrypted		18. If a "zip" parameter was included, uncompress the decrypted
	plaintext using the specified compression algorithm.		plaintext using the specified compression algorithm.
	18. If all the previous steps succeeded, output the resulting		19. If there was no recipient for which all of the decryption steps
	Plaintext.		succeeded, then the JWE MUST be rejected. Otherwise, output the
			Plaintext. In the JWE JSON Serialization case, also return a
			result to the application indicating for which of the recipients
			the decryption succeeded and failed.
			Finally, note that it is an application decision which algorithms are
			acceptable in a given context. Even if a JWE can be successfully
			decrypted, unless the algorithms used in the JWE are acceptable to
			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
	The key identification methods for this specification are the same as		The key identification methods for this specification are the same as
	those defined in Section 6 of [JWS], except that the key being		those defined in Section 6 of [JWS], except that the key being
	skipping to change at page 20, line 47 ¶		skipping to change at page 20, line 34 ¶
	features are used for that application. For instance, applications		features are used for that application. For instance, applications
	might specify that only the JWE JSON Serialization is used, that only		might specify that only the JWE JSON Serialization is used, that only
	JWE JSON Serialization support for a single recipient is used, or		JWE JSON Serialization support for a single recipient is used, or
	that support for multiple recipients is used. JWE implementations		that support for multiple recipients is used. JWE implementations
	only need to implement the features needed for the applications they		only need to implement the features needed for the applications they
	are designed to support.		are designed to support.
	7.1. JWE Compact Serialization		7.1. JWE Compact Serialization
	The JWE Compact Serialization represents encrypted content as a		The JWE Compact Serialization represents encrypted content as a
	compact URL-safe string. This string is BASE64URL(UTF8(JWE Protected		compact, URL-safe string. This string is:
	Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' ||
	BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE		BASE64URL(UTF8(JWE Protected Header)) || '.' ||
	Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). Only one		BASE64URL(JWE Encrypted Key) || '.' ||
	recipient is supported by the JWE Compact Serialization and it		BASE64URL(JWE Initialization Vector) || '.' ||
	provides no syntax to represent JWE Shared Unprotected Header, JWE		BASE64URL(JWE Ciphertext) || '.' ||
			BASE64URL(JWE Authentication Tag)
			Only one recipient is supported by the JWE Compact Serialization and
			it provides no syntax to represent JWE Shared Unprotected Header, JWE
	Per-Recipient Unprotected Header, or JWE AAD values.		Per-Recipient Unprotected Header, or JWE AAD values.
	7.2. JWE JSON Serialization		7.2. JWE JSON Serialization
	The JWE JSON Serialization represents encrypted content as a JSON		The JWE JSON Serialization represents encrypted content as a JSON
	object. Content using the JWE JSON Serialization can be encrypted to		object. Content using the JWE JSON Serialization can be encrypted to
	more than one recipient. This representation is neither optimized		more than one recipient. This representation is neither optimized
	for compactness nor URL-safe.		for compactness nor URL-safe.
	The following members are defined for use in top-level JSON objects		The following members are defined for use in top-level JSON objects
	skipping to change at page 26, line 41 ¶		skipping to change at page 26, line 31 ¶
	o Header Parameter Description: Critical		o Header Parameter Description: Critical
	o Header Parameter Usage Location(s): JWE		o Header Parameter Usage Location(s): JWE
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 4.1.13 of [[ this document ]]		o Specification Document(s): Section 4.1.13 of [[ this document ]]
	11. Security Considerations		11. Security Considerations
	All of the security issues that are pertinent to any cryptographic		All of the security issues that are pertinent to any cryptographic
	application must be addressed by JWS/JWE/JWK agents. Among these		application must be addressed by JWS/JWE/JWK agents. Among these
	issues are protecting the user's asymmetric private and symmetric		issues are protecting the user's asymmetric private and symmetric
	secret keys, preventing various attacks, and helping avoid mistakes		secret keys and employing countermeasures to various attacks.
	such as inadvertently encrypting a message to the wrong recipient.
	The entire list of security considerations is beyond the scope of
	this document, but some significant considerations are listed here.
	All the security considerations in the JWS specification also apply		All the security considerations in the JWS specification also apply
	to this specification. Likewise, all the security considerations in		to this specification. Likewise, all the security considerations in
	XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other		XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other
	than those that are XML specific.		than those that are XML specific.
	11.1. Using Matching Algorithm Strengths		11.1. Key Entropy and Random Values
			See Section 10.1 of [JWS] for security considerations on key entropy
			and random values. In addition to the uses of random values listed
			there, note that random values are also used for content encryption
			keys (CEKs) and initialization vectors (IVs) when performing
			encryption.
			11.2. Key Protection
			See Section 10.2 of [JWS] for security considerations on key
			protection. In addition to the keys listed there that must be
			protected, implementations performing encryption must protect the key
			encryption key and the content encryption key. Compromise of the key
			encryption key may result in the disclosure of all contents protected
			with that key. Similarly, compromise of the content encryption key
			may result in disclosure of the associated encrypted content.
			11.3. Using Matching Algorithm Strengths
	Algorithms of matching strengths should be used together whenever		Algorithms of matching strengths should be used together whenever
	possible. For instance, when AES Key Wrap is used with a given key		possible. For instance, when AES Key Wrap is used with a given key
	size, using the same key size is recommended when AES GCM is also		size, using the same key size is recommended when AES GCM is also
	used.		used. If the key encryption and content encryption algorithms are
			different, the effective security is determined by the weaker of the
			two algorithms.
	11.2. Adaptive Chosen-Ciphertext Attacks		Also, see RFC 3766 [RFC3766] for information on determining strengths
			for public keys used for exchanging symmetric keys.
			11.4. Adaptive Chosen-Ciphertext Attacks
	When decrypting, particular care must be taken not to allow the JWE		When decrypting, particular care must be taken not to allow the JWE
	recipient to be used as an oracle for decrypting messages. RFC 3218		recipient to be used as an oracle for decrypting messages. RFC 3218
	[RFC3218] should be consulted for specific countermeasures to attacks		[RFC3218] should be consulted for specific countermeasures to attacks
	on RSAES-PKCS1-V1_5. An attacker might modify the contents of the		on RSAES-PKCS1-V1_5. An attacker might modify the contents of the
	"alg" parameter from "RSA-OAEP" to "RSA1_5" in order to generate a		"alg" parameter from "RSA-OAEP" to "RSA1_5" in order to generate a
	formatting error that can be detected and used to recover the CEK		formatting error that can be detected and used to recover the CEK
	even if RSAES OAEP was used to encrypt the CEK. It is therefore		even if RSAES OAEP was used to encrypt the CEK. It is therefore
	particularly important to report all formatting errors to the CEK,		particularly important to report all formatting errors to the CEK,
	Additional Authenticated Data, or ciphertext as a single error when		Additional Authenticated Data, or ciphertext as a single error when
	the encrypted content is rejected.		the encrypted content is rejected.
	Additionally, this type of attack can be prevented by the use of "key		Additionally, this type of attack can be prevented by restricting the
	tainting". This method restricts the use of a key to a limited set		use of a key to a limited set of algorithms -- usually one. This
	of algorithms -- usually one. This means, for instance, that if the		means, for instance, that if the key is marked as being for
	key is marked as being for "RSA-OAEP" only, any attempt to decrypt a		"RSA-OAEP" only, any attempt to decrypt a message using the "RSA1_5"
	message using the "RSA1_5" algorithm with that key would fail		algorithm with that key should fail immediately due to invalid use of
	immediately due to invalid use of the key.		the key.
	11.3. 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 receiver
	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),
	July 2014.		September 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),
	July 2014.		September 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), July 2014.		in progress), September 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.
	skipping to change at page 29, line 4 ¶		skipping to change at page 29, line 14 ¶
	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.
	[NIST.800-38D]		[NIST.800-38D]
	National Institute of Standards and Technology (NIST),		National Institute of Standards and Technology (NIST),
	"Recommendation for Block Cipher Modes of Operation:		"Recommendation for Block Cipher Modes of Operation:
	Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,		Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,
	December 2001.		December 2001.
	[RFC3218] Rescorla, E., "Preventing the Million Message Attack on		[RFC3218] Rescorla, E., "Preventing the Million Message Attack on
	Cryptographic Message Syntax", RFC 3218, January 2002.		Cryptographic Message Syntax", RFC 3218, January 2002.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
			[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
			Public Keys Used For Exchanging Symmetric Keys", BCP 86,
			RFC 3766, April 2004.
	[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Requirements for Security", BCP 106, RFC 4086, June 2005.		Requirements for Security", BCP 106, RFC 4086, June 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.REC-xmlenc-core1-20130411]		[W3C.REC-xmlenc-core1-20130411]
	Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,		Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
	"XML Encryption Syntax and Processing Version 1.1", World		"XML Encryption Syntax and Processing Version 1.1", World
	Wide Web Consortium Recommendation REC-xmlenc-core1-		Wide Web Consortium Recommendation REC-xmlenc-core1-
	skipping to change at page 46, line 4 ¶		skipping to change at page 46, line 32 ¶
	Eric Rescorla, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean		Eric Rescorla, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean
	Turner.		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 ]]
			-32
			o Addressed Gen-ART review comments by Russ Housley.
			o Addressed secdir review comments by Scott Kelly, Tero Kivinen, and
			Stephen Kent.
	-31		-31
	o Updated the reference to draft-mcgrew-aead-aes-cbc-hmac-sha2.		o Updated the reference to draft-mcgrew-aead-aes-cbc-hmac-sha2.
	-30		-30
	o Added subsection headings within the Overview section for the two		o Added subsection headings within the Overview section for the two
	serializations.		serializations.
	o Added references and cleaned up the reference syntax in a few		o Added references and cleaned up the reference syntax in a few
End of changes. 63 change blocks.
	145 lines changed or deleted		165 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/