negotiating-channels: reowkr followup from !226

1 files changed, 47 insertions, 39 deletions

diff --git a/spec/tor-spec/negotiating-channels.md b/spec/tor-spec/negotiating-channels.md
index a95d4db..fbd3d6a 100644
--- a/spec/tor-spec/negotiating-channels.md
+++ b/spec/tor-spec/negotiating-channels.md
@@ -167,19 +167,14 @@ A CERTS cell MUST have no more than one certificate of any CertType.
 
 ### Authenticating the responder from its CERTS {#auth-responder}
 
-The responder's CERTS cell is meant to prove
-that the responder posses one or more
-[relay identities](./relay-keys.md#identity).
-It does this by containing certificate chains
-from each relay identity key
-to the TLS certificate presented during the TLS handshake.
+When the initiator is required
+by other parts of this specification
+to verify the identity of the responder,
+the responder must provide a CERTS cell as follows:
 
-> The responder's ownership of that TLS certificate
-> was already proven during the TLS hadnshake itself.
+XXXX ^ but I think this is always required?  So surely this should be
 
-From a CERTS cell,
-an initiator has enough information to authenticate the responder.
-To do so, the initiator MUST check that all of the following apply:
+The responder's CERTS cell is as follows:
 
 - The CERTS cell contains exactly one CertType 4 Ed25519
   `IDENTITY_V_SIGNING_CERT`.
@@ -197,25 +192,56 @@ To do so, the initiator MUST check that all of the following apply:
     that was presented curing the TLS handshake.
 - All of the certs above must be correctly signed, and not expired.
 
-It the above tests all pass,
+The initiator must check all of the above.
+If this is successful
 the initiator knows that the responder
 has the identity `KP_relayid_ed`.
 
+> The responder's CERTS cell is meant to prove
+> that the responder posses one or more
+> [relay identities](./relay-keys.md#identity).
+> It does this by containing certificate chains
+> from each relay identity key
+> to the TLS certificate presented during the TLS handshake.
+
+> The responder's ownership of that TLS certificate
+> was already proven during the TLS hadnshake itself.
 
 ### Validating an initiator's CERTS {#validate-initiator-certs}
 
+When the responder is required
+by other parts of this specification
+to verify the identity of the initiator,
+the initiator must provide a CERTS cell.
 
-An initiator's CERTS cell
-differs from a responders CERTS cell
-in that it contains a `SIGNING_V_LINK_AUTH` certificate
-instead of a `SIGNING_V_TLS_CERT` certificate.
+> Recall that
+> [not all initiators authenticate themselves](./channels.md#does-initiator-authenticate);
+> bridges and clients do not prove their identity.
 
+The initiator's CERTS cell must conform to the rules
+for the responder's CERTS cell (see above)
+[mutatis mutandis](https://en.wikipedia.org/wiki/Mutatis_mutandis),
+except that:
 
-> First, recall that
-> [not all initiators authenticate themselves](./channels.md#does-initiator-authenticate);
-> bridges and clients do not do so.
->
-> Second, if the initiator *does* choose to authenticate:
+**Instead** of containg a `SIGNING_V_TLS_CERT`,
+
+- The CERTS cell contains exactly one CertType 6
+  `SIGNING_V_LINK_AUTH` certificate.
+  - This certificate must be signed with `KP_relayid_ed`.
+    (Its subject key is deemed to be `KP_link_ed`.)
+- All of the certs above must be correctly signed, and not expired.
+
+The responder must check all of the CERTS cell's properties
+(as stated here, and in the previous section).
+If this is successful
+**and**
+the initiator can send a valid
+[AUTHENTICATE cell](#AUTHENTICATE-cells),
+then the initiator has ownership of the presented `KP_relayid_ed`.
+
+> Note that
+> the CERTS cell is _not_ yet sufficent to authenticate the channel,
+> until AUTHENTICATE is received:
 > unlike the responder,
 > the initiator is not required to present a TLS certificate
 > during the TLS handshake.
@@ -228,24 +254,6 @@ instead of a `SIGNING_V_TLS_CERT` certificate.
 > This key is later used to sign an "authentication challenge",
 > and bind it to the channel.
 
-To process an initiator's CERTS cell,
-the responder MUST procede as for a responder's certificates,
-[as described above](#auth-responder),
-except that **instead** of checking for a `SIGNING_V_TLS_CERT`,
-it must verify that:
-
-- The CERTS cell contains exactly one CertType 6
-  `SIGNING_V_LINK_AUTH` certificate.
-  - This certificate must be signed with `KP_relayid_ed`.
-    (Its subject key is deemed to be `KP_link_ed`.)
-- All of the certs above must be correctly signed, and not expired.
-
-This is _not_ yet sufficent to authenticate the channel.
-It only proves that
-_if_ the initiator can send a valid
-[AUTHENTICATE cell](#AUTHENTICATE-cells),
-then the initiator has the presented `KP_relayid_ed`.
-
 ### Authenticating an RSA identity (#auth-RSA)
 
 After processing a CERTS cell