< draft-miller-jose-jwe-protected-jwk-00.txt		draft-miller-jose-jwe-protected-jwk-01.txt >
	JOSE Working Group M. Miller		JOSE Working Group M. Miller
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track February 01, 2013		Intended status: Standards Track February 21, 2013
	Expires: August 05, 2013		Expires: August 25, 2013
	Using JSON Web Encryption (JWE) for Protecting JSON Web Key (JWK)		Using JavaScript Object Notation (JSON) Web Encryption (JWE) for
	Objects		Protecting JSON Web Key (JWK) Objects
	draft-miller-jose-jwe-protected-jwk-00		draft-miller-jose-jwe-protected-jwk-01
	Abstract		Abstract
	This document specifies an approach to protecting JSON Web Key (JWK)		This document specifies an approach to protecting a private key
	objects using JSON Web Encryption (JWE). This document also		formatted as a JavaScript Syntax Object Notation (JSON) Web Key (JWK)
	specifies a set of algorithms for encrypting content using password-		object using JSON Web Encryption (JWE). This document also specifies
	based cryptography.		a set of algorithms for protecting such content using password-based
			cryptography.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 August 05, 2013.		This Internet-Draft will expire on August 25, 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 12 ¶		skipping to change at page 2, line 22 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Protecting Keys . . . . . . . . . . . . . . . . . . . . . . . 3		3. Protecting Keys . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Details for Private Keys . . . . . . . . . . . . . . . . 4		3.1. Details for Private Keys . . . . . . . . . . . . . . . . 4
	3.2. Details for Symmetric Keys . . . . . . . . . . . . . . . 4		3.2. Details for Symmetric Keys . . . . . . . . . . . . . . . 4
	4. Private Key Example . . . . . . . . . . . . . . . . . . . . . 4		4. Private Key Example . . . . . . . . . . . . . . . . . . . . . 5
	5. Symmetric Key Example . . . . . . . . . . . . . . . . . . . . 7		5. Symmetric Key Example . . . . . . . . . . . . . . . . . . . . 8
	6. Using Password-Based Cryptography . . . . . . . . . . . . . . 9		6. Using Password-Based Cryptography . . . . . . . . . . . . . . 10
	6.1. PBKDF2 Key Type . . . . . . . . . . . . . . . . . . . . . 9		6.1. PBKDF2 Key Type . . . . . . . . . . . . . . . . . . . . . 10
	6.1.1. 's' Parameter . . . . . . . . . . . . . . . . . . . . 9		6.1.1. 's' Parameter . . . . . . . . . . . . . . . . . . . . 10
	6.1.2. 'c' Parameter . . . . . . . . . . . . . . . . . . . . 9		6.1.2. 'c' Parameter . . . . . . . . . . . . . . . . . . . . 10
			6.1.3. 'hint' Parameter . . . . . . . . . . . . . . . . . . 10
	6.2. PBES2 Key Encryption Algorithms . . . . . . . . . . . . . 10		6.2. PBES2 Key Encryption Algorithms . . . . . . . . . . . . . 10
	6.2.1. PBES2-HS256+A128KW . . . . . . . . . . . . . . . . . 10		6.2.1. PBES2-HS256+A128KW . . . . . . . . . . . . . . . . . 11
	6.2.2. PBES2-HS512+A256KW . . . . . . . . . . . . . . . . . 10		6.2.2. PBES2-HS512+A256KW . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7.1. JSON Web Key Types Registration . . . . . . . . . . . . . 10		7.1. JSON Web Key Types Registration . . . . . . . . . . . . . 11
	7.2. JSON Web Key Parameters Registration . . . . . . . . . . 10		7.2. JSON Web Key Parameters Registration . . . . . . . . . . 12
	7.3. JSON Web Encryption Algorithms . . . . . . . . . . . . . 11		7.3. JSON Web Encryption Algorithms . . . . . . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8.1. Re-using Keying Material . . . . . . . . . . . . . . . . 12		8.1. Re-using Keying Material . . . . . . . . . . . . . . . . 13
	8.2. Lifetime of Protected Keys . . . . . . . . . . . . . . . 12		8.2. Password Considerations . . . . . . . . . . . . . . . . . 13
	8.3. Password Considerations . . . . . . . . . . . . . . . . . 12		9. Internationalization Considerations . . . . . . . . . . . . . 13
	9. Internationalization Considerations . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14		Appendix B. Document History . . . . . . . . . . . . . . . . . . 15
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	There are times when it is necessary to transport or exchange a		There are times when it is necessary to transport a private key,
	private or symmetric key, but the transport mechanism might not		whether the private component to an asymmetric cipher key-pair or a
			symmetric cipher key used for encryption or generating a message
			authentication code (MAC), where the transport mechanism might not
	provide adequate content protection for the key. For instance, end-		provide adequate content protection for the key. For instance, end-
	to-end scenarios where the key holder and key recipient are linked		to-end scenarios where the key holder and key recipient are linked
	through multiple network hops that might or might not employ		through multiple network hops that might or might not employ
	transport layer security (TLS, [RFC5246]), nor might exchange of a		transport layer security (TLS, [RFC5246]), or the key holder an key
	key using physical media such as a USB drive that itself is not		recipient (often the same human being) might exchange a private key
			using physical media such as a USB drive that itself is not
	encrypted.		encrypted.
	This document specifies an approach that uses [JWE] to encrypt a		This document specifies an approach that uses JavaScript Object
	private or symmetric key that is formatted as [JWK]. This document		Notation (JSON) Web Encryption [JWE] to encrypt a private key that is
	also specifies and registers JSON Web Key formats and JSON Web		formatted as a JSON Web Key [JWK]. While [JWE] provides protection
	Encryption algorithms based on [RFC2898] that allow for protecting		of symmetric keys, this key is itself intended for the protection of
	keys using a password.		content, not as the content itself. Further, [JWE] does not itself
			provide protection of an asymmetric private key.
			Ofttimes the transport of private keys involves direct interaction
			with human beings. In these scenarios the use of a human-
			understandable password or passphrase to protect the private key is
			desirable. Therefore, this document also specifies and registers JWK
			formats and JWE algorithms based on [RFC2898] to allow for protecting
			content using a password.
	2. Terminology		2. Terminology
	This document inherits JSON Web Algorithms (JWA)-related terminology		This document inherits JSON Web Algorithms (JWA)-related terminology
	from [JWA], JSON Web Encryption (JWE)-related terminology from [JWE],		from [JWA], JSON Web Encryption (JWE)-related terminology from [JWE],
	JSON Web Key (JWK)-related terminology from [JWK], and password-based		JSON Web Key (JWK)-related terminology from [JWK], and password-based
	cryptography-related terminology from [RFC2898]. Security-related		cryptography-related terminology from [RFC2898]. Security-related
	terms are to be understood in the sense defined in [RFC4949].		terms are to be understood in the sense defined in [RFC4949].
	The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	3. Protecting Keys		3. Protecting Keys
	The process for protecting private keys and symmetric keys are		The process for protecting private keys and symmetric keys are
	identical. The only differences are typically the algorithms used to		identical. The only differences are typically the algorithms used to
	protect the key.		protect the key.
	To protect a key, the key holder performs the following steps:		To protect a private key, the key holder performs the following
			steps:
	1. Converts the JWK object to a UTF-8 encoded string (K').		1. Converts the JWK object to a UTF-8 encoded string (K').
	2. Performs the message encryption steps from [JWE] to generate the		2. Performs the message encryption steps from [JWE] to generate the
	JWE header H, JWE Encrypted Key E, JWE Initialization Vector IV,		JWE header H, JWE Encrypted Key E, JWE Initialization Vector IV,
	JWE Ciphertext C, and JWE Integrity Value I, using the following		JWE Ciphertext C, and JWE Integrity Value I, using the following
	inputs:		inputs:
	* The 'alg' property set to the intended key encryption		* The 'alg' property set to the intended key encryption
	algorithm (e.g., "RSA-OAEP", or "PBES2-HS512+A256KW" from		algorithm (e.g., "RSA-OAEP", or "PBES2-HS512+A256KW" from
	skipping to change at page 4, line 35 ¶		skipping to change at page 5, line 5 ¶
	3.2. Details for Symmetric Keys		3.2. Details for Symmetric Keys
	Symmetric keys are typically protected using public-private key		Symmetric keys are typically protected using public-private key
	pairs. It is assumed the key holder has the appropriate public		pairs. It is assumed the key holder has the appropriate public
	key(s) for the key recipient(s).		key(s) for the key recipient(s).
	The process defined herein expects JWK objects. While more compact		The process defined herein expects JWK objects. While more compact
	to simply encrypt the symmetric key directly with a public key, using		to simply encrypt the symmetric key directly with a public key, using
	the complete JWE process on complete JWK objects allows additional		the complete JWE process on complete JWK objects allows additional
	properties to be protected (e.g., expected lifetime, acceptable uses)		properties to be protected (e.g., expected lifetime, acceptable uses)
	without exceeding the input limits inherent in most public-private		without exceeding the very restrictive plaintext length limits in
	key operations.		most public-private key operations (e.g., 234 octects when using the
			"RSA-OAEP" algorithm with a 2048-bit key).
	4. Private Key Example		4. Private Key Example
	NOTE: unless otherwise indicated, all line breaks are included for		NOTE: unless otherwise indicated, all line breaks are included for
	readability.		readability.
	The key holder begins with the [JWK] representation of the private		The key holder begins with the [JWK] representation of the private
	key (here using a [RFC3447] RSA private key, formatted per [JPSK]):		key (here using a [RFC3447] RSA private key, formatted per [JPSK]):
	{		{
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 29 ¶
	"kty":"PBKDF2",		"kty":"PBKDF2",
	"s":"2WCTcJZ1Rvd_CJuJripQ1w",		"s":"2WCTcJZ1Rvd_CJuJripQ1w",
	"c":4096		"c":4096
	}		}
	}		}
	Password:		Password:
	Thus from my lips, by yours, my sin is purged.		Thus from my lips, by yours, my sin is purged.
	Content Master Key (encoded as base64url per [RFC4686]):		Content Master Key (encoded as base64url per [RFC4648]):
	1ICvnpc3zPRNS7JoJ9bnJ929eX7EnRwmc0CHNOF1zKc		1ICvnpc3zPRNS7JoJ9bnJ929eX7EnRwmc0CHNOF1zKc
	Initialization Vector (encoded as base64url per [RFC4686]):		Initialization Vector (encoded as base64url per [RFC4648]):
	B9BVK3hIsEu9zUOWjKeOSg		B9BVK3hIsEu9zUOWjKeOSg
	The key holder performs steps 1 and 2 to generate the [JWE] outputs		The key holder performs steps 1 and 2 to generate the [JWE] outputs
	(represented using the Compact Serialization):		(represented using the Compact Serialization):
	eyJhbGciOiJQQkVTMi1IUzI1NitBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDK0hTMjU		eyJhbGciOiJQQkVTMi1IUzI1NitBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDK0hTMjU
	2IiwiandrIjp7Imt0eSI6IlBCS0RGMiIsInNhbHQiOiIyV0NUY0paMVJ2ZF9DSn		2IiwiandrIjp7Imt0eSI6IlBCS0RGMiIsInNhbHQiOiIyV0NUY0paMVJ2ZF9DSn
	VKcmlwUTF3IiwiaXRycyI6NDA5Nn19.		VKcmlwUTF3IiwiaXRycyI6NDA5Nn19.
	dO4VTHV1JJnnPxbc9xswMA6ezNLCQ1Nq0Bnt4l2hjzxyXfbgM3w-cQ.		dO4VTHV1JJnnPxbc9xswMA6ezNLCQ1Nq0Bnt4l2hjzxyXfbgM3w-cQ.
	skipping to change at page 8, line 23 ¶		skipping to change at page 8, line 39 ¶
	ahTEkEcjtduRqfkxJKHYVq9Iro4x1cewXFdJZUuMOQAhoD63AHemXE		ahTEkEcjtduRqfkxJKHYVq9Iro4x1cewXFdJZUuMOQAhoD63AHemXE
	kdPiKqJvkBXDT_Eo4NPOjMKKkFPy2MsJQBmdtVknUvzxEchhYjZ490		kdPiKqJvkBXDT_Eo4NPOjMKKkFPy2MsJQBmdtVknUvzxEchhYjZ490
	EJTvGJ7OYwrSwkcCxy9D29XxL-OQLkSLlH1XD8kgVmJw8hsb42Bg0j		EJTvGJ7OYwrSwkcCxy9D29XxL-OQLkSLlH1XD8kgVmJw8hsb42Bg0j
	PgKlkvcyENmYpYE_hqlJoqYNFzgtAnNtK4C3tspix46R3IgilQG2Of		PgKlkvcyENmYpYE_hqlJoqYNFzgtAnNtK4C3tspix46R3IgilQG2Of
	i99vpUnmTvjrOlNef2l65PRsPHD1Gl9fyPLCxrkolXbdwvxZ9j2d2f		i99vpUnmTvjrOlNef2l65PRsPHD1Gl9fyPLCxrkolXbdwvxZ9j2d2f
	Iu-OBTxRhnBtarNls_k",		Iu-OBTxRhnBtarNls_k",
	"e":"AQAB"		"e":"AQAB"
	}		}
	}		}
	Content Master Key (encoded as base64url per [RFC4686]):		Content Master Key (encoded as base64url per [RFC4648]):
	ci5IlLIHnFLn-1lhL5CWOS3DdbXGU-BPuFCrLspXAkA		ci5IlLIHnFLn-1lhL5CWOS3DdbXGU-BPuFCrLspXAkA
	Initialization Vector (encoded as base64url per [RFC4686]):		Initialization Vector (encoded as base64url per [RFC4648]):
	_dYbckd_xuJUBUNsxkT9yw		_dYbckd_xuJUBUNsxkT9yw
	The key holder performs steps 1 and 2 to generate the [JWE] outputs		The key holder performs steps 1 and 2 to generate the [JWE] outputs
	(represented using the Compact Serialization):		(represented using the Compact Serialization):
	eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMrSFMyNTYiLCJqd2siOns		eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMrSFMyNTYiLCJqd2siOns
	ia3R5IjoiUlNBIiwibiI6IkFMZWtQRDFrb3RYWkNZX1lVel9JVFdCWmIyblRPdz		ia3R5IjoiUlNBIiwibiI6IkFMZWtQRDFrb3RYWkNZX1lVel9JVFdCWmIyblRPdz
	M1VnZabG5xVGlZU2V1c081OHFDdFlEemFoVEVrRWNqdGR1UnFma3hKS0hZVnE5S		M1VnZabG5xVGlZU2V1c081OHFDdFlEemFoVEVrRWNqdGR1UnFma3hKS0hZVnE5S
	XJvNHgxY2V3WEZkSlpVdU1PUUFob0Q2M0FIZW1YRWtkUGlLcUp2a0JYRFRfRW80		XJvNHgxY2V3WEZkSlpVdU1PUUFob0Q2M0FIZW1YRWtkUGlLcUp2a0JYRFRfRW80
	TlBPak1LS2tGUHkyTXNKUUJtZHRWa25Vdnp4RWNoaFlqWjQ5MEVKVHZHSjdPWXd		TlBPak1LS2tGUHkyTXNKUUJtZHRWa25Vdnp4RWNoaFlqWjQ5MEVKVHZHSjdPWXd
	yU3drY0N4eTlEMjlYeEwtT1FMa1NMbEgxWEQ4a2dWbUp3OGhzYjQyQmcwalBnS2		yU3drY0N4eTlEMjlYeEwtT1FMa1NMbEgxWEQ4a2dWbUp3OGhzYjQyQmcwalBnS2
	xrdmN5RU5tWXBZRV9ocWxKb3FZTkZ6Z3RBbk50SzRDM3RzcGl4NDZSM0lnaWxRR		xrdmN5RU5tWXBZRV9ocWxKb3FZTkZ6Z3RBbk50SzRDM3RzcGl4NDZSM0lnaWxRR
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 21 ¶
	6.1. PBKDF2 Key Type		6.1. PBKDF2 Key Type
	The "PBKDF2" key type is used to contain the parameters necessary to		The "PBKDF2" key type is used to contain the parameters necessary to
	derive a cipher key from a password using the PBKDF2 algorithm from		derive a cipher key from a password using the PBKDF2 algorithm from
	[RFC2898]. The following parameters are defined:		[RFC2898]. The following parameters are defined:
	6.1.1. 's' Parameter		6.1.1. 's' Parameter
	The REQUIRED "s" parameter contains the PBKDF2 salt value (S), as a		The REQUIRED "s" parameter contains the PBKDF2 salt value (S), as a
	base64url encoded string (per [RFC4686]). This value MUST NOT be the		base64url encoded string (per [RFC4648]). This value MUST NOT be the
	empty string "".		empty string "".
			The salt expands the possible keys that can be derived from a given
			password. [RFC2898] originally recommended a minimum salt length of
			8 octets (since there is no concern here of a derived key being re-
			used for different purposes). The salt MUST be generated randomly;
			see [RFC4086] for considerations on generating random values.
	6.1.2. 'c' Parameter		6.1.2. 'c' Parameter
	The REQUIRED "c" parameter contains the PBKDF2 iteration count (c),		The REQUIRED "c" parameter contains the PBKDF2 iteration count (c),
	as an integer. This value MUST NOT be less than 1, as per [RFC2898].		as an integer. This value MUST NOT be less than 1, as per [RFC2898].
	6.2. PBES2 Key Encryption Algorithms		The iteration count adds computational expense, ideally compounded by
			the possible range of keys introduced by the salt. [RFC2898]
			originally recommended a minimum iteration count of 1000.
			6.1.3. 'hint' Parameter
			The OPTIONAL "hint" parameter contains a description clue to the
			password, as a string. If present, this value SHOULD NOT be the
			empty string "".
			The hint is typically displayed to the user as a reminder or mnemonic
			for the actual password used. This parameter MUST NOT contain the
			actual password, and implementations MAY use various heuristic
			algorithms to prohibit hints that are alternate forms of the actual
			password.
			6.2. PBES2 Key Encryption Algorithms
	The "PBES2-HS256+A128KW" and "PBES2-HS512+A256KW" algorithms defined		The "PBES2-HS256+A128KW" and "PBES2-HS512+A256KW" algorithms defined
	below are used to encrypt a JWE Content Master Key using a user-		below are used to encrypt a JWE Content Master Key using a user-
	supplied password to derive the key encryption key. With these		supplied password to derive the key encryption key. With these
	algorithms, the derived key is used to encrypt the JWE Content Master		algorithms, the derived key is used to encrypt the JWE Content Master
	Key. These algorithms combine a key derivation function with an		Key. These algorithms combine a key derivation function with an
	encryption scheme to encrypt the JWE Content Master Key according to		encryption scheme to encrypt the JWE Content Master Key according to
	PBES2 from section 6.2 of [RFC2898].		PBES2 from section 6.2 of [RFC2898].
	6.2.1. PBES2-HS256+A128KW		6.2.1. PBES2-HS256+A128KW
	skipping to change at page 10, line 37 ¶		skipping to change at page 11, line 32 ¶
	The "PBES2-HS512+A256KW" algorithm uses "HMAC-SHA512" as the PRF "and		The "PBES2-HS512+A256KW" algorithm uses "HMAC-SHA512" as the PRF "and
	"AES256-WRAP" as defined in [RFC3394] for the encryption scheme. The		"AES256-WRAP" as defined in [RFC3394] for the encryption scheme. The
	salt (S) and iteration count (c) MUST be specified by the "s" and "c"		salt (S) and iteration count (c) MUST be specified by the "s" and "c"
	parameters (respectively) in the applicable "PBKDF2" JWK object. The		parameters (respectively) in the applicable "PBKDF2" JWK object. The
	derived-key length (dkLen) is 32 octets.		derived-key length (dkLen) is 32 octets.
	7. IANA Considerations		7. IANA Considerations
	7.1. JSON Web Key Types Registration		7.1. JSON Web Key Types Registration
			This document registers the following to the JSON Web Key Types
			registry:
	o "kty" Paramater value: "PBKDF2"		o "kty" Paramater value: "PBKDF2"
	o Implementation Requirements: OPTIONAL		o Implementation Requirements: OPTIONAL
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 6.1 of [[ this document ]]		o Specification Document(s): Section 6.1 of [[ this document ]]
	7.2. JSON Web Key Parameters Registration		7.2. JSON Web Key Parameters Registration
			This document registers the following to the JSON Web Key Parameters
			registry:
	o Parameter Name: "s"		o Parameter Name: "s"
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 6.1.1 of [[ this document ]]		o Specification Document(s): Section 6.1.1 of [[ this document ]]
	o Parameter Name: "c"		o Parameter Name: "c"
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 6.1.2 of [[ this document ]]		o Specification Document(s): Section 6.1.2 of [[ this document ]]
			o Parameter Name: "hint"
			o Change Controller: IETF
			o Specification Document(s): Section 6.1.3 of [[ this document ]]
	7.3. JSON Web Encryption Algorithms		7.3. JSON Web Encryption Algorithms
			This document registers the following to the JSON Web Encryption
			Algorithms registry:
	o Algorithm Name: "PBES2-HS256+A128KW"		o Algorithm Name: "PBES2-HS256+A128KW"
	o Algorithm Usage Location(s): "alg"		o Algorithm Usage Location(s): "alg"
	o Implementation Requirements: OPTIONAL		o Implementation Requirements: OPTIONAL
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 6.2.1 of [[ this document ]]		o Specification Document(s): Section 6.2.1 of [[ this document ]]
	o Algorithm Name: "PBES2-HS512+A256KW"		o Algorithm Name: "PBES2-HS512+A256KW"
	o Algorithm Usage Location(s): "alg"		o Algorithm Usage Location(s): "alg"
	o Implementation Requirements: OPTIONAL		o Implementation Requirements: OPTIONAL
	o Change Controller: IETF		o Change Controller: IETF
	skipping to change at page 12, line 4 ¶		skipping to change at page 13, line 17 ¶
	o Algorithm Usage Location(s): "alg"		o Algorithm Usage Location(s): "alg"
	o Implementation Requirements: OPTIONAL		o Implementation Requirements: OPTIONAL
	o Change Controller: IETF		o Change Controller: IETF
	o Specification Document(s): Section 6.2.2 of [[ this document ]]		o Specification Document(s): Section 6.2.2 of [[ this document ]]
	8. Security Considerations		8. Security Considerations
	8.1. Re-using Keying Material		8.1. Re-using Keying Material
	It is NOT RECOMMENDED to re-use the same keying material (Key		It is NOT RECOMMENDED to re-use the same keying material (Key
	Encryption Key, Content Master Key, Initialization Vector, etc) to		Encryption Key, Content Master Key, Initialization Vector, etc) to
	protect multiple JWK objects, or to protect the same JWK object		protect multiple JWK objects, or to protect the same JWK object
	multiple times. When using "PBES2-HS256+A128KW" or		multiple times. One suggestion for preventing re-use is to always
	"PBES2-HS512+A256KW", implementations MUST NOT use the same Key		generate a new set keying material for each protection operation,
	Encryption Key for a given password, and SHOULD take steps to prevent		based on the considerations noted in this document as well as from
	the same Key Encryption Key being used by different passwords when		[RFC4086].
	possible.
	8.2. Lifetime of Protected Keys
	Depending on the application, a protected JWK could potentially be
	stored for an indefinite time, anywhere from milliseconds (e.g.,
	broadcasted over a computer network) to years (e.g., stored as a
	file).
	8.3. Password Considerations		8.2. Password Considerations
	While convenient for end users, passwords have many drawbacks. To		While convenient for end users, passwords have many drawbacks. To
	help mitigate these limitations, this document applies principles		help mitigate these limitations, this document applies principles
	from [RFC2898] to derive cryptographic keys from user-supplied		from [RFC2898] to derive cryptographic keys from user-supplied
	passwords.		passwords.
	The salt expands the possible keys that can be derived from a given
	password. [RFC2898] originally recommended a minimum salt length of
	8 octets (since there is no concern here of a derived key being re-
	used for different purposes). The salt MUST be generated randomly;
	see [RFC4086] for considerations on generating random values.
	The iteration count adds computational expense, ideally compounded by
	the possible range of keys introduced by the salt. [RFC2898]
	originally recommended a minimum iteration count of 1000.
	An ideal password is one that is as large (or larger) than the		An ideal password is one that is as large (or larger) than the
	derived key length but less than the PRF's block size. For		derived key length but less than the PRF's block size. Passwords
	"PBES2-HS256+A128KW", the ideal password is between 16 and 64 octets		larger than the PRF's block size are first hashed, which reduces an
	long; for "PBES2-HS512+A256KW", the ideal password is between 32 and		attacker's effective search space to the length of the hash algorithm
	128 octets long.		(32 octects for HMAC-SHA-256; 64 octets for HMAC-SHA-512). For
			"PBES2-HS256+A128KW", it is RECOMMENDED that the password be no
			longer than 64 octets long; for "PBES2-HS512+A256KW", it is
			RECOMMENDED that the password be no longer than 128 octets long.
	9. Internationalization Considerations		9. Internationalization Considerations
	Passwords obtained from users are likely to require preparation and		Passwords obtained from users are likely to require preparation and
	normalization to account for differences of octet sequences generated		normalization to account for differences of octet sequences generated
	by different input devices, locales, etc. It is RECOMMENDED for		by different input devices, locales, etc. It is RECOMMENDED for
	applications to perform the steps outlined in [SASLPREP] to prepare a		applications to perform the steps outlined in [SASLPREP] to prepare a
	user-supplied password before performing key derivation and		password supplied directly by a user before performing key derivation
	encryption.		and encryption.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[JWA] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-		[JWA] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
	json-web-algorithms-08 (work in progress), December 2012.		json-web-algorithms-08 (work in progress), December 2012.
	[JWE] Jones, M., Rescola, E., and J. Hildebrand, "JSON Web		[JWE] Jones, M., Rescola, E., and J. Hildebrand, "JSON Web
	Encryption (JWE)", draft-ietf-jose-json-web-encryption-08		Encryption (JWE)", draft-ietf-jose-json-web-encryption-08
	skipping to change at page 13, line 47 ¶		skipping to change at page 14, line 47 ¶
	[RFC2898] Kaliski, B., "Password-Based Cryptography Specification",		[RFC2898] Kaliski, B., "Password-Based Cryptography Specification",
	RFC 2898, September 2000.		RFC 2898, September 2000.
	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard		[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, September 2002.		(AES) Key Wrap Algorithm", RFC 3394, September 2002.
	[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Requirements for Security", RFC 4086, June 2005.		Requirements for Security", RFC 4086, June 2005.
	[RFC4686] 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.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
	4949, August 2007.		4949, August 2007.
	10.2. Informative References		10.2. Informative References
	[AES] National Institute of Standards and Technology (NIST),		[AES] National Institute of Standards and Technology (NIST),
	"Advanced Encryption Standard (AES)", FIPS PUB 197,		"Advanced Encryption Standard (AES)", FIPS PUB 197,
	November 2001.		November 2001.
	skipping to change at page 14, line 22 ¶		skipping to change at page 15, line 22 ¶
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 2898, February 2003.		Version 2.1", RFC 2898, February 2003.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Appendix B. Document History		Appendix B. Document History
			-01 Incorporated changes suggested by Jim Schaad:
			* Expanded the acronym "JSON" on first use.
			* Expanded the introduction to explain how this document's
			protection of symmetric keys differs from [JWE].
			* Expanded the introduction to better explain why password-based
			encryption algorithms are needed.
			* Moved information on PBKDF2 salt from the security
			considerations to the "s" JWK parameter definition.
			* Moved information on PBKDF2 iteration count from security
			considerations to the "c" JWK parameter definition.
			* Added the "hint" JWK parameter.
			* Explicitly noted what registries are updated by the IANA
			considerations.
			* Relaxed language around re-use of keying material.
			* Removed section discussing protected key lifetimes.
			* Improved recommendations around password lengths.
	-00 Initial revision		-00 Initial revision
	Author's Address		Author's Address
	Matthew Miller		Matthew Miller
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1899 Wynkoop Street, Suite 600		1899 Wynkoop Street, Suite 600
	Denver, CO 80202		Denver, CO 80202
	USA		USA
End of changes. 35 change blocks.
	83 lines changed or deleted		146 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/