purging PKEY

1 files changed, 28 insertions, 21 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index a68a0e8..8c6bf27 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -139,7 +139,7 @@
        called PKEY and EDKEY, respectively.
      </t>
      <section anchor="zone_privacy" numbered="true" toc="default">
-       <name>Privacy</name>
+       <name>Zone Key Blinding</name>
        <t>
          In GNS, the contents of a zone are cryptographically signed before
          publishing. Instead of the zone private key "d", the signature MUST
@@ -240,8 +240,8 @@ HDKD-Public(zk, label) -> zk'
            </dd>
          </dl>
          <t>
-           Given a label, the output of the HDKD-Private function is
-           calculated as follows for PKEY zones:
+           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
@@ -292,6 +292,8 @@ zk' := h mod L * zk
            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" />.
+           Finally, the label representation of a PKEY public zone key is
+           the Base32-encoding of "zk" prefixed with "pkey-".
          </t>
        </section>
        <section anchor="zone_type_edkey" numbered="true" toc="default">
@@ -426,8 +428,9 @@ zk' := h mod L * zk
      </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
+       <t>In GNS, a delegation of a label to a zone of type "PKEY" 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">
@@ -537,7 +540,7 @@ zk' := h mod L * zk
          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
+         delegation record (<xref target="zone_types" />) containing this zone's
          public zone key.
          This record SHOULD only be stored under the empty label "@" but MAY be
          returned with record sets under any label as a supplemental record.
@@ -845,8 +848,9 @@ q := SHA512 (HDKD-Public(zk, label))
            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
+           As a special exception, record sets with (only) a zone delegation
+           record type are never padded.
+           Note that a record set with a delegation record MUST NOT
            contain other records.
          </dd>
 
@@ -999,8 +1003,8 @@ BDATA := TWOFISH(K[32:63], IV[16:31],
          <li>
            Case 1:
            If the remainder of the name to resolve is empty and the record set
-           does not consist of a PKEY, CNAME or DNS2GNS record, the record set
-           is the result and the recursion is concluded.
+           does not consist of a delegation, CNAME or DNS2GNS record,
+           the record set is the result and the recursion is concluded.
          </li>
    <li>
      Case 2:
@@ -1013,7 +1017,7 @@ BDATA := TWOFISH(K[32:63], IV[16:31],
            Case 3:
            If the remainder of the name to resolve is not empty and
      does not match the "_SERVICE._PROTO" syntax, then the current record set
-           MUST consist of a single PKEY record (<xref target="pkey_processing" />),
+           MUST consist of a single delegation record (<xref target="delegation_processing" />),
            a single CNAME record (<xref target="cname_processing" />),
            or one or more GNS2DNS records (<xref target="gns2dns_processing" />),
            which are processed as described in the respective sections below.
@@ -1028,7 +1032,7 @@ BDATA := TWOFISH(K[32:63], IV[16:31],
      if possible.
    </li>
    </ol>
-         <section anchor="pkey_processing" numbered="true" toc="default">
+         <section anchor="delegation_processing" numbered="true" toc="default">
            <name>PKEY</name>
            <t>
              When the resolver encounters a PKEY record and the remainder of
@@ -1061,8 +1065,9 @@ BDATA := TWOFISH(K[32:63], IV[16:31],
              The DNS server names may themselves be names in GNS or DNS.
              If the DNS server name ends in ".+", the rest of the name is to be
              interpreted relative to the zone of the GNS2DNS record.
-             If the DNS server name ends in ".&lt;Base32(zk)&gt;", the DNS
-             server name is to be resolved against the GNS zone zk.
+             If the DNS server name ends in a label representation of a
+             zone key, the DNS server name is to be resolved against
+             the GNS zone zk.
            </t>
            <t>
              Multiple GNS2DNS records may be stored under the same label,
@@ -1116,7 +1121,7 @@ BDATA := TWOFISH(K[32:63], IV[16:31],
            <t>
              The recursive DNS resolution process may yield a CNAME as well
              which in turn may either point into the DNS or GNS namespace
-             (if it ends in a ".&lt;Base32(zk)&gt;").
+             (if it ends in a label representation of a zone key).
              In order to prevent infinite loops, the resolver MUST
              implement loop detections or limit the number of recursive
              resolution steps.
@@ -1474,12 +1479,12 @@ NICK: john (Supplemental)
        <t>
          GNS clients SHOULD first try to interpret the top-level domain of
          a GNS name as a zone key.
-         For example. if the top-level domain is a Base32-encoded public zone
-         key "zk", the root zone of the resolution process is implicitly given
-         by the name:
+         For example. if the top-level domain is a label representation of
+         a public zone key "zkl", the root 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)>
+Example name: www.example.<zkl>
 => Root zone: zk
 => Name to resolve from root zone: www.example
          ]]></artwork>
@@ -1560,9 +1565,11 @@ example.com = zk2
          </t>
          <t>
            In terms of crypto-agility, whenever the need for an updated cryptographic
-           scheme arises to replace ECDSA over Curve25519 it may simply be introduced
+           scheme arises to, for example, replace ECDSA over Curve25519 for
+           PKEY records it may simply be introduced
            through a new record type. Such a new record type may then replace
-           the PKEY record type for future records. The old record type remains
+           the delegation record type for future records.
+           The old record type remains
            and zones can iteratively migrate to the updated zone keys.
          </t>
        </section>