Add proposal 347-domain-separation.md

6 files changed, 86 insertions, 0 deletions

diff --git a/mdbook/proposals/book.toml b/mdbook/proposals/book.toml
index 17426f8..fdbe64a 100644
--- a/mdbook/proposals/book.toml
+++ b/mdbook/proposals/book.toml
@@ -276,4 +276,5 @@ enable = false
 "/344.html" = "./344-protocol-info-leaks.txt"
 "/345.html" = "./345-specs-in-mdbook.html"
 "/346.html" = "./346-protovers-again.html"
+"/347.html" = "./347-domain-separation.html"
 # END AUTO-GENERATED REDIRECTS
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 3381783..7acc0f7 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -268,6 +268,7 @@ Proposals by number:
 344  Prioritizing Protocol Information Leaks in Tor [OPEN]
 345  Migrating the tor specifications to mdbook [CLOSED]
 346  Clarifying and extending the use of protocol versioning [OPEN]
+347  Domain separation for certificate signing keys [OPEN]
 
 
 Proposals by status:
@@ -305,6 +306,7 @@ Proposals by status:
    343  CAA Extensions for the Tor Rendezvous Specification
    344  Prioritizing Protocol Information Leaks in Tor
    346  Clarifying and extending the use of protocol versioning
+   347  Domain separation for certificate signing keys
  ACCEPTED:
    282  Remove "Named" and "Unnamed" handling from consensus voting [for arti-dirauth]
    285  Directory documents should be standardized as UTF-8 [for arti-dirauth]
diff --git a/proposals/347-domain-separation.md b/proposals/347-domain-separation.md
new file mode 100644
index 0000000..3056d10
--- /dev/null
+++ b/proposals/347-domain-separation.md
@@ -0,0 +1,80 @@
+```
+Filename: 347-domain-separation.md
+Title: Domain separation for certificate signing keys
+Author: Nick Mathewson
+Created: 19 Oct 2023
+Status: Open
+```
+
+## Our goal
+
+We'd like to be able to use the "family key" from proposal 321 as a
+general purpose signing key, to authenticate other things than the
+membership of a family.  For example, we might want to have a
+challenge/response mechanism where the challenger says, "If you want
+to log in as the owner of the account corresponding to this family,
+sign the following challenge with your key.  Or we might want to
+have a message authentication scheme where an operator can
+sign a message in a way that proves key ownership.
+
+We _might_ also like to use relay identity keys or onion service
+identitiy keys for the same purpose.
+
+## The problem
+
+When we're using a signing key for two purposes, it's important
+to perform some kind of domain separation so that documents
+signed for one purpose can't be mistaken for documents signed for the
+other.
+
+For example, in the challenge/response example, it would be bad if
+the challenger could provide a challenge string that would cause the
+signer to inadvertently authenticate an incorrect family.
+
+These keys are currently used in some places with no
+personalization. Their signature format is as described in
+`cert-spec.txt`, which says:
+
+>  The signature is created by signing all the fields in
+>  the certificate up until "SIGNATURE" (that is, signing
+>  sizeof(ed25519_cert) - 64 bytes).
+
+
+
+## One solution
+
+This one is pretty easy: we would extend `cert-spec` as follows.
+
+
+> ### Using signing keys for other purposes.
+>
+> Other protocols may introduce other uses for the signing keys
+> in these certificates other than those specified here.  When
+> they do, they MUST ensure that the documents being signed
+> cannot be confused with the certificate bodies of this document.
+>
+> In some existing cases in the Tor protocols, we achieve this by
+> specifying an ASCII prefix string that must be prepended to the
+> other protocol's signed object before it is signed.
+>
+> For future protocols, we recommend that this be done by
+> specifying that the signing key is to be used to sign a
+> cSHAKE digest (or other secure customizable digest)
+> of the other protocol's signed object, using
+> a customization string unique to the other protocol.
+
+We would also make this amendment:
+
+> ### Future versions of this specification
+>
+> In order to maintain the domain separation that currently exists
+> between the signatures on these certificates and other documents
+> signed with the same keys, it suffices (for now!) that these
+> certificates begin with the version byte `[01]`, whereas
+> the other documents are in printable ASCII, which never
+> includes `[01]`.
+>
+> Future versions of this specification SHOULD move to using
+> an ed25519-prehash construction, using a customizable hash
+> with built-in domain separation.
+
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index d83a5b1..c7fd3d9 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -264,4 +264,5 @@ Below are a list of proposals sorted by their proposal number.  See
 * [`344-protocol-info-leaks.txt`](/proposals/344-protocol-info-leaks.txt): Prioritizing Protocol Information Leaks in Tor [OPEN]
 * [`345-specs-in-mdbook.md`](/proposals/345-specs-in-mdbook.md): Migrating the tor specifications to mdbook [CLOSED]
 * [`346-protovers-again.md`](/proposals/346-protovers-again.md): Clarifying and extending the use of protocol versioning [OPEN]
+* [`347-domain-separation.md`](/proposals/347-domain-separation.md): Domain separation for certificate signing keys [OPEN]
 
diff --git a/proposals/BY_STATUS.md b/proposals/BY_STATUS.md
index 64c800e..8e5f0ed 100644
--- a/proposals/BY_STATUS.md
+++ b/proposals/BY_STATUS.md
@@ -39,6 +39,7 @@ for discussion.
 * [`343-rend-caa.txt`](/proposals/343-rend-caa.txt): CAA Extensions for the Tor Rendezvous Specification
 * [`344-protocol-info-leaks.txt`](/proposals/344-protocol-info-leaks.txt): Prioritizing Protocol Information Leaks in Tor
 * [`346-protovers-again.md`](/proposals/346-protovers-again.md): Clarifying and extending the use of protocol versioning
+* [`347-domain-separation.md`](/proposals/347-domain-separation.md): Domain separation for certificate signing keys
 
 
 ## ACCEPTED proposals: slated for implementation
diff --git a/proposals/SUMMARY.md b/proposals/SUMMARY.md
index 0827524..b8d6265 100644
--- a/proposals/SUMMARY.md
+++ b/proposals/SUMMARY.md
@@ -257,6 +257,7 @@
  - [`344-protocol-info-leaks`](./344-protocol-info-leaks.txt): Prioritizing Protocol Information Leaks in Tor (OPEN)
  - [`345-specs-in-mdbook`](./345-specs-in-mdbook.md): Migrating the tor specifications to mdbook (CLOSED)
  - [`346-protovers-again`](./346-protovers-again.md): Clarifying and extending the use of protocol versioning (OPEN)
+ - [`347-domain-separation`](./347-domain-separation.md): Domain separation for certificate signing keys (OPEN)