gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: start revocation


From: gnunet
Subject: [lsd0001] branch master updated: start revocation
Date: Mon, 10 Feb 2020 20:52:05 +0100

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 c182a1b  start revocation
c182a1b is described below

commit c182a1b9aa53b9b9d1b98854556ce6abc2707022
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Mon Feb 10 20:48:15 2020 +0100

    start revocation
---
 draft-schanzen-gns.html |  43 +++++++++++++--
 draft-schanzen-gns.txt  | 142 +++++++++++++++++++++++++++++++++---------------
 draft-schanzen-gns.xml  |  39 +++++++++++--
 3 files changed, 171 insertions(+), 53 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 3a810ae..57bec4a 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2246,10 +2246,10 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <a href="#section-7" class="section-number selfRef">7. </a><a 
href="#name-zone-revocation" class="section-name selfRef">Zone Revocation</a>
       </h2>
 <p id="section-7-1">
-  Whenever a recursive resolver encounters a new GNS zone, it MUST
-  check against the local revocation list whether the respective
-  zone key has been revoked.  If the zone key was revoked, the
-  resolution MUST fail with an empty result set.<a href="#section-7-1" 
class="pilcrow">¶</a></p>
+         Whenever a recursive resolver encounters a new GNS zone, it MUST
+         check against the local revocation list whether the respective
+         zone key has been revoked.  If the zone key was revoked, the
+         resolution MUST fail with an empty result set.<a href="#section-7-1" 
class="pilcrow">¶</a></p>
 <p id="section-7-2">
          In order to revoke a zone key, a signed revocation object SHOULD be
          published.
@@ -2259,7 +2259,40 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
          The revocation message including the proof-of-work MAY be calculated
          ahead of time to support timely revocation.<a href="#section-7-2" 
class="pilcrow">¶</a></p>
 <p id="section-7-3">
-         A revocation message is defined as follows:<a href="#section-7-3" 
class="pilcrow">¶</a></p>
+         The following the the basic data "REVDAT" on which the proof-of work 
is
+         calculated:<a href="#section-7-3" class="pilcrow">¶</a></p>
+<div id="figure_revocation">
+<figure id="figure-14">
+        <div class="artwork art-text alignLeft" id="section-7-4.1">
+<pre>
+           0     8     16    24    32    40    48    56
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |                     NONCE                     |
+           +-----------------------------------------------|
+           |                  PUBLIC KEY                   |
+           |                                               |
+           |                                               |
+           |                                               |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           </pre>
+</div>
+<figcaption><a href="#figure-14" class="selfRef">Figure 
14</a></figcaption></figure>
+</div>
+<p id="section-7-5">
+         A single pass in the proof-of-work algorithm is defined as follows:<a 
href="#section-7-5" class="pilcrow">¶</a></p>
+<figure id="figure-15">
+        <div class="artwork art-text alignLeft" id="section-7-6.1">
+<pre>
+         skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
+         skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", skey)
+         enc := AES (skey, skey_iv, REVDAT)
+         REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+         </pre>
+</div>
+<figcaption><a href="#figure-15" class="selfRef">Figure 
15</a></figcaption></figure>
+<p id="section-7-7">
+       The above function is called with different values for the "NONCE" in
+       "REVDAT" until the amount of leading zeroes is greater or equal 25.<a 
href="#section-7-7" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="governance">
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index b13f497..ee95795 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -85,9 +85,9 @@ Table of Contents
        6.2.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  18
    7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  19
    8.  Determining the Root Zone and Zone Governance . . . . . . . .  19
-   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
-   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
-   11. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  20
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
+   11. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  21
    12. Normative References  . . . . . . . . . . . . . . . . . . . .  23
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
 
@@ -1024,7 +1024,32 @@ Internet-Draft             The GNU Name System           
  November 2019
    work.  The revocation message including the proof-of-work MAY be
    calculated ahead of time to support timely revocation.
 
-   A revocation message is defined as follows:
+   The following the the basic data "REVDAT" on which the proof-of work
+   is calculated:
+
+              0     8     16    24    32    40    48    56
+              +-----+-----+-----+-----+-----+-----+-----+-----+
+              |                     NONCE                     |
+              +-----------------------------------------------|
+              |                  PUBLIC KEY                   |
+              |                                               |
+              |                                               |
+              |                                               |
+              +-----+-----+-----+-----+-----+-----+-----+-----+
+
+                                 Figure 14
+
+   A single pass in the proof-of-work algorithm is defined as follows:
+
+            skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
+            skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", skey)
+            enc := AES (skey, skey_iv, REVDAT)
+            REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+
+                                 Figure 15
+
+   The above function is called with different values for the "NONCE" in
+   "REVDAT" until the amount of leading zeroes is greater or equal 25.
 
 8.  Determining the Root Zone and Zone Governance
 
@@ -1033,6 +1058,14 @@ Internet-Draft             The GNU Name System           
  November 2019
    resolver may have a local start zone configured/hard-coded which
    points to a local or remote start zone key.  A resolver client may
    also determine the start zone from the suffix of the name given for
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 19]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    resolution or using information retrieved out of band.  The
    governance model of any zone is at the sole discretion of the zone
    owner.  However, the choice of start zone(s) is at the sole
@@ -1059,13 +1092,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             => Root zone: zk
             => Name to resolve from root zone: www.example
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 19]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    In GNS, users MAY own and manage their own zones.  Each local zone
    SHOULD be associated with a single GNS label, but users MAY choose to
    use longer names consisting of multiple labels.  If the name of a
@@ -1088,6 +1114,14 @@ Internet-Draft             The GNU Name System           
  November 2019
    ".".  If multiple suffixes match the name to resolve, the longest
    matching suffix MUST BE used.  The suffix length of two results
    cannot be equal, as this would indicate a misconfiguration.  If both
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    a locally managed zone and a configuration entry exist for the same
    suffix, the locally managed zone MUST have priority.
 
@@ -1113,15 +1147,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.
 
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 20]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             label := "mail"
 
             d :=
@@ -1146,6 +1171,13 @@ Internet-Draft             The GNU Name System           
  November 2019
             6668e9f684f4dc33
             6d656b27392b0fee
 
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             d_h :=
             01fb61f482c17633
             77611c4c2509e0f3
@@ -1170,14 +1202,6 @@ Internet-Draft             The GNU Name System           
  November 2019
 
             AES_IV :=
             a808b929bc9fad7a
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 21]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             686bbe3432bed77a
 
             TWOFISH_KEY :=
@@ -1202,6 +1226,14 @@ Internet-Draft             The GNU Name System           
  November 2019
             00000000
 
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             RRBLOCK :=
             055cb070e05fe6de SIGNATURE
             ad694a50e5b4dedd
@@ -1227,13 +1259,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             001fd19a6406a721
             713f0a0d
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
 12.  Normative References
 
    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
@@ -1258,6 +1283,13 @@ Internet-Draft             The GNU Name System           
  November 2019
               10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
               2003, <https://www.rfc-editor.org/info/rfc3629>.
 
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
               Advanced Encryption Standard (AES) Cipher Algorithm in the
               SNMP User-based Security Model", RFC 3826,
@@ -1283,13 +1315,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>.
 
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
-
-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
@@ -1313,6 +1338,14 @@ Authors' Addresses
    GNUnet e.V.
    Boltzmannstrasse 3
    85748 Garching
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    Germany
 
    Email: address@hidden
@@ -1341,4 +1374,27 @@ Authors' Addresses
 
 
 
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index be3c791..9d98a63 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1066,10 +1066,10 @@
      <section anchor="revocation" numbered="true" toc="default">
        <name>Zone Revocation</name>
        <t>
-        Whenever a recursive resolver encounters a new GNS zone, it MUST
-        check against the local revocation list whether the respective
-        zone key has been revoked.  If the zone key was revoked, the
-        resolution MUST fail with an empty result set.
+         Whenever a recursive resolver encounters a new GNS zone, it MUST
+         check against the local revocation list whether the respective
+         zone key has been revoked.  If the zone key was revoked, the
+         resolution MUST fail with an empty result set.
        </t>
        <t>
          In order to revoke a zone key, a signed revocation object SHOULD be
@@ -1081,8 +1081,37 @@
          ahead of time to support timely revocation.
        </t>
        <t>
-         A revocation message is defined as follows:
+         The following the the basic data "REVDAT" on which the proof-of work 
is
+         calculated:
        </t>
+       <figure anchor="figure_revocation">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+           0     8     16    24    32    40    48    56
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |                     NONCE                     |
+           +-----------------------------------------------|
+           |                  PUBLIC KEY                   |
+           |                                               |
+           |                                               |
+           |                                               |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           ]]></artwork>
+       </figure>
+       <t>
+         A single pass in the proof-of-work algorithm is defined as follows:
+       </t>
+       <figure>
+       <artwork name="" type="" align="left" alt=""><![CDATA[
+         skey := kdf_scrypt (salt="gnunet-revocation-proof-of-work", REVDAT)
+         skey_iv := iv_derive (salt="gnunet-revocation-proof-of-work", 
"gnunet-proof-of-work-iv", skey)
+         enc := AES (skey, skey_iv, REVDAT)
+         REV := kdf_scrypt(salt="gnunet-revocation-proof-of-work", enc)
+         ]]></artwork>
+     </figure>
+     <t>
+       The above function is called with different values for the "NONCE" in
+       "REVDAT" until the amount of leading zeroes is greater or equal 25.
+     </t>
      </section>
      <section anchor="governance" numbered="true" toc="default">
        <name>Determining the Root Zone and Zone Governance</name>

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



reply via email to

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