path: root/draft-schanzen-gns.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.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-00" 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 Specification
  </title>
  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-00"/>
  <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>schanzen@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>

  <date day="23" month="July" year="2019"/>
  <!-- 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 (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.
     </t>
     <t>

     </t>
   </section>
   <section anchor="zones" numbered="true" toc="default">
     <name>Zones</name>
     <t>
       A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
       where d is the private key and zk the corresponding public key.
       GNS employs the curve parameters of the twisted edwards representation
       of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
       with the ECDSA scheme (<xref target="RFC6979" />).
       In the following, we use the following naming convention for our
       cryptographic primitives:
     </t>
     <dl>
       <dt>d</dt>
       <dd>
         is a 256-bit ECDSA private key.
         In GNS, records are signed using a key derived from "d" as described in
         <xref target="publish" />.
       </dd>
       <dt>p</dt>
       <dd>
         is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
         2^255 - 19.
       </dd>
       <dt>B</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>
       <dt>zk</dt>
       <dd>
         is the ECDSA public key corresponding to d. It is defined in
         <xref target="RFC6979" /> as the curve point d*B where B is the group
         generator of the elliptic curve.
         The public key is used to uniquely identify a GNS zone and is referred to
         as the "zone key".
       </dd>
     </dl>
   </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 creating a zone
       key pair. 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" />).
       </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 |   /    | 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>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 anchor="gnsrecords_numbers" numbered="true" toc="default">
       <name>Record Types</name>
       <t>
         GNS-specific record type numbers start at 2^16, i.e. after the record
         type numbers for DNS. The following is a list of defined and reserved
         record types in GNS:
       </t>
       <figure anchor="figure_rrtypenums">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           Number                | Type            | Comment
           ------------------------------------------------------------
           65536                 | PKEY            | GNS delegation
           65537                 | NICK            | GNS zone nickname
           65538                 | LEHO            | Legacy hostname
           65539                 | VPN             | Virtual private network
           65540                 | GNS2DNS         | DNS delegation
           65541                 | BOX             | Boxed record (for TLSA/SRV)
           65542 up to 2^24 - 1  | -               | Reserved
           2^24 up to 2^32 - 1   | -               | Unassigned / For private use
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
     </section>
     <section anchor="gnsrecords_pkey" numbered="true" toc="default">
       <name>PKEY</name>
       <t>In GNS, a delegation of a label to a zone is represented through a PKEY
         record. 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>
     </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. (all 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
         PKEY <xref target="gnsrecords_pkey" /> record containing this zone's
         public zone key.
         This record SHOULD only be stored under the empty label "@".
         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 inlcude 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.foo.gnu" will be stored in the record set of
         "foo.gnu" 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
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  TODO                  DNS NAME                   |
           /                                               /
           /                                               /
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                 DNS SERVER NAME               |
           /      TODO                                         /
           /                                               /
           |                                               |
           +-----------------------------------------------+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
     </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>Key Derivations</name>
       <t>
         Given a label, the DHT key "q" is derived as follows:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
         PRK_h := HKDF-Extract ("key-derivation", zk)
         h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
         d_h := h * d mod L
         zk_h := h mod L * zk
         q := SHA512 (zk_h)
         ]]></artwork>
       <t>
         We use a hash-based key derivation function (HKDF) as defined in
         <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
         phase and HMAC-SHA256 for the expansion phase.
       </t>
       <dl>
         <dt>PRK_h</dt>
         <dd>
           is key material retrieved using an HKDF using the string
           "key-derivation" as salt and the public zone key "zk" as initial
           keying material.
         </dd>
         <dt>h</dt>
         <dd>
           is the 512-bit HKDF expansion result. The expansion info input is a
           concatenation of the label and string "gns".
         </dd>
         <dt>d</dt>
         <dd>
           is the 256-bit private zone key as defined in <xref target="zones" />.
         </dd>
         <dt>label</dt>
         <dd>
           is a UTF-8 string under which the resource records are published.
         </dd>
         <dt>d_h</dt>
         <dd>
           is a 256-bit private key derived from the "d" using the
           keying material "h".
         </dd>
         <dt>zk_h</dt>
         <dd>
           is a 256-bit public key derived from the zone key "zk" using the
           keying material "h".
         </dd>
         <dt>L</dt>
         <dd>
           is the prime-order subgroup as defined in <xref target="zones" />.
         </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 public key "zk_h" corresponding to the
           derived private key "d_h".
         </dd>
       </dl>
       <t>
         We point out that the multiplication of "zk" with "h" is a point multiplication,
         while the multiplication of "d" with "h" is a scalar multiplication.
       </t>
     </section>
     <section anchor="wire" numbered="true" toc="default">
       <name>Resource Records Block</name>
       <t>
         GNS records are grouped by their labels and published as a single
         block in the DHT.
         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                   |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                  PUBLIC KEY                   |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |         SIZE          |       PURPOSE         |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                   EXPIRATION                  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                    BDATA                      /
           /                                               /
           /                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>where:</t>
       <dl>
         <dt>SIGNATURE</dt>
         <dd>
           A 512-bit ECDSA deterministic signature compliant with
           <xref target="RFC6979" />. The signature is computed over the data
           following the PUBLIC KEY field.
           The signature is created using the derived private key "d_h" (see
           <xref target="publish" />).
         </dd>
         <dt>PUBLIC KEY</dt>
         <dd>
           is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
           wire format of this value is defined in <xref target="RFC8032" />,
           Section 5.1.5.
         </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 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 PKEY record type
           are never padded. Note that a record set with a PKEY record MUST NOT
           contain other records.
         </dd>

       </dl>
       <t>
         The symmetric keys and initialization vectors are derived from the
         record label and the zone key "zk". For decryption of the resource
         records block payload, the key material "K" and initialization vector
         "IV" for the symmetric cipher are derived as follows:
       </t>
       <!-- OLD VERSION
       PRK_kiv := HKDF-Extract (zk, label)
       K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
       IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
       -->
       <artwork name="" type="" align="left" alt=""><![CDATA[
         PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
         PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
         K := HKDF-Expand (PRK_k, label, 512 / 8);
         IV := HKDF-Expand (PRK_iv, label, 256 / 8)
         ]]></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 64 octets (512 bit) for the symmetric
         keys and 32 octets (256 bit) for the initialization vectors.
         We divide the resulting keying material "K" into a 256-bit AES
         <xref target="RFC3826" /> key
         and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
       </t>
       <figure anchor="figure_hkdf_keys">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                    AES KEY                    |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                  TWOFISH KEY                  |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         Similarly, we divide "IV" into a 128-bit initialization vector
         and a 128-bit initialization vector:
       </t>
       <figure anchor="figure_hkdf_ivs">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                    AES IV                     |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                  TWOFISH IV                   |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>

       <t>
         The keys and IVs are used for a CFB128-AES-256 and
         CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
         Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
         RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
         BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
         ]]></artwork>
     </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>
       TODO
     </t>
     <section anchor="entry_zone" numbered="true" toc="default">
       <name>Entry Zone</name>
       <t>
         There are three sources from which the entry zone can be determined
         which MUST be queried in this order:
       </t>
       <ol>
         <li>Check if top-level domain maps to a local zone key.</li>
         <li>Check if top-level domain maps to a local zone name.</li>
         <li>Check if a configuration exists that maps a prefix to an
           external zone key.</li>
       </ol>
       <t>
         If the TLD is a Base32-encoded public zone key "zk", the entry
         zone of the resolution process is implicitly given by the name.
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
         Example name: www.example.<Base32(zk)>
         => Entry zone: zk
         => Name to resolve from entry zone: www.example
           ]]></artwork>

         <t>
           Each local zone is associated with a single GNS label. If this label
           is the top-level domain (TLD) of the name to resolve, resolution
           MUST start from this local zone.
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
           Example name: www.example.gnu
           Local zones:
           fr = (d0,zk0)
           gnu = (d1,zk1)
           com = (d2,zk2)
           ...
           => Entry zone: zk1
           => Name to resolve from entry zone: www.example
           ]]></artwork>

         <t>
           If no matching local zone for the TLD is found, external prefix to
           zone mappings are checked. External prefix to zone key mapping
           SHOULD be configurable through the GNS implementation. A mapping
           has the form "prefix = public zone key".
           The prefix may consist of multiple GNS labels concatenated with a
           ".". If multiple prefixes match the name to resolve, the longest
           prefix is chosen. The prefix length of two results cannot be equal,
           as this would indicate a misconfiguration.
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
           Example name: www.example.gnu
           Local prefix mappings:
           gnu = zk0
           example.gnu = zk1
           example.com = zk2
           ...
           => Entry zone: zk1
           => Name to resolve from entry zone: www
           ]]></artwork>
       </section>
       <section anchor="record_retrieval" numbered="true" toc="default">
         <name>Record Retrieval</name>
         <t>
           In order to resolve a name in GNS, a type MAY be given.
           However, filtering of record results according to type is done after
           the resource record set is retrieved.
         </t>
         <t>
           In each step of the recursive name resolution, there is an
           authoritative zone zk and a name to resolve which may be empty.
           Initially, the authoritative zone is the entry zone. If the name
           is empty, it is interpreted as the apex label "@".
         </t>
         <ol>
           <li>Extract the right-most label from the name to look up.</li>
           <li>Calculate q using the label and zk.</li>
           <li>Perform a DHT query GET(q) to retrieve the RRBLOCK.</li>
           <li>Verify the RRBLOCK and decrypt the BDATA contained in it.</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.
         </t>
       </section>
       <section anchor="record_processing" numbered="true" toc="default">
         <name>Record Processing</name>
         <t>
           If the remainder of the name to resolve is not empty, the records
           result MUST consist of a single PKEY record or one or more GNS2DNS records.
           The recursion is then continued with the PKEY record value as new
           authoritative zone or using the specified DNS server(s) as defined
           int the following.
         </t>
         <t>
           If the remainder of the name to resolve is empty but 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. If the record type to be resolved is
           PKEY, the PKEY record set is returned and the resolution is concluded.
         </t>
         <t>
           If the remainder of the name to resolve is empty and the records set
           does not consist of a PKEY record, the record set is the result and
           the resolution is concluded.
         </t>
         <section anchor="pkey_processing" numbered="true" toc="default">
           <name>PKEY</name>
           <t>
             When a resolver encounters a PKEY record, resolution continues
             recursively with the remainder of the name in the newly discovered
             GNS zone as defined in <xref target="entry_zone" />.
           </t>
         </section>
         <section anchor="gns2dns_processing" numbered="true" toc="default">
           <name>GNS2DNS</name>
           <t>
             When a resolver encounters a GNS2DNS record it is expected that it first
             resolves the IP(s) of the DNS specified 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.
             Then, the DNS name from the GNS2DNS record is appended
             to the remainder of the name to be resolved, and
             resolved by querying the name server(s).
             Multiple
             GNS2DNS records may be stored under the same label, in which case the
             resolver MUST try all of them.  However, if multiple GNS2DNS records
             are present, the DNS name MUST be identical for all of them.
           </t>
         </section>
         <section anchor="cname_processing" numbered="true" toc="default">
           <name>CNAME</name>
           <t>
             Upon encountering a CNAME record, the resolver must continue the
             resolution using the CNAME unless the queried record type is a
             CNAME and we have reached the leftmost label of the name.
             Resolution may continue either in GNS if GNS is authoritative of
             the respective TLD or if the TLD is a relative zone indicator ("+")
             and we have found the CNAME in a GNS zone.
             Otherwise, the resolver should continue the resolution recursively
             through DNS.
           </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.
             In order to prevent infinite loops, the resolver should
             implement loop detections or limit the recursive resolution of
             CNAMEs using an upper bound.
           </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 it 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>
             If the queried record type is either A or AAAA and the retrieved
             record set contains at least one VPN record, the resolver must 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.
             No result is returned if the resolver implementation does not
             support any of the tunnnels provided in the VPN records.
           </t>
         </section>
       </section>
     </section>
     <section anchor="revocation" numbered="true" toc="default">
       <name>Zone Revocation</name>
       <t>
         In order to revoke a zone, a signed revocation object must 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.
         The revocation message may be calculated ahead of time.
       </t>
       <t>
         A revocation message is defined as follows:
       </t>
     </section>
     <section anchor="security" numbered="true" toc="default">
       <name>Security Considerations</name>
       <t>
         TODO
       </t>
     </section>
     <section anchor="iana" numbered="true" toc="default">
       <name>IANA Considerations</name>
       <t>
         This will be fun
       </t>
     </section>
     <!-- iana -->
     <section>
       <name>Test Vectors</name>
       <t>
         The following represents a test vector for a record of type MX with
         a priority of 10 and the mail hostname mail.example.com.
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
         label := "mail"

         d :=
         71199f7b287cc77a
         0d21b5e40a77cb1d
         f89333903b284fe8
         1878bf47f3b39da0

         zk (public zone key) :=
         dff911496d025d7e
         0885c03d19153e99
         4f213f23ea719eca
         17fc32dc410e082e

         h :=
         2af3275a9cf90e54
         f2dbf7930be76fb9
         5e7c80b1416f8ca6
         dc50ce8e1fb759b9
         fedcdcf546c17e9b
         4c4f23632855c053
         6668e9f684f4dc33
         6d656b27392b0fee

         d_h :=
         01fb61f482c17633
         77611c4c2509e0f3
         81b0e7e4405c10bd
         0017c802f7d32e18

         q (query key) :=
         6fce4deddc5ad681
         f4e29a3310767e3b
         8b38bc1b276ce2ba
         9bf1b49df1e120a3
         20ecc9dffb68416f
         11729ad878ad3bdf
         d0b4db2626b620d7
         8e0604e4393c66a3

         AES_KEY :=
         afefd21a087a150d
         6757741a4eda02a5
         65df7ca86ba44b21
         3f8106c0071eaf01

         AES_IV :=
         a808b929bc9fad7a
         686bbe3432bed77a

         TWOFISH_KEY :=
         c9d0089df01d0bf4
         e4c8db4b2ccc7328
         3425e8a811ae59d2
         99e2747285d2a479

         TWOFISH_IV :=
         071be189a9d236f9
         b4a3654bb8c281d4

         RDATA :=
         0000000100059412 RR COUNT | EXPIRA-
         09ddea0f00000014  -TION    | DATA SIZE (20)
         0000000f00000000 TYPE (15=MX) | FLAGS (0)
         000a046d61696c07 Priority (10) |4 | mail | 7
         6578616d706c6503 example | 3
         636f6d0000000000 com | \0 | Followed by
         0000000000000000 24 bytes of padding to 2^6
         0000000000000000
         00000000


         RRBLOCK :=
         055cb070e05fe6de SIGNATURE
         ad694a50e5b4dedd
         b9fdcbdbae004f65
         afc99ba9c5a3bb54
         07e731a34680ee33
         ae0de7bfeda7d2b7
         8c6b854a008b1b54
         10df4f39f5ba9f46____________
         8cb514a56c0eaae0 zk_h
         56745158a63ee4dd
         76853cb9545e326e
         76d7fa920f818291____________
         000000540000000f SIZE (=84) | PURPOSE (=15)
         0005941209dde25b EXPIRATION
         d99d08fa123da096 BDATA
         66c2fb9bf020a85d
         e80818d0a84059a8
         5eee901a66459e5e
         3d1a10b29a5b8354
         1b58636781166b9a
         642920eee8e7a65a
         001fd19a6406a721
         713f0a0d
         ]]></artwork>

     </section>
   </middle>
   <back>
     <references>
       <name>Normative References</name>
       <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748"><front><title>Elliptic Curves for Security</title><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><author initials="M." surname="Hamburg" fullname="M. Hamburg"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2016" month="January"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="RFC" value="7748"/><seriesInfo name="DOI" value="10.17487/RFC7748"/></reference>
       <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826"><front><title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title><author initials="U." surname="Blumenthal" fullname="U. Blumenthal"><organization/></author><author initials="F." surname="Maino" fullname="F. Maino"><organization/></author><author initials="K." surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date year="2004" month="June"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture.  The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
       <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
       <reference anchor="RFC5891" target="https://www.rfc-editor.org/info/rfc5891"><front><title>Internationalized Domain Names in Applications (IDNA): Protocol</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is the revised protocol definition for Internationalized Domain Names (IDNs).  The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents.  This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself.  IDNA is only meant for processing domain names, not free text.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5891"/><seriesInfo name="DOI" value="10.17487/RFC5891"/></reference>
       <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
         <front>
           <title>
             HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
           </title>
           <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
             <organization/>
           </author>
           <author initials="P." surname="Eronen" fullname="P. Eronen">
             <organization/>
           </author>
           <date year="2010" month="May"/>
           <abstract>
             <t>
               This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
             </t>
           </abstract>
         </front>
         <seriesInfo name="RFC" value="5869"/>
         <seriesInfo name="DOI" value="10.17487/RFC5869"/>
       </reference>
       <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><seriesInfo name="DOI" value="10.17487/RFC3629"/>
       </reference>
       <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
         <front>
           <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
           <author initials="S." surname="Josefsson" fullname="S. Josefsson">
             <organization/>
           </author>
           <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
             <organization/>
           </author>
           <date year="2017" month="January"/>
           <abstract>
             <t>
               This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
             </t>
           </abstract>
         </front>
         <seriesInfo name="RFC" value="8032"/>
         <seriesInfo name="DOI" value="10.17487/RFC8032"/>
       </reference>
       <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013" month="April"/><abstract><t>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6895"/><seriesInfo name="DOI" value="10.17487/RFC6895"/></reference>
       <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"><front><title>Domain names - concepts and facilities</title><author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"><organization/></author><date year="1987" month="November"/><abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1034"/><seriesInfo name="DOI" value="10.17487/RFC1034"/></reference>
       <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
         <front>
           <title>Domain names - implementation and specification</title>
           <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
             <organization/>
           </author>
           <date year="1987" month="November"/>
           <abstract>
             <t>
               This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
             </t>
           </abstract>
         </front>
         <seriesInfo name="STD" value="13"/>
         <seriesInfo name="RFC" value="1035"/>
         <seriesInfo name="DOI" value="10.17487/RFC1035"/>
       </reference>
       <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
         <front>
           <title>
             Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
           </title>
           <author initials="T." surname="Pornin" fullname="T. Pornin">
             <organization/>
           </author>
           <date year="2013" month="August"/>
           <abstract>
             <t>
               This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
             </t>
           </abstract>
         </front>
         <seriesInfo name="RFC" value="6979"/>
         <seriesInfo name="DOI" value="10.17487/RFC6979"/>
       </reference>
       <reference anchor="TWOFISH">
         <front>
           <title>
             The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
           </title>
           <author initials="B." surname="Schneier" fullname="B. Schneier">
             <organization/>
           </author>
           <date year="1999" month="March"/>
         </front>
       </reference>
       <reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc2782">
         <front>
           <title>
             A DNS RR for specifying the location of services (DNS SRV)
           </title>
           <author initials="A." surname="Gulbrandsen" fullname="A. Gulbrandsen">
             <organization/>
           </author>
           <author initials="P." surname="Vixie" fullname="P. Vixie">
             <organization/>
           </author>
           <author initials="L." surname="Esibov" fullname="L. Esibov">
             <organization/>
           </author>
           <date year="2000" month="February"/>
           <abstract>
             <t>
               This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]
             </t>
           </abstract>
         </front>
         <seriesInfo name="RFC" value="2782"/>
         <seriesInfo name="DOI" value="10.17487/RFC2782"/>
       </reference>


       <!--    <reference anchor="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>