commit e54431f10a716a34831a5ce8963dfbb41ba60450
parent c0d9c47bf8a03b8bf6c549ef16a91e13c8c2d7a2
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 17 Jun 2022 21:29:32 +0200
petnames
Diffstat:
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -336,15 +336,33 @@
<section anchor="overview" numbered="true" toc="default">
<name>Overview</name>
<t>
+ GNS exhibits the three properties of a petname system:
+ </t>
+ <ol>
+ <li>
+ It provides global names through the concept of zone top-level
+ domains (zTLDs). As zones can be uniquely identified by their zone key
+ and are statistically unqiue, GNS names with a zTLD suffix are also
+ globally unique.
+ </li>
+ <li>
+ It provides memorable or "human-readable" names by enabling users to
+ configure local mappings from nicknames to zones.
+ Zone owners can publish their mappings
+ in order to enable namespace delegation and facilitate resolution of
+ memorable names.
+ </li>
+ <li>
+ It provides secure mapping from names to records as zone contents
+ are signed using blinded private keys and encrypted using derived
+ secret keys.
+ </li>
+ </ol>
+ <t>
In GNS, any user can create and manage one or more zones
(<xref target="zones"/>) as part of a zone master implementation.
- 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 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"/>).
A label can be mapped to a delegation record which results in the
@@ -445,7 +463,6 @@
+---------+ |
]]></artwork>
</figure>
-
<t>
In the remainder of this document, the "implementer" refers to the developer building
a GNS implementation including the resolver, zone master, and
