gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0001] branch master updated: add minimum acks


From: gnunet
Subject: [lsd0001] branch master updated: add minimum acks
Date: Tue, 01 Feb 2022 15:17:09 +0100

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

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new b89ee1f  add minimum acks
b89ee1f is described below

commit b89ee1f7215ff8df918e0204e9ec51c8c91362b2
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Tue Feb 1 15:17:03 2022 +0100

    add minimum acks
---
 draft-schanzen-gns.xml | 40 ++++++++++++++++++++++++----------------
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 5ec4713..54c784b 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -201,7 +201,7 @@
        <dd>
         The rightmost label in a GNS name is a GNS Top-Level Domain (TLD).
         Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>),
-        GNS does not expect all users to use the same global root zone. 
Instead, 
+        GNS does not expect all users to use the same global root zone. 
Instead,
          with the exception of Zone Top-Level Domains (see below),
          GNS TLDs are typically part of the configuration of the local resolver
          (see <xref target="governance"/>), and may thus not be globally 
unique.
@@ -390,7 +390,7 @@
        <dt>Verify(zk,message,signature) -> boolean, 
Verify(zk',message,signature) -> boolean</dt>
        <dd>
          is a function to verify the signature was created by
-         the private key d (or derived key d') corresponding to 
+         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
          must have used the same label.
@@ -610,7 +610,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          <dd>A single epoch is fixed at 365 days.</dd>
        </dl>
        <t>
-         The revocation message wire format is illustrated in 
+         The revocation message wire format is illustrated in
          <xref target="figure_revocationdata"/>.
        </t>
        <figure anchor="figure_revocationdata">
@@ -918,11 +918,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        <dl>
          <dt>d</dt>
          <dd>
-           is a 256-bit ECDSA private key. 
+           is a 256-bit ECDSA private key.
          </dd>
          <dt>zk</dt>
          <dd>
-           is the ECDSA public zone key corresponding to d. 
+           is the ECDSA public zone key corresponding to d.
          </dd>
          <dt>p</dt>
          <dd>
@@ -941,7 +941,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          <dt>KeyGen()</dt>
          <dd>The generation of the private
            scalar d and the curve point zk := d*G (where G is the group 
generator
-           of the elliptic curve) as defined in Section 2.2. of 
+           of the elliptic curve) as defined in Section 2.2. of
            <xref target="RFC6979" /> represents the KeyGen() function.
          </dd>
        </dl>
@@ -1023,7 +1023,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          The block counter is a 32-bit integer value in network byte order.
          The initialization vector is the expiration time of the
          resource record block in network byte order.
-         The resulting counter (IV) wire format can be found in 
+         The resulting counter (IV) wire format can be found in
          <xref target="figure_hkdf_ivs_pkey"/>.
        </t>
        <figure anchor="figure_hkdf_ivs_pkey">
@@ -1083,7 +1083,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          <dl>
            <dt>d</dt>
            <dd>
-             is a 256-bit EdDSA private key. 
+             is a 256-bit EdDSA private key.
            </dd>
            <dt>a</dt>
            <dd>
@@ -1092,7 +1092,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            </dd>
            <dt>zk</dt>
            <dd>
-             is the EdDSA public key corresponding to d. It is defined 
+             is the EdDSA public key corresponding to d. It is defined
              as the curve point a*G where G is the
              group generator of the elliptic curve
              as defined in <xref target="ed25519" />.
@@ -1116,7 +1116,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
              The generation of the private key d and the associated public
              key zk := a*G where G is the
              group generator of the elliptic curve and a is an integer
-             derived from d using the SHA-512 hash function 
+             derived from d using the SHA-512 hash function
              as defined
              in Section 3.2. of <xref target="RFC8032" /> represents the 
KeyGen()
              function.
@@ -1170,7 +1170,7 @@ zk' := h * zk
            a concatenation of the label and the string "gns".
            The result of the HKDF must be clamped and interpreted in network
            byte order.
-           a is the 256-bit integer corresponding to the 256-bit private 
+           a is the 256-bit integer corresponding to the 256-bit private
            key d.
            The label is a UTF-8 string under which the resource records are
            published.
@@ -1246,7 +1246,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            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 illustrated in 
+           The resulting counter (IV) wire format is illustrated in
            <xref target="figure_hkdf_ivs_edkey"/>.
          </t>
          <figure anchor="figure_hkdf_ivs_edkey">
@@ -1459,7 +1459,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          resolution process as specified in <xref target="resolution"/>.
        </t>
        <t>
-           A GTS DATA entry wire format is illustrated in 
+           A GTS DATA entry wire format is illustrated in
          <xref target="figure_vpnrecord"/>.
        </t>
        <figure anchor="figure_vpnrecord">
@@ -1573,7 +1573,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
          A GNS implementation must publish RRBLOCKs
          in accordance to the properties and recommendations of the underlying
          storage. This may include a periodic refresh publication.
-         The GNS RRBLOCK wire format is illustrated in 
+         The GNS RRBLOCK wire format is illustrated in
          <xref target="figure_record_block"/>.
        </t>
        <figure anchor="figure_record_block">
@@ -1660,7 +1660,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
        <t>
          A symmetric encryption scheme is used to encrypt the resource records
          set RDATA into the BDATA field of a GNS RRBLOCK.
-         The wire format of the RDATA is illustrated in 
+         The wire format of the RDATA is illustrated in
          <xref target="figure_rdata"/>.
        </t>
        <figure anchor="figure_rdata">
@@ -2366,7 +2366,7 @@ NICK: john (Supplemental)
          as a descriptive comment as defined above.
        </t>
        <t>
-         GANA is requested to populate this registry as listed in 
+         GANA is requested to populate this registry as listed in
          <xref target="figure_rrtypenums"/>.
        </t>
        <figure anchor="figure_rrtypenums">
@@ -2786,6 +2786,14 @@ b9ae0482cdaa9095
          ]]>
        </artwork>
      </section>
+     <section pn="section-acks">
+        <name>Acknowledgements</name>
+        <t>
+          The authors thank D. J. Bernstein, A. Farrel and S. Bortzmeyer for 
their
+          insightful reviews. We thank NLnet and NGI DISCOVERY for funding
+          work on the GNU Name System.
+        </t>
+     </section>
    </middle>
    <back>
      <references>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]