[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: update with actual rfc source
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: update with actual rfc source |
|
Date: |
Wed, 22 Nov 2023 15:15:03 +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 72e7276 update with actual rfc source
72e7276 is described below
commit 72e72760540b6453efcd6429aa0c0da415dcaa53
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Nov 22 15:14:59 2023 +0100
update with actual rfc source
---
rfc9498.xml | 3790 +++++++++++++++++++++++++----------------------------------
1 file changed, 1570 insertions(+), 2220 deletions(-)
diff --git a/rfc9498.xml b/rfc9498.xml
index db28c64..5305c50 100644
--- a/rfc9498.xml
+++ b/rfc9498.xml
@@ -1,13 +1,33 @@
-<?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>
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE rfc [
+ <!ENTITY nbsp " ">
+ <!ENTITY zwsp "​">
+ <!ENTITY nbhy "‑">
+ <!ENTITY wj "⁠">
+]>
+
+<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">
+
+ <!-- xml2rfc v2v3 conversion 2.26.0 -->
+ <front>
<title abbrev="The GNU Name System">The GNU Name System</title>
- <seriesInfo name="RFC" value="9498" stream="independent"/>
+ <seriesInfo name="RFC" value="9498"/>
<author fullname="Martin Schanzenbach" initials="M."
surname="Schanzenbach">
- <organization showOnFrontPage="true">Fraunhofer AISEC</organization>
+ <organization>Fraunhofer AISEC</organization>
<address>
<postal>
<street>Lichtenbergstrasse 11</street>
@@ -19,7 +39,7 @@
</address>
</author>
<author fullname="Christian Grothoff" initials="C." surname="Grothoff">
- <organization showOnFrontPage="true">Berner Fachhochschule</organization>
+ <organization>Berner Fachhochschule</organization>
<address>
<postal>
<street>Hoeheweg 80</street>
@@ -31,7 +51,7 @@
</address>
</author>
<author fullname="Bernd Fix" initials="B." surname="Fix">
- <organization showOnFrontPage="true">GNUnet e.V.</organization>
+ <organization>GNUnet e.V.</organization>
<address>
<postal>
<street>Boltzmannstrasse 3</street>
@@ -42,22 +62,23 @@
<email>fix@gnunet.org</email>
</address>
</author>
- <date month="11" year="2023"/>
+ <date month="November" year="2023"/>
<keyword>name systems</keyword>
- <abstract pn="section-abstract">
- <t indent="0" pn="section-abstract-1">
+
+ <abstract>
+ <t>
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">
+ <t>
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">
+ <t>
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
@@ -65,300 +86,11 @@
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">
+ <section anchor="introduction">
+ <name>Introduction</name>
+ <t>
This specification describes the GNU Name System (GNS), a
censorship-resistant, privacy-preserving, and decentralized
domain name resolution protocol. GNS cryptographically secures
@@ -366,220 +98,219 @@
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
+ <t>
+ Per Domain Name System (DNS) terminology <xref target="RFC1035"/>, GNS
roughly follows the idea of a local
+ root zone deployment (see <xref target="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"/>,
+ By following the guidelines in <xref target="namespace_ambiguity"/>,
users should manage to avoid any confusion as to how names are
resolved.
</t>
- <t indent="0" pn="section-1-3">
+ <t>
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"/>,
+ Distributed Security Infrastructure <xref target="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"/>.
+ cryptographic ideas behind GNS can be found in <xref target="GNS"/>.
</t>
- <t indent="0" pn="section-1-4">
+ <t>
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>",
+ <section>
+ <name>Requirements Notation</name>
+ <t>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
+ are to be interpreted as described in BCP 14
+ <xref target="RFC2119"/> <xref target="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">
+ <section>
+ <name>Terminology</name>
+ <dl newline="false">
+ <dt>Apex Label:</dt>
+ <dd>
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"/>.
+ <xref target="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">
+ <dt>Application:</dt>
+ <dd>
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">
+ <dt>Blinded Zone Key:</dt>
+ <dd>
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">
+ <dt>Extension Label:</dt>
+ <dd>
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"/>).
+ record (see <xref target="gnsrecords_redirect"/>).
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">
+ <dt>Label Separator:</dt>
+ <dd>
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"/>),
+ (see below) and boxed records (see <xref target="gnsrecords_box"/>),
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"/>.
+ <dt>Label:</dt>
+ <dd>
+ A GNS label is a label as defined in <xref target="RFC8499"/>.
Labels are UTF-8 strings in Unicode
- Normalization Form C (NFC) <xref target="Unicode-UAX15"
format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.
+ Normalization Form C (NFC) <xref target="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"/>).
+ (see also <xref target="security_abuse"/>).
</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
+ <dt>Name:</dt>
+ <dd>
+ A name in GNS is a domain name as defined in <xref
target="RFC8499"/>:
+ names are UTF-8 strings <xref target="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
+ Applications (IDNA) <xref target="RFC5890"/>.
+ In the spirit of <xref target="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"/>.
+ <xref target="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"/>).
+ (see <xref target="namespace_ambiguity"/>).
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"/>.
+ <xref target="RFC9476"/>. ".gns.alt" is also registered in the
GANA ".alt Subdomains" registry
+ <xref target="GANA"/>.
</dd>
- <dt pn="section-2-1.15">Resolver:</dt>
- <dd pn="section-2-1.16">
+ <dt>Resolver:</dt>
+ <dd>
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"/>.
+ <xref target="resolution"/>.
</dd>
- <dt pn="section-2-1.17">Resource Record:</dt>
- <dd pn="section-2-1.18">
+ <dt>Resource Record:</dt>
+ <dd>
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">
+ <dt>Start Zone:</dt>
+ <dd>
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"/>).
+ (see <xref target="governance"/>).
</dd>
- <dt pn="section-2-1.21">Top-Level Domain (TLD):</dt>
- <dd pn="section-2-1.22">
+ <dt>Top-Level Domain (TLD):</dt>
+ <dd>
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"/>),
+ Unlike DNS TLDs (defined in <xref target="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"/>),
+ with the exception of zTLDs (see <xref target="zTLD"/>),
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.
+ (see <xref target="governance"/>) and thus might not be globally
unique.
</dd>
- <dt pn="section-2-1.23">Zone:</dt>
- <dd pn="section-2-1.24">
+ <dt>Zone:</dt>
+ <dd>
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">
+ <dt>Zone Key:</dt>
+ <dd>
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">
+ <dt>Zone Key Derivation Function:</dt>
+ <dd>
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">
+ <dt>Zone Publisher:</dt>
+ <dd>
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"/>.
+ <xref target="publish"/>.
</dd>
- <dt pn="section-2-1.31">Zone Owner:</dt>
- <dd pn="section-2-1.32">
+ <dt>Zone Owner:</dt>
+ <dd>
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">
+ <dt>Zone Top-Level Domain (zTLD):</dt>
+ <dd>
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"/>).
+ zone key of a zone (see <xref target="zTLD"/>).
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">
+ <dt>Zone Type:</dt>
+ <dd>
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">
+ <section anchor="overview">
+ <name>Overview</name>
+ <t>
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
+ <dl newline="true">
+ <dt>
+ Global names through the concept of zTLDs:</dt><dd>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">
+ <dt>
Memorable petnames for zones:</dt>
- <dd pn="section-3-2.4">Users can configure local, memorable references
to zones.
+ <dd>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">
+ <dt>
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
+ <dd>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.
@@ -588,14 +319,14 @@
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">
+ <t>
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"/>).
+ supporting configuration such as Start Zones (see <xref
target="governance"/>).
</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">
+ <section anchor="names">
+ <name>Names and Zones</name>
+ <t>
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
@@ -603,10 +334,10 @@
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">
+ <sourcecode>
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
</sourcecode>
- <t indent="0" pn="section-3.1-3">
+ <t>
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.
@@ -615,16 +346,16 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
work on the local system where the "pet.gns.alt" petname is
configured.
</t>
- <t indent="0" pn="section-3.1-4">
+ <t>
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"/>.
+ <xref target="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.
+ (see <xref target="zones"/>) 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.
+ (see <xref target="rrecords"/>) 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
@@ -634,12 +365,12 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
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">
+ <section anchor="publishing">
+ <name>Publishing Binding Information</name>
+ <t>
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"/>.
+ before being published in remote key-value storage (see <xref
target="publish"/>),
+ as illustrated in <xref target="figure_arch_publish"/>.
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
@@ -656,12 +387,12 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
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"/>.
+ based on <xref target="RFC7363"/>, <xref target="Kademlia"/>, or
+ <xref target="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">
+ <figure anchor="figure_arch_publish">
+ <name>An Example Diagram of Two Hosts Publishing GNS Zones</name>
+ <artwork name="" type="" alt="">
Host A | Remote | Host B
| Storage |
| |
@@ -684,23 +415,23 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
+---------+ | | +---------+
</artwork>
</figure>
- <t indent="0" pn="section-3.2-3">
+ <t>
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
+ configured (see <xref target="resolution"/>) 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">
+ <section anchor="resolving">
+ <name>Resolving Names</name>
+ <t>
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"/>.
+ delegations recursively, as illustrated in <xref
target="figure_arch_resolv"/>.
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"/>).
+ fetches the respective record set from the storage layer (see <xref
target="resolution"/>).
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.
@@ -714,9 +445,9 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
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">
+ <figure anchor="figure_arch_resolv">
+ <name>High-Level View of the GNS Resolution Process</name>
+ <artwork name="" type="" alt="">
Local Host | Remote
| Storage
|
@@ -742,34 +473,34 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
</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">
+ <section anchor="zones">
+ <name>Zones</name>
+ <t>
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.
+ (see <xref target="zTLD"/>), 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"/>.
+ in the GANA "GNS Record Types" registry <xref target="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">
+ <dl newline="true">
+ <dt>KeyGen() -> d, zkey</dt>
+ <dd>
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">
+ <dt>ZKDF(zkey, label) -> zkey'</dt>
+ <dd>
A ZKDF that blinds a zone key zkey
- using a label. zkey and zkey' must be unlinkable. Furthermore,
+ 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">
+ <dt>S-Encrypt(zkey, label, expiration, plaintext) -> ciphertext</dt>
+ <dd>
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.
@@ -777,38 +508,38 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
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">
+ <dt>S-Decrypt(zkey, label, expiration, ciphertext) -> plaintext</dt>
+ <dd>
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">
+ <dt>Sign(d, message) -> signature</dt>
+ <dd>
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">
+ <dt>Verify(zkey, message, signature) -> boolean</dt>
+ <dd>
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">
+ <dt>SignDerived(d, label, message) -> signature</dt>
+ <dd>
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">
+ <dt>VerifyDerived(zkey', message, signature) -> boolean</dt>
+ <dd>
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
@@ -816,36 +547,36 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
the Verify() function.
</dd>
</dl>
- <t indent="0" pn="section-4-3">
+ <t>
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"/>.
+ their corresponding delegation records as discussed in <xref
target="gnsrecords_delegation"/>.
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"/>).
+ record types in the GANA "GNS Record Types" registry (see <xref
target="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.
+ of this document -- in particular, <xref
target="security_cryptography"/> -- 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">
+ <section anchor="zTLD">
+ <name>Zone Top-Level Domain (zTLD)</name>
+ <t>
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"/>).
+ zone key (see <xref target="figure_zid"/>).
The used encoding is a variation of the Crockford Base32 encoding
- <xref target="CrockfordB32" format="default" sectionFormat="of"
derivedContent="CrockfordB32"/> called Base32GNS.
+ <xref target="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
+ variation, are defined in <xref target="CrockfordB32Encode"/>, found
in <xref target="app-c"/>.
+ The functions for encoding and decoding based on <xref
target="CrockfordB32Encode"/> 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">
+ <figure anchor="figure_zid">
+ <name>The Binary Representation of the zTLD</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| ZONE TYPE | ZONE KEY /
@@ -855,21 +586,21 @@
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
+-----+-----+-----+-----+-----+-----+-----+-----+
</artwork>
</figure>
- <t indent="0" pn="section-4.1-3">
+ <t>
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">
+ <t>
Consequently, a zTLD is encoded and decoded as follows:
</t>
- <artwork name="" type="" alt="" align="left" pn="section-4.1-5">
+ <artwork name="" type="" alt="">
zTLD := Base32GNS-Encode(ztype||zkey)
ztype||zkey := Base32GNS-Decode(zTLD)
</artwork>
- <t indent="0" pn="section-4.1-6">
+ <t>
where "||" is the concatenation operator.
</t>
- <t indent="0" pn="section-4.1-7">
+ <t>
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:
@@ -886,13 +617,13 @@ ztype||zkey := Base32GNS-Decode(zTLD)
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">
+ <artwork name="" type="" alt="">
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">
+ <section anchor="revocation">
+ <name>Zone Revocation</name>
+ <t>
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.
@@ -900,7 +631,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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"/>.
+ network is implemented in <xref target="GNUnet"/>.
Alternatively, revocation messages could also be distributed via a
distributed ledger or a trusted central server.
To prevent
@@ -909,39 +640,39 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <t>
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
+ derivation function as defined in <xref target="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 newline="false">
+ <dt>S:</dt>
+ <dd>The salt. Fixed 16-byte string: "GnsRevocationPow"</dd>
+ <dt>t:</dt>
+ <dd>Number of iterations: 3</dd>
+ <dt>m:</dt>
+ <dd>Memory size in KiB: 1024</dd>
+ <dt>T:</dt>
+ <dd>Output length of hash in bytes: 64</dd>
+ <dt>p:</dt>
+ <dd>Parallelization parameter: 1</dd>
+ <dt>v:</dt>
+ <dd>Algorithm version: 0x13</dd>
+ <dt>y:</dt>
+ <dd>Algorithm type (Argon2id): 2</dd>
+ <dt>X:</dt>
+ <dd>Unused</dd>
+ <dt>K:</dt>
+ <dd>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
+ <t>
+ <xref target="figure_revocation"/> 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">
+ <figure anchor="figure_revocation">
+ <name>The Format of the PoW Data</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| POW |
@@ -955,28 +686,28 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>POW:</dt>
+ <dd>
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">
+ <dt>TIMESTAMP:</dt>
+ <dd>
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">
+ <dt>ZONE TYPE:</dt>
+ <dd>
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">
+ <dt>ZONE KEY:</dt>
+ <dd>
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">
+ <t>
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.
@@ -984,7 +715,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <t>
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
@@ -995,24 +726,24 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <t>
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 newline="false">
+ <dt>Z:</dt>
+ <dd>The number of PoWs that are required. Its value is fixed at
32.</dd>
+ <dt>D:</dt>
+ <dd>The lower limit of the average difficulty. Its value is fixed at
22.</dd>
+ <dt>EPOCH:</dt>
+ <dd>A single epoch. Its value is fixed at 365 days in
microseconds.</dd>
</dl>
- <t indent="0" pn="section-4.2-11">
+ <t>
The revocation message wire format is illustrated in
- <xref target="figure_revocationdata" format="default"
sectionFormat="of" derivedContent="Figure 5"/>.
+ <xref target="figure_revocationdata"/>.
</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">
+ <figure anchor="figure_revocationdata">
+ <name>The Revocation Message Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP |
@@ -1037,16 +768,16 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>TIMESTAMP:</dt>
+ <dd>
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">
+ <dt>TTL:</dt>
+ <dd>
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.
@@ -1055,42 +786,42 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <dt>POW_i:</dt>
+ <dd>
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">
+ <dt>ZONE TYPE:</dt>
+ <dd>
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">
+ <dt>ZONE KEY:</dt>
+ <dd>
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">
+ <dt>SIGNATURE:</dt>
+ <dd>
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"/>).
+ (see <xref target="zones"/>).
</dd>
</dl>
- <t indent="0" pn="section-4.2-14">
+ <t>
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"/>.
+ in <xref target="figure_revsigwithpseudo"/>.
</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">
+ <figure anchor="figure_revsigwithpseudo">
+ <name>The Wire Format of the Revocation Data for Signing</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x03) |
@@ -1104,14 +835,14 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>SIZE:</dt>
+ <dd>
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">
+ <dt>PURPOSE:</dt>
+ <dd>
A 32-bit signature purpose flag.
The value of this field <bcp14>MUST</bcp14> be 3.
The value is encoded in network byte order.
@@ -1119,30 +850,30 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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"/>.
+ GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>.
</dd>
- <dt pn="section-4.2-16.5">TIMESTAMP:</dt>
- <dd pn="section-4.2-16.6">
+ <dt>TIMESTAMP:</dt>
+ <dd>
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">
+ <dt>ZONE TYPE:</dt>
+ <dd>
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>
+ <dt>ZONE KEY:</dt>
+ <dd>Field as defined in the revocation message above.</dd>
</dl>
- <t indent="0" pn="section-4.2-17">
+ <t>
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
+ <ol>
+ <li>The signature <bcp14>MUST</bcp14> be verified against the zone
key.</li>
+ <li>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>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">
+ <t>
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)
@@ -1151,7 +882,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
revocation <bcp14>MUST</bcp14> be determined by examining the leading
zeroes in the POW values.
</t>
- <t indent="0" pn="section-4.2-20">
+ <t>
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.
@@ -1160,12 +891,12 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
If the current time is after the expiration date, the
revocation is considered stale.
</t>
- <t indent="0" pn="section-4.2-21">
+ <t>
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">
+ <t>
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,
@@ -1176,33 +907,33 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <t>
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"/>).
+ delegation record processing (see <xref
target="delegation_processing"/>).
</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">
+ <section anchor="rrecords">
+ <name>Resource Records</name>
+ <t>
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"/>)
+ no zones can be published in storage (see <xref target="publish"/>)
and name resolution is limited to non-local Start Zones
- (see <xref target="governance" format="default" sectionFormat="of"
derivedContent="Section 7.1"/>).
+ (see <xref target="governance"/>).
</t>
- <t indent="0" pn="section-5-2">
+ <t>
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"/>.
+ <xref target="figure_gnsrecord"/>.
</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">
+ <figure anchor="figure_gnsrecord">
+ <name>The Resource Record Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
@@ -1214,43 +945,43 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
/ /
</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">
+ <dl newline="false">
+ <dt>EXPIRATION:</dt>
+ <dd>
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">
+ <dt>SIZE:</dt>
+ <dd>
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">
+ <dt>FLAGS:</dt>
+ <dd>
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">
+ <dt>TYPE:</dt>
+ <dd>
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
+ records as defined in <xref target="rrecords"/>, a DNS record
+ type as defined in <xref target="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"/>.
+ below 2<sup>16</sup> are reserved for 16-bit DNS resource record
types allocated by IANA <xref target="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"/>.
+ GANA "GNS Record Types" registry <xref target="GANA"/>.
</dd>
- <dt pn="section-5-4.9">DATA:</dt>
- <dd pn="section-5-4.10">
+ <dt>DATA:</dt>
+ <dd>
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">
+ <t>
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
@@ -1260,29 +991,29 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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"/>
+ <xref target="figure_flag"/>
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">
+ <figure anchor="figure_flag">
+ <name>The Resource Record Flag Wire Format</name>
+ <artwork name="" type="" alt="">
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">
+ <dl newline="false">
+ <dt>CRITICAL:</dt>
+ <dd>
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">
+ <dt>SHADOW:</dt>
+ <dd>
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
@@ -1290,21 +1021,21 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <dt>SUPPLEMENTAL:</dt>
+ <dd>
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">
+ <section anchor="gnsrecords_delegation">
+ <name>Zone Delegation Records</name>
+ <t>
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"/>).
+ the GANA "GNS Record Types" registry (see <xref target="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
@@ -1322,7 +1053,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <t>
In the following, "||" is the concatenation operator of two byte
strings.
The algorithm specification uses character strings such as GNS labels or
constant values.
@@ -1330,15 +1061,15 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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">
+ <section anchor="gnsrecords_pkey">
+ <name>PKEY</name>
+ <t>
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"/>.
+ represented through a PKEY record. The PKEY DATA entry wire format
is illustrated in <xref target="figure_pkeyrecord"/>.
</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">
+ <figure anchor="figure_pkeyrecord">
+ <name>The PKEY Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
@@ -1348,67 +1079,67 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>PUBLIC KEY:</dt>
+ <dd>
A 256-bit Ed25519 public key.
</dd>
</dl>
- <t indent="0" pn="section-5.1.1-4">
+ <t>
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"/>.
+ of Curve25519 <xref target="RFC7748"/> (the reasoning behind choosing
+ this curve can be found in <xref target="security_cryptography"/>)
+ with the ECDSA scheme <xref target="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">
+ <dl newline="false">
+ <dt>d:</dt>
+ <dd>
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">
+ <dt>zkey:</dt>
+ <dd>
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.,
+ <dt>p:</dt>
+ <dd>
+ The prime of edwards25519 as defined in <xref target="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">
+ <dt>G:</dt>
+ <dd>
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"/>.
+ <xref target="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"/>.
+ <dt>L:</dt>
+ <dd>
+ The order of the prime-order subgroup of edwards25519 as defined in
<xref target="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
+ <dt>KeyGen():</dt>
+ <dd>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.
+ of the elliptic curve) as defined in <xref target="RFC6979"
sectionFormat="of" section="2.2"/> represents the KeyGen() function.
</dd>
</dl>
- <t indent="0" pn="section-5.1.1-6">
+ <t>
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">
+ <artwork name="" type="" alt="">
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">
+ <t>
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.
+ <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/> for
the extraction
+ phase and SHA-256 <xref target="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.
@@ -1418,13 +1149,13 @@ ZKDF(zkey, label):
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">
+ <t>
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"/>.
+ signatures as specified in <xref target="RFC6979"/>.
The same functions can be used for derived keys:
</t>
- <artwork name="" type="" alt="" align="left" pn="section-5.1.1-10">
+ <artwork name="" type="" alt="">
SignDerived(d, label, message):
zkey := d * G
PRK_h := HKDF-Extract("key-derivation", zkey)
@@ -1432,18 +1163,18 @@ SignDerived(d, label, message):
d' := (h * d) mod L
return Sign(d', message)
</artwork>
- <t indent="0" pn="section-5.1.1-11">
+ <t>
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">
+ <artwork name="" type="" alt="">
VerifyDerived(zkey', message, signature):
return Verify(zkey', message, signature)
</artwork>
- <t indent="0" pn="section-5.1.1-13">
+ <t>
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):
+ as defined in <xref target="MODES"/> (CTR-AES256):
</t>
- <artwork name="" type="" alt="" align="left" pn="section-5.1.1-14">
+ <artwork name="" type="" alt="">
S-Encrypt(zkey, label, expiration, plaintext):
PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
@@ -1462,29 +1193,29 @@ S-Decrypt(zkey, label, expiration, ciphertext):
IV := NONCE || expiration || BLOCK_COUNTER
return CTR-AES256(K, IV, ciphertext)
</artwork>
- <t indent="0" pn="section-5.1.1-15">
+ <t>
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 record label and the zone key zkey, using an HKDF as defined in
<xref target="RFC5869"/>.
+ SHA-512 <xref target="RFC6234"/> is used for the
+ extraction phase and SHA-256 <xref target="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"/>.
+ The symmetric key K is a 256-bit AES key <xref target="RFC3826"/>.
</t>
- <t indent="0" pn="section-5.1.1-16">
+ <t>
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"/>.
+ 32-bit block counter as defined in <xref target="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"/>.
+ <xref target="figure_hkdf_ivs_pkey"/>.
</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
+ <figure anchor="figure_hkdf_ivs_pkey">
+ <name>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">
+ <artwork name="" type="" alt="">
0 8 16 24 32
+-----+-----+-----+-----+
| NONCE |
@@ -1497,17 +1228,17 @@ S-Decrypt(zkey, label, expiration, ciphertext):
</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">
+ <section anchor="gnsrecords_edkey">
+ <name>EDKEY</name>
+ <t>
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"/>.
+ is illustrated in <xref target="figure_edkeyrecord"/>.
</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">
+ <figure anchor="figure_edkeyrecord">
+ <name>The EDKEY DATA Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
@@ -1517,77 +1248,77 @@ S-Decrypt(zkey, label, expiration, ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>PUBLIC KEY:</dt>
+ <dd>
A 256-bit EdDSA zone key.
</dd>
</dl>
- <t indent="0" pn="section-5.1.2-4">
+ <t>
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"/>.
+ of Curve25519 <xref target="RFC7748"/> (a.k.a. Ed25519)
+ with the Ed25519 scheme <xref target="ed25519"/> as specified in
+ <xref target="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">
+ <dl newline="false">
+ <dt>d:</dt>
+ <dd>
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">
+ <dt>a:</dt>
+ <dd>
An integer derived from d using the SHA-512 hash function
- as defined in <xref target="RFC8032" format="default"
sectionFormat="of" derivedContent="RFC8032"/>.
+ as defined in <xref target="RFC8032"/>.
</dd>
- <dt pn="section-5.1.2-5.5">zkey:</dt>
- <dd pn="section-5.1.2-5.6">
+ <dt>zkey:</dt>
+ <dd>
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"/>.
+ as defined in <xref target="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.,
+ <dt>p:</dt>
+ <dd>
+ The prime of edwards25519 as defined in <xref target="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">
+ <dt>G:</dt>
+ <dd>
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"/>.
+ <xref target="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"/>.
+ <dt>L:</dt>
+ <dd>
+ The order of the prime-order subgroup of edwards25519 as defined
in <xref target="RFC8032"/>.
</dd>
- <dt pn="section-5.1.2-5.13">KeyGen():</dt>
- <dd pn="section-5.1.2-5.14">
+ <dt>KeyGen():</dt>
+ <dd>
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"/>
+ in <xref target="RFC8032" sectionFormat="of" section="5.1.5"/>
represents the KeyGen()
function.
</dd>
</dl>
- <t indent="0" pn="section-5.1.2-6">
+ <t>
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"/>.
+ <t>
+ The "EDKEY" ZKDF instantiation is based on <xref target="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"/>.
+ SHA-512 hash function as defined in <xref target="RFC8032"
sectionFormat="of" section="5.1.5"/>.
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">
+ <artwork name="" type="" alt="">
ZKDF(zkey, label):
/* Calculate the blinding factor */
PRK_h := HKDF-Extract("key-derivation", zkey)
@@ -1598,17 +1329,17 @@ ZKDF(zkey, label):
zkey' := h * zkey
return zkey'
</artwork>
- <t indent="0" pn="section-5.1.2-9">
+ <t>
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">
+ <t>
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.
+ <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/>
for the extraction
+ phase and HMAC-SHA-256 <xref target="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.
@@ -1621,16 +1352,16 @@ ZKDF(zkey, label):
key d.
The multiplication of zkey with h is a point multiplication.
</t>
- <t indent="0" pn="section-5.1.2-11">
+ <t>
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"/>.
+ be implemented as defined in <xref target="RFC8032"/>.
</t>
- <t indent="0" pn="section-5.1.2-12">
+ <t>
Signatures for EDKEY zones use a derived private scalar d';
- this is not compliant with <xref target="RFC8032" format="default"
sectionFormat="of" derivedContent="RFC8032"/>.
+ this is not compliant with <xref target="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"/>.
+ signature part R according to <xref target="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
@@ -1640,7 +1371,7 @@ ZKDF(zkey, label):
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">
+ <artwork name="" type="" alt="">
SignDerived(d, label, message):
/* Key expansion */
dh := SHA-512(d)
@@ -1665,21 +1396,21 @@ SignDerived(d, label, message):
S := r + SHA-512(R || zkey' || message) * d' mod L
return (R,S)
</artwork>
- <t indent="0" pn="section-5.1.2-14">
+ <t>
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">
+ <artwork name="" type="" alt="">
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">
+ <t>
The S-Encrypt() and S-Decrypt() functions use XSalsa20
- as defined in <xref target="XSalsa20" format="default"
sectionFormat="of" derivedContent="XSalsa20"/>
+ as defined in <xref target="XSalsa20"/>
and use the XSalsa20-Poly1305 encryption function:
</t>
- <artwork name="" type="" alt="" align="left" pn="section-5.1.2-17">
+ <artwork name="" type="" alt="">
S-Encrypt(zkey, label, expiration, plaintext):
PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
@@ -1696,35 +1427,35 @@ S-Decrypt(zkey, label, expiration, ciphertext):
IV := NONCE || expiration
return XSalsa20-Poly1305(K, IV, ciphertext)
</artwork>
- <t indent="0" pn="section-5.1.2-18">
+ <t>
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">
+ <t>
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.
+ <xref target="RFC5869"/>.
+ SHA-512 <xref target="RFC6234"/> is used for the
+ extraction phase and SHA-256 <xref target="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"/>.
+ <xref target="XSalsa20"/>.
No additional authenticated data (AAD) is used.
</t>
- <t indent="0" pn="section-5.1.2-20">
+ <t>
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"/>.
+ <xref target="figure_hkdf_ivs_edkey"/>.
</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">
+ <figure anchor="figure_hkdf_ivs_edkey">
+ <name>The Counter Block Initialization Vector</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| NONCE |
@@ -1736,13 +1467,13 @@ S-Decrypt(zkey, label, expiration, ciphertext):
</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">
+ <section anchor="gnsrecords_redirect">
+ <name>Redirection Records</name>
+ <t>
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"/>.
+ the GANA "GNS Record Types" registry <xref target="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
@@ -1750,9 +1481,9 @@ S-Decrypt(zkey, label, expiration, ciphertext):
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">
+ <section anchor="gnsrecords_rdr">
+ <name>REDIRECT</name>
+ <t>
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.
@@ -1760,13 +1491,13 @@ S-Decrypt(zkey, label, expiration, ciphertext):
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"/>.
+ Details on the processing of this record are provided in <xref
target="redirect_processing"/>.
- A REDIRECT DATA entry is illustrated in <xref
target="figure_redirectrecord" format="default" sectionFormat="of"
derivedContent="Figure 13"/>.
+ A REDIRECT DATA entry is illustrated in <xref
target="figure_redirectrecord"/>.
</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">
+ <figure anchor="figure_redirectrecord">
+ <name>The REDIRECT DATA Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| REDIRECT NAME |
@@ -1776,9 +1507,9 @@ S-Decrypt(zkey, label, expiration, ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>REDIRECT NAME:</dt>
+ <dd>
The name to continue with.
This value can be a regular name or a relative
name.
@@ -1788,13 +1519,13 @@ S-Decrypt(zkey, label, expiration, ciphertext):
</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">
+ <section anchor="gnsrecords_gns2dns">
+ <name>GNS2DNS</name>
+ <t>
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.
+ <xref target="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.
@@ -1802,10 +1533,10 @@ S-Decrypt(zkey, label, expiration, ciphertext):
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">
+ A GNS2DNS DATA entry is illustrated in <xref
target="figure_gns2dnsrecord"/>.</t>
+ <figure anchor="figure_gns2dnsrecord">
+ <name>The GNS2DNS DATA Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| NAME |
@@ -1820,14 +1551,14 @@ S-Decrypt(zkey, label, expiration, ciphertext):
+-----------------------------------------------+
</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">
+ <dl newline="false">
+ <dt>NAME:</dt>
+ <dd>
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">
+ <dt>DNS SERVER NAME:</dt>
+ <dd>
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
@@ -1839,23 +1570,23 @@ S-Decrypt(zkey, label, expiration, ciphertext):
The value is UTF-8 encoded and zero terminated.
</dd>
</dl>
- <t indent="0" pn="section-5.2.2-4">
+ <t>
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"/>.
+ representation <xref target="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">
+ <section anchor="gnsrecords_other">
+ <name>Auxiliary Records</name>
+ <t>
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"/>.
+ according to <xref target="record_processing"/>.
</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">
+ <section anchor="gnsrecords_leho">
+ <name>LEHO</name>
+ <t>
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.
@@ -1865,21 +1596,21 @@ S-Decrypt(zkey, label, expiration, ciphertext):
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
+ Indication <xref target="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">
+ <t>
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"/>.
+ A LEHO DATA entry is illustrated in <xref
target="figure_lehorecord"/>.
</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">
+ <figure anchor="figure_lehorecord">
+ <name>The LEHO DATA Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME |
@@ -1889,36 +1620,36 @@ S-Decrypt(zkey, label, expiration, ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>LEGACY HOSTNAME:</dt>
+ <dd>
A UTF-8 string (which is not zero terminated) representing the
legacy hostname.
</dd>
</dl>
- <t indent="0" pn="section-5.3.1-5">
+ <t>
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"/>.
+ <xref target="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">
+ <section anchor="gnsrecords_nick">
+ <name>NICK</name>
+ <t>
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
+ delegation record (<xref target="gnsrecords_delegation"/>) 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
+ <xref target="nick_processing"/> 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"/>.
+ A NICK DATA entry is illustrated in <xref
target="figure_nickrecord"/>.
</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">
+ <figure anchor="figure_nickrecord">
+ <name>The NICK DATA Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| NICKNAME |
@@ -1928,24 +1659,24 @@ S-Decrypt(zkey, label, expiration, ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>NICKNAME:</dt>
+ <dd>
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">
+ <section anchor="gnsrecords_box">
+ <name>BOX</name>
+ <t>
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">
+ <t>
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
@@ -1954,12 +1685,12 @@ S-Decrypt(zkey, label, expiration, ciphertext):
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"/>.
+ For reference, see also <xref target="RFC2782"/>.
+ A BOX DATA entry is illustrated in <xref
target="figure_boxrecord"/>.
</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">
+ <figure anchor="figure_boxrecord">
+ <name>The BOX DATA Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
@@ -1971,27 +1702,27 @@ S-Decrypt(zkey, label, expiration, ciphertext):
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>PROTO:</dt>
+ <dd>
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"/>
+ below 2<sup>8</sup> are reserved for 8-bit Internet Protocol
numbers allocated by IANA <xref target="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"/>.
+ GANA "GNUnet Overlay Protocols" registry <xref target="GANA"/>.
</dd>
- <dt pn="section-5.3.3-4.3">SVC:</dt>
- <dd pn="section-5.3.3-4.4">
+ <dt>SVC:</dt>
+ <dd>
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">
+ <dt>TYPE:</dt>
+ <dd>
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">
+ <dt>RECORD DATA:</dt>
+ <dd>
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.
@@ -2000,9 +1731,9 @@ S-Decrypt(zkey, label, expiration, ciphertext):
</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">
+ <section anchor="publish">
+ <name>Record Encoding for Remote Storage</name>
+ <t>
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
@@ -2012,28 +1743,28 @@ S-Decrypt(zkey, label, expiration, ciphertext):
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">
+ <artwork name="" type="" alt="">
PUT(key, block)
GET(key) -> block
</artwork>
- <t indent="0" pn="section-6-3">
+ <t>
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">
+ <t>
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">
+ <t>
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"/>.
+ in <xref target="figure_storage_publish"/>.
A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource
records in blocks.
An implementation <bcp14>MUST</bcp14> use the PUT storage procedure
@@ -2042,9 +1773,9 @@ GET(key) -> block
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">
+ <figure anchor="figure_storage_publish">
+ <name>Management and Publication of Local Zones in Distributed
Storage</name>
+ <artwork name="" type="" alt="">
Local Host | Remote
| Storage
|
@@ -2070,14 +1801,14 @@ GET(key) -> block
+---------+ |
</artwork>
</figure>
- <t indent="0" pn="section-6-7">
+ <t>
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"/>.
+ illustrated in <xref target="figure_storage_derivations"/>.
</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">
+ <figure anchor="figure_storage_derivations">
+ <name>Storage Key and Record Block Creation Overview</name>
+ <artwork name="" type="" alt="">
+----------+ +-------+ +------------+ +-------------+
| Zone Key | | Label | | Record Set | | Private Key |
+----------+ +-------+ +------------+ +-------------+
@@ -2103,53 +1834,53 @@ GET(key) -> block
+------+ +-------------+
</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">
+ <section anchor="blinding">
+ <name>The Storage Key</name>
+ <t>
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"/>).
+ ensures query privacy (see <xref target="RFC8324"
sectionFormat="comma" section="3.5"/>).
</t>
- <t indent="0" pn="section-6.1-2">
+ <t>
Given a label, the storage key q is derived as follows:
</t>
- <artwork name="" type="" alt="" align="left" pn="section-6.1-3">
+ <artwork name="" type="" alt="">
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.
+ <dl newline="false">
+ <dt>label:</dt>
+ <dd>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">
+ <dt>zkey:</dt>
+ <dd>
The zone key.
</dd>
- <dt pn="section-6.1-4.5">q:</dt>
- <dd pn="section-6.1-4.6">
+ <dt>q:</dt>
+ <dd>
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.
+ It is the SHA-512 hash <xref target="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">
+ <section anchor="rdata">
+ <name>Plaintext Record Data (RDATA)</name>
+ <t>
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">
+ <t>
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"/>.
+ <xref target="figure_rdata"/>.
</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">
+ <figure anchor="figure_rdata">
+ <name>The RDATA Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
@@ -2172,14 +1903,14 @@ q := SHA-512(ZKDF(zkey, label))
+-----+-----+-----+-----+-----+-----+-----+-----+
</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"/>.
+ <dl newline="false">
+ <dt>EXPIRATION, SIZE, TYPE, FLAGS, and DATA:</dt>
+ <dd>
+ Definitions for these fields are provided below <xref
target="figure_gnsrecord"/>
+ in <xref target="rrecords"/>.
</dd>
- <dt pn="section-6.2-4.3">PADDING:</dt>
- <dd pn="section-6.2-4.4">
+ <dt>PADDING:</dt>
+ <dd>
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
@@ -2189,18 +1920,18 @@ q := SHA-512(ZKDF(zkey, label))
</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">
+ <section anchor="records_block">
+ <name>The Resource Record Block</name>
+ <t>
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"/>.
+ <xref target="figure_record_block"/>.
</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">
+ <figure anchor="figure_record_block">
+ <name>The RRBLOCK Wire Format</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | ZONE TYPE |
@@ -2222,59 +1953,59 @@ q := SHA-512(ZKDF(zkey, label))
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>SIZE:</dt>
+ <dd>
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">
+ <dt>ZONE TYPE:</dt>
+ <dd>
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">
+ <dt>ZONE KEY (BLINDED):</dt>
+ <dd>
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">
+ <dt>SIGNATURE:</dt>
+ <dd>
The signature is computed over the EXPIRATION and BDATA fields
- as shown in <xref target="figure_rrsigwithpseudo" format="default"
sectionFormat="of" derivedContent="Figure 22"/>.
+ as shown in <xref target="figure_rrsigwithpseudo"/>.
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"/>).
+ the cryptosystem of the zone (see <xref target="zones"/>).
</dd>
- <dt pn="section-6.3-3.9">EXPIRATION:</dt>
- <dd pn="section-6.3-3.10">
+ <dt>EXPIRATION:</dt>
+ <dd>
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"/>).
+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"/>).
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">
+ <dt>BDATA:</dt>
+ <dd>
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">
+ <t>
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"/>.
+ in <xref target="figure_rrsigwithpseudo"/>.
</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">
+ <figure anchor="figure_rrsigwithpseudo">
+ <name>The Wire Format Used for Creating the Signature of the
RRBLOCK</name>
+ <artwork name="" type="" alt="">
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x0F) |
@@ -2287,40 +2018,40 @@ records. Then, the minimum of all of these expiration
times is taken. The final
+-----+-----+-----+-----+-----+-----+-----+-----+
</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">
+ <dl newline="false">
+ <dt>SIZE:</dt>
+ <dd>
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">
+ <dt>PURPOSE:</dt>
+ <dd>
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"/>.
+ GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>.
</dd>
- <dt pn="section-6.3-6.5">EXPIRATION:</dt>
- <dd pn="section-6.3-6.6">
+ <dt>EXPIRATION:</dt>
+ <dd>
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>
+ <dt>BDATA:</dt>
+ <dd>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">
+ <section anchor="resolution">
+ <name>Name Resolution</name>
+ <t>
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
+ <xref target="figure_resolution"/> 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
@@ -2336,9 +2067,9 @@ records. Then, the minimum of all of these expiration
times is taken. The final
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">
+ <figure anchor="figure_resolution">
+ <name>The Recursive GNS Resolution Process</name>
+ <artwork name="" type="" alt="">
Local Host | Remote
| Storage
|
@@ -2365,44 +2096,46 @@ records. Then, the minimum of all of these expiration
times is taken. The final
+---------+ |
</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">
+ <section anchor="governance">
+ <name>Start Zones</name>
+ <t>
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"/>).
+ of the remainder of the name is initiated (see <xref
target="recursion"/>).
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).
+ management of root servers in DNS (see Sections <xref
target="RFC8324" section="3.12"
+ sectionFormat="bare"/> and <xref target="RFC8324" section="3.10"
+ sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively).
</t>
- <t indent="0" pn="section-7.1-2">
+ <t>
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"/>).
+ the given name as the beginning of a zTLD (see <xref target="zTLD"/>).
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"/>.
+ the Start Zone key according to <xref target="zTLD"/>.
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">
+ <artwork name="" type="" alt="">
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">
+ <t>
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
@@ -2415,7 +2148,7 @@ Example name: www.example.<zTLD>
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">
+ <artwork name="" type="" alt="">
Example name: www.example.xyz.gns.alt
Local suffix mappings:
xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0)
@@ -2425,48 +2158,48 @@ 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">
+ <t>
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">
+ <section anchor="recursion">
+ <name>Recursion</name>
+ <t>
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">
+ <t>
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
+ <ol>
+ <li>Extract the rightmost label from the name to look up.</li>
+ <li>Calculate q using the label and zkey as defined in
+ <xref target="blinding"/>.</li>
+ <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li>
+ <li>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
+ <li>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>
+ inverting the process described in <xref
target="records_block"/>.</li>
</ol>
- <t indent="0" pn="section-7.2-4">
+ <t>
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">
+ <section anchor="record_processing">
+ <name>Record Processing</name>
+ <t>
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
@@ -2481,42 +2214,43 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <t>
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,
+ <dl newline="false">
+ <dt>Case 1:</dt>
+ <dd>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,
+ Details are provided in <xref target="redirect_processing"/>.</dd>
+ <dt>Case 2:</dt>
+ <dd>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
+ Details are provided in <xref target="gns2dns_processing"/>.</dd>
+ <dt>Case 3:</dt>
+ <dd>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
+ is concluded as described in <xref target="box_processing"/>.</dd>
+ <dt>Case 4:</dt>
+ <dd>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 target zone as described in <xref
target="delegation_processing"/>.</dd>
+ <dt>Case 5:</dt>
+ <dd>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"/>.
+ first be processed according to <xref target="nick_processing"/>.
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
+ </dl>
+ <t>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">
+
+ <section anchor="redirect_processing">
+ <name>REDIRECT</name>
+ <t>
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
@@ -2528,9 +2262,9 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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"/>.
+ converted to an IDNA-compliant representation <xref
target="RFC5890"/>.
</t>
- <t indent="0" pn="section-7.3.1-2">
+ <t>
In order to prevent infinite loops, the resolver
<bcp14>MUST</bcp14>
implement loop detection or limit the number of recursive
resolution steps.
@@ -2539,22 +2273,22 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <section anchor="gns2dns_processing">
+ <name>GNS2DNS</name>
+ <t>
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">
+ <ol>
+ <li>The resolver encounters one or more GNS2DNS records;</li>
+ <li>The remaining name is empty; and</li>
+ <li>The desired record type is GNS2DNS.</li>
+ </ol>
+ <t>
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.
+ representation <xref target="RFC5890"/> for resolution in DNS.
GNS2DNS records <bcp14>MAY</bcp14>
contain numeric IPv4 or IPv6 addresses, allowing the resolver to
skip this step.
@@ -2566,7 +2300,7 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <t>
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.
@@ -2576,26 +2310,26 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <t>
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">
+ <t>
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.
+ representation <xref target="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">
+ <t>
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
@@ -2603,10 +2337,10 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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
+ supplemental LEHO record (see <xref target="gnsrecords_leho"/>)
with a
relative expiration time of one hour.
</t>
- <t indent="0" pn="section-7.3.2-8">
+ <t>
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>
@@ -2614,7 +2348,7 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <t>
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.
@@ -2626,9 +2360,9 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <section anchor="box_processing">
+ <name>BOX</name>
+ <t>
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
@@ -2637,23 +2371,23 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <section anchor="delegation_processing">
+ <name>Zone Delegation Records</name>
+ <t>
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">
+ <t>
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
+ check against the local revocation list (see <xref
target="revocation"/>) 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">
+ <t>
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.
@@ -2663,7 +2397,7 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <t>
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
@@ -2672,13 +2406,13 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <section anchor="nick_processing">
+ <name>NICK</name>
+ <t>
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
+ supplemental (see <xref target="rrecords"/>) 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
@@ -2686,18 +2420,18 @@ example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
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">
+ <t>
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">
+ <artwork name="" type="" alt="">
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">
+ <t>
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
@@ -2705,13 +2439,13 @@ NICK: eve (non-supplemental)
"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">
+ <artwork name="" type="" alt="">
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">
+ <t>
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
@@ -2722,29 +2456,29 @@ NICK: john (supplemental)
</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"/>.
+ <section anchor="encoding">
+ <name>Internationalization and Character Encoding</name>
+ <t>
+ All names in GNS are encoded in UTF-8 <xref target="RFC3629"/>.
Labels <bcp14>MUST</bcp14> be canonicalized using
- Normalization Form C (NFC) <xref target="Unicode-UAX15"
format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.
+ Normalization Form C (NFC) <xref target="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"/>.
+ see <xref target="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">
+ <section anchor="security">
+ <name>Security and Privacy Considerations</name>
+ <section anchor="security_availability">
+ <name>Availability</name>
+ <t>
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">
+ <t>
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
@@ -2752,9 +2486,9 @@ NICK: john (supplemental)
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">
+ <section anchor="security_agility">
+ <name>Agility</name>
+ <t>
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
@@ -2767,7 +2501,7 @@ NICK: john (supplemental)
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">
+ <t>
This document concerns itself with the selection of cryptographic
algorithms used in GNS.
The algorithms identified in this document are not known to be
@@ -2778,7 +2512,7 @@ NICK: john (supplemental)
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">
+ <t>
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
@@ -2793,20 +2527,20 @@ NICK: john (supplemental)
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">
+ <section anchor="security_cryptography">
+ <name>Cryptography</name>
+ <t>
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
+ When specifying new ztypes as per <xref target="zones"/>, the same
considerations apply.
</t>
- <t indent="0" pn="section-9.3-2">
+ <t>
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"/>.
+ the Curve25519 and EdDSA papers <xref target="RFC7748"/> <xref
target="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.
@@ -2815,7 +2549,7 @@ NICK: john (supplemental)
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">
+ <t>
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
@@ -2847,9 +2581,9 @@ NICK: john (supplemental)
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">
+ <section anchor="security_abuse">
+ <name>Abuse Mitigation</name>
+ <t>
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.
@@ -2858,7 +2592,7 @@ NICK: john (supplemental)
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">
+ <t>
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
@@ -2869,9 +2603,9 @@ NICK: john (supplemental)
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">
+ <section anchor="security_keymanagement">
+ <name>Zone Management</name>
+ <t>
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.
@@ -2883,7 +2617,7 @@ NICK: john (supplemental)
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">
+ <t>
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
@@ -2896,7 +2630,7 @@ NICK: john (supplemental)
Extension and customization of the zone are at the full discretion
of
the user.
</t>
- <t indent="0" pn="section-9.5-3">
+ <t>
While implementations following this specification will be
interoperable, if two implementations connect to different remote
storage entities,
they are mutually unreachable.
@@ -2908,14 +2642,14 @@ NICK: john (supplemental)
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.
+ within the Tor network <xref target="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">
+ <section anchor="security_dht">
+ <name>DHTs as Remote Storage</name>
+ <t>
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
@@ -2925,15 +2659,15 @@ NICK: john (supplemental)
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"/>.
+ <xref target="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">
+ <section anchor="security_rev">
+ <name>Revocations</name>
+ <t>
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.
@@ -2942,12 +2676,12 @@ NICK: john (supplemental)
Consequently, implementers and users must take precautions in order
to manage revocations accordingly.
</t>
- <t indent="0" pn="section-9.7-2">
+ <t>
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.">
+ <ol>
+ <li>
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
@@ -2956,7 +2690,7 @@ NICK: john (supplemental)
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.">
+ <li>
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
@@ -2969,9 +2703,9 @@ NICK: john (supplemental)
</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">
+ <section anchor="privacy_labels">
+ <name>Zone Privacy</name>
+ <t>
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
@@ -2983,22 +2717,22 @@ NICK: john (supplemental)
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">
+ <t>
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">
+ <t>
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">
+ <section anchor="sec_governance">
+ <name>Zone Governance</name>
+ <t>
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
@@ -3007,9 +2741,9 @@ NICK: john (supplemental)
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"/>.
+ works, including <xref target="SecureNS"/>.
</t>
- <t indent="0" pn="section-9.9-2">
+ <t>
GNS is designed to provide a secure, privacy-enhancing alternative
to the
DNS name resolution protocol, especially when censorship or
manipulation
is encountered.
@@ -3019,12 +2753,14 @@ NICK: john (supplemental)
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.
+ raised in Sections <xref target="RFC8324" section="3.12"
+ sectionFormat="bare"/> and <xref target="RFC8324" section="3.10"
+ sectionFormat="bare"/> of <xref target="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">
+ <t>
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
@@ -3035,35 +2771,35 @@ NICK: john (supplemental)
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">
+ <t>
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">
+ <section anchor="namespace_ambiguity">
+ <name>Namespace Ambiguity</name>
+ <t>
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">
+ <t>
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
+ respective common display format <xref target="RFC8499"/> or
+ other special-use domain names <xref target="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"/>.
+ it is actually a GNS name, as discussed in <xref target="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">
+ <t>
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
@@ -3079,14 +2815,14 @@ NICK: john (supplemental)
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">
+ <t>
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">
+ <t>
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.
@@ -3097,72 +2833,68 @@ NICK: john (supplemental)
</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
+ <section anchor="gana">
+ <name>GANA Considerations</name>
+ <section anchor="gana_gnunet-sig-purposes">
+ <name>GNUnet Signature Purposes Registry</name>
+ <t>
+ GANA <xref target="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>
+ <xref target="tab_purposenums"/>.
+ </t>
+
+<table anchor="tab_purposenums">
+ <name>The GANA GNUnet Signature Purposes Registry</name>
+ <thead>
+ <tr>
+ <th>Purpose</th>
+ <th>Name</th>
+ <th>References</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>3</td>
+ <td>GNS_REVOCATION</td>
+ <td>RFC 9498</td>
+ <td>GNS zone key revocation</td>
+ </tr>
+ <tr>
+ <td>15</td>
+ <td>GNS_RECORD_SIGN</td>
+ <td>RFC 9498</td>
+ <td>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"/>
+ <section anchor="gana_gnsrr">
+ <name>GNS Record Types Registry</name>
+ <t>
+ GANA <xref target="GANA"/>
manages the "GNS Record Types" registry.
+ </t>
+ <t>Each entry has the following format:
</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
+ <dl newline="false">
+ <dt>Name:</dt><dd>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
+ <dt>Number:</dt><dd>A 32-bit number above 65535.</dd>
+ <dt>Comment:</dt><dd>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
+ <dt>Contact:</dt><dd>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">
+ <dt>References:</dt><dd>Optionally, references (such as an RFC)
describing the record type.</dd>
+ </dl>
+ <t>
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"/>
+ Served". This policy is modeled on that described in <xref
target="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">
+ <ul>
+ <li>
Adding new entries is possible after review by any authorized
GANA contributor, using a
first-come-first-served policy for unique name allocation.
@@ -3170,850 +2902,505 @@ NICK: john (supplemental)
appropriate for the record type.
The registry will define a unique number for the entry.
</li>
- <li pn="section-10.2-5.2">
+ <li>
Authorized GANA contributors for review of new entries are reachable
at
<gns-registry@gnunet.org>.
</li>
- <li pn="section-10.2-5.3">
+ <li>
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">
+ </ul>
+ <t>
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"/>.
+ <xref target="tab_rrtypenums"/>.
</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>
+
+<table anchor="tab_rrtypenums">
+ <name>The GANA GNS Record Types Registry</name>
+ <thead>
+ <tr>
+ <th>Number</th>
+ <th>Name</th>
+ <th>Contact</th>
+ <th>References</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>65536</td>
+ <td>PKEY</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone delegation (PKEY)</td>
+ </tr>
+ <tr>
+ <td>65537</td>
+ <td>NICK</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone nickname</td>
+ </tr>
+ <tr>
+ <td>65538</td>
+ <td>LEHO</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS legacy hostname</td>
+ </tr>
+ <tr>
+ <td>65540</td>
+ <td>GNS2DNS</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Delegation to DNS</td>
+ </tr>
+ <tr>
+ <td>65541</td>
+ <td>BOX</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Box records</td>
+ </tr>
+ <tr>
+ <td>65551</td>
+ <td>REDIRECT</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Redirection record</td>
+ </tr>
+ <tr>
+ <td>65556</td>
+ <td>EDKEY</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone delegation (EDKEY)</td>
+ </tr>
+ </tbody>
+ <tfoot>
+ <tr>
+ <td align="left" colspan="5">(*): 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"/>
+ <section anchor="gana_alt">
+ <name>.alt Subdomains Registry</name>
+ <t>
+ GANA <xref target="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>Each entry has the following format:
</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
+ <dl newline="false">
+ <dt>Label:</dt><dd>The label of the subdomain (in DNS "letters,
digits, hyphen" (LDH) format as defined in <xref target="RFC5890"
sectionFormat="of" section="2.3.1"/>).</dd>
+ <dt>Description:</dt><dd>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
+ <dt>Contact:</dt><dd>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">
+ <dt>References:</dt><dd>Optionally, references (such as an RFC)
describing the record type.</dd>
+ </dl>
+ <t>
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"/>
+ Served". This policy is modeled on that described in <xref
target="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">
+ <ul>
+ <li>
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">
+ <li>
Authorized GANA contributors for review of new entries are reachable
at
<alt-registry@gnunet.org>.
</li>
- <li pn="section-10.3-5.3">
+ <li>
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">
+ </ul>
+ <t>
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"/>.
+ as listed in <xref target="tab_altsubdomains"/>.
</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>
+<table anchor="tab_altsubdomains">
+ <name>The GANA .alt Subdomains Registry</name>
+ <thead>
+ <tr>
+ <th>Label</th>
+ <th>Contact</th>
+ <th>References</th>
+ <th>Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>gns</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>The .alt subdomain for GNS</td>
+ </tr>
+ </tbody>
+ <tfoot>
+ <tr>
+ <td align="left" colspan="4">(*): 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">
+ <section>
+ <name>IANA Considerations</name>
+ <t>
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">
+ <section>
+ <name>Implementation and Deployment Status</name>
+ <t>
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
+ <xref target="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
+ <xref target="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
+ <t>
+ Currently, the GNUnet peer-to-peer network <xref target="GNUnet"/>
+ is an active deployment of GNS on top of its DHT <xref
target="R5N"/>. The Go implementation <xref target="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"/>
+ <t>
+ The self-sovereign identity system re:claimID <xref target="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
+ <t>
+ The Ascension tool <xref target="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">
+ <references>
+ <name>References</name>
+ <references>
+ <name>Normative References</name>
+
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml"/>
+
+ <reference anchor="GANA" target="https://gana.gnunet.org/";>
+ <front>
+ <title>GNUnet Assigned Numbers Authority (GANA)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="MODES"
target="https://doi.org/10.6028/NIST.SP.800-38A";>
+ <front>
+ <title>Recommendation for Block Cipher Modes of Operation: Methods
and Techniques</title>
+ <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
+ <organization>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";>
+ <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";>
+ <front>
+ <title>Extending the Salsa20 nonce</title>
+ <author initials="D. J." surname="Bernstein" fullname="Daniel
Bernstein">
+ <organization>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";>
+ <front>
+ <title>Unicode Standard Annex #15: Unicode Normalization
Forms</title>
+ <author initials="M." surname="Davis" fullname="Mark Davis">
+ <organization/>
+ </author>
+ <author initials="K." surname="Whistler" fullname="Ken Whistler">
+ <organization/>
</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 initials="M." surname="Dürst" fullname="Martin Dürst">
+ <organization/>
</author>
- <author initials="G." surname="Kadianakis" fullname="George
Kadianakis">
+ <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";>
+ <front>
+ <title>Unicode Technical Standard #46: Unicode IDNA Compatibility
Processing</title>
+ <author initials="M." surname="Davis" fullname="Mark Davis">
+ <organization/>
+ </author>
+ <author initials="M." surname="Suignard" fullname="Michel Suignard">
+ <organization/>
</author>
- <author initials="N." surname="Mathewson" fullname="Nick
Mathewson">
+ <date year="2023" month="September"/>
+ </front>
+ <refcontent>Revision 31, The Unicode Consortium, Mountain
View</refcontent>
+ </reference>
+ </references>
+ <references>
+ <name>Informative References</name>
+
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7363.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8324.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml"/>
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8244.xml"/>
+
+<!-- draft-ietf-dnsop-alt-tld (RFC 9476; published) -->
+<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9476.xml"/>
+
+ <reference anchor="TorRendSpec"
target="https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt";>
+ <front>
+ <title>Tor Rendezvous Specification - Version 3</title>
+ <author>
+ <organization>Tor Project</organization>
</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">
+ <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";>
+ <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";>
+ <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 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">
+ <date year="1996" month="October"/>
+ </front>
+ </reference>
+
+ <reference anchor="Kademlia"
target="https://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf";>
+ <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 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">
+ <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";>
+ <front>
+ <title>High-speed high-security signatures</title>
+ <author initials="D. J." surname="Bernstein" fullname="Daniel
Bernstein">
+ <organization>University of Illinois at Chicago</organization>
+ </author>
+ <author initials="N." surname="Duif" fullname="Niels Duif">
+ <organization>Technische Universiteit Eindhoven</organization>
+ </author>
+ <author initials="T." surname="Lange" fullname="Tanja Lange">
+ <organization>Technische Universiteit Eindhoven</organization>
+ </author>
+ <author initials="P." surname="Schwabe" fullname="Peter Schwabe">
+ <organization>National Taiwan University</organization>
+ </author>
+ <author initials="B-Y." surname="Yang" fullname="Bo-Yin Yang">
+ <organization>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";>
+ <front>
+ <title>A Censorship-Resistant, Privacy-Enhancing and Fully
Decentralized Name System</title>
+ <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="M." surname="Schanzenbach" fullname="Martin
Schanzenbach">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <organization>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";>
+ <front>
+ <title>R5N: Randomized Recursive Routing for Restricted-Route
Networks</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <organization>Technische Universität München</organization>
</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">
+ <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";>
+ <front>
+ <title>Toward secure name resolution on the Internet</title>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <organization>Bern University of Applied Sciences</organization>
+ </author>
+ <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+ <organization>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>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";>
+ <front>
+ <title>gnunet.git - GNUnet core repository</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
</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>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="Ascension"
target="https://git.gnunet.org/ascension.git";>
+ <front>
+ <title>ascension.git - DNS zones to GNS migrating using incremental
zone
+transfer (AXFR/IXFR)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="GNUnet" target="https://gnunet.org";>
+ <front>
+ <title>The GNUnet Project (Home Page)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="reclaim" target="https://reclaim.gnunet.org";>
+ <front>
+ <title>re:claimID - Self-sovereign, Decentralised Identity
Management and Personal Data Sharing</title>
+ <author>
+ <organization>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";>
+ <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";>
+ <front>
+ <title>System Databases and Name Service Switch (Section 29)</title>
+ <author>
+ <organization>GNU Project</organization>
+ </author>
+ </front>
+ </reference>
</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">
+ </references>
+ <section>
+ <name>Usage and Migration</name>
+ <t>
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
@@ -4023,22 +3410,22 @@ NICK: john (supplemental)
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">
+ <section anchor="day_in_zoneowner">
+ <name>Zone Dissemination</name>
+ <t>
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"/>.
+ as defined in <xref target="publish"/>.
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">
+ <t>
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.
@@ -4048,7 +3435,7 @@ NICK: john (supplemental)
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">
+ <t>
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
@@ -4060,7 +3447,7 @@ NICK: john (supplemental)
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">
+ <t>
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,
@@ -4069,12 +3456,12 @@ NICK: john (supplemental)
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.
+ <xref target="security"/> 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">
+ <section>
+ <name>Start Zone Configuration</name>
+ <t>
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.
@@ -4086,8 +3473,8 @@ NICK: john (supplemental)
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">
+ <ul>
+ <li>
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
@@ -4098,7 +3485,7 @@ NICK: john (supplemental)
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"/>:
+ <xref target="day_in_zoneowner"/>:
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
@@ -4113,21 +3500,21 @@ NICK: john (supplemental)
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">
+ <li>
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"/>.
+ from <xref target="security"/>.
Formalizing such best practices is out of scope for this
specification.
</li>
- </ul>
+ </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">
+ <section anchor="uc_virthost">
+ <name>Globally Unique Names and the Web</name>
+ <t>
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
@@ -4136,7 +3523,7 @@ NICK: john (supplemental)
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">
+ <t>
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.
@@ -4148,45 +3535,45 @@ NICK: john (supplemental)
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"/>)
+ <t>
+ If there is a LEHO record (<xref target="gnsrecords_leho"/>)
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">
+ <sourcecode name="" type="http-message"><![CDATA[
GET / HTTP/1.1
Host: www.example.com
-</sourcecode>
- <t indent="0" pn="section-appendix.a.3-5">
+]]></sourcecode>
+ <t>
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">
+ </t>
+ <t>
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">
+ <sourcecode name="" type="http-message"><![CDATA[
GET / HTTP/1.1
Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
-</sourcecode>
- <t indent="0" pn="section-appendix.a.3-8">
+]]></sourcecode>
+ <t>
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">
+ <sourcecode name="" type="http-message"><![CDATA[
GET / HTTP/1.1
Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
-</sourcecode>
- <t indent="0" pn="section-appendix.a.3-10">
+]]></sourcecode>
+ <t>
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"/>.
+the exception mentioned in the last sentence of <xref
target="delegation_processing"/>.
</t>
- <t indent="0" pn="section-appendix.a.3-11">
+ <t>
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.
@@ -4194,15 +3581,15 @@ the exception mentioned in the last sentence of <xref
target="delegation_process
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">
+ <section>
+ <name>Migration Paths</name>
+ <t>
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">
+ <t>
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
@@ -4215,27 +3602,27 @@ the exception mentioned in the last sentence of <xref
target="delegation_process
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"/>.
+ <xref target="GNUnet"/>.
</t>
- <t indent="0" pn="section-appendix.a.4-3">
+ <t>
A similar approach is to use operating system extensions such as
- the NSS <xref target="nsswitch" format="default"
sectionFormat="of" derivedContent="nsswitch"/>.
+ the NSS <xref target="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"/>.
+ can be found in <xref target="GNUnet"/>.
</t>
- <t indent="0" pn="section-appendix.a.4-4">
+ <t>
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 play (<xref target="uc_virthost"/>).
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"/>
+ purposes, a local GNS-aware SOCKS5 proxy <xref target="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.
@@ -4248,17 +3635,17 @@ the exception mentioned in the last sentence of <xref
target="delegation_process
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"/>.
+ <xref target="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">
+ <section>
+ <name>Example Flows</name>
+ <section>
+ <name>AAAA Example Resolution</name>
+ <figure anchor="figure_resolution_ex_aaaa">
+ <name>Example Resolution of an IPv6 Address</name>
+ <artwork name="" type="" alt="">
Local Host | Remote
| Storage
|
@@ -4285,22 +3672,22 @@ the exception mentioned in the last sentence of <xref
target="delegation_process
+---------+ |
</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>
+ <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
+ <li>Determine Start Zone for "www.example.gnu.gns.alt".</li>
+ <li>Start Zone: zkey0 - Remainder: "www.example".</li>
+ <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate
GET(q0).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record
containing zkey1.</li>
+ <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate
GET(q1).</li>
+ <li>Retrieve RRBLOCK consisting of a single AAAA record containing
the IPv6 address 2001:db8::1.</li>
+ <li>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">
+ <section>
+ <name>REDIRECT Example Resolution</name>
+ <figure anchor="figure_resolution_ex_redir">
+ <name>Example Resolution of an IPv6 Address with Redirect</name>
+ <artwork name="" type="" alt="">
Local Host | Remote
| Storage
|
@@ -4327,24 +3714,24 @@ the exception mentioned in the last sentence of <xref
target="delegation_process
+---------+ |
</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>
+ <li>Look up AAAA record for name: "www.example.tld.gns.alt".</li>
+ <li>Determine Start Zone for "www.example.tld.gns.alt".</li>
+ <li>Start Zone: zkey0 - Remainder: "www.example".</li>
+ <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate
GET(q0).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record
containing zkey1.</li>
+ <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate
GET(q1).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single REDIRECT
record containing "www2.+".</li>
+ <li>Calculate q2=SHA512(ZKDF(zkey1, "www2")) and initiate
GET(q2).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single AAAA record
containing the IPv6 address 2001:db8::1.</li>
+ <li>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">
+ <section>
+ <name>GNS2DNS Example Resolution</name>
+ <figure anchor="figure_resolution_ex_gnsdns">
+ <name>Example Resolution of an IPv6 Address with DNS Handover</name>
+ <artwork name="" type="" alt="">
Local Host | Remote
| Storage
|
@@ -4371,27 +3758,27 @@ the exception mentioned in the last sentence of <xref
target="delegation_process
+---------+ |
</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>
+ <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
+ <li>Determine Start Zone for "www.example.gnu.gns.alt".</li>
+ <li>Start Zone: zkey0 - Remainder: "www.example".</li>
+ <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate
GET(q0).</li>
+ <li>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>Use system resolver to look up a AAAA record for the DNS name
"www.example.com".</li>
+ <li>Retrieve a DNS reply consisting of a single AAAA record
containing the IPv6 address 2001:db8::1.</li>
+ <li>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">
+ <section anchor="app-c">
+ <name>Base32GNS</name>
+ <t>
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
+ <t>
+ <xref target="CrockfordB32Encode"/> 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:
@@ -4403,192 +3790,193 @@ the exception mentioned in the last sentence of <xref
target="delegation_process
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>
+<table anchor="CrockfordB32Encode">
+ <name>The Base32GNS Alphabet, Including the Additional Encoding Symbol
"U"</name>
+ <thead>
+ <tr>
+ <th>Symbol Value</th>
+ <th>Decoding Symbol</th>
+ <th>Encoding Symbol</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>0</td>
+ <td>0 O o</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1 I i L l</td>
+ <td>1</td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>2</td>
+ <td>2</td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td>3</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>4</td>
+ <td>4</td>
+ </tr>
+ <tr>
+ <td>5</td>
+ <td>5</td>
+ <td>5</td>
+ </tr>
+ <tr>
+ <td>6</td>
+ <td>6</td>
+ <td>6</td>
+ </tr>
+ <tr>
+ <td>7</td>
+ <td>7</td>
+ <td>7</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>8</td>
+ <td>8</td>
+ </tr>
+ <tr>
+ <td>9</td>
+ <td>9</td>
+ <td>9</td>
+ </tr>
+ <tr>
+ <td>10</td>
+ <td>A a</td>
+ <td>A</td>
+ </tr>
+ <tr>
+ <td>11</td>
+ <td>B b</td>
+ <td>B</td>
+ </tr>
+ <tr>
+ <td>12</td>
+ <td>C c</td>
+ <td>C</td>
+ </tr>
+ <tr>
+ <td>13</td>
+ <td>D d</td>
+ <td>D</td>
+ </tr>
+ <tr>
+ <td>14</td>
+ <td>E e</td>
+ <td>E</td>
+ </tr>
+ <tr>
+ <td>15</td>
+ <td>F f</td>
+ <td>F</td>
+ </tr>
+ <tr>
+ <td>16</td>
+ <td>G g</td>
+ <td>G</td>
+ </tr>
+ <tr>
+ <td>17</td>
+ <td>H h</td>
+ <td>H</td>
+ </tr>
+ <tr>
+ <td>18</td>
+ <td>J j</td>
+ <td>J</td>
+ </tr>
+ <tr>
+ <td>19</td>
+ <td>K k</td>
+ <td>K</td>
+ </tr>
+ <tr>
+ <td>20</td>
+ <td>M m</td>
+ <td>M</td>
+ </tr>
+ <tr>
+ <td>21</td>
+ <td>N n</td>
+ <td>N</td>
+ </tr>
+ <tr>
+ <td>22</td>
+ <td>P p</td>
+ <td>P</td>
+ </tr>
+ <tr>
+ <td>23</td>
+ <td>Q q</td>
+ <td>Q</td>
+ </tr>
+ <tr>
+ <td>24</td>
+ <td>R r</td>
+ <td>R</td>
+ </tr>
+ <tr>
+ <td>25</td>
+ <td>S s</td>
+ <td>S</td>
+ </tr>
+ <tr>
+ <td>26</td>
+ <td>T t</td>
+ <td>T</td>
+ </tr>
+ <tr>
+ <td>27</td>
+ <td>V v U u</td>
+ <td>V</td>
+ </tr>
+ <tr>
+ <td>28</td>
+ <td>W w</td>
+ <td>W</td>
+ </tr>
+ <tr>
+ <td>29</td>
+ <td>X x</td>
+ <td>X</td>
+ </tr>
+ <tr>
+ <td>30</td>
+ <td>Y y</td>
+ <td>Y</td>
+ </tr>
+ <tr>
+ <td>31</td>
+ <td>Z z</td>
+ <td>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">
+ <section>
+ <name>Test Vectors</name>
+ <t>
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">
+ <section>
+ <name>Base32GNS Encoding/Decoding</name>
+ <t>
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">
+<sourcecode name="" type="test-vectors"><![CDATA[
Base32GNS-Encode:
Input string: "Hello World"
Output string: "91JPRV3F41BPYWKCCG"
@@ -4602,18 +3990,19 @@ Base32GNS-Decode:
Input string: "91JPRU3F41BPYWKCCG"
Output string: "Hello World"
-</sourcecode>
+]]></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">
+ <section>
+ <name>Record Sets</name>
+ <t>
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">
+ <t><strong>(1) PKEY zone with ASCII label and one delegation
record</strong></t>
+ <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d, big-endian):
50 d7 b6 52 a4 ef ea df
f3 73 96 90 97 85 e5 95
@@ -4725,9 +4114,9 @@ RRBLOCK:
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">
+]]></sourcecode>
+ <t><strong>(2) PKEY zone with UTF-8 label and three
records</strong></t>
+ <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d, big-endian):
50 d7 b6 52 a4 ef ea df
f3 73 96 90 97 85 e5 95
@@ -4901,10 +4290,10 @@ RRBLOCK:
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">
+ b1 55 dc 6d 13 26 91 74
+]]></sourcecode>
+ <t><strong>(3) EDKEY zone with ASCII label and one delegation
record</strong></t>
+ <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d):
5a f7 02 0e e1 91 60 32
88 32 35 2b bc 6a 68 a8
@@ -5027,9 +4416,9 @@ RRBLOCK:
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">
+]]></sourcecode>
+ <t><strong>(4) EDKEY zone with UTF-8 label and three
records</strong></t>
+ <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d):
5a f7 02 0e e1 91 60 32
88 32 35 2b bc 6a 68 a8
@@ -5215,14 +4604,14 @@ RRBLOCK:
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>
+]]></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">
+ <section>
+ <name>Zone Revocation</name>
+ <t>
The following is an example revocation for a PKEY zone:
</t>
- <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.3-2">
+ <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d, big-endian):
6f ea 32 c0 5a f5 8b fa
97 95 53 d1 88 60 5f d5
@@ -5298,11 +4687,11 @@ Proof:
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">
+]]></sourcecode>
+ <t>
The following is an example revocation for an EDKEY zone:
</t>
- <sourcecode name="" type="test-vectors" markers="false"
pn="section-appendix.d.3-4">
+ <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d):
5a f7 02 0e e1 91 60 32
88 32 35 2b bc 6a 68 a8
@@ -5378,57 +4767,18 @@ Proof:
5c a8 cb 4d d0 f8 4c 3b
77 48 7a ac 6e ce 38 48
0b a9 d5 00
-</sourcecode>
+]]></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">
+ <section numbered="false">
+ <name>Acknowledgements</name>
+ <t>
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>
+ </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: update with actual rfc source,
gnunet <=