Public Key Authenticated Encryption for JOSE: ECDH-1PU

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 https://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 7 November 2021.¶

Copyright Notice

Copyright (c) 2021 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 (https://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 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

JSON Object Signing and Encryption (JOSE) defines a number of encryption (JWE) [RFC7516] and digital signature (JWS) [RFC7515] algorithms. When symmetric cryptography is used, JWE provides authenticated encryption that ensures both confidentiality and sender authentication. However, for public key cryptography the existing JWE encryption algorithms provide only confidentiality and some level of ciphertext integrity. When sender authentication is required, users must resort to nested signed-then-encrypted structures, which increases the overhead and size of resulting messages. This document describes an alternative encryption algorithm called ECDH-1PU that provides public key authenticated encryption, allowing the benefits of authenticated encryption to be enjoyed for public key JWE as it currently is for symmetric cryptography.¶

ECDH-1PU is based on the One-Pass Unified Model for Elliptic Curve Diffie-Hellman key agreement described in [NIST.800-56A].¶

The advantages of public key authenticated encryption with ECDH-1PU compared to using nested signed-then-encrypted documents include the following:¶

• The resulting message size is more compact as an additional layer of headers and base64url-encoding is avoided. A 500-byte payload when encrypted and authenticated with ECDH-1PU (with P-256 keys and "A256GCM" Content Encryption Method) results in a 1087-byte JWE in Compact Encoding. An equivalent nested signed-then-encrypted JOSE message using the same keys and encryption method is 1489 bytes (37% larger).¶
• The same primitives are used for both confidentiality and authenticity, providing savings in code size for constrained environments.¶
• The generic composition of signatures and public key encryption involves a number of subtle details that are essential to security [PKAE]. Providing a dedicated algorithm for public key authenticated encryption reduces complexity for users of JOSE libraries.¶
• ECDH-1PU provides only authenticity and not the stronger security properties of non-repudiation or third-party verifiability. This can be an advantage in applications where privacy, anonymity, or plausible deniability are goals.¶

2. Key Agreement with Elliptic Curve Diffie-Hellman One-Pass Unified Model (ECDH-1PU)

This section defines the specifics of key agreement with Elliptic Curve Diffie-Hellman One-Pass Unified Model, in combination with the one-step KDF, as defined in Section 5.8.2.1 of [NIST.800-56A] using the Concatenation Format of Section 5.8.2.1.1. This is identical to the ConcatKDF function used by the existing JWE ECDH-ES algorithm defined in Section 4.6 of [RFC7518]. As for ECDH-ES, the key agreement result can be used in one of two ways:¶

1. directly as the Content Encryption Key (CEK) for the "enc" algorithm, in the Direct Key Agreement mode, or¶
2. as a symmetric key used to wrap the CEK with the "A128KW", "A192KW", or "A256KW" algorithms, in the Key Agreement with Key Wrapping mode.¶

A fresh ephemeral public key value MUST be generated for each message. When encrypting the message to multiple recipients using ECDH-1PU, the same ephemeral keys MAY be reused for multiple recipients [MRES].¶

In Direct Key Agreement mode, the output of the KDF MUST be a key of the same length as that used by the "enc" algorithm. In this case, the empty octet sequence is used as the JWE Encrypted Key value. The "alg" (algorithm) Header Parameter value "ECDH-1PU" is used in Direct Key Agreement mode.¶

In Key Agreement with Key Wrapping mode, the output of the KDF MUST be a key of the length needed for the specified key wrapping algorithm. In this case, the JWE Encrypted Key is the CEK wrapped with the agreed-upon key.¶

The following "alg" (algorithm) Header Parameter values are used to indicate the JWE Encrypted Key is the result of encrypting the CEK using the result of the key agreement algorithm as the key encryption key for the corresponding key wrapping algorithm:¶

3. IANA considerations

This section registers identifiers under the IANA JSON Web Signature and Encryption Algorithms Registry established by [RFC7518] and the IANA JSON Web Signature and Encryption Header Parameters registry established by [RFC7515].¶

4. Security Considerations

The security considerations of [RFC7516] and [RFC7518] relevant to ECDH-ES also apply to this specification.¶

The security considerations of [NIST.800-56A] apply here.¶

When performing an ECDH key agreement between a static private key and any untrusted public key, care should be taken to ensure that the public key is a valid point on the same curve as the private key. Failure to do so may result in compromise of the static private key. For the NIST curves P-256, P-384, and P-521, appropriate validation routines are given in Section 5.6.2.3.3 of [NIST.800-56A]. For the curves used by X25519 and X448, consult the security considerations of [RFC7748].¶

The ECDH-1PU algorithm is vulnerable to Key Compromise Impersonation (KCI) attacks. If the long-term static private key of a party is compromised, then the attacker can not only impersonate that party to other parties, but also impersonate any other party when communicating with the compromised party. If resistance to KCI is desired in a single message, then the sender SHOULD use a nested JWS signature over the content.¶

When Key Agreement with Key Wrapping is used, the JWE Authentication Tag is included in the input to the Key Derivation Function, as described in section Section 2.3. Without this step, when the same Content Encryption Key (CEK) is reused for multiple recipients, then any of those recipients can produce a new message that appears to come from the original sender. If the MAC used by the content encryption algorithm is not compactly committing ([ccAEAD]) then it may be possible for a recipient to calculate an alternative message that produces the same authentication tag. An alternative is to encrypt the message separately to each recipient using Direct Key Agreement, or to sign the message using a nested signed-then-encrypted JOSE composition.¶

The security properties of the one-pass unified model are given in Section 7.3 of [NIST.800-56A].¶

Appendix A. Example ECDH-1PU Key Agreement Computation with A256GCM

This example uses ECDH-1PU in Direct Key Agreement mode ("alg" value "ECDH-1PU") to produce an agreed-upon key for AES GCM with a 256-bit key ("enc" value "A256GCM"). The example re-uses the keys and parameters of the example computation in Appendix C of [RFC7518], with the addition of an extra static key-pair for Alice.¶

In this example, a producer Alice is encrypting content to a consumer Bob. Alice's static key-pair (in JWK format) used for the key agreement in this example (including the private part) is:¶

      {"kty":"EC",
       "crv":"P-256",
       "x":"WKn-ZIGevcwGIyyrzFoZNBdaq9_TsqzGl96oc0CWuis",
       "y":"y77t-RvAHRKTsSGdIYUfweuOvwrvDD-Q3Hv5J0fSKbE",
       "d":"Hndv7ZZjs_ke8o9zXYo3iq-Yr8SewI5vrqd0pAvEPqg"}

Bob's static key-pair (in JWK format) is:¶

      {"kty":"EC",
       "crv":"P-256",
       "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
       "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
       "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"}

The producer (Alice) generates an ephemeral key for the key agreement computation. Alice's ephemeral key (in JWK format) is:¶

      {"kty":"EC",
       "crv":"P-256",
       "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
       "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
       "d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"}

Header Parameter values used in this example are as follows. The "apu" (agreement PartyUInfo) Header Parameter value is the base64url encoding of the UTF-8 string "Alice" and the "apv" (agreement PartyVInfo) Header Parameter value is the base64url encoding of the UTF-8 string "Bob". The "epk" (ephemeral public key) Header Parameter is used to communicate the producer's (Alice's) ephemeral public key value to the consumer (Bob).¶

     {"alg":"ECDH-1PU",
      "enc":"A256GCM",
      "apu":"QWxpY2U",
      "apv":"Qm9i",
      "epk":
       {"kty":"EC",
        "crv":"P-256",
        "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
        "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
       }
     }

The resulting one-pass KDF [NIST.800-56A] parameter values are:¶

Ze

This is set to the output of the ECDH key agreement between Alice's ephemeral private key and Bob's static public key. In this example, Ze is the following octet sequence (in hexadecimal notation):¶

      9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c
      fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4

Zs

This is set to the output of the ECDH key agreement between Alice's static private key and Bob's static public key. In this example, Zs is the following octet sequence (in hexadecimal notation):¶

      e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d
      41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d

Z

This is set to the concatenation of Ze followed by Zs. In this example, Z is the following octet sequence (in hexadecimal notation):¶

      9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c
      fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4
      e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d
      41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d

keydatalen

This value is 256 - the number of bits in the desired output key (because "A256GCM" uses a 256-bit key).¶

cctag

This value is the empty octet string.¶

AlgorithmID

This is set to the octets representing the 32-bit big-endian value 7 - 00 00 00 07 in hexadecimal notation - the number of octets in the AlgorithmID content "A256GCM", followed by the octets representing the ASCII string "A256GCM" - 41 32 35 36 47 43 4d (in hex). The complete value is therefore: 00 00 00 07 41 32 35 36 47 43 4d¶

PartyUInfo

This is set to the octets representing the 32-bit big-endian value 5, followed by the octets representing the UTF-8 string "Alice". In hexadecimal notation: 00 00 00 05 41 6c 69 63 65¶

PartyVInfo

This is set to the octets representing the 32-bit big-endian value 3, followed by the octets representing the UTF-8 string "Bob". In hexadecimal notation: 00 00 00 03 42 6f 62¶

SuppPubInfo

This is set to the octets representing the 32-bit big-endian value 256 - the keydatalen value. In hexadecimal notation: 00 00 01 00¶

SuppPrivInfo

This is set to the empty octet sequence.¶

Concatenating the parameters AlgorithmID through SuppPrivInfo results in a FixedInfo value in Concatenation Format (as per Section 5.8.2.1.1 of [NIST.800-56A]) of (in hexidecimal notation):¶

      00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41
      6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00

Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo value results in a one-pass KDF round 1 hash input of (hexadecimal):¶

      00 00 00 01 9e 56 d9 1d 81 71 35 d3 72 83 42 83
      bf 84 26 9c fb 31 6e a3 da 80 6a 48 f6 da a7 79
      8c fe 90 c4 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c
      68 8b 3e 7d 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12
      41 ef d5 0d 00 00 00 07 41 32 35 36 47 43 4d 00
      00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00
      00 01 00

The resulting derived key, which is the full 256 bits of the round 1 hash output is:¶

      6c af 13 72 3d 14 85 0a d4 b4 2c d6 dd e9 35 bf
      fd 2f ff 00 a9 ba 70 de 05 c2 03 a5 e1 72 2c a7

The base64url-encoded representation of this derived key is:¶

      bK8Tcj0UhQrUtCzW3ek1v_0v_wCpunDeBcIDpeFyLKc

Appendix B. Example ECDH-1PU+A128KW Key Agreement computation with A256CBC-HS256

This example uses ECDH-1PU in Key Agreement with Key Wrapping mode ("alg" value "ECDH-1PU+A128KW") to encrypt a JWE for multiple recipients using the JWE JSON Serialization. The example uses X25519 key pairs, as described in [RFC8037]. Alice is sending an identical message to Bob and Charlie. Because Bob and Charlie are using the same curve (X25519), Alice reuses the same ephemeral key-pair for both recipients and includes it in the JWE Protected Header. If this was not the case, Alice should generate a separate ephemeral key-pair for each recipient and include it in each per-recipient header instead.¶

Alice's static key pair, represented as an OKP JWK (including the private component) is:¶

     {"kty": "OKP",
      "crv": "X25519",
      "x": "Knbm_BcdQr7WIoz-uqit9M0wbcfEr6y-9UfIZ8QnBD4",
      "d": "i9KuFhSzEBsiv3PKVL5115OCdsqQai5nj_Flzfkw5jU"}

Bob's static key-pair (in JWK format) is:¶

     {"kty": "OKP",
      "crv": "X25519",
      "x": "BT7aR0ItXfeDAldeeOlXL_wXqp-j5FltT0vRSG16kRw",
      "d": "1gDirl_r_Y3-qUa3WXHgEXrrEHngWThU3c9zj9A2uBg"}

Charlie's static key-pair (in JWK format) is:¶

     {"kty": "OKP",
      "crv": "X25519",
      "x": "q-LsvU772uV_2sPJhfAIq-3vnKNVefNoIlvyvg1hrnE",
      "d": "Jcv8gklhMjC0b-lsk5onBbppWAx5ncNtbM63Jr9xBQE"}

Alice generates an ephemeral key-pair on the same curve. Alice's ephemeral key-pair (in JWK format) is:¶

     {"kty": "OKP",
      "crv": "X25519",
      "x": "k9of_cpAajy0poW5gaixXGs9nHkwg1AFqUAFa39dyBc",
      "d": "x8EVZH4Fwk673_mUujnliJoSrLz0zYzzCWp5GUX2fc8"}

    {"alg":"ECDH-1PU+A128KW",
     "enc":"A256CBC-HS512",
     "apu":"QWxpY2U",
     "apv":"Qm9iIGFuZCBDaGFybGll",
     "epk":
      {"kty":"OKP",
       "crv":"X25519",
       "x":"k9of_cpAajy0poW5gaixXGs9nHkwg1AFqUAFa39dyBc"}}

    {"kid":"bob-key-2"}
    {"kid":"2021-05-06"}

    {"jku":"https://alice.example.com/keys.jwks"}

    [123, 34, 97, 108, 103, 34, 58, 34, 69, 67, 68, 72, 45, 49, 80, 85,
    43, 65, 49, 50, 56, 75, 87, 34, 44, 34, 101, 110, 99, 34, 58, 34,
    65, 50, 53, 54, 67, 66, 67, 45, 72, 83, 53, 49, 50, 34, 44, 34, 97,
    112, 117, 34, 58, 34, 81, 87, 120, 112, 89, 50, 85, 34, 44, 34, 97,
    112, 118, 34, 58, 34, 81, 109, 57, 105, 73, 71, 70, 117, 90, 67, 66,
    68, 97, 71, 70, 121, 98, 71, 108, 108, 34, 44, 34, 101, 112, 107,
    34, 58, 123, 34, 107, 116, 121, 34, 58, 34, 79, 75, 80, 34, 44, 34,
    99, 114, 118, 34, 58, 34, 88, 50, 53, 53, 49, 57, 34, 44, 34, 120,
    34, 58, 34, 107, 57, 111, 102, 95, 99, 112, 65, 97, 106, 121, 48,
    112, 111, 87, 53, 103, 97, 105, 120, 88, 71, 115, 57, 110, 72, 107,
    119, 103, 49, 65, 70, 113, 85, 65, 70, 97, 51, 57, 100, 121, 66, 99,
    34, 125, 125]

    ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0
    ef ee ed ec eb ea e9 e8 e7 e6 e5 e4 e3 e2 e1 e0
    df de dd dc db da d9 d8 d7 d6 d5 d4 d3 d2 d1 d0
    cf ce cd cc cb ca c9 c8 c7 c6 c5 c4 c3 c2 c1 c0

    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f

    [84, 104, 114, 101, 101, 32, 105, 115, 32, 97, 32, 109, 97, 103, 105, 99,
    32, 110, 117, 109, 98, 101, 114, 46]

    Az2IWsISEMDJvyc5XRL-3-d-RgNBOGolCsxFFoUXFYw

    HLb4fTlm8spGmij3RyOs2gJ4DpHM4hhVRwdF_hGb3WQ

            32 81 08 96 e0 fe 4d 57 0e d1 ac fc ed f6 71 17
            dc 19 4e d5 da ac 21 d8 ff 7a f3 24 46 94 89 7f

            21 57 61 2c 90 48 ed fa e7 7c b2 e4 23 71 40 60
            59 67 c0 5c 7f 77 a4 8e ea f2 cf 29 a5 73 7c 4a

            32 81 08 96 e0 fe 4d 57 0e d1 ac fc ed f6 71 17
            dc 19 4e d5 da ac 21 d8 ff 7a f3 24 46 94 89 7f
            21 57 61 2c 90 48 ed fa e7 7c b2 e4 23 71 40 60
            59 67 c0 5c 7f 77 a4 8e ea f2 cf 29 a5 73 7c 4a

            00 00 00 20 1c b6 f8 7d 39 66 f2 ca 46 9a 28 f7
            47 23 ac da 02 78 0e 91 cc e2 18 55 47 07 45 fe
            11 9b dd 64

            00 00 00 80 00 00 00 20 1c b6 f8 7d 39 66 f2 ca
            46 9a 28 f7 47 23 ac da 02 78 0e 91 cc e2 18 55
            47 07 45 fe 11 9b dd 64

            00 00 00 0f 45 43 44 48 2d 31 50 55 2b 41 31 32
            38 4b 57 00 00 00 05 41 6c 69 63 65 00 00 00 0f
            42 6f 62 20 61 6e 64 20 43 68 61 72 6c 69 65 00
            00 00 80 00 00 00 20 1c b6 f8 7d 39 66 f2 ca 46
            9a 28 f7 47 23 ac da 02 78 0e 91 cc e2 18 55 47
            07 45 fe 11 9b dd 64

            00 00 00 01 32 81 08 96 e0 fe 4d 57 0e d1 ac fc
            ed f6 71 17 dc 19 4e d5 da ac 21 d8 ff 7a f3 24
            46 94 89 7f 21 57 61 2c 90 48 ed fa e7 7c b2 e4
            23 71 40 60 59 67 c0 5c 7f 77 a4 8e ea f2 cf 29
            a5 73 7c 4a 00 00 00 0f 45 43 44 48 2d 31 50 55
            2b 41 31 32 38 4b 57 00 00 00 05 41 6c 69 63 65
            00 00 00 0f 42 6f 62 20 61 6e 64 20 43 68 61 72
            6c 69 65 00 00 00 80 00 00 00 20 1c b6 f8 7d 39
            66 f2 ca 46 9a 28 f7 47 23 ac da 02 78 0e 91 cc
            e2 18 55 47 07 45 fe 11 9b dd 64

            df 4c 37 a0 66 83 06 a1 1e 3d 6b 00 74 b5 d8 df

            pOMVA9_PtoRe7xXW1139NzzN1UhiFoio8lGto9cf0t8PyU-sjNXH8-LIRLycq8CHJQ
            bDwvQeU1cSl55cQ0hGezJu2N9IY0QN

            89 dc fe 4c 37 c1 dc 02 71 f3 46 b5 b3 b1 9c 3b
            70 5c a2 a7 2f 9a 23 77 85 c3 44 06 fc b7 5f 10

            78 fe 63 fc 66 1c f8 d1 8f 92 a8 42 2a 64 18 e4
            ed 5e 20 a9 16 81 85 fd ee dc a1 c3 d8 e6 a6 1c

            89 dc fe 4c 37 c1 dc 02 71 f3 46 b5 b3 b1 9c 3b
            70 5c a2 a7 2f 9a 23 77 85 c3 44 06 fc b7 5f 10
            78 fe 63 fc 66 1c f8 d1 8f 92 a8 42 2a 64 18 e4
            ed 5e 20 a9 16 81 85 fd ee dc a1 c3 d8 e6 a6 1c

            00 00 00 01 89 dc fe 4c 37 c1 dc 02 71 f3 46 b5
            b3 b1 9c 3b 70 5c a2 a7 2f 9a 23 77 85 c3 44 06
            fc b7 5f 10 78 fe 63 fc 66 1c f8 d1 8f 92 a8 42
            2a 64 18 e4 ed 5e 20 a9 16 81 85 fd ee dc a1 c3
            d8 e6 a6 1c 00 00 00 0f 45 43 44 48 2d 31 50 55
            2b 41 31 32 38 4b 57 00 00 00 05 41 6c 69 63 65
            00 00 00 0f 42 6f 62 20 61 6e 64 20 43 68 61 72
            6c 69 65 00 00 00 80 00 00 00 20 1c b6 f8 7d 39
            66 f2 ca 46 9a 28 f7 47 23 ac da 02 78 0e 91 cc
            e2 18 55 47 07 45 fe 11 9b dd 64

            57 d8 12 6f 1b 7e c4 cc b0 58 4d ac 03 cb 27 cc

            56GVudgRLIMEElQ7DpXsijJVRSWUSDNdbWkdV3g0GUNq6hcT_GkxwnxlPIWrTXCqRp
            VKQC8fe4z3PQ2YH2afvjQ28aiCTWFE

    {
     "protected":
      "eyJhbGciOiJFQ0RILTFQVStBMTI4S1ciLCJlbmMiOiJBMjU2Q0JDLUhTNTEyIiwiYXB1Ijoi
       UVd4cFkyVSIsImFwdiI6IlFtOWlJR0Z1WkNCRGFHRnliR2xsIiwiZXBrIjp7Imt0eSI6Ik9L
       UCIsImNydiI6IlgyNTUxOSIsIngiOiJrOW9mX2NwQWFqeTBwb1c1Z2FpeFhHczluSGt3ZzFB
       RnFVQUZhMzlkeUJjIn19",
     "unprotected":
      {"jku":"https://alice.example.com/keys.jwks"},
     "recipients":[
      {"header":
        {"kid":"bob-key-2"},
       "encrypted_key":
        "pOMVA9_PtoRe7xXW1139NzzN1UhiFoio8lGto9cf0t8PyU-sjNXH8-LIRLycq8CHJQbDwvQ
        eU1cSl55cQ0hGezJu2N9IY0QN"},
      {"header":
        {"kid":"2021-05-06"},
       "encrypted_key":
        "56GVudgRLIMEElQ7DpXsijJVRSWUSDNdbWkdV3g0GUNq6hcT_GkxwnxlPIWrTXCqRpVKQC8
         fe4z3PQ2YH2afvjQ28aiCTWFE"}],
     "iv":
      "AAECAwQFBgcICQoLDA0ODw",
     "ciphertext":
      "Az2IWsISEMDJvyc5XRL-3-d-RgNBOGolCsxFFoUXFYw",
     "tag":
      "HLb4fTlm8spGmij3RyOs2gJ4DpHM4hhVRwdF_hGb3WQ"
    }

Author's Address