[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: add nick
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: add nick |
|
Date: |
Sat, 05 Oct 2019 10:55:06 +0200 |
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 3ac6665 add nick
3ac6665 is described below
commit 3ac66657c0b978ef6b4f538a2cd3b9200ec65097
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sat Oct 5 10:52:54 2019 +0200
add nick
---
draft-schanzen-gns.html | 92 +++++++++++------
draft-schanzen-gns.txt | 266 +++++++++++++++++++++++++++++-------------------
draft-schanzen-gns.xml | 26 +++++
3 files changed, 250 insertions(+), 134 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index d8e173a..3a1ee65 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1090,7 +1090,10 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3"
class="xref">3.3</a>. <a href="#name-leho" class="xref">LEHO</a><a
href="#section-boilerplate.3-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.4">
- <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4"
class="xref">3.4</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4"
class="xref">3.4</a>. <a href="#name-nick" class="xref">NICK</a><a
href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.5">
+ <p id="section-boilerplate.3-1.3.2.5.1"><a href="#section-3.5"
class="xref">3.5</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -1451,12 +1454,43 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<span>[<a href="#RFC3492" class="xref">RFC3492</a>]</span>.<a
href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
-<div id="gnsrecords_box">
+<div id="gnsrecords_nick">
<section id="section-3.4">
+ <h3 id="name-nick">
+<a href="#section-3.4" class="section-number selfRef">3.4. </a><a
href="#name-nick" class="section-name selfRef">NICK</a>
+ </h3>
+<p id="section-3.4-1">Nickname records can be used by zone administrators to
publish an
+ indication on what label this zone prefers to be referred to.
+ This is a suggestion to other zones what label to use when creating a
+ PKEY <a href="#gnsrecords_pkey" class="xref">Section 3.1</a> record
containing this zone's
+ public zone key.
+ A NICK resource record contains an UTF-8 string
+ (which is not 0-terminated) representing the preferred label.
+ This string may NOT inlcude a ".".
+ A NICK DATA entry has the following format:<a href="#section-3.4-1"
class="pilcrow">¶</a></p>
+<div id="figure_nickrecord">
+<figure id="figure-6">
+ <div class="artwork art-text alignLeft" id="section-3.4-2.1">
+<pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | NICKNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
+</div>
+<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
+</div>
+</section>
+</div>
+<div id="gnsrecords_box">
+<section id="section-3.5">
<h3 id="name-box">
-<a href="#section-3.4" class="section-number selfRef">3.4. </a><a
href="#name-box" class="section-name selfRef">BOX</a>
+<a href="#section-3.5" class="section-number selfRef">3.5. </a><a
href="#name-box" class="section-name selfRef">BOX</a>
</h3>
-<p id="section-3.4-1">
+<p id="section-3.5-1">
In GNS, every "." in a name delegates to another zone, and
GNS lookups are expected to return all of the required useful
information in one record set. This is incompatible with the
@@ -1471,10 +1505,10 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
otherwise it is to be left untouched. This way, TLSA (and SRV)
records do not require a separate network request, and TLSA
records become inseparable from the corresponding address records.
- A BOX DATA entry has the following format:<a href="#section-3.4-1"
class="pilcrow">¶</a></p>
+ A BOX DATA entry has the following format:<a href="#section-3.5-1"
class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
-<figure id="figure-6">
- <div class="artwork art-text alignLeft" id="section-3.4-2.1">
+<figure id="figure-7">
+ <div class="artwork art-text alignLeft" id="section-3.5-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1487,26 +1521,26 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
+<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
</div>
-<dl class="dlParallel" id="section-3.4-3">
- <dt id="section-3.4-3.1">PROTO</dt>
- <dd id="section-3.4-3.2">
- the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.<a href="#section-3.4-3.2" class="pilcrow">¶</a>
+<dl class="dlParallel" id="section-3.5-3">
+ <dt id="section-3.5-3.1">PROTO</dt>
+ <dd id="section-3.5-3.2">
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.<a href="#section-3.5-3.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.4-3.3">SVC</dt>
- <dd id="section-3.4-3.4">
+ <dt id="section-3.5-3.3">SVC</dt>
+ <dd id="section-3.5-3.4">
the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.<a href="#section-3.4-3.4"
class="pilcrow">¶</a>
+ In network byte order.<a href="#section-3.5-3.4"
class="pilcrow">¶</a>
</dd>
- <dt id="section-3.4-3.5">TYPE</dt>
- <dd id="section-3.4-3.6">
- is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.4-3.6" class="pilcrow">¶</a>
+ <dt id="section-3.5-3.5">TYPE</dt>
+ <dd id="section-3.5-3.6">
+ is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.5-3.6" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.4-3.7">RECORD DATA</dt>
- <dd id="section-3.4-3.8">
+ <dt id="section-3.5-3.7">RECORD DATA</dt>
+ <dd id="section-3.5-3.8">
is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.<a href="#section-3.4-3.8"
class="pilcrow">¶</a>
+ defined for the respective TYPE in DNS.<a href="#section-3.5-3.8"
class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1606,7 +1640,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
include a periodic refresh publication.
A GNS resource records block has the following format:<a
href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
-<figure id="figure-7">
+<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1635,7 +1669,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
+<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
</div>
<p id="section-4.2-3">where:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.2-4">
@@ -1698,7 +1732,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
set RDATA into the BDATA field of a GNS record block.
The wire format of the RDATA looks as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
<div id="figure_rdata">
-<figure id="figure-8">
+<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.3-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1726,7 +1760,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
/ /
</pre>
</div>
-<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
+<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
</div>
<p id="section-4.3-3">where:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.3-4">
@@ -1785,7 +1819,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
and a 256-bit TWOFISH <span>[<a href="#TWOFISH"
class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-8"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
-<figure id="figure-9">
+<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.3-9.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1802,13 +1836,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
+<figcaption><a href="#figure-10" class="selfRef">Figure
10</a></figcaption></figure>
</div>
<p id="section-4.3-10">
Similarly, we divide "IV" into a 128-bit initialization vector
and a 128-bit initialization vector:<a href="#section-4.3-10"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
-<figure id="figure-10">
+<figure id="figure-11">
<div class="artwork art-text alignLeft" id="section-4.3-11.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1821,7 +1855,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-10" class="selfRef">Figure
10</a></figcaption></figure>
+<figcaption><a href="#figure-11" class="selfRef">Figure
11</a></figcaption></figure>
</div>
<p id="section-4.3-12">
The keys and IVs are used for a CFB128-AES-256 and
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index b44d435..dbfbae6 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -66,19 +66,20 @@ Table of Contents
3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.4. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.5. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Publishing records . . . . . . . . . . . . . . . . . . . . . 8
4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 8
4.2. Resource records block . . . . . . . . . . . . . . . . . 9
- 4.3. Block data encryption and decryption . . . . . . . . . . 10
+ 4.3. Block data encryption and decryption . . . . . . . . . . 11
5. Internationalization and Character Encoding . . . . . . . . . 13
6. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 13
- 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 13
- 6.2. Recursive Resolution . . . . . . . . . . . . . . . . . . 13
- 7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 13
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6.2. Recursive Resolution . . . . . . . . . . . . . . . . . . 14
+ 7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 14
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
@@ -104,8 +105,7 @@ Table of Contents
some respects as even as an alternative to some of today's Public Key
Infrastructures, in particular X.509 for the Web.
- This document contains the GNU Name System (GNS) technical
- specification of the GNU Name System (GNS), a fully decentralized and
+
@@ -114,6 +114,8 @@ Schanzenbach, et al. Expires 24 January 2020
[Page 2]
Internet-Draft The GNU Name System July 2019
+ This document contains the GNU Name System (GNS) technical
+ specification of the GNU Name System (GNS), a fully decentralized and
censorship-resistant name system. GNS provides a privacy-enhancing
alternative to the Domain Name System (DNS). The design of GNS
incorporates the capability to integrate and coexist with DNS. GNS
@@ -163,8 +165,6 @@ Internet-Draft The GNU Name System
July 2019
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 3]
Internet-Draft The GNU Name System July 2019
@@ -352,7 +352,27 @@ Internet-Draft The GNU Name System
July 2019
(e.g. "Host:" header) it must be converted to a punycode
representation [RFC3492].
-3.4. BOX
+3.4. NICK
+
+ Nickname records can be used by zone administrators to publish an
+ indication on what label this zone prefers to be referred to. This
+ is a suggestion to other zones what label to use when creating a PKEY
+ Section 3.1 record containing this zone's public zone key. A NICK
+ resource record contains an UTF-8 string (which is not 0-terminated)
+ representing the preferred label. This string may NOT inlcude a ".".
+ A NICK DATA entry has the following format:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | NICKNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 6
+
+3.5. BOX
In GNS, every "." in a name delegates to another zone, and GNS
lookups are expected to return all of the required useful information
@@ -366,6 +386,14 @@ Internet-Draft The GNU Name System
July 2019
received, a GNS resolver must unbox it if the name to be resolved
continues with "_SERVICE._PROTO", otherwise it is to be left
untouched. This way, TLSA (and SRV) records do not require a
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
+
separate network request, and TLSA records become inseparable from
the corresponding address records. A BOX DATA entry has the
following format:
@@ -380,20 +408,11 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 6
+ Figure 7
PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
-
SVC the 16-bit service value of the boxed record, i.e. the port
number. In network byte order.
@@ -422,6 +441,15 @@ Internet-Draft The GNU Name System
July 2019
q := SHA512 (zk_h)
We use a hash-based key derivation function (HKDF) as defined in
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
SHA256 for the expansion phase.
@@ -443,13 +471,6 @@ Internet-Draft The GNU Name System
July 2019
zk_h is a 256-bit public key derived from the zone key "zk" using
the keying material "h".
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
L is the prime-order subgroup as defined in Section 2.
q Is the 512-bit DHT key under which the resource records block is
@@ -470,6 +491,21 @@ Internet-Draft The GNU Name System
July 2019
refresh publication. A GNS resource records block has the following
format:
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
@@ -495,17 +531,10 @@ Internet-Draft The GNU Name System
July 2019
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 7
+ Figure 8
where:
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
-
-Internet-Draft The GNU Name System July 2019
-
-
SIGNATURE A 512-bit ECDSA deterministic signature compliant with
[RFC6979]. The signature is computed over the data following the
PUBLIC KEY field. The signature is created using the derived
@@ -526,6 +555,13 @@ Internet-Draft The GNU Name System
July 2019
PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
network byte order).
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+
+Internet-Draft The GNU Name System July 2019
+
+
EXPIRATION Specifies when the resource records block expires and the
encrypted block SHOULD be removed from the DHT and caches as it is
likely stale. However, applications MAY continue to use non-
@@ -546,22 +582,6 @@ Internet-Draft The GNU Name System
July 2019
set RDATA into the BDATA field of a GNS record block. The wire
format of the RDATA looks as follows:
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
-
-Internet-Draft The GNU Name System July 2019
-
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| RR COUNT | EXPIRA- /
@@ -586,10 +606,18 @@ Internet-Draft The GNU Name System
July 2019
/ PADDING /
/ /
- Figure 8
+ Figure 9
where:
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+
+Internet-Draft The GNU Name System July 2019
+
+
RR COUNT A 32-bit value containing the number of variable-length
resource records which are following after this field in network
byte order.
@@ -609,15 +637,6 @@ Internet-Draft The GNU Name System
July 2019
then use "zk_h" to compute "q" which is the query for the DHT. Upon
receiving a block from the DHT, the receiver first checks that the
PUBLIC KEY field matches "zk_h". Then, the client MUST verify the
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
-
-Internet-Draft The GNU Name System July 2019
-
-
signature. These steps are mandatory to prevent record spoofing and
MUST be performed before decryption.
@@ -639,6 +658,22 @@ Internet-Draft The GNU Name System
July 2019
"K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH]
key:
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| AES KEY |
@@ -652,7 +687,7 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 9
+ Figure 10
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
@@ -666,15 +701,7 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
-
- Figure 10
+ Figure 11
The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256
chained symmetric cipher. Both ciphers are used in Cipher FeedBack
@@ -694,6 +721,15 @@ Internet-Draft The GNU Name System
July 2019
TODO
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+
+Internet-Draft The GNU Name System July 2019
+
+
6.1. Entry Zone
There are three sources from which the entry zone can be determined:
@@ -723,13 +759,6 @@ Internet-Draft The GNU Name System
July 2019
The following represents a test vector for a record of type MX with a
priority of 10 and the mail hostname mail.example.com.
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
label := "mail"
d :=
@@ -749,6 +778,14 @@ Internet-Draft The GNU Name System
July 2019
f2dbf7930be76fb9
5e7c80b1416f8ca6
dc50ce8e1fb759b9
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+
+Internet-Draft The GNU Name System July 2019
+
+
fedcdcf546c17e9b
4c4f23632855c053
6668e9f684f4dc33
@@ -778,14 +815,6 @@ Internet-Draft The GNU Name System
July 2019
AES_IV :=
a808b929bc9fad7a
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
686bbe3432bed77a
TWOFISH_KEY :=
@@ -805,6 +834,14 @@ Internet-Draft The GNU Name System
July 2019
000a046d61696c07 Priority (10) |4 | mail | 7
6578616d706c6503 example | 3
636f6d0000000000 com | \0 | Followed by
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+
+Internet-Draft The GNU Name System July 2019
+
+
0000000000000000 24 bytes of padding to 2^6
0000000000000000
00000000
@@ -835,13 +872,6 @@ Internet-Draft The GNU Name System
July 2019
001fd19a6406a721
713f0a0d
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
11. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
@@ -861,6 +891,13 @@ Internet-Draft The GNU Name System
July 2019
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+Internet-Draft The GNU Name System July 2019
+
+
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826,
@@ -890,14 +927,6 @@ Internet-Draft The GNU Name System
July 2019
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
-
-
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
@@ -917,6 +946,14 @@ Authors' Addresses
Email: address@hidden
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
+
+Internet-Draft The GNU Name System July 2019
+
+
Christian Grothoff
Berner Fachhochschule
Hoeheweg 80
@@ -949,4 +986,23 @@ Authors' Addresses
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 18]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index edf77f6..ce74c57 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -345,6 +345,32 @@
<xref target="RFC3492" />.
</t>
</section>
+ <section anchor="gnsrecords_nick" numbered="true" toc="default">
+ <name>NICK</name>
+ <t>Nickname records can be used by zone administrators to publish an
+ indication on what label this zone prefers to be referred to.
+ This is a suggestion to other zones what label to use when creating a
+ PKEY <xref target="gnsrecords_pkey" /> record containing this zone's
+ public zone key.
+ A NICK resource record contains an UTF-8 string
+ (which is not 0-terminated) representing the preferred label.
+ This string may NOT inlcude a ".".
+ A NICK DATA entry has the following format:
+ </t>
+ <figure anchor="figure_nickrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | NICKNAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ </section>
+
<section anchor="gnsrecords_box" numbered="true" toc="default">
<name>BOX</name>
<t>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [lsd0001] branch master updated: add nick,
gnunet <=