r11789@catbus: nickm | 2007-02-12 22:42:58 -0500

 Merge proposal 106 into tor-spec.txt; reformat it slightly; mark it closed.


svn:r9576

1 files changed, 33 insertions, 33 deletions

diff --git a/proposals/106-less-tls-constraint.txt b/proposals/106-less-tls-constraint.txt
index f44532e..6f53497 100644
--- a/proposals/106-less-tls-constraint.txt
+++ b/proposals/106-less-tls-constraint.txt
@@ -4,7 +4,7 @@ Version: $Revision: 12105 $
 Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $
 Author: Nick Mathewson
 Created:
-Status: Finished
+Status: Closed
 
 Overview:
 
@@ -22,11 +22,11 @@ Motivation:
 
 What we check now, and where we check it:
 
-tor_tls_check_lifetime:
+ tor_tls_check_lifetime:
     peer has certificate
     notBefore <= now <= notAfter
 
-tor_tls_verify:
+ tor_tls_verify:
     peer has at least one certificate
     There is at least one certificate in the chain
     At least one of the certificates in the chain is not the one used to
@@ -34,16 +34,16 @@ tor_tls_verify:
     The certificate _not_ used to negotiate the connection has signed the
         link cert
 
-tor_tls_get_peer_cert_nickname:
+ tor_tls_get_peer_cert_nickname:
     peer has a certificate.
     certificate has a subjectName.
     subjectName has a commonName.
     commonName consists only of characters in LEGAL_NICKNAME_CHARACTERS. [2]
 
-tor_tls_peer_has_cert:
+ tor_tls_peer_has_cert:
     peer has a certificate.
 
-connection_or_check_valid_handshake:
+ connection_or_check_valid_handshake:
     tor_tls_peer_has_cert [1]
     tor_tls_get_peer_cert_nickname [1]
     tor_tls_verify [1]
@@ -52,33 +52,33 @@ connection_or_check_valid_handshake:
     If we initiated the connection, then we got the identity digest we
         expected.
 
-USEFUL THINGS WE COULD DO:
+ USEFUL THINGS WE COULD DO:
 
-[1] We could just not force clients to have any certificate at all, let alone
-    an identity certificate.  Internally to the code, we could assign the
-    identity_digest field of these or_connections to a random number, or even
-    not add them to the identity_digest->or_conn map.
-[so if somebody connects with no certs, we let them. and mark them as
-a client and don't treat them as a server. great. -rd]
+ [1] We could just not force clients to have any certificate at all, let alone
+     an identity certificate.  Internally to the code, we could assign the
+     identity_digest field of these or_connections to a random number, or even
+     not add them to the identity_digest->or_conn map.
+ [so if somebody connects with no certs, we let them. and mark them as
+ a client and don't treat them as a server. great. -rd]
 
-[2] Instead of using a restricted nickname character set that makes our
-    commonName structure look unlike typical SSL certificates, we could treat
-    the nickname as extending from the start of the commonName up to but not
-    including the first non-nickname character.
+ [2] Instead of using a restricted nickname character set that makes our
+     commonName structure look unlike typical SSL certificates, we could treat
+     the nickname as extending from the start of the commonName up to but not
+     including the first non-nickname character.
 
-    Alternatively, we could stop checking commonNames entirely.  We don't
-    actually _do_ anything based on the nickname in the certificate, so
-    there's really no harm in letting every router have any commonName it
-    wants.
-[this is the better choice -rd]
-[agreed. -nm]
+     Alternatively, we could stop checking commonNames entirely.  We don't
+     actually _do_ anything based on the nickname in the certificate, so
+     there's really no harm in letting every router have any commonName it
+     wants.
+ [this is the better choice -rd]
+ [agreed. -nm]
 
 REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS:
 
-Assuming that we removed the above requirements, we could then (in a later
-release) have clients not send certificates, and sometimes and started making
-our DNs a little less formulaic, client->server OR connections would still be
-recognizable by:
+ Assuming that we removed the above requirements, we could then (in a later
+ release) have clients not send certificates, and sometimes and started
+ making our DNs a little less formulaic, client->server OR connections would
+ still be recognizable by:
     having a two-certificate chain sent by the server
     using a particular set of ciphersuites
     traffic patterns
@@ -86,7 +86,7 @@ recognizable by:
 
 OTHER IMPLICATIONS:
 
-If we stop verifying the above requirements:
+ If we stop verifying the above requirements:
 
     It will be slightly (but only slightly) more common to connect to a non-Tor
     server running TLS, and believe that you're talking to a Tor server (until
@@ -95,8 +95,8 @@ If we stop verifying the above requirements:
     It will be far easier for non-Tor SSL clients to accidentally connect to
     Tor servers and speak HTTPS or whatever to them.
 
-If, in a later release, we have clients not send certificates, and we make
-DNs less recognizable:
+ If, in a later release, we have clients not send certificates, and we make
+ DNs less recognizable:
 
     If clients don't send certs, servers don't need to verify them: win!
 
@@ -107,6 +107,6 @@ DNs less recognizable:
 
 OTHER SPEC CHANGES:
 
-When a client doesn't give us an identity, we should never extend any
-circuits to it (duh), and we should allow it to set circuit ID however it
-wants.
+ When a client doesn't give us an identity, we should never extend any
+ circuits to it (duh), and we should allow it to set circuit ID however it
+ wants.