Clarify who sends certs and chains

svn:r3462
This commit is contained in:
Nick Mathewson 2005-01-30 00:20:15 +00:00
parent 247bef6241
commit 522fdb65de

View File

@ -71,11 +71,10 @@ TODO: (very soon)
support any suite without ephemeral keys, symmetric keys of at
least 128 bits, and digests of at least 160 bits.
[what kind of cert does an OP send? -RD]
An OR always sends a two-certificate chain, consisting of a self-signed
certificate containing the OR's identity key, and a second certificate
using a short-term connection key. The commonName of the second
certificate is the OR's nickname, and the commonName of the first
An OP or OR always sends a two-certificate chain, consisting of a
self-signed certificate containing the OR's identity key, and a second
certificate using a short-term connection key. The commonName of the
second certificate is the OR's nickname, and the commonName of the first
certificate is the OR's nickname, followed by a space and the string
"<identity>".
@ -85,6 +84,10 @@ TODO: (very soon)
EXTEND cell, the expected identity key is the one given in the cell.) If
the key is not as expected, the party must close the connection.
All parties SHOULD reject connections to or from ORs that have malformed
or missing certificates. ORs MAY accept connections from OPs with
malformed or missing certificates.
Once a TLS connection is established, the two sides send cells
(specified below) to one another. Cells are sent serially. All
cells are 512 bytes long. Cells may be sent embedded in TLS