< draft-ietf-jose-json-web-encryption-25.txt		draft-ietf-jose-json-web-encryption-26.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: October 2, 2014 Cisco		Expires: November 1, 2014 Cisco
	March 31, 2014		April 30, 2014
	JSON Web Encryption (JWE)		JSON Web Encryption (JWE)
	draft-ietf-jose-json-web-encryption-25		draft-ietf-jose-json-web-encryption-26
	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 October 2, 2014.		This Internet-Draft will expire on November 1, 2014.
	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 26, line 26 ¶		skipping to change at page 26, line 26 ¶
	All of the security issues faced by any cryptographic application		All of the security issues faced by any cryptographic application
	must be faced by a JWS/JWE/JWK agent. Among these issues are		must be faced by a JWS/JWE/JWK agent. Among these issues are
	protecting the user's private and symmetric keys, preventing various		protecting the user's private and symmetric keys, preventing various
	attacks, and helping the user avoid mistakes such as inadvertently		attacks, and helping the user avoid mistakes such as inadvertently
	encrypting a message for the wrong recipient. The entire list of		encrypting a message for the wrong recipient. The entire list of
	security considerations is beyond the scope of this document.		security considerations is beyond the scope of this document.
	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.CR-xmlenc-core1-20120313] 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.
	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,
	skipping to change at page 27, line 12 ¶		skipping to change at page 27, line 12 ¶
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[ECMAScript]		[ECMAScript]
	Ecma International, "ECMAScript Language Specification,		Ecma International, "ECMAScript Language Specification,
	5.1 Edition", ECMA 262, June 2011.		5.1 Edition", ECMA 262, June 2011.
	[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),
	March 2014.		April 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),
	March 2014.		April 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), March 2014.		in progress), April 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 27, line 46 ¶		skipping to change at page 27, line 46 ¶
	[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014.		Interchange Format", RFC 7159, March 2014.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	12.2. Informative References		12.2. Informative References
	[I-D.mcgrew-aead-aes-cbc-hmac-sha2]		[I-D.mcgrew-aead-aes-cbc-hmac-sha2]
	McGrew, D. and K. Paterson, "Authenticated Encryption with		McGrew, D., Foley, J., and K. Paterson, "Authenticated
	AES-CBC and HMAC-SHA",		Encryption with AES-CBC and HMAC-SHA",
	draft-mcgrew-aead-aes-cbc-hmac-sha2-01 (work in progress),		draft-mcgrew-aead-aes-cbc-hmac-sha2-04 (work in progress),
	October 2012.		February 2014.
	[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.
	[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.
	[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.CR-xmlenc-core1-20120313]		[W3C.REC-xmlenc-core1-20130411]
	Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,		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 CR CR-xmlenc-core1-20120313,		Wide Web Consortium Recommendation REC-xmlenc-core1-
	March 2012,		20130411, April 2013,
	<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.		<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
	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 "The true sign of intelligence is		This example encrypts the plaintext "The true sign of intelligence is
	not knowledge but imagination." to the recipient using RSAES OAEP for		not knowledge but imagination." to the recipient using RSAES OAEP for
	key encryption and AES GCM for content encryption. The		key encryption and AES GCM for content encryption. The
	representation of this plaintext is:		representation of this plaintext (using JSON array notation) is:
	[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. JWE Header		A.1.1. JWE Header
	The following example JWE Protected Header declares that:		The following example JWE Protected Header declares that:
	skipping to change at page 29, line 18 ¶		skipping to change at page 29, line 18 ¶
	{"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
	A.1.2. Content Encryption Key (CEK)		A.1.2. Content Encryption Key (CEK)
	Generate a 256 bit random Content Encryption Key (CEK). In this		Generate a 256 bit random Content Encryption Key (CEK). In this
	example, the value is:		example, the value (using JSON array notation) is:
	[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,		[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,
	212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,		212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,
	234, 64, 252]		234, 64, 252]
	A.1.3. Key Encryption		A.1.3. Key Encryption
	Encrypt the CEK with the recipient's public key using the RSAES OAEP		Encrypt the CEK with the recipient's public key using the RSAES OAEP
	algorithm to produce the JWE Encrypted Key. This example uses the RSA		algorithm to produce the JWE Encrypted Key. This example uses the RSA
	key represented in JSON Web Key [JWK] format below (with line breaks		key represented in JSON Web Key [JWK] format below (with line breaks
	skipping to change at page 32, line 33 ¶		skipping to change at page 32, line 33 ¶
	includes random values, the encryption results above will not be		includes random values, the encryption results above will not be
	completely reproducible. However, since the AES GCM computation is		completely reproducible. However, since the AES GCM computation is
	deterministic, the JWE Encrypted Ciphertext values will be the same		deterministic, the JWE Encrypted Ciphertext values will be the same
	for all encryptions performed using these inputs.		for all encryptions performed using these inputs.
	A.2. Example JWE using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256		A.2. Example JWE using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256
	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-PKCS1-V1_5 for key encryption and		recipient using RSAES-PKCS1-V1_5 for key encryption and
	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 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. JWE Header		A.2.1. JWE 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 and
	skipping to change at page 36, line 13 ¶		skipping to change at page 36, line 13 ¶
	PKCS1-V1_5 computation includes random values, the encryption results		PKCS1-V1_5 computation includes random values, the encryption results
	above will not be completely reproducible. However, since the AES		above will not be completely reproducible. However, since the AES
	CBC computation is deterministic, the JWE Encrypted Ciphertext values		CBC computation is deterministic, the JWE Encrypted Ciphertext values
	will be the same for all encryptions performed using these inputs.		will be the same for all encryptions performed using these inputs.
	A.3. Example JWE using AES Key Wrap and AES_128_CBC_HMAC_SHA_256		A.3. Example JWE using AES Key Wrap and AES_128_CBC_HMAC_SHA_256
	This example encrypts the plaintext "Live long and prosper." to the		This example encrypts the plaintext "Live long and prosper." to the
	recipient using AES Key Wrap for key encryption and		recipient using AES Key Wrap for key encryption and
	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 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. JWE Header		A.3.1. JWE 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
	skipping to change at page 42, line 13 ¶		skipping to change at page 42, line 13 ¶
	authenticated encryption computation using the values from the		authenticated encryption computation using the values from the
	example in Appendix A.3. As described where this algorithm is		example in Appendix A.3. As described where this algorithm is
	defined in Sections 5.2 and 5.2.3 of JWA, the AES_CBC_HMAC_SHA2		defined in Sections 5.2 and 5.2.3 of JWA, the AES_CBC_HMAC_SHA2
	family of algorithms are implemented using Advanced Encryption		family of algorithms are implemented using Advanced Encryption
	Standard (AES) in Cipher Block Chaining (CBC) mode with PKCS #5		Standard (AES) in Cipher Block Chaining (CBC) mode with PKCS #5
	padding to perform the encryption and an HMAC SHA-2 function to		padding to perform the encryption and an HMAC SHA-2 function to
	perform the integrity calculation - in this case, HMAC SHA-256.		perform the integrity calculation - in this case, HMAC SHA-256.
	B.1. Extract MAC_KEY and ENC_KEY from Key		B.1. Extract MAC_KEY and ENC_KEY from Key
	The 256 bit AES_128_CBC_HMAC_SHA_256 key K used in this example is:		The 256 bit AES_128_CBC_HMAC_SHA_256 key K used in this example
			(using JSON array notation) is:
	[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,		[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
	206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,		206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
	44, 207]		44, 207]
	Use the first 128 bits of this key as the HMAC SHA-256 key MAC_KEY,		Use the first 128 bits of this key as the HMAC SHA-256 key MAC_KEY,
	which is:		which is:
	[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,		[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
	206]		206]
	skipping to change at page 44, line 15 ¶		skipping to change at page 44, line 15 ¶
	[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,		[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
	194, 85]		194, 85]
	Appendix C. Acknowledgements		Appendix C. Acknowledgements
	Solutions for encrypting JSON content were also explored by JSON		Solutions for encrypting JSON content were also explored by JSON
	Simple Encryption [JSE] and JavaScript Message Security Format		Simple Encryption [JSE] and JavaScript Message Security Format
	[I-D.rescorla-jsms], both of which significantly influenced this		[I-D.rescorla-jsms], both of which significantly influenced this
	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.REC-xmlenc-core1-20130411] 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, Eric Rescorla, and Nat		Special thanks are due to John Bradley, Eric Rescorla, and Nat
	Sakimura for the discussions that helped inform the content of this		Sakimura for the discussions that helped inform the content of this
	specification, to Eric Rescorla and Joe Hildebrand for allowing the		specification, to Eric Rescorla and Joe Hildebrand for allowing the
	reuse of text from [I-D.rescorla-jsms] in this document, and to Eric		reuse of text from [I-D.rescorla-jsms] in this document, and to Eric
	Rescorla for co-authoring many drafts of this specification.		Rescorla for co-authoring many drafts of this specification.
	Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund		Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund
	Jay for validating the examples in this specification.		Jay for validating the examples in this specification.
	skipping to change at page 44, line 38 ¶		skipping to change at page 44, line 38 ¶
	includes dozens of active and dedicated participants. In particular,		includes dozens of active and dedicated participants. In particular,
	the following individuals contributed ideas, feedback, and wording		the following individuals contributed ideas, feedback, and wording
	that influenced this specification:		that influenced this specification:
	Richard Barnes, John Bradley, Brian Campbell, Breno de Medeiros, Dick		Richard Barnes, John Bradley, Brian Campbell, Breno de Medeiros, Dick
	Hardt, Jeff Hodges, Edmund Jay, James Manger, Matt Miller, Tony		Hardt, Jeff Hodges, Edmund Jay, James Manger, Matt Miller, Tony
	Nadalin, Hideki Nara, Axel Nennker, Emmanuel Raviart, Eric Rescorla,		Nadalin, Hideki Nara, Axel Nennker, Emmanuel Raviart, Eric Rescorla,
	Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.		Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
	Jim Schaad and Karen O'Donoghue chaired the JOSE working group and		Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
	Sean Turner and Stephen Farrell served as Security area directors		Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
	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 ]]
			-26
			o Noted that octet sequences are depicted using JSON array notation.
			o Updated references, including to W3C specifications.
	-25		-25
	o Corrected two external section number references that had changed.		o Corrected two external section number references that had changed.
	o Corrected a typo in an algorithm name in the prose of an example.		o Corrected a typo in an algorithm name in the prose of an example.
	-24		-24
	o Corrected complete JSON Serialization example.		o Corrected complete JSON Serialization example.
	skipping to change at page 51, line 34 ¶		skipping to change at page 51, line 39 ¶
	o Indented artwork elements to better distinguish them from the body		o Indented artwork elements to better distinguish them from the body
	text.		text.
	-04		-04
	o Refer to the registries as the primary sources of defined values		o Refer to the registries as the primary sources of defined values
	and then secondarily reference the sections defining the initial		and then secondarily reference the sections defining the initial
	contents of the registries.		contents of the registries.
	o Normatively reference XML Encryption 1.1		o Normatively reference XML Encryption 1.1 for its security
	[W3C.CR-xmlenc-core1-20120313] for its security considerations.		considerations.
	o Reference draft-jones-jose-jwe-json-serialization instead of		o Reference draft-jones-jose-jwe-json-serialization instead of
	draft-jones-json-web-encryption-json-serialization.		draft-jones-json-web-encryption-json-serialization.
	o Described additional open issues.		o Described additional open issues.
	o Applied editorial suggestions.		o Applied editorial suggestions.
	-03		-03
End of changes. 19 change blocks.
	27 lines changed or deleted		34 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/