commit 20e233e73c5d2a93dcdcff4e2cb2d21c1392597a parent a61551d4ac4480130eb08f2a5f4119e7c2a05187 Author: Martin Schanzenbach <schanzen@gnunet.org> Date: Wed, 2 Feb 2022 19:50:23 +0100 more revocation Diffstat:
| M | draft-schanzen-gns.xml | | | 14 | +++++++------- |
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml @@ -745,13 +745,13 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62] (D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with unsynchronized clocks. The TTL added on top of the TIMESTAMP yields the - expiration date.</li> - <!-- FIXME: what if the TTL in the message disagrees with our calculations? What should be done? - What if floating point rounding errors cause a disagreement in TTL calculations? - IMO we should simply mandate that when FORWARDING a message, the sender should - use the TTL they calculated themselves. --> - <li>The current time MUST be between TIMESTAMP and - TIMESTAMP+TTL.</li> + expiration date. + Should the verifier calculate the TTL and find that it differs from + the field value, the verifier MUST continue and + use the calculated value when forwarding the revocation. + </li> + <li>The current time SHOULD be between TIMESTAMP and + TIMESTAMP+TTL. Implementations MAY process the revocation without validating this.</li> </ol> </section>