[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: cite rfc 2119
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: cite rfc 2119 |
|
Date: |
Sun, 10 Nov 2019 21:05:33 +0100 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 1f02080 cite rfc 2119
1f02080 is described below
commit 1f02080c7484d60f6a28dc33de2adc73bd48195f
Author: Christian Grothoff <address@hidden>
AuthorDate: Sun Nov 10 21:02:55 2019 +0100
cite rfc 2119
---
draft-schanzen-gns.html | 724 +++++++++++++++++++++++-------------------------
draft-schanzen-gns.txt | 506 ++++++++++-----------------------
draft-schanzen-gns.xml | 144 +++-------
3 files changed, 524 insertions(+), 850 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 67ff657..95693d0 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2,35 +2,20 @@
<html lang="en" class="Internet-Draft">
<head>
<meta charset="utf-8">
-<meta content="Common,Latin" name="scripts">
-<meta content="initial-scale=1.0" name="viewport">
<title>
The GNU Name System Specification
</title>
-<meta content="Martin Schanzenbach" name="author">
-<meta content="Christian Grothoff" name="author">
-<meta content="Bernd Fix" name="author">
-<meta content="
+ <meta name="author" content="Martin Schanzenbach">
+<meta name="author" content="Christian Grothoff">
+<meta name="author" content="Bernd Fix">
+<meta name="description" content="
This document contains the GNU Name System (GNS) technical
specification.
- " name="description">
-<meta content="xml2rfc 2.26.0" name="generator">
-<meta content="name systems" name="keyword">
-<link href="draft-schanzen-gns.xml" type="application/rfc+xml" rel="alternate">
-<link href="#copyright" rel="license">
-<style type="text/css">/*
-
- NOTE: Changes at the bottom of this file overrides some earlier settings.
-
- Once the style has stabilized and has been adopted as an official RFC style,
- this can be consolidated so that style settings occur only in one place, but
- for now the contents of this file consists first of the initial CSS work as
- provided to the RFC Formatter (xml2rfc) work, followed by itemized and
- commented changes found necssary during the development of the v3
- formatters.
-
-*/
-
-/* fonts */
+ ">
+<meta name="generator" content="xml2rfc 2.15.5">
+<meta name="keyword" content="name systems">
+<link rel="alternate" type="application/rfc+xml" href="draft-schanzen-gns.xml">
+<link rel="license" href="#copyright">
+<style type="text/css">/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /*
Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif
(print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /*
Monospace */
@@ -196,16 +181,11 @@ dl > dt {
float: left;
margin-right: 1em;
}
-/*
-dl.nohang > dt {
- float: none;
-}
-*/
dl > dd {
margin-bottom: .8em;
min-height: 1.3em;
}
-dl.compact > dd, .dlCompact > dd {
+dl.compact > dd, dlCompact > dd {
margin-bottom: 0em;
}
dl > dd > dl {
@@ -218,7 +198,7 @@ a {
text-decoration: none;
}
a[href] {
- color: #22e; /* Arlen: WCAG 2019 */
+ color: #3E8EDE;
}
a[href]:hover {
background-color: #f2f2f2;
@@ -271,7 +251,6 @@ aside, blockquote {
}
blockquote {
background-color: #f9f9f9;
- color: #111; /* Arlen: WCAG 2019 */
border: 1px solid #ddd;
border-radius: 3px;
margin: 1em 0;
@@ -315,7 +294,7 @@ table p {
/* pilcrow */
a.pilcrow {
- color: #666; /* Arlen: AHDJ 2019 */
+ color: #777;
text-decoration: none;
visibility: hidden;
user-select: none;
@@ -376,7 +355,7 @@ hr {
/* The prepared/rendered info at the very bottom of the page */
.docInfo {
- color: #666; /* Arlen: WCAG 2019 */
+ color: #999;
font-size: 0.9em;
font-style: italic;
margin-top: 2em;
@@ -490,17 +469,17 @@ hr.addr {
right: 0.2em;
padding: 0.2em;
content: "The RFC Editor will remove this note";
- color: #9e2a00; /* Arlen: WCAG 2019 */
- background-color: #ffd; /* Arlen: WCAG 2019 */
+ color: #b76427;
+ background-color: rgba(249, 232, 105, 0.3);
}
.rfcEditorRemove {
position: relative;
padding-top: 1.8em;
- background-color: #ffd; /* Arlen: WCAG 2019 */
+ background-color: rgba(249, 232, 105, 0.3);
border-radius: 3px;
}
.cref {
- background-color: #ffd; /* Arlen: WCAG 2019 */
+ background-color: rgba(249, 232, 105, 0.3);
padding: 2px 4px;
}
.crefSource {
@@ -607,7 +586,7 @@ hr.addr {
/* pagination */
@media print {
body {
-
+ font-family: 'Noto Serif', "Times New Roman", Times, serif;
width: 100%;
}
p {
@@ -649,9 +628,6 @@ hr.addr {
}
}
-/* This is commented out here, as the string-set: doesn't
- pass W3C validation currently */
-/*
.ears thead .left {
string-set: ears-top-left content();
}
@@ -675,7 +651,6 @@ hr.addr {
.ears tfoot .right {
string-set: ears-bottom-right content();
}
-*/
@page :first {
padding-top: 0;
@@ -697,9 +672,6 @@ hr.addr {
size: A4;
margin-bottom: 45mm;
padding-top: 20px;
- /* The follwing is commented out here, but set appropriately by in code, as
- the content depends on the document */
- /*
@top-left {
content: 'Internet-Draft';
vertical-align: bottom;
@@ -735,15 +707,10 @@ hr.addr {
vertical-align: top;
border-top: solid 1px #ccc;
}
- */
-
}
/* Changes introduced to fix issues found during implementation */
-/* Make sure links are clickable even if overlapped by following H* */
-a {
- z-index: 2;
-}
+
/* Separate body from document info even without intervening H1 */
section {
clear: both;
@@ -802,12 +769,10 @@ tt, code, pre, code {
}
/* Fix the height/width aspect for ascii art*/
-pre.sourcecode,
.art-text pre {
line-height: 1.12;
}
-
/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
float: right;
@@ -868,18 +833,10 @@ caption {
script don't end up on the other side of the page. */
address.vcard {
- max-width: 30em;
+ max-width: 20em;
margin-right: auto;
}
-/* For address alignment dependent on LTR or RTL scripts */
-address div.left {
- text-align: left;
-}
-address div.right {
- text-align: right;
-}
-
/* Provide table alignment support. We can't use the alignX classes above
since they do unwanted things with caption and other styling. */
table.right {
@@ -899,89 +856,19 @@ table.left {
caption a[href] {
color: #222;
}
-
-@media print {
- .toplink {
- display: none;
- }
-
- /* avoid overwriting the top border line with the ToC header */
- #toc {
- padding-top: 1px;
- }
-
- /* Avoid page breaks inside dl and author address entries */
- dd {
- page-break-before: avoid;
- }
- .vcard {
- page-break-inside: avoid;
- }
-
-}
-/* Avoid wrapping of URLs in references */
-.references a {
- white-space: nowrap;
-}
-/* Tweak the bcp14 keyword presentation */
-.bcp14 {
- font-variant: small-caps;
- font-weight: bold;
- font-size: 0.9em;
-}
-/* Tweak the invisible space above H* in order not to overlay links in text
above */
- h2 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 31px;
- }
- h3 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 24px;
- }
- h4 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 24px;
- }
-/* Float artwork pilcrow to the right */
-.artwork a.pilcrow {
- display: block;
- line-height: 0.7;
- margin-top: 0.15em;
-}
-/* Make pilcrows on dd visible */
-@media screen {
- dd:hover > a.pilcrow {
- visibility: visible;
- }
-}
-/* Make the placement of figcaption match that of a table's caption
- by removing the figure's added bottom margin */
-.alignLeft.art-text,
-.alignCenter.art-text,
-.alignRight.art-text {
- margin-bottom: 0;
-}
-.alignLeft,
-.alignCenter,
-.alignRight {
- margin: 1em 0 0 0;
-}
</style>
-<link href="rfc-local.css" type="text/css" rel="stylesheet">
+<link rel="stylesheet" href="rfc-local.css" type="text/css">
</head>
<body>
-<script>
-async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(let
t=0;t<e.length;t++)if(/#identifiers/.exec(e[t].selectorText)){const
a=e[t].cssText.replace("#identifiers","#metadata");document.styleSheets[0].insertRule(a,document.styleSheets[0].cssRules.length)}}catch(e){console.log(e)}const
e=document.getElementById("metadata");if(e){e.style.background="#eee";try{var
t;t=document.URL.indexOf("html")>=0?document.URL.replace(/html$/,"json"):document.URL+".json";const
o=aw [...]
-<script src="metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">The GNU Name System</td>
-<td class="right">July 2019</td>
+<td class="right">November 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Schanzenbach, et al.</td>
-<td class="center">Expires 24 January 2020</td>
+<td class="center">Expires 13 May 2020</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
@@ -993,12 +880,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dd class="internet-draft">draft-schanzen-gns-00</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
-<time datetime="2019-07-23" class="published">23 July 2019</time>
+<time datetime="2019-11-10" class="published">10 November 2019</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2020-01-24">24 January 2020</time></dd>
+<dd class="expires"><time datetime="2020-05-13">13 May 2020</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
@@ -1028,21 +915,17 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of
This Memo</a>
</h2>
-<p id="section-boilerplate.1-1">
- This Internet-Draft is submitted in full conformance with the
+<p id="section-boilerplate.1-1">This Internet-Draft is submitted in full
conformance with the
provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1"
class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-2">
- Internet-Drafts are working documents of the Internet Engineering Task
+<p id="section-boilerplate.1-2">Internet-Drafts are working documents of the
Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
- at <span><a
href="https://datatracker.ietf.org/drafts/current/";>https://datatracker.ietf.org/drafts/current/</a></span>.<a
href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-3">
- Internet-Drafts are draft documents valid for a maximum of six months
+ at https://datatracker.ietf.org/drafts/current/.<a
href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">Internet-Drafts are draft documents valid for
a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a
href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-4">
- This Internet-Draft will expire on 24 January 2020.<a
href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">This Internet-Draft will expire on 13 May
2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
@@ -1050,19 +933,17 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright
Notice</a>
</h2>
-<p id="section-boilerplate.2-1">
- Copyright (c) 2019 IETF Trust and the persons identified as the
- document authors. All rights reserved.<a
href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.2-2">
- This document is subject to BCP 78 and the IETF Trust's Legal
+<p id="section-boilerplate.2-1">Copyright (c) 2019 IETF Trust and the persons
identified as the document
+ authors. All rights reserved.<a href="#section-boilerplate.2-1"
class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">This document is subject to BCP 78 and the
IETF Trust's Legal
Provisions Relating to IETF Documents
- (<span><a
href="https://trustee.ietf.org/license-info";>https://trustee.ietf.org/license-info</a></span>)
in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with
- respect to this document. Code Components extracted from this
- document must include Simplified BSD License text as described in
- Section 4.e of the Trust Legal Provisions and are provided without
- warranty as described in the Simplified BSD License.<a
href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
carefully,
+ as they describe your rights and restrictions with respect to this
+ document. Code Components extracted from this document must include
+ Simplified BSD License text as described in Section 4.e of the
Trust
+ Legal Provisions and are provided without warranty as described in
the
+ Simplified BSD License.<a href="#section-boilerplate.2-2"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
@@ -1072,102 +953,102 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.1">
- <p id="section-boilerplate.3-1.1.1"><a href="#section-1"
class="xref">1</a>. <a href="#name-introduction"
class="xref">Introduction</a><a href="#section-boilerplate.3-1.1.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.1.1"><a href="#section-1"
class="xref">1</a>. <a href="#name-introduction"
class="xref">Introduction</a><a href="#section-boilerplate.3-1.1.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.2">
- <p id="section-boilerplate.3-1.2.1"><a href="#section-2"
class="xref">2</a>. <a href="#name-zones" class="xref">Zones</a><a
href="#section-boilerplate.3-1.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.2.1"><a href="#section-2"
class="xref">2</a>. <a href="#name-zones" class="xref">Zones</a><a
href="#section-boilerplate.3-1.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3">
- <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>
+ <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-record-types" class="xref">Record
Types</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-record-types" class="xref">Record
Types</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-pkey" class="xref">PKEY</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>
+ <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>
+ <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>
<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-nick" class="xref">NICK</a><a
href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.5.1"><a href="#section-3.5"
class="xref">3.5</a>. <a href="#name-nick" class="xref">NICK</a><a
href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.6">
- <p id="section-boilerplate.3-1.3.2.6.1"><a href="#section-3.6"
class="xref">3.6</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.6.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.6.1"><a href="#section-3.6"
class="xref">3.6</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.6.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.7">
- <p id="section-boilerplate.3-1.3.2.7.1"><a href="#section-3.7"
class="xref">3.7</a>. <a href="#name-vpn" class="xref">VPN</a><a
href="#section-boilerplate.3-1.3.2.7.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.7.1"><a href="#section-3.7"
class="xref">3.7</a>. <a href="#name-vpn" class="xref">VPN</a><a
href="#section-boilerplate.3-1.3.2.7.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4">
- <p id="section-boilerplate.3-1.4.1"><a href="#section-4"
class="xref">4</a>. <a href="#name-publishing-records" class="xref">Publishing
Records</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.1"><a href="#section-4"
class="xref">4</a>. <a href="#name-publishing-records" class="xref">Publishing
Records</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.1">
- <p id="section-boilerplate.3-1.4.2.1.1"><a href="#section-4.1"
class="xref">4.1</a>. <a href="#name-key-derivations" class="xref">Key
Derivations</a><a href="#section-boilerplate.3-1.4.2.1.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.2.1.1"><a href="#section-4.1"
class="xref">4.1</a>. <a href="#name-key-derivations" class="xref">Key
Derivations</a><a href="#section-boilerplate.3-1.4.2.1.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.2">
- <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2"
class="xref">4.2</a>. <a href="#name-resource-records-block"
class="xref">Resource Records Block</a><a
href="#section-boilerplate.3-1.4.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2"
class="xref">4.2</a>. <a href="#name-resource-records-block"
class="xref">Resource Records Block</a><a
href="#section-boilerplate.3-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.3">
- <p id="section-boilerplate.3-1.4.2.3.1"><a href="#section-4.3"
class="xref">4.3</a>. <a href="#name-record-data-encryption-and-"
class="xref">Record Data Encryption and Decryption</a><a
href="#section-boilerplate.3-1.4.2.3.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.2.3.1"><a href="#section-4.3"
class="xref">4.3</a>. <a href="#name-record-data-encryption-and-"
class="xref">Record Data Encryption and Decryption</a><a
href="#section-boilerplate.3-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.5">
- <p id="section-boilerplate.3-1.5.1"><a href="#section-5"
class="xref">5</a>. <a href="#name-internationalization-and-ch"
class="xref">Internationalization and Character Encoding</a><a
href="#section-boilerplate.3-1.5.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.5.1"><a href="#section-5"
class="xref">5</a>. <a href="#name-internationalization-and-ch"
class="xref">Internationalization and Character Encoding</a><a
href="#section-boilerplate.3-1.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6">
- <p id="section-boilerplate.3-1.6.1"><a href="#section-6"
class="xref">6</a>. <a href="#name-name-resolution" class="xref">Name
Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.1"><a href="#section-6"
class="xref">6</a>. <a href="#name-name-resolution" class="xref">Name
Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.1">
- <p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1"
class="xref">6.1</a>. <a href="#name-entry-zone" class="xref">Entry Zone</a><a
href="#section-boilerplate.3-1.6.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1"
class="xref">6.1</a>. <a href="#name-entry-zone" class="xref">Entry Zone</a><a
href="#section-boilerplate.3-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.2">
- <p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2"
class="xref">6.2</a>. <a href="#name-record-retrieval" class="xref">Record
Retrieval</a><a href="#section-boilerplate.3-1.6.2.2.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2"
class="xref">6.2</a>. <a href="#name-record-retrieval" class="xref">Record
Retrieval</a><a href="#section-boilerplate.3-1.6.2.2.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3">
- <p id="section-boilerplate.3-1.6.2.3.1"><a href="#section-6.3"
class="xref">6.3</a>. <a href="#name-record-processing" class="xref">Record
Processing</a><a href="#section-boilerplate.3-1.6.2.3.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.1"><a href="#section-6.3"
class="xref">6.3</a>. <a href="#name-record-processing" class="xref">Record
Processing</a><a href="#section-boilerplate.3-1.6.2.3.1"
class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.1">
- <p id="section-boilerplate.3-1.6.2.3.2.1.1"><a
href="#section-6.3.1" class="xref">6.3.1</a>. <a href="#name-pkey-2"
class="xref">PKEY</a><a href="#section-boilerplate.3-1.6.2.3.2.1.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.2.1.1"><a
href="#section-6.3.1" class="xref">6.3.1</a>. <a href="#name-pkey-2"
class="xref">PKEY</a><a href="#section-boilerplate.3-1.6.2.3.2.1.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty"
id="section-boilerplate.3-1.6.2.3.2.2">
- <p id="section-boilerplate.3-1.6.2.3.2.2.1"><a
href="#section-6.3.2" class="xref">6.3.2</a>. <a href="#name-gns2dns-2"
class="xref">GNS2DNS</a><a href="#section-boilerplate.3-1.6.2.3.2.2.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.2.2.1"><a
href="#section-6.3.2" class="xref">6.3.2</a>. <a href="#name-gns2dns-2"
class="xref">GNS2DNS</a><a href="#section-boilerplate.3-1.6.2.3.2.2.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty"
id="section-boilerplate.3-1.6.2.3.2.3">
- <p id="section-boilerplate.3-1.6.2.3.2.3.1"><a
href="#section-6.3.3" class="xref">6.3.3</a>. <a href="#name-cname"
class="xref">CNAME</a><a href="#section-boilerplate.3-1.6.2.3.2.3.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.2.3.1"><a
href="#section-6.3.3" class="xref">6.3.3</a>. <a href="#name-cname"
class="xref">CNAME</a><a href="#section-boilerplate.3-1.6.2.3.2.3.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty"
id="section-boilerplate.3-1.6.2.3.2.4">
- <p id="section-boilerplate.3-1.6.2.3.2.4.1"><a
href="#section-6.3.4" class="xref">6.3.4</a>. <a href="#name-box-2"
class="xref">BOX</a><a href="#section-boilerplate.3-1.6.2.3.2.4.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.2.4.1"><a
href="#section-6.3.4" class="xref">6.3.4</a>. <a href="#name-box-2"
class="xref">BOX</a><a href="#section-boilerplate.3-1.6.2.3.2.4.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty"
id="section-boilerplate.3-1.6.2.3.2.5">
- <p id="section-boilerplate.3-1.6.2.3.2.5.1"><a
href="#section-6.3.5" class="xref">6.3.5</a>. <a href="#name-vpn-2"
class="xref">VPN</a><a href="#section-boilerplate.3-1.6.2.3.2.5.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.2.5.1"><a
href="#section-6.3.5" class="xref">6.3.5</a>. <a href="#name-vpn-2"
class="xref">VPN</a><a href="#section-boilerplate.3-1.6.2.3.2.5.1"
class="pilcrow">¶</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.7">
- <p id="section-boilerplate.3-1.7.1"><a href="#section-7"
class="xref">7</a>. <a href="#name-zone-revocation" class="xref">Zone
Revocation</a><a href="#section-boilerplate.3-1.7.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.7.1"><a href="#section-7"
class="xref">7</a>. <a href="#name-zone-revocation" class="xref">Zone
Revocation</a><a href="#section-boilerplate.3-1.7.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.8">
- <p id="section-boilerplate.3-1.8.1"><a href="#section-8"
class="xref">8</a>. <a href="#name-security-considerations"
class="xref">Security Considerations</a><a href="#section-boilerplate.3-1.8.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.8.1"><a href="#section-8"
class="xref">8</a>. <a href="#name-security-considerations"
class="xref">Security Considerations</a><a href="#section-boilerplate.3-1.8.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.9">
- <p id="section-boilerplate.3-1.9.1"><a href="#section-9"
class="xref">9</a>. <a href="#name-iana-considerations" class="xref">IANA
Considerations</a><a href="#section-boilerplate.3-1.9.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.9.1"><a href="#section-9"
class="xref">9</a>. <a href="#name-iana-considerations" class="xref">IANA
Considerations</a><a href="#section-boilerplate.3-1.9.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.10">
- <p id="section-boilerplate.3-1.10.1"><a href="#section-10"
class="xref">10</a>. <a href="#name-test-vectors" class="xref">Test
Vectors</a><a href="#section-boilerplate.3-1.10.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.10.1"><a href="#section-10"
class="xref">10</a>. <a href="#name-test-vectors" class="xref">Test
Vectors</a><a href="#section-boilerplate.3-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.11">
- <p id="section-boilerplate.3-1.11.1"><a href="#section-11"
class="xref">11</a>. <a href="#name-normative-references"
class="xref">Normative References</a><a href="#section-boilerplate.3-1.11.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.11.1"><a href="#section-11"
class="xref">11</a>. <a href="#name-normative-references"
class="xref">Normative References</a><a href="#section-boilerplate.3-1.11.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.12">
- <p id="section-boilerplate.3-1.12.1"><a href="#section-appendix.a"
class="xref"></a> <a href="#name-authors-addresses" class="xref">Authors'
Addresses</a><a href="#section-boilerplate.3-1.12.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.12.1"><a href="#section-appendix.a"
class="xref"></a> <a href="#name-authors-addresses" class="xref">Authors'
Addresses</a><a href="#section-boilerplate.3-1.12.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
@@ -1185,7 +1066,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
names. As the awareness of the central role DNS plays on the Internet
rises, various institutions are using their power (including legal
means)
to engage in attacks on the DNS, thus threatening the global
availability
- and integrity of information on the Internet.<a href="#section-1-1"
class="pilcrow">¶</a></p>
+ and integrity of information on the Internet.
+ <a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
DNS was not designed with security as a goal. This makes it very
vulnerable, especially to attackers that have the technical capabilities
@@ -1196,7 +1078,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
manipulation is encountered. GNS can bind names to any kind of
cryptographically secured token, enabling it to double in some respects
as
even as an alternative to some of today's Public Key Infrastructures, in
- particular X.509 for the Web.<a href="#section-1-2"
class="pilcrow">¶</a></p>
+ particular X.509 for the Web.
+ <a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
This document contains the GNU Name System (GNS) technical specification
of the GNU Name System (GNS), a fully decentralized and
censorship-resistant
@@ -1209,11 +1092,21 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
of providing a global, secure and memorable mapping without a trusted
authority. GNS uses the transitivity in the SDSI design to replace the
trusted root with secure delegation of authority thus making petnames
- useful to other users while operating under a very strong adversary
model.<a href="#section-1-3" class="pilcrow">¶</a></p>
+ useful to other users while operating under a very strong adversary
model.
+ <a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
This document defines the normative wire format of resource records,
resolution processes,
- cryptographic routines and security considerations for use by
implementors.<a href="#section-1-4" class="pilcrow">¶</a></p>
-<p id="section-1-5"><a href="#section-1-5" class="pilcrow">¶</a></p>
+ cryptographic routines and security considerations for use by
implementors.
+ <a href="#section-1-4" class="pilcrow">¶</a></p>
+<p id="section-1-5">
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described
+ in <span>[<a href="#RFC2119" class="xref">RFC2119</a>].
+ </span><a href="#section-1-5" class="pilcrow">¶</a></p>
+<p id="section-1-6">
+
+ <a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="zones">
@@ -1225,38 +1118,43 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
where d is the private key and zk the corresponding public key.
GNS employs the curve parameters of the twisted edwards representation
- of Curve25519 <span>[<a href="#RFC7748"
class="xref">RFC7748</a>]</span> (a.k.a. edwards25519)
- with the ECDSA scheme (<span>[<a href="#RFC6979"
class="xref">RFC6979</a>]</span>).
+ of Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]
(a.k.a. edwards25519)
+ with the ECDSA scheme (</span><span>[<a href="#RFC6979"
class="xref">RFC6979</a>]).
In the following, we use the following naming convention for our
- cryptographic primitives:<a href="#section-2-1"
class="pilcrow">¶</a></p>
+ cryptographic primitives:
+ </span><a href="#section-2-1" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-2-2">
<dt id="section-2-2.1">d</dt>
<dd id="section-2-2.2">
is a 256-bit ECDSA private key.
In GNS, records are signed using a key derived from "d" as described
in
- <a href="#publish" class="xref">Section 4</a>.<a
href="#section-2-2.2" class="pilcrow">¶</a>
-</dd>
+ <a href="#publish" class="xref">Section 4</a>.
+ </dd>
<dt id="section-2-2.3">p</dt>
<dd id="section-2-2.4">
- is the prime of edwards25519 as defined in <span>[<a href="#RFC7748"
class="xref">RFC7748</a>]</span>, i.e.
- 2^255 - 19.<a href="#section-2-2.4" class="pilcrow">¶</a>
+ is the prime of edwards25519 as defined in <span>[<a href="#RFC7748"
class="xref">RFC7748</a>], i.e.
+ 2^255 - 19.
+ </span>
</dd>
<dt id="section-2-2.5">B</dt>
<dd id="section-2-2.6">
is the group generator (X(P),Y(P)) of edwards25519 as defined in
- <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a
href="#section-2-2.6" class="pilcrow">¶</a>
+ <span>[<a href="#RFC7748" class="xref">RFC7748</a>].
+ </span>
</dd>
<dt id="section-2-2.7">L</dt>
<dd id="section-2-2.8">
- is the prime-order subgroup of edwards25519 in <span>[<a
href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.8"
class="pilcrow">¶</a>
+ is the prime-order subgroup of edwards25519 in <span>[<a
href="#RFC7748" class="xref">RFC7748</a>].
+ </span>
</dd>
<dt id="section-2-2.9">zk</dt>
<dd id="section-2-2.10">
is the ECDSA public key corresponding to d. It is defined in
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> as the
curve point d*B where B is the group
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>] as the curve
point d*B where B is the group
generator of the elliptic curve.
The public key is used to uniquely identify a GNS zone and is
referred to
- as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
+ as the "zone key".
+ </span>
</dd>
</dl>
</section>
@@ -1272,10 +1170,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
key pair. Records may be added to each zone, hence a (local) persistency
mechanism for resource records and zones must be provided.
This local zone database is used by the GNS resolver implementation
- and to publish record information.<a href="#section-3-1"
class="pilcrow">¶</a></p>
+ and to publish record information.
+ <a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
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-2"
class="pilcrow">¶</a></p>
+ The resource record format is defined as follows:
+ <a href="#section-3-2" class="pilcrow">¶</a></p>
<div id="figure_gnsrecord">
<figure id="figure-1">
<div class="artwork art-text alignLeft" id="section-3-3.1">
@@ -1292,7 +1192,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
/ /
</pre>
</div>
-<figcaption><a href="#figure-1" class="selfRef">Figure
1</a></figcaption></figure>
+<figcaption><a href="#figure-1">Figure 1</a></figcaption></figure>
</div>
<p id="section-3-4">where:<a href="#section-3-4" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-5">
@@ -1300,32 +1200,33 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dd id="section-3-5.2">
denotes the absolute 64-bit expiration date of the record.
In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-3-5.2" class="pilcrow">¶</a>
-</dd>
+ byte order.
+ </dd>
<dt id="section-3-5.3">DATA SIZE</dt>
<dd id="section-3-5.4">
denotes the 32-bit size of the DATA field in bytes and in network byte
- order.<a href="#section-3-5.4" class="pilcrow">¶</a>
-</dd>
+ order.
+ </dd>
<dt id="section-3-5.5">TYPE</dt>
<dd id="section-3-5.6">
is the 32-bit resource record type. This type can be one of the GNS
resource
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
+ type as defined in <span>[<a href="#RFC1035"
class="xref">RFC1035</a>] or any of the
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 (<span>[<a
href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-5.6"
class="pilcrow">¶</a>
+ below 2^16 are reserved for allocation via IANA (</span><span>[<a
href="#RFC6895" class="xref">RFC6895</a>]).
+ </span>
</dd>
<dt id="section-3-5.7">FLAGS</dt>
<dd id="section-3-5.8">
- is a 32-bit resource record flags field (see below).<a
href="#section-3-5.8" class="pilcrow">¶</a>
-</dd>
+ is a 32-bit resource record flags field (see below).
+ </dd>
<dt id="section-3-5.9">DATA</dt>
<dd id="section-3-5.10">
the variable-length resource record data payload. The contents are
defined
by the
- respective type of the resource record.<a href="#section-3-5.10"
class="pilcrow">¶</a>
-</dd>
+ respective type of the resource record.
+ </dd>
</dl>
<p id="section-3-6">
Flags indicate metadata surrounding the resource record. A flag
@@ -1342,10 +1243,11 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
------+--------+--------+--------+--------+--------+
</pre>
</div>
-<figcaption><a href="#figure-2" class="selfRef">Figure
2</a></figcaption></figure>
+<figcaption><a href="#figure-2">Figure 2</a></figcaption></figure>
</div>
<p id="section-3-8">
- where:<a href="#section-3-8" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3-8" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-9">
<dt id="section-3-9.1">SHADOW</dt>
<dd id="section-3-9.2">
@@ -1353,23 +1255,23 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
records of the same record type have expired. Used to allow zone
publishers to
facilitate good performance when records change by allowing them to
put future
values of records into the DHT. This way, future values can propagate
and may be
- cached before the transition becomes active.<a href="#section-3-9.2"
class="pilcrow">¶</a>
-</dd>
+ cached before the transition becomes active.
+ </dd>
<dt id="section-3-9.3">EXPREL</dt>
<dd id="section-3-9.4">
The expiration time value of the record is a relative time (still in
microseconds)
and not an absolute time. This flag should never be encountered by a
resolver
for records obtained from the DHT, but might be present when a
resolver looks up
- private records of a zone hosted locally.<a href="#section-3-9.4"
class="pilcrow">¶</a>
-</dd>
+ private records of a zone hosted locally.
+ </dd>
<dt id="section-3-9.5">PRIVATE</dt>
<dd id="section-3-9.6">
This is a private record of this peer and it should thus not be
published in the DHT. Thus, this flag should never be encountered by
a resolver for records obtained from the DHT.
Private records should still be considered just like
- regular records when resolving labels in local zones.<a
href="#section-3-9.6" class="pilcrow">¶</a>
-</dd>
+ regular records when resolving labels in local zones.
+ </dd>
</dl>
<div id="gnsrecords_numbers">
<section id="section-3.1">
@@ -1379,7 +1281,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-3.1-1">
GNS-specific record type numbers start at 2^16, i.e. after the record
type numbers for DNS. The following is a list of defined and reserved
- record types in GNS:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+ record types in GNS:
+ <a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="figure_rrtypenums">
<figure id="figure-3">
<div class="artwork art-text alignLeft" id="section-3.1-2.1">
@@ -1396,7 +1299,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
2^24 up to 2^32 - 1 | - | Unassigned / For private
use
</pre>
</div>
-<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
+<figcaption><a href="#figure-3">Figure 3</a></figcaption></figure>
</div>
</section>
</div>
@@ -1422,15 +1325,16 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
+<figcaption><a href="#figure-4">Figure 4</a></figcaption></figure>
</div>
<p id="section-3.2-3">
- where:<a href="#section-3.2-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.2-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.2-4">
<dt id="section-3.2-4.1">PUBLIC KEY</dt>
<dd id="section-3.2-4.2">
- A 256-bit ECDSA zone key.<a href="#section-3.2-4.2"
class="pilcrow">¶</a>
-</dd>
+ A 256-bit ECDSA zone key.
+ </dd>
</dl>
</section>
</div>
@@ -1442,8 +1346,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-3.3-1">It is possible to delegate a label back into DNS through
a GNS2DNS record.
The resource record contains a DNS name for the resolver to continue
with
in DNS followed by a DNS server. Both names are in the format defined
in
- <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS
names.
- A GNS2DNS DATA entry has the following format:<a
href="#section-3.3-1" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC1034" class="xref">RFC1034</a>] for DNS names.
+ A GNS2DNS DATA entry has the following format:</span><a
href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-3.3-2.1">
@@ -1462,21 +1366,22 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
+<figcaption><a href="#figure-5">Figure 5</a></figcaption></figure>
</div>
<p id="section-3.3-3">
- where:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3-4">
<dt id="section-3.3-4.1">DNS NAME</dt>
<dd id="section-3.3-4.2">
- The name to continue with in DNS (0-terminated).<a
href="#section-3.3-4.2" class="pilcrow">¶</a>
-</dd>
+ The name to continue with in DNS (0-terminated).
+ </dd>
<dt id="section-3.3-4.3">DNS SERVER NAME</dt>
<dd id="section-3.3-4.4">
The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
form or a DNS name. It may also be a relative GNS name ending with a
- "+" top-level domain. (all 0-terminated)<a href="#section-3.3-4.4"
class="pilcrow">¶</a>
-</dd>
+ "+" top-level domain. (all 0-terminated)
+ </dd>
</dl>
</section>
</div>
@@ -1506,20 +1411,22 @@ 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-6">Figure 6</a></figcaption></figure>
</div>
<p id="section-3.4-3">
- where:<a href="#section-3.4-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.4-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.4-4">
<dt id="section-3.4-4.1">LEGACY HOSTNAME</dt>
<dd id="section-3.4-4.2">
- A UTF-8 string (which is not 0-terminated) representing the legacy
hostname.<a href="#section-3.4-4.2" class="pilcrow">¶</a>
-</dd>
+ A UTF-8 string (which is not 0-terminated) representing the legacy
hostname.
+ </dd>
</dl>
<p id="section-3.4-5">
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to a punycode
representation
- <span>[<a href="#RFC5891" class="xref">RFC5891</a>]</span>.<a
href="#section-3.4-5" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC5891" class="xref">RFC5891</a>].
+ </span><a href="#section-3.4-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gnsrecords_nick">
@@ -1533,7 +1440,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
PKEY <a href="#gnsrecords_pkey" class="xref">Section 3.2</a> record
containing this zone's
public zone key.
This record SHOULD only be stored under the empty label "@".
- A NICK DATA entry has the following format:<a href="#section-3.5-1"
class="pilcrow">¶</a></p>
+ A NICK DATA entry has the following format:
+ <a href="#section-3.5-1" class="pilcrow">¶</a></p>
<div id="figure_nickrecord">
<figure id="figure-7">
<div class="artwork art-text alignLeft" id="section-3.5-2.1">
@@ -1547,16 +1455,17 @@ 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-7">Figure 7</a></figcaption></figure>
</div>
<p id="section-3.5-3">
- where:<a href="#section-3.5-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.5-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.5-4">
<dt id="section-3.5-4.1">NICKNAME</dt>
<dd id="section-3.5-4.2">
A UTF-8 string (which is not 0-terminated) representing the
preferred
- label of the zone. This string MUST NOT inlcude a "." character.<a
href="#section-3.5-4.2" class="pilcrow">¶</a>
-</dd>
+ label of the zone. This string MUST NOT inlcude a "." character.
+ </dd>
</dl>
</section>
</div>
@@ -1576,8 +1485,9 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
TLSA record for "_https._tcp.foo.gnu" will be stored in the record
set of
"foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol
(PROTO) 6
(tcp) and record_type "TLSA".
- For reference, see also <span>[<a href="#RFC2782"
class="xref">RFC2782</a>]</span>
- A BOX DATA entry has the following format:<a href="#section-3.6-1"
class="pilcrow">¶</a></p>
+ For reference, see also <span>[<a href="#RFC2782"
class="xref">RFC2782</a>]
+ A BOX DATA entry has the following format:
+ </span><a href="#section-3.6-1" class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-3.6-2.1">
@@ -1593,29 +1503,30 @@ 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-8">Figure 8</a></figcaption></figure>
</div>
<p id="section-3.6-3">
- where:<a href="#section-3.6-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.6-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.6-4">
<dt id="section-3.6-4.1">PROTO</dt>
<dd id="section-3.6-4.2">
- the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.<a href="#section-3.6-4.2" class="pilcrow">¶</a>
-</dd>
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
+ </dd>
<dt id="section-3.6-4.3">SVC</dt>
<dd id="section-3.6-4.4">
the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.<a href="#section-3.6-4.4"
class="pilcrow">¶</a>
-</dd>
+ In network byte order.
+ </dd>
<dt id="section-3.6-4.5">TYPE</dt>
<dd id="section-3.6-4.6">
- is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.6-4.6" class="pilcrow">¶</a>
-</dd>
+ is the 32-bit record type of the boxed record. In network byte
order.
+ </dd>
<dt id="section-3.6-4.7">RECORD DATA</dt>
<dd id="section-3.6-4.8">
is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.<a href="#section-3.6-4.8"
class="pilcrow">¶</a>
-</dd>
+ defined for the respective TYPE in DNS.
+ </dd>
</dl>
</section>
</div>
@@ -1644,7 +1555,7 @@ 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-9">Figure 9</a></figcaption></figure>
</div>
</section>
</div>
@@ -1662,14 +1573,16 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
encrypted and published together in a single resource records block
(RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
The key "q" which is derived from the zone key "zk" and the respective
- label of the contained records.<a href="#section-4-1"
class="pilcrow">¶</a></p>
+ label of the contained records.
+ <a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="blinding">
<section id="section-4.1">
<h3 id="name-key-derivations">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a
href="#name-key-derivations" class="section-name selfRef">Key Derivations</a>
</h3>
<p id="section-4.1-1">
- Given a label, the DHT key "q" is derived as follows:<a
href="#section-4.1-1" class="pilcrow">¶</a></p>
+ Given a label, the DHT key "q" is derived as follows:
+ <a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-2">
<pre>
PRK_h := HKDF-Extract ("key-derivation", zk)
@@ -1677,57 +1590,60 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
d_h := h * d mod L
zk_h := h mod L * zk
q := SHA512 (zk_h)
- </pre><a href="#section-4.1-2" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-4.1-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.<a
href="#section-4.1-3" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]. We use
HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ </span><a href="#section-4.1-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.1-4">
<dt id="section-4.1-4.1">PRK_h</dt>
<dd id="section-4.1-4.2">
is key material retrieved using an HKDF using the string
"key-derivation" as salt and the public zone key "zk" as initial
- keying material.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
-</dd>
+ keying material.
+ </dd>
<dt id="section-4.1-4.3">h</dt>
<dd id="section-4.1-4.4">
is the 512-bit HKDF expansion result. The expansion info input is a
- concatenation of the label and string "gns".<a
href="#section-4.1-4.4" class="pilcrow">¶</a>
-</dd>
+ concatenation of the label and string "gns".
+ </dd>
<dt id="section-4.1-4.5">d</dt>
<dd id="section-4.1-4.6">
- is the 256-bit private zone key as defined in <a href="#zones"
class="xref">Section 2</a>.<a href="#section-4.1-4.6" class="pilcrow">¶</a>
-</dd>
+ is the 256-bit private zone key as defined in <a href="#zones"
class="xref">Section 2</a>.
+ </dd>
<dt id="section-4.1-4.7">label</dt>
<dd id="section-4.1-4.8">
- is a UTF-8 string under which the resource records are published.<a
href="#section-4.1-4.8" class="pilcrow">¶</a>
-</dd>
+ is a UTF-8 string under which the resource records are published.
+ </dd>
<dt id="section-4.1-4.9">d_h</dt>
<dd id="section-4.1-4.10">
is a 256-bit private key derived from the "d" using the
- keying material "h".<a href="#section-4.1-4.10"
class="pilcrow">¶</a>
-</dd>
+ keying material "h".
+ </dd>
<dt id="section-4.1-4.11">zk_h</dt>
<dd id="section-4.1-4.12">
is a 256-bit public key derived from the zone key "zk" using the
- keying material "h".<a href="#section-4.1-4.12"
class="pilcrow">¶</a>
-</dd>
+ keying material "h".
+ </dd>
<dt id="section-4.1-4.13">L</dt>
<dd id="section-4.1-4.14">
- is the prime-order subgroup as defined in <a href="#zones"
class="xref">Section 2</a>.<a href="#section-4.1-4.14" class="pilcrow">¶</a>
-</dd>
+ is the prime-order subgroup as defined in <a href="#zones"
class="xref">Section 2</a>.
+ </dd>
<dt id="section-4.1-4.15">q</dt>
<dd id="section-4.1-4.16">
Is the 512-bit 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 "d_h".<a href="#section-4.1-4.16"
class="pilcrow">¶</a>
-</dd>
+ derived private key "d_h".
+ </dd>
</dl>
<p id="section-4.1-5">
We point out that the multiplication of "zk" with "h" is a point
multiplication,
- while the multiplication of "d" with "h" is a scalar
multiplication.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
+ while the multiplication of "d" with "h" is a scalar multiplication.
+ <a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="wire">
@@ -1743,7 +1659,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
A GNS implementation must publish RRBLOCKs
in accordance to the properties and recommendations of the underlying
DHT. This may include a periodic refresh publication.
- A GNS RRBLOCK has the following format:<a href="#section-4.2-1"
class="pilcrow">¶</a></p>
+ A GNS RRBLOCK has the following format:
+ <a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
@@ -1774,23 +1691,24 @@ 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-10">Figure 10</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
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]. The signature
is computed over the data
following the PUBLIC KEY field.
The signature is created using the derived private key "d_h" (see
- <a href="#publish" class="xref">Section 4</a>).<a
href="#section-4.2-4.2" class="pilcrow">¶</a>
-</dd>
+ </span><a href="#publish" class="xref">Section 4</a>).
+ </dd>
<dt id="section-4.2-4.3">PUBLIC KEY</dt>
<dd id="section-4.2-4.4">
is the 256-bit 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>
+ wire format of this value is defined in <span>[<a href="#RFC8032"
class="xref">RFC8032</a>],
+ Section 5.1.5.
+ </span>
</dd>
<dt id="section-4.2-4.5">SIZE</dt>
<dd id="section-4.2-4.6">
@@ -1800,13 +1718,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
addition to the length of the BDATA. While a 32-bit value is used,
implementations MAY refuse to publish blocks beyond a certain
size significantly below 4 GB. However, a minimum block size of
- 62 kilobytes MUST be supported.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
-</dd>
+ 62 kilobytes MUST be supported.
+ </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>
-</dd>
+ byte order).
+ </dd>
<dt id="section-4.2-4.9">EXPIRATION</dt>
<dd id="section-4.2-4.10">
Specifies when the RRBLOCK expires and the encrypted block
@@ -1819,12 +1737,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
expiration time of all shadow records with matching type and the
expiration times of the non-shadow records is considered.
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>
+ (0 hour), January 1, 1970 in network byte order.
+ </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 SIZE - 16.<a
href="#section-4.2-4.12" class="pilcrow">¶</a>
-</dd>
+ The encrypted resource records with a total size of SIZE - 16.
+ </dd>
</dl>
</section>
</div>
@@ -1835,7 +1753,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-4.3-1">
A symmetric encryption scheme is used to encrypt the resource records
set RDATA into the BDATA field of a GNS RRBLOCK.
- The wire format of the RDATA looks as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
+ 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-11">
<div class="artwork art-text alignLeft" id="section-4.3-2.1">
@@ -1865,7 +1784,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
/ /
</pre>
</div>
-<figcaption><a href="#figure-11" class="selfRef">Figure
11</a></figcaption></figure>
+<figcaption><a href="#figure-11">Figure 11</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">
@@ -1873,15 +1792,15 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dd id="section-4.3-4.2">
A 32-bit value containing the number of variable-length resource
records which are
- following after this field in network byte order.<a
href="#section-4.3-4.2" class="pilcrow">¶</a>
-</dd>
+ following after this field in network byte order.
+ </dd>
<dt id="section-4.3-4.3">EXPIRATION, DATA SIZE, TYPE, FLAGS and
DATA</dt>
<dd id="section-4.3-4.4">
These fields were defined
in the resource record format in <a href="#rrecords"
class="xref">Section 3</a>.
There MUST be a total of RR COUNT of these resource records
- present.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
-</dd>
+ present.
+ </dd>
<dt id="section-4.3-4.5">PADDING</dt>
<dd id="section-4.3-4.6">
The padding MUST contain the value 0 in all octets.
@@ -1889,31 +1808,34 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
COUNT field is a power of two.
As a special exception, record sets with (only) a PKEY record type
are never padded. Note that a record set with a PKEY record MUST NOT
- contain other records.<a href="#section-4.3-4.6"
class="pilcrow">¶</a>
-</dd>
+ contain other records.
+ </dd>
</dl>
<p id="section-4.3-5">
The symmetric keys and initialization vectors are derived from the
record label and the zone key "zk". For decryption of the resource
records block payload, the key material "K" and initialization vector
- "IV" for the symmetric cipher are derived as follows:<a
href="#section-4.3-5" class="pilcrow">¶</a></p>
+ "IV" for the symmetric cipher are derived as follows:
+ <a href="#section-4.3-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-6">
<pre>
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- </pre><a href="#section-4.3-6" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-4.3-6" class="pilcrow">¶</a>
</div>
<p id="section-4.3-7">
HKDF is a hash-based key derivation function as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>.
Specifically, HMAC-SHA512 is used for the
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]. Specifically,
HMAC-SHA512 is used 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 vectors.
We divide the resulting keying material "K" into a 256-bit AES
- <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-7"
class="pilcrow">¶</a></p>
+ </span><span>[<a href="#RFC3826" class="xref">RFC3826</a>] key
+ and a 256-bit TWOFISH </span><span>[<a href="#TWOFISH"
class="xref">TWOFISH</a>] key:
+ </span><a href="#section-4.3-7" class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
<figure id="figure-12">
<div class="artwork art-text alignLeft" id="section-4.3-8.1">
@@ -1932,11 +1854,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-12" class="selfRef">Figure
12</a></figcaption></figure>
+<figcaption><a href="#figure-12">Figure 12</a></figcaption></figure>
</div>
<p id="section-4.3-9">
Similarly, we divide "IV" into a 128-bit initialization vector
- and a 128-bit initialization vector:<a href="#section-4.3-9"
class="pilcrow">¶</a></p>
+ and a 128-bit initialization vector:
+ <a href="#section-4.3-9" class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
<figure id="figure-13">
<div class="artwork art-text alignLeft" id="section-4.3-10.1">
@@ -1951,17 +1874,19 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-13" class="selfRef">Figure
13</a></figcaption></figure>
+<figcaption><a href="#figure-13">Figure 13</a></figcaption></figure>
</div>
<p id="section-4.3-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 (CFB) mode <span>[<a href="#RFC3826"
class="xref">RFC3826</a>]</span>.<a href="#section-4.3-11"
class="pilcrow">¶</a></p>
+ Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826"
class="xref">RFC3826</a>].
+ </span><a href="#section-4.3-11" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-12">
<pre>
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
- </pre><a href="#section-4.3-12" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-4.3-12" class="pilcrow">¶</a>
</div>
</section>
</section>
@@ -1972,10 +1897,11 @@ 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">
- All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629"
class="xref">RFC3629</a>]</span>.
+ All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629"
class="xref">RFC3629</a>].
This does not include any DNS names found in DNS records, such as CNAME
records, which are internationalized through the IDNA specifications
- <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span>.<a
href="#section-5-1" class="pilcrow">¶</a></p>
+ </span><span>[<a href="#RFC5890" class="xref">RFC5890</a>].
+ </span><a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="resolution">
@@ -1984,7 +1910,8 @@ 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-name-resolution" class="section-name selfRef">Name Resolution</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>
<div id="entry_zone">
<section id="section-6.1">
<h3 id="name-entry-zone">
@@ -1992,7 +1919,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h3>
<p id="section-6.1-1">
There are three sources from which the entry zone can be determined
- which MUST be queried in this order:<a href="#section-6.1-1"
class="pilcrow">¶</a></p>
+ which MUST be queried in this order:
+ <a href="#section-6.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-6.1-2">
<li id="section-6.1-2.1">Check if top-level domain maps to a local
zone key.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
</li>
@@ -2004,18 +1932,21 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</ol>
<p id="section-6.1-3">
If the TLD is a Base32-encoded public zone key "zk", the entry
- zone of the resolution process is implicitly given by the name.<a
href="#section-6.1-3" class="pilcrow">¶</a></p>
+ zone of the resolution process is implicitly given by the name.
+ <a href="#section-6.1-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-6.1-4">
<pre>
Example name: www.example.<Base32(zk)>
=> Entry zone: zk
=> Name to resolve from entry zone: www.example
- </pre><a href="#section-6.1-4" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-6.1-4" class="pilcrow">¶</a>
</div>
<p id="section-6.1-5">
Each local zone is associated with a single GNS label. If this label
is the top-level domain (TLD) of the name to resolve, resolution
- MUST start from this local zone.<a href="#section-6.1-5"
class="pilcrow">¶</a></p>
+ MUST start from this local zone.
+ <a href="#section-6.1-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-6.1-6">
<pre>
Example name: www.example.gnu
@@ -2026,7 +1957,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www.example
- </pre><a href="#section-6.1-6" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-6.1-6" class="pilcrow">¶</a>
</div>
<p id="section-6.1-7">
If no matching local zone for the TLD is found, external prefix to
@@ -2036,7 +1968,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
The prefix may consist of multiple GNS labels concatenated with a
".". If multiple prefixes match the name to resolve, the longest
prefix is chosen. The prefix length of two results cannot be equal,
- as this would indicate a misconfiguration.<a href="#section-6.1-7"
class="pilcrow">¶</a></p>
+ as this would indicate a misconfiguration.
+ <a href="#section-6.1-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-6.1-8">
<pre>
Example name: www.example.gnu
@@ -2047,7 +1980,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www
- </pre><a href="#section-6.1-8" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-6.1-8" class="pilcrow">¶</a>
</div>
</section>
</div>
@@ -2059,12 +1993,14 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-6.2-1">
In order to resolve a name in GNS, a type MAY be given.
However, filtering of record results according to type is done after
- the resource record set is retrieved.<a href="#section-6.2-1"
class="pilcrow">¶</a></p>
+ the resource record set is retrieved.
+ <a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">
In each step of the recursive name resolution, there is an
authoritative zone zk and a name to resolve which may be empty.
Initially, the authoritative zone is the entry zone. If the name
- is empty, it is interpreted as the apex label "@".<a
href="#section-6.2-2" class="pilcrow">¶</a></p>
+ is empty, it is interpreted as the apex label "@".
+ <a href="#section-6.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-6.2-3">
<li id="section-6.2-3.1">Extract the right-most label from the name
to look up.<a href="#section-6.2-3.1" class="pilcrow">¶</a>
</li>
@@ -2080,7 +2016,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
provided signature, the resolver MUST check that the authoritative
zone key was used to sign the record:
The derived zone key "h*zk" must match the public key provided in
- the RRBLOCK.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
+ the RRBLOCK.
+ <a href="#section-6.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="record_processing">
@@ -2093,17 +2030,20 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
result MUST consist of a single PKEY record or one or more GNS2DNS
records.
The recursion is then continued with the PKEY record value as new
authoritative zone or using the specified DNS server(s) as defined
- int the following.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
+ int the following.
+ <a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
If the remainder of the name to resolve is empty but we have
received
a record set containing only a single PKEY record, the recursion is
continued with the PKEY as authoritative zone and the empty apex
label "@" as remaining name. If the record type to be resolved is
- PKEY, the PKEY record set is returned and the resolution is
concluded.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
+ PKEY, the PKEY record set is returned and the resolution is
concluded.
+ <a href="#section-6.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3-3">
If the remainder of the name to resolve is empty and the records set
does not consist of a PKEY record, the record set is the result and
- the resolution is concluded.<a href="#section-6.3-3"
class="pilcrow">¶</a></p>
+ the resolution is concluded.
+ <a href="#section-6.3-3" class="pilcrow">¶</a></p>
<div id="pkey_processing">
<section id="section-6.3.1">
<h4 id="name-pkey-2">
@@ -2112,7 +2052,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-6.3.1-1">
When a resolver encounters a PKEY record, resolution continues
recursively with the remainder of the name in the newly discovered
- GNS zone as defined in <a href="#entry_zone" class="xref">Section
6.1</a>.<a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
+ GNS zone as defined in <a href="#entry_zone" class="xref">Section
6.1</a>.
+ <a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gns2dns_processing">
@@ -2134,7 +2075,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
Multiple
GNS2DNS records may be stored under the same label, in which case
the
resolver MUST try all of them. However, if multiple GNS2DNS
records
- are present, the DNS name MUST be identical for all of them.<a
href="#section-6.3.2-1" class="pilcrow">¶</a></p>
+ are present, the DNS name MUST be identical for all of them.
+ <a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cname_processing">
@@ -2150,13 +2092,15 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
the respective TLD or if the TLD is a relative zone indicator
("+")
and we have found the CNAME in a GNS zone.
Otherwise, the resolver should continue the resolution recursively
- through DNS.<a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
+ through DNS.
+ <a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3.3-2">
The recursive DNS resolution process may yield a CNAME as well
which in turn may either point into the DNS or GNS namespace.
In order to prevent infinite loops, the resolver should
implement loop detections or limit the recursive resolution of
- CNAMEs using an upper bound.<a href="#section-6.3.3-2"
class="pilcrow">¶</a></p>
+ CNAMEs using an upper bound.
+ <a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="box_processing">
@@ -2169,7 +2113,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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 separate network request, and TLSA
- records become inseparable from the corresponding address
records.<a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
+ records become inseparable from the corresponding address records.
+ <a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="vpn_processing">
@@ -2183,7 +2128,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
tunnel and return the IPv4 or IPv6 tunnel address, respectively.
The type of tunnel depends on the contents of the VPN record data.
No result is returned if the resolver implementation does not
- support any of the tunnnels provided in the VPN records.<a
href="#section-6.3.5-1" class="pilcrow">¶</a></p>
+ support any of the tunnnels provided in the VPN records.
+ <a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
@@ -2200,9 +2146,11 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
This object must be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
flooding attacks, the revocation message must contain a proof-of-work.
- The revocation message may be calculated ahead of time.<a
href="#section-7-1" class="pilcrow">¶</a></p>
+ The revocation message may be calculated ahead of time.
+ <a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
- A revocation message is defined as follows:<a href="#section-7-2"
class="pilcrow">¶</a></p>
+ A revocation message is defined as follows:
+ <a href="#section-7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
@@ -2211,7 +2159,8 @@ 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-security-considerations" class="section-name selfRef">Security
Considerations</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">
@@ -2220,7 +2169,8 @@ 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">
@@ -2229,7 +2179,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h2>
<p id="section-10-1">
The following represents a test vector for a record of type MX with
- a priority of 10 and the mail hostname mail.example.com.<a
href="#section-10-1" class="pilcrow">¶</a></p>
+ a priority of 10 and the mail hostname mail.example.com.
+ <a href="#section-10-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-10-2">
<pre>
label := "mail"
@@ -2328,56 +2279,67 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
642920eee8e7a65a
001fd19a6406a721
713f0a0d
- </pre><a href="#section-10-2" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-10-2" class="pilcrow">¶</a>
</div>
</section>
<section id="section-11">
<h2 id="name-normative-references">
-<a href="#section-11" class="section-number selfRef">11. </a><a
href="#name-normative-references" class="section-name selfRef">Normative
References</a>
+<a href="#name-normative-references" class="section-name selfRef">Normative
References</a>
</h2>
<dl class="references">
<dt id="RFC1034">[RFC1034]</dt>
<dd>
-<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain
names - concepts and facilities"</span>, <span class="seriesInfo">STD
13</span>, <span class="seriesInfo">RFC 1034</span>, <span
class="seriesInfo">DOI 10.17487/RFC1034</span>, <time
datetime="1987-11">November 1987</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc1034";>https://www.rfc-editor.org/info/rfc1034</a>></span>.
</dd>
+<span class="refAuthor">Mockapetris, P.V.</span>, <span
class="refTitle">"Domain names - concepts and facilities"</span>, <span
class="seriesInfo">STD13</span>, <span class="seriesInfo">RFC1034</span>, <span
class="seriesInfo">DOI10.17487/RFC1034</span>, <time
datetime="1987-11">November 1987</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc1034";>https://www.rfc-editor.org/info/rfc1034</a>></span>.
</dd>
<dt id="RFC1035">[RFC1035]</dt>
<dd>
-<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain
names - implementation and specification"</span>, <span class="seriesInfo">STD
13</span>, <span class="seriesInfo">RFC 1035</span>, <span
class="seriesInfo">DOI 10.17487/RFC1035</span>, <time
datetime="1987-11">November 1987</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc1035";>https://www.rfc-editor.org/info/rfc1035</a>></span>.
</dd>
+<span class="refAuthor">Mockapetris, P.V.</span>, <span
class="refTitle">"Domain names - implementation and specification"</span>,
<span class="seriesInfo">STD13</span>, <span class="seriesInfo">RFC1035</span>,
<span class="seriesInfo">DOI10.17487/RFC1035</span>, <time
datetime="1987-11">November 1987</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc1035";>https://www.rfc-editor.org/info/rfc1035</a>></span>.
</dd>
+<dt id="RFC2119">[RFC2119]</dt>
+ <dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words
for use in RFCs to Indicate Requirement Levels"</span>, <span
class="seriesInfo">BCP14</span>, <span class="seriesInfo">RFC2119</span>, <span
class="seriesInfo">DOI10.17487/RFC2119</span>, <time datetime="1997-03">March
1997</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc2119";>https://www.rfc-editor.org/info/rfc2119</a>></span>.
</dd>
<dt id="RFC2782">[RFC2782]</dt>
<dd>
-<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie,
P.</span><span class="refAuthor">, and L. Esibov</span>, <span
class="refTitle">"
- A DNS RR for specifying the location of services (DNS SRV)
- "</span>, <span class="seriesInfo">RFC 2782</span>, <span
class="seriesInfo">DOI 10.17487/RFC2782</span>, <time
datetime="2000-02">February 2000</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc2782";>https://www.rfc-editor.org/info/rfc2782</a>></span>.
</dd>
+<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie,
P.</span><span class="refAuthor">, and L. Esibov</span>, <span
class="refTitle">"A DNS RR for specifying the location of services (DNS
SRV)"</span>, <span class="seriesInfo">RFC2782</span>, <span
class="seriesInfo">DOI10.17487/RFC2782</span>, <time
datetime="2000-02">February 2000</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc2782";>https://www.rfc-editor.org/info/rfc2782</a>></span>.
</dd>
<dt id="RFC3629">[RFC3629]</dt>
<dd>
-<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a
transformation format of ISO 10646"</span>, <span class="seriesInfo">STD
63</span>, <span class="seriesInfo">RFC 3629</span>, <span
class="seriesInfo">DOI 10.17487/RFC3629</span>, <time
datetime="2003-11">November 2003</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc3629";>https://www.rfc-editor.org/info/rfc3629</a>></span>.
</dd>
+<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a
transformation format of ISO 10646"</span>, <span
class="seriesInfo">STD63</span>, <span class="seriesInfo">RFC3629</span>, <span
class="seriesInfo">DOI10.17487/RFC3629</span>, <time
datetime="2003-11">November 2003</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc3629";>https://www.rfc-editor.org/info/rfc3629</a>></span>.
</dd>
<dt id="RFC3826">[RFC3826]</dt>
<dd>
-<span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino,
F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span
class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in
the SNMP User-based Security Model"</span>, <span class="seriesInfo">RFC
3826</span>, <span class="seriesInfo">DOI 10.17487/RFC3826</span>, <time
datetime="2004-06">June 2004</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc3826";>https://www.rfc-editor.org/ [...]
+<span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino,
F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span
class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in
the SNMP User-based Security Model"</span>, <span
class="seriesInfo">RFC3826</span>, <span
class="seriesInfo">DOI10.17487/RFC3826</span>, <time datetime="2004-06">June
2004</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc3826";>https://www.rfc-editor.org/info/rfc3826</a>></span>.
</dd>
<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)
- "</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>
+<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)"</span>, <span class="seriesInfo">RFC5869</span>,
<span class="seriesInfo">DOI10.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="RFC5890">[RFC5890]</dt>
<dd>
-<span class="refAuthor">Klensin, J.</span>, <span
class="refTitle">"Internationalized Domain Names for Applications (IDNA):
Definitions and Document Framework"</span>, <span class="seriesInfo">RFC
5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time
datetime="2010-08">August 2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5890";>https://www.rfc-editor.org/info/rfc5890</a>></span>.
</dd>
+<span class="refAuthor">Klensin, J.</span>, <span
class="refTitle">"Internationalized Domain Names for Applications (IDNA):
Definitions and Document Framework"</span>, <span
class="seriesInfo">RFC5890</span>, <span
class="seriesInfo">DOI10.17487/RFC5890</span>, <time datetime="2010-08">August
2010</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc5890";>https://www.rfc-editor.org/info/rfc5890</a>></span>.
</dd>
<dt id="RFC5891">[RFC5891]</dt>
<dd>
-<span class="refAuthor">Klensin, J.</span>, <span
class="refTitle">"Internationalized Domain Names in Applications (IDNA):
Protocol"</span>, <span class="seriesInfo">RFC 5891</span>, <span
class="seriesInfo">DOI 10.17487/RFC5891</span>, <time datetime="2010-08">August
2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5891";>https://www.rfc-editor.org/info/rfc5891</a>></span>.
</dd>
+<span class="refAuthor">Klensin, J.</span>, <span
class="refTitle">"Internationalized Domain Names in Applications (IDNA):
Protocol"</span>, <span class="seriesInfo">RFC5891</span>, <span
class="seriesInfo">DOI10.17487/RFC5891</span>, <time datetime="2010-08">August
2010</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc5891";>https://www.rfc-editor.org/info/rfc5891</a>></span>.
</dd>
<dt id="RFC6895">[RFC6895]</dt>
<dd>
-<span class="refAuthor">Eastlake 3rd, D.</span>, <span
class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span
class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>,
<span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time
datetime="2013-04">April 2013</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc6895";>https://www.rfc-editor.org/info/rfc6895</a>></span>.
</dd>
+<span class="refAuthor">Eastlake 3rd, D.</span>, <span
class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span
class="seriesInfo">BCP42</span>, <span class="seriesInfo">RFC6895</span>, <span
class="seriesInfo">DOI10.17487/RFC6895</span>, <time datetime="2013-04">April
2013</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc6895";>https://www.rfc-editor.org/info/rfc6895</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)
- "</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>
+<span class="refAuthor">Pornin, T.</span>, <span
class="refTitle">"Deterministic Usage of the Digital Signature Algorithm (DSA)
and Elliptic Curve Digital Signature Algorithm (ECDSA)"</span>, <span
class="seriesInfo">RFC6979</span>, <span
class="seriesInfo">DOI10.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="RFC7748">[RFC7748]</dt>
<dd>
-<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg,
M.</span><span class="refAuthor">, and S. Turner</span>, <span
class="refTitle">"Elliptic Curves for Security"</span>, <span
class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI
10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>,
<span><<a
href="https://www.rfc-editor.org/info/rfc7748";>https://www.rfc-editor.org/info/rfc7748</a>></span>.
</dd>
+<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg,
M.</span><span class="refAuthor">, and S. Turner</span>, <span
class="refTitle">"Elliptic Curves for Security"</span>, <span
class="seriesInfo">RFC7748</span>, <span
class="seriesInfo">DOI10.17487/RFC7748</span>, <time datetime="2016-01">January
2016</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc7748";>https://www.rfc-editor.org/info/rfc7748</a>></span>.
</dd>
<dt id="RFC8032">[RFC8032]</dt>
<dd>
-<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I.
Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature
Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span
class="seriesInfo">DOI 10.17487/RFC8032</span>, <time
datetime="2017-01">January 2017</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc8032";>https://www.rfc-editor.org/info/rfc8032</a>></span>.
</dd>
+<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I.
Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature
Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC8032</span>, <span
class="seriesInfo">DOI10.17487/RFC8032</span>, <time datetime="2017-01">January
2017</time>
+ <span>, <<a
href="https://www.rfc-editor.org/info/rfc8032";>https://www.rfc-editor.org/info/rfc8032</a>></span>.
</dd>
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"
@@ -2391,38 +2353,38 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#name-authors-addresses" class="section-name selfRef">Authors'
Addresses</a>
</h2>
<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Martin
Schanzenbach</span></div>
-<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
-<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse
3</span></div>
-<div dir="auto" class="left">
+ <div dir="auto"><span class="fn nameRole">Martin
Schanzenbach</span></div>
+<div dir="auto"><span class="org">GNUnet e.V.</span></div>
+<div dir="auto"><span class="street-address">Boltzmannstrasse 3</span></div>
+<div dir="auto">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto" class="left"><span class="country-name">Germany</span></div>
+<div dir="auto"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:address@hidden"; class="email">address@hidden</a>
</div>
</address>
<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Christian
Grothoff</span></div>
-<div dir="auto" class="left"><span class="org">Berner
Fachhochschule</span></div>
-<div dir="auto" class="left"><span class="street-address">Hoeheweg
80</span></div>
-<div dir="auto" class="left">CH-<span class="postal-code">2501</span> <span
class="locality">Biel/Bienne</span>
+ <div dir="auto"><span class="org">Berner Fachhochschule</span></div>
+<div dir="auto"><span class="fn nameRole">Christian Grothoff</span></div>
+<div dir="auto"><span class="street-address">Hoeheweg 80</span></div>
+<div dir="auto">CH-<span class="postal-code">2501</span> <span
class="locality">Biel/Bienne</span>
</div>
-<div dir="auto" class="left"><span
class="country-name">Switzerland</span></div>
+<div dir="auto"><span class="country-name">Switzerland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:address@hidden"; class="email">address@hidden</a>
</div>
</address>
<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Bernd
Fix</span></div>
-<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
-<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse
3</span></div>
-<div dir="auto" class="left">
+ <div dir="auto"><span class="fn nameRole">Bernd Fix</span></div>
+<div dir="auto"><span class="org">GNUnet e.V.</span></div>
+<div dir="auto"><span class="street-address">Boltzmannstrasse 3</span></div>
+<div dir="auto">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto" class="left"><span class="country-name">Germany</span></div>
+<div dir="auto"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:address@hidden"; class="email">address@hidden</a>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 63bdc20..349d2c9 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -5,10 +5,10 @@
Independent Stream M. Schanzenbach
Internet-Draft GNUnet e.V.
Intended status: Informational C. Grothoff
-Expires: 24 January 2020 Berner Fachhochschule
+Expires: 13 May 2020 Berner Fachhochschule
B. Fix
GNUnet e.V.
- 23 July 2019
+ 10 November 2019
The GNU Name System Specification
@@ -34,7 +34,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on 24 January 2020.
+ This Internet-Draft will expire on 13 May 2020.
Copyright Notice
@@ -42,7 +42,7 @@ Copyright Notice
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents (https://trustee.ietf.org/
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
@@ -50,46 +50,38 @@ Copyright Notice
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 1]
-
-Internet-Draft The GNU Name System July 2019
-
-
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Resource Records . . . . . . . . . . . . . . . . . . . . . . 4
- 3.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 5
- 3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.6. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.7. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 10
- 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 10
- 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 11
- 4.3. Record Data Encryption and Decryption . . . . . . . . . . 12
- 5. Internationalization and Character Encoding . . . . . . . . . 15
- 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 16
- 6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 16
- 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.3.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 18
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 18
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 20
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
+ 1. Introduction
+ 2. Zones
+ 3. Resource Records
+ 3.1. Record Types
+ 3.2. PKEY
+ 3.3. GNS2DNS
+ 3.4. LEHO
+ 3.5. NICK
+ 3.6. BOX
+ 3.7. VPN
+ 4. Publishing Records
+ 4.1. Key Derivations
+ 4.2. Resource Records Block
+ 4.3. Record Data Encryption and Decryption
+ 5. Internationalization and Character Encoding
+ 6. Name Resolution
+ 6.1. Entry Zone
+ 6.2. Record Retrieval
+ 6.3. Record Processing
+ 6.3.1. PKEY
+ 6.3.2. GNS2DNS
+ 6.3.3. CNAME
+ 6.3.4. BOX
+ 6.3.5. VPN
+ 7. Zone Revocation
+ 8. Security Considerations
+ 9. IANA Considerations
+ 10. Test Vectors
+ 11. Normative References
+ Authors' Addresses
1. Introduction
@@ -106,14 +98,6 @@ Table of Contents
vulnerable, especially to attackers that have the technical
capabilities of an entire nation state at their disposal. This
specification describes a censorship-resistant, privacy-preserving
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 2]
-
-Internet-Draft The GNU Name System July 2019
-
-
and decentralized name system: The GNU Name System (GNS). It is
designed to provide a secure alternative to DNS, especially when
censorship or manipulation is encountered. GNS can bind names to any
@@ -139,6 +123,10 @@ Internet-Draft The GNU Name System
July 2019
resolution processes, cryptographic routines and security
considerations for use by implementors.
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
2. Zones
@@ -149,29 +137,21 @@ Internet-Draft The GNU Name System
July 2019
([RFC6979]). In the following, we use the following naming
convention for our cryptographic primitives:
- d is a 256-bit ECDSA private key. In GNS, records are signed using
- a key derived from "d" as described in Section 4.
+ d is a 256-bit ECDSA private key. In GNS, records are signed using
+ a key derived from "d" as described in Section 4.
- p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- - 19.
+ p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
+ - 19.
- B is the group generator (X(P),Y(P)) of edwards25519 as defined in
- [RFC7748].
+ B is the group generator (X(P),Y(P)) of edwards25519 as defined in
+ [RFC7748].
- L is the prime-order subgroup of edwards25519 in [RFC7748].
+ L is the prime-order subgroup of edwards25519 in [RFC7748].
zk is the ECDSA public key corresponding to d. It is defined in
- [RFC6979] as the curve point d*B where B is the group generator of
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 3]
-
-Internet-Draft The GNU Name System July 2019
-
-
- the elliptic curve. The public key is used to uniquely identify a
- GNS zone and is referred to as the "zone key".
+ [RFC6979] as the curve point d*B where B is the group generator
+ of the elliptic curve. The public key is used to uniquely
+ identify a GNS zone and is referred to as the "zone key".
3. Resource Records
@@ -201,30 +181,25 @@ Internet-Draft The GNU Name System
July 2019
where:
EXPIRATION denotes the absolute 64-bit expiration date of the
- record. In microseconds since midnight (0 hour), January 1, 1970
- in network byte order.
+ record. In microseconds since midnight (0 hour), January
+ 1, 1970 in network byte order.
- DATA SIZE denotes the 32-bit size of the DATA field in bytes and in
- network byte order.
+ DATA SIZE denotes the 32-bit size of the DATA field in bytes and in
+ network byte order.
- TYPE is the 32-bit resource record type. This type can be one of
- the GNS 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. This value must be stored
- in network byte order. Note that values below 2^16 are reserved
- for allocation via IANA ([RFC6895]).
+ TYPE is the 32-bit resource record type. This type can be one
+ of the GNS 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.
+ This value must be stored in network byte order. Note
+ that values below 2^16 are reserved for allocation via
+ IANA ([RFC6895]).
- FLAGS is a 32-bit resource record flags field (see below).
-
- DATA the variable-length resource record data payload. The contents
- are defined by the respective type of the resource record.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 4]
-
-Internet-Draft The GNU Name System July 2019
+ FLAGS is a 32-bit resource record flags field (see below).
+ DATA the variable-length resource record data payload. The
+ contents are defined by the respective type of the
+ resource record.
Flags indicate metadata surrounding the resource record. A flag
value of 0 indicates that all flags are unset. The following
@@ -240,24 +215,25 @@ Internet-Draft The GNU Name System
July 2019
where:
- SHADOW If this flag is set, this record should be ignored by
- resolvers unless all (other) records of the same record type have
- expired. Used to allow zone publishers to facilitate good
- performance when records change by allowing them to put future
- values of records into the DHT. This way, future values can
- propagate and may be cached before the transition becomes active.
+ SHADOW If this flag is set, this record should be ignored by
+ resolvers unless all (other) records of the same record type
+ have expired. Used to allow zone publishers to facilitate
+ good performance when records change by allowing them to put
+ future values of records into the DHT. This way, future
+ values can propagate and may be cached before the transition
+ becomes active.
- EXPREL The expiration time value of the record is a relative time
- (still in microseconds) and not an absolute time. This flag
- should never be encountered by a resolver for records obtained
- from the DHT, but might be present when a resolver looks up
- private records of a zone hosted locally.
+ EXPREL The expiration time value of the record is a relative time
+ (still in microseconds) and not an absolute time. This flag
+ should never be encountered by a resolver for records
+ obtained from the DHT, but might be present when a resolver
+ looks up private records of a zone hosted locally.
PRIVATE This is a private record of this peer and it should thus not
- be published in the DHT. Thus, this flag should never be
- encountered by a resolver for records obtained from the DHT.
- Private records should still be considered just like regular
- records when resolving labels in local zones.
+ be published in the DHT. Thus, this flag should never be
+ encountered by a resolver for records obtained from the DHT.
+ Private records should still be considered just like regular
+ records when resolving labels in local zones.
3.1. Record Types
@@ -265,23 +241,6 @@ Internet-Draft The GNU Name System
July 2019
type numbers for DNS. The following is a list of defined and
reserved record types in GNS:
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
-
-
Number | Type | Comment
------------------------------------------------------------
65536 | PKEY | GNS delegation
@@ -325,19 +284,6 @@ Internet-Draft The GNU Name System
July 2019
format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
the following format:
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
-
-Internet-Draft The GNU Name System July 2019
-
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS NAME |
@@ -355,11 +301,12 @@ Internet-Draft The GNU Name System
July 2019
where:
- DNS NAME The name to continue with in DNS (0-terminated).
+ DNS NAME The name to continue with in DNS (0-terminated).
DNS SERVER NAME The DNS server to use. May be an IPv4/IPv6 address
- in dotted decimal form or a DNS name. It may also be a relative
- GNS name ending with a "+" top-level domain. (all 0-terminated)
+ in dotted decimal form or a DNS name. It may also
+ be a relative GNS name ending with a "+" top-level
+ domain. (all 0-terminated)
3.4. LEHO
@@ -383,16 +330,7 @@ Internet-Draft The GNU Name System
July 2019
where:
LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated)
- representing the legacy hostname.
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
+ representing the legacy hostname.
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to a punycode
@@ -420,8 +358,8 @@ Internet-Draft The GNU Name System
July 2019
where:
NICKNAME A UTF-8 string (which is not 0-terminated) representing the
- preferred label of the zone. This string MUST NOT inlcude a "."
- character.
+ preferred label of the zone. This string MUST NOT inlcude
+ a "." character.
3.6. BOX
@@ -436,20 +374,6 @@ Internet-Draft The GNU Name System
July 2019
(PROTO) 6 (tcp) and record_type "TLSA". For reference, see also
[RFC2782] A BOX DATA entry has the following format:
-
-
-
-
-
-
-
-
-
-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
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
@@ -464,17 +388,17 @@ Internet-Draft The GNU Name System
July 2019
where:
- PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte
- order.
+ PROTO the 16-bit protocol number, e.g. 6 for tcp. In network
+ byte order.
- SVC the 16-bit service value of the boxed record, i.e. the port
- number. In network byte order.
+ SVC the 16-bit service value of the boxed record, i.e. the
+ port number. In network byte order.
- TYPE is the 32-bit record type of the boxed record. In network byte
- order.
+ TYPE is the 32-bit record type of the boxed record. In
+ network byte order.
RECORD DATA is a variable length field containing the "DATA" format
- of TYPE as defined for the respective TYPE in DNS.
+ of TYPE as defined for the respective TYPE in DNS.
3.7. VPN
@@ -495,17 +419,6 @@ Internet-Draft The GNU Name System
July 2019
Figure 9
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
-
-Internet-Draft The GNU Name System July 2019
-
-
4. Publishing Records
GNS resource records are published in a distributed hash table (DHT).
@@ -531,36 +444,28 @@ Internet-Draft The GNU Name System
July 2019
SHA256 for the expansion phase.
PRK_h is key material retrieved using an HKDF using the string "key-
- derivation" as salt and the public zone key "zk" as initial keying
- material.
+ derivation" as salt and the public zone key "zk" as initial
+ keying material.
- h is the 512-bit HKDF expansion result. The expansion info input is
- a concatenation of the label and string "gns".
+ h is the 512-bit HKDF expansion result. The expansion info
+ input is a concatenation of the label and string "gns".
- d is the 256-bit private zone key as defined in Section 2.
+ d is the 256-bit private zone key as defined in Section 2.
label is a UTF-8 string under which the resource records are
- published.
-
- d_h is a 256-bit private key derived from the "d" using the keying
- material "h".
-
- zk_h is a 256-bit public key derived from the zone key "zk" using
- the keying material "h".
-
- 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
- published. It is the SHA512 hash over the public key "zk_h"
- corresponding to the derived private key "d_h".
-
+ published.
+ d_h is a 256-bit private key derived from the "d" using the keying
+ material "h".
+ 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 10]
-
-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 published. It is the SHA512 hash over the public key
+ "zk_h" corresponding to the derived private key "d_h".
We point out that the multiplication of "zk" with "h" is a point
multiplication, while the multiplication of "d" with "h" is a scalar
@@ -604,48 +509,42 @@ Internet-Draft The GNU Name System
July 2019
where:
- 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_h" (see Section 4).
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
-
-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_h" (see Section 4).
PUBLIC KEY is the 256-bit public key "zk_h" to be used to verify
- SIGNATURE. The wire format of this value is defined in [RFC8032],
- Section 5.1.5.
+ SIGNATURE. The wire format of this value is defined in
+ [RFC8032], Section 5.1.5.
- SIZE A 32-bit value containing the length of the signed data
- following the PUBLIC KEY field in network byte order. This value
- always includes the length of the fields SIZE (4), PURPOSE (4) and
- EXPIRATION (8) in addition to the length of the BDATA. While a
- 32-bit value is used, implementations MAY refuse to publish blocks
- beyond a certain size significantly below 4 GB. However, a
- minimum block size of 62 kilobytes MUST be supported.
+ SIZE A 32-bit value containing the length of the signed data
+ following the PUBLIC KEY field in network byte order.
+ This value always includes the length of the fields SIZE
+ (4), PURPOSE (4) and EXPIRATION (8) in addition to the
+ length of the BDATA. While a 32-bit value is used,
+ implementations MAY refuse to publish blocks beyond a
+ certain size significantly below 4 GB. However, a
+ minimum block size of 62 kilobytes MUST be supported.
- PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
- network byte order).
+ PURPOSE A 32-bit signature purpose flag. This field MUST be 15
+ (in network byte order).
EXPIRATION Specifies when the RRBLOCK 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-expired
- individual records until they expire. The value MUST be set to
- the expiration time of the resource record contained within this
- block with the smallest expiration time. If a records block
- includes shadow records, then the maximum expiration time of all
- shadow records with matching type and the expiration times of the
- non-shadow records is considered. This is a 64-bit absolute date
- in microseconds since midnight (0 hour), January 1, 1970 in
- network byte order.
-
- BDATA The encrypted resource records with a total size of SIZE - 16.
+ block SHOULD be removed from the DHT and caches as it is
+ likely stale. However, applications MAY continue to use
+ non-expired individual records until they expire. The
+ value MUST be set to the expiration time of the resource
+ record contained within this block with the smallest
+ expiration time. If a records block includes shadow
+ records, then the maximum expiration time of all shadow
+ records with matching type and the expiration times of
+ the non-shadow records is considered. This is a 64-bit
+ absolute date in microseconds since midnight (0 hour),
+ January 1, 1970 in network byte order.
+
+ BDATA The encrypted resource records with a total size of SIZE
+ - 16.
4.3. Record Data Encryption and Decryption
@@ -653,27 +552,6 @@ Internet-Draft The GNU Name System
July 2019
set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of
the RDATA looks as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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
+-----+-----+-----+-----+-----+-----+-----+-----+
| RR COUNT | EXPIRA- /
@@ -721,15 +599,6 @@ Internet-Draft The GNU Name System
July 2019
records block payload, the key material "K" and initialization vector
"IV" for the symmetric cipher are derived as follows:
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
@@ -779,13 +648,6 @@ Internet-Draft The GNU Name System
July 2019
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV,
BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV,
RDATA))
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
5. Internationalization and Character Encoding
All labels in GNS are encoded in UTF-8 [RFC3629]. This does not
@@ -834,14 +696,6 @@ Internet-Draft The GNU Name System
July 2019
SHOULD be configurable through the GNS implementation. A mapping has
the form "prefix = public zone key". The prefix may consist of
multiple GNS labels concatenated with a ".". If multiple prefixes
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
match the name to resolve, the longest prefix is chosen. The prefix
length of two results cannot be equal, as this would indicate a
misconfiguration.
@@ -890,14 +744,6 @@ Internet-Draft The GNU Name System
July 2019
If the remainder of the name to resolve is empty but we have received
a record set containing only a single PKEY record, the recursion is
continued with the PKEY as authoritative zone and the empty apex
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
-
-
label "@" as remaining name. If the record type to be resolved is
PKEY, the PKEY record set is returned and the resolution is
concluded.
@@ -942,18 +788,6 @@ Internet-Draft The GNU Name System
July 2019
prevent infinite loops, the resolver should implement loop detections
or limit the recursive resolution of CNAMEs using an upper bound.
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
-
-Internet-Draft The GNU Name System July 2019
-
-
6.3.4. BOX
When a BOX record is received, a GNS resolver must unbox it if the
@@ -1002,14 +836,6 @@ Internet-Draft The GNU Name System
July 2019
f89333903b284fe8
1878bf47f3b39da0
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
-
-Internet-Draft The GNU Name System July 2019
-
-
zk (public zone key) :=
dff911496d025d7e
0885c03d19153e99
@@ -1058,14 +884,6 @@ Internet-Draft The GNU Name System
July 2019
3425e8a811ae59d2
99e2747285d2a479
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 19]
-
-Internet-Draft The GNU Name System July 2019
-
-
TWOFISH_IV :=
071be189a9d236f9
b4a3654bb8c281d4
@@ -1109,23 +927,19 @@ Internet-Draft The GNU Name System
July 2019
11. Normative References
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
- <https://www.rfc-editor.org/info/rfc1034>.
+ [RFC1034] Mockapetris, P.V., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
+ November 1987, <https://www.rfc-editor.org/info/rfc1034>.
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 20]
-
-Internet-Draft The GNU Name System July 2019
-
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
+ [RFC1035] Mockapetris, P.V., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
@@ -1169,15 +983,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 21]
-
-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,
@@ -1197,8 +1002,8 @@ Authors' Addresses
Email: address@hidden
- Christian Grothoff
Berner Fachhochschule
+ Christian Grothoff
Hoeheweg 80
CH-2501 Biel/Bienne
Switzerland
@@ -1213,20 +1018,3 @@ Authors' Addresses
Germany
Email: address@hidden
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 22]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 44ca14c..325d9e1 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1,7 +1,18 @@
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
-<!ENTITY RFC3986 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml";>
+<!ENTITY RFC1034 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml";>
+<!ENTITY RFC1035 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml";>
+<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml";>
+<!ENTITY RFC2782 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml";>
<!ENTITY RFC3629 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml";>
+<!ENTITY RFC3826 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml";>
+<!ENTITY RFC5869 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml";>
+<!ENTITY RFC5890 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml";>
+<!ENTITY RFC5891 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml";>
+<!ENTITY RFC6895 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml";>
+<!ENTITY RFC6979 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml";>
+<!ENTITY RFC7748 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml";>
+<!ENTITY RFC8032 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml";>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
@@ -54,7 +65,7 @@
</address>
</author>
- <date day="23" month="July" year="2019"/>
+ <date day="10" month="November" year="2019"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Independent Stream</workgroup>
@@ -105,6 +116,12 @@
This document defines the normative wire format of resource records,
resolution processes,
cryptographic routines and security considerations for use by
implementors.
</t>
+ <t>
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described
+ in <xref target="RFC2119"/>.
+ </t>
<t>
</t>
@@ -1124,89 +1141,21 @@
<back>
<references>
<name>Normative References</name>
- <reference anchor="RFC7748"
target="https://www.rfc-editor.org/info/rfc7748";><front><title>Elliptic Curves
for Security</title><author initials="A." surname="Langley" fullname="A.
Langley"><organization/></author><author initials="M." surname="Hamburg"
fullname="M. Hamburg"><organization/></author><author initials="S."
surname="Turner" fullname="S. Turner"><organization/></author><date year="2016"
month="January"/><abstract><t>This memo specifies two elliptic curves over
prime fie [...]
- <reference anchor="RFC3826"
target="https://www.rfc-editor.org/info/rfc3826";><front><title>The Advanced
Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security
Model</title><author initials="U." surname="Blumenthal" fullname="U.
Blumenthal"><organization/></author><author initials="F." surname="Maino"
fullname="F. Maino"><organization/></author><author initials="K."
surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date
year="2004" month="Ju [...]
- <reference anchor="RFC5890"
target="https://www.rfc-editor.org/info/rfc5890";><front><title>Internationalized
Domain Names for Applications (IDNA): Definitions and Document
Framework</title><author initials="J." surname="Klensin" fullname="J.
Klensin"><organization/></author><date year="2010"
month="August"/><abstract><t>This document is one of a collection that,
together, describe the protocol and usage context for a revision of
Internationalized Domain Names for Applications (IDN [...]
- <reference anchor="RFC5891"
target="https://www.rfc-editor.org/info/rfc5891";><front><title>Internationalized
Domain Names in Applications (IDNA): Protocol</title><author initials="J."
surname="Klensin" fullname="J. Klensin"><organization/></author><date
year="2010" month="August"/><abstract><t>This document is the revised protocol
definition for Internationalized Domain Names (IDNs). The rationale for
changes, the relationship to the older specification, and important terminology
[...]
- <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="RFC3629"
target="https://www.rfc-editor.org/info/rfc3629";><front><title>UTF-8, a
transformation format of ISO 10646</title><author initials="F."
surname="Yergeau" fullname="F. Yergeau"><organization/></author><date
year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large
character set called the Universal Character Set (UCS) which encompasses most
of the world's writing systems. The originally proposed encodings of the UCS,
however, were not c [...]
- </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="RFC6895"
target="https://www.rfc-editor.org/info/rfc6895";><front><title>Domain Name
System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake
3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013"
month="April"/><abstract><t>This document specifies Internet Assigned Numbers
Authority (IANA) parameter assignment considerations for the allocation of
Domain Name System (DNS) resource record types, CLASSes, operation codes, e
[...]
- <reference anchor="RFC1034"
target="https://www.rfc-editor.org/info/rfc1034";><front><title>Domain names -
concepts and facilities</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 basic definition of The
Domain Name System. It obsoletes RFC-882. This memo describes the domain
style names and their used for host address look up and electronic mail forwar
[...]
- <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 [...]
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="6979"/>
- <seriesInfo name="DOI" value="10.17487/RFC6979"/>
- </reference>
+
+ &RFC1034;
+ &RFC1035;
+ &RFC2782;
+ &RFC2119;
+ &RFC3629;
+ &RFC3826;
+ &RFC5869;
+ &RFC5890;
+ &RFC5891;
+ &RFC6895;
+ &RFC6979;
+ &RFC7748;
+ &RFC8032;
+
<reference anchor="TWOFISH">
<front>
<title>
@@ -1218,31 +1167,6 @@
<date year="1999" month="March"/>
</front>
</reference>
- <reference anchor="RFC2782"
target="https://www.rfc-editor.org/info/rfc2782";>
- <front>
- <title>
- A DNS RR for specifying the location of services (DNS SRV)
- </title>
- <author initials="A." surname="Gulbrandsen" fullname="A.
Gulbrandsen">
- <organization/>
- </author>
- <author initials="P." surname="Vixie" fullname="P. Vixie">
- <organization/>
- </author>
- <author initials="L." surname="Esibov" fullname="L. Esibov">
- <organization/>
- </author>
- <date year="2000" month="February"/>
- <abstract>
- <t>
- This document describes a DNS RR which specifies the location
of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="2782"/>
- <seriesInfo name="DOI" value="10.17487/RFC2782"/>
- </reference>
-
<!-- <reference anchor="ISO20022">
<front>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: cite rfc 2119,
gnunet <=