path: root/draft-schanzen-gns.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml">
<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">
<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
<!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC5891 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
<!ENTITY RFC6781 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml">
<!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
<!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
<!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
<!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
 <!-- xml2rfc v2v3 conversion 2.26.0 -->
 <front>
  <title abbrev="The GNU Name System">
   The GNU Name System
  </title>
  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-01"/>
  <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
   <organization>GNUnet e.V.</organization>
   <address>
    <postal>
     <street>Boltzmannstrasse 3</street>
     <city>Garching</city>
     <code>85748</code>
     <country>DE</country>
    </postal>
    <email>schanzen@gnunet.org</email>
   </address>
  </author>
  <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
   <organization>Berner Fachhochschule</organization>
   <address>
    <postal>
     <street>Hoeheweg 80</street>
     <city>Biel/Bienne</city>
     <code>2501</code>
     <country>CH</country>
    </postal>
    <email>grothoff@gnunet.org</email>
   </address>
  </author>
  <author fullname="Bernd Fix" initials="B." surname="Fix">
   <organization>GNUnet e.V.</organization>
   <address>
    <postal>
     <street>Boltzmannstrasse 3</street>
     <city>Garching</city>
     <code>85748</code>
     <country>DE</country>
    </postal>
    <email>fix@gnunet.org</email>
   </address>
  </author>

  <!-- Meta-data Declarations -->
  <area>General</area>
  <workgroup>Independent Stream</workgroup>
  <keyword>name systems</keyword>
  <abstract>
   <t>This document contains the GNU Name System (GNS) technical specification.</t>
  </abstract>
 </front>
 <middle>
   <section anchor="introduction" numbered="true" toc="default">
     <name>Introduction</name>
     <t>
       The Domain Name System (DNS) is a unique distributed database and a vital
       service for most Internet applications. While DNS is distributed, it
       relies on centralized, trusted registrars to provide globally unique
       names. As the awareness of the central role DNS plays on the Internet
       rises, various institutions are using their power (including legal means)
       to engage in attacks on the DNS, thus threatening the global availability
       and integrity of information on the Internet.
     </t>
     <t>
       DNS was not designed with security as a goal. This makes it very
       vulnerable, especially to attackers that have the technical capabilities
       of an entire nation state at their disposal.
       This specification describes a censorship-resistant, privacy-preserving
       and decentralized name system: The GNU Name System (GNS). It is designed
       to provide a secure alternative to DNS, especially when censorship or
       manipulation is encountered. GNS can bind names to any kind of
       cryptographically secured token, enabling it to double in some respects as
       even as an alternative to some of today’s Public Key Infrastructures, in
       particular X.509 for the Web.
     </t>
     <t>
       This document contains the GNU Name System (GNS) technical specification
       of the GNU Name System <xref target="GNS" />, a fully decentralized and censorship-resistant
       name system. GNS provides a privacy-enhancing alternative to the Domain
       Name System (DNS). The design of GNS incorporates the capability to
       integrate and coexist with DNS. GNS is based on the principle of a petname
       system and builds on ideas from the Simple Distributed Security
       Infrastructure (SDSI), addressing a central issue with the decentralized
       mapping of secure identifiers to memorable names: namely the impossibility
       of providing a global, secure and memorable mapping without a trusted
       authority. GNS uses the transitivity in the SDSI design to replace the
       trusted root with secure delegation of authority thus making petnames
       useful to other users while operating under a very strong adversary model.
     </t>
     <t>
       This document defines the normative wire format of resource records, resolution processes,
       cryptographic routines and security considerations for use by implementors.
       GNS requires a distributed hash table (DHT) for record storage.
       Specification of the DHT is out of scope of this document.
     </t>
     <t>
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
       "OPTIONAL" in this document are to be interpreted as described
       in <xref target="RFC2119"/>.
     </t>
     <t>

     </t>
   </section>
   <section anchor="zones" numbered="true" toc="default">
     <name>Zones</name>
     <t>
       A zone in GNS is defined by a zone type "ztype" that identifies
       a cryptosystem and a public/private key pair "(d,zk)",
       where "d" is the private key and "zk" the corresponding public key
       in the public key cipher identified by the "ztype".
       The contents of a zone are cryptographically signed before
       being published a distributed hash table (DHT).
       Records are grouped by their label and encrypted (<xref target="recordencryption"/>)
       using an encryption key derived from the label and the zone public key.
       Instead of the zone private key "d", the signature MUST
       be created using a blinded public/private key pair "d'" and "zk'".
       This blinding is realized using a hierarchical deterministic key
       derivation (HDKD) scheme.
       Such a scheme allows the deterministic derivation of keys from
       the original public and private zone keys using "label" values.
       Specifically, the zone owner can derive private keys "d'", and a
       resolver to derive the corresponding public keys "zk'".  Using
       different "label" values in the derivation results in different
       keys.  Without knowledge of the "label" values, the different
       derivations are unlinkable both to the original key and to each
       other.
       This prevents zone enumeration and requires knowledge
       of both "zk" and the "label" to confirm affiliation with a
       specific zone. At the same time, the blinded "zk'" provides nodes
       with the ability to verifiy the integrity of the published information
       without disclosing the originating zone.
     </t>
     <t>
       The following variables are associated with a zone in GNS:
     </t>
     <dl>
       <dt>ztype</dt>
       <dd>
         is the unique type of the zone type as registered in the
         GNUnet Assigned Numbers Authority <xref target="GANA" />.
         The zone type determines which cryptosystem is used for the
         asymmetric and symmetric key operations of the zone. A 32-bit number.
       </dd>
       <dt>d</dt>
       <dd>
         is the private zone key. The specific format depends on the zone type.
       </dd>
       <dt>zk</dt>
       <dd>
         is the public zone key. The specific format depends on the zone type.
       </dd>
       <dt>zid</dt>
       <dd>
         is the unique public identifier of a zone. It consists of the "ztype"
         and the public zone key "zk".
       </dd>
       <dt>zTLD</dt>
       <dd>
         is a string which encodes the "ztype" as well as the zone
         key "zk" into a domain name. The "zTLD" is used as a
         globally unique reference to a specific namespace in the
         process of name resolution.
       </dd>
     </dl>
     <t>
       The "zid" wire format is defined as follows:
     </t>
     <figure anchor="figure_zid">
       <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |      PUBLIC ZONE KEY  /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
         ]]></artwork>
       <!--        <postamble>which is a very simple example.</postamble>-->
     </figure>
     <t>
       The string representation of the "zid" is defined as:
     </t>
     <artwork name="" type="" align="left" alt=""><![CDATA[
zkl := <Base32(zid)>
     ]]></artwork>
   <t>
       If "zkl" is less than 63 characters, it is also the "zTLD".
       If the resulting "zkl" should be longer than 63 characters, the
       string must be divided into smaller labels separated by the label
       separator ".".  Here, the most significant bytes of the "zid" must be contained
       in the rightmost label of the resulting string and the least significant
       bytes in the leftmost label of the resulting string. For example,
       assuming a "zkl" of 130 characters, the encoding would be:
     </t>
     <artwork name="" type="" align="left" alt=""><![CDATA[
zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
     ]]></artwork>
   </section>
   <section anchor="zone_types" numbered="true" toc="default">
     <name>Zone Types</name>
     <t>
       A zone type identifies a family of eight functions:
     </t>
     <dl>
       <dt>Private-KeyGen() -> d</dt>
       <dd>
         is a function to generate a fresh private key "d".
       </dd>
       <dt>Public-KeyGen(d) -> zk</dt>
       <dd>
         is a function to derive a public key "zk" from a private key "d".
       </dd>
       <dt>HDKD-Private(d,label) -> d'</dt>
       <dd>
         is an HDKD function which blinds a private zone key "d"
         using "label", resulting in another private key which
         can be used to create cryptographic signatures.
       </dd>
       <dt>S-Encrypt(zk,label,nonce,expiration,rdata) -> bdata</dt>
       <dd>
         is a deterministic symmetric encryption function which encrypts the record
         data "rdata" based on key material derived from "zk", "label",
         "nonce" and "expiration".
         A deterministic encryption scheme is
         required to improve performance by leveraging caching features
         of DHTs.
       </dd>
       <dt>Sign(d',bdata) -> sig</dt>
       <dd>
         is a function to sign "bdata" using the (blinded) private key
         "d'", yielding an unforgable cryptographic signature "sig".
       </dd>
       <dt>HDKD-Public(zk,label) -> zk'</dt>
       <dd>
         is a HDKD function which blinds a public zone key "zk"
         using "label". "zk" and "zk'" must be unlinkable. Furthermore,
         blinding "zk" with different values for "label" must result
         in unlinkable different resulting values for "zk'".
       </dd>
       <dt>Verify(zk',bdata,sig) -> valid</dt>
       <dd>
         is a function to verify the signature "sig" was created by
         the a private key "d'" derived from "d" and "label" if
         "zk'" was derived from the corresponding to
         "zk := Public-Keygen(d)" and "label".
         The function returns "true" if the signature is valid,
         and otherwise "false".
       </dd>
       <dt>S-Decrypt(zk,label,nonce,expiration,bdata) -> rdata</dt>
       <dd>
         is a symmetric encryption function which decrypts the encrypted record
         data "bdata" based on key material derived from "zk", "label",
         "nonce" and "expiration".
       </dd>
     </dl>
     <t>
       Zone types are identified by a 32-bit resource record type number.
       Resource record types are discussed in the next section.
     </t>
   </section>
   <section anchor="rrecords" numbered="true" toc="default">
     <name>Resource Records</name>
     <t>
       A GNS implementor MUST provide a mechanism to create and manage resource
       records for local zones. A local zone is established by selecting a
       zone type and creating a zone
       key pair. Implementations SHOULD select a secure zone type automatically
       and not leave the zone type selection to the user.
       Records may be added to each zone, hence a (local) persistency
       mechanism for resource records and zones must be provided.
       This local zone database is used by the GNS resolver implementation
       and to publish record information.
     </t>
     <t>
       A GNS resource record holds the data of a specific record in a zone.
       The resource record format is defined as follows:
     </t>
     <figure anchor="figure_gnsrecord">
       <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       DATA SIZE       |          TYPE         |
+-----+-----+-----+-----+-----+-----+-----+-----+
|           FLAGS       |        DATA           /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
         ]]></artwork>
       <!--        <postamble>which is a very simple example.</postamble>-->
     </figure>
     <t>where:</t>
     <dl>
       <dt>EXPIRATION</dt>
       <dd>
         denotes the absolute 64-bit expiration date of the record.
         In microseconds since midnight (0 hour), January 1, 1970 in network
         byte order.
       </dd>
       <dt>DATA SIZE</dt>
       <dd>
         denotes the 32-bit size of the DATA field in bytes and in network byte
         order.
       </dd>
       <dt>TYPE</dt>
       <dd>
         is the 32-bit resource record type. This type can be one of the GNS resource
         records as defined in <xref target="rrecords" /> or a DNS record
         type as defined in <xref target="RFC1035" /> or any of the
         complementary standardized DNS resource record types. This value must be
         stored in network byte order. Note that values
         below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />),
         while values above 2^16 are allocated by the
         GNUnet Assigned Numbers Authority <xref target="GANA" />.
       </dd>
       <dt>FLAGS</dt>
       <dd>
         is a 32-bit resource record flags field (see below).
       </dd>
       <dt>DATA</dt>
       <dd>
         the variable-length resource record data payload. The contents are defined
         by the
         respective type of the resource record.
       </dd>
     </dl>
     <t>
       Flags indicate metadata surrounding the resource record. A flag
       value of 0 indicates that all flags are unset. The following
       illustrates the flag distribution in the 32-bit flag value of a
       resource record:</t>
     <figure anchor="figure_flag">
       <artwork name="" type="" align="left" alt=""><![CDATA[
... 5       4         3        2        1        0
------+--------+--------+--------+--------+--------+
/ ... | SHADOW | EXPREL | SUPPL  | PRIVATE|    /   |
------+--------+--------+--------+--------+--------+
         ]]></artwork>
       <!--        <postamble>which is a very simple example.</postamble>-->
     </figure>
     <t>
       where:
     </t>
     <dl>
       <dt>SHADOW</dt>
       <dd>
         If this flag is set, this record should be ignored by resolvers unless all (other)
         records of the same record type have expired.  Used to allow zone publishers to
         facilitate good performance when records change by allowing them to put future
         values of records into the DHT. This way, future values can propagate and may be
         cached before the transition becomes active.
       </dd>
       <dt>EXPREL</dt>
       <dd>
         The expiration time value of the record is a relative time (still in microseconds)
         and not an absolute time. This flag should never be encountered by a resolver
         for records obtained from the DHT, but might be present when a resolver looks up
         private records of a zone hosted locally.
       </dd>
       <dt>
         SUPPL
       </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
         may be useful for the application. This flag should only be encountered
         by a resolver for records obtained from the DHT.
       </dd>
       <dt>PRIVATE</dt>
       <dd>
         This is a private record of this peer and it should thus not be
         published in the DHT.  Thus, this flag should never be encountered by
         a resolver for records obtained from the DHT.
         Private records should still be considered just like
         regular records when resolving labels in local zones.
       </dd>
     </dl>
   </section>
   <section anchor="gnsrecords_numbers" numbered="true" toc="default">
     <name>Record Types</name>
     <t>
       A registry of GNS Record Types is described in <xref target="gana"/>.  The
       registration policy for this registry is "First Come First Served", as
       described in <xref target="RFC8126"/>.
       <!--When requesting new entries, careful
           consideration of the following criteria is strongly advised:FIXME what considerations?-->
     </t>
     <section anchor="gnsrecords_pkey" numbered="true" toc="default">
       <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 number is a zone
         type and thus also implies the cryptosystem for the zone that
         is being delegated to.
         A PKEY resource record contains the public key of the zone to
         delegate to.
         A PKEY record MUST be the only record under a label. No other
         records are allowed. A PKEY DATA entry has the following format:</t>
       <figure anchor="figure_pkeyrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         where:
       </t>
       <dl>
         <dt>PUBLIC KEY</dt>
         <dd>
           A 256-bit ECDSA zone key.
         </dd>
       </dl>

       <t>
         For PKEY zones the zone key material is derived using the
         curve parameters of the twisted edwards representation
         of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
         with the ECDSA scheme (<xref target="RFC6979" />).
         Consequently , we use the following naming convention for our
         cryptographic primitives for PKEY zones:
       </t>
       <dl>
         <dt>d</dt>
         <dd>
           is a 256-bit ECDSA private zone key.
         </dd>
         <dt>zk</dt>
         <dd>
           is the ECDSA public zone key corresponding to d. It is defined in
           <xref target="RFC6979" /> as the curve point d*G where G is the group
           generator of the elliptic curve. The public key is used to uniquely
           identify a GNS zone and is referred to as the "zone key".
         </dd>
         <dt>p</dt>
         <dd>
           is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
           2^255 - 19.
         </dd>
         <dt>G</dt>
         <dd>
           is the group generator (X(P),Y(P)) of edwards25519 as defined in
           <xref target="RFC7748" />.
         </dd>
         <dt>L</dt>
         <dd>
           is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
         </dd>
       </dl>
       <t>
         The "zid" of a PKEY is 32 + 4 bytes in length. This means that
         a Base32-encoded "zTLD" will always fit into a single label and does
         not need any further conversion.
       </t>
       <t>
         Given a label, the output d' of the HDKD-Private(d,label) function for zone
         key blinding is calculated as follows for PKEY zones:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
zk := d * G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d' := h * d mod L
        ]]></artwork>
       <t>
         Equally, given a label, the output zk' of the HDKD-Public(zk,label) function is
         calculated as follows for PKEY zones:
       </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
zk' := h mod L * zk
        ]]></artwork>
       <t>
         The PKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in
         <xref target="RFC5869" />, using HMAC-SHA512 for the extraction
         phase and HMAC-SHA256 for the expansion phase.
         "PRK_h" is key material retrieved using an HKDF using the string
         "key-derivation" as salt and the public zone key "zk" as initial
         keying material.
         "h" is the 512-bit HKDF expansion result. The expansion info input is
         a concatenation of the label and string "gns".
         "label" is a UTF-8 string under which the resource records are
         published.
       </t>
       <t>
         We point out that the multiplication of "zk" with "h" is a point multiplication,
         while the multiplication of "d" with "h" is a scalar multiplication.
       </t>
       <t>
         The Sign() and Verify() functions
         for PKEY zones are implemented using 512-bit ECDSA deterministic
         signatures as specified in <xref target="RFC6979" />.
       </t>
       <t>
         The S-Encrypt() and S-Decrypt() functions use AES in counter mode
         as defined in <xref target="MODES" /> (CTR-AES-256):
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
RDATA := CTR-AES256(K, IV, BDATA)
BDATA := CTR-AES256(K, IV, RDATA)
         ]]></artwork>
       <t>
         The key "K" and counter "IV" are derived from
         the record "label" and the zone key "zk" as follows:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 256 / 8);
NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
]]></artwork>
       <t>
         HKDF is a hash-based key derivation function as defined in
         <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
         extraction phase and HMAC-SHA256 for the expansion phase.
         The output keying material is 32 octets (256 bits) for the symmetric
         key and 4 octets (32 bits) for the nonce.
         The symmetric key "K" is a 256-bit AES <xref target="RFC3826" /> key.
       </t>
       <t>
         The nonce is combined with a 64-bit initialization vector and a
         32-bit block counter as defined in <xref target="RFC3686" />.
         The block counter begins with the 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 initialization vector is the expiration time of the
         resource record block in network byte order.
         The resulting counter ("IV") wire format is as follows:
       </t>
       <figure anchor="figure_hkdf_ivs_pkey">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32
+-----+-----+-----+-----+
|         NONCE         |
+-----+-----+-----+-----+
|       EXPIRATION      |
|                       |
+-----+-----+-----+-----+
|      BLOCK COUNTER    |
+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
     </section>

     <section anchor="gnsrecords_edkey" numbered="true" toc="default">
       <name>EDKEY</name>
       <t>In GNS, a delegation of a label to a zone of type "EDKEY" is
         represented through a EDKEY record.  The EDKEY number is a zone
         type and thus also implies the cryptosystem for the zone that
         is being delegated to.
         An EDKEY resource record contains the public key of the zone to
         delegate to.
         A EDKEY record MUST be the only record under a label. No other
         records are allowed. A EDKEY DATA entry has the following format:</t>
       <figure anchor="figure_edkeyrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         where:
       </t>
       <dl>
         <dt>PUBLIC KEY</dt>
         <dd>
           A 256-bit EdDSA zone key.
         </dd>
       </dl>
         <t>
           For EDKEY zones the zone key material is derived using the
           curve parameters of the twisted edwards representation
           of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
           with the Ed25519-SHA-512 scheme <xref target="ed25519" />.
           Consequently , we use the following naming convention for our
           cryptographic primitives for EDKEY zones:
         </t>
         <dl>
           <dt>d</dt>
           <dd>
             is a 256-bit EdDSA private zone key.
           </dd>
           <dt>a</dt>
           <dd>
             is is an integer derived from "d" using the SHA512 hash function
             as defined in <xref target="ed25519" />.
           </dd>
           <dt>zk</dt>
           <dd>
             is the EdDSA public zone key corresponding to "d". It is defined in
             <xref target="ed25519" /> as the curve point "a*G" where "G" is the
             group generator of the elliptic curve and "a" is an integer
             derived from "d" using the SHA512 hash function.
             The public key is used to uniquely identify a GNS zone and is
             referred to as the "zone key".
           </dd>
           <dt>p</dt>
           <dd>
             is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
             2^255 - 19.
           </dd>
           <dt>G</dt>
           <dd>
             is the group generator (X(P),Y(P)) of edwards25519 as defined in
            <xref target="RFC7748" />.
           </dd>
           <dt>L</dt>
           <dd>
             is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
           </dd>
         </dl>
         <t>
           The "zid" of an EDKEY is 32 + 4 bytes in length. This means that
           a Base32-encoded "zTLD" will always fit into a single label and does
           not need any further conversion.
         </t>
         <t>
           Given a label, the output of the HDKD-Private function for zone
           key blinding is calculated as follows for EDKEY zones:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
zk := a * G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
h[0] &= 248;
h[31] &= 127;
h[31] |= 64;
a' := h * a mod L
           ]]></artwork>
         <t>
           Equally, given a label, the output of the HDKD-Public function is
           calculated as follows for PKEY zones:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
h[0] &= 248;
h[31] &= 127;
h[31] |= 64;
zk' := h mod L * zk
         ]]></artwork>
         <t>
           The EDKEY cryptosystem uses a
           hash-based key derivation function (HKDF) as defined in
           <xref target="RFC5869" />, using HMAC-SHA512 for the extraction
           phase and HMAC-SHA256 for the expansion phase.
           "PRK_h" is key material retrieved using an HKDF using the string
           "key-derivation" as salt and the public zone key "zk" as initial
           keying material.
           "h" is the 512-bit HKDF expansion result. The expansion info input is
           a concatenation of the label and string "gns".
           The result of the HKDF must be clamped.
           "a" is the 256-bit integer corresponding to the 256-bit private zone
           key "d".
           "label" is a UTF-8 string under which the resource records are
           published.
         </t>
         <t>
           We point out that the multiplication of "zk" with "h" is a point multiplication,
           while the multiplication of "a" with "h" is a scalar multiplication.
         </t>
         <t>
           Signatures for EDKEY zones using the derived private key "a'"
           are NOT compliant with <xref target="ed25519" />.
           Instead, signatures MUST be generated as follows for any given
           message M and deterministic random-looking "r":
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
R := r * G
S := r + SHA512(R, zk', M) * a' mod L
           ]]></artwork>
         <t>
           A signature (R,S) is valid if the following holds:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
SB == R + SHA512(R, zk', M) * A'
           ]]></artwork>
         <t>
           <!-- FIXME: here we SHOULD consider standardizing AES-GCM
                instead. Please review this choice when implementing
                EDKEY support! -->
           The S-Encrypt() and S-Decrypt() functions use AES in galois
           counter mode as defined in <xref target="GCM" /> (GCM-AES-256):
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
RDATA := GCM-AES-256(K, IV, BDATA)
BDATA := GCM-AES-256(K, IV, RDATA) = CIPHERTEXT | GCM_TAG
           ]]></artwork>
         <t>
           The result of the GCM encryption function is the encrypted
           ciphertext concatenated with the 128-bit GCM authentication
           tag "GCM_TAG".
           Accordingly, the length of BDATA equals the length of the
           RDATA plus the 16 octets of the authentication tag.
         </t>
         <t>
           The key "K" and counter "IV" are derived from
           the record "label" and the zone key "zk" as follows:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 256 / 8);
IV := HKDF-Expand (PRK_n, label, 96 / 8)
]]></artwork>
         <t>
           HKDF is a hash-based key derivation function as defined in
           <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
           extraction phase and HMAC-SHA256 for the expansion phase.
           The output keying material is 32 octets (256 bits) for the symmetric
           key and 12 octets (96 bits) for the IV.
           The symmetric key "K" is a 256-bit AES <xref target="RFC3826" /> key.
           No additional authenticated data (AAD) is used.
         </t>
       </section>

       <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
       <name>GNS2DNS</name>
       <t>It is possible to delegate a label back into DNS through a GNS2DNS record.
         The resource record contains a DNS name for the resolver to continue with
         in DNS followed by a DNS server. Both names are in the format defined in
         <xref target="RFC1034" /> for DNS names.
         A GNS2DNS DATA entry has the following format:</t>
       <figure anchor="figure_gns2dnsrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    DNS NAME                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 DNS SERVER NAME               |
/                                               /
/                                               /
|                                               |
+-----------------------------------------------+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         where:
       </t>
       <dl>
         <dt>DNS NAME</dt>
         <dd>
           The name to continue with in DNS (0-terminated).
         </dd>
         <dt>DNS SERVER NAME</dt>
         <dd>
           The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
           form or a DNS name. It may also be a relative GNS name ending with a
           "+" top-level domain. The value is UTF-8 encoded (also for DNS names)
           and 0-terminated.
         </dd>
       </dl>
     </section>

     <section anchor="gnsrecords_leho" numbered="true" toc="default">
       <name>LEHO</name>
       <t>Legacy hostname records can be used by applications that are expected
         to supply a DNS name on the application layer. The most common use case
         is HTTP virtual hosting, which as-is would not work with GNS names as
         those may not be globally unique.

         A LEHO resource record is expected to be found together in a single
         resource record with an IPv4 or IPv6 address.
         A LEHO DATA entry has the following format:</t>
       <figure anchor="figure_lehorecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 LEGACY HOSTNAME               |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         where:
       </t>
       <dl>
         <dt>LEGACY HOSTNAME</dt>
         <dd>
           A UTF-8 string (which is not 0-terminated) representing the legacy hostname.
         </dd>
       </dl>
       <t>
         NOTE: If an application uses a LEHO value in an HTTP request header
         (e.g. "Host:" header) it must be converted to a punycode representation
         <xref target="RFC5891" />.
       </t>
     </section>
     <section anchor="gnsrecords_nick" numbered="true" toc="default">
       <name>NICK</name>
       <t>
         Nickname records can be used by zone administrators to publish an
         indication on what label this zone prefers to be referred to.
         This is a suggestion to other zones what label to use when creating a
         delegation record (<xref target="zone_types" />) containing this zone's
         public zone key.
         This record SHOULD only be stored under the empty label "@" but MAY be
         returned with record sets under any label as a supplemental record.
         <xref target="nick_processing"/> details how a resolver must process
         supplemental and non-supplemental NICK records.
         A NICK DATA entry has the following format:
       </t>
       <figure anchor="figure_nickrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                  NICKNAME                     |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         where:
       </t>
       <dl>
         <dt>NICKNAME</dt>
         <dd>
           A UTF-8 string (which is not 0-terminated) representing the preferred
           label of the zone. This string MUST NOT include a "." character.
         </dd>
       </dl>
     </section>
     <section anchor="gnsrecords_box" numbered="true" toc="default">
       <name>BOX</name>
       <t>
         In GNS, every "." in a name delegates to another zone, and
         GNS lookups are expected to return all of the required useful
         information in one record set.  This is incompatible with the
         special labels used by DNS for SRV and TLSA records.  Thus, GNS
         defines the BOX record format to box up SRV and TLSA records and
         include them in the record set of the label they are associated
         with.  For example, a
         TLSA record for "_https._tcp.example.org" will be stored in the record set of
         "example.org" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
         (tcp) and record TYPE "TLSA".
         For reference, see also <xref target="RFC2782" />.
         A BOX DATA entry has the following format:
       </t>
       <figure anchor="figure_boxrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PROTO   |    SVC    |       TYPE            |
+-----------+-----------------------------------+
|                 RECORD DATA                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         where:
       </t>
       <dl>
         <dt>PROTO</dt>
         <dd>
           the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
         </dd>
         <dt>SVC</dt>
         <dd>
           the 16-bit service value of the boxed record, i.e. the port number.
           In network byte order.
         </dd>
         <dt>TYPE</dt>
         <dd>
           is the 32-bit record type of the boxed record. In network byte order.
         </dd>
         <dt>RECORD DATA</dt>
         <dd>
           is a variable length field containing the "DATA" format of TYPE as
           defined for the respective TYPE in DNS.
         </dd>
       </dl>
     </section>
     <section anchor="gnsrecords_vpn" numbered="true" toc="default">
       <name>VPN</name>
       <t>
         A VPN DATA entry has the following format:</t>
       <figure anchor="figure_vpnrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|          HOSTING PEER PUBLIC KEY              |
|                (256 bits)                     |
|                                               |
|                                               |
+-----------+-----------------------------------+
|   PROTO   |    SERVICE  NAME                  |
+-----------+                                   +
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         where:
       </t>
       <dl>
         <dt>HOSTING PEER PUBLIC KEY</dt>
         <dd>
           is a 256-bit EdDSA public key identifying the peer hosting the
           service.
         </dd>
         <dt>PROTO</dt>
         <dd>
           the 16-bit protocol number, e.g. 6 for TCP. In network byte order.
         </dd>
         <dt>SERVICE NAME</dt>
         <dd>
           a shared secret used to identify the service at the hosting peer,
           used to derive the port number requird to connect to the service.
           The service name MUST be a 0-terminated UTF-8 string.
         </dd>
       </dl>
     </section>
   </section>
   <section anchor="publish" numbered="true" toc="default">
     <name>Publishing Records</name>
     <t>
       GNS resource records are published in a distributed hash table (DHT).
       We assume that a DHT provides two functions: GET(key) and PUT(key,value).
       In GNS, resource records are grouped by their respective labels,
       encrypted and published together in a single resource records block
       (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
       The key "q" which is derived from the zone key "zk" and the respective
       "label" of the contained records.
     </t>
     <section anchor="blinding" numbered="true" toc="default">
       <name>DHT Key Derivations</name>
       <t>
         Given a label, the DHT key "q" is derived as follows:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
q := SHA512 (HDKD-Public(zk, label))
         ]]></artwork>
       <dl>
         <dt>label</dt>
         <dd>is a UTF-8 string under which the resource records are published.
         </dd>
         <dt>zk</dt>
         <dd>
           is the public zone key.
         </dd>
         <dt>q</dt>
         <dd>
           Is the 512-bit DHT key under which the resource records block is
           published.
           It is the SHA512 hash over the derived public zone key.
         </dd>
       </dl>
     </section>
     <section anchor="wire" numbered="true" toc="default">
       <name>Resource Records Block</name>
       <t>
         GNS records are grouped by their labels and published as a single
         block in the DHT. The grouped record sets MAY be paired with any
         number of supplemental records. Supplemental records must have the
         supplemental flag set (See <xref target="rrecords"/>).
         The contained resource records are encrypted using a symmetric
         encryption scheme.
         A GNS implementation must publish RRBLOCKs
         in accordance to the properties and recommendations of the underlying
         DHT. This may include a periodic refresh publication.
         A GNS RRBLOCK has the following format:
       </t>
       <figure anchor="figure_record_block">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   SIGNATURE                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |    PUBLIC ZONE KEY    |
+-----+-----+-----+-----+       (BLINDED)       |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE          |       PURPOSE         |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    BDATA                      /
/                                               /
/                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>where:</t>
       <dl>
         <dt>SIGNATURE</dt>
         <dd>
           The signature is computed over the data following
           the PUBLIC KEY field.
           The signature is created using the Sign() function of
           the cryptosystem of the zone and the derived private key
           "HDKD-Private(d, label)" (see <xref target="zone_types" />).
         </dd>
         <dt>ZONE TYPE</dt>
         <dd>
           is the 32-bit zone type.
         </dd>
         <dt>ZONE PUBLIC KEY</dt>
         <dd>
           is the blinded public zone key "HDKD-Public(zk, label)"
           to be used to verify SIGNATURE.
         </dd>
         <dt>SIZE</dt>
         <dd>
           A 32-bit value containing the length of the signed data following the
           PUBLIC KEY field in network byte order. This value always includes the
           length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
           addition to the length of the BDATA.  While a 32-bit value is used,
           implementations MAY refuse to publish blocks beyond a certain
           size significantly below 4 GB. However, a minimum block size of
           62 kilobytes MUST be supported.
           <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
         </dd>
         <dt>PURPOSE</dt>
         <dd>
           A 32-bit signature purpose flag. This field MUST be 15 (in network
           byte order).
         </dd>
         <dt>EXPIRATION</dt>
         <dd>
           Specifies when the RRBLOCK expires and the encrypted block
           SHOULD be removed from the DHT and caches as it is likely stale.
           However, applications MAY continue to use non-expired individual
           records until they expire.  The value MUST be set to the
           expiration time of the resource record contained within this block with the
           smallest expiration time.
           If a records block includes shadow records, then the maximum
           expiration time of all shadow records with matching type and the
           expiration times of the non-shadow records is considered.
           This is a 64-bit absolute date in microseconds since midnight
           (0 hour), January 1, 1970 in network byte order.
         </dd>
         <dt>BDATA</dt>
         <dd>
           The encrypted resource records with a total size of SIZE - 16.
         </dd>
       </dl>
     </section>
     <section anchor="recordencryption" numbered="true" toc="default">
       <name>Record Data Encryption and Decryption</name>
       <t>
         A symmetric encryption scheme is used to encrypt the resource records
         set RDATA into the BDATA field of a GNS RRBLOCK.
         The wire format of the RDATA looks as follows:
       </t>
       <figure anchor="figure_rdata">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|     RR COUNT          |        EXPIRA-        /
+-----+-----+-----+-----+-----+-----+-----+-----+
/         -TION         |       DATA SIZE       |
+-----+-----+-----+-----+-----+-----+-----+-----+
|         TYPE          |          FLAGS        |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      DATA                     /
/                                               /
/                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       DATA SIZE       |          TYPE         |
+-----+-----+-----+-----+-----+-----+-----+-----+
|           FLAGS       |        DATA           /
+-----+-----+-----+-----+                       /
/                       +-----------------------/
/                       |                       /
+-----------------------+                       /
/                     PADDING                   /
/                                               /
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>where:</t>
       <dl>
         <dt>RR COUNT</dt>
         <dd>
           A 32-bit value containing the number of variable-length resource
           records which are
           following after this field in network byte order.
         </dd>
         <dt>EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
         <dd>
           These fields were defined
           in the resource record format in <xref target="rrecords" />.
           There MUST be a total of RR COUNT of these resource records
           present.
         </dd>
         <dt>PADDING</dt>
         <dd>
           The padding MUST contain the value 0 in all octets.
           The padding MUST ensure that the size of the RDATA WITHOUT the RR
           COUNT field is a power of two.
           As a special exception, record sets with (only) a zone delegation
           record type are never padded.
           Note that a record set with a delegation record MUST NOT
           contain other records.
         </dd>
       </dl>
     </section>
   </section>
   <section anchor="encoding" numbered="true" toc="default">
     <name>Internationalization and Character Encoding</name>
     <t>
       All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
       This does not include any DNS names found in DNS records, such as CNAME
       records, which are internationalized through the IDNA specifications
       <xref target="RFC5890" />.
     </t>
   </section>
   <section anchor="resolution" numbered="true" toc="default">
     <name>Name Resolution</name>
     <t>
       Names in GNS are resolved by recursively querying the DHT record storage.
       In the following, we define how resolution is initiated and each
       iteration in the resolution is processed.
     </t>
     <t>
       GNS resolution of a name must start in a given starting zone indicated using
       a zone public key.
       Details on how the starting zone may be determined is discussed in
       <xref target="governance" />.
     </t>
     <t>
       When GNS name resolution is requested, a desired record type MAY be
       provided by the client.
       The GNS resolver will use the desired record type to guide
       processing, for example by providing conversion of VPN records to A
       or AAAA records, if that is desired.

       However, filtering of record sets according to the required record
       types MUST still be done by the client after the resource record set
       is retrieved.
     </t>
       <section anchor="recursion" numbered="true" toc="default">
         <name>Recursion</name>
         <t>
           In each step of the recursive name resolution, there is an
           authoritative zone zk and a name to resolve. The name may be empty.
           Initially, the authoritative zone is the start zone. If the name
           is empty, it is interpreted as the apex label "@".
         </t>
         <t>
           From here, the following steps are recursively executed, in order:
         </t>
         <ol>
           <li>Extract the right-most label from the name to look up.</li>
           <li>Calculate q using the label and zk as defined in
           <xref target="blinding" />.</li>
           <li>Perform a DHT query GET(q) to retrieve the RRBLOCK.</li>
           <li>Verify and process the RRBLOCK and decrypt the BDATA contained
             in it as defined in <xref target="recordencryption" />.</li>
         </ol>
         <t>
           Upon receiving the RRBLOCK from the DHT, apart from verifying the
           provided signature, the resolver MUST check that the authoritative
           zone key was used to sign the record:
           The derived zone key "h*zk" MUST match the public key provided in
           the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT lookup
           GET(q) MUST continue.
         </t>
       </section>
       <section anchor="record_processing" numbered="true" toc="default">
         <name>Record Processing</name>
   <t>
           Record processing occurs at the end of a single recursion. We assume
           that the RRBLOCK has been cryptographically verified and decrypted.
           At this point, we must first determine if we have received a valid
           record set in the context of the name we are trying to resolve:
         </t>
   <ol>
         <li>
           Case 1:
           If the remainder of the name to resolve is empty and the record set
           does not consist of a delegation, CNAME or DNS2GNS record,
           the record set is the result and the recursion is concluded.
         </li>
   <li>
     Case 2:
     If 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 result and the recusion
     is concluded (<xref target="box_processing" />).
   </li>
         <li>
           Case 3:
           If the remainder of the name to resolve is not empty and
     does not match the "_SERVICE._PROTO" syntax, then the current record set
           MUST consist of a single delegation record (<xref target="delegation_processing" />),
           a single CNAME record (<xref target="cname_processing" />),
           or one or more GNS2DNS records (<xref target="gns2dns_processing" />),
           which are processed as described in the respective sections below.
           The record set may include any number of supplemental records.
           Otherwise, resolution fails
           and the resolver MUST return an empty record set.

     Finally, after the recursion terminates, the client preferences
     for the record type SHOULD be considered. If a VPN record is found
     and the client requests an A or AAAA record, the VPN record
     SHOULD be converted (<xref target="vpn_processing" />)
     if possible.
   </li>
   </ol>
         <section anchor="delegation_processing" numbered="true" toc="default">
           <name>Encountering 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.
             Implementations MUST NOT allow multiple different zone type
             delegations under a single label.
             Implementations MAY support any subset of zone types.  If
             an unsupported zone type is encountered, resolution fails
             (NXDOMAIN).
           </t>
           <t>
             If the remainder of the name to resolve is empty and we have
             received a record set containing only a single PKEY record, the
             recursion is continued with the PKEY as authoritative zone and
             the empty apex label "@" as remaining name, except in the case
             where the desired record type is PKEY, in which case the PKEY
             record is returned and the resolution is concluded without
             resolving the empty apex label.
           </t>
         </section>
         <section anchor="gns2dns_processing" numbered="true" toc="default">
           <name>GNS2DNS</name>
           <t>
             When a resolver encounters one or more GNS2DNS records and the remaining name
             is empty and the desired record type is GNS2DNS, the GNS2DNS
             records are returned.
           </t>
           <t>
             Otherwise, it is expected that the resolver first resolves the
             IP(s) of the specified DNS name server(s). GNS2DNS records MAY
             contain numeric IPv4 or IPv6 addresses, allowing the resolver to
             skip this step.
             The DNS server names may themselves be names in GNS or DNS.
             If the DNS server name ends in ".+", the rest of the name is to be
             interpreted relative to the zone of the GNS2DNS record.
             If the DNS server name ends in a label representation of a
             zone key, the DNS server name is to be resolved against
             the GNS zone zk.
           </t>
           <t>
             Multiple GNS2DNS records may be stored under the same label,
             in which case the resolver MUST try all of them.
             The resolver MAY try them in any order or even in parallel.
             If multiple GNS2DNS records are present, the DNS name MUST be
             identical for all of them, if not the resolution fails and an
             emtpy record set is returned as the record set is invalid.
           </t>
           <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
             resolved by querying the DNS name server(s).  As the DNS servers
             specified are possibly authoritative DNS servers, the GNS resolver MUST
             support recursive resolution and MUST NOT delegate this to the
             authoritative DNS servers.
             The first successful recursive name resolution result
             is returned to the client.
             In addition, the resolver returns the queried DNS name as a
             supplemental LEHO record (<xref target="gnsrecords_leho" />) with a
             relative expiration time of one hour.
           </t>
     <t>
       GNS resolvers SHOULD offer a configuration
       option to disable DNS processing to avoid information leakage
       and provide a consistent security profile for all name resolutions.
       Such resolvers would return an empty record set upon encountering
       a GNS2DNS record during the recursion. However, if GNS2DNS records
       are encountered in the record set for the apex and a GNS2DNS record
       is expicitly requested by the application, such records MUST
       still be returned, even if DNS support is disabled by the
       GNS resolver configuration.
     </t>
         </section>
         <section anchor="cname_processing" numbered="true" toc="default">
           <name>CNAME</name>
           <t>
             If a CNAME record is encountered, the canonical name is
             appended to the remaining name, except if the remaining name
             is empty and the desired record type is CNAME, in which case
             the resolution concludes with the CNAME record.
             If the canonical name ends in ".+",
             resolution continues in GNS with the new name in the
             current zone.  Otherwise, the resulting name is resolved via the
             default operating system name resolution process.
             This may in turn again trigger a GNS resolution process depending
             on the system configuration.
             <!-- Note: this permits non-DNS resolvers to be triggered via NSS! -->
           </t>
           <t>
             The recursive DNS resolution process may yield a CNAME as well
             which in turn may either point into the DNS or GNS namespace
             (if it ends in a label representation of a zone key).
             In order to prevent infinite loops, the resolver MUST
             implement loop detections or limit the number of recursive
             resolution steps.
             If the last CNAME was a DNS name, the resolver returns the DNS name
             as a supplemental LEHO record (<xref target="gnsrecords_leho" />)
             with a relative expiration time of one hour.
       <!-- Note: Martin: do we actually implement this in GNS today?
      Seems rather tricky to detect if we go via NSS... -->
           </t>
         </section>
         <section anchor="box_processing" numbered="true" toc="default">
           <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
             (and SRV) records do not require a separate network request, and
             TLSA records become inseparable from the corresponding address
             records.
           </t>
         </section>
         <section anchor="vpn_processing" numbered="true" toc="default">
           <name>VPN</name>
           <t>
       At the end of the recursion,
             if the queried record type is either A or AAAA and the retrieved
             record set contains at least one VPN record, the resolver SHOULD
             open a tunnel and return the IPv4 or IPv6 tunnel address,
             respectively.
             The type of tunnel depends on the contents of the VPN record data.
             The VPN record MUST be returned if the resolver implementation
             does not support setting up a tunnnel.
           </t>
         </section>
         <section anchor="nick_processing" numbered="true" toc="default">
           <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 client. The encountered NICK records may either
             be 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
             queried record type.
           </t>
           <t>
             The differentiation between a supplemental and non-supplemental
             NICK record allows the client to match the record to the
             authoritative zone. Consider the following example:
           </t>
       <figure>
         <artwork name="" type="" align="left" alt=""><![CDATA[
Query: alice.example (type=A)
Result:
A: 192.0.2.1
NICK: eve
         ]]></artwork>
        </figure>
        <t>
          In this example, the returned NICK record is non-supplemental.
          For the client, this means that the NICK belongs to the zone
          "alice.doe" and is published under the empty label along with an A
          record. The NICK record should be interpreted as: The zone defined by
          "alice.doe" wants to be referred to as "eve".
          In contrast, consider the following:
        </t>
       <figure>
         <artwork name="" type="" align="left" alt=""><![CDATA[
Query: alice.example (type=AAAA)
Result:
AAAA: 2001:DB8::1
NICK: john (Supplemental)
         ]]></artwork>
     </figure>
     <t>
       In this case, the NICK record is marked as supplemental. This means that
       the NICK record belongs to the zone "doe" and is published under the
       label "alice" along with an A record. The NICK record should be
       interpreted as: The zone defined by "doe" wants to be referred to as
       "john". This distinction is likely useful for other records published as
       supplemental.
      </t>


         </section>
       </section>
     </section>
     <section anchor="revocation" numbered="true" toc="default">
       <name>Zone Revocation</name>
       <t>
         Whenever a recursive resolver encounters a new GNS zone, it MUST
         check against the local revocation list whether the respective
         zone key has been revoked.  If the zone key was revoked, the
         resolution MUST fail with an empty result set.
       </t>
       <t>
         In order to revoke a zone key, a signed revocation object SHOULD be
         published.
         This object MUST be signed using the private zone key.
         The revocation object is flooded in the overlay network. To prevent
         flooding attacks, the revocation message MUST contain a proof of work
         (PoW).
         The revocation message including the PoW MAY be calculated
         ahead of time to support timely revocation.
       </t>
       <t>
         For all occurences below, "Argon2id" is the Password-based Key
         Derivation Function as defined in <xref target="Argon2" />. For the
         PoW calculations the algorithm is instantiated with the
         following parameters:
       </t>
       <dl>
         <dt>S</dt>
         <dd>The salt. Fixed 16-octet 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>
         The following is the message string "P" on which the PoW is
         calculated:
       </t>
       <figure anchor="figure_revocation">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      POW                      |
+-----------------------------------------------+
|                   TIMESTAMP                   |
+-----------------------------------------------+
|       ZONE TYPE       |    PUBLIC ZONE KEY    |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>where:</t>
       <dl>
         <dt>POW</dt>
         <dd>
           A 64-bit solution to the PoW. In network byte order.
         </dd>
         <dt>TIMESTAMP</dt>
         <dd>
           denotes the absolute 64-bit date when the revocation was computed.
           In microseconds since midnight (0 hour), January 1, 1970 in network
           byte order.
         </dd>
         <dt>PUBLIC KEY</dt>
         <dd>
           is the 256-bit public key "zk" of the zone which is being revoked and
           the key to be used to verify SIGNATURE. The
           wire format of this value is defined in <xref target="RFC8032" />,
           Section 5.1.5.
         </dd>
       </dl>
       <t>
         Traditionally, PoW schemes require to find a "POW" such that
         at least D leading zeroes are found in the hash result.
         D is then referred to as the "difficulty" of the PoW.
         In order to reduce the variance in time it takes to calculate the
         PoW, we require that a number "Z" different PoWs must be
         found that on average have "D" leading zeroes.
       </t>
       <t>
         The resulting proofs may then published and disseminated. The concrete
         dissemination and publication methods are out of scope of this
         document. Given an average difficulty of "D", the proofs have an
         expiration time of EPOCH. With each additional bit difficulty, the
         lifetime of the proof is prolonged for another EPOCH.
         Consequently, by calculating a more difficult PoW, the lifetime of the
         proof can be increased on demand by the zone owner.
       </t>
       <t>
         The parameters are defined as follows:
       </t>
       <dl>
         <dt>Z</dt>
         <dd>The number of PoWs required is fixed at 32.</dd>
         <dt>D</dt>
         <dd>The difficulty is fixed at 22.</dd>
         <dt>EPOCH</dt>
         <dd>A single epoch is fixed at 365 days.</dd>
       </dl>
       <t>
         Given that proof has been found, a revocation data object is defined
         as follows:
       </t>
       <figure anchor="figure_revocationdata">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      TTL                      |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     POW_0                     |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                       ...                     |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     POW_Z-1                   |
+-----------------------------------------------+
|                   SIGNATURE                   |
|                                               |
|                                               |
|                                               |
|                                               |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |    PUBLIC ZONE KEY    |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>where:</t>
       <dl>
         <dt>TIMESTAMP</dt>
         <dd>
           denotes the absolute 64-bit date when the revocation was computed.
           In microseconds since midnight (0 hour), January 1, 1970 in network
           byte order. This is the same value as the timestamp used in the
           individual PoW calculations.
         </dd>
         <dt>TTL</dt>
         <dd>
           denotes the relative 64-bit time to live of of the record in
           microseconds also in network byte order. This field is informational
           for a verifier. The verifier may discard revocation if the TTL
           indicates that it is already expired. However, the actual TTL of the
           revocation must be determined by examining the leading zeros in the
           proof of work calculation.
         </dd>
         <dt>POW_i</dt>
         <dd>
           The values calculated as part of the PoW, in network byte order.
           Each POW_i MUST be unique in the set of POW values.
           To facilitate fast verification
           of uniqueness, the POW values must be given in strictly
           monotonically increasing order in the message.
         </dd>
         <dt>SIGNATURE</dt>
         <dd>
           A 512-bit ECDSA deterministic signature compliant with
           <xref target="RFC6979" /> over the public zone zk of the zone
           which is revoked and corresponds to the key used in the PoW.
           The signature is created using the private zone key "d" (see
           <xref target="zones" />).
         </dd>
         <dt>ZONE TYPE</dt>
         <dd>
           The 32-bit zone type corresponding to the zone public key.
         </dd>
         <dt>ZONE PUBLIC KEY</dt>
         <dd>
           is the public key "zk" of the zone which is being revoked and
           the key to be used to verify SIGNATURE.
         </dd>
       </dl>
      <t>
         The signature over the public key covers a 32-bit pseudo header
         conceptually prefixed to the public key. The pseudo header includes
         the key length and signature purpose:
       </t>
       <figure anchor="figure_revsigwithpseudo">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE (0x30)   |       PURPOSE (0x03)  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |     ZONE PUBLIC KEY   |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>where:</t>
       <dl>
         <dt>SIZE</dt>
         <dd>
           A 32-bit value containing the length of the signed data in bytes
           in network byte order.
         </dd>
         <dt>PURPOSE</dt>
         <dd>
           A 32-bit signature purpose flag. This field MUST be 3 (in network
           byte order).
         </dd>
         <dt>ZONE TYPE</dt>
         <dd>
           The 32-bit zone type corresponding to the zone public key.
         </dd>
         <dt>ZONE PUBLIC KEY / TIMESTAMP</dt>
         <dd>Both values as defined in the revocation data object above.</dd>
       </dl>
       <t>
         In order to verify a revocation the following steps must be taken,
         in order:
       </t>
       <ol>
         <li>The current time MUST be between TIMESTAMP and
           TIMESTAMP+TTL.</li>
         <li>The signature MUST match the public key.</li>
         <li>The set of POW values MUST NOT contain duplicates.</li>
         <li>The average number of leading zeroes resulting from the provided
           POW values D' MUST be greater than D.</li>
         <li>The validation period (TTL) of the revocation is calculated as
           (D'-D) * EPOCH * 1.1. The EPOCH is extended by
           10% in order to deal with unsynchronized clocks.
           The TTL added on top of the TIMESTAMP yields the
           expiration date.</li>
       </ol>
     </section>
     <section anchor="governance" numbered="true" toc="default">
       <name>Determining the Root Zone and Zone Governance</name>
       <t>
         The resolution of a GNS name must start in a given start zone
         indicated to the resolver using any public zone key.
         The local resolver may have a local start zone configured/hard-coded
         which points to a local or remote start zone key.
         A resolver client may also determine the start zone from the
         suffix of the name given for resolution or using information
   retrieved out of band.
         The governance model of any zone is at the sole discretion
         of the zone owner. However, the choice of start zone(s) is at the sole
         discretion of the local system administrator or user.
       </t>
       <t>
         This is an important distinguishing factor from the Domain Name System
         where root zone governance is centralized at the Internet Corporation
         for Assigned Names and Numbers (ICANN).
         In DNS terminology, GNS roughly follows the idea of a hyper-hyper
   local root zone deployment, with the difference that it is not
   expected that all deployments use the same local root zone.
       </t>
       <t>
         In the following, we give examples how a local client resolver SHOULD
         discover the start zone.  The process given is not exhaustive and
         clients MAY suppliement it with other mechanisms or ignore it if the
   particular application requires a different process.
       </t>
       <t>
         GNS clients MUST first try to interpret the top-level domain of
         a GNS name as a zone key representation ("zTLD").
         If the top-level domain is indicated to be a label representation of
         a public zone key with a well-defined "ztype" value, the root zone of
         the resolution process is implicitly given by the suffic of the name:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.<zTLD>
=> Root zone: zk of type ztype
=> Name to resolve from root zone: www.example
         ]]></artwork>
       <t>
         In GNS, users MAY own and manage their own zones.
         Each local zone SHOULD be associated with a single GNS label,
   but users MAY choose to use longer names consisting of
   multiple labels.
         If the name of a locally managed zone matches the suffix
   of the name to be resolved,
   resolution SHOULD start from the respective local zone:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.org
Local zones:
fr = (d0,zk0)
gnu = (d1,zk1)
com = (d2,zk2)
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www.example
         ]]></artwork>
       <t>
         Finally, additional "suffix to zone" mappings MAY be configured.
         Suffix to zone key mappings SHOULD be configurable through a local
         configuration file or database by the user or system administrator.
         The suffix MAY consist of multiple GNS labels concatenated with a
         ".". If multiple suffixes match the name to resolve, the longest
         matching suffix MUST BE used. The suffix length of two results
         cannot be equal, as this would indicate a misconfiguration.
   If both a locally managed zone and a configuration entry exist
   for the same suffix, the locally managed zone MUST have priority.
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.org
Local suffix mappings:
gnu = zk0
example.org = zk1
example.com = zk2
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www
         ]]></artwork>
     </section>
     <section anchor="security" numbered="true" toc="default">
       <name>Security Considerations</name>
       <section anchor="security_crypto" numbered="true" toc="default">
         <name>Cryptography</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.  The security also depends on the engineering
           of the protocol used by the system to ensure that there are no
           non-cryptographic ways to bypass the security of the overall system.
         </t>
         <t>
           This document concerns itself with the selection of cryptographic
           algorithms for use in GNS.
           The algorithms identified in this document are not known to be
           broken (in the cryptographic sense) at the current time, and
           cryptographic research so far leads us to believe that they are
           likely to remain secure into the foreseeable future.  However, this
           isn't necessarily forever, and it is expected that new revisions of
           this document will be issued from time to time to reflect the current
           best practices in this area.
         </t>
         <t>
           GNS PKEY zone keys use ECDSA over Curve25519.
           This is an unconventional choice,
           as ECDSA is usually used with other curves.  However, traditional
           ECDSA curves are problematic for a range of reasons described in
           the Curve25519 and EdDSA papers.  Using EdDSA directly is also
           not possible, as a hash function is used on the private key which
           destroys the linearity that the GNU Name System depends upon.
           We are not aware of anyone suggesting that using Curve25519 instead
           of another common curve of similar size would lower the security of
           ECDSA.  GNS uses 256-bit curves because that way the encoded (public)
           keys fit into a single DNS label, which is good for usability.
         </t>
         <t>
           In terms of crypto-agility, whenever the need for an updated cryptographic
           scheme arises to, for example, replace ECDSA over Curve25519 for
           PKEY records it may simply be introduced
           through a new record type. Such a new record type may then replace
           the delegation record type for future records.
           The old record type remains
           and zones can iteratively migrate to the updated zone keys.
         </t>
         <t>
           In order to ensure ciphertext indistinguishability, care must be
           taken with respect to the initialization vector in the counter
           block. In our design, the IV is always the expiration time of the
           record block.
           For blocks with relative expiration times it is implicitly
           ensured that each time a block is published into the DHT, its IV is
           unique as the expiration time is calculated dynamically and increases
           monotonically.
           For blocks with absolute expiration times, the implementation
           MUST ensure that the expiration time is modified when the record
           data changes. For example. the expiration time may be increased
           by a single microsecond.
         </t>
       </section>
       <section anchor="security_abuse" numbered="true" toc="default">
         <name>Abuse mitigation</name>
         <t>
           GNS names are UTF-8 strings. Consequently, GNS faces similar issues
           with respect to name spoofing as DNS does for internationalized
           domain names.
           In DNS, attackers may register similar sounding or looking
           names (see above) in order to execute phishing attacks.
           GNS zone administrators must take into account this attack vector and
           incorporate rules in order to mitigate it.
         </t>
         <t>
           Further, DNS can be used to combat illegal content on the internet
           by having the respective domains seized by authorities.
           However, the same mechanisms can also be abused in order to impose
           state censorship, which ist one of the motivations behind GNS.
           Hence, such a seizure is, by design, difficult to impossible in GNS.
           In particular, GNS does not support WHOIS (<xref target="RFC3912" />).
         </t>
       </section>
       <section anchor="security_keymanagement" numbered="true" toc="default">
         <name>Zone management</name>
         <t>
           In GNS, zone administrators need to manage and protect their zone
           keys. Once a zone key is lost it cannot be recovered. Once it is
           compromised it cannot be revoked (unless a revocation message was
           pre-calculated and is still available).
           Zone administrators, and for GNS this includes end-users, are
           required to responsibly and dilligently protect their cryptographic
           keys.  Offline signing is in principle possible, but GNS does not
           support separate zone signing and key-signing keys
           (as in <xref target="RFC6781" />) in order to provide usable security.
         </t>
         <t>
           Similarly, users are required to manage their local root zone.
           In order to ensure integrity and availability or names, users must
           ensure that their local root zone information is not compromised or
           outdated.
           It can be expected that the processing of zone revocations and an
           initial root zone is provided with a GNS client implementation
           ("drop shipping").
           Extension and customization of the zone is at the full discretion of
           the user.
         </t>
       </section>
       <section anchor="security_dht" numbered="true" toc="default">
         <name>Impact of underlying DHT</name>
         <t>
           This document does not specifiy the properties of the underlying
           distributed hash table (DHT) which is required by any GNS
           implementation. For implementors, it is important to note that
           the properties of the DHT are directly inherited by the
           GNS implementation. This includes both security as well as
           other non-functional properties such as scalability and performance.
           Implementors should take great care when selecting or implementing
           a DHT for use in a GNS implementation.
           DHTs with strong security and performance guarantees exist
           <xref target="R5N"/>.
           It should also be taken into consideration that GNS implementations
           which build upon different DHT overlays are unlikely to be
           interoperable with each other.
         </t>
       </section>
       <section anchor="security_rev" numbered="true" toc="default">
         <name>Revocations</name>
         <t>
           Zone administrators are advised to pre-generate zone revocations
           and securely store the revocation information in case the zone
           key is lost, compromised or replaced in the furture.
           Pre-calculated revocations may become invalid due to expirations
           or protocol changes such as epoch adjustments.
           Consequently, implementors and users must make precautions in order
           to manage revocations accordingly.
         </t>
         <t>
           Revocation payloads do NOT include a 'new' key for key replacement.
           Inclusion of such a key would have two major disadvantages:
         </t>
         <t>
           If revocation is used after a private key was compromised,
           allowing key replacement would be dangerous: if an
           adversary took over the private key, the adversary could then
           broadcast a revocation with a key replacement. For the replacement,
           the compromised owner would have no chance to issue even a
           revocation. Thus, allowing a revocation message to replace a private
           key makes dealing with key compromise situations worse.
         </t>
         <t>
           Sometimes, key revocations are used with the objective of changing
           cryptosystems. Migration to another cryptosystem by replacing keys
           via a revocation message would only be secure as long as both
           cryptosystems are still secure against forgery. Such a planned,
           non-emergency migration to another cryptosystem should be done by
           running zones for both ciphersystems in parallel for a while. The
           migration would conclude by revoking the legacy zone key only once
           it is deemed no longer secure, and hopefully after most users have
           migrated to the replacement.
         </t>
       </section>
     </section>
     <section anchor="gana" numbered="true" toc="default">
       <name>GANA Considerations</name>
       <t>
         GANA <xref target="GANA" />
         is requested to create an "GNU Name System Record Types" registry.
         The registry shall record for each entry:
       </t>
       <ul>
         <li>Name: The name of the record type (case-insensitive ASCII
           string, restricted to alphanumeric characters</li>
         <li>Number: 32-bit, above 65535</li>
         <li>Comment: Optionally, a brief English text describing the purpose of
           the record type (in UTF-8)</li>
         <li>Contact: Optionally, the contact information of a person to contact for
           further information</li>
         <li>References: Optionally, references describing the record type
           (such as an RFC)</li>
       </ul>
       <t>
         The registration policy for this sub-registry is "First Come First
         Served", as described in <xref target="RFC8126"/>.
         GANA is requested to populate this registry as follows:
       </t>
       <figure anchor="figure_rrtypenums">
         <artwork name="" type="" align="left" alt=""><![CDATA[
Number | Name    | Contact | References | Description
-------+---------+---------+------------+-------------------------
65536  | PKEY    | N/A     | [This.I-D] | GNS zone delegation
65537  | NICK    | N/A     | [This.I-D] | GNS zone nickname
65538  | LEHO    | N/A     | [This.I-D] | GNS legacy hostname
65539  | VPN     | N/A     | [This.I-D] | VPN resolution
65540  | GNS2DNS | N/A     | [This.I-D] | Delegation to DNS
65541  | BOX     | N/A     | [This.I-D] | Boxed record
           ]]></artwork>
       </figure>
       <t>
         GANA is requested to amend the "GNUnet Signature Purpose" registry
         as follows:
       </t>
       <figure anchor="figure_purposenums">
         <artwork name="" type="" align="left" alt=""><![CDATA[
Purpose | Name            | References | Description
--------+-----------------+------------+--------------------------
  3     | GNS_REVOCATION  | [This.I-D] | GNS zone key revocation
 15     | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature
           ]]></artwork>
       </figure>
     </section>
     <!-- gana -->
     <section>
       <name>Test Vectors</name>
       <t>
         The following represents a test vector for a record set with a DNS
         record of type "A" as well as a GNS record of type "PKEY"
         under the label "test".
       </t>
       <artwork name="" type="" align="left" alt="">
         <![CDATA[
Zone private key (d, little-endian scalar):
3015471ecb45455b5e9df50ff416b3d53aa6db6cafec858449f788142d091d41

Zone public key (zk):
bf06e687a291a509b6326bb6394dd6ed3ff9e5eb78ea5752ed0eba0807023a33

Label: test
RRCOUNT: 2

Record #0
EXPIRATION: 1590482415557079
DATA_SIZE: 4
TYPE: 1
FLAGS: 0
DATA:
01020304

Record #1
EXPIRATION: 1590482415557079
DATA_SIZE: 32
TYPE: 65536
FLAGS: 2
DATA:
814fbb06b17f4ecf
d098700619179f9d
4aef24465bd6958a
e4ed01cd024b1856

RDATA:
0005a6890b6699d7
0000000400000001
0000000001020304
0005a6890b6699d7
0000002000010000
00000002814fbb06
b17f4ecfd0987006
19179f9d4aef2446
5bd6958ae4ed01cd
024b185600000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000

BDATA:
9f471611a5c06fc2
c9ad33f642dd315c
f8fc675aed23e8a1
d19a5bad657557fe
6e1d50709860593e
5376c30f6f22daac
5293986b7444476d
b8f289f5537da168
dc81cba256d8401b
642dbe6a24346e11
9148ade8acb4d5e5
cef5eb5ad1e3b95d
d143123d387b8df0
ba4e2d75a9eb94a4
f3250b975fee90e9
558bb9e1e009ca46
b7a066dd

RRBLOCK:
08180a871b910ade
a1125a1030d0f269
069e5731c90ad0d0
cfa10bf61b3f0c79
0833b515d4c746e6
4a7261947bfb6429
21200bb97a96292d
6abefab1197f7e4e
b399c628a71d3627
d64a2bd66080f64d
91c0120ab14601d8
18de23c8da82b80b
000000940000000f
0005a6890b6699d7
9f471611a5c06fc2
c9ad33f642dd315c
f8fc675aed23e8a1
d19a5bad657557fe
6e1d50709860593e
5376c30f6f22daac
5293986b7444476d
b8f289f5537da168
dc81cba256d8401b
642dbe6a24346e11
9148ade8acb4d5e5
cef5eb5ad1e3b95d
d143123d387b8df0
ba4e2d75a9eb94a4
f3250b975fee90e9
558bb9e1e009ca46
b7a066dd
           ]]>
       </artwork>
       <t>
         The following is an example revocation for a zone:
       </t>
       <artwork name="" type="" align="left" alt="">
         <![CDATA[
Zone private key (d, little-endian scalar):
90ea2a95cb9ef482b45817dc45b805cae00f387022a065a3674f41ad15173c63

Zone public key (zk):
4ac1e51d9a585a9ad9fb0dfac2be100aee83f0cc79c4c5ea8f3eb8afd9092fa5

Difficulty (5 base difficulty + 2 epochs): 7

Proof:
0005a5fd368978f4
0000395d1827c000
e23f657bc47ec853
e23f657bc47ec9d8
e23f657bc47ecaec
e23f657bc47ecb29
e23f657bc47ecc00
e23f657bc47ecc79
e23f657bc47ece83
e23f657bc47ecfc6
e23f657bc47ecfc8
e23f657bc47ecfd5
e23f657bc47ed02b
e23f657bc47ed03b
e23f657bc47ed0ff
e23f657bc47ed241
e23f657bc47ed264
e23f657bc47ed2e5
e23f657bc47ed343
e23f657bc47ed348
e23f657bc47ed45e
e23f657bc47ed480
e23f657bc47ed49a
e23f657bc47ed564
e23f657bc47ed565
e23f657bc47ed5b6
e23f657bc47ed5de
e23f657bc47ed5e0
e23f657bc47ed77f
e23f657bc47ed800
e23f657bc47ed80c
e23f657bc47ed817
e23f657bc47ed82c
e23f657bc47ed8a6
0396020c831a5405
cee6c38842209191
c8db799dbe81e0dc
f6dbd4f91c257ae2
0079e7fd1cd31cc2
4cd9a52831d5ec30
f10e22e5a6dd9065
18746cfce2095610
4ac1e51d9a585a9a
d9fb0dfac2be100a
ee83f0cc79c4c5ea
8f3eb8afd9092fa5
         ]]>
       </artwork>
     </section>
   </middle>
   <back>
     <references>
       <name>Normative References</name>

       &RFC1034;
       &RFC1035;
       &RFC2782;
       &RFC2119;
       &RFC3629;
       &RFC3686;
       &RFC3826;
       &RFC3912;
       &RFC5869;
       &RFC5890;
       &RFC5891;
       &RFC6781;
       &RFC6895;
       &RFC6979;
       &RFC7748;
       &RFC8032;
       &RFC8126;

       <reference anchor="GANA" target="https://gana.gnunet.org/">
         <front>
           <title>GNUnet Assigned Numbers Authority (GANA)</title>
           <author><organization>GNUnet e.V.</organization>
           </author>
           <date month="April" year="2020" />
         </front>
       </reference>

       <reference anchor="GNS" target="https://doi.org/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 year="2014"/>
         </front>
       </reference>
      <reference anchor="R5N" target="https://doi.org/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>
           <date year="2011"/>
         </front>
       </reference>


       <reference anchor="Argon2" target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/">
         <front>
           <title>The memory-hard Argon2 password hash and proof-of-work function</title>
          <author initials="A." surname="Biryukov" fullname="Alex Biryukov">
            <organization>University of Luxembourg</organization>
          </author>

          <author initials="D." surname="Dinu" fullname="Daniel Dinu">
            <organization>University of Luxembourg</organization>
          </author>

          <author initials="D." surname="Khovratovich"
            fullname="Dmitry Khovratovich">
            <organization>ABDK Consulting</organization>
          </author>
          <author initials="S." surname="Josefsson"
            fullname="Simon Josefsson">
            <organization>SJD AB</organization>
          </author>
           <date year="2020" month="March"/>
           <abstract>
             <t>
               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>
       </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"/>
           <abstract>
             <t>
               This recommendation defines five confidentiality modes of operation for use with an underlying symmetric key block cipher algorithm: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR). Used with an underlying block cipher algorithm that is approved in a Federal Information Processing Standard (FIPS), these modes can provide cryptographic protection for sensitive, but unclassified, computer data.
             </t>
           </abstract>
         </front>
       </reference>
       <reference anchor="GCM" target="https://doi.org/10.6028/NIST.SP.800-38D">
         <front>
           <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
          <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
            <organization>NIST</organization>
          </author>

           <date year="2007" month="November"/>
           <abstract>
             <t>
               This Recommendation specifies the Galois/Counter Mode (GCM), an algorithm for authenticated encryption with associated data, and its specialization, GMAC, for generating a message authentication code (MAC) on data that is not encrypted. GCM and GMAC are modes of operation for an underlying approved symmetric key block cipher.
             </t>
           </abstract>
         </front>
       </reference>

      <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9">
         <front>
           <title>High-Speed High-Security Signatures</title>
          <author initials="D." 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." surname="Yang"
            fullname="Bo-Yin Yang">
          <organization>Academia Sinica</organization>

          </author>
           <date year="2011"/>
         </front>
       </reference>

       <!--    <reference anchor="ISO20022">
         <front>
         <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
         <author>
         <organization>International Organization for Standardization</organization>
         <address>
         <uri>http://www.iso.ch</uri>
         </address>
         </author>
         <date month="May" year="2013"/>
         </front>
       </reference>-->
     </references>
     <!-- Change Log
       v00 2017-07-23  MS   Initial version
     -->
   </back>
 </rfc>