commit 1f97560c26f81b9aba2e0492c1360061a4a95e79
parent 40d0e28b5be15ff798a94b993dcf48de52393f7c
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 7 Mar 2022 19:53:23 +0100
typos
Diffstat:
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -938,7 +938,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
being delegated to.
A zone delegation record payload contains the public key of
the zone to delegate to.
- A zone delegation record <bcp14>MUST</bcp14> have the CRTITICAL flag set
+ A zone delegation record <bcp14>MUST</bcp14> have the CRITICAL flag set
and <bcp14>MUST</bcp14> be the only non-supplemental record under a label.
There <bcp14>MAY</bcp14> be inactive records of the same type which have
the SHADOW flag set in order to facilitate smooth key rollovers.
@@ -1090,7 +1090,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
<t>
The key K and counter IV are derived from
the record label and the zone key zk using a hash-based key
- derivation function (HDKF) as defined in <xref target="RFC5869" />.
+ derivation function (HKDF) as defined in <xref target="RFC5869" />.
SHA-512 <xref target="RFC6234"/> is used for the
extraction phase and SHA-256 <xref target="RFC6234"/> for the expansion phase.
The output keying material is 32 bytes (256 bits) for the symmetric
@@ -1397,7 +1397,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
Any implementation <bcp14>SHOULD</bcp14> support all redirection record types defined here
and <bcp14>MAY</bcp14> support any number of additional redirection records defined in
the GNU Name System Record Types registry (see Section <xref target="gana"/>).
- Redirection records <bcp14>MUST</bcp14> have the CRTITICAL flag set.
+ Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set.
Not supporting some record types may consequently result in resolution failures.
This may be a valid choice if some redirection record types have been
determined to be insecure, or if an application has reasons to not
@@ -2023,7 +2023,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
record could not be processed <bcp14>SHOULD</bcp14> be returned in the error
description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
merely complicating troubleshooting for the user.
- The next steps depend on the context of the name that is beging
+ The next steps depend on the context of the name that is being
resolved:
</t>
<ul>
@@ -2085,7 +2085,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
</t>
<t>
In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14>
- implement loop detections or limit the number of recursive
+ implement loop detection or limit the number of recursive
resolution steps.
The loop detection <bcp14>MUST</bcp14> be effective even
if a REDIRECT found in GNS triggers subsequent GNS lookups via
@@ -2541,7 +2541,7 @@ NICK: john (Supplemental)
<section>
<name>Name Leakage</name>
<t>
- GNS names are indistiguishable from DNS names or other special-use
+ GNS names are indistinguishable from DNS names or other special-use
domain names <xref target="RFC6761"/>.
This poses a risk when trying to resolve a name through DNS when
it is actually a GNS name.