gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: explain pseudo hheader


From: gnunet
Subject: [lsd0001] branch master updated: explain pseudo hheader
Date: Mon, 17 Feb 2020 20:58:50 +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 0000d4f  explain pseudo hheader
0000d4f is described below

commit 0000d4f781bc0c570d8cadc39e8b7631c99da95e
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Mon Feb 17 20:54:54 2020 +0100

    explain pseudo hheader
---
 draft-schanzen-gns.html |  71 ++++++++++++++-------
 draft-schanzen-gns.txt  | 166 ++++++++++++++++++++++++------------------------
 draft-schanzen-gns.xml  |  56 ++++++++++------
 3 files changed, 168 insertions(+), 125 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 720af60..b1ce9dd 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2407,7 +2407,7 @@ table {
            0     8     16    24    32    40    48    56
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |                     NONCE                     |
-           +-----------------------------------------------|
+           +-----------------------------------------------+
            |                  PUBLIC KEY                   |
            |                                               |
            |                                               |
@@ -2497,8 +2497,9 @@ table {
 </div>
 <figcaption><a href="#figure-19" class="selfRef">Figure 
19</a></figcaption></figure>
 <p id="section-7-17">
-         In order to prove ownership over the revoked zone, the owner 
calculates
-         a signature over the following data:<a href="#section-7-17" 
class="pilcrow">¶</a></p>
+         The final revocation data object consists of a signature over the
+         public of the zone which is revoked, the zone key itself and the just
+         calculated proof-of-work:<a href="#section-7-17" 
class="pilcrow">¶</a></p>
 <div id="figure_revocationdata">
 <figure id="figure-20">
         <div class="artwork art-text alignLeft" id="section-7-18.1">
@@ -2514,8 +2515,6 @@ table {
            |                                               |
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-           |         SIZE          |       PURPOSE         | &lt;- Currently 
we do NOT publish this!
-           +-----+-----+-----+-----+-----+-----+-----+-----+
            |                  PUBLIC KEY                   |
            |                                               |
            |                                               |
@@ -2532,36 +2531,60 @@ table {
         <dt id="section-7-20.1">SIGNATURE</dt>
 <dd id="section-7-20.2">
            A 512-bit ECDSA deterministic signature compliant with
-           <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The 
signature is computed over the data
-           following the SIZE, PURPOSE and PUBLIC KEY fields.
+           <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> over the 
public zone zk of the zone
+           which is revoked and corresponds to the key used in POW.
            The signature is created using the private zone key "d" (see
            <a href="#zones" class="xref">Section 2</a>).<a 
href="#section-7-20.2" class="pilcrow">¶</a>
 </dd>
-<dt id="section-7-20.3">SIZE</dt>
+<dt id="section-7-20.3">PUBLIC KEY</dt>
 <dd id="section-7-20.4">
-           A 32-bit value containing the length of the signed data in bytes
-           (40 bytes) in network byte order.<a href="#section-7-20.4" 
class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-20.5">PURPOSE</dt>
-<dd id="section-7-20.6">
-           A 32-bit signature purpose flag. This field MUST be 3 (in network
-           byte order).<a href="#section-7-20.6" class="pilcrow">¶</a>
-</dd>
-<dt id="section-7-20.7">PUBLIC KEY</dt>
-<dd id="section-7-20.8">
            is the 256-bit public key "zk" of the zone which is being revoked 
and
            the key to be used to verify SIGNATURE. The
            wire format of this value is defined in <span>[<a href="#RFC8032" 
class="xref">RFC8032</a>]</span>,
-           Section 5.1.5.<a href="#section-7-20.8" class="pilcrow">¶</a>
+           Section 5.1.5.<a href="#section-7-20.4" class="pilcrow">¶</a>
 </dd>
-<dt id="section-7-20.9">POW</dt>
-<dd id="section-7-20.10">
-           The value of the proof of work.<a href="#section-7-20.10" 
class="pilcrow">¶</a>
+<dt id="section-7-20.5">POW</dt>
+<dd id="section-7-20.6">
+           The value of the proof of work.<a href="#section-7-20.6" 
class="pilcrow">¶</a>
 </dd>
 </dl>
 <p id="section-7-21">
          The resulting block may now be published and disseminated. The 
concrete
          dissemination and publication methods are out of scope of this 
document.<a href="#section-7-21" class="pilcrow">¶</a></p>
+<p id="section-7-22">
+         The signature over the public key covers a 32 bit pseuso header
+         conceptually prefixed to the public key. The pseudo header includes
+         the key length and signature purpose:<a href="#section-7-22" 
class="pilcrow">¶</a></p>
+<div id="figure_pkeywithpseudo">
+<figure id="figure-21">
+        <div class="artwork art-text alignLeft" id="section-7-23.1">
+<pre>
+           0     8     16    24    32    40    48    56
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |         SIZE (0x50)   |       PURPOSE (0x03)  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |                  PUBLIC KEY                   |
+           |                                               |
+           |                                               |
+           |                                               |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           </pre>
+</div>
+<figcaption><a href="#figure-21" class="selfRef">Figure 
21</a></figcaption></figure>
+</div>
+<p id="section-7-24">where:<a href="#section-7-24" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7-25">
+        <dt id="section-7-25.1">SIZE</dt>
+<dd id="section-7-25.2">
+           A 32-bit value containing the length of the signed data in bytes
+           (40 bytes) in network byte order.<a href="#section-7-25.2" 
class="pilcrow">¶</a>
+</dd>
+<dt id="section-7-25.3">PURPOSE</dt>
+<dd id="section-7-25.4">
+           A 32-bit signature purpose flag. This field MUST be 3 (in network
+           byte order).<a href="#section-7-25.4" class="pilcrow">¶</a>
+</dd>
+</dl>
 </section>
 </div>
 <div id="governance">
@@ -2684,7 +2707,7 @@ The registry shall record for each entry:<a 
href="#section-10-1" class="pilcrow"
          Served", as described in <span>[<a href="#RFC8126" 
class="xref">RFC8126</a>]</span>.
          IANA is requested to populate this registry as follows:<a 
href="#section-10-3" class="pilcrow">¶</a></p>
 <div id="figure_rrtypenums">
-<figure id="figure-21">
+<figure id="figure-22">
         <div class="artwork art-text alignLeft" id="section-10-4.1">
 <pre>
            Number   | Type            | Contact | References
@@ -2698,7 +2721,7 @@ The registry shall record for each entry:<a 
href="#section-10-1" class="pilcrow"
            FIXME We have a lot more?
            </pre>
 </div>
-<figcaption><a href="#figure-21" class="selfRef">Figure 
21</a></figcaption></figure>
+<figcaption><a href="#figure-22" class="selfRef">Figure 
22</a></figcaption></figure>
 </div>
 </section>
 </div>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index db0f57e..5fa1fd0 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -90,7 +90,7 @@ Table of Contents
    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
    11. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  25
    12. Normative References  . . . . . . . . . . . . . . . . . . . .  27
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29
 
 1.  Introduction
 
@@ -1089,7 +1089,7 @@ Internet-Draft             The GNU Name System            
 November 2019
               0     8     16    24    32    40    48    56
               +-----+-----+-----+-----+-----+-----+-----+-----+
               |                     NONCE                     |
-              +-----------------------------------------------|
+              +-----------------------------------------------+
               |                  PUBLIC KEY                   |
               |                                               |
               |                                               |
@@ -1178,8 +1178,9 @@ Schanzenbach, et al.       Expires 13 May 2020            
     [Page 21]
 Internet-Draft             The GNU Name System             November 2019
 
 
-   In order to prove ownership over the revoked zone, the owner
-   calculates a signature over the following data:
+   The final revocation data object consists of a signature over the
+   public of the zone which is revoked, the zone key itself and the just
+   calculated proof-of-work:
 
               0     8     16    24    32    40    48    56
               +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1192,8 +1193,6 @@ Internet-Draft             The GNU Name System            
 November 2019
               |                                               |
               |                                               |
               +-----+-----+-----+-----+-----+-----+-----+-----+
-              |         SIZE          |       PURPOSE         | <- Currently 
we do NOT publish this!
-              +-----+-----+-----+-----+-----+-----+-----+-----+
               |                  PUBLIC KEY                   |
               |                                               |
               |                                               |
@@ -1207,16 +1206,10 @@ Internet-Draft             The GNU Name System          
   November 2019
    where:
 
    SIGNATURE  A 512-bit ECDSA deterministic signature compliant with
-      [RFC6979].  The signature is computed over the data following the
-      SIZE, PURPOSE and PUBLIC KEY fields.  The signature is created
+      [RFC6979] over the public zone zk of the zone which is revoked and
+      corresponds to the key used in POW.  The signature is created
       using the private zone key "d" (see Section 2).
 
-   SIZE  A 32-bit value containing the length of the signed data in
-      bytes (40 bytes) in network byte order.
-
-   PURPOSE  A 32-bit signature purpose flag.  This field MUST be 3 (in
-      network byte order).
-
    PUBLIC KEY  is the 256-bit public key "zk" of the zone which is being
       revoked and the key to be used to verify SIGNATURE.  The wire
       format of this value is defined in [RFC8032], Section 5.1.5.
@@ -1227,6 +1220,13 @@ Internet-Draft             The GNU Name System           
  November 2019
    concrete dissemination and publication methods are out of scope of
    this document.
 
+   The signature over the public key covers a 32 bit pseuso header
+   conceptually prefixed to the public key.  The pseudo header includes
+   the key length and signature purpose:
+
+
+
+
 
 
 Schanzenbach, et al.       Expires 13 May 2020                 [Page 22]
@@ -1234,6 +1234,26 @@ Schanzenbach, et al.       Expires 13 May 2020           
      [Page 22]
 Internet-Draft             The GNU Name System             November 2019
 
 
+              0     8     16    24    32    40    48    56
+              +-----+-----+-----+-----+-----+-----+-----+-----+
+              |         SIZE (0x50)   |       PURPOSE (0x03)  |
+              +-----+-----+-----+-----+-----+-----+-----+-----+
+              |                  PUBLIC KEY                   |
+              |                                               |
+              |                                               |
+              |                                               |
+              +-----+-----+-----+-----+-----+-----+-----+-----+
+
+                                 Figure 21
+
+   where:
+
+   SIZE  A 32-bit value containing the length of the signed data in
+      bytes (40 bytes) in network byte order.
+
+   PURPOSE  A 32-bit signature purpose flag.  This field MUST be 3 (in
+      network byte order).
+
 8.  Determining the Root Zone and Zone Governance
 
    The resolution of a GNS name must start in a given start zone
@@ -1263,6 +1283,13 @@ Internet-Draft             The GNU Name System           
  November 2019
    Base32-encoded public zone key "zk", the root zone of the resolution
    process is implicitly given by the name:
 
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             Example name: www.example.<Base32(zk)>
             => Root zone: zk
             => Name to resolve from root zone: www.example
@@ -1282,14 +1309,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             => Entry zone: zk1
             => Name to resolve from entry zone: www.example
 
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 23]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    Finally, additional "suffix to zone" mappings MAY be configured.
    Suffix to zone key mappings SHOULD be configurable through a local
    configuration file or database by the user or system administrator.
@@ -1318,6 +1337,15 @@ Internet-Draft             The GNU Name System           
  November 2019
    IANA is requested to create an "GNU Name System Record Type"
    registry.  The registry shall record for each entry:
 
+
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    *  Type: The name of the record type (case insensitive ASCII string,
       restricted to alphanumeric characters
 
@@ -1333,19 +1361,6 @@ Internet-Draft             The GNU Name System           
  November 2019
    Served", as described in [RFC8126].  IANA is requested to populate
    this registry as follows:
 
-
-
-
-
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 24]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
               Number   | Type            | Contact | References
               ---------+-----------------+---------+---------
               65536    | PKEY            | N/A     | [This.I-D]
@@ -1356,7 +1371,7 @@ Internet-Draft             The GNU Name System            
 November 2019
               65541    | BOX             | N/A     | [This.I-D]
               FIXME We have a lot more?
 
-                                 Figure 21
+                                 Figure 22
 
 11.  Test Vectors
 
@@ -1379,6 +1394,14 @@ Internet-Draft             The GNU Name System           
  November 2019
 
             h :=
             2af3275a9cf90e54
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             f2dbf7930be76fb9
             5e7c80b1416f8ca6
             dc50ce8e1fb759b9
@@ -1394,14 +1417,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             0017c802f7d32e18
 
             q (query key) :=
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 25]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             6fce4deddc5ad681
             f4e29a3310767e3b
             8b38bc1b276ce2ba
@@ -1435,6 +1450,14 @@ Internet-Draft             The GNU Name System           
  November 2019
             0000000100059412 RR COUNT | EXPIRA-
             09ddea0f00000014  -TION    | DATA SIZE (20)
             0000000f00000000 TYPE (15=MX) | FLAGS (0)
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 26]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
             000a046d61696c07 Priority (10) |4 | mail | 7
             6578616d706c6503 example | 3
             636f6d0000000000 com | \0 | Followed by
@@ -1450,14 +1473,6 @@ Internet-Draft             The GNU Name System           
  November 2019
             afc99ba9c5a3bb54
             07e731a34680ee33
             ae0de7bfeda7d2b7
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 26]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
             8c6b854a008b1b54
             10df4f39f5ba9f46____________
             8cb514a56c0eaae0 zk_h
@@ -1491,6 +1506,14 @@ Internet-Draft             The GNU Name System           
  November 2019
               DOI 10.17487/RFC2782, February 2000,
               <https://www.rfc-editor.org/info/rfc2782>.
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 27]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,
               DOI 10.17487/RFC2119, March 1997,
@@ -1506,14 +1529,6 @@ Internet-Draft             The GNU Name System           
  November 2019
               DOI 10.17487/RFC3826, June 2004,
               <https://www.rfc-editor.org/info/rfc3826>.
 
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 27]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
               Key Derivation Function (HKDF)", RFC 5869,
               DOI 10.17487/RFC5869, May 2010,
@@ -1547,6 +1562,14 @@ Internet-Draft             The GNU Name System           
  November 2019
               DOI 10.17487/RFC8032, January 2017,
               <https://www.rfc-editor.org/info/rfc8032>.
 
+
+
+
+Schanzenbach, et al.       Expires 13 May 2020                 [Page 28]
+
+Internet-Draft             The GNU Name System             November 2019
+
+
    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
               Writing an IANA Considerations Section in RFCs", BCP 26,
               RFC 8126, DOI 10.17487/RFC8126, June 2017,
@@ -1561,15 +1584,6 @@ Internet-Draft             The GNU Name System           
  November 2019
 
 Authors' Addresses
 
-
-
-
-
-Schanzenbach, et al.       Expires 13 May 2020                 [Page 28]
-
-Internet-Draft             The GNU Name System             November 2019
-
-
    Martin Schanzenbach
    GNUnet e.V.
    Boltzmannstrasse 3
@@ -1601,20 +1615,6 @@ Internet-Draft             The GNU Name System           
  November 2019
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 
 
 
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 2a811df..eef349d 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1155,7 +1155,7 @@
            0     8     16    24    32    40    48    56
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |                     NONCE                     |
-           +-----------------------------------------------|
+           +-----------------------------------------------+
            |                  PUBLIC KEY                   |
            |                                               |
            |                                               |
@@ -1238,8 +1238,9 @@
          </artwork>
        </figure>
        <t>
-         In order to prove ownership over the revoked zone, the owner 
calculates
-         a signature over the following data:
+         The final revocation data object consists of a signature over the
+         public of the zone which is revoked, the zone key itself and the just
+         calculated proof-of-work:
        </t>
        <figure anchor="figure_revocationdata">
          <artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1254,8 +1255,6 @@
            |                                               |
            |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
-           |         SIZE          |       PURPOSE         | <- Currently we 
do NOT publish this!
-           +-----+-----+-----+-----+-----+-----+-----+-----+
            |                  PUBLIC KEY                   |
            |                                               |
            |                                               |
@@ -1270,22 +1269,12 @@
          <dt>SIGNATURE</dt>
          <dd>
            A 512-bit ECDSA deterministic signature compliant with
-           <xref target="RFC6979" />. The signature is computed over the data
-           following the SIZE, PURPOSE and PUBLIC KEY fields.
+           <xref target="RFC6979" /> over the public zone zk of the zone
+           which is revoked and corresponds to the key used in POW.
            The signature is created using the private zone key "d" (see
            <xref target="zones" />).
          </dd>
-         <dt>SIZE</dt>
-         <dd>
-           A 32-bit value containing the length of the signed data in bytes
-           (40 bytes) in network byte order.
-         </dd>
-         <dt>PURPOSE</dt>
-         <dd>
-           A 32-bit signature purpose flag. This field MUST be 3 (in network
-           byte order).
-         </dd>
-         <dt>PUBLIC KEY</dt>
+                  <dt>PUBLIC KEY</dt>
          <dd>
            is the 256-bit public key "zk" of the zone which is being revoked 
and
            the key to be used to verify SIGNATURE. The
@@ -1301,6 +1290,37 @@
          The resulting block may now be published and disseminated. The 
concrete
          dissemination and publication methods are out of scope of this 
document.
        </t>
+       <t>
+         The signature over the public key covers a 32 bit pseuso header
+         conceptually prefixed to the public key. The pseudo header includes
+         the key length and signature purpose:
+       </t>
+       <figure anchor="figure_pkeywithpseudo">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+           0     8     16    24    32    40    48    56
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |         SIZE (0x50)   |       PURPOSE (0x03)  |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |                  PUBLIC KEY                   |
+           |                                               |
+           |                                               |
+           |                                               |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           ]]></artwork>
+       </figure>
+       <t>where:</t>
+       <dl>
+         <dt>SIZE</dt>
+         <dd>
+           A 32-bit value containing the length of the signed data in bytes
+           (40 bytes) in network byte order.
+         </dd>
+         <dt>PURPOSE</dt>
+         <dd>
+           A 32-bit signature purpose flag. This field MUST be 3 (in network
+           byte order).
+         </dd>
+       </dl>
      </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]