commit dd85c56e1a0458c395823dde89cd52fafc3aacf9
parent 0299824a7cacf6fec80f109a6e9319ea4f1dddf7
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 22 Dec 2021 16:24:54 +0100
update
Diffstat:
1 file changed, 48 insertions(+), 44 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -167,22 +167,51 @@
<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.
+ </t>
+ <t>
A zone can be populated with mappings from labels to resource records by
its owner (<xref target="rrecords"/>).
- Names can be delegated to other zones using delegation records and in
+ Labels can be delegated to other zones using delegation records and in
order to support (legacy) applications as well as facilitate the use
of petnames, GNS defines auxiliary record types in addition to
supporting traditional DNS records.
- Resource records of zones are grouped by label, encrypted and signed
- before beging published as RRBLOCK in a distributed key-value storage
+ </t>
+ <t>
+ Zone contents are encrypted and signed
+ before being published as RRBLOCKs 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 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.
+ Specification of such a distributed or decentralized storage is out of
+ scope of this document but possible existing implementations include those
+ based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
+ <xref target="R5N" />.
+ </t>
+ <t>
Starting from a configurable root zone, names are resolved following zone
delegations which are iteratively queried from the storage (<xref target="resolution"/>).
</t>
<t>
- In this document, the "implementer" refers to the developer building
+ In the remainder of this document, the "implementer" refers to the developer building
a GNS implementation including, for example, zone management tools and
name resolution components.
An "application" refers to a component which uses a GNS implementation
@@ -192,34 +221,16 @@
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
<t>
- A zone in GNS is defined by a zone type that identifies
- a cryptosystem and a public/private key pair where d is the private
- key and zk the corresponding public key.
- The contents of a zone are cryptographically signed before
- being published by its owner for resolution by other parties.
- Records are grouped by their label, and encrypted using an encryption
- key derived from the label and the zone public key (see <xref target="records_block"/>).
- Instead of the zone private key d, a GNS zone MUST support the creation
- of signatures using a blinded public/private key pair.
- This blinding is commonly realized using a deterministic key
- derivation scheme.
- Such a scheme allows the deterministic derivation of keys 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 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>
- Based on the above, the following variables are associated with a zone in
- GNS and used in the following throughout this specification.
+ In this section, the zone type, zone ID, zTLD and zone revocation is
+ defined.
</t>
<section anchor="ztype" numbered="true" toc="default">
<name>Zone Type</name>
@@ -1397,30 +1408,23 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
<t>
Any API which allows storing a value under a key and retrieving
a value from the key can be used by an implementation for record storage.
- 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.
- Specification of such a distributed or decentralized storage is out of
- scope of this document but possible existing implementations include <xref target="RFC7363" />,
- <xref target="Kademlia" />, <xref target="R5N" /> or <xref target="Ipfs" />.
- </t>
- <t>
We assume that an implementation realizes two procedures on top of a
storage:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
PUT(key,value)
-value := GET(key)
+GET(key) -> value
]]></artwork>
<t>
- In GNS, resource records are grouped by their respective labels,
+ Resource records are grouped by their respective labels,
encrypted and published together in a single resource records block
(RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK).
The key q is derived from the zone key and the respective
label of the contained records. The storage key derivation and records
block creation is specified in the following sections.
- A client implementation must enable the user the manage zones and use the
- PUT storage procedure in order to update the zone contents.
+ A client implementation MUST enable the user the manage zones.
+ The implementation MUST use the PUT storage procedure in order to update
+ the zone contents accordingly.
</t>
<section anchor="blinding" numbered="true" toc="default">
<name>The Storage Key</name>
@@ -2696,7 +2700,7 @@ cae1789d
<date year="2002"/>
</front>
</reference>
- <reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561">
+ <!--<reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561">
<front>
<title>Ipfs-content addressed, versioned, p2p file system.</title>
<author initials="J." surname="Benet" fullname="Juan Benet">
@@ -2704,7 +2708,7 @@ cae1789d
<date year="2014"/>
</front>
</reference>
-
+ -->
<reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9">
<front>
