Update Introduction in draft-bradleylundberg-cfrg-arkg.md

draft-bradleylundberg-cfrg-arkg.md

@@ -131,75 +131,66 @@ We expect that additional instances will be defined in the future.
 
 # Introduction
 
-Asymmetric cryptography, also called public key cryptography, is a fundamental component of much of modern information security.
-However, even the flexibility of asymmetric cryptosystems is not always enough for all applications.
-For the sake of privacy and forward secrecy it may be necessary to frequently generate new keys,
-but it is not always feasible for the holder of the private keys to be available whenever a new key pair is needed.
-For example, this is often the case when using a hardware security device to hold private keys,
-where the device may be detached or locked at the time a new key pair is needed.
-
-The Asynchronous Remote Key Generation (ARKG) algorithm
-enables the holder of private keys to delegate generation of public keys without giving access to the corresponding private keys.
-This enables a public key consumer to autonomously generate public keys whenever one is needed,
-while the private key holder can later derive the corresponding private key using a "key handle" generated along with the public key.
-
-The algorithm consists of three procedures:
-(1) the _delegating party_ generates a _seed pair_ and emits the _public seed_ to a _subordinate party_,
-(2) the subordinate party uses the public seed to generate a public key and a _key handle_ on behalf of the delegating party, and
-(3) the delegating party uses the key handle and the _private seed_
-to derive the private key corresponding to the public key generated by procedure (2).
-Procedure (1) is performed once, and procedures (2) and (3) may be repeated any number of times with the same seed pair.
-The required cryptographic 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]
+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:
 
-- Efficient single-use signing keys.
-  The European Union has proposed a digital identity system which, in order to protect users' privacy,
-  needs a unique key pair for each authentication signature.
-  In online usage the system could relatively easily create a key on demand,
-  submit it to a certification authority to have a single-use certificate issued for that key,
-  and then submit that certificate with an authentication signature to a third party to access a service.
-
-  However, the proposed system also includes offline use cases:
-  A user might for example need to use the system in a location with poor or no internet connectivity
-  to present a digital driver's license or authorize a payment.
-  For this, the system may need to pre-emptively generate a large amount of single-use certificates to be used offline.
-
-  One candidate implementation under evaluation to provide signing and key management for this system
-  is the W3C Web Authentication API [WebAuthn] (WebAuthn),
-  which requires a user gesture whenever a WebAuthn operation is invoked.
-  A WebAuthn-based implementation of the proposed digital identity system
-  could use ARKG to pre-emptively generate key pairs for offline use without the need to prompt for a user gesture for each key pair generated.
-
-- Enhanced forward secrecy for encrypted messaging.
-  For example, [section 8.5.4 of RFC 9052][rfc9052-direct-key-agreement] defines COSE representations for encrypted messages and notes that
+- __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][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."
-  Applications could work around this limitation by exchanging a large number of keys in advance,
-  but that number limits how many messages can be sent before another such exchange is needed.
-  This also requires the sender to allocate storage space for the keys,
-  which may be challenging to support in constrained hardware.
+  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.
 
-  ARKG could enable the sender to generate ephemeral recipient public keys on demand.
-  This may enhance forward secrecy if the sender keeps the ARKG public seed secret,
-  since each recipient key pair is used to encrypt only one message.
-
-- Generating additional public keys as backup keys.
+- __Backup key generation__:
   For example, the W3C Web Authentication API [WebAuthn] (WebAuthn) generates a new key pair for each account on each web site.
-  This makes it difficult for users to set up a backup authenticator,
-  because each time a key pair is created for the primary authenticator,
-  another key pair also needs to be created for the backup authenticator, which may be stored in a safe but inconvenient location.
-
-  ARKG could enable the primary authenticator to also generate a public key for a paired backup authenticator
-  whenever it generates a key pair for itself,
-  allowing the user to set up the pairing once
-  and then leave the backup authenticator in safe storage until the primary authenticator is lost.
+  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
 
+
 ## Requirements Language
 
 {::boilerplate bcp14-tagged}
@@ -247,19 +238,19 @@ The parameters of an ARKG instance are:
 
     No input.
 
-    Output consists of a blinding public key `pk` and a blinding secret key `sk`.
+    Output consists of a blinding public key `pk` and a blinding private key `sk`.
 
   - 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-Secret-Key(sk, tau) -> sk_tau`: Deterministically compute a blinded secret key.
+  - Function `BL-Blind-Private-Key(sk, tau) -> sk_tau`: Deterministically compute a blinded private key.
 
-    Input consists of a blinding secret key `sk` and a blinding factor `tau`.
+    Input consists of a blinding private key `sk` and a blinding factor `tau`.
 
-    Output consists of the blinded secret key `sk_tau`.
+    Output consists of the blinded private key `sk_tau`.
 
   - Integer `L_bl`: The length of the blinding factor `tau` in octets.
 
@@ -274,7 +265,7 @@ The parameters of an ARKG instance are:
 
     No input.
 
-    Output consists of public key `pk` and secret key `sk`.
+    Output consists of public key `pk` and private key `sk`.
 
   - `KEM-Encaps(pk) -> (k, c)`: Generate a key encapsulation.
 
@@ -284,7 +275,7 @@ The parameters of an ARKG instance are:
 
   - `KEM-Decaps(sk, c) -> k`: Decapsulate a shared secret.
 
-    Input consists of encapsulation secret key `sk` and encapsulation ciphertext `c`.
+    Input consists of encapsulation private key `sk` and encapsulation ciphertext `c`.
 
     Output consists of the shared secret `k` on success, or an error otherwise.
 
@@ -331,7 +322,7 @@ A concrete ARKG instantiation MUST specify the instantiation
 of each of the above functions and values.
 
 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-Secret-Key` output ECDSA keys,
+For example, if `BL-Blind-Public-Key` and `BL-Blind-Private-Key` output ECDSA keys,
 then the ARKG instance will also output ECDSA keys.
 
 Instantiations MUST satisfy the following compatibility criteria:
@@ -340,7 +331,7 @@ Instantiations MUST satisfy the following compatibility criteria:
   is a valid input key material `ikm` of `KDF`.
 
 - Output key material `okm` of length `L_bl` of `KDF`
-  is a valid input blinding factor `tau` of `BL-Blind-Public-Key` and `BL-Blind-Secret-Key`.
+  is a valid input blinding factor `tau` of `BL-Blind-Public-Key` and `BL-Blind-Private-Key`.
 
   It is permissible for some `KDF` outputs to not be valid blinding factors,
   as long as this happens with negligible probability -
@@ -436,7 +427,7 @@ ARKG-Derive-Public-Key((pk_kem, pk_bl), info) -> (pk', kh)
     Output:
         pk'       A blinded public key.
         kh        A key handle for deriving the blinded
-                    secret key sk' corresponding to pk'.
+                    private key sk' corresponding to pk'.
 
     The output (pk', kh) is calculated as follows:
 
@@ -454,17 +445,17 @@ for example because `KDF` returns an invalid `tau` or `mk`,
 the procedure can safely be retried with the same arguments.
 
 
-## The function ARKG-Derive-Secret-Key
+## The function ARKG-Derive-Private-Key
 
 This function is performed by the delegating party, which holds the ARKG private seed `(sk_kem, sk_bl)`.
-The resulting secret key `sk'` can be used in asymmetric cryptography protocols
+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 secret keys any number of times.
+in order to derive the same or different private keys any number of times.
 
 ~~~pseudocode
-ARKG-Derive-Secret-Key((sk_kem, sk_bl), kh, info) -> sk'
+ARKG-Derive-Private-Key((sk_kem, sk_bl), kh, info) -> sk'
     ARKG instance parameters:
         BL        A key blinding scheme.
         KEM       A key encapsulation mechanism.
@@ -476,15 +467,15 @@ ARKG-Derive-Secret-Key((sk_kem, sk_bl), kh, info) -> sk'
                     of the MAC scheme MAC.
 
     Inputs:
-        sk_kem    A key encapsulation secret key.
-        sk_bl     A key blinding secret key.
+        sk_kem    A key encapsulation private key.
+        sk_bl     A key blinding private key.
         kh        A key handle output from ARKG-Derive-Public-Key.
         info      An octet string containing optional context
                     and application specific information
                     (can be a zero-length string).
 
     Output:
-        sk'       A blinded secret key.
+        sk'       A blinded private key.
 
     The output sk' is calculated as follows:
 
@@ -496,15 +487,15 @@ ARKG-Derive-Secret-Key((sk_kem, sk_bl), kh, info) -> sk'
         Abort with an error.
 
     tau = KDF("arkg-blind" || 0x00 || info, k, L_bl)
-    sk' = BL-Blind-Secret-Key(sk_bl, tau)
+    sk' = BL-Blind-Private-Key(sk_bl, tau)
 ~~~
 
 Errors in this procedure are typically unrecoverable.
 For example, `KDF` might return an invalid `tau` or `mk`, or the `tag` may be invalid.
 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 a correct and honest implementation of `ARKG-Derive-Secret-Key`.
+of a correct and honest implementation of `ARKG-Derive-Private-Key`.
 See also {{design-rationale-mac}}.
 
 
@@ -545,7 +536,7 @@ BL-Blind-Public-Key(pk, tau) -> pk_tau
     pk_tau = pk + tau * G
 
 
-BL-Blind-Secret-Key(sk, tau) -> sk_tau
+BL-Blind-Private-Key(sk, tau) -> sk_tau
 
     If tau = 0 or tau >= N, abort with an error.
     sk_tau_tmp = sk + tau
@@ -572,7 +563,7 @@ Then the `KEM` parameter of ARKG may be instantiated as follows:
   using the procedures defined in sections 2.3.7 and 2.3.8 of [SEC1].
 
 - `ECDH(pk, sk)` represents the compact output of ECDH [RFC6090]
-  using public key (curve point) `pk` and secret key (exponent) `sk`.
+  using public key (curve point) `pk` and private key (exponent) `sk`.
 
 - `G` is the generator of `crv`.
 - `N` is the order of `G`.
@@ -758,7 +749,7 @@ The identifier `ARKG-X25519-X25519-HMAC-SHA256-HKDF-SHA256` represents the follo
 
 TODO?: Define COSE representations for interoperability:
 - ARKG public seed (for interoperability between different implementers of `ARKG-Generate-Seed` and `ARKG-Derive-Public-Key`)
-- ARKG key handle (for interoperability between different implementers of `ARKG-Derive-Public-Key` and `ARKG-Derive-Secret-Key`)
+- ARKG key handle (for interoperability between different implementers of `ARKG-Derive-Public-Key` and `ARKG-Derive-Private-Key`)
 
 
 # Security Considerations {#Security}
@@ -789,27 +780,27 @@ and those addressed to other delegating parties.
 We anticipate use cases where a private key usage request may contain key handles for several delegating parties
 eligible to fulfill the request,
 and the delegate party to be used can be chosen opportunistically depending on which are available at the time.
-Without the MAC, choosing the wrong key handle would cause the `ARKG-Derive-Secret-Key` procedure to silently derive the wrong key
+Without the MAC, choosing the wrong key handle would 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.
 The MAC also allows ARKG key handles to be transmitted via heterogeneous data channels,
 possibly including a mix of ARKG key handles and similar values used for other algorithms.
 
 The second purpose is so that the delegating party can be assured that no errors should happen
-during the execution of `ARKG-Derive-Secret-Key`, such as out-of-range or invalid key values.
+during the execution of `ARKG-Derive-Private-Key`, such as out-of-range or invalid key values.
 For example, key generation in `ARKG-Derive-Public-Key` might be done by randomly testing candidates [NIST.SP.800-56Ar3]
 and retrying `ARKG-Derive-Public-Key` until a valid candidate is found.
-A MAC enables `ARKG-Derive-Secret-Key` to assume that the first candidate from a given pseudo-random seed will be successful,
+A MAC enables `ARKG-Derive-Private-Key` to assume that the first candidate from a given pseudo-random seed will be successful,
 and otherwise return an explicit error rejecting the key handle as invalid.
 `ARKG-Derive-Public-Key` is likely to run on powerful general-purpose hardware, such as a laptop, smartphone or server,
-while `ARKG-Derive-Secret-Key` might run on more constrained hardware such as a cryptographic smart card,
+while `ARKG-Derive-Private-Key` might run on more constrained hardware such as a cryptographic smart card,
 which benefits greatly from such optimizations.
 
 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 `KEM` as group exponentiation
-and instantiating `BL` as group multiplication to blind public keys and modular integer addition to blind secret keys.
+and instantiating `BL` as group multiplication to blind public keys and modular integer addition to blind private keys.
 The `MAC` and `KDF` parameters correspond trivially to the MAC and KDF parameters in [Frymann2020],
 where KDF<sub>1</sub>(_k_) = KDF(_k_, _l_<sub>1</sub>) and KDF<sub>2</sub>(_k_) = KDF(_k_, _l_<sub>2</sub>)
 with fixed labels _l_<sub>1</sub> and _l_<sub>2</sub>.