[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: bcp14 tags
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: bcp14 tags |
|
Date: |
Mon, 21 Feb 2022 10:41:08 +0100 |
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 dac3a45 bcp14 tags
dac3a45 is described below
commit dac3a4519641a807bf3feaec2a0b86ea02b4d6c0
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Feb 21 10:40:59 2022 +0100
bcp14 tags
---
draft-schanzen-gns.xml | 286 ++++++++++++++++++++++++-------------------------
1 file changed, 143 insertions(+), 143 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index e5644bc..2a672c6 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -198,9 +198,9 @@
list of labels concatenated with a label separator.
Names are resolved starting from the rightmost label.
GNS does not impose length restrictions on names or labels.
- However, applications MAY ensure that name and label lengths are
+ However, applications <bcp14>MAY</bcp14> ensure that name and label
lengths are
compatible with DNS and in particular IDNA <xref target="RFC5890"/>.
- In the spirit of <xref target="RFC5895"/>, applications MAY preprocess
+ In the spirit of <xref target="RFC5895"/>, applications
<bcp14>MAY</bcp14> preprocess
names and labels to ensure compatibility with DNS or support
specific user expectations, for example according to
<xref target="Unicode-UTS46"/>.
@@ -213,7 +213,7 @@
The apex label, label separator and the extension label have
special purposes in the resolution protocol which are defined
in the rest of the document.
- Zone administrators MAY disallow certain labels that may be easily
+ Zone administrators <bcp14>MAY</bcp14> disallow certain labels that
may be easily
confused with other labels through registration policies.
</dd>
<dt>Apex Label</dt>
@@ -228,7 +228,7 @@
<dt>Extension Label</dt>
<dd>
If a name ends with the extension label the rest of the name
- MUST be interpreted relative to the current zone in the resolution
process.
+ <bcp14>MUST</bcp14> be interpreted relative to the current zone in
the resolution process.
The primary use for this is in redirections where the redirection
target is defined relative to the authoritative zone of the
redirection
record (<xref target="gnsrecords_redirect"/>).
@@ -377,7 +377,7 @@
Each zone can be represented by a Zone Top-Level Domain (zTLD) string.
</t>
<t>
- A implementation SHOULD enable the user to create and manage zones.
+ A implementation <bcp14>SHOULD</bcp14> enable the user to create and
manage zones.
If this functionality is not implemented, names can still be resolved
if zone keys for the initial step in the name resolution are available
(see <xref target="resolution"/>).
@@ -390,7 +390,7 @@
The ztype determines which cryptosystem is used for the
asymmetric and symmetric key operations of the zone and the format of
the delegation record type.
- Any ztype MUST define the following set of cryptographic functions:
+ Any ztype <bcp14>MUST</bcp14> define the following set of cryptographic
functions:
</t>
<dl>
<dt>KeyGen() -> d, zk</dt>
@@ -502,7 +502,7 @@ ztype||zkey := Base32GNS-Decode(zTLD)
<t>
The zTLD can be used as-is as a rightmost label in a GNS name.
If an application wants to ensure DNS compatibility of the name,
- it MAY also represent the zTLD as follows:
+ it <bcp14>MAY</bcp14> also represent the zTLD as follows:
If the zTLD is less than or equal to 63 characters, it can
be used as a zTLD as-is.
If the zTLD is longer than 63 characters, the
@@ -512,7 +512,7 @@ ztype||zkey := Base32GNS-Decode(zTLD)
the least significant bytes in the leftmost label of the resulting
string. This allows the
resolver to determine the ztype and zTLD length from the rightmost
label and to subsequently determine how many labels the zTLD should
span.
- A GNS implementation MUST support the division of zTLD in DNS
compatible
+ A GNS implementation <bcp14>MUST</bcp14> support the division of zTLD
in DNS compatible
label lengths.
For example, assuming a zTLD of 130 characters, a viable division
would be:
@@ -525,9 +525,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<section anchor="revocation" numbered="true" toc="default">
<name>Zone Revocation</name>
<t>
- In order to revoke a zone key, a signed revocation message MUST be
+ In order to revoke a zone key, a signed revocation message
<bcp14>MUST</bcp14> be
published.
- This message MUST be signed using the private key.
+ This message <bcp14>MUST</bcp14> be signed using the private key.
The revocation message is broadcast to the network.
The specification of the broadcast mechanism is out of scope for this
document.
@@ -536,9 +536,9 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
Alternatively, revocation messages could also be distributed via a
distributed ledger or a trusted central server.
To prevent
- flooding attacks, the revocation message MUST contain a proof of work
+ flooding attacks, the revocation message <bcp14>MUST</bcp14> contain
a proof of work
(PoW).
- The revocation message including the PoW MAY be calculated
+ The revocation message including the PoW <bcp14>MAY</bcp14> be
calculated
ahead of time to support timely revocation.
</t>
<t>
@@ -675,24 +675,24 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<dd>
denotes the relative 64-bit time to live of the record in
microseconds also in network byte order.
- The field SHOULD be set to EPOCH * 1.1.
+ The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1.
If the average number of leading zeros D' is larger than
- D, then the field value MAY be increased up to
+ D, then the field value <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 MAY discard a revocation without
+ 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 MUST be determined by examining the leading zeroes in the
+ revocation <bcp14>MUST</bcp14> be determined by examining the
leading zeroes in the
POW values.
</dd>
<dt>POW_i</dt>
<dd>
The values calculated as part of the PoW, in network byte order.
- Each POW_i MUST be unique in the set of POW values.
+ Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values.
To facilitate fast verification
of uniqueness, the POW values must be given in strictly
monotonically increasing order in the message.
@@ -747,7 +747,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<dt>PURPOSE</dt>
<dd>
A 32-bit signature purpose flag.
- The value of this field MUST be 3.
+ The value of this field <bcp14>MUST</bcp14> be 3.
The value is encoded in network byte order.
It defines the context in which
the signature is created so that it cannot be reused in other parts
@@ -767,14 +767,14 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<dd>Field as defined in the revocation message above.</dd>
</dl>
<t>
- In order to verify a revocation the following steps MUST be taken:
+ In order to verify a revocation the following steps
<bcp14>MUST</bcp14> be taken:
</t>
<ol>
- <li>The signature MUST be verified against the zone key.</li>
- <li>The set of POW values MUST NOT contain duplicates which MUST be
checked by verifying that the values are strictly monotonically increasing.</li>
+ <li>The signature <bcp14>MUST</bcp14> be verified against the zone
key.</li>
+ <li>The set of POW values <bcp14>MUST</bcp14> NOT contain duplicates
which <bcp14>MUST</bcp14> be checked by verifying that the values are strictly
monotonically increasing.</li>
<li>The average number of leading zeroes D' resulting from the
provided
- POW values MUST be greater than and not equal to D. Implementers
- MUST NOT use an integer data type to calculate or represent D'.</li>
+ POW values <bcp14>MUST</bcp14> be greater than and not equal to D.
Implementers
+ <bcp14>MUST</bcp14> NOT 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
@@ -782,11 +782,11 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
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 MUST continue and
+ the TTL field value, the verifier <bcp14>MUST</bcp14> continue and
use the calculated value when forwarding the revocation.
</li>
- <li>The current time SHOULD be between TIMESTAMP and
- TIMESTAMP + validity period. Implementations MAY process the
revocation without validating this.</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>
</section>
@@ -795,7 +795,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<section anchor="rrecords" numbered="true" toc="default">
<name>Resource Records</name>
<t>
- A GNS implementation SHOULD provide a mechanism to create and manage
local
+ A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism to
create and manage local
zones as well as a persistence mechanism such as a database for resource
records.
A new local zone is established by selecting a zone type and creating a
@@ -859,11 +859,11 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
</dl>
<t>
Flags indicate metadata surrounding the resource record.
- Applications creating resource records MUST set all bits which are
+ Applications creating resource records <bcp14>MUST</bcp14> set all bits
which are
not defined as a flag to 0. Additional flags may be defined in
future protocol versions.
If an application or implementation encounters a flag which it does not
- recognize, it MUST be ignored.
+ recognize, it <bcp14>MUST</bcp14> be ignored.
Any combination of the flags specified below are valid.
<xref target="figure_flag"/>
illustrates the flag distribution in the 16-bit flag field of a
@@ -882,12 +882,12 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<dd>
If this flag is set, it indicates that processing is critical.
Implementations that do not support the record type or are otherwise
- unable to process the record MUST abort resolution upon encountering
+ unable to process the record <bcp14>MUST</bcp14> abort resolution
upon encountering
the record in the resolution process.
</dd>
<dt>SHADOW</dt>
<dd>
- If this flag is set, this record MUST be ignored by resolvers unless
all (other)
+ If this flag is set, this record <bcp14>MUST</bcp14> be ignored by
resolvers unless all (other)
records of the same record type have expired. Used to allow zone
publishers to
facilitate good performance when records change by allowing them to
put future
values of records into the storage.
@@ -906,14 +906,14 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
<name>Zone Delegation Records</name>
<t>
This section defines the initial set of zone delegation record types.
- Any implementation SHOULD support all zone types defined here and
- MAY support any number of additional delegation records defined in
+ Any implementation <bcp14>SHOULD</bcp14> support all zone types defined
here and
+ <bcp14>MAY</bcp14> support any number of additional delegation records
defined in
the GNU Name System Record Types registry (see <xref target="gana"/>).
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
+ Zone delegation records <bcp14>MUST</bcp14> NOT be stored and published
under the apex label.
A zone delegation record type value is the same as the respective ztype
value.
@@ -921,8 +921,8 @@ 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 MUST have the CRTITICAL flag set.
- A zone delegation record MUST be the only record under a label.
+ A zone delegation record <bcp14>MUST</bcp14> have the CRTITICAL flag
set.
+ A zone delegation record <bcp14>MUST</bcp14> be the only record under a
label.
No other records are allowed.
</t>
<section anchor="gnsrecords_pkey" numbered="true" toc="default">
@@ -1227,13 +1227,13 @@ ZKDF-Public(zk,label):
return zk'
]]></artwork>
<t>
- Implementers SHOULD employ a constant time scalar
+ Implementers <bcp14>SHOULD</bcp14> employ a constant time scalar
multiplication for the constructions above to protect against
timing attacks. Otherwise, timing attacks may leak private key
material if an attacker can predict when a system starts the
publication process.
<!--Also, implementers
- MUST ensure that the private key a is an ed25519 private key
+ <bcp14>MUST</bcp14> ensure that the private key a is an ed25519
private key
and specifically that "a[0] & 7 == 0" holds.-->
</t>
<t>
@@ -1256,7 +1256,7 @@ ZKDF-Public(zk,label):
co-factor are integer operations.
</t>
<t>
- The Sign(d,message) and Verify(zk,message,signature) procedures MUST
+ The Sign(d,message) and Verify(zk,message,signature) procedures
<bcp14>MUST</bcp14>
be implemented as defined in <xref target="RFC8032" />.
</t>
<t>
@@ -1265,7 +1265,7 @@ ZKDF-Public(zk,label):
As the corresponding private key to the derived private scalar d'
is not known, it is not possible to deterministically derive the
signature part R according to <xref target="RFC8032" />.
- Instead, signatures MUST be generated as follows for any given
+ Instead, signatures <bcp14>MUST</bcp14> be generated as follows for
any given
message and private zone key:
A nonce is calculated from the highest 32 bytes of the
expansion of the private key d and the blinding factor h.
@@ -1374,21 +1374,21 @@ S-Decrypt(zk,label,expiration,ciphertext):
<name>Redirection Records</name>
<t>
Redirect records may be used to redirect resolution.
- Any implementation SHOULD support all redirection record types defined
here
- and MAY support any number of additional redirection records defined in
+ 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 MUST have the CRTITICAL flag set.
- Not supporting some record types MAY result in resolution failures.
- This MAY BE a valid choice if some redirection record types have been
+ Redirection records <bcp14>MUST</bcp14> have the CRTITICAL flag set.
+ Not supporting some record types <bcp14>MAY</bcp14> result in
resolution failures.
+ This <bcp14>MAY</bcp14> BE a valid choice if some redirection record
types have been
determined to be insecure, or if an application has reasons to not
support redirection to DNS for reasons such as complexity or security.
- Redirection records MUST NOT be stored and published under the apex
label.
+ Redirection records <bcp14>MUST</bcp14> NOT be stored and published
under the apex label.
</t>
<section anchor="gnsrecords_rdr" numbered="true" toc="default">
<name>REDIRECT</name>
<t>
A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
- A REDIRECT record MUST be the only record under a label.
+ A REDIRECT record <bcp14>MUST</bcp14> be the only record under a
label.
No other records are allowed.
Details on processing of this record is defined in <xref
target="redirect_processing"/>.
@@ -1424,8 +1424,8 @@ S-Decrypt(zk,label,expiration,ciphertext):
The resource record contains a DNS name for the resolver to continue
with
in DNS followed by a DNS server. Both names are in the format defined
in
<xref target="RFC1034" /> for DNS names.
- There MAY be multiple GNS2DNS records under a label.
- There MAY also be DNSSEC DS records or any other records used to
+ There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label.
+ There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other
records used to
secure the connection with the DNS servers under the same label.
No other record types are allowed in the same record set.
A GNS2DNS DATA entry is illustrated in <xref
target="figure_gns2dnsrecord"/>.</t>
@@ -1457,16 +1457,16 @@ S-Decrypt(zk,label,expiration,ciphertext):
form or an IPv6 address in colon-hexadecimal form or a DNS name.
It may also be a relative GNS name ending with a
"+" as the rightmost label.
- The implementation MUST check the string syntactically for
+ The implementation <bcp14>MUST</bcp14> check the string
syntactically for
an IP address in the respective notation before checking for a
relative GNS name.
- If all three checks fail, the name MUST be treated as a DNS name.
+ If all three checks fail, the name <bcp14>MUST</bcp14> be treated
as a DNS name.
The value is UTF-8 encoded and 0-terminated.
</dd>
</dl>
<t>
NOTE: If an application uses DNS names obtained from GNS2DNS records
- in a DNS request they MUST first be converted to an IDNA compliant
+ in a DNS request they <bcp14>MUST</bcp14> first be converted to an
IDNA compliant
representation <xref target="RFC5890" />.
</t>
</section>
@@ -1475,7 +1475,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
<name>Auxiliary Records</name>
<t>
This section defines the initial set of auxiliary GNS record types.
Any
- implementation SHOULD be able to process the specified record types
+ implementation <bcp14>SHOULD</bcp14> be able to process the specified
record types
according to <xref target="record_processing"/>.
</t>
<section anchor="gnsrecords_leho" numbered="true" toc="default">
@@ -1519,7 +1519,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
</dl>
<t>
NOTE: If an application uses a LEHO value in an HTTP request header
- (e.g. "Host:" header) it MUST be converted to an IDNA compliant
representation
+ (e.g. "Host:" header) it <bcp14>MUST</bcp14> be converted to an IDNA
compliant representation
<xref target="RFC5890" />.
</t>
</section>
@@ -1531,7 +1531,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
This is a suggestion to other zones what label to use when creating a
delegation record (<xref target="gnsrecords_delegation" />) containing
this zone key.
- This record SHOULD only be stored under the apex label "@" but MAY be
+ This record <bcp14>SHOULD</bcp14> only be stored under the apex label
"@" but <bcp14>MAY</bcp14> be
returned with record sets under any label as a supplemental record.
<xref target="nick_processing"/> details how a resolver must process
supplemental and non-supplemental NICK records.
@@ -1552,7 +1552,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
<dt>NICKNAME</dt>
<dd>
A UTF-8 string (which is not 0-terminated) representing the
preferred
- label of the zone. This string MUST be a valid GNS label.
+ label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS
label.
</dd>
</dl>
</section>
@@ -1624,9 +1624,9 @@ S-Decrypt(zk,label,expiration,ciphertext):
<t>
Any API which allows storing a value under a 512-bit key and retrieving
one or more values from the key can be used by an implementation for
record storage.
- To be useful, the API MUST permit storing at least 176 byte values
+ To be useful, the API <bcp14>MUST</bcp14> permit storing at least 176
byte values
to be able to support the defined zone delegation record encodings,
- and SHOULD allow at least 1024 byte values.
+ and <bcp14>SHOULD</bcp14> allow at least 1024 byte values.
In the following, it is assumed that an implementation realizes two
procedures on top of a storage:
</t>
@@ -1639,8 +1639,8 @@ GET(key) -> value
record would require a revocation of the record.
In GNS, zones can only be revoked as a whole. Records automatically
expire and it is under the discretion of the storage as to when to
delete
- the record. The GNS implementation MUST NOT publish expired resource
- records. Any GNS resolver MUST discard expired records returned from
+ the record. The GNS implementation <bcp14>MUST</bcp14> NOT publish
expired resource
+ records. Any GNS resolver <bcp14>MUST</bcp14> discard expired records
returned from
the storage.
</t>
<t>
@@ -1654,7 +1654,7 @@ GET(key) -> value
ensure query privacy (see <xref target="RFC8324"/>, Section 3.5).
The storage key derivation and records
block creation is specified in the following sections.
- The implementation MUST use the PUT storage procedure in order to update
+ The implementation <bcp14>MUST</bcp14> use the PUT storage procedure in
order to update
the zone contents accordingly.
</t>
<section anchor="blinding" numbered="true" toc="default">
@@ -1685,8 +1685,8 @@ q := SHA-512 (ZKDF-Public(zk, label))
<name>The Records Block</name>
<t>
GNS records are grouped by their labels and published as a single
- block in the storage. The grouped record sets MAY be paired with any
- number of supplemental records. Supplemental records MUST have the
+ block in the storage. The grouped record sets <bcp14>MAY</bcp14> be
paired with any
+ number of supplemental records. Supplemental records
<bcp14>MUST</bcp14> have the
supplemental flag set (See <xref target="rrecords"/>).
The contained resource records are encrypted using a symmetric
encryption scheme.
@@ -1726,7 +1726,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
A 32-bit value containing the length of the block in bytes.
In network byte order.
While a 32-bit value is used,
- implementations MAY refuse to publish blocks beyond a certain
+ implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond
a certain
size significantly below 4 GB.
</dd>
<dt>ZONE TYPE</dt>
@@ -1751,9 +1751,9 @@ q := SHA-512 (ZKDF-Public(zk, label))
<dt>EXPIRATION</dt>
<dd>
Specifies when the RRBLOCK expires and the encrypted block
- SHOULD be removed from the storage and caches as it is likely stale.
- However, applications MAY continue to use non-expired individual
- records until they expire. The value MUST be set to the
+ <bcp14>SHOULD</bcp14> be removed from the storage and caches as it
is likely stale.
+ However, applications <bcp14>MAY</bcp14> continue to use
non-expired individual
+ records until they expire. The value <bcp14>MUST</bcp14> be set to
the
expiration time of the resource record contained within this block
with the
smallest expiration time.
If a records block includes shadow records, then the maximum
@@ -1797,7 +1797,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
<dt>PURPOSE</dt>
<dd>
A 32-bit signature purpose flag. The value of this
- field MUST be 15.
+ field <bcp14>MUST</bcp14> be 15.
The value is encoded in network byte order.
It defines the context in which
the signature is created so that it cannot be reused in other parts
@@ -1850,15 +1850,15 @@ q := SHA-512 (ZKDF-Public(zk, label))
</dd>
<dt>PADDING</dt>
<dd>
- When publishing an RDATA block, the implementation MUST ensure that
+ When publishing an RDATA block, the implementation
<bcp14>MUST</bcp14> ensure that
the size of the RDATA is a power of two
- using the padding field. The field MUST be set to zero and MUST be
+ using the padding field. The field <bcp14>MUST</bcp14> be set to
zero and <bcp14>MUST</bcp14> be
ignored on receipt.
As a special exception, record sets with (only) a zone delegation
record type are never padded.
- Note that a record set with a delegation record MUST NOT
+ Note that a record set with a delegation record <bcp14>MUST</bcp14>
NOT
contain other records. If other records are encountered, the whole
- record block MUST be discarded.
+ record block <bcp14>MUST</bcp14> be discarded.
</dd>
</dl>
</section>
@@ -1869,19 +1869,19 @@ q := SHA-512 (ZKDF-Public(zk, label))
Names in GNS are resolved by recursively querying the record storage.
Recursive in this context means that a resolver does not provide
intermediate results for a query.
- Instead, it MUST respond to a resolution request with either the
+ Instead, it <bcp14>MUST</bcp14> respond to a resolution request with
either the
requested resource record or an error message in case the resolution
fails.
The following sections detail how resolution is initiated and each
iteration in the resolution is processed.
</t>
<t>
- The application MAY provide a desired record type to the resolver.
+ The application <bcp14>MAY</bcp14> provide a desired record type to the
resolver.
The desired record type is used to guide processing.
For example, if a zone delegation record type is requested, the
resolution of the apex label in that zone must be skipped, as
the desired record is already found.
- The resolver implementation MUST NOT filter results according to the
desired
+ The resolver implementation <bcp14>MUST</bcp14> NOT filter results
according to the desired
record type.
Filtering of record sets is typically done by the application.
</t>
@@ -1903,19 +1903,19 @@ q := SHA-512 (ZKDF-Public(zk, label))
For names ending with a zTLD the start zone is explicitly given in the
suffix of the name to resolve.
In order to ensure uniqueness of names with zTLDs any
- implementation MUST use the given zone as start zone.
- An implementation MUST first try to interpret the rightmost label of
+ implementation <bcp14>MUST</bcp14> use the given zone as start zone.
+ An implementation <bcp14>MUST</bcp14> first try to interpret the
rightmost label of
the given name as the beginning of a zTLD (<xref target="zTLD"/>).
If the rightmost label cannot be (partially) decoded or if it does not
indicate a supported ztype, the name is treated as a normal name and
- start zone discovery MUST continue with finding a local suffix-to-zone
+ start zone discovery <bcp14>MUST</bcp14> continue with finding a
local suffix-to-zone
mapping.
If a valid ztype can be found in the rightmost label, the
- implementation MUST try to synthesize and decode the zTLD to retrieve
+ implementation <bcp14>MUST</bcp14> try to synthesize and decode the
zTLD to retrieve
the start zone key according to <xref target="zTLD"/>.
If the zTLD cannot be synthesized or decoded, the resolution of
the name fails and an error is returned to the application.
- Otherwise, the zone key MUST be used as the start zone:
+ Otherwise, the zone key <bcp14>MUST</bcp14> be used as the start zone:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.<zTLD>
@@ -1923,16 +1923,16 @@ Example name: www.example.<zTLD>
=> Name to resolve from start zone: www.example
]]></artwork>
<t>
- For names not ending with a zTLD the resolver MUST determine the start
+ For names not ending with a zTLD the resolver <bcp14>MUST</bcp14>
determine the start
zone through a local suffix-to-zone mapping.
- Suffix-to-zone mappings MUST be configurable through a local
+ Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a
local
configuration file or database by the user or system administrator.
- A suffix MAY consist of multiple GNS labels concatenated with a
+ A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels
concatenated with a
label separator.
If multiple suffixes match the name to resolve, the longest
- matching suffix MUST be used. The suffix length of two results
- MUST NOT be equal. This indicates a misconfiguration and the
- implementation MUST return an error.
+ matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two
results
+ <bcp14>MUST</bcp14> NOT be equal. This indicates a misconfiguration
and the
+ implementation <bcp14>MUST</bcp14> return an error.
The following is a non-normative example mapping of start zones:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1946,10 +1946,10 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
=> Name to resolve from start zone: www
]]></artwork>
<t>
- The process given above MAY be supplemented with other mechanisms if
+ The process given above <bcp14>MAY</bcp14> be supplemented with other
mechanisms if
the particular application requires a different process.
- If no start zone can be discovered, resolution MUST fail and an
- error MUST be returned to the application.
+ If no start zone can be discovered, resolution <bcp14>MUST</bcp14>
fail and an
+ error <bcp14>MUST</bcp14> be returned to the application.
</t>
</section>
<section anchor="recursion" numbered="true" toc="default">
@@ -1973,11 +1973,11 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
</ol>
<t>
Upon receiving the RRBLOCK from the storage, as part of verifying
the
- provided signature, the resolver MUST check that the SHA-512 hash
of the
+ provided signature, the resolver <bcp14>MUST</bcp14> check that the
SHA-512 hash of the
derived authoritative zone key zk' from the RRBLOCK matches the
query q
and that the block is not yet expired.
- If the signature does not match or the block is expired, the
RRBLOCK MUST
- be ignored and, if applicable, the storage lookup GET(q) MUST
continue to
+ If the signature does not match or the block is expired, the
RRBLOCK <bcp14>MUST</bcp14>
+ be ignored and, if applicable, the storage lookup GET(q)
<bcp14>MUST</bcp14> continue to
look for other RRBLOCKs.
</t>
</section>
@@ -1987,14 +1987,14 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
Record processing occurs once a well-formed block has been
decrypted.
In record processing, only the valid records obtained are
considered.
To filter records by validity, the resolver
- MUST at least check the expiration time and the FLAGS field of the
+ <bcp14>MUST</bcp14> at least check the expiration time and the
FLAGS field of the
respective record. In particular, SHADOW and
SUPPLEMENTAL flags may exclude the record from being considered.
If the resolver encounters a record with the CRITICAL flag set and
- does not support the record type the resolution MUST be aborted
- and an error MUST be returned. The information that the critical
- record could not be processed SHOULD be returned in the error
- description. The implementation MAY choose not to return the reason
for the failure,
+ does not support the record type the resolution <bcp14>MUST</bcp14>
be aborted
+ and an error <bcp14>MUST</bcp14> be returned. The information that
the critical
+ 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
resolved:
@@ -2031,13 +2031,13 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
Case 5:
If the remainder of the name to resolve is empty
the record set is the final result.
- If any NICK records are in the final result set, it MUST be
+ If any NICK records are in the final result set, it
<bcp14>MUST</bcp14> be
processed according to <xref target="nick_processing" />.
Otherwise, the final result set is returned.
</li>
<li>
Finally, if none of the above is applicable resolution fails and the
- resolver MUST return an empty record set.
+ resolver <bcp14>MUST</bcp14> return an empty record set.
</li>
</ul>
<section anchor="redirect_processing" numbered="true" toc="default">
@@ -2053,14 +2053,14 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
default operating system name resolution process.
This may in turn trigger a GNS name resolution process depending
on the system configuration.
- In case resolution continues in DNS, the name MUST first be
+ In case resolution continues in DNS, the name <bcp14>MUST</bcp14>
first be
converted to an IDNA compliant representation <xref
target="RFC5890" />.
</t>
<t>
- In order to prevent infinite loops, the resolver MUST
+ In order to prevent infinite loops, the resolver
<bcp14>MUST</bcp14>
implement loop detections or limit the number of recursive
resolution steps.
- The loop detection MUST be effective even
+ The loop detection <bcp14>MUST</bcp14> be effective even
if a REDIRECT found in GNS triggers subsequent GNS lookups via
the default operating system name resolution process.
</t>
@@ -2077,7 +2077,7 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
IP addresses of the specified DNS name servers.
The DNS name may have to be converted to an IDNA compliant
representation <xref target="RFC5890" /> for resolution in DNS.
- GNS2DNS records MAY
+ GNS2DNS records <bcp14>MAY</bcp14>
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.
@@ -2090,16 +2090,16 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
</t>
<t>
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
+ in which case the resolver <bcp14>MUST</bcp14> try all of them.
+ The resolver <bcp14>MAY</bcp14> try them in any order or even in
parallel.
+ If multiple GNS2DNS records are present, the DNS name
<bcp14>MUST</bcp14> be
identical for all of them, if not the resolution fails and an
- appropriate error is SHOULD be returned to the application.
+ appropriate error is <bcp14>SHOULD</bcp14> be returned to the
application.
</t>
<t>
If there are DNSSEC DS records or any other records used to
secure the connection with the DNS servers stored under the label,
- the DNS resolver SHOULD use them to secure the connection with
+ the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the
connection with
the DNS server.
</t>
<t>
@@ -2109,39 +2109,39 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
resolved by querying the DNS name server(s).
The synthesized name may have to be converted to an IDNA compliant
representation <xref target="RFC5890" /> for resolution in DNS.
- If such a conversion is not possible, the resolution MUST be
aborted
- and an error MUST be returned. The information that the critical
- record could not be processed SHOULD be returned in the error
- description. The implementation MAY choose not to return the
reason for the failure,
+ If such a conversion is not possible, the resolution
<bcp14>MUST</bcp14> be aborted
+ and an error <bcp14>MUST</bcp14> be returned. The information
that the critical
+ 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.
</t>
<t>
As the DNS servers
- specified are possibly authoritative DNS servers, the GNS
resolver MUST
- support recursive DNS resolution and MUST NOT delegate this to the
+ specified are possibly authoritative DNS servers, the GNS
resolver <bcp14>MUST</bcp14>
+ support recursive DNS resolution and <bcp14>MUST</bcp14> NOT
delegate this to the
authoritative DNS servers.
The first successful recursive name resolution result
is returned to the application.
- In addition, the resolver SHOULD return the queried DNS name as a
+ In addition, the resolver <bcp14>SHOULD</bcp14> return the
queried DNS name as a
supplemental LEHO record (see <xref target="gnsrecords_leho" />)
with a
relative expiration time of one hour.
</t>
<t>
Once the transition from GNS into DNS is made through a
GNS2DNS record, there is no "going back".
- The (possibly recursive) resolution of the DNS name MUST NOT
+ The (possibly recursive) resolution of the DNS name
<bcp14>MUST</bcp14> NOT
delegate back into GNS and should only follow the DNS
specifications.
- For example, names contained in DNS CNAME records MUST NOT be
+ For example, names contained in DNS CNAME records
<bcp14>MUST</bcp14> NOT be
interpreted as GNS names.
</t>
<t>
- GNS resolvers SHOULD offer a configuration
+ GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration
option to disable DNS processing to avoid information leakage
and provide a consistent security profile for all name
resolutions.
Such resolvers would return an empty record set upon encountering
a GNS2DNS record during the recursion. However, if GNS2DNS records
are encountered in the record set for the apex label and a
GNS2DNS record
- is explicitly requested by the application, such records MUST
+ is explicitly requested by the application, such records
<bcp14>MUST</bcp14>
still be returned, even if DNS support is disabled by the
GNS resolver configuration.
</t>
@@ -2168,20 +2168,20 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
GNS zone specified in the delegation record.
</t>
<t>
- Whenever a resolver encounters a new GNS zone, it MUST
+ Whenever a resolver encounters a new GNS zone, it
<bcp14>MUST</bcp14>
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.
+ resolution <bcp14>MUST</bcp14> fail with an empty result set.
</t>
<t>
- Implementations MUST NOT allow multiple different zone
+ Implementations <bcp14>MUST</bcp14> NOT allow multiple different
zone
delegations under a single label.
- Implementations MAY support any subset of ztypes.
+ Implementations <bcp14>MAY</bcp14> support any subset of ztypes.
Handling of
- Implementations MUST NOT process zone delegation for the apex
+ Implementations <bcp14>MUST</bcp14> NOT process zone delegation
for the apex
label "@". Upon encountering a zone delegation record under
- this label, resolution fails and an error MUST be returned. The
- implementation MAY choose not to return the reason for the
failure,
+ this label, resolution fails and an error <bcp14>MUST</bcp14> be
returned. The
+ implementation <bcp14>MAY</bcp14> choose not to return the reason
for the failure,
merely impacting troubleshooting information for the user.
</t>
<t>
@@ -2250,7 +2250,7 @@ NICK: john (Supplemental)
<name>Internationalization and Character Encoding</name>
<t>
All names in GNS are encoded in UTF-8 <xref target="RFC3629" />.
- Labels MUST be canonicalized using
+ Labels <bcp14>MUST</bcp14> be canonicalized using
Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
This does not include any DNS names found in DNS records, such as
CNAME
record data, which is internationalized through the IDNA
specifications
@@ -2263,13 +2263,13 @@ NICK: john (Supplemental)
<name>Availability</name>
<t>
In order to ensure availability of records beyond their
- absolute expiration times, implementations MAY allow to locally
+ absolute expiration times, implementations <bcp14>MAY</bcp14> allow
to locally
define relative expiration time values of records.
Records can then be published recurringly with updated
absolute expiration times by the implementation.
</t>
<t>
- Implementations MAY allow users to manage private records in
+ Implementations <bcp14>MAY</bcp14> allow users to manage private
records in
their zones that are not published in the storage.
Private records are considered just like
regular records when resolving labels in local zones,
@@ -2284,11 +2284,11 @@ NICK: john (Supplemental)
with those algorithms. The security also depends on the engineering
of the protocol used by the system to ensure that there are no
non-cryptographic ways to bypass the security of the overall system.
- This is why developers of applications managing GNS zones SHOULD
+ This is why developers of applications managing GNS zones
<bcp14>SHOULD</bcp14>
select a default ztype considered secure at the time of
releasing the software.
For applications targeting end users that are not expected to
- understand cryptography, the application developer MUST NOT leave
+ understand cryptography, the application developer
<bcp14>MUST</bcp14> NOT leave
the ztype selection of new zones to end users.
</t>
<t>
@@ -2342,24 +2342,24 @@ NICK: john (Supplemental)
ensured because each time a block is published into the storage,
its IV is
unique as the expiration time is calculated dynamically and
increases
monotonically with the system time. Still,
- an implementation MUST ensure that when relative expiration times
- are decreased, the expiration time of the next record block MUST
+ an implementation <bcp14>MUST</bcp14> ensure that when relative
expiration times
+ are decreased, the expiration time of the next record block
<bcp14>MUST</bcp14>
be after the last published block.
For records where an absolute expiration time is used, the
implementation
- MUST ensure that the expiration time is always increased when the
record
+ <bcp14>MUST</bcp14> ensure that the expiration time is always
increased when the record
data changes. For example, the expiration time on the wire may be
increased
by a single microsecond even if the user did not request a change.
In case of deletion of all resource records under a label, the
- implementation MUST keep track of the last absolute expiration time
- of the last published resource block. Implementations MAY define
+ implementation <bcp14>MUST</bcp14> keep track of the last absolute
expiration time
+ of the last published resource block. Implementations
<bcp14>MAY</bcp14> define
and use a special record type as a tombstone that preserves the last
- absolute expiration time, but then MUST take care to not publish a
+ absolute expiration time, but then <bcp14>MUST</bcp14> take care to
not publish a
block with this record.
When new records are added under this label later, the
implementation
- MUST ensure that the expiration times are after the last published
+ <bcp14>MUST</bcp14> ensure that the expiration times are after the
last published
block.
Finally, in order to ensure monotonically increasing expiration
times
- the implementation MUST keep a local record of the last time
obtained
+ the implementation <bcp14>MUST</bcp14> keep a local record of the
last time obtained
from the system clock, so as to construct a monotonic clock in case
the system clock jumps backwards.
</t>
@@ -2551,10 +2551,10 @@ NICK: john (Supplemental)
gns-registry@gnunet.org.
</t>
<t>
- Any request MUST contain a unique name and a point of contact.
- The contact information MAY be added to the registry given the consent
+ Any request <bcp14>MUST</bcp14> contain a unique name and a point of
contact.
+ The contact information <bcp14>MAY</bcp14> be added to the registry
given the consent
of the requester.
- The request MAY optionally also contain relevant references as well
+ The request <bcp14>MAY</bcp14> optionally also contain relevant
references as well
as a descriptive comment as defined above.
</t>
<t>
@@ -2950,7 +2950,7 @@ Purpose | Name | References | Comment
If the bit length of the byte string to encode is not a multiple of 5
it is padded to the next multiple with zeroes.
In order to further increase tolerance for failures in character
- recognition, the letter "U" MUST be decoded to the same value as the
+ recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the
same value as the
letter "V" in Base32GNS.
</t>
<figure anchor="CrockfordB32Encode" title="The Base32GNS Alphabet
Including the Additional U Encode Symbol.">
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: bcp14 tags,
gnunet <=