[lsd0001] branch master updated: typos

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 3475598  typos
3475598 is described below

commit 3475598f9ae584e01ef603404f9e096287370e53
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Feb 8 09:42:07 2022 +0100

    typos
---
 draft-schanzen-gns.xml | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 5f38d97..49faeeb 100644
--- 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.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.