[lsd0001] branch master updated: -misc minor edits

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 67b27a4  -misc minor edits
67b27a4 is described below

commit 67b27a4f6a60fab903f5789a991261490b3f901b
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Mon Jan 31 16:43:06 2022 +0100

    -misc minor edits
---
 draft-schanzen-gns.xml | 42 +++++++++++++++++++++++++-----------------
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 652ce02..7119820 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -197,10 +197,10 @@
        <dd>
         The rightmost label in a GNS name is a GNS Top-Level Domain (TLD).
         Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>),
-        GNS does not use a root zone as such. Instead, 
+        GNS does not expect all users to use the same global root zone. 
Instead, 
          with the exception of Zone Top-Level Domains (see below),
-         GNS TLDs are part of the configuration of the local resolver
-         (see <xref target="governance"/>) and may not be globally unique.
+         GNS TLDs are typically part of the configuration of the local resolver
+         (see <xref target="governance"/>), and may thus not be globally 
unique.
        </dd>
        <dt>Zone</dt>
        <dd>
@@ -255,13 +255,17 @@
        Zones are uniquely identified by a zone key.
        Zone contents are signed using blinded private keys and
        encrypted using derived secret keys.
-       The zone type determines the respectice set of cryptographic functions.
+       The zone type determines the respective set of cryptographic operations
+       and the wire formats for encrypted data, public keys and signatures.
      </t>
      <t>
        A zone can be populated with mappings from labels to resource records by
        its owner (<xref target="rrecords"/>).
-       Labels can be delegated to other zones using delegation records and in
-       order to support (legacy) applications as well as facilitate the use
+       A label can be mapped to a delegation record which results in the
+       corresponding subdomain being delegated to another zone. Circular
+       delegations are explicitly allowed, including delegating a subdomain
+       to its immediate parent zone.  In
+       order to support (legacy) applications as well as to facilitate the use
        of petnames, GNS defines auxiliary record types in addition to
        supporting traditional DNS records.
      </t>
@@ -271,31 +275,35 @@
        (<xref target="publish"/>).
        In this process, unique zone identification is hidden from the network
        through the use of key blinding.
-       It allows the creation of signatures for zone contents
+       Key blinding allows the creation of signatures for zone contents
        using a blinded public/private key pair.
        This blinding is realized using a deterministic key
        derivation from
-       the original zone key and corresponding private key using record label 
values.
-       Specifically, the zone owner can derive private keys for each record
+       the original zone key and corresponding private key using record label 
values
+       as blinding factors.
+       Specifically, the zone owner can derive blinded private keys for each 
record
        set published under a label, and a
-       resolver can derive the corresponding public keys.
+       resolver can derive the corresponding blinded public keys.
        It is expected that GNS implementations use distributed or decentralized
        storages such as distributed hash tables (DHT) in order to facilitate
-       availability within a network without the need of servers.
+       availability within a network without the need for dedicated 
infrastructure.
        Specification of such a distributed or decentralized storage is out of
-       scope of this document but possible existing implementations include 
those
+       scope of this document, but possible existing implementations include 
those
        based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
        <xref target="R5N" />.
      </t>
      <t>
        Names in GNS are domain names as defined in <xref target="RFC8499"/>.
-       Starting from a configurable root zone, names are resolved following 
zone
-       delegations which are recursively queried from the storage (<xref 
target="resolution"/>).
+       Starting from a configurable root zone, names are resolved by following 
zone
+       delegations. For each label in a name, the recursive GNS resolver
+       fetches the respective record from the storage layer (<xref 
target="resolution"/>).
        Without knowledge of the label values and the zone keys, the
-       different derived keys are unlinkable both to the original key and to 
each
+       different derived keys are unlinkable both to the original zone key and 
to each
        other.
-       This prevents zone enumeration and requires knowledge
-       of both the zone key and the label to confirm affiliation with a
+       This prevents zone enumeration (except via impractical online brute
+       force attacks) and requires knowledge
+       of both the zone key and the label to confirm affiliation of a
+       query or the corresponding encrypted record set with a
        specific zone. At the same time, the blinded zone key provides
        resolvers
        with the ability to verify the integrity of the published information

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.