commit af4f1b3aa4615ec75d24133997b3c91e84633937
parent e2dd1d7536510b66568f73b444d9c5efd5e0ffef
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 5 Dec 2021 17:21:04 +0100
more ise
Diffstat:
1 file changed, 107 insertions(+), 22 deletions(-)
diff --git 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>
