]> Yubico

Gävlegatan 22 Stockholm SE emil@emlun.se

Yubico

ve7jtb@ve7jtb.com

IRTF Crypto Forum KDF Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Asynchronous Remote Key Generation (ARKG) introduces a mechanism to generate public keys without access to the corresponding private keys. Such a mechanism is useful for many scenarios when a new public key is needed but the private key holder is not available to perform the key generation. This may occur when private keys are stored in a hardware security device, which may be unavailable or locked at the time a new public key is needed. Some motivating use cases of ARKG include:

• Single-use asymmetric keys: Envisioned for the European Union's digital identity framework, which is set to use single-use asymmetric keys to prevent colluding verifiers from using public keys as correlation handles. Each digital identity credential would thus be issued with a single-use proof-of-possession key, used only once to present the credential to a verifier. ARKG empowers both online and offline usage scenarios: for offline scenarios, ARKG enables pre-generation of public keys for single-use credentials without needing to access the hardware security device that holds the private keys. For online scenarios, ARKG gives the credential issuer assurance that all derived private keys are bound to the same secure hardware element. In both cases, application performance may be improved since public keys can be generated in a general-purpose execution environment instead of a secure enclave.
• Enhanced forward secrecy: The use of ARKG can facilitate forward secrecy in certain contexts. For instance, section 8.5.4 of RFC 9052 notes that "Since COSE is designed for a store-and-forward environment rather than an online environment, [...] forward secrecy (see ) is not achievable. A static key will always be used for the receiver of the COSE object." As opposed to workarounds like exchanging a large number of keys in advance, ARKG enables the sender to generate ephemeral recipient public keys on demand.
• Backup key generation: For example, the W3C Web Authentication API (WebAuthn) generates a new key pair for each account on each web site. ARKG could allow for simultaneously generating a backup public key when registering a new public key. A primary authenticator could generate both a key pair for itself and a public key for a paired backup authenticator. The backup authenticator only needs to be paired with the primary authenticator once, and can then be safely stored until it is needed.

ARKG consists of three procedures:

• Initialization: The delegating party generates a seed pair and discloses the public seed to a subordinate party, while securely retaining the private seed.
• Public key generation: The subordinate party uses the public seed to autonomously generate a new public key along with a unique key handle for the public key. This can be repeated any number of times.
• Private key derivation: The delegating party uses a key handle and the private seed to derive the private key corresponding to the public key generated along with the key handle. This can be repeated with any number of key handles.

Notably, ARKG can be built entirely using established cryptographic primitives. The required primitives are a public key blinding scheme and a key encapsulation mechanism (KEM), which may in turn use a key derivation function (KDF) and a message authentication code (MAC) scheme. Both conventional primitives and quantum-resistant alternatives exist that meet these requirements.

Requirements Language 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.

Notation The following notation is used throughout this document:

• The symbol || represents octet string concatenation.
• Literal text strings and octet strings are denoted using the CDDL syntax defined in .
• Elliptic curve operations are written in additive notation: + denotes point addition, i.e., the curve group operation; * denotes point multiplication, i.e., repeated point addition; and + also denotes scalar addition modulo the curve order. * has higher precedence than +, i.e., a + b * C is equivalent to a + (b * C).
• LEN(x) is the length, in octets, of the octet string x.
• The function I2OSP converts a nonnegative integer into an octet string as defined in .

The Asynchronous Remote Key Generation (ARKG) algorithm The ARKG algorithm consists of three functions, each performed by one of two participants: the delegating party or the subordinate party. The delegating party generates an ARKG seed pair and emits the public seed to the subordinate party while keeping the private seed secret. The subordinate party can then use the public seed to generate derived public keys and key handles, and the delegating party can use the private seed and a key handle to derive the corresponding private key. This construction of ARKG is fully deterministic, extracting input entropy as explicit parameters, as opposed to the internal random sampling typically used in the academic literature . Implementations MAY choose to instead implement the ARKG-Derive-Seed and KEM-Encaps functions as nondeterministic procedures omitting their respective ikm parameters and sampling random entropy internally; this choice does not affect interoperability between the functions ARKG-Derive-Seed, ARKG-Derive-Public-Key and ARKG-Derive-Private-Key. The following subsections define the abstract instance parameters used to construct the three ARKG functions, followed by the definitions of the three ARKG functions.

Instance parameters ARKG is composed of a suite of other algorithms. The parameters of an ARKG instance are:

• BL: An asymmetric key blinding scheme , consisting of:
  • Function BL-Generate-Keypair() -> (pk, sk): Generate a blinding key pair. Input consists of input keying material entropy ikm. Output consists of a blinding public key pk and a blinding private key sk.
  • Function BL-PRF(ikm_tau, ctx) -> tau: Derive a pseudorandom blinding factor. Input consists of input entropy ikm_tau and a domain separation parameter ctx. Output consists of the blinding factor tau.
  • Function BL-Blind-Public-Key(pk, tau) -> pk_tau: Deterministically compute a blinded public key. Input consists of a blinding public key pk, and a blinding factor tau. Output consists of the blinded public key pk_tau.
  • Function BL-Blind-Private-Key(sk, tau) -> sk_tau: Deterministically compute a blinded private key. Input consists of a blinding private key sk, and the blinding factor tau. Output consists of the blinded private key sk_tau.
  ikm is an opaque octet string of a suitable length as defined by the ARKG instance. ikm_tau is an opaque octet string generated as the k output of KEM-Encaps and KEM-Decaps. ctx is an opaque octet string of arbitrary length. The representations of pk and pk_tau are defined by the protocol that invokes ARKG. The representations of sk, tau and sk_tau are undefined implementation details. See for definitions of security properties required of the key blinding scheme BL.
• KEM: A key encapsulation mechanism , consisting of the functions:
  • KEM-Derive-Key-Pair(ikm) -> (pk, sk): Derive a key encapsulation key pair. Input consists of input keying material entropy ikm. Output consists of public key pk and private key sk.
  • KEM-Encaps(pk, ikm, ctx) -> (k, c): Derive a key encapsulation. Input consists of an encapsulation public key pk, input entropy ikm and a domain separation parameter ctx. Output consists of a shared secret k and an encapsulation ciphertext c.
  • KEM-Decaps(sk, c, ctx) -> k: Decapsulate a shared secret. Input consists of encapsulation private key sk, encapsulation ciphertext c and a domain separation parameter ctx. Output consists of the shared secret k on success, or an error otherwise.
  ikm is an opaque octet string of a suitable length as defined by the ARKG instance. k, c and ctx are opaque octet strings of arbitrary length. The representation of pk is defined by the protocol that invokes ARKG. The representation of sk is an undefined implementation detail. The KEM MUST guarantee integrity of the ciphertext, meaning that knowledge of the public key pk and the domain separation parameter ctx is required in order to create any ciphertext c that can be successfully decapsulated by the corresponding private key sk. describes a general formula for how any KEM can be adapted to include this guarantee. discusses the reasons for this requirement. See for definitions of additional security properties required of the key encapsulation mechanism KEM.

A concrete ARKG instantiation MUST specify the instantiation of each of the above functions. The output keys of the BL scheme are also the output keys of the ARKG instance as a whole. For example, if BL-Blind-Public-Key and BL-Blind-Private-Key output ECDSA keys, then the ARKG instance will also output ECDSA keys. We denote a concrete ARKG instance by the pattern ARKG-NAME, substituting for NAME some description of the chosen instantiation for BL and KEM. Note that this pattern cannot in general be unambiguously parsed; implementations MUST NOT attempt to construct an ARKG instance by parsing such a pattern string. Concrete ARKG instances MUST always be identified by lookup in a registry of fully specified ARKG instances. This is to prevent usage of algorithm combinations that may be incompatible or insecure.

The function ARKG-Derive-Seed This function is performed by the delegating party. The delegating party derives the ARKG seed pair (pk, sk) and keeps the private seed sk secret, while the public seed pk is provided to the subordinate party. The subordinate party will then be able to derive public keys on behalf of the delegating party. (pk, sk) ARKG instance parameters: BL A key blinding scheme. KEM A key encapsulation mechanism. Inputs: ikm_bl Input keying material entropy for BL. ikm_kem Input keying material entropy for KEM. Output: (pk, sk) An ARKG seed pair with public seed pk and private seed sk. The output (pk, sk) is calculated as follows: (pk_bl, sk_bl) = BL-Derive-Key-Pair(ikm_bl) (pk_kem, sk_kem) = KEM-Derive-Key-Pair(ikm_kem) pk = (pk_bl, pk_kem) sk = (sk_bl, sk_kem) ]]>

Nondeterministic variants Applications that do not need a deterministic interface MAY choose to instead implement ARKG-Derive-Seed, KEM-Derive-Key-Pair and BL-Derive-Key-Pair as nondeterministic procedures omitting their respective ikm parameters and sampling random entropy internally; this choice does not affect interoperability with ARKG-Derive-Public-Key and ARKG-Derive-Private-Key.

The function ARKG-Derive-Public-Key This function is performed by the subordinate party, which holds the ARKG public seed pk = (pk_bl, pk_kem). The resulting public key pk' can be provided to external parties to use in asymmetric cryptography protocols, and the resulting key handle kh can be used by the delegating party to derive the private key corresponding to pk'. This function may be invoked any number of times with the same public seed, using different ikm or ctx arguments, in order to generate any number of public keys. (pk', kh) ARKG instance parameters: BL A key blinding scheme. KEM A key encapsulation mechanism. Inputs: pk_bl A key blinding public key. pk_kem A key encapsulation public key. ikm Input entropy for KEM encapsulation. ctx An octet string of length at most 64, containing optional context and application specific information (can be a zero-length string). Output: pk' A blinded public key. kh A key handle for deriving the blinded private key sk' corresponding to pk'. The output (pk', kh) is calculated as follows: if LEN(ctx) > 64: Abort with an error. ctx' = I2OSP(LEN(ctx), 1) || ctx ctx_bl = 'ARKG-Derive-Key-BL.' || ctx' ctx_kem = 'ARKG-Derive-Key-KEM.' || ctx' (ikm_tau, c) = KEM-Encaps(pk_kem, ikm, ctx_kem) tau = BL-PRF(ikm_tau, ctx_bl) pk' = BL-Blind-Public-Key(pk_bl, tau) kh = c ]]> If this procedure aborts due to an error, the procedure can safely be retried with the same (pk_bl, pk_kem) and ctx arguments but a new ikm argument. See for guidance on using ctx arguments longer than 64 bytes.

Nondeterministic variants Applications that do not need a deterministic interface MAY choose to instead implement ARKG-Derive-Public-Key and KEM-Encaps as nondeterministic procedures omitting their respective ikm parameter and sampling random entropy internally; this choice does not affect interoperability with ARKG-Derive-Private-Key. BL-PRF and BL-Blind-Public-Key must always be deterministic for compatibility with ARKG-Derive-Private-Key.

The function ARKG-Derive-Private-Key This function is performed by the delegating party, which holds the ARKG private seed (sk_bl, sk_kem). The resulting private key sk' can be used in asymmetric cryptography protocols to prove possession of sk' to an external party that has the corresponding public key. This function may be invoked any number of times with the same private seed, in order to derive the same or different private keys any number of times. sk' ARKG instance parameters: BL A key blinding scheme. KEM A key encapsulation mechanism. Inputs: sk_bl A key blinding private key. sk_kem A key encapsulation private key. kh A key handle output from ARKG-Derive-Public-Key. ctx An octet string of length at most 64, containing optional context and application specific information (can be a zero-length string). Output: sk' A blinded private key. The output sk' is calculated as follows: if LEN(ctx) > 64: Abort with an error. ctx' = I2OSP(LEN(ctx), 1) || ctx ctx_bl = 'ARKG-Derive-Key-BL.' || ctx' ctx_kem = 'ARKG-Derive-Key-KEM.' || ctx' ikm_tau = KEM-Decaps(sk_kem, kh, ctx_kem) If decapsulation failed: Abort with an error. tau = BL-PRF(ikm_tau, ctx_bl) sk' = BL-Blind-Private-Key(sk_bl, tau) ]]> Errors in this procedure are typically unrecoverable. For example, KEM-Decaps may fail to decapsulate the KEM ciphertext kh if it fails an integrity check. ARKG instantiations SHOULD be chosen in a way that such errors are impossible if kh was generated by an honest and correct implementation of ARKG-Derive-Public-Key. Incorrect or malicious implementations of ARKG-Derive-Public-Key do not degrade the security of an honest and correct implementation of ARKG-Derive-Private-Key. See also . See for guidance on using ctx arguments longer than 64 bytes.

Using ctx values longer than 64 bytes The ctx parameter of ARKG-Derive-Public-Key and ARKG-Derive-Private-Key is limited to a length of at most 64 bytes. This is because this value needs to be communicated from the subordinate party to the delegating party to use the same argument value in both functions, therefore it is necessary in some contexts to limit the size of this parameter in order to limit the size of overall protocol messages. If applications require ctx values longer than 64 bytes, implementors MAY use techniques such as that described in . Precise procedure definitions are left as an application-specific implementation detail.

Generic ARKG instantiations This section defines generic formulae for instantiating the individual ARKG parameters, which can be used to define concrete ARKG instantiations.

Using elliptic curve addition for key blinding Instantiations of ARKG whose output keys are elliptic curve keys can use elliptic curve addition as the key blinding scheme BL  . This section defines a general formula for such instantiations of BL. This formula has the following parameters:

• crv: An elliptic curve.
• hash-to-crv-suite: A hash-to-curve suite suitable for hashing to the scalar field of crv.
• DST_ext: A domain separation tag.

Then the BL parameter of ARKG may be instantiated as follows:

• G is the generator of the prime order subgroup of crv.
• N is the order of G.
• The function hash_to_field is defined in .

(pk, sk) DST_bl_sk = 'ARKG-BL-EC-KG.' || DST_ext sk = hash_to_field(ikm, 1) with the parameters: DST: DST_bl_sk F: GF(N), the scalar field of the prime order subgroup of crv p: N m: 1 L: The L defined in hash-to-crv-suite expand_message: The expand_message function defined in hash-to-crv-suite pk = sk * G BL-PRF(ikm_tau, ctx) -> tau DST_tau = 'ARKG-BL-EC.' || DST_ext || ctx tau = hash_to_field(ikm_tau, 1) with the parameters: DST: DST_tau F: GF(N), the scalar field of the prime order subgroup of crv p: N m: 1 L: The L defined in hash-to-crv-suite expand_message: The expand_message function defined in hash-to-crv-suite BL-Blind-Public-Key(pk, tau) -> pk_tau pk_tau = pk + tau * G BL-Blind-Private-Key(sk, tau) -> sk_tau sk_tau_tmp = sk + tau If sk_tau_tmp = 0, abort with an error. sk_tau = sk_tau_tmp ]]>

Using HMAC to adapt a KEM without ciphertext integrity Not all key encapsulation mechanisms guarantee ciphertext integrity, meaning that a valid KEM ciphertext can be created only with knowledge of the KEM public key. This section defines a general formula for adapting any KEM to guarantee ciphertext integrity by prepending a MAC to the KEM ciphertext. For example, ECDH does not guarantee ciphertext integrity - any elliptic curve point is a valid ECDH ciphertext and can be successfully decapsulated using any elliptic curve private scalar. This formula has the following parameters:

• Hash: A cryptographic hash function.
• DST_ext: A domain separation parameter.
• Sub-Kem: A key encapsulation mechanism as described for the KEM parameter in , except Sub-Kem MAY ignore the ctx parameter and MAY not guarantee ciphertext integrity. Sub-Kem defines the functions Sub-Kem-Derive-Key-Pair, Sub-Kem-Encaps and Sub-Kem-Decaps.

The KEM parameter of ARKG may be instantiated using Sub-Kem, HMAC and HKDF as follows:

• L is the output length of Hash in octets.
• LEFT(X, n) is the first n bytes of the byte array X.
• DROP_LEFT(X, n) is the byte array X without the first n bytes.

We truncate the HMAC output to 128 bits (16 octets) because as described in , ARKG needs ciphertext integrity only to ensure correctness, not for security. Extendable-output functions used as the Hash parameter SHOULD still be instantiated with an output length appropriate for the desired security level, in order to not leak information about the Sub-Kem shared secret key. (pk, sk) (pk, sk) = Sub-Kem-Derive-Key-Pair(ikm) KEM-Encaps(pk, ikm, ctx) -> (k, c) ctx_sub = 'ARKG-KEM-HMAC.' || DST_ext || ctx (k', c') = Sub-Kem-Encaps(pk, ikm, ctx_sub) prk = HKDF-Extract with the arguments: Hash: Hash salt: not set IKM: k' info_mk = 'ARKG-KEM-HMAC-mac.' || DST_ext || ctx mk = HKDF-Expand with the arguments: Hash: Hash PRK: prk info: info_mk L: L t = HMAC-Hash-128(K=mk, text=c') info_k = 'ARKG-KEM-HMAC-shared.' || DST_ext || ctx k = HKDF-Expand with the arguments: Hash: Hash PRK: prk info: info_k L: The length of k' in octets. c = t || c' KEM-Decaps(sk, c, ctx) -> k t = LEFT(c, 16) c' = DROP_LEFT(c, 16) ctx_sub = 'ARKG-KEM-HMAC.' || DST_ext || ctx k' = Sub-Kem-Decaps(sk, c', ctx_sub) prk = HKDF-Extract with the arguments: Hash: Hash salt: not set IKM: k' mk = HKDF-Expand with the arguments: Hash: Hash PRK: prk info: 'ARKG-KEM-HMAC-mac.' || DST_ext || ctx L: L t' = HMAC-Hash-128(K=mk, text=c') If t = t': k = HKDF-Expand with the arguments: Hash: Hash PRK: prk info: 'ARKG-KEM-HMAC-shared.' || DST_ext || ctx L: The length of k' in octets. Else: Abort with an error. ]]> In concrete instances where Sub-Kem-Encaps and Sub-Kem-Decaps ignore the ctx parameter, implementations MAY eliminate the parameter and omit the computation of ctx_sub.

Using ECDH as the KEM Instantiations of ARKG can use ECDH as the key encapsulation mechanism KEM  . This section defines a general formula for such instantiations of KEM. This formula has the following parameters:

• crv: an elliptic curve valid for use with ECDH .
• Hash: A cryptographic hash function.
• hash-to-crv-suite: A hash-to-curve suite suitable for hashing to the scalar field of crv.
• DST_ext: A domain separation parameter.

The above parameters define the following intermediate value:

• DST_aug: 'ARKG-ECDH.' || DST_ext.

The KEM parameter of ARKG may be instantiated as described in section with the parameters:

• Hash: Hash.
• DST_ext: DST_aug.
• Sub-Kem: The functions Sub-Kem-Derive-Key-Pair, Sub-Kem-Encaps and Sub-Kem-Decaps defined as follows:
  • Elliptic-Curve-Point-to-Octet-String and Octet-String-to-Elliptic-Curve-Point are the conversion routines defined in sections 2.3.3 and 2.3.4 of , without point compression.
  • ECDH(pk, sk) represents the compact output of ECDH using public key (curve point) pk and private key (exponent) sk.
  • G is the generator of the prime order subgroup of crv.
  • N is the order of G.
  (pk, sk) DST_kem_sk = 'ARKG-KEM-ECDH-KG.' || DST_aug sk = hash_to_field(ikm, 1) with the parameters: DST: DST_kem_sk F: GF(N), the scalar field of the prime order subgroup of crv p: N m: 1 L: The L defined in hash-to-crv-suite expand_message: The expand_message function defined in hash-to-crv-suite pk = sk * G Sub-Kem-Encaps(pk, ikm, ctx) -> (k, c) (pk', sk') = Sub-Kem-Derive-Key-Pair(ikm) k = ECDH(pk, sk') c = Elliptic-Curve-Point-to-Octet-String(pk') Sub-Kem-Decaps(sk, c, ctx) -> k pk' = Octet-String-to-Elliptic-Curve-Point(c) k = ECDH(pk', sk) ]]>

Note: This instance intentionally ignores the ctx parameter of Sub-Kem-Encaps and Sub-Kem-Decaps.

Using X25519 or X448 as the KEM Instantiations of ARKG can use X25519 or X448 as the key encapsulation mechanism KEM. This section defines a general formula for such instantiations of KEM. This formula has the following parameters:

• DH-Function: the function X25519 or the function X448 .
• DST_ext: A domain separation parameter.

The KEM parameter of ARKG may be instantiated as described in section with the parameters:

• Hash: SHA-512 if DH-Function is X25519, or SHAKE256 with output length 64 octets if DH-Function is X448.
• DST_ext: 'ARKG-ECDHX.' || DST_ext.
• Sub-Kem: The functions Sub-Kem-Derive-Key-Pair, Sub-Kem-Encaps and Sub-Kem-Decaps defined as follows:
  • G is the octet string h'0900000000000000 0000000000000000 0000000000000000 0000000000000000' if DH-Function is X25519, or the octet string h'0500000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000' if DH-Function is X448. These are the little-endian encodings of the integers 9 and 5, which is the u-coordinate of the generator point of the respective curve group.
  (pk, sk) sk = ikm pk = DH-Function(sk, G) Sub-Kem-Encaps(pk, ikm, ctx) -> (k, c) (pk', sk') = Sub-Kem-Derive-Key-Pair(ikm) k = DH-Function(sk', pk) c = pk' Sub-Kem-Decaps(sk, c, ctx) -> k k = DH-Function(sk, c) ]]>

Note: This instance intentionally ignores the ctx parameter of Sub-Kem-Encaps and Sub-Kem-Decaps.

Using the same key for both key blinding and KEM When an ARKG instance uses the same type of key for both the key blinding and the KEM - for example, if elliptic curve arithmetic is used for key blinding as described in and ECDH is used as the KEM as described in - then the two keys MAY be the same key. Representations of such an ARKG seed MAY allow for omitting the second copy of the constituent key, but such representations MUST clearly identify that the single constituent key is to be used both as the key blinding key and the KEM key.

Concrete ARKG instantiations This section defines an initial set of concrete ARKG instantiations.

ARKG-P256 The identifier ARKG-P256 represents the following ARKG instance:

• BL: Elliptic curve addition as described in with the parameters:
  • crv: The NIST curve secp256r1 .
  • hash-to-crv-suite: P256_XMD:SHA-256_SSWU_RO_ .
  • DST_ext: 'ARKG-P256'.
• KEM: ECDH as described in with the parameters:
  • crv: The NIST curve secp256r1 .
  • Hash: SHA-256 .
  • hash-to-crv-suite: P256_XMD:SHA-256_SSWU_RO_ .
  • DST_ext: 'ARKG-P256'.

Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG instance SHOULD contain at least 256 bits of entropy.

ARKG-P384 The identifier ARKG-P384 represents the following ARKG instance:

• BL: Elliptic curve addition as described in with the parameters:
  • crv: The NIST curve secp384r1 .
  • hash-to-crv-suite: P384_XMD:SHA-384_SSWU_RO_ .
  • DST_ext: 'ARKG-P384'.
• KEM: ECDH as described in with the parameters:
  • crv: The NIST curve secp384r1 .
  • Hash: SHA-384 .
  • hash-to-crv-suite: P384_XMD:SHA-384_SSWU_RO_ .
  • DST_ext: 'ARKG-P384'.

Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG instance SHOULD contain at least 384 bits of entropy.

ARKG-P521 The identifier ARKG-P521 represents the following ARKG instance:

• BL: Elliptic curve addition as described in with the parameters:
  • crv: The NIST curve secp521r1 .
  • hash-to-crv-suite: P521_XMD:SHA-512_SSWU_RO_ .
  • DST_ext: 'ARKG-P521'.
• KEM: ECDH as described in with the parameters:
  • crv: The NIST curve secp521r1 .
  • Hash: SHA-512 .
  • hash-to-crv-suite: P521_XMD:SHA-512_SSWU_RO_ .
  • DST_ext: 'ARKG-P521'.

Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG instance SHOULD contain at least 512 bits of entropy.

ARKG-P256k The identifier ARKG-P256k represents the following ARKG instance:

• BL: Elliptic curve addition as described in with the parameters:
  • crv: The SECG curve secp256k1 .
  • hash-to-crv-suite: secp256k1_XMD:SHA-256_SSWU_RO_ .
  • DST_ext: 'ARKG-P256k'.
• KEM: ECDH as described in with the parameters:
  • crv: The SECG curve secp256k1 .
  • Hash: SHA-256 .
  • hash-to-crv-suite: secp256k1_XMD:SHA-256_SSWU_RO_ .
  • DST_ext: 'ARKG-P256k'.

Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG instance SHOULD contain at least 256 bits of entropy.

COSE bindings This section proposes additions to COSE to support ARKG use cases. These consist of a new key type to represent ARKG public seeds, algorithm identifiers for signing using an ARKG-derived private key, and new COSE_Sign_Args algorithm parameters for ARKG.

COSE key type: ARKG public seed An ARKG public seed is represented as a COSE_Key structure with kty value TBD (placeholder value -65537). defines key type parameters pkbl (-1) and pkkem (-2) for the BL and KEM public key, respectively, as well as key type parameter dkalg (-3), representing the algorithm that derived public and private keys are to be used with. COSE key type parameters for the ARKG-pub key type.

Name	Label	Value type	Required?	Description
pkbl	-1	COSE_Key	Required	BL key of ARKG public seed
pkkem	-2	COSE_Key	Required	KEM key of ARKG public seed
dkalg	-3	int / tstr	Optional	alg parameter of public and private keys derived from this ARKG public seed

When dkalg (-3) is present in an ARKG public seed, the alg (3) parameter of public keys derived using ARKG-Derive-Public-Key with that seed SHOULD be set to the dkalg (-3) value of the seed. The alg (3) parameter, when present, identifies the ARKG instance this public seed is to be used with. An initial set of COSE algorithm identifiers for this purpose is defined in . The following CDDL example represents an ARKG-P256 public seed restricted to generating derived keys for use with the ESP256 signature algorithm: The following is the same example encoded as CBOR:

COSE algorithms This section defines COSE algorithm identifiers for ARKG instances, and for signature algorithms combined with using a signing private key derived using ARKG. defines algorithm identifiers to represent ARKG instances. COSE algorithm identifiers for ARKG instances.

Name	Value	Description
ARKG-P256	TBD (placeholder -65700)	The ARKG instance ARKG-P256 defined in .
ARKG-P384	TBD (placeholder -65701)	The ARKG instance ARKG-P384 defined in .
ARKG-P521	TBD (placeholder -65702)	The ARKG instance ARKG-P521 defined in .
ARKG-P256k	TBD (placeholder -65703)	The ARKG instance ARKG-P256k defined in .

defines algorithm identifiers to represent signing algorithms. These MAY be used to negotiate algorithm selection between a digester and signer as described in , and in key representations exchanged between such digesters and signers, but SHOULD NOT appear in COSE structures consumed by signature verifiers. COSE structures consumed by signature verifiers SHOULD instead use the corresponding algorithm identifier listed in the "verification algorithm" column. All algorithm identifiers in denote signature algorithm suites where:

• Key generation consists of executing ARKG-Derive-Seed to derive or generate an ARKG seed pair, and disclosing the public seed.
• Signing consists of first executing ARKG-Derive-Public-Key to derive a verification public key and key handle, then executing ARKG-Derive-Private-Key with that key handle to derive the private signing key, and finally using the derived private signing key to generate a signature valid under the derived verification public key. Multiple signings can also be done with the same verification public key and key handle.
• Verification consists of executing the verification algorithm indicated in the table, using the derived verification public key.

COSE algorithms for signing with an ARKG-derived key.

Name	Value	Verification algorithm	Description
ESP256-ARKG	TBD	-9 (ESP256)	ESP256 using private key derived by ARKG-P256 ().
ESP256-split-ARKG	TBD (placeholder -65539)	-9 (ESP256)	ESP256-split using private key derived by ARKG-P256 ().
ESP384-ARKG	TBD	-51 (ESP384)	ESP384 using private key derived by ARKG-P384 ().
ESP384-split-ARKG	TBD	-51 (ESP384)	ESP384-split using private key derived by ARKG-P384 ().
ESP512-ARKG	TBD	-52 (ESP512)	ESP512 using private key derived by ARKG-P521 ().
ESP512-split-ARKG	TBD	-52 (ESP512)	ESP512-split using private key derived by ARKG-P521 ().
ES256K-ARKG	TBD	-47 (ES256K)	ES256K using private key derived by ARKG-P256k ().

As an example of the intended uses of these algorithm identifiers, consider a split signing use case with signing keys derived using ARKG-P256:

• First, a digester and signer use the algorithm identifier -65539 (ESP256-split-ARKG, placeholder value) to negotiate a signing protocol and their respective roles in it. This identifier expresses that the signer will generate ARKG seed pairs, the digester will use ARKG-Derive-Public-Key with those public seeds to derive public keys, and the signer will use ARKG-Derive-Private-Key and ESP256-split to sign data with private keys corresponding to those derived public keys.
• The signer, acting as the ARKG delegating party, then generates an ARKG-P256 seed pair and discloses the public seed to the digester. The public seed is encoded as a COSE_Key, with 1 (kty): -65537 (ARKG-pub, placeholder value) to indicate it is an ARKG public seed, 3 (alg): -67000 (ARKG-P256, placeholder value) to indicate which instance of ARKG-Derive-Public-Key to use it with, and -3 (dkalg): -9 (ESP256) to indicate which verification algorithm third-party verifiers may use to verify signatures made by keys derived from this public seed.
• The digester uses the ARKG public seed in ARKG-Derive-Public-Key. The resulting public key is encoded as a COSE_Key with 1 (kty): 2 (EC2) to indicate it is an elliptic curve key and 3 (alg): -9 (ESP256) to indicate its verification algorithm. The digester then provides this derived public key to some third party.
• That third party later requests a signature by the derived public key. The digester relays this request to the signer, along with some identifier for the ARKG seed pair if necessary, and uses a COSE_Sign_Args structure to convey ARKG-Derive-Private-Key inputs to the signer. The COSE_Sign_Args structure has 3 (alg): -65539 (ESP256-split-ARKG, placeholder value) to indicate the digester's intent as initially negotiated, and includes the kh and ctx arguments for the signer to use in ARKG-Derive-Private-Key. Since the negotiated algorithm is ESP256-split-ARKG, the digester performs the hash step of the ECDSA signing procedure as defined in , and provides the digest as the "data to be signed" input to the signer. The signer uses the indicated ARKG private seed in ARKG-Derive-Private-Key and uses the resulting derived private key to generate the requested signature.
• The third party receives the signature, uses the 3 (alg): -9 (ESP256) attribute of the public key to identify the verification algorithm to run, and uses that algorithm to verify the signature.

Note how in this example, the identifier -65539 (ESP256-split-ARKG, placeholder value) is not exposed to the third-party verifier; it is used only between digester and signer to negotiate and execute a signing protocol. The verifier does not need to know the internal details of the signing protocol, only what algorithm to use to verify the signature. Consider also an example using ESP256-ARKG instead:

• A digester and signer use the algorithm identifier TBD (ESP256-ARKG) to negotiate a signing protocol. This identifier expresses that the signer will generate ARKG seed pairs, the digester will use ARKG-Derive-Public-Key with those public seeds to derive public keys, and the signer will use ARKG-Derive-Private-Key and ESP256 to sign data with private keys corresponding to those derived public keys.
• The example proceeds just like the the ESP256-split-ARKG example above, except the signer uses the derived private key with ESP256 instead of ESP256-split. Therefore, the digester relays the "data to be signed" unaltered from the third party to the signer in this case.

COSE signing arguments This section defines ARKG-specific parameters for the COSE_Sign_Args structure . These consist of the parameters -1 and -2 respectively for the kh and ctx parameters of ARKG-Derive-Private-Key. defines these algorithm parameters for COSE_Sign_args. kh and ctx are both REQUIRED for all the relevant alg values. Algorithm parameters for COSE_Sign_Args.

Name	Label	Type	Required?	Algorithm	Description
kh	-1	bstr	Required	ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ES256K-ARKG	kh argument to ARKG-Derive-Private-Key.
ctx	-2	bstr	Required	ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ES256K-ARKG	ctx argument to ARKG-Derive-Private-Key.

The following CDDL example conveys the kh and ctx arguments for signing data using the ESP256-split algorithm and a key derived using ARKG-P256: The following is the same example encoded as CBOR:

Security Considerations

Security Properties ARKG satisfies two security properties, defined in . Informally, they are:

• Public key unlinkability: Derived public keys are indistinguishable from randomly sampled public keys, even with knowledge of the ARKG public seed. Consequently, it is also not distinguishable whether two derived public keys were derived from the same ARKG public seed or from different public seeds. This property holds under the assumption that the adversary does not know the tau or ikm_tau value that was computed in ARKG-Derive-Public-Key when deriving the public key. Indeed, knowledge of tau along with a public seed pk and derived public key pk' is sufficient to determine with certainty whether pk' is derived from pk. This also means that is is possible to prove, by revealing tau, that pk' is derived from pk, and therefore that knowledge of the corresponding derived private key sk' implies knowledge of the private seed sk. This property is called PK-unlinkability in .
• Private key security: Derived private keys cannot be recovered without knowledge of the ARKG private seed, even with knowledge of other public and private keys derived from the same seed. Consequently, signatures by derived private keys enjoy the same unforgeability properties as signatures made by equivalent keys generated without ARKG. This property is called SK-security in , specifically the msKS variant ("malicious-strong SK-security") which is the strongest of the four variants defined.

Secret Values Both security properties discussed in rely on the secrecy of the ARKG private seed. This is the primary secret which must be kept confidential in all circumstances. The ARKG functions also use other values of varying levels of sensitivity:

• The ikm_bl and ikm_kem arguments to ARKG-Derive-Seed: These uniquely determine the ARKG private seed, and so must be at least equally well protected as the private seed itself. Note that implementations can choose to not store ikm_bl or ikm_kem if the resulting pk and sk are instead stored directly. See also for discussion of nondeterministic variants that eliminate the ikm_bl and ikm_kem parameters; note however that the same considerations apply to any and all random entropy used to replace them.
• The arguments to ARKG-Derive-Public-Key, and all intermediate variables used during its execution, do not need to be kept confidential for private key security to hold. No special protection of them is needed during execution of ARKG-Derive-Public-Key, they do not need to be securely erased, and no additional protection is needed for outputs in transit between subordinate party and delegating party. The private key derived by ARKG-Derive-Public-Key remains secure even if ARKG-Derive-Public-Key is executed entirely in public. However, some of these values enable varying levels of attack on privacy or public key unlinkability if known. Some of them ultimately become private key material, so they should not be revealed unnecessarily. The subsequent list items expand on these considerations.
• The ikm argument to ARKG-Derive-Public-Key determines ikm_tau and therefore tau. ikm must therefore be confidential for public key unlinkability to hold; the considerations in also apply to ikm. Since ikm is used to derive private key material, it should not be revealed unnecessarily. See also for discussion of nondeterministic variants that eliminate the ikm parameters; note however that the same considerations apply to any and all random entropy used to replace it.
• The ctx argument to ARKG-Derive-Public-Key and ARKG-Derive-Private-Key is fuctionally similar to ikm, but intended for domain separation rather than a primary entropy source. It is not intended to be kept confidential and can safely be a public constant, or an application constant appended with a key index, or similar.
• The pk' output from ARKG-Derive-Public-Key may safely be made public, but may become a correlation handle if the same pk' is shared with multiple recipients. Privacy considerations for public keys in general apply.
• The kh output from ARKG-Derive-Public-Key does not need to be kept confidential, but - unlike the pk' output - also does not need to be revealed to third parties. It should not be revealed unnecessarily since it encodes private key material.
• The kh argument to ARKG-Derive-Private-Key is equivalent to the kh output from ARKG-Derive-Public-Key; the same considerations apply.
• The values prk, mk and k in the procedures of do not need to be kept confidential for private key security to hold, but knowledge of at least one of them enables distinguishing the kh output produced by that execution of ARKG-Derive-Public-Key. This could enable a limited de-anonymization attack against that particular kh value. k should not be revealed unnecessarily since it encodes private key material.

KEM Ciphertext Integrity requires that the KEM scheme guarantees ciphertext integrity, meaning that a valid KEM ciphertext can be created only with knowledge of the KEM public key. This is not a security requirement; failure to satisfy this property does not weaken either of the security properties discussed in . It may however degrade the correctness of the ARKG instance, as explained in , potentially causing protocol failures that may be difficult to troubleshoot or for end-users to understand.

Privacy Considerations

Public Seed Secrecy The security properties described in hold even if the ARKG public seed is publicly known, as the name suggests, but there are situations when it may nevertheless be desirable to keep an ARKG public seed confidential.

• If ARKG is used to derive multiple "pseudonym" public keys, then the public seed is a correlation handle that may reveal that some pseudonyms are related, even without conclusive proof that they were derived from that seed. The public seed should therefore not be revealed along with such pseudonyms.
• Knowledge of an ARKG public seed is sufficient to derive public keys from it, and prove that they were derived from that seed by revealing tau (see ). A malicious actor could use this to, for example:
  • make purchases at the seed owner's expense, if the seller does not require proof of private key possession at the time of the purchase.
  • accuse the seed owner of wrongdoing by planting incriminating keys in their name.
  To prevent such and other abuse, it is prudent to keep the public seed confidential.
• Knowledge of the KEM component of an ARKG public seed is sufficient to generate ARKG key handles valid for that ARKG private seed. If this is undesirable - for example if it could lead to the delegating party being overloaded - then the KEM component of the public seed should be kept confidential.

IANA Considerations

COSE Key Types Registrations This section registers the following values in the IANA "COSE Key Types" registry .

• Name: ARKG-pub
  • Value: TBD (Placeholder -65537)
  • Description: ARKG public seed
  • Capabilities: [kty(-65537), pk_bl, pk_kem]
  • Reference: of this document

COSE Key Type Parameters Registrations This section registers the following values in the IANA "COSE Key Type Parameters" registry .

• Key Type: TBD (ARKG-pub, placeholder -65537)
  • Name: pk_bl
  • Label: -1
  • CBOR Type: COSE_Key
  • Description: ARKG key blinding public key
  • Reference: of this document
• Key Type: TBD (ARKG-pub, placeholder -65537)
  • Name: pk_kem
  • Label: -2
  • CBOR Type: COSE_Key
  • Description: ARKG key encapsulation public key
  • Reference: of this document

COSE Algorithms Registrations This section registers the following values in the IANA "COSE Algorithms" registry .

• Name: ARKG-P256
  • Value: TBD (placeholder -65700)
  • Description: ARKG using ECDH and additive blinding on secp256r1
  • Reference: of this document
  • Recommended: TBD
• Name: ARKG-P384
  • Value: TBD (placeholder -65701)
  • Description: ARKG using ECDH and additive blinding on secp384r1
  • Reference: of this document
  • Recommended: TBD
• Name: ARKG-P521
  • Value: TBD (placeholder -65702)
  • Description: ARKG using ECDH and additive blinding on secp521r1
  • Reference: of this document
  • Recommended: TBD
• Name: ARKG-P256k
  • Value: TBD (placeholder -65703)
  • Description: ARKG using ECDH and additive blinding on secp256k1
  • Reference: of this document
  • Recommended: TBD
• Name: ESP256-ARKG
  • Value: TBD
  • Description: ESP256 using private key derived by ARKG-P256
  • Reference: , of this document
  • Recommended: TBD
• Name: ESP256-split-ARKG
  • Value: TBD (placeholder -65539)
  • Description: ESP256-split using private key derived by ARKG-P256
  • Reference: , of this document
  • Recommended: TBD
• Name: ESP384-ARKG
  • Value: TBD
  • Description: ESP384 using private key derived by ARKG-P384
  • Reference: , of this document
  • Recommended: TBD
• Name: ESP384-split-ARKG
  • Value: TBD
  • Description: ESP384-split using private key derived by ARKG-P384
  • Reference: , of this document
  • Recommended: TBD
• Name: ESP512-ARKG
  • Value: TBD
  • Description: ESP512 using private key derived by ARKG-P521
  • Reference: , of this document
  • Recommended: TBD
• Name: ESP512-split-ARKG
  • Value: TBD
  • Description: ESP512-split using private key derived by ARKG-P521
  • Reference: , of this document
  • Recommended: TBD
• Name: ESP256K-ARKG
  • Value: TBD
  • Description: ESP256K using private key derived by ARKG-P256k
  • Reference: , of this document
  • Recommended: TBD

COSE Signing Arguments Algorithm Parameters Registrations This section registers the following values in the IANA "COSE Signing Arguments Algorithm Parameters" registry :

• Name: kh
  • Label: -1
  • Type: bstr
  • Required: yes
  • Algorithm: ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ES256K-ARKG
  • Description: kh argument to ARKG-Derive-Private-Key.
  • Capabilities: [alg(-65539, TBD)]
  • Change Controller: IETF
  • Reference: of this document
• Name: ctx
  • Label: -2
  • Type: bstr
  • Required: yes
  • Algorithm: ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ES256K-ARKG
  • Description: ctx argument to ARKG-Derive-Private-Key.
  • Capabilities: [alg(-65539, TBD)]
  • Change Controller: IETF
  • Reference: of this document

Design rationale

Using a MAC The ARKG construction by Stebila et al. omits the MAC and instead encodes application context in the PRF labels, arguing that this leads to invalid keys/signatures in cases that would have a bad MAC. We choose to keep the MAC from the construction by Frymann et al. , but allow it to be omitted in case the chosen KEM already guarantees ciphertext integrity. The reason for this is to ensure that the delegating party can distinguish key handles that belong to its ARKG seed. For example, this is important for applications using the W3C Web Authentication API , which do not know beforehand which authenticators are connected and available. Instead, authentication requests may include references to several eligible authenticators, and the one to use is chosen opportunistically by the WebAuthn client depending on which are available at the time. Consider using ARKG in such a scenario to sign some data with a derived private key: a user may have several authenticators and thus several ARKG seeds, so the signing request might include several well-formed ARKG key handles, but only one of them belongs to the ARKG seed of the authenticator that is currently connected. Without an integrity check, choosing the wrong key handle might cause the ARKG-Derive-Private-Key procedure to silently derive the wrong key instead of returning an explicit error, which would in turn lead to an invalid signature or similar final output. This would make it difficult or impossible to diagnose the root cause of the issue and present actionable user feedback. For this reason, we require the KEM to guarantee ciphertext integrity so that ARKG-Derive-Private-Key can fail early if the key handle belongs to a different ARKG seed. It is straightforward to see that adding the MAC to the construction by Wilson does not weaken the security properties defined by Frymann et al. : the construction by Frymann et al. can be reduced to the ARKG construction in this document by instantiating BL as described in and KEM as described in . The use of hash_to_field in corresponds to the KDF₁ parameter in , and the use of HMAC and HKDF in corresponds to the MAC and KDF₂ parameters in . Hence if one can break PK-unlinkability or SK-security of the ARKG construction in this document, one can also break the same property of the construction by Frymann et al.

Implementation Status This section is to be removed from the specification by the RFC Editor before publication as an RFC. There are currently two known implementations using features defined by this specification:

• wwWallet, an EU Digital Identity pilot project. wwWallet was entered into the "EUDI Wallet Prototypes" competition held by SprinD GmbH, and a branch of the wallet was submitted in the competition. The competition entry implements ARKG for efficiently generating single-use hardware-bound holder binding keys. The implementation uses the COSE_Key_Ref data structure defined in an earlier version of (version -01 of the Individual-Draft I-D.draft-lundberg-cose-two-party-signing-algs-01) in order to send ARKG inputs to a WebAuthn authenticator, and uses the placeholder value for ESP256-split-ARKG defined in to negotiate creation and usage of ARKG-derived keys for signing operations. Work to update the implementation to instead use COSE_Sign_Args as defined in is ongoing.
• Yubico, a hardware security key vendor, has produced limited-availability prototypes of their YubiKey product with an ARKG implementation interoperable with wwWallet. The YubiKey implementation uses the COSE_Sign_Args data structure defined in to receive ARKG inputs from a WebAuthn Relying Party, and uses the placeholder value for ESP256-split-ARKG defined in to negotiate creation and usage of ARKG-derived keys for signing operations.

summarizes implementation status for individual features. Implementation status of individual features.

Feature	Implementations
ARKG-P256	wwWallet, Yubico
ARKG-P384	-
ARKG-P521	-
ARKG-P256k	-
ESP256-ARKG	-
ESP256-split-ARKG	wwWallet, Yubico
ESP384-ARKG	-
ESP384-split-ARKG	-
ESP512-ARKG	-
ESP512-split-ARKG	-
ES256K-ARKG	-
COSE_Sign_Args	wwWallet, Yubico

Related Internet-Drafts Parts of this specification depend upon definitions from :

• The algorithm identifiers ESP256-split-ARKG, ESP384-split-ARKG and ESP512-split-ARKG defined in depend respectively on the algorithm identifiers ESP256-split, ESP384-split and ESP512-split defined in .
• The ARKG-specific COSE_Sign_Args parameter definitions in depend on for the definition of the COSE_Sign_Args structure.

Future Work Hierarchical Deterministic Keys (HDK) is a possible application of ARKG which has identified a limitation in the present construction, as discussed in HDK GitHub issue #94. ARKG can be used recursively - for example, ARKG-P256 can be used to derive P-256 keys that are themselves used as ARKG seeds - but then requires one invocation of ARKG-Derive-Private-Key per layer of recursion in order to derive higher-layer private keys. This can be an issue if the base ARKG private seed is hardware-bound, since it would require multiple calls to the secure hardware device, especially if each of those calls requires a user gesture for authorization. Therefore a modified ARKG construction has been proposed, along with a draft for a potential security proof, which enables multiple layers of recursive ARKG to be condensed into a single invocation of ARKG-Derive-Private-Key. We would have liked to use this modified construction in this specification, but have not been able to get the potential proof appropriately peer reviewed in a timely manner, so prototypes have moved forward with the present construction. The modified construction may be revisited in the future if there is demand for applications, in which case new algorithm identifiers and such can be defined for the modified construction.

References Normative References Yubico Self-Issued Consulting This specification defines COSE algorithm identifiers for negotiating how to split a signature algorithm between two cooperating parties. Typically the first party hashes the data to be signed and the second party finishes the signature over the hashed data. This is a common technique, useful for example when the signing private key is held in a smart card or similar hardware component with limited processing power and communication bandwidth. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification algorithm without additional steps to preprocess the signed data. IANA Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

National Institute of Standards and Technology Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind 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. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. Certicom Research Certicom Research 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Cleverbase Hierarchical Deterministic Keys enables managing large sets of keys bound to a secure cryptographic device that protects a single key. This enables the development of secure digital identity wallets providing many one-time-use public keys. Some instantiations can be implemented in such a way that the secure cryptographic device does not need to support key blinding, enabling the use of devices that already are widely deployed. Technische Universität Darmstadt IBM Zurich Research Lab University of Waterloo University of Waterloo

Test Vectors This section lists test vectors for validating implementations. Test vectors are listed in CDDL syntax using variable names defined in and . Elliptic curve points are encoded using the Elliptic-Curve-Point-to-Octet-String procedure defined in section 2.3.3 of , without point compression.

ARKG-P256

Acknowledgements ARKG was first proposed under this name by Frymann et al. , who analyzed a proposed extension to W3C Web Authentication by Lundberg and Nilsson , which was in turn inspired by a similar construction by Wuille used to create privacy-preserving Bitcoin addresses. Frymann et al. generalized the constructions by Lundberg, Nilsson and Wuille from elliptic curves to any discrete logarithm (DL) problem, and also proved the security of arbitrary asymmetric protocols composed with ARKG. Further generalizations to include quantum-resistant instantiations were developed independently by Brendel et al. , Frymann et al. and Wilson . This document adopts the construction proposed by Wilson , modified by the inclusion of a MAC in the key handles as done in the original construction by Frymann et al. . The construction by Wilson was later refined by Stebila et al. , but this revision replaced the "key blinding scheme" component with a "key-blinding signature scheme" component which is not one-for-one compatible with the construction in the present revision of this specification. The authors would like to thank all of these authors for their research and development work that led to the creation of this document.

Document History -11 * Editorial fixes. * Clarified meaning of COSE algorithm identifiers for signing algorithms, and added "walk-through" examples of usage. * Added subsection "Security Properties" to Security Considerations. * Added subsection "Secret Values" to Security Considerations. * Added subsection "KEM Ciphertext Integrity" to Security Considerations. * Added subsection "Public Seed Secrecy" to Privacy Considerations. * Updated "Split Signing Algorithms for COSE" reference from individual-draft to WG draft. * Fixed undefined references WebAuthn, FIPS 180-4 and FIPS 202. -10

• Fixed tau misspelled as tau' in body of BL-Blind-Private-Key in section "Using elliptic curve addition for key blinding".
• Fixed definitions and references misspelling ESP512 as ESP521.
• Minor editorial clarifications.
• Updated informative references to research papers and changed citation style for the same.
• Made "Acknowledgements" and "Document History" sections un-numbered.
• Added Implementation Status section.

-09

• Fixed hash_to_field argument ikm_tau misnamed as tau in section "Using elliptic curve addition for key blinding".
• Updated to match draft -02 of I-D.draft-lundberg-cose-two-party-signing-algs-02.
  • COSE algorithm identifier definitions for ARKG instances moved from section "COSE key type: ARKG public seed" to new section "COSE algorithms".
  • Added COSE algorithm identifier definitions for signature algorithms with key derived using ARKG.
  • COSE key type Ref-ARKG-Derived deleted in favour of new COSE_Sign_Args algorithm parameters.
  • Section "COSE key reference type: ARKG derived private key" replaced with "COSE signing arguments".
  • Added section "COSE Signing Arguments Algorithm Parameters Registrations".

-08

• Fixed incorrectly swapped ikm_bl and ikm_kem arguments in ARKG-Derive-Seed definition.
• Extracted parameter function BL-PRF and modified signatures of BL-Blind-Public-Key and BL-Blind-Private-Key accordingly. This is an editorial refactorization; overall operation of concrete ARKG instances is unchanged.
• Removed three redundant sets of ARKG-P256 test vectors.
• Added intermediate values to ARKG-P256 test vectors.
• Changed second set of ARKG-P256 test vectors to use a 32-byte ikm instead of h'00'.
• Clarified in sections "Using HMAC to adapt a KEM without ciphertext integrity", "Using ECDH as the KEM" and "Using X25519 or X448 as the KEM" that ctx_sub is intentionally ignored in those instances.

-07

• Fixed hash_to_field DST in Sub-Kem-Derive-Key-Pair in section "Using ECDH as the KEM" to agree with test vectors.

-06

• Changed DST construction in section "Using ECDH as the KEM" to include the "ARKG-ECDH." prefix everywhere in the formula. Previously the prefix was added in the argument to the "Using HMAC to adapt a KEM without ciphertext integrity" formula but not in the Sub-Kem functions defined in "Using ECDH as the KEM".

-05

• Deleted concrete instances ARKG-curve25519ADD-X25519, ARKG-curve448ADD-X448, ARKG-edwards25519ADD-X25519 and ARKG-edwards448ADD-X448 since implementations with a non-prime order generator, including EdDSA, are incompatible with the additive blinding scheme defined in section "Using elliptic curve addition for key blinding".
• Remodeled procedures to be fully deterministic:
  • BL-Generate-Keypair() replaced with BL-Derive-Key-Pair(ikm).
  • KEM-Generate-Keypair() replaced with KEM-Derive-Key-Pair(ikm).
  • ARKG-Generate-Seed() replaced with ARKG-Derive-Seed(ikm_bl, ikm_kem).
  • Parameter ikm added to ARKG-Derive-Public-Key.
  • Instance parameter hash-to-crv-suite added to generic formula "Using ECDH as the KEM", affecting concrete instances ARKG-P256ADD-ECDH, ARKG-P384ADD-ECDH, ARKG-P521ADD-ECDH and ARKG-P256kADD-ECDH.
  • Section "Deterministic key generation" deleted.
• Flipped order of (pk_bl, pk_kem) and (sk_bl, sk_kem) parameter and return value tuples for consistent ordering between BL and KEM throughout document.
• info parameter renamed to ctx.
• ctx length limited to at most 64 bytes.
• Encoding of ctx in ARKG-Derive-Public-Key and ARKG-Derive-Private-Key now embeds the length of ctx.
• Renamed concrete instances and corresponding DST_ext values:
  • ARKG-P256ADD-ECDH to ARKG-P256
  • ARKG-P384ADD-ECDH to ARKG-P384
  • ARKG-P521ADD-ECDH to ARKG-P521
  • ARKG-P256kADD-ECDH to ARKG-P256k
• Added ARKG-P256 test vectors.

-04

• Extracted COSE_Key_Ref definition and COSE algorithm registrations to draft-lundberg-cose-two-party-signing-algs.
• Redefined alg (3) parameter and added dkalg (-3) in ARKG-pub COSE_Key.
• Defined alg (3) and inst (-3) parameters of Ref-ARKG-derived COSE key type.

-03

• Renamed section "Using HMAC to adapt a KEM without {integrity protection => ciphertext integrity}".
• Fixed info argument to HMAC in section "Using HMAC to adapt a KEM without ciphertext integrity".
• Added reference to Shoup for definition of key encapsulation mechanism.
• Added CDDL definition of COSE_Key_Ref.
• Editorial fixes to references.
• Renamed proposed COSE Key Types.

-02

• Rewritten introduction.
• Renamed ARKG-Derive-Secret-Key to ARKG-Derive-Private-Key.
• Overhauled EC instantiations to use hash_to_field and account for non-prime order curve key generation.
• Eliminated top-level MAC and KDF instance parameters.
• Added info parameter to instance parameter functions.
• Added requirement of KEM ciphertext integrity and generic formula for augmenting any KEM using HMAC.
• Added curve/edwards25519/448 instances.
• Added proposal for COSE bindings and key reference types.

-01

• Editorial fixes to formatting and references

-00

• Initial Version

Contributors Yubico

Agency for Digital Government

SE

Self-Issued Consulting

United States https://self-issued.info/

Cleverbase

NL