]>
Public Key Authenticated Encryption for JOSE: ECDH-1PU
ForgeRock
Broad Quay House
Prince Street
Bristol
`BS1 4DJ`

United Kingdom
neil.madden@forgerock.com
Security
Internet-Draft
JSON Object Signing and Encryption
JOSE
JSON Web Encryption
JWE
JSON Web Algorithms
JWA
Elliptic Curve Diffie-Hellman Key Agreement
ECDH
ECDH-1PU
This document describes the ECDH-1PU public key authenticated encryption algorithm
for JWE. The algorithm is similar to the existing ECDH-ES encryption algorithm, but
adds an additional ECDH key agreement between static keys of the sender and recipient.
This additional step allows the recipient to be assured of sender authenticity without
requiring a nested signed-then-encrypted message structure. The mode is also a useful
building block for constructing interactive handshake protocols on top of JOSE.
JSON Object Signing and Encryption (JOSE) defines a number of encryption (JWE)
and digital signature (JWS)
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 .
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.
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 .
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.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 when, and only when, they appear
in all capitals, as shown here.
This section defines the specifics of key agreement with Elliptic Curve Diffie-Hellman
Ephemeral-Static Static-Static, in combination with the one-step KDF, as defined in
Section 5.8.2.1 of 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 . As for ECDH-ES,
the key agreement result can be used in one of two ways:
directly as the Content Encryption Key (CEK) for the "enc" algorithm, in the
Direct Key Agreement mode, or
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 new ephemeral public key value MUST be generated for each key agreement operation.
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:
"alg" Param Value
Key Management Algorithm
ECDH-1PU+A128KW
ECDH-1PU using Concat KDF and CEK wrapped with "A128KW"
ECDH-1PU+A192KW
ECDH-1PU using Concat KDF and CEK wrapped with "A192KW"
ECDH-1PU+A256KW
ECDH-1PU using Concat KDF and CEK wrapped with "A256KW"
The "epk" (ephemeral public key), "apu" (Agreement PartyUInfo), and "apv" (Agreement PartyVInfo)
header parameters are used in ECDH-1PU exactly as defined in Section 4.6.1 of
.
When no other values are supplied, it is RECOMMENDED that the producer software
initializes the "apu" header to the base64url-encoding of the SHA-256 hash of the
concatenation of the sender's static public key and the ephemeral public key, and
the "apv" header to the base64url-encoding of the SHA-256 hash of the recipient's
static public key. This ensures that all keys involved in the key agreement are
cryptographically bound to the derived keys.
The key derivation process derives the agreed-upon key from the shared secret Z
established through the ECDH algorithm, per Section 6.2.1.2 of .
For the NIST prime order curves "P-256", "P-384", and "P-521", the ECC CDH primitive
for cofactor Diffie-Hellman defined in Section 5.7.1.2 of is
used (taking note that the cofactor for all these curves is 1). For curves "X25519" and
"X448" the appropriate ECDH primitive from Section 5 of is used.
Key derivation is performed using the one-step KDF, as defined in Section 5.8.1 and
Section 5.8.2.1 of using the Concatenation Format of
Section 5.8.2.1.1, where the Auxilary Function H is SHA-256. The KDF parameters
are set as follows:
This is set to the representation of the shared secret Z as an octet sequence.
As per Section 6.2.1.2 of Z is the concatenation
of Ze and Zs, where Ze is the shared secret derived from applying the ECDH
primitive to the sender's ephemeral private key and the recipient's static
public key. Zs is the shared secret derived from applying the ECDH primitive
to the sender's static private key and the recipient's static public key.
This is set to the number of bits in the desired output key. For "ECDH-1PU",
this is the length of the key used by the "enc" algorithm. For "ECDH-1PU+A128KW",
"ECDH-1PU+A192KW", and "ECDH-1PU+A256KW", this is 128, 192, and 256, respectively.
The AlgorithmID values is of the form Datalen || Data, where Data is a variable-length
string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter
that indicates the length (in octets) of Data. In the Direct Key Agreement case,
Data is set to the octets of the ASCII representation of the "enc" Header Parameter value.
In the Key Agreement with Key Wrapping case, Data is set to the octets of the ASCII
representation of the "alg" (algorithm) Header Parameter value.
The PartyUInfo value is of the form Datalen || Data, where Data is
a variable-length string of zero or more octets, and Datalen is a
fixed-length, big-endian 32-bit counter that indicates the length
(in octets) of Data. If an "apu" (agreement PartyUInfo) Header
Parameter is present, Data is set to the result of base64url
decoding the "apu" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence.
The PartyVInfo value is of the form Datalen || Data, where Data is
a variable-length string of zero or more octets, and Datalen is a
fixed-length, big-endian 32-bit counter that indicates the length
(in octets) of Data. If an "apv" (agreement PartyVInfo) Header
Parameter is present, Data is set to the result of base64url
decoding the "apv" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence.
This is set to the keydatalen represented as a 32-bit big-endian integer.
This is set to the empty octet sequence.

Applications need to specifiy how the "apu" and "apv" Header Parameters are used for that
application. The "apu" and "apv" values MUST be distinct, when used. Applications wishing
to conform to need to provide values that meet the requirements
of that doucument, e.g., by using values that identify the producer and consumer.
A party that has received a JWE encrypted with ECDH-1PU MAY reply to that message by
creating a new JWE using ECDH-1PU, but using the ephemeral public key ("epk") from the
first message as if it was the originating party's static public key. In this case,
key agreement proceeds exactly as for , but with the originator's
ephemeral public key used as the recipient (Party V) static public key. The "alg" (algorithm)
Header Parameter in the response MUST be identical to the "alg" Header Parameter of the
original message.
The value of the "apu" (Agreement PartyUInfo) Header Parameter value from the original
message SHOULD be reflected as the "apv" (Agreement PartyVInfo) Header Parameter value in
the new message. Applications need to specify how the new "apu" Header Parameter should be
constructed.
If a "kid" claim was included in the ephemeral public key of the original message, then
a "kid" Header Parameter with the same value MUST be included in the reply JWE.
After the initial message and a reply have been exchanged, the two parties may communicate
using the derived key from the second message as the encryption key for any number of
additional messages. When ECDH-1PU is used in Direct Key Agreement mode, then subsequent
messages using the derived key MUST be encrypted using the "dir" (Direct) JWE algorithm. When
used in Key Agreement with Key Wrapping mode, subsequent messages using the derived key MUST
be encrypted using the associated Key Wrapping algorithm, as shown in the following table:
ECDH-1PU "alg" Param Value
Subsequent "alg" Param Value
ECDH-1PU+A128KW
A128KW
ECDH-1PU+A192KW
A192KW
ECDH-1PU+A256KW
A256KW
This section registers JWE algorithms as per the registry established in
.
Algorithm Name: "ECDH-1PU"
Algorithm Description: ECDH One-Pass Unified Model using Concat KDF
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s):
Algorithm Analysis Document(s): (Section 7.3),

The security considerations of relevant to ECDH-ES
also apply to this specification.
The security considerations of 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 . For the curves
used by X25519 and X448, consult the security considerations of .
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. The second and any subsequent messages in
the two-way interactive handshake described in are not
vulnerable to KCI. If resistance to KCI is desired in a single message, then it is
RECOMMENDED to use a nested JWS signature over the content.
When Key Agreement with Key Wrapping is used, with the same Content Encryption Key (CEK)
reused for multiple recipients, any of those recipients can produce a new message that
appears to come from the original sender and will be trusted by any of the other recipients.
It is RECOMMENDED that a unique CEK is used for each recipient.
&RFC7515;
&RFC7516;
&RFC7518;
&RFC7748;
&RFC8174;
Recommendation for Pair-Wise Key Establishment Using Discrete Logarithm Cryptography Revision 3.
Computer Security Division, Information Technology Laboratory
Computer Security Division, Information Technology Laboratory
Computer Security Division, Information Technology Laboratory
Computer Security Division, Information Technology Laboratory
National Security Agency
Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses
University of California at Davis