sander · sander · Aug 23, 2024 · Aug 23, 2024 · Aug 23, 2024
diff --git a/Makefile b/Makefile
@@ -18,7 +18,7 @@ hdk.pdf:
 		"<title>Hierarchical Deterministic Keys for the European Digital Identity Wallet</title>" \
 		"<meta charset=utf-8>" \
 		> build/hdk.html
-	npx -p @mermaid-js/mermaid-cli mmdc -i draft-dijkhuis-cfrg-hierarchical-deterministic-keys.md -o build/keys.md -e svg -t neutral -w 400
+	npx -p @mermaid-js/mermaid-cli mmdc -i draft-dijkhuis-cfrg-hdkeys.md -o build/keys.md -e svg -t neutral -w 400
 	cat README.md | \
 		sed -e "s/# Hierarchical Deterministic Keys for the European Digital Identity Wallet/# Introduction to Hierarchical Deterministic Keys/g" | \
 		sed -e "s/keys.md/#hierarchical-deterministic-keys/g" | \

diff --git a/README.md b/README.md
@@ -45,7 +45,7 @@ Expert participants from Potential:
 
 ## Contents
 
-To address challenges 5 and 6, this repository contains a freely accessible, unencumbered specification of **[Hierarchical Deterministic Keys](draft-dijkhuis-cfrg-hierarchical-deterministic-keys.md)**. This enables an EU Digital Identity Wallet deployment that distributes key management efficiently:
+To address challenges 5 and 6, this repository contains a freely accessible, unencumbered specification of **[Hierarchical Deterministic Keys](draft-dijkhuis-cfrg-hdkeys.md)**. This enables an EU Digital Identity Wallet deployment that distributes key management efficiently:
 
 ![A wallet architecture using Hierarchical Deterministic Keys associated with keys protected using a wallet secure cryptographic device, optionally using Asynchronous Remote Key Generation (ARKG).](media/deployment.svg)
 

diff --git a/...s-cfrg-hierarchical-deterministic-keys.md → draft-dijkhuis-cfrg-hdkeys.md b/...s-cfrg-hierarchical-deterministic-keys.md → draft-dijkhuis-cfrg-hdkeys.md
@@ -2,7 +2,7 @@
 title: Hierarchical Deterministic Keys
 abbrev: HDK
 category: info
-docname: draft-dijkhuis-cfrg-hierarchical-deterministic-keys-latest
+docname: draft-dijkhuis-cfrg-hdkeys-latest
 submissiontype: independent
 v: 3
 area: IRTF
@@ -31,17 +31,15 @@ normative:
             - organization: National Institute of Standards and Technology (NIST)
         date: 2012-06
     ISO18013-5:
-        title: "Personal identification — ISO-compliant driving licence – Part 5: Mobile driving licence (mDL) application"
+        title: "Personal identification - ISO-compliant driving licence - Part 5: Mobile driving licence (mDL) application"
         target: https://www.iso.org/standard/69084.html
         seriesinfo:
             ISO/IEC: 18013-5:2021
         author:
             - organization: ISO/IEC
         date: 2019-09
-    RFC2119:
     RFC7800:
     RFC8017:
-    RFC8174:
     RFC9380:
     SEC2:
         title: "SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0"
@@ -151,31 +149,32 @@ Solutions MAY omit application of the asynchronous remote key generation functio
 The following example illustrates the use of key derivation. An HDK tree is defined by an initial public key and a seed value, which is a byte array containing sufficient entropy. Now tree nodes are constructed as follows.
 
 ~~~
-                           ┌────────────────────────┐
-                           │Confidential static data│
-                           │┌─────────┐ ┌────┐      │
-                           ││pk_device│ │seed│      │
-                           │└────┬────┘ └──┬─┘      │
-                           └─────┼─────────┼────────┘
-               ┌─────────────────┼─────────┼───────────────────────────┐
-               │Level 0          ▼         ▼                           │
-               │┌─────────────────────────────────────────────────────┐│
-               ││(pk0, sdk0, salt0) = hdk0 = HDK-Root(pk_device, seed)││
-               │└────┬────────────────────────────────────────────────┘│
-               └─────┼─────────────────────────────────────────────────┘
-Level 1              ▼
-┌─────────────────────────┐┌────────────────────────┐┌─────────────────────────┐
-│(pk1, sk1, salt1) =      ││HDK-Derive-Local(hd0, 1)││HDK-Derive-Local(hdk0, 2)│
-│HDK-Derive-Local(hdk0, 0)││                        ││                         │
-└───────────┬────────┬────┘└────────────────────────┘└─────────────────────────┘
-            │        └────────────────────────┐
-            │                                 │
-┌───────────┼─────────────────────────────────┼──────────────────────────────┐
-│Level 2    ▼                                 ▼                              │
-│┌────────────────────────────────────┐┌────────────────────────────────────┐│
-││HDK-Derive-Local((pk1,sk1,salt1), 0)││HDK-Derive-Local((pk1,sk1,salt1), 1)││
-│└────────────────────────────────────┘└────────────────────────────────────┘│
-└────────────────────────────────────────────────────────────────────────────┘
+              +------------------------+
+              |Confidential static data|
+              |+---------+ +----+      |
+              ||pk_device| |seed|      |
+              |+----+----+ +--+-+      |
+              +-----+---------+--------+
+  +-----------------+---------+---------------------------+
+  |Level 0          v         v                           |
+  |+-----------------------------------------------------+|
+  ||(pk0, sdk0, salt0) = hdk0 = HDK-Root(pk_device, seed)||
+  |+----+------------------------------------------------+|
+  +-----+-------------------------------------------------+
+Level 1 v
++-------------------------++-----------------++-----------------+
+|(pk1, sk1, salt1) =      ||HDK-Derive-Local(||HDK-Derive-Local(|
+|HDK-Derive-Local(hdk0, 0)||    hdk0, 1)     ||    hdk0, 2)     |
++-----------+--------+----++-----------------++-----------------+
+            |        +---------------+
+            |                        |
++-----------+------------------------+--------------------+
+|Level 2    v                        v                    |
+|+-----------------------++-----------------------+       |
+||HDK-Derive-Local(      ||HDK-Derive-Local(      |       |
+||    (pk1,sk1,salt1), 0)||    (pk1,sk1,salt1), 1)|       |
+|+-----------------------++-----------------------+       |
++---------------------------------------------------------+
 ~~~
 
 The solution instance computes the Level 0 HDK at the root node using a deterministic function called HDK-Root. The HDK consists of a key pair `(pk0, sk0)`, and a byte string `salt0` to derive next-level keys.
@@ -198,23 +197,23 @@ In this example, a document is issued in such a way that it can be presented wit
 In secure
 cryptographic
 device
-┌───────────┐
-│sk_device  ┼─────────────┐
-└───────────┘             │
-─────────────             │
-HDK in                    │
-solution                  │
-instance                  ▼        ┌───────────┐
-┌───────────┐    HDK-Authenticate─►│device_data│
-│pk         │       ▲     ▲        └───────────┘
-└───────────┘       │     │
-┌───────────┐       │     │
-│sk         ┼───────┘     │
-└───────────┘             │
-─────────────             │
-┌───────────┐             │
-│reader_data┼─────────────┘
-└───────────┘
++-----------+
+|sk_device  +-------------+
++-----------+             |
+-------------             |
+HDK in                    |
+solution                  |
+instance                  v        +-----------+
++-----------+    HDK-Authenticate->|device_data|
+|pk         |       ^     ^        +-----------+
++-----------+       |     |
++-----------+       |     |
+|sk         +-------+     |
++-----------+             |
+-------------             |
++-----------+             |
+|reader_data+-------------+
++-----------+
 ~~~
 
 Blinding methods can be constructed such that the secure cryptographic device does not need to be designed for it. In such cases, `sk_device` does not contain the value of the private device key but a reference to it.
@@ -341,7 +340,7 @@ A solution instance authenticates the device by creating a blinded proof applyin
 Inputs:
 - sk_device, a (reference to a) device private key.
 - sk_hdk, an HDK private key.
-- reader_data, a byte string of solution instance-specific reader data.
+- reader_data, a byte string of solution instance-specific data.
 
 Outputs:
 - device_data, a byte string of device data for proving possession.
@@ -537,15 +536,15 @@ The solution proposal discussed herein works in all four WSCD architectures that
   - P-256 EC-SDSA key pair generation
   - P-256 EC-SDSA signature creation
 
-The other HDK operations can be performed in the WI running on any UD, including hostile ones with limited sandboxing capabilities, such as in a smartphone’s rich execution environment or in a personal computer web browser.
+The other HDK operations can be performed in the WI running on any UD, including hostile ones with limited sandboxing capabilities, such as in a smartphone's rich execution environment or in a personal computer web browser.
 
 If the user enters the PIN in the WI instead of on the WSCD directly, the WI MUST process it directly after entering, the WI MUST keep the plaintext PIN confidential, and the WI MUST delete the PIN from memory as soon as the encrypted PIN or data derived from the PIN is passed over the SCI.
 
 The rate-limiting of the PIN check MUST be managed within the WSCD or on securely managed SCI infrastructure. In particular, the rate-limiting MUST NOT be managed solely in local WI software since it is aassumed that attackers could modify this without detection.
 
 ## Trust evidence
 
-Some issuers could require evidence from a solution provider of the security of the holder’s cryptographic device. This evidence is in the context of [EU2024-1183] divided into initial “Wallet Trust Evidence” and related “Issuer Trust Evidence”. Each is a protected document that contains a trust evidence public key associated with a private key that is protected in the secure cryptographic device. In HDK, these public keys are specified as follows.
+Some issuers could require evidence from a solution provider of the security of the holder's cryptographic device. This evidence is in the context of [EU2024-1183] divided into initial "Wallet Trust Evidence" and related "Issuer Trust Evidence". Each is a protected document that contains a trust evidence public key associated with a private key that is protected in the secure cryptographic device. In HDK, these public keys are specified as follows.
 
 ### Wallet Trust Evidence