commit 3475598f9ae584e01ef603404f9e096287370e53
parent bc42d15a0ceafb5d6535d7db538fa995c936be4d
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 8 Feb 2022 09:42:07 +0100
typos
Diffstat:
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -422,7 +422,7 @@
<dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
<dd>
is a function to sign a message (typically encrypted record data) using the (blinded) private
- key d (d'), yielding an unforgable cryptographic signature.
+ key d (d'), yielding an unforgeable cryptographic signature.
In order to leverage performance-enhancing caching features of certain
underlying storages, in particular DHTs, a deterministic signature
scheme is recommended.
@@ -432,7 +432,7 @@
is a function to verify the signature was created by
the private key d (or derived key d') corresponding to
the zone key zk (or derived zone key zk')
- where d,zk := Keygen(). If deriviations were used, they
+ where d,zk := Keygen(). If derivations were used, they
must have used the same label.
The function returns a boolean value of "TRUE" if the signature is valid,
and otherwise "FALSE".
@@ -687,7 +687,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<dd>
denotes the absolute 64-bit date when the revocation was computed.
In microseconds since midnight (0 hour), January 1, 1970 UTC in network
- byte order. This is the same value as the timestamp used in the
+ byte order. This is the same value as the time stamp used in the
individual PoW calculations.
</dd>
<dt>TTL</dt>
@@ -719,7 +719,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
</dd>
<dt>SIGNATURE</dt>
<dd>
- A signature over a timestamp and the zone zk of the zone
+ A signature over a time stamp and the zone zk of the zone
which is revoked and corresponds to the key used in the PoW.
The signature is created using the Sign() function of
the cryptosystem of the zone and the private key
@@ -729,7 +729,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<!-- FIXME Do we really need a purpose? -->
<t>
The signature over the public key covers a 32-bit header
- prefixed to the timestamp and public key fields.
+ prefixed to the time stamp and public key fields.
The header includes the key length and signature purpose.
The wire format is illustrated
in <xref target="figure_revsigwithpseudo"/>.
@@ -779,7 +779,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<li>The signature MUST be verified against the zone key.</li>
<li>The set of POW values MUST NOT contain duplicates which MUST be checked by verifying that the values are strictly monotonically increasing.</li>
<li>The average number of leading zeroes D' resulting from the provided
- POW values MUST be greater than and not equal to D. Implementors
+ POW values MUST be greater than and not equal to D. Implementers
MUST NOT use an integer data type to calculate or represent D'.</li>
<li>The validation period (TTL) of the revocation is calculated as
(D'-D) * EPOCH * 1.1. The EPOCH is extended by
@@ -1451,7 +1451,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
<t>
NOTE: If an application uses DNS names obtained from GNS2DNS records
in a DNS request they must first be converted to a punycode representation
- <xref target="RFC5890" />.
+ <xref target="RFC5890" />. <!-- punycode or IDNA? -->
</t>
</section>
</section>
@@ -2462,7 +2462,7 @@ NICK: john (Supplemental)
via a revocation message would only be secure as long as both
cryptosystems are still secure against forgery. Such a planned,
non-emergency migration to another cryptosystem should be done by
- running zones for both ciphersystems in parallel for a while. The
+ running zones for both cipher systems in parallel for a while. The
migration would conclude by revoking the legacy zone key only once
it is deemed no longer secure, and hopefully after most users have
migrated to the replacement.
