< draft-ietf-jose-json-web-key-10.txt		draft-ietf-jose-json-web-key-11.txt >
	JOSE Working Group M. Jones		JOSE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track April 25, 2013		Intended status: Standards Track May 28, 2013
	Expires: October 27, 2013		Expires: November 29, 2013
	JSON Web Key (JWK)		JSON Web Key (JWK)
	draft-ietf-jose-json-web-key-10		draft-ietf-jose-json-web-key-11
	Abstract		Abstract
	A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data		A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data
	structure that represents a cryptographic key. This specification		structure that represents a cryptographic key. This specification
	also defines a JSON Web Key Set (JWK Set) JSON data structure for		also defines a JSON Web Key Set (JWK Set) JSON data structure for
	representing a set of JWKs. Cryptographic algorithms and identifiers		representing a set of JWKs. Cryptographic algorithms and identifiers
	for use with this specification are described in the separate JSON		for use with this specification are described in the separate JSON
	Web Algorithms (JWA) specification.		Web Algorithms (JWA) specification.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 27, 2013.		This Internet-Draft will expire on November 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. JSON Web Key (JWK) Format . . . . . . . . . . . . . . . . . . 4		3. JSON Web Key (JWK) Format . . . . . . . . . . . . . . . . . . 4
	3.1. "kty" (Key Type) Parameter . . . . . . . . . . . . . . . . 4		3.1. "kty" (Key Type) Parameter . . . . . . . . . . . . . . . . 4
	3.2. "use" (Key Use) Parameter . . . . . . . . . . . . . . . . 4		3.2. "use" (Key Use) Parameter . . . . . . . . . . . . . . . . 5
	3.3. "alg" (Algorithm) Parameter . . . . . . . . . . . . . . . 5		3.3. "alg" (Algorithm) Parameter . . . . . . . . . . . . . . . 5
	3.4. "kid" (Key ID) Parameter . . . . . . . . . . . . . . . . . 5		3.4. "kid" (Key ID) Parameter . . . . . . . . . . . . . . . . . 5
	4. JSON Web Key Set (JWK Set) Format . . . . . . . . . . . . . . 5		3.5. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . . . 5
			3.6. "x5t" (X.509 Certificate Thumbprint) Header Parameter . . 6
			3.7. "x5c" (X.509 Certificate Chain) Parameter . . . . . . . . 6
			4. JSON Web Key Set (JWK Set) Format . . . . . . . . . . . . . . 6
	4.1. "keys" (JSON Web Key Set) Parameter . . . . . . . . . . . 6		4.1. "keys" (JSON Web Key Set) Parameter . . . . . . . . . . . 6
	5. String Comparison Rules . . . . . . . . . . . . . . . . . . . 6		5. String Comparison Rules . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. Encrypted JWK and Encrypted JWK Set Formats . . . . . . . . . 7
	6.1. JSON Web Key Parameters Registry . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6.1.1. Registration Template . . . . . . . . . . . . . . . . 7		7.1. JSON Web Key Parameters Registry . . . . . . . . . . . . . 8
	6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 7		7.1.1. Registration Template . . . . . . . . . . . . . . . . 8
	6.2. JSON Web Key Set Parameters Registry . . . . . . . . . . . 8		7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 8
	6.2.1. Registration Template . . . . . . . . . . . . . . . . 8		7.2. JSON Web Key Set Parameters Registry . . . . . . . . . . . 9
	6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 8		7.2.1. Registration Template . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7.3. JSON Web Signature and Encryption Type Values
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 9		Registration . . . . . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . . 10		7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 10
	Appendix A. Example JSON Web Key Sets . . . . . . . . . . . . . . 10		7.4. Media Type Registration . . . . . . . . . . . . . . . . . 10
	A.1. Example Public Keys . . . . . . . . . . . . . . . . . . . 10		7.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 10
	A.2. Example Private Keys . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	A.3. Example Symmetric Keys . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16		Appendix A. Example JSON Web Key Sets . . . . . . . . . . . . . . 14
			A.1. Example Public Keys . . . . . . . . . . . . . . . . . . . 14
			A.2. Example Private Keys . . . . . . . . . . . . . . . . . . . 15
			A.3. Example Symmetric Keys . . . . . . . . . . . . . . . . . . 17
			Appendix B. Example Use of "x5c" (X.509 Certificate Chain)
			Parameter . . . . . . . . . . . . . . . . . . . . . . 17
			Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18
			Appendix D. Document History . . . . . . . . . . . . . . . . . . 19
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) [RFC4627]		A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) [RFC4627]
	data structure that represents a cryptographic key. This		data structure that represents a cryptographic key. This
	specification also defines a JSON Web Key Set (JWK Set) JSON data		specification also defines a JSON Web Key Set (JWK Set) JSON data
	structure for representing a set of JWKs. Cryptographic algorithms		structure for representing a set of JWKs. Cryptographic algorithms
	and identifiers for use with this specification are described in the		and identifiers for use with this specification are described in the
	separate JSON Web Algorithms (JWA) [JWA] specification.		separate JSON Web Algorithms (JWA) [JWA] specification.
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	be achieved through administrative delegation of portions of the		be achieved through administrative delegation of portions of the
	namespace or through use of collision-resistant name allocation		namespace or through use of collision-resistant name allocation
	functions. Examples of Collision Resistant Namespaces include:		functions. Examples of Collision Resistant Namespaces include:
	Domain Names, Object Identifiers (OIDs) as defined in the ITU-T		Domain Names, Object Identifiers (OIDs) as defined in the ITU-T
	X.660 and X.670 Recommendation series, and Universally Unique		X.660 and X.670 Recommendation series, and Universally Unique
	IDentifiers (UUIDs) [RFC4122]. When using an administratively		IDentifiers (UUIDs) [RFC4122]. When using an administratively
	delegated namespace, the definer of a name needs to take		delegated namespace, the definer of a name needs to take
	reasonable precautions to ensure they are in control of the		reasonable precautions to ensure they are in control of the
	portion of the namespace they use to define the name.		portion of the namespace they use to define the name.
			Encrypted JWK A JWE with a JWK as its plaintext value.
			Encrypted JWK Set A JWE with a JWK Set as its plaintext value.
	3. JSON Web Key (JWK) Format		3. JSON Web Key (JWK) Format
	A JSON Web Key (JWK) is a JSON object containing specific members, as		A JSON Web Key (JWK) is a JSON object containing specific members, as
	specified below. Those members that are common to all key types are		specified below. Those members that are common to all key types are
	defined below.		defined below.
	In addition to the common parameters, each JWK will have members that		In addition to the common parameters, each JWK will have members that
	are specific to the kind of key being represented. These members		are specific to the kind of key being represented. These members
	represent the parameters of the key. Section 5 of the JSON Web		represent the parameters of the key. Section 5 of the JSON Web
	Algorithms (JWA) [JWA] specification defines multiple kinds of		Algorithms (JWA) [JWA] specification defines multiple kinds of
	cryptographic keys and their associated members.		cryptographic keys and their associated members.
	The member names within a JWK MUST be unique; objects with duplicate		The member names within a JWK MUST be unique; objects with duplicate
	member names MUST be rejected.		member names MUST be rejected.
	Additional members MAY be present in the JWK. If not understood by		Additional members MAY be present in the JWK. If not understood by
	implementations encountering them, they MUST be ignored. Member		implementations encountering them, they MUST be ignored. Member
	names used for representing key parameters for different kinds of		names used for representing key parameters for different kinds of
	keys need not be distinct. Any new member name SHOULD either be		keys need not be distinct. Any new member name SHOULD either be
	registered in the IANA JSON Web Key Parameters registry Section 6.1		registered in the IANA JSON Web Key Parameters registry Section 7.1
	or be a value that contains a Collision Resistant Namespace.		or be a value that contains a Collision Resistant Namespace.
	3.1. "kty" (Key Type) Parameter		3.1. "kty" (Key Type) Parameter
	The "kty" (key type) member identifies the cryptographic algorithm		The "kty" (key type) member identifies the cryptographic algorithm
	family used with the key. "kty" values SHOULD either be registered in		family used with the key. "kty" values SHOULD either be registered in
	the IANA JSON Web Key Types registry [JWA] or be a value that		the IANA JSON Web Key Types registry [JWA] or be a value that
	contains a Collision Resistant Namespace. The "kty" value is a case		contains a Collision Resistant Namespace. The "kty" value is a case
	sensitive string. Use of this member is REQUIRED.		sensitive string. Use of this member is REQUIRED.
	A list of defined "kty" values can be found in the IANA JSON Web Key		A list of defined "kty" values can be found in the IANA JSON Web Key
	Types registry [JWA]; the initial contents of this registry are the		Types registry [JWA]; the initial contents of this registry are the
	values defined in Section 5.1 of the JSON Web Algorithms (JWA) [JWA]		values defined in Section 5.1 of the JSON Web Algorithms (JWA) [JWA]
	specification.		specification.
	Additional members used with these "kty" values can be found in the		Additional members used with these "kty" values can be found in the
	IANA JSON Web Key Parameters registry Section 6.1; the initial		IANA JSON Web Key Parameters registry Section 7.1; the initial
	contents of this registry are the values defined in Sections 5.2 and		contents of this registry are the values defined in Sections 5.2 and
	5.3 of the JSON Web Algorithms (JWA) [JWA] specification.		5.3 of the JSON Web Algorithms (JWA) [JWA] specification.
	3.2. "use" (Key Use) Parameter		3.2. "use" (Key Use) Parameter
	The "use" (key use) member identifies the intended use of the key.		The "use" (key use) member identifies the intended use of the key.
	Values defined by this specification are:		Values defined by this specification are:
	o "sig" (signature or MAC operation)		o "sig" (signature or MAC operation)
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 31 ¶
	those used in the JWS [JWS] and JWE [JWE] "alg" and "enc" header		those used in the JWS [JWS] and JWE [JWE] "alg" and "enc" header
	parameters; these values can be found in the JSON Web Signature and		parameters; these values can be found in the JSON Web Signature and
	Encryption Algorithms registry [JWA]. Use of this member is		Encryption Algorithms registry [JWA]. Use of this member is
	OPTIONAL.		OPTIONAL.
	3.4. "kid" (Key ID) Parameter		3.4. "kid" (Key ID) Parameter
	The "kid" (key ID) member can be used to match a specific key. This		The "kid" (key ID) member can be used to match a specific key. This
	can be used, for instance, to choose among a set of keys within a JWK		can be used, for instance, to choose among a set of keys within a JWK
	Set during key rollover. The interpretation of the "kid" value is		Set during key rollover. The interpretation of the "kid" value is
	unspecified. Key ID values within a JWK Set need not be unique. The		unspecified. When "kid" values are used within a JWK Set, different
	"kid" value is a case sensitive string. Use of this member is		keys within the JWK Set SHOULD use distinct "kid" values. The "kid"
	OPTIONAL.		value is a case sensitive string. Use of this member is OPTIONAL.
	When used with JWS or JWE, the "kid" value can be used to match a JWS		When used with JWS or JWE, the "kid" value can be used to match a JWS
	or JWE "kid" header parameter value.		or JWE "kid" header parameter value.
	In some contexts, different keys using the same Key ID value might be		3.5. "x5u" (X.509 URL) Header Parameter
	present, with the keys being disambiguated using other information,
	such as the "kty" or "use" values. For example, imagine "kid" values		The "x5u" (X.509 URL) member is a URI [RFC3986] that refers to a
	like "Current", "Upcoming", and "Deprecated", used for key rollover		resource for an X.509 public key certificate or certificate chain
	guidance. One could apply a label to all keys where the		[RFC5280]. The identified resource MUST provide a representation of
	classification fits. If there are multiple "Current" keys, then in		the certificate or certificate chain that conforms to RFC 5280
	this example, they might be differentiated either by having different		[RFC5280] in PEM encoded form [RFC1421]. The key in the first
	"kty" or "use" values, or some combination of both. As one example,		certificate MUST match the bare public key represented by other
	there might only be one current RSA signing key and one current		members of the JWK. The protocol used to acquire the resource MUST
	Elliptic Curve signing key, but both would be "Current".		provide integrity protection; an HTTP GET request to retrieve the
			certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the
			server MUST be validated, as per Section 3.1 of HTTP Over TLS
			[RFC2818]. Use of this member is OPTIONAL.
			3.6. "x5t" (X.509 Certificate Thumbprint) Header Parameter
			The "x5t" (X.509 Certificate Thumbprint) member is a base64url
			encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an
			X.509 certificate [RFC5280]. The key in the certificate MUST match
			the bare public key represented by other members of the JWK. Use of
			this member is OPTIONAL.
			3.7. "x5c" (X.509 Certificate Chain) Parameter
			x5c The "x5c" (X.509 Certificate Chain) member contains a chain of
			one or more PKIX certificates [RFC5280]. The certificate chain is
			represented as a JSON array of certificate value strings. Each
			string in the array is a base64 encoded ([RFC4648] Section 4 --
			not base64url encoded) DER [ITU.X690.1994] PKIX certificate value.
			The PKIX certificate containing the key value MUST be the first
			certificate. This MAY be followed by additional certificates,
			with each subsequent certificate being the one used to certify the
			previous one. The key in the first certificate MUST match the
			bare public key represented by other members of the JWK. Use of
			this member is OPTIONAL.
	4. JSON Web Key Set (JWK Set) Format		4. JSON Web Key Set (JWK Set) Format
	A JSON Web Key Set (JWK Set) is a JSON object that contains an array		A JSON Web Key Set (JWK Set) is a JSON object that contains an array
	of JSON Web Key values as the value of its "keys" member.		of JSON Web Key values as the value of its "keys" member.
	The member names within a JWK Set MUST be unique; objects with		The member names within a JWK Set MUST be unique; objects with
	duplicate member names MUST be rejected.		duplicate member names MUST be rejected.
	Additional members MAY be present in the JWK Set. If not understood		Additional members MAY be present in the JWK Set. If not understood
	by implementations encountering them, they MUST be ignored.		by implementations encountering them, they MUST be ignored.
	Parameters for representing additional properties of JWK Sets SHOULD		Parameters for representing additional properties of JWK Sets SHOULD
	either be registered in the IANA JSON Web Key Set Parameters registry		either be registered in the IANA JSON Web Key Set Parameters registry
	Section 6.2 or be a value that contains a Collision Resistant		Section 7.2 or be a value that contains a Collision Resistant
	Namespace.		Namespace.
	4.1. "keys" (JSON Web Key Set) Parameter		4.1. "keys" (JSON Web Key Set) Parameter
	The value of the "keys" (JSON Web Key Set) member is an array of JSON		The value of the "keys" (JSON Web Key Set) member is an array of JSON
	Web Key (JWK) values. Use of this member is REQUIRED.		Web Key (JWK) values. Use of this member is REQUIRED.
	5. String Comparison Rules		5. String Comparison Rules
	Processing a JWK inevitably requires comparing known strings to		Processing a JWK inevitably requires comparing known strings to
	values in JSON objects. For example, in checking what the key type		values in JSON objects. For example, in checking what the key type
	is, the Unicode string encoding "kty" will be checked against the		is, the Unicode string encoding "kty" will be checked against the
	member names in the JWK to see if there is a matching name.		member names in the JWK to see if there is a matching name.
	Comparisons between JSON strings and other Unicode strings MUST be		Comparisons between JSON strings and other Unicode strings MUST be
	performed by comparing Unicode code points without normalization as		performed by comparing Unicode code points without normalization as
	specified in the String Comparison Rules in Section 5.3 of [JWS].		specified in the String Comparison Rules in Section 5.3 of [JWS].
	6. IANA Considerations		6. Encrypted JWK and Encrypted JWK Set Formats
			JWKs containing non-public key material will need to be encrypted in
			some contexts to prevent the disclosure of private or symmetric key
			values to unintended parties. The use of an Encrypted JWK, which is
			a JWE with a JWK as its plaintext value, is RECOMMENED for this
			purpose. The processing of Encrypted JWKs is identical to the
			processing of other JWEs. A "cty" (content type) header parameter
			value of "JWK" can be used to indicate that the content of the JWE is
			a JWK in contexts where this is useful.
			JWK Sets containing non-public key material will similarly need to be
			encrypted. The use of an Encrypted JWK Set, which is a JWE with a
			JWK Set as its plaintext value, is RECOMMENED for this purpose. The
			processing of Encrypted JWK Sets is identical to the processing of
			other JWEs. A "cty" (content type) header parameter value of
			"JWK-SET" can be used to indicate that the content of the JWE is a
			JWK Set in contexts where this is useful.
			7. IANA Considerations
	The following registration procedure is used for all the registries		The following registration procedure is used for all the registries
	established by this specification.		established by this specification.
	Values are registered with a Specification Required [RFC5226] after a		Values are registered with a Specification Required [RFC5226] after a
	two-week review period on the [TBD]@ietf.org mailing list, on the		two-week review period on the [TBD]@ietf.org mailing list, on the
	advice of one or more Designated Experts. However, to allow for the		advice of one or more Designated Experts. However, to allow for the
	allocation of values prior to publication, the Designated Expert(s)		allocation of values prior to publication, the Designated Expert(s)
	may approve registration once they are satisfied that such a		may approve registration once they are satisfied that such a
	specification will be published.		specification will be published.
	skipping to change at page 7, line 9 ¶		skipping to change at page 8, line 12 ¶
	Within the review period, the Designated Expert(s) will either		Within the review period, the Designated Expert(s) will either
	approve or deny the registration request, communicating this decision		approve or deny the registration request, communicating this decision
	to the review list and IANA. Denials should include an explanation		to the review list and IANA. Denials should include an explanation
	and, if applicable, suggestions as to how to make the request		and, if applicable, suggestions as to how to make the request
	successful.		successful.
	IANA must only accept registry updates from the Designated Expert(s)		IANA must only accept registry updates from the Designated Expert(s)
	and should direct all requests for registration to the review mailing		and should direct all requests for registration to the review mailing
	list.		list.
	6.1. JSON Web Key Parameters Registry		7.1. JSON Web Key Parameters Registry
	This specification establishes the IANA JSON Web Key Parameters		This specification establishes the IANA JSON Web Key Parameters
	registry for reserved JWK parameter names. The registry records the		registry for reserved JWK parameter names. The registry records the
	reserved parameter name and a reference to the specification that		reserved parameter name and a reference to the specification that
	defines it. This specification registers the parameter names defined		defines it. It also records whether the parameter conveys public or
	in Section 3. The same JWK parameter name may be registered multiple		private information. This specification registers the parameter
	times, provided that duplicate parameter registrations are only for		names defined in Section 3. The same JWK parameter name may be
	algorithm-specific JWK parameters; in this case, the meaning of the		registered multiple times, provided that duplicate parameter
	duplicate parameter name is disambiguated by the "kty" value of the		registrations are only for algorithm-specific JWK parameters; in this
	JWK containing it.		case, the meaning of the duplicate parameter name is disambiguated by
			the "kty" value of the JWK containing it.
	6.1.1. Registration Template		7.1.1. Registration Template
	Parameter Name:		Parameter Name:
	The name requested (e.g., "example"). This name is case		The name requested (e.g., "example"). This name is case
	sensitive. Names that match other registered names in a case		sensitive. Names that match other registered names in a case
	insensitive manner SHOULD NOT be accepted.		insensitive manner SHOULD NOT be accepted.
			Parameter Information Class:
			Registers whether the parameter conveys public or private
			information. Its value must be one the words Public or Private.
	Change Controller:		Change Controller:
	For Standards Track RFCs, state "IETF". For others, give the name		For Standards Track RFCs, state "IETF". For others, give the name
	of the responsible party. Other details (e.g., postal address,		of the responsible party. Other details (e.g., postal address,
	email address, home page URI) may also be included.		email address, home page URI) may also be included.
	Specification Document(s):		Specification Document(s):
	Reference to the document(s) that specify the parameter,		Reference to the document(s) that specify the parameter,
	preferably including URI(s) that can be used to retrieve copies of		preferably including URI(s) that can be used to retrieve copies of
	the document(s). An indication of the relevant sections may also		the document(s). An indication of the relevant sections may also
	be included but is not required.		be included but is not required.
	6.1.2. Initial Registry Contents		7.1.2. Initial Registry Contents
	o Parameter Name: "kty"		o Parameter Name: "kty"
			o Parameter Information Class: Public
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 3.1 of [[ this document ]]		o Specification Document(s): Section 3.1 of [[ this document ]]
	o Parameter Name: "use"		o Parameter Name: "use"
			o Parameter Information Class: Public
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 3.2 of [[ this document ]]		o Specification Document(s): Section 3.2 of [[ this document ]]
	o Parameter Name: "alg"		o Parameter Name: "alg"
			o Parameter Information Class: Public
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 3.3 of [[ this document ]]		o Specification Document(s): Section 3.3 of [[ this document ]]
	o Parameter Name: "kid"		o Parameter Name: "kid"
			o Parameter Information Class: Public
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 3.4 of [[ this document ]]		o Specification Document(s): Section 3.4 of [[ this document ]]
	6.2. JSON Web Key Set Parameters Registry		o Parameter Name: "x5u"
			o Parameter Information Class: Public
			o Change Controller: IETF
			o Specification Document(s): Section 3.5 of [[ this document ]]
			o Parameter Name: "x5t"
			o Parameter Information Class: Public
			o Change Controller: IETF
			o Specification Document(s): Section 3.6 of [[ this document ]]
			o Parameter Name: "x5c"
			o Parameter Information Class: Public
			o Change Controller: IETF
			o Specification Document(s): Section 3.7 of [[ this document ]]
			7.2. JSON Web Key Set Parameters Registry
	This specification establishes the IANA JSON Web Key Set Parameters		This specification establishes the IANA JSON Web Key Set Parameters
	registry for reserved JWK Set parameter names. The registry records		registry for reserved JWK Set parameter names. The registry records
	the reserved parameter name and a reference to the specification that		the reserved parameter name and a reference to the specification that
	defines it. This specification registers the parameter names defined		defines it. This specification registers the parameter names defined
	in Section 4.		in Section 4.
	6.2.1. Registration Template		7.2.1. Registration Template
	Parameter Name:		Parameter Name:
	The name requested (e.g., "example"). This name is case		The name requested (e.g., "example"). This name is case
	sensitive. Names that match other registered names in a case		sensitive. Names that match other registered names in a case
	insensitive manner SHOULD NOT be accepted.		insensitive manner SHOULD NOT be accepted.
	Change Controller:		Change Controller:
	For Standards Track RFCs, state "IETF". For others, give the name		For Standards Track RFCs, state "IETF". For others, give the name
	of the responsible party. Other details (e.g., postal address,		of the responsible party. Other details (e.g., postal address,
	email address, home page URI) may also be included.		email address, home page URI) may also be included.
	Specification Document(s):		Specification Document(s):
	Reference to the document(s) that specify the parameter,		Reference to the document(s) that specify the parameter,
	preferably including URI(s) that can be used to retrieve copies of		preferably including URI(s) that can be used to retrieve copies of
	the document(s). An indication of the relevant sections may also		the document(s). An indication of the relevant sections may also
	be included but is not required.		be included but is not required.
	6.2.2. Initial Registry Contents		7.2.2. Initial Registry Contents
	o Parameter Name: "keys"		o Parameter Name: "keys"
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 4.1 of [[ this document ]]		o Specification Document(s): Section 4.1 of [[ this document ]]
	7. Security Considerations		7.3. JSON Web Signature and Encryption Type Values Registration
			7.3.1. Registry Contents
			This specification registers the "JWK" and "JWK-SET" type values in
			the IANA JSON Web Signature and Encryption Type Values registry
			[JWS]:
			o "typ" Header Parameter Value: "JWK"
			o Abbreviation for MIME Type: application/jwk+json
			o Change Controller: IETF
			o Specification Document(s): Section 3 of [[ this document ]]
			o "typ" Header Parameter Value: "JWK-SET"
			o Abbreviation for MIME Type: application/jwk-set+json
			o Change Controller: IETF
			o Specification Document(s): Section 4 of [[ this document ]]
			7.4. Media Type Registration
			7.4.1. Registry Contents
			This specification registers the "application/jwk+json" and
			"application/jwk-set+json" Media Types [RFC2046] in the MIME Media
			Type registry [RFC4288] to indicate, respectively, that the content
			is a JWK or a JWK Set.
			o Type Name: application
			o Subtype Name: jwk+json
			o Required Parameters: n/a
			o Optional Parameters: n/a
			o Encoding considerations: application/jwk+json values are
			represented as JSON object; UTF-8 encoding SHOULD be employed for
			the JSON object.
			o Security Considerations: See the Security Considerations section
			of [[ this document ]]
			o Interoperability Considerations: n/a
			o Published Specification: [[ this document ]]
			o Applications that use this media type: TBD
			o Additional Information: Magic number(s): n/a, File extension(s):
			n/a, Macintosh file type code(s): n/a
			o Person & email address to contact for further information: Michael
			B. Jones, mbj@microsoft.com
			o Intended Usage: COMMON
			o Restrictions on Usage: none
			o Author: Michael B. Jones, mbj@microsoft.com
			o Change Controller: IETF
			o Type Name: application
			o Subtype Name: jwk-set+json
			o Required Parameters: n/a
			o Optional Parameters: n/a
			o Encoding considerations: application/jwk-set+json values are
			represented as a JSON Object; UTF-8 encoding SHOULD be employed
			for the JSON object.
			o Security Considerations: See the Security Considerations section
			of [[ this document ]]
			o Interoperability Considerations: n/a
			o Published Specification: [[ this document ]]
			o Applications that use this media type: TBD
			o Additional Information: Magic number(s): n/a, File extension(s):
			n/a, Macintosh file type code(s): n/a
			o Person & email address to contact for further information: Michael
			B. Jones, mbj@microsoft.com
			o Intended Usage: COMMON
			o Restrictions on Usage: none
			o Author: Michael B. Jones, mbj@microsoft.com
			o Change Controller: IETF
			8. Security Considerations
	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, but		security considerations is beyond the scope of this document, but
	some significant considerations are listed here.		some significant considerations are listed here.
	A key is no more trustworthy than the method by which it was		A key is no more trustworthy than the method by which it was
	skipping to change at page 9, line 21 ¶		skipping to change at page 12, line 25 ¶
	the plaintext of a JWE.		the plaintext of a JWE.
	The security considerations in RFC 3447 [RFC3447] and RFC 6030		The security considerations in RFC 3447 [RFC3447] and RFC 6030
	[RFC6030] about protecting private and symmetric keys also apply to		[RFC6030] about protecting private and symmetric keys also apply to
	this specification.		this specification.
	The security considerations in XML DSIG 2.0		The security considerations in XML DSIG 2.0
	[W3C.CR-xmldsig-core2-20120124], about key representations also apply		[W3C.CR-xmldsig-core2-20120124], about key representations also apply
	to this specification, other than those that are XML specific.		to this specification, other than those that are XML specific.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
			[ITU.X690.1994]
			International Telecommunications Union, "Information
			Technology - ASN.1 encoding rules: Specification of Basic
			Encoding Rules (BER), Canonical Encoding Rules (CER) and
			Distinguished Encoding Rules (DER)", ITU-T Recommendation
			X.690, 1994.
	[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),
	April 2013.		May 2013.
	[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web		[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
	Encryption (JWE)", draft-ietf-jose-json-web-encryption		Encryption (JWE)", draft-ietf-jose-json-web-encryption
	(work in progress), April 2013.		(work in progress), May 2013.
	[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), April 2013.		in progress), May 2013.
			[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
			Mail: Part I: Message Encryption and Authentication
			Procedures", RFC 1421, February 1993.
			[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
			Extensions (MIME) Part Two: Media Types", RFC 2046,
			November 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.
			[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", STD 66,
			RFC 3986, January 2005.
			[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
			Registration Procedures", RFC 4288, December 2005.
	[RFC4627] Crockford, D., "The application/json Media Type for		[RFC4627] Crockford, D., "The application/json Media Type for
	JavaScript Object Notation (JSON)", RFC 4627, July 2006.		JavaScript Object Notation (JSON)", RFC 4627, July 2006.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008.
			[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, May 2008.
	[W3C.CR-xmldsig-core2-20120124]		[W3C.CR-xmldsig-core2-20120124]
	Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P.,		Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P.,
	Hirsch, F., Cantor, S., and T. Roessler, "XML Signature		Hirsch, F., Cantor, S., and T. Roessler, "XML Signature
	Syntax and Processing Version 2.0", World Wide Web		Syntax and Processing Version 2.0", World Wide Web
	Consortium CR CR-xmldsig-core2-20120124, January 2012,		Consortium CR CR-xmldsig-core2-20120124, January 2012,
	<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.		<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
	8.2. Informative References		9.2. Informative References
	[MagicSignatures]		[MagicSignatures]
	Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic		Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
	Signatures", January 2011.		Signatures", January 2011.
	[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.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	skipping to change at page 13, line 25 ¶		skipping to change at page 17, line 25 ¶
	"alg":"A128KW",		"alg":"A128KW",
	"k":"GawgguFyGrWKav7AX4VKUg"},		"k":"GawgguFyGrWKav7AX4VKUg"},
	{"kty":"oct",		{"kty":"oct",
	"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75		"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
	aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow",		aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow",
	"kid":"HMAC key used in JWS A.1 example"}		"kid":"HMAC key used in JWS A.1 example"}
	]		]
	}		}
	Appendix B. Acknowledgements		Appendix B. Example Use of "x5c" (X.509 Certificate Chain) Parameter
			The following is a non-normative example of a JWK with a RSA signing
			key represented both as a bare public key and as an X.509 certificate
			using the "x5c" parameter:
			{"kty":"RSA",
			"use":"sig",
			"kid":"1b94c",
			"n":"vrjOfz9Ccdgx5nQudyhdoR17V-IubWMeOZCwX_jj0hgAsz2J_pqYW08
			PLbK_PdiVGKPrqzmDIsLI7sA25VEnHU1uCLNwBuUiCO11_-7dYbsr4iJmG0Q
			u2j8DsVyT1azpJC_NG84Ty5KKthuCaPod7iI7w0LK9orSMhBEwwZDCxTWq4a
			YWAchc8t-emd9qOvWtVMDC2BXksRngh6X5bUYLy6AyHKvj-nUy1wgzjYQDwH
			MTplCoLtU-o-8SNnZ1tmRoGE9uJkBLdh5gFENabWnU5m1ZqZPdwS-qo-meMv
			VfJb6jJVWRpl2SUtCnYG2C32qvbWbjZ_jBPD5eunqsIo1vQ",
			"e":"AQAB",
			"x5c":
			["MIIDQjCCAiqgAwIBAgIGATz/FuLiMA0GCSqGSIb3DQEBBQUAMGIxCzAJB
			gNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYD
			VQQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1
			wYmVsbDAeFw0xMzAyMjEyMzI5MTVaFw0xODA4MTQyMjI5MTVaMGIxCzAJBg
			NVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDV
			QQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1w
			YmVsbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL64zn8/QnH
			YMeZ0LncoXaEde1fiLm1jHjmQsF/449IYALM9if6amFtPDy2yvz3YlRij66
			s5gyLCyO7ANuVRJx1NbgizcAblIgjtdf/u3WG7K+IiZhtELto/A7Fck9Ws6
			SQvzRvOE8uSirYbgmj6He4iO8NCyvaK0jIQRMMGQwsU1quGmFgHIXPLfnpn
			fajr1rVTAwtgV5LEZ4Iel+W1GC8ugMhyr4/p1MtcIM42EA8BzE6ZQqC7VPq
			PvEjZ2dbZkaBhPbiZAS3YeYBRDWm1p1OZtWamT3cEvqqPpnjL1XyW+oyVVk
			aZdklLQp2Btgt9qr21m42f4wTw+Xrp6rCKNb0CAwEAATANBgkqhkiG9w0BA
			QUFAAOCAQEAh8zGlfSlcI0o3rYDPBB07aXNswb4ECNIKG0CETTUxmXl9KUL
			+9gGlqCz5iWLOgWsnrcKcY0vXPG9J1r9AqBNTqNgHq2G03X09266X5CpOe1
			zFo+Owb1zxtp3PehFdfQJ610CDLEaS9V9Rqp17hCyybEpOGVwe8fnk+fbEL
			2Bo3UPGrpsHzUoaGpDftmWssZkhpBJKVMJyf/RuP2SmmaIzmnw9JiSlYhzo
			4tpzd5rFXhjRbg4zW9C+2qok+2+qDM1iJ684gPHMIY8aLWrdgQTxkumGmTq
			gawR+N5MDtdPTEQ0XfIBc2cJEUyMTY5MPvACWpkA6SdS4xSvdXK3IVfOWA=="]
			}
			Appendix C. Acknowledgements
	A JSON representation for RSA public keys was previously introduced		A JSON representation for RSA public keys was previously introduced
	by John Panzer, Ben Laurie, and Dirk Balfanz in Magic Signatures		by John Panzer, Ben Laurie, and Dirk Balfanz in Magic Signatures
	[MagicSignatures].		[MagicSignatures].
	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:
	Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de		Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de
	Medeiros, Joe Hildebrand, Edmund Jay, Ben Laurie, James Manger, Tony		Medeiros, Joe Hildebrand, Edmund Jay, Ben Laurie, James Manger, Matt
	Nadalin, Axel Nennker, John Panzer, Eric Rescorla, Nat Sakimura, Jim		Miller, Tony Nadalin, Axel Nennker, John Panzer, Eric Rescorla, Nat
	Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner.		Sakimura, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean
			Turner.
	Jim Schaad and Karen O'Donoghue chaired the JOSE working group and		Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
	Sean Turner and Stephen Farrell served as Security area directors		Sean Turner and Stephen Farrell served as Security area directors
	during the creation of this specification.		during the creation of this specification.
	Appendix C. 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 ]]
			-11
			o Stated that when "kid" values are used within a JWK Set, different
			keys within the JWK Set SHOULD use distinct "kid" values.
			o Added optional "x5u" (X.509 URL), "x5t" (X.509 Certificate
			Thumbprint), and "x5c" (X.509 Certificate Chain) JWK parameters.
			o Added section on Encrypted JWK and Encrypted JWK Set Formats.
			o Added a Parameter Information Class value to the JSON Web Key
			Parameters registry, which registers whether the parameter conveys
			public or private information.
			o Registered "application/jwk+json" and "application/jwk-set+json"
			MIME types and "JWK" and "JWK-SET" typ header parameter values,
			addressing issue #21.
	-10		-10
	o No changes were made, other than to the version number and date.		o No changes were made, other than to the version number and date.
	-09		-09
	o Expanded the scope of the JWK specification to include private and		o Expanded the scope of the JWK specification to include private and
	symmetric key representations, as specified by		symmetric key representations, as specified by
	draft-jones-jose-json-private-and-symmetric-key-00.		draft-jones-jose-json-private-and-symmetric-key-00.
	o Defined that members that are not understood must be ignored.		o Defined that members that are not understood must be ignored.
End of changes. 39 change blocks.
	66 lines changed or deleted		306 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/