< draft-ietf-jose-json-web-encryption-34.txt		draft-ietf-jose-json-web-encryption-35.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: April 17, 2015 Cisco		Expires: April 20, 2015 Cisco
	October 14, 2014		October 17, 2014
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	draft-ietf-jose-json-web-encryption-34		draft-ietf-jose-json-web-encryption-35
	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 April 17, 2015.		This Internet-Draft will expire on April 20, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	10.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 24		10.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 24
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 26		11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26		11.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26
	11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . . 27		11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . . 27
	11.3. Using Matching Algorithm Strengths . . . . . . . . . . . . 27		11.3. Using Matching Algorithm Strengths . . . . . . . . . . . . 27
	11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 27		11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 27
	11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 27		11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 28		12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	12.2. Informative References . . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 30		Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 29
	A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 30		A.1. Example JWE using RSAES OAEP and AES GCM . . . . . . . . . 30
	A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 30		A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 30
	A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 30		A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 30
	A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 31		A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 30
	A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 32		A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 32
	A.1.5. Additional Authenticated Data . . . . . . . . . . . . 32		A.1.5. Additional Authenticated Data . . . . . . . . . . . . 32
	A.1.6. Content Encryption . . . . . . . . . . . . . . . . . . 32		A.1.6. Content Encryption . . . . . . . . . . . . . . . . . . 32
	A.1.7. Complete Representation . . . . . . . . . . . . . . . 33		A.1.7. Complete Representation . . . . . . . . . . . . . . . 33
	A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . . 33		A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . . 33
	A.2. Example JWE using RSAES-PKCS1-V1_5 and		A.2. Example JWE using RSAES-PKCS1-V1_5 and
	AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 33		AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . . 33
	A.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 34		A.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 34
	A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 34		A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . . 34
	A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 34		A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . . 34
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	words for use in RFCs to Indicate Requirement Levels [RFC2119]. If		words for use in RFCs to Indicate Requirement Levels [RFC2119]. If
	these words are used without being spelled in uppercase then they are		these words are used without being spelled in uppercase then they are
	to be interpreted with their normal natural language meanings.		to be interpreted with their normal natural language meanings.
	BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per		BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
	Section 2 of [JWS].		Section 2 of [JWS].
	UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation		UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
	of STRING.		of STRING.
	ASCII(STRING) denotes the octets of the ASCII [USASCII]		ASCII(STRING) denotes the octets of the ASCII [RFC20] representation
	representation of STRING.		of STRING.
	The concatenation of two values A and B is denoted as A || B.		The concatenation of two values A and B is denoted as A || B.
	2. Terminology		2. Terminology
	These terms defined by the JSON Web Signature (JWS) [JWS]		These terms defined by the JSON Web Signature (JWS) [JWS]
	specification are incorporated into this specification: "JSON Web		specification are incorporated into this specification: "JSON Web
	Signature (JWS)", "Base64url Encoding", "Collision-Resistant Name",		Signature (JWS)", "Base64url Encoding", "Collision-Resistant Name",
	"Header Parameter", "JOSE Header", and "StringOrURI".		"Header Parameter", "JOSE Header", and "StringOrURI".
	These terms defined by the Internet Security Glossary, Version 2		These terms defined by the Internet Security Glossary, Version 2
	[RFC4949] are incorporated into this specification: "Ciphertext" and		[RFC4949] are incorporated into this specification: "Ciphertext",
			"Digital Signature", "Message Authentication Code (MAC)", and
	"Plaintext".		"Plaintext".
	These terms are defined by this specification:		These terms are defined by this specification:
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	A data structure representing an encrypted and integrity protected		A data structure representing an encrypted and integrity protected
	message.		message.
	Authenticated Encryption with Associated Data (AEAD)		Authenticated Encryption with Associated Data (AEAD)
	An AEAD algorithm is one that encrypts the Plaintext, allows		An AEAD algorithm is one that encrypts the Plaintext, allows
	skipping to change at page 9, line 51 ¶		skipping to change at page 9, line 51 ¶
	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 union of the members of the JWE Protected Header,		JOSE Header are the union of the members of the JWE Protected Header,
	JWE Shared Unprotected Header, and JWE Per-Recipient Unprotected		JWE Shared Unprotected Header, and JWE Per-Recipient Unprotected
	Header values that are present.		Header values that are present.
	In the JWE JSON Serialization, a JWE object is represented as the		In the JWE JSON Serialization, a JWE object is represented as the
	combination of these eight values,		combination of these eight values:
	BASE64URL(UTF8(JWE Protected Header)),
	JWE Shared Unprotected Header,		BASE64URL(UTF8(JWE Protected Header))
	JWE Per-Recipient Unprotected Header,		JWE Shared Unprotected Header
	BASE64URL(JWE Encrypted Key),		JWE Per-Recipient Unprotected Header
	BASE64URL(JWE Initialization Vector),		BASE64URL(JWE Encrypted Key)
	BASE64URL(JWE Ciphertext),		BASE64URL(JWE Initialization Vector)
	BASE64URL(JWE Authentication Tag), and		BASE64URL(JWE Ciphertext)
	BASE64URL(JWE AAD),		BASE64URL(JWE Authentication Tag)
	with the six base64url encoded result strings and the two unprotected		BASE64URL(JWE AAD)
	JSON object values being represented as members within a JSON object.
	The inclusion of some of these values is OPTIONAL. The JWE JSON		The six base64url encoded result strings and the two unprotected JSON
			object values are represented as members within a JSON object. The
			inclusion of some of these values is OPTIONAL. The JWE JSON
	Serialization can also encrypt the plaintext to multiple recipients.		Serialization can also encrypt the plaintext to multiple recipients.
	See Section 7.2 for more information about the JWE JSON		See Section 7.2 for more information about the JWE JSON
	Serialization.		Serialization.
	3.3. Example JWE		3.3. Example JWE
	This example encrypts the plaintext "The true sign of intelligence is		This example encrypts the plaintext "The true sign of intelligence is
	not knowledge but imagination." to the recipient.		not knowledge but imagination." to the recipient.
	The following example JWE Protected Header declares that:		The following example JWE Protected Header declares that:
	o the Content Encryption Key is encrypted to the recipient using the
	RSAES OAEP [RFC3447] algorithm to produce the JWE Encrypted Key		o The Content Encryption Key is encrypted to the recipient using the
	and		RSAES OAEP [RFC3447] algorithm to produce the JWE Encrypted Key.
	o authenticated encryption is performed on the Plaintext using the
			o Authenticated encryption is performed on the Plaintext using the
	AES GCM [AES, NIST.800-38D] algorithm with a 256 bit key to		AES GCM [AES, NIST.800-38D] algorithm with a 256 bit key to
	produce the Ciphertext and the Authentication Tag.		produce the Ciphertext and the Authentication Tag.
	{"alg":"RSA-OAEP","enc":"A256GCM"}		{"alg":"RSA-OAEP","enc":"A256GCM"}
	Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected		Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
	Header)) gives this value:		Header)) gives this value:
	eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ		eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
	skipping to change at page 12, line 51 ¶		skipping to change at page 13, line 7 ¶
	The "zip" (compression algorithm) applied to the Plaintext before		The "zip" (compression algorithm) applied to the Plaintext before
	encryption, if any. The "zip" value defined by this specification		encryption, if any. The "zip" value defined by this specification
	is:		is:
	o "DEF" - Compression with the DEFLATE [RFC1951] algorithm		o "DEF" - Compression with the DEFLATE [RFC1951] algorithm
	Other values MAY be used. Compression algorithm values can be		Other values MAY be used. Compression algorithm values can be
	registered in the IANA JSON Web Encryption Compression Algorithm		registered in the IANA JSON Web Encryption Compression Algorithm
	registry defined in [JWA]. The "zip" value is a case-sensitive		registry defined in [JWA]. The "zip" value is a case-sensitive
	string. If no "zip" parameter is present, no compression is applied		string. If no "zip" parameter is present, no compression is applied
	to the Plaintext before encryption. This Header Parameter MUST be		to the Plaintext before encryption. When used, this Header Parameter
	integrity protected, and therefore MUST occur only within the JWE		MUST be integrity protected; therefore, it MUST occur only within the
	Protected Header, when used. Use of this Header Parameter is		JWE Protected Header. Use of this Header Parameter is OPTIONAL.
	OPTIONAL. This Header Parameter MUST be understood and processed by		This Header Parameter MUST be understood and processed by
	implementations.		implementations.
	4.1.4. "jku" (JWK Set URL) Header Parameter		4.1.4. "jku" (JWK Set URL) Header Parameter
	This parameter has the same meaning, syntax, and processing rules as		This parameter has the same meaning, syntax, and processing rules as
	the "jku" Header Parameter defined in Section 4.1.2 of [JWS], except		the "jku" Header Parameter defined in Section 4.1.2 of [JWS], except
	that the JWK Set resource contains the public key to which the JWE		that the JWK Set resource contains the public key to which the JWE
	was encrypted; this can be used to determine the private key needed		was encrypted; this can be used to determine the private key needed
	to decrypt the JWE.		to decrypt the JWE.
	skipping to change at page 17, line 50 ¶		skipping to change at page 17, line 51 ¶
	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
	Header values. When using the JWE Compact Serialization, the		Header values. When using the JWE Compact Serialization, the
	JWE Protected Header, the JWE Encrypted Key, the JWE		JWE Protected Header, the JWE Encrypted Key, the JWE
	Initialization Vector, the JWE Ciphertext, and the JWE		Initialization Vector, the JWE Ciphertext, and the JWE
	Authentication Tag are represented as base64url encoded values		Authentication Tag are represented as base64url encoded values
	in that order, separated by four period ('.') characters. The		in that order, with each value being separated from the next by
	JWE JSON Serialization is described in Section 7.2.		a single period ('.') character, resulting in exactly four
			delimiting period characters being used. The JWE JSON
			Serialization is described in Section 7.2.
	2. Base64url decode the encoded representations of the JWE		2. Base64url decode the encoded representations of the JWE
	Protected Header, the JWE Encrypted Key, the JWE Initialization		Protected Header, the JWE Encrypted Key, the JWE Initialization
	Vector, the JWE Ciphertext, the JWE Authentication Tag, and the		Vector, the JWE Ciphertext, the JWE Authentication Tag, and the
	JWE AAD, following the restriction that no line breaks, white		JWE AAD, following the restriction that no line breaks, white
	space, or other additional characters have been used.		space, or other additional characters have been used.
	3. Verify that the octet sequence resulting from decoding the		3. Verify that the octet sequence resulting from decoding the
	encoded JWE Protected Header is a UTF-8 encoded representation		encoded JWE Protected Header is a UTF-8 encoded representation
	of a completely valid JSON object conforming to RFC 7159		of a completely valid JSON object conforming to RFC 7159
	skipping to change at page 28, line 26 ¶		skipping to change at page 28, line 26 ¶
	draft-ietf-jose-json-web-key (work in progress),		draft-ietf-jose-json-web-key (work in progress),
	October 2014.		October 2014.
	[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", draft-ietf-jose-json-web-signature (work		Signature (JWS)", draft-ietf-jose-json-web-signature (work
	in progress), October 2014.		in progress), October 2014.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, May 1996.		version 1.3", RFC 1951, May 1996.
			[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
			October 1969.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	RFC 4949, August 2007.		RFC 4949, August 2007.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014.		Interchange Format", RFC 7159, March 2014.
	[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.
	12.2. Informative References		12.2. Informative References
	[AES] National Institute of Standards and Technology (NIST),		[AES] National Institute of Standards and Technology (NIST),
	"Advanced Encryption Standard (AES)", FIPS PUB 197,		"Advanced Encryption Standard (AES)", FIPS PUB 197,
	November 2001.		November 2001.
	[I-D.mcgrew-aead-aes-cbc-hmac-sha2]		[I-D.mcgrew-aead-aes-cbc-hmac-sha2]
	McGrew, D., Foley, J., and K. Paterson, "Authenticated		McGrew, D., Foley, J., and K. Paterson, "Authenticated
	Encryption with AES-CBC and HMAC-SHA",		Encryption with AES-CBC and HMAC-SHA",
	draft-mcgrew-aead-aes-cbc-hmac-sha2-05 (work in progress),		draft-mcgrew-aead-aes-cbc-hmac-sha2-05 (work in progress),
	skipping to change at page 30, line 26 ¶		skipping to change at page 30, line 22 ¶
	[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32,		[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32,
	111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99,		111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99,
	101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108,		101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108,
	101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105,		101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105,
	110, 97, 116, 105, 111, 110, 46]		110, 97, 116, 105, 111, 110, 46]
	A.1.1. JOSE Header		A.1.1. JOSE Header
	The following example JWE Protected Header declares that:		The following example JWE Protected Header declares that:
	o the Content Encryption Key is encrypted to the recipient using the		o The Content Encryption Key is encrypted to the recipient using the
	RSAES OAEP algorithm to produce the JWE Encrypted Key and		RSAES OAEP algorithm to produce the JWE Encrypted Key.
	o authenticated encryption is performed on the Plaintext using the		o Authenticated encryption is performed on the Plaintext using the
	AES GCM algorithm with a 256 bit key to produce the Ciphertext and		AES GCM algorithm with a 256 bit key to produce the Ciphertext and
	the Authentication Tag.		the Authentication Tag.
	{"alg":"RSA-OAEP","enc":"A256GCM"}		{"alg":"RSA-OAEP","enc":"A256GCM"}
	Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected		Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
	Header)) gives this value:		Header)) gives this value:
	eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ		eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
	skipping to change at page 34, line 12 ¶		skipping to change at page 34, line 9 ¶
	AES_128_CBC_HMAC_SHA_256 for content encryption. The representation		AES_128_CBC_HMAC_SHA_256 for content encryption. The representation
	of this plaintext (using JSON array notation) is:		of this plaintext (using JSON array notation) is:
	[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,		[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
	112, 114, 111, 115, 112, 101, 114, 46]		112, 114, 111, 115, 112, 101, 114, 46]
	A.2.1. JOSE Header		A.2.1. JOSE Header
	The following example JWE Protected Header declares that:		The following example JWE Protected Header declares that:
	o the Content Encryption Key is encrypted to the recipient using the		o The Content Encryption Key is encrypted to the recipient using the
	RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and		RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key.
	o authenticated encryption is performed on the Plaintext using the		o Authenticated encryption is performed on the Plaintext using the
	AES_128_CBC_HMAC_SHA_256 algorithm to produce the Ciphertext and		AES_128_CBC_HMAC_SHA_256 algorithm to produce the Ciphertext and
	the Authentication Tag.		the Authentication Tag.
	{"alg":"RSA1_5","enc":"A128CBC-HS256"}		{"alg":"RSA1_5","enc":"A128CBC-HS256"}
	Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected		Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
	Header)) gives this value:		Header)) gives this value:
	eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0		eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
	skipping to change at page 38, line 9 ¶		skipping to change at page 38, line 9 ¶
	AES_128_CBC_HMAC_SHA_256 for content encryption. The representation		AES_128_CBC_HMAC_SHA_256 for content encryption. The representation
	of this plaintext (using JSON array notation) is:		of this plaintext (using JSON array notation) is:
	[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,		[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
	112, 114, 111, 115, 112, 101, 114, 46]		112, 114, 111, 115, 112, 101, 114, 46]
	A.3.1. JOSE Header		A.3.1. JOSE Header
	The following example JWE Protected Header declares that:		The following example JWE Protected Header declares that:
	o the Content Encryption Key is encrypted to the recipient using the		o The Content Encryption Key is encrypted to the recipient using the
	AES Key Wrap algorithm with a 128 bit key to produce the JWE		AES Key Wrap algorithm with a 128 bit key to produce the JWE
	Encrypted Key and		Encrypted Key.
	o authenticated encryption is performed on the Plaintext using the		o Authenticated encryption is performed on the Plaintext using the
	AES_128_CBC_HMAC_SHA_256 algorithm to produce the Ciphertext and		AES_128_CBC_HMAC_SHA_256 algorithm to produce the Ciphertext and
	the Authentication Tag.		the Authentication Tag.
	{"alg":"A128KW","enc":"A128CBC-HS256"}		{"alg":"A128KW","enc":"A128CBC-HS256"}
	Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected		Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected
	Header)) gives this value:		Header)) gives this value:
	eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0		eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
	skipping to change at page 46, line 23 ¶		skipping to change at page 46, line 23 ¶
	This specification is the work of the JOSE Working Group, which		This specification is the work of the JOSE Working Group, which
	includes dozens of active and dedicated participants. In particular,		includes dozens of active and dedicated participants. In particular,
	the following individuals contributed ideas, feedback, and wording		the following individuals contributed ideas, feedback, and wording
	that influenced this specification:		that influenced this specification:
	Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de		Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de
	Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley,		Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley,
	Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger,		Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger,
	Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel		Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel
	Nennker, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura,		Nennker, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat
	Jim Schaad, Hannes Tschofenig, and Sean Turner.		Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
	Jim Schaad and Karen O'Donoghue chaired the JOSE working group and		Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
	Sean Turner, Stephen Farrell, and Kathleen Moriarty served as		Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
	Security area directors during the creation of this specification.		Security area directors during the creation of this specification.
	Appendix D. Document History		Appendix D. Document History
	[[ to be removed by the RFC Editor before publication as an RFC ]]		[[ to be removed by the RFC Editor before publication as an RFC ]]
			-35
			o Addressed AppsDir reviews by Ray Polk.
	-34		-34
	o Addressed IESG review comments by Barry Leiba, Alissa Cooper, Pete		o Addressed IESG review comments by Barry Leiba, Alissa Cooper, Pete
	Resnick, Stephen Farrell, and Richard Barnes.		Resnick, Stephen Farrell, and Richard Barnes.
	-33		-33
	o Noted that certificate thumbprints are also sometimes known as		o Noted that certificate thumbprints are also sometimes known as
	certificate fingerprints.		certificate fingerprints.
End of changes. 22 change blocks.
	46 lines changed or deleted		55 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/