gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: more ise


From: gnunet
Subject: [lsd0001] branch master updated: more ise
Date: Sun, 05 Dec 2021 17:21:08 +0100

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 af4f1b3  more ise
af4f1b3 is described below

commit af4f1b3aa4615ec75d24133997b3c91e84633937
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Dec 5 17:21:04 2021 +0100

    more ise
---
 draft-schanzen-gns.xml | 129 ++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 107 insertions(+), 22 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index a991396..2124358 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -9,13 +9,13 @@
 <!ENTITY RFC3686 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml";>
 <!ENTITY RFC3826 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml";>
 <!ENTITY RFC3912 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml";>
-<!ENTITY RFC4648 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml";>
 <!ENTITY RFC5869 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml";>
 <!ENTITY RFC5890 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml";>
 <!ENTITY RFC5891 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml";>
 <!ENTITY RFC6781 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml";>
 <!ENTITY RFC6895 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml";>
 <!ENTITY RFC6979 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml";>
+<!ENTITY RFC7363 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml";>
 <!ENTITY RFC7748 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml";>
 <!ENTITY RFC8032 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml";>
 <!ENTITY RFC8126 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml";>
@@ -138,7 +138,11 @@
        This document defines the normative wire format of resource records, 
resolution processes,
        cryptographic routines and security considerations for use by 
implementors.
        GNS requires a distributed hash table (DHT) for record storage.
+       In general any API which allows storing a value under a key and 
retrieving
+       a value from the key can be used.
        Specification of the DHT is out of scope of this document.
+       Possible implementation of such a service include <xref 
target="RFC7363" />
+       <xref target="Kademlia" /> or <xref target="Ipfs" />.
      </t>
      <t>
        This specification was developed outside the IETF and does not have
@@ -235,17 +239,64 @@
      <t>
        For the string representation of the "zid", we use the Crockford Base32
        encoding <xref target="CrockfordB32"/> but we decode the letter "U" to
-       the same Base32 value as the letter "V".
-       Assuming the encode function of <xref target="CrockfordB32"/> to be
-       "Base32Crockford, we define our function as "StringEncode" as follows:
+       the same Base32 value as the letter "V" in order to further increase
+       tolerance for failures in character recognition.
+       The encoding and decoding symbols for Crockford Base32 including this 
modification are defined in
+       Figure <xref target="CrockfordB32Encode"/>.
+       We assume that the functions for encoding and
+       decoding based on this table are called
+       "StringEncode(decodedString)" and
+       "StringDecode(encodedString)".
      </t>
-     <artwork name="" type="" align="left" alt=""><![CDATA[
-zkl := <StringEncode(zid)>
-    ]]></artwork>
+     <figure anchor="CrockfordB32Encode">
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+Symbol      Decode            Encode
+Value       Symbol            Symbol
+0           0 O o             0
+1           1 I i L l         1
+2           2                 2
+3           3                 3
+4           4                 4
+5           5                 5
+6           6                 6
+7           7                 7
+8           8                 8
+9           9                 9
+10          A a               A
+11          B b               B
+12          C c               C
+13          D d               D
+14          E e               E
+15          F f               F
+16          G g               G
+17          H h               H
+18          J j               J
+19          K k               K
+20          M m               M
+21          N n               N
+22          P p               P
+23          Q q               Q
+24          R r               R
+25          S s               S
+26          T t               T
+27          V v               V U
+28          W w               W
+29          X x               X
+30          Y y               Y
+31          Z z               Z
+         ]]></artwork>
+     </figure>
      <t>
-       Note that Crockfor Base32 is NOT compatible with the Base32 encoding
-       as defined in <xref target="RFC4648"/>.
+       The Base32-Crockford Alphabet Including the Additional U Encode Symbol.
      </t>
+     <t>
+       For the string representation of a "zid" we
+       define:
+     </t>
+     <artwork name="" type="" align="left" alt=""><![CDATA[
+zkl := StringEncode(zid)
+zid := StringDecode(zkl)
+    ]]></artwork>
    <t>
        If "zkl" is less than 63 characters, it is also the "zTLD".
        If the resulting "zkl" should be longer than 63 characters, the
@@ -486,19 +537,22 @@ 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. edwards25519)
          with the ECDSA scheme (<xref target="RFC6979" />).
-         Consequently , we use the following naming convention for our
+         Consequently, we use the following naming convention for our
          cryptographic primitives for PKEY zones:
        </t>
        <dl>
          <dt>d</dt>
          <dd>
-           is a 256-bit ECDSA private zone key.
+           is a 256-bit ECDSA private zone key. The generation as defined in
+           <xref target="RFC7748" /> represents the Private-KeyGen() function.
          </dd>
          <dt>zk</dt>
          <dd>
-           is the ECDSA public zone key corresponding to d. It is defined in
-           <xref target="RFC6979" /> as the curve point d*G where G is the 
group
-           generator of the elliptic curve. The public key is used to uniquely
+           is the ECDSA public zone key corresponding to d. Its generation is
+           defined in <xref target="RFC6979" /> as the curve point d*G where G
+           is the group generator of the elliptic curve.
+           This generation represents the Public-KeyGen(d) function.
+           The public key is used to uniquely
            identify a GNS zone and is referred to as the "zone key".
          </dd>
          <dt>p</dt>
@@ -660,7 +714,9 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          <dl>
            <dt>d</dt>
            <dd>
-             is a 256-bit EdDSA private zone key.
+             is a 256-bit EdDSA private zone key. The generation as defined
+             in <xref target="RFC7748" /> represents the Private-KeyGen()
+             function.
            </dd>
            <dt>a</dt>
            <dd>
@@ -673,6 +729,8 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
              <xref target="ed25519" /> as the curve point "a*G" where "G" is 
the
              group generator of the elliptic curve and "a" is an integer
              derived from "d" using the SHA512 hash function.
+             This generation including the derivation of "a" represents the
+             Public-KeyGen(d) function.
              The public key is used to uniquely identify a GNS zone and is
              referred to as the "zone key".
            </dd>
@@ -1237,13 +1295,15 @@ q := SHA512 (HDKD-Public(zk, label))
          </dd>
          <dt>PADDING</dt>
          <dd>
-           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.
+           When publishing an RDATA block, the implementation MUST ensure that
+           the size of the RDATA WITHOUT the RR COUNT field is a power of two
+           using the padding field. The field MUST be set to zero and MUST be
+           ignored on receipt.
            As a special exception, record sets with (only) a zone delegation
            record type are never padded.
            Note that a record set with a delegation record MUST NOT
-           contain other records.
+           contain other records. If other records are encountered, the whole
+           record block MUST be discarded.
          </dd>
        </dl>
      </section>
@@ -1362,8 +1422,11 @@ q := SHA512 (HDKD-Public(zk, label))
              Implementations MUST NOT allow multiple different zone type
              delegations under a single label.
              Implementations MAY support any subset of zone types.  If
-             an unsupported zone type is encountered, resolution fails
-             (NXDOMAIN).
+             an unsupported zone type is encountered, resolution fails and an
+             error MUST be returned. The information that the zone type is
+             unknown SHOULD be returned in the error description. The
+             implementation MAY choose not to return the reason for the 
failure,
+             merely impacting troubleshooting information for the user.
            </t>
            <t>
              If the remainder of the name to resolve is empty and we have
@@ -2399,7 +2462,6 @@ cae1789d
        &RFC3686;
        &RFC3826;
        &RFC3912;
-       &RFC4648;
        &RFC5869;
        &RFC5890;
        &RFC5891;
@@ -2487,6 +2549,7 @@ cae1789d
      </references>
      <references>
        <name>Informative References</name>
+       &RFC7363;
        <reference anchor="Tor224" 
target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135";>
          <front>
            <title>Next-Generation Hidden Services in Tor</title>
@@ -2500,6 +2563,28 @@ cae1789d
            <date year="2013" month="November"/>
          </front>
        </reference>
+       <reference anchor="Kademlia" 
target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf";>
+         <front>
+           <title>Kademlia: A peer-to-peer information system based on the xor 
metric.</title>
+          <author initials="P." surname="Maymounkov" fullname="Petar 
Maymounkov">
+          </author>
+
+          <author initials="D." surname="Mazieres"
+            fullname="David Mazieres">
+        </author>
+           <date year="2002"/>
+         </front>
+       </reference>
+       <reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561";>
+         <front>
+           <title>Ipfs-content addressed, versioned, p2p file system.</title>
+          <author initials="J." surname="Benet" fullname="Juan Benet">
+          </author>
+           <date year="2014"/>
+         </front>
+       </reference>
+
+
        <reference anchor="ed25519" 
target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9";>
          <front>
            <title>High-Speed High-Security Signatures</title>

-- 
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]