prop224: Switch back to a TYPE/LEN/KEY construction for cells.

Nick pointed out that having the length explicit is better for
backwards/future compatibility.

Also change some field names so that they are mostly uniform
throughout the proposal.

1 files changed, 24 insertions, 32 deletions

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 1edbc08..001d2ba 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -152,19 +152,6 @@ Status: Draft
    themselves, but over those strings prefixed with a distinguishing
    value.
 
-   Through this proposal we use the following construction when sending
-   cryptographic keys in tor cells:
-
-        KEYTYPE         [1 byte]
-        KEY             [depends on KEYTYPE]
-
-   In this case the size of the KEY depends on the KEYTYPE. Here are the
-   currently defined key types:
-
-     * The KEYTYPE value [01] is for Ed25519 keys (size: 32 bytes).
-     * The KEYTYPE value [02] is for Curve25519 keys (size: 32 bytes).
-     * The KEYTYPE value [03] is for truncated Curve25519 keys (size: 8 bytes).
-
 0.4. Protocol building blocks [BUILDING-BLOCKS]
 
    In sections below, we need to transmit the locations and identities
@@ -1192,10 +1179,12 @@ Status: Draft
 
    An INTRODUCE1 cell has the following contents:
 
-     AUTH_KEYTYPE    [1 byte]
-     AUTH_KEYID      [depends on AUTH_KEYTYPE]
-     ENC_KEYTYPE     [1 byte]
-     ENC_KEYID       [depends on ENC_KEYTYPE]
+     AUTH_KEY_TYPE   [1 byte]
+     AUTH_KEY_LEN    [1 byte]
+     AUTH_KEY        [AUTH_KEY_LEN bytes]
+     ENC_KEY_TYPE    [1 byte]
+     ENC_KEY_LEN     [1 byte]
+     ENC_KEY         [ENC_KEY_LEN bytes]
      N_EXTENSIONS    [1 byte]
      N_EXTENSIONS times:
        EXT_FIELD_TYPE [1 byte]
@@ -1208,20 +1197,20 @@ Status: Draft
    encryption method? The latter is probably safer.]
 
    Upon receiving an INTRODUCE1 cell, the introduction point checks
-   whether AUTH_KEYID and ENC_KEYID match a configured introduction
+   whether AUTH_KEY and ENC_KEY match a configured introduction
    point authentication key and introduction point encryption key.  If
    they do, the cell is relayed; if not, it is not.
 
-   (After checking AUTH_KEYID and ENC_KEYID and finding no match, the
-   introduction point should check to see whether a legacy hidden service is
-   running whose PK_ID is the first 20 bytes of AUTH_KEYID.  If so, it
-   behaves as in rend-spec.txt.)
+   (After checking AUTH_KEY and ENC_KEY and finding no match, the introduction
+   point should check to see whether a legacy hidden service is running whose
+   PK_ID is the first 20 bytes of AUTH_KEY.  If so, it behaves as in
+   rend-spec.txt.)
 
-   The AUTH_KEYTYPE is an Ed25519 public key (value [01]).
+   The AUTH_KEY_TYPE is an Ed25519 public key (value [01]).
 
-   The ENC_KEYTYPE is a truncated Curve25519 public key (value [03]). (This key
+   The ENC_KEY_TYPE is a truncated Curve25519 public key (value [03]). (This key
    is safe to truncate, since all the keys are generated by the hidden service
-   host, and the ID is only valid relative to a single AUTH_KEYID.)  The
+   host, and the ID is only valid relative to a single AUTH_KEY.)  The
    ENCRYPTED field is as described in 3.3 below.
 
    To relay an INTRODUCE1 cell, the introduction point sends an
@@ -1296,7 +1285,8 @@ Status: Draft
           EXT_FIELD_LEN                          [1 byte]
           EXT_FIELD                              [EXT_FIELD_LEN bytes]
       ONION_KEY_TYPE                             [1 bytes]
-      ONION_KEY                                  [depends on ONION_KEY_TYPE]
+      ONION_KEY_LEN                              [1 bytes]
+      ONION_KEY                                  [ONION_KEY_LEN bytes]
       NSPEC      (Number of link specifiers)     [1 byte]
       NSPEC times:
           LSTYPE (Link specifier type)           [1 byte]
@@ -1394,10 +1384,12 @@ Status: Draft
    Substituting those fields into the INTRODUCE1 cell body format
    described in [FMT_INTRO1] above, we have
 
-            AUTH_KEYTYPE                [1 byte]
-            AUTH_KEYID                  [depends on AUTH_KEYTYPE]
-            ENC_KEYTYPE                 [1 byte]
-            ENC_KEYID                   [depends on ENC_KEYTYPE]
+            AUTH_KEY_TYPE               [1 byte]
+            AUTH_KEY_LEN                [1 byte]
+            AUTH_KEY                    [AUTH_KEY_LEN bytes]
+            ENC_KEY_TYPE                [1 byte]
+            ENC_KEY_LEN                 [1 byte]
+            ENC_KEY                     [ENC_KEY_LEN bytes]
             N_EXTENSIONS                [1 bytes]
             N_EXTENSIONS times:
                EXT_FIELD_TYPE           [1 byte]
@@ -1416,10 +1408,10 @@ Status: Draft
    described in [LEGACY-INTRODUCE1].)
 
    Here, the encryption key plays the role of B in the regular ntor
-   handshake, and the AUTH_KEYID field plays the role of the node ID.
+   handshake, and the AUTH_KEY field plays the role of the node ID.
    The CLIENT_PK field is the public key X. The ENCRYPTED_DATA field is
    the message plaintext, encrypted with the symmetric key ENC_KEY. The
-   MAC field is a MAC of all of the cell from the AUTH_KEYID through the
+   MAC field is a MAC of all of the cell from the AUTH_KEY through the
    end of ENCRYPTED_DATA, using the MAC_KEY value as its key.
 
    To process this format, the hidden service checks PK_VALID(CLIENT_PK)