< draft-jones-json-web-signature-01.txt		draft-jones-json-web-signature-02.txt >
	Network Working Group M. Jones		Network Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track D. Balfanz		Intended status: Standards Track D. Balfanz
	Expires: September 26, 2011 Google		Expires: October 31, 2011 Google
	J. Bradley		J. Bradley
	independent		independent
	Y. Goland		Y. Goland
	Microsoft		Microsoft
	J. Panzer		J. Panzer
	Google		Google
	N. Sakimura		N. Sakimura
	Nomura Research Institute		Nomura Research Institute
	P. Tarjan		P. Tarjan
	Facebook		Facebook
	March 25, 2011		April 29, 2011
	JSON Web Signature (JWS)		JSON Web Signature (JWS)
	draft-jones-json-web-signature-01		draft-jones-json-web-signature-02
	Abstract		Abstract
	JSON Web Signature (JWS) is a means of representing signed content		JSON Web Signature (JWS) is a means of representing signed content
	using JSON data structures. Related encryption capabilities are		using JSON data structures. Related encryption capabilities are
	described in the separate JSON Web Encryption (JWE) specification.		described in the separate JSON Web Encryption (JWE) specification.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 September 26, 2011.		This Internet-Draft will expire on October 31, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 12		HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Creating a JWS with RSA SHA-256, RSA SHA-384, or RSA		7.2. Creating a JWS with RSA SHA-256, RSA SHA-384, or RSA
	SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . . 13		SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.3. Creating a JWS with ECDSA P-256 SHA-256, ECDSA P-384		7.3. Creating a JWS with ECDSA P-256 SHA-256, ECDSA P-384
	SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . . . . 14		SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . . . . 14
	7.4. Additional Algorithms . . . . . . . . . . . . . . . . . . 16		7.4. Additional Algorithms . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9.1. Unicode Comparison Security Issues . . . . . . . . . . . . 17		9.1. Unicode Comparison Security Issues . . . . . . . . . . . . 17
	10. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 17		10. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 17
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 19		11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . . 20		11.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 20		Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 20
	A.1. JWS using HMAC SHA-256 . . . . . . . . . . . . . . . . . . 21		A.1. JWS using HMAC SHA-256 . . . . . . . . . . . . . . . . . . 20
	A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 21		A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 21
	A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 22		A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 22
	A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 22		A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 22
	A.2. JWS using RSA SHA-256 . . . . . . . . . . . . . . . . . . 23		A.2. JWS using RSA SHA-256 . . . . . . . . . . . . . . . . . . 23
	A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 23		A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 23
	A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 26		A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 26
	A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 26		A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 26
	A.3. JWS using ECDSA P-256 SHA-256 . . . . . . . . . . . . . . 27		A.3. JWS using ECDSA P-256 SHA-256 . . . . . . . . . . . . . . 27
	A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 27		A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 27
	A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 28		A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 28
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	Appendix C. Notes on implementing base64url encoding without		Appendix C. Notes on implementing base64url encoding without
	padding . . . . . . . . . . . . . . . . . . . . . . . 31		padding . . . . . . . . . . . . . . . . . . . . . . . 31
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32
	Appendix E. Document History . . . . . . . . . . . . . . . . . . 33		Appendix E. Document History . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	JSON Web Signature (JWS) is a compact signature format intended for		JSON Web Signature (JWS) is a compact signature format intended for
	space constrained environments such as HTTP Authorization headers and		space constrained environments such as HTTP Authorization headers and
	URI query parameters. The JWS signature mechanisms are independent		URI query parameters. It represents signed content using JSON
	of the type of content being signed, allowing arbitrary content to be		[RFC4627] data structures. The JWS signature mechanisms are
	signed. A related encryption capability is described in a separate		independent of the type of content being signed, allowing arbitrary
	JSON Web Encryption (JWE) [JWE] specification.		content to be signed. A related encryption capability is described
			in a separate JSON Web Encryption (JWE) [JWE] specification.
	2. Terminology		2. Terminology
	JSON Web Signature (JWS) A data structure cryptographically securing		JSON Web Signature (JWS) A data structure cryptographically securing
	a JWS Header Input and a JWS Payload Input with a JWS Crypto		a JWS Header Input and a JWS Payload Input with a JWS Crypto
	Output.		Output.
	JWS Header Input A string containing a base64url encoded JSON object		JWS Header Input A string containing a base64url encoded JSON object
	that describes the cryptographic operations applied to the JWS		that describes the cryptographic operations applied to the JWS
	Header Input and the JWS Payload Input.		Header Input and the JWS Payload Input.
	skipping to change at page 7, line 38 ¶		skipping to change at page 7, line 38 ¶
	| | | | REQUIRED. |		| | | | REQUIRED. |
	| typ | string | String | The "typ" (type) header |		| typ | string | String | The "typ" (type) header |
	| | | | parameter is used to declare |		| | | | parameter is used to declare |
	| | | | the type of the signed |		| | | | the type of the signed |
	| | | | content. The "typ" value is |		| | | | content. The "typ" value is |
	| | | | case sensitive. This header |		| | | | case sensitive. This header |
	| | | | parameter is OPTIONAL. |		| | | | parameter is OPTIONAL. |
	| jku | string | URL | The "jku" (JSON Key URL) |		| jku | string | URL | The "jku" (JSON Key URL) |
	| | | | header parameter is a URL |		| | | | header parameter is a URL |
	| | | | that points to JSON-encoded |		| | | | that points to JSON-encoded |
	| | | | public key certificates that |		| | | | public keys that can be used |
	| | | | can be used to validate the |		| | | | to validate the signature. |
	| | | | signature. The specification |		| | | | The keys MUST be encoded as |
	| | | | for this encoding is TBD. |		| | | | per the JSON Web Key (JWK) |
	| | | | This header parameter is |		| | | | [JWK] specification. This |
	| | | | OPTIONAL. |		| | | | header parameter is OPTIONAL. |
	| kid | string | String | The "kid" (key ID) header |		| kid | string | String | The "kid" (key ID) header |
	| | | | parameter is a hint |		| | | | parameter is a hint |
	| | | | indicating which specific key |		| | | | indicating which specific key |
	| | | | owned by the signer should be |		| | | | owned by the signer should be |
	| | | | used to validate the |		| | | | used to validate the |
	| | | | signature. This allows |		| | | | signature. This allows |
	| | | | signers to explicitly signal |		| | | | signers to explicitly signal |
	| | | | a change of key to |		| | | | a change of key to |
	| | | | recipients. Omitting this |		| | | | recipients. Omitting this |
	| | | | parameter is equivalent to |		| | | | parameter is equivalent to |
	skipping to change at page 18, line 9 ¶		skipping to change at page 18, line 9 ¶
	drafts):		drafts):
	o Consider whether there is a better term than "Digital Signature"		o Consider whether there is a better term than "Digital Signature"
	for the concept that includes both HMACs and digital signatures		for the concept that includes both HMACs and digital signatures
	using public keys.		using public keys.
	o Consider whether we really want to allow private header parameter		o Consider whether we really want to allow private header parameter
	names that are not registered with IANA and are not in collision-		names that are not registered with IANA and are not in collision-
	resistant namespaces. Eventually this could result in interop		resistant namespaces. Eventually this could result in interop
	nightmares where you need to have different code to talk to		nightmares where you need to have different code to talk to
	different endpoints that "knows" about each endpoints' private		different endpoints that "knows" about each endpoint's private
	parameters.		parameters.
	o Clarify the optional ability to provide type information in the		o Clarify the optional ability to provide type information in the
	JWS header. Specifically, clarify the intended use of the "typ"		JWS header. Specifically, clarify the intended use of the "typ"
	Header Parameter, whether it conveys syntax or semantics, and		Header Parameter, whether it conveys syntax or semantics, and
	indeed, whether this is the right approach. Also clarify the		indeed, whether this is the right approach. Also clarify the
	relationship between these type values and MIME [RFC2045] types.		relationship between these type values and MIME [RFC2045] types.
	o Clarify the semantics of the "kid" (key ID) header parameter.		o Clarify the semantics of the "kid" (key ID) header parameter.
	Open issues include: What happens if a "kid" header is received		Open issues include: What happens if a "kid" header is received
	skipping to change at page 18, line 42 ¶		skipping to change at page 18, line 42 ¶
	(it's what's commonly implemented) and what the potential		(it's what's commonly implemented) and what the potential
	consequences are.		consequences are.
	o Add Security Considerations text on timing attacks.		o Add Security Considerations text on timing attacks.
	o Finish the Security Considerations section.		o Finish the Security Considerations section.
	o Sort out what to do with the IANA registries if this is first		o Sort out what to do with the IANA registries if this is first
	standardized as an OpenID specification.		standardized as an OpenID specification.
	o Write the related specification for encoding public keys using
	JSON, as per the agreement documented at
	http://self-issued.info/?p=390. This will be used by the "jku"
	(JSON Key URL) header parameter.
	o Finish the companion encryption specification, per the agreements		o Finish the companion encryption specification, per the agreements
	documented at http://self-issued.info/?p=378.		documented at http://self-issued.info/?p=378.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[FIPS.180-3]		[FIPS.180-3]
	National Institute of Standards and Technology, "Secure		National Institute of Standards and Technology, "Secure
	Hash Standard (SHS)", FIPS PUB 180-3, October 2008.		Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
	[FIPS.186-3]		[FIPS.186-3]
	National Institute of Standards and Technology, "Digital		National Institute of Standards and Technology, "Digital
	Signature Standard (DSS)", FIPS PUB 186-3, June 2009.		Signature Standard (DSS)", FIPS PUB 186-3, June 2009.
			[JWK] Jones, M., "JSON Web Key (JWK)", April 2011.
	[JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer,		[JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer,
	J., Sakimura, N., and P. Tarjan, "JSON Web Token (JWT)",		J., Sakimura, N., and P. Tarjan, "JSON Web Token (JWT)",
	March 2011.		March 2011.
	[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic		[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
	Mail: Part I: Message Encryption and Authentication		Mail: Part I: Message Encryption and Authentication
	Procedures", RFC 1421, February 1993.		Procedures", RFC 1421, February 1993.
	[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform		[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
	Resource Locators (URL)", RFC 1738, December 1994.		Resource Locators (URL)", RFC 1738, December 1994.
	skipping to change at page 33, line 7 ¶		skipping to change at page 33, line 7 ¶
	A-z_4ME		A-z_4ME
	Appendix D. Acknowledgements		Appendix D. Acknowledgements
	Solutions for signing JSON content were previously explored by Magic		Solutions for signing JSON content were previously explored by Magic
	Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas		Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas
	Applications [CanvasApp], all of which influenced this draft.		Applications [CanvasApp], all of which influenced this draft.
	Appendix E. Document History		Appendix E. Document History
			-02
			o Reference the JSON Web Key (JWK) specification from the "jku"
			header parameter.
	-01		-01
	o Changed RSA SHA-256 from MUST be supported to RECOMMENDED that it		o Changed RSA SHA-256 from MUST be supported to RECOMMENDED that it
	be supported. Rationale: Several people have objected to the		be supported. Rationale: Several people have objected to the
	requirement for implementing RSA SHA-256, some because they will		requirement for implementing RSA SHA-256, some because they will
	only be using HMACs and symmetric keys, and others because they		only be using HMACs and symmetric keys, and others because they
	only want to use ECDSA when using asymmetric keys, either for		only want to use ECDSA when using asymmetric keys, either for
	security or key length reasons, or both.		security or key length reasons, or both.
	o Clarified that "x5u" is an HTTPS URL referencing a PEM-encoded		o Clarified that "x5u" is an HTTPS URL referencing a PEM-encoded
End of changes. 13 change blocks.
	23 lines changed or deleted		27 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/