commit be8ace04e2b38e5d7cb26f6b288adfa8c365325a
parent 66b1d7711b8a5d104559e3a46f09c730d451defa
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 20 Dec 2021 21:14:56 +0100
ise mostly done
Diffstat:
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -600,8 +600,8 @@ zk' := h mod L * zk
"key-derivation" as salt and the public zone key as initial
keying material.
h is the 512-bit HKDF expansion result and must be interpreted in
- network byte order. The expansion info input is
- a concatenation of the label and string "gns".
+ network byte order. The expansion information input is
+ a concatenation of the label and the string "gns".
The label is a UTF-8 string under which the resource records are
published.
The multiplication of zk with h is a point multiplication,
@@ -703,7 +703,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
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
+ Consequently, we use the following naming convention for our
cryptographic primitives for EDKEY zones:
</t>
<dl>
@@ -785,8 +785,9 @@ zk' := h * zk
PRK_h is key material retrieved using an HKDF using the string
"key-derivation" as salt and the public zone key as initial
keying material.
- The blinding factor h is the 512-bit HKDF expansion result. The expansion info input is
- a concatenation of the label and string "gns".
+ The blinding factor h is the 512-bit HKDF expansion result.
+ The expansion information input is
+ a concatenation of the label and the string "gns".
The result of the HKDF must be clamped and interpreted in network
byte order.
a is the 256-bit integer corresponding to the 256-bit private zone
@@ -799,7 +800,7 @@ zk' := h * zk
</t>
<t>
Signatures for EDKEY zones using the derived private key a'
- are NOT compliant with <xref target="ed25519" />.
+ are not compliant with <xref target="ed25519" />.
As the corresponding private key to the derived private scalar a'
is not known, it is not possible to deterministically derive the
signature part R according to <xref target="ed25519" />.
@@ -923,13 +924,14 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<dl>
<dt>DNS NAME</dt>
<dd>
- The name to continue with in DNS (0-terminated).
+ The name to continue with in DNS. The value is UTF-8 encoded and
+ 0-terminated.
</dd>
<dt>DNS SERVER NAME</dt>
<dd>
The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
form or a DNS name. It may also be a relative GNS name ending with a
- "+" top-level domain. The value is UTF-8 encoded (also for DNS names)
+ "+" top-level domain. The value is UTF-8 encoded
and 0-terminated.
</dd>
</dl>
@@ -938,7 +940,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<section anchor="gnsrecords_leho" numbered="true" toc="default">
<name>LEHO</name>
<t>Legacy hostname records can be used by applications that are expected
- to supply a DNS name on the application layer. The most common use case
+ to supply a DNS name at the application layer. The most common use case
is HTTP virtual hosting, which as-is would not work with GNS names as
those may not be globally unique.
@@ -976,7 +978,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<name>NICK</name>
<t>
Nickname records can be used by zone administrators to publish an
- indication on what label this zone prefers to be referred to.
+ the label that a zone prefers to have used when it is referred to.
This is a suggestion to other zones what label to use when creating a
delegation record (<xref target="zone_types" />) containing this zone's
public zone key.
@@ -1246,8 +1248,10 @@ q := SHA512 (HDKD-Public(zk, label))
</dd>
<dt>PURPOSE</dt>
<dd>
- A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).
+ A 32-bit signature purpose flag. For a RRBLOCK the value of this
+ field MUST be 15. The value is encoded in network byte order.
+ The value of this field corresponds to an entry in the
+ GANA "GNUnet Signature Purpose" registry.
</dd>
<dt>EXPIRATION</dt>
<dd>
@@ -1541,7 +1545,7 @@ example.com = zk2
</t>
<t>
Otherwise, it is expected that the resolver first resolves the
- IP(s) of the specified DNS name server(s). GNS2DNS records MAY
+ IP addresses of the specified DNS name servers. GNS2DNS records MAY
contain numeric IPv4 or IPv6 addresses, allowing the resolver to
skip this step.
The DNS server names may themselves be names in GNS or DNS.
