1 files changed, 31 insertions, 9 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index e0b38de..50f71cd 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -14,6 +14,7 @@
 <!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
 <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
 <!ENTITY RFC5895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml">
+<!ENTITY RFC6066 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
 <!ENTITY RFC6234 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml">
 <!ENTITY RFC6761 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml">
 <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
@@ -450,8 +451,8 @@
    <section anchor="zones" numbered="true" toc="default">
      <name>Zones</name>
      <t>
-       A zone master implementation <bcp14>SHOULD</bcp14> enable the user to
-       create and manage zones.
+       A zone master implementation <bcp14>SHOULD</bcp14> enable the zone
+       owners to create and manage zones.
        If this functionality is not implemented, names can still be resolved
        if zone keys for the initial step in the name resolution are available
        (see <xref target="resolution"/>).
@@ -535,6 +536,8 @@
        document.
        All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation
        record types in the GNU Name System Record Types registry (see <xref target="gana"/>).
+       When defining new record types the cryptographic security considerations
+       of this document apply, in particular <xref target="security_cryptography"/>.
      </t>
      <section anchor="zTLD" numbered="true" toc="default">
        <name>Zone Top-Level Domain</name>
@@ -568,7 +571,10 @@
        <artwork name="" type="" align="left" alt=""><![CDATA[
 zTLD := Base32GNS-Encode(ztype||zkey)
 ztype||zkey := Base32GNS-Decode(zTLD)
-    ]]></artwork>
+         ]]></artwork>
+       <t>
+         where "||" is the concatenation operator.
+       </t>
        <t>
          The zTLD can be used as-is as a rightmost label in a GNS name.
          If an application wants to ensure DNS compatibility of the name,
@@ -589,7 +595,7 @@ ztype||zkey := Base32GNS-Decode(zTLD)
        <!-- FIXME: Is this really really necessary? Really? -->
        <artwork name="" type="" align="left" alt=""><![CDATA[
 zTLD[126..129].zTLD[63..125].zTLD[0..62]
-       ]]></artwork>
+         ]]></artwork>
    </section>
     <section anchor="revocation" numbered="true" toc="default">
        <name>Zone Revocation</name>
@@ -1016,6 +1022,14 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
        There <bcp14>MAY</bcp14> be inactive records of the same type which have
        the SHADOW flag set in order to facilitate smooth key rollovers.
      </t>
+     <t>
+       In the following, "||" is the concatenation operator of two byte strings.
+       The algorithm specification uses character strings such as GNS labels or
+       constant values.
+       When used in concatenations or as input to functions the
+       null-terminator of the character strings <bcp14>MUST NOT</bcp14> be
+       included.
+     </t>
      <section anchor="gnsrecords_pkey" numbered="true" toc="default">
        <name>PKEY</name>
        <t>
@@ -1557,9 +1571,11 @@ S-Decrypt(zk,label,expiration,ciphertext):
          DNS name of the service to be transmitted over the transport protocol.
          In GNS, legacy host name records provide applications the DNS name that
          is required to establish a connection to such a service.
-         The most common use case is HTTP virtual hosting, where a DNS name must
-         be supplied in the HTTP "Host"-header.
-         Using a GNS name for the "Host"-header might not work as
+         The most common use case is HTTP virtual hosting and TLS Server Name
+         Indication <xref target="RFC6066"/>, where a DNS name must
+         be supplied in the HTTP "Host"-header and the TLS handshake,
+         respectively.
+         Using a GNS name in those cases might not work as
          it might not be globally unique. Furthermore, even if uniqueness is
          not an issue, the legacy service might not even be aware of GNS.
        </t>
@@ -1688,7 +1704,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
    </section>
    </section>
    <section anchor="publish" numbered="true" toc="default">
-     <name>Record Storage</name>
+     <name>Record Encoding</name>
      <t>
        Any API which allows storing a value under a 512-bit key and retrieving
        one or more values from the key can be used by an implementation for record storage.
@@ -2451,6 +2467,12 @@ NICK: john (Supplemental)
        <section anchor="security_cryptography" numbered="true" toc="default">
          <name>Cryptography</name>
          <t>
+           The following considerations provide background on the design choices
+           of the ztypes specified in this document.
+           When specifying new ztypes as per <xref target="zones"/>, the same
+           considerations apply.
+         </t>
+         <t>
            GNS PKEY zone keys use ECDSA over Ed25519.
            This is an unconventional choice,
            as ECDSA is usually used with other curves.  However, standardized
@@ -2934,7 +2956,7 @@ Purpose | Name            | References | Comment
      <references>
        <name>Informative References</name>
          &RFC4033;
-       <!--  &RFC6781; -->
+         &RFC6066;
          &RFC7363;
          &RFC8324;
          &RFC8806;