From 6e2173aa2616bc118d765bd606a73b215017fdbf Mon Sep 17 00:00:00 2001 From: Micha Kraus Date: Mon, 7 Oct 2024 14:23:18 +0200 Subject: [PATCH 1/2] clarification of HDK-Root checks --- draft-dijkhuis-cfrg-hdkeys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-dijkhuis-cfrg-hdkeys.md b/draft-dijkhuis-cfrg-hdkeys.md index bef4448..da538fe 100644 --- a/draft-dijkhuis-cfrg-hdkeys.md +++ b/draft-dijkhuis-cfrg-hdkeys.md @@ -550,7 +550,7 @@ Some issuers could require evidence from a solution provider of the security of The Wallet Trust Evidence public key is the root HDK public key. To achieve reader unlinkability, the wallet SHOULD limit access to a trusted person identification document provider only. -To prevent association across identities, the solution provider MUST before issuing Wallet Trust Evidence ensure that the root HDK public key is associated with a newly generated device key pair. For example, the solution provider could rely on freshness of a key attestation and ensure that each device public key is attested only once. +To prevent association across identities, the solution provider MUST before issuing Wallet Trust Evidence ensure that (a) a newly generated device key pair is used and (b) the wallet follows the protocol so that HDK-Root is bound to exactly this key. For (a), the solution provider could rely on freshness of a key attestation and ensure that each device public key is attested only once. For (b), the wallet could proof knowledge of sk' with a Schnorr non-interactive zero-knowledge proof with base point pk_device. This would ensure, that the root blinding key sk' is not shared with the solution provider to reduce the risk of the solution provider unblinding future derived keys. ### Issuer Trust Evidence From 229b846115c86349d285fd967d0d1c13ee244da9 Mon Sep 17 00:00:00 2001 From: Sander Dijkhuis Date: Sat, 12 Oct 2024 10:35:46 +0200 Subject: [PATCH 2/2] Fix markup and reference, add contributor credit (#41) --- draft-dijkhuis-cfrg-hdkeys.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-dijkhuis-cfrg-hdkeys.md b/draft-dijkhuis-cfrg-hdkeys.md index da538fe..bc60d19 100644 --- a/draft-dijkhuis-cfrg-hdkeys.md +++ b/draft-dijkhuis-cfrg-hdkeys.md @@ -18,6 +18,9 @@ author: surname: Dijkhuis organization: Cleverbase email: mail@sanderdijkhuis.nl +contributor: + - fullname: Micha Kraus + organization: Bundesdruckerei ipr: trust200902 normative: I-D.draft-bradleylundberg-cfrg-arkg-02: @@ -40,6 +43,7 @@ normative: date: 2019-09 RFC7800: RFC8017: + RFC8235: RFC9380: SEC2: title: "SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0" @@ -550,7 +554,7 @@ Some issuers could require evidence from a solution provider of the security of The Wallet Trust Evidence public key is the root HDK public key. To achieve reader unlinkability, the wallet SHOULD limit access to a trusted person identification document provider only. -To prevent association across identities, the solution provider MUST before issuing Wallet Trust Evidence ensure that (a) a newly generated device key pair is used and (b) the wallet follows the protocol so that HDK-Root is bound to exactly this key. For (a), the solution provider could rely on freshness of a key attestation and ensure that each device public key is attested only once. For (b), the wallet could proof knowledge of sk' with a Schnorr non-interactive zero-knowledge proof with base point pk_device. This would ensure, that the root blinding key sk' is not shared with the solution provider to reduce the risk of the solution provider unblinding future derived keys. +To prevent association across identities, the solution provider MUST before issuing Wallet Trust Evidence ensure that (a) a newly generated device key pair is used and (b) the wallet follows the protocol so that the HDK-Root output is bound to exactly this key. For (a), the solution provider could rely on freshness of a key attestation and ensure that each device public key is attested only once. For (b), the wallet could proof knowledge of `sk'` with a Schnorr non-interactive zero-knowledge proof [RFC8235] with base point `pk_device`. This would ensure,that the root blinding key `sk'` is not shared with the solution provider to reduce the risk of the solution provider unblinding future derived keys. ### Issuer Trust Evidence