[lsd0001] branch master updated: revocation handling in record processing

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new fd967d3  revocation handling in record processing
fd967d3 is described below

commit fd967d3b65d9761c237475ae534f0f6625d03707
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sat Feb 19 20:32:56 2022 +0100

    revocation handling in record processing
---
 draft-schanzen-gns.xml | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 4160319..7f426ea 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -525,12 +525,6 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
    </section>
     <section anchor="revocation" numbered="true" toc="default">
        <name>Zone Revocation</name>
-       <t>
-         Whenever a resolver encounters a new GNS zone, it MUST
-         check against the local revocation list whether the respective
-         zone key has been revoked.  If the zone key was revoked, the
-         resolution MUST fail with an empty result set.
-       </t>
        <t>
          In order to revoke a zone key, a signed revocation message MUST be
          published.
@@ -915,9 +909,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
        Any implementation SHOULD support all zone types defined here and
        MAY support any number of additional delegation records defined in
        the GNU Name System Record Types registry (see <xref target="gana"/>).
-       Zone delegation records MUST have the CRTITICAL flag set.
-       Not supporting some zone types MAY result in resolution failures. This
-       MAY be a valid choice if some zone delegation record types have been
+       Not supporting some zone types will result in resolution failures in 
case
+       the respective zone type is encountered.
+       This may be a valid choice if some zone delegation record types have 
been
        determined to be cryptographically insecure.
        Zone delegation records MUST NOT be stored and published
        under the apex label.
@@ -925,8 +919,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
        value.
        The ztype defines the cryptographic primitives for the zone that is
        being delegated to.
-       A zone delegation resource record payload contains the public key of
+       A zone delegation record payload contains the public key of
        the zone to delegate to.
+       A zone delegation record MUST have the CRTITICAL flag set.
        A zone delegation record MUST be the only record under a label.
        No other records are allowed.
      </t>
@@ -2194,6 +2189,14 @@ example.com = zk2
              and the remainder of the name is not empty, resolution continues
              recursively with the remainder of the name in the
              GNS zone specified in the delegation record.
+           </t>
+           <t>
+             Whenever a resolver encounters a new GNS zone, it MUST
+             check against the local revocation list whether the respective
+             zone key has been revoked. If the zone key was revoked, the
+             resolution MUST fail with an empty result set.
+           </t>
+           <t>
              Implementations MUST NOT allow multiple different zone
              delegations under a single label.
              Implementations MAY support any subset of ztypes.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.