[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: misc clarifications
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: misc clarifications |
|
Date: |
Sun, 10 Nov 2019 22:01:37 +0100 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 54978df misc clarifications
54978df is described below
commit 54978df21095c17630c58b3a1d8c77bfd3694227
Author: Christian Grothoff <address@hidden>
AuthorDate: Sun Nov 10 21:59:00 2019 +0100
misc clarifications
---
draft-schanzen-gns.html | 142 +++++++++++++++++++++++++++-------------------
draft-schanzen-gns.txt | 148 +++++++++++++++++++++++++++---------------------
draft-schanzen-gns.xml | 13 +++--
3 files changed, 175 insertions(+), 128 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index b9bbbee..f9fc894 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1576,6 +1576,7 @@ caption a[href] {
<dd id="section-3.7-4.6">
a shared secret used to identify the service at the hosting peer,
used to derive the port number requird to connect to the service.
+ The service name MUST be a 0-terminated UTF-8 string.
</dd>
</dl>
</section>
@@ -1947,7 +1948,7 @@ caption a[href] {
</li>
<li id="section-6.1-2.2">Check if top-level domain maps to a local
zone name.<a href="#section-6.1-2.2" class="pilcrow">¶</a>
</li>
- <li id="section-6.1-2.3">Check if a configuration exists that maps a
prefix to an
+ <li id="section-6.1-2.3">Check if a configuration exists that maps a
suffix to an
external zone key.<a href="#section-6.1-2.3" class="pilcrow">¶</a>
</li>
</ol>
@@ -1982,19 +1983,19 @@ caption a[href] {
<a href="#section-6.1-6" class="pilcrow">¶</a>
</div>
<p id="section-6.1-7">
- If no matching local zone for the TLD is found, external prefix to
- zone mappings are checked. External prefix to zone key mapping
+ If no matching local zone for the TLD is found, external suffix to
+ zone mappings are checked. External suffix to zone key mapping
SHOULD be configurable through the GNS implementation. A mapping
- has the form "prefix = public zone key".
- The prefix may consist of multiple GNS labels concatenated with a
- ".". If multiple prefixes match the name to resolve, the longest
- prefix is chosen. The prefix length of two results cannot be equal,
+ has the form "suffix = public zone key".
+ The suffix may consist of multiple GNS labels concatenated with a
+ ".". If multiple suffixes match the name to resolve, the longest
matching
+ suffix MUST be used. The suffix length of two results cannot be
equal,
as this would indicate a misconfiguration.
<a href="#section-6.1-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-6.1-8">
<pre>
Example name: www.example.gnu
- Local prefix mappings:
+ Local suffix mappings:
gnu = zk0
example.gnu = zk1
example.com = zk2
@@ -2012,9 +2013,14 @@ caption a[href] {
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a
href="#name-record-retrieval" class="section-name selfRef">Record Retrieval</a>
</h3>
<p id="section-6.2-1">
- In order to resolve a name in GNS, a type MAY be given.
- However, filtering of record results according to type is done after
- the resource record set is retrieved.
+ When GNS name resolution is requested, a desired record type MAY be
provided
+ by the client.
+ The GNS resolver will use the desired record type to guide
processing, for
+ example by providing conversion of VPN records to A or AAAA
records, if that
+ is desired.
+
+ However, filtering of record sets according to the required record
types
+ MUST still be done by the client after the resource record set is
retrieved.
<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">
In each step of the recursive name resolution, there is an
@@ -2036,8 +2042,9 @@ caption a[href] {
Upon receiving the RRBLOCK from the DHT, apart from verifying the
provided signature, the resolver MUST check that the authoritative
zone key was used to sign the record:
- The derived zone key "h*zk" must match the public key provided in
- the RRBLOCK.
+ The derived zone key "h*zk" MUST match the public key provided in
+ the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT
lookup
+ GET(q) MUST continue.
<a href="#section-6.2-4" class="pilcrow">¶</a></p>
</section>
</div>
@@ -2048,33 +2055,34 @@ caption a[href] {
</h3>
<p id="section-6.3-1">
If the remainder of the name to resolve is not empty, the records
- result MUST consist of a single PKEY record or one or more GNS2DNS
records.
- The recursion is then continued with the PKEY record value as new
- authoritative zone or using the specified DNS server(s) as defined
- int the following.
+ result MUST consist of a single PKEY record, CNAME record,
+ or one or more GNS2DNS records. Otherwise, resolution fails
+ and GNS returns an empty record set.
<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
- If the remainder of the name to resolve is empty but we have
received
- a record set containing only a single PKEY record, the recursion is
- continued with the PKEY as authoritative zone and the empty apex
- label "@" as remaining name. If the record type to be resolved is
- PKEY, the PKEY record set is returned and the resolution is
concluded.
- <a href="#section-6.3-2" class="pilcrow">¶</a></p>
-<p id="section-6.3-3">
If the remainder of the name to resolve is empty and the records set
- does not consist of a PKEY record, the record set is the result and
- the resolution is concluded.
- <a href="#section-6.3-3" class="pilcrow">¶</a></p>
+ does not consist of a PKEY, CNAME or DNS2GNS record, the record set
+ is the result and the resolution is concluded.
+ <a href="#section-6.3-2" class="pilcrow">¶</a></p>
<div id="pkey_processing">
<section id="section-6.3.1">
<h4 id="name-pkey-2">
<a href="#section-6.3.1" class="section-number selfRef">6.3.1. </a><a
href="#name-pkey-2" class="section-name selfRef">PKEY</a>
</h4>
<p id="section-6.3.1-1">
- When a resolver encounters a PKEY record, resolution continues
+ When a resolver encounters a PKEY record and the remainder of
+ the name is non-empty, resolution continues
recursively with the remainder of the name in the newly discovered
GNS zone as defined in <a href="#entry_zone" class="xref">Section
6.1</a>.
<a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.3.1-2">
+ If the remainder of the name to resolve is empty and we have
received
+ a record set containing only a single PKEY record, the recursion
is
+ continued with the PKEY as authoritative zone and the empty apex
+ label "@" as remaining name, except in the case where the desired
+ record type is PKEY, in which case the PKEY record is returned and
+ the resolution is concluded without resolving the empty apex
label.
+ <a href="#section-6.3.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gns2dns_processing">
@@ -2083,21 +2091,37 @@ caption a[href] {
<a href="#section-6.3.2" class="section-number selfRef">6.3.2. </a><a
href="#name-gns2dns-2" class="section-name selfRef">GNS2DNS</a>
</h4>
<p id="section-6.3.2-1">
- When a resolver encounters a GNS2DNS record it is expected that
it first
+ When a resolver encounters a GNS2DNS record and the remaining name
+ is empty and the desired record type is GNS2DNS, the GNS2DNS
records
+ are returned.
+ <a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
+<p id="section-6.3.2-2">
+ Otherwise, it is expected that the resolver first
resolves the IP(s) of the DNS specified name server(s). GNS2DNS
records MAY contain numeric IPv4 or IPv6 addresses, allowing the
resolver to skip this step.
The DNS server names may themselves be names in GNS or DNS. If
the
DNS server name ends in ".+", the rest of the name is to be
interpreted
relative to the zone of the GNS2DNS record.
- Then, the DNS name from the GNS2DNS record is appended
- to the remainder of the name to be resolved, and
- resolved by querying the name server(s).
+ If the DNS server name ends in ".<Base32(zk)>", the DNS
server name
+ is to be resolved against the GNS zone zk.
+ <a href="#section-6.3.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.3.2-3">
Multiple
GNS2DNS records may be stored under the same label, in which case
the
- resolver MUST try all of them. However, if multiple GNS2DNS
records
- are present, the DNS name MUST be identical for all of them.
- <a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
+ resolver MUST try all of them. The resolver may try them in any
+ order or even in parallel. If multiple GNS2DNS records
+ are present, the DNS name MUST be identical for all of them, if
+ not the resolution fails. <a href="#section-6.3.2-3"
class="pilcrow">¶</a></p>
+<p id="section-6.3.2-4">
+ Once the IP addresses of the DNS servers have been determined,
+ the DNS name from the GNS2DNS record is appended
+ to the remainder of the name to be resolved, and
+ resolved by querying the name server(s). As the DNS servers
+ are likely authoritative DNS servers, the GNS resolver MUST
+ support recursive resolution and not delegate this to the
+ authoritative DNS servers.
+ <a href="#section-6.3.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cname_processing">
@@ -2106,21 +2130,22 @@ caption a[href] {
<a href="#section-6.3.3" class="section-number selfRef">6.3.3. </a><a
href="#name-cname" class="section-name selfRef">CNAME</a>
</h4>
<p id="section-6.3.3-1">
- Upon encountering a CNAME record, the resolver must continue the
- resolution using the CNAME unless the queried record type is a
- CNAME and we have reached the leftmost label of the name.
- Resolution may continue either in GNS if GNS is authoritative of
- the respective TLD or if the TLD is a relative zone indicator
("+")
- and we have found the CNAME in a GNS zone.
- Otherwise, the resolver should continue the resolution recursively
- through DNS.
- <a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
+ If a CNAME record is encountered, the canonical name is
+ appended to the remaining name, except if the remaining name
+ is empty and the desired record type is CNAME, in which case
+ the resolution concludes with the CNAME record.
+ If the canonical name ends in ".+",
+ resolution continues in GNS with the new name in the
+ current zone. Otherwise, the resulting name is resolved via the
+ default operating system name resolution process.
+ <a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3.3-2">
The recursive DNS resolution process may yield a CNAME as well
- which in turn may either point into the DNS or GNS namespace.
- In order to prevent infinite loops, the resolver should
- implement loop detections or limit the recursive resolution of
- CNAMEs using an upper bound.
+ which in turn may either point into the DNS or GNS namespace
+ (if it ends in a ".<Base32(zk)>").
+ In order to prevent infinite loops, the resolver MUST
+ implement loop detections or limit the number of recursive
resolution
+ steps.
<a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
@@ -2130,9 +2155,9 @@ caption a[href] {
<a href="#section-6.3.4" class="section-number selfRef">6.3.4. </a><a
href="#name-box-2" class="section-name selfRef">BOX</a>
</h4>
<p id="section-6.3.4-1">
- When a BOX record is received, a GNS resolver
- must unbox it if the name to be resolved continues with
"_SERVICE._PROTO",
- otherwise it is to be left untouched. This way, TLSA (and SRV)
+ When a BOX record is received, a GNS resolver
+ must unbox it if the name to be resolved continues with
"_SERVICE._PROTO".
+ Otherwise, the BOX record is to be left untouched. This way,
TLSA (and SRV)
records do not require a separate network request, and TLSA
records become inseparable from the corresponding address records.
<a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
@@ -2145,11 +2170,11 @@ caption a[href] {
</h4>
<p id="section-6.3.5-1">
If the queried record type is either A or AAAA and the retrieved
- record set contains at least one VPN record, the resolver must
open a
+ record set contains at least one VPN record, the resolver SHOULD
open a
tunnel and return the IPv4 or IPv6 tunnel address, respectively.
The type of tunnel depends on the contents of the VPN record data.
- No result is returned if the resolver implementation does not
- support any of the tunnnels provided in the VPN records.
+ The VPN record MUST be returned if the resolver implementation
does not
+ support setting up a tunnnel.
<a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
</section>
</div>
@@ -2163,11 +2188,12 @@ caption a[href] {
<a href="#section-7" class="section-number selfRef">7. </a><a
href="#name-zone-revocation" class="section-name selfRef">Zone Revocation</a>
</h2>
<p id="section-7-1">
- In order to revoke a zone, a signed revocation object must be
published.
- This object must be signed using the private zone key.
+ In order to revoke a zone, a signed revocation object SHOULD be
published.
+ This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message must contain a proof-of-work.
- The revocation message may be calculated ahead of time.
+ flooding attacks, the revocation message MUST contain a proof-of-work.
+ The revocation message including the proof-of-work MAY be calculated
+ ahead of time to support timely revocation.
<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
A revocation message is defined as follows:
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 2b3afef..afaa08d 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -431,7 +431,8 @@ Table of Contents
SERVICE NAME a shared secret used to identify the service at the
hosting peer, used to derive the port number requird to connect to
- the service.
+ the service. The service name MUST be a 0-terminated UTF-8
+ string.
4. Publishing Records
@@ -682,7 +683,7 @@ Table of Contents
2. Check if top-level domain maps to a local zone name.
- 3. Check if a configuration exists that maps a prefix to an external
+ 3. Check if a configuration exists that maps a suffix to an external
zone key.
If the TLD is a Base32-encoded public zone key "zk", the entry zone
@@ -705,17 +706,17 @@ Table of Contents
=> Entry zone: zk1
=> Name to resolve from entry zone: www.example
- If no matching local zone for the TLD is found, external prefix to
- zone mappings are checked. External prefix to zone key mapping
+ If no matching local zone for the TLD is found, external suffix to
+ zone mappings are checked. External suffix to zone key mapping
SHOULD be configurable through the GNS implementation. A mapping has
- the form "prefix = public zone key". The prefix may consist of
- multiple GNS labels concatenated with a ".". If multiple prefixes
- match the name to resolve, the longest prefix is chosen. The prefix
- length of two results cannot be equal, as this would indicate a
- misconfiguration.
+ the form "suffix = public zone key". The suffix may consist of
+ multiple GNS labels concatenated with a ".". If multiple suffixes
+ match the name to resolve, the longest matching suffix MUST be used.
+ The suffix length of two results cannot be equal, as this would
+ indicate a misconfiguration.
Example name: www.example.gnu
- Local prefix mappings:
+ Local suffix mappings:
gnu = zk0
example.gnu = zk1
example.com = zk2
@@ -725,9 +726,12 @@ Table of Contents
6.2. Record Retrieval
- In order to resolve a name in GNS, a type MAY be given. However,
- filtering of record results according to type is done after the
- resource record set is retrieved.
+ When GNS name resolution is requested, a desired record type MAY be
+ provided by the client. The GNS resolver will use the desired record
+ type to guide processing, for example by providing conversion of VPN
+ records to A or AAAA records, if that is desired. However, filtering
+ of record sets according to the required record types MUST still be
+ done by the client after the resource record set is retrieved.
In each step of the recursive name resolution, there is an
authoritative zone zk and a name to resolve which may be empty.
@@ -745,87 +749,103 @@ Table of Contents
Upon receiving the RRBLOCK from the DHT, apart from verifying the
provided signature, the resolver MUST check that the authoritative
zone key was used to sign the record: The derived zone key "h*zk"
- must match the public key provided in the RRBLOCK.
+ MUST match the public key provided in the RRBLOCK, otherwise the
+ RRBLOCK MUST be ignored and the DHT lookup GET(q) MUST continue.
6.3. Record Processing
If the remainder of the name to resolve is not empty, the records
- result MUST consist of a single PKEY record or one or more GNS2DNS
- records. The recursion is then continued with the PKEY record value
- as new authoritative zone or using the specified DNS server(s) as
- defined int the following.
-
- If the remainder of the name to resolve is empty but we have received
- a record set containing only a single PKEY record, the recursion is
- continued with the PKEY as authoritative zone and the empty apex
- label "@" as remaining name. If the record type to be resolved is
- PKEY, the PKEY record set is returned and the resolution is
- concluded.
+ result MUST consist of a single PKEY record, CNAME record, or one or
+ more GNS2DNS records. Otherwise, resolution fails and GNS returns an
+ empty record set.
If the remainder of the name to resolve is empty and the records set
- does not consist of a PKEY record, the record set is the result and
- the resolution is concluded.
+ does not consist of a PKEY, CNAME or DNS2GNS record, the record set
+ is the result and the resolution is concluded.
6.3.1. PKEY
- When a resolver encounters a PKEY record, resolution continues
- recursively with the remainder of the name in the newly discovered
- GNS zone as defined in Section 6.1.
+ When a resolver encounters a PKEY record and the remainder of the
+ name is non-empty, resolution continues recursively with the
+ remainder of the name in the newly discovered GNS zone as defined in
+ Section 6.1.
+
+ If the remainder of the name to resolve is empty and we have received
+ a record set containing only a single PKEY record, the recursion is
+ continued with the PKEY as authoritative zone and the empty apex
+ label "@" as remaining name, except in the case where the desired
+ record type is PKEY, in which case the PKEY record is returned and
+ the resolution is concluded without resolving the empty apex label.
6.3.2. GNS2DNS
- When a resolver encounters a GNS2DNS record it is expected that it
- first resolves the IP(s) of the DNS specified name server(s).
- GNS2DNS records MAY contain numeric IPv4 or IPv6 addresses, allowing
- the resolver to skip this step. The DNS server names may themselves
- be names in GNS or DNS. If the DNS server name ends in ".+", the
- rest of the name is to be interpreted relative to the zone of the
- GNS2DNS record. Then, the DNS name from the GNS2DNS record is
- appended to the remainder of the name to be resolved, and resolved by
- querying the name server(s). Multiple GNS2DNS records may be stored
- under the same label, in which case the resolver MUST try all of
- them. However, if multiple GNS2DNS records are present, the DNS name
- MUST be identical for all of them.
+ When a resolver encounters a GNS2DNS record and the remaining name is
+ empty and the desired record type is GNS2DNS, the GNS2DNS records are
+ returned.
+
+ Otherwise, it is expected that the resolver first resolves the IP(s)
+ of the DNS specified name server(s). GNS2DNS records MAY contain
+ numeric IPv4 or IPv6 addresses, allowing the resolver to skip this
+ step. The DNS server names may themselves be names in GNS or DNS.
+ If the DNS server name ends in ".+", the rest of the name is to be
+ interpreted relative to the zone of the GNS2DNS record. If the DNS
+ server name ends in ".<Base32(zk)>", the DNS server name is to be
+ resolved against the GNS zone zk.
+
+ Multiple GNS2DNS records may be stored under the same label, in which
+ case the resolver MUST try all of them. The resolver may try them in
+ any order or even in parallel. If multiple GNS2DNS records are
+ present, the DNS name MUST be identical for all of them, if not the
+ resolution fails.
+
+ Once the IP addresses of the DNS servers have been determined, the
+ DNS name from the GNS2DNS record is appended to the remainder of the
+ name to be resolved, and resolved by querying the name server(s). As
+ the DNS servers are likely authoritative DNS servers, the GNS
+ resolver MUST support recursive resolution and not delegate this to
+ the authoritative DNS servers.
6.3.3. CNAME
- Upon encountering a CNAME record, the resolver must continue the
- resolution using the CNAME unless the queried record type is a CNAME
- and we have reached the leftmost label of the name. Resolution may
- continue either in GNS if GNS is authoritative of the respective TLD
- or if the TLD is a relative zone indicator ("+") and we have found
- the CNAME in a GNS zone. Otherwise, the resolver should continue the
- resolution recursively through DNS.
+ If a CNAME record is encountered, the canonical name is appended to
+ the remaining name, except if the remaining name is empty and the
+ desired record type is CNAME, in which case the resolution concludes
+ with the CNAME record. If the canonical name ends in ".+",
+ resolution continues in GNS with the new name in the current zone.
+ Otherwise, the resulting name is resolved via the default operating
+ system name resolution process.
The recursive DNS resolution process may yield a CNAME as well which
- in turn may either point into the DNS or GNS namespace. In order to
- prevent infinite loops, the resolver should implement loop detections
- or limit the recursive resolution of CNAMEs using an upper bound.
+ in turn may either point into the DNS or GNS namespace (if it ends in
+ a ".<Base32(zk)>"). In order to prevent infinite loops, the resolver
+ MUST implement loop detections or limit the number of recursive
+ resolution steps.
6.3.4. BOX
When a BOX record is received, a GNS resolver must unbox it if the
- name to be resolved continues with "_SERVICE._PROTO", otherwise it is
- to be left untouched. This way, TLSA (and SRV) records do not
- require a separate network request, and TLSA records become
+ name to be resolved continues with "_SERVICE._PROTO". Otherwise, the
+ BOX record is to be left untouched. This way, TLSA (and SRV) records
+ do not require a separate network request, and TLSA records become
inseparable from the corresponding address records.
6.3.5. VPN
If the queried record type is either A or AAAA and the retrieved
- record set contains at least one VPN record, the resolver must open a
- tunnel and return the IPv4 or IPv6 tunnel address, respectively. The
- type of tunnel depends on the contents of the VPN record data. No
- result is returned if the resolver implementation does not support
- any of the tunnnels provided in the VPN records.
+ record set contains at least one VPN record, the resolver SHOULD open
+ a tunnel and return the IPv4 or IPv6 tunnel address, respectively.
+ The type of tunnel depends on the contents of the VPN record data.
+ The VPN record MUST be returned if the resolver implementation does
+ not support setting up a tunnnel.
7. Zone Revocation
- In order to revoke a zone, a signed revocation object must be
- published. This object must be signed using the private zone key.
+ In order to revoke a zone, a signed revocation object SHOULD be
+ published. This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message must contain a proof-of-
- work. The revocation message may be calculated ahead of time.
+ flooding attacks, the revocation message MUST contain a proof-of-
+ work. The revocation message including the proof-of-work MAY be
+ calculated ahead of time to support timely revocation.
A revocation message is defined as follows:
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 04ae9af..6d50f25 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -986,7 +986,7 @@
The DNS server names may themselves be names in GNS or DNS. If
the
DNS server name ends in ".+", the rest of the name is to be
interpreted
relative to the zone of the GNS2DNS record.
- If the DNS server name ends in ".<Base32(zk)>", the DNS server
name
+ If the DNS server name ends in ".<Base32(zk)>", the DNS
server name
is to be resolved against the GNS zone zk.
</t>
<t>
@@ -1025,7 +1025,7 @@
<t>
The recursive DNS resolution process may yield a CNAME as well
which in turn may either point into the DNS or GNS namespace
- (if it ends in a ".<Base32(zk)>").
+ (if it ends in a ".<Base32(zk)>").
In order to prevent infinite loops, the resolver MUST
implement loop detections or limit the number of recursive
resolution
steps.
@@ -1057,11 +1057,12 @@
<section anchor="revocation" numbered="true" toc="default">
<name>Zone Revocation</name>
<t>
- In order to revoke a zone, a signed revocation object must be
published.
- This object must be signed using the private zone key.
+ In order to revoke a zone, a signed revocation object SHOULD be
published.
+ This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
- flooding attacks, the revocation message must contain a proof-of-work.
- The revocation message may be calculated ahead of time.
+ flooding attacks, the revocation message MUST contain a proof-of-work.
+ The revocation message including the proof-of-work MAY be calculated
+ ahead of time to support timely revocation.
</t>
<t>
A revocation message is defined as follows:
--
To stop receiving notification emails like this one, please contact
address@hidden.