Editorial review of PR #10

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