< draft-ietf-jose-json-web-key-36.txt		draft-ietf-jose-json-web-key-37.txt >
	JOSE Working Group M. Jones		JOSE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track October 24, 2014		Intended status: Standards Track November 19, 2014
	Expires: April 27, 2015		Expires: May 23, 2015
	JSON Web Key (JWK)		JSON Web Key (JWK)
	draft-ietf-jose-json-web-key-36		draft-ietf-jose-json-web-key-37
	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 27, 2015.		This Internet-Draft will expire on May 23, 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 8, line 20 ¶		skipping to change at page 8, line 20 ¶
	The "use" and "key_ops" JWK members SHOULD NOT be used together;		The "use" and "key_ops" JWK members SHOULD NOT be used together;
	however, if both are used, the information they convey MUST be		however, if both are used, the information they convey MUST be
	consistent. Applications should specify which of these members they		consistent. Applications should specify which of these members they
	use, if either is to be used by the application.		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. The
	this member is OPTIONAL.		"alg" value is a case-sensitive ASCII string. Use of this member is
			OPTIONAL.
	4.5. "kid" (Key ID) Parameter		4.5. "kid" (Key ID) Parameter
	The "kid" (key ID) member is used to match a specific key. This is		The "kid" (key ID) member is used to match a specific key. This is
	used, for instance, to choose among a set of keys within a JWK Set		used, for instance, to choose among a set of keys within a JWK Set
	during key rollover. The structure of the "kid" value is		during key rollover. The structure of the "kid" value is
	unspecified. When "kid" values are used within a JWK Set, different		unspecified. When "kid" values are used within a JWK Set, different
	keys within the JWK Set SHOULD use distinct "kid" values. (One		keys within the JWK Set SHOULD use distinct "kid" values. (One
	example in which different keys might use the same "kid" value is if		example in which different keys might use the same "kid" value is if
	they have different "kty" (key type) values but are considered to be		they have different "kty" (key type) values but are considered to be
	skipping to change at page 12, line 8 ¶		skipping to change at page 12, line 8 ¶
	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 jose-reg-review@ietf.org		after a three-week review period on the jose-reg-review@ietf.org
	mailing list, on the advice of one or more Designated Experts.		mailing list, on the advice of one or more Designated Experts.
	However, to allow for the allocation of values prior to publication,		However, to allow for the allocation of values prior to publication,
	the Designated Expert(s) may approve registration once they are		the Designated Expert(s) may approve registration once they are
	satisfied that such a specification will be published.		satisfied that such a specification will be published.
	Registration requests must be sent to the jose-reg-review@ietf.org		Registration requests must be sent to the jose-reg-review@ietf.org
	mailing list for review and comment, with an appropriate subject		mailing list for review and comment, with an appropriate subject
	(e.g., "Request for access token type: example").		(e.g., "Request to register JWK parameter: example").
	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 20, line 44 ¶		skipping to change at page 20, line 44 ¶
	Any data associated with a key that is obtained in an untrusted		Any data associated with a key that is obtained in an untrusted
	manner should be treated with skepticism. See Section 10.3 of [JWS]		manner should be treated with skepticism. See Section 10.3 of [JWS]
	for security considerations on key origin authentication.		for security considerations on key origin authentication.
	The security considerations in Section 12.3 of XML DSIG 2.0		The security considerations in Section 12.3 of XML DSIG 2.0
	[W3C.NOTE-xmldsig-core2-20130411] about the strength of a digital		[W3C.NOTE-xmldsig-core2-20130411] about the strength of a digital
	signature depending upon all the links in the security chain also		signature depending upon all the links in the security chain also
	apply to this specification.		apply to this specification.
	The TLS Requirements in Section 8 of [JWS] also apply to this		The TLS Requirements in Section 8 of [JWS] also apply to this
	specification.		specification, except that the "x5u" JWK member is the only feature
			defined by this specification using TLS.
	9.2. Preventing Disclosure of Non-Public Key Information		9.2. Preventing Disclosure of Non-Public Key Information
	Private and symmetric keys MUST be protected from disclosure to		Private and symmetric keys MUST be protected from disclosure to
	unintended parties. One recommended means of doing so is to encrypt		unintended parties. One recommended means of doing so is to encrypt
	JWKs or JWK Sets containing them by using the JWK or JWK Set value as		JWKs or JWK Sets containing them by using the JWK or JWK Set value as
	the plaintext of a JWE. Of course, this requires that there be a		the plaintext of a JWE. Of course, this requires that there be a
	secure way to obtain the key used to encrypt the non-public key		secure way to obtain the key used to encrypt the non-public key
	information to the intended party and a secure way for that party to		information to the intended party and a secure way for that party to
	obtain the corresponding decryption key.		obtain the corresponding decryption key.
	skipping to change at page 22, line 7 ¶		skipping to change at page 22, line 7 ¶
	[ITU.X690.1994]		[ITU.X690.1994]
	International Telecommunications Union, "Information		International Telecommunications Union, "Information
	Technology - ASN.1 encoding rules: Specification of Basic		Technology - ASN.1 encoding rules: Specification of Basic
	Encoding Rules (BER), Canonical Encoding Rules (CER) and		Encoding Rules (BER), Canonical Encoding Rules (CER) and
	Distinguished Encoding Rules (DER)", ITU-T Recommendation		Distinguished Encoding Rules (DER)", ITU-T Recommendation
	X.690, 1994.		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),
	October 2014.		November 2014.
	[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",		[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	draft-ietf-jose-json-web-encryption (work in progress),		draft-ietf-jose-json-web-encryption (work in progress),
	October 2014.		November 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), November 2014.
	[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,		[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
	October 1969.		October 1969.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		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.
	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 ]]
			-37
			o Updated the TLS requirements language to only require
			implementations to support TLS when they support features using
			TLS.
			o Restricted algorithm names to using only ASCII characters.
			o Updated the example IANA registration request subject line.
	-36		-36
	o Stated that if both "use" and "key_ops" are used, the information		o Stated that if both "use" and "key_ops" are used, the information
	they convey MUST be consistent.		they convey MUST be consistent.
	o Clarified where white space and line breaks may occur in JSON		o Clarified where white space and line breaks may occur in JSON
	objects by referencing Section 2 of RFC 7159.		objects by referencing Section 2 of RFC 7159.
	o Specified that registration reviews occur on the		o Specified that registration reviews occur on the
	jose-reg-review@ietf.org mailing list.		jose-reg-review@ietf.org mailing list.
End of changes. 10 change blocks.
	11 lines changed or deleted		23 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/