[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: RFC 9498
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: RFC 9498 |
|
Date: |
Wed, 22 Nov 2023 15:04:15 +0100 |
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 732db61 RFC 9498
732db61 is described below
commit 732db6154bed55715ff120545f0a4a625677bd82
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Nov 22 15:03:35 2023 +0100
RFC 9498
---
Makefile | 4 +-
rfc9498.xml | 5434 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 5436 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index d426a48..ba2d48b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
all: txt html
html:
- xml2rfc --html --css style.css draft-schanzen-gns.xml
+ xml2rfc --html --css style.css rfc9498.xml
txt:
- xml2rfc draft-schanzen-gns.xml
+ xml2rfc rfc9498.xml
diff --git a/rfc9498.xml b/rfc9498.xml
new file mode 100644
index 0000000..db28c64
--- /dev/null
+++ b/rfc9498.xml
@@ -0,0 +1,5434 @@
+<?xml version='1.0' encoding='utf-8'?>
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; version="3"
submissionType="independent" category="info" docName="draft-schanzen-gns-28"
number="9498" ipr="trust200902" sortRefs="false" symRefs="true" tocDepth="3"
tocInclude="true" updates="" obsoletes="" xml:lang="en"
prepTime="2023-11-20T18:08:49" indexInclude="true" scripts="Common,Latin">
+ <link href="https://datatracker.ietf.org/doc/draft-schanzen-gns-28";
rel="prev"/>
+ <link href="https://dx.doi.org/10.17487/rfc9498"; rel="alternate"/>
+ <link href="urn:issn:2070-1721" rel="alternate"/>
+ <front>
+ <title abbrev="The GNU Name System">The GNU Name System</title>
+ <seriesInfo name="RFC" value="9498" stream="independent"/>
+ <author fullname="Martin Schanzenbach" initials="M."
surname="Schanzenbach">
+ <organization showOnFrontPage="true">Fraunhofer AISEC</organization>
+ <address>
+ <postal>
+ <street>Lichtenbergstrasse 11</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>Germany</country>
+ </postal>
+ <email>martin.schanzenbach@aisec.fraunhofer.de</email>
+ </address>
+ </author>
+ <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
+ <organization showOnFrontPage="true">Berner Fachhochschule</organization>
+ <address>
+ <postal>
+ <street>Hoeheweg 80</street>
+ <city>Biel/Bienne</city>
+ <code>2501</code>
+ <country>Switzerland</country>
+ </postal>
+ <email>christian.grothoff@bfh.ch</email>
+ </address>
+ </author>
+ <author fullname="Bernd Fix" initials="B." surname="Fix">
+ <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>Germany</country>
+ </postal>
+ <email>fix@gnunet.org</email>
+ </address>
+ </author>
+ <date month="11" year="2023"/>
+ <keyword>name systems</keyword>
+ <abstract pn="section-abstract">
+ <t indent="0" pn="section-abstract-1">
+ This document provides the GNU Name System (GNS) technical
+ specification.
+ GNS is a decentralized and censorship-resistant domain name
+ resolution protocol that provides a privacy-enhancing alternative to the
+ Domain Name System (DNS) protocols.
+ </t>
+ <t indent="0" pn="section-abstract-2">
+ This document defines the normative wire format of resource records,
+ resolution processes, cryptographic routines, and security and privacy
+ considerations for use by implementers.
+ </t>
+ <t indent="0" pn="section-abstract-3">
+ This specification was developed outside the IETF and does not have
+ IETF consensus. It is published here to inform readers about the
+ function of GNS, guide future GNS implementations, and ensure
+ interoperability among implementations (for example, pre-existing
+ GNUnet implementations).
+ </t>
+ </abstract>
+ <boilerplate>
+ <section anchor="status-of-memo" numbered="false" removeInRFC="false"
toc="exclude" pn="section-boilerplate.1">
+ <name slugifiedName="name-status-of-this-memo">Status of This
Memo</name>
+ <t indent="0" pn="section-boilerplate.1-1">
+ This document is not an Internet Standards Track specification; it
is
+ published for informational purposes.
+ </t>
+ <t indent="0" pn="section-boilerplate.1-2">
+ This is a contribution to the RFC Series, independently of any
+ other RFC stream. The RFC Editor has chosen to publish this
+ document at its discretion and makes no statement about its value
+ for implementation or deployment. Documents approved for
+ publication by the RFC Editor are not candidates for any level of
+ Internet Standard; see Section 2 of RFC 7841.
+ </t>
+ <t indent="0" pn="section-boilerplate.1-3">
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ <eref target="https://www.rfc-editor.org/info/rfc9498";
brackets="none"/>.
+ </t>
+ </section>
+ <section anchor="copyright" numbered="false" removeInRFC="false"
toc="exclude" pn="section-boilerplate.2">
+ <name slugifiedName="name-copyright-notice">Copyright Notice</name>
+ <t indent="0" pn="section-boilerplate.2-1">
+ Copyright (c) 2023 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+ </t>
+ <t indent="0" pn="section-boilerplate.2-2">
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (<eref target="https://trustee.ietf.org/license-info";
brackets="none"/>) 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.
+ </t>
+ </section>
+ </boilerplate>
+ <toc>
+ <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude"
pn="section-toc.1">
+ <name slugifiedName="name-table-of-contents">Table of Contents</name>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1">
+ <li pn="section-toc.1-1.1">
+ <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref
derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.
<xref derivedContent="" format="title" sectionFormat="of"
target="name-introduction">Introduction</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.1.2">
+ <li pn="section-toc.1-1.1.2.1">
+ <t indent="0" keepWithNext="true"
pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter"
sectionFormat="of" target="section-1.1"/>. <xref derivedContent=""
format="title" sectionFormat="of"
target="name-requirements-notation">Requirements Notation</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.2">
+ <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref
derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.
<xref derivedContent="" format="title" sectionFormat="of"
target="name-terminology">Terminology</xref></t>
+ </li>
+ <li pn="section-toc.1-1.3">
+ <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3"
format="counter" sectionFormat="of" target="section-3"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-overview">Overview</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.3.2">
+ <li pn="section-toc.1-1.3.2.1">
+ <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref
derivedContent="3.1" format="counter" sectionFormat="of"
target="section-3.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-names-and-zones">Names and Zones</xref></t>
+ </li>
+ <li pn="section-toc.1-1.3.2.2">
+ <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref
derivedContent="3.2" format="counter" sectionFormat="of"
target="section-3.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-publishing-binding-informat">Publishing Binding
Information</xref></t>
+ </li>
+ <li pn="section-toc.1-1.3.2.3">
+ <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref
derivedContent="3.3" format="counter" sectionFormat="of"
target="section-3.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-resolving-names">Resolving Names</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.4">
+ <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4"
format="counter" sectionFormat="of" target="section-4"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-zones">Zones</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.4.2">
+ <li pn="section-toc.1-1.4.2.1">
+ <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref
derivedContent="4.1" format="counter" sectionFormat="of"
target="section-4.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-top-level-domain-ztld">Zone Top-Level
Domain (zTLD)</xref></t>
+ </li>
+ <li pn="section-toc.1-1.4.2.2">
+ <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref
derivedContent="4.2" format="counter" sectionFormat="of"
target="section-4.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-revocation">Zone Revocation</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.5">
+ <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5"
format="counter" sectionFormat="of" target="section-5"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-resource-records">Resource Records</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.5.2">
+ <li pn="section-toc.1-1.5.2.1">
+ <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref
derivedContent="5.1" format="counter" sectionFormat="of"
target="section-5.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-delegation-records">Zone Delegation
Records</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.5.2.1.2">
+ <li pn="section-toc.1-1.5.2.1.2.1">
+ <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref
derivedContent="5.1.1" format="counter" sectionFormat="of"
target="section-5.1.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-pkey">PKEY</xref></t>
+ </li>
+ <li pn="section-toc.1-1.5.2.1.2.2">
+ <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref
derivedContent="5.1.2" format="counter" sectionFormat="of"
target="section-5.1.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-edkey">EDKEY</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.5.2.2">
+ <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref
derivedContent="5.2" format="counter" sectionFormat="of"
target="section-5.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-redirection-records">Redirection
Records</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.5.2.2.2">
+ <li pn="section-toc.1-1.5.2.2.2.1">
+ <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref
derivedContent="5.2.1" format="counter" sectionFormat="of"
target="section-5.2.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-redirect">REDIRECT</xref></t>
+ </li>
+ <li pn="section-toc.1-1.5.2.2.2.2">
+ <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref
derivedContent="5.2.2" format="counter" sectionFormat="of"
target="section-5.2.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-gns2dns">GNS2DNS</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.5.2.3">
+ <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref
derivedContent="5.3" format="counter" sectionFormat="of"
target="section-5.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-auxiliary-records">Auxiliary Records</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.5.2.3.2">
+ <li pn="section-toc.1-1.5.2.3.2.1">
+ <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref
derivedContent="5.3.1" format="counter" sectionFormat="of"
target="section-5.3.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-leho">LEHO</xref></t>
+ </li>
+ <li pn="section-toc.1-1.5.2.3.2.2">
+ <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref
derivedContent="5.3.2" format="counter" sectionFormat="of"
target="section-5.3.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-nick">NICK</xref></t>
+ </li>
+ <li pn="section-toc.1-1.5.2.3.2.3">
+ <t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref
derivedContent="5.3.3" format="counter" sectionFormat="of"
target="section-5.3.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-box">BOX</xref></t>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.6">
+ <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6"
format="counter" sectionFormat="of" target="section-6"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-record-encoding-for-remote-">Record Encoding for Remote
Storage</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.6.2">
+ <li pn="section-toc.1-1.6.2.1">
+ <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref
derivedContent="6.1" format="counter" sectionFormat="of"
target="section-6.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-the-storage-key">The Storage Key</xref></t>
+ </li>
+ <li pn="section-toc.1-1.6.2.2">
+ <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref
derivedContent="6.2" format="counter" sectionFormat="of"
target="section-6.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-plaintext-record-data-rdata">Plaintext Record
Data (RDATA)</xref></t>
+ </li>
+ <li pn="section-toc.1-1.6.2.3">
+ <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref
derivedContent="6.3" format="counter" sectionFormat="of"
target="section-6.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-the-resource-record-block">The Resource Record
Block</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.7">
+ <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7"
format="counter" sectionFormat="of" target="section-7"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-name-resolution">Name Resolution</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.7.2">
+ <li pn="section-toc.1-1.7.2.1">
+ <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref
derivedContent="7.1" format="counter" sectionFormat="of"
target="section-7.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-start-zones">Start Zones</xref></t>
+ </li>
+ <li pn="section-toc.1-1.7.2.2">
+ <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref
derivedContent="7.2" format="counter" sectionFormat="of"
target="section-7.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-recursion">Recursion</xref></t>
+ </li>
+ <li pn="section-toc.1-1.7.2.3">
+ <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref
derivedContent="7.3" format="counter" sectionFormat="of"
target="section-7.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-record-processing">Record Processing</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.7.2.3.2">
+ <li pn="section-toc.1-1.7.2.3.2.1">
+ <t indent="0" pn="section-toc.1-1.7.2.3.2.1.1"><xref
derivedContent="7.3.1" format="counter" sectionFormat="of"
target="section-7.3.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-redirect-2">REDIRECT</xref></t>
+ </li>
+ <li pn="section-toc.1-1.7.2.3.2.2">
+ <t indent="0" pn="section-toc.1-1.7.2.3.2.2.1"><xref
derivedContent="7.3.2" format="counter" sectionFormat="of"
target="section-7.3.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-gns2dns-2">GNS2DNS</xref></t>
+ </li>
+ <li pn="section-toc.1-1.7.2.3.2.3">
+ <t indent="0" pn="section-toc.1-1.7.2.3.2.3.1"><xref
derivedContent="7.3.3" format="counter" sectionFormat="of"
target="section-7.3.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-box-2">BOX</xref></t>
+ </li>
+ <li pn="section-toc.1-1.7.2.3.2.4">
+ <t indent="0" pn="section-toc.1-1.7.2.3.2.4.1"><xref
derivedContent="7.3.4" format="counter" sectionFormat="of"
target="section-7.3.4"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-delegation-records-2">Zone Delegation
Records</xref></t>
+ </li>
+ <li pn="section-toc.1-1.7.2.3.2.5">
+ <t indent="0" pn="section-toc.1-1.7.2.3.2.5.1"><xref
derivedContent="7.3.5" format="counter" sectionFormat="of"
target="section-7.3.5"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-nick-2">NICK</xref></t>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.8">
+ <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8"
format="counter" sectionFormat="of" target="section-8"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-internationalization-and-ch">Internationalization and Character
Encoding</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9">
+ <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9"
format="counter" sectionFormat="of" target="section-9"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-security-and-privacy-consid">Security and Privacy
Considerations</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.9.2">
+ <li pn="section-toc.1-1.9.2.1">
+ <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref
derivedContent="9.1" format="counter" sectionFormat="of"
target="section-9.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-availability">Availability</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.2">
+ <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref
derivedContent="9.2" format="counter" sectionFormat="of"
target="section-9.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-agility">Agility</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.3">
+ <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref
derivedContent="9.3" format="counter" sectionFormat="of"
target="section-9.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-cryptography">Cryptography</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.4">
+ <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref
derivedContent="9.4" format="counter" sectionFormat="of"
target="section-9.4"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-abuse-mitigation">Abuse Mitigation</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.5">
+ <t indent="0" pn="section-toc.1-1.9.2.5.1"><xref
derivedContent="9.5" format="counter" sectionFormat="of"
target="section-9.5"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-management">Zone Management</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.6">
+ <t indent="0" pn="section-toc.1-1.9.2.6.1"><xref
derivedContent="9.6" format="counter" sectionFormat="of"
target="section-9.6"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-dhts-as-remote-storage">DHTs as Remote
Storage</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.7">
+ <t indent="0" pn="section-toc.1-1.9.2.7.1"><xref
derivedContent="9.7" format="counter" sectionFormat="of"
target="section-9.7"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-revocations">Revocations</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.8">
+ <t indent="0" pn="section-toc.1-1.9.2.8.1"><xref
derivedContent="9.8" format="counter" sectionFormat="of"
target="section-9.8"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-privacy">Zone Privacy</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.9">
+ <t indent="0" pn="section-toc.1-1.9.2.9.1"><xref
derivedContent="9.9" format="counter" sectionFormat="of"
target="section-9.9"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-governance">Zone Governance</xref></t>
+ </li>
+ <li pn="section-toc.1-1.9.2.10">
+ <t indent="0" pn="section-toc.1-1.9.2.10.1"><xref
derivedContent="9.10" format="counter" sectionFormat="of"
target="section-9.10"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-namespace-ambiguity">Namespace
Ambiguity</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.10">
+ <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10"
format="counter" sectionFormat="of" target="section-10"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-gana-considerations">GANA Considerations</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.10.2">
+ <li pn="section-toc.1-1.10.2.1">
+ <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref
derivedContent="10.1" format="counter" sectionFormat="of"
target="section-10.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-gnunet-signature-purposes-r">GNUnet Signature
Purposes Registry</xref></t>
+ </li>
+ <li pn="section-toc.1-1.10.2.2">
+ <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref
derivedContent="10.2" format="counter" sectionFormat="of"
target="section-10.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-gns-record-types-registry">GNS Record Types
Registry</xref></t>
+ </li>
+ <li pn="section-toc.1-1.10.2.3">
+ <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref
derivedContent="10.3" format="counter" sectionFormat="of"
target="section-10.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-alt-subdomains-registry">.alt Subdomains
Registry</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.11">
+ <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11"
format="counter" sectionFormat="of" target="section-11"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-iana-considerations">IANA Considerations</xref></t>
+ </li>
+ <li pn="section-toc.1-1.12">
+ <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12"
format="counter" sectionFormat="of" target="section-12"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-implementation-and-deployme">Implementation and Deployment
Status</xref></t>
+ </li>
+ <li pn="section-toc.1-1.13">
+ <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13"
format="counter" sectionFormat="of" target="section-13"/>. <xref
derivedContent="" format="title" sectionFormat="of"
target="name-references">References</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.13.2">
+ <li pn="section-toc.1-1.13.2.1">
+ <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref
derivedContent="13.1" format="counter" sectionFormat="of"
target="section-13.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-normative-references">Normative
References</xref></t>
+ </li>
+ <li pn="section-toc.1-1.13.2.2">
+ <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref
derivedContent="13.2" format="counter" sectionFormat="of"
target="section-13.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-informative-references">Informative
References</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.14">
+ <t indent="0" pn="section-toc.1-1.14.1"><xref
derivedContent="Appendix A" format="default" sectionFormat="of"
target="section-appendix.a"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-usage-and-migration">Usage and
Migration</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.14.2">
+ <li pn="section-toc.1-1.14.2.1">
+ <t indent="0" pn="section-toc.1-1.14.2.1.1"><xref
derivedContent="A.1" format="counter" sectionFormat="of"
target="section-appendix.a.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-dissemination">Zone
Dissemination</xref></t>
+ </li>
+ <li pn="section-toc.1-1.14.2.2">
+ <t indent="0" pn="section-toc.1-1.14.2.2.1"><xref
derivedContent="A.2" format="counter" sectionFormat="of"
target="section-appendix.a.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-start-zone-configuration">Start Zone
Configuration</xref></t>
+ </li>
+ <li pn="section-toc.1-1.14.2.3">
+ <t indent="0" pn="section-toc.1-1.14.2.3.1"><xref
derivedContent="A.3" format="counter" sectionFormat="of"
target="section-appendix.a.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-globally-unique-names-and-t">Globally Unique
Names and the Web</xref></t>
+ </li>
+ <li pn="section-toc.1-1.14.2.4">
+ <t indent="0" pn="section-toc.1-1.14.2.4.1"><xref
derivedContent="A.4" format="counter" sectionFormat="of"
target="section-appendix.a.4"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-migration-paths">Migration Paths</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.15">
+ <t indent="0" pn="section-toc.1-1.15.1"><xref
derivedContent="Appendix B" format="default" sectionFormat="of"
target="section-appendix.b"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-example-flows">Example Flows</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.15.2">
+ <li pn="section-toc.1-1.15.2.1">
+ <t indent="0" pn="section-toc.1-1.15.2.1.1"><xref
derivedContent="B.1" format="counter" sectionFormat="of"
target="section-appendix.b.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-aaaa-example-resolution">AAAA Example
Resolution</xref></t>
+ </li>
+ <li pn="section-toc.1-1.15.2.2">
+ <t indent="0" pn="section-toc.1-1.15.2.2.1"><xref
derivedContent="B.2" format="counter" sectionFormat="of"
target="section-appendix.b.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-redirect-example-resolution">REDIRECT Example
Resolution</xref></t>
+ </li>
+ <li pn="section-toc.1-1.15.2.3">
+ <t indent="0" pn="section-toc.1-1.15.2.3.1"><xref
derivedContent="B.3" format="counter" sectionFormat="of"
target="section-appendix.b.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-gns2dns-example-resolution">GNS2DNS Example
Resolution</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.16">
+ <t indent="0" pn="section-toc.1-1.16.1"><xref
derivedContent="Appendix C" format="default" sectionFormat="of"
target="section-appendix.c"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-base32gns">Base32GNS</xref></t>
+ </li>
+ <li pn="section-toc.1-1.17">
+ <t indent="0" pn="section-toc.1-1.17.1"><xref
derivedContent="Appendix D" format="default" sectionFormat="of"
target="section-appendix.d"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-test-vectors">Test Vectors</xref></t>
+ <ul bare="true" empty="true" indent="2" spacing="compact"
pn="section-toc.1-1.17.2">
+ <li pn="section-toc.1-1.17.2.1">
+ <t indent="0" pn="section-toc.1-1.17.2.1.1"><xref
derivedContent="D.1" format="counter" sectionFormat="of"
target="section-appendix.d.1"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-base32gns-encoding-decoding">Base32GNS
Encoding/Decoding</xref></t>
+ </li>
+ <li pn="section-toc.1-1.17.2.2">
+ <t indent="0" pn="section-toc.1-1.17.2.2.1"><xref
derivedContent="D.2" format="counter" sectionFormat="of"
target="section-appendix.d.2"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-record-sets">Record Sets</xref></t>
+ </li>
+ <li pn="section-toc.1-1.17.2.3">
+ <t indent="0" pn="section-toc.1-1.17.2.3.1"><xref
derivedContent="D.3" format="counter" sectionFormat="of"
target="section-appendix.d.3"/>. <xref derivedContent="" format="title"
sectionFormat="of" target="name-zone-revocation-2">Zone Revocation</xref></t>
+ </li>
+ </ul>
+ </li>
+ <li pn="section-toc.1-1.18">
+ <t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent=""
format="none" sectionFormat="of" target="section-appendix.e"/><xref
derivedContent="" format="title" sectionFormat="of"
target="name-acknowledgements">Acknowledgements</xref></t>
+ </li>
+ <li pn="section-toc.1-1.19">
+ <t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent=""
format="none" sectionFormat="of" target="section-appendix.f"/><xref
derivedContent="" format="title" sectionFormat="of"
target="name-authors-addresses">Authors' Addresses</xref></t>
+ </li>
+ </ul>
+ </section>
+ </toc>
+ </front>
+ <middle>
+ <section anchor="introduction" numbered="true" removeInRFC="false"
toc="include" pn="section-1">
+ <name slugifiedName="name-introduction">Introduction</name>
+ <t indent="0" pn="section-1-1">
+ This specification describes the GNU Name System (GNS), a
+ censorship-resistant, privacy-preserving, and decentralized
+ domain name resolution protocol. GNS cryptographically secures
+ the binding of names to arbitrary tokens, enabling it to double
+ in some respects as an alternative to some of today's public
+ key infrastructures.
+ </t>
+ <t indent="0" pn="section-1-2">
+ Per Domain Name System (DNS) terminology <xref target="RFC1035"
format="default" sectionFormat="of" derivedContent="RFC1035"/>, GNS roughly
follows the idea of a local
+ root zone deployment (see <xref target="RFC8806" format="default"
sectionFormat="of" derivedContent="RFC8806"/>), with the
+ difference that the design encourages alternative roots and
+ does not expect all deployments to use the same or any specific
+ root zone. In the GNS reference implementation, users can
+ autonomously and freely delegate control of names to zones
+ through their local configurations.
+ GNS expects each user to be in control of their setup.
+ By following the guidelines in <xref target="namespace_ambiguity"
format="default" sectionFormat="of" derivedContent="Section 9.10"/>,
+ users should manage to avoid any confusion as to how names are
+ resolved.
+ </t>
+ <t indent="0" pn="section-1-3">
+ Name resolution and zone dissemination are based on the
+ principle of a petname system where users can assign local
+ names to zones. The GNS has its roots in ideas from the Simple
+ Distributed Security Infrastructure <xref target="SDSI"
format="default" sectionFormat="of" derivedContent="SDSI"/>,
+ enabling the decentralized mapping of secure identifiers to
+ memorable names. One of the first academic descriptions of the
+ cryptographic ideas behind GNS can be found in <xref target="GNS"
format="default" sectionFormat="of" derivedContent="GNS"/>.
+ </t>
+ <t indent="0" pn="section-1-4">
+ This document defines the normative wire format of resource
+ records, resolution processes, cryptographic routines, and
+ security and privacy considerations for use by implementers.
+ </t>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-1.1">
+ <name slugifiedName="name-requirements-notation">Requirements
Notation</name>
+ <t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>",
"<bcp14>MUST NOT</bcp14>",
+ "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
+ "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
+ "<bcp14>SHOULD NOT</bcp14>",
+ "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
+ "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
+ are to be interpreted as described in BCP 14
+ <xref target="RFC2119" format="default" sectionFormat="of"
derivedContent="RFC2119"/> <xref target="RFC8174" format="default"
sectionFormat="of" derivedContent="RFC8174"/> when, and only
+ when, they appear in all capitals, as shown here.</t>
+ </section>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
+ <name slugifiedName="name-terminology">Terminology</name>
+ <dl newline="false" indent="3" spacing="normal" pn="section-2-1">
+ <dt pn="section-2-1.1">Apex Label:</dt>
+ <dd pn="section-2-1.2">
+ This type of label is used to publish resource
+ records in a zone that can be resolved without providing a specific
+ label. It is the GNS method for providing what is called the "zone
apex" in DNS
+ <xref target="RFC4033" format="default" sectionFormat="of"
derivedContent="RFC4033"/>.
+ The apex label is represented using the character U+0040 ("@" without
the quotes).
+ </dd>
+ <dt pn="section-2-1.3">Application:</dt>
+ <dd pn="section-2-1.4">
+ An application is a component that uses a GNS implementation
+ to resolve names into records and processes its contents.
+ </dd>
+ <dt pn="section-2-1.5">Blinded Zone Key:</dt>
+ <dd pn="section-2-1.6">
+ A blinded zone key is a key derived from a zone key and a label.
+ The zone key and any blinded zone key derived from it are unlinkable
+ without knowledge of the specific label used for the derivation.
+ </dd>
+ <dt pn="section-2-1.7">Extension Label:</dt>
+ <dd pn="section-2-1.8">
+ This type of label is used to refer to the authoritative zone that
the record is in.
+ The primary use for the extension label is in redirections where the
redirection
+ target is defined relative to the authoritative zone of the
redirection
+ record (see <xref target="gnsrecords_redirect" format="default"
sectionFormat="of" derivedContent="Section 5.2"/>).
+ The extension label is represented using the character U+002B ("+"
without the quotes).
+ </dd>
+ <dt pn="section-2-1.9">Label Separator:</dt>
+ <dd pn="section-2-1.10">
+ Labels in a name are separated using the label separator U+002E
+ ("." without the quotes).
+ In GNS, except for zone Top-Level Domains (zTLDs)
+ (see below) and boxed records (see <xref target="gnsrecords_box"
format="default" sectionFormat="of" derivedContent="Section 5.3.3"/>),
+ every label separator in a name indicates delegation to another zone.
+ </dd>
+ <dt pn="section-2-1.11">Label:</dt>
+ <dd pn="section-2-1.12">
+ A GNS label is a label as defined in <xref target="RFC8499"
format="default" sectionFormat="of" derivedContent="RFC8499"/>.
+ Labels are UTF-8 strings in Unicode
+ Normalization Form C (NFC) <xref target="Unicode-UAX15"
format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.
+ The apex label and the extension label have
+ special purposes in the resolution protocol that are defined
+ in the rest of this document.
+ Zone administrators <bcp14>MAY</bcp14> disallow certain labels that
+ might be easily confused with other labels through registration
policies
+ (see also <xref target="security_abuse" format="default"
sectionFormat="of" derivedContent="Section 9.4"/>).
+ </dd>
+ <dt pn="section-2-1.13">Name:</dt>
+ <dd pn="section-2-1.14">
+ A name in GNS is a domain name as defined in <xref target="RFC8499"
format="default" sectionFormat="of" derivedContent="RFC8499"/>:
+ names are UTF-8 strings <xref target="RFC3629" format="default"
sectionFormat="of" derivedContent="RFC3629"/> consisting of an
+ ordered list of labels concatenated with a label separator.
+ Names are resolved starting from the rightmost label.
+ GNS does not impose length restrictions on names or labels.
+ However, applications <bcp14>MAY</bcp14> ensure that name and label
lengths are
+ compatible with DNS and, in particular, Internationalized Domain
Names for
+ Applications (IDNA) <xref target="RFC5890" format="default"
sectionFormat="of" derivedContent="RFC5890"/>.
+ In the spirit of <xref target="RFC5895" format="default"
sectionFormat="of" derivedContent="RFC5895"/>, applications <bcp14>MAY</bcp14>
preprocess
+ names and labels to ensure compatibility with DNS or support
+ specific user expectations -- for example, according to
+ <xref target="Unicode-UTS46" format="default" sectionFormat="of"
derivedContent="Unicode-UTS46"/>.
+ A GNS name may be indistinguishable from a DNS name, and care must
+ be taken by applications and implementers when handling GNS names
+ (see <xref target="namespace_ambiguity" format="default"
sectionFormat="of" derivedContent="Section 9.10"/>).
+ In order to avoid misinterpretation of example domains with (reserved)
+ DNS domains, this document uses the suffix ".gns.alt" in compliance
with
+ <xref target="RFC9476" format="default" sectionFormat="of"
derivedContent="RFC9476"/>. ".gns.alt" is also registered in the GANA ".alt
Subdomains" registry
+ <xref target="GANA" format="default" sectionFormat="of"
derivedContent="GANA"/>.
+ </dd>
+ <dt pn="section-2-1.15">Resolver:</dt>
+ <dd pn="section-2-1.16">
+ In this document, a resolver is the component of a GNS implementation
that provides
+ the recursive name resolution logic defined in
+ <xref target="resolution" format="default" sectionFormat="of"
derivedContent="Section 7"/>.
+ </dd>
+ <dt pn="section-2-1.17">Resource Record:</dt>
+ <dd pn="section-2-1.18">
+ A GNS resource record is the information associated with a label in a
+ GNS zone.
+ A GNS resource record contains information as defined by its
+ resource record type.
+ </dd>
+ <dt pn="section-2-1.19">Start Zone:</dt>
+ <dd pn="section-2-1.20">
+ In order to resolve any given GNS name, an initial Start Zone must be
+ determined for this name.
+ The Start Zone can be explicitly defined as part of the name using a
+ zTLD.
+ Otherwise, it is determined through a local suffix-to-zone mapping
+ (see <xref target="governance" format="default" sectionFormat="of"
derivedContent="Section 7.1"/>).
+ </dd>
+ <dt pn="section-2-1.21">Top-Level Domain (TLD):</dt>
+ <dd pn="section-2-1.22">
+ The rightmost part of a GNS name is a GNS TLD.
+ A GNS TLD can consist of one or more labels.
+ Unlike DNS TLDs (defined in <xref target="RFC8499" format="default"
sectionFormat="of" derivedContent="RFC8499"/>),
+ GNS does not expect all users to use the same global root zone.
Instead,
+ with the exception of zTLDs (see <xref target="zTLD" format="default"
sectionFormat="of" derivedContent="Section 4.1"/>),
+ GNS TLDs are typically part of the configuration of the local resolver
+ (see <xref target="governance" format="default" sectionFormat="of"
derivedContent="Section 7.1"/>) and thus might not be globally unique.
+ </dd>
+ <dt pn="section-2-1.23">Zone:</dt>
+ <dd pn="section-2-1.24">
+ A GNS zone contains authoritative information (resource records).
+ A zone is uniquely identified by its zone key. Unlike DNS zones,
+ a GNS zone does not need to have an SOA record under the apex label.
+ </dd>
+ <dt pn="section-2-1.25">Zone Key:</dt>
+ <dd pn="section-2-1.26">
+ The zone key is a key that uniquely identifies a zone.
+ It is usually a public key of an asymmetric key pair.
+ However, the established technical term "public key" is misleading,
+ as in GNS a zone key may be a shared secret
+ that should not be disclosed to unauthorized parties.
+ </dd>
+ <dt pn="section-2-1.27">Zone Key Derivation Function:</dt>
+ <dd pn="section-2-1.28">
+ The zone key derivation function (ZKDF) blinds a zone key using a
label.
+ </dd>
+ <dt pn="section-2-1.29">Zone Publisher:</dt>
+ <dd pn="section-2-1.30">
+ The zone publisher is the component of a GNS implementation that
provides
+ local zone management and publication as defined in
+ <xref target="publish" format="default" sectionFormat="of"
derivedContent="Section 6"/>.
+ </dd>
+ <dt pn="section-2-1.31">Zone Owner:</dt>
+ <dd pn="section-2-1.32">
+ The zone owner is the holder of the secret (typically a private key),
+ which (together with a label and a value to sign) allows the creation
of zone
+ signatures that can be validated against the respective blinded zone
key.
+ </dd>
+ <dt pn="section-2-1.33">Zone Top-Level Domain (zTLD):</dt>
+ <dd pn="section-2-1.34">
+ A GNS zTLD is a sequence of GNS labels at
+ the end of a GNS name. The zTLD encodes a zone type and
+ zone key of a zone (see <xref target="zTLD" format="default"
sectionFormat="of" derivedContent="Section 4.1"/>).
+ Due to the statistical uniqueness of zone keys, zTLDs are also
globally unique.
+ A zTLD label sequence can only be distinguished from ordinary TLD
label sequences
+ by attempting to decode the labels into a zone type and zone key.
+ </dd>
+ <dt pn="section-2-1.35">Zone Type:</dt>
+ <dd pn="section-2-1.36">
+ The type of a GNS zone determines the cipher system and binary
encoding
+ format of the zone key, blinded zone keys, and cryptographic
signatures.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="overview" numbered="true" removeInRFC="false"
toc="include" pn="section-3">
+ <name slugifiedName="name-overview">Overview</name>
+ <t indent="0" pn="section-3-1">
+ GNS exhibits the three properties that are commonly used to describe
+ a petname system:
+ </t>
+ <dl newline="true" indent="3" spacing="normal" pn="section-3-2">
+ <dt pn="section-3-2.1">
+ Global names through the concept of zTLDs:</dt>
+ <dd pn="section-3-2.2">As zones can be uniquely identified by their
zone keys
+ and are statistically unique, zTLDs are globally unique mappings to
zones.
+ Consequently, GNS domain names with a zTLD suffix are also globally
unique.
+ Names with zTLD suffixes are not memorable.</dd>
+ <dt pn="section-3-2.3">
+ Memorable petnames for zones:</dt>
+ <dd pn="section-3-2.4">Users can configure local, memorable references
to zones.
+ Such petnames serve as zTLD monikers that provide
+ convenient names for zones to the local operator.
+ The petnames may also be published as suggestions for other
+ users searching for a good label to use when referencing the
+ respective zone.</dd>
+ <dt pn="section-3-2.5">
+ A secure mapping from names to records:</dt>
+ <dd pn="section-3-2.6">GNS allows zone owners to map labels to
resource records or to
+ delegate authority of names in the subdomain induced by a label to
other zones.
+ Zone owners may choose to publish this information to make it
+ available to other users.
+ Mappings are encrypted and signed
+ using keys derived from the respective label before being published
in remote storage.
+ When names are resolved, signatures on resource records,
+ including delegations, are verified by the recursive resolver.</dd>
+ </dl>
+ <t indent="0" pn="section-3-3">
+ In the remainder of this document, the "implementer" refers to the
developer building
+ a GNS implementation that includes the resolver, zone publisher, and
+ supporting configuration such as Start Zones (see <xref
target="governance" format="default" sectionFormat="of" derivedContent="Section
7.1"/>).
+ </t>
+ <section anchor="names" numbered="true" removeInRFC="false"
toc="include" pn="section-3.1">
+ <name slugifiedName="name-names-and-zones">Names and Zones</name>
+ <t indent="0" pn="section-3.1-1">
+ It follows from the above that GNS does not support names that are
+ simultaneously global, secure, and memorable.
+ Instead, names are either global and not memorable or not globally
+ unique and memorable.
+ An example for a global name pointing to the record "example" in
+ a zone is as follows:
+ </t>
+ <sourcecode markers="false" pn="section-3.1-2">
+example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
+</sourcecode>
+ <t indent="0" pn="section-3.1-3">
+ Now consider the case where a user locally configured the petname
+ "pet.gns.alt" for the zone with the "example" record of the name
+ above.
+ The name "example.pet.gns.alt" would then point to the same record as
the
+ globally unique name above, but name resolution would only
+ work on the local system where the "pet.gns.alt" petname is
+ configured.
+ </t>
+ <t indent="0" pn="section-3.1-4">
+ The delegation of petnames and subsequent resolution of delegation
+ build on ideas from the Simple Distributed Security Infrastructure
+ <xref target="SDSI" format="default" sectionFormat="of"
derivedContent="SDSI"/>.
+ In GNS, any user can create and manage any number of zones
+ (see <xref target="zones" format="default" sectionFormat="of"
derivedContent="Section 4"/>) if their system provides a zone publisher
implementation.
+ For each zone, the zone type determines the respective set of
cryptographic operations
+ and the wire formats for encrypted data, public keys, and signatures.
+ A zone can be populated with mappings from labels to resource records
+ (see <xref target="rrecords" format="default" sectionFormat="of"
derivedContent="Section 5"/>) by its owner.
+ A label can be mapped to a delegation record; this results in the
+ corresponding subdomain being delegated to another zone. Circular
+ delegations are explicitly allowed, including delegating a subdomain
+ to its immediate parent zone. In
+ order to support (legacy) applications as well as to facilitate the
use
+ of petnames, GNS defines auxiliary record types in addition to
+ supporting existing DNS records.
+ </t>
+ </section>
+ <section anchor="publishing" numbered="true" removeInRFC="false"
toc="include" pn="section-3.2">
+ <name slugifiedName="name-publishing-binding-informat">Publishing
Binding Information</name>
+ <t indent="0" pn="section-3.2-1">
+ Zone contents are encrypted and signed
+ before being published in remote key-value storage (see <xref
target="publish" format="default" sectionFormat="of" derivedContent="Section
6"/>),
+ as illustrated in <xref target="figure_arch_publish" format="default"
sectionFormat="of" derivedContent="Figure 1"/>.
+ In this process, unique zone identification is hidden from the network
+ through the use of key blinding.
+ Key blinding allows the creation of signatures for zone contents
+ using a blinded public/private key pair.
+ This blinding is realized using a deterministic key
+ derivation from
+ the original zone key and corresponding private key using record
label values
+ as inputs from which blinding factors are derived.
+ Specifically, the zone owner can derive blinded private keys for each
record
+ set published under a label, and a
+ resolver can derive the corresponding blinded public keys.
+ It is expected that GNS implementations use decentralized remote
+ storage entities, such as distributed hash tables (DHTs), in order to
facilitate
+ availability within a network without the need for dedicated
infrastructure.
+ The specification of such a distributed or decentralized storage
entity is out of
+ scope for this document, but possible existing implementations
include those
+ based on <xref target="RFC7363" format="default" sectionFormat="of"
derivedContent="RFC7363"/>, <xref target="Kademlia" format="default"
sectionFormat="of" derivedContent="Kademlia"/>, or
+ <xref target="R5N" format="default" sectionFormat="of"
derivedContent="R5N"/>.
+ </t>
+ <figure anchor="figure_arch_publish" align="left"
suppress-title="false" pn="figure-1">
+ <name slugifiedName="name-an-example-diagram-of-two-h">An Example
Diagram of Two Hosts Publishing GNS Zones</name>
+ <artwork name="" type="" alt="" align="left" pn="section-3.2-2.1">
+ Host A | Remote | Host B
+ | Storage |
+ | |
+ | +---------+ |
+ | / /| |
+ Publish | +---------+ | | Publish
+ +-----------+ Records | | | | | Records +-----------+
+ | Zone |----------|->| Record | |<-|----------| Zone |
+ | Publisher | | | Storage | | | | Publisher |
+ +-----------+ | | |/ | +-----------+
+ A | +---------+ | A
+ | | | |
+ +---------+ | | +---------+
+ / | /| | | / | /|
+ +---------+ | | | +---------+ |
+ | | | | | | | |
+ | Local | | | | | Local | |
+ | Zones | | | | | Zones | |
+ | |/ | | | |/
+ +---------+ | | +---------+
+ </artwork>
+ </figure>
+ <t indent="0" pn="section-3.2-3">
+ A zone publisher implementation <bcp14>SHOULD</bcp14> be provided as
+ part of a GNS implementation to enable users to create and manage
zones.
+ If this functionality is not implemented, names can still be resolved
+ if zone keys for the initial step in the name resolution have been
+ configured (see <xref target="resolution" format="default"
sectionFormat="of" derivedContent="Section 7"/>) or if the names end with a
+ zTLD suffix.
+ </t>
+ </section>
+ <section anchor="resolving" numbered="true" removeInRFC="false"
toc="include" pn="section-3.3">
+ <name slugifiedName="name-resolving-names">Resolving Names</name>
+ <t indent="0" pn="section-3.3-1">
+ Applications use the resolver to look up GNS names.
+ Starting from a configurable Start Zone, names are resolved by
following zone
+ delegations recursively, as illustrated in <xref
target="figure_arch_resolv" format="default" sectionFormat="of"
derivedContent="Figure 2"/>.
+ For each label in a name, the recursive GNS resolver
+ fetches the respective record set from the storage layer (see <xref
target="resolution" format="default" sectionFormat="of" derivedContent="Section
7"/>).
+ Without knowledge of the label values and the zone keys, the
+ different derived keys are unlinkable to both the original zone key
and each
+ other.
+ This prevents zone enumeration (except via expensive online
+ brute-force attacks): to confirm the affiliation of a
+ query or the corresponding encrypted record set with a
+ specific zone requires knowledge of both the zone key and the label,
+ neither of which is disclosed to remote storage by the protocol.
+ At the same time, the blinded zone key and digital signatures
+ associated with each encrypted record set allow resolvers and
oblivious remote
+ storage to verify the integrity of the published information
+ without disclosing anything about the originating zone or the record
sets.
+ </t>
+ <figure anchor="figure_arch_resolv" align="left"
suppress-title="false" pn="figure-2">
+ <name slugifiedName="name-high-level-view-of-the-gns-">High-Level
View of the GNS Resolution Process</name>
+ <artwork name="" type="" alt="" align="left" pn="section-3.3-2.1">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ Name +----------+ Recursive | | | |
+| | Lookup | | Resolution | | Record | |
+|Application|--------->| Resolver |-------------|->| Storage | |
+| |<---------| |<------------|--| |/
++-----------+ Results +----------+ Intermediate| +---------+
+ A Results |
+ | |
+ +---------+ |
+ / | /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ </section>
+ </section>
+ <section anchor="zones" numbered="true" removeInRFC="false" toc="include"
pn="section-4">
+ <name slugifiedName="name-zones">Zones</name>
+ <t indent="0" pn="section-4-1">
+ A zone in GNS is uniquely identified by its zone type (ztype) and zone
key.
+ Each zone can be referenced by its zTLD
+ (see <xref target="zTLD" format="default" sectionFormat="of"
derivedContent="Section 4.1"/>), which is a string that encodes the zone type
and zone key.
+ The ztype is a unique 32-bit number that corresponds to
+ a resource record type number identifying a delegation record type
+ in the GANA "GNS Record Types" registry <xref target="GANA"
format="default" sectionFormat="of" derivedContent="GANA"/>.
+ The ztype is a unique identifier for the set cryptographic functions
+ of the zone and the format of the delegation record type.
+ Any ztype registration <bcp14>MUST</bcp14> define the following set of
cryptographic functions:
+ </t>
+ <dl newline="true" indent="3" spacing="normal" pn="section-4-2">
+ <dt pn="section-4-2.1">KeyGen() -> d, zkey</dt>
+ <dd pn="section-4-2.2">
+ A function for generating a new private key d and
+ the corresponding public zone key zkey.
+ </dd>
+ <dt pn="section-4-2.3">ZKDF(zkey, label) -> zkey'</dt>
+ <dd pn="section-4-2.4">
+ A ZKDF that blinds a zone key zkey
+ using a label. zkey and zkey' must be unlinkable. Furthermore,
+ blinding zkey with different values for the label must result
+ in different, unlinkable zkey' values.
+ </dd>
+ <dt pn="section-4-2.5">S-Encrypt(zkey, label, expiration, plaintext)
-> ciphertext</dt>
+ <dd pn="section-4-2.6">
+ A symmetric encryption function that encrypts the plaintext
+ to derive ciphertext based on key material derived from the zone key
zkey,
+ a label, and an expiration timestamp.
+ In order to leverage performance-enhancing caching features of certain
+ underlying storage entities -- in particular, DHTs -- a deterministic
encryption
+ scheme is recommended.
+ </dd>
+ <dt pn="section-4-2.7">S-Decrypt(zkey, label, expiration, ciphertext)
-> plaintext</dt>
+ <dd pn="section-4-2.8">
+ A symmetric decryption function that decrypts the ciphertext
+ into plaintext based on key material derived from the zone key,
+ a label, and an expiration timestamp.
+ </dd>
+ <dt pn="section-4-2.9">Sign(d, message) -> signature</dt>
+ <dd pn="section-4-2.10">
+ A function for signing a message using the private
+ key d, yielding an unforgeable cryptographic signature.
+ In order to leverage performance-enhancing caching features of certain
+ underlying storage entities -- in particular, DHTs -- a deterministic
signature
+ scheme is recommended.
+ </dd>
+ <dt pn="section-4-2.11">Verify(zkey, message, signature) ->
boolean</dt>
+ <dd pn="section-4-2.12">
+ A function for verifying that the signature was created using
+ the private key d corresponding to the zone key zkey
+ where d,zkey := KeyGen().
+ The function returns a boolean value of "TRUE" if the signature is
valid
+ and "FALSE" otherwise.
+ </dd>
+ <dt pn="section-4-2.13">SignDerived(d, label, message) ->
signature</dt>
+ <dd pn="section-4-2.14">
+ A function for signing a message (typically encrypted record data)
that
+ can be verified using the derived zone key zkey' := ZKDF(zkey, label).
+ In order to leverage performance-enhancing caching features of certain
+ underlying storage entities -- in particular, DHTs -- a deterministic
signature
+ scheme is recommended.
+ </dd>
+ <dt pn="section-4-2.15">VerifyDerived(zkey', message, signature) ->
boolean</dt>
+ <dd pn="section-4-2.16">
+ A function for verifying the signature using the derived zone key
+ zkey' := ZKDF(zkey, label). The function returns a boolean value
+ of "TRUE" if the signature is valid and "FALSE" otherwise. Depending
+ on the signature scheme used, this function can be identical to
+ the Verify() function.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-4-3">
+ The cryptographic functions of the default ztypes are specified with
+ their corresponding delegation records as discussed in <xref
target="gnsrecords_delegation" format="default" sectionFormat="of"
derivedContent="Section 5.1"/>.
+ In order to support cryptographic agility, additional ztypes
<bcp14>MAY</bcp14>
+ be defined in the future that replace or update the default ztypes
defined in this
+ document.
+ All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone
delegation
+ record types in the GANA "GNS Record Types" registry (see <xref
target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>).
+ When defining new record types, the cryptographic security
considerations
+ of this document -- in particular, <xref target="security_cryptography"
format="default" sectionFormat="of" derivedContent="Section 9.3"/> -- apply.
+ </t>
+ <section anchor="zTLD" numbered="true" removeInRFC="false" toc="include"
pn="section-4.1">
+ <name slugifiedName="name-zone-top-level-domain-ztld">Zone Top-Level
Domain (zTLD)</name>
+ <t indent="0" pn="section-4.1-1">
+ A zTLD is a string that encodes the
+ zone type and zone key into a domain name suffix.
+ A zTLD is used as a globally unique reference to a
+ zone in the process of name resolution.
+ It is created by encoding a binary concatenation of the zone type and
+ zone key (see <xref target="figure_zid" format="default"
sectionFormat="of" derivedContent="Figure 3"/>).
+ The used encoding is a variation of the Crockford Base32 encoding
+ <xref target="CrockfordB32" format="default" sectionFormat="of"
derivedContent="CrockfordB32"/> called Base32GNS.
+ The encoding and decoding symbols for Base32GNS, including this
+ variation, are defined in <xref target="CrockfordB32Encode"
format="default" sectionFormat="of" derivedContent="Table 4"/>, found in <xref
target="app-c" format="default" sectionFormat="of" derivedContent="Appendix
C"/>.
+ The functions for encoding and decoding based on <xref
target="CrockfordB32Encode" format="default" sectionFormat="of"
derivedContent="Table 4"/> are called
+ Base32GNS-Encode and Base32GNS-Decode, respectively.
+ </t>
+ <figure anchor="figure_zid" align="left" suppress-title="false"
pn="figure-3">
+ <name slugifiedName="name-the-binary-representation-o">The Binary
Representation of the zTLD</name>
+ <artwork name="" type="" alt="" align="left" pn="section-4.1-2.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <t indent="0" pn="section-4.1-3">
+ The ZONE TYPE <bcp14>MUST</bcp14> be encoded in network byte order.
The format
+ of the ZONE KEY depends entirely on the ZONE TYPE.
+ </t>
+ <t indent="0" pn="section-4.1-4">
+ Consequently, a zTLD is encoded and decoded as follows:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-4.1-5">
+zTLD := Base32GNS-Encode(ztype||zkey)
+ztype||zkey := Base32GNS-Decode(zTLD)
+ </artwork>
+ <t indent="0" pn="section-4.1-6">
+ where "||" is the concatenation operator.
+ </t>
+ <t indent="0" pn="section-4.1-7">
+ The zTLD can be used "as is" as a rightmost label in a GNS name.
+ If an application wants to ensure DNS compatibility of the name,
+ it <bcp14>MAY</bcp14> also represent the zTLD as follows:
+ if the zTLD is less than or equal to 63 characters, it can
+ be used as a zTLD as is.
+ If the zTLD is longer than 63 characters, the
+ zTLD is divided into smaller labels separated by the label separator.
+ Here, the most significant bytes of the "ztype||zkey" concatenation
+ must be contained in the rightmost label of the resulting string and
+ the least significant bytes in the leftmost label of the resulting
string. This allows the
+ resolver to determine the ztype and zTLD length from the rightmost
+ label and to subsequently determine how many labels the zTLD should
span.
+ A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs
+ in DNS-compatible label lengths.
+ For example, assuming a zTLD of 130 characters, the division is as
follows:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-4.1-8">
+zTLD[126..129].zTLD[63..125].zTLD[0..62]
+ </artwork>
+ </section>
+ <section anchor="revocation" numbered="true" removeInRFC="false"
toc="include" pn="section-4.2">
+ <name slugifiedName="name-zone-revocation">Zone Revocation</name>
+ <t indent="0" pn="section-4.2-1">
+ In order to revoke a zone key, a signed revocation message
<bcp14>MUST</bcp14> be
+ published.
+ This message <bcp14>MUST</bcp14> be signed using the private key of
the zone.
+ The revocation message is broadcast to the network.
+ The specification of the broadcast mechanism is out of scope for this
+ document.
+ A possible broadcast mechanism for efficient flooding in a distributed
+ network is implemented in <xref target="GNUnet" format="default"
sectionFormat="of" derivedContent="GNUnet"/>.
+ Alternatively, revocation messages could also be distributed via a
+ distributed ledger or a trusted central server.
+ To prevent
+ flooding attacks, the revocation message <bcp14>MUST</bcp14> contain
a proof of work
+ (PoW).
+ The revocation message, including the PoW, <bcp14>MAY</bcp14> be
calculated
+ ahead of time to support timely revocation.
+ </t>
+ <t indent="0" pn="section-4.2-2">
+ For all occurrences below, "Argon2id" is the password-based key
+ derivation function as defined in <xref target="RFC9106"
format="default" sectionFormat="of" derivedContent="RFC9106"/>. For the
+ PoW calculations, the algorithm is instantiated with the
+ following parameters:
+ </t>
+ <dl newline="false" indent="3" spacing="normal" pn="section-4.2-3">
+ <dt pn="section-4.2-3.1">S:</dt>
+ <dd pn="section-4.2-3.2">The salt. Fixed 16-byte string:
"GnsRevocationPow"</dd>
+ <dt pn="section-4.2-3.3">t:</dt>
+ <dd pn="section-4.2-3.4">Number of iterations: 3</dd>
+ <dt pn="section-4.2-3.5">m:</dt>
+ <dd pn="section-4.2-3.6">Memory size in KiB: 1024</dd>
+ <dt pn="section-4.2-3.7">T:</dt>
+ <dd pn="section-4.2-3.8">Output length of hash in bytes: 64</dd>
+ <dt pn="section-4.2-3.9">p:</dt>
+ <dd pn="section-4.2-3.10">Parallelization parameter: 1</dd>
+ <dt pn="section-4.2-3.11">v:</dt>
+ <dd pn="section-4.2-3.12">Algorithm version: 0x13</dd>
+ <dt pn="section-4.2-3.13">y:</dt>
+ <dd pn="section-4.2-3.14">Algorithm type (Argon2id): 2</dd>
+ <dt pn="section-4.2-3.15">X:</dt>
+ <dd pn="section-4.2-3.16">Unused</dd>
+ <dt pn="section-4.2-3.17">K:</dt>
+ <dd pn="section-4.2-3.18">Unused</dd>
+ </dl>
+ <t indent="0" pn="section-4.2-4">
+ <xref target="figure_revocation" format="default" sectionFormat="of"
derivedContent="Figure 4"/> illustrates the format
+ of the data "P" on which the PoW is calculated.
+ </t>
+ <figure anchor="figure_revocation" align="left" suppress-title="false"
pn="figure-4">
+ <name slugifiedName="name-the-format-of-the-pow-data">The Format of
the PoW Data</name>
+ <artwork name="" type="" alt="" align="left" pn="section-4.2-5.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW |
++-----------------------------------------------+
+| TIMESTAMP |
++-----------------------------------------------+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-4.2-6">
+ <dt pn="section-4.2-6.1">POW:</dt>
+ <dd pn="section-4.2-6.2">
+ A 64-bit value that is a solution to the PoW. In network byte order.
+ </dd>
+ <dt pn="section-4.2-6.3">TIMESTAMP:</dt>
+ <dd pn="section-4.2-6.4">
+ Denotes the absolute 64-bit date when the revocation was computed.
+ In microseconds since midnight (0 hour), January 1, 1970 UTC in
network
+ byte order.
+ </dd>
+ <dt pn="section-4.2-6.5">ZONE TYPE:</dt>
+ <dd pn="section-4.2-6.6">
+ The 32-bit zone type in network byte order.
+ </dd>
+ <dt pn="section-4.2-6.7">ZONE KEY:</dt>
+ <dd pn="section-4.2-6.8">
+ The 256-bit public key zkey of the zone that is being revoked.
+ The wire format of this value is defined by the ZONE TYPE.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-4.2-7">
+ Usually, PoW schemes require that one POW value be found, such that
+ a specific number of leading zeroes are found in the hash result.
+ This number is then referred to as the difficulty of the PoW.
+ In order to reduce the variance in time it takes to calculate the
+ PoW, a valid GNS revocation requires that a number of different PoWs
(Z, as defined below)
+ must be found that on average have at least D leading zeroes.
+ </t>
+ <t indent="0" pn="section-4.2-8">
+ Given an average difficulty of D, the proofs have an
+ expiration time of EPOCH. Applications <bcp14>MAY</bcp14> calculate
proofs
+ with a difficulty that is higher than D by providing POW
+ values where there are (on average) more than D bits of leading
zeroes.
+ With each additional bit of difficulty, the
+ lifetime of the proof is prolonged by another EPOCH.
+ Consequently, by calculating a more difficult PoW, the lifetime of the
+ proof -- and thus the persistence of the revocation message --
+ can be increased on demand by the zone owner.
+ </t>
+ <t indent="0" pn="section-4.2-9">
+ The parameters are defined as follows:
+ </t>
+ <dl newline="false" indent="3" spacing="normal" pn="section-4.2-10">
+ <dt pn="section-4.2-10.1">Z:</dt>
+ <dd pn="section-4.2-10.2">The number of PoWs that are required. Its
value is fixed at 32.</dd>
+ <dt pn="section-4.2-10.3">D:</dt>
+ <dd pn="section-4.2-10.4">The lower limit of the average difficulty.
Its value is fixed at 22.</dd>
+ <dt pn="section-4.2-10.5">EPOCH:</dt>
+ <dd pn="section-4.2-10.6">A single epoch. Its value is fixed at 365
days in microseconds.</dd>
+ </dl>
+ <t indent="0" pn="section-4.2-11">
+ The revocation message wire format is illustrated in
+ <xref target="figure_revocationdata" format="default"
sectionFormat="of" derivedContent="Figure 5"/>.
+ </t>
+ <figure anchor="figure_revocationdata" align="left"
suppress-title="false" pn="figure-5">
+ <name slugifiedName="name-the-revocation-message-wire">The
Revocation Message Wire Format</name>
+ <artwork name="" type="" alt="" align="left" pn="section-4.2-12.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TTL |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_0 |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ... |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_(Z-1) |
++-----------------------------------------------+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+/ SIGNATURE /
+/ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-4.2-13">
+ <dt pn="section-4.2-13.1">TIMESTAMP:</dt>
+ <dd pn="section-4.2-13.2">
+ Denotes the absolute 64-bit date when the revocation was computed.
+ In microseconds since midnight (0 hour), January 1, 1970 UTC in
network
+ byte order. This is the same value as the timestamp used in the
+ individual PoW calculations.
+ </dd>
+ <dt pn="section-4.2-13.3">TTL:</dt>
+ <dd pn="section-4.2-13.4">
+ Denotes the relative 64-bit time to live of the record in
+ microseconds in network byte order.
+ The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1.
+ Given an average number of leading zeroes D', then the field value
+ <bcp14>MAY</bcp14> be increased up to (D'-D+1) * EPOCH * 1.1.
+ Validators <bcp14>MAY</bcp14> reject messages with lower or higher
+ values when received.
+ </dd>
+ <dt pn="section-4.2-13.5">POW_i:</dt>
+ <dd pn="section-4.2-13.6">
+ The values calculated as part of the PoW, in network byte order.
+ Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values.
+ To facilitate fast verification
+ of uniqueness, the POW values <bcp14>MUST</bcp14> be given in
strictly
+ monotonically increasing order in the message.
+ </dd>
+ <dt pn="section-4.2-13.7">ZONE TYPE:</dt>
+ <dd pn="section-4.2-13.8">
+ The 32-bit zone type corresponding to the zone key in network byte
order.
+ </dd>
+ <dt pn="section-4.2-13.9">ZONE KEY:</dt>
+ <dd pn="section-4.2-13.10">
+ The public key zkey of the zone that is being revoked and
+ the key to be used to verify SIGNATURE.
+ </dd>
+ <dt pn="section-4.2-13.11">SIGNATURE:</dt>
+ <dd pn="section-4.2-13.12">
+ A signature over a timestamp and the zone zkey of the zone
+ that is revoked and corresponds to the key used in the PoW.
+ The signature is created using the Sign() function of
+ the cryptosystem of the zone and the private key
+ (see <xref target="zones" format="default" sectionFormat="of"
derivedContent="Section 4"/>).
+ </dd>
+ </dl>
+ <t indent="0" pn="section-4.2-14">
+ The signature in the revocation message covers a 32-bit header
+ prefixed to the TIMESTAMP, ZONE TYPE, and ZONE KEY fields.
+ The header includes the key length and signature purpose.
+ The wire format is illustrated
+ in <xref target="figure_revsigwithpseudo" format="default"
sectionFormat="of" derivedContent="Figure 6"/>.
+ </t>
+ <figure anchor="figure_revsigwithpseudo" align="left"
suppress-title="false" pn="figure-6">
+ <name slugifiedName="name-the-wire-format-of-the-revo">The Wire
Format of the Revocation Data for Signing</name>
+ <artwork name="" type="" alt="" align="left" pn="section-4.2-15.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE (0x03) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-4.2-16">
+ <dt pn="section-4.2-16.1">SIZE:</dt>
+ <dd pn="section-4.2-16.2">
+ A 32-bit value containing the length of the signed data in bytes
+ in network byte order.
+ </dd>
+ <dt pn="section-4.2-16.3">PURPOSE:</dt>
+ <dd pn="section-4.2-16.4">
+ A 32-bit signature purpose flag.
+ The value of this field <bcp14>MUST</bcp14> be 3.
+ The value is encoded in network byte order.
+ It defines the context in which
+ the signature is created so that it cannot be reused in other parts
+ of the protocol that might include possible future extensions.
+ The value of this field corresponds to an entry in the
+ GANA "GNUnet Signature Purposes" registry <xref target="GANA"
format="default" sectionFormat="of" derivedContent="GANA"/>.
+ </dd>
+ <dt pn="section-4.2-16.5">TIMESTAMP:</dt>
+ <dd pn="section-4.2-16.6">
+ Field as defined in the revocation message above.
+ </dd>
+ <dt pn="section-4.2-16.7">ZONE TYPE:</dt>
+ <dd pn="section-4.2-16.8">
+ Field as defined in the revocation message above.
+ </dd>
+ <dt pn="section-4.2-16.9">ZONE KEY:</dt>
+ <dd pn="section-4.2-16.10">Field as defined in the revocation
message above.</dd>
+ </dl>
+ <t indent="0" pn="section-4.2-17">
+ In order to validate a revocation, the following steps
<bcp14>MUST</bcp14> be taken:
+ </t>
+ <ol indent="adaptive" spacing="normal" start="1" type="1"
pn="section-4.2-18">
+ <li pn="section-4.2-18.1" derivedCounter="1.">The signature
<bcp14>MUST</bcp14> be verified against the zone key.</li>
+ <li pn="section-4.2-18.2" derivedCounter="2.">The set of POW values
<bcp14>MUST NOT</bcp14> contain duplicates; this <bcp14>MUST</bcp14> be checked
by verifying that the values are strictly monotonically increasing.</li>
+ <li pn="section-4.2-18.3" derivedCounter="3.">The average number of
leading zeroes D' resulting from the provided
+ POW values <bcp14>MUST</bcp14> be greater than or equal to D.
Implementers
+ <bcp14>MUST NOT</bcp14> use an integer data type to calculate or
represent D'.</li>
+ </ol>
+ <t indent="0" pn="section-4.2-19">
+ The TTL field in the revocation message is informational.
+ A revocation <bcp14>MAY</bcp14> be discarded without checking the POW
+ values or the signature if the TTL (in combination with TIMESTAMP)
+ indicates that the revocation has already expired.
+ The actual validity period of the
+ revocation <bcp14>MUST</bcp14> be determined by examining the leading
+ zeroes in the POW values.
+ </t>
+ <t indent="0" pn="section-4.2-20">
+ The validity period of the revocation is calculated as
+ (D'-D+1) * EPOCH * 1.1. The EPOCH is extended by
+ 10% in order to deal with poorly synchronized clocks.
+ The validity period added on top of the TIMESTAMP yields the
+ expiration date.
+ If the current time is after the expiration date, the
+ revocation is considered stale.
+ </t>
+ <t indent="0" pn="section-4.2-21">
+ Verified revocations <bcp14>MUST</bcp14> be stored locally.
+ The implementation <bcp14>MAY</bcp14> discard stale revocations and
+ evict them from the local store at any time.
+ </t>
+ <t indent="0" pn="section-4.2-22">
+ It is important that implementations broadcast received revocations
+ if they are valid and not stale.
+ Should the calculated validity period differ from the TTL field value,
+ the calculated value <bcp14>MUST</bcp14> be used as the TTL field
value
+ when forwarding the revocation message.
+ Systems might disagree on the current time, so implementations
+ <bcp14>MAY</bcp14> use stale but otherwise valid
+ revocations but <bcp14>SHOULD NOT</bcp14> broadcast them.
+ Forwarded stale revocations <bcp14>MAY</bcp14> be discarded by the
receiver.
+ </t>
+ <t indent="0" pn="section-4.2-23">
+ Any locally stored revocation <bcp14>MUST</bcp14> be considered during
+ delegation record processing (see <xref
target="delegation_processing" format="default" sectionFormat="of"
derivedContent="Section 7.3.4"/>).
+ </t>
+ </section>
+ </section>
+ <section anchor="rrecords" numbered="true" removeInRFC="false"
toc="include" pn="section-5">
+ <name slugifiedName="name-resource-records">Resource Records</name>
+ <t indent="0" pn="section-5-1">
+ A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism for
creating and managing local
+ zones as well as a persistence mechanism (such as a local database) for
resource
+ records.
+ A new local zone is established by selecting a zone type and creating a
+ zone key pair.
+ If this mechanism is not implemented,
+ no zones can be published in storage (see <xref target="publish"
format="default" sectionFormat="of" derivedContent="Section 6"/>)
+ and name resolution is limited to non-local Start Zones
+ (see <xref target="governance" format="default" sectionFormat="of"
derivedContent="Section 7.1"/>).
+ </t>
+ <t indent="0" pn="section-5-2">
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is illustrated in
+ <xref target="figure_gnsrecord" format="default" sectionFormat="of"
derivedContent="Figure 7"/>.
+ </t>
+ <figure anchor="figure_gnsrecord" align="left" suppress-title="false"
pn="figure-7">
+ <name slugifiedName="name-the-resource-record-wire-fo">The Resource
Record Wire Format</name>
+ <artwork name="" type="" alt="" align="left" pn="section-5-3.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | FLAGS | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
+/ /
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5-4">
+ <dt pn="section-5-4.1">EXPIRATION:</dt>
+ <dd pn="section-5-4.2">
+ Denotes the absolute 64-bit expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 UTC in
network
+ byte order.
+ </dd>
+ <dt pn="section-5-4.3">SIZE:</dt>
+ <dd pn="section-5-4.4">
+ Denotes the 16-bit size of the DATA field in bytes in network byte
+ order.
+ </dd>
+ <dt pn="section-5-4.5">FLAGS:</dt>
+ <dd pn="section-5-4.6">
+ A 16-bit field indicating special properties of the resource record.
+ The semantics of the different bits are defined below.
+ </dd>
+ <dt pn="section-5-4.7">TYPE:</dt>
+ <dd pn="section-5-4.8">
+ The 32-bit resource record type in
+ network byte order. This type can be one of the GNS resource
+ records as defined in <xref target="rrecords" format="default"
sectionFormat="of" derivedContent="Section 5"/>, a DNS record
+ type as defined in <xref target="RFC1035" format="default"
sectionFormat="of" derivedContent="RFC1035"/>, or any of the
+ complementary standardized DNS resource record types.
+ Note that values
+ below 2<sup>16</sup> are reserved for 16-bit DNS resource record
types allocated by IANA <xref target="RFC6895" format="default"
sectionFormat="of" derivedContent="RFC6895"/>.
+ Values above 2<sup>16</sup> are allocated by the
+ GANA "GNS Record Types" registry <xref target="GANA" format="default"
sectionFormat="of" derivedContent="GANA"/>.
+ </dd>
+ <dt pn="section-5-4.9">DATA:</dt>
+ <dd pn="section-5-4.10">
+ The variable-length resource record data payload. The content is
defined
+ by the
+ respective type of the resource record.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-5-5">
+ The FLAGS field is used to indicate special properties of the resource
record.
+ An application creating resource records <bcp14>MUST</bcp14> set all
bits
+ in FLAGS to 0 unless it specifically understands and
+ wants to set the respective flag.
+ As additional flags can be defined in future protocol versions,
+ if an application or implementation encounters a flag that it does not
+ recognize, the flag <bcp14>MUST</bcp14> be ignored. However, all
implementations
+ <bcp14>MUST</bcp14> understand the SHADOW and CRITICAL flags defined
below.
+ Any combination of the flags specified below is valid.
+ <xref target="figure_flag" format="default" sectionFormat="of"
derivedContent="Figure 8"/>
+ illustrates the flag distribution in the 16-bit FLAGS field of a
+ resource record:
+ </t>
+ <figure anchor="figure_flag" align="left" suppress-title="false"
pn="figure-8">
+ <name slugifiedName="name-the-resource-record-flag-wi">The Resource
Record Flag Wire Format</name>
+ <artwork name="" type="" alt="" align="left" pn="section-5-6.1">
+0 13 14 15
++--------...+-------------+-------+---------+
+| Reserved |SUPPLEMENTAL |SHADOW |CRITICAL |
++--------...+-------------+-------+---------+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5-7">
+ <dt pn="section-5-7.1">CRITICAL:</dt>
+ <dd pn="section-5-7.2">
+ If this flag is set, it indicates that processing is critical.
+ Implementations that do not support the record type or are otherwise
+ unable to process the record <bcp14>MUST</bcp14> abort resolution
upon encountering
+ the record in the resolution process.
+ </dd>
+ <dt pn="section-5-7.3">SHADOW:</dt>
+ <dd pn="section-5-7.4">
+ If this flag is set, this record <bcp14>MUST</bcp14> 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 storage.
+ This way, future values can propagate and can be
+ cached before the transition becomes active.
+ </dd>
+ <dt pn="section-5-7.5">SUPPLEMENTAL:</dt>
+ <dd pn="section-5-7.6">
+ This is a supplemental record. It is provided in addition to the
+ other records. This flag indicates that this record is not explicitly
+ managed alongside the other records under the respective name but
+ might be useful for the application.
+ </dd>
+ </dl>
+ <section anchor="gnsrecords_delegation" numbered="true"
removeInRFC="false" toc="include" pn="section-5.1">
+ <name slugifiedName="name-zone-delegation-records">Zone Delegation
Records</name>
+ <t indent="0" pn="section-5.1-1">
+ This section defines the initial set of zone delegation record types.
+ Any implementation <bcp14>SHOULD</bcp14> support all zone types defined
here and
+ <bcp14>MAY</bcp14> support any number of additional delegation records
defined in
+ the GANA "GNS Record Types" registry (see <xref target="GANA"
format="default" sectionFormat="of" derivedContent="GANA"/>).
+ Not supporting some zone types will result in resolution failures if
+ the respective zone type is encountered.
+ This can be a valid choice if some zone delegation record types have
been
+ determined to be cryptographically insecure.
+ Zone delegation records <bcp14>MUST NOT</bcp14> be stored or published
+ under the apex label.
+ A zone delegation record type value is the same as the respective ztype
+ value.
+ The ztype defines the cryptographic primitives for the zone that is
+ being delegated to.
+ A zone delegation record payload contains the public key of
+ the zone to delegate to.
+ A zone delegation record <bcp14>MUST</bcp14> have the CRITICAL flag set
+ and <bcp14>MUST</bcp14> be the only non-supplemental record under a
label.
+ There <bcp14>MAY</bcp14> be inactive records of the same type that have
+ the SHADOW flag set in order to facilitate smooth key rollovers.
+ </t>
+ <t indent="0" pn="section-5.1-2">
+ In the following, "||" is the concatenation operator of two byte
strings.
+ The algorithm specification uses character strings such as GNS labels or
+ constant values.
+ When used in concatenations or as input to functions, the
+ zero terminator of the character strings <bcp14>MUST NOT</bcp14> be
+ included.
+ </t>
+ <section anchor="gnsrecords_pkey" numbered="true" removeInRFC="false"
toc="include" pn="section-5.1.1">
+ <name slugifiedName="name-pkey">PKEY</name>
+ <t indent="0" pn="section-5.1.1-1">
+ In GNS, a delegation of a label to a zone of type "PKEY" is
+ represented through a PKEY record. The PKEY DATA entry wire format
is illustrated in <xref target="figure_pkeyrecord" format="default"
sectionFormat="of" derivedContent="Figure 9"/>.
+ </t>
+ <figure anchor="figure_pkeyrecord" align="left"
suppress-title="false" pn="figure-9">
+ <name slugifiedName="name-the-pkey-wire-format">The PKEY Wire
Format</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.1.1-2.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.1.1-3">
+ <dt pn="section-5.1.1-3.1">PUBLIC KEY:</dt>
+ <dd pn="section-5.1.1-3.2">
+ A 256-bit Ed25519 public key.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-5.1.1-4">
+ For PKEY zones, the zone key material is derived using the
+ curve parameters of the twisted Edwards representation
+ of Curve25519 <xref target="RFC7748" format="default"
sectionFormat="of" derivedContent="RFC7748"/> (the reasoning behind choosing
+ this curve can be found in <xref target="security_cryptography"
format="default" sectionFormat="of" derivedContent="Section 9.3"/>)
+ with the ECDSA scheme <xref target="RFC6979" format="default"
sectionFormat="of" derivedContent="RFC6979"/>.
+ The following naming convention is used for the cryptographic
primitives of PKEY zones:
+ </t>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.1.1-5">
+ <dt pn="section-5.1.1-5.1">d:</dt>
+ <dd pn="section-5.1.1-5.2">
+ A 256-bit Ed25519 private key (clamped private scalar).
+ </dd>
+ <dt pn="section-5.1.1-5.3">zkey:</dt>
+ <dd pn="section-5.1.1-5.4">
+ The Ed25519 public zone key corresponding to d.
+ </dd>
+ <dt pn="section-5.1.1-5.5">p:</dt>
+ <dd pn="section-5.1.1-5.6">
+ The prime of edwards25519 as defined in <xref target="RFC7748"
format="default" sectionFormat="of" derivedContent="RFC7748"/>, i.e.,
+ 2<sup>255</sup> - 19.
+ </dd>
+ <dt pn="section-5.1.1-5.7">G:</dt>
+ <dd pn="section-5.1.1-5.8">
+ The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as
defined in
+ <xref target="RFC7748" format="default" sectionFormat="of"
derivedContent="RFC7748"/>.
+ </dd>
+ <dt pn="section-5.1.1-5.9">L:</dt>
+ <dd pn="section-5.1.1-5.10">
+ The order of the prime-order subgroup of edwards25519 as defined in
<xref target="RFC7748" format="default" sectionFormat="of"
derivedContent="RFC7748"/>.
+ </dd>
+ <dt pn="section-5.1.1-5.11">KeyGen():</dt>
+ <dd pn="section-5.1.1-5.12">The generation of the private
+ scalar d and the curve point zkey := d*G (where G is the group
generator
+ of the elliptic curve) as defined in <xref target="RFC6979"
sectionFormat="of" section="2.2" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc6979#section-2.2";
derivedContent="RFC6979"/> represents the KeyGen() function.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-5.1.1-6">
+ The zone type and zone key of a PKEY are 4 + 32 bytes in length. This
means that
+ a zTLD will always fit into a single label and does
+ not need any further conversion.
+ Given a label, the output zkey' of the ZKDF(zkey, label) function is
+ calculated as follows for PKEY zones:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.1-7">
+ZKDF(zkey, label):
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ zkey' := (h mod L) * zkey
+ return zkey'
+ </artwork>
+ <t indent="0" pn="section-5.1.1-8">
+ The PKEY cryptosystem uses an HMAC-based key derivation function
(HKDF) as defined in
+ <xref target="RFC5869" format="default" sectionFormat="of"
derivedContent="RFC5869"/>, using SHA-512 <xref target="RFC6234"
format="default" sectionFormat="of" derivedContent="RFC6234"/> for the
extraction
+ phase and SHA-256 <xref target="RFC6234" format="default"
sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
+ PRK_h is key material retrieved using an HKDF that uses the string
+ "key-derivation" as the salt and the zone key as the initial
+ keying material.
+ h is the 512-bit HKDF expansion result and must be interpreted in
+ network byte order. The expansion information input is
+ a concatenation of the label and the string "gns".
+ The multiplication of zkey with h in ZKDF() is a point multiplication,
+ while the multiplication of d with h in SignDerived() below is a
scalar multiplication.
+ </t>
+ <t indent="0" pn="section-5.1.1-9">
+ The Sign() and Verify() functions
+ for PKEY zones are implemented using 512-bit ECDSA deterministic
+ signatures as specified in <xref target="RFC6979" format="default"
sectionFormat="of" derivedContent="RFC6979"/>.
+ The same functions can be used for derived keys:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.1-10">
+SignDerived(d, label, message):
+ zkey := d * G
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ d' := (h * d) mod L
+ return Sign(d', message)
+ </artwork>
+ <t indent="0" pn="section-5.1.1-11">
+ A signature is valid for the derived public key zkey' := ZKDF(zkey,
label) if the following holds:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.1-12">
+VerifyDerived(zkey', message, signature):
+ return Verify(zkey', message, signature)
+ </artwork>
+ <t indent="0" pn="section-5.1.1-13">
+ The S-Encrypt() and S-Decrypt() functions use AES in counter mode
+ as defined in <xref target="MODES" format="default"
sectionFormat="of" derivedContent="MODES"/> (CTR-AES256):
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.1-14">
+S-Encrypt(zkey, label, expiration, plaintext):
+ PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
+ BLOCK_COUNTER := 0x0000000000000001
+ IV := NONCE || expiration || BLOCK_COUNTER
+ return CTR-AES256(K, IV, plaintext)
+
+S-Decrypt(zkey, label, expiration, ciphertext):
+ PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
+ BLOCK_COUNTER := 0x0000000000000001
+ IV := NONCE || expiration || BLOCK_COUNTER
+ return CTR-AES256(K, IV, ciphertext)
+ </artwork>
+ <t indent="0" pn="section-5.1.1-15">
+ The key K and counter Initialization Vector (IV) are derived from
+ the record label and the zone key zkey, using an HKDF as defined in
<xref target="RFC5869" format="default" sectionFormat="of"
derivedContent="RFC5869"/>.
+ SHA-512 <xref target="RFC6234" format="default" sectionFormat="of"
derivedContent="RFC6234"/> is used for the
+ extraction phase and SHA-256 <xref target="RFC6234" format="default"
sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
+ The output keying material is 32 bytes (256 bits) for the symmetric
+ key and 4 bytes (32 bits) for the NONCE.
+ The symmetric key K is a 256-bit AES key <xref target="RFC3826"
format="default" sectionFormat="of" derivedContent="RFC3826"/>.
+ </t>
+ <t indent="0" pn="section-5.1.1-16">
+ The nonce is combined with a 64-bit IV and a
+ 32-bit block counter as defined in <xref target="RFC3686"
format="default" sectionFormat="of" derivedContent="RFC3686"/>.
+ The block counter begins with a value of 1, and it is incremented
+ to generate subsequent portions of the key stream.
+ The block counter is a 32-bit integer value in network byte order.
+ The format of the counter IV used by the S-Encrypt() and S-Decrypt()
+ functions is illustrated in
+ <xref target="figure_hkdf_ivs_pkey" format="default"
sectionFormat="of" derivedContent="Figure 10"/>.
+ </t>
+ <figure anchor="figure_hkdf_ivs_pkey" align="left"
suppress-title="false" pn="figure-10">
+ <name slugifiedName="name-structure-of-the-counter-iv">Structure
of the Counter IV as Used in S-Encrypt() and
+ S-Decrypt()</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.1.1-17.1">
+0 8 16 24 32
++-----+-----+-----+-----+
+| NONCE |
++-----+-----+-----+-----+
+| EXPIRATION |
+| |
++-----+-----+-----+-----+
+| BLOCK COUNTER |
++-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ </section>
+ <section anchor="gnsrecords_edkey" numbered="true" removeInRFC="false"
toc="include" pn="section-5.1.2">
+ <name slugifiedName="name-edkey">EDKEY</name>
+ <t indent="0" pn="section-5.1.2-1">
+ In GNS, a delegation of a label to a zone of type "EDKEY" is
+ represented through an EDKEY record.
+ The EDKEY DATA entry wire format
+ is illustrated in <xref target="figure_edkeyrecord" format="default"
sectionFormat="of" derivedContent="Figure 11"/>.
+ </t>
+ <figure anchor="figure_edkeyrecord" align="left"
suppress-title="false" pn="figure-11">
+ <name slugifiedName="name-the-edkey-data-wire-format">The EDKEY
DATA Wire Format</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.1.2-2.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.1.2-3">
+ <dt pn="section-5.1.2-3.1">PUBLIC KEY:</dt>
+ <dd pn="section-5.1.2-3.2">
+ A 256-bit EdDSA zone key.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-5.1.2-4">
+ For EDKEY zones, the zone key material is derived using the
+ curve parameters of the twisted Edwards representation
+ of Curve25519 <xref target="RFC7748" format="default"
sectionFormat="of" derivedContent="RFC7748"/> (a.k.a. Ed25519)
+ with the Ed25519 scheme <xref target="ed25519" format="default"
sectionFormat="of" derivedContent="ed25519"/> as specified in
+ <xref target="RFC8032" format="default" sectionFormat="of"
derivedContent="RFC8032"/>.
+ The following naming convention is used for the
+ cryptographic primitives of EDKEY zones:
+ </t>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.1.2-5">
+ <dt pn="section-5.1.2-5.1">d:</dt>
+ <dd pn="section-5.1.2-5.2">
+ A 256-bit EdDSA private key.
+ </dd>
+ <dt pn="section-5.1.2-5.3">a:</dt>
+ <dd pn="section-5.1.2-5.4">
+ An integer derived from d using the SHA-512 hash function
+ as defined in <xref target="RFC8032" format="default"
sectionFormat="of" derivedContent="RFC8032"/>.
+ </dd>
+ <dt pn="section-5.1.2-5.5">zkey:</dt>
+ <dd pn="section-5.1.2-5.6">
+ The EdDSA public key corresponding to d. It is defined
+ as the curve point a*G where G is the
+ group generator of the elliptic curve
+ as defined in <xref target="RFC8032" format="default"
sectionFormat="of" derivedContent="RFC8032"/>.
+ </dd>
+ <dt pn="section-5.1.2-5.7">p:</dt>
+ <dd pn="section-5.1.2-5.8">
+ The prime of edwards25519 as defined in <xref target="RFC8032"
format="default" sectionFormat="of" derivedContent="RFC8032"/>, i.e.,
+ 2<sup>255</sup> - 19.
+ </dd>
+ <dt pn="section-5.1.2-5.9">G:</dt>
+ <dd pn="section-5.1.2-5.10">
+ The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519
as defined in
+ <xref target="RFC8032" format="default" sectionFormat="of"
derivedContent="RFC8032"/>.
+ </dd>
+ <dt pn="section-5.1.2-5.11">L:</dt>
+ <dd pn="section-5.1.2-5.12">
+ The order of the prime-order subgroup of edwards25519 as defined
in <xref target="RFC8032" format="default" sectionFormat="of"
derivedContent="RFC8032"/>.
+ </dd>
+ <dt pn="section-5.1.2-5.13">KeyGen():</dt>
+ <dd pn="section-5.1.2-5.14">
+ The generation of the private key d and the associated public
+ key zkey := a*G (where G is the
+ group generator of the elliptic curve and a is an integer
+ derived from d using the SHA-512 hash function)
+ as defined
+ in <xref target="RFC8032" sectionFormat="of" section="5.1.5"
format="default" derivedLink="https://rfc-editor.org/rfc/rfc8032#section-5.1.5";
derivedContent="RFC8032"/>
+ represents the KeyGen()
+ function.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-5.1.2-6">
+ The zone type and zone key of an EDKEY are 4 + 32 bytes in length.
This means that
+ a zTLD will always fit into a single label and does
+ not need any further conversion.
+ </t>
+ <t indent="0" pn="section-5.1.2-7">
+ The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"
format="default" sectionFormat="of" derivedContent="Tor224"/>.
+ As noted above for KeyGen(), a is calculated from d using the
+ SHA-512 hash function as defined in <xref target="RFC8032"
sectionFormat="of" section="5.1.5" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8032#section-5.1.5";
derivedContent="RFC8032"/>.
+ Given a label, the output of the ZKDF function is
+ calculated as follows:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.2-8">
+ZKDF(zkey, label):
+ /* Calculate the blinding factor */
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ /* Ensure that h == h mod L */
+ h := h mod L
+
+ zkey' := h * zkey
+ return zkey'
+ </artwork>
+ <t indent="0" pn="section-5.1.2-9">
+ Implementers <bcp14>SHOULD</bcp14> employ a constant-time scalar
+ multiplication for the constructions above to protect against
+ timing attacks. Otherwise, timing attacks could leak private key
+ material if an attacker can predict when a system starts the
+ publication process.
+ </t>
+ <t indent="0" pn="section-5.1.2-10">
+ The EDKEY cryptosystem uses an HKDF as defined in
+ <xref target="RFC5869" format="default" sectionFormat="of"
derivedContent="RFC5869"/>, using SHA-512 <xref target="RFC6234"
format="default" sectionFormat="of" derivedContent="RFC6234"/> for the
extraction
+ phase and HMAC-SHA-256 <xref target="RFC6234" format="default"
sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
+ PRK_h is key material retrieved using an HKDF that uses the string
+ "key-derivation" as the salt and the zone key as the initial
+ keying material.
+ The blinding factor h is the 512-bit HKDF expansion result.
+ The expansion information input is
+ a concatenation of the label and the string "gns".
+ The result of the HKDF must be clamped and interpreted in network
+ byte order.
+ a is the 256-bit integer corresponding to the 256-bit private
+ key d.
+ The multiplication of zkey with h is a point multiplication.
+ </t>
+ <t indent="0" pn="section-5.1.2-11">
+ The Sign(d, message) and Verify(zkey, message, signature)
procedures <bcp14>MUST</bcp14>
+ be implemented as defined in <xref target="RFC8032"
format="default" sectionFormat="of" derivedContent="RFC8032"/>.
+ </t>
+ <t indent="0" pn="section-5.1.2-12">
+ Signatures for EDKEY zones use a derived private scalar d';
+ this is not compliant with <xref target="RFC8032" format="default"
sectionFormat="of" derivedContent="RFC8032"/>.
+ As the private key that corresponds to the derived private scalar
+ is not known, it is not possible to deterministically derive the
+ signature part R according to <xref target="RFC8032"
format="default" sectionFormat="of" derivedContent="RFC8032"/>.
+ Instead, signatures <bcp14>MUST</bcp14> be generated as follows for
any given
+ message and private zone key:
+ a nonce is calculated from the highest 32 bytes of the
+ expansion of the private key d and the blinding factor h.
+ The nonce is then hashed with the message to r.
+ This way, the full derivation path is included in the calculation
+ of the R value of the signature, ensuring that it is never reused
+ for two different derivation paths or messages.
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.2-13">
+SignDerived(d, label, message):
+ /* Key expansion */
+ dh := SHA-512(d)
+ /* EdDSA clamping */
+ a := dh[0..31]
+ a[0] := a[0] & 248
+ a[31] := a[31] & 127
+ a[31] := a[31] | 64
+ /* Calculate zkey corresponding to d */
+ zkey := a * G
+
+ /* Calculate blinding factor */
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ /* Ensure that h == h mod L */
+ h := h mod L
+
+ d' := (h * a) mod L
+ nonce := SHA-256(dh[32..63] || h)
+ r := SHA-512(nonce || message)
+ R := r * G
+ S := r + SHA-512(R || zkey' || message) * d' mod L
+ return (R,S)
+ </artwork>
+ <t indent="0" pn="section-5.1.2-14">
+ A signature (R,S) is valid for the derived public key zkey' :=
+ ZKDF(zkey, label) if the following holds:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.2-15">
+VerifyDerived(zkey', message, signature):
+ (R,S) := signature
+ return S * G == R + SHA-512(R, zkey', message) * zkey'
+ </artwork>
+ <t indent="0" pn="section-5.1.2-16">
+ The S-Encrypt() and S-Decrypt() functions use XSalsa20
+ as defined in <xref target="XSalsa20" format="default"
sectionFormat="of" derivedContent="XSalsa20"/>
+ and use the XSalsa20-Poly1305 encryption function:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-5.1.2-17">
+S-Encrypt(zkey, label, expiration, plaintext):
+ PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
+ IV := NONCE || expiration
+ return XSalsa20-Poly1305(K, IV, plaintext)
+
+S-Decrypt(zkey, label, expiration, ciphertext):
+ PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
+ IV := NONCE || expiration
+ return XSalsa20-Poly1305(K, IV, ciphertext)
+ </artwork>
+ <t indent="0" pn="section-5.1.2-18">
+ The result of the XSalsa20-Poly1305 encryption function is the
encrypted
+ ciphertext followed by the 128-bit authentication
+ tag.
+ Accordingly, the length of encrypted data equals the length of the
+ data plus the 16 bytes of the authentication tag.
+ </t>
+ <t indent="0" pn="section-5.1.2-19">
+ The key K and counter IV are derived from
+ the record label and the zone key zkey using an HKDF as defined in
+ <xref target="RFC5869" format="default" sectionFormat="of"
derivedContent="RFC5869"/>.
+ SHA-512 <xref target="RFC6234" format="default" sectionFormat="of"
derivedContent="RFC6234"/> is used for the
+ extraction phase and SHA-256 <xref target="RFC6234"
format="default" sectionFormat="of" derivedContent="RFC6234"/> for the
expansion phase.
+ The output keying material is 32 bytes (256 bits) for the symmetric
+ key and 16 bytes (128 bits) for the NONCE.
+ The symmetric key K is a 256-bit XSalsa20 key
+ <xref target="XSalsa20" format="default" sectionFormat="of"
derivedContent="XSalsa20"/>.
+ No additional authenticated data (AAD) is used.
+ </t>
+ <t indent="0" pn="section-5.1.2-20">
+ The nonce is combined with an 8-byte IV.
+ The IV is the expiration time of the
+ resource record block in network byte order.
+ The resulting counter (IV) wire format is illustrated in
+ <xref target="figure_hkdf_ivs_edkey" format="default"
sectionFormat="of" derivedContent="Figure 12"/>.
+ </t>
+ <figure anchor="figure_hkdf_ivs_edkey" align="left"
suppress-title="false" pn="figure-12">
+ <name slugifiedName="name-the-counter-block-initializ">The Counter
Block Initialization Vector</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.1.2-21.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NONCE |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ </section>
+ </section>
+ <section anchor="gnsrecords_redirect" numbered="true"
removeInRFC="false" toc="include" pn="section-5.2">
+ <name slugifiedName="name-redirection-records">Redirection
Records</name>
+ <t indent="0" pn="section-5.2-1">
+ Redirection records are used to redirect resolution.
+ Any implementation <bcp14>SHOULD</bcp14> support all redirection record
types defined here
+ and <bcp14>MAY</bcp14> support any number of additional redirection
records defined in
+ the GANA "GNS Record Types" registry <xref target="GANA"
format="default" sectionFormat="of" derivedContent="GANA"/>.
+ Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set.
+ Not supporting some record types can result in resolution failures.
+ This can be a valid choice if some redirection record types have been
+ determined to be insecure, or if an application has reasons to not
+ support redirection to DNS for reasons such as complexity or security.
+ Redirection records <bcp14>MUST NOT</bcp14> be stored or published
under the apex label.
+ </t>
+ <section anchor="gnsrecords_rdr" numbered="true" removeInRFC="false"
toc="include" pn="section-5.2.1">
+ <name slugifiedName="name-redirect">REDIRECT</name>
+ <t indent="0" pn="section-5.2.1-1">
+ A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
+ A REDIRECT record <bcp14>MUST</bcp14> be the only non-supplemental
+ record under a label.
+ There <bcp14>MAY</bcp14> be inactive records of the same type that
have
+ the SHADOW flag set in order to facilitate smooth changes of
redirection
+ targets.
+ No other records are allowed.
+ Details on the processing of this record are provided in <xref
target="redirect_processing" format="default" sectionFormat="of"
derivedContent="Section 7.3.1"/>.
+
+ A REDIRECT DATA entry is illustrated in <xref
target="figure_redirectrecord" format="default" sectionFormat="of"
derivedContent="Figure 13"/>.
+ </t>
+ <figure anchor="figure_redirectrecord" align="left"
suppress-title="false" pn="figure-13">
+ <name slugifiedName="name-the-redirect-data-wire-form">The
REDIRECT DATA Wire Format</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.2.1-2.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| REDIRECT NAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.2.1-3">
+ <dt pn="section-5.2.1-3.1">REDIRECT NAME:</dt>
+ <dd pn="section-5.2.1-3.2">
+ The name to continue with.
+ This value can be a regular name or a relative
+ name.
+ Relative GNS names are indicated by an extension label (U+002B
("+"))
+ as the rightmost label.
+ The string is UTF-8 encoded and zero terminated.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="gnsrecords_gns2dns" numbered="true"
removeInRFC="false" toc="include" pn="section-5.2.2">
+ <name slugifiedName="name-gns2dns">GNS2DNS</name>
+ <t indent="0" pn="section-5.2.2-1">
+ A GNS2DNS record delegates resolution to DNS.
+ 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
+ <xref target="RFC1034" format="default" sectionFormat="of"
derivedContent="RFC1034"/> for DNS names.
+ There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label.
+ There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other
records used to
+ secure the connection with the DNS servers under the same label.
+ There <bcp14>MAY</bcp14> be inactive records of the same type or
types that have
+ the SHADOW flag set in order to facilitate smooth changes of
redirection
+ targets.
+ No other non-supplemental record types are allowed in the same record
set.
+ A GNS2DNS DATA entry is illustrated in <xref
target="figure_gns2dnsrecord" format="default" sectionFormat="of"
derivedContent="Figure 14"/>.</t>
+ <figure anchor="figure_gns2dnsrecord" align="left"
suppress-title="false" pn="figure-14">
+ <name slugifiedName="name-the-gns2dns-data-wire-forma">The GNS2DNS
DATA Wire Format</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.2.2-2.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS SERVER NAME |
+/ /
+/ /
+| |
++-----------------------------------------------+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.2.2-3">
+ <dt pn="section-5.2.2-3.1">NAME:</dt>
+ <dd pn="section-5.2.2-3.2">
+ The name to continue with in DNS. The value is UTF-8 encoded and
+ zero terminated.
+ </dd>
+ <dt pn="section-5.2.2-3.3">DNS SERVER NAME:</dt>
+ <dd pn="section-5.2.2-3.4">
+ The DNS server to use. This value can be an IPv4 address in
dotted-decimal
+ form, an IPv6 address in colon-hexadecimal form, or a DNS name.
+ It can also be a relative GNS name ending with a
+ "+" as the rightmost label.
+ The implementation <bcp14>MUST</bcp14> check the string
syntactically for
+ an IP address in the respective notation before checking for a
+ relative GNS name.
+ If all three checks fail, the name <bcp14>MUST</bcp14> be treated
as a DNS name.
+ The value is UTF-8 encoded and zero terminated.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-5.2.2-4">
+ NOTE: If an application uses DNS names obtained from GNS2DNS records
+ in a DNS request, they <bcp14>MUST</bcp14> first be converted to an
IDNA-compliant
+ representation <xref target="RFC5890" format="default"
sectionFormat="of" derivedContent="RFC5890"/>.
+ </t>
+ </section>
+ </section>
+ <section anchor="gnsrecords_other" numbered="true" removeInRFC="false"
toc="include" pn="section-5.3">
+ <name slugifiedName="name-auxiliary-records">Auxiliary Records</name>
+ <t indent="0" pn="section-5.3-1">
+ This section defines the initial set of auxiliary GNS record types.
Any
+ implementation <bcp14>SHOULD</bcp14> be able to process the specified
record types
+ according to <xref target="record_processing" format="default"
sectionFormat="of" derivedContent="Section 7.3"/>.
+ </t>
+ <section anchor="gnsrecords_leho" numbered="true" removeInRFC="false"
toc="include" pn="section-5.3.1">
+ <name slugifiedName="name-leho">LEHO</name>
+ <t indent="0" pn="section-5.3.1-1">
+ The LEHO (LEgacy HOstname) record is used to provide a hint for
legacy hostnames:
+ applications can use the GNS to look up IPv4 or IPv6 addresses of
+ Internet services.
+ However, connecting to such services sometimes not only requires
+ the knowledge of an IP address and port but also requires the
canonical
+ DNS name of the service to be transmitted over the transport protocol.
+ In GNS, legacy hostname records provide applications the DNS name that
+ is required to establish a connection to such a service.
+ The most common use case is HTTP virtual hosting and TLS Server Name
+ Indication <xref target="RFC6066" format="default" sectionFormat="of"
derivedContent="RFC6066"/>, where a DNS name must
+ be supplied in the HTTP "Host"-header and the TLS handshake,
+ respectively.
+ Using a GNS name in those cases might not work, as
+ it might not be globally unique. Furthermore, even if uniqueness is
+ not an issue, the legacy service might not even be aware of GNS.
+ </t>
+ <t indent="0" pn="section-5.3.1-2">
+ A LEHO resource record is expected to be found together with A or AAAA
+ resource records with IPv4 or IPv6 addresses.
+ A LEHO DATA entry is illustrated in <xref
target="figure_lehorecord" format="default" sectionFormat="of"
derivedContent="Figure 15"/>.
+ </t>
+ <figure anchor="figure_lehorecord" align="left"
suppress-title="false" pn="figure-15">
+ <name slugifiedName="name-the-leho-data-wire-format">The LEHO DATA
Wire Format</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.3.1-3.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| LEGACY HOSTNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.3.1-4">
+ <dt pn="section-5.3.1-4.1">LEGACY HOSTNAME:</dt>
+ <dd pn="section-5.3.1-4.2">
+ A UTF-8 string (which is not zero terminated) representing the
legacy hostname.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-5.3.1-5">
+ NOTE: If an application uses a LEHO value in an HTTP request header
+ (e.g., a "Host"-header), it <bcp14>MUST</bcp14> be converted to an
IDNA-compliant representation
+ <xref target="RFC5890" format="default" sectionFormat="of"
derivedContent="RFC5890"/>.
+ </t>
+ </section>
+ <section anchor="gnsrecords_nick" numbered="true" removeInRFC="false"
toc="include" pn="section-5.3.2">
+ <name slugifiedName="name-nick">NICK</name>
+ <t indent="0" pn="section-5.3.2-1">
+ Nickname records can be used by zone administrators to publish a
+ label that a zone prefers to have used when it is referred to.
+ This is a suggestion for other zones regarding what label to use when
creating a
+ delegation record (<xref target="gnsrecords_delegation"
format="default" sectionFormat="of" derivedContent="Section 5.1"/>) containing
+ this zone key.
+ This record <bcp14>SHOULD</bcp14> only be stored locally
+ under the apex label "@" but <bcp14>MAY</bcp14> be
+ returned with record sets under any label as a supplemental record.
+ <xref target="nick_processing" format="default" sectionFormat="of"
derivedContent="Section 7.3.5"/> details how a resolver must process
+ supplemental and non-supplemental NICK records.
+ A NICK DATA entry is illustrated in <xref target="figure_nickrecord"
format="default" sectionFormat="of" derivedContent="Figure 16"/>.
+ </t>
+ <figure anchor="figure_nickrecord" align="left"
suppress-title="false" pn="figure-16">
+ <name slugifiedName="name-the-nick-data-wire-format">The NICK DATA
Wire Format</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.3.2-2.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NICKNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.3.2-3">
+ <dt pn="section-5.3.2-3.1">NICKNAME:</dt>
+ <dd pn="section-5.3.2-3.2">
+ A UTF-8 string (which is not zero terminated) representing the
preferred
+ label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS
label.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="gnsrecords_box" numbered="true" removeInRFC="false"
toc="include" pn="section-5.3.3">
+ <name slugifiedName="name-box">BOX</name>
+ <t indent="0" pn="section-5.3.3-1">
+ GNS lookups are expected to return all of the required useful
+ information in one record set. This avoids unnecessary additional
+ lookups and cryptographically ties together information that belongs
+ together, making it impossible for an adversarial storage entity to
provide
+ partial answers that might omit information critical for security.
+ </t>
+ <t indent="0" pn="section-5.3.3-2">
+ This general strategy is incompatible with the
+ special labels used by DNS for SRV and TLSA records. Thus, GNS
+ defines the BOX record format to box up SRV and TLSA records and
+ include them in the record set of the label they are associated
+ with. For example, a
+ TLSA record for "_https._tcp.example.org" will be stored in the
record set of
+ "example.org" as a BOX record with service (SVC) 443 (https),
protocol (PROTO) 6
+ (tcp), and record TYPE "TLSA".
+ For reference, see also <xref target="RFC2782" format="default"
sectionFormat="of" derivedContent="RFC2782"/>.
+ A BOX DATA entry is illustrated in <xref target="figure_boxrecord"
format="default" sectionFormat="of" derivedContent="Figure 17"/>.
+ </t>
+ <figure anchor="figure_boxrecord" align="left"
suppress-title="false" pn="figure-17">
+ <name slugifiedName="name-the-box-data-wire-format">The BOX DATA
Wire Format</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-5.3.3-3.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PROTO | SVC | TYPE |
++-----------+-----------------------------------+
+| RECORD DATA |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-5.3.3-4">
+ <dt pn="section-5.3.3-4.1">PROTO:</dt>
+ <dd pn="section-5.3.3-4.2">
+ The 16-bit protocol number in network byte order.
+ Values
+ below 2<sup>8</sup> are reserved for 8-bit Internet Protocol
numbers allocated by IANA <xref target="RFC5237" format="default"
sectionFormat="of" derivedContent="RFC5237"/>
+ (e.g., 6 for TCP).
+ Values above 2<sup>8</sup> are allocated by the
+ GANA "GNUnet Overlay Protocols" registry <xref target="GANA"
format="default" sectionFormat="of" derivedContent="GANA"/>.
+ </dd>
+ <dt pn="section-5.3.3-4.3">SVC:</dt>
+ <dd pn="section-5.3.3-4.4">
+ The 16-bit service value of the boxed record in network byte order.
In the case of
+ TCP and UDP, it is the port number.
+ </dd>
+ <dt pn="section-5.3.3-4.5">TYPE:</dt>
+ <dd pn="section-5.3.3-4.6">
+ The 32-bit record type of the boxed record in network byte order.
+ </dd>
+ <dt pn="section-5.3.3-4.7">RECORD DATA:</dt>
+ <dd pn="section-5.3.3-4.8">
+ A variable-length field containing the "DATA" format of TYPE as
+ defined for the respective TYPE. Thus, for TYPE values below
2<sup>16</sup>, the
+ format is the same as the respective record type's binary format in
DNS.
+ </dd>
+ </dl>
+ </section>
+ </section>
+ </section>
+ <section anchor="publish" numbered="true" removeInRFC="false"
toc="include" pn="section-6">
+ <name slugifiedName="name-record-encoding-for-remote-">Record Encoding
for Remote Storage</name>
+ <t indent="0" pn="section-6-1">
+ Any API that allows storing a block under a 512-bit key and retrieving
+ one or more blocks from a key can be used by an implementation for
remote storage.
+ To be useful, and to be able to support the defined zone delegation
+ record encodings, the API <bcp14>MUST</bcp14> permit storing blocks of
size
+ 176 bytes or more and <bcp14>SHOULD</bcp14> allow blocks of size 1024
bytes
+ or more.
+ In the following, it is assumed that an implementation realizes two
+ procedures on top of storage:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-6-2">
+PUT(key, block)
+GET(key) -> block
+</artwork>
+ <t indent="0" pn="section-6-3">
+ A GNS implementation publishes blocks
+ in accordance with the properties and recommendations of the underlying
+ remote storage. This can include a periodic refresh operation to
preserve the
+ availability of published blocks.
+ </t>
+ <t indent="0" pn="section-6-4">
+ There is no mechanism for explicitly deleting individual blocks from
remote storage.
+ However, blocks include an EXPIRATION field, which guides remote
+ storage implementations to decide when to delete blocks. Given
multiple blocks
+ for the same key, remote storage implementations <bcp14>SHOULD</bcp14>
try
+ to preserve and return the block with the largest EXPIRATION value.
+ </t>
+ <t indent="0" pn="section-6-5">
+ All resource records from the same zone sharing the same label are
+ encrypted and published together in a single resource record block
+ (RRBLOCK) in the remote storage under a key q, as illustrated
+ in <xref target="figure_storage_publish" format="default"
sectionFormat="of" derivedContent="Figure 18"/>.
+ A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource
+ records in blocks.
+ An implementation <bcp14>MUST</bcp14> use the PUT storage procedure
+ when record sets change to update the zone contents. Implementations
+ <bcp14>MUST</bcp14> ensure that the EXPIRATION fields of RRBLOCKs
+ increase strictly monotonically for every change, even if the smallest
+ expiration time of records in the block does not increase.
+ </t>
+ <figure anchor="figure_storage_publish" align="left"
suppress-title="false" pn="figure-18">
+ <name slugifiedName="name-management-and-publication-">Management and
Publication of Local Zones in Distributed Storage</name>
+ <artwork name="" type="" alt="" align="left" pn="section-6-6.1">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ | | | |
+| | +-----------+PUT(q, RRBLOCK) | | Record | |
+| User | | Zone |----------------|->| Storage | |
+| | | Publisher | | | |/
++-----------+ +-----------+ | +---------+
+ | A |
+ | | Zone records |
+ | | grouped by label |
+ | | |
+ | +---------+ |
+ |Create / Delete / | /| |
+ |and Update +---------+ | |
+ |Local Zones | | | |
+ | | Local | | |
+ +-------------->| Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <t indent="0" pn="section-6-7">
+ Storage key derivation and record
+ block creation are specified in the following sections and
+ illustrated in <xref target="figure_storage_derivations"
format="default" sectionFormat="of" derivedContent="Figure 19"/>.
+ </t>
+ <figure anchor="figure_storage_derivations" align="left"
suppress-title="false" pn="figure-19">
+ <name slugifiedName="name-storage-key-and-record-bloc">Storage Key and
Record Block Creation Overview</name>
+ <artwork name="" type="" alt="" align="left" pn="section-6-8.1">
++----------+ +-------+ +------------+ +-------------+
+| Zone Key | | Label | | Record Set | | Private Key |
++----------+ +-------+ +------------+ +-------------+
+ | | | |
+ | | v |
+ | | +-----------+ |
+ | +---------->| S-Encrypt | |
+ +----------|---------->+-----------+ |
+ | | | | |
+ | | | v v
+ | | | +-------------+
+ | +---------------|-->| SignDerived |
+ | | | +-------------+
+ | | | |
+ | v v v
+ | +------+ +--------------+
+ +----->| ZKDF |------->| Record Block |
+ +------+ +--------------+
+ |
+ v
+ +------+ +-------------+
+ | Hash |------->| Storage Key |
+ +------+ +-------------+
+ </artwork>
+ </figure>
+ <section anchor="blinding" numbered="true" removeInRFC="false"
toc="include" pn="section-6.1">
+ <name slugifiedName="name-the-storage-key">The Storage Key</name>
+ <t indent="0" pn="section-6.1-1">
+ The storage key is derived from the zone key and the respective
+ label of the contained records.
+ The required knowledge of both the zone key and the label in
combination
+ with the similarly derived symmetric secret keys and blinded zone keys
+ ensures query privacy (see <xref target="RFC8324"
sectionFormat="comma" section="3.5" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.5";
derivedContent="RFC8324"/>).
+ </t>
+ <t indent="0" pn="section-6.1-2">
+ Given a label, the storage key q is derived as follows:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-6.1-3">
+q := SHA-512(ZKDF(zkey, label))
+ </artwork>
+ <dl newline="false" indent="3" spacing="normal" pn="section-6.1-4">
+ <dt pn="section-6.1-4.1">label:</dt>
+ <dd pn="section-6.1-4.2">A UTF-8 string under which the resource
records are published.
+ </dd>
+ <dt pn="section-6.1-4.3">zkey:</dt>
+ <dd pn="section-6.1-4.4">
+ The zone key.
+ </dd>
+ <dt pn="section-6.1-4.5">q:</dt>
+ <dd pn="section-6.1-4.6">
+ The 512-bit storage key under which the resource record block is
+ published.
+ It is the SHA-512 hash <xref target="RFC6234" format="default"
sectionFormat="of" derivedContent="RFC6234"/> over the derived zone key.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="rdata" numbered="true" removeInRFC="false"
toc="include" pn="section-6.2">
+ <name slugifiedName="name-plaintext-record-data-rdata">Plaintext
Record Data (RDATA)</name>
+ <t indent="0" pn="section-6.2-1">
+ GNS records from a zone are grouped by their labels such that all
+ records under the same label are published together as a single
+ block in storage. Such grouped record sets <bcp14>MAY</bcp14> be
paired with
+ supplemental records.
+ </t>
+ <t indent="0" pn="section-6.2-2">
+ Record data (RDATA) is the format used to encode such a group of GNS
records.
+ The binary format of RDATA is illustrated in
+ <xref target="figure_rdata" format="default" sectionFormat="of"
derivedContent="Figure 20"/>.
+ </t>
+ <figure anchor="figure_rdata" align="left" suppress-title="false"
pn="figure-20">
+ <name slugifiedName="name-the-rdata-wire-format">The RDATA Wire
Format</name>
+ <artwork name="" type="" alt="" align="left" pn="section-6.2-3.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | FLAGS | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | FLAGS | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PADDING /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-6.2-4">
+ <dt pn="section-6.2-4.1">EXPIRATION, SIZE, TYPE, FLAGS, and
DATA:</dt>
+ <dd pn="section-6.2-4.2">
+ Definitions for these fields are provided below <xref
target="figure_gnsrecord" format="default" sectionFormat="of"
derivedContent="Figure 7"/>
+ in <xref target="rrecords" format="default" sectionFormat="of"
derivedContent="Section 5"/>.
+ </dd>
+ <dt pn="section-6.2-4.3">PADDING:</dt>
+ <dd pn="section-6.2-4.4">
+ When serializing records into RDATA, a GNS implementation
<bcp14>MUST</bcp14> ensure that
+ the size of the RDATA is a power of two
+ using this field. The field <bcp14>MUST</bcp14> be set to zero and
<bcp14>MUST</bcp14> be
+ ignored on receipt.
+ As a special exception, record sets with (only) a zone delegation
+ record type are never padded.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="records_block" numbered="true" removeInRFC="false"
toc="include" pn="section-6.3">
+ <name slugifiedName="name-the-resource-record-block">The Resource
Record Block</name>
+ <t indent="0" pn="section-6.3-1">
+ The resource records grouped in an RDATA are encrypted using the
S-Encrypt()
+ function defined by the zone type of the zone to which the resource
records belong
+ and prefixed with metadata into a resource record block (RRBLOCK) for
remote storage.
+ The GNS RRBLOCK wire format is illustrated in
+ <xref target="figure_record_block" format="default"
sectionFormat="of" derivedContent="Figure 21"/>.
+ </t>
+ <figure anchor="figure_record_block" align="left"
suppress-title="false" pn="figure-21">
+ <name slugifiedName="name-the-rrblock-wire-format">The RRBLOCK Wire
Format</name>
+ <artwork name="" type="" alt="" align="left" pn="section-6.3-2.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | ZONE TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ZONE KEY /
+/ (BLINDED) /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| BDATA |
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-6.3-3">
+ <dt pn="section-6.3-3.1">SIZE:</dt>
+ <dd pn="section-6.3-3.2">
+ A 32-bit value containing the length of the block in bytes in
network byte order.
+ Despite the message format's use of a 32-bit value,
+ implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond
a certain
+ size significantly below the theoretical block size limit of 4 GB.
+ </dd>
+ <dt pn="section-6.3-3.3">ZONE TYPE:</dt>
+ <dd pn="section-6.3-3.4">
+ The 32-bit ztype in network byte order.
+ </dd>
+ <dt pn="section-6.3-3.5">ZONE KEY (BLINDED):</dt>
+ <dd pn="section-6.3-3.6">
+ The blinded zone key "ZKDF(zkey, label)"
+ to be used to verify SIGNATURE.
+ The length and format of the blinded public key depend on the ztype.
+ </dd>
+ <dt pn="section-6.3-3.7">SIGNATURE:</dt>
+ <dd pn="section-6.3-3.8">
+ The signature is computed over the EXPIRATION and BDATA fields
+ as shown in <xref target="figure_rrsigwithpseudo" format="default"
sectionFormat="of" derivedContent="Figure 22"/>.
+ The length and format of the signature depend on the ztype.
+ The signature is created using the SignDerived() function of
+ the cryptosystem of the zone (see <xref target="zones"
format="default" sectionFormat="of" derivedContent="Section 4"/>).
+ </dd>
+ <dt pn="section-6.3-3.9">EXPIRATION:</dt>
+ <dd pn="section-6.3-3.10">
+ Specifies when the RRBLOCK expires and the encrypted block
+ <bcp14>SHOULD</bcp14> be removed from storage and caches, as it is
likely stale.
+ However, applications <bcp14>MAY</bcp14> continue to use
non-expired individual
+ records until they expire. The RRBLOCK expiration value
<bcp14>MUST</bcp14> be computed by first determining for each record type
present in the RRBLOCK the maximum expiration time of all records of that type,
including shadow
+records. Then, the minimum of all of these expiration times is taken. The
final expiration time is then the larger value of (1) the previous EXPIRATION
value of a previous RRBLOCK for the same storage key plus one (if any) and (2)
the computed minimum expiration time across the contained record types. This
ensures strict monotonicity (see <xref target="security_cryptography"
format="default" sectionFormat="of" derivedContent="Section 9.3"/>).
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 UTC in network byte order.
+ </dd>
+ <dt pn="section-6.3-3.11">BDATA:</dt>
+ <dd pn="section-6.3-3.12">
+ The encrypted RDATA computed using S-Encrypt() with the
+ zone key, label, and expiration time as additional inputs.
+ Its ultimate size and content are determined by
+ the S-Encrypt() function of the ztype.
+ </dd>
+ </dl>
+ <t indent="0" pn="section-6.3-4">
+ The signature over the public key covers a 32-bit pseudo header
+ conceptually prefixed to the EXPIRATION and BDATA fields.
+ The wire format is illustrated
+ in <xref target="figure_rrsigwithpseudo" format="default"
sectionFormat="of" derivedContent="Figure 22"/>.
+ </t>
+ <figure anchor="figure_rrsigwithpseudo" align="left"
suppress-title="false" pn="figure-22">
+ <name slugifiedName="name-the-wire-format-used-for-cr">The Wire
Format Used for Creating the Signature of the RRBLOCK</name>
+ <artwork name="" type="" alt="" align="left" pn="section-6.3-5.1">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE (0x0F) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| BDATA |
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false" indent="3" spacing="normal" pn="section-6.3-6">
+ <dt pn="section-6.3-6.1">SIZE:</dt>
+ <dd pn="section-6.3-6.2">
+ A 32-bit value containing the length of the signed data in bytes
+ in network byte order.
+ </dd>
+ <dt pn="section-6.3-6.3">PURPOSE:</dt>
+ <dd pn="section-6.3-6.4">
+ A 32-bit signature purpose flag in network byte order. The value of
this
+ field <bcp14>MUST</bcp14> be 15. It defines the context in which
+ the signature is created so that it cannot be reused in other parts
+ of the protocol that might include possible future extensions.
+ The value of this field corresponds to an entry in the
+ GANA "GNUnet Signature Purposes" registry <xref target="GANA"
format="default" sectionFormat="of" derivedContent="GANA"/>.
+ </dd>
+ <dt pn="section-6.3-6.5">EXPIRATION:</dt>
+ <dd pn="section-6.3-6.6">
+ Field as defined in the RRBLOCK message above.
+ </dd>
+ <dt pn="section-6.3-6.7">BDATA:</dt>
+ <dd pn="section-6.3-6.8">Field as defined in the RRBLOCK message
above.</dd>
+ </dl>
+ </section>
+ </section>
+ <section anchor="resolution" numbered="true" removeInRFC="false"
toc="include" pn="section-7">
+ <name slugifiedName="name-name-resolution">Name Resolution</name>
+ <t indent="0" pn="section-7-1">
+ Names in GNS are resolved by recursively querying the record storage.
+ Recursive in this context means that a resolver does not provide
+ intermediate results for a query to the application.
+ Instead, it <bcp14>MUST</bcp14> respond to a resolution request with
either the
+ requested resource record or an error message if resolution
+ fails.
+ <xref target="figure_resolution" format="default" sectionFormat="of"
derivedContent="Figure 23"/> illustrates how an application
+ requests the lookup of a GNS name (1).
+ The application <bcp14>MAY</bcp14> provide a desired record type to the
resolver.
+ Subsequently, a Start Zone is determined (2) and the recursive
+ resolution process started.
+ This is where the desired record type is used to guide processing.
+ For example, if a zone delegation record type is requested, the
+ resolution of the apex label in that zone must be skipped, as
+ the desired record is already found.
+ Details on how the resolution process is initiated and each iterative
+ result (3a,3b) in the resolution is processed are provided in the
sections below.
+ The results of the lookup are eventually returned to the application
(4).
+ The implementation <bcp14>MUST NOT</bcp14> filter the returned resource
+ record sets according to the desired record type.
+ Filtering of record sets is typically done by the application.
+ </t>
+ <figure anchor="figure_resolution" align="left" suppress-title="false"
pn="figure-23">
+ <name slugifiedName="name-the-recursive-gns-resolutio">The Recursive
GNS Resolution Process</name>
+ <artwork name="" type="" alt="" align="left" pn="section-7-2.1">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ (1) Name +----------+ | | | |
+| | Lookup | | (3a) GET(q) | | Record | |
+|Application|----------| Resolver |---------------|->| Storage | |
+| |<---------| |<--------------|--| |/
++-----------+ (4) +----------+ (3b) RRBLOCK | +---------+
+ Records A |
+ | |
+ (2) Determination of | |
+ Start Zone | |
+ | |
+ +---------+ |
+ / | /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <section anchor="governance" numbered="true" removeInRFC="false"
toc="include" pn="section-7.1">
+ <name slugifiedName="name-start-zones">Start Zones</name>
+ <t indent="0" pn="section-7.1-1">
+ The resolution of a GNS name starts by identifying the Start Zone
+ suffix. Once the Start Zone suffix is identified, recursive resolution
+ of the remainder of the name is initiated (see <xref
target="recursion" format="default" sectionFormat="of" derivedContent="Section
7.2"/>).
+ There are two types of Start Zone suffixes: zTLDs and local
+ suffix-to-zone mappings.
+ The choice of available suffix-to-zone mappings is at the sole
+ discretion of the local system administrator or user.
+ This property addresses the issue of a single hierarchy with a
+ centrally controlled root and the related issue of distribution and
+ management of root servers in DNS (see Sections <xref
target="RFC8324" section="3.12" sectionFormat="bare" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.12";
derivedContent="RFC8324"/> and <xref target="RFC8324" section="3.10"
sectionFormat="bare" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.10";
derivedContent="RFC8324"/> of <xref target="RFC8324" format="default"
sectionFormat="of" derivedContent="RFC8324"/>, respectively).
+ </t>
+ <t indent="0" pn="section-7.1-2">
+ For names ending with a zTLD, the Start Zone is explicitly given in
the
+ suffix of the name to resolve.
+ In order to ensure uniqueness of names with zTLDs, any
+ implementation <bcp14>MUST</bcp14> use the given zone as the Start
Zone.
+ An implementation <bcp14>MUST</bcp14> first try to interpret the
rightmost label of
+ the given name as the beginning of a zTLD (see <xref target="zTLD"
format="default" sectionFormat="of" derivedContent="Section 4.1"/>).
+ If the rightmost label cannot be (partially) decoded or if it does not
+ indicate a supported ztype, the name is treated as a normal name and
+ Start Zone discovery <bcp14>MUST</bcp14> continue with finding a
local suffix-to-zone
+ mapping.
+ If a valid ztype can be found in the rightmost label, the
+ implementation <bcp14>MUST</bcp14> try to synthesize and decode the
zTLD to retrieve
+ the Start Zone key according to <xref target="zTLD" format="default"
sectionFormat="of" derivedContent="Section 4.1"/>.
+ If the zTLD cannot be synthesized or decoded, the resolution of
+ the name fails and an error is returned to the application.
+ Otherwise, the zone key <bcp14>MUST</bcp14> be used as the Start Zone:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-7.1-3">
+Example name: www.example.<zTLD>
+=> Start Zone: zkey of type ztype
+=> Name to resolve from Start Zone: www.example
+ </artwork>
+ <t indent="0" pn="section-7.1-4">
+ For names not ending with a zTLD, the resolver <bcp14>MUST</bcp14>
determine the Start
+ Zone through a local suffix-to-zone mapping.
+ Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a
local
+ configuration file or database by the user or system administrator.
+ A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels
concatenated with a
+ label separator.
+ If multiple suffixes match the name to resolve, the longest
+ matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two
results
+ <bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration,
and the
+ implementation <bcp14>MUST</bcp14> return an error.
+ The following is a non-normative example mapping of Start Zones:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-7.1-5">
+Example name: www.example.xyz.gns.alt
+Local suffix mappings:
+xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0)
+example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zkey1)
+example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
+...
+=> Start Zone: zkey1
+=> Name to resolve from Start Zone: www
+ </artwork>
+ <t indent="0" pn="section-7.1-6">
+ The process given above <bcp14>MAY</bcp14> be supplemented with other
mechanisms if
+ the particular application requires a different process.
+ If no Start Zone can be identified, resolution <bcp14>MUST</bcp14>
fail and an
+ error <bcp14>MUST</bcp14> be returned to the application.
+ </t>
+ </section>
+ <section anchor="recursion" numbered="true" removeInRFC="false"
toc="include" pn="section-7.2">
+ <name slugifiedName="name-recursion">Recursion</name>
+ <t indent="0" pn="section-7.2-1">
+ In each step of the recursive name resolution, there is an
+ authoritative zone zkey and a name to resolve.
+ The name <bcp14>MAY</bcp14> be empty.
+ If the name is empty, it is interpreted as the apex label "@".
+ Initially, the authoritative zone is the Start Zone.
+ </t>
+ <t indent="0" pn="section-7.2-2">
+ From here, the following steps are recursively executed, in order:
+ </t>
+ <ol indent="adaptive" spacing="normal" start="1" type="1"
pn="section-7.2-3">
+ <li pn="section-7.2-3.1" derivedCounter="1.">Extract the rightmost
label from the name to look up.</li>
+ <li pn="section-7.2-3.2" derivedCounter="2.">Calculate q using the
label and zkey as defined in
+ <xref target="blinding" format="default" sectionFormat="of"
derivedContent="Section 6.1"/>.</li>
+ <li pn="section-7.2-3.3" derivedCounter="3.">Perform a storage query
GET(q) to retrieve the RRBLOCK.</li>
+ <li pn="section-7.2-3.4" derivedCounter="4.">Check that (a) the
block is not expired, (b) the SHA-512 hash
+ of the derived authoritative zone key zkey' from the RRBLOCK
matches
+ the query q, and (c) the signature is valid. If any of these
+ tests fail, the RRBLOCK <bcp14>MUST</bcp14>
+ be ignored and, if applicable, the storage lookup GET(q)
+ <bcp14>MUST</bcp14> continue to look for other RRBLOCKs.</li>
+ <li pn="section-7.2-3.5" derivedCounter="5.">Obtain the RDATA by
decrypting the BDATA contained in the
+ RRBLOCK using S-Decrypt() as defined by the zone type,
effectively
+ inverting the process described in <xref target="records_block"
format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</li>
+ </ol>
+ <t indent="0" pn="section-7.2-4">
+ Once a well-formed block has been decrypted, the records from
+ RDATA are subjected to record processing.
+ </t>
+ </section>
+ <section anchor="record_processing" numbered="true" removeInRFC="false"
toc="include" pn="section-7.3">
+ <name slugifiedName="name-record-processing">Record Processing</name>
+ <t indent="0" pn="section-7.3-1">
+ In record processing, only the valid records obtained are
considered.
+ To filter records by validity, the resolver
+ <bcp14>MUST</bcp14> at least check the expiration time and the
FLAGS field of the
+ respective record.
+ Specifically, the resolver <bcp14>MUST</bcp14> disregard expired
records.
+ Furthermore, SHADOW and
+ SUPPLEMENTAL flags can also exclude records from being considered.
+ If the resolver encounters a record with the CRITICAL flag set and
+ does not support the record type, the resolution
<bcp14>MUST</bcp14> be aborted
+ and an error <bcp14>MUST</bcp14> be returned. Information
indicating that the critical
+ record could not be processed <bcp14>SHOULD</bcp14> be returned in
the error
+ description. The implementation <bcp14>MAY</bcp14> choose not to
return the reason for the failure,
+ merely complicating troubleshooting for the user.
+ </t>
+ <t indent="0" pn="section-7.3-2">
+ The next steps depend on the context of the name that is being
+ resolved:
+ </t>
+ <dl newline="false" indent="3" spacing="normal" pn="section-7.3-3">
+ <dt pn="section-7.3-3.1">Case 1:</dt>
+ <dd pn="section-7.3-3.2">If the filtered record set consists of a
single REDIRECT record,
+ the remainder of the name is prepended to the REDIRECT DATA and the
+ recursion is started again from the resulting name.
+ Details are provided in <xref target="redirect_processing"
format="default" sectionFormat="of" derivedContent="Section 7.3.1"/>.</dd>
+ <dt pn="section-7.3-3.3">Case 2:</dt>
+ <dd pn="section-7.3-3.4">If the filtered record set consists
exclusively of one or more GNS2DNS records,
+ resolution continues with DNS.
+ Details are provided in <xref target="gns2dns_processing"
format="default" sectionFormat="of" derivedContent="Section 7.3.2"/>.</dd>
+ <dt pn="section-7.3-3.5">Case 3:</dt>
+ <dd pn="section-7.3-3.6">If the remainder of the name to be resolved
is of the format
+ "_SERVICE._PROTO" and the record set contains one or more matching
BOX
+ records, the records in the BOX records are the final result and
the recursion
+ is concluded as described in <xref target="box_processing"
format="default" sectionFormat="of" derivedContent="Section 7.3.3"/>.</dd>
+ <dt pn="section-7.3-3.7">Case 4:</dt>
+ <dd pn="section-7.3-3.8">If the current record set
+ consists of a single delegation record,
+ resolution of the remainder of the name is delegated to
+ the target zone as described in <xref
target="delegation_processing" format="default" sectionFormat="of"
derivedContent="Section 7.3.4"/>.</dd>
+ <dt pn="section-7.3-3.9">Case 5:</dt>
+ <dd pn="section-7.3-3.10">If the remainder of the name to resolve is
empty,
+ the record set is the final result.
+ If any NICK records are in the final result set, they
<bcp14>MUST</bcp14>
+ first be processed according to <xref target="nick_processing"
format="default" sectionFormat="of" derivedContent="Section 7.3.5"/>.
+ Otherwise, the record result set is directly returned as the final
result.</dd>
+ </dl>
+ <t indent="0" pn="section-7.3-4">Finally, if none of the above cases
are applicable, resolution fails and the
+ resolver <bcp14>MUST</bcp14> return an empty record set.</t>
+ <section anchor="redirect_processing" numbered="true"
removeInRFC="false" toc="include" pn="section-7.3.1">
+ <name slugifiedName="name-redirect-2">REDIRECT</name>
+ <t indent="0" pn="section-7.3.1-1">
+ If the remaining name is empty and the desired record type is
+ REDIRECT, the resolution concludes with the REDIRECT record.
+ If the rightmost label of the REDIRECT NAME is the extension label
+ (U+002B ("+")),
+ resolution continues in GNS with the new name in the
+ current zone.
+ Otherwise, the resulting name is resolved via the
+ default operating system name resolution process.
+ This can in turn trigger a GNS name resolution process, depending
+ on the system configuration.
+ If resolution continues in DNS, the name <bcp14>MUST</bcp14>
first be
+ converted to an IDNA-compliant representation <xref
target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.
+ </t>
+ <t indent="0" pn="section-7.3.1-2">
+ In order to prevent infinite loops, the resolver
<bcp14>MUST</bcp14>
+ implement loop detection or limit the number of recursive
+ resolution steps.
+ The loop detection <bcp14>MUST</bcp14> be effective even
+ if a REDIRECT found in GNS triggers subsequent GNS lookups via
+ the default operating system name resolution process.
+ </t>
+ </section>
+ <section anchor="gns2dns_processing" numbered="true"
removeInRFC="false" toc="include" pn="section-7.3.2">
+ <name slugifiedName="name-gns2dns-2">GNS2DNS</name>
+ <t indent="0" pn="section-7.3.2-1">
+ A resolver returns GNS2DNS records when all of the following
+ conditions are met:
+ </t>
+ <ol indent="adaptive" spacing="normal" start="1" type="1"
pn="section-7.3.2-2">
+ <li pn="section-7.3.2-2.1" derivedCounter="1.">The resolver
encounters one or more GNS2DNS records;</li>
+ <li pn="section-7.3.2-2.2" derivedCounter="2.">The remaining name
is empty; and</li>
+ <li pn="section-7.3.2-2.3" derivedCounter="3.">The desired record
type is GNS2DNS.</li>
+ </ol>
+ <t indent="0" pn="section-7.3.2-3">
+ Otherwise, it is expected that the resolver first resolves the
+ IP addresses of the specified DNS name servers.
+ The DNS name <bcp14>MUST</bcp14> be converted to an IDNA-compliant
+ representation <xref target="RFC5890" format="default"
sectionFormat="of" derivedContent="RFC5890"/> for resolution in DNS.
+ GNS2DNS records <bcp14>MAY</bcp14>
+ contain numeric IPv4 or IPv6 addresses, allowing the resolver to
+ skip this step.
+ The DNS server names might themselves be names in GNS or DNS.
+ If the rightmost label of the DNS server name is the extension
label
+ (U+002B ("+")), the rest of the name is to be
+ interpreted relative to the zone of the GNS2DNS record.
+ If the DNS server name ends in a label representation of a
+ zone key, the DNS server name is to be resolved against
+ the GNS zone zkey.
+ </t>
+ <t indent="0" pn="section-7.3.2-4">
+ Multiple GNS2DNS records can be stored under the same label,
+ in which case the resolver <bcp14>MUST</bcp14> try all of them.
+ The resolver <bcp14>MAY</bcp14> try them in any order or even in
parallel.
+ If multiple GNS2DNS records are present, the DNS name
<bcp14>MUST</bcp14> be
+ identical for all of them. Otherwise, it is not clear which name
+ the resolver is supposed to follow. If different DNS names are
+ present, the resolution fails and an
+ appropriate error <bcp14>SHOULD</bcp14> be returned to the
application.
+ </t>
+ <t indent="0" pn="section-7.3.2-5">
+ If there are DNSSEC DS records or any other records used to
+ secure the connection with the DNS servers stored under the label,
+ the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the
connection with
+ the DNS server.
+ </t>
+ <t indent="0" pn="section-7.3.2-6">
+ Once the IP addresses of the DNS servers have been determined,
+ the DNS name from the GNS2DNS record is appended
+ to the remainder of the name to be resolved and is
+ resolved by querying the DNS name server(s).
+ The synthesized name has to be converted to an IDNA-compliant
+ representation <xref target="RFC5890" format="default"
sectionFormat="of" derivedContent="RFC5890"/> for resolution in DNS.
+ If such a conversion is not possible, the resolution
<bcp14>MUST</bcp14> be aborted
+ and an error <bcp14>MUST</bcp14> be returned. Information
indicating that the critical
+ record could not be processed <bcp14>SHOULD</bcp14> be returned
in the error
+ description. The implementation <bcp14>MAY</bcp14> choose not to
return the reason for the failure,
+ merely complicating troubleshooting for the user.
+ </t>
+ <t indent="0" pn="section-7.3.2-7">
+ As the DNS servers
+ specified are possibly authoritative DNS servers, the GNS
resolver <bcp14>MUST</bcp14>
+ support recursive DNS resolution and <bcp14>MUST NOT</bcp14>
delegate this to the
+ authoritative DNS servers.
+ The first successful recursive name resolution result
+ is returned to the application.
+ In addition, the resolver <bcp14>SHOULD</bcp14> return the
queried DNS name as a
+ supplemental LEHO record (see <xref target="gnsrecords_leho"
format="default" sectionFormat="of" derivedContent="Section 5.3.1"/>) with a
+ relative expiration time of one hour.
+ </t>
+ <t indent="0" pn="section-7.3.2-8">
+ Once the transition from GNS to DNS is made through a
+ GNS2DNS record, there is no "going back".
+ The (possibly recursive) resolution of the DNS name <bcp14>MUST
NOT</bcp14>
+ delegate back into GNS and should only follow the DNS
specifications.
+ For example, names contained in DNS CNAME records <bcp14>MUST
NOT</bcp14> be
+ interpreted by resolvers that support both DNS and GNS as GNS
names.
+ </t>
+ <t indent="0" pn="section-7.3.2-9">
+ GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration
+ option to disable DNS processing to avoid information leakage
+ and provide a consistent security profile for all name
resolutions.
+ Such resolvers would return an empty record set upon encountering
+ a GNS2DNS record during the recursion. However, if GNS2DNS records
+ are encountered in the record set for the apex label and a
GNS2DNS record
+ is explicitly requested by the application, such records
<bcp14>MUST</bcp14>
+ still be returned, even if DNS support is disabled by the
+ GNS resolver configuration.
+ </t>
+ </section>
+ <section anchor="box_processing" numbered="true" removeInRFC="false"
toc="include" pn="section-7.3.3">
+ <name slugifiedName="name-box-2">BOX</name>
+ <t indent="0" pn="section-7.3.3-1">
+ When a BOX record is received, a GNS resolver must unbox it if the
+ name to be resolved continues with "_SERVICE._PROTO".
+ Otherwise, the BOX record is to be left untouched. This way, TLSA
+ (and SRV) records do not require a separate network request, and
+ TLSA records become inseparable from the corresponding address
+ records.
+ </t>
+ </section>
+ <section anchor="delegation_processing" numbered="true"
removeInRFC="false" toc="include" pn="section-7.3.4">
+ <name slugifiedName="name-zone-delegation-records-2">Zone Delegation
Records</name>
+ <t indent="0" pn="section-7.3.4-1">
+ When the resolver encounters a record of a supported
+ zone delegation record type (such as PKEY or EDKEY)
+ and the remainder of the name is not empty, resolution continues
+ recursively with the remainder of the name in the
+ GNS zone specified in the delegation record.
+ </t>
+ <t indent="0" pn="section-7.3.4-2">
+ Whenever a resolver encounters a new GNS zone, it
<bcp14>MUST</bcp14>
+ check against the local revocation list (see <xref
target="revocation" format="default" sectionFormat="of" derivedContent="Section
4.2"/>) to see
+ whether the respective
+ zone key has been revoked. If the zone key was revoked, the
+ resolution <bcp14>MUST</bcp14> fail with an empty result set.
+ </t>
+ <t indent="0" pn="section-7.3.4-3">
+ Implementations <bcp14>MUST NOT</bcp14> allow multiple different
zone
+ delegations under a single label (except if some are shadow
records).
+ Implementations <bcp14>MAY</bcp14> support any subset of ztypes.
+ Implementations <bcp14>MUST NOT</bcp14> process zone delegation
records
+ stored under the apex label ("@"). If a zone delegation record
is encountered under
+ the apex label, resolution fails and an error <bcp14>MUST</bcp14>
be returned. The
+ implementation <bcp14>MAY</bcp14> choose not to return the reason
for the failure,
+ merely impacting troubleshooting information for the user.
+ </t>
+ <t indent="0" pn="section-7.3.4-4">
+ If the remainder of the name to resolve is empty and a record set was
+ received containing only a single delegation record, the recursion is
+ continued with the record value as the authoritative zone and the
+ apex label "@" as the remaining name. The exception is the case
+ where the desired record type as specified by the application is
+ equal to the ztype, in which case the delegation record is returned.
+ </t>
+ </section>
+ <section anchor="nick_processing" numbered="true" removeInRFC="false"
toc="include" pn="section-7.3.5">
+ <name slugifiedName="name-nick-2">NICK</name>
+ <t indent="0" pn="section-7.3.5-1">
+ NICK records are only relevant to the recursive resolver
+ if the record set in question is the final result, which is to
+ be returned to the application. The encountered NICK records can
be either
+ supplemental (see <xref target="rrecords" format="default"
sectionFormat="of" derivedContent="Section 5"/>) or
+ non-supplemental.
+ If the NICK record is supplemental, the resolver only returns the
+ record set if one of the non-supplemental records matches the
+ queried record type.
+ It is possible that one record set contains both supplemental
+ and non-supplemental NICK records.
+ </t>
+ <t indent="0" pn="section-7.3.5-2">
+ The differentiation between a supplemental and non-supplemental
+ NICK record allows the application to match the record to the
+ authoritative zone. Consider the following example:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-7.3.5-3">
+Query: alice.example.gns.alt (type=A)
+Result:
+A: 192.0.2.1
+NICK: eve (non-supplemental)
+ </artwork>
+ <t indent="0" pn="section-7.3.5-4">
+ In this example, the returned NICK record is non-supplemental.
+ For the application, this means that the NICK belongs to the zone
+ "alice.example.gns.alt" and is published under the apex label along
with an A
+ record. The NICK record is interpreted as follows: the zone defined
by
+ "alice.example.gns.alt" wants to be referred to as "eve".
+ In contrast, consider the following:
+ </t>
+ <artwork name="" type="" alt="" align="left" pn="section-7.3.5-5">
+Query: alice.example.gns.alt (type=AAAA)
+Result:
+AAAA: 2001:db8::1
+NICK: john (supplemental)
+ </artwork>
+ <t indent="0" pn="section-7.3.5-6">
+ In this case, the NICK record is marked as supplemental. This means that
+ the NICK record belongs to the zone "example.gns.alt" and is published
under the
+ label "alice" along with a AAAA record. Here, the NICK record should be
+ interpreted as follows: the zone defined by "example.gns.alt" wants to
be referred to as
+ "john". This distinction is likely useful for other records published as
+ supplemental.
+ </t>
+ </section>
+ </section>
+ </section>
+ <section anchor="encoding" numbered="true" removeInRFC="false"
toc="include" pn="section-8">
+ <name
slugifiedName="name-internationalization-and-ch">Internationalization and
Character Encoding</name>
+ <t indent="0" pn="section-8-1">
+ All names in GNS are encoded in UTF-8 <xref target="RFC3629"
format="default" sectionFormat="of" derivedContent="RFC3629"/>.
+ Labels <bcp14>MUST</bcp14> be canonicalized using
+ Normalization Form C (NFC) <xref target="Unicode-UAX15"
format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.
+ This does not include any DNS names found in DNS records, such as
CNAME
+ record data, which is internationalized through the IDNA
specifications;
+ see <xref target="RFC5890" format="default" sectionFormat="of"
derivedContent="RFC5890"/>.
+ </t>
+ </section>
+ <section anchor="security" numbered="true" removeInRFC="false"
toc="include" pn="section-9">
+ <name slugifiedName="name-security-and-privacy-consid">Security and
Privacy Considerations</name>
+ <section anchor="security_availability" numbered="true"
removeInRFC="false" toc="include" pn="section-9.1">
+ <name slugifiedName="name-availability">Availability</name>
+ <t indent="0" pn="section-9.1-1">
+ In order to ensure availability of records beyond their
+ absolute expiration times, implementations <bcp14>MAY</bcp14> allow
+ relative expiration time values of records to be locally defined.
+ Records can then be published recurringly with updated
+ absolute expiration times by the implementation.
+ </t>
+ <t indent="0" pn="section-9.1-2">
+ Implementations <bcp14>MAY</bcp14> allow users to manage private
records in
+ their zones that are not published in storage.
+ Private records are treated just like
+ regular records when resolving labels in local zones,
+ but their data is completely unavailable to non-local users.
+ </t>
+ </section>
+ <section anchor="security_agility" numbered="true" removeInRFC="false"
toc="include" pn="section-9.2">
+ <name slugifiedName="name-agility">Agility</name>
+ <t indent="0" pn="section-9.2-1">
+ The security of cryptographic systems depends on both the strength
of
+ the cryptographic algorithms chosen and the strength of the keys
used
+ with those algorithms. This security also depends on the
engineering
+ of the protocol used by the system to ensure that there are no
+ non-cryptographic ways to bypass the security of the overall system.
+ This is why developers of applications managing GNS zones
<bcp14>SHOULD</bcp14>
+ select a default ztype considered secure at the time of
+ releasing the software.
+ For applications targeting end users that are not expected to
+ understand cryptography, the application developer <bcp14>MUST
NOT</bcp14> leave
+ the ztype selection of new zones to end users.
+ </t>
+ <t indent="0" pn="section-9.2-2">
+ This document concerns itself with the selection of cryptographic
+ algorithms used in GNS.
+ The algorithms identified in this document are not known to be
+ broken (in the cryptographic sense) at the current time, and
+ cryptographic research so far leads us to believe that they are
+ likely to remain secure into the foreseeable future. However, this
+ is not necessarily forever, and it is expected that new revisions of
+ this document will be issued from time to time to reflect the
current
+ best practices in this area.
+ </t>
+ <t indent="0" pn="section-9.2-3">
+ In terms of crypto-agility, whenever the need for an updated
cryptographic
+ scheme arises to, for example, replace ECDSA over Ed25519 for
+ PKEY records, it can simply be introduced
+ through a new record type.
+ Zone administrators can then replace
+ the delegation record type for future records.
+ The old record type remains,
+ and zones can iteratively migrate to the updated zone keys.
+ To ensure that implementations correctly generate an error message
+ when encountering a ztype that they do not support,
+ current and future delegation records must always have the
+ CRITICAL flag set.
+ </t>
+ </section>
+ <section anchor="security_cryptography" numbered="true"
removeInRFC="false" toc="include" pn="section-9.3">
+ <name slugifiedName="name-cryptography">Cryptography</name>
+ <t indent="0" pn="section-9.3-1">
+ The following considerations provide background on the design
choices
+ of the ztypes specified in this document.
+ When specifying new ztypes as per <xref target="zones"
format="default" sectionFormat="of" derivedContent="Section 4"/>, the same
+ considerations apply.
+ </t>
+ <t indent="0" pn="section-9.3-2">
+ GNS PKEY zone keys use ECDSA over Ed25519.
+ This is an unconventional choice,
+ as ECDSA is usually used with other curves. However, standardized
+ ECDSA curves are problematic for a range of reasons, as described in
+ the Curve25519 and EdDSA papers <xref target="RFC7748"
format="default" sectionFormat="of" derivedContent="RFC7748"/> <xref
target="ed25519" format="default" sectionFormat="of" derivedContent="ed25519"/>.
+ Using EdDSA directly is also
+ not possible, as a hash function is used on the private key and
+ will destroy the linearity that the key blinding in GNS depends
upon.
+ We are not aware of anyone suggesting that using Ed25519 instead
+ of another common curve of similar size would lower the security of
+ ECDSA. GNS uses 256-bit curves; that way, the encoded (public)
+ keys fit into a single DNS label, which is good for usability.
+ </t>
+ <t indent="0" pn="section-9.3-3">
+ In order to ensure ciphertext indistinguishability, care must be
+ taken with respect to the IV in the counter
+ block. In our design, the IV always includes the expiration time of
the
+ record block.
+ When applications store records with relative expiration times,
+ monotonicity is implicitly
+ ensured because each time a block is published in storage, its IV is
+ unique, as the expiration time is calculated dynamically and
increases
+ monotonically with the system time. Still,
+ an implementation <bcp14>MUST</bcp14> ensure that when relative
expiration times
+ are decreased, the expiration time of the next record block
<bcp14>MUST</bcp14>
+ be after the last published block.
+ For records where an absolute expiration time is used, the
implementation
+ <bcp14>MUST</bcp14> ensure that the expiration time is always
increased when the record
+ data changes. For example, the expiration time on the wire could be
increased
+ by a single microsecond even if the user did not request a change.
+ In the case of deletion of all resource records under a label, the
+ implementation <bcp14>MUST</bcp14> keep track of the last absolute
expiration time
+ of the last published resource block. Implementations
<bcp14>MAY</bcp14> define
+ and use a special record type as a tombstone that preserves the last
+ absolute expiration time but then <bcp14>MUST</bcp14> take care to
not publish a
+ block with such a tombstone record.
+ When new records are added under this label later, the
implementation
+ <bcp14>MUST</bcp14> ensure that the expiration times are after the
last published
+ block.
+ Finally, in order to ensure monotonically increasing expiration
times,
+ the implementation <bcp14>MUST</bcp14> keep a local record of the
last time obtained
+ from the system clock, so as to construct a monotonic clock if
+ the system clock jumps backwards.
+ </t>
+ </section>
+ <section anchor="security_abuse" numbered="true" removeInRFC="false"
toc="include" pn="section-9.4">
+ <name slugifiedName="name-abuse-mitigation">Abuse Mitigation</name>
+ <t indent="0" pn="section-9.4-1">
+ GNS names are UTF-8 strings. Consequently, GNS faces issues
+ with respect to name spoofing similar to those for DNS with respect
to internationalized
+ domain names.
+ In DNS, attackers can register similar-sounding or similar-looking
+ names (see above) in order to execute phishing attacks.
+ GNS zone administrators must take into account this attack vector
and
+ incorporate rules in order to mitigate it.
+ </t>
+ <t indent="0" pn="section-9.4-2">
+ Further, DNS can be used to combat illegal content on the Internet
+ by having the respective domains seized by authorities.
+ However, the same mechanisms can also be abused in order to impose
+ state censorship.
+ Avoiding that possibility is one of the motivations behind GNS.
+ In GNS, TLDs are not enumerable. By design, the Start Zone of
+ the resolver is defined locally, and hence such a seizure is
+ difficult and ineffective in GNS.
+ </t>
+ </section>
+ <section anchor="security_keymanagement" numbered="true"
removeInRFC="false" toc="include" pn="section-9.5">
+ <name slugifiedName="name-zone-management">Zone Management</name>
+ <t indent="0" pn="section-9.5-1">
+ In GNS, zone administrators need to manage and protect their zone
+ keys. Once a private zone key is lost, it cannot be recovered, and
+ the zone revocation message cannot be computed anymore.
+ Revocation messages can be precalculated if revocation is
+ required in cases where a private zone key is lost.
+ Zone administrators, and for GNS this includes end users, are
+ required to responsibly and diligently protect their cryptographic
+ keys.
+ GNS supports signing records in advance ("offline") in order to
+ support processes (such as air gaps) that aim to protect private
keys.
+ </t>
+ <t indent="0" pn="section-9.5-2">
+ Similarly, users are required to manage their local Start Zone
configuration.
+ In order to ensure the integrity and availability of names, users
must
+ ensure that their local Start Zone information is not compromised or
+ outdated.
+ It can be expected that the processing of zone revocations and an
+ initial Start Zone are provided with a GNS implementation
+ ("drop shipping").
+ Shipping an initial Start Zone configuration effectively establishes
+ a root zone.
+ Extension and customization of the zone are at the full discretion
of
+ the user.
+ </t>
+ <t indent="0" pn="section-9.5-3">
+ While implementations following this specification will be
+ interoperable, if two implementations connect to different remote
storage entities,
+ they are mutually unreachable.
+ This can lead to a state where a record exists in the global
+ namespace for a particular name, but the implementation is not
+ communicating with the remote storage entity that contains the
respective
+ block and is hence unable to resolve it.
+ This situation is similar to a split-horizon DNS configuration.
+ The remote storage entity used will most likely depend on the
specific application
+ context using GNS resolution.
+ For example, one application is the resolution of hidden services
+ within the Tor network <xref target="TorRendSpec" format="default"
sectionFormat="of" derivedContent="TorRendSpec"/>, which would suggest using
Tor routers for remote storage.
+ Implementations of "aggregated" remote storage entities are
conceivable but
+ are expected to be the exception.
+ </t>
+ </section>
+ <section anchor="security_dht" numbered="true" removeInRFC="false"
toc="include" pn="section-9.6">
+ <name slugifiedName="name-dhts-as-remote-storage">DHTs as Remote
Storage</name>
+ <t indent="0" pn="section-9.6-1">
+ This document does not specify the properties of the underlying
+ remote storage, which is required by any GNS implementation.
+ It is important to note that the properties of the underlying
+ remote storage are directly inherited by the
+ GNS implementation. This includes both security and
+ other non-functional properties such as scalability and performance.
+ Implementers should take great care when selecting or implementing
+ a DHT for use as remote storage in a GNS implementation.
+ DHTs with reasonable security and performance properties exist
+ <xref target="R5N" format="default" sectionFormat="of"
derivedContent="R5N"/>.
+ It should also be taken into consideration that GNS implementations
+ that build upon different DHT overlays are unlikely to be
+ mutually reachable.
+ </t>
+ </section>
+ <section anchor="security_rev" numbered="true" removeInRFC="false"
toc="include" pn="section-9.7">
+ <name slugifiedName="name-revocations">Revocations</name>
+ <t indent="0" pn="section-9.7-1">
+ Zone administrators are advised to pregenerate zone revocations
+ and to securely store the revocation information if the zone
+ key is lost, compromised, or replaced in the future.
+ Precalculated revocations can cease to be valid due to expirations
+ or protocol changes such as epoch adjustments.
+ Consequently, implementers and users must take precautions in order
+ to manage revocations accordingly.
+ </t>
+ <t indent="0" pn="section-9.7-2">
+ Revocation payloads do not include a "new" key for key replacement.
+ Inclusion of such a key would have two major disadvantages:
+ </t>
+ <ol indent="adaptive" spacing="normal" start="1" type="1"
pn="section-9.7-3">
+ <li pn="section-9.7-3.1" derivedCounter="1.">
+ If a revocation is published after a private key was compromised,
+ allowing key replacement would be dangerous: if an
+ adversary took over the private key, the adversary could then
+ broadcast a revocation with a key replacement. For the replacement,
+ the compromised owner would have no chance to issue a
+ revocation. Thus, allowing a revocation message to replace a private
+ key makes dealing with key compromise situations worse.
+ </li>
+ <li pn="section-9.7-3.2" derivedCounter="2.">
+ Sometimes, key revocations are used with the objective of changing
+ cryptosystems. Migration to another cryptosystem by replacing keys
+ via a revocation message would only be secure as long as both
+ cryptosystems are still secure against forgery. Such a planned,
+ non-emergency migration to another cryptosystem should be done by
+ running zones for both cipher systems in parallel for a while. The
+ migration would conclude by revoking the legacy zone key only when
+ it is deemed no longer secure and, hopefully, after most users have
+ migrated to the replacement.
+ </li>
+ </ol>
+ </section>
+ <section anchor="privacy_labels" numbered="true" removeInRFC="false"
toc="include" pn="section-9.8">
+ <name slugifiedName="name-zone-privacy">Zone Privacy</name>
+ <t indent="0" pn="section-9.8-1">
+ GNS does not support authenticated denial of existence of names
+ within a zone.
+ Record data is published in encrypted form using keys derived from
the
+ zone key and record label. Zone administrators should
+ carefully consider whether (1) a label and zone key are public or
+ (2) one or both of these should be used as a shared secret to
restrict access
+ to the corresponding record data.
+ Unlike public zone keys, low-entropy labels can be guessed by an
attacker. If an attacker
+ knows the public zone key, the use of well-known or guessable
+ labels effectively threatens the disclosure of the corresponding
records.
+ </t>
+ <t indent="0" pn="section-9.8-2">
+ It should be noted that the guessing attack on labels only applies
if the
+ zone key is somehow disclosed to the adversary. GNS itself
+ does not disclose it during a lookup or when resource records are
+ published (as only the blinded zone keys are used on the network).
+ However, zone keys do become public during revocation.
+ </t>
+ <t indent="0" pn="section-9.8-3">
+ It is thus <bcp14>RECOMMENDED</bcp14> to use a
+ label with sufficient entropy to prevent guessing attacks
+ if any data in a resource record set is sensitive.
+ </t>
+ </section>
+ <section anchor="sec_governance" numbered="true" removeInRFC="false"
toc="include" pn="section-9.9">
+ <name slugifiedName="name-zone-governance">Zone Governance</name>
+ <t indent="0" pn="section-9.9-1">
+ While DNS is distributed, in practice it
+ relies on centralized, trusted registrars to provide globally unique
+ names. As awareness of the central role DNS plays on the Internet
+ increases, 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.
+ While a wider discussion of this issue is out of scope for this
document,
+ analyses and investigations can be found in recent academic research
+ works, including <xref target="SecureNS" format="default"
sectionFormat="of" derivedContent="SecureNS"/>.
+ </t>
+ <t indent="0" pn="section-9.9-2">
+ GNS is designed to provide a secure, privacy-enhancing alternative
to the
+ DNS name resolution protocol, especially when censorship or
manipulation
+ is encountered.
+ In particular, it directly addresses concerns in DNS with respect to
+ query privacy.
+ However, depending on the governance of the root zone, any
deployment
+ will likely suffer from the issue of a
+ single hierarchy with a centrally controlled root and the
+ related issue of distribution and management of root servers in
DNS, as
+ raised in Sections <xref target="RFC8324" section="3.12"
sectionFormat="bare" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.12";
derivedContent="RFC8324"/> and <xref target="RFC8324" section="3.10"
sectionFormat="bare" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.10";
derivedContent="RFC8324"/> of <xref target="RFC8324" format="default"
sectionFormat="of" derivedContent="RFC8324"/>, respectively.
+ In DNS, those issues directly result from the centralized root
+ zone governance at the Internet Corporation for Assigned Names and
+ Numbers (ICANN), which allows it to provide globally unique names.
+ </t>
+ <t indent="0" pn="section-9.9-3">
+ In GNS, Start Zones give users local authority over their preferred
+ root zone governance.
+ It enables users to replace or enhance a trusted root zone
+ configuration provided by a third party (e.g., the implementer or a
+ multi-stakeholder governance body like ICANN) with secure
delegation of
+ authority using local petnames while operating under a
+ very strong adversary model.
+ In combination with zTLDs, this provides users of GNS with a global,
+ secure, and memorable mapping without a trusted authority.
+ </t>
+ <t indent="0" pn="section-9.9-4">
+ Any GNS implementation <bcp14>MAY</bcp14> provide a default
+ governance model in the form of an initial Start Zone mapping.
+ </t>
+ </section>
+ <section anchor="namespace_ambiguity" numbered="true"
removeInRFC="false" toc="include" pn="section-9.10">
+ <name slugifiedName="name-namespace-ambiguity">Namespace
Ambiguity</name>
+ <t indent="0" pn="section-9.10-1">
+ Technically, the GNS protocol can be used to resolve names in the
+ namespace of the global DNS.
+ However, this would require the respective governance bodies and
+ stakeholders (e.g., the IETF and ICANN) to standardize the use of
GNS for this particular use
+ case.
+ </t>
+ <t indent="0" pn="section-9.10-2">
+ This capability implies that GNS names may be
+ indistinguishable from DNS names in their
+ respective common display format <xref target="RFC8499"
format="default" sectionFormat="of" derivedContent="RFC8499"/> or
+ other special-use domain names <xref target="RFC6761"
format="default" sectionFormat="of" derivedContent="RFC6761"/> if
+ a local Start Zone configuration maps suffixes from the
+ global DNS to GNS zones.
+ For applications, which name system should be
+ used in order to resolve a given name will then be ambiguous.
+ This poses a risk when trying to resolve a name through DNS when
+ it is actually a GNS name, as discussed in <xref target="RFC8244"
format="default" sectionFormat="of" derivedContent="RFC8244"/>.
+ In such a case, the GNS name is likely to be leaked as part of the
DNS
+ resolution.
+ </t>
+ <t indent="0" pn="section-9.10-3">
+ In order to prevent disclosure of queried GNS names, it is
+ <bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to
resolve
+ a given name in GNS before any other method, taking into account
+ potential suffix-to-zone mappings and zTLDs.
+ Suffix-to-zone mappings are expected to be configured by the user or
+ local administrator, and as such the resolution in GNS is
+ in line with user expectations even if the name could also be
resolved
+ through DNS.
+ If no suffix-to-zone mapping for the name exists and no zTLD is
found,
+ resolution <bcp14>MAY</bcp14> continue with other methods such as
DNS.
+ If a suffix-to-zone mapping for the name exists or the name ends
with
+ a zTLD, it <bcp14>MUST</bcp14> be resolved using GNS, and
+ resolution <bcp14>MUST NOT</bcp14> continue by any other means
+ independent of the GNS resolution result.
+ </t>
+ <t indent="0" pn="section-9.10-4">
+ Mechanisms such as the Name Service Switch (NSS) of UNIX-like
+ operating systems are an example of how such a resolution process
+ can be implemented and used.
+ The NSS allows system administrators to configure hostname
resolution
+ precedence and is integrated with the system resolver
implementation.
+ </t>
+ <t indent="0" pn="section-9.10-5">
+ For use cases where GNS names may be confused with names
+ of other name resolution mechanisms (in particular, DNS), the
+ ".gns.alt" domain <bcp14>SHOULD</bcp14> be used.
+ For use cases like implementing sinkholes to block
+ malware sites or serving DNS domains via GNS to bypass censorship,
+ GNS <bcp14>MAY</bcp14> be deliberately used in ways that interfere
+ with resolution of another name system.
+ </t>
+ </section>
+ </section>
+ <section anchor="gana" numbered="true" removeInRFC="false" toc="include"
pn="section-10">
+ <name slugifiedName="name-gana-considerations">GANA Considerations</name>
+ <section anchor="gana_gnunet-sig-purposes" numbered="true"
removeInRFC="false" toc="include" pn="section-10.1">
+ <name slugifiedName="name-gnunet-signature-purposes-r">GNUnet
Signature Purposes Registry</name>
+ <t indent="0" pn="section-10.1-1">
+ GANA <xref target="GANA" format="default" sectionFormat="of"
derivedContent="GANA"/> has assigned signature purposes in its
+ "GNUnet Signature Purposes" registry as listed in
+ <xref target="tab_purposenums" format="default" sectionFormat="of"
derivedContent="Table 1"/>.
+ </t>
+ <table anchor="tab_purposenums" align="center" pn="table-1">
+ <name slugifiedName="name-the-gana-gnunet-signature-p">The GANA
GNUnet Signature Purposes Registry</name>
+ <thead>
+ <tr>
+ <th align="left" colspan="1" rowspan="1">Purpose</th>
+ <th align="left" colspan="1" rowspan="1">Name</th>
+ <th align="left" colspan="1" rowspan="1">References</th>
+ <th align="left" colspan="1" rowspan="1">Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">3</td>
+ <td align="left" colspan="1" rowspan="1">GNS_REVOCATION</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">GNS zone key
revocation</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">15</td>
+ <td align="left" colspan="1" rowspan="1">GNS_RECORD_SIGN</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">GNS record set
signature</td>
+ </tr>
+ </tbody>
+ </table>
+ </section>
+ <section anchor="gana_gnsrr" numbered="true" removeInRFC="false"
toc="include" pn="section-10.2">
+ <name slugifiedName="name-gns-record-types-registry">GNS Record Types
Registry</name>
+ <t indent="0" pn="section-10.2-1">
+ GANA <xref target="GANA" format="default" sectionFormat="of"
derivedContent="GANA"/>
+ manages the "GNS Record Types" registry.
+ </t>
+ <t indent="0" pn="section-10.2-2">Each entry has the following format:
+ </t>
+ <dl newline="false" indent="3" spacing="normal" pn="section-10.2-3">
+ <dt pn="section-10.2-3.1">Name:</dt>
+ <dd pn="section-10.2-3.2">The name of the record type
(case-insensitive ASCII
+ string, restricted to alphanumeric characters). For zone delegation
+ records, the assigned number represents the ztype value of the
zone.</dd>
+ <dt pn="section-10.2-3.3">Number:</dt>
+ <dd pn="section-10.2-3.4">A 32-bit number above 65535.</dd>
+ <dt pn="section-10.2-3.5">Comment:</dt>
+ <dd pn="section-10.2-3.6">Optionally, brief English text describing
the purpose of
+ the record type (in UTF-8).</dd>
+ <dt pn="section-10.2-3.7">Contact:</dt>
+ <dd pn="section-10.2-3.8">Optionally, the contact information for a
person to contact for
+ further information.</dd>
+ <dt pn="section-10.2-3.9">References:</dt>
+ <dd pn="section-10.2-3.10">Optionally, references (such as an RFC)
describing the record type.</dd>
+ </dl>
+ <t indent="0" pn="section-10.2-4">
+ The registration policy for this registry is "First Come First
+ Served". This policy is modeled on that described in <xref
target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>
+ and describes the actions taken by GANA:
+ </t>
+ <ul bare="false" empty="false" indent="3" spacing="normal"
pn="section-10.2-5">
+ <li pn="section-10.2-5.1">
+ Adding new entries is possible after review by any authorized
+ GANA contributor, using a
+ first-come-first-served policy for unique name allocation.
+ Reviewers are responsible for ensuring that the chosen "Name" is
+ appropriate for the record type.
+ The registry will define a unique number for the entry.
+ </li>
+ <li pn="section-10.2-5.2">
+ Authorized GANA contributors for review of new entries are reachable
at
+ <gns-registry@gnunet.org>.
+ </li>
+ <li pn="section-10.2-5.3">
+ Any request <bcp14>MUST</bcp14> contain a unique name and a point of
contact.
+ The contact information <bcp14>MAY</bcp14> be added to the registry,
with the consent
+ of the requester.
+ The request <bcp14>MAY</bcp14> optionally also contain relevant
references as well
+ as a descriptive comment, as defined above.
+ </li>
+ </ul>
+ <t indent="0" pn="section-10.2-6">
+ GANA has assigned numbers for the record types defined in this
+ specification in the "GNS Record Types" registry as listed in
+ <xref target="tab_rrtypenums" format="default" sectionFormat="of"
derivedContent="Table 2"/>.
+ </t>
+ <table anchor="tab_rrtypenums" align="center" pn="table-2">
+ <name slugifiedName="name-the-gana-gns-record-types-r">The GANA GNS
Record Types Registry</name>
+ <thead>
+ <tr>
+ <th align="left" colspan="1" rowspan="1">Number</th>
+ <th align="left" colspan="1" rowspan="1">Name</th>
+ <th align="left" colspan="1" rowspan="1">Contact</th>
+ <th align="left" colspan="1" rowspan="1">References</th>
+ <th align="left" colspan="1" rowspan="1">Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">65536</td>
+ <td align="left" colspan="1" rowspan="1">PKEY</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">GNS zone delegation
(PKEY)</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">65537</td>
+ <td align="left" colspan="1" rowspan="1">NICK</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">GNS zone nickname</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">65538</td>
+ <td align="left" colspan="1" rowspan="1">LEHO</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">GNS legacy hostname</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">65540</td>
+ <td align="left" colspan="1" rowspan="1">GNS2DNS</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">Delegation to DNS</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">65541</td>
+ <td align="left" colspan="1" rowspan="1">BOX</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">Box records</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">65551</td>
+ <td align="left" colspan="1" rowspan="1">REDIRECT</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">Redirection record</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">65556</td>
+ <td align="left" colspan="1" rowspan="1">EDKEY</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">GNS zone delegation
(EDKEY)</td>
+ </tr>
+ </tbody>
+ <tfoot>
+ <tr>
+ <td align="left" colspan="5" rowspan="1">(*):
gns-registry@gnunet.org</td>
+ </tr>
+ </tfoot>
+ </table>
+ </section>
+ <section anchor="gana_alt" numbered="true" removeInRFC="false"
toc="include" pn="section-10.3">
+ <name slugifiedName="name-alt-subdomains-registry">.alt Subdomains
Registry</name>
+ <t indent="0" pn="section-10.3-1">
+ GANA <xref target="GANA" format="default" sectionFormat="of"
derivedContent="GANA"/>
+ manages the ".alt Subdomains" registry. This GANA-operated .alt
registry
+ may or may not be taken into account by any particular implementer,
and
+ it is not in any way associated with or sanctioned by the IETF or
ICANN.
+ </t>
+ <t indent="0" pn="section-10.3-2">Each entry has the following format:
+ </t>
+ <dl newline="false" indent="3" spacing="normal" pn="section-10.3-3">
+ <dt pn="section-10.3-3.1">Label:</dt>
+ <dd pn="section-10.3-3.2">The label of the subdomain (in DNS
"letters, digits, hyphen" (LDH) format as defined in <xref target="RFC5890"
sectionFormat="of" section="2.3.1" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc5890#section-2.3.1";
derivedContent="RFC5890"/>).</dd>
+ <dt pn="section-10.3-3.3">Description:</dt>
+ <dd pn="section-10.3-3.4">Optionally, brief English text describing
the purpose of
+ the subdomain (in UTF-8).</dd>
+ <dt pn="section-10.3-3.5">Contact:</dt>
+ <dd pn="section-10.3-3.6">Optionally, the contact information for a
person to contact for
+ further information.</dd>
+ <dt pn="section-10.3-3.7">References:</dt>
+ <dd pn="section-10.3-3.8">Optionally, references (such as an RFC)
describing the record type.</dd>
+ </dl>
+ <t indent="0" pn="section-10.3-4">
+ The registration policy for this registry is "First Come First
+ Served". This policy is modeled on that described in <xref
target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>
+ and describes the actions taken by GANA:
+ </t>
+ <ul bare="false" empty="false" indent="3" spacing="normal"
pn="section-10.3-5">
+ <li pn="section-10.3-5.1">
+ Adding new entries is possible after review by any authorized
+ GANA contributor, using a
+ first-come-first-served policy for unique subdomain allocation.
+ Reviewers are responsible for ensuring that the chosen "Subdomain" is
+ appropriate for the purpose.
+ </li>
+ <li pn="section-10.3-5.2">
+ Authorized GANA contributors for review of new entries are reachable
at
+ <alt-registry@gnunet.org>.
+ </li>
+ <li pn="section-10.3-5.3">
+ Any request <bcp14>MUST</bcp14> contain a unique subdomain and a
point of contact.
+ The contact information <bcp14>MAY</bcp14> be added to the registry,
with the consent
+ of the requester.
+ The request <bcp14>MAY</bcp14> optionally also contain relevant
references as well
+ as a descriptive comment, as defined above.
+ </li>
+ </ul>
+ <t indent="0" pn="section-10.3-6">
+ GANA has assigned the subdomain defined in this
+ specification in the ".alt Subdomains" registry
+ as listed in <xref target="tab_altsubdomains" format="default"
sectionFormat="of" derivedContent="Table 3"/>.
+ </t>
+ <table anchor="tab_altsubdomains" align="center" pn="table-3">
+ <name slugifiedName="name-the-gana-alt-subdomains-reg">The GANA .alt
Subdomains Registry</name>
+ <thead>
+ <tr>
+ <th align="left" colspan="1" rowspan="1">Label</th>
+ <th align="left" colspan="1" rowspan="1">Contact</th>
+ <th align="left" colspan="1" rowspan="1">References</th>
+ <th align="left" colspan="1" rowspan="1">Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">gns</td>
+ <td align="left" colspan="1" rowspan="1">(*)</td>
+ <td align="left" colspan="1" rowspan="1">RFC 9498</td>
+ <td align="left" colspan="1" rowspan="1">The .alt subdomain for
GNS</td>
+ </tr>
+ </tbody>
+ <tfoot>
+ <tr>
+ <td align="left" colspan="4" rowspan="1">(*):
alt-registry@gnunet.org</td>
+ </tr>
+ </tfoot>
+ </table>
+ </section>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include" pn="section-11">
+ <name slugifiedName="name-iana-considerations">IANA Considerations</name>
+ <t indent="0" pn="section-11-1">
+ This document has no IANA actions.
+ </t>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include" pn="section-12">
+ <name slugifiedName="name-implementation-and-deployme">Implementation
and Deployment Status</name>
+ <t indent="0" pn="section-12-1">
+ There are two implementations conforming to this specification,
written
+ in C and Go, respectively. The C implementation as part of GNUnet
+ <xref target="GNUnetGNS" format="default" sectionFormat="of"
derivedContent="GNUnetGNS"/> represents the original
+ and reference implementation. The Go implementation
+ <xref target="GoGNS" format="default" sectionFormat="of"
derivedContent="GoGNS"/> demonstrates how two implementations of GNS are
+ interoperable if they are built on top of the same underlying
+ DHT storage.
+ </t>
+ <t indent="0" pn="section-12-2">
+ Currently, the GNUnet peer-to-peer network <xref target="GNUnet"
format="default" sectionFormat="of" derivedContent="GNUnet"/>
+ is an active deployment of GNS on top of its DHT <xref target="R5N"
format="default" sectionFormat="of" derivedContent="R5N"/>. The Go
implementation <xref target="GoGNS" format="default" sectionFormat="of"
derivedContent="GoGNS"/> uses this deployment
+ by building on top of the GNUnet DHT services available on any
+ GNUnet peer. It shows how GNS implementations
+ can attach to this existing deployment and participate in name
+ resolution as well as zone publication.
+ </t>
+ <t indent="0" pn="section-12-3">
+ The self-sovereign identity system re:claimID <xref target="reclaim"
format="default" sectionFormat="of" derivedContent="reclaim"/>
+ is using GNS in order to selectively share identity attributes and
+ attestations with third parties.
+ </t>
+ <t indent="0" pn="section-12-4">
+ The Ascension tool <xref target="Ascension" format="default"
sectionFormat="of" derivedContent="Ascension"/> facilitates the migration of
DNS zones to
+ GNS zones by translating information retrieved from a DNS zone
+ transfer into a GNS zone.
+ </t>
+ </section>
+ </middle>
+ <back>
+ <references pn="section-13">
+ <name slugifiedName="name-references">References</name>
+ <references pn="section-13.1">
+ <name slugifiedName="name-normative-references">Normative
References</name>
+ <reference anchor="RFC1034"
target="https://www.rfc-editor.org/info/rfc1034"; quoteTitle="true"
derivedAnchor="RFC1034">
+ <front>
+ <title>Domain names - concepts and facilities</title>
+ <author fullname="P. Mockapetris" initials="P."
surname="Mockapetris"/>
+ <date month="November" year="1987"/>
+ <abstract>
+ <t indent="0">This RFC is the revised basic definition of The
Domain Name System. It obsoletes RFC-882. This memo describes the domain style
names and their used for host address look up and electronic mail forwarding.
It discusses the clients and servers in the domain name system and the protocol
used between them.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="STD" value="13"/>
+ <seriesInfo name="RFC" value="1034"/>
+ <seriesInfo name="DOI" value="10.17487/RFC1034"/>
+ </reference>
+ <reference anchor="RFC1035"
target="https://www.rfc-editor.org/info/rfc1035"; quoteTitle="true"
derivedAnchor="RFC1035">
+ <front>
+ <title>Domain names - implementation and specification</title>
+ <author fullname="P. Mockapetris" initials="P."
surname="Mockapetris"/>
+ <date month="November" year="1987"/>
+ <abstract>
+ <t indent="0">This RFC is the revised specification of the
protocol and format used in the implementation of the Domain Name System. It
obsoletes RFC-883. This memo documents the details of the domain name client -
server communication.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="STD" value="13"/>
+ <seriesInfo name="RFC" value="1035"/>
+ <seriesInfo name="DOI" value="10.17487/RFC1035"/>
+ </reference>
+ <reference anchor="RFC2782"
target="https://www.rfc-editor.org/info/rfc2782"; quoteTitle="true"
derivedAnchor="RFC2782">
+ <front>
+ <title>A DNS RR for specifying the location of services (DNS
SRV)</title>
+ <author fullname="A. Gulbrandsen" initials="A."
surname="Gulbrandsen"/>
+ <author fullname="P. Vixie" initials="P." surname="Vixie"/>
+ <author fullname="L. Esibov" initials="L." surname="Esibov"/>
+ <date month="February" year="2000"/>
+ <abstract>
+ <t indent="0">This document describes a DNS RR which specifies
the location of the server(s) for a specific protocol and domain.
[STANDARDS-TRACK]</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="2782"/>
+ <seriesInfo name="DOI" value="10.17487/RFC2782"/>
+ </reference>
+ <reference anchor="RFC2119"
target="https://www.rfc-editor.org/info/rfc2119"; quoteTitle="true"
derivedAnchor="RFC2119">
+ <front>
+ <title>Key words for use in RFCs to Indicate Requirement
Levels</title>
+ <author fullname="S. Bradner" initials="S." surname="Bradner"/>
+ <date month="March" year="1997"/>
+ <abstract>
+ <t indent="0">In many standards track documents several words
are used to signify the requirements in the specification. These words are
often capitalized. This document defines these words as they should be
interpreted in IETF documents. This document specifies an Internet Best Current
Practices for the Internet Community, and requests discussion and suggestions
for improvements.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="BCP" value="14"/>
+ <seriesInfo name="RFC" value="2119"/>
+ <seriesInfo name="DOI" value="10.17487/RFC2119"/>
+ </reference>
+ <reference anchor="RFC3629"
target="https://www.rfc-editor.org/info/rfc3629"; quoteTitle="true"
derivedAnchor="RFC3629">
+ <front>
+ <title>UTF-8, a transformation format of ISO 10646</title>
+ <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
+ <date month="November" year="2003"/>
+ <abstract>
+ <t indent="0">ISO/IEC 10646-1 defines a large character set
called the Universal Character Set (UCS) which encompasses most of the world's
writing systems. The originally proposed encodings of the UCS, however, were
not compatible with many current applications and protocols, and this has led
to the development of UTF-8, the object of this memo. UTF-8 has the
characteristic of preserving the full US-ASCII range, providing compatibility
with file systems, parsers and other s [...]
+ </abstract>
+ </front>
+ <seriesInfo name="STD" value="63"/>
+ <seriesInfo name="RFC" value="3629"/>
+ <seriesInfo name="DOI" value="10.17487/RFC3629"/>
+ </reference>
+ <reference anchor="RFC3686"
target="https://www.rfc-editor.org/info/rfc3686"; quoteTitle="true"
derivedAnchor="RFC3686">
+ <front>
+ <title>Using Advanced Encryption Standard (AES) Counter Mode With
IPsec Encapsulating Security Payload (ESP)</title>
+ <author fullname="R. Housley" initials="R." surname="Housley"/>
+ <date month="January" year="2004"/>
+ <abstract>
+ <t indent="0">This document describes the use of Advanced
Encryption Standard (AES) Counter Mode, with an explicit initialization vector,
as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="3686"/>
+ <seriesInfo name="DOI" value="10.17487/RFC3686"/>
+ </reference>
+ <reference anchor="RFC3826"
target="https://www.rfc-editor.org/info/rfc3826"; quoteTitle="true"
derivedAnchor="RFC3826">
+ <front>
+ <title>The Advanced Encryption Standard (AES) Cipher Algorithm in
the SNMP User-based Security Model</title>
+ <author fullname="U. Blumenthal" initials="U."
surname="Blumenthal"/>
+ <author fullname="F. Maino" initials="F." surname="Maino"/>
+ <author fullname="K. McCloghrie" initials="K."
surname="McCloghrie"/>
+ <date month="June" year="2004"/>
+ <abstract>
+ <t indent="0">This document describes a symmetric encryption
protocol that supplements the protocols described in the User-based Security
Model (USM), which is a Security Subsystem for version 3 of the Simple Network
Management Protocol for use in the SNMP Architecture. The symmetric encryption
protocol described in this document is based on the Advanced Encryption
Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key
size of 128 bits. [STANDARDS-TR [...]
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="3826"/>
+ <seriesInfo name="DOI" value="10.17487/RFC3826"/>
+ </reference>
+ <reference anchor="RFC5237"
target="https://www.rfc-editor.org/info/rfc5237"; quoteTitle="true"
derivedAnchor="RFC5237">
+ <front>
+ <title>IANA Allocation Guidelines for the Protocol Field</title>
+ <author fullname="J. Arkko" initials="J." surname="Arkko"/>
+ <author fullname="S. Bradner" initials="S." surname="Bradner"/>
+ <date month="February" year="2008"/>
+ <abstract>
+ <t indent="0">This document revises the IANA guidelines for
allocating new Protocol field values in IPv4 header. It modifies the rules
specified in RFC 2780 by removing the Expert Review option. The change will
also affect the allocation of Next Header field values in IPv6. This document
specifies an Internet Best Current Practices for the Internet Community, and
requests discussion and suggestions for improvements.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="BCP" value="37"/>
+ <seriesInfo name="RFC" value="5237"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5237"/>
+ </reference>
+ <reference anchor="RFC5869"
target="https://www.rfc-editor.org/info/rfc5869"; quoteTitle="true"
derivedAnchor="RFC5869">
+ <front>
+ <title>HMAC-based Extract-and-Expand Key Derivation Function
(HKDF)</title>
+ <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
+ <author fullname="P. Eronen" initials="P." surname="Eronen"/>
+ <date month="May" year="2010"/>
+ <abstract>
+ <t indent="0">This document specifies a simple Hashed Message
Authentication Code (HMAC)-based key derivation function (HKDF), which can be
used as a building block in various protocols and applications. The key
derivation function (KDF) is intended to support a wide range of applications
and requirements, and is conservative in its use of cryptographic hash
functions. This document is not an Internet Standards Track specification; it
is published for informational purposes.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="5869"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5869"/>
+ </reference>
+ <reference anchor="RFC5890"
target="https://www.rfc-editor.org/info/rfc5890"; quoteTitle="true"
derivedAnchor="RFC5890">
+ <front>
+ <title>Internationalized Domain Names for Applications (IDNA):
Definitions and Document Framework</title>
+ <author fullname="J. Klensin" initials="J." surname="Klensin"/>
+ <date month="August" year="2010"/>
+ <abstract>
+ <t indent="0">This document is one of a collection that,
together, describe the protocol and usage context for a revision of
Internationalized Domain Names for Applications (IDNA), superseding the earlier
version. It describes the document collection and provides definitions and
other material that are common to the set. [STANDARDS-TRACK]</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="5890"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5890"/>
+ </reference>
+ <reference anchor="RFC5895"
target="https://www.rfc-editor.org/info/rfc5895"; quoteTitle="true"
derivedAnchor="RFC5895">
+ <front>
+ <title>Mapping Characters for Internationalized Domain Names in
Applications (IDNA) 2008</title>
+ <author fullname="P. Resnick" initials="P." surname="Resnick"/>
+ <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
+ <date month="September" year="2010"/>
+ <abstract>
+ <t indent="0">In the original version of the Internationalized
Domain Names in Applications (IDNA) protocol, any Unicode code points taken
from user input were mapped into a set of Unicode code points that "made
sense", and then encoded and passed to the domain name system (DNS). The
IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that
the input to the protocol comes from a set of "permitted" code points, which it
then encodes and passes to the DNS [...]
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="5895"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5895"/>
+ </reference>
+ <reference anchor="RFC6234"
target="https://www.rfc-editor.org/info/rfc6234"; quoteTitle="true"
derivedAnchor="RFC6234">
+ <front>
+ <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and
HKDF)</title>
+ <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake
3rd"/>
+ <author fullname="T. Hansen" initials="T." surname="Hansen"/>
+ <date month="May" year="2011"/>
+ <abstract>
+ <t indent="0">Federal Information Processing Standard, FIPS</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6234"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6234"/>
+ </reference>
+ <reference anchor="RFC6895"
target="https://www.rfc-editor.org/info/rfc6895"; quoteTitle="true"
derivedAnchor="RFC6895">
+ <front>
+ <title>Domain Name System (DNS) IANA Considerations</title>
+ <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake
3rd"/>
+ <date month="April" year="2013"/>
+ <abstract>
+ <t indent="0">This document specifies Internet Assigned Numbers
Authority (IANA) parameter assignment considerations for the allocation of
Domain Name System (DNS) resource record types, CLASSes, operation codes, error
codes, DNS protocol message header bits, and AFSDB resource record subtypes. It
obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="BCP" value="42"/>
+ <seriesInfo name="RFC" value="6895"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6895"/>
+ </reference>
+ <reference anchor="RFC6979"
target="https://www.rfc-editor.org/info/rfc6979"; quoteTitle="true"
derivedAnchor="RFC6979">
+ <front>
+ <title>Deterministic Usage of the Digital Signature Algorithm
(DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
+ <author fullname="T. Pornin" initials="T." surname="Pornin"/>
+ <date month="August" year="2013"/>
+ <abstract>
+ <t indent="0">This document defines a deterministic digital
signature generation procedure. Such signatures are compatible with standard
Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA) digital signatures and can be processed with unmodified
verifiers, which need not be aware of the procedure described therein.
Deterministic signatures retain the cryptographic security features associated
with digital signatures but can be more easily [...]
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6979"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6979"/>
+ </reference>
+ <reference anchor="RFC7748"
target="https://www.rfc-editor.org/info/rfc7748"; quoteTitle="true"
derivedAnchor="RFC7748">
+ <front>
+ <title>Elliptic Curves for Security</title>
+ <author fullname="A. Langley" initials="A." surname="Langley"/>
+ <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
+ <author fullname="S. Turner" initials="S." surname="Turner"/>
+ <date month="January" year="2016"/>
+ <abstract>
+ <t indent="0">This memo specifies two elliptic curves over prime
fields that offer a high level of practical security in cryptographic
applications, including Transport Layer Security (TLS). These curves are
intended to operate at the ~128-bit and ~224-bit security level, respectively,
and are generated deterministically based on a list of required properties.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="7748"/>
+ <seriesInfo name="DOI" value="10.17487/RFC7748"/>
+ </reference>
+ <reference anchor="RFC8032"
target="https://www.rfc-editor.org/info/rfc8032"; quoteTitle="true"
derivedAnchor="RFC8032">
+ <front>
+ <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
+ <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
+ <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
+ <date month="January" year="2017"/>
+ <abstract>
+ <t indent="0">This document describes elliptic curve signature
scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is
instantiated with recommended parameters for the edwards25519 and edwards448
curves. An example implementation and test vectors are provided.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8032"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8032"/>
+ </reference>
+ <reference anchor="RFC8126"
target="https://www.rfc-editor.org/info/rfc8126"; quoteTitle="true"
derivedAnchor="RFC8126">
+ <front>
+ <title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
+ <author fullname="M. Cotton" initials="M." surname="Cotton"/>
+ <author fullname="B. Leiba" initials="B." surname="Leiba"/>
+ <author fullname="T. Narten" initials="T." surname="Narten"/>
+ <date month="June" year="2017"/>
+ <abstract>
+ <t indent="0">Many protocols make use of points of extensibility
that use constants to identify various protocol parameters. To ensure that the
values in these fields do not have conflicting uses and to promote
interoperability, their allocations are often coordinated by a central record
keeper. For IETF protocols, that role is filled by the Internet Assigned
Numbers Authority (IANA).</t>
+ <t indent="0">To make assignments in a given registry prudently,
guidance describing the conditions under which new values should be assigned,
as well as when and how modifications to existing values can be made, is
needed. This document defines a framework for the documentation of these
guidelines by specification authors, in order to assure that the provided
guidance for the IANA Considerations is clear and addresses the various issues
that are likely in the operation of [...]
+ <t indent="0">This is the third edition of this document; it
obsoletes RFC 5226.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="BCP" value="26"/>
+ <seriesInfo name="RFC" value="8126"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8126"/>
+ </reference>
+ <reference anchor="RFC8174"
target="https://www.rfc-editor.org/info/rfc8174"; quoteTitle="true"
derivedAnchor="RFC8174">
+ <front>
+ <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
Words</title>
+ <author fullname="B. Leiba" initials="B." surname="Leiba"/>
+ <date month="May" year="2017"/>
+ <abstract>
+ <t indent="0">RFC 2119 specifies common key words that may be
used in protocol specifications. This document aims to reduce the ambiguity by
clarifying that only UPPERCASE usage of the key words have the defined special
meanings.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="BCP" value="14"/>
+ <seriesInfo name="RFC" value="8174"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8174"/>
+ </reference>
+ <reference anchor="RFC8499"
target="https://www.rfc-editor.org/info/rfc8499"; quoteTitle="true"
derivedAnchor="RFC8499">
+ <front>
+ <title>DNS Terminology</title>
+ <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
+ <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
+ <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
+ <date month="January" year="2019"/>
+ <abstract>
+ <t indent="0">The Domain Name System (DNS) is defined in
literally dozens of different RFCs. The terminology used by implementers and
developers of DNS protocols, and by operators of DNS systems, has sometimes
changed in the decades since the DNS was first defined. This document gives
current definitions for many of the terms used in the DNS in a single
document.</t>
+ <t indent="0">This document obsoletes RFC 7719 and updates RFC
2308.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="BCP" value="219"/>
+ <seriesInfo name="RFC" value="8499"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8499"/>
+ </reference>
+ <reference anchor="RFC9106"
target="https://www.rfc-editor.org/info/rfc9106"; quoteTitle="true"
derivedAnchor="RFC9106">
+ <front>
+ <title>Argon2 Memory-Hard Function for Password Hashing and
Proof-of-Work Applications</title>
+ <author fullname="A. Biryukov" initials="A." surname="Biryukov"/>
+ <author fullname="D. Dinu" initials="D." surname="Dinu"/>
+ <author fullname="D. Khovratovich" initials="D."
surname="Khovratovich"/>
+ <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
+ <date month="September" year="2021"/>
+ <abstract>
+ <t indent="0">This document describes the Argon2 memory-hard
function for password hashing and proof-of-work applications. We provide an
implementer-oriented description with test vectors. The purpose is to simplify
adoption of Argon2 for Internet protocols. This document is a product of the
Crypto Forum Research Group (CFRG) in the IRTF.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="9106"/>
+ <seriesInfo name="DOI" value="10.17487/RFC9106"/>
+ </reference>
+ <reference anchor="GANA" target="https://gana.gnunet.org/";
quoteTitle="true" derivedAnchor="GANA">
+ <front>
+ <title>GNUnet Assigned Numbers Authority (GANA)</title>
+ <author>
+ <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+ <reference anchor="MODES"
target="https://doi.org/10.6028/NIST.SP.800-38A"; quoteTitle="true"
derivedAnchor="MODES">
+ <front>
+ <title>Recommendation for Block Cipher Modes of Operation: Methods
and Techniques</title>
+ <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
+ <organization showOnFrontPage="true">NIST</organization>
+ </author>
+ <date year="2001" month="December"/>
+ </front>
+ <refcontent>NIST Special Publication 800-38A</refcontent>
+ <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
+ </reference>
+ <reference anchor="CrockfordB32"
target="https://www.crockford.com/base32.html"; quoteTitle="true"
derivedAnchor="CrockfordB32">
+ <front>
+ <title>Base 32</title>
+ <author initials="D." surname="Crockford" fullname="Douglas
Crockford">
+ </author>
+ <date year="2019" month="March"/>
+ </front>
+ </reference>
+ <reference anchor="XSalsa20"
target="https://cr.yp.to/papers.html#xsalsa"; quoteTitle="true"
derivedAnchor="XSalsa20">
+ <front>
+ <title>Extending the Salsa20 nonce</title>
+ <author initials="D. J." surname="Bernstein" fullname="Daniel
Bernstein">
+ <organization showOnFrontPage="true">University of Illinois at
Chicago</organization>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
+ <reference anchor="Unicode-UAX15"
target="https://www.unicode.org/reports/tr15/tr15-31.html"; quoteTitle="true"
derivedAnchor="Unicode-UAX15">
+ <front>
+ <title>Unicode Standard Annex #15: Unicode Normalization
Forms</title>
+ <author initials="M." surname="Davis" fullname="Mark Davis">
+ <organization showOnFrontPage="true"/>
+ </author>
+ <author initials="K." surname="Whistler" fullname="Ken Whistler">
+ <organization showOnFrontPage="true"/>
+ </author>
+ <author initials="M." surname="Dürst" fullname="Martin Dürst">
+ <organization showOnFrontPage="true"/>
+ </author>
+ <date year="2009" month="September"/>
+ </front>
+ <refcontent>Revision 31, The Unicode Consortium, Mountain
View</refcontent>
+ </reference>
+ <reference anchor="Unicode-UTS46"
target="https://www.unicode.org/reports/tr46"; quoteTitle="true"
derivedAnchor="Unicode-UTS46">
+ <front>
+ <title>Unicode Technical Standard #46: Unicode IDNA Compatibility
Processing</title>
+ <author initials="M." surname="Davis" fullname="Mark Davis">
+ <organization showOnFrontPage="true"/>
+ </author>
+ <author initials="M." surname="Suignard" fullname="Michel
Suignard">
+ <organization showOnFrontPage="true"/>
+ </author>
+ <date year="2023" month="September"/>
+ </front>
+ <refcontent>Revision 31, The Unicode Consortium, Mountain
View</refcontent>
+ </reference>
+ </references>
+ <references pn="section-13.2">
+ <name slugifiedName="name-informative-references">Informative
References</name>
+ <reference anchor="RFC1928"
target="https://www.rfc-editor.org/info/rfc1928"; quoteTitle="true"
derivedAnchor="RFC1928">
+ <front>
+ <title>SOCKS Protocol Version 5</title>
+ <author fullname="M. Leech" initials="M." surname="Leech"/>
+ <author fullname="M. Ganis" initials="M." surname="Ganis"/>
+ <author fullname="Y. Lee" initials="Y." surname="Lee"/>
+ <author fullname="R. Kuris" initials="R." surname="Kuris"/>
+ <author fullname="D. Koblas" initials="D." surname="Koblas"/>
+ <author fullname="L. Jones" initials="L." surname="Jones"/>
+ <date month="March" year="1996"/>
+ <abstract>
+ <t indent="0">This memo describes a protocol that is an
evolution of the previous version of the protocol, version 4 [1]. This new
protocol stems from active discussions and prototype implementations.
[STANDARDS-TRACK]</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="1928"/>
+ <seriesInfo name="DOI" value="10.17487/RFC1928"/>
+ </reference>
+ <reference anchor="RFC4033"
target="https://www.rfc-editor.org/info/rfc4033"; quoteTitle="true"
derivedAnchor="RFC4033">
+ <front>
+ <title>DNS Security Introduction and Requirements</title>
+ <author fullname="R. Arends" initials="R." surname="Arends"/>
+ <author fullname="R. Austein" initials="R." surname="Austein"/>
+ <author fullname="M. Larson" initials="M." surname="Larson"/>
+ <author fullname="D. Massey" initials="D." surname="Massey"/>
+ <author fullname="S. Rose" initials="S." surname="Rose"/>
+ <date month="March" year="2005"/>
+ <abstract>
+ <t indent="0">The Domain Name System Security Extensions
(DNSSEC) add data origin authentication and data integrity to the Domain Name
System. This document introduces these extensions and describes their
capabilities and limitations. This document also discusses the services that
the DNS security extensions do and do not provide. Last, this document
describes the interrelationships between the documents that collectively
describe DNSSEC. [STANDARDS-TRACK]</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="4033"/>
+ <seriesInfo name="DOI" value="10.17487/RFC4033"/>
+ </reference>
+ <reference anchor="RFC6066"
target="https://www.rfc-editor.org/info/rfc6066"; quoteTitle="true"
derivedAnchor="RFC6066">
+ <front>
+ <title>Transport Layer Security (TLS) Extensions: Extension
Definitions</title>
+ <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake
3rd"/>
+ <date month="January" year="2011"/>
+ <abstract>
+ <t indent="0">This document provides specifications for existing
TLS extensions. It is a companion document for RFC 5246, "The Transport Layer
Security (TLS) Protocol Version 1.2". The extensions specified are server_name,
max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac,
and status_request. [STANDARDS-TRACK]</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6066"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6066"/>
+ </reference>
+ <reference anchor="RFC7363"
target="https://www.rfc-editor.org/info/rfc7363"; quoteTitle="true"
derivedAnchor="RFC7363">
+ <front>
+ <title>Self-Tuning Distributed Hash Table (DHT) for REsource
LOcation And Discovery (RELOAD)</title>
+ <author fullname="J. Maenpaa" initials="J." surname="Maenpaa"/>
+ <author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
+ <date month="September" year="2014"/>
+ <abstract>
+ <t indent="0">REsource LOcation And Discovery (RELOAD) is a
peer-to-peer (P2P) signaling protocol that provides an overlay network service.
Peers in a RELOAD overlay network collectively run an overlay algorithm to
organize the overlay and to store and retrieve data. This document describes
how the default topology plugin of RELOAD can be extended to support
self-tuning, that is, to adapt to changing operating conditions such as churn
and network size.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="7363"/>
+ <seriesInfo name="DOI" value="10.17487/RFC7363"/>
+ </reference>
+ <reference anchor="RFC8324"
target="https://www.rfc-editor.org/info/rfc8324"; quoteTitle="true"
derivedAnchor="RFC8324">
+ <front>
+ <title>DNS Privacy, Authorization, Special Uses, Encoding,
Characters, Matching, and Root Structure: Time for Another Look?</title>
+ <author fullname="J. Klensin" initials="J." surname="Klensin"/>
+ <date month="February" year="2018"/>
+ <abstract>
+ <t indent="0">The basic design of the Domain Name System was
completed almost 30 years ago. The last half of that period has been
characterized by significant changes in requirements and expectations, some of
which either require changes to how the DNS is used or can be accommodated only
poorly or not at all. This document asks the question of whether it is time to
either redesign and replace the DNS to match contemporary requirements and
expectations (rather than continuin [...]
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8324"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8324"/>
+ </reference>
+ <reference anchor="RFC8806"
target="https://www.rfc-editor.org/info/rfc8806"; quoteTitle="true"
derivedAnchor="RFC8806">
+ <front>
+ <title>Running a Root Server Local to a Resolver</title>
+ <author fullname="W. Kumari" initials="W." surname="Kumari"/>
+ <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
+ <date month="June" year="2020"/>
+ <abstract>
+ <t indent="0">Some DNS recursive resolvers have
longer-than-desired round-trip times to the closest DNS root server; those
resolvers may have difficulty getting responses from the root servers, such as
during a network attack. Some DNS recursive resolver operators want to prevent
snooping by third parties of requests sent to DNS root servers. In both cases,
resolvers can greatly decrease the round-trip time and prevent observation of
requests by serving a copy of the full r [...]
+ <t indent="0">This document obsoletes RFC 7706.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8806"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8806"/>
+ </reference>
+ <reference anchor="RFC6761"
target="https://www.rfc-editor.org/info/rfc6761"; quoteTitle="true"
derivedAnchor="RFC6761">
+ <front>
+ <title>Special-Use Domain Names</title>
+ <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
+ <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
+ <date month="February" year="2013"/>
+ <abstract>
+ <t indent="0">This document describes what it means to say that
a Domain Name (DNS name) is reserved for special use, when reserving such a
name is appropriate, and the procedure for doing so. It establishes an IANA
registry for such domain names, and seeds it with entries for some of the
already established special domain names.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6761"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6761"/>
+ </reference>
+ <reference anchor="RFC8244"
target="https://www.rfc-editor.org/info/rfc8244"; quoteTitle="true"
derivedAnchor="RFC8244">
+ <front>
+ <title>Special-Use Domain Names Problem Statement</title>
+ <author fullname="T. Lemon" initials="T." surname="Lemon"/>
+ <author fullname="R. Droms" initials="R." surname="Droms"/>
+ <author fullname="W. Kumari" initials="W." surname="Kumari"/>
+ <date month="October" year="2017"/>
+ <abstract>
+ <t indent="0">The policy defined in RFC 6761 for IANA
registrations in the "Special-Use Domain Names" registry has been shown,
through experience, to present challenges that were not anticipated when RFC
6761 was written. This memo presents a list, intended to be comprehensive, of
the problems that have since been identified. In addition, it reviews the
history of domain names and summarizes current IETF publications and some
publications from other organizations relating t [...]
+ <t indent="0">This document should be considered required
reading for IETF participants who wish to express an informed opinion on the
topic of Special-Use Domain Names.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8244"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8244"/>
+ </reference>
+ <reference anchor="RFC9476"
target="https://www.rfc-editor.org/info/rfc9476"; quoteTitle="true"
derivedAnchor="RFC9476">
+ <front>
+ <title>The .alt Special-Use Top-Level Domain</title>
+ <author fullname="W. Kumari" initials="W." surname="Kumari"/>
+ <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
+ <date month="September" year="2023"/>
+ <abstract>
+ <t indent="0">This document reserves a Top-Level Domain (TLD)
label "alt" to be used in non-DNS contexts. It also provides advice and
guidance to developers creating alternative namespaces.</t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="9476"/>
+ <seriesInfo name="DOI" value="10.17487/RFC9476"/>
+ </reference>
+ <reference anchor="TorRendSpec"
target="https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt";
quoteTitle="true" derivedAnchor="TorRendSpec">
+ <front>
+ <title>Tor Rendezvous Specification - Version 3</title>
+ <author>
+ <organization showOnFrontPage="true">Tor Project</organization>
+ </author>
+ <date month="June" year="2023"/>
+ </front>
+ <refcontent>commit b345ca0</refcontent>
+ </reference>
+ <reference anchor="Tor224"
target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135";
quoteTitle="true" derivedAnchor="Tor224">
+ <front>
+ <title>Next-Generation Hidden Services in Tor</title>
+ <author initials="D." surname="Goulet" fullname="David Goulet">
+ </author>
+ <author initials="G." surname="Kadianakis" fullname="George
Kadianakis">
+ </author>
+ <author initials="N." surname="Mathewson" fullname="Nick
Mathewson">
+ </author>
+ <date year="2013" month="November"/>
+ </front>
+ <refcontent>Appendix A.2 ("Tor's key derivation scheme")</refcontent>
+ </reference>
+ <reference anchor="SDSI"
target="https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367";
quoteTitle="true" derivedAnchor="SDSI">
+ <front>
+ <title>SDSI - A Simple Distributed Security Infrastructure</title>
+ <author initials="R. L." surname="Rivest" fullname="Ron L. Rivest">
+ </author>
+ <author initials="B." surname="Lampson" fullname="Butler Lampson">
+ </author>
+ <date year="1996" month="October"/>
+ </front>
+ </reference>
+ <reference anchor="Kademlia"
target="https://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf";
quoteTitle="true" derivedAnchor="Kademlia">
+ <front>
+ <title>Kademlia: A Peer-to-peer Information System Based on the
XOR Metric</title>
+ <author initials="P." surname="Maymounkov" fullname="Petar
Maymounkov">
+ </author>
+ <author initials="D." surname="Mazières" fullname="David Mazières">
+ </author>
+ <date year="2002"/>
+ </front>
+ <seriesInfo name="DOI" value="10.1007/3-540-45748-8_5"/>
+ </reference>
+ <reference anchor="ed25519"
target="https://ed25519.cr.yp.to/ed25519-20110926.pdf"; quoteTitle="true"
derivedAnchor="ed25519">
+ <front>
+ <title>High-speed high-security signatures</title>
+ <author initials="D. J." surname="Bernstein" fullname="Daniel
Bernstein">
+ <organization showOnFrontPage="true">University of Illinois at
Chicago</organization>
+ </author>
+ <author initials="N." surname="Duif" fullname="Niels Duif">
+ <organization showOnFrontPage="true">Technische Universiteit
Eindhoven</organization>
+ </author>
+ <author initials="T." surname="Lange" fullname="Tanja Lange">
+ <organization showOnFrontPage="true">Technische Universiteit
Eindhoven</organization>
+ </author>
+ <author initials="P." surname="Schwabe" fullname="Peter Schwabe">
+ <organization showOnFrontPage="true">National Taiwan
University</organization>
+ </author>
+ <author initials="B-Y." surname="Yang" fullname="Bo-Yin Yang">
+ <organization showOnFrontPage="true">Academia
Sinica</organization>
+ </author>
+ <date year="2011"/>
+ </front>
+ <seriesInfo name="DOI" value="10.1007/s13389-012-0027-1"/>
+ </reference>
+ <reference anchor="GNS"
target="https://sci-hub.st/10.1007/978-3-319-12280-9_9"; quoteTitle="true"
derivedAnchor="GNS">
+ <front>
+ <title>A Censorship-Resistant, Privacy-Enhancing and Fully
Decentralized Name System</title>
+ <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+ <organization showOnFrontPage="true">Technische Universität
München</organization>
+ </author>
+ <author initials="M." surname="Schanzenbach" fullname="Martin
Schanzenbach">
+ <organization showOnFrontPage="true">Technische Universität
München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <organization showOnFrontPage="true">Technische Universität
München</organization>
+ </author>
+ <date month="October" year="2014"/>
+ </front>
+ <refcontent>13th International Conference on Cryptology and Network
Security (CANS)</refcontent>
+ <seriesInfo name="DOI" value="10.13140/2.1.4642.3044"/>
+ </reference>
+ <reference anchor="R5N"
target="https://sci-hub.st/10.1109/ICNSS.2011.6060022"; quoteTitle="true"
derivedAnchor="R5N">
+ <front>
+ <title>R5N: Randomized Recursive Routing for Restricted-Route
Networks</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan S.
Evans">
+ <organization showOnFrontPage="true">Technische Universität
München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <organization showOnFrontPage="true">Technische Universität
München</organization>
+ </author>
+ <date month="September" year="2011"/>
+ </front>
+ <refcontent>5th International Conference on Network and System
Security (NSS)</refcontent>
+ <seriesInfo name="DOI" value="10.1109/ICNSS.2011.6060022"/>
+ </reference>
+ <reference anchor="SecureNS"
target="https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018";
quoteTitle="true" derivedAnchor="SecureNS">
+ <front>
+ <title>Toward secure name resolution on the Internet</title>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <organization showOnFrontPage="true">Bern University of Applied
Sciences</organization>
+ </author>
+ <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+ <organization showOnFrontPage="true">Technische Universität
München</organization>
+ </author>
+ <author initials="M." surname="Ermert" fullname="Monika Ermert">
+ </author>
+ <author initials="J." surname="Appelbaum" fullname="Jacob
Appelbaum">
+ <organization showOnFrontPage="true">TU Eindhoven</organization>
+ </author>
+ <date month="August" year="2018"/>
+ </front>
+ <refcontent>Computers and Security, Volume 77, Issue C, pp.
694-708</refcontent>
+ <seriesInfo name="DOI" value="10.1016/j.cose.2018.01.018"/>
+ </reference>
+ <reference anchor="GNUnetGNS"
target="https://git.gnunet.org/gnunet.git"; quoteTitle="true"
derivedAnchor="GNUnetGNS">
+ <front>
+ <title>gnunet.git - GNUnet core repository</title>
+ <author>
+ <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+ <reference anchor="Ascension"
target="https://git.gnunet.org/ascension.git"; quoteTitle="true"
derivedAnchor="Ascension">
+ <front>
+ <title>ascension.git - DNS zones to GNS migrating using
incremental zone transfer (AXFR/IXFR)</title>
+ <author>
+ <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+ <reference anchor="GNUnet" target="https://gnunet.org";
quoteTitle="true" derivedAnchor="GNUnet">
+ <front>
+ <title>The GNUnet Project (Home Page)</title>
+ <author>
+ <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+ <reference anchor="reclaim" target="https://reclaim.gnunet.org";
quoteTitle="true" derivedAnchor="reclaim">
+ <front>
+ <title>re:claimID - Self-sovereign, Decentralised Identity
Management and Personal Data Sharing</title>
+ <author>
+ <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+ <reference anchor="GoGNS"
target="https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns";
quoteTitle="true" derivedAnchor="GoGNS">
+ <front>
+ <title>gnunet-go (Go GNS)</title>
+ <author initials="B." surname="Fix" fullname="Bernd Fix">
+ </author>
+ <date month="July" year="2023"/>
+ </front>
+ <refcontent>commit 5c815ba</refcontent>
+ </reference>
+ <reference anchor="nsswitch"
target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html";
quoteTitle="true" derivedAnchor="nsswitch">
+ <front>
+ <title>System Databases and Name Service Switch (Section
29)</title>
+ <author>
+ <organization showOnFrontPage="true">GNU Project</organization>
+ </author>
+ </front>
+ </reference>
+ </references>
+ </references>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.a">
+ <name slugifiedName="name-usage-and-migration">Usage and Migration</name>
+ <t indent="0" pn="section-appendix.a-1">
+ This section outlines a number of specific use cases that may
+ help readers of this technical specification better understand the
protocol.
+ The considerations below are not meant to be normative for the
+ GNS protocol in any way.
+ Instead, they are provided in order to give context and to provide
+ some background on what the intended use of the protocol is
+ by its designers.
+ Further, this section provides pointers to migration paths.
+ </t>
+ <section anchor="day_in_zoneowner" numbered="true" removeInRFC="false"
toc="include" pn="section-appendix.a.1">
+ <name slugifiedName="name-zone-dissemination">Zone Dissemination</name>
+ <t indent="0" pn="section-appendix.a.1-1">
+ In order to become a zone owner, it is sufficient to generate
+ a zone key and a corresponding secret key using a GNS
implementation.
+ At this point, the zone owner can manage GNS resource records in a
+ local zone database.
+ The resource records can then be published by a GNS implementation
+ as defined in <xref target="publish" format="default"
sectionFormat="of" derivedContent="Section 6"/>.
+ For other users to resolve the resource records, the respective
+ zone information must be disseminated first.
+ The zone owner may decide to make the zone key and labels known
+ to a selected set of users only or to make this information
available
+ to the general public.
+ </t>
+ <t indent="0" pn="section-appendix.a.1-2">
+ Sharing zone information directly with specific users not only
allows
+ an implementation to potentially preserve zone and record privacy
but also allows
+ the zone owner and the user to establish strong trust relationships.
+ For example, a bank may send a customer letter with a QR code that
+ contains the GNS zone of the bank.
+ This allows the user to scan the QR code and establish a strong
+ link to the zone of the bank and with it, for example, the IP
address
+ of the online banking web site.
+ </t>
+ <t indent="0" pn="section-appendix.a.1-3">
+ Most Internet services likely want to make their zones available
+ to the general public in the most efficient way possible.
+ First, it is reasonable to assume that zones that are commanding
+ high levels of reputation and trust are likely included in the
+ default suffix-to-zone mappings of implementations.
+ Hence, dissemination of a zone through delegation under such zones
+ can be a viable path in order to disseminate a zone publicly.
+ For example, it is conceivable that organizations such as ICANN
+ or country-code TLD registrars also manage GNS zones
+ and offer registration or delegation services.
+ </t>
+ <t indent="0" pn="section-appendix.a.1-4">
+ Following best practices, particularly those related to
+ security and abuse mitigation, are methods that allow zone owners
+ and aspiring registrars to gain a good reputation and, eventually,
+ trust.
+ This includes, of course, diligent protection of private zone key
+ material.
+ Formalizing such best practices is out of scope for this
+ specification and should be addressed in a separate document that
takes
+ <xref target="security" format="default" sectionFormat="of"
derivedContent="Section 9"/> of this document into account.
+ </t>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.a.2">
+ <name slugifiedName="name-start-zone-configuration">Start Zone
Configuration</name>
+ <t indent="0" pn="section-appendix.a.2-1">
+ A user is expected to install a GNS implementation if it is not
already
+ provided through other means such as the operating system
+ or the browser.
+ It is likely that the implementation ships with a
+ default Start Zone configuration.
+ This means that the user is able to resolve GNS names ending on a
+ zTLD or ending on any suffix-to-name mapping that is part of the
+ default Start Zone configuration.
+ At this point, the user may delete or otherwise modify the
+ implementation's default configuration:
+ </t>
+ <ul bare="false" empty="false" indent="3" spacing="normal"
pn="section-appendix.a.2-2">
+ <li pn="section-appendix.a.2-2.1">
+ Deletion of suffix-to-zone mappings may become necessary if the
+ zone owner referenced by the mapping has lost the trust of the
user.
+ For example, this could be due to lax registration policies
resulting
+ in phishing activities.
+ Modification and addition of new mappings are means to heal the
+ namespace perforation that would occur in the case of a deletion
+ or to simply establish a strong direct trust relationship.
+ However, this requires the user's knowledge of the respective zone
+ keys.
+ This information must be retrieved out of band, as illustrated in
+ <xref target="day_in_zoneowner" format="default"
sectionFormat="of" derivedContent="Appendix A.1"/>:
+ a bank may send the user a letter with a QR code that contains the
+ GNS zone of the bank.
+ The user scans the QR code and adds a new suffix-to-name mapping
+ using a chosen local name for their bank.
+ Other examples include scanning zone information off the device of
+ a friend, from a storefront, or from an advertisement.
+ The level of trust in the respective zone is contextual and likely
+ varies from user to user.
+ Trust in a zone provided through a letter from a bank that
+ may also include a credit card is certainly different from a zone
+ found on a random advertisement on the street.
+ However, this trust is immediately tangible to the user and can
+ be reflected in the local naming as well.
+ </li>
+ <li pn="section-appendix.a.2-2.2">
+ Users that are also clients should facilitate the modification of
the Start Zone
+ configuration -- for example, by providing a QR code reader or
other
+ import mechanisms.
+ Implementations are ideally implemented
+ according to best practices and addressing applicable points
+ from <xref target="security" format="default" sectionFormat="of"
derivedContent="Section 9"/>.
+ Formalizing such best practices is out of scope for this
+ specification.
+ </li>
+ </ul>
+ </section>
+ <section anchor="uc_virthost" numbered="true" removeInRFC="false"
toc="include" pn="section-appendix.a.3">
+ <name slugifiedName="name-globally-unique-names-and-t">Globally Unique
Names and the Web</name>
+ <t indent="0" pn="section-appendix.a.3-1">
+ HTTP virtual hosting and TLS Server Name Indication (SNI) are common
+ use cases on the Web.
+ HTTP clients supply a DNS name in the HTTP
+ "Host"-header or as part of the TLS handshake, respectively.
+ This allows the HTTP server to serve the indicated virtual host
+ with a matching TLS certificate.
+ The global uniqueness of DNS names is a prerequisite of those use
cases.
+ </t>
+ <t indent="0" pn="section-appendix.a.3-2">
+ Not all GNS names are globally unique.
+ However, any resource record in GNS can be represented as a
+ concatenation of a GNS label and the zTLD of the zone.
+ While not memorable, this globally unique GNS name can be
+ leveraged in order to facilitate the same use cases.
+ Consider the GNS name "www.example.gns.alt" entered in a GNS-aware
+ HTTP client.
+ At first, "www.example.gns.alt" is resolved using GNS, yielding a
record
+ set.
+ Then, the HTTP client determines the virtual host as follows:
+ </t>
+ <t indent="0" pn="section-appendix.a.3-3">
+ If there is a LEHO record (<xref target="gnsrecords_leho"
format="default" sectionFormat="of" derivedContent="Section 5.3.1"/>)
+ containing "www.example.com" in the record set, then the HTTP
+ client uses this as the value of the
+ "Host"-header field of the HTTP request:
+ </t>
+ <sourcecode name="" type="http-message" markers="false"
pn="section-appendix.a.3-4">
+GET / HTTP/1.1
+Host: www.example.com
+</sourcecode>
+ <t indent="0" pn="section-appendix.a.3-5">
+In the absence of a LEHO record, an additional GNS resolution is
+required to check whether "www.example.gns.alt" itself points to a
+zone delegation record, which implies that the record set that was
+originally resolved is published under the apex label.
+ </t>
+ <t indent="0" pn="section-appendix.a.3-6">
+If it does, the unique GNS name is simply the zTLD representation of
+the delegated zone:
+ </t>
+ <sourcecode name="" type="http-message" markers="false"
pn="section-appendix.a.3-7">
+GET / HTTP/1.1
+Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+</sourcecode>
+ <t indent="0" pn="section-appendix.a.3-8">
+On the other hand, if there is no zone delegation record for
+"www.example.gns.alt", then the unique GNS name is the concatenation of
+the leftmost label (e.g., "www") and the zTLD representation of the zone:
+ </t>
+ <sourcecode name="" type="http-message" markers="false"
pn="section-appendix.a.3-9">
+GET / HTTP/1.1
+Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+</sourcecode>
+ <t indent="0" pn="section-appendix.a.3-10">
+Note that this second GNS resolution does not require any additional
+network operation, as only the local record processing differs as per
+the exception mentioned in the last sentence of <xref
target="delegation_processing" format="default" sectionFormat="of"
derivedContent="Section 7.3.4"/>.
+ </t>
+ <t indent="0" pn="section-appendix.a.3-11">
+ If the HTTP client is a browser, the use of a unique GNS name
+ for virtual hosting or TLS SNI does not necessarily have to be
+ shown to the user.
+ For example, the name in the URL bar may remain as
"www.example.gns.alt"
+ even if the used unique name in the "Host"-header differs.
+ </t>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.a.4">
+ <name slugifiedName="name-migration-paths">Migration Paths</name>
+ <t indent="0" pn="section-appendix.a.4-1">
+ DNS resolution is built into a variety of existing software
+ components -- most significantly, operating systems and HTTP
clients.
+ This section illustrates possible migration paths for both in order
+ to enable legacy applications to resolve GNS names.
+ </t>
+ <t indent="0" pn="section-appendix.a.4-2">
+ One way to efficiently facilitate the resolution of GNS names
+ is via GNS-enabled DNS server implementations.
+ Local DNS queries are thereby either rerouted or explicitly
configured
+ to be resolved by a "DNS-to-GNS" server that runs locally.
+ This DNS server tries to interpret any incoming query for a name
+ as a GNS resolution request.
+ If no Start Zone can be found for the name and it does not end in
+ a zTLD, the server tries to resolve the name in DNS.
+ Otherwise, the name is resolved in GNS.
+ In the latter case, the resulting record set is converted to a DNS
+ answer packet and is returned accordingly.
+ An implementation of a DNS-to-GNS server can be found in
+ <xref target="GNUnet" format="default" sectionFormat="of"
derivedContent="GNUnet"/>.
+ </t>
+ <t indent="0" pn="section-appendix.a.4-3">
+ A similar approach is to use operating system extensions such as
+ the NSS <xref target="nsswitch" format="default"
sectionFormat="of" derivedContent="nsswitch"/>.
+ It allows the system administrator to configure plugins
+ that are used for hostname resolution.
+ A GNS nsswitch plugin can be used in a fashion similar to
+ that used for the DNS-to-GNS server.
+ An implementation of a glibc-compatible nsswitch plugin for GNS
+ can be found in <xref target="GNUnet" format="default"
sectionFormat="of" derivedContent="GNUnet"/>.
+ </t>
+ <t indent="0" pn="section-appendix.a.4-4">
+ The methods above are usually also effective for HTTP client
+ software.
+ However, HTTP clients are commonly used in combination with
+ TLS.
+ TLS certificate validation, and SNI in particular, require
additional logic in HTTP clients when GNS names are
+ in play (<xref target="uc_virthost" format="default"
sectionFormat="of" derivedContent="Appendix A.3"/>).
+ In order to transparently enable this functionality for migration
+ purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928"
format="default" sectionFormat="of" derivedContent="RFC1928"/>
+ can be configured to resolve domain names.
+ The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable
+ of resolving both GNS and DNS names.
+ In the event of a TLS connection request with a GNS name, the
SOCKS5
+ proxy can terminate the TLS connection
+ and establish a secure connection against the requested host.
+ In order to establish a secure connection, the proxy may use LEHO
+ and TLSA records stored in the record set under the GNS name.
+ The proxy must provide a locally trusted certificate for the GNS
+ name to the HTTP client; this usually requires the generation and
+ configuration of a local trust anchor in the browser.
+ An implementation of this SOCKS5 proxy can be found in
+ <xref target="GNUnet" format="default" sectionFormat="of"
derivedContent="GNUnet"/>.
+ </t>
+ </section>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.b">
+ <name slugifiedName="name-example-flows">Example Flows</name>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.b.1">
+ <name slugifiedName="name-aaaa-example-resolution">AAAA Example
Resolution</name>
+ <figure anchor="figure_resolution_ex_aaaa" align="left"
suppress-title="false" pn="figure-24">
+ <name slugifiedName="name-example-resolution-of-an-ip">Example
Resolution of an IPv6 Address</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-appendix.b.1-1.1">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ (1) +----------+ | | | |
+| | | | (4,6) | | Record | |
+|Application|----------| Resolver |---------------|->| Storage | |
+| |<---------| |<--------------|--| |/
++-----------+ (8) +----------+ (5,7) | +---------+
+ A |
+ | |
+ (2,3) | |
+ | |
+ | |
+ +---------+ |
+ / v /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <ol indent="adaptive" spacing="normal" start="1" type="1"
pn="section-appendix.b.1-2">
+ <li pn="section-appendix.b.1-2.1" derivedCounter="1.">Look up AAAA
record for name: "www.example.gnu.gns.alt".</li>
+ <li pn="section-appendix.b.1-2.2" derivedCounter="2.">Determine
Start Zone for "www.example.gnu.gns.alt".</li>
+ <li pn="section-appendix.b.1-2.3" derivedCounter="3.">Start Zone:
zkey0 - Remainder: "www.example".</li>
+ <li pn="section-appendix.b.1-2.4" derivedCounter="4.">Calculate
q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li>
+ <li pn="section-appendix.b.1-2.5" derivedCounter="5.">Retrieve and
decrypt RRBLOCK consisting of a single PKEY record containing zkey1.</li>
+ <li pn="section-appendix.b.1-2.6" derivedCounter="6.">Calculate
q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li>
+ <li pn="section-appendix.b.1-2.7" derivedCounter="7.">Retrieve
RRBLOCK consisting of a single AAAA record containing the IPv6 address
2001:db8::1.</li>
+ <li pn="section-appendix.b.1-2.8" derivedCounter="8.">Return record
set to application.</li>
+ </ol>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.b.2">
+ <name slugifiedName="name-redirect-example-resolution">REDIRECT
Example Resolution</name>
+ <figure anchor="figure_resolution_ex_redir" align="left"
suppress-title="false" pn="figure-25">
+ <name slugifiedName="name-example-resolution-of-an-ipv">Example
Resolution of an IPv6 Address with Redirect</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-appendix.b.2-1.1">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ (1) +----------+ | | | |
+| | | | (4,6,8) | | Record | |
+|Application|----------| Resolver |----------------|->| Storage | |
+| |<---------| |<---------------|--| |/
++-----------+ (10) +----------+ (5,7,9) | +---------+
+ A |
+ | |
+ (2,3) | |
+ | |
+ | |
+ +---------+ |
+ / v /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <ol indent="adaptive" spacing="normal" start="1" type="1"
pn="section-appendix.b.2-2">
+ <li pn="section-appendix.b.2-2.1" derivedCounter="1.">Look up AAAA
record for name: "www.example.tld.gns.alt".</li>
+ <li pn="section-appendix.b.2-2.2" derivedCounter="2.">Determine
Start Zone for "www.example.tld.gns.alt".</li>
+ <li pn="section-appendix.b.2-2.3" derivedCounter="3.">Start Zone:
zkey0 - Remainder: "www.example".</li>
+ <li pn="section-appendix.b.2-2.4" derivedCounter="4.">Calculate
q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li>
+ <li pn="section-appendix.b.2-2.5" derivedCounter="5.">Retrieve and
decrypt RRBLOCK consisting of a single PKEY record containing zkey1.</li>
+ <li pn="section-appendix.b.2-2.6" derivedCounter="6.">Calculate
q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li>
+ <li pn="section-appendix.b.2-2.7" derivedCounter="7.">Retrieve and
decrypt RRBLOCK consisting of a single REDIRECT record containing "www2.+".</li>
+ <li pn="section-appendix.b.2-2.8" derivedCounter="8.">Calculate
q2=SHA512(ZKDF(zkey1, "www2")) and initiate GET(q2).</li>
+ <li pn="section-appendix.b.2-2.9" derivedCounter="9.">Retrieve and
decrypt RRBLOCK consisting of a single AAAA record containing the IPv6 address
2001:db8::1.</li>
+ <li pn="section-appendix.b.2-2.10" derivedCounter="10.">Return
record set to application.</li>
+ </ol>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.b.3">
+ <name slugifiedName="name-gns2dns-example-resolution">GNS2DNS Example
Resolution</name>
+ <figure anchor="figure_resolution_ex_gnsdns" align="left"
suppress-title="false" pn="figure-26">
+ <name slugifiedName="name-example-resolution-of-an-ipv6">Example
Resolution of an IPv6 Address with DNS Handover</name>
+ <artwork name="" type="" alt="" align="left"
pn="section-appendix.b.3-1.1">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ (1) +----------+ | | | |
+| | | | (4) | | Record | |
+|Application|----------| Resolver |------------------|->| Storage | |
+| |<---------| |<-----------------|--| |/
++-----------+ (8) +----------+ (5) | +---------+
+ A A |
+ | | (6,7) |
+ (2,3) | +----------+ |
+ | | |
+ | v |
+ +---------+ +------------+ |
+ / v /| | System DNS | |
+ +---------+ | | Resolver | |
+ | | | +------------+ |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <ol indent="adaptive" spacing="normal" start="1" type="1"
pn="section-appendix.b.3-2">
+ <li pn="section-appendix.b.3-2.1" derivedCounter="1.">Look up AAAA
record for name: "www.example.gnu.gns.alt".</li>
+ <li pn="section-appendix.b.3-2.2" derivedCounter="2.">Determine
Start Zone for "www.example.gnu.gns.alt".</li>
+ <li pn="section-appendix.b.3-2.3" derivedCounter="3.">Start Zone:
zkey0 - Remainder: "www.example".</li>
+ <li pn="section-appendix.b.3-2.4" derivedCounter="4.">Calculate
q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li>
+ <li pn="section-appendix.b.3-2.5" derivedCounter="5.">Retrieve and
decrypt RRBLOCK consisting of a single GNS2DNS record containing the name
"example.com" and the DNS server IPv4 address 192.0.2.1.</li>
+ <li pn="section-appendix.b.3-2.6" derivedCounter="6.">Use system
resolver to look up a AAAA record for the DNS name "www.example.com".</li>
+ <li pn="section-appendix.b.3-2.7" derivedCounter="7.">Retrieve a DNS
reply consisting of a single AAAA record containing the IPv6 address
2001:db8::1.</li>
+ <li pn="section-appendix.b.3-2.8" derivedCounter="8.">Return record
set to application.</li>
+ </ol>
+ </section>
+ </section>
+ <section anchor="app-c" numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.c">
+ <name slugifiedName="name-base32gns">Base32GNS</name>
+ <t indent="0" pn="section-appendix.c-1">
+ Encoding converts a byte array into a string of symbols.
+ Decoding converts a string of symbols into a byte array.
+ Decoding fails if the input string has symbols outside the defined
set.
+ </t>
+ <t indent="0" pn="section-appendix.c-2">
+ <xref target="CrockfordB32Encode" format="default" sectionFormat="of"
derivedContent="Table 4"/> defines the encoding and decoding symbols for a given
+ symbol value.
+ Each symbol value encodes 5 bits.
+ It can be used to implement the encoding by reading it as follows:
+ a symbol "A" or "a" is decoded to a 5-bit value 10 when decoding.
+ A 5-bit block with a value of 18 is encoded to the character "J" when
encoding.
+ If the bit length of the byte string to encode is not a multiple of 5,
+ it is padded to the next multiple with zeroes.
+ In order to further increase tolerance for failures in character
+ recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the
same value as the
+ letter "V" in Base32GNS.
+ </t>
+ <table anchor="CrockfordB32Encode" align="center" pn="table-4">
+ <name slugifiedName="name-the-base32gns-alphabet-incl">The Base32GNS
Alphabet, Including the Additional Encoding Symbol "U"</name>
+ <thead>
+ <tr>
+ <th align="left" colspan="1" rowspan="1">Symbol Value</th>
+ <th align="left" colspan="1" rowspan="1">Decoding Symbol</th>
+ <th align="left" colspan="1" rowspan="1">Encoding Symbol</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">0</td>
+ <td align="left" colspan="1" rowspan="1">0 O o</td>
+ <td align="left" colspan="1" rowspan="1">0</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">1</td>
+ <td align="left" colspan="1" rowspan="1">1 I i L l</td>
+ <td align="left" colspan="1" rowspan="1">1</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">2</td>
+ <td align="left" colspan="1" rowspan="1">2</td>
+ <td align="left" colspan="1" rowspan="1">2</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">3</td>
+ <td align="left" colspan="1" rowspan="1">3</td>
+ <td align="left" colspan="1" rowspan="1">3</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">4</td>
+ <td align="left" colspan="1" rowspan="1">4</td>
+ <td align="left" colspan="1" rowspan="1">4</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">5</td>
+ <td align="left" colspan="1" rowspan="1">5</td>
+ <td align="left" colspan="1" rowspan="1">5</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">6</td>
+ <td align="left" colspan="1" rowspan="1">6</td>
+ <td align="left" colspan="1" rowspan="1">6</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">7</td>
+ <td align="left" colspan="1" rowspan="1">7</td>
+ <td align="left" colspan="1" rowspan="1">7</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">8</td>
+ <td align="left" colspan="1" rowspan="1">8</td>
+ <td align="left" colspan="1" rowspan="1">8</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">9</td>
+ <td align="left" colspan="1" rowspan="1">9</td>
+ <td align="left" colspan="1" rowspan="1">9</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">10</td>
+ <td align="left" colspan="1" rowspan="1">A a</td>
+ <td align="left" colspan="1" rowspan="1">A</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">11</td>
+ <td align="left" colspan="1" rowspan="1">B b</td>
+ <td align="left" colspan="1" rowspan="1">B</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">12</td>
+ <td align="left" colspan="1" rowspan="1">C c</td>
+ <td align="left" colspan="1" rowspan="1">C</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">13</td>
+ <td align="left" colspan="1" rowspan="1">D d</td>
+ <td align="left" colspan="1" rowspan="1">D</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">14</td>
+ <td align="left" colspan="1" rowspan="1">E e</td>
+ <td align="left" colspan="1" rowspan="1">E</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">15</td>
+ <td align="left" colspan="1" rowspan="1">F f</td>
+ <td align="left" colspan="1" rowspan="1">F</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">16</td>
+ <td align="left" colspan="1" rowspan="1">G g</td>
+ <td align="left" colspan="1" rowspan="1">G</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">17</td>
+ <td align="left" colspan="1" rowspan="1">H h</td>
+ <td align="left" colspan="1" rowspan="1">H</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">18</td>
+ <td align="left" colspan="1" rowspan="1">J j</td>
+ <td align="left" colspan="1" rowspan="1">J</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">19</td>
+ <td align="left" colspan="1" rowspan="1">K k</td>
+ <td align="left" colspan="1" rowspan="1">K</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">20</td>
+ <td align="left" colspan="1" rowspan="1">M m</td>
+ <td align="left" colspan="1" rowspan="1">M</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">21</td>
+ <td align="left" colspan="1" rowspan="1">N n</td>
+ <td align="left" colspan="1" rowspan="1">N</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">22</td>
+ <td align="left" colspan="1" rowspan="1">P p</td>
+ <td align="left" colspan="1" rowspan="1">P</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">23</td>
+ <td align="left" colspan="1" rowspan="1">Q q</td>
+ <td align="left" colspan="1" rowspan="1">Q</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">24</td>
+ <td align="left" colspan="1" rowspan="1">R r</td>
+ <td align="left" colspan="1" rowspan="1">R</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">25</td>
+ <td align="left" colspan="1" rowspan="1">S s</td>
+ <td align="left" colspan="1" rowspan="1">S</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">26</td>
+ <td align="left" colspan="1" rowspan="1">T t</td>
+ <td align="left" colspan="1" rowspan="1">T</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">27</td>
+ <td align="left" colspan="1" rowspan="1">V v U u</td>
+ <td align="left" colspan="1" rowspan="1">V</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">28</td>
+ <td align="left" colspan="1" rowspan="1">W w</td>
+ <td align="left" colspan="1" rowspan="1">W</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">29</td>
+ <td align="left" colspan="1" rowspan="1">X x</td>
+ <td align="left" colspan="1" rowspan="1">X</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">30</td>
+ <td align="left" colspan="1" rowspan="1">Y y</td>
+ <td align="left" colspan="1" rowspan="1">Y</td>
+ </tr>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">31</td>
+ <td align="left" colspan="1" rowspan="1">Z z</td>
+ <td align="left" colspan="1" rowspan="1">Z</td>
+ </tr>
+ </tbody>
+ </table>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.d">
+ <name slugifiedName="name-test-vectors">Test Vectors</name>
+ <t indent="0" pn="section-appendix.d-1">
+ The following test vectors can be used by implementations to test
+ for conformance with this specification. Unless indicated otherwise,
+ the test vectors are provided as hexadecimal byte arrays.
+ </t>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.d.1">
+ <name slugifiedName="name-base32gns-encoding-decoding">Base32GNS
Encoding/Decoding</name>
+ <t indent="0" pn="section-appendix.d.1-1">
+ The following are test vectors for the Base32GNS encoding used for
zTLDs. The input strings are encoded without the zero terminator.
+ </t>
+ <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.1-2">
+Base32GNS-Encode:
+ Input string: "Hello World"
+ Output string: "91JPRV3F41BPYWKCCG"
+
+ Input bytes: 474e55204e616d652053797374656d
+ Output string: "8X75A82EC5PPA82KF5SQ8SBD"
+
+Base32GNS-Decode:
+ Input string: "91JPRV3F41BPYWKCCG"
+ Output string: "Hello World"
+
+ Input string: "91JPRU3F41BPYWKCCG"
+ Output string: "Hello World"
+</sourcecode>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.d.2">
+ <name slugifiedName="name-record-sets">Record Sets</name>
+ <t indent="0" pn="section-appendix.d.2-1">
+ The test vectors include record sets with a variety
+ of record types and flags for both PKEY and EDKEY zones.
+ This includes labels with UTF-8 characters to demonstrate
+ internationalized labels.
+ </t>
+ <t indent="0" pn="section-appendix.d.2-2"><strong>(1) PKEY zone with
ASCII label and one delegation record</strong></t>
+ <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.2-3">
+Zone private key (d, big-endian):
+ 50 d7 b6 52 a4 ef ea df
+ f3 73 96 90 97 85 e5 95
+ 21 71 a0 21 78 c8 e7 d4
+ 50 fa 90 79 25 fa fd 98
+
+Zone identifier (ztype|zkey):
+ 00 01 00 00 67 7c 47 7d
+ 2d 93 09 7c 85 b1 95 c6
+ f9 6d 84 ff 61 f5 98 2c
+ 2c 4f e0 2d 5a 11 fe df
+ b0 c2 90 1f
+
+zTLD:
+000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+
+Label:
+ 74 65 73 74 64 65 6c 65
+ 67 61 74 69 6f 6e
+
+Number of records (integer): 1
+
+Record #0 := (
+ EXPIRATION: 8143584694000000 us
+ 00 1c ee 8c 10 e2 59 80
+
+ DATA_SIZE:
+ 00 20
+
+ TYPE:
+ 00 01 00 00
+
+ FLAGS: 00 01
+
+ DATA:
+ 21 e3 b3 0f f9 3b c6 d3
+ 5a c8 c6 e0 e1 3a fd ff
+ 79 4c b7 b4 4b bb c7 48
+ d2 59 d0 a0 28 4d be 84
+
+)
+
+RDATA:
+ 00 1c ee 8c 10 e2 59 80
+ 00 20 00 01 00 01 00 00
+ 21 e3 b3 0f f9 3b c6 d3
+ 5a c8 c6 e0 e1 3a fd ff
+ 79 4c b7 b4 4b bb c7 48
+ d2 59 d0 a0 28 4d be 84
+
+Encryption NONCE|EXPIRATION|BLOCK COUNTER:
+ e9 0a 00 61 00 1c ee 8c
+ 10 e2 59 80 00 00 00 01
+
+Encryption key (K):
+ 86 4e 71 38 ea e7 fd 91
+ a3 01 36 89 9c 13 2b 23
+ ac eb db 2c ef 43 cb 19
+ f6 bf 55 b6 7d b9 b3 b3
+
+Storage key (q):
+ 4a dc 67 c5 ec ee 9f 76
+ 98 6a bd 71 c2 22 4a 3d
+ ce 2e 91 70 26 c9 a0 9d
+ fd 44 ce f3 d2 0f 55 a2
+ 73 32 72 5a 6c 8a fb bb
+ b0 f7 ec 9a f1 cc 42 64
+ 12 99 40 6b 04 fd 9b 5b
+ 57 91 f8 6c 4b 08 d5 f4
+
+ZKDF(zkey, label):
+ 18 2b b6 36 ed a7 9f 79
+ 57 11 bc 27 08 ad bb 24
+ 2a 60 44 6a d3 c3 08 03
+ 12 1d 03 d3 48 b7 ce b6
+
+Derived private key (d', big-endian):
+ 0a 4c 5e 0f 00 63 df ce
+ db c8 c7 f2 b2 2c 03 0c
+ 86 28 b2 c2 cb ac 9f a7
+ 29 aa e6 1f 89 db 3e 9c
+
+BDATA:
+ 0c 1e da 5c c0 94 a1 c7
+ a8 88 64 9d 25 fa ee bd
+ 60 da e6 07 3d 57 d8 ae
+ 8d 45 5f 4f 13 92 c0 74
+ e2 6a c6 69 bd ee c2 34
+ 62 b9 62 95 2c c6 e9 eb
+
+RRBLOCK:
+ 00 00 00 a0 00 01 00 00
+ 18 2b b6 36 ed a7 9f 79
+ 57 11 bc 27 08 ad bb 24
+ 2a 60 44 6a d3 c3 08 03
+ 12 1d 03 d3 48 b7 ce b6
+ 0a d1 0b c1 3b 40 3b 5b
+ 25 61 26 b2 14 5a 6f 60
+ c5 14 f9 51 ff a7 66 f7
+ a3 fd 4b ac 4a 4e 19 90
+ 05 5c b8 7e 8d 1b fd 19
+ aa 09 a4 29 f7 29 e9 f5
+ c6 ee c2 47 0a ce e2 22
+ 07 59 e9 e3 6c 88 6f 35
+ 00 1c ee 8c 10 e2 59 80
+ 0c 1e da 5c c0 94 a1 c7
+ a8 88 64 9d 25 fa ee bd
+ 60 da e6 07 3d 57 d8 ae
+ 8d 45 5f 4f 13 92 c0 74
+ e2 6a c6 69 bd ee c2 34
+ 62 b9 62 95 2c c6 e9 eb
+</sourcecode>
+ <t indent="0" pn="section-appendix.d.2-4"><strong>(2) PKEY zone with
UTF-8 label and three records</strong></t>
+ <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.2-5">
+Zone private key (d, big-endian):
+ 50 d7 b6 52 a4 ef ea df
+ f3 73 96 90 97 85 e5 95
+ 21 71 a0 21 78 c8 e7 d4
+ 50 fa 90 79 25 fa fd 98
+
+Zone identifier (ztype|zkey):
+ 00 01 00 00 67 7c 47 7d
+ 2d 93 09 7c 85 b1 95 c6
+ f9 6d 84 ff 61 f5 98 2c
+ 2c 4f e0 2d 5a 11 fe df
+ b0 c2 90 1f
+
+zTLD:
+000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+
+Label:
+ e5 a4 a9 e4 b8 8b e7 84
+ a1 e6 95 b5
+
+Number of records (integer): 3
+
+Record #0 := (
+ EXPIRATION: 8143584694000000 us
+ 00 1c ee 8c 10 e2 59 80
+
+ DATA_SIZE:
+ 00 10
+
+ TYPE:
+ 00 00 00 1c
+
+ FLAGS: 00 00
+
+ DATA:
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 de ad be ef
+
+)
+
+Record #1 := (
+ EXPIRATION: 17999736901000000 us
+ 00 3f f2 aa 54 08 db 40
+
+ DATA_SIZE:
+ 00 06
+
+ TYPE:
+ 00 01 00 01
+
+ FLAGS: 00 00
+
+ DATA:
+ e6 84 9b e7 a7 b0
+
+)
+
+Record #2 := (
+ EXPIRATION: 11464693629000000 us
+ 00 28 bb 13 ff 37 19 40
+
+ DATA_SIZE:
+ 00 0b
+
+ TYPE:
+ 00 00 00 10
+
+ FLAGS: 00 04
+
+ DATA:
+ 48 65 6c 6c 6f 20 57 6f
+ 72 6c 64
+
+)
+
+RDATA:
+ 00 1c ee 8c 10 e2 59 80
+ 00 10 00 00 00 00 00 1c
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 de ad be ef
+ 00 3f f2 aa 54 08 db 40
+ 00 06 00 00 00 01 00 01
+ e6 84 9b e7 a7 b0 00 28
+ bb 13 ff 37 19 40 00 0b
+ 00 04 00 00 00 10 48 65
+ 6c 6c 6f 20 57 6f 72 6c
+ 64 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+
+Encryption NONCE|EXPIRATION|BLOCK COUNTER:
+ ee 96 33 c1 00 1c ee 8c
+ 10 e2 59 80 00 00 00 01
+
+Encryption key (K):
+ fb 3a b5 de 23 bd da e1
+ 99 7a af 7b 92 c2 d2 71
+ 51 40 8b 77 af 7a 41 ac
+ 79 05 7c 4d f5 38 3d 01
+
+Storage key (q):
+ af f0 ad 6a 44 09 73 68
+ 42 9a c4 76 df a1 f3 4b
+ ee 4c 36 e7 47 6d 07 aa
+ 64 63 ff 20 91 5b 10 05
+ c0 99 1d ef 91 fc 3e 10
+ 90 9f 87 02 c0 be 40 43
+ 67 78 c7 11 f2 ca 47 d5
+ 5c f0 b5 4d 23 5d a9 77
+
+ZKDF(zkey, label):
+ a5 12 96 df 75 7e e2 75
+ ca 11 8d 4f 07 fa 7a ae
+ 55 08 bc f5 12 aa 41 12
+ 14 29 d4 a0 de 9d 05 7e
+
+Derived private key (d', big-endian):
+ 0a be 56 d6 80 68 ab 40
+ e1 44 79 0c de 9a cf 4d
+ 78 7f 2d 3c 63 b8 53 05
+ 74 6e 68 03 32 15 f2 ab
+
+BDATA:
+ d8 c2 8d 2f d6 96 7d 1a
+ b7 22 53 f2 10 98 b8 14
+ a4 10 be 1f 59 98 de 03
+ f5 8f 7e 7c db 7f 08 a6
+ 16 51 be 4d 0b 6f 8a 61
+ df 15 30 44 0b d7 47 dc
+ f0 d7 10 4f 6b 8d 24 c2
+ ac 9b c1 3d 9c 6f e8 29
+ 05 25 d2 a6 d0 f8 84 42
+ 67 a1 57 0e 8e 29 4d c9
+ 3a 31 9f cf c0 3e a2 70
+ 17 d6 fd a3 47 b4 a7 94
+ 97 d7 f6 b1 42 2d 4e dd
+ 82 1c 19 93 4e 96 c1 aa
+ 87 76 57 25 d4 94 c7 64
+ b1 55 dc 6d 13 26 91 74
+
+RRBLOCK:
+ 00 00 00 f0 00 01 00 00
+ a5 12 96 df 75 7e e2 75
+ ca 11 8d 4f 07 fa 7a ae
+ 55 08 bc f5 12 aa 41 12
+ 14 29 d4 a0 de 9d 05 7e
+ 08 5b d6 5f d4 85 10 51
+ ba ce 2a 45 2a fc 8a 7e
+ 4f 6b 2c 1f 74 f0 20 35
+ d9 64 1a cd ba a4 66 e0
+ 00 ce d6 f2 d2 3b 63 1c
+ 8e 8a 0b 38 e2 ba e7 9a
+ 22 ca d8 1d 4c 50 d2 25
+ 35 8e bc 17 ac 0f 89 9e
+ 00 1c ee 8c 10 e2 59 80
+ d8 c2 8d 2f d6 96 7d 1a
+ b7 22 53 f2 10 98 b8 14
+ a4 10 be 1f 59 98 de 03
+ f5 8f 7e 7c db 7f 08 a6
+ 16 51 be 4d 0b 6f 8a 61
+ df 15 30 44 0b d7 47 dc
+ f0 d7 10 4f 6b 8d 24 c2
+ ac 9b c1 3d 9c 6f e8 29
+ 05 25 d2 a6 d0 f8 84 42
+ 67 a1 57 0e 8e 29 4d c9
+ 3a 31 9f cf c0 3e a2 70
+ 17 d6 fd a3 47 b4 a7 94
+ 97 d7 f6 b1 42 2d 4e dd
+ 82 1c 19 93 4e 96 c1 aa
+ 87 76 57 25 d4 94 c7 64
+ b1 55 dc 6d 13 26 91 74
+</sourcecode>
+ <t indent="0" pn="section-appendix.d.2-6"><strong>(3) EDKEY zone with
ASCII label and one delegation record</strong></t>
+ <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.2-7">
+Zone private key (d):
+ 5a f7 02 0e e1 91 60 32
+ 88 32 35 2b bc 6a 68 a8
+ d7 1a 7c be 1b 92 99 69
+ a7 c6 6d 41 5a 0d 8f 65
+
+Zone identifier (ztype|zkey):
+ 00 01 00 14 3c f4 b9 24
+ 03 20 22 f0 dc 50 58 14
+ 53 b8 5d 93 b0 47 b6 3d
+ 44 6c 58 45 cb 48 44 5d
+ db 96 68 8f
+
+zTLD:
+000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
+
+Label:
+ 74 65 73 74 64 65 6c 65
+ 67 61 74 69 6f 6e
+
+Number of records (integer): 1
+
+Record #0 := (
+ EXPIRATION: 8143584694000000 us
+ 00 1c ee 8c 10 e2 59 80
+
+ DATA_SIZE:
+ 00 20
+
+ TYPE:
+ 00 01 00 00
+
+ FLAGS: 00 01
+
+ DATA:
+ 21 e3 b3 0f f9 3b c6 d3
+ 5a c8 c6 e0 e1 3a fd ff
+ 79 4c b7 b4 4b bb c7 48
+ d2 59 d0 a0 28 4d be 84
+
+)
+
+RDATA:
+ 00 1c ee 8c 10 e2 59 80
+ 00 20 00 01 00 01 00 00
+ 21 e3 b3 0f f9 3b c6 d3
+ 5a c8 c6 e0 e1 3a fd ff
+ 79 4c b7 b4 4b bb c7 48
+ d2 59 d0 a0 28 4d be 84
+
+Encryption NONCE|EXPIRATION:
+ 98 13 2e a8 68 59 d3 5c
+ 88 bf d3 17 fa 99 1b cb
+ 00 1c ee 8c 10 e2 59 80
+
+Encryption key (K):
+ 85 c4 29 a9 56 7a a6 33
+ 41 1a 96 91 e9 09 4c 45
+ 28 16 72 be 58 60 34 aa
+ e4 a2 a2 cc 71 61 59 e2
+
+Storage key (q):
+ ab aa ba c0 e1 24 94 59
+ 75 98 83 95 aa c0 24 1e
+ 55 59 c4 1c 40 74 e2 55
+ 7b 9f e6 d1 54 b6 14 fb
+ cd d4 7f c7 f5 1d 78 6d
+ c2 e0 b1 ec e7 60 37 c0
+ a1 57 8c 38 4e c6 1d 44
+ 56 36 a9 4e 88 03 29 e9
+
+ZKDF(zkey, label):
+ 9b f2 33 19 8c 6d 53 bb
+ db ac 49 5c ab d9 10 49
+ a6 84 af 3f 40 51 ba ca
+ b0 dc f2 1c 8c f2 7a 1a
+
+nonce := SHA-256(dh[32..63] || h):
+ 14 f2 c0 6b ed c3 aa 2d
+ f0 71 13 9c 50 39 34 f3
+ 4b fa 63 11 a8 52 f2 11
+ f7 3a df 2e 07 61 ec 35
+
+Derived private key (d', big-endian):
+ 3b 1b 29 d4 23 0b 10 a8
+ ec 4d a3 c8 6e db 88 ea
+ cd 54 08 5c 1d db 63 f7
+ a9 d7 3f 7c cb 2f c3 98
+
+BDATA:
+ 57 7c c6 c9 5a 14 e7 04
+ 09 f2 0b 01 67 e6 36 d0
+ 10 80 7c 4f 00 37 2d 69
+ 8c 82 6b d9 2b c2 2b d6
+ bb 45 e5 27 7c 01 88 1d
+ 6a 43 60 68 e4 dd f1 c6
+ b7 d1 41 6f af a6 69 7c
+ 25 ed d9 ea e9 91 67 c3
+
+RRBLOCK:
+ 00 00 00 b0 00 01 00 14
+ 9b f2 33 19 8c 6d 53 bb
+ db ac 49 5c ab d9 10 49
+ a6 84 af 3f 40 51 ba ca
+ b0 dc f2 1c 8c f2 7a 1a
+ 9f 56 a8 86 ea 73 9d 59
+ 17 50 8f 9b 75 56 39 f3
+ a9 ac fa ed ed ca 7f bf
+ a7 94 b1 92 e0 8b f9 ed
+ 4c 7e c8 59 4c 9f 7b 4e
+ 19 77 4f f8 38 ec 38 7a
+ 8f 34 23 da ac 44 9f 59
+ db 4e 83 94 3f 90 72 00
+ 00 1c ee 8c 10 e2 59 80
+ 57 7c c6 c9 5a 14 e7 04
+ 09 f2 0b 01 67 e6 36 d0
+ 10 80 7c 4f 00 37 2d 69
+ 8c 82 6b d9 2b c2 2b d6
+ bb 45 e5 27 7c 01 88 1d
+ 6a 43 60 68 e4 dd f1 c6
+ b7 d1 41 6f af a6 69 7c
+ 25 ed d9 ea e9 91 67 c3
+</sourcecode>
+ <t indent="0" pn="section-appendix.d.2-8"><strong>(4) EDKEY zone with
UTF-8 label and three records</strong></t>
+ <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.2-9">
+Zone private key (d):
+ 5a f7 02 0e e1 91 60 32
+ 88 32 35 2b bc 6a 68 a8
+ d7 1a 7c be 1b 92 99 69
+ a7 c6 6d 41 5a 0d 8f 65
+
+Zone identifier (ztype|zkey):
+ 00 01 00 14 3c f4 b9 24
+ 03 20 22 f0 dc 50 58 14
+ 53 b8 5d 93 b0 47 b6 3d
+ 44 6c 58 45 cb 48 44 5d
+ db 96 68 8f
+
+zTLD:
+000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
+
+Label:
+ e5 a4 a9 e4 b8 8b e7 84
+ a1 e6 95 b5
+
+Number of records (integer): 3
+
+Record #0 := (
+ EXPIRATION: 8143584694000000 us
+ 00 1c ee 8c 10 e2 59 80
+
+ DATA_SIZE:
+ 00 10
+
+ TYPE:
+ 00 00 00 1c
+
+ FLAGS: 00 00
+
+ DATA:
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 de ad be ef
+
+)
+
+Record #1 := (
+ EXPIRATION: 17999736901000000 us
+ 00 3f f2 aa 54 08 db 40
+
+ DATA_SIZE:
+ 00 06
+
+ TYPE:
+ 00 01 00 01
+
+ FLAGS: 00 00
+
+ DATA:
+ e6 84 9b e7 a7 b0
+
+)
+
+Record #2 := (
+ EXPIRATION: 11464693629000000 us
+ 00 28 bb 13 ff 37 19 40
+
+ DATA_SIZE:
+ 00 0b
+
+ TYPE:
+ 00 00 00 10
+
+ FLAGS: 00 04
+
+ DATA:
+ 48 65 6c 6c 6f 20 57 6f
+ 72 6c 64
+
+)
+
+RDATA:
+ 00 1c ee 8c 10 e2 59 80
+ 00 10 00 00 00 00 00 1c
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 de ad be ef
+ 00 3f f2 aa 54 08 db 40
+ 00 06 00 00 00 01 00 01
+ e6 84 9b e7 a7 b0 00 28
+ bb 13 ff 37 19 40 00 0b
+ 00 04 00 00 00 10 48 65
+ 6c 6c 6f 20 57 6f 72 6c
+ 64 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+
+Encryption NONCE|EXPIRATION:
+ bb 0d 3f 0f bd 22 42 77
+ 50 da 5d 69 12 16 e6 c9
+ 00 1c ee 8c 10 e2 59 80
+
+Encryption key (K):
+ 3d f8 05 bd 66 87 aa 14
+ 20 96 28 c2 44 b1 11 91
+ 88 c3 92 56 37 a4 1e 5d
+ 76 49 6c 29 45 dc 37 7b
+
+Storage key (q):
+ ba f8 21 77 ee c0 81 e0
+ 74 a7 da 47 ff c6 48 77
+ 58 fb 0d f0 1a 6c 7f bb
+ 52 fc 8a 31 be f0 29 af
+ 74 aa 0d c1 5a b8 e2 fa
+ 7a 54 b4 f5 f6 37 f6 15
+ 8f a7 f0 3c 3f ce be 78
+ d3 f9 d6 40 aa c0 d1 ed
+
+ZKDF(zkey, label):
+ 74 f9 00 68 f1 67 69 53
+ 52 a8 a6 c2 eb 98 48 98
+ c5 3a cc a0 98 04 70 c6
+ c8 12 64 cb dd 78 ad 11
+
+nonce := SHA-256(dh[32..63] || h):
+ f8 6a b5 33 8a 74 d7 a1
+ d2 77 ea 11 ff 95 cb e8
+ 3a cf d3 97 3b b4 ab ca
+ 0a 1b 60 62 c3 7a b3 9c
+
+Derived private key (d', big-endian):
+ 17 c0 68 a6 c3 f7 20 de
+ 0e 1b 69 ff 3f 53 e0 5d
+ 3f e5 c5 b0 51 25 7a 89
+ a6 3c 1a d3 5a c4 35 58
+
+BDATA:
+ 4e b3 5a 50 d4 0f e1 a4
+ 29 c7 f4 b2 67 a0 59 de
+ 4e 2c 8a 89 a5 ed 53 d3
+ d4 92 58 59 d2 94 9f 7f
+ 30 d8 a2 0c aa 96 f8 81
+ 45 05 2d 1c da 04 12 49
+ 8f f2 5f f2 81 6e f0 ce
+ 61 fe 69 9b fa c7 2c 15
+ dc 83 0e a9 b0 36 17 1c
+ cf ca bb dd a8 de 3c 86
+ ed e2 95 70 d0 17 4b 82
+ 82 09 48 a9 28 b7 f0 0e
+ fb 40 1c 10 fe 80 bb bb
+ 02 76 33 1b f7 f5 1b 8d
+ 74 57 9c 14 14 f2 2d 50
+ 1a d2 5a e2 49 f5 bb f2
+ a6 c3 72 59 d1 75 e4 40
+ b2 94 39 c6 05 19 cb b1
+
+RRBLOCK:
+ 00 00 01 00 00 01 00 14
+ 74 f9 00 68 f1 67 69 53
+ 52 a8 a6 c2 eb 98 48 98
+ c5 3a cc a0 98 04 70 c6
+ c8 12 64 cb dd 78 ad 11
+ 75 6d 2c 15 7a d2 ea 4f
+ c0 b1 b9 1c 08 03 79 44
+ 61 d3 de f2 0d d1 63 6c
+ fe dc 03 89 c5 49 d1 43
+ 6c c3 5b 4e 1b f8 89 5a
+ 64 6b d9 a6 f4 6b 83 48
+ 1d 9c 0e 91 d4 e1 be bb
+ 6a 83 52 6f b7 25 2a 06
+ 00 1c ee 8c 10 e2 59 80
+ 4e b3 5a 50 d4 0f e1 a4
+ 29 c7 f4 b2 67 a0 59 de
+ 4e 2c 8a 89 a5 ed 53 d3
+ d4 92 58 59 d2 94 9f 7f
+ 30 d8 a2 0c aa 96 f8 81
+ 45 05 2d 1c da 04 12 49
+ 8f f2 5f f2 81 6e f0 ce
+ 61 fe 69 9b fa c7 2c 15
+ dc 83 0e a9 b0 36 17 1c
+ cf ca bb dd a8 de 3c 86
+ ed e2 95 70 d0 17 4b 82
+ 82 09 48 a9 28 b7 f0 0e
+ fb 40 1c 10 fe 80 bb bb
+ 02 76 33 1b f7 f5 1b 8d
+ 74 57 9c 14 14 f2 2d 50
+ 1a d2 5a e2 49 f5 bb f2
+ a6 c3 72 59 d1 75 e4 40
+ b2 94 39 c6 05 19 cb b1
+</sourcecode>
+ </section>
+ <section numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.d.3">
+ <name slugifiedName="name-zone-revocation-2">Zone Revocation</name>
+ <t indent="0" pn="section-appendix.d.3-1">
+ The following is an example revocation for a PKEY zone:
+ </t>
+ <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.3-2">
+Zone private key (d, big-endian):
+ 6f ea 32 c0 5a f5 8b fa
+ 97 95 53 d1 88 60 5f d5
+ 7d 8b f9 cc 26 3b 78 d5
+ f7 47 8c 07 b9 98 ed 70
+
+Zone identifier (ztype|zkey):
+ 00 01 00 00 2c a2 23 e8
+ 79 ec c4 bb de b5 da 17
+ 31 92 81 d6 3b 2e 3b 69
+ 55 f1 c3 77 5c 80 4a 98
+ d5 f8 dd aa
+
+zTLD:
+000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8
+
+Difficulty (5 base difficulty + 2 epochs): 7
+
+Signed message:
+ 00 00 00 34 00 00 00 03
+ 00 05 ff 1c 56 e4 b2 68
+ 00 01 00 00 2c a2 23 e8
+ 79 ec c4 bb de b5 da 17
+ 31 92 81 d6 3b 2e 3b 69
+ 55 f1 c3 77 5c 80 4a 98
+ d5 f8 dd aa
+
+Proof:
+ 00 05 ff 1c 56 e4 b2 68
+ 00 00 39 5d 18 27 c0 00
+ 38 0b 54 aa 70 16 ac a2
+ 38 0b 54 aa 70 16 ad 62
+ 38 0b 54 aa 70 16 af 3e
+ 38 0b 54 aa 70 16 af 93
+ 38 0b 54 aa 70 16 b0 bf
+ 38 0b 54 aa 70 16 b0 ee
+ 38 0b 54 aa 70 16 b1 c9
+ 38 0b 54 aa 70 16 b1 e5
+ 38 0b 54 aa 70 16 b2 78
+ 38 0b 54 aa 70 16 b2 b2
+ 38 0b 54 aa 70 16 b2 d6
+ 38 0b 54 aa 70 16 b2 e4
+ 38 0b 54 aa 70 16 b3 2c
+ 38 0b 54 aa 70 16 b3 5a
+ 38 0b 54 aa 70 16 b3 9d
+ 38 0b 54 aa 70 16 b3 c0
+ 38 0b 54 aa 70 16 b3 dd
+ 38 0b 54 aa 70 16 b3 f4
+ 38 0b 54 aa 70 16 b4 42
+ 38 0b 54 aa 70 16 b4 76
+ 38 0b 54 aa 70 16 b4 8c
+ 38 0b 54 aa 70 16 b4 a4
+ 38 0b 54 aa 70 16 b4 c9
+ 38 0b 54 aa 70 16 b4 f0
+ 38 0b 54 aa 70 16 b4 f7
+ 38 0b 54 aa 70 16 b5 79
+ 38 0b 54 aa 70 16 b6 34
+ 38 0b 54 aa 70 16 b6 8e
+ 38 0b 54 aa 70 16 b7 b4
+ 38 0b 54 aa 70 16 b8 7e
+ 38 0b 54 aa 70 16 b8 f8
+ 38 0b 54 aa 70 16 b9 2a
+ 00 01 00 00 2c a2 23 e8
+ 79 ec c4 bb de b5 da 17
+ 31 92 81 d6 3b 2e 3b 69
+ 55 f1 c3 77 5c 80 4a 98
+ d5 f8 dd aa 08 ca ff de
+ 3c 6d f1 45 f7 e0 79 81
+ 15 37 b2 b0 42 2d 5e 1f
+ b2 01 97 81 ec a2 61 d1
+ f9 d8 ea 81 0a bc 2f 33
+ 47 7f 04 e3 64 81 11 be
+ 71 c2 48 82 1a d6 04 f4
+ 94 e7 4d 0b f5 11 d2 c1
+ 62 77 2e 81
+</sourcecode>
+ <t indent="0" pn="section-appendix.d.3-3">
+ The following is an example revocation for an EDKEY zone:
+ </t>
+ <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.3-4">
+Zone private key (d):
+ 5a f7 02 0e e1 91 60 32
+ 88 32 35 2b bc 6a 68 a8
+ d7 1a 7c be 1b 92 99 69
+ a7 c6 6d 41 5a 0d 8f 65
+
+Zone identifier (ztype|zkey):
+ 00 01 00 14 3c f4 b9 24
+ 03 20 22 f0 dc 50 58 14
+ 53 b8 5d 93 b0 47 b6 3d
+ 44 6c 58 45 cb 48 44 5d
+ db 96 68 8f
+
+zTLD:
+000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
+
+Difficulty (5 base difficulty + 2 epochs): 7
+
+Signed message:
+ 00 00 00 34 00 00 00 03
+ 00 05 ff 1c 57 35 42 bd
+ 00 01 00 14 3c f4 b9 24
+ 03 20 22 f0 dc 50 58 14
+ 53 b8 5d 93 b0 47 b6 3d
+ 44 6c 58 45 cb 48 44 5d
+ db 96 68 8f
+
+Proof:
+ 00 05 ff 1c 57 35 42 bd
+ 00 00 39 5d 18 27 c0 00
+ 58 4c 93 3c b0 99 2a 08
+ 58 4c 93 3c b0 99 2d f7
+ 58 4c 93 3c b0 99 2e 21
+ 58 4c 93 3c b0 99 2e 2a
+ 58 4c 93 3c b0 99 2e 53
+ 58 4c 93 3c b0 99 2e 8e
+ 58 4c 93 3c b0 99 2f 13
+ 58 4c 93 3c b0 99 2f 2d
+ 58 4c 93 3c b0 99 2f 3c
+ 58 4c 93 3c b0 99 2f 41
+ 58 4c 93 3c b0 99 2f fd
+ 58 4c 93 3c b0 99 30 33
+ 58 4c 93 3c b0 99 30 82
+ 58 4c 93 3c b0 99 30 a2
+ 58 4c 93 3c b0 99 30 e1
+ 58 4c 93 3c b0 99 31 ce
+ 58 4c 93 3c b0 99 31 de
+ 58 4c 93 3c b0 99 32 12
+ 58 4c 93 3c b0 99 32 4e
+ 58 4c 93 3c b0 99 32 9f
+ 58 4c 93 3c b0 99 33 31
+ 58 4c 93 3c b0 99 33 87
+ 58 4c 93 3c b0 99 33 8c
+ 58 4c 93 3c b0 99 33 e5
+ 58 4c 93 3c b0 99 33 f3
+ 58 4c 93 3c b0 99 34 26
+ 58 4c 93 3c b0 99 34 30
+ 58 4c 93 3c b0 99 34 68
+ 58 4c 93 3c b0 99 34 88
+ 58 4c 93 3c b0 99 34 8a
+ 58 4c 93 3c b0 99 35 4c
+ 58 4c 93 3c b0 99 35 bd
+ 00 01 00 14 3c f4 b9 24
+ 03 20 22 f0 dc 50 58 14
+ 53 b8 5d 93 b0 47 b6 3d
+ 44 6c 58 45 cb 48 44 5d
+ db 96 68 8f 04 ae 26 f7
+ 63 56 5a b7 aa ab 01 71
+ 72 4f 3c a8 bc c5 1a 98
+ b7 d4 c9 2e a3 3c d9 34
+ 4c a8 b6 3e 04 53 3a bf
+ 1a 3c 05 49 16 b3 68 2c
+ 5c a8 cb 4d d0 f8 4c 3b
+ 77 48 7a ac 6e ce 38 48
+ 0b a9 d5 00
+</sourcecode>
+ </section>
+ </section>
+ <section numbered="false" removeInRFC="false" toc="include"
pn="section-appendix.e">
+ <name slugifiedName="name-acknowledgements">Acknowledgements</name>
+ <t indent="0" pn="section-appendix.e-1">
+ The authors thank all reviewers for their comments. In particular,
+ we thank <contact fullname="D. J. Bernstein"/>, <contact
fullname="S. Bortzmeyer"/>, <contact fullname="A. Farrel"/>, <contact
fullname="E. Lear"/>, and <contact fullname="R. Salz"/> for their
+ insightful and detailed technical reviews. We thank <contact
fullname="J. Yao"/> and <contact fullname="J. Klensin"/> for the
+ internationalization reviews. We thank <contact fullname="Dr. J.
Appelbaum"/> for suggesting the name "GNU Name System" and <contact
fullname="Dr. Richard Stallman"/> for approving its use. We thank <contact
fullname="T. Lange"/> and <contact fullname="M. Wachs"/> for their earlier
contributions to the design and implementation of GNS. We thank NLnet and NGI
DISCOVERY for funding
+ work on the GNU Name System.
+ </t>
+ </section>
+ <section anchor="authors-addresses" numbered="false" removeInRFC="false"
toc="include" pn="section-appendix.f">
+ <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
+ <author fullname="Martin Schanzenbach" initials="M."
surname="Schanzenbach">
+ <organization showOnFrontPage="true">Fraunhofer AISEC</organization>
+ <address>
+ <postal>
+ <street>Lichtenbergstrasse 11</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>Germany</country>
+ </postal>
+ <email>martin.schanzenbach@aisec.fraunhofer.de</email>
+ </address>
+ </author>
+ <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
+ <organization showOnFrontPage="true">Berner
Fachhochschule</organization>
+ <address>
+ <postal>
+ <street>Hoeheweg 80</street>
+ <city>Biel/Bienne</city>
+ <code>2501</code>
+ <country>Switzerland</country>
+ </postal>
+ <email>christian.grothoff@bfh.ch</email>
+ </address>
+ </author>
+ <author fullname="Bernd Fix" initials="B." surname="Fix">
+ <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>Germany</country>
+ </postal>
+ <email>fix@gnunet.org</email>
+ </address>
+ </author>
+ </section>
+ </back>
+</rfc>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: RFC 9498,
gnunet <=