[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [torspec/master] Give the rsa1024-relay-id-migration.txt proposal a number



commit 8bc6db6a9f8ac4eb3d85cfe574653b1ef8f255d3
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Tue Apr 8 14:44:33 2014 -0400

    Give the rsa1024-relay-id-migration.txt proposal a number
---
 proposals/230-rsa1024-relay-id-migration.txt |   83 ++++++++++++++++++++++++++
 proposals/xxx-rsa1024-relay-id-migration.txt |   83 --------------------------
 2 files changed, 83 insertions(+), 83 deletions(-)

diff --git a/proposals/230-rsa1024-relay-id-migration.txt b/proposals/230-rsa1024-relay-id-migration.txt
new file mode 100644
index 0000000..d2f3aff
--- /dev/null
+++ b/proposals/230-rsa1024-relay-id-migration.txt
@@ -0,0 +1,83 @@
+Filename: 230-rsa1024-relay-id-maigration.txt
+Title: How to change RSA1024 relay identity keys
+Authors: Nick Mathewson
+Created: 7 April 2014
+Target: 0.2.?
+Status: Draft
+
+1. Intro and motivation
+
+   Some times, a relay would like to migrate from one RSA1024
+   identity key to another without losing its previous status.
+
+   This is especially important because proposal 220 ("Migrate
+   server identity keys to Ed25519") is not yet implemented, and so
+   server identity keys are not kept offline.  So when an OpenSSL
+   bug like CVE-2014-0160 makes memory-reading attacks a threat to
+   identity keys, we need a way for routers to migrate ASAP.
+
+   This proposal does not cover migrating RSA1024 OR identity keys
+   for authorities.
+
+2. Design
+
+   I propose that when a relay changes its identity key, it should
+   include a "old-identity" field in its server descriptor for 60 days
+   after the migration.  This old-identity would include the
+   old RSA1024 identity, a signature of the new identity key
+   with the old one, and the date when the migration occurred.
+
+   This field would appear as an "old-id" field in microdescriptors,
+   containing a SHA1 fingerprint of the old identity key, if the
+   signature turned out to be value.
+
+   Authorities would store old-identity => new-identity mappings,
+   and:
+
+      * Treat history information (wfu, mtbf, [and what else?]) from
+        old identities as applying to new identities instead.
+
+      * No longer accept any routers descriptors signed by the old
+        identity.
+
+   Clients would migrate any guard entries for the old identity to
+   the new identity.
+
+   (This will break clients connections for clients who try to
+   connect to the old identity key before learning about the new
+   one, but the window there won't be large for any single router.)
+
+3. Descriptor format details
+
+   Router descriptors may contain these new elements:
+
+      "old-rsa1024-id-key" NL RSA_KEY NL
+
+        Contains an old RSA1024 identity key. If this appears,
+        old-rsa1024-id-migration must also appear. [At most once]
+
+      "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL
+
+        Contains a signature of:
+         The bytes "RSA1024 ID MIGRATION"               [20 bytes]
+         The ISO-TIME field above as an 8 byte field    [8 bytes]
+         A SHA256 hash of the new identity              [32 bytes]
+
+        If this appears, "old-rsa1024-id-key" must also appear.
+        [At most once].
+
+4. Interface
+
+   To use this feature, a router should rename its secret_id_key
+   file to secret_id_key_OLD.  The first time that Tor starts and
+   finds a secret_id_key_OLD file, it generates a new ID key if one
+   is not present, and generates the text of the old-rsa-1024-id-key
+   and old-rsa1024-id-migration fields above.  It stores them in a
+   new "old_id_key_migration" file, and deletes the
+   secret_id_key_OLD file.  It includes them in its desecriptors.
+
+   Sixty days after the stored timestamp, the router deletes the
+   "old_id_key_migration" file and stops including its contents in
+   the descriptor.
+
+
diff --git a/proposals/xxx-rsa1024-relay-id-migration.txt b/proposals/xxx-rsa1024-relay-id-migration.txt
deleted file mode 100644
index 45166f0..0000000
--- a/proposals/xxx-rsa1024-relay-id-migration.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-Filename: xxx-rsa1024-relay-id-maigration.txt
-Title: How to change RSA1024 relay identity keys
-Authors: Nick Mathewson
-Created: 7 April 2014
-Target: 0.2.?
-Status: Draft
-
-1. Intro and motivation
-
-   Some times, a relay would like to migrate from one RSA1024
-   identity key to another without losing its previous status.
-
-   This is especially important because proposal 220 ("Migrate
-   server identity keys to Ed25519") is not yet implemented, and so
-   server identity keys are not kept offline.  So when an OpenSSL
-   bug like CVE-2014-0160 makes memory-reading attacks a threat to
-   identity keys, we need a way for routers to migrate ASAP.
-
-   This proposal does not cover migrating RSA1024 OR identity keys
-   for authorities.
-
-2. Design
-
-   I propose that when a relay changes its identity key, it should
-   include a "old-identity" field in its server descriptor for 60 days
-   after the migration.  This old-identity would include the
-   old RSA1024 identity, a signature of the new identity key
-   with the old one, and the date when the migration occurred.
-
-   This field would appear as an "old-id" field in microdescriptors,
-   containing a SHA1 fingerprint of the old identity key, if the
-   signature turned out to be value.
-
-   Authorities would store old-identity => new-identity mappings,
-   and:
-
-      * Treat history information (wfu, mtbf, [and what else?]) from
-        old identities as applying to new identities instead.
-
-      * No longer accept any routers descriptors signed by the old
-        identity.
-
-   Clients would migrate any guard entries for the old identity to
-   the new identity.
-
-   (This will break clients connections for clients who try to
-   connect to the old identity key before learning about the new
-   one, but the window there won't be large for any single router.)
-
-3. Descriptor format details
-
-   Router descriptors may contain these new elements:
-
-      "old-rsa1024-id-key" NL RSA_KEY NL
-
-        Contains an old RSA1024 identity key. If this appears,
-        old-rsa1024-id-migration must also appear. [At most once]
-
-      "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL
-
-        Contains a signature of:
-         The bytes "RSA1024 ID MIGRATION"               [20 bytes]
-         The ISO-TIME field above as an 8 byte field    [8 bytes]
-         A SHA256 hash of the new identity              [32 bytes]
-
-        If this appears, "old-rsa1024-id-key" must also appear.
-        [At most once].
-
-4. Interface
-
-   To use this feature, a router should rename its secret_id_key
-   file to secret_id_key_OLD.  The first time that Tor starts and
-   finds a secret_id_key_OLD file, it generates a new ID key if one
-   is not present, and generates the text of the old-rsa-1024-id-key
-   and old-rsa1024-id-migration fields above.  It stores them in a
-   new "old_id_key_migration" file, and deletes the
-   secret_id_key_OLD file.  It includes them in its desecriptors.
-
-   Sixty days after the stored timestamp, the router deletes the
-   "old_id_key_migration" file and stops including its contents in
-   the descriptor.
-
-



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits