Skip to content

Commit

Permalink
Script updating gh-pages from 1f8ef4e. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Apr 9, 2024
1 parent b128956 commit 5ecc1e0
Show file tree
Hide file tree
Showing 2 changed files with 109 additions and 95 deletions.
84 changes: 52 additions & 32 deletions proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1275,45 +1275,65 @@ <h2 id="name-copyright-notice">
<h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
</h2>
<p id="section-1-1">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:<a href="#section-1-1" class="pilcrow"></a></p>
<p id="section-1-1">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.<a href="#section-1-1" class="pilcrow"></a></p>
<p id="section-1-2">Some motivating use cases of ARKG include:<a href="#section-1-2" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-1-2.1">
<p id="section-1-2.1.1"><strong>Initialization</strong>: The intended private key holder generates a <em>seed pair</em>, disclosing the <em>shared secret seed</em> to a subordinate entity while securely retaining the <em>private seed</em>.<a href="#section-1-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-2.2">
<p id="section-1-2.2.1"><strong>Public key generation</strong>: With the shared seed, the subordinate entity autonomously generates any number of new public keys alongside a unique <em>key handle</em> for each invocation.<a href="#section-1-2.2.1" class="pilcrow"></a></p>
<li class="normal" id="section-1-3.1">
<p id="section-1-3.1.1"><strong>Single-use asymmetric keys</strong>:
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.<a href="#section-1-3.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-3.2">
<p id="section-1-3.2.1"><strong>Enhanced forward secrecy</strong>:
The use of ARKG can facilitate forward secrecy in certain contexts.
For instance, <a href="https://www.rfc-editor.org/rfc/rfc9052.html#name-direct-key-agreement">section 8.5.4 of RFC 9052</a> notes that
"Since COSE is designed for a store-and-forward environment rather than an online environment,
[...] forward secrecy (see <span>[<a href="#RFC4949" class="cite xref">RFC4949</a>]</span>) 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.<a href="#section-1-3.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-2.3">
<p id="section-1-2.3.1"><strong>Private key derivation</strong>: 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.<a href="#section-1-2.3.1" class="pilcrow"></a></p>
<li class="normal" id="section-1-3.3">
<p id="section-1-3.3.1"><strong>Backup key generation</strong>:
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.<a href="#section-1-3.3.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-1-3">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:<a href="#section-1-3" class="pilcrow"></a></p>
<p id="section-1-4">ARKG consists of three procedures:<a href="#section-1-4" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-1-4.1">
<p id="section-1-4.1.1"><strong>Single-use asymmetric keys</strong>:
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.<a href="#section-1-4.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-4.2">
<p id="section-1-4.2.1"><strong>Enhanced forward secrecy</strong>:
The use of ARKG facilitates forward secrecy in certain contexts. For instance, <a href="https://www.rfc-editor.org/rfc/rfc9052.html#name-direct-key-agreement">section 8.5.4 of RFC 9052</a> 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 <span>[<a href="#RFC4949" class="cite xref">RFC4949</a>]</span>) 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.<a href="#section-1-4.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-4.3">
<p id="section-1-4.3.1"><strong>Backup key generation</strong>:
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.<a href="#section-1-4.3.1" class="pilcrow"></a></p>
<li class="normal" id="section-1-5.1">
<p id="section-1-5.1.1"><strong>Initialization</strong>:
The <em>delegating party</em> generates a <em>seed pair</em> and discloses the <em>public seed</em> to a <em>subordinate party</em>,
while securely retaining the <em>private seed</em>.<a href="#section-1-5.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-5.2">
<p id="section-1-5.2.1"><strong>Public key generation</strong>:
The subordinate party uses the public seed to autonomously generate a new public key
along with a unique <em>key handle</em> for the public key.
This can be repeated any number of times.<a href="#section-1-5.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-5.3">
<p id="section-1-5.3.1"><strong>Private key derivation</strong>:
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.<a href="#section-1-5.3.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-1-5">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. <span>[<a href="#Wilson" class="cite xref">Wilson</a>]</span><a href="#section-1-5" class="pilcrow"></a></p>
<p id="section-1-6">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. <span>[<a href="#Wilson" class="cite xref">Wilson</a>]</span><a href="#section-1-6" class="pilcrow"></a></p>
<div id="requirements-language">
<section id="section-1.1">
<h3 id="name-requirements-language">
Expand Down
120 changes: 57 additions & 63 deletions proposal-2024-03-09/Introduction/draft-bradleylundberg-cfrg-arkg.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down

0 comments on commit 5ecc1e0

Please sign in to comment.