commit 0000d4f781bc0c570d8cadc39e8b7631c99da95e
parent 07da6fb74b35b7a9e0d488e5f3bb46ddff7fac5c
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Mon, 17 Feb 2020 20:54:54 +0100
explain pseudo hheader
Diffstat:
3 files changed, 168 insertions(+), 125 deletions(-)
diff --git 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 | <- 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
@@ -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
@@ -1607,18 +1621,4 @@ Internet-Draft The GNU Name System November 2019
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 29]
diff --git 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>
