[lsd0001] branch master updated: remove some we's

[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 74d3fa2  remove some we's
74d3fa2 is described below

commit 74d3fa2b09a31129661b923cbf36f37c7bcbcb3d
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sat Feb 19 16:09:47 2022 +0100

    remove some we's
---
 draft-schanzen-gns.xml | 35 +++++++++++++++++------------------
 1 file changed, 17 insertions(+), 18 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index ca3e3e0..66cc5f0 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -412,7 +412,7 @@
        <dd>
          is a zone key derivation function which blinds a private key d
          using label, resulting in another private key which
-         can be used to create cryptographic signatures.  We note that
+         can be used to create cryptographic signatures.
          GNS only requires a signature to be created directly with
          d to sign a revocation message for the zone key zk.
        </dd>
@@ -497,7 +497,7 @@
          Base32GNS-Encode and Base32GNS-Decode, respectively.
        </t>
        <t>
-         For the string representation of a zTLD we define:
+         The string representation of a zTLD is:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 zkl := Base32GNS-Encode(ztype||zkey)
@@ -618,8 +618,8 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          at least D leading zeroes are found in the hash result.
          D is then referred to as the difficulty of the PoW.
          In order to reduce the variance in time it takes to calculate the
-         PoW, we require that a number Z different PoWs must be
-         found that on average have D leading zeroes.
+         PoW, a valid GNS revocation requires that a number Z different PoWs
+         must be found that on average have D leading zeroes.
        </t>
        <t>
          The resulting proofs may then published and disseminated. The concrete
@@ -960,8 +960,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          curve parameters of the twisted Edwards representation
          of Curve25519 <xref target="RFC7748" /> (a.k.a. Ed25519)
          with the ECDSA scheme <xref target="RFC6979" />.
-         Consequently, we use the following naming convention for our
-         cryptographic primitives for PKEY zones:
+         The following naming convention is used for the cryptographic 
primitives of PKEY zones:
        </t>
        <dl>
          <dt>d</dt>
@@ -1142,8 +1141,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
            of Curve25519 <xref target="RFC7748" /> (a.k.a. Ed25519)
            with the Ed25519 scheme <xref target="ed25519" /> as specified in
            <xref target="RFC8032" />.
-           Consequently, we use the following naming convention for our
-           cryptographic primitives for EDKEY zones:
+           The following naming convention is used for the
+           cryptographic primitives of EDKEY zones:
          </t>
          <!-- Check if we want to use RFC8032 instead of paper ed25519 -->
          <dl>
@@ -1236,7 +1235,7 @@ ZKDF-Public(zk,label):
   return zk'
            ]]></artwork>
          <t>
-           We note that implementers SHOULD employ a constant time scalar
+           Implementers SHOULD employ a constant time scalar
            multiplication for the constructions above to protect against
            timing attacks. Otherwise, timing attacks may leak private key
            material if an attacker can predict when a system starts the
@@ -1281,7 +1280,7 @@ ZKDF-Public(zk,label):
            A nonce is calculated from the highest 32 bytes of the
            expansion of the private key d and the blinding factor h.
            The nonce is then hashed with the message to r.
-           This way, we include the full derivation path in the calculation
+           This way, the full derivation path is included in the calculation
            of the R value of the signature, ensuring that it is never reused
            for two different derivation paths or messages.
          </t>
@@ -1638,8 +1637,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
        To be useful, the API MUST permit storing at least 176 byte values
        to be able to support the defined zone delegation record encodings,
        and SHOULD allow at least 1024 byte values.
-       We assume that an implementation realizes two procedures on top of a
-       storage:
+       In the following, it is assumed that an implementation realizes two
+       procedures on top of a storage:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
 PUT(key,value)
@@ -1883,7 +1882,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
        Instead, it MUST respond to a resolution request with either the
        requested resource record or an error message in case the resolution
        fails.
-       In the following, we define how resolution is initiated and each
+       The following sections detail how resolution is initiated and each
        iteration in the resolution is processed.
      </t>
      <t>
@@ -1925,7 +1924,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
          management of root servers in DNS (see <xref target="RFC8324"/>, 
Section 3.10 and 3.12).
        </t>
         <t>
-         In the following, we give examples how a resolver SHOULD
+         Below examples can be found how a resolver SHOULD
          discover the start zone.  The process given is not exhaustive and
          resolvers MAY supplement it with other mechanisms or ignore it if the
          particular application requires a different process.
@@ -2029,8 +2028,8 @@ example.com = zk2
            record could not be processed SHOULD be returned in the error
            description. The implementation MAY choose not to return the reason 
for the failure,
            merely complicating troubleshooting for the user.
-           The next steps depend
-           on the context of the name we are trying to resolve:
+           The next steps depend on the context of the name that is beging
+           resolved:
          </t>
          <ul>
          <li>
@@ -2207,8 +2206,8 @@ example.com = zk2
              merely impacting troubleshooting information for the user.
            </t>
            <t>
-             If the remainder of the name to resolve is empty and we have
-             received a record set containing only a single delegation record, 
the
+             If the remainder of the name to resolve is empty and a record set
+             was received containing only a single delegation record, the
              recursion is continued with the record value as authoritative zone
              and the apex label "@" as remaining name.
              Except in the case where the desired record type as specified by

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