[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: update
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: update |
|
Date: |
Thu, 26 Sep 2019 20:41:58 +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 519c0bd update
519c0bd is described below
commit 519c0bd45bd15609d0b6163f270977806eced2d2
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Thu Sep 26 20:39:54 2019 +0200
update
---
draft-schanzen-gns.html | 556 +++++++++++++++++-------------
draft-schanzen-gns.txt | 398 ++++++++++++----------
draft-schanzen-gns.xml | 872 ++++++++++++++++++++++++++----------------------
3 files changed, 1017 insertions(+), 809 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 7b55b46..76076d1 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1081,10 +1081,16 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-boilerplate.3-1.3.1"><a href="#section-3"
class="xref">3</a>. <a href="#name-resource-records" class="xref">Resource
records</a><a href="#section-boilerplate.3-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.1">
- <p id="section-boilerplate.3-1.3.2.1.1"><a href="#section-3.1"
class="xref">3.1</a>. <a href="#name-flags" class="xref">Flags</a><a
href="#section-boilerplate.3-1.3.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.1.1"><a href="#section-3.1"
class="xref">3.1</a>. <a href="#name-wire-format" class="xref">Wire
format</a><a href="#section-boilerplate.3-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.2">
- <p id="section-boilerplate.3-1.3.2.2.1"><a href="#section-3.2"
class="xref">3.2</a>. <a href="#name-gns-resource-record-types"
class="xref">GNS resource record types</a><a
href="#section-boilerplate.3-1.3.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.2.1"><a href="#section-3.2"
class="xref">3.2</a>. <a href="#name-pkey" class="xref">PKEY</a><a
href="#section-boilerplate.3-1.3.2.2.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.3">
+ <p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3"
class="xref">3.3</a>. <a href="#name-gns2dns" class="xref">GNS2DNS</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-leho" class="xref">LEHO</a><a
href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -1147,12 +1153,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-2" class="section-number selfRef">2. </a><a
href="#name-zones" class="section-name selfRef">Zones</a>
</h2>
<p id="section-2-1">
- A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ A zone in GNS is defined by a public/private ECC key pair (x,zk),
where P is the generator of an elliptic curve, x is the private key and
- x*P the corresponding public key.
+ zk := x*P the corresponding public key.
The keys are constructed using the Ed25519 ECC scheme as defined in
<span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.
- The public key "x*P" is used to uniquely identify and refer to the zone.
+ The public key "zk" is used to uniquely identify and refer to the zone and
+ is thus called "zone key".
Records published in the zone are signed using a private key derived
from the private key "x" as described in <a href="#publish"
class="xref">Section 4</a>.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
@@ -1162,12 +1169,17 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<h2 id="name-resource-records">
<a href="#section-3" class="section-number selfRef">3. </a><a
href="#name-resource-records" class="section-name selfRef">Resource records</a>
</h2>
-<p id="section-3-1">
+<div id="rrecords_wire">
+<section id="section-3.1">
+ <h3 id="name-wire-format">
+<a href="#section-3.1" class="section-number selfRef">3.1. </a><a
href="#name-wire-format" class="section-name selfRef">Wire format</a>
+ </h3>
+<p id="section-3.1-1">
A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:<a href="#section-3-1"
class="pilcrow">¶</a></p>
+ The resource record format is defined as follows:<a href="#section-3.1-1"
class="pilcrow">¶</a></p>
<div id="figure_gnsrecord">
<figure id="figure-1">
- <div class="artwork art-text alignLeft" id="section-3-2.1">
+ <div class="artwork art-text alignLeft" id="section-3.1-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1185,83 +1197,82 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure
1</a></figcaption></figure>
</div>
-<p id="section-3-3">where:<a href="#section-3-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3-4">
- <dt id="section-3-4.1">EXPIRATION</dt>
- <dd id="section-3-4.2">
+<p id="section-3.1-3">where:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-3.1-4">
+ <dt id="section-3.1-4.1">EXPIRATION</dt>
+ <dd id="section-3.1-4.2">
Denotes the absolute expiration date of the record.
In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-3-4.2" class="pilcrow">¶</a>
+ byte order.<a href="#section-3.1-4.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-3-4.3">DATA SIZE</dt>
- <dd id="section-3-4.4">
- The size of the DATA field in bytes and in network byte order.<a
href="#section-3-4.4" class="pilcrow">¶</a>
+ <dt id="section-3.1-4.3">DATA SIZE</dt>
+ <dd id="section-3.1-4.4">
+ The size of the DATA field in bytes and in network byte order.<a
href="#section-3.1-4.4" class="pilcrow">¶</a>
</dd>
- <dt id="section-3-4.5">TYPE</dt>
- <dd id="section-3-4.6">
+ <dt id="section-3.1-4.5">TYPE</dt>
+ <dd id="section-3.1-4.6">
The resource record type. This type can be one of the GNS resource
- records as defined in <a href="#gnsrecords" class="xref">Section 3.2</a>
or a DNS record
+ records as defined in <a href="#rrecords" class="xref">Section 3</a> or a
DNS record
type as defined in <span>[<a href="#RFC1035"
class="xref">RFC1035</a>]</span> or any of the
- complementary standardized DNS resource record types.<a
href="#section-3-4.6" class="pilcrow">¶</a>
+ complementary standardized DNS resource record types. This value must be
+ stored in network byte order. Note that values
+ below 2^16 are reserved for allocation via IANA and link to the DNS
+ record type registry.<a href="#section-3.1-4.6" class="pilcrow">¶</a>
</dd>
- <dt id="section-3-4.7">FLAGS</dt>
- <dd id="section-3-4.8">
- Resource record flags. Flags are defined in <a href="#flags"
class="xref">Section 3.1</a>.<a href="#section-3-4.8" class="pilcrow">¶</a>
+ <dt id="section-3.1-4.7">FLAGS</dt>
+ <dd id="section-3.1-4.8">
+ Resource record flags.<a href="#section-3.1-4.8" class="pilcrow">¶</a>
</dd>
- <dt id="section-3-4.9">DATA</dt>
- <dd id="section-3-4.10">
+ <dt id="section-3.1-4.9">DATA</dt>
+ <dd id="section-3.1-4.10">
The resource record data payload. The contents are defined by the
- respective type of the resource record.<a href="#section-3-4.10"
class="pilcrow">¶</a>
+ respective type of the resource record.<a href="#section-3.1-4.10"
class="pilcrow">¶</a>
</dd>
- </dl>
-<div id="flags">
-<section id="section-3.1">
- <h3 id="name-flags">
-<a href="#section-3.1" class="section-number selfRef">3.1. </a><a
href="#name-flags" class="section-name selfRef">Flags</a>
- </h3>
-<p id="section-3.1-1">
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+ </dl>
+<p id="section-3.1-5">
+ Flags indicate metadata surrounding the resource record. A flag
+ value of 0 indicates that all flags are unset. The following
+ illustrates the flag distribution in the 32-bit flag value of a
+ resource record:<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<div id="figure_flag">
<figure id="figure-2">
- <div class="artwork art-text alignLeft" id="section-3.1-2.1">
+ <div class="artwork art-text alignLeft" id="section-3.1-6.1">
<pre>
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
- </pre>
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
+ </pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure
2</a></figcaption></figure>
</div>
-<p id="section-3.1-3">
- where:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.1-4">
- <dt id="section-3.1-4.1">SHADOW</dt>
- <dd id="section-3.1-4.2">
- If this flag is set, this record should not be used unless all (other)
- records with an absolute expiration time have expired.<a
href="#section-3.1-4.2" class="pilcrow">¶</a>
+<p id="section-3.1-7">
+ where:<a href="#section-3.1-7" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-3.1-8">
+ <dt id="section-3.1-8.1">SHADOW</dt>
+ <dd id="section-3.1-8.2">
+ If this flag is set, this record should not be used unless all (other)
+ records with an absolute expiration time have expired.<a
href="#section-3.1-8.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-4.3">EXPREL</dt>
- <dd id="section-3.1-4.4">
- The expiration time value of the record is a relative time and not
- an absolute time. This flag can be ignored by a resolver.<a
href="#section-3.1-4.4" class="pilcrow">¶</a>
+ <dt id="section-3.1-8.3">EXPREL</dt>
+ <dd id="section-3.1-8.4">
+ The expiration time value of the record is a relative time and not
+ an absolute time. This flag should never be encountered by a resolver
+ for records resolved from the DHT.<a href="#section-3.1-8.4"
class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-4.5">PRIVATE</dt>
- <dd id="section-3.1-4.6">
- This is a private record of this peer and it should thus not be
- handed out to other peers. This flag should never be encountered by
- a resolver.<a href="#section-3.1-4.6" class="pilcrow">¶</a>
+ <dt id="section-3.1-8.5">PRIVATE</dt>
+ <dd id="section-3.1-8.6">
+ This is a private record of this peer and it should thus not be
+ handed out to other peers. This flag should never be encountered by
+ a resolver for records resolved from the DHT.<a href="#section-3.1-8.6"
class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
-<div id="gnsrecords">
+<div id="gnsrecords_pkey">
<section id="section-3.2">
- <h3 id="name-gns-resource-record-types">
-<a href="#section-3.2" class="section-number selfRef">3.2. </a><a
href="#name-gns-resource-record-types" class="section-name selfRef">GNS
resource record types</a>
+ <h3 id="name-pkey">
+<a href="#section-3.2" class="section-number selfRef">3.2. </a><a
href="#name-pkey" class="section-name selfRef">PKEY</a>
</h3>
<p id="section-3.2-1">The a PKEY DATA entry has the following format:<a
href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_pkeyrecord">
@@ -1281,6 +1292,52 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</div>
</section>
</div>
+<div id="gnsrecords_gns2dns">
+<section id="section-3.3">
+ <h3 id="name-gns2dns">
+<a href="#section-3.3" class="section-number selfRef">3.3. </a><a
href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
+ </h3>
+<p id="section-3.3-1">The a GNS2DNS DATA entry has the following format:<a
href="#section-3.3-1" class="pilcrow">¶</a></p>
+<div id="figure_gns2dnsrecord">
+<figure id="figure-4">
+ <div class="artwork art-text alignLeft" id="section-3.3-2.1">
+<pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
+</div>
+<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
+</div>
+</section>
+</div>
+<div id="gnsrecords_leho">
+<section id="section-3.4">
+ <h3 id="name-leho">
+<a href="#section-3.4" class="section-number selfRef">3.4. </a><a
href="#name-leho" class="section-name selfRef">LEHO</a>
+ </h3>
+<p id="section-3.4-1">The a LEHO DATA entry has the following format:<a
href="#section-3.4-1" class="pilcrow">¶</a></p>
+<div id="figure_lehorecord">
+<figure id="figure-5">
+ <div class="artwork art-text alignLeft" id="section-3.4-2.1">
+<pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | LEGACY HOSTNAME |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
+</div>
+<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
+</div>
+</section>
+</div>
</section>
</div>
<div id="publish">
@@ -1289,12 +1346,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-4" class="section-number selfRef">4. </a><a
href="#name-publishing-records" class="section-name selfRef">Publishing
records</a>
</h2>
<p id="section-4-1">
- GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels and published
- together in a single block in the DHT.
- A resource records block is published under a key which is derived from
- the zone key and the respective label of the contained records.
- Given a label, the DHT key "q" is derived as follows:<a
href="#section-4-1" class="pilcrow">¶</a></p>
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels and published
+ together in a single block in the DHT.
+ A resource records block is published under a key which is derived from
+ the zone key "zk" and the respective label of the contained records.
+ Given a label, the DHT key "q" is derived as follows:<a
href="#section-4-1" class="pilcrow">¶</a></p>
<div id="blinding">
<section id="section-4.1">
<h3 id="name-key-derivations">
@@ -1302,48 +1359,59 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h3>
<div class="artwork art-text alignLeft" id="section-4.1-1">
<pre>
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d := h*x mod p
- q := SHA512 (d*P)
- </pre><a href="#section-4.1-1" class="pilcrow">¶</a>
+ PRK_h := HKDF-Extract ("key-derivation", zk)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ x_h := h*x mod p
+ zk_h := h*zk mod p
+ q := SHA512 (zk_h)
+ </pre><a href="#section-4.1-1" class="pilcrow">¶</a>
</div>
<p id="section-4.1-2">
- We use a hash-based key derivation function (HKDF) as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.<a href="#section-4.1-2"
class="pilcrow">¶</a></p>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.<a href="#section-4.1-2"
class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.1-3">
- <dt id="section-4.1-3.1">h</dt>
+ <dt id="section-4.1-3.1">PRK_h</dt>
<dd id="section-4.1-3.2">
- is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public zone key "x*P" as initial keying
- material. The label and string "gns" are concatenated and used in the
- HKDF expansion phase.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key "x*P" as initial
keying
+ material.<a href="#section-4.1-3.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-3.3">x</dt>
+ <dt id="section-4.1-3.3">h</dt>
<dd id="section-4.1-3.4">
- is the private zone key as defined in <span>[<a href="#RFC8032"
class="xref">RFC8032</a>]</span>.<a href="#section-4.1-3.4"
class="pilcrow">¶</a>
+ is the HKDF expansion result. The expansion info is a concatenation
of
+ the label and string "gns".<a href="#section-4.1-3.4"
class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-3.5">P</dt>
+ <dt id="section-4.1-3.5">x</dt>
<dd id="section-4.1-3.6">
- is the base point of the curve Ed25519 as defined in
- <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a
href="#section-4.1-3.6" class="pilcrow">¶</a>
+ is the private zone key as defined in <span>[<a href="#RFC8032"
class="xref">RFC8032</a>]</span>.<a href="#section-4.1-3.6"
class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-3.7">label</dt>
+ <dt id="section-4.1-3.7">P</dt>
<dd id="section-4.1-3.8">
- under wich the resource records are published.<a href="#section-4.1-3.8"
class="pilcrow">¶</a>
+ is the base point of the curve Ed25519 as defined in
+ <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a
href="#section-4.1-3.8" class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-3.9">d</dt>
+ <dt id="section-4.1-3.9">label</dt>
<dd id="section-4.1-3.10">
- is a private key derived from the zone key "x" using the keying
- material "h" (512 bit) and "p" is the group order as defined in
- <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a
href="#section-4.1-3.10" class="pilcrow">¶</a>
+ under wich the resource records are published.<a
href="#section-4.1-3.10" class="pilcrow">¶</a>
</dd>
- <dt id="section-4.1-3.11">q</dt>
+ <dt id="section-4.1-3.11">x_h</dt>
<dd id="section-4.1-3.12">
- Is the DHT key under which the resource records block is published.
- It is the SHA512 hash over the public key "d*P" corresponding to the
- derived private key "d".<a href="#section-4.1-3.12" class="pilcrow">¶</a>
+ is a private key derived from the zone private key "x" using the
+ keying material "h" (512 bit) and "p" is the group order as defined
in
+ <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a
href="#section-4.1-3.12" class="pilcrow">¶</a>
+</dd>
+ <dt id="section-4.1-3.13">zk_h</dt>
+ <dd id="section-4.1-3.14">
+ is a public key derived from the zone key "zk" using the keying
+ material "h" (512 bit) and "p" is the group order as defined in
+ <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.<a
href="#section-4.1-3.14" class="pilcrow">¶</a>
+</dd>
+ <dt id="section-4.1-3.15">q</dt>
+ <dd id="section-4.1-3.16">
+ Is the DHT key under which the resource records block is published.
+ It is the SHA512 hash over the public key "zk_h" corresponding to the
+ derived private key "x_h".<a href="#section-4.1-3.16"
class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1354,80 +1422,101 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a
href="#name-resource-records-block" class="section-name selfRef">Resource
records block</a>
</h3>
<p id="section-4.2-1">
- GNS records are grouped by their labels and published as a single
- block in the DHT.
- The contained resource records are encrypted using a symmetric
- encryption scheme.
- A GNS resource records block has the following format:<a
href="#section-4.2-1" class="pilcrow">¶</a></p>
+ GNS records are grouped by their labels and published as a single
+ block in the DHT.
+ The contained resource records are encrypted using a symmetric
+ encryption scheme.
+ 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-4">
+<figure id="figure-6">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
+<figcaption><a href="#figure-6" class="selfRef">Figure
6</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">
<dt id="section-4.2-4.1">SIGNATURE</dt>
<dd id="section-4.2-4.2">
- A 512-bit ECDSA deterministic signature compliant with
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The
signature is computed over the data
- following the PUBLIC KEY field.
- The signature is created using the derived private key "d" (see
- <a href="#publish" class="xref">Section 4</a>).<a
href="#section-4.2-4.2" class="pilcrow">¶</a>
+ A 512-bit ECDSA deterministic signature compliant with
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The
signature is computed over the data
+ following the PUBLIC KEY field.
+ The signature is created using the derived private key "x_h" (see
+ <a href="#publish" class="xref">Section 4</a>).<a
href="#section-4.2-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.3">PUBLIC KEY</dt>
<dd id="section-4.2-4.4">
- The 256-bit ECC public key "d*P" to be used to verify SIGNATURE.<a
href="#section-4.2-4.4" class="pilcrow">¶</a>
+ The 256-bit ECC public key "zk_h" to be used to verify SIGNATURE. The
+ wire format of this value is defined in <span>[<a href="#RFC8032"
class="xref">RFC8032</a>]</span>,
+ Section 5.1.5.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.5">BDATA SIZE</dt>
<dd id="section-4.2-4.6">
- A 32-bit value containing the length of the following data (PURPOSE,
- EXPIRATION, BDATA) in network byte order.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
+ A 32-bit value containing the length of the following data (PURPOSE,
+ EXPIRATION, BDATA) in network byte order.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.7">PURPOSE</dt>
<dd id="section-4.2-4.8">
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
+ A 32-bit signature purpose flag. This field MUST be 15 (in network
+ byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.9">EXPIRATION</dt>
<dd id="section-4.2-4.10">
- The resource records block expiration time. This is the expiration
- time of the resource record contained within this block with the
- smallest expiration time.
- This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.<a
href="#section-4.2-4.10" class="pilcrow">¶</a>
+ The resource records block expiration time. This is the expiration
+ time of the resource record contained within this block with the
+ smallest expiration time.
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 in network byte order.<a
href="#section-4.2-4.10" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.11">BDATA</dt>
<dd id="section-4.2-4.12">
- The encrypted resource records with a total size of "BDATA SIZE".<a
href="#section-4.2-4.12" class="pilcrow">¶</a>
+ The encrypted resource records with a total size of "BDATA SIZE".<a
href="#section-4.2-4.12" class="pilcrow">¶</a>
</dd>
</dl>
+<p id="section-4.2-5">
+ As per <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>, an
ECDSA signature consists of a pair
+ of integers, r and s:<a href="#section-4.2-5" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-4.2-6">
+<pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | r |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | s |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre><a href="#section-4.2-6" class="pilcrow">¶</a>
+</div>
</section>
</div>
<section id="section-4.3">
@@ -1435,122 +1524,119 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a
href="#name-block-data-encryption-and-d" class="section-name selfRef">Block
data encryption and decryption</a>
</h3>
<p id="section-4.3-1">
- A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
- in a GNS record block. The keys are derived from the record label
- and the public key "d*P". The secret scalar "d" is derived from "h"
- and private key "x" of a GNS zone.
- Both label and public key and "x*P" are implicity known by a GNS
- resolver while "d*P" is provided within the resource records block.
- The validity of "d" can be checked by computing "h" from "x*P" and
- label and verifying that "d*P = h*x*P". This step is mandatory to
- prevent spoofed records to be verified and decrypted correctly.
- The keying material "K" and initialization vector "IV" for the
- symmetric encryption/decryption are derived as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
+ A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
+ in a GNS record block. The keys are derived from the record label
+ and the zone key "zk".
+ The validity of "d" can be checked by computing "h" from "x_h" and
+ label and verifying that "zk_h = h*zk". This step is mandatory to
+ prevent spoofed records to be verified and decrypted correctly.
+ The keying material "K" and initialization vector "IV" for the
+ symmetric encryption/decryption are derived as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-2">
<pre>
- PRK_kiv := HKDF-Extract (d*P, label)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
- </pre><a href="#section-4.3-2" class="pilcrow">¶</a>
+ PRK_kiv := HKDF-Extract (zk, label)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ </pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
<p id="section-4.3-3">
- We use a hash-based key derivation function (HKDF) as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.
- The output keying material is 64 octets (512 bit) for the symmetric
- keys and 32 octets (256 bit) for the initialization vector.
- We divide the resulting keying material "K" into a 256-bit AES key
- "Kaes" and a 256-bit TWOFISH key "Ktwo":<a href="#section-4.3-3"
class="pilcrow">¶</a></p>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vector.
+ We divide the resulting keying material "K" into a 256-bit AES key
+ "Kaes" and a 256-bit TWOFISH key "Ktwo":<a href="#section-4.3-3"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
-<figure id="figure-5">
+<figure id="figure-7">
<div class="artwork art-text alignLeft" id="section-4.3-4.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
+<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
</div>
<p id="section-4.3-5">
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:<a href="#section-4.3-5"
class="pilcrow">¶</a></p>
+ Similarly, we divide "IV" into a 128-bit initialization vector IVaes
+ and a 128-bit initialization vector IVtwo:<a href="#section-4.3-5"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
-<figure id="figure-6">
+<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-4.3-6.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
+<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
</div>
<p id="section-4.3-7">
- The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.<a
href="#section-4.3-7" class="pilcrow">¶</a></p>
+ The symmetric keys and IVs are used for a AES+TWOFISH combined
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.<a
href="#section-4.3-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-8">
<pre>
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
- </pre><a href="#section-4.3-8" class="pilcrow">¶</a>
+ RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
+ BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ </pre><a href="#section-4.3-8" class="pilcrow">¶</a>
</div>
<p id="section-4.3-9">
- The decrypted RDATA has the following format:<a href="#section-4.3-9"
class="pilcrow">¶</a></p>
+ The decrypted RDATA has the following format:<a href="#section-4.3-9"
class="pilcrow">¶</a></p>
<div id="figure_rdata">
-<figure id="figure-7">
+<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.3-10.1">
<pre>
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
- / /
- </pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / /
+ </pre>
</div>
-<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
+<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
</div>
<p id="section-4.3-11">where:<a href="#section-4.3-11"
class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.3-12">
<dt id="section-4.3-12.1">RR COUNT</dt>
<dd id="section-4.3-12.2">
- A 32-bit value containing the number of resource records which are
- following in network byte order.<a href="#section-4.3-12.2"
class="pilcrow">¶</a>
+ A 32-bit value containing the number of resource records which are
+ following in network byte order.<a href="#section-4.3-12.2"
class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-4.3-13">
- is followed by a set of resource records with the respective
- formats defined in <a href="#rrecords" class="xref">Section 3</a>.<a
href="#section-4.3-13" class="pilcrow">¶</a></p>
+ is followed by a set of resource records with the respective
+ formats defined in <a href="#rrecords" class="xref">Section 3</a>.<a
href="#section-4.3-13" class="pilcrow">¶</a></p>
</section>
</section>
</div>
@@ -1560,7 +1646,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-5" class="section-number selfRef">5. </a><a
href="#name-internationalization-and-ch" class="section-name
selfRef">Internationalization and Character Encoding</a>
</h2>
<p id="section-5-1">
- TODO<a href="#section-5-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
@@ -1569,7 +1655,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-6" class="section-number selfRef">6. </a><a
href="#name-security-considerations" class="section-name selfRef">Security
Considerations</a>
</h2>
<p id="section-6-1">
- TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="resolution">
@@ -1578,7 +1664,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-7" class="section-number selfRef">7. </a><a
href="#name-record-resolution" class="section-name selfRef">Record
Resolution</a>
</h2>
<p id="section-7-1">
- TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="revocation">
@@ -1587,7 +1673,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-8" class="section-number selfRef">8. </a><a
href="#name-namespace-revocation" class="section-name selfRef">Namespace
Revocation</a>
</h2>
<p id="section-8-1">
- TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
@@ -1596,7 +1682,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-9" class="section-number selfRef">9. </a><a
href="#name-iana-considerations" class="section-name selfRef">IANA
Considerations</a>
</h2>
<p id="section-9-1">
- This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
+ This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
@@ -1610,12 +1696,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dt id="RFC5869">[RFC5869]</dt>
<dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P.
Eronen</span>, <span class="refTitle">"
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
"</span>, <span class="seriesInfo">RFC 5869</span>, <span
class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May
2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5869";>https://www.rfc-editor.org/info/rfc5869</a>></span>.
</dd>
<dt id="RFC6979">[RFC6979]</dt>
<dd>
<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"
- Deterministic Usage of the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA)
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA)
"</span>, <span class="seriesInfo">RFC 6979</span>, <span
class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08">August
2013</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc6979";>https://www.rfc-editor.org/info/rfc6979</a>></span>.
</dd>
<dt id="RFC8032">[RFC8032]</dt>
<dd>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 0bf8079..0bc791d 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -63,19 +63,21 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Resource records . . . . . . . . . . . . . . . . . . . . . . 2
- 3.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.2. GNS resource record types . . . . . . . . . . . . . . . . 4
- 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 4
- 4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 4
- 4.2. Resource records block . . . . . . . . . . . . . . . . . 5
- 4.3. Block data encryption and decryption . . . . . . . . . . 6
- 5. Internationalization and Character Encoding . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 8
- 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 8
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
- 10. Normative References . . . . . . . . . . . . . . . . . . . . 9
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1. Wire format . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 5
+ 4.2. Resource records block . . . . . . . . . . . . . . . . . 6
+ 4.3. Block data encryption and decryption . . . . . . . . . . 7
+ 5. Internationalization and Character Encoding . . . . . . . . . 9
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 9
+ 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 10
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
@@ -90,19 +92,17 @@ Table of Contents
2. Zones
- A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ A zone in GNS is defined by a public/private ECC key pair (x,zk),
where P is the generator of an elliptic curve, x is the private key
- and x*P the corresponding public key. The keys are constructed using
- the Ed25519 ECC scheme as defined in [RFC8032]. The public key "x*P"
- is used to uniquely identify and refer to the zone. Records
- published in the zone are signed using a private key derived from the
- private key "x" as described in Section 4.
+ and zk := x*P the corresponding public key. The keys are constructed
+ using the Ed25519 ECC scheme as defined in [RFC8032]. The public key
+ "zk" is used to uniquely identify and refer to the zone and is thus
+ called "zone key". Records published in the zone are signed using a
+ private key derived from the private key "x" as described in
+ Section 4.
3. Resource records
- A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:
-
@@ -114,6 +114,11 @@ Schanzenbach, et al. Expires 24 January 2020
[Page 2]
Internet-Draft The GNU Name System July 2019
+3.1. Wire format
+
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is defined as follows:
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
@@ -139,28 +144,23 @@ Internet-Draft The GNU Name System
July 2019
order.
TYPE The resource record type. This type can be one of the GNS
- resource records as defined in Section 3.2 or a DNS record type as
+ resource records as defined in Section 3 or a DNS record type as
defined in [RFC1035] or any of the complementary standardized DNS
- resource record types.
+ resource record types. This value must be stored in network byte
+ order. Note that values below 2^16 are reserved for allocation
+ via IANA and link to the DNS record type registry.
- FLAGS Resource record flags. Flags are defined in Section 3.1.
+ FLAGS Resource record flags.
DATA The resource record data payload. The contents are defined by
the respective type of the resource record.
-3.1. Flags
-
Flags indicate metadata surrounding the resource record. A flag
value of 0 indicates that all flags are unset. The following
illustrates the flag distribution in the 32-bit flag value of a
resource record:
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
- Figure 2
@@ -170,19 +170,27 @@ Schanzenbach, et al. Expires 24 January 2020
[Page 3]
Internet-Draft The GNU Name System July 2019
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
+
+ Figure 2
+
where:
SHADOW If this flag is set, this record should not be used unless
all (other) records with an absolute expiration time have expired.
EXPREL The expiration time value of the record is a relative time
- and not an absolute time. This flag can be ignored by a resolver.
+ and not an absolute time. This flag should never be encountered
+ by a resolver for records resolved from the DHT.
PRIVATE This is a private record of this peer and it should thus not
be handed out to other peers. This flag should never be
- encountered by a resolver.
+ encountered by a resolver for records resolved from the DHT.
-3.2. GNS resource record types
+3.2. PKEY
The a PKEY DATA entry has the following format:
@@ -196,52 +204,95 @@ Internet-Draft The GNU Name System
July 2019
Figure 3
+3.3. GNS2DNS
+
+ The a GNS2DNS DATA entry has the following format:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 4
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 4]
+
+Internet-Draft The GNU Name System July 2019
+
+
+3.4. LEHO
+
+ The a LEHO DATA entry has the following format:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | LEGACY HOSTNAME |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 5
+
4. Publishing records
GNS resource records are published in a distributed hash table (DHT).
Resource records are grouped by their respective labels and published
together in a single block in the DHT. A resource records block is
- published under a key which is derived from the zone key and the
+ published under a key which is derived from the zone key "zk" and the
respective label of the contained records. Given a label, the DHT
key "q" is derived as follows:
4.1. Key derivations
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d := h*x mod p
- q := SHA512 (d*P)
+ PRK_h := HKDF-Extract ("key-derivation", zk)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ x_h := h*x mod p
+ zk_h := h*zk mod p
+ q := SHA512 (zk_h)
We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
SHA256 for the expansion phase.
- h is key material retrieved using an HKDF using the string "key-
+ PRK_h is key material retrieved using an HKDF using the string "key-
derivation" as salt and the public zone key "x*P" as initial
+ keying material.
+ h is the HKDF expansion result. The expansion info is a
+ concatenation of the label and string "gns".
+ x is the private zone key as defined in [RFC8032].
-Schanzenbach, et al. Expires 24 January 2020 [Page 4]
-
-Internet-Draft The GNU Name System July 2019
+ P is the base point of the curve Ed25519 as defined in [RFC8032].
+ label under wich the resource records are published.
- keying material. The label and string "gns" are concatenated and
- used in the HKDF expansion phase.
- x is the private zone key as defined in [RFC8032].
- P is the base point of the curve Ed25519 as defined in [RFC8032].
- label under wich the resource records are published.
+Schanzenbach, et al. Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
- d is a private key derived from the zone key "x" using the keying
+
+ x_h is a private key derived from the zone private key "x" using the
+ keying material "h" (512 bit) and "p" is the group order as
+ defined in [RFC8032].
+
+ zk_h is a public key derived from the zone key "zk" using the keying
material "h" (512 bit) and "p" is the group order as defined in
[RFC8032].
q Is the DHT key under which the resource records block is
- published. It is the SHA512 hash over the public key "d*P"
- corresponding to the derived private key "d".
+ published. It is the SHA512 hash over the public key "zk_h"
+ corresponding to the derived private key "x_h".
4.2. Resource records block
@@ -250,49 +301,51 @@ Internet-Draft The GNU Name System
July 2019
a symmetric encryption scheme. A GNS resource records block has the
following format:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ Figure 6
+ where:
-Schanzenbach, et al. Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
- Figure 4
- where:
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+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
- private key "d" (see Section 4).
+ private key "x_h" (see Section 4).
- PUBLIC KEY The 256-bit ECC public key "d*P" to be used to verify
- SIGNATURE.
+ PUBLIC KEY The 256-bit ECC public key "zk_h" to be used to verify
+ SIGNATURE. The wire format of this value is defined in [RFC8032],
+ Section 5.1.5.
BDATA SIZE A 32-bit value containing the length of the following
data (PURPOSE, EXPIRATION, BDATA) in network byte order.
@@ -309,114 +362,119 @@ Internet-Draft The GNU Name System
July 2019
BDATA The encrypted resource records with a total size of "BDATA
SIZE".
+ As per [RFC8032], an ECDSA signature consists of a pair of integers,
+ r and s:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | r |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | s |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
4.3. Block data encryption and decryption
A symmetric encryption scheme is used to en-/decrypt the "BDATA"
field in a GNS record block. The keys are derived from the record
- label and the public key "d*P". The secret scalar "d" is derived
- from "h" and private key "x" of a GNS zone. Both label and public
- key and "x*P" are implicity known by a GNS resolver while "d*P" is
- provided within the resource records block. The validity of "d" can
- be checked by computing "h" from "x*P" and label and verifying that
- "d*P = h*x*P". This step is mandatory to prevent spoofed records to
- be verified and decrypted correctly. The keying material "K" and
- initialization vector "IV" for the symmetric encryption/decryption
- are derived as follows:
-
- PRK_kiv := HKDF-Extract (d*P, label)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
-
- We use a hash-based key derivation function (HKDF) as defined in
- [RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
- SHA256 for the expansion phase. The output keying material is 64
+ label and the zone key "zk". The validity of "d" can be checked by
+ computing "h" from "x_h" and label and verifying that "zk_h = h*zk".
+ This step is mandatory to prevent spoofed records to be verified and
+ decrypted correctly. The keying material "K" and initialization
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
Internet-Draft The GNU Name System July 2019
+ vector "IV" for the symmetric encryption/decryption are derived as
+ follows:
+
+ PRK_kiv := HKDF-Extract (zk, label)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+
+ We use a hash-based key derivation function (HKDF) as defined in
+ [RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
+ SHA256 for the expansion phase. The output keying material is 64
octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
the initialization vector. We divide the resulting keying material
"K" into a 256-bit AES key "Kaes" and a 256-bit TWOFISH key "Ktwo":
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 5
+ Figure 7
Similarly, we divide "IV" into a 128-bit initialization vector IVaes
and a 128-bit initialization vector IVtwo:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 6
+ Figure 8
The symmetric keys and IVs are used for a AES+TWOFISH combined
cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
-
- The decrypted RDATA has the following format:
-
-
+ RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
+ BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
Internet-Draft The GNU Name System July 2019
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
- / /
+ The decrypted RDATA has the following format:
- Figure 7
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / /
+
+ Figure 9
where:
@@ -438,18 +496,20 @@ Internet-Draft The GNU Name System
July 2019
TODO
-8. Namespace Revocation
- TODO
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
Internet-Draft The GNU Name System July 2019
+8. Namespace Revocation
+
+ TODO
+
9. IANA Considerations
This will be fun
@@ -495,17 +555,16 @@ Authors' Addresses
Email: address@hidden
- Bernd Fix
- GNUnet e.V.
- Boltzmannstrasse 3
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
Internet-Draft The GNU Name System July 2019
+ Bernd Fix
+ GNUnet e.V.
+ Boltzmannstrasse 3
85748 Garching
Germany
@@ -554,7 +613,4 @@ Internet-Draft The GNU Name System
July 2019
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 8e78652..a72d3b4 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -81,18 +81,21 @@
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
<t>
- A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ A zone in GNS is defined by a public/private ECC key pair (x,zk),
where P is the generator of an elliptic curve, x is the private key and
- x*P the corresponding public key.
+ zk := x*P the corresponding public key.
The keys are constructed using the Ed25519 ECC scheme as defined in
<xref target="RFC8032" />.
- The public key "x*P" is used to uniquely identify and refer to the zone.
+ The public key "zk" is used to uniquely identify and refer to the zone and
+ is thus called "zone key".
Records published in the zone are signed using a private key derived
from the private key "x" as described in <xref target="publish" />.
</t>
</section>
<section anchor="rrecords" numbered="true" toc="default">
- <name>Resource records</name>
+ <name>Resource records</name>
+ <section anchor="rrecords_wire" numbered="true" toc="default">
+ <name>Wire format</name>
<t>
A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined as follows:
@@ -129,64 +132,65 @@
<dt>TYPE</dt>
<dd>
The resource record type. This type can be one of the GNS resource
- records as defined in <xref target="gnsrecords" /> or a DNS record
+ records as defined in <xref target="rrecords" /> or a DNS record
type as defined in <xref target="RFC1035" /> or any of the
- complementary standardized DNS resource record types.
- </dd>
- <dt>FLAGS</dt>
- <dd>
- Resource record flags. Flags are defined in <xref target="flags" />.
- </dd>
- <dt>DATA</dt>
- <dd>
+ complementary standardized DNS resource record types. This value must be
+ stored in network byte order. Note that values
+ below 2^16 are reserved for allocation via IANA and link to the DNS
+ record type registry.
+ </dd>
+ <dt>FLAGS</dt>
+ <dd>
+ Resource record flags.
+ </dd>
+ <dt>DATA</dt>
+ <dd>
The resource record data payload. The contents are defined by the
respective type of the resource record.
- </dd>
- </dl>
- <section anchor="flags" numbered="true" toc="default">
- <name>Flags</name>
- <t>
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
- illustrates the flag distribution in the 32-bit flag value of a
- resource record:</t>
- <figure anchor="figure_flag">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- ... 5 4 3 2 1 0
- ------+--------+--------+--------+--------+--------+
- / ... | SHADOW | EXPREL | / | PRIVATE| / |
- ------+--------+--------+--------+--------+--------+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- where:
- </t>
- <dl>
- <dt>SHADOW</dt>
- <dd>
- If this flag is set, this record should not be used unless all (other)
- records with an absolute expiration time have expired.
- </dd>
- <dt>EXPREL</dt>
- <dd>
- The expiration time value of the record is a relative time and not
- an absolute time. This flag can be ignored by a resolver.
- </dd>
- <dt>PRIVATE</dt>
- <dd>
- This is a private record of this peer and it should thus not be
- handed out to other peers. This flag should never be encountered by
- a resolver.
- </dd>
- </dl>
- </section>
- <section anchor="gnsrecords" numbered="true" toc="default">
- <name>GNS resource record types</name>
-
- <t>The a PKEY DATA entry has the following format:</t>
- <figure anchor="figure_pkeyrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ </dd>
+ </dl>
+ <t>
+ Flags indicate metadata surrounding the resource record. A flag
+ value of 0 indicates that all flags are unset. The following
+ illustrates the flag distribution in the 32-bit flag value of a
+ resource record:</t>
+ <figure anchor="figure_flag">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ ... 5 4 3 2 1 0
+ ------+--------+--------+--------+--------+--------+
+ / ... | SHADOW | EXPREL | / | PRIVATE| / |
+ ------+--------+--------+--------+--------+--------+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ where:
+ </t>
+ <dl>
+ <dt>SHADOW</dt>
+ <dd>
+ If this flag is set, this record should not be used unless all (other)
+ records with an absolute expiration time have expired.
+ </dd>
+ <dt>EXPREL</dt>
+ <dd>
+ The expiration time value of the record is a relative time and not
+ an absolute time. This flag should never be encountered by a resolver
+ for records resolved from the DHT.
+ </dd>
+ <dt>PRIVATE</dt>
+ <dd>
+ This is a private record of this peer and it should thus not be
+ handed out to other peers. This flag should never be encountered by
+ a resolver for records resolved from the DHT.
+ </dd>
+ </dl>
+</section>
+<section anchor="gnsrecords_pkey" numbered="true" toc="default">
+ <name>PKEY</name>
+ <t>The a PKEY DATA entry has the following format:</t>
+ <figure anchor="figure_pkeyrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
@@ -195,384 +199,446 @@
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- </section>
- </section>
-
- <section anchor="publish" numbered="true" toc="default">
- <name>Publishing records</name>
- <t>
- GNS resource records are published in a distributed hash table (DHT).
- Resource records are grouped by their respective labels and published
- together in a single block in the DHT.
- A resource records block is published under a key which is derived from
- the zone key and the respective label of the contained records.
- Given a label, the DHT key "q" is derived as follows:
- </t>
- <section anchor="blinding" numbered="true" toc="default">
- <name>Key derivations</name>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+</section>
+<section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
+ <name>GNS2DNS</name>
+ <t>The a GNS2DNS DATA entry has the following format:</t>
+ <figure anchor="figure_gns2dnsrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- PRK_h := HKDF-Extract ("key-derivation", x*P)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
- d := h*x mod p
- q := SHA512 (d*P)
- ]]></artwork>
- <t>
- We use a hash-based key derivation function (HKDF) as defined in
- <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.
- </t>
- <dl>
- <dt>h</dt>
- <dd>
- is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public zone key "x*P" as initial keying
- material. The label and string "gns" are concatenated and used in the
- HKDF expansion phase.
- </dd>
- <dt>x</dt>
- <dd>
- is the private zone key as defined in <xref target="RFC8032" />.
- </dd>
- <dt>P</dt>
- <dd>
- is the base point of the curve Ed25519 as defined in
- <xref target="RFC8032" />.
- </dd>
- <dt>label</dt>
- <dd>
- under wich the resource records are published.
- </dd>
- <dt>d</dt>
- <dd>
- is a private key derived from the zone key "x" using the keying
- material "h" (512 bit) and "p" is the group order as defined in
- <xref target="RFC8032" />.
- </dd>
- <dt>q</dt>
- <dd>
- Is the DHT key under which the resource records block is published.
- It is the SHA512 hash over the public key "d*P" corresponding to the
- derived private key "d".
- </dd>
- </dl>
- </section>
- <section anchor="wire" numbered="true" toc="default">
- <name>Resource records block</name>
- <t>
- GNS records are grouped by their labels and published as a single
- block in the DHT.
- The contained resource records are encrypted using a symmetric
- encryption scheme.
- A GNS resource records block has the following format:
- </t>
- <figure anchor="figure_record_block">
- <artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
+ | PUBLIC KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
- </figure>
- <t>where:</t>
- <dl>
- <dt>SIGNATURE</dt>
- <dd>
- A 512-bit ECDSA deterministic signature compliant with
- <xref target="RFC6979" />. The signature is computed over the data
- following the PUBLIC KEY field.
- The signature is created using the derived private key "d" (see
- <xref target="publish" />).
- </dd>
- <dt>PUBLIC KEY</dt>
- <dd>
- The 256-bit ECC public key "d*P" to be used to verify SIGNATURE.
- </dd>
- <dt>BDATA SIZE</dt>
- <dd>
- A 32-bit value containing the length of the following data (PURPOSE,
- EXPIRATION, BDATA) in network byte order.
- </dd>
- <dt>PURPOSE</dt>
- <dd>
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).
- </dd>
- <dt>EXPIRATION</dt>
- <dd>
- The resource records block expiration time. This is the expiration
- time of the resource record contained within this block with the
- smallest expiration time.
- This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.
- </dd>
- <dt>BDATA</dt>
- <dd>
- The encrypted resource records with a total size of "BDATA SIZE".
- </dd>
- </dl>
- </section>
- <section numbered="true" toc="default">
- <name>Block data encryption and decryption</name>
- <t>
- A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
- in a GNS record block. The keys are derived from the record label
- and the public key "d*P". The secret scalar "d" is derived from "h"
- and private key "x" of a GNS zone.
- Both label and public key and "x*P" are implicity known by a GNS
- resolver while "d*P" is provided within the resource records block.
- The validity of "d" can be checked by computing "h" from "x*P" and
- label and verifying that "d*P = h*x*P". This step is mandatory to
- prevent spoofed records to be verified and decrypted correctly.
- The keying material "K" and initialization vector "IV" for the
- symmetric encryption/decryption are derived as follows:
- </t>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+</section>
+
+<section anchor="gnsrecords_leho" numbered="true" toc="default">
+ <name>LEHO</name>
+ <t>The a LEHO DATA entry has the following format:</t>
+ <figure anchor="figure_lehorecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- PRK_kiv := HKDF-Extract (d*P, label)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
- ]]></artwork>
- <t>
- We use a hash-based key derivation function (HKDF) as defined in
- <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.
- The output keying material is 64 octets (512 bit) for the symmetric
- keys and 32 octets (256 bit) for the initialization vector.
- We divide the resulting keying material "K" into a 256-bit AES key
- "Kaes" and a 256-bit TWOFISH key "Ktwo":
- </t>
- <figure anchor="figure_hkdf_keys">
- <artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
+ | LEGACY HOSTNAME |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:
- </t>
- <figure anchor="figure_hkdf_ivs">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+</section>
+ </section>
+
+ <section anchor="publish" numbered="true" toc="default">
+ <name>Publishing records</name>
<t>
- The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
- ]]></artwork>
- <t>
- The decrypted RDATA has the following format:
- </t>
- <figure anchor="figure_rdata">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | RR COUNT | EXPIRA- /
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / -TION | DATA SIZE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TYPE | FLAGS |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA /
- / /
- / |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA /
- +-----+-----+-----+-----+ /
- / /
- / /
- / /
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>where:</t>
- <dl>
- <dt>RR COUNT</dt>
- <dd>
- A 32-bit value containing the number of resource records which are
- following in network byte order.
- </dd>
- </dl>
- <t>
- is followed by a set of resource records with the respective
- formats defined in <xref target="rrecords" />.
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels and published
+ together in a single block in the DHT.
+ A resource records block is published under a key which is derived from
+ the zone key "zk" and the respective label of the contained records.
+ Given a label, the DHT key "q" is derived as follows:
</t>
- </section>
+ <section anchor="blinding" numbered="true" toc="default">
+ <name>Key derivations</name>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ PRK_h := HKDF-Extract ("key-derivation", zk)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ x_h := h*x mod p
+ zk_h := h*zk mod p
+ q := SHA512 (zk_h)
+ ]]></artwork>
+ <t>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ </t>
+ <dl>
+ <dt>PRK_h</dt>
+ <dd>
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key "x*P" as initial
keying
+ material.
+ </dd>
+ <dt>h</dt>
+ <dd>
+ is the HKDF expansion result. The expansion info is a concatenation
of
+ the label and string "gns".
+ </dd>
+ <dt>x</dt>
+ <dd>
+ is the private zone key as defined in <xref target="RFC8032" />.
+ </dd>
+ <dt>P</dt>
+ <dd>
+ is the base point of the curve Ed25519 as defined in
+ <xref target="RFC8032" />.
+ </dd>
+ <dt>label</dt>
+ <dd>
+ under wich the resource records are published.
+ </dd>
+ <dt>x_h</dt>
+ <dd>
+ is a private key derived from the zone private key "x" using the
+ keying material "h" (512 bit) and "p" is the group order as defined
in
+ <xref target="RFC8032" />.
+ </dd>
+ <dt>zk_h</dt>
+ <dd>
+ is a public key derived from the zone key "zk" using the keying
+ material "h" (512 bit) and "p" is the group order as defined in
+ <xref target="RFC8032" />.
+ </dd>
+ <dt>q</dt>
+ <dd>
+ Is the DHT key under which the resource records block is published.
+ It is the SHA512 hash over the public key "zk_h" corresponding to the
+ derived private key "x_h".
+ </dd>
+ </dl>
+ </section>
+ <section anchor="wire" numbered="true" toc="default">
+ <name>Resource records block</name>
+ <t>
+ GNS records are grouped by their labels and published as a single
+ block in the DHT.
+ The contained resource records are encrypted using a symmetric
+ encryption scheme.
+ A GNS resource records block has the following format:
+ </t>
+ <figure anchor="figure_record_block">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA SIZE | PURPOSE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | BDATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>SIGNATURE</dt>
+ <dd>
+ A 512-bit ECDSA deterministic signature compliant with
+ <xref target="RFC6979" />. The signature is computed over the data
+ following the PUBLIC KEY field.
+ The signature is created using the derived private key "x_h" (see
+ <xref target="publish" />).
+ </dd>
+ <dt>PUBLIC KEY</dt>
+ <dd>
+ The 256-bit ECC public key "zk_h" to be used to verify SIGNATURE. The
+ wire format of this value is defined in <xref target="RFC8032" />,
+ Section 5.1.5.
+ </dd>
+ <dt>BDATA SIZE</dt>
+ <dd>
+ A 32-bit value containing the length of the following data (PURPOSE,
+ EXPIRATION, BDATA) in network byte order.
+ </dd>
+ <dt>PURPOSE</dt>
+ <dd>
+ A 32-bit signature purpose flag. This field MUST be 15 (in network
+ byte order).
+ </dd>
+ <dt>EXPIRATION</dt>
+ <dd>
+ The resource records block expiration time. This is the expiration
+ time of the resource record contained within this block with the
+ smallest expiration time.
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 in network byte order.
+ </dd>
+ <dt>BDATA</dt>
+ <dd>
+ The encrypted resource records with a total size of "BDATA SIZE".
+ </dd>
+ </dl>
+ <t>
+ As per <xref target="RFC8032" />, an ECDSA signature consists of a
pair
+ of integers, r and s:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | r |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | s |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </section>
+ <section numbered="true" toc="default">
+ <name>Block data encryption and decryption</name>
+ <t>
+ A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
+ in a GNS record block. The keys are derived from the record label
+ and the zone key "zk".
+ The validity of "d" can be checked by computing "h" from "x_h" and
+ label and verifying that "zk_h = h*zk". This step is mandatory to
+ prevent spoofed records to be verified and decrypted correctly.
+ The keying material "K" and initialization vector "IV" for the
+ symmetric encryption/decryption are derived as follows:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ PRK_kiv := HKDF-Extract (zk, label)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ ]]></artwork>
+ <t>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vector.
+ We divide the resulting keying material "K" into a 256-bit AES key
+ "Kaes" and a 256-bit TWOFISH key "Ktwo":
+ </t>
+ <figure anchor="figure_hkdf_keys">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ Similarly, we divide "IV" into a 128-bit initialization vector IVaes
+ and a 128-bit initialization vector IVtwo:
+ </t>
+ <figure anchor="figure_hkdf_ivs">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+
+ <t>
+ The symmetric keys and IVs are used for a AES+TWOFISH combined
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
+ BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ ]]></artwork>
+ <t>
+ The decrypted RDATA has the following format:
+ </t>
+ <figure anchor="figure_rdata">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | RR COUNT | EXPIRA- /
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / -TION | DATA SIZE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TYPE | FLAGS |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA /
+ / /
+ / |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA /
+ +-----+-----+-----+-----+ /
+ / /
+ / /
+ / /
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>RR COUNT</dt>
+ <dd>
+ A 32-bit value containing the number of resource records which are
+ following in network byte order.
+ </dd>
+ </dl>
+ <t>
+ is followed by a set of resource records with the respective
+ formats defined in <xref target="rrecords" />.
+ </t>
+ </section>
</section>
<section anchor="encoding" numbered="true" toc="default">
- <name>Internationalization and Character Encoding</name>
- <t>
- TODO
- </t>
+ <name>Internationalization and Character Encoding</name>
+ <t>
+ TODO
+ </t>
</section>
<section anchor="security" numbered="true" toc="default">
- <name>Security Considerations</name>
- <t>
- TODO
- </t>
+ <name>Security Considerations</name>
+ <t>
+ TODO
+ </t>
</section>
<section anchor="resolution" numbered="true" toc="default">
- <name>Record Resolution</name>
- <t>
- TODO
- </t>
+ <name>Record Resolution</name>
+ <t>
+ TODO
+ </t>
</section>
<section anchor="revocation" numbered="true" toc="default">
- <name>Namespace Revocation</name>
- <t>
- TODO
- </t>
+ <name>Namespace Revocation</name>
+ <t>
+ TODO
+ </t>
</section>
<section anchor="iana" numbered="true" toc="default">
- <name>IANA Considerations</name>
- <t>
- This will be fun
- </t>
+ <name>IANA Considerations</name>
+ <t>
+ This will be fun
+ </t>
</section>
<!-- iana -->
- </middle>
- <back>
+</middle>
+<back>
<references>
- <name>Normative References</name>
- <reference anchor="RFC5869"
target="https://www.rfc-editor.org/info/rfc5869";>
- <front>
- <title>
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
- </title>
- <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
- <organization/>
- </author>
- <author initials="P." surname="Eronen" fullname="P. Eronen">
- <organization/>
- </author>
- <date year="2010" month="May"/>
- <abstract>
- <t>
- This document specifies a simple Hashed Message Authentication Code
(HMAC)-based key derivation function (HKDF), which can be used as a building
block in various protocols and applications. The key derivation function (KDF)
is intended to support a wide range of applications and requirements, and is
conservative in its use of cryptographic hash functions. This document is not
an Internet Standards Track specification; it is published for informational
purposes.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="5869"/>
- <seriesInfo name="DOI" value="10.17487/RFC5869"/>
- </reference>
- <reference anchor="RFC8032"
target="https://www.rfc-editor.org/info/rfc8032";>
- <front>
- <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
- <author initials="S." surname="Josefsson" fullname="S. Josefsson">
- <organization/>
- </author>
- <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
- <organization/>
- </author>
- <date year="2017" month="January"/>
- <abstract>
- <t>
- This document describes elliptic curve signature scheme Edwards-curve
Digital Signature Algorithm (EdDSA). The algorithm is instantiated with
recommended parameters for the edwards25519 and edwards448 curves. An example
implementation and test vectors are provided.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="8032"/>
- <seriesInfo name="DOI" value="10.17487/RFC8032"/>
- </reference>
- <reference anchor="RFC1035"
target="https://www.rfc-editor.org/info/rfc1035";>
- <front>
- <title>Domain names - implementation and specification</title>
- <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
- <organization/>
- </author>
- <date year="1987" month="November"/>
- <abstract>
- <t>
- This RFC is the revised specification of the protocol and format used
in the implementation of the Domain Name System. It obsoletes RFC-883. This
memo documents the details of the domain name client - server communication.
- </t>
- </abstract>
- </front>
- <seriesInfo name="STD" value="13"/>
- <seriesInfo name="RFC" value="1035"/>
- <seriesInfo name="DOI" value="10.17487/RFC1035"/>
- </reference>
- <reference anchor="RFC6979"
target="https://www.rfc-editor.org/info/rfc6979";>
- <front>
- <title>
- Deterministic Usage of the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA)
- </title>
- <author initials="T." surname="Pornin" fullname="T. Pornin">
- <organization/>
- </author>
- <date year="2013" month="August"/>
- <abstract>
- <t>
- This document defines a deterministic digital signature generation
procedure. Such signatures are compatible with standard Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital
signatures and can be processed with unmodified verifiers, which need not be
aware of the procedure described therein. Deterministic signatures retain the
cryptographic security features associated with digital signatures but can be
more easily implemented in vario [...]
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="6979"/>
- <seriesInfo name="DOI" value="10.17487/RFC6979"/>
- </reference>
- <!-- <reference anchor="ISO20022">
- <front>
- <title>ISO 20022 Financial Services - Universal financial industry
message scheme</title>
- <author>
- <organization>International Organization for
Standardization</organization>
- <address>
- <uri>http://www.iso.ch</uri>
- </address>
- </author>
- <date month="May" year="2013"/>
- </front>
- </reference>-->
+ <name>Normative References</name>
+ <reference anchor="RFC5869"
target="https://www.rfc-editor.org/info/rfc5869";>
+ <front>
+ <title>
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ </title>
+ <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
+ <organization/>
+ </author>
+ <author initials="P." surname="Eronen" fullname="P. Eronen">
+ <organization/>
+ </author>
+ <date year="2010" month="May"/>
+ <abstract>
+ <t>
+ This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a
building block in various protocols and applications. The key derivation
function (KDF) is intended to support a wide range of applications and
requirements, and is conservative in its use of cryptographic hash functions.
This document is not an Internet Standards Track specification; it is published
for informational purposes.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="5869"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5869"/>
+ </reference>
+ <reference anchor="RFC8032"
target="https://www.rfc-editor.org/info/rfc8032";>
+ <front>
+ <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
+ <author initials="S." surname="Josefsson" fullname="S. Josefsson">
+ <organization/>
+ </author>
+ <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
+ <organization/>
+ </author>
+ <date year="2017" month="January"/>
+ <abstract>
+ <t>
+ This document describes elliptic curve signature scheme
Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is
instantiated with recommended parameters for the edwards25519 and edwards448
curves. An example implementation and test vectors are provided.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8032"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8032"/>
+ </reference>
+ <reference anchor="RFC1035"
target="https://www.rfc-editor.org/info/rfc1035";>
+ <front>
+ <title>Domain names - implementation and specification</title>
+ <author initials="P.V." surname="Mockapetris" fullname="P.V.
Mockapetris">
+ <organization/>
+ </author>
+ <date year="1987" month="November"/>
+ <abstract>
+ <t>
+ This RFC is the revised specification of the protocol and format
used in the implementation of the Domain Name System. It obsoletes RFC-883.
This memo documents the details of the domain name client - server
communication.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="STD" value="13"/>
+ <seriesInfo name="RFC" value="1035"/>
+ <seriesInfo name="DOI" value="10.17487/RFC1035"/>
+ </reference>
+ <reference anchor="RFC6979"
target="https://www.rfc-editor.org/info/rfc6979";>
+ <front>
+ <title>
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and
Elliptic Curve Digital Signature Algorithm (ECDSA)
+ </title>
+ <author initials="T." surname="Pornin" fullname="T. Pornin">
+ <organization/>
+ </author>
+ <date year="2013" month="August"/>
+ <abstract>
+ <t>
+ This document defines a deterministic digital signature generation
procedure. Such signatures are compatible with standard Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital
signatures and can be processed with unmodified verifiers, which need not be
aware of the procedure described therein. Deterministic signatures retain the
cryptographic security features associated with digital signatures but can be
more easily implemented in [...]
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6979"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6979"/>
+ </reference>
+ <!-- <reference anchor="ISO20022">
+ <front>
+ <title>ISO 20022 Financial Services - Universal financial industry
message scheme</title>
+ <author>
+ <organization>International Organization for
Standardization</organization>
+ <address>
+ <uri>http://www.iso.ch</uri>
+ </address>
+ </author>
+ <date month="May" year="2013"/>
+ </front>
+ </reference>-->
</references>
<!-- Change Log
v00 2017-07-23 MS Initial version
-->
- </back>
+</back>
</rfc>
--
To stop receiving notification emails like this one, please contact
address@hidden.