1 files changed, 145 insertions, 114 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9a58ceb..ed50901 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -37,13 +37,13 @@
 <?rfc sortrefs="yes" ?>
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-18" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-19" 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-18"/>
+  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-19"/>
   <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
    <organization>Fraunhofer AISEC</organization>
    <address>
@@ -335,111 +335,142 @@
    </section>
    <section anchor="overview" numbered="true" toc="default">
      <name>Overview</name>
-     <t>
-       GNS exhibits the three properties of a petname system:
-     </t>
-     <ol>
-       <li>
-         It provides global names through the concept of zone top-level
-         domains (zTLDs). As zones can be uniquely identified by their zone key
-         and are statistically unqiue, GNS names with a zTLD suffix are also
-         globally unique.
-       </li>
-       <li>
-         It provides memorable or "human-readable" names by enabling users to
-         configure local mappings from nicknames to zones.
-         Zone owners can publish their mappings
-         in order to enable namespace delegation and facilitate resolution of
-         memorable names.
-       </li>
-       <li>
-         It provides secure mapping from names to records as zone contents
-         are signed using blinded private keys and encrypted using derived
-         secret keys.
-       </li>
-     </ol>
-     <t>
-       In GNS, any user can create and manage one or more zones
-       (<xref target="zones"/>) as part of a zone master implementation.
-       The zone type determines the respective set of cryptographic operations
-       and the wire formats for encrypted data, public keys and signatures.
-       A zone can be populated with mappings from labels to resource records by
-       its owner (<xref target="rrecords"/>).
-       A label can be mapped to a delegation record which results in the
-       corresponding subdomain being delegated to another zone. Circular
-       delegations are explicitly allowed, including delegating a subdomain
-       to its immediate parent zone.  In
-       order to support (legacy) applications as well as to facilitate the use
-       of petnames, GNS defines auxiliary record types in addition to
-       supporting existing DNS records.
-     </t>
-     <t>
-       Zone contents are encrypted and signed
-       before being published in a key-value storage (<xref target="publish"/>)
-       as illustrated in <xref target="figure_arch_publish"/>.
-       In this process, unique zone identification is hidden from the network
-       through the use of key blinding.
-       Key blinding allows the creation of signatures for zone contents
-       using a blinded public/private key pair.
-       This blinding is realized using a deterministic key
-       derivation from
-       the original zone key and corresponding private key using record label values
-       as blinding factors.
-       Specifically, the zone owner can derive blinded private keys for each record
-       set published under a label, and a
-       resolver can derive the corresponding blinded public keys.
-       It is expected that GNS implementations use distributed or decentralized
-       storages such as distributed hash tables (DHT) in order to facilitate
-       availability within a network without the need for dedicated infrastructure.
-       Specification of such a distributed or decentralized storage is out of
-       scope of this document, but possible existing implementations include those
-       based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
-       <xref target="R5N" />.
-     </t>
-     <figure anchor="figure_arch_publish" title="An example diagram of two hosts publishing GNS zones.">
-       <artwork name="" type="" align="left" alt=""><![CDATA[
-        Local Host     |   Remote        |    Remote Host
-                       |   Storage       |
-                       |                 |
-                       |    +---------+  |
-                       |   /         /|  |
-              Publish  |  +---------+ |  |  Publish
-  +---------+ Records  |  |         | |  |  Records +---------+
-  |  Zone   |----------|->| Record  | |<-|----------|  Zone   |
-  | Master  |          |  | Storage | |  |          | Master  |
-  +---------+          |  |         |/   |          +---------+
-       A               |  +---------+    |               A
-       |               |                 |               |
-    +---------+        |                 |           +---------+
-   /   |     /|        |                 |          /    |    /|
-  +---------+ |        |                 |         +---------+ |
-  |         | |        |                 |         |         | |
-  |  Local  | |        |                 |         |  Local  | |
-  |  Zones  | |        |                 |         |  Zones  | |
-  |         |/         |                 |         |         |/
-  +---------+          |                 |         +---------+
-         ]]></artwork>
-     </figure>
-     <t>
-       Applications use the resolver to lookup GNS names.
-       Starting from a configurable start zone, names are resolved by following zone
-       delegations recursively as illustrated in <xref target="figure_arch_resolv"/>.
-       For each label in a name, the recursive GNS resolver
-       fetches the respective record from the storage layer (<xref target="resolution"/>).
-       Without knowledge of the label values and the zone keys, the
-       different derived keys are unlinkable both to the original zone key and to each
-       other.
-       This prevents zone enumeration (except via impractical online brute
-       force attacks) and requires knowledge
-       of both the zone key and the label to confirm affiliation of a
-       query or the corresponding encrypted record set with a
-       specific zone. At the same time, the blinded zone key provides
-       resolvers
-       with the ability to verify the integrity of the published information
-       without disclosing the originating zone.
-     </t>
-     <figure anchor="figure_arch_resolv" title="High-level view of the GNS resolution process.">
-       <artwork name="" type="" align="left" alt=""><![CDATA[
+       <t>
+         GNS exhibits the three properties that are commonly used to describe
+         a petname system:
+       </t>
+       <ol>
+         <li>
+           Global names through the concept of zone top-level
+           domains (zTLDs): As zones can be uniquely identified by their zone key
+           and are statistically unique, zTLDs are globally unique mappings to zones.
+           Consequently, GNS names with a zTLD suffix are also globally unique.
+           Global GNS names are not human-readable.
+         </li>
+         <li>
+           Memorable petnames for zones:
+           Users can configure local petnames for zones.
+           The petnames serve as zTLD monikers in order to support human-readable
+           names.
+           The petnames may also be published in order to delegate namespaces
+           of zones.
+         </li>
+         <li>
+           A secure mapping from names to records:
+           GNS allows zone owners to map petnames to resource records or to
+           delegate authority of the petname to other zones and publish this
+           information.
+           The mappings are signed and encrypted using keys derived from local
+           labels.
+           When names are resolved, resource records including delegations can
+           be verified by the implementation.
+         </li>
+       </ol>
+       <t>
+         It follows from the above that GNS does not support names which are
+         simultaneously global, secure and human-readable.
+         Instead, names are either global and not human-readable or not globally
+         unique and human-readable.
+         An example for a global name pointing to the record "example" in
+         a zone is:
+       </t>
+       <sourcecode>
+example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
+       </sourcecode>
+       <t>
+         Now consider the petname "pet" for the example zone
+         of the name above.
+         The following name would point to the same record as the
+         globally unique name above but it is only valid locally:
+       </t>
+       <sourcecode>
+example.pet
+       </sourcecode>
+       <t>
+         The delegation of petnames and subsequent resolution of delegation
+         builds on ideas from the Simple Distributed Security Infrastructure
+         <xref target="SDSI" />.
+         In GNS, any user can create and manage one or more zones
+         (<xref target="zones"/>) as part of a zone master implementation.
+         The zone type determines the respective set of cryptographic operations
+         and the wire formats for encrypted data, public keys and signatures.
+         A zone can be populated with mappings from labels to resource records by
+         its owner (<xref target="rrecords"/>).
+         A label can be mapped to a delegation record which results in the
+         corresponding subdomain being delegated to another zone. Circular
+         delegations are explicitly allowed, including delegating a subdomain
+         to its immediate parent zone.  In
+         order to support (legacy) applications as well as to facilitate the use
+         of petnames, GNS defines auxiliary record types in addition to
+         supporting existing DNS records.
+       </t>
+       <t>
+         Zone contents are encrypted and signed
+         before being published in a key-value storage (<xref target="publish"/>)
+         as illustrated in <xref target="figure_arch_publish"/>.
+         In this process, unique zone identification is hidden from the network
+         through the use of key blinding.
+         Key blinding allows the creation of signatures for zone contents
+         using a blinded public/private key pair.
+         This blinding is realized using a deterministic key
+         derivation from
+         the original zone key and corresponding private key using record label values
+         as blinding factors.
+         Specifically, the zone owner can derive blinded private keys for each record
+         set published under a label, and a
+         resolver can derive the corresponding blinded public keys.
+         It is expected that GNS implementations use distributed or decentralized
+         storages such as distributed hash tables (DHT) in order to facilitate
+         availability within a network without the need for dedicated infrastructure.
+         Specification of such a distributed or decentralized storage is out of
+         scope of this document, but possible existing implementations include those
+         based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
+         <xref target="R5N" />.
+       </t>
+       <figure anchor="figure_arch_publish" title="An example diagram of two hosts publishing GNS zones.">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+       Local Host     |   Remote        |    Remote Host
+                      |   Storage       |
+                      |                 |
+                      |    +---------+  |
+                      |   /         /|  |
+             Publish  |  +---------+ |  |  Publish
+ +---------+ Records  |  |         | |  |  Records +---------+
+ |  Zone   |----------|->| Record  | |<-|----------|  Zone   |
+ | Master  |          |  | Storage | |  |          | Master  |
+ +---------+          |  |         |/   |          +---------+
+      A               |  +---------+    |               A
+      |               |                 |               |
+   +---------+        |                 |           +---------+
+  /   |     /|        |                 |          /    |    /|
+ +---------+ |        |                 |         +---------+ |
+ |         | |        |                 |         |         | |
+ |  Local  | |        |                 |         |  Local  | |
+ |  Zones  | |        |                 |         |  Zones  | |
+ |         |/         |                 |         |         |/
+ +---------+          |                 |         +---------+
+           ]]></artwork>
+       </figure>
+       <t>
+         Applications use the resolver to lookup GNS names.
+         Starting from a configurable start zone, names are resolved by following zone
+         delegations recursively as illustrated in <xref target="figure_arch_resolv"/>.
+         For each label in a name, the recursive GNS resolver
+         fetches the respective record from the storage layer (<xref target="resolution"/>).
+         Without knowledge of the label values and the zone keys, the
+         different derived keys are unlinkable both to the original zone key and to each
+         other.
+         This prevents zone enumeration (except via impractical online brute
+         force attacks) and requires knowledge
+         of both the zone key and the label to confirm affiliation of a
+         query or the corresponding encrypted record set with a
+         specific zone. At the same time, the blinded zone key provides
+         resolvers
+         with the ability to verify the integrity of the published information
+         without disclosing the originating zone.
+       </t>
+       <figure anchor="figure_arch_resolv" title="High-level view of the GNS resolution process.">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
                            Local Host           |   Remote
                                                 |   Storage
                                                 |
@@ -461,13 +492,13 @@
                      |  Zones  | |              |
                      |         |/               |
                      +---------+                |
-         ]]></artwork>
-     </figure>
-     <t>
-       In the remainder of this document, the "implementer" refers to the developer building
-       a GNS implementation including the resolver, zone master, and
-       supporting configuration such as start zones (<xref target="governance"/>).
-     </t>
+           ]]></artwork>
+       </figure>
+       <t>
+         In the remainder of this document, the "implementer" refers to the developer building
+         a GNS implementation including the resolver, zone master, and
+         supporting configuration such as start zones (<xref target="governance"/>).
+       </t>
    </section>
    <section anchor="zones" numbered="true" toc="default">
      <name>Zones</name>