From 252d848b2d9d034d81c8c681dc30b3b0d854e75a Mon Sep 17 00:00:00 2001 From: Martin Schanzenbach Date: Wed, 22 Dec 2021 16:58:15 +0100 Subject: fixes --- draft-schanzen-gns.xml | 53 ++++++++++++++++++++++++-------------------------- 1 file changed, 25 insertions(+), 28 deletions(-) diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index 307b6fa..f00eb46 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml @@ -167,22 +167,9 @@ In GNS, any user may create and manage one or more cryptographically secured 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. A zone can be populated with mappings from labels to resource records by @@ -194,10 +181,18 @@ 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 (). 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 @@ Starting from a configurable root zone, names are resolved following zone delegations which are recursively queried from the storage (). + 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. In the remainder of this document, the "implementer" refers to the developer building @@ -222,15 +226,10 @@ Zones 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. - - In this section, the zone type, zone ID, zTLD and zone revocation is - defined. + specified.
Zone Type @@ -246,8 +245,8 @@ 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 - . + The creation of zone keys for the default zone types are specificed in + . 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 - . 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