< draft-ietf-jose-json-web-key-35.txt		draft-ietf-jose-json-web-key-36.txt >
	JOSE Working Group M. Jones		JOSE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track October 17, 2014		Intended status: Standards Track October 24, 2014
	Expires: April 20, 2015		Expires: April 27, 2015
	JSON Web Key (JWK)		JSON Web Key (JWK)
	draft-ietf-jose-json-web-key-35		draft-ietf-jose-json-web-key-36
	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 that		also defines a JSON Web Key Set (JWK Set) JSON data structure that
	represents a set of JWKs. Cryptographic algorithms and identifiers		represents 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 and IANA registries defined by		Web Algorithms (JWA) specification and IANA registries defined by
	that specification.		that specification.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 20, 2015.		This Internet-Draft will expire on April 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 42 ¶
	"kid":"Public key used in JWS A.3 example"		"kid":"Public key used in JWS A.3 example"
	}		}
	Additional example JWK values can be found in Appendix A.		Additional example JWK values can be found in Appendix A.
	4. JSON Web Key (JWK) Format		4. JSON Web Key (JWK) Format
	A JSON Web Key (JWK) is a JSON object that represents a cryptographic		A JSON Web Key (JWK) is a JSON object that represents a cryptographic
	key. The members of the object represent properties of the key,		key. The members of the object represent properties of the key,
	including its value. This JSON object MAY contain white space and/or		including its value. This JSON object MAY contain white space and/or
	line breaks. This document defines the key parameters that are not		line breaks before or after any JSON values or structural characters,
	algorithm specific, and thus common to many keys.		in accordance with Section 2 of RFC 7159 [RFC7159]. This document
			defines the key parameters that are not algorithm specific, and thus
			common to many keys.
	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 key type-specific. These members represent the parameters of the		are key type-specific. These members represent the parameters of the
	key. Section 6 of the JSON Web Algorithms (JWA) [JWA] specification		key. Section 6 of the JSON Web Algorithms (JWA) [JWA] specification
	defines multiple kinds of cryptographic keys and their associated		defines multiple kinds of cryptographic keys and their associated
	members.		members.
	The member names within a JWK MUST be unique; JWK parsers MUST either		The member names within a JWK MUST be unique; JWK parsers MUST either
	reject JWKs with duplicate member names or use a JSON parser that		reject JWKs with duplicate member names or use a JSON parser that
	returns only the lexically last duplicate member name, as specified		returns only the lexically last duplicate member name, as specified
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	because of the potential vulnerabilities associated with using the		because of the potential vulnerabilities associated with using the
	same key with multiple algorithms. Thus, the combinations "sign"		same key with multiple algorithms. Thus, the combinations "sign"
	with "verify", "encrypt" with "decrypt", and "wrapKey" with		with "verify", "encrypt" with "decrypt", and "wrapKey" with
	"unwrapKey" are permitted, but other combinations SHOULD NOT be used.		"unwrapKey" are permitted, but other combinations SHOULD NOT be used.
	Additional Key Operations values can be registered in the IANA JSON		Additional Key Operations values can be registered in the IANA JSON
	Web Key Operations registry defined in Section 8.3. The same		Web Key Operations registry defined in Section 8.3. The same
	considerations about registering extension values apply to the		considerations about registering extension values apply to the
	"key_ops" member as do for the "use" member.		"key_ops" member as do for the "use" member.
	The "use" and "key_ops" JWK members SHOULD NOT be used together.		The "use" and "key_ops" JWK members SHOULD NOT be used together;
	Applications should specify which of these members they use, if		however, if both are used, the information they convey MUST be
	either is to be used by the application.		consistent. Applications should specify which of these members they
			use, if either is to be used by the application.
	4.4. "alg" (Algorithm) Parameter		4.4. "alg" (Algorithm) Parameter
	The "alg" (algorithm) member identifies the algorithm intended for		The "alg" (algorithm) member identifies the algorithm intended for
	use with the key. The values used should either be registered in the		use with the key. The values used should either be registered in the
	IANA JSON Web Signature and Encryption Algorithms registry defined in		IANA JSON Web Signature and Encryption Algorithms registry defined in
	[JWA] or be a value that contains a Collision-Resistant Name. Use of		[JWA] or be a value that contains a Collision-Resistant Name. Use of
	this member is OPTIONAL.		this member is OPTIONAL.
	4.5. "kid" (Key ID) Parameter		4.5. "kid" (Key ID) Parameter
	skipping to change at page 11, line 45 ¶		skipping to change at page 11, line 45 ¶
	omitted.		omitted.
	See Appendix C for an example encrypted JWK.		See Appendix C for an example encrypted JWK.
	8. IANA Considerations		8. 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 on a Specification Required [RFC5226] basis		Values are registered on a Specification Required [RFC5226] basis
	after a three-week review period on the [TBD]@ietf.org mailing list,		after a three-week review period on the jose-reg-review@ietf.org
	on the advice of one or more Designated Experts. However, to allow		mailing list, on the advice of one or more Designated Experts.
	for the allocation of values prior to publication, the Designated		However, to allow for the allocation of values prior to publication,
	Expert(s) may approve registration once they are satisfied that such		the Designated Expert(s) may approve registration once they are
	a specification will be published.		satisfied that such a specification will be published.
	Registration requests must be sent to the [TBD]@ietf.org mailing list		Registration requests must be sent to the jose-reg-review@ietf.org
	for review and comment, with an appropriate subject (e.g., "Request		mailing list for review and comment, with an appropriate subject
	for access token type: example"). [[ Note to the RFC Editor: The name		(e.g., "Request for access token type: example").
	of the mailing list should be determined in consultation with the
	IESG and IANA. Suggested name: jose-reg-review. ]]
	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. Registration requests that are undetermined for a period		successful. Registration requests that are undetermined for a period
	longer than 21 days can be brought to the IESG's attention (using the		longer than 21 days can be brought to the IESG's attention (using the
	iesg@ietf.org mailing list) for resolution.		iesg@ietf.org mailing list) for resolution.
	Criteria that should be applied by the Designated Expert(s) includes		Criteria that should be applied by the Designated Expert(s) includes
	skipping to change at page 38, line 30 ¶		skipping to change at page 38, line 30 ¶
	Hannes Tschofenig, and Sean Turner.		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 E. Document History		Appendix E. 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 ]]
			-36
			o Stated that if both "use" and "key_ops" are used, the information
			they convey MUST be consistent.
			o Clarified where white space and line breaks may occur in JSON
			objects by referencing Section 2 of RFC 7159.
			o Specified that registration reviews occur on the
			jose-reg-review@ietf.org mailing list.
	-35		-35
	o Used real values for examples in the IANA Registration Templates.		o Used real values for examples in the IANA Registration Templates.
	-34		-34
	o Addressed IESG review comments by Pete Resnick, Stephen Farrell,		o Addressed IESG review comments by Pete Resnick, Stephen Farrell,
	and Richard Barnes.		and Richard Barnes.
	o Referenced RFC 4945 for PEM certificate delimiter syntax.		o Referenced RFC 4945 for PEM certificate delimiter syntax.
End of changes. 8 change blocks.
	19 lines changed or deleted		31 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/