[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] fix some typos on proposal 220
commit 7ab099c16aec1b30b0c9217793afb8391ba70a56
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
Date: Sun Feb 2 22:32:53 2014 -0500
fix some typos on proposal 220
---
proposals/220-ecc-id-keys.txt | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/proposals/220-ecc-id-keys.txt b/proposals/220-ecc-id-keys.txt
index ebbc3b5..b14fea7 100644
--- a/proposals/220-ecc-id-keys.txt
+++ b/proposals/220-ecc-id-keys.txt
@@ -59,7 +59,7 @@ Status: Draft
1.1. 'Personalized' signatures
Each of the keys introduced here is used to sign more than one kind
- of document. While these documents should be unambiguous, I'd going
+ of document. While these documents should be unambiguous, I'm going
to forward-proof the signatures by specifying each signature to be
generated, not on the document itself, but on the document prefixed
with some distinguishing string.
@@ -106,7 +106,7 @@ Status: Draft
SIGNATURE [64 Bytes]
FIXED_PREFIX is "REVOKEID" or "REVOKESK". VERSION is [01]. KEYTYPE is
- [01] for revoking a signing key or [02] or revoking an identity key.
+ [01] for revoking a signing key or [02] for revoking an identity key.
REVOKED_KEY is the key being revoked; IDENTITY_KEY is the node's
Ed25519 identity key. PUBLISHED is the time that the document was
generated, in seconds since the epoch. EXTRA_STUFF is left for a
@@ -132,7 +132,7 @@ Status: Draft
But we also support offline identity keys:
* When a Tor node starts with an Ed25519 public identity key
- but no private identity key, it checks wither it has
+ but no private identity key, it checks whether it has
a currently valid certified signing keypair. If it does,
it starts. Otherwise, it refuses to start.
* If a Tor node's signing key is going to expire soon, it starts
@@ -152,9 +152,9 @@ Status: Draft
signing key and checking the signature before fully parsing the rest
of the document. -NM]
- When an identity-ed25519 element is present, there must also be an
+ When an identity-ed25519 element is present, there must also be a
"router-signature-ed25519" element. It MUST be the next-to-last
- element in the descriptor, appearing immediately before RSA
+ element in the descriptor, appearing immediately before the RSA
signature. It MUST contain an ed25519 signature of the entire
document, from the first character up to but not including the
"router-signature-ed25519" element, prefixed with the string "Tor
@@ -162,9 +162,9 @@ Status: Draft
"router-signature-ed25519" SP signature NL
- Were 'signature' is encoded in base64 with terminating =s removed.
+ Where 'signature' is encoded in base64 with terminating =s removed.
- The identity key in the identity-ed25519 key MUST be the one used to
+ The identity-key in the identity-ed25519 key MUST be the one used to
sign the certification, and the signing key in the certification MUST
be the one used to sign the document.
@@ -204,9 +204,9 @@ Status: Draft
appear in router descriptors.
Additionally, we add the base64-encoded, =-stripped SHA256 digest of
- a node's extra-info document field to the extra-info-digest line.
- (All versions of Tor that recognize this line allow an extra field
- there.)
+ a node's extra-info document field to the extra-info-digest line in
+ the router descriptor. (All versions of Tor that recognize this line
+ allow an extra field there.)
2.3.3. A note on signature verification
@@ -259,7 +259,7 @@ Status: Draft
"id" SP ed25519-identity NL
- where ed25519-identity is base-64 encoded, with trailing = characters
+ where ed25519-identity is base64-encoded, with trailing = characters
omitted. In vote documents, it may be replaced by the format:
"id" SP "none" NL
@@ -348,7 +348,7 @@ Status: Draft
7: RSA cross-certification for Ed25519 identity key
The content of certificate type 4 is:
- Ed25519 identity key [32 byets]
+ Ed25519 identity key [32 bytes]
Signing key certificate as in 2.1 above [variable length]
The content of certificate type 5 is:
@@ -463,9 +463,9 @@ Status: Draft
Anywhere in the interface that takes an $identity should be able to
take an ECC identity too. ECC identities are case-sensitive base64
encodings of Ed25519 identity keys. You can use $ to indicate them as
- well; we distinguish RSA identity digests length.
+ well; we distinguish RSA identity digests by length.
- When we need to indicate an Ed25519 identity key in an hostname
+ When we need to indicate an Ed25519 identity key in a hostname
format (as in a .exit address), we use the lowercased version of the
name, and perform a case-insensitive match. (This loses us a little
less than one bit per byte of name, leaving plenty of bits to make
@@ -477,7 +477,7 @@ Status: Draft
Clients shouldn't accept .exit addresses with Ed25519 names on SOCKS
or DNS ports by default, even when AllowDotExit is set. We can add
- another option for the later if there's a good reason to have this.
+ another option for them later if there's a good reason to have this.
We need an identity-to-node map for ECC identity and for RSA
identity.
@@ -488,7 +488,7 @@ Status: Draft
7. Hidden service changes out of scope
- Hidden services need to be able identity nodes by ECC keys, just as
+ Hidden services need to be able to identity nodes by ECC keys, just as
they will need to include ntor keys as well as TAP keys. Not just
yet though. This needs to be part of a bigger hidden service
revamping strategy.
@@ -518,3 +518,4 @@ Status: Draft
* Ed25519 support for hidden services
* Bridge identity support.
* Ed25519-aware family support
+
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits