From 1f8ef4e6670123dae1957990314e5c690cf83b55 Mon Sep 17 00:00:00 2001 From: Emil Lundberg Date: Tue, 9 Apr 2024 19:40:44 +0200 Subject: [PATCH] Editorial review of PR #10 --- draft-bradleylundberg-cfrg-arkg.md | 64 ++++++++++++++++++++---------- 1 file changed, 43 insertions(+), 21 deletions(-) diff --git a/draft-bradleylundberg-cfrg-arkg.md b/draft-bradleylundberg-cfrg-arkg.md index 3f0792d..23db56c 100644 --- a/draft-bradleylundberg-cfrg-arkg.md +++ b/draft-bradleylundberg-cfrg-arkg.md @@ -131,34 +131,56 @@ We expect that additional instances will be defined in the future. # Introduction -Asynchronous Remote Key Generation (ARKG) introduces a mechanism to generate public keys without access to the corresponding private keys, and without anyone other than the intended private key holder being able to generate these private keys. -Such a mechanism is pivotal for many scenarios where private key holders cannot engage in the generation of new key pairs whenever a public key is needed. -This may occur when the hardware security device that protects the private keys is unavailable at the time of generation. ARKG is delineated through three primary procedures: +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. -* __Initialization__: The intended private key holder generates a _seed pair_, disclosing the _shared secret seed_ to a subordinate entity while securely retaining the _private seed_. -* __Public key generation__: With the shared seed, the subordinate entity autonomously generates any number of new public keys alongside a unique _key handle_ for each invocation. -* __Private key derivation__: The intended private key holder jointly employs the key handle and the private seed to derive the private keys corresponding to the public keys generated by procedure two. - -One application is key blinding where the private key is a function of a long-term private key and a freshly generated blinding key, and correspondingly where the public key is a function of the long-term public key and the same blinding key. Some motivating use cases of ARKG include: - __Single-use asymmetric keys__: - Envisioned for the European Union's digital identity framework, ARKG facilitates the generation of unique key pairs for individual authentication processes. - Unique single-use asymmetric keys prevent colluding verifiers from using the public key material as a correlation handle. - In online usage, ARKG enables public key generation on demand. This is useful when creating single-use certificates, single-use proof of possession keys to be included in (qualified) electronic attestations of attributes or personal identification data attestations. - In offline usage, ARKG enables pre-generation of single-use keys. - One candidate implementation for single-use keys is the W3C Web Authentication API [WebAuthn] (WebAuthn), which presently requires private key holder engagement whenever a WebAuthn operation is invoked. + 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 enables offline usage scenarios by allowing pre-generation of public keys for single-use credentials + without needing to access the hardware security device that holds the private keys. + - __Enhanced forward secrecy__: - The use of ARKG facilitates forward secrecy in certain contexts. For instance, [section 8.5.4 of RFC 9052][rfc9052-direct-key-agreement] defines COSE representations for encrypted messages and notes that + The use of ARKG can facilitate forward secrecy in certain contexts. + For instance, [section 8.5.4 of RFC 9052][rfc9052-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 generation of ephemeral recipient public keys on demand. -- __Backup key generation__: - In contexts like the W3C Web Authentication API [WebAuthn] (WebAuthn), ARKG allows for the simultaneous generation of primary and backup public keys. The primary authenticator could generate both a key pair for itself and a public key for a paired backup authenticator. Here, the backup authenticator is paired with the primary authenticator once, and then safely stored until it is needed. + \[...\] 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. - -Notably, ARKG can be built entirely using commonly deployed cryptographic primitives. The required primitives are a key encapsulation mechanism (KEM), -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] +- __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, a key encapsulation mechanism (KEM), +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] [rfc9052-direct-key-agreement]: https://www.rfc-editor.org/rfc/rfc9052.html#name-direct-key-agreement