diff options
Diffstat (limited to 'draft-schanzen-gns.xml')
| -rw-r--r-- | draft-schanzen-gns.xml | 38 |
1 files changed, 21 insertions, 17 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index a90c318..01b0a05 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml @@ -37,13 +37,13 @@ <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?> -<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-20" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3"> +<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-21" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 2.26.0 --> <front> <title abbrev="The GNU Name System"> The GNU Name System </title> - <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-20"/> + <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-21"/> <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> <organization>Fraunhofer AISEC</organization> <address> @@ -2749,16 +2749,20 @@ NICK: john (Supplemental) "Single Hierarchy with a Centrally Controlled Root" and "Distribution and Management of Root Servers" as raised in <xref target="RFC8324"/>. - In the Domain Name System root zone governance is centralized at the - Internet Corporation for Assigned Names and Numbers (ICANN). - GNS can be used to leverage the transitivity in the SDSI design to - replace the trusted root with secure delegation of authority thus - making petnames useful to other users while operating under a very - strong adversary model. - By building on the ideas from SDSI, GNS allows to address a central - issue with the decentralized mapping of secure identifiers to memorable - names: namely the impossiblity of providing a global, secure and - memorable mapping without a trusted authority. + In DNS, those issues are a direct result from the centralized root + zone governance at the Internet Corporation for Assigned Names and + Numbers (ICANN) which allows it to provide globally unique names. + </t> + <t> + In GNS, start zones give users local authority over their preferred + root zone governance. + It enables users to replace or enhance a trusted root zone + configuration provided by a third party (e.g. the implementer or a + multi-stakeholder governance body like ICANN) with secure delegation of + authority using local petnames while operating under a + very strong adversary model. + In combination with zTLDs, this provides users of GNS with a global, + secure and memorable mapping without a trusted authority. </t> <t> Any GNS implementation <bcp14>MAY</bcp14> provide a default @@ -2771,15 +2775,15 @@ NICK: john (Supplemental) Technically, the GNS protocol can be used to resolve names in the namespace of the global DNS. However, this would require the respective governance bodies and - stakeholders to standardize the use of GNS for this particular use - case and publish their zones accordingly. + stakeholders (e.g. IETF and ICANN) to standardize the use of GNS for this particular use + case. </t> <t> - However, this capability means that by definition GNS names may be + However, this capability implies that GNS names may be indistinguishable from DNS names in their respective common display format <xref target="RFC8499"/> or - other special-use domain names <xref target="RFC6761"/> given - a local GNS start zone configuration that maps suffixes from the + other special-use domain names <xref target="RFC6761"/> if + a local start zone configuration maps suffixes from the global DNS to GNS zones. For applications, it is then ambiguous which name system should be used in order to resolve a given name. |