commit c97e7ddab0826d4332aab4ddf81551445f941604
parent 9ca637f332c2a2847d6513e8d153ffdc7b8e980f
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 20 May 2022 15:27:19 +0200
some notes on usage
Diffstat:
1 file changed, 109 insertions(+), 0 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -3329,6 +3329,115 @@ Value Symbol Symbol
<li>Return record set to application.</li>
</ol>
</section>
+ <section anchor="day_in_zoneowner">
+ <name>A Day in the Life of a Zone Owner</name>
+ <t>
+ In order to become a zone owner, it is sufficient to generate
+ a zone key and a corresponding secret key.
+ At this point, the zone owner can manage GNS resource records in a
+ local zone database.
+ The resource records can then be published by a GNS implementation
+ as defined in <xref target="publish"/>.
+ </t>
+ <t>
+ In order for other users to resolve the resource records, respective
+ zone information must be disseminated first.
+ The zone owner may decide to make the zone key and labels known
+ to a selected set of users only or to make this information available
+ to the general public.
+ </t>
+ <t>
+ Sharing zone information directly with specific users not only allows
+ to potentially preserve zone and record privacy, but also allows
+ the zone owner and the user to establish strong trust relationships.
+ For example, a bank may send a customer letter with a QR code which
+ contains the GNS zone of the bank.
+ This allows the user to scan the QR code and establish a strong
+ link to the zone of the bank and with it, for example, the IP address
+ of the online banking web site.
+ </t>
+ <t>
+ Most Internet services likely want to make their zones available
+ to the general public as efficiently as possible.
+ First, it is reasonable to assume that zones which are commanding
+ high levels of reputation and trust are likely included in the
+ default suffix-to-zone mappings of implementations.
+ Hence dissemination of a zone through delegation under such zones
+ can be a viable path in order to disseminate a zone publicly.
+ For example, it is conceivable that organizations such as ICANN
+ or country-code top-level domain registrars also manage GNS zones
+ and offer registration or delegation services.
+ </t>
+ <t>
+ Following best practices in particularly those relating to
+ security and abuse mitigation are methods which allow zone owners
+ and aspiring registrars to gain a good reputation and eventually
+ trust.
+ This includes, of course, diligent protection of private zone key
+ material.
+ Formalizing such best practices is out of scope of this
+ specification and should be addressed in a separate document addressing
+ <xref target="security"/>.
+ </t>
+ </section>
+ <section>
+ <name>User-centric zone management</name>
+ <t>
+ A user is expected to install a GNS implementation if it is not already
+ provided through other means such as the operating system
+ or the browser.
+ </t>
+ <t>
+ It is expected that in any case, the implementation likely ships
+ with a configurable default suffix-to-name mapping.
+ This means that the user is able to resolve GNS names ending on a
+ zTLD or ending on a configured suffix-to-name mapping.
+ </t>
+ <t>
+ At this point the user may modify the implementation's default
+ suffix-to-name mapping.
+ This includes:
+ </t>
+ <ul>
+ <li>Deletion of mappings.</li>
+ <li>Modification of a mapping</li>
+ <li>Addition of a new mapping</li>
+ </ul>
+ <t>
+ The user may delete mappings. This may become necessary of the
+ zone owner referenced by the mapping has lost the trust of the user.
+ For example, this could be due to lax registration policies resulting
+ in phishing activities.
+ </t>
+ <t>
+ Modification and addition of new mappings are means to heal the
+ namespace perforation which would occur in the case of a deletion
+ or to simply establish a strong direct trust relationship.
+ However, this requires the user's knowledge of respective zone
+ information.
+ This information must be retrieved out of band, as illustrated in
+ <xref target="day_in_zoneowner"/>:
+ A bank may send the user a letter with a QR code which contains the
+ GNS zone of the bank.
+ Other examples include scanning the QR off the device of a friend,
+ from a storefront, or an advertisement.
+ The level of trust in the respective zone is contextual and likely
+ varies from user to user.
+ Trust in a zone provided through a letter from a bank which
+ may also include a credit card is certainly different from a zone
+ found on a random advertisement in the streets.
+ However, this trust is immediately tangible to the user and can
+ be reflected in the local naming as well.
+ </t>
+ <t>
+ User clients should facilitate the suffix-to-name modification
+ process and are ideally implemented
+ according to best practices, particular addressing applicable points
+ from <xref target="security"/>.
+ Formalizing such best practices is out of scope of this
+ specification.
+ </t>
+ </section>
</section>
<section>
<name>Test Vectors</name>
