[lsd0001] branch master updated: abstract and bytes

[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 7942bb6  abstract and bytes
7942bb6 is described below

commit 7942bb6f71d0ad26458e23362337e5f9ee4fbc38
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sat Dec 4 09:50:34 2021 +0100

    abstract and bytes
---
 draft-schanzen-gns.xml | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 61af916..d51e138 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -26,13 +26,13 @@
 <?rfc sortrefs="yes" ?>
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info" 
docName="draft-schanzen-gns-03" ipr="trust200902" obsoletes="" updates="" 
submissionType="IETF" xml:lang="en" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info" 
docName="draft-schanzen-gns-05" ipr="trust200902" obsoletes="" updates="" 
submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.26.0 -->
  <front>
   <title abbrev="The GNU Name System">
    The GNU Name System
   </title>
-  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-04"/>
+  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-05"/>
   <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
    <organization>GNUnet e.V.</organization>
    <address>
@@ -75,7 +75,22 @@
   <workgroup>Independent Stream</workgroup>
   <keyword>name systems</keyword>
   <abstract>
-   <t>This document contains the GNU Name System (GNS) technical 
specification.</t>
+    <t>
+      This document contains the GNU Name System (GNS) technical
+      specification. GNS is a decentralized and censorship-resistant name
+      system that provides a privacy-enhancing alternative to the Domain
+      Name System (DNS).
+    </t>
+    <t>
+      This document defines the normative wire format of resource records,
+      resolution processes, cryptographic routines and security
+      considerations for use by implementers.
+    </t>
+    <t>
+      This specification was developed outside the IETF and does not have
+      IETF consensus.  It is published here to guide implementation of GNS
+      and to ensure interoperability among implementations.
+    </t>
   </abstract>
  </front>
  <middle>
@@ -558,8 +573,8 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          HKDF is a hash-based key derivation function as defined in
          <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
          extraction phase and HMAC-SHA256 for the expansion phase.
-         The output keying material is 32 octets (256 bits) for the symmetric
-         key and 4 octets (32 bits) for the nonce.
+         The output keying material is 32 bytes (256 bits) for the symmetric
+         key and 4 bytes (32 bits) for the nonce.
          The symmetric key "K" is a 256-bit AES <xref target="RFC3826" /> key.
        </t>
        <t>
@@ -726,7 +741,7 @@ zk' := h * zk
            signature part "R" according to <xref target="ed25519" />.
            Instead, signatures MUST be generated as follows for any given
            message M:
-           A nonce is calculated from the highest 32 octets of the
+           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 "M" to "r".
            This way, we include the full derivation path in the calculation
@@ -760,7 +775,7 @@ BDATA := XSalsa20(K, IV, RDATA) = CIPHERTEXT | TAG
            ciphertext concatenated with the 128-bit authentication
            tag "TAG".
            Accordingly, the length of BDATA equals the length of the
-           RDATA plus the 16 octets of the authentication tag.
+           RDATA plus the 16 bytes of the authentication tag.
          </t>
          <t>
            The key "K" and counter "IV" are derived from
@@ -776,14 +791,14 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            HKDF is a hash-based key derivation function as defined in
            <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
            extraction phase and HMAC-SHA256 for the expansion phase.
-           The output keying material is 32 octets (256 bits) for the symmetric
-           key and 16 octets (128 bits) for the NONCE.
+           The output keying material is 32 bytes (256 bits) for the symmetric
+           key and 16 bytes (128 bits) for the NONCE.
            The symmetric key "K" is a 256-bit XSalsa20
            <xref target="XSalsa20" /> key.
            No additional authenticated data (AAD) is used.
          </t>
          <t>
-           The nonce is combined with an 8 octet initialization vector.
+           The nonce is combined with an 8 byte initialization vector.
            The initialization vector is the expiration time of the
            resource record block in network byte order.
            The resulting counter ("IV") wire format is as follows:
@@ -1200,7 +1215,7 @@ q := SHA512 (HDKD-Public(zk, label))
          </dd>
          <dt>PADDING</dt>
          <dd>
-           The padding MUST contain the value 0 in all octets.
+           The padding MUST contain the value 0 in all bytes.
            The padding MUST ensure that the size of the RDATA WITHOUT the RR
            COUNT field is a power of two.
            As a special exception, record sets with (only) a zone delegation
@@ -1524,7 +1539,7 @@ NICK: john (Supplemental)
        </t>
        <dl>
          <dt>S</dt>
-         <dd>The salt. Fixed 16-octet string: "GnsRevocationPow".</dd>
+         <dd>The salt. Fixed 16-byte string: "GnsRevocationPow".</dd>
          <dt>t</dt>
          <dd>Number of iterations: 3</dd>
          <dt>m</dt>

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