Update Introduction in draft-bradleylundberg-cfrg-arkg.md #15
Conversation
Restructured the text a bit so that the problem statement is earlier, that the procedures required are enumerated, and to position ARKG in relation to KBSS. Changed some terms. - the seed is not private public. It is private, shared secret. If it was public, then any entity could derive the same keys, rendering the entire proposal moot. - reduced the number of terms used to describe similar concepts. For instance, 'intended private key holder' instead of delegating party, subordinate entity instead of public key consumer etc. - Changed the order of how the text uses examples. Examples are now used to illustrate the benefit of a certain ARKG property. Overall changes to readability and clarity (I hope).
AltmannPeter
changed the title
There was a problem hiding this comment.
There's a lot I like here! I ended up rewriting and restructuring a lot of it, though, to cut down on some redundancy and try to say the same things in fewer words.
I also moved the "three procedures" to after the examples, I think the section flows a little better now with ending on the declaration that quantum-resistant instantiations exist and not ending abruptly after a bullet-point list.
I hope I've preserved the spirit of what you wanted to accomplish, do you agree?
draft-bradleylundberg-cfrg-arkg.md
Outdated
| 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, and without anyone other than the intended private key holder being able to generate these private keys. |
There was a problem hiding this comment.
and without anyone other than the intended private key holder being able to generate these private keys
This seems redundant, already covered by the first half?
draft-bradleylundberg-cfrg-arkg.md
Outdated
| 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, 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. |
There was a problem hiding this comment.
Replacing the "delegating party" term would have to be done throughout the document as a whole, not just the introduction. I'm reverting to using the "delegating party" term for now.
draft-bradleylundberg-cfrg-arkg.md
Outdated
|
|
||
| * __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_. |
There was a problem hiding this comment.
I like the term "shared seed" (it does not always need to be secret, depending on application) as opposed to "public seed", but this also needs to be changed throughout the whole document. Reverting to "public seed" for now, but we can change to "shared seed" in a separate PR.
draft-bradleylundberg-cfrg-arkg.md
Outdated
| 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. |
There was a problem hiding this comment.
which presently requires private key holder engagement
Not just presently, it's unlikely that this restriction will ever be relaxed in WebAuthn.
| "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." |
There was a problem hiding this comment.
These backslashes are needed so the RFC "compiler" doesn't interpret this as a reference.
draft-bradleylundberg-cfrg-arkg.md
Outdated
| * __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. |
There was a problem hiding this comment.
I think this is mostly covered by the examples below?
draft-bradleylundberg-cfrg-arkg.md
Outdated
| 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] |
There was a problem hiding this comment.
Why remove the key blinding scheme from the list of primitives?
draft-bradleylundberg-cfrg-arkg.md
Outdated
| - __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. |
There was a problem hiding this comment.
The online use case isn't a very strong motivation, as that can almost as easily be done with conventional key generation. The offline use case is much stronger in my opinion: pre-generating keys in large batches at once without having to call out to the secure element (possibly invoking a user gesture) for each key.
There was a problem hiding this comment.
The online use case for single-use, just-in-time PID/(Q)EAA still looks valid:
- Creating a brand new ECDSA key in the mobile SCE does not provide the issuer any assurance that it is bound to the same device as the PID that was presented to them. With ARKG, the issuer can have this assurance.
- Creating a brand new ECDSA key in the mobile SCE requires additional key management, which brings the latency of key generation and in the Android case also the problem of key deletion. With ARKG, the SCE does not need to do any additional key generation or deletion.
Refer to private keys instead of secret keys for asymmetric key pairs
Note that for online scenarios, ARKG gives assurance of same-hardware binding
Restructured the text a bit so that the problem statement is earlier, that the procedures required are enumerated, and to position ARKG in relation to KBSS.
Changed some terms.
Overall changes to readability and clarity (I hope).