Crypto Forum E. Lundberg, Ed. Internet-Draft J. Bradley Intended status: Informational Yubico Expires: 9 October 2025 7 April 2025 The Asynchronous Remote Key Generation (ARKG) algorithm draft-bradleylundberg-cfrg-arkg-05 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bradleylundberg-cfrg-arkg/. Source for this draft and an issue tracker can be found at https://github.com/Yubico/arkg-rfc. 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/. Lundberg & Bradley Expires 9 October 2025 [Page 1] Internet-Draft ARKG April 2025 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 9 October 2025. Copyright Notice Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 2. The Asynchronous Remote Key Generation (ARKG) algorithm . . . 5 2.1. Instance parameters . . . . . . . . . . . . . . . . . . . 6 2.2. The function ARKG-Derive-Seed . . . . . . . . . . . . . . 8 2.2.1. Nondeterministic variants . . . . . . . . . . . . . . 8 2.3. The function ARKG-Derive-Public-Key . . . . . . . . . . . 9 2.3.1. Nondeterministic variants . . . . . . . . . . . . . . 10 2.4. The function ARKG-Derive-Private-Key . . . . . . . . . . 10 2.5. Using ctx values longer than 64 bytes . . . . . . . . . . 12 3. Generic ARKG instantiations . . . . . . . . . . . . . . . . . 12 3.1. Using elliptic curve addition for key blinding . . . . . 12 3.2. Using HMAC to adapt a KEM without ciphertext integrity . 14 3.3. Using ECDH as the KEM . . . . . . . . . . . . . . . . . . 16 3.4. Using X25519 or X448 as the KEM . . . . . . . . . . . . . 17 3.5. Using the same key for both key blinding and KEM . . . . 18 4. Concrete ARKG instantiations . . . . . . . . . . . . . . . . 18 4.1. ARKG-P256 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. ARKG-P384 . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. ARKG-P521 . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4. ARKG-P256k . . . . . . . . . . . . . . . . . . . . . . . 20 5. COSE bindings . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. COSE key type: ARKG public seed . . . . . . . . . . . . . 21 5.2. COSE key reference type: ARKG derived private key . . . . 23 Lundberg & Bradley Expires 9 October 2025 [Page 2] Internet-Draft ARKG April 2025 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.1. COSE Key Types Registrations . . . . . . . . . . . . . . 25 8.2. COSE Key Type Parameters Registrations . . . . . . . . . 26 8.3. COSE Algorithms Registrations . . . . . . . . . . . . . . 27 9. Design rationale . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Using a MAC . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Implementation Status . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 32 B.1. ARKG-P256 . . . . . . . . . . . . . . . . . . . . . . . . 32 B.2. Other instances . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Document History . . . . . . . . . . . . . . . . . . 36 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. 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. Lundberg & Bradley Expires 9 October 2025 [Page 3] Internet-Draft ARKG April 2025 * *Enhanced forward secrecy*: The use of ARKG can facilitate forward secrecy in certain contexts. For instance, section 8.5.4 of RFC 9052 (https://www.rfc-editor.org/rfc/rfc9052.html#name-direct-key- agreement) notes that "Since COSE is designed for a store-and- forward environment rather than an online environment, [...] forward secrecy (see [RFC4949]) 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 the sender to generate ephemeral recipient public keys on demand. * *Backup key generation*: For example, the W3C Web Authentication API [WebAuthn] (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. [Wilson] Lundberg & Bradley Expires 9 October 2025 [Page 4] Internet-Draft ARKG April 2025 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. 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 Section 3.1 of [RFC8610]. * 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 Section 4.1 of [RFC8017]. 2. 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 [Frymann2020] [Wilson] [Clermont]. 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. Lundberg & Bradley Expires 9 October 2025 [Page 5] Internet-Draft ARKG April 2025 The following subsections define the abstract instance parameters used to construct the three ARKG functions, followed by the definitions of the three ARKG functions. 2.1. Instance parameters ARKG is composed of a suite of other algorithms. The parameters of an ARKG instance are: * BL: An asymmetric key blinding scheme [Wilson], consisting of: - Function BL-Derive-Key-Pair(ikm) -> (pk, sk): Derive 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-Blind-Public-Key(pk, tau, ctx) -> pk_tau: Deterministically compute a blinded public key. Input consists of a blinding public key pk, a blinding factor tau and a domain separation parameter ctx. Output consists of the blinded public key pk_tau. - Function BL-Blind-Private-Key(sk, tau, ctx) -> sk_tau: Deterministically compute a blinded private key. Input consists of a blinding private key sk, a blinding factor tau and a domain separation parameter ctx. 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. tau and ctx are opaque octet strings of arbitrary length. The representations of pk and pk_tau are defined by the protocol that invokes ARKG. The representations of sk and sk_tau are an undefined implementation detail. See [Wilson] for definitions of security properties required of the key blinding scheme BL. * KEM: A key encapsulation mechanism [Shoup], consisting of the functions: Lundberg & Bradley Expires 9 October 2025 [Page 6] Internet-Draft ARKG April 2025 - 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. Section 3.2 describes a general formula for how any KEM can be adapted to include this guarantee. Section 9.1 discusses the reasons for this requirement. See [Wilson] 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. Lundberg & Bradley Expires 9 October 2025 [Page 7] Internet-Draft ARKG April 2025 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. 2.2. 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. ARKG-Derive-Seed(ikm_bl, ikm_kem) -> (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_kem, sk_kem) = KEM-Derive-Key-Pair(ikm_bl) (pk_bl, sk_bl) = BL-Derive-Key-Pair(ikm_kem) pk = (pk_bl, pk_kem) sk = (sk_bl, sk_kem) 2.2.1. 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. Lundberg & Bradley Expires 9 October 2025 [Page 8] Internet-Draft ARKG April 2025 2.3. 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. ARKG-Derive-Public-Key((pk_bl, pk_kem), ikm, ctx) -> (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' (tau, c) = KEM-Encaps(pk_kem, ikm, ctx_kem) pk' = BL-Blind-Public-Key(pk_bl, tau, ctx_bl) 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. Lundberg & Bradley Expires 9 October 2025 [Page 9] Internet-Draft ARKG April 2025 See Section 2.5 for guidance on using ctx arguments longer than 64 bytes. 2.3.1. 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. BL-Blind-Public-Key must always be deterministic for compatibility with ARKG-Derive-Private-Key. 2.4. 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. Lundberg & Bradley Expires 9 October 2025 [Page 10] Internet-Draft ARKG April 2025 ARKG-Derive-Private-Key((sk_bl, sk_kem), kh, ctx) -> 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' tau = KEM-Decaps(sk_kem, kh, ctx_kem) If decapsulation failed: Abort with an error. sk' = BL-Blind-Private-Key(sk_bl, tau, ctx_bl) 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 Section 9.1. See Section 2.5 for guidance on using ctx arguments longer than 64 bytes. Lundberg & Bradley Expires 9 October 2025 [Page 11] Internet-Draft ARKG April 2025 2.5. 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 Section 5.3.3 of [RFC9380]. Precise procedure definitions are left as an application- specific implementation detail. 3. Generic ARKG instantiations This section defines generic formulae for instantiating the individual ARKG parameters, which can be used to define concrete ARKG instantiations. 3.1. 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 [Frymann2020] [Wilson]. 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 [RFC9380] 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 Section 5 of [RFC9380]. Lundberg & Bradley Expires 9 October 2025 [Page 12] Internet-Draft ARKG April 2025 BL-Derive-Key-Pair(ikm) -> (pk, sk) sk = hash_to_field(ikm, 1) with the parameters: DST: 'ARKG-BL-EC-KG.' || DST_ext 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-Blind-Public-Key(pk, tau, ctx) -> pk_tau tau' = hash_to_field(tau, 1) with the parameters: DST: 'ARKG-BL-EC.' || DST_ext || ctx 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_tau = pk + tau' * G BL-Blind-Private-Key(sk, tau, ctx) -> sk_tau tau' = hash_to_field(tau, 1) with the parameters: DST: 'ARKG-BL-EC.' || DST_ext || ctx 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 sk_tau_tmp = sk + tau' If sk_tau_tmp = 0, abort with an error. sk_tau = sk_tau_tmp Lundberg & Bradley Expires 9 October 2025 [Page 13] Internet-Draft ARKG April 2025 3.2. 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 Section 2.1, 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 [RFC2104] and HKDF [RFC5869] 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 Section 9.1, 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. KEM-Derive-Key-Pair(ikm) -> (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 Lundberg & Bradley Expires 9 October 2025 [Page 14] Internet-Draft ARKG April 2025 (k', c') = Sub-Kem-Encaps(pk, ikm, 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') 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. 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: Lundberg & Bradley Expires 9 October 2025 [Page 15] Internet-Draft ARKG April 2025 Abort with an error. 3.3. Using ECDH as the KEM Instantiations of ARKG can use ECDH [RFC6090] as the key encapsulation mechanism KEM [Frymann2020] [Wilson]. 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 [RFC6090]. * Hash: A cryptographic hash function. * hash-to-crv-suite: A hash-to-curve suite [RFC9380] suitable for hashing to the scalar field of crv. * DST_ext: A domain separation parameter. The KEM parameter of ARKG may be instantiated as described in section Section 3.2 with the parameters: * Hash: Hash. * DST_ext: 'ARKG-ECDH.' || DST_ext. * 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 [SEC1], without point compression. - ECDH(pk, sk) represents the compact output of ECDH [RFC6090] 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. Lundberg & Bradley Expires 9 October 2025 [Page 16] Internet-Draft ARKG April 2025 Sub-Kem-Derive-Key-Pair(ikm) -> (pk, sk) sk = hash_to_field(ikm, 1) with the parameters: DST: 'ARKG-KEM-ECDH-KG.' || DST_ext 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) 3.4. Using X25519 or X448 as the KEM Instantiations of ARKG can use X25519 or X448 [RFC7748] 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 [RFC7748]. * DST_ext: A domain separation parameter. The KEM parameter of ARKG may be instantiated as described in section Section 3.2 with the parameters: * Hash: SHA-512 [FIPS 180-4] if DH-Function is X25519, or SHAKE256 [FIPS 202] with output length 64 octets if DH-Function is X448. * DST_ext: 'ARKG-ECDHX.' || DST_ext. Lundberg & Bradley Expires 9 October 2025 [Page 17] Internet-Draft ARKG April 2025 * 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. Sub-Kem-Derive-Key-Pair(ikm) -> (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) 3.5. 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 Section 3.1 and ECDH is used as the KEM as described in Section 3.3 [Frymann2020] - 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. 4. Concrete ARKG instantiations This section defines an initial set of concrete ARKG instantiations. TODO: IANA registry? COSE/JOSE? Lundberg & Bradley Expires 9 October 2025 [Page 18] Internet-Draft ARKG April 2025 4.1. ARKG-P256 The identifier ARKG-P256 represents the following ARKG instance: * BL: Elliptic curve addition as described in Section 3.1 with the parameters: - crv: The NIST curve secp256r1 [SEC2]. - hash-to-crv-suite: P256_XMD:SHA-256_SSWU_RO_ [RFC9380]. - DST_ext: 'ARKG-P256'. * KEM: ECDH as described in Section 3.3 with the parameters: - crv: The NIST curve secp256r1 [SEC2]. - Hash: SHA-256 [FIPS 180-4]. - hash-to-crv-suite: P256_XMD:SHA-256_SSWU_RO_ [RFC9380]. - 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. 4.2. ARKG-P384 The identifier ARKG-P384 represents the following ARKG instance: * BL: Elliptic curve addition as described in Section 3.1 with the parameters: - crv: The NIST curve secp384r1 [SEC2]. - hash-to-crv-suite: P384_XMD:SHA-384_SSWU_RO_ [RFC9380]. - DST_ext: 'ARKG-P384'. * KEM: ECDH as described in Section 3.3 with the parameters: - crv: The NIST curve secp384r1 [SEC2]. - Hash: SHA-384 [FIPS 180-4]. - hash-to-crv-suite: P384_XMD:SHA-384_SSWU_RO_ [RFC9380]. - DST_ext: 'ARKG-P384'. Lundberg & Bradley Expires 9 October 2025 [Page 19] Internet-Draft ARKG April 2025 Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG instance SHOULD contain at least 384 bits of entropy. 4.3. ARKG-P521 The identifier ARKG-P521 represents the following ARKG instance: * BL: Elliptic curve addition as described in Section 3.1 with the parameters: - crv: The NIST curve secp521r1 [SEC2]. - hash-to-crv-suite: P521_XMD:SHA-512_SSWU_RO_ [RFC9380]. - DST_ext: 'ARKG-P521'. * KEM: ECDH as described in Section 3.3 with the parameters: - crv: The NIST curve secp521r1 [SEC2]. - Hash: SHA-512 [FIPS 180-4]. - hash-to-crv-suite: P521_XMD:SHA-512_SSWU_RO_ [RFC9380]. - 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. 4.4. ARKG-P256k The identifier ARKG-P256k represents the following ARKG instance: * BL: Elliptic curve addition as described in Section 3.1 with the parameters: - crv: The SECG curve secp256k1 [SEC2]. - hash-to-crv-suite: secp256k1_XMD:SHA-256_SSWU_RO_ [RFC9380]. - DST_ext: 'ARKG-P256k'. * KEM: ECDH as described in Section 3.3 with the parameters: - crv: The SECG curve secp256k1 [SEC2]. - Hash: SHA-256 [FIPS 180-4]. Lundberg & Bradley Expires 9 October 2025 [Page 20] Internet-Draft ARKG April 2025 - hash-to-crv-suite: secp256k1_XMD:SHA-256_SSWU_RO_ [RFC9380]. - 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. 5. COSE bindings This section proposes additions to COSE [RFC9052] to support ARKG use cases. These consist of new key type definitions to represent ARKG public seeds and references [I-D.lundberg-cose-2p-algs] to private keys derived using ARKG. 5.1. COSE key type: ARKG public seed An ARKG public seed is represented as a COSE_Key structure [RFC9052] with kty value TBD (placeholder value -65537). Table 1 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. +=======+=======+==========+===========+============================+ | Name | Label | Value | Required? | Description | | | | type | | | +=======+=======+==========+===========+============================+ | 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 / | Optional | alg parameter of | | | | tstr | | public and private | | | | | | keys derived from | | | | | | this ARKG public seed | +-------+-------+----------+-----------+----------------------------+ Table 1: COSE key type parameters for the ARKG-pub key type. 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. Table 2 defines an initial set of COSE algorithm identifiers for this purpose. Lundberg & Bradley Expires 9 October 2025 [Page 21] Internet-Draft ARKG April 2025 +============+==================+==============================+ | Name | Value | Description | +============+==================+==============================+ | ARKG-P256 | TBD (placeholder | The ARKG instance defined in | | | -65700) | Section 4.1 of this document | +------------+------------------+------------------------------+ | ARKG-P384 | TBD (placeholder | The ARKG instance defined in | | | -65701) | Section 4.2 of this document | +------------+------------------+------------------------------+ | ARKG-P521 | TBD (placeholder | The ARKG instance defined in | | | -65702) | Section 4.3 of this document | +------------+------------------+------------------------------+ | ARKG-P256k | TBD (placeholder | The ARKG instance defined in | | | -65703) | Section 4.4 of this document | +------------+------------------+------------------------------+ Table 2: COSE algorithm identifiers to represent ARKG instances. The following CDDL [RFC8610] example represents an ARKG-P256 public seed restricted to generating derived keys for use with the ESP256 [I-D.jose-fully-spec-algs] signature algorithm: Lundberg & Bradley Expires 9 October 2025 [Page 22] Internet-Draft ARKG April 2025 { 1: -65537, ; kty: ARKG-pub (placeholder value) ; kid: Opaque identifier 2: h'60b6dfddd31659598ae5de49acb220d8 704949e84d484b68344340e2565337d2', 3: -65700, ; alg: ARKG-P256 (placeholder value) -1: { ; BL public key 1: 2, ; kty: EC2 -1: 1, ; crv: P256 -2: h'69380FC1C3B09652134FEEFBA61776F9 7AF875CE46CA20252C4165102966EBC5', -3: h'8B515831462CCB0BD55CBA04BFD50DA6 3FAF18BD845433622DAF97C06A10D0F1', }, -2: { ; KEM public key 1: 2, ; kty: EC2 -1: 1, ; crv: P256 -2: h'5C099BEC31FAA581D14E208250D3FFDA 9EC7F543043008BC84967A8D875B5D78', -3: h'539D57429FCB1C138DA29010A155DCA1 4566A8F55AC2F1780810C49D4ED72D58', }, -3: -9 ; Derived key algorithm: ESP256 } The following is the same example encoded as CBOR: h'a6013a0001000002582060b6dfddd31659598ae5de49acb220d8704949e84d48 4b68344340e2565337d2033a000100a320a40102200121582069380fc1c3b096 52134feefba61776f97af875ce46ca20252c4165102966ebc52258208b515831 462ccb0bd55cba04bfd50da63faf18bd845433622daf97c06a10d0f121a40102 20012158205c099bec31faa581d14e208250d3ffda9ec7f543043008bc84967a 8d875b5d78225820539d57429fcb1c138da29010a155dca14566a8f55ac2f178 0810c49d4ed72d582228' 5.2. COSE key reference type: ARKG derived private key A reference to a private key derived using ARKG may be represented as a COSE_Key_Ref structure [I-D.lundberg-cose-2p-algs] whose kty is TBD (Ref-ARKG-derived, placeholder -65538). This key reference type defines key type parameters -1 and -2 respectively for the kh and ctx parameters of ARKG-Derive-Private-Key. The kid (2) parameter identifies the ARKG private seed sk. Thus the COSE_Key_Ref structure conveys all arguments to use in ARKG-Derive-Private-Key to derive the referenced private key. Lundberg & Bradley Expires 9 October 2025 [Page 23] Internet-Draft ARKG April 2025 Table 3 defines key type parameters for the Ref-ARKG-derived key type. A COSE_Key_Ref structure whose kty is TBD (Ref-ARKG-derived, placeholder -65538) MUST include the parameters kh (-1) and ctx (-2). The inst (-3) parameter MAY be used to indicate the ARKG instance whose ARKG-Derive-Private-Key procedure to use to derive the private key; its value is taken from the IANA "COSE Algorithms" registry [IANA.cose] and an initial set of values is defined in Table 1. If dkalg (-3) is present in the ARKG public seed used in ARKG-Derive- Public-Key to generate the kh value, then the alg (3) parameter of the COSE_Key_Ref SHOULD be set to the dkalg (-3) value of the seed. If alg (3) is present in the seed, then the inst (-3) parameter of the COSE_Key_Ref SHOULD be set to the alg (3) value of the seed. +======+=======+============+===========+===========================+ | Name | Label | Value | Required? | Description | | | | type | | | +======+=======+============+===========+===========================+ | kh | -1 | bstr | Required | kh argument to ARKG- | | | | | | Derive-Private-Key | +------+-------+------------+-----------+---------------------------+ | ctx | -2 | bstr | Required | ctx argument to ARKG- | | | | | | Derive-Private-Key | +------+-------+------------+-----------+---------------------------+ | inst | -3 | int / | Optional | COSE algorithm identifier | | | | tstr | | of ARKG instance | +------+-------+------------+-----------+---------------------------+ Table 3: COSE key type parameters for the Ref-ARKG-derived type. The following CDDL example represents a reference to a key derived using ARKG-P256 and restricted for use with the ESP256 [I-D.jose-fully-spec-algs] signature algorithm: Lundberg & Bradley Expires 9 October 2025 [Page 24] Internet-Draft ARKG April 2025 { 1: -65538, ; kty: Ref-ARKG-derived ; kid: Opaque identifier of ARKG-pub 2: h'60b6dfddd31659598ae5de49acb220d8 704949e84d484b68344340e2565337d2', 3: -9, ; alg: ESP256 ; ARKG-P256 key handle ; (HMAC-SHA-256-128 followed by SEC1 uncompressed ECDH public key) -1: h'ae079e9c52212860678a7cee25b6a6d4 048219d973768f8e1adb8eb84b220b0ee3 a2532828b9aa65254fe3717a29499e9b aee70cea75b5c8a2ec2eb737834f7467 e37b3254776f65f4cfc81e2bc4747a84', ; ctx argument to ARKG-Derive-Private-Key -2: 'Example application info', -3: -65700 ; inst: ARKG-P256 (placeholder value) } The following is the same example encoded as CBOR: h'a6013a0001000102582060b6dfddd31659598ae5de49acb220d8704949e84d48 4b68344340e2565337d20328205851ae079e9c52212860678a7cee25b6a6d404 8219d973768f8e1adb8eb84b220b0ee3a2532828b9aa65254fe3717a29499e9b aee70cea75b5c8a2ec2eb737834f7467e37b3254776f65f4cfc81e2bc4747a84 2158184578616d706c65206170706c69636174696f6e20696e666f223a000100 a3' 6. Security Considerations TODO 7. Privacy Considerations TODO 8. IANA Considerations 8.1. COSE Key Types Registrations This section registers the following values in the IANA "COSE Key Types" registry [IANA.cose]. * Name: ARKG-pub Lundberg & Bradley Expires 9 October 2025 [Page 25] Internet-Draft ARKG April 2025 - Value: TBD (Placeholder -65537) - Description: ARKG public seed - Capabilities: [kty(-65537), pk_bl, pk_kem] - Reference: Section 5.1 of this document * Name: Ref-ARKG-derived - Value: TBD (Placeholder -65538) - Description: Reference to private key derived by ARKG - Capabilities: [kty(-65538), kh, ctx] - Reference: [I-D.lundberg-cose-2p-algs], Section 5.2 of this document These registrations add the following choices to the CDDL [RFC8610] type socket $COSE_kty_ref [I-D.lundberg-cose-2p-algs]: $COSE_kty_ref /= -65538 ; Placeholder value 8.2. COSE Key Type Parameters Registrations This section registers the following values in the IANA "COSE Key Type Parameters" registry [IANA.cose]. * Key Type: TBD (ARKG-pub, placeholder -65537) - Name: pk_bl - Label: -1 - CBOR Type: COSE_Key - Description: ARKG key blinding public key - Reference: Section 5.1 of this document * Key Type: TBD (ARKG-pub, placeholder -65537) - Name: pk_kem - Label: -2 - CBOR Type: COSE_Key Lundberg & Bradley Expires 9 October 2025 [Page 26] Internet-Draft ARKG April 2025 - Description: ARKG key encapsulation public key - Reference: Section 5.1 of this document * Key Type: TBD (Ref-ARKG-derived, placeholder -65538) - Name: kh - Label: -1 - CBOR Type: bstr - Description: kh argument to ARKG-Derive-Private-Key - Reference: [I-D.lundberg-cose-2p-algs], Section 5.2 of this document * Key Type: TBD (Ref-ARKG-derived, placeholder -65538) - Name: ctx - Label: -2 - CBOR Type: bstr - Description: ctx argument to ARKG-Derive-Private-Key - Reference: [I-D.lundberg-cose-2p-algs], Section 5.2 of this document 8.3. COSE Algorithms Registrations This section registers the following values in the IANA "COSE Algorithms" registry [IANA.cose]. * Name: ARKG-P256 - Value: TBD (placeholder -65700) - Description: ARKG using ECDH and additive blinding on secp256r1 - Reference: Section 4.1 of this document - Recommended: TBD * Name: ARKG-P384 - Value: TBD (placeholder -65701) Lundberg & Bradley Expires 9 October 2025 [Page 27] Internet-Draft ARKG April 2025 - Description: ARKG using ECDH and additive blinding on secp384r1 - Reference: Section 4.2 of this document - Recommended: TBD * Name: ARKG-P521 - Value: TBD (placeholder -65702) - Description: ARKG using ECDH and additive blinding on secp521r1 - Reference: Section 4.3 of this document - Recommended: TBD * Name: ARKG-P256k - Value: TBD (placeholder -65703) - Description: ARKG using ECDH and additive blinding on secp256k1 - Reference: Section 4.4 of this document - Recommended: TBD 9. Design rationale 9.1. Using a MAC The ARKG construction by Wilson [Wilson] 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. [Frymann2020], 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 [WebAuthn], 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, Lundberg & Bradley Expires 9 October 2025 [Page 28] Internet-Draft ARKG April 2025 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. [Frymann2020]: the construction by Frymann et al. can be reduced to the ARKG construction in this document by instantiating BL as described in Section 3.1 and KEM as described in Section 3.3. The use of hash_to_field in Section 3.1 corresponds to the KDF_1 parameter in [Frymann2020], and the use of HMAC and HKDF in Section 3.2 corresponds to the MAC and KDF_2 parameters in [Frymann2020]. 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. 9.2. Implementation Status TODO 10. References 10.1. Normative References [I-D.jose-fully-spec-algs] Jones, M. B. and O. Steele, "Fully-Specified Algorithms for JOSE and COSE", Work in Progress, Internet-Draft, draft-ietf-jose-fully-specified-algorithms-09, 2 April 2025, . [I-D.lundberg-cose-2p-algs] Lundberg, E. and M. B. Jones, "COSE Algorithms for Two- Party Signing", Work in Progress, Internet-Draft, draft- lundberg-cose-two-party-signing-algs-01, 3 March 2025, . [IANA.cose] IANA, "CBOR Object Signing and Encryption (COSE)", . Lundberg & Bradley Expires 9 October 2025 [Page 29] Internet-Draft ARKG April 2025 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . Lundberg & Bradley Expires 9 October 2025 [Page 30] Internet-Draft ARKG April 2025 [RFC8812] Jones, M., "CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms", RFC 8812, DOI 10.17487/RFC8812, August 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380, DOI 10.17487/RFC9380, August 2023, . [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 2009, . [SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", 2010, . 10.2. Informative References [BIP32] Wuille, P., "BIP 32 Hierarchical Deterministic Wallets", 2012, . [Clermont] Clermont, S. A., "Post Quantum Asynchronous Remote Key Generation. Master's thesis", 2022, . [Frymann2020] Frymann, N., Gardham, D., Kiefer, F., Lundberg, E., Manulis, M., and D. Nilsson, "Asynchronous Remote Key Generation: An Analysis of Yubico's Proposal for W3C WebAuthn. CCS '20: Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security", 2020, . [Frymann2023] Frymann, N., Gardham, D., and M. Manulis, "Asynchronous Remote Key Generation for Post-Quantum Cryptosystems from Lattices. 2023 IEEE 8th European Symposium on Security and Privacy", 2023, . Lundberg & Bradley Expires 9 October 2025 [Page 31] Internet-Draft ARKG April 2025 [Shoup] Shoup, V., "A Proposal for an ISO Standard for Public Key Encryption (version 2.0)", 2001, . [WebAuthn-Recovery] Lundberg, E. and D. Nilsson, "WebAuthn recovery extension: Asynchronous delegated key generation without shared secrets. GitHub", 2019, . [Wilson] Wilson, S. M., "Post-Quantum Account Recovery for Passwordless Authentication. Master's thesis", 2023, . Appendix A. Acknowledgements ARKG was first proposed under this name by Frymann et al. [Frymann2020], who analyzed a proposed extension to W3C Web Authentication by Lundberg and Nilsson [WebAuthn-Recovery], which was in turn inspired by a similar construction by Wuille [BIP32] used to create privacy-preserving Bitcoin addresses. Frymann et al. [Frymann2020] 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 Clermont [Clermont], Frymann et al. [Frymann2023] and Wilson [Wilson]. This document adopts the construction proposed by Wilson [Wilson], modified by the inclusion of a MAC in the key handles as done in the original construction by Frymann et al. [Frymann2020]. The authors would like to thank all of these authors for their research and development work that led to the creation of this document. Appendix B. Test Vectors This section lists test vectors for validating implementations. Test vectors are listed in CDDL [RFC8610] syntax using parameter and output names defined in Section 2. Elliptic curve points are encoded using the Elliptic-Curve-Point-to-Octet-String procedure defined in section 2.3.3 of [SEC1], without point compression. B.1. ARKG-P256 Lundberg & Bradley Expires 9 October 2025 [Page 32] Internet-Draft ARKG April 2025 ; Inputs: ctx = 'ARKG-P256.test vectors' ikm_bl = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f' ikm_kem = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f' ikm = h'404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f' ; Derive-Seed outputs: pk_bl = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df 65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7' pk_kem = h'042eff91b46617d0628b979405bb871a7593e4b02ec533712bc1cf80d0b0a1ccf3 0ec3b161632183ceedf94fbe35a96e60a17c2c79c6379b141eeeba521ea8030f' sk_bl = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455 sk_kem = 0x4253051878eac98187f1394605a3ef5ce1981e664cea41e8094c7d12c606d906 ; Derive-Public-Key outputs: pk_prime = h'04018fcbb2f920282a321da180efe321307d03ed476883c02199cc563ccc66a077 ec03e52a66d4de13c85187323f0a06b9d90c287ea774457b9362c1f66b6a177e' ;kh = (implementation defined) ; Derive-Private-Key outputs: sk_prime = 0x52cb5af8edfb25fe5e945f5e83cb7929de9459bda95ef68085b5cb9018c5cacc' ; Inputs: ctx = 'ARKG-P256.test vectors' ikm_bl = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f' ikm_kem = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f' ikm = h'00' ; Derive-Seed outputs: pk_bl = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df 65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7' pk_kem = h'042eff91b46617d0628b979405bb871a7593e4b02ec533712bc1cf80d0b0a1ccf3 0ec3b161632183ceedf94fbe35a96e60a17c2c79c6379b141eeeba521ea8030f' sk_bl = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455 sk_kem = 0x4253051878eac98187f1394605a3ef5ce1981e664cea41e8094c7d12c606d906 ; Derive-Public-Key outputs: pk_prime = h'04d54c794c2aaf1883a1e52581320ec70caeba03a5b57f8ebf3ae8b80db1e016a3 79269f8d519890fcc67439b196b0a8e8518b4794feed03b3ded413cd0d3050e3' ;kh = (implementation defined) ; Derive-Private-Key outputs: sk_prime = 0x35e5bae9b0c15765ca4fef9e01433cbd1dd3ba4633c3dd025967fbc1b4421d1c' Lundberg & Bradley Expires 9 October 2025 [Page 33] Internet-Draft ARKG April 2025 ; Inputs: ctx = 'ARKG-P256.test vectors.0' ikm_bl = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f' ikm_kem = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f' ikm = h'404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f' ; Derive-Seed outputs: pk_bl = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df 65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7' pk_kem = h'042eff91b46617d0628b979405bb871a7593e4b02ec533712bc1cf80d0b0a1ccf3 0ec3b161632183ceedf94fbe35a96e60a17c2c79c6379b141eeeba521ea8030f' sk_bl = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455 sk_kem = 0x4253051878eac98187f1394605a3ef5ce1981e664cea41e8094c7d12c606d906 ; Derive-Public-Key outputs: pk_prime = h'047dab2c6ed6cd827750f20487c99d5ac113b6539d0d326bc0ad104a94c4ba3ff3 6f5d3f6e82bdbcf8c404f3c64e2e0a07b1b423f85ee05683f592d63235968c51' ;kh = (implementation defined) ; Derive-Private-Key outputs: sk_prime = 0x02d98cb8ca1ddbe689b75c2e31ba8c1e502977d11f6e28f7493fbba00585d2f0' ; Inputs: ctx = 'ARKG-P256.test vectors.0' ikm_bl = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f' ikm_kem = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f' ikm = h'00' ; Derive-Seed outputs: pk_bl = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df 65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7' pk_kem = h'042eff91b46617d0628b979405bb871a7593e4b02ec533712bc1cf80d0b0a1ccf3 0ec3b161632183ceedf94fbe35a96e60a17c2c79c6379b141eeeba521ea8030f' sk_bl = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455 sk_kem = 0x4253051878eac98187f1394605a3ef5ce1981e664cea41e8094c7d12c606d906 ; Derive-Public-Key outputs: pk_prime = h'04fe2d29db1ffd0e1ef0819500bdbb812b6d8952c0a57a3ba0548910cafeddfce3 da32d503cd074cbed924f5bd78b7bddf0f7593a2256dd6876ecbb0e1a44bbbb6' ;kh = (implementation defined) ; Derive-Private-Key outputs: sk_prime = 0x154bb2b991864eef4b254cd148407f19fc32276056f8281b6c6c455cf00a38c1' Lundberg & Bradley Expires 9 October 2025 [Page 34] Internet-Draft ARKG April 2025 ; Inputs: ctx = 'ARKG-P256.test vectors.1' ikm_bl = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f' ikm_kem = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f' ikm = h'404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f' ; Derive-Seed outputs: pk_bl = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df 65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7' pk_kem = h'042eff91b46617d0628b979405bb871a7593e4b02ec533712bc1cf80d0b0a1ccf3 0ec3b161632183ceedf94fbe35a96e60a17c2c79c6379b141eeeba521ea8030f' sk_bl = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455 sk_kem = 0x4253051878eac98187f1394605a3ef5ce1981e664cea41e8094c7d12c606d906 ; Derive-Public-Key outputs: pk_prime = h'0421df5ebc51bc67135990608349b66e799f5d7a406a404142c13910a7d488e0ca 58bc6bcab558299b7bda9e8b1718e781dc66ca0c9b28f5da2e7a00cf2ada9765' ;kh = (implementation defined) ; Derive-Private-Key outputs: sk_prime = 0xb3437c08215fb083ff360b1300743fddf7aed2493dfabba718aefa60984ed09b' ; Inputs: ctx = 'ARKG-P256.test vectors.1' ikm_bl = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f' ikm_kem = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f' ikm = h'00' ; Derive-Seed outputs: pk_bl = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df 65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7' pk_kem = h'042eff91b46617d0628b979405bb871a7593e4b02ec533712bc1cf80d0b0a1ccf3 0ec3b161632183ceedf94fbe35a96e60a17c2c79c6379b141eeeba521ea8030f' sk_bl = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455 sk_kem = 0x4253051878eac98187f1394605a3ef5ce1981e664cea41e8094c7d12c606d906 ; Derive-Public-Key outputs: pk_prime = h'0487c9f65395d4ddba545d6184fbb739440e1e7af008ada987eac44d58e4f9f073 22f7099029ca1523e9ea7c07e5b4fff6ac6f7006d156bca8a6496796043a68dd' ;kh = (implementation defined) ; Derive-Private-Key outputs: sk_prime = 0xc9006d3cac426ecf57ced462f11fba41d2db516a5d3111e058bc0c3c2e469ed2' B.2. Other instances TODO Lundberg & Bradley Expires 9 October 2025 [Page 35] Internet-Draft ARKG April 2025 Appendix C. Document History -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 Lundberg & Bradley Expires 9 October 2025 [Page 36] Internet-Draft ARKG April 2025 - 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. Lundberg & Bradley Expires 9 October 2025 [Page 37] Internet-Draft ARKG April 2025 * 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 Dain Nilsson Yubico Peter Altmann Agency for Digital Government Sweden Michael B. Jones Self-Issued Consulting United States URI: https://self-issued.info/ Sander Dijkhuis Cleverbase Netherlands Authors' Addresses Emil Lundberg (editor) Yubico Gävlegatan 22 Stockholm Sweden Email: emil@emlun.se John Bradley Yubico Email: ve7jtb@ve7jtb.com Lundberg & Bradley Expires 9 October 2025 [Page 38]