One document matched: draft-barnes-jose-key-wrapping-01.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-barnes-jose-key-wrapping-01" category="info">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="JOSE Refactor">Proposed Refactoring of JOSE to Align Encryption and Key Wrapping</title>

    <author initials="R." surname="Barnes" fullname="Richard Barnes">
      <organization>BBN</organization>
      <address>
        
        
        <email>rlb@ipv.sx</email>
        
      </address>
    </author>

    <date year="2013" month="May" day="06"/>

    <area>Security</area>
    <workgroup>JOSE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The discussions around key wrapping in the JOSE working group have raised new requirements for wrapped keys, namely: (1) Wrapping keys other than symmetric keys, (2) cryptographically binding attributes to keys, and (3) allowing the use of AEAD cryptographic algorithms for key wrapping (other than AES-KW). This document proposes a refactoring of the JOSE document set that provides a cleaner conceptual structure for JWS / JWE and transparent support for wrapped keys, all with a relatively minor impact on the compact form of JWS and JWE objects.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The goal of a JOSE object is to provide the recipient with the result of a cryptographic operation (encryption, MAC, or signature) and instructions for how to process that result.  These instructutions are in two main parts: (1) A cryptographic algorithm to be applied, and (2) the key to be used with that algorithm (in wrapped form).  </t>

<t>The current structure of the JWE and JWS headers scatters these two information elements across several different header parameters.  JWE contains parameters for two different encryptions, the content encryption and the key encryption.  It would be simpler if these two encryptions could be handled in the same way.  Namely, the encrypted key within a JWE should become a JWE itself.  Thus, we make the following proposal:</t>

<t><list style='numbers'>
  <t>Define a simple, JWE-based format for wrapped keys.  This provides a consolidated format for wrapped keys, within JWE and without.</t>
  <t>Define the “recipients” parameter in JWE to be an array of JWE objects representeing wrapped keys.  </t>
  <t>Add a “kdf” parameter which is used to signal the use of a key derivation function such as ECDH or PBKDF2.  This takes the place of the “alg” parameter for ECDH, and is the natural way to include PBKDF2.  </t>
  <t>Adjust the mapping between the compact and JSON serializations to account for the above changes.  </t>
</list></t>

<t>These major changes will then drive several smaller, more editorial changes, including: </t>

<t><list style='symbols'>
  <t>Remove the “dir” value of the “alg” parameter.  The use of direct encryption is signalled by the lack of a “recipients” parameter with wrapped keys.</t>
  <t>Removing the “ECDH-ES+A128KW” value of the “alg” parameter, since this is specified jointly, e.g., by setting “enc” to “A128KW” and “kdf” to “ECDH-ES”.</t>
  <t>Combine “alg” and “enc” registries for JWE into a single registry, since the same set of algorithms can now be used for content encryption and key encryption.</t>
  <t>Remove the “alg” parameter from JWE.  It is no longer necessary, since the algorithm used for key wrapping is signalled in the “enc” parameter of the inner JWE.</t>
</list></t>

<t>This restructuring simplifies key wrapping, by using JWE for key wrapping.  Since the encrypted CMK is just another encrypted object, and because the wrapped key is encapsulated in the “key” object, JOSE implementations need only a single “unwrap” operation, instead of separate “JWE unwrap” and “key unwrap” operations.   </t>

<t>It also resolves the ambiguity that arises in the current JWE design as to what parameters should go in the overall header vs. per-recipient headers.  Namely, the parameters in the overall header relate to encryption of content, and parameters in per-recipient content relate to encryption of keys.</t>

<figure anchor="currentheader-enc-a128gcm-recipients-header-alg-a128kw-kid-1-encryptedkey-initializationvector-ciphertext-authenticationtag-proposedheader-enc-a128gcm-recipients-header-enc-a128kw-kid-1-ciphertext-initializationvector-ciphertext-authenticationtag-"><artwork><![CDATA[
CURRENT:
{
    "header": { "enc": "A128GCM" },
    "recipients:" [{
        "header": { "alg": "A128KW", "kid": "1" },
        "encrypted_key": "..."
    }],
    "initialization_vector": "...",
    "ciphertext": "...",
    "authentication_tag": "..."
}

PROPOSED:
{
    "header": { "enc": "A128GCM" },
    "recipients:" [{
        "header": { "enc": "A128KW", "kid": "1" },
        "ciphertext": "..."
    }],
    "initialization_vector": "...",
    "ciphertext": "...",
    "authentication_tag": "..."
}
]]></artwork></figure>

<t>This example shows how the change from the current syntax can be very minor.  The only change here is that the “enc” parameter is used for both the outer JWE and the inner JWE; the fact that direct encryption is being done in the inner JWE is apparent from the lack of a “recipients” parameter in the inner JWE.  The “encrypted_key” parameter is renamed “ciphertext” for compatibility with JWE.</t>

<t>This structure also provides a neat division of JWEs into “direct” and “indirect” modes.  If there is no “recipients” parameter, then the JWE is “direct”; no wrapped keys are provided.  If there is a “recipients” parameter, then the JWE is “indirect”; the recipient knows that it needs to unwrap the CEK before decrypting content.</t>

<t>This proposal also allows the use of AEAD algorithms for key wrapping [[NIST-SP800-38F]], without the need for special code for key encryption vs. content encryption.  For example, the following JWE object uses AES-GCM for key encryption:</t>

<figure anchor="header-enc-a128cbc-hs256-recipients-header-alga128gcm-kid1-initializationvector-ciphertext-authenticationtag-initializationvector-ciphertext-authenticationtag-"><artwork><![CDATA[
{
    "header": { "enc": "A128CBC-HS256" },
    "recipients": [{
        "header": { "alg":"A128GCM", "kid":"1" }
        "initialization_vector": "..."
        "ciphertext": "...",
        "authentication_tag": "..."
    }],
    "initialization_vector": "...",
    "ciphertext": "...",
    "authentication_tag": "..."
}
]]></artwork></figure>

<t>In the remainder of this document, we provide text for the proposed changes, in cases where text is not immediately clear: </t>

<t><list style='symbols'>
  <t>Part 1: Wrapped Key format</t>
  <t>Part 3: “kdf” (Key Derivation Function) Header Parameter</t>
  <t>Part 4: Changes to the compact serialization</t>
</list></t>

<t>We also provide a set of detailed examples that show the proposed changes affect the representation of JWE objects in several important cases.</t>

</section>
<section anchor="wrapped-key-format-1" title="Wrapped Key Format [1]">

<t>[[To be included in JWK]]</t>

<t>A wrapped key is a JWE object with a key as its payload.  If the key is a symmetric key with no attributes, it is express directly as an octet string; otherwise it is encoded in JSON as a JWK.  The processing of wrapped keys is identical to normal JWE processing, with two additional rules:</t>

<t><list style='numbers'>
  <t>If a wrapped key has no “cty” parameter, then its MUST be interpreted as the octets of a symmetric key.  That is, the payload is equivalent to a JWK with “kty” equal to “oct”, and “k” equal to the payload octets (base64url encoded).</t>
  <t>If a wrapped key contains something other than a bare symmetric key, then a “cty” attribute MUST be present to specify the type of the wrapped key.  For a JWK, the relevant “cty” value is “application/jwk+json”.</t>
</list></t>

</section>
<section anchor="kdf-key-derivation-function-parameter-3" title="“kdf” (Key Derivation Function) Parameter [3]">

<t>[[To be included in JWE]]</t>

<t>The “kdf” parameter indicates an algorithm that the recipient must apply to the the private key indicated in a JWE before it is used as an encryption key.  For example, the value “ECDH-ES” for the “kdf” parameter indicates that the recipient must use ECDH key agreement and the Concat KDF to derive the encryption key.  Likewise, a “PBKDF2” value for this parameter would indicate that the encryption key must be derived from the identified key by way of PBKDF2.</t>

<t>The “kdf” parameter MUST NOT be used in indirect mode.  Use of this header parameter is OPTIONAL.  This parameter MUST be understood by implementations.</t>

</section>
<section anchor="compact-form-4" title="Compact form [4]">

<t>[[To be included in JWE]]</t>

<t>The JWE compact form is a compact, URL-safe representation of a JWE JSON object.  In order to be compatible with the compact form, all top level header parametrs in the JSON-formatted JWE object MUST be protected.  Only the “protect” field is encoded; the “header” field is ignored.  All parameters in the JWE objects in the “recipients” object MUST be unprotected.  This section describes the transformation between the JSON and compact forms of a JWE object.</t>

<t>The translation from JSON form to compact form is as follows:</t>

<t><list style='numbers'>
  <t>Set the Encoded JWE Header to the value of the “protect” field</t>
  <t>If the “recipients” field is present, compute a Encoded JWE Key Header and Encoded JWE Encrypted Key for each recipient in the “recipients” field
  <list style='symbols'>
      <t>If the “initialization_vector” or “authentication_tag” fields are present in the JWE, add them to the “header” field</t>
      <t>Base64url encode the octets of the UTF-8 representation of the value of the “protect” field to create the Encoded JWE Key Header</t>
      <t>Set the Encoded JWE Encrypted Key to the value of the “ciphertext” field</t>
    </list></t>
  <t>Set the Encoded JWE Key Headers value to the concatenation of the Encoded JWE Key Header values, separated by the tilde (‘~’) character, in the same order as the “recipients” array</t>
  <t>Set the Encoded JWE Encrypted Keys value to the concatenation of the Encoded JWE Encrypted Key values, separated by the tilde (‘~’) character, in the same order as the “recipients” array</t>
  <t>Set the Encoded JWE Initialization Vector to be the value of the “initialization_vector” field</t>
  <t>Set the Encoded JWE Ciphertext to be the value of the “ciphertext” field</t>
  <t>Set the Encoded JWE AUthentication Tag to be the value of the “authentication_tag” field</t>
  <t>The compact form of the JWE is the concatenation of the following values, separated by five period (‘.’) characters.<vspace />
  <list style='symbols'>
      <t>Encoded JWE Header</t>
      <t>Encoded JWE Key Headers</t>
      <t>Encoded JWE Encrypted Keys</t>
      <t>Encoded JWE Initialization Vector</t>
      <t>Encoded JWE Ciphertext</t>
      <t>Encoded JWE Authentication Tag</t>
    </list></t>
</list></t>

<t>The translation from compact to JSON form is the reverse of this process.  First the compact object is split on the period (‘.’) character to obtain the six parts listed above.  If the Encoded JWE Key Headers and Encoded JWE Encrypted Keys segments are present, then they are split on the tilde (‘~’) character and used to reconstruct the “recipients” array.  (If these two segments have different numbers of entries, then the implementation MUST reject the object as having invalid syntax.)  </t>

<section anchor="sample-javascript-conversion-routines" title="Sample JavaScript Conversion Routines">

<t>The following JavaScript function code samples illustrate the process of converting between the compact and JSON encodings (actually, between compact form and a JavaScript object equivalent to the JSON form).  We make the following assumptions:</t>

<t><list style='symbols'>
  <t>PERIOD = ‘.’</t>
  <t>TILDE = ‘~’</t>
  <t>base64url_decode() and base64url_encode() perform their eponymous functions</t>
</list></t>

<figure anchor="function-jwejs2compactjwe-encode-per-recipient-information-if-present-var-keyheaders-var-encryptedkeys-if-jwerecipients-for-var-i0-i-jwerecipientslength-i-if-jwerecipientsiinitializationvector-jwerecipientsiheaderinitializationvectorjwerecipientsiinitializationvectorif-jwerecipientsiauthenticationtag-jwerecipientsiheaderauthenticationtagjwerecipientsiauthenticationtagkeyheaderspush-base64urlencodejsonstringify-jwerecipientsiheader-encryptedkeyspush-jwerecipientsiciphertext-return-jweprotectkeyheadersjointildeencryptedkeysjointildejweinitializationvector-jweciphertext-jweauthenticationtag-"><artwork><![CDATA[
function JWE_js2compact(jwe) {
  // Encode per-recipient information, if present 
  var keyHeaders = [];
  var encryptedKeys = [];
  if (jwe.recipients) {
    for (var i=0; i < jwe.recipients.length; ++i) {
      if (jwe.recipients[i].initialization_vector) {
        jwe.recipients[i].header.initialization_vector
          = jwe.recipients[i].initialization_vector;
      }
      if (jwe.recipients[i].authentication_tag) {
        jwe.recipients[i].header.authentication_tag
          = jwe.recipients[i].authentication_tag;
      }

      keyHeaders.push( base64url_encode(
        JSON.stringify( jwe.recipients[i].header ) ) );
      encryptedKeys.push( jwe.recipients[i].ciphertext );

    }
  }

  return  jwe.protect
  + "." + keyHeaders.join(TILDE)
  + "." + encryptedKeys.join(TILDE)
  + "." + (jwe.initialization_vector || "")
  + "." + (jwe.ciphertext || "")
  + "." + (jwe.authentication_tag || "");
}
]]></artwork></figure>

<figure anchor="function-jwecompact2jscompact-var-parts-compactsplitperiodif-partslength-6-throw-syntax-error-compact-form-must-have-6-componentsvar-jwe-protect-parts0initializationvector-parts3ciphertext-parts4authenticationtag-parts5reconstruct-per-recipient-information-if-presentif-parts1length-0-parts2length-0-keyheaders-parts1splittildeencryptedkeys-parts2splittildeif-keyheaderslength-encryptedkeyslength-throw-syntax-error-recipient-arrays-different-lengthsjwerecipients-for-var-i0-i-keyheaderslength-i-var-recipientjwe-var-header-jsonparse-base64urldecodekeyheadersi-if-initializationvector-in-header-recipientjweinitializationvector-headerinitializationvectordelete-headerinitializationvectorif-authenticationtag-in-header-recipientjweauthenticationtag-headerauthenticationtagdelete-headerauthenticationtagrecipientjweheader-headerrecipientjweciphertext-encryptedkeysijwerecipientspushrecipientjwereturn-jwe"><artwork><![CDATA[
function JWE_compact2js(compact) {
  var parts = compact.split(PERIOD);
  if (parts.length != 6) {
    throw "Syntax error: compact form must have 6 components";
  }

  var jwe = {
    "protect": parts[0],
    "initialization_vector": parts[3],
    "ciphertext": parts[4],
    "authentication_tag": parts[5]
  };

  // Reconstruct per-recipient information, if present
  if (parts[1].length > 0 && parts[2].length > 0) {
    keyHeaders = parts[1].split(TILDE);
    encryptedKeys = parts[2].split(TILDE);
    if (keyHeaders.length != encryptedKeys.length) {
      throw "Syntax error: recipient arrays different lengths";
    }

    jwe.recipients = [];
    for (var i=0; i < keyHeaders.length; ++i) {
      var recipientJWE = {};
      var header = JSON.parse( base64url_decode(keyHeaders[i]) );
      if ("initialization_vector" in header) {
        recipientJWE.initialization_vector = 
          header.initialization_vector;
        delete header["initialization_vector"];
      }
      if ("authentication_tag" in header) {
        recipientJWE.authentication_tag =
          header.authentication_tag;
        delete header["authentication_tag"];
      }
      recipientJWE.header = header;
      recipientJWE.ciphertext = encryptedKeys[i];
      jwe.recipients.push(recipientJWE);
    }
  }

  return jwe;
}
]]></artwork></figure>

</section>
</section>
<section anchor="detailed-examples" title="Detailed Examples">

<t>In this section, we present detailed examples for several important use cases.  Note that binary values in this section are not generated using the indicated cryptographic algorithms; rather, they are randomly generated strings of appropriate length.  Line breaks and white space are for readability only.  </t>

<t>In the provided compact forms, we have assumed that all top-level header parameters are moved to the “protect” field from the “header” field.</t>

<section anchor="rsa-direct" title="RSA Direct">

<figure anchor="header-enc-rsa-oaep-kid-1-ciphertext-badblwefcivagcgxekpm3yucmldtqyt8z6bkdasr6pufflzhtxinrthq9jwsvlwy1ignmj8afgz3akf-mhl1f90gt2er-pon3ekl8pt19hkzngurkowez5b6mxsvoig95zfnj4wgky6cd-gahcmijsbm8be6hgl0lilray1a0uw"><artwork><![CDATA[
{
    "header": { 
        "enc": "RSA-OAEP", 
        "kid": "1" 
    },
    "ciphertext": "badbLWEFcivAgcGXeKpm3YuCmldtqy
        t8Z6BkdaSR6PufFlzhTXINRthq9jwSVLWY1iGnMj8
        afGZ3AkF-mhl1f90Gt2ER-PON3eKL8pt19HkZnGUr
        koWeZ5b6mXSvOIg95zfnj4wgkY6CD-GahCMIjSBm8
        BE6HgL0liLrAy1A0uw"
}
]]></artwork></figure>

<t>The recipient can recognize that direct encryption is being done by the lack of a “recipient” parameter.  The recipient then uses the private key corresponding to the “kid” parameter to decrypt the ciphertext using RSA-OAEP.</t>

<t>The compact form of this JWE is 214 octets long</t>

<figure anchor="eyjlbmmioijsu0ett0ffucisimtpzci6ijeifqbadblwefcivagcgxekpm3yucmldtqyt8z6bkdasr6pufflzhtxinrthq9jwsvlwy1ignmj8afgz3akf-mhl1f90gt2er-ponekl8pt19hkzngurkowez5b6mxsvoig95zfnj4wgky6cd-gahcmijsbm8be6hgl0lilray1a0uw"><artwork><![CDATA[
 eyJlbmMiOiJSU0EtT0FFUCIsImtpZCI6IjEifQ
.
.
.
.badbLWEFcivAgcGXeKpm3YuCmldtqyt8Z6BkdaSR6PufFlzh
 TXINRthq9jwSVLWY1iGnMj8afGZ3AkF-mhl1f90Gt2ER-PON
 3eKL8pt19HkZnGUrkoWeZ5b6mXSvOIg95zfnj4wgkY6CD-Ga
 hCMIjSBm8BE6HgL0liLrAy1A0uw
.
]]></artwork></figure>

</section>
<section anchor="direct-encryption-with-a-symmetric-algorithm" title="Direct Encryption with a Symmetric Algorithm">

<figure anchor="header-enc-a128gcm-kid-1-initializationvector-drdectjt3255qkjrpvzvsa-ciphertext-urgfnoogcs7mnonzppzsojlrmxuzb96d-authenticationtag-66z3o-arcjmcmtbghdveaa"><artwork><![CDATA[
{
    "header": { 
        "enc": "A128GCM", 
        "kid": "1" 
    },
    "initialization_vector": "dRdeCTjt3255QKjrpvZVsA", 
    "ciphertext": "uRgFnOogcs7MnOnzPpzsojlrMXuZb96D", 
    "authentication_tag": "66Z3o-ArcjmCMtbGhDVEaA"
}
]]></artwork></figure>

<t>The recipient can recognize that direct encryption is being done by the lack of a “recipient” parameter.  The recipient then uses the symmetric key identified by the “kid” parameter to decrypt the ciphertext using AES-GCM.</t>

<t>The compact form of this JWE is 117 octets long</t>

<figure anchor="eyjlbmmioijbmti4r0nniiwia2lkijoimsj9drdectjt3255qkjrpvzvsaurgfnoogcs7mnonzppzsojlrmxuzb96dz3o-arcjmcmtbghdveaa"><artwork><![CDATA[
 eyJlbmMiOiJBMTI4R0NNIiwia2lkIjoiMSJ9
.
.
.dRdeCTjt3255QKjrpvZVsA
.uRgFnOogcs7MnOnzPpzsojlrMXuZb96D
.66Z3o-ArcjmCMtbGhDVEaA
]]></artwork></figure>

</section>
<section anchor="direct-symmetric-encryption-with-an-ecdh-derived-key" title="Direct Symmetric Encryption with an ECDH-derived key">

<figure anchor="header-enc-a128gcmkdf-ecdhkid-1-epk-ktyeccrvp-256xmkbctnickusdii11yss3526idz8aito7tu6kpaqv7d4y4etl6srw2yilurn5vfvvhuhp7x8pxltmwwlbbm4ifymapu-vablqlyrdfqdstcg8zcj0ea9huclh2k4ycezuvj3qxrmdureuhcpqfua7hcxmaxtoax4uo6-p6rmnfivsa-initializationvector-drdectjt3255qkjrpvzvsa-ciphertext-urgfnoogcs7mnonzppzsojlrmxuzb96d-authenticationtag-66z3o-arcjmcmtbghdveaa"><artwork><![CDATA[
{
    "header": { 
        "enc": "A128GCM",
        "kdf": "ECDH",
        "kid": "1", 
        "epk": { 
            "kty":"EC",
            "crv":"P-256",
            "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
            "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM"
        }, 
        "apu": "VaBLqlyRDFQdstcg8ZcJ0ea9hUC_LH2K4YCezuVj3qx_rM_
                DurEUHC_PqFUA7HcXmaxtOax4uO6-p6rmNFIvSA" 
    },
    "initialization_vector": "dRdeCTjt3255QKjrpvZVsA", 
    "ciphertext": "uRgFnOogcs7MnOnzPpzsojlrMXuZb96D", 
    "authentication_tag": "66Z3o-ArcjmCMtbGhDVEaA"
}
]]></artwork></figure>

<t>The recipient can recognize that direct encryption is being done by the lack of a “recipient” parameter.  The presence of the “kdf” parameter indicates the need to derive a CEK from the shared secret identified by the “kid” value (in this case, an ECDH private key).  The recipient combines the identified private key with the ephemeral ECDH public key in the “epk” parameter to obtain a shared secret ZZ.  The shared secret ZZ is then combined with the information in the “apu” field and used with the Concat KDF to derive the encryption key.  Finally, the recipient uses the derived encryption key to decrypt the content using AES-GCM.</t>

<t>The compact form of this JWE is 439 octets long</t>

<figure anchor="eyjlbmmioijbmti4r0nniiwia2rmijoirunescisimtpzci6ijeilcjlcgsionsia3r5ijoirumilcjjcnyioijqlti1niisingioijns0jdve5jy0tvu0rpatexevnzmzuynmlewjhbavrvn1r1nktqqxf2n0q0iiwiesi6ijrfdgw2u1jxmllptfvytjv2znzwshvocdd4ofb4bhrtv1dsymjnnelgeu0ifswiyxb1ijoivmfcthfsevjerlfkc3rjzzhay0owzwe5afvdx0ximks0wunlenvwajnxef9ytv9edxjfvuhdx1bxrlvbn0hjwg1hehrpyxg0du82lxa2cm1orkl2u0eifqdrdectjt3255qkjrpvzvsaurgfnoogcs7mnonzppzsojlrmxuzb96dz3o-arcjmcmtbghdveaa"><artwork><![CDATA[
 eyJlbmMiOiJBMTI4R0NNIiwia2RmIjoiRUNESCIsImtpZCI6
 IjEiLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIs
 IngiOiJNS0JDVE5JY0tVU0RpaTExeVNzMzUyNmlEWjhBaVRv
 N1R1NktQQXF2N0Q0IiwieSI6IjRFdGw2U1JXMllpTFVyTjV2
 ZnZWSHVocDd4OFB4bHRtV1dsYmJNNElGeU0ifSwiYXB1Ijoi
 VmFCTHFseVJERlFkc3RjZzhaY0owZWE5aFVDX0xIMks0WUNl
 enVWajNxeF9yTV9EdXJFVUhDX1BxRlVBN0hjWG1heHRPYXg0
 dU82LXA2cm1ORkl2U0EifQ
.
.
.dRdeCTjt3255QKjrpvZVsA
.uRgFnOogcs7MnOnzPpzsojlrMXuZb96D
.66Z3o-ArcjmCMtbGhDVEaA
]]></artwork></figure>

</section>
<section anchor="indirect-encryption-with-an-aes-wrapped-key" title="Indirect Encryption with an AES-wrapped Key">

<figure anchor="header-enc-a128gcmrecipients-header-enc-a128kwkid-1ciphertext-a8nmmwxkxqcw8uyqsnch6mdakoudqjiinitializationvector-drdectjt3255qkjrpvzvsa-ciphertext-urgfnoogcs7mnonzppzsojlrmxuzb96d-authenticationtag-66z3o-arcjmcmtbghdveaa"><artwork><![CDATA[
{
    "header": {
        "enc": "A128GCM",
    },
    "recipients": [{
        "header": {
            "enc": "A128KW",
            "kid": "1"
        },
        "ciphertext": "A8nMMWXKxQCw8UYQsNCH6_mdAKOUDqJI"
    }],
    "initialization_vector": "dRdeCTjt3255QKjrpvZVsA", 
    "ciphertext": "uRgFnOogcs7MnOnzPpzsojlrMXuZb96D", 
    "authentication_tag": "66Z3o-ArcjmCMtbGhDVEaA"
}
]]></artwork></figure>

<t>The recipient can recognize by the presence of the “recipients” header that indirect encryption is being used, and thus that it needs to decrypt the CEK from one of the wrapped keys in the “recipients” array.  Assuming the recipient has access to the identified symmetric key, it decrypts the encrypted key and uses it to decrypt the content using AES-GCM. </t>

<t>The compact form of this JWE is 171 octets long</t>

<figure anchor="eyjlbmmioijbmti4r0nnin0eyjlbmmioijbmti4s1cilcjrawqioiixin0a8nmmwxkxqcw8uyqsnch6mdakoudqjidrdectjt3255qkjrpvzvsaurgfnoogcs7mnonzppzsojlrmxuzb96dz3o-arcjmcmtbghdveaa"><artwork><![CDATA[
eyJlbmMiOiJBMTI4R0NNIn0
.eyJlbmMiOiJBMTI4S1ciLCJraWQiOiIxIn0
.A8nMMWXKxQCw8UYQsNCH6_mdAKOUDqJI
.dRdeCTjt3255QKjrpvZVsA
.uRgFnOogcs7MnOnzPpzsojlrMXuZb96D
.66Z3o-ArcjmCMtbGhDVEaA
]]></artwork></figure>

</section>
<section anchor="indirect-encryption-with-rsa-and-ecdh-wrapped-keys" title="Indirect Encryption with RSA- and ECDH-Wrapped Keys">

<figure anchor="header-enc-a128gcm-recipients-header-enc-rsa-oaep-kid-1-ciphertext-badblwefcivagcgxekpm3yucmldtqyt8z6bkdasr6pufflzhtxinrthq9jwsvlwy1ignmj8afgz3akf-mhl1f90gt2er-pon3ekl8pt19hkzngurkowez5b6mxsvoig95zfnj4wgky6cd-gahcmijsbm8be6hgl0lilray1a0uwheader-enc-a128kwkdf-ecdhkid-1-epk-ktyeccrvp-256xmkbctnickusdii11yss3526idz8aito7tu6kpaqv7d4y4etl6srw2yilurn5vfvvhuhp7x8pxltmwwlbbm4ifymapu-vablqlyrdfqdstcg8zcj0ea9huclh2k4ycezuvj3qxrmdureuhcpqfua7hcxmaxtoax4uo6-p6rmnfivsa-ciphertext-a8nmmwxkxqcw8uyqsnch6mdakoudqjiinitializationvector-drdectjt3255qkjrpvzvsa-ciphertext-urgfnoogcs7mnonzppzsojlrmxuzb96d-authenticationtag-66z3o-arcjmcmtbghdveaa"><artwork><![CDATA[
{
    "header": {
        "enc": "A128GCM"       
    },
    "recipients": [{
        "header": { 
            "enc": "RSA-OAEP", 
            "kid": "1" 
        },
        "ciphertext": "badbLWEFcivAgcGXeKpm3YuCmldtqy
            t8Z6BkdaSR6PufFlzhTXINRthq9jwSVLWY1iGnMj8
            afGZ3AkF-mhl1f90Gt2ER-PON3eKL8pt19HkZnGUr
            koWeZ5b6mXSvOIg95zfnj4wgkY6CD-GahCMIjSBm8
            BE6HgL0liLrAy1A0uw"
    },{
        "header": {
            "enc": "A128KW",
            "kdf": "ECDH",
            "kid": "1", 
            "epk": { 
                "kty":"EC",
                "crv":"P-256",
                "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
                "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM"
            }, 
            "apu": "VaBLqlyRDFQdstcg8ZcJ0ea9hUC_LH2K4YCezuVj3qx_rM_
                    DurEUHC_PqFUA7HcXmaxtOax4uO6-p6rmNFIvSA" 
        },
        "ciphertext": "A8nMMWXKxQCw8UYQsNCH6_mdAKOUDqJI"
    }],
    "initialization_vector": "dRdeCTjt3255QKjrpvZVsA", 
    "ciphertext": "uRgFnOogcs7MnOnzPpzsojlrMXuZb96D", 
    "authentication_tag": "66Z3o-ArcjmCMtbGhDVEaA"
}
]]></artwork></figure>

<t>The recipient can recognize by the presence of the “recipients” header that indirect encryption is being used, and thus that it needs to decrypt the CEK from one of the wrapped keys in the “recipients” array.  Assuming the recipient has the private key corresponding to the identified RSA or ECDH keys, it processes the corresponding wrapped key object as a direct JWE to decrypt the CEK.  The recipient then uses the CEK to decrypt the content using AES-GCM.</t>

<t>The compact form of this JWE is 703 octets long</t>

<figure anchor="eyjlbmmioijbmti4r0nnin0eyjlbmmioijsu0ett0ffucisimtpzci6ijeifqeyjlbmmioijbmti4s1cilcjrzgyioijfq0riiiwia2lkijoimsisimvwayi6eyjrdhkioijfqyisimnydii6ilatmju2iiwieci6ik1lqknutkljs1vtrglpmtf5u3mznti2auraoefpvg83vhu2s1bbcxy3rdqilcj5ijoinev0bdztulcywwlmvxjonxzmdlzidwhwn3g4uhhsdg1xv2xiyk00suz5tsj9lcjhchuioijwyujmcwx5ukrguwrzdgnnofpjsjblytlovunftegyszrzq2v6dvzqm3f4x3jnx0r1ckvvsenfuhfgvue3sgnybwf4de9hedr1tzytcdzybu5gsxztqsj9badblwefcivagcgxekpm3yucmldtqyt8z6bkdasr6pufflzhtxinrthq9jwsvlwy1ignmj8afgz3akf-mhl1f90gt2er-ponekl8pt19hkzngurkowez5b6mxsvoig95zfnj4wgky6cd-gahcmijsbm8be6hgl0lilray1a0uwa8nmmwxkxqcw8uyqsnch6mdakoudqjidrdectjt3255qkjrpvzvsaurgfnoogcs7mnonzppzsojlrmxuzb96dz3o-arcjmcmtbghdveaa"><artwork><![CDATA[
eyJlbmMiOiJBMTI4R0NNIn0
.eyJlbmMiOiJSU0EtT0FFUCIsImtpZCI6IjEifQ
~eyJlbmMiOiJBMTI4S1ciLCJrZGYiOiJFQ0RIIiwia2lkIjoi
 MSIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwi
 eCI6Ik1LQkNUTkljS1VTRGlpMTF5U3MzNTI2aURaOEFpVG83
 VHU2S1BBcXY3RDQiLCJ5IjoiNEV0bDZTUlcyWWlMVXJONXZm
 dlZIdWhwN3g4UHhsdG1XV2xiYk00SUZ5TSJ9LCJhcHUiOiJW
 YUJMcWx5UkRGUWRzdGNnOFpjSjBlYTloVUNfTEgySzRZQ2V6
 dVZqM3F4X3JNX0R1ckVVSENfUHFGVUE3SGNYbWF4dE9heDR1
 TzYtcDZybU5GSXZTQSJ9
.badbLWEFcivAgcGXeKpm3YuCmldtqyt8Z6BkdaSR6PufFlzh
 TXINRthq9jwSVLWY1iGnMj8afGZ3AkF-mhl1f90Gt2ER-PON
 3eKL8pt19HkZnGUrkoWeZ5b6mXSvOIg95zfnj4wgkY6CD-Ga
 hCMIjSBm8BE6HgL0liLrAy1A0uw
~A8nMMWXKxQCw8UYQsNCH6_mdAKOUDqJI
.dRdeCTjt3255QKjrpvZVsA
.uRgFnOogcs7MnOnzPpzsojlrMXuZb96D
.66Z3o-ArcjmCMtbGhDVEaA
]]></artwork></figure>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The refactoring proposed in this document has several security benefits.</t>

<t>First, by using the JWE format for wrapped keys in JWE, JWE can benefit from general AEAD algorithms for key wrapping, for example, AES-GCM as opposed to AES key wrap.  These other AEAD algorithms are more widely available than AES key wrap, and offer better security properties in some situations.  This benefit is available to the compact serialization as well as the revised JSON format.</t>

<t>Second, by using the same format for key encryption and content encryption, code for processing objects in the proposed format will only have to have support one way of decrypting objects.  This simplification will reduce the chance for bugs in implementations.</t>

<t>Third, the use of consolidated algorithm and key objects allows for simpler validation rules on JOSE objects, again reducing the chance that an improperly-constructed JOSE object will be able to trigger implementation bugs.</t>

<t>There are two areas where this proposal might require increased caution by applications.  The first is in the choice of JWE mode, direct vs. indirect.  The revised JWE specification should emphasize that indirect-mode JWE is much more secure, because attackers have to break two levels of encryption to access long-lived keys, instead of just one.</t>

<t>The second area of concern is the selection of algorithms.  The security considerations in the revised JWE specification should note that applications that use indirect JWEs should choose different algorithms for key encryption and content encryption.  That way, an attacker must compromise two different algorithms in order to mis-use a JWE object.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This memo makes no request of IANA.  However, changes to the JOSE specs resulting from this proposal might require adjustments to some IANA registrations.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='I-D.ietf-jose-json-web-encryption'>
<front>
<title>JSON Web Encryption (JWE)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
    <organization />
</author>

<date month='December' day='28' year='2012' />

<abstract><t>JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification.  Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification.</t></abstract>

</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' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-08.pdf' />
</reference>



<reference anchor='I-D.ietf-jose-json-web-signature'>
<front>
<title>JSON Web Signature (JWS)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<author initials='J' surname='Bradley' fullname='John Bradley'>
    <organization />
</author>

<author initials='N' surname='Sakimura' fullname='Nat Sakimura'>
    <organization />
</author>

<date month='December' day='28' year='2012' />

<abstract><t>JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-jose-json-web-signature-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-08.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-08.pdf' />
</reference>



<reference anchor='I-D.ietf-jose-json-web-algorithms'>
<front>
<title>JSON Web Algorithms (JWA)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<date month='December' day='28' year='2012' />

<abstract><t>The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.</t></abstract>

</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' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-08.pdf' />
</reference>



<reference anchor='I-D.ietf-jose-json-web-key'>
<front>
<title>JSON Web Key (JWK)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<date month='December' day='28' year='2012' />

<abstract><t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a public key.  This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification.</t></abstract>

</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' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-08.pdf' />
</reference>




    </references>




  </back>
</rfc>