[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: some notes on usage
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: some notes on usage |
Date: |
Fri, 20 May 2022 15:27:26 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new c97e7dd some notes on usage
c97e7dd is described below
commit c97e7ddab0826d4332aab4ddf81551445f941604
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri May 20 15:27:19 2022 +0200
some notes on usage
---
draft-schanzen-gns.xml | 109 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 109 insertions(+)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 897ca3e..5456628 100644
--- 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>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: some notes on usage,
gnunet <=