gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0001] 02/02: update files


From: gnunet
Subject: [lsd0001] 02/02: update files
Date: Sun, 15 Dec 2019 19:23:49 +0100

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

commit 5f18c8152f8690b741e4869a0991fa655a261d08
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sun Dec 15 19:20:41 2019 +0100

    update files
---
 draft-schanzen-gns.html |  19 +++++----
 draft-schanzen-gns.txt  | 108 ++++++++++++++++++++++++------------------------
 2 files changed, 65 insertions(+), 62 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 8e50c32..227d8b9 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2046,25 +2046,28 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <p id="section-6.1-2">
            In each step of the recursive name resolution, there is an
            authoritative zone zk and a name to resolve which may be empty.
-           Initially, the authoritative zone is the entry zone. If the name
+           Initially, the authoritative zone is the root entry zone. If the 
name
            is empty, it is interpreted as the apex label "@".<a 
href="#section-6.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-6.1-3">
-          <li id="section-6.1-3.1">Extract the right-most label from the name 
to look up.<a href="#section-6.1-3.1" class="pilcrow">¶</a>
+<p id="section-6.1-3">
+           From here, the following steps are recursively executed, in 
order:<a href="#section-6.1-3" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal" id="section-6.1-4">
+          <li id="section-6.1-4.1">Extract the right-most label from the name 
to look up.<a href="#section-6.1-4.1" class="pilcrow">¶</a>
 </li>
-          <li id="section-6.1-3.2">Calculate q using the label and zk.<a 
href="#section-6.1-3.2" class="pilcrow">¶</a>
+          <li id="section-6.1-4.2">Calculate q using the label and zk.<a 
href="#section-6.1-4.2" class="pilcrow">¶</a>
 </li>
-          <li id="section-6.1-3.3">Perform a DHT query GET(q) to retrieve the 
RRBLOCK.<a href="#section-6.1-3.3" class="pilcrow">¶</a>
+          <li id="section-6.1-4.3">Perform a DHT query GET(q) to retrieve the 
RRBLOCK.<a href="#section-6.1-4.3" class="pilcrow">¶</a>
 </li>
-          <li id="section-6.1-3.4">Verify the RRBLOCK and decrypt the BDATA 
contained in it.<a href="#section-6.1-3.4" class="pilcrow">¶</a>
+          <li id="section-6.1-4.4">Verify and process the RRBLOCK and decrypt 
the BDATA contained
+             in it.<a href="#section-6.1-4.4" class="pilcrow">¶</a>
 </li>
         </ol>
-<p id="section-6.1-4">
+<p id="section-6.1-5">
            Upon receiving the RRBLOCK from the DHT, apart from verifying the
            provided signature, the resolver MUST check that the authoritative
            zone key was used to sign the record:
            The derived zone key "h*zk" MUST match the public key provided in
            the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT 
lookup
-           GET(q) MUST continue.<a href="#section-6.1-4" 
class="pilcrow">¶</a></p>
+           GET(q) MUST continue.<a href="#section-6.1-5" 
class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="record_processing">
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 8cf9404..4df857d 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -79,19 +79,19 @@ Table of Contents
      6.1.  Record Retrieval  . . . . . . . . . . . . . . . . . . . .  15
      6.2.  Record Processing . . . . . . . . . . . . . . . . . . . .  16
        6.2.1.  PKEY  . . . . . . . . . . . . . . . . . . . . . . . .  16
-       6.2.2.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . .  16
+       6.2.2.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . .  17
        6.2.3.  CNAME . . . . . . . . . . . . . . . . . . . . . . . .  17
-       6.2.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       6.2.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  18
        6.2.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  18
    7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  18
    8.  Root Zone Governance  . . . . . . . . . . . . . . . . . . . .  18
      8.1.  Top-level domain as local zone key  . . . . . . . . . . .  18
-     8.2.  Top-level domain maps to a local zone name  . . . . . . .  18
+     8.2.  Top-level domain maps to a local zone name  . . . . . . .  19
      8.3.  Name suffix mapped to an external zone key  . . . . . . .  19
    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
    11. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  19
-   12. Normative References  . . . . . . . . . . . . . . . . . . . .  21
+   12. Normative References  . . . . . . . . . . . . . . . . . . . .  22
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23
 
 1.  Introduction
@@ -842,8 +842,10 @@ Schanzenbach, et al.       Expires 13 May 2020             
    [Page 15]
 Internet-Draft             The GNU Name System             November 2019
 
 
-   Initially, the authoritative zone is the entry zone.  If the name is
-   empty, it is interpreted as the apex label "@".
+   Initially, the authoritative zone is the root entry zone.  If the
+   name is empty, it is interpreted as the apex label "@".
+
+   From here, the following steps are recursively executed, in order:
 
    1.  Extract the right-most label from the name to look up.
 
@@ -851,7 +853,8 @@ Internet-Draft             The GNU Name System             
November 2019
 
    3.  Perform a DHT query GET(q) to retrieve the RRBLOCK.
 
-   4.  Verify the RRBLOCK and decrypt the BDATA contained in it.
+   4.  Verify and process the RRBLOCK and decrypt the BDATA contained in
+       it.
 
    Upon receiving the RRBLOCK from the DHT, apart from verifying the
    provided signature, the resolver MUST check that the authoritative
@@ -883,11 +886,8 @@ Internet-Draft             The GNU Name System             
November 2019
    record type is PKEY, in which case the PKEY record is returned and
    the resolution is concluded without resolving the empty apex label.
 
-6.2.2.  GNS2DNS
 
-   When a resolver encounters a GNS2DNS record and the remaining name is
-   empty and the desired record type is GNS2DNS, the GNS2DNS records are
-   returned.
+
 
 
 
@@ -898,6 +898,12 @@ Schanzenbach, et al.       Expires 13 May 2020             
    [Page 16]
 Internet-Draft             The GNU Name System             November 2019
 
 
+6.2.2.  GNS2DNS
+
+   When a resolver encounters a GNS2DNS record and the remaining name is
+   empty and the desired record type is GNS2DNS, the GNS2DNS records are
+   returned.
+
    Otherwise, it is expected that the resolver first resolves the IP(s)
    of the DNS specified name server(s).  GNS2DNS records MAY contain
    numeric IPv4 or IPv6 addresses, allowing the resolver to skip this
@@ -937,13 +943,7 @@ Internet-Draft             The GNU Name System             
November 2019
    MUST implement loop detections or limit the number of recursive
    resolution steps.
 
-6.2.4.  BOX
 
-   When a BOX record is received, a GNS resolver must unbox it if the
-   name to be resolved continues with "_SERVICE._PROTO".  Otherwise, the
-   BOX record is to be left untouched.  This way, TLSA (and SRV) records
-   do not require a separate network request, and TLSA records become
-   inseparable from the corresponding address records.
 
 
 
@@ -954,6 +954,14 @@ Schanzenbach, et al.       Expires 13 May 2020             
    [Page 17]
 Internet-Draft             The GNU Name System             November 2019
 
 
+6.2.4.  BOX
+
+   When a BOX record is received, a GNS resolver must unbox it if the
+   name to be resolved continues with "_SERVICE._PROTO".  Otherwise, the
+   BOX record is to be left untouched.  This way, TLSA (and SRV) records
+   do not require a separate network request, and TLSA records become
+   inseparable from the corresponding address records.
+
 6.2.5.  VPN
 
    If the queried record type is either A or AAAA and the retrieved
@@ -995,14 +1003,6 @@ Internet-Draft             The GNU Name System            
 November 2019
               => Root zone: zk
               => Name to resolve from root zone: www.example
 
-8.2.  Top-level domain maps to a local zone name
-
-   Each local zone of the user may be associated with a single GNS
-   label.  If this label is the top-level domain (TLD) of the name to
-   resolve, resolution can from the local zone.
-
-
-
 
 
 Schanzenbach, et al.       Expires 13 May 2020                 [Page 18]
@@ -1010,6 +1010,12 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 18]
 Internet-Draft             The GNU Name System             November 2019
 
 
+8.2.  Top-level domain maps to a local zone name
+
+   Each local zone of the user may be associated with a single GNS
+   label.  If this label is the top-level domain (TLD) of the name to
+   resolve, resolution can from the local zone.
+
               Example name: www.example.gnu
               Local zones:
               fr = (d0,zk0)
@@ -1052,12 +1058,6 @@ Internet-Draft             The GNU Name System           
  November 2019
    The following represents a test vector for a record of type MX with a
    priority of 10 and the mail hostname mail.example.com.
 
-            label := "mail"
-
-            d :=
-            71199f7b287cc77a
-            0d21b5e40a77cb1d
-            f89333903b284fe8
 
 
 
@@ -1066,6 +1066,12 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 19]
 Internet-Draft             The GNU Name System             November 2019
 
 
+            label := "mail"
+
+            d :=
+            71199f7b287cc77a
+            0d21b5e40a77cb1d
+            f89333903b284fe8
             1878bf47f3b39da0
 
             zk (public zone key) :=
@@ -1108,12 +1114,6 @@ Internet-Draft             The GNU Name System           
  November 2019
 
             AES_IV :=
             a808b929bc9fad7a
-            686bbe3432bed77a
-
-            TWOFISH_KEY :=
-            c9d0089df01d0bf4
-            e4c8db4b2ccc7328
-            3425e8a811ae59d2
 
 
 
@@ -1122,6 +1122,12 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 20]
 Internet-Draft             The GNU Name System             November 2019
 
 
+            686bbe3432bed77a
+
+            TWOFISH_KEY :=
+            c9d0089df01d0bf4
+            e4c8db4b2ccc7328
+            3425e8a811ae59d2
             99e2747285d2a479
 
             TWOFISH_IV :=
@@ -1165,12 +1171,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             001fd19a6406a721
             713f0a0d
 
-12.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
-              <https://www.rfc-editor.org/info/rfc1034>.
-
 
 
 Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
@@ -1178,6 +1178,12 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 21]
 Internet-Draft             The GNU Name System             November 2019
 
 
+12.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <https://www.rfc-editor.org/info/rfc1034>.
+
    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
               November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -1221,12 +1227,6 @@ Internet-Draft             The GNU Name System           
  November 2019
               Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
               April 2013, <https://www.rfc-editor.org/info/rfc6895>.
 
-   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
-              Algorithm (DSA) and Elliptic Curve Digital Signature
-              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
-              2013, <https://www.rfc-editor.org/info/rfc6979>.
-
-
 
 
 Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
@@ -1234,6 +1234,11 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 22]
 Internet-Draft             The GNU Name System             November 2019
 
 
+   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
+              Algorithm (DSA) and Elliptic Curve Digital Signature
+              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
+              2013, <https://www.rfc-editor.org/info/rfc6979>.
+
    [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
               for Security", RFC 7748, DOI 10.17487/RFC7748, January
               2016, <https://www.rfc-editor.org/info/rfc7748>.
@@ -1280,9 +1285,4 @@ Authors' Addresses
 
 
 
-
-
-
-
-
 Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]

-- 
To stop receiving notification emails like this one, please contact
address@hidden.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]