One document matched: draft-miller-jose-jwe-protected-jwk-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-miller-jose-jwe-protected-jwk-01" ipr="trust200902">
<front>
<title abbrev="JWE Protected JWK">Using JavaScript Object Notation (JSON) Web Encryption (JWE) for Protecting JSON Web Key (JWK) Objects</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3204</phone>
<email>mamille2@cisco.com</email>
</address>
</author>
<date month="February" day="21" year="2013"/>
<area>Security</area>
<workgroup>JOSE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies an approach to protecting a private key formatted as a JavaScript Syntax Object Notation (JSON) Web Key (JWK) object using JSON Web Encryption (JWE). This document also specifies a set of algorithms for protecting such content using password-based cryptography.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>There are times when it is necessary to transport a private key, 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-to-end scenarios where the key holder and key recipient are linked through multiple network hops that might or might not employ transport layer security (TLS, <xref target="RFC5246"/>), or the key holder an key recipient (often the same human being) might exchange a private key using physical media such as a USB drive that itself is not encrypted.</t>
<t>This document specifies an approach that uses JavaScript Object Notation (JSON) Web Encryption <xref target="JWE"/> to encrypt a private key that is formatted as a JSON Web Key <xref target="JWK"/>. While <xref target="JWE"/> provides protection of symmetric keys, this key is itself intended for the protection of content, not as the content itself. Further, <xref target="JWE"/> does not itself provide protection of an asymmetric private key.</t>
<t>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 <xref target="RFC2898"/> to allow for protecting content using a password.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits JSON Web Algorithms (JWA)-related terminology from <xref target="JWA"/>, JSON Web Encryption (JWE)-related terminology from <xref target="JWE"/>, JSON Web Key (JWK)-related terminology from <xref target="JWK"/>, and password-based cryptography-related terminology from <xref target="RFC2898"/>. Security-related terms are to be understood in the sense defined in <xref target="RFC4949"/>.</t>
<t>The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="Protecting Keys" anchor="protect">
<t>The process for protecting private keys and symmetric keys are identical. The only differences are typically the algorithms used to protect the key.</t>
<t>To protect a private key, the key holder performs the following steps:<vspace blankLines="1"/>
<list style="numbers">
<t>Converts the JWK object to a UTF-8 encoded string (K').<vspace blankLines="1"/></t>
<t>Performs the message encryption steps from <xref target="JWE"/> to generate the JWE header H, JWE Encrypted Key E, JWE Initialization Vector IV, JWE Ciphertext C, and JWE Integrity Value I, using the following inputs:<vspace blankLines="1"/>
<list style="symbols">
<t>The 'alg' property set to the intended key encryption algorithm (e.g., "RSA-OAEP", or "PBES2-HS512+A256KW" from below).<vspace blankLines="1"/></t>
<t>Keying material appropriate for the selected key encryption algorithm (e.g., private key for "RSA-OAEP", or shared password, salt, and iteration count for "PBES2-HS512+A256KW").<vspace blankLines="1"/></t>
<t>The 'enc' property set to the intended content encryption algorithm (e.g., "A256GCM" or "A256CBC+HS512").<vspace blankLines="1"/></t>
<t>Keying material appropriate for the selected content encryption algorithm (e.g., Content Encryption Key and Initialization Vector).<vspace blankLines="1"/></t>
<t>K' as the plaintext content to encrypt.</t>
</list>
</t>
<t>Serializes to the appropriate format for exchange, such as the Compact Serialization documented in <xref target="JWE"/>.<vspace blankLines="1"/></t>
</list>
</t>
<section title="Details for Private Keys" anchor="protect-private">
<t>Private keys are typically protected using a symmetric key. This symmetric key can be exchanged or determined in various ways, such as deriving one from a user-supplied password; the algorithms "PBES2-HS256+A128KW" and "PBES2-HS512+A256KW" (defined in <xref target="pbcrypto-pbes2-jwe"/>) enable this.</t>
</section>
<section title="Details for Symmetric Keys" anchor="protect-symmetric">
<t>Symmetric keys are typically protected using public-private key pairs. It is assumed the key holder has the appropriate public key(s) for the key recipient(s).</t>
<t>The process defined herein expects JWK objects. While more compact to simply encrypt the symmetric key directly with a public key, using the complete JWE process on complete JWK objects allows additional properties to be protected (e.g., expected lifetime, acceptable uses) without exceeding the very restrictive plaintext length limits in most public-private key operations (e.g., 234 octects when using the "RSA-OAEP" algorithm with a 2048-bit key).</t>
</section>
</section>
<section title="Private Key Example" anchor="example-privkey">
<t>NOTE: unless otherwise indicated, all line breaks are included for readability.</t>
<t>The key holder begins with the <xref target="JWK"/> representation of the private key (here using a <xref target="RFC3447"/> RSA private key, formatted per <xref target="JPSK"/>):</t>
<t>
<figure>
<artwork><![CDATA[
{
"kty":"RSA",
"kid":"juliet@capulet.lit",
"n":"ALekPD1kotXZCY_YUz_ITWBZb2nTOw35VvZlnqTiYSeusO58qCtYDz
ahTEkEcjtduRqfkxJKHYVq9Iro4x1cewXFdJZUuMOQAhoD63AHemXE
kdPiKqJvkBXDT_Eo4NPOjMKKkFPy2MsJQBmdtVknUvzxEchhYjZ490
EJTvGJ7OYwrSwkcCxy9D29XxL-OQLkSLlH1XD8kgVmJw8hsb42Bg0j
PgKlkvcyENmYpYE_hqlJoqYNFzgtAnNtK4C3tspix46R3IgilQG2Of
i99vpUnmTvjrOlNef2l65PRsPHD1Gl9fyPLCxrkolXbdwvxZ9j2d2f
Iu-OBTxRhnBtarNls_k",
"e":"AQAB",
"d":"GRtbIQmhOZtyszfgKdg4u_N-R_mZGU_9k7JQ_jn1DnfTuMdSNprTea
STyWfSNkuaAwnOEbIQVy1IQbWVV25NY3ybc_IhUJtfri7bAXYEReWa
Cl3hdlPKXy9UvqPYGR0kIXTQRqns-dVJ7jahlI7LyckrpTmrM8dWBo
4_PMaenNnPiQgO0xnuToxutRZJfJvG4Ox4ka3GORQd9CsCZ2vsUDms
XOfUENOyMqADC6p1M3h33tsurY15k9qMSpG9OX_IJAXmxzAh_tWiZO
wk2K4yxH9tS3Lq1yX8C1EWmeRDkK2ahecG85-oLKQt5VEpWHKmjOi_
gJSdSgqcN96X52esAQ",
"p":"ANq50jleISkjfLEuAoHEBxW7NPF26BQ6irpt7HOIdxkca05kHZdWSv
bsPjyB30D9BZMV1a8flhPmRG66orx_9ogi1Eu8AJel7wEbdSpCGlMT
z0mAfcpN9bNEPFCvehN_zqwAwGLQCbPjNycQi3zYKoeehw5xE00IR9
6wk-U98icL",
"q":"2a43135aa05479f570676fc36e3d693d0ab21d21e38fdd0be71fcc
3b3a9800931c2cc66d6d4b702aabd50eaded6c4a3764872885b0ed
b7a49b7e65b382069ba50c4dc6e069a0e39ffdafc780c5cafe586a
8a0238cbf92a4b5c18e762308d49f9ae046b27ec98a35878d4a47e
bf3da9621100798ae1b6d5adc55a8b0915620fa7",
"dp":"KkMTWqBUefVwZ2_Dbj1pPQqyHSHjj90L5x_MOzqYAJMcLMZtbUtwK
qvVDq3tbEo3ZIcohbDtt6SbfmWzggabpQxNxuBpoOOf_a_HgMXK_l
hqigI4y_kqS1wY52IwjUn5rgRrJ-yYo1h41KR-vz2pYhEAeYrhttW
txVqLCRViD6c",
"dq":"AvfS0-gRxvn0bwJoMSnFxYcK1WnuEjQFluMGfwGitQBWtfZ1Er7t1
xDkbN9GQTB9yqpDoYaN06H7CFtrkxhJIBQaj6nkF5KKS3TQtQ5qCz
kOkmxIe3KRbBymXxkb5qwUpX5ELD5xFc6FeiafWYY63TmmEAu_lRF
COJ3xDea-ots",
"qi":"AJUkIvsPQqclEXjBKz9UbAS5O8DbTr7OREKT6prjL6luezQVHM0nB
KD8JlKqmm7vVdPj8uHUOe_22qaCkbtUfdG77hZ1Ot0h1hBYJWULyQ
zHgL5o-LJvhadKGLv53qLYENIc2yOYK8u2o3WMvftpTcf--mgWaDl
LvRwiflLH0jiP"
}
]]></artwork>
</figure>
</t>
<t>The key holder uses the following <xref target="JWE"/> inputs:<vspace blankLines="1"/></t>
<t>
<figure>
<preamble>JWE Header:</preamble>
<artwork><![CDATA[
{
"alg":"PBES2-HS256+A128KW",
"enc":"A128CBC+HS256",
"jwk":{
"kty":"PBKDF2",
"s":"2WCTcJZ1Rvd_CJuJripQ1w",
"c":4096
}
}
]]></artwork>
</figure>
<vspace blankLines="1"/>
</t>
<t>
<figure>
<preamble>Password:</preamble>
<artwork><![CDATA[
Thus from my lips, by yours, my sin is purged.
]]></artwork>
</figure>
<vspace blankLines="1"/>
</t>
<t>
<figure>
<preamble>Content Master Key (encoded as base64url per <xref target="RFC4648"/>):</preamble>
<artwork><![CDATA[
1ICvnpc3zPRNS7JoJ9bnJ929eX7EnRwmc0CHNOF1zKc
]]></artwork>
</figure>
<vspace blankLines="1"/>
</t>
<t>
<figure>
<preamble>Initialization Vector (encoded as base64url per <xref target="RFC4648"/>):</preamble>
<artwork><![CDATA[
B9BVK3hIsEu9zUOWjKeOSg
]]></artwork>
</figure>
<vspace blankLines="1"/>
</t>
<t>The key holder performs steps 1 and 2 to generate the <xref target="JWE"/> outputs (represented using the Compact Serialization):<vspace blankLines="1"/></t>
<t>
<figure>
<artwork><![CDATA[
eyJhbGciOiJQQkVTMi1IUzI1NitBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDK0hTMjU
2IiwiandrIjp7Imt0eSI6IlBCS0RGMiIsInNhbHQiOiIyV0NUY0paMVJ2ZF9DSn
VKcmlwUTF3IiwiaXRycyI6NDA5Nn19.
dO4VTHV1JJnnPxbc9xswMA6ezNLCQ1Nq0Bnt4l2hjzxyXfbgM3w-cQ.
B9BVK3hIsEu9zUOWjKeOSg.
mUt0YpU0Gsfis7tK70aggz5Qb5J6oppjl7aSn_S4DIHJkSF-Gd9KEu4XF0vbMc1
kvovNOmnahDLoJIq7hoB666zt1yp4umZKuzhOQ5O3jwOwC4rUf1W3hDM5p2nYZq
LFqDBme-Z8KVwosfBj2TkZSnFWC6cqMy6d7K6egWz7uct39ZH6_FAUrr0JiMMnj
0jxTEBP6apiLD-GJutxITnWISmGmX0jOWyTKRh-F-I3lJ3pXE0_4vWR8-gXaFGW
CgItofAOsdKKoxiSJvXPVxK-oqPFPlS0H5OLHw9tkjmPVZ0Ot-RLgoMPQJ0Yi47
U0DBh_2-IQBcpPvwBnUzl8KcrLFh-NpTSoC_zIn6xos5r4JVXf5v1V79MKGvk3-
evdQoEKtS9LnimKTP8YmeqAnU1Y3VoUkgeRTZikKhQ_kwpAxakaRuBzfaIOKjqY
X5J_jSJuuBQU_4fgHPkvrq1zJ3TnUAWZIqFcw27dKGMxXLMlz_sbW2YerZ0BULc
xbe8bJpbHkE64r7Nc86iZyL6e-8htkUvpGmdQGqno-q723Ry-u2Iz1-exjgjbNu
z4tbSrf49Y0_VSFEuHLnCRChVQE8cgupCy8GioEpuC7v1hMNE7JZTVbG3Ud3QzZ
Webr0sAYjWwqa2ySoJ7AaRfIiVgMdTAS2_gBdbYRSYI2pkQTHpyZ8D_lp5RvYFR
FNsHWoEToXeL1P_csuKaGsikKbzgXdevrjmCJTOpByGYO5cb2O8xFyYy1VX_pM6
bxqj5ai8-jyiCoDKvF_40wT_9F6H79UIZtuc3L7r7OxKrmY32LLvfofVRsfdIcK
AhMvnvOCpzRN3sHiR7iAx1bvaIaz40Mshf8z-__70GEqr5oWxRwyv2uhCiPHtV6
lBIhCqki6th317-n_lR58LHw894ja0xbOOxUJfZziaG14O9tqjetTSB0JGKXC4S
ry6zzeyqDwsSpY439Uqn7va_V5ELLfJf9S7fh0AtZS3ogpw4oT-6LbywFPf0jH9
LgNmatORG_J2wgu8R8QpKogo_WTQK7izHVtEMe1vQQElAy8P2SUjOJiOU6wAW4o
neU7HUUwD3cvFSn-ykze48FurI5f6DXyPNTVtzaEjBnVVP517bGb_3V_-1SCBdZ
1f_sYWJ0S8r2u5ccy28CP_7MhZOY8r4oJJn2NmT_jDOllCNtJLKVdKon0QslEER
GXa8r6Jtp3UbfLVjZQbnFl2mBygH4PoWbyGVxUNDE66mZVKM4Y-6ng5L84PrDt5
aAQ0HREqjvX4bsQgWyXKq-HRe5DXO2qdoPAIoPGhqOlZz70iYHO5lkX_Oso3eBv
DCDVbkD7Gr-LZJusrVtA6Hf82YpUUldjyPsD985T2hdcSQMoxol8aWNDL52T4Eo
FTTLFNG0Xy3qvS79ScgMOSIOE8k_DgzyBrcGJibeeaVKGdbqUQRADaeWO2QM3Rq
9TOyizLNyyjkJBgecWtIfLAWSTPx7n39zuBhGb5oChAFlR1HqrV76KO22rj08ra
J_zi8YQpp4qTTXmYwY5sjftE8IDDcLxk6ovvDM7262onZ5CP3GKp09s9dTJZi2L
tmZ8NAHlJ5Q9v9XMHi0tvLKKlahdcvgnG3sC_gL46osnNE3gBipLe_IQNl0X0zU
cakwzYtC02JeBbNFQSduY4OBiAAhD2VhyhLMNvGyt9QjntCru1z_gkr1qZR4y5W
Uec9WtxPqqC-dny-MZOINZd13LdStVY_g0KaAJET0etT4vYZJ6IfqdEXRSKKQKN
CJpencNhJH99NEumPwY0J8hYGC-KkGb6ZQ0yeQDIpcH2reMS9_DU0JaFtd5BpKm
pNDAvmekzWv65o6MCzLVN4Wlf4tZ6a7FnLxDg0jQBsPGh3ZKEeGmvxJKSvGK_Or
5-gXJdMyj1n0bWyex-ZTmtbR3OHKgAlFQUdLuB-47UFS0HtF0Lo1ENPZUoxwFcg
Uu2Yr30O8vhHLhkRAyAvrFPBHhSqcGr954FeMhMo18dKu3zdykyueIQpLIpU7qN
btXXSOu1c1rPqBMm3h77iLmNzSByFER32-W7hQwx9-Ikbwy52DaZACpXdyzZOQ2
PSYEJeuy8CyHap8_Dwucb3CQiqBi-iz25Mmwx8qBjWq3K31W4WeF0heC_rCe6LS
vOCuHJXpu8Wqa1LeyTbuHyQawH8Aev-MzVLXp0E-WtggfNi-mqcThs25993uveI
TpmK6lyQu6SX31t6MlQKI_29e46cYRMFhsEZSGM--acnZiryvi39IKsVNtOf33E
9zlKntRdmMoROenR-q5--9nObKaF81k3Xb-yWNTlQh1ot59rWAeqpPv0uA.
big8BFT-dXJqoKGScpLk0ssjuyWn7fxDvJc7AN7ONPw
]]></artwork>
</figure>
</t>
</section>
<section title="Symmetric Key Example" anchor="protect-example-symm">
<t>NOTE: unless otherwise indicated, all line breaks are included for readability.</t>
<t>The key holder begins with the <xref target="JWK"/> representation of the symmetric key (here using a <xref target="AES"/> 128-bit key, formatted as per <xref target="JPSK"/>):</t>
<t>
<figure>
<artwork><![CDATA[
{
"kty":"oct",
"kid": "b8acba65-8af2-4e93-a8e0-d4abd7f25e52",
"k": "fKrBr19_ne9Cp3akXGpqgA"
}
]]></artwork>
</figure>
</t>
<t>The key holder uses the following <xref target="JWE"/> inputs:</t>
<t>
<figure>
<preamble>JWE Header:</preamble>
<artwork><![CDATA[
{
"alg":"RSA-OAEP",
"enc":"A128CBC+HS256",
"jwk":{
"kty":"RSA",
"n":"ALekPD1kotXZCY_YUz_ITWBZb2nTOw35VvZlnqTiYSeusO58qCtYDz
ahTEkEcjtduRqfkxJKHYVq9Iro4x1cewXFdJZUuMOQAhoD63AHemXE
kdPiKqJvkBXDT_Eo4NPOjMKKkFPy2MsJQBmdtVknUvzxEchhYjZ490
EJTvGJ7OYwrSwkcCxy9D29XxL-OQLkSLlH1XD8kgVmJw8hsb42Bg0j
PgKlkvcyENmYpYE_hqlJoqYNFzgtAnNtK4C3tspix46R3IgilQG2Of
i99vpUnmTvjrOlNef2l65PRsPHD1Gl9fyPLCxrkolXbdwvxZ9j2d2f
Iu-OBTxRhnBtarNls_k",
"e":"AQAB"
}
}
]]></artwork>
</figure>
<vspace blankLines="1"/>
</t>
<t>
<figure>
<preamble>Content Master Key (encoded as base64url per <xref target="RFC4648"/>):</preamble>
<artwork><![CDATA[
ci5IlLIHnFLn-1lhL5CWOS3DdbXGU-BPuFCrLspXAkA
]]></artwork>
</figure>
<vspace blankLines="1"/>
</t>
<t>
<figure>
<preamble>Initialization Vector (encoded as base64url per <xref target="RFC4648"/>):</preamble>
<artwork><![CDATA[
_dYbckd_xuJUBUNsxkT9yw
]]></artwork>
</figure>
<vspace blankLines="1"/>
</t>
<t>The key holder performs steps 1 and 2 to generate the <xref target="JWE"/> outputs (represented using the Compact Serialization):<vspace blankLines="1"/></t>
<t>
<figure>
<artwork><![CDATA[
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMrSFMyNTYiLCJqd2siOns
ia3R5IjoiUlNBIiwibiI6IkFMZWtQRDFrb3RYWkNZX1lVel9JVFdCWmIyblRPdz
M1VnZabG5xVGlZU2V1c081OHFDdFlEemFoVEVrRWNqdGR1UnFma3hKS0hZVnE5S
XJvNHgxY2V3WEZkSlpVdU1PUUFob0Q2M0FIZW1YRWtkUGlLcUp2a0JYRFRfRW80
TlBPak1LS2tGUHkyTXNKUUJtZHRWa25Vdnp4RWNoaFlqWjQ5MEVKVHZHSjdPWXd
yU3drY0N4eTlEMjlYeEwtT1FMa1NMbEgxWEQ4a2dWbUp3OGhzYjQyQmcwalBnS2
xrdmN5RU5tWXBZRV9ocWxKb3FZTkZ6Z3RBbk50SzRDM3RzcGl4NDZSM0lnaWxRR
zJPZmk5OXZwVW5tVHZqck9sTmVmMmw2NVBSc1BIRDFHbDlmeVBMQ3hya29sWGJk
d3Z4WjlqMmQyZkl1LU9CVHhSaG5CdGFyTmxzX2siLCJlIjoiQVFBQiJ9fQ.
UW26BTjbDGjgQ288JXJpGGpbZVV3WyZYJdm1Fvux8wM_t7bh6UbjbOdYXjL3rzD
phZteaD-DXiKrdGaVndTMLUmjg78H0R9K2WHxWNhTWiq8iMDGtw6BYnHW_r5DSf
vhojcDhCCBKWyO-QLXvTO1mfgo6UQwYY32Lvz-IrbxphrfBePsEXVYm75PLIIft
PnRwN3fWDMkKLCq2AesvWDuRWtKVjsh7uu_AX2ky6dvov2Lw_xMiDshsNz62RES
bNUW-ylMqNNn_VAYWKHK83k5CZppPlBb_8MDEUBPyGe_NDCa3118eo20tJGMn8v
XRg8k7D0nJ051hGlzAkMQ0S_x9g.
_dYbckd_xuJUBUNsxkT9yw.
QHkwptAlO0Gdo5BrbkaGPSek6wASr-twP8ZQ3YYHOkbRMedtsM0QwpvdnfUXoJL
7HZ0fbI-5YwO3PHvTOMXKx-K26cA-Hn9aseBvuICL2getFnrUcXs3vQI416PCw7
n39HtFLozCaBhJBaMv5x41CT6eaeRCMXE9Kbgz8lFicKNS9GYB7bUQfPXJl-qP7
05v-qkY4m2BAfofWtyGK-bnbs2ZKhKgaRTdRZlbnZTC19eSS8bPlalSNBrpr2eP
kDGDsYIKJvtbqD_xHeb7u5BT3ELmDl4CDjMruB3RiNwINcwNkCAhkg9tgV_vFCm
Qzsc9DH6dlnkYrbnyFrAD4Qe7xI1anDjLmRvU2cBB68-AtRd3PmpVzbr4t2eo33
GX9c_6fUILJS8WuExPs7KJkOuqDfKCPWDwRfX-yf8YUkrBZMj9aImyY2MyMJZFu
ITxseXbhkQFPJn-A4scSt1suWEXch5fKfl1KfxJlMio-Bm8kfUba4mgOKen7cJ0
whFSh7cupuSG0vVMLeBoBVGnndjARUxl5I57NZupH7xq3L8lDVHu_mQ_8Ae1j2h
QmPOA7_882j1ubpM9Kq-YmOPP4R8wk9SD0bl0k222mSMUMMEZoiSVk7OSHPHkXj
v-IkXkMmKT0lZiRohdKanb-Dfa1GWXeFTKFSKKJUQibLQ2zy6jlBptIEkxQNrJe
F-96Ie08r93r79ZRs3lNegzhI6ShMot1YBiG5C-WiOvPw6zysh_-AIGbuvZ9hBn
nuNfeGr2VPPcO5Z0FKGYGJ0DDnwlNHkdztEj_xLzSZjMxeO6o2hVJScLzzyG_Fy
T2v2kUHv_qeal18x-ICLR3yyF6JzoT0zKYPouBEIM5EZNAX9A3UjG0kNWW4Lou9
dlbLIZm-T7H6kj89RATMbDCwHa-nsF2kmnTRR6djt7lzDU1CHEEcM83ZWxi9qTR
cN_YrCokMkSjZYI87GqmnYHFsTktBBMNDX0u9SBdDZSwmz4EPsn7blYFt6Oiyd-
EBJlE_ocI4desERjIj0vKsgCoa9ea46S4m_gPa8xlCHK9wcsXU0ZhH8Lo_PyLm0
4CnjAbhKV0g8WvupjRQijkA6WoqYxQCP9EsDWH7kHJxDWV0uXXFoPZkcW5DBWrG
1NUC4TAjjI-9qhW7bpBZTLZHDJ99Awsh5lBqPYwUoPMS-lx-FPv9pAEih0rdHdH
__PelgmXKSwsoBSXzS_ErzePKwTfMAqedpe4WVykQ1rOTRn3uW01sv5gfRBRpo.
PnWwSPZ6TWOHKQwCIIt1HcCLhXof1j4frx2IcLXjIQ0
]]></artwork>
</figure>
</t>
</section>
<section title="Using Password-Based Cryptography" anchor="pbcrypto">
<t>There are often times when a key is exchanged through immediate human interaction. To help facilitate such exchanges, a number of password-based cryptography schemes utilizing <xref target="RFC2898"/> are defined to supplement the key format and encryption algorithms from <xref target="JWA"/>.</t>
<section title="PBKDF2 Key Type" anchor="pbcrypto-pbkdf2-jwk">
<t>The "PBKDF2" key type is used to contain the parameters necessary to derive a cipher key from a password using the PBKDF2 algorithm from <xref target="RFC2898"/>. The following parameters are defined:</t>
<section title="'s' Parameter" anchor="pbcrypto-pbkdf2-jwk-S">
<t>The REQUIRED "s" parameter contains the PBKDF2 salt value (S), as a base64url encoded string (per <xref target="RFC4648"/>). This value MUST NOT be the empty string "".</t>
<t>The salt expands the possible keys that can be derived from a given password. <xref target="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 <xref target="RFC4086"/> for considerations on generating random values.</t>
</section>
<section title="'c' Parameter" anchor="pbcrypto-pbkdf2-jwk-c">
<t>The REQUIRED "c" parameter contains the PBKDF2 iteration count (c), as an integer. This value MUST NOT be less than 1, as per <xref target="RFC2898"/>.</t>
<t>The iteration count adds computational expense, ideally compounded by the possible range of keys introduced by the salt. <xref target="RFC2898"/> originally recommended a minimum iteration count of 1000.</t>
</section>
<section title="'hint' Parameter" anchor="pbcrypto-pbkdf2-jwk-hint">
<t>The OPTIONAL "hint" parameter contains a description clue to the password, as a string. If present, this value SHOULD NOT be the empty string "".</t>
<t>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.</t>
</section>
</section>
<section title="PBES2 Key Encryption Algorithms" anchor="pbcrypto-pbes2-jwe">
<t>The "PBES2-HS256+A128KW" and "PBES2-HS512+A256KW" algorithms defined below are used to encrypt a JWE Content Master Key using a user-supplied password to derive the key encryption key. With these algorithms, the derived key is used to encrypt the JWE Content Master Key. These algorithms combine a key derivation function with an encryption scheme to encrypt the JWE Content Master Key according to PBES2 from section 6.2 of <xref target="RFC2898"/>.</t>
<section title="PBES2-HS256+A128KW" anchor="pbcrypto-pbes2-jwe-hs256-a128kw">
<t>The "PBES2-HS256+A128KW" algorithm uses "HMAC-SHA256" as the PRF and "AES128-WRAP" as defined in <xref target="RFC3394"/> for the encryption scheme. The salt (S) and iteration count (c) MUST be specified by the "s" and "c" parameters (respectively) in the applicable "PBKDF2" JWK object. The derived-key length (dkLen) is 16 octets.</t>
</section>
<section title="PBES2-HS512+A256KW" anchor="pbcrypto-pbes2-jwe-hs512-a256kw">
<t>The "PBES2-HS512+A256KW" algorithm uses "HMAC-SHA512" as the PRF "and "AES256-WRAP" as defined in <xref target="RFC3394"/> for the encryption scheme. The salt (S) and iteration count (c) MUST be specified by the "s" and "c" parameters (respectively) in the applicable "PBKDF2" JWK object. The derived-key length (dkLen) is 32 octets.</t>
</section>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="JSON Web Key Types Registration" anchor="iana-jwk-types">
<t>This document registers the following to the JSON Web Key Types registry:</t>
<t>
<list style="symbols">
<t>"kty" Paramater value: "PBKDF2"<vspace blankLines="1"/></t>
<t>Implementation Requirements: OPTIONAL<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="pbcrypto-pbkdf2-jwk"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="JSON Web Key Parameters Registration" anchor="iana-jwk-params">
<t>This document registers the following to the JSON Web Key Parameters registry:</t>
<t>
<list style="symbols">
<t>Parameter Name: "s"<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="pbcrypto-pbkdf2-jwk-S"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
<t>
<list style="symbols">
<t>Parameter Name: "c"<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="pbcrypto-pbkdf2-jwk-c"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
<t>
<list style="symbols">
<t>Parameter Name: "hint"<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="pbcrypto-pbkdf2-jwk-hint"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="JSON Web Encryption Algorithms" anchor="iana-jwe-algs">
<t>This document registers the following to the JSON Web Encryption Algorithms registry:</t>
<t>
<list style="symbols">
<t>Algorithm Name: "PBES2-HS256+A128KW"<vspace blankLines="1"/></t>
<t>Algorithm Usage Location(s): "alg"</t>
<t>Implementation Requirements: OPTIONAL<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="pbcrypto-pbes2-jwe-hs256-a128kw"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
<t>
<list style="symbols">
<t>Algorithm Name: "PBES2-HS512+A256KW"<vspace blankLines="1"/></t>
<t>Algorithm Usage Location(s): "alg"</t>
<t>Implementation Requirements: OPTIONAL<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="pbcrypto-pbes2-jwe-hs512-a256kw"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<section title="Re-using Keying Material" anchor="security-reuse">
<t>It is NOT RECOMMENDED to re-use the same keying material (Key Encryption Key, Content Master Key, Initialization Vector, etc) to protect multiple JWK objects, or to protect the same JWK object multiple times. One suggestion for preventing re-use is to always generate a new set keying material for each protection operation, based on the considerations noted in this document as well as from <xref target="RFC4086"/>.</t>
</section>
<!--
<section title="Lifetime of Protected Keys" anchor="security-store">
<t>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). This lifetime can influence the factors used to protect the key; for a protected JWK that exists for as long as it takes to transit a network might use minimal-strength keys and algorithms, while longer term storage might necessitate stronger factors.</t>
</section>
-->
<section title="Password Considerations" anchor="security-pwd">
<t>While convenient for end users, passwords have many drawbacks. To help mitigate these limitations, this document applies principles from <xref target="RFC2898"/> to derive cryptographic keys from user-supplied passwords.</t>
<t>An ideal password is one that is as large (or larger) than the derived key length but less than the PRF's block size. Passwords larger than the PRF's block size are first hashed, which reduces an attacker's effective search space to the length of the hash algorithm (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.</t>
</section>
</section>
<section title="Internationalization Considerations" anchor="i18n">
<t>Passwords obtained from users are likely to require preparation and normalization to account for differences of octet sequences generated by different input devices, locales, etc. It is RECOMMENDED for applications to perform the steps outlined in <xref target="SASLPREP"/> to prepare a password supplied directly by a user before performing key derivation and encryption.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="JWA">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-algorithms-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-08.txt"/>
</reference>
<reference anchor="JWE">
<front>
<title>JSON Web Encryption (JWE)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<author initials="E." surname="Rescola" fullname="Eric Rescola">
<organization>RTFM, Inc.</organization>
<address>
<email>ekr@rtfm.com</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-encryption-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-08.txt"/>
</reference>
<reference anchor="JWK">
<front>
<title>JSON Web Key (JWK)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-key-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-08.txt"/>
</reference>
<reference anchor="JPSK">
<front>
<title>JSON Private and Symmetric Key</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-jones-jose-json-private-and-symmetric-key-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-jones-jose-json-private-and-symmetric-key-00.txt"/>
</reference>
<reference anchor="SASLPREP">
<front>
<title>Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="September" year="2012"/>
<abstract>
<t>This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-melnikov-precis-saslprepbis-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-melnikov-precis-saslprepbis-04.txt"/>
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>+1 617 495 3864</phone>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</t></list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC2898">
<front>
<title>Password-Based Cryptography Specification</title>
<author initials="B." surname="Kaliski" fullname="Burt Kaliski">
<organization>RSA Labratories</organization>
</author>
<date year="2000" month="September"/>
<abstract>
<t>This memo represents a republication of PKCS #5 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2898"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2898.txt"/>
</reference>
<reference anchor="RFC3394">
<front>
<title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title>
<author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization>Soaring Hawk Consulting</organization>
</author>
<author initials="R." surname="Housley" fullname="Russell Housley">
<organization>RSA Laboratories</organization>
</author>
<date year="2002" month="September"/>
<abstract>
<t>The purpose of this document is to make the Advanced Encryption Standard (AES) Key Wrap algorithm conveniently available to the Internet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES Key Wrap posted by NIST.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3394"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3394.txt"/>
</reference>
<reference anchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake 3rd">
<organization>Motorola Laboratories</organization>
<address>
<email>donald.eastlake@motorola.com</email>
</address>
</author>
<author initials="J." surname="Schiller" fullname="Jeffrey I. Schiller">
<organization>MIT, Room E30-311</organization>
<address>
<email>jis@mit.edu</email>
</address>
</author>
<author initials="S." surname="Crocker" fullname="Steve Crocker">
<organization/>
<address>
<email>steve@stevecrocker.com</email>
</address>
</author>
<date month="June" year="2005"/>
</front>
<seriesInfo name="RFC" value="4086"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc4086.txt"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization/>
</author>
<date year="2006" month="October"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<format type="TXT" octets="35491" target="http://www.ietf.org/rfc/rfc4648.txt"/>
</reference>
<reference anchor="RFC4949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials="R." surname="Shirey" fullname="R. Shirey">
<organization/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4949"/>
<format type="TXT" octets="867626" target="http://www.ietf.org/rfc/rfc4949.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="AES">
<front>
<title>Advanced Encryption Standard (AES)</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date month="November" year="2001"/>
</front>
<seriesInfo name="FIPS" value="PUB 197"/>
<format target="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf" type="PDF"/>
</reference>
<reference anchor="RFC3447">
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials="J." surname="Jonsson" fullname="Jakob Jonsson">
<organization>Philipps-Universitaet Marburg</organization>
</author>
<author initials="B." surname="Kaliski" fullname="Burt Kaliski">
<organization>RSA Labratories</organization>
</author>
<date year="2003" month="February"/>
<abstract>
<t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2898"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2898.txt"/>
</reference>
<reference anchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials="T." surname="Dierks" fullname="Tim Dierks"/>
<author initials="E." surname="Rescorla" fullname="Eric REscorla"/>
<date month="August" year="2008"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc5246"/>
</reference>
</references>
<section title="Acknowledgements" anchor="acknowledgements">
</section>
<section title="Document History" anchor="history">
<t>
<list style="hanging">
<t hangText="-01">
Incorporated changes suggested by Jim Schaad:<vspace blankLines="1"/>
<list style="symbols">
<t>Expanded the acronym "JSON" on first use.</t>
<t>Expanded the introduction to explain how this document's protection of symmetric keys differs from <xref target="JWE"/>.</t>
<t>Expanded the introduction to better explain why password-based encryption algorithms are needed.</t>
<t>Moved information on PBKDF2 salt from the security considerations to the "s" JWK parameter definition.</t>
<t>Moved information on PBKDF2 iteration count from security considerations to the "c" JWK parameter definition.</t>
<t>Added the "hint" JWK parameter.</t>
<t>Explicitly noted what registries are updated by the IANA considerations.</t>
<t>Relaxed language around re-use of keying material.</t>
<t>Removed section discussing protected key lifetimes.</t>
<t>Improved recommendations around password lengths.</t>
</list>
</t>
<t hangText="-00">Initial revision</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:06:22 |