[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: FTBFS
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: FTBFS |
|
Date: |
Fri, 04 Oct 2019 23:22:37 +0200 |
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 4ff9b30 FTBFS
4ff9b30 is described below
commit 4ff9b30e4046f9260bc5e24b6011dda0eb517603
Author: Christian Grothoff <address@hidden>
AuthorDate: Fri Oct 4 23:20:28 2019 +0200
FTBFS
---
draft-schanzen-gns.html | 648 ++++++++++++++++++++++--------------------------
draft-schanzen-gns.txt | 403 +++++++++++-------------------
draft-schanzen-gns.xml | 12 +-
3 files changed, 447 insertions(+), 616 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 3bcde51..7658afa 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,80 +856,10 @@ 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>
@@ -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 24 January
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,65 +953,65 @@ 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-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-security-considerations"
class="xref">Security Considerations</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-record-resolution" class="xref">Record
Resolution</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-namespace-revocation"
class="xref">Namespace Revocation</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>
@@ -1148,7 +1029,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
@@ -1159,7 +1041,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
@@ -1172,11 +1055,15 @@ 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">
+
+ <a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="zones">
@@ -1188,40 +1075,45 @@ 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>]).
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:<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>
@@ -1233,7 +1125,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</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">
@@ -1250,7 +1143,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-3">where:<a href="#section-3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-4">
@@ -1258,32 +1151,33 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<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.<a href="#section-3-4.2" class="pilcrow">¶</a>
-</dd>
+ byte order.
+ </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.<a href="#section-3-4.4" class="pilcrow">¶</a>
-</dd>
+ order.
+ </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>]</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-4.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-4.7">FLAGS</dt>
<dd id="section-3-4.8">
- is a 32-bit resource record flags field (see below).<a
href="#section-3-4.8" class="pilcrow">¶</a>
-</dd>
+ is a 32-bit resource record flags field (see below).
+ </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.<a href="#section-3-4.10"
class="pilcrow">¶</a>
-</dd>
+ respective type of the resource record.
+ </dd>
</dl>
<p id="section-3-5">
Flags indicate metadata surrounding the resource record. A flag
@@ -1300,10 +1194,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-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">
@@ -1311,23 +1206,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-8.2"
class="pilcrow">¶</a>
-</dd>
+ cached before the transition becomes active.
+ </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.<a href="#section-3-8.4"
class="pilcrow">¶</a>
-</dd>
+ private records of a zone hosted locally.
+ </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.<a
href="#section-3-8.6" class="pilcrow">¶</a>
-</dd>
+ regular records when resolving labels in local zones.
+ </dd>
</dl>
<div id="gnsrecords_pkey">
<section id="section-3.1">
@@ -1351,7 +1246,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</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>
@@ -1363,7 +1258,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<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>]</span> for DNS
names.
+ <span>[<a href="#RFC1034" class="xref">RFC1034</a>] 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.
@@ -1377,7 +1272,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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:<a
href="#section-3.2-1" class="pilcrow">¶</a></p>
+ A GNS2DNS DATA entry has the following format:</span><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">
@@ -1396,7 +1291,7 @@ 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>
</section>
</div>
@@ -1428,12 +1323,13 @@ 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">
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">
@@ -1472,27 +1368,27 @@ 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>
<dl class="dlParallel" id="section-3.4-3">
<dt id="section-3.4-3.1">PROTO</dt>
<dd id="section-3.4-3.2">
- the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.<a href="#section-3.4-3.2" class="pilcrow">¶</a>
-</dd>
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
+ </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.<a href="#section-3.4-3.4"
class="pilcrow">¶</a>
-</dd>
+ In network byte order.
+ </dd>
<dt id="section-3.4-3.5">TYPE</dt>
<dd id="section-3.4-3.6">
- is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.4-3.6" class="pilcrow">¶</a>
-</dd>
+ is the 32-bit record type of the boxed record. In network byte
order.
+ </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.<a href="#section-3.4-3.8"
class="pilcrow">¶</a>
-</dd>
+ defined for the respective TYPE in DNS.
+ </dd>
</dl>
</section>
</div>
@@ -1509,67 +1405,76 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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.
- Given a label, the DHT key "q" is derived as follows:<a
href="#section-4-1" class="pilcrow">¶</a></p>
+ <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>
-<div class="artwork art-text alignLeft" id="section-4.1-1">
+<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>
+<div class="artwork art-text alignLeft" id="section-4.1-2">
<pre>
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d_h := h*d mod L
zk_h := h*zk mod L
q := SHA512 (zk_h)
- </pre><a href="#section-4.1-1" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
-<p id="section-4.1-2">
+<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-2" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-4.1-3">
- <dt id="section-4.1-3.1">PRK_h</dt>
- <dd id="section-4.1-3.2">
+ <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-3.2" class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.1-3.3">h</dt>
- <dd id="section-4.1-3.4">
+ 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-3.4" class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.1-3.5">d</dt>
- <dd id="section-4.1-3.6">
- is the 256-bit private zone key as defined in <a href="#zones"
class="xref">Section 2</a>.<a href="#section-4.1-3.6" class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.1-3.7">label</dt>
- <dd id="section-4.1-3.8">
- is a UTF-8 string under which the resource records are published.<a
href="#section-4.1-3.8" class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.1-3.9">d_h</dt>
- <dd id="section-4.1-3.10">
+ 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>.
+ </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>
+ <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-3.10"
class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.1-3.11">zk_h</dt>
- <dd id="section-4.1-3.12">
+ 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-3.12"
class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.1-3.13">L</dt>
- <dd id="section-4.1-3.14">
- is the prime-order subgroup as defined in <a href="#zones"
class="xref">Section 2</a>.<a href="#section-4.1-3.14" class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.1-3.15">q</dt>
- <dd id="section-4.1-3.16">
+ 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>.
+ </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-3.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>
</section>
</div>
<div id="wire">
@@ -1582,7 +1487,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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">
@@ -1613,52 +1519,58 @@ 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-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">
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.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
-</dd>
+ 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>
<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">
- is the 64-bit resource records block expiration time. This is the
- expiration
- time of the resource record contained within this block with the
+ 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*
+ 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.<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>
@@ -1669,7 +1581,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 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">
@@ -1699,7 +1612,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
/ /
</pre>
</div>
-<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
+<figcaption><a href="#figure-8">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">
@@ -1708,44 +1621,58 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
A 32-bit value containing the number of variable-length resource
records which are
following after this field in network byte order.
- The resource record format is defined in <a href="#rrecords"
class="xref">Section 3</a>.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
-</dd>
- <dt id="section-4.3-4.3">PADDING</dt>
+ </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>
+ <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.
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.4"
class="pilcrow">¶</a>
-</dd>
+ contain other records.
+ </dd>
</dl>
<p id="section-4.3-5">
- Upon receiving a resource records block, first the validity of a
- given "zk_h" MUST be checked by computing the expected "zk_h" from
"zk"
- and label (as defined in <a href="#blinding" class="xref">Section
4.1</a>) and verifying that
- both are equal. This step is mandatory to prevent record spoofing.<a
href="#section-4.3-5" class="pilcrow">¶</a></p>
+ To obtain a given resource records block, the client must first
compute
+ "zk_h" from "zk"
+ and label (as defined in <a href="#blinding" class="xref">Section
4.1</a>)
+ 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 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>
<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 en-/decryption 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>]</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-8"
class="pilcrow">¶</a></p>
+ 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>
<div id="figure_hkdf_keys">
<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.3-9.1">
@@ -1764,11 +1691,12 @@ 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>
<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">
@@ -1783,17 +1711,19 @@ 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.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>
@@ -1804,37 +1734,41 @@ 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="security">
+<div id="resolution">
<section id="section-6">
- <h2 id="name-security-considerations">
-<a href="#section-6" class="section-number selfRef">6. </a><a
href="#name-security-considerations" class="section-name selfRef">Security
Considerations</a>
+ <h2 id="name-record-resolution">
+<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="resolution">
+<div id="revocation">
<section id="section-7">
- <h2 id="name-record-resolution">
-<a href="#section-7" class="section-number selfRef">7. </a><a
href="#name-record-resolution" class="section-name selfRef">Record
Resolution</a>
+ <h2 id="name-namespace-revocation">
+<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="revocation">
+<div id="security">
<section id="section-8">
- <h2 id="name-namespace-revocation">
-<a href="#section-8" class="section-number selfRef">8. </a><a
href="#name-namespace-revocation" class="section-name selfRef">Namespace
Revocation</a>
+ <h2 id="name-security-considerations">
+<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">
@@ -1843,7 +1777,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">
@@ -1852,7 +1787,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"
@@ -1951,51 +1887,63 @@ 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="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">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>
+<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>
<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>, <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="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>, <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">"
@@ -2009,38 +1957,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 268985f..3afc969 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 (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,35 +50,27 @@ 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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 12
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
- 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 12
- 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 12
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
+ 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
@@ -106,14 +98,6 @@ 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),
@@ -140,36 +124,27 @@ Internet-Draft The GNU Name System
July 2019
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 |
@@ -186,23 +161,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).
+ 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
@@ -218,32 +195,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.
-
-
-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.
+ 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
@@ -274,14 +244,6 @@ Internet-Draft The GNU Name System
July 2019
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
@@ -330,14 +292,6 @@ Internet-Draft The GNU Name System
July 2019
(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
@@ -368,31 +322,17 @@ Internet-Draft The GNU Name System
July 2019
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.
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
+ of TYPE as defined for the respective TYPE in DNS.
4. Publishing records
@@ -401,10 +341,11 @@ Internet-Draft The GNU Name System
July 2019
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.
- Given a label, the DHT key "q" is derived as follows:
4.1. Key derivations
+ Given a label, the DHT key "q" is derived as follows:
+
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d_h := h*d mod L
@@ -416,39 +357,32 @@ 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".
+ published.
- L is the prime-order subgroup as defined in Section 2.
+ d_h is a 256-bit private key derived from the "d" using the keying
+ material "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".
+ 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".
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
+ 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.
4.2. Resource records block
@@ -486,42 +420,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).
+ 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.
-
- SIZE A 32-bit value containing the length of the signed data
- following the PUBLIC KEY field in network byte order. This value
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
-
-Internet-Draft The GNU Name System July 2019
-
-
- always includes the length of the fields SIZE (4), PURPOSE (4) and
- EXPIRATION (8) in addition to the length of the BDATA.
-
- PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
- network byte order).
-
- EXPIRATION is the 64-bit resource records block expiration time.
- This is 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.
+ 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.
+
+ 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.
4.3. Block data encryption and decryption
@@ -555,18 +489,15 @@ Internet-Draft The GNU Name System
July 2019
Figure 8
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
-
-Internet-Draft The GNU Name System July 2019
-
-
where:
RR COUNT A 32-bit value containing the number of variable-length
resource records which are following after this field in network
- byte order. The resource record format is defined in Section 3.
+ byte order.
+
+ EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA These fields were defined in
+ the resource record format in Section 3. There MUST be a total of
+ 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.
@@ -574,15 +505,18 @@ Internet-Draft The GNU Name System
July 2019
are never padded. Note that a record set with a PKEY record MUST
NOT contain other records.
- Upon receiving a resource records block, first the validity of a
- given "zk_h" MUST be checked by computing the expected "zk_h" from
- "zk" and label (as defined in Section 4.1) and verifying that both
- are equal. This step is mandatory to prevent record spoofing.
+ 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
+ signature. These steps are mandatory to prevent record spoofing and
+ MUST be performed before decryption.
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 en-/decryption are derived as follows:
+ "IV" for the symmetric cipher are derived as follows:
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
@@ -610,14 +544,6 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
-
-Internet-Draft The GNU Name System July 2019
-
-
Figure 9
Similarly, we divide "IV" into a 128-bit initialization vector and a
@@ -648,15 +574,15 @@ Internet-Draft The GNU Name System
July 2019
which are internationalized through the IDNA specifications
[RFC5890].
-6. Security Considerations
+6. Record Resolution
TODO
-7. Record Resolution
+7. Namespace Revocation
TODO
-8. Namespace Revocation
+8. Security Considerations
TODO
@@ -664,16 +590,6 @@ Internet-Draft The GNU Name System
July 2019
This will be fun
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
-
10. Test Vectors
The following represents a test vector for a record of type MX with a
@@ -722,14 +638,6 @@ Internet-Draft The GNU Name System
July 2019
AES_KEY :=
afefd21a087a150d
6757741a4eda02a5
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
65df7ca86ba44b21
3f8106c0071eaf01
@@ -778,14 +686,6 @@ Internet-Draft The GNU Name System
July 2019
66c2fb9bf020a85d
e80818d0a84059a8
5eee901a66459e5e
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
3d1a10b29a5b8354
1b58636781166b9a
642920eee8e7a65a
@@ -794,11 +694,11 @@ 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>.
- [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>.
@@ -833,15 +733,6 @@ Internet-Draft The GNU Name System
July 2019
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
@@ -868,8 +759,8 @@ Authors' Addresses
Email: address@hidden
- Christian Grothoff
Berner Fachhochschule
+ Christian Grothoff
Hoeheweg 80
CH-2501 Biel/Bienne
Switzerland
@@ -884,13 +775,3 @@ Authors' Addresses
Germany
Email: address@hidden
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 1adabe6..d731fed 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -391,8 +391,6 @@
</dd>
</dl>
</section>
-
-
</section>
<section anchor="publish" numbered="true" toc="default">
@@ -406,7 +404,9 @@
</t>
<section anchor="blinding" numbered="true" toc="default">
<name>Key derivations</name>
- Given a label, the DHT key "q" is derived as follows:
+ <t>
+ Given a label, the DHT key "q" is derived as follows:
+ </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
@@ -461,8 +461,10 @@
derived private key "d_h".
</dd>
</dl>
- 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.
+ <t>
+ 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.
+ </t>
</section>
<section anchor="wire" numbered="true" toc="default">
<name>Resource records block</name>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [lsd0001] branch master updated: FTBFS,
gnunet <=