commit 0a62fcc3be82282fe1d01b44c1b2171b215254fd
parent f177a162f164edc868134f6385bb15214649a792
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
Date: Fri, 4 Sep 2020 23:03:22 +0200
purging PKEY
Diffstat:
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git 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 ".<Base32(zk)>", 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 ".<Base32(zk)>").
+ (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>
