commit 98b6997bda240d4deb9e8f65244e2352c6200019
parent 118c58412c3c34832eb304618c922ade8241b090
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 21 Feb 2022 15:48:54 +0100
more revocationing
Diffstat:
1 file changed, 38 insertions(+), 22 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -676,13 +676,6 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<bcp14>MAY</bcp14> be increased up to (D'-D) * EPOCH * 1.1.
The EPOCH is extended by
10% in order to deal with unsynchronized clocks.
- This field is informational for a verifier.
- A verifier <bcp14>MAY</bcp14> discard a revocation without
- checking the POW values or the signature if the TTL (in combination with TIMESTAMP)
- indicates that the revocation has already expired.
- The actual validity period of the
- revocation <bcp14>MUST</bcp14> be determined by examining the leading zeroes in the
- POW values.
</dd>
<dt>POW_i</dt>
<dd>
@@ -770,22 +763,45 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<li>The average number of leading zeroes D' resulting from the provided
POW values <bcp14>MUST</bcp14> be greater than and not equal to D. Implementers
<bcp14>MUST NOT</bcp14> use an integer data type to calculate or represent D'.</li>
- <li>
- The validity period of the revocation is calculated as
- (D'-D) * EPOCH * 1.1. The EPOCH is extended by
- 10% in order to deal with unsynchronized clocks.
- The validity period added on top of the TIMESTAMP yields the
- expiration date.
- Should the verifier calculate the validity and find that it differs from
- the TTL field value, the verifier <bcp14>MUST</bcp14> continue and
- use the calculated value when forwarding the revocation.
- </li>
- <li>
- The current time <bcp14>SHOULD</bcp14> be between TIMESTAMP and
- TIMESTAMP + validity period.
- Implementations <bcp14>MAY</bcp14> process the revocation without validating this.
- </li>
</ol>
+ <t>
+ The TTL field is informational.
+ A revocation <bcp14>MAY</bcp14> be discarded without checking the POW
+ values or the signature if the TTL (in combination with TIMESTAMP)
+ indicates that the revocation has already expired.
+ The actual validity period of the
+ revocation <bcp14>MUST</bcp14> be determined by examining the leading
+ zeroes in the POW values.
+ </t>
+ <t>
+ The validity period of the revocation is calculated as
+ (D'-D) * EPOCH * 1.1. The EPOCH is extended by
+ 10% in order to deal with unsynchronized clocks.
+ The validity period added on top of the TIMESTAMP yields the
+ expiration date.
+ If the current time is after the expiration date, the
+ revocation is considered stale but may still be otherwise
+ considered valid.
+ Stale revocations <bcp14>MAY</bcp14> be discarded.
+ </t>
+ <t>
+ Verified revocations <bcp14>SHOULD</bcp14> be cached locally.
+ An implementation without a local revocations cache will be unable
+ to effectively process zone revocations.
+ The implementation <bcp14>MAY</bcp14> evict revocations from the local
+ cache at any time using an eviction strategy.
+ </t>
+ <t>
+ Implementations <bcp14>MUST</bcp14> forward received revocations to
+ other peers if they are valid and not stale.
+ Should the calculated validity period differs from the TTL field value,
+ the calculated value <bcp14>MUST</bcp14> be used as TTL field value
+ when forwarding the revocation message.
+ Any valid revocation MAY be used during delegation record
+ processing (<xref target="delegation_processing"/>).
+ Implementations <bcp14>MAY</bcp14> use stale but otherwise valid
+ revocations and <bcp14>MAY</bcp14> forward them to other peers.
+ </t>
</section>
