1 files changed, 89 insertions, 69 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 1ccb978..bf76096 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -183,7 +183,7 @@
          A GNS label is a label as defined in <xref target="RFC8499"/>.
          Within this document, labels are always assumed to be strings of
          UTF-8 characters <xref target="RFC8499"/> with a maximum length of
-         63 bytes. When hashed, labels MUST be canonicalized using
+         63 bytes.  When hashed, labels MUST be canonicalized using
          Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
        </dd>
        <dt>Name</dt>
@@ -195,26 +195,27 @@
        </dd>
        <dt>Top-Level Domain</dt>
        <dd>
-         A GNS Top-Level Domain is a GNS label and a Top-Level
-         Domain (TLD) as defined in <xref target="RFC8499"/>.
-         With the exception of Zone Top-Level Domains (see below),
-         GNS TLDs are part of the configuration of the local resolver
-         (see <xref target="governance"/>) and may not be globally unique.
+         The rightmost label in a GNS name is a GNS Top-Level Domain (TLD).
+         Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>),
+         GNS does not expect all users to use the same global root zone. Instead, 
+         with the exception of Zone Top-Level Domains (see below),
+         GNS TLDs are typically part of the configuration of the local resolver
+         (see <xref target="governance"/>), and may thus not be globally unique.
        </dd>
        <dt>Zone</dt>
        <dd>
          A GNS zone contains authoritative information (resource records).
-         A zone is uniquely identified by its zone key.
+         A zone is uniquely identified by its zone key.  Unlike DNS zones,
+         a GNS zone does not need to have a SOA record at its apex.
        </dd>
        <dt>Zone Type</dt>
        <dd>
-         The type of a GNS zone determines the format and type of the
-         zone key.
+         The type of a GNS zone determines the cipher system and binary encoding
+         format of the zone key, blinded zone keys, and signatures.
        </dd>
        <dt>Zone Key</dt>
        <dd>
          The zone key uniquely identifies a zone.
-         Its format and type depend on the associated zone type.
          The zone key is usually a public key of an asymmetric key pair.
        </dd>
        <dt>Blinded Zone Key</dt>
@@ -224,16 +225,18 @@
        </dd>
        <dt>Zone Owner</dt>
        <dd>
-         The owner of a GNS zone is the holder of the private key corresponding to
-         the respective zone key.
+         The owner of a GNS zone is the holder of the secret (typically a private key)
+         that (together with a label and a value to sign) allows the creation of zone
+         signatures that can be validated against the respective blinded zone key.
        </dd>
        <dt>Zone Top-Level Domain</dt>
        <dd>
-         A GNS Zone Top-Level Domain (zTLD) is a GNS name and a Top-Level
-         Domain (TLD) as defined in <xref target="RFC8499"/>.
-         It represents a sub-group of all TLDs and encodes the zone type and
+         A GNS Zone Top-Level Domain (zTLD) is a GNS label used as the
+         rightmost label in a GNS name which encodes a zone type and
          zone key of a zone.
          Due to the statistical uniqueness of zone keys, zTLDs are also globally unique.
+         A zTLD label can only be distinguished from ordinary TLD labels
+         by attempting to decode the label to a zone type and zone key.
        </dd>
        <dt>Resource Record</dt>
        <dd>
@@ -252,13 +255,17 @@
        Zones are uniquely identified by a zone key.
        Zone contents are signed using blinded private keys and
        encrypted using derived secret keys.
-       The zone type determines the respectice set of cryptographic functions.
+       The zone type determines the respective set of cryptographic operations
+       and the wire formats for encrypted data, public keys and signatures.
      </t>
      <t>
        A zone can be populated with mappings from labels to resource records by
        its owner (<xref target="rrecords"/>).
-       Labels can be delegated to other zones using delegation records and in
-       order to support (legacy) applications as well as facilitate the use
+       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 traditional DNS records.
      </t>
@@ -268,31 +275,35 @@
        (<xref target="publish"/>).
        In this process, unique zone identification is hidden from the network
        through the use of key blinding.
-       It allows the creation of signatures for zone contents
+       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.
-       Specifically, the zone owner can derive private keys for each record
+       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 public keys.
+       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 of servers.
+       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
+       scope of this document, but possible existing implementations include those
        based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
        <xref target="R5N" />.
      </t>
      <t>
        Names in GNS are domain names as defined in <xref target="RFC8499"/>.
-       Starting from a configurable root zone, names are resolved following zone
-       delegations which are recursively queried from the storage (<xref target="resolution"/>).
+       Starting from a configurable root zone, names are resolved by following zone
+       delegations. 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 key and to each
+       different derived keys are unlinkable both to the original zone key and to each
        other.
-       This prevents zone enumeration and requires knowledge
-       of both the zone key and the label to confirm affiliation with a
+       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
@@ -313,44 +324,44 @@
        It can be represented by a Zone Top-Level Domain (zTLD) string.
      </t>
      <t>
-       The zone type ztype is the unique zone type of the zone as registered
+       Each zone type (ztype) is assigned a unique 32-bit number when it is registered
        in the GNUnet Assigned Numbers Authority <xref target="GANA" />.
-       The zone type determines which cryptosystem is used for the
+       The ztype determines which cryptosystem is used for the
        asymmetric and symmetric key operations of the zone.
-       The zone type is identified by a 32-bit number.
-       It always corresponds to a resource record type number identifying a
-       delegation into a zone of this type.
+       The ztype number always corresponds to a resource record type
+       number identifying a delegation into a zone of this type. To
+       ensure that there are no conflicts with DNS record types, ztypes
+       are always assigned numeric values above 65535.
      </t>
      <t>
-       For any zone, d is the private key. zk is the zone key.
-       The specific formats depends on the zone type.
-       The creation of zone keys for the default zone types are specified in
+       For any zone, let d be the private key and zk the public zone key.
+       The specific wire format used depends on the ztype.
+       The creation of zone keys for the default ztypes are specified in
        <xref target="gnsrecords_delegation"/>.
-       New zone types may be specified in the future, for example if the
+       New ztypes may be specified in the future, for example if the
        cryptographic mechanisms used in this document are broken.
-       Any zone type MUST define the following set of cryptographic functions:
+       Any ztype MUST define the following set of cryptographic functions:
      </t>
      <dl>
-       <dt>Private-KeyGen() -> d</dt>
+       <dt>KeyGen() -> d, zk</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 zone key zk from a private key d.
+         is a function to generate a fresh private key d and
+         the corresponding public zone key zk.
        </dd>
        <dt>ZKDF-Private(d,label) -> d'</dt>
        <dd>
          is a zone key derivation function which blinds a private key d
          using label, resulting in another private key which
-         can be used to create cryptographic signatures.
+         can be used to create cryptographic signatures.  We note that
+         GNS only requires a signature to be created directly with
+         d to sign a revocation message for the zone key zk.
        </dd>
        <dt>ZKDF-Public(zk,label) -> zk'</dt>
        <dd>
          is a zone key derivation function which blinds a zone key zk
          using a label. zk and zk' must be unlinkable. Furthermore,
          blinding zk with different values for the label must result
-         in unlinkable different resulting values for zk'.
+         in unlinkable zk' values.
        </dd>
        <dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt>
        <dd>
@@ -367,17 +378,18 @@
          data based on key material derived from the zone key,
          a label, a nonce and an expiration.
        </dd>
-       <dt>Sign(d',message) -> signature</dt>
+       <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
        <dd>
-         is a function to sign encrypted record data using the (blinded) private
-         key d', yielding an unforgable cryptographic signature.
+         is a function to sign a message (typically encrypted record data) using the (blinded) private
+         key d (d'), yielding an unforgable cryptographic signature.
        </dd>
-       <dt>Verify(zk',message,signature) -> valid</dt>
+       <dt>Verify(zk,message,signature) -> boolean, Verify(zk',message,signature) -> boolean</dt>
        <dd>
          is a function to verify the signature was created by
-         the private key d' derived from d and a label if
-         zk' was derived from the corresponding zone key
-         zk := Public-Keygen(d) and same label.
+         the private key d (or derived key d') corresponding to 
+         the zone key zk (or derived zone key zk')
+         where d,zk := Keygen(). If deriviations were used, they
+         must have used the same label.
          The function returns a boolean value of "TRUE" if the signature is valid,
          and otherwise "FALSE".
        </dd>
@@ -902,15 +914,11 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        <dl>
          <dt>d</dt>
          <dd>
-           is a 256-bit ECDSA private key. The generation of the private
-           scalar as defined in Section 2.2. of <xref target="RFC6979" /> represents the Private-KeyGen() function.
+           is a 256-bit ECDSA private key. 
          </dd>
          <dt>zk</dt>
          <dd>
-           is the ECDSA zone key corresponding to d. Its generation is
-           defined in Section 2.2. of <xref target="RFC6979" /> as the curve point d*G where G
-           is the group generator of the elliptic curve.
-           This generation represents the Public-KeyGen(d) function.
+           is the ECDSA public zone key corresponding to d. 
          </dd>
          <dt>p</dt>
          <dd>
@@ -926,6 +934,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          <dd>
            is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
          </dd>
+         <dt>KeyGen()</dt>
+         <dd>The generation of the private
+           scalar d and the curve point zk := d*G (where G is the group generator
+           of the elliptic curve) as defined in Section 2.2. of 
+           <xref target="RFC6979" /> represents the KeyGen() function.
+         </dd>
        </dl>
        <t>
          The zone type and zone key of a PKEY are 32 + 4 bytes in length. This means that
@@ -1065,9 +1079,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
          <dl>
            <dt>d</dt>
            <dd>
-             is a 256-bit EdDSA private key. The generation as defined
-             in Section 3.2. of <xref target="RFC8032" /> and represents the Private-KeyGen()
-             function.
+             is a 256-bit EdDSA private key. 
            </dd>
            <dt>a</dt>
            <dd>
@@ -1076,12 +1088,10 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            </dd>
            <dt>zk</dt>
            <dd>
-             is the EdDSA public key corresponding to d. It is defined in
-             Section 3.2 of <xref target="RFC8032" /> 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 SHA-512 hash function.
-             This generation including the derivation of a represents the
-             Public-KeyGen(d) function.
+             is the EdDSA public key corresponding to d. It is defined 
+             as the curve point a*G where G is the
+             group generator of the elliptic curve
+             as defined in <xref target="ed25519" />.
            </dd>
            <dt>p</dt>
            <dd>
@@ -1097,6 +1107,16 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            <dd>
              is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
            </dd>
+           <dt>KeyGen()</dt>
+           <dd>
+             The generation of the private key d and the associated public
+             key zk := a*G where G is the
+             group generator of the elliptic curve and a is an integer
+             derived from d using the SHA-512 hash function 
+             as defined
+             in Section 3.2. of <xref target="RFC8032" /> represents the KeyGen()
+             function.
+            </dd>
          </dl>
          <t>
            The zone type and zone key of an EDKEY are 32 + 4 bytes in length. This means that