From 5ecc1e08ef341496cc64ba6830bfa69d38b1e414 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Tue, 9 Apr 2024 17:41:25 +0000 Subject: [PATCH] Script updating gh-pages from 1f8ef4e. [ci skip] --- .../draft-bradleylundberg-cfrg-arkg.html | 84 +++++++----- .../draft-bradleylundberg-cfrg-arkg.txt | 120 +++++++++--------- 2 files changed, 109 insertions(+), 95 deletions(-) diff --git a/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.html b/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.html index d7c81e0..4d8b426 100644 --- a/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.html +++ b/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.html @@ -1275,45 +1275,65 @@

1. 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.

+

Some motivating use cases of ARKG include:

-

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:

+

ARKG consists of three procedures:

-

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]

+

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]

diff --git a/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.txt b/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.txt index c01ae33..19d1c37 100644 --- a/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.txt +++ b/proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.txt @@ -114,73 +114,67 @@ Table of Contents 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: - - * *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: + 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, 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. - - * *Enhanced forward secrecy*: The use of ARKG facilitates forward + 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 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) defines COSE representations for encrypted messages and - 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. - - 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] + 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, 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] 1.1. Requirements Language