massive revision of zone type description

1 files changed, 481 insertions, 341 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 6769d75..1b08d16 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -134,61 +134,60 @@
    <section anchor="zones" numbered="true" toc="default">
      <name>Zones</name>
      <t>
-       A zone in GNS is defined by a public/private key pair (d,zk),
-       where d is the private key and zk the corresponding public key.
+       A zone in GNS is defined by a zone type "ztype" that identifies
+       a cryptosystem and a public/private key pair "(d,zk)",
+       where "d" is the private key and "zk" the corresponding public key
+       in the public key cipher identified by the "ztype".
        The contents of a zone are cryptographically signed before
-       being published a Distributed Hash Table (DHT).
+       being published a distributed hash table (DHT).
        Records are grouped by their label and encrypted (<xref target="recordencryption"/>)
        using an encryption key derived from the label and the zone public key.
        Instead of the zone private key "d", the signature MUST
-       be created using a blinded public/private key pair d' and zk'.
-       This blinding is realized using a Hierarchical Deterministic Key
-       Derivation (HDKD) scheme.
-       Such a scheme allows the zone owner to derive a private d' and a
-       resolver to derive the corresponding public key zk' in a deterministic
-       manner from the original public and private zone keys as well as a
-       label. This feature prevents zone enumeration and requires knowledge
-       of both "zk" and the queried label to confirm affiliation with a
+       be created using a blinded public/private key pair "d'" and "zk'".
+       This blinding is realized using a hierarchical deterministic key
+       derivation (HDKD) scheme.
+       Such a scheme allows the deterministic derivation of keys from
+       the original public and private zone keys using "label" values.
+       Specifically, the zone owner can derive private keys "d'", and a
+       resolver to derive the corresponding public keys "zk'".  Using
+       different "label" values in the derivation results in different
+       keys.  Without knowledge of the "label" values, the different
+       derivations are unlinkable both to the original key and to each
+       other.
+       This prevents zone enumeration and requires knowledge
+       of both "zk" and the "label" to confirm affiliation with a
        specific zone. At the same time, the blinded "zk'" provides nodes
        with the ability to verifiy the integrity of the published information
        without disclosing the originating zone.
      </t>
      <t>
-       The following primitives define a zone in GNS:
+       The following variables are associated with a zone in GNS:
      </t>
      <dl>
-       <dt>d</dt>
+       <dt>ztype</dt>
        <dd>
-         is the private zone key.
+         is the unique type of the zone type as registered in the
+         GNUnet Assigned Numbers Authority <xref target="GANA" />.
+         The zone type determines which cryptosystem is used for the
+         asymmetric and symmetric key operations of the zone. A 32-bit number.
        </dd>
-       <dt>zk</dt>
+       <dt>d</dt>
        <dd>
-         is the public zone key.
+         is the private zone key. The specific format depends on the zone type.
        </dd>
-       <dt>ztype</dt>
+       <dt>zk</dt>
        <dd>
-         is the unique type of the zone type as registered in
-         GANA. A 32-bit number.
+         is the public zone key. The specific format depends on the zone type.
        </dd>
        <dt>zid</dt>
        <dd>
-         is the unique identifier of a zone. It consists of the "ztype"
+         is the unique public identifier of a zone. It consists of the "ztype"
          and the public zone key "zk".
        </dd>
-       <dt>HDKD-Private(d) -> d'</dt>
-       <dd>
-         is an HDKD function which blinds a private zone key of the
-         respective type.
-       </dd>
-       <dt>HDKD-Public(zk) -> zk'</dt>
-       <dd>
-         is a HDKD function which blinds a public zone key "zk" of the
-         respective type.
-       </dd>
        <dt>zTLD</dt>
        <dd>
          is a string which encodes the "ztype" as well as the zone
-         key "zk" into one or more labels. The "zTLD" is used as a
+         key "zk" into a domain name. The "zTLD" is used as a
          globally unique reference to a specific namespace in the
          process of name resolution.
        </dd>
@@ -216,236 +215,87 @@ zkl := <Base32(zid)>
    <t>
        If "zkl" is less than 63 characters, it is also the "zTLD".
        If the resulting "zkl" should be longer than 63 characters, the
-       String must be divided into smaller labels separated by the label
-       separator ".". Where the most significant bytes of the "zid" be contained
+       string must be divided into smaller labels separated by the label
+       separator ".".  Here, the most significant bytes of the "zid" must be contained
        in the rightmost label of the resulting string and the least significant
        bytes in the leftmost label of the resulting string. For example,
-       assuming a "zkl" of 130 characters:
+       assuming a "zkl" of 130 characters, the encoding would be:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
 zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
      ]]></artwork>
-     <!-- FIXME: We probably want to define more things here such as
-       how zone types are registered and identified ? -->
-     <section anchor="zone_types" numbered="true" toc="default">
-       <name>Zone Types</name>
-       <t>
-         In the following, we define two instantiations of GNS
-         zone types with different cryptographic primitives.
-         Additional zone types may be defined in the future and require
-         registration in the GANA zone type registry.
-         Implementations MAY support any subset of zone types.
-         Implementations MUST NOT allow multiple different zone type
-         delegations under a single label.
-         <!-- FIXME: Are the below types mandatory? -->
-       </t>
-       <section anchor="zone_type_pkey" numbered="true" toc="default">
-         <name>PKEY Zone</name>
-         <t>
-           For PKEY zones the zone key material is derived using the
-           curve parameters of the twisted edwards representation
-           of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
-           with the ECDSA scheme (<xref target="RFC6979" />).
-           Consequently , we use the following naming convention for our
-           cryptographic primitives for PKEY zones:
-         </t>
-         <dl>
-           <dt>d</dt>
-           <dd>
-             is a 256-bit ECDSA private zone key.
-           </dd>
-           <dt>zk</dt>
-           <dd>
-             is the ECDSA public zone key corresponding to d. It is defined in
-             <xref target="RFC6979" /> as the curve point d*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>
-           <dt>ztype</dt>
-           <dd>
-             is registered with the value "0" in GANA.
-           </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>
-         </dl>
-         <t>
-           Given a label, the output of the HDKD-Private function for zone
-           key blinding is calculated as follows for PKEY zones:
-         </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-zk := d * B
-PRK_h := HKDF-Extract ("key-derivation", zk)
-h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-d' := h * d mod L
-           ]]></artwork>
-         <t>
-           Equally, given a label, the output of the HDKD-Public function is
-           calculated as follows for PKEY zones:
-         </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-PRK_h := HKDF-Extract ("key-derivation", zk)
-h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-zk' := h mod L * zk
-         ]]></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.
-           "PRK_h" is key material retrieved using an HKDF using the string
-           "key-derivation" as salt and the public zone key "zk" as initial
-           keying material.
-           "h" is the 512-bit HKDF expansion result. The expansion info input is
-           a concatenation of the label and string "gns".
-           "label" is a UTF-8 string under which the resource records are
-           published.
-         </t>
-         <t>
-           We point out that the multiplication of "zk" with "h" is a point multiplication,
-           while the multiplication of "d" with "h" is a scalar multiplication.
-           Signatures for PKEY zones are 512-bit ECDSA deterministic
-           signatures compliant with <xref target="RFC6979" />.
-         </t>
-         <t>
-           The "zid" of a PKEY is 32 + 4 bytes in length. This means that
-           a Base32-encoded "zTLD" will always fit into a single label and does
-           not need any further conversion.
-         </t>
-       </section>
-       <section anchor="zone_type_edkey" numbered="true" toc="default">
-         <name>EDKEY Zone</name>
-         <t>
-           For EDKEY zones the zone key material is derived using the
-           curve parameters of the twisted edwards representation
-           of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
-           with the Ed25519-SHA-512 scheme <xref target="ed25519" />.
-           Consequently , we use the following naming convention for our
-           cryptographic primitives for EDKEY zones:
-         </t>
-         <dl>
-           <dt>d</dt>
-           <dd>
-             is a 256-bit EdDSA private zone key.
-           </dd>
-           <dt>a</dt>
-           <dd>
-             is is an integer derived from d using the SHA512 hash function
-             as defined in <xref target="ed25519" />.
-           </dd>
-           <dt>zk</dt>
-           <dd>
-             is the EdDSA public zone key corresponding to d. It is defined in
-             <xref target="ed25519" /> as the curve point a*B where B is the
-             group generator of the elliptic curve and a is an integer
-             derived from d using the SHA512 hash function.
-             The public key is used to uniquely identify a GNS zone and is
-             referred to as the "zone key".
-           </dd>
-           <dt>ztype</dt>
-           <dd>
-             is registered with the value "1" in GANA.
-           </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>
-         </dl>
-         <t>
-           Given a label, the output of the HDKD-Private function for zone
-           key blinding is calculated as follows for EDKEY zones:
-         </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-zk := a * B
-PRK_h := HKDF-Extract ("key-derivation", zk)
-h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-h[0] &= 248;
-h[31] &= 127;
-h[31] |= 64;
-a' := h * a mod L
-           ]]></artwork>
-         <t>
-           Equally, given a label, the output of the HDKD-Public function is
-           calculated as follows for PKEY zones:
-         </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-PRK_h := HKDF-Extract ("key-derivation", zk)
-h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
-h[0] &= 248;
-h[31] &= 127;
-h[31] |= 64;
-zk' := h mod L * zk
-         ]]></artwork>
-         <t>
-           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.
-           "PRK_h" is key material retrieved using an HKDF using the string
-           "key-derivation" as salt and the public zone key "zk" as initial
-           keying material.
-           "h" is the 512-bit HKDF expansion result. The expansion info input is
-           a concatenation of the label and string "gns".
-           The result of the HKDF must be clamped.
-           "a" is the 256-bit integer correspinding to the 256-bit private zone
-           key d as defined in <xref target="zone_type_edkey" />.
-           "label" is a UTF-8 string under which the resource records are
-           published.
-         </t>
-         <t>
-           We point out that the multiplication of "zk" with "h" is a point multiplication,
-           while the multiplication of "a" with "h" is a scalar multiplication.
-         </t>
-         <t>
-           Signatures for EDKEY zones using the derived private key a'
-           are NOT compliant with <xref target="ed25519" />.
-           Instead, signatures MUST be generated as follows for any given
-           message M and deterministic random-looking r:
-         </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-R := r * B
-S := r + SHA512(R, zk', M) * a' mod L
-           ]]></artwork>
-         <t>
-           A signature (R,S) is valid if the following holds:
-         </t>
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-SB == R + SHA512(R, zk', M) * A'
-           ]]></artwork>
-         <t>
-           The "zid" of an EDKEY is 32 + 4 bytes in length. This means that
-           a Base32-encoded "zTLD" will always fit into a single label and does
-           not need any further conversion.
-         </t>
-
-       </section>
-     </section>
+   </section>
+   <section anchor="zone_types" numbered="true" toc="default">
+     <name>Zone Types</name>
+     <t>
+       A zone type identifies a family of eight functions:
+     </t>
+     <dl>
+       <dt>Private-KeyGen() -> d</dt>
+       <dd>
+         is a function to generate a fresh private key "d".
+       </dd>
+       <dt>Public-KeyGen(d) -> zk</dt>
+       <dd>
+         is a function to derive a public key "zk" from a private key "d".
+       </dd>
+       <dt>HDKD-Private(d,label) -> d'</dt>
+       <dd>
+         is an HDKD function which blinds a private zone key "d"
+         using "label", resulting in another private key which
+         can be used to create cryptographic signatures.
+       </dd>
+       <dt>S-Encrypt(zk,label,nonce,expiration,rdata) -> bdata</dt>
+       <dd>
+         is a deterministic symmetric encryption function which encrypts the record
+         data "rdata" based on key material derived from "zk", "label",
+         "nonce" and "expiration".
+         A deterministic encryption scheme is
+         required to improve performance by leveraging caching features
+         of DHTs.
+       </dd>
+       <dt>Sign(d',bdata) -> sig</dt>
+       <dd>
+         is a function to sign "bdata" using the (blinded) private key
+         "d'", yielding an unforgable cryptographic signature "sig".
+       </dd>
+       <dt>HDKD-Public(zk,label) -> zk'</dt>
+       <dd>
+         is a HDKD function which blinds a public zone key "zk"
+         using "label". "zk" and "zk'" must be unlinkable. Furthermore,
+         blinding "zk" with different values for "label" must result
+         in unlinkable different resulting values for "zk'".
+       </dd>
+       <dt>Verify(zk',bdata,sig) -> valid</dt>
+       <dd>
+         is a function to verify the signature "sig" was created by
+         the a private key "d'" derived from "d" and "label" if
+         "zk'" was derived from the corresponding to
+         "zk := Public-Keygen(d)" and "label".
+         The function returns "true" if the signature is valid,
+         and otherwise "false".
+       </dd>
+       <dt>S-Decrypt(zk,label,nonce,expiration,bdata) -> rdata</dt>
+       <dd>
+         is a symmetric encryption function which decrypts the encrypted record
+         data "bdata" based on key material derived from "zk", "label",
+         "nonce" and "expiration".
+       </dd>
+     </dl>
+     <t>
+       Zone types are identified by a 32-bit resource record type number.
+       Resource record types are discussed in the next section.
+     </t>
    </section>
    <section anchor="rrecords" numbered="true" toc="default">
      <name>Resource Records</name>
      <t>
        A GNS implementor MUST provide a mechanism to create and manage resource
-       records for local zones. A local zone is established by creating a zone
-       key pair. Records may be added to each zone, hence a (local) persistency
+       records for local zones. A local zone is established by selecting a
+       zone type and creating a zone
+       key pair. Implementations SHOULD select a secure zone type automatically
+       and not leave the zone type selection to the user.
+       Records may be added to each zone, hence a (local) persistency
        mechanism for resource records and zones must be provided.
        This local zone database is used by the GNS resolver implementation
        and to publish record information.
@@ -489,7 +339,9 @@ SB == R + SHA512(R, zk', M) * A'
          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" />).
+         below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />),
+         while values above 2^16 are allocated by the
+         GNUnet Assigned Numbers Authority <xref target="GANA" />.
        </dd>
        <dt>FLAGS</dt>
        <dd>
@@ -554,22 +406,25 @@ SB == R + SHA512(R, zk', M) * A'
          regular records when resolving labels in local zones.
        </dd>
      </dl>
-     <section anchor="gnsrecords_numbers" numbered="true" toc="default">
-       <name>Record Types</name>
-       <t>
-         A registry of GNS Record Types is described in <xref target="gana"/>.  The
-         registration policy for this registry is "First Come First Served", as
-           described in <xref target="RFC8126"/>.
-         <!--When requesting new entries, careful
-         consideration of the following criteria is strongly advised:FIXME what considerations?-->
-       </t>
-     </section>
+   </section>
+   <section anchor="gnsrecords_numbers" numbered="true" toc="default">
+     <name>Record Types</name>
+     <t>
+       A registry of GNS Record Types is described in <xref target="gana"/>.  The
+       registration policy for this registry is "First Come First Served", as
+       described in <xref target="RFC8126"/>.
+       <!--When requesting new entries, careful
+           consideration of the following criteria is strongly advised:FIXME what considerations?-->
+     </t>
      <section anchor="gnsrecords_pkey" numbered="true" toc="default">
        <name>PKEY</name>
        <t>In GNS, a delegation of a label to a zone of type "PKEY" is
-         represented through a PKEY record.
+         represented through a PKEY record.  The PKEY number is a zone
+         type and thus also implies the cryptosystem for the zone that
+         is being delegated to.
          A PKEY resource record contains the public key of the zone to
-         delegate to. A PKEY record MUST be the only record under a label. No other
+         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[
@@ -592,8 +447,332 @@ SB == R + SHA512(R, zk', M) * A'
            A 256-bit ECDSA zone key.
          </dd>
        </dl>
+
+       <t>
+         For PKEY zones the zone key material is derived using the
+         curve parameters of the twisted edwards representation
+         of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
+         with the ECDSA scheme (<xref target="RFC6979" />).
+         Consequently , we use the following naming convention for our
+         cryptographic primitives for PKEY zones:
+       </t>
+       <dl>
+         <dt>d</dt>
+         <dd>
+           is a 256-bit ECDSA private zone key.
+         </dd>
+         <dt>zk</dt>
+         <dd>
+           is the ECDSA public zone key corresponding to d. It is defined in
+           <xref target="RFC6979" /> as the curve point d*G where G is the group
+           generator of the elliptic curve. The public key is used to uniquely
+           identify a GNS zone and is referred to as the "zone key".
+         </dd>
+         <dt>p</dt>
+         <dd>
+           is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
+           2^255 - 19.
+         </dd>
+         <dt>G</dt>
+         <dd>
+           is the group generator (X(P),Y(P)) of edwards25519 as defined in
+           <xref target="RFC7748" />.
+         </dd>
+         <dt>L</dt>
+         <dd>
+           is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
+         </dd>
+       </dl>
+       <t>
+         The "zid" of a PKEY is 32 + 4 bytes in length. This means that
+         a Base32-encoded "zTLD" will always fit into a single label and does
+         not need any further conversion.
+       </t>
+       <t>
+         Given a label, the output d' of the HDKD-Private(d,label) function for zone
+         key blinding is calculated as follows for PKEY zones:
+       </t>
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+zk := d * G
+PRK_h := HKDF-Extract ("key-derivation", zk)
+h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+d' := h * d mod L
+        ]]></artwork>
+       <t>
+         Equally, given a label, the output zk' of the HDKD-Public(zk,label) function is
+         calculated as follows for PKEY zones:
+       </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+PRK_h := HKDF-Extract ("key-derivation", zk)
+h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+zk' := h mod L * zk
+        ]]></artwork>
+       <t>
+         The PKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in
+         <xref target="RFC5869" />, using HMAC-SHA512 for the extraction
+         phase and HMAC-SHA256 for the expansion phase.
+         "PRK_h" is key material retrieved using an HKDF using the string
+         "key-derivation" as salt and the public zone key "zk" as initial
+         keying material.
+         "h" is the 512-bit HKDF expansion result. The expansion info input is
+         a concatenation of the label and string "gns".
+         "label" is a UTF-8 string under which the resource records are
+         published.
+       </t>
+       <t>
+         We point out that the multiplication of "zk" with "h" is a point multiplication,
+         while the multiplication of "d" with "h" is a scalar multiplication.
+       </t>
+       <t>
+         The Sign() and Verify() functions
+         for PKEY zones are implemented using 512-bit ECDSA deterministic
+         signatures as specified in <xref target="RFC6979" />.
+       </t>
+       <t>
+         The S-Encrypt() and S-Decrypt() functions use AES in counter mode
+         as defined in <xref target="MODES" /> (CTR-AES-256):
+       </t>
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+RDATA := CTR-AES256(K, IV, BDATA)
+BDATA := CTR-AES256(K, IV, RDATA)
+         ]]></artwork>
+       <t>
+         The key "K" and counter "IV" are derived from
+         the record "label" and the zone key "zk" as follows:
+       </t>
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
+K := HKDF-Expand (PRK_k, label, 256 / 8);
+NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
+]]></artwork>
+       <t>
+         HKDF is a hash-based key derivation function as defined in
+         <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
+         extraction phase and HMAC-SHA256 for the expansion phase.
+         The output keying material is 32 octets (256 bits) for the symmetric
+         key and 4 octets (32 bits) for the nonce.
+         The symmetric key "K" is a 256-bit AES <xref target="RFC3826" /> key:
+       </t>
+       <t>
+         The nonce is combined with a 64-bit initialization vector and a
+         32-bit block counter as defined in <xref target="RFC3686" />.
+         The block counter begins with the value of 1, and it is incremented
+         to generate subsequent portions of the key stream.
+         The block counter is a 32-bit integer value in network byte order.
+         The initialization vector is the expiration time of the
+         resource record block in network byte order.
+         The resulting counter ("IV") wire format is as follows:
+       </t>
+       <figure anchor="figure_hkdf_ivs_pkey">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+0     8     16    24    32
++-----+-----+-----+-----+
+|         NONCE         |
++-----+-----+-----+-----+
+|       EXPIRATION      |
+|                       |
++-----+-----+-----+-----+
+|      BLOCK COUNTER    |
++-----+-----+-----+-----+
+           ]]></artwork>
+       </figure>
      </section>
-     <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
+
+     <section anchor="gnsrecords_edkey" numbered="true" toc="default">
+       <name>EDKEY</name>
+       <t>In GNS, a delegation of a label to a zone of type "EDKEY" is
+         represented through a EDKEY record.  The EDKEY number is a zone
+         type and thus also implies the cryptosystem for the zone that
+         is being delegated to.
+         An EDKEY resource record contains the public key of the zone to
+         delegate to.
+         A EDKEY record MUST be the only record under a label. No other
+         records are allowed. A EDKEY DATA entry has the following format:</t>
+       <figure anchor="figure_edkeyrecord">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+0     8     16    24    32    40    48    56
++-----+-----+-----+-----+-----+-----+-----+-----+
+|                   PUBLIC KEY                  |
+|                                               |
+|                                               |
+|                                               |
++-----+-----+-----+-----+-----+-----+-----+-----+
+           ]]></artwork>
+         <!--        <postamble>which is a very simple example.</postamble>-->
+       </figure>
+       <t>
+         where:
+       </t>
+       <dl>
+         <dt>PUBLIC KEY</dt>
+         <dd>
+           A 256-bit EdDSA zone key.
+         </dd>
+       </dl>
+         <t>
+           For EDKEY zones the zone key material is derived using the
+           curve parameters of the twisted edwards representation
+           of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
+           with the Ed25519-SHA-512 scheme <xref target="ed25519" />.
+           Consequently , we use the following naming convention for our
+           cryptographic primitives for EDKEY zones:
+         </t>
+         <dl>
+           <dt>d</dt>
+           <dd>
+             is a 256-bit EdDSA private zone key.
+           </dd>
+           <dt>a</dt>
+           <dd>
+             is is an integer derived from "d" using the SHA512 hash function
+             as defined in <xref target="ed25519" />.
+           </dd>
+           <dt>zk</dt>
+           <dd>
+             is the EdDSA public zone key corresponding to "d". It is defined in
+             <xref target="ed25519" /> as the curve point "a*G" where "G" is the
+             group generator of the elliptic curve and "a" is an integer
+             derived from "d" using the SHA512 hash function.
+             The public key is used to uniquely identify a GNS zone and is
+             referred to as the "zone key".
+           </dd>
+           <dt>p</dt>
+           <dd>
+             is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
+             2^255 - 19.
+           </dd>
+           <dt>G</dt>
+           <dd>
+             is the group generator (X(P),Y(P)) of edwards25519 as defined in
+            <xref target="RFC7748" />.
+           </dd>
+           <dt>L</dt>
+           <dd>
+             is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
+           </dd>
+         </dl>
+         <t>
+           The "zid" of an EDKEY is 32 + 4 bytes in length. This means that
+           a Base32-encoded "zTLD" will always fit into a single label and does
+           not need any further conversion.
+         </t>
+         <t>
+           Given a label, the output of the HDKD-Private function for zone
+           key blinding is calculated as follows for EDKEY zones:
+         </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+zk := a * G
+PRK_h := HKDF-Extract ("key-derivation", zk)
+h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+h[0] &= 248;
+h[31] &= 127;
+h[31] |= 64;
+a' := h * a mod L
+           ]]></artwork>
+         <t>
+           Equally, given a label, the output of the HDKD-Public function is
+           calculated as follows for PKEY zones:
+         </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+PRK_h := HKDF-Extract ("key-derivation", zk)
+h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+h[0] &= 248;
+h[31] &= 127;
+h[31] |= 64;
+zk' := h mod L * zk
+         ]]></artwork>
+         <t>
+           The EDKEY cryptosystem uses a
+           hash-based key derivation function (HKDF) as defined in
+           <xref target="RFC5869" />, using HMAC-SHA512 for the extraction
+           phase and HMAC-SHA256 for the expansion phase.
+           "PRK_h" is key material retrieved using an HKDF using the string
+           "key-derivation" as salt and the public zone key "zk" as initial
+           keying material.
+           "h" is the 512-bit HKDF expansion result. The expansion info input is
+           a concatenation of the label and string "gns".
+           The result of the HKDF must be clamped.
+           "a" is the 256-bit integer corresponding to the 256-bit private zone
+           key "d".
+           "label" is a UTF-8 string under which the resource records are
+           published.
+         </t>
+         <t>
+           We point out that the multiplication of "zk" with "h" is a point multiplication,
+           while the multiplication of "a" with "h" is a scalar multiplication.
+         </t>
+         <t>
+           Signatures for EDKEY zones using the derived private key "a'"
+           are NOT compliant with <xref target="ed25519" />.
+           Instead, signatures MUST be generated as follows for any given
+           message M and deterministic random-looking "r":
+         </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+R := r * G
+S := r + SHA512(R, zk', M) * a' mod L
+           ]]></artwork>
+         <t>
+           A signature (R,S) is valid if the following holds:
+         </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+SB == R + SHA512(R, zk', M) * A'
+           ]]></artwork>
+         <t>
+           <!-- FIXME: here we SHOULD consider standardizing AES-GCM
+                instead. Please review this choice when implementing
+                EDKEY support! -->
+           The S-Encrypt() and S-Decrypt() functions use AES in counter mode
+           as defined in <xref target="MODES" /> (CTR-AES-256):
+         </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+RDATA := CTR-AES256(K, IV, BDATA)
+BDATA := CTR-AES256(K, IV, RDATA)
+         ]]></artwork>
+         <t>
+           The key "K" and counter "IV" are derived from
+           the record "label" and the zone key "zk" as follows:
+         </t>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
+K := HKDF-Expand (PRK_k, label, 256 / 8);
+NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
+]]></artwork>
+         <t>
+           HKDF is a hash-based key derivation function as defined in
+           <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
+           extraction phase and HMAC-SHA256 for the expansion phase.
+           The output keying material is 32 octets (256 bits) for the symmetric
+           key and 4 octets (32 bits) for the nonce.
+           The symmetric key "K" is a 256-bit AES <xref target="RFC3826" /> key:
+         </t>
+         <t>
+           The nonce is combined with a 64-bit initialization vector and a
+           32-bit block counter as defined in <xref target="RFC3686" />.
+           The block counter begins with the value of 1, and it is incremented
+           to generate subsequent portions of the key stream.
+           The block counter is a 32-bit integer value in network byte order.
+           The initialization vector is the expiration time of the
+           resource record block in network byte order.
+           The resulting counter ("IV") wire format is as follows:
+         </t>
+         <figure anchor="figure_hkdf_ivs_edkey">
+           <artwork name="" type="" align="left" alt=""><![CDATA[
+0     8     16    24    32
++-----+-----+-----+-----+
+|         NONCE         |
++-----+-----+-----+-----+
+|       EXPIRATION      |
+|                       |
++-----+-----+-----+-----+
+|      BLOCK COUNTER    |
++-----+-----+-----+-----+
+           ]]></artwork>
+         </figure>
+       </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
@@ -816,7 +995,7 @@ SB == R + SHA512(R, zk', M) * A'
        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.
+       "label" of the contained records.
      </t>
      <section anchor="blinding" numbered="true" toc="default">
        <name>DHT Key Derivations</name>
@@ -887,7 +1066,8 @@ q := SHA512 (HDKD-Public(zk, label))
          <dd>
            The signature is computed over the data following
            the PUBLIC KEY field.
-           The signature is created using the derived private key
+           The signature is created using the Sign() function of
+           the cryptosystem of the zone and the derived private key
            "HDKD-Private(d, label)" (see <xref target="zone_types" />).
          </dd>
          <dt>ZONE TYPE</dt>
@@ -995,78 +1175,7 @@ q := SHA512 (HDKD-Public(zk, label))
            Note that a record set with a delegation record MUST NOT
            contain other records.
          </dd>
-
        </dl>
-       <t>
-         DHTs often offer caching in oder to improve performance.
-         In order to leverage this, a deterministic encryption scheme is
-         required in order to leverage caching features.
-         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>
-       <artwork name="" type="" align="left" alt=""><![CDATA[
-PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
-PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
-K := HKDF-Expand (PRK_k, label, 256 / 8);
-NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
-]]></artwork>
-       <t>
-         HKDF is a hash-based key derivation function as defined in
-         <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
-         extraction phase and HMAC-SHA256 for the expansion phase.
-         The output keying material is 32 octets (256 bits) for the symmetric
-         key and 4 octets (32 bits) for the nonce.
-         The symmetric key "K" is a 256-bit AES <xref target="RFC3826" /> key:
-       </t>
-       <t>
-         The nonce is combined with a 64-bit initialization vector and a
-         32-bit block counter as defined in <xref target="RFC3686" />.
-         The block counter begins with the value of 1, and it is incremented
-         to generate subsequent portions of the key stream.
-         The block counter is a 32-bit integer value in network byte order.
-         The initialization vector is the expiration time of the
-         resource record block in network byte order.
-         The resulting COUNTER wire format is as follows:
-       </t>
-       <figure anchor="figure_hkdf_ivs">
-         <artwork name="" type="" align="left" alt=""><![CDATA[
-0     8     16    24    32
-+-----+-----+-----+-----+
-|         NONCE         |
-+-----+-----+-----+-----+
-|       EXPIRATION      |
-|                       |
-+-----+-----+-----+-----+
-|      BLOCK COUNTER    |
-+-----+-----+-----+-----+
-           ]]></artwork>
-         <!--        <postamble>which is a very simple example.</postamble>-->
-       </figure>
-
-       <t>
-         The key and counter block are used for the AES cipher in counter mode
-         as defined in <xref target="MODES" /> (CTR-AES-256):
-       </t>
-       <artwork name="" type="" align="left" alt=""><![CDATA[
-RDATA := CTR-AES256(K, COUNTER, BDATA)
-BDATA := CTR-AES256(K, COUNTER, RDATA)
-         ]]></artwork>
-       <t>
-         In order to ensure ciphertext indistinguishability, care must be
-         taken with respect to the initialization vector in the counter
-         block. In our design, the IV is always the expiration time of the
-         record block.
-         For blocks with relative expiration times it is implicitly
-         ensured that each time a block is published into the DHT, its IV is
-         unique as the expiration time is calculated dynamically and increases
-         monotonically.
-         For blocks with absolute expiration times, the implementation
-         MUST ensure that the expiration time is modified when the record
-         data changes. For example. the expiration time may be increased
-         by a single microsecond.
-       </t>
      </section>
    </section>
    <section anchor="encoding" numbered="true" toc="default">
@@ -1172,12 +1281,19 @@ BDATA := CTR-AES256(K, COUNTER, RDATA)
    </li>
    </ol>
          <section anchor="delegation_processing" numbered="true" toc="default">
-           <name>PKEY</name>
+           <name>Encountering zone delegation records</name>
            <t>
-             When the resolver encounters a PKEY record and the remainder of
+             When the resolver encounters a record of a supported
+             zone delegation record type (such as PKEY or EDKEY)
+             and the remainder of
              the name is not empty, resolution continues
              recursively with the remainder of the name in the
-             GNS zone specified in the PKEY record.
+             GNS zone specified in the delegation record.
+             Implementations MUST NOT allow multiple different zone type
+             delegations under a single label.
+             Implementations MAY support any subset of zone types.  If
+             an unsupported zone type is encountered, resolution fails
+             (NXDOMAIN).
            </t>
            <t>
              If the remainder of the name to resolve is empty and we have
@@ -1718,6 +1834,20 @@ example.com = zk2
            The old record type remains
            and zones can iteratively migrate to the updated zone keys.
          </t>
+         <t>
+           In order to ensure ciphertext indistinguishability, care must be
+           taken with respect to the initialization vector in the counter
+           block. In our design, the IV is always the expiration time of the
+           record block.
+           For blocks with relative expiration times it is implicitly
+           ensured that each time a block is published into the DHT, its IV is
+           unique as the expiration time is calculated dynamically and increases
+           monotonically.
+           For blocks with absolute expiration times, the implementation
+           MUST ensure that the expiration time is modified when the record
+           data changes. For example. the expiration time may be increased
+           by a single microsecond.
+         </t>
        </section>
        <section anchor="security_abuse" numbered="true" toc="default">
          <name>Abuse mitigation</name>
@@ -1822,7 +1952,8 @@ example.com = zk2
      <section anchor="gana" numbered="true" toc="default">
        <name>GANA Considerations</name>
        <t>
-         GANA is requested to create an "GNU Name System Record Types" registry.
+         GANA <xref target="GANA" />
+         is requested to create an "GNU Name System Record Types" registry.
          The registry shall record for each entry:
        </t>
        <ul>
@@ -2089,6 +2220,15 @@ ee83f0cc79c4c5ea
        &RFC8032;
        &RFC8126;
 
+       <reference anchor="GANA" target="https://gana.gnunet.org/">
+         <front>
+           <title>GNUnet Assigned Numbers Authority (GANA)</title>
+           <author><organization>GNUnet e.V.</organization>
+           </author>
+           <date month="April" year="2020" />
+         </front>
+       </reference>
+
        <reference anchor="GNS" target="https://doi.org/10.1007/978-3-319-12280-9_9">
          <front>
            <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title>