1 files changed, 72 insertions, 6 deletions

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 81923c6..1ed4743 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2462,7 +2462,7 @@ table {
                                   128 / 8)
            ALTERNATIVE:
            PRK := HKDF-Extract ("gnunet-proof-of-work-iv", K)
-           IV := HKDF-Expand (PRK, "gnunet-revocation-proof-of-work", 128 / 8);
+           IV := HKDF-Expand (PRK, "gnunet-revocation-proof-of-work", 256 / 8);
 
          </pre>
 </div>
@@ -2486,16 +2486,82 @@ table {
 </div>
 <figcaption><a href="#figure-18" class="selfRef">Figure 18</a></figcaption></figure>
 <p id="section-7-15">
-       The above EREV data object is again derived using the scrypt algorithm.
-       The proof of work is complete, if the following inequality holds:<a href="#section-7-15" class="pilcrow">¶</a></p>
+         The above EREV data object is again derived using the scrypt algorithm.
+         The proof of work is complete, if the following inequality holds:<a href="#section-7-15" class="pilcrow">¶</a></p>
 <figure id="figure-19">
         <div class="artwork art-text alignLeft" id="section-7-16.1">
 <pre>
-         scrypt(P := EREV) &lt; 2^(39)-1
+         POW := scrypt(P := EREV) &lt; 2^(39)-1
          
          </pre>
 </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>
+<div id="figure_revocationdata">
+<figure id="figure-20">
+        <div class="artwork art-text alignLeft" id="section-7-18.1">
+<pre>
+           0     8     16    24    32    40    48    56
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |                   SIGNATURE                   |
+           |                                               |
+           |                                               |
+           |                                               |
+           |                                               |
+           |                                               |
+           |                                               |
+           |                                               |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |         SIZE          |       PURPOSE         |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |                  PUBLIC KEY                   |
+           |                                               |
+           |                                               |
+           |                                               |
+           +-----+-----+-----+-----+-----+-----+-----+-----+
+           |                      POW                      |
+           +-----------------------------------------------+
+           </pre>
+</div>
+<figcaption><a href="#figure-20" class="selfRef">Figure 20</a></figcaption></figure>
+</div>
+<p id="section-7-19">where:<a href="#section-7-19" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-7-20">
+        <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.
+           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>
+<dd id="section-7-20.4">
+           A 32-bit value containing the length of the signed data 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>
+</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>
+</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>
 </section>
 </div>
 <div id="governance">
@@ -2618,7 +2684,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-20">
+<figure id="figure-21">
         <div class="artwork art-text alignLeft" id="section-10-4.1">
 <pre>
            Number   | Type            | Contact | References
@@ -2632,7 +2698,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-20" class="selfRef">Figure 20</a></figcaption></figure>
+<figcaption><a href="#figure-21" class="selfRef">Figure 21</a></figcaption></figure>
 </div>
 </section>
 </div>