JOSE Working Group R. Barnes Internet-Draft BBN Intended status: Informational May 06, 2013 Expires: November 7, 2013 Proposed Refactoring of JOSE to Align Encryption and Key Wrapping draft-barnes-jose-key-wrapping-01 Abstract 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 7, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Barnes Expires November 7, 2013 [Page 1] Internet-Draft JOSE Refactor May 2013 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Wrapped Key Format [1] . . . . . . . . . . . . . . . . . . . . 6 3. "kdf" (Key Derivation Function) Parameter [3] . . . . . . . . 7 4. Compact form [4] . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Sample JavaScript Conversion Routines . . . . . . . . . . 9 5. Detailed Examples . . . . . . . . . . . . . . . . . . . . . . 12 5.1. RSA Direct . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Direct Encryption with a Symmetric Algorithm . . . . . . . 13 5.3. Direct Symmetric Encryption with an ECDH-derived key . . . 14 5.4. Indirect Encryption with an AES-wrapped Key . . . . . . . 15 5.5. Indirect Encryption with RSA- and ECDH-Wrapped Keys . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Normative References . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Barnes Expires November 7, 2013 [Page 2] Internet-Draft JOSE Refactor May 2013 1. Introduction 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). 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: 1. Define a simple, JWE-based format for wrapped keys. This provides a consolidated format for wrapped keys, within JWE and without. 2. Define the "recipients" parameter in JWE to be an array of JWE objects representeing wrapped keys. 3. 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. 4. Adjust the mapping between the compact and JSON serializations to account for the above changes. These major changes will then drive several smaller, more editorial changes, including: o 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. o 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". o 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. o Remove the "alg" parameter from JWE. It is no longer necessary, since the algorithm used for key wrapping is signalled in the Barnes Expires November 7, 2013 [Page 3] Internet-Draft JOSE Refactor May 2013 "enc" parameter of the inner JWE. 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. 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. 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": "..." } Figure 1 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. This structure also provides a neat division of JWEs into "direct" Barnes Expires November 7, 2013 [Page 4] Internet-Draft JOSE Refactor May 2013 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. 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: { "header": { "enc": "A128CBC-HS256" }, "recipients": [{ "header": { "alg":"A128GCM", "kid":"1" } "initialization_vector": "..." "ciphertext": "...", "authentication_tag": "..." }], "initialization_vector": "...", "ciphertext": "...", "authentication_tag": "..." } Figure 2 In the remainder of this document, we provide text for the proposed changes, in cases where text is not immediately clear: o Part 1: Wrapped Key format o Part 3: "kdf" (Key Derivation Function) Header Parameter o Part 4: Changes to the compact serialization We also provide a set of detailed examples that show the proposed changes affect the representation of JWE objects in several important cases. Barnes Expires November 7, 2013 [Page 5] Internet-Draft JOSE Refactor May 2013 2. Wrapped Key Format [1] [[To be included in JWK]] 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: 1. 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). 2. 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". Barnes Expires November 7, 2013 [Page 6] Internet-Draft JOSE Refactor May 2013 3. "kdf" (Key Derivation Function) Parameter [3] [[To be included in JWE]] 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. The "kdf" parameter MUST NOT be used in indirect mode. Use of this header parameter is OPTIONAL. This parameter MUST be understood by implementations. Barnes Expires November 7, 2013 [Page 7] Internet-Draft JOSE Refactor May 2013 4. Compact form [4] [[To be included in JWE]] 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. The translation from JSON form to compact form is as follows: 1. Set the Encoded JWE Header to the value of the "protect" field 2. If the "recipients" field is present, compute a Encoded JWE Key Header and Encoded JWE Encrypted Key for each recipient in the "recipients" field * If the "initialization_vector" or "authentication_tag" fields are present in the JWE, add them to the "header" field * Base64url encode the octets of the UTF-8 representation of the value of the "protect" field to create the Encoded JWE Key Header * Set the Encoded JWE Encrypted Key to the value of the "ciphertext" field 3. 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 4. 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 5. Set the Encoded JWE Initialization Vector to be the value of the "initialization_vector" field 6. Set the Encoded JWE Ciphertext to be the value of the "ciphertext" field 7. Set the Encoded JWE AUthentication Tag to be the value of the "authentication_tag" field Barnes Expires November 7, 2013 [Page 8] Internet-Draft JOSE Refactor May 2013 8. The compact form of the JWE is the concatenation of the following values, separated by five period ('.') characters. * Encoded JWE Header * Encoded JWE Key Headers * Encoded JWE Encrypted Keys * Encoded JWE Initialization Vector * Encoded JWE Ciphertext * Encoded JWE Authentication Tag 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.) 4.1. Sample JavaScript Conversion Routines 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: o PERIOD = '.' o TILDE = '~' o base64url_decode() and base64url_encode() perform their eponymous functions Barnes Expires November 7, 2013 [Page 9] Internet-Draft JOSE Refactor May 2013 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 || ""); } Figure 3 Barnes Expires November 7, 2013 [Page 10] Internet-Draft JOSE Refactor May 2013 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; } Figure 4 Barnes Expires November 7, 2013 [Page 11] Internet-Draft JOSE Refactor May 2013 5. Detailed Examples 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. In the provided compact forms, we have assumed that all top-level header parameters are moved to the "protect" field from the "header" field. 5.1. RSA Direct { "header": { "enc": "RSA-OAEP", "kid": "1" }, "ciphertext": "badbLWEFcivAgcGXeKpm3YuCmldtqy t8Z6BkdaSR6PufFlzhTXINRthq9jwSVLWY1iGnMj8 afGZ3AkF-mhl1f90Gt2ER-PON3eKL8pt19HkZnGUr koWeZ5b6mXSvOIg95zfnj4wgkY6CD-GahCMIjSBm8 BE6HgL0liLrAy1A0uw" } Figure 5 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. The compact form of this JWE is 214 octets long eyJlbmMiOiJSU0EtT0FFUCIsImtpZCI6IjEifQ . . . .badbLWEFcivAgcGXeKpm3YuCmldtqyt8Z6BkdaSR6PufFlzh TXINRthq9jwSVLWY1iGnMj8afGZ3AkF-mhl1f90Gt2ER-PON 3eKL8pt19HkZnGUrkoWeZ5b6mXSvOIg95zfnj4wgkY6CD-Ga hCMIjSBm8BE6HgL0liLrAy1A0uw . Figure 6 Barnes Expires November 7, 2013 [Page 12] Internet-Draft JOSE Refactor May 2013 5.2. Direct Encryption with a Symmetric Algorithm { "header": { "enc": "A128GCM", "kid": "1" }, "initialization_vector": "dRdeCTjt3255QKjrpvZVsA", "ciphertext": "uRgFnOogcs7MnOnzPpzsojlrMXuZb96D", "authentication_tag": "66Z3o-ArcjmCMtbGhDVEaA" } Figure 7 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. The compact form of this JWE is 117 octets long eyJlbmMiOiJBMTI4R0NNIiwia2lkIjoiMSJ9 . . .dRdeCTjt3255QKjrpvZVsA .uRgFnOogcs7MnOnzPpzsojlrMXuZb96D .66Z3o-ArcjmCMtbGhDVEaA Figure 8 Barnes Expires November 7, 2013 [Page 13] Internet-Draft JOSE Refactor May 2013 5.3. Direct Symmetric Encryption with an ECDH-derived key { "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" } Figure 9 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. The compact form of this JWE is 439 octets long Barnes Expires November 7, 2013 [Page 14] Internet-Draft JOSE Refactor May 2013 eyJlbmMiOiJBMTI4R0NNIiwia2RmIjoiRUNESCIsImtpZCI6 IjEiLCJlcGsiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIs IngiOiJNS0JDVE5JY0tVU0RpaTExeVNzMzUyNmlEWjhBaVRv N1R1NktQQXF2N0Q0IiwieSI6IjRFdGw2U1JXMllpTFVyTjV2 ZnZWSHVocDd4OFB4bHRtV1dsYmJNNElGeU0ifSwiYXB1Ijoi VmFCTHFseVJERlFkc3RjZzhaY0owZWE5aFVDX0xIMks0WUNl enVWajNxeF9yTV9EdXJFVUhDX1BxRlVBN0hjWG1heHRPYXg0 dU82LXA2cm1ORkl2U0EifQ . . .dRdeCTjt3255QKjrpvZVsA .uRgFnOogcs7MnOnzPpzsojlrMXuZb96D .66Z3o-ArcjmCMtbGhDVEaA Figure 10 5.4. Indirect Encryption with an AES-wrapped Key { "header": { "enc": "A128GCM", }, "recipients": [{ "header": { "enc": "A128KW", "kid": "1" }, "ciphertext": "A8nMMWXKxQCw8UYQsNCH6_mdAKOUDqJI" }], "initialization_vector": "dRdeCTjt3255QKjrpvZVsA", "ciphertext": "uRgFnOogcs7MnOnzPpzsojlrMXuZb96D", "authentication_tag": "66Z3o-ArcjmCMtbGhDVEaA" } Figure 11 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. The compact form of this JWE is 171 octets long Barnes Expires November 7, 2013 [Page 15] Internet-Draft JOSE Refactor May 2013 eyJlbmMiOiJBMTI4R0NNIn0 .eyJlbmMiOiJBMTI4S1ciLCJraWQiOiIxIn0 .A8nMMWXKxQCw8UYQsNCH6_mdAKOUDqJI .dRdeCTjt3255QKjrpvZVsA .uRgFnOogcs7MnOnzPpzsojlrMXuZb96D .66Z3o-ArcjmCMtbGhDVEaA Figure 12 5.5. Indirect Encryption with RSA- and ECDH-Wrapped Keys { "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" } Figure 13 Barnes Expires November 7, 2013 [Page 16] Internet-Draft JOSE Refactor May 2013 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. The compact form of this JWE is 703 octets long eyJlbmMiOiJBMTI4R0NNIn0 .eyJlbmMiOiJSU0EtT0FFUCIsImtpZCI6IjEifQ ~eyJlbmMiOiJBMTI4S1ciLCJrZGYiOiJFQ0RIIiwia2lkIjoi MSIsImVwayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwi eCI6Ik1LQkNUTkljS1VTRGlpMTF5U3MzNTI2aURaOEFpVG83 VHU2S1BBcXY3RDQiLCJ5IjoiNEV0bDZTUlcyWWlMVXJONXZm dlZIdWhwN3g4UHhsdG1XV2xiYk00SUZ5TSJ9LCJhcHUiOiJW YUJMcWx5UkRGUWRzdGNnOFpjSjBlYTloVUNfTEgySzRZQ2V6 dVZqM3F4X3JNX0R1ckVVSENfUHFGVUE3SGNYbWF4dE9heDR1 TzYtcDZybU5GSXZTQSJ9 .badbLWEFcivAgcGXeKpm3YuCmldtqyt8Z6BkdaSR6PufFlzh TXINRthq9jwSVLWY1iGnMj8afGZ3AkF-mhl1f90Gt2ER-PON 3eKL8pt19HkZnGUrkoWeZ5b6mXSvOIg95zfnj4wgkY6CD-Ga hCMIjSBm8BE6HgL0liLrAy1A0uw ~A8nMMWXKxQCw8UYQsNCH6_mdAKOUDqJI .dRdeCTjt3255QKjrpvZVsA .uRgFnOogcs7MnOnzPpzsojlrMXuZb96D .66Z3o-ArcjmCMtbGhDVEaA Figure 14 Barnes Expires November 7, 2013 [Page 17] Internet-Draft JOSE Refactor May 2013 6. Security Considerations The refactoring proposed in this document has several security benefits. 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. 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. 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. 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. 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. Barnes Expires November 7, 2013 [Page 18] Internet-Draft JOSE Refactor May 2013 7. IANA Considerations This memo makes no request of IANA. However, changes to the JOSE specs resulting from this proposal might require adjustments to some IANA registrations. Barnes Expires November 7, 2013 [Page 19] Internet-Draft JOSE Refactor May 2013 8. Normative References [I-D.ietf-jose-json-web-algorithms] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-json-web-algorithms-08 (work in progress), December 2012. [I-D.ietf-jose-json-web-encryption] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web Encryption (JWE)", draft-ietf-jose-json-web-encryption-08 (work in progress), December 2012. [I-D.ietf-jose-json-web-key] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-key-08 (work in progress), December 2012. [I-D.ietf-jose-json-web-signature] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", draft-ietf-jose-json-web-signature-08 (work in progress), December 2012. Barnes Expires November 7, 2013 [Page 20] Internet-Draft JOSE Refactor May 2013 Author's Address Richard Barnes BBN Email: rlb@ipv.sx Barnes Expires November 7, 2013 [Page 21]