[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: fix padding
From: |
gnunet |
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: fix padding |
Date: |
Sat, 05 Oct 2019 08:45:41 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 1912d84 fix padding
1912d84 is described below
commit 1912d8475a376cd096c8a719ff101a6c68eb2469
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sat Oct 5 08:43:31 2019 +0200
fix padding
---
draft-schanzen-gns.html | 568 +++++++++++++++++++++++++++---------------------
draft-schanzen-gns.txt | 419 ++++++++++++++++++++++++-----------
draft-schanzen-gns.xml | 3 +-
3 files changed, 619 insertions(+), 371 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 7658afa..ca80214 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2,20 +2,35 @@
<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 name="author" content="Martin Schanzenbach">
-<meta name="author" content="Christian Grothoff">
-<meta name="author" content="Bernd Fix">
-<meta name="description" content="
+<meta content="Martin Schanzenbach" name="author">
+<meta content="Christian Grothoff" name="author">
+<meta content="Bernd Fix" name="author">
+<meta content="
This document contains the GNU Name System (GNS) technical
specification.
- ">
-<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 */
+ " 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 */
@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 */
@@ -181,11 +196,16 @@ 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 {
@@ -198,7 +218,7 @@ a {
text-decoration: none;
}
a[href] {
- color: #3E8EDE;
+ color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
background-color: #f2f2f2;
@@ -251,6 +271,7 @@ aside, blockquote {
}
blockquote {
background-color: #f9f9f9;
+ color: #111; /* Arlen: WCAG 2019 */
border: 1px solid #ddd;
border-radius: 3px;
margin: 1em 0;
@@ -294,7 +315,7 @@ table p {
/* pilcrow */
a.pilcrow {
- color: #777;
+ color: #666; /* Arlen: AHDJ 2019 */
text-decoration: none;
visibility: hidden;
user-select: none;
@@ -355,7 +376,7 @@ hr {
/* The prepared/rendered info at the very bottom of the page */
.docInfo {
- color: #999;
+ color: #666; /* Arlen: WCAG 2019 */
font-size: 0.9em;
font-style: italic;
margin-top: 2em;
@@ -469,17 +490,17 @@ hr.addr {
right: 0.2em;
padding: 0.2em;
content: "The RFC Editor will remove this note";
- color: #b76427;
- background-color: rgba(249, 232, 105, 0.3);
+ color: #9e2a00; /* Arlen: WCAG 2019 */
+ background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
position: relative;
padding-top: 1.8em;
- background-color: rgba(249, 232, 105, 0.3);
+ background-color: #ffd; /* Arlen: WCAG 2019 */
border-radius: 3px;
}
.cref {
- background-color: rgba(249, 232, 105, 0.3);
+ background-color: #ffd; /* Arlen: WCAG 2019 */
padding: 2px 4px;
}
.crefSource {
@@ -586,7 +607,7 @@ hr.addr {
/* pagination */
@media print {
body {
- font-family: 'Noto Serif', "Times New Roman", Times, serif;
+
width: 100%;
}
p {
@@ -628,6 +649,9 @@ 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();
}
@@ -651,6 +675,7 @@ hr.addr {
.ears tfoot .right {
string-set: ears-bottom-right content();
}
+*/
@page :first {
padding-top: 0;
@@ -672,6 +697,9 @@ 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;
@@ -707,10 +735,15 @@ 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;
@@ -769,10 +802,12 @@ 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;
@@ -833,10 +868,18 @@ caption {
script don't end up on the other side of the page. */
address.vcard {
- max-width: 20em;
+ max-width: 30em;
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 {
@@ -856,10 +899,80 @@ 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 rel="stylesheet" href="rfc-local.css" type="text/css">
+<link href="rfc-local.css" type="text/css" rel="stylesheet">
</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>
@@ -915,17 +1028,21 @@ caption a[href] {
<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 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
+ 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
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 24 January 2020.<a
href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
@@ -933,17 +1050,19 @@ caption a[href] {
<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
- (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>
+ (<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>
</section>
</div>
<div id="toc">
@@ -953,65 +1072,65 @@ caption a[href] {
</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-pkey" class="xref">PKEY</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-pkey" class="xref">PKEY</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-gns2dns" class="xref">GNS2DNS</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-gns2dns" class="xref">GNS2DNS</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-leho" class="xref">LEHO</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-leho" class="xref">LEHO</a><a
href="#section-boilerplate.3-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.4">
- <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4"
class="xref">3.4</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4"
class="xref">3.4</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.4.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-block-data-encryption-and-d"
class="xref">Block 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-block-data-encryption-and-d"
class="xref">Block 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-record-resolution" class="xref">Record
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-record-resolution" class="xref">Record
Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
</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-namespace-revocation"
class="xref">Namespace 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-namespace-revocation"
class="xref">Namespace 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>
@@ -1029,8 +1148,7 @@ caption a[href] {
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
@@ -1041,8 +1159,7 @@ caption a[href] {
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
@@ -1055,15 +1172,11 @@ caption a[href] {
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"><a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="zones">
@@ -1075,45 +1188,40 @@ caption a[href] {
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>]
(a.k.a. edwards25519)
- with the ECDSA scheme (</span><span>[<a href="#RFC6979"
class="xref">RFC6979</a>]).
+ 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>).
The deterministic property of ECDSA (as opposed to EdDSA) is required
in order to achieve zone privacy.
In the following, we use the following naming convention for our
- cryptographic primitives:
- </span><a href="#section-2-1" class="pilcrow">¶</a></p>
+ cryptographic primitives:<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>.
- </dd>
+ <a href="#publish" class="xref">Section 4</a>.<a
href="#section-2-2.2" class="pilcrow">¶</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>], i.e.
- 2^255 - 19.
- </span>
+ 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>
</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>
+ <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a
href="#section-2-2.6" class="pilcrow">¶</a>
</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>
+ 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>
</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>] as the curve
point d*B where B is the group
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> 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".
- </span>
+ as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1125,8 +1233,7 @@ caption a[href] {
</h2>
<p id="section-3-1">
A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:
- <a href="#section-3-1" class="pilcrow">¶</a></p>
+ The resource record format is defined as follows:<a href="#section-3-1"
class="pilcrow">¶</a></p>
<div id="figure_gnsrecord">
<figure id="figure-1">
<div class="artwork art-text alignLeft" id="section-3-2.1">
@@ -1143,7 +1250,7 @@ caption a[href] {
/ /
</pre>
</div>
-<figcaption><a href="#figure-1">Figure 1</a></figcaption></figure>
+<figcaption><a href="#figure-1" class="selfRef">Figure
1</a></figcaption></figure>
</div>
<p id="section-3-3">where:<a href="#section-3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-4">
@@ -1151,33 +1258,32 @@ caption a[href] {
<dd id="section-3-4.2">
denotes the absolute 64-bit expiration date of the record.
In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.
- </dd>
+ byte order.<a href="#section-3-4.2" class="pilcrow">¶</a>
+</dd>
<dt id="section-3-4.3">DATA SIZE</dt>
<dd id="section-3-4.4">
denotes the 32-bit size of the DATA field in bytes and in network byte
- order.
- </dd>
+ order.<a href="#section-3-4.4" class="pilcrow">¶</a>
+</dd>
<dt id="section-3-4.5">TYPE</dt>
<dd id="section-3-4.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>] or any of the
+ type as defined in <span>[<a href="#RFC1035"
class="xref">RFC1035</a>]</span> 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><span>[<a
href="#RFC6895" class="xref">RFC6895</a>]).
- </span>
+ below 2^16 are reserved for allocation via IANA (<span>[<a
href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-4.6"
class="pilcrow">¶</a>
</dd>
<dt id="section-3-4.7">FLAGS</dt>
<dd id="section-3-4.8">
- is a 32-bit resource record flags field (see below).
- </dd>
+ is a 32-bit resource record flags field (see below).<a
href="#section-3-4.8" class="pilcrow">¶</a>
+</dd>
<dt id="section-3-4.9">DATA</dt>
<dd id="section-3-4.10">
the variable-length resource record data payload. The contents are
defined
by the
- respective type of the resource record.
- </dd>
+ respective type of the resource record.<a href="#section-3-4.10"
class="pilcrow">¶</a>
+</dd>
</dl>
<p id="section-3-5">
Flags indicate metadata surrounding the resource record. A flag
@@ -1194,11 +1300,10 @@ caption a[href] {
------+--------+--------+--------+--------+--------+
</pre>
</div>
-<figcaption><a href="#figure-2">Figure 2</a></figcaption></figure>
+<figcaption><a href="#figure-2" class="selfRef">Figure
2</a></figcaption></figure>
</div>
<p id="section-3-7">
- where:
- <a href="#section-3-7" class="pilcrow">¶</a></p>
+ where:<a href="#section-3-7" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-8">
<dt id="section-3-8.1">SHADOW</dt>
<dd id="section-3-8.2">
@@ -1206,23 +1311,23 @@ caption a[href] {
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.
- </dd>
+ cached before the transition becomes active.<a href="#section-3-8.2"
class="pilcrow">¶</a>
+</dd>
<dt id="section-3-8.3">EXPREL</dt>
<dd id="section-3-8.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.
- </dd>
+ private records of a zone hosted locally.<a href="#section-3-8.4"
class="pilcrow">¶</a>
+</dd>
<dt id="section-3-8.5">PRIVATE</dt>
<dd id="section-3-8.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.
- </dd>
+ regular records when resolving labels in local zones.<a
href="#section-3-8.6" class="pilcrow">¶</a>
+</dd>
</dl>
<div id="gnsrecords_pkey">
<section id="section-3.1">
@@ -1246,7 +1351,7 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-3">Figure 3</a></figcaption></figure>
+<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
</div>
</section>
</div>
@@ -1258,7 +1363,7 @@ caption a[href] {
<p id="section-3.2-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>] for DNS names.
+ <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS
names.
If a resolver encounters a GNS2DNS record it is expected that it first
resolves the IP(s) of the DNS server(s). GNS2DNS records MAY contain
numeric IPv4 or IPv6 addresses, allowing the resolver to skip this
step.
@@ -1272,7 +1377,7 @@ caption a[href] {
GNS2DNS records may be stored under the same label, in which case the
resolve MUST try all of them. However, if multiple GNS2DNS records
are present, the DNS name MUST be identical for all of them.
- A GNS2DNS DATA entry has the following format:</span><a
href="#section-3.2-1" class="pilcrow">¶</a></p>
+ A GNS2DNS DATA entry has the following format:<a
href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
<figure id="figure-4">
<div class="artwork art-text alignLeft" id="section-3.2-2.1">
@@ -1291,7 +1396,7 @@ caption a[href] {
+-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-4">Figure 4</a></figcaption></figure>
+<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
</div>
</section>
</div>
@@ -1323,13 +1428,12 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-5">Figure 5</a></figcaption></figure>
+<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
</div>
<p id="section-3.3-3">
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="#RFC3492" class="xref">RFC3492</a>].
- </span><a href="#section-3.3-3" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC3492" class="xref">RFC3492</a>]</span>.<a
href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gnsrecords_box">
@@ -1368,27 +1472,27 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-6">Figure 6</a></figcaption></figure>
+<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
</div>
<dl class="dlParallel" id="section-3.4-3">
<dt id="section-3.4-3.1">PROTO</dt>
<dd id="section-3.4-3.2">
- the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
- </dd>
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.<a href="#section-3.4-3.2" class="pilcrow">¶</a>
+</dd>
<dt id="section-3.4-3.3">SVC</dt>
<dd id="section-3.4-3.4">
the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.
- </dd>
+ In network byte order.<a href="#section-3.4-3.4"
class="pilcrow">¶</a>
+</dd>
<dt id="section-3.4-3.5">TYPE</dt>
<dd id="section-3.4-3.6">
- is the 32-bit record type of the boxed record. In network byte
order.
- </dd>
+ is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.4-3.6" class="pilcrow">¶</a>
+</dd>
<dt id="section-3.4-3.7">RECORD DATA</dt>
<dd id="section-3.4-3.8">
is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.
- </dd>
+ defined for the respective TYPE in DNS.<a href="#section-3.4-3.8"
class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1404,16 +1508,14 @@ caption a[href] {
Resource records are grouped by their respective labels, encrypted and
published together in a single block in the DHT.
A resource records block is published under a 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>
+ from the zone key "zk" and the respective 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)
@@ -1421,60 +1523,57 @@ caption a[href] {
d_h := h*d mod L
zk_h := h*zk mod L
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>]. 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>
+ <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>
<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.
- </dd>
+ keying material.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
+</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".
- </dd>
+ concatenation of the label and string "gns".<a
href="#section-4.1-4.4" class="pilcrow">¶</a>
+</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>.
- </dd>
+ 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>
<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.
- </dd>
+ is a UTF-8 string under which the resource records are published.<a
href="#section-4.1-4.8" class="pilcrow">¶</a>
+</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".
- </dd>
+ keying material "h".<a href="#section-4.1-4.10"
class="pilcrow">¶</a>
+</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".
- </dd>
+ keying material "h".<a href="#section-4.1-4.12"
class="pilcrow">¶</a>
+</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>.
- </dd>
+ 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>
<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".
- </dd>
+ derived private key "d_h".<a href="#section-4.1-4.16"
class="pilcrow">¶</a>
+</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">
@@ -1487,8 +1586,7 @@ caption a[href] {
block in the DHT.
The contained resource records are encrypted using a symmetric
encryption scheme.
- A GNS resource records block has the following format:
- <a href="#section-4.2-1" class="pilcrow">¶</a></p>
+ A GNS resource records block has the following format:<a
href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
<figure id="figure-7">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
@@ -1519,24 +1617,23 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-7">Figure 7</a></figcaption></figure>
+<figcaption><a href="#figure-7" class="selfRef">Figure
7</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>]. The signature
is computed over the data
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The
signature is computed over the data
following the PUBLIC KEY field.
The signature is created using the derived private key "d_h" (see
- </span><a href="#publish" class="xref">Section 4</a>).
- </dd>
+ <a href="#publish" class="xref">Section 4</a>).<a
href="#section-4.2-4.2" class="pilcrow">¶</a>
+</dd>
<dt id="section-4.2-4.3">PUBLIC KEY</dt>
<dd id="section-4.2-4.4">
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>],
- Section 5.1.5.
- </span>
+ wire format of this value is defined in <span>[<a href="#RFC8032"
class="xref">RFC8032</a>]</span>,
+ Section 5.1.5.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4.2-4.5">SIZE</dt>
<dd id="section-4.2-4.6">
@@ -1546,13 +1643,13 @@ caption a[href] {
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.
- </dd>
+ 62 kilobytes MUST be supported.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
+</dd>
<dt id="section-4.2-4.7">PURPOSE</dt>
<dd id="section-4.2-4.8">
A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).
- </dd>
+ byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
+</dd>
<dt id="section-4.2-4.9">EXPIRATION</dt>
<dd id="section-4.2-4.10">
Specifies when the resource records block expires and the encrypted
block
@@ -1565,12 +1662,12 @@ caption a[href] {
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.
- </dd>
+ (0 hour), January 1, 1970 in network byte order.<a
href="#section-4.2-4.10" class="pilcrow">¶</a>
+</dd>
<dt id="section-4.2-4.11">BDATA</dt>
<dd id="section-4.2-4.12">
- The encrypted resource records with a total size of SIZE - 16.
- </dd>
+ The encrypted resource records with a total size of SIZE - 16.<a
href="#section-4.2-4.12" class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1581,8 +1678,7 @@ caption a[href] {
<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 record block.
- 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-8">
<div class="artwork art-text alignLeft" id="section-4.3-2.1">
@@ -1612,7 +1708,7 @@ caption a[href] {
/ /
</pre>
</div>
-<figcaption><a href="#figure-8">Figure 8</a></figcaption></figure>
+<figcaption><a href="#figure-8" class="selfRef">Figure
8</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">
@@ -1620,23 +1716,24 @@ caption a[href] {
<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.
- </dd>
+ following after this field in network byte order.<a
href="#section-4.3-4.2" class="pilcrow">¶</a>
+</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.
- </dd>
+ present.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
+</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.
- The padding MUST ensure that the size of the RDATA is a power of
two.
+ The padding MUST ensure that the size of the RDATA WITHOUT the RR
+ 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.
- </dd>
+ contain other records.<a href="#section-4.3-4.6"
class="pilcrow">¶</a>
+</dd>
</dl>
<p id="section-4.3-5">
To obtain a given resource records block, the client must first
compute
@@ -1646,33 +1743,29 @@ caption a[href] {
Upon receiving a block from the DHT, the receiver first checks
that the PUBLIC KEY field matches "zk_h". Then, the client MUST
verify
the signature. These steps are mandatory to prevent record spoofing
and
- MUST be performed before decryption.
- <a href="#section-4.3-5" class="pilcrow">¶</a></p>
+ MUST be performed before decryption.<a href="#section-4.3-5"
class="pilcrow">¶</a></p>
<p id="section-4.3-6">
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-6" class="pilcrow">¶</a></p>
+ "IV" for the symmetric cipher are derived as follows:<a
href="#section-4.3-6" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-7">
<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-7" class="pilcrow">¶</a>
+ </pre><a href="#section-4.3-7" class="pilcrow">¶</a>
</div>
<p id="section-4.3-8">
HKDF is a hash-based key derivation function as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]. Specifically,
HMAC-SHA512 is used for the
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>.
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><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-8" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
+ and a 256-bit TWOFISH <span>[<a href="#TWOFISH"
class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-8"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.3-9.1">
@@ -1691,12 +1784,11 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-9">Figure 9</a></figcaption></figure>
+<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
</div>
<p id="section-4.3-10">
Similarly, we divide "IV" into a 128-bit initialization vector
- and a 128-bit initialization vector:
- <a href="#section-4.3-10" class="pilcrow">¶</a></p>
+ and a 128-bit initialization vector:<a href="#section-4.3-10"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.3-11.1">
@@ -1711,19 +1803,17 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-10">Figure 10</a></figcaption></figure>
+<figcaption><a href="#figure-10" class="selfRef">Figure
10</a></figcaption></figure>
</div>
<p id="section-4.3-12">
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-12" class="pilcrow">¶</a></p>
+ Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826"
class="xref">RFC3826</a>]</span>.<a href="#section-4.3-12"
class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-13">
<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-13" class="pilcrow">¶</a>
+ </pre><a href="#section-4.3-13" class="pilcrow">¶</a>
</div>
</section>
</section>
@@ -1734,11 +1824,10 @@ caption a[href] {
<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>].
+ All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629"
class="xref">RFC3629</a>]</span>.
This does not include any DNS names found in DNS records, such as CNAME
records, which are internationalized through the IDNA specifications
- </span><span>[<a href="#RFC5890" class="xref">RFC5890</a>].
- </span><a href="#section-5-1" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span>.<a
href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="resolution">
@@ -1747,8 +1836,7 @@ caption a[href] {
<a href="#section-6" class="section-number selfRef">6. </a><a
href="#name-record-resolution" class="section-name selfRef">Record
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>
</section>
</div>
<div id="revocation">
@@ -1757,8 +1845,7 @@ caption a[href] {
<a href="#section-7" class="section-number selfRef">7. </a><a
href="#name-namespace-revocation" class="section-name selfRef">Namespace
Revocation</a>
</h2>
<p id="section-7-1">
- TODO
- <a href="#section-7-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
@@ -1767,8 +1854,7 @@ caption a[href] {
<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">
@@ -1777,8 +1863,7 @@ caption a[href] {
<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">
@@ -1787,8 +1872,7 @@ caption a[href] {
</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"
@@ -1887,63 +1971,51 @@ caption a[href] {
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="#name-normative-references" class="section-name selfRef">Normative
References</a>
+<a href="#section-11" class="section-number selfRef">11. </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.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>
+<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>
<dt id="RFC1035">[RFC1035]</dt>
<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>
+<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>
<dt id="RFC3492">[RFC3492]</dt>
<dd>
-<span class="refAuthor">Costello, A.</span>, <span class="refTitle">"Punycode:
A Bootstring encoding of Unicode for Internationalized Domain Names in
Applications (IDNA)"</span>, <span class="seriesInfo">RFC3492</span>, <span
class="seriesInfo">DOI10.17487/RFC3492</span>, <time datetime="2003-03">March
2003</time>
- <span>, <<a
href="https://www.rfc-editor.org/info/rfc3492">https://www.rfc-editor.org/info/rfc3492</a>></span>.
</dd>
+<span class="refAuthor">Costello, A.</span>, <span class="refTitle">"Punycode:
A Bootstring encoding of Unicode for Internationalized Domain Names in
Applications (IDNA)"</span>, <span class="seriesInfo">RFC 3492</span>, <span
class="seriesInfo">DOI 10.17487/RFC3492</span>, <time datetime="2003-03">March
2003</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc3492">https://www.rfc-editor.org/info/rfc3492</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">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>
+<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>
<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">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>
+<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/ [...]
<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">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>
+ "</span>, <span class="seriesInfo">RFC 5869</span>, <span
class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May
2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>></span>.
</dd>
<dt id="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">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>
+<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>
<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">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>
+<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>
<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">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>
+ "</span>, <span class="seriesInfo">RFC 6979</span>, <span
class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08">August
2013</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc6979">https://www.rfc-editor.org/info/rfc6979</a>></span>.
</dd>
<dt id="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">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>
+<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>
<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">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>
+<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>
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"
@@ -1957,41 +2029,41 @@ caption a[href] {
<a href="#name-authors-addresses" class="section-name selfRef">Authors'
Addresses</a>
</h2>
<address class="vcard">
- <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">
+ <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">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto"><span class="country-name">Germany</span></div>
+<div dir="auto" class="left"><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"><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 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>
-<div dir="auto"><span class="country-name">Switzerland</span></div>
+<div dir="auto" class="left"><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"><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">
+ <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">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto"><span class="country-name">Germany</span></div>
+<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
-<a href="mailto:address@hidden" class="email">address@hidden</a>
+<a href="mailto:address@hidden" class="email">address@hidden</a>
</div>
</address>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 3afc969..46241a9 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -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 (http://trustee.ietf.org/
+ Provisions Relating to IETF Documents (https://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,27 +50,35 @@ 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. Zones
- 3. Resource records
- 3.1. PKEY
- 3.2. GNS2DNS
- 3.3. LEHO
- 3.4. BOX
- 4. Publishing records
- 4.1. Key derivations
- 4.2. Resource records block
- 4.3. Block data encryption and decryption
- 5. Internationalization and Character Encoding
- 6. Record Resolution
- 7. Namespace Revocation
- 8. Security Considerations
- 9. IANA Considerations
- 10. Test Vectors
- 11. Normative References
- Authors' Addresses
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Resource records . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 8
+ 4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2. Resource records block . . . . . . . . . . . . . . . . . 9
+ 4.3. Block data encryption and decryption . . . . . . . . . . 10
+ 5. Internationalization and Character Encoding . . . . . . . . . 13
+ 6. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 13
+ 7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 13
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
@@ -98,6 +106,14 @@ Table of Contents
specification of the GNU Name System (GNS), a fully decentralized and
censorship-resistant name system. GNS provides a privacy-enhancing
alternative to the Domain Name System (DNS). The design of GNS
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 2]
+
+Internet-Draft The GNU Name System July 2019
+
+
incorporates the capability to integrate and coexist with DNS. GNS
is based on the principle of a petname system and builds on ideas
from the Simple Distributed Security Infrastructure (SDSI),
@@ -124,27 +140,36 @@ Table of Contents
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 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
A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined as follows:
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 3]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
@@ -161,25 +186,23 @@ Table of Contents
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).
+ 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.
+ 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
@@ -195,25 +218,32 @@ Table of Contents
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.
- 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.
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 4]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ 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.
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. PKEY
@@ -244,6 +274,14 @@ Table of Contents
addresses, allowing the resolver to skip this step. The DNS server
names may themselves be names in GNS or DNS. If the DNS server name
ends in ".+", the rest of the name is to be interpreted relative to
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
+
+
the zone of the GNS2DNS record. Then, the DNS name from the GNS2DNS
record is appended to the remainder of the name to be resolved, and
resolved by querying the name server(s). Multiple GNS2DNS records
@@ -292,6 +330,14 @@ Table of Contents
(e.g. "Host:" header) it must be converted to a punycode
representation [RFC3492].
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
+
3.4. BOX
In GNS, every "." in a name delegates to another zone, and GNS
@@ -322,17 +368,31 @@ Table of Contents
Figure 6
- 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.
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
4. Publishing records
@@ -357,30 +417,39 @@ Table of Contents
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.
+ published.
- d_h is a 256-bit private key derived from the "d" using the keying
- material "h".
+ 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".
+ 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.
+ 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".
+ 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
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
multiplication, while the multiplication of "d" with "h" is a scalar
multiplication.
@@ -420,42 +489,47 @@ Table of Contents
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).
+ 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.
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+Internet-Draft The GNU Name System July 2019
- PURPOSE A 32-bit signature purpose flag. This field MUST be 15
- (in network byte order).
+
+ 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).
EXPIRATION Specifies when the resource records block expires and the
- encrypted block SHOULD be removed from the DHT and caches
- as it is likely stale. However, applications MAY
- continue to use non-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.
+ 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.
4.3. Block data encryption and decryption
@@ -463,6 +537,31 @@ Table of Contents
set RDATA into the BDATA field of a GNS record block. The wire
format of the RDATA looks as follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| RR COUNT | EXPIRA- /
@@ -500,16 +599,25 @@ Table of Contents
RR COUNT of these resource records present.
PADDING The padding MUST contain the value 0 in all octets. The
- padding MUST ensure that the size of the RDATA 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.
+ padding MUST ensure that the size of the RDATA WITHOUT the RR
+ 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.
To obtain a given resource records block, the client must first
compute "zk_h" from "zk" and label (as defined in Section 4.1) and
then use "zk_h" to compute "q" which is the query for the DHT. Upon
receiving a block from the DHT, the receiver first checks that the
PUBLIC KEY field matches "zk_h". Then, the client MUST verify the
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+
+Internet-Draft The GNU Name System July 2019
+
+
signature. These steps are mandatory to prevent record spoofing and
MUST be performed before decryption.
@@ -558,6 +666,14 @@ Table of Contents
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+
+Internet-Draft The GNU Name System July 2019
+
+
Figure 10
The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256
@@ -606,6 +722,14 @@ Table of Contents
zk (public zone key) :=
dff911496d025d7e
0885c03d19153e99
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+
+Internet-Draft The GNU Name System July 2019
+
+
4f213f23ea719eca
17fc32dc410e082e
@@ -655,6 +779,13 @@ Table of Contents
071be189a9d236f9
b4a3654bb8c281d4
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+
+Internet-Draft The GNU Name System July 2019
+
+
RDATA :=
0000000100059412 RR COUNT | EXPIRA-
09ddea0f00000014 -TION | DATA SIZE (20)
@@ -694,14 +825,23 @@ Table of Contents
11. Normative References
- [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>.
+ [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>.
- [RFC1035] Mockapetris, P.V., "Domain names - implementation and
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+
+Internet-Draft The GNU Name System July 2019
+
+
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
@@ -750,6 +890,14 @@ Table of Contents
Authors' Addresses
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+Internet-Draft The GNU Name System July 2019
+
+
Martin Schanzenbach
GNUnet e.V.
Boltzmannstrasse 3
@@ -759,8 +907,8 @@ Authors' Addresses
Email: address@hidden
- Berner Fachhochschule
Christian Grothoff
+ Berner Fachhochschule
Hoeheweg 80
CH-2501 Biel/Bienne
Switzerland
@@ -774,4 +922,31 @@ Authors' Addresses
85748 Garching
Germany
- Email: address@hidden
+ Email: address@hidden
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 8c045f7..500ae5d 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -608,7 +608,8 @@
<dt>PADDING</dt>
<dd>
The padding MUST contain the value 0 in all octets.
- The padding MUST ensure that the size of the RDATA is a power of
two.
+ The padding MUST ensure that the size of the RDATA WITHOUT the RR
+ 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.
--
To stop receiving notification emails like this one, please contact
address@hidden.