commit 252d848b2d9d034d81c8c681dc30b3b0d854e75a
parent 79a6958f6c79ff29da1672d0e99777d8d947eda8
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 22 Dec 2021 16:58:15 +0100
fixes
Diffstat:
1 file changed, 25 insertions(+), 28 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -167,22 +167,9 @@
<t>
In GNS, any user may create and manage one or more cryptographically
secured zones (<xref target="zones"/>).
- A GNS 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 public and private zone keys using record label values.
- Specifically, the zone owner can derive private keys for each record
- set published under a label, and a
- resolver can derive the corresponding public keys.
- Without knowledge of the label values and the zone public keys, the
- different derivations are unlinkable both to the original key and to each
- other.
- This prevents zone enumeration and requires knowledge
- of both the public zone key and the label to confirm affiliation with a
- specific zone. At the same time, the blinded zone public key provides nodes
- with the ability to verifiy the integrity of the published information
- without disclosing the originating zone.
+ A set of cryptographic functions which are determined by the zone type
+ enable the creation of signatures for zone contents using blinded
+ public/private key pairs and encryption of zone contents.
</t>
<t>
A zone can be populated with mappings from labels to resource records by
@@ -194,10 +181,18 @@
</t>
<t>
Zone contents are encrypted and signed
- before being published as RRBLOCKs in a distributed key-value storage
+ before being published in a distributed key-value storage
(<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
+ using a blinded public/private key pair.
+ This blinding is realized using a deterministic key
+ derivation from
+ the original public and private zone keys using record label values.
+ Specifically, the zone owner can derive private keys for each record
+ set published under a label, and a
+ resolver can derive the corresponding 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.
@@ -209,6 +204,15 @@
<t>
Starting from a configurable root zone, names are resolved following zone
delegations which are recursively queried from the storage (<xref target="resolution"/>).
+ Without knowledge of the label values and the zone public keys, the
+ different derived keys are unlinkable both to the original key and to each
+ other.
+ This prevents zone enumeration and requires knowledge
+ of both the public zone key and the label to confirm affiliation with a
+ specific zone. At the same time, the blinded zone public key provides
+ resolvers
+ with the ability to verify the integrity of the published information
+ without disclosing the originating zone.
</t>
<t>
In the remainder of this document, the "implementer" refers to the developer building
@@ -222,15 +226,10 @@
<name>Zones</name>
<t>
A zone in GNS is defined by its zone type and zone ID.
- The zone type determines a set of cryptographic functions which
- enables the creation of signatures for zone contents using a blinded
- public/private key pairs and encryption of zone contents.
Further, each zone can be represented by a Zone Top-Level Domain (zTLD)
string.
- </t>
- <t>
In this section, the zone type, zone ID, zTLD and zone revocation is
- defined.
+ specified.
</t>
<section anchor="ztype" numbered="true" toc="default">
<name>Zone Type</name>
@@ -246,8 +245,8 @@
<t>
For any zone, d is the private zone key. zk is the public zone key.
The specific formats depends on the zone type.
- The default zone delegation record types are specified in
- <xref target="rrecords"/>.
+ The creation of zone keys for the default zone types are specificed in
+ <xref target="gnsrecords_delegation"/>.
New zone types may be specified in the future, for example if the
cryptographic mechanisms used in this document are broken.
Any zone type MUST define the following set of cryptographic functions:
@@ -662,8 +661,6 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
A GNS implementer MUST provide a mechanism to create and manage resource
records for local zones. A local zone is established by selecting a
zone type and creating a zone key pair.
- The creation of zone keys for the default zone types are specificed in
- <xref target="gnsrecords_delegation"/>.
As records may be added to each created zone, a (local) persistency
mechanism such as a database for resource records and zones must be provided.
This local zone database is used by the name resolution logic and serves
@@ -2225,7 +2222,7 @@ Number | Name | Contact | References | Comment
</t>
<figure anchor="figure_purposenums">
<artwork name="" type="" align="left" alt=""><![CDATA[
-Purpose | Name | References | Description
+Purpose | Name | References | Comment
--------+-----------------+------------+--------------------------
3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation
15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature
