[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated (58d255d -> 7520fd5)
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated (58d255d -> 7520fd5) |
|
Date: |
Wed, 16 Feb 2022 21:42:39 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0001.
from 58d255d ise attempt to improve sign descriptions
new 1869ead zkl lt or eq
new 8e69ca0 pow
new 140861c various minor fixes
new f8411ee pow
new 7520fd5 last ISE updates; new TVs
The 5 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-gns.xml | 301 ++++++++++++++++++++++++++-----------------------
1 file changed, 157 insertions(+), 144 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index c4d86c1..08545fc 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -475,7 +475,7 @@ zkl := Base32GNS-Encode(ztype||zkey)
ztype||zkey := Base32GNS-Decode(zkl)
]]></artwork>
<t>
- If zkl is less than 63 characters, it can directly be
+ If zkl is less than or equal to 63 characters, it can directly be
used as a zTLD.
If zkl is longer than 63 characters, the
zTLD is constructed by dividing zkl into smaller labels separated by
the
@@ -582,7 +582,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
</dd>
</dl>
<t>
- Traditionally, PoW schemes require to find a POW value such that
+ Usually, PoW schemes require to find one POW value such that
at least D leading zeroes are found in the hash result.
D is then referred to as the difficulty of the PoW.
In order to reduce the variance in time it takes to calculate the
@@ -650,12 +650,20 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<dt>TTL</dt>
<dd>
denotes the relative 64-bit time to live of the record in
- microseconds also in network byte order. This field is informational
- for a verifier. A verifier MAY discard a revocation without
+ microseconds also in network byte order.
+ The field SHOULD 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'-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
checking the POW values or the signature if the TTL (in combination
with TIMESTAMP)
- indicates that the revocation has already expired. However, the
actual TTL of the
- revocation must be determined by examining the leading zeroes in the
- proof of work calculation.
+ indicates that the revocation has already expired.
+ The actual validity period of the
+ revocation MUST be determined by examining the leading zeroes in the
+ POW values.
</dd>
<dt>POW_i</dt>
<dd>
@@ -743,17 +751,18 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<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>
- <li>The validation period (TTL) of the revocation is calculated as
+ <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 TTL added on top of the TIMESTAMP yields the
- expiration date.
- Should the verifier calculate the TTL and find that it differs from
- the field value, the verifier MUST continue and
+ 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
use the calculated value when forwarding the revocation.
</li>
<li>The current time SHOULD be between TIMESTAMP and
- TIMESTAMP+TTL. Implementations MAY process the revocation without
validating this.</li>
+ TIMESTAMP + validity period. Implementations MAY process the
revocation without validating this.</li>
</ol>
</section>
@@ -762,13 +771,14 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
<section anchor="rrecords" numbered="true" toc="default">
<name>Resource Records</name>
<t>
- A GNS implementer SHOULD provide a mechanism to create and manage
resource
- records for local zones. A new local zone is established by selecting a
- zone type and creating a zone key pair.
- As records may be added to each zone by its owner, a (local) persistence
- mechanism such as a database for resource records and zones SHOULD be
provided.
- This local zone database is used by the name resolution logic and serves
- as a basis for publishing zones into the GNS storage (see <xref
target="publish"/>).
+ A GNS implementation SHOULD 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
+ zone key pair.
+ If this mechanism is not implemented, name resolution is
+ limited to non-local start zones (<xref target="governance"/>)
+ and no zones can be published in the storage (<xref target="publish"/>).
</t>
<t>
A GNS resource record holds the data of a specific record in a zone.
@@ -829,13 +839,14 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
future protocol versions.
If an application or implementation encounters a flag which it does not
recognize, it MUST 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
resource record:
</t>
<figure anchor="figure_flag" title="The Resource Record Flag Wire
Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
-0 13 14 15 16
+0 13 14 15
+--------...+-------------+-------+---------+
| Reserved |SUPPLEMENTAL |SHADOW |CRITICAL |
+--------...+-------------+-------+---------+
@@ -846,12 +857,12 @@ zTLD := zkl[126..129].zkl[63..125].zkl[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 MUST abort resolution upon encountering
the record in the resolution process.
</dd>
<dt>SHADOW</dt>
<dd>
- If this flag is set, this record should be ignored by resolvers
unless all (other)
+ If this flag is set, this record MUST 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.
@@ -863,8 +874,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
This is a supplemental record. It is provided in addition to the
other records. This flag indicates that this record is not explicitly
managed alongside the other records under the respective name but
- may be useful for the application. This flag should only be
encountered
- by a resolver for records obtained from the storage.
+ may be useful for the application.
</dd>
</dl>
<section anchor="gnsrecords_delegation" numbered="true" toc="default">
@@ -876,7 +886,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
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
+ 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.
@@ -1017,7 +1027,6 @@ VerifyDerived(zk,label,message,signature):
The S-Encrypt() and S-Decrypt() functions use AES in counter mode
as defined in <xref target="MODES" /> (CTR-AES-256):
</t>
- <figure anchor="figure_senc_pkey" title="The PKEY S-Encrypt Procedure.">
<artwork name="" type="" align="left" alt=""><![CDATA[
S-Encrypt(zk,label,expiration,plaintext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
@@ -1026,10 +1035,7 @@ S-Encrypt(zk,label,expiration,plaintext):
NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
IV := NONCE || expiration || 0x0000000000000001
return CTR-AES256(K, IV, plaintext)
- ]]></artwork>
- </figure>
- <figure anchor="figure_sdec_pkey" title="The PKEY S-Decrypt Procedure.">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+
S-Decrypt(zk,label,expiration,ciphertext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
@@ -1038,7 +1044,6 @@ S-Decrypt(zk,label,expiration,ciphertext):
IV := NONCE || expiration || 0x0000000000000001
return CTR-AES256(K, IV, ciphertext)
]]></artwork>
- </figure>
<t>
The key K and counter IV are derived from
the record label and the zone key zk using a hash-based key
@@ -1439,7 +1444,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
</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 punycode
+ in a DNS request they MUST first be converted to an IDNA punycode
representation <xref target="RFC5891" />.
</t>
</section>
@@ -1453,6 +1458,9 @@ S-Decrypt(zk,label,expiration,ciphertext):
</t>
<section anchor="gnsrecords_leho" numbered="true" toc="default">
<name>LEHO</name>
+ <t>
+ This record is used to provide LEgacy HOstnames.
+ </t>
<t>
Applications can use the GNS to lookup IPv4 or IPv6 addresses of
internet services.
@@ -1466,10 +1474,12 @@ S-Decrypt(zk,label,expiration,ciphertext):
Using a GNS name for the "Host"-header may not work as
it may not be globally unique. Furthermore, even if uniqueness is
not an issue, the legacy service might not even be aware of GNS.
-
+ </t>
+ <t>
A LEHO resource record is expected to be found together in a single
resource record with an IPv4 or IPv6 address.
- A LEHO DATA entry is illustrated in <xref
target="figure_lehorecord"/>.</t>
+ A LEHO DATA entry is illustrated in <xref
target="figure_lehorecord"/>.
+ </t>
<figure anchor="figure_lehorecord" title="The LEHO DATA Wire Format.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
@@ -1489,15 +1499,15 @@ 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 punycode
representation
+ (e.g. "Host:" header) it MUST be converted to an IDNA punycode
representation
<xref target="RFC5891" />.
</t>
</section>
<section anchor="gnsrecords_nick" numbered="true" toc="default">
<name>NICK</name>
<t>
- Nickname records can be used by zone administrators to publish an
- the label that a zone prefers to have used when it is referred to.
+ Nickname records can be used by zone administrators to publish a
+ label that a zone prefers to have used when it is referred to.
This is a suggestion to other zones what label to use when creating a
delegation record (<xref target="gnsrecords_delegation" />) containing
this zone key.
@@ -1522,7 +1532,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 NOT include a "." character.
+ label of the zone. This string MUST be a valid GNS label.
</dd>
</dl>
</section>
@@ -1565,7 +1575,7 @@ S-Decrypt(zk,label,expiration,ciphertext):
<dl>
<dt>PROTO</dt>
<dd>
- the 16-bit protocol number, e.g. 6 for tcp.
+ the 16-bit protocol number, e.g. 6 for TCP.
Note that values
below 2^8 are reserved for allocation via IANA <xref
target="RFC5237" />,
while values above 2^8 are allocated by the
@@ -1662,7 +1672,7 @@ q := SHA-512 (ZKDF-Public(zk, label))
supplemental flag set (See <xref target="rrecords"/>).
The contained resource records are encrypted using a symmetric
encryption scheme.
- A GNS implementation publish RRBLOCKs
+ A GNS implementation publishes RRBLOCKs
in accordance to the properties and recommendations of the underlying
storage. This may include a periodic refresh operation to ensure the
availability of the published RRBLOCKs.
@@ -1695,14 +1705,15 @@ q := SHA-512 (ZKDF-Public(zk, label))
<dl>
<dt>SIZE</dt>
<dd>
- A 32-bit value containing the length of the block.
+ 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
size significantly below 4 GB.
</dd>
<dt>ZONE TYPE</dt>
<dd>
- is the 32-bit ztype.
+ is the 32-bit ztype. In network byte order.
</dd>
<dt>ZONE KEY</dt>
<dd>
@@ -1976,7 +1987,7 @@ example.com = zk2
<section anchor="record_processing" numbered="true" toc="default">
<name>Record Processing</name>
<t>
- Record processing occurs once a well-formed block was decrypted.
+ 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 of the
@@ -2290,7 +2301,7 @@ NICK: john (Supplemental)
<t>
GNS PKEY zone keys use ECDSA over Ed25519.
This is an unconventional choice,
- as ECDSA is usually used with other curves. However, traditional
+ as ECDSA is usually used with other curves. However, standardized
ECDSA curves are problematic for a range of reasons described in
the Curve25519 and EdDSA papers. Using EdDSA directly is also
not possible, as a hash function is used on the private key which
@@ -2420,7 +2431,7 @@ NICK: john (Supplemental)
Zone administrators are advised to pre-generate zone revocations
and to securely store the revocation information in case the zone
key is lost, compromised or replaced in the future.
- Pre-calculated revocations may become invalid due to expirations
+ Pre-calculated revocations may cease to be valid due to expirations
or protocol changes such as epoch adjustments.
Consequently, implementers and users must take precautions in order
to manage revocations accordingly.
@@ -2524,8 +2535,9 @@ NICK: john (Supplemental)
as a descriptive comment as defined above.
</t>
<t>
- GANA is requested to populate this registry as listed in
- <xref target="figure_rrtypenums"/>.
+ GANA has assigned numbers for the record types defined in this
+ specification in the "GNU Name System Record Types" registry
+ as listed in <xref target="figure_rrtypenums"/>.
</t>
<figure anchor="figure_rrtypenums" title="The GANA Resource Record
Registry.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -2541,8 +2553,9 @@ Number | Name | Contact | References | Comment
]]></artwork>
</figure>
<t>
- GANA is requested to amend the "GNUnet Signature Purpose" registry
- as illustrated in <xref target="figure_purposenums"/>.
+ GANA has assigned signature purposes in its
+ "GNUnet Signature Purpose" registry as listed in
+ <xref target="figure_purposenums"/>.
</t>
<figure anchor="figure_purposenums" title="Requested Changes in the
GANA GNUnet Signature Purpose Registry.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -3023,7 +3036,7 @@ b928158000000001
Encryption key (K):
864e7138eae7fd91
a30136899c132b23
-acebd2cef43cb19
+acebdb2cef43cb19
f6bf55b67db9b3b3
Storage key (q):
@@ -3107,7 +3120,7 @@ DATA:
e6849be7a7b0
Record #2
-EXPIRATION: 6089306424
+EXPIRATION: 6131101992
DATA_SIZE: 11
TYPE: 16
FLAGS: 4004
@@ -3124,7 +3137,7 @@ RDATA:
00b00f81b7449b40
0006800000010001
e6849be7a7b00000
-00016af37138000b
+00016d713128000b
4004000000104865
6c6c6f20576f726c
6400000000000000
@@ -3135,8 +3148,8 @@ e6849be7a7b00000
0000000000000000
Encryption NONCE|EXPIRATION|BLOCK COUNTER:
-a5df4a330005d816
-0d595e8900000001
+a5df4a330005d82a
+1a7efea100000001
Encryption key (K):
39a8824c4da40242
@@ -3155,22 +3168,22 @@ d85f2fed85e170be
ee86bf67ce2b9ece
BDATA:
-83df3617de6bbd8a
-887e6ddca9755edd
-fd56b4a39d07b9a8
-1f285d004ba567b2
-40c9766411e40fc7
-8627f6b372486f99
-215875f5b8745879
-394f61a10f770922
-3c94b04d93d16cdc
-0a072402e926512f
-08cc632ed7310018
-69550cacac78d9d2
-0d6dff70d329c84f
-a6fc8e78f64188da
-4a217ebfae374937
-c62121526e85d97c
+158cb30b44e088bc
+7def82f8a0428512
+de3bebd23772c7f0
+51269662f4046d14
+6f40ae5bf3713121
+9684e314962e23ba
+5dae79056d9e66ac
+a296736986aa8f91
+7e2ab5055ed6cc2b
+44835bb00c4a57d9
+f400d864cb1587ac
+5078d9e4b98021fb
+2719c8a3ca268fc2
+94efe588bd622423
+eb3b8e67af1a5185
+a1fcb58e99b730cc
RRBLOCK:
000000f000010000
@@ -3178,31 +3191,31 @@ ddef91ac40ad25e3
6b65242789ee9662
e195ced12e76245e
10ebc70bbe089906
-01f1f20d0dd97f38
-7d726e47046f5bdc
-1158724a2f1ccf39
-ecfd0e918351e2ea
-0696cc286dfb1722
-ed0f4ea9da83bbcf
-5dd4a2842fe5bb64
-17ae3602a06527c4
-0005d8160d595e89
-83df3617de6bbd8a
-887e6ddca9755edd
-fd56b4a39d07b9a8
-1f285d004ba567b2
-40c9766411e40fc7
-8627f6b372486f99
-215875f5b8745879
-394f61a10f770922
-3c94b04d93d16cdc
-0a072402e926512f
-08cc632ed7310018
-69550cacac78d9d2
-0d6dff70d329c84f
-a6fc8e78f64188da
-4a217ebfae374937
-c62121526e85d97c
+0277c5c92f3d5a09
+f90dd4cb2accfa46
+d2a5ff7f841f8207
+ade978da078ff49e
+04767e0cad4c7bb3
+4a478ccc6288b426
+e7e3cd1915d39884
+3477e98e03af547b
+0005d82a1a7efea1
+158cb30b44e088bc
+7def82f8a0428512
+de3bebd23772c7f0
+51269662f4046d14
+6f40ae5bf3713121
+9684e314962e23ba
+5dae79056d9e66ac
+a296736986aa8f91
+7e2ab5055ed6cc2b
+44835bb00c4a57d9
+f400d864cb1587ac
+5078d9e4b98021fb
+2719c8a3ca268fc2
+94efe588bd622423
+eb3b8e67af1a5185
+a1fcb58e99b730cc
Zone private key (d):
5af7020ee1916032
@@ -3341,7 +3354,7 @@ DATA:
e6849be7a7b0
Record #2
-EXPIRATION: 6089306424
+EXPIRATION: 6131101992
DATA_SIZE: 11
TYPE: 16
FLAGS: 4004
@@ -3358,7 +3371,7 @@ RDATA:
00b00f81b7449b40
0006800000010001
e6849be7a7b00000
-00016af37138000b
+00016d713128000b
4004000000104865
6c6c6f20576f726c
6400000000000000
@@ -3371,7 +3384,7 @@ e6849be7a7b00000
Encryption NONCE|EXPIRATION:
d9402801e26324b6
0c227f25203e9f26
-0005d8160d59693e
+0005d82a1a7f108e
Encryption key (K):
20007fe09b16dc86
@@ -3390,24 +3403,24 @@ ad5ade579522e9d7
10fa23cd93e56e8c
BDATA:
-92b722bc0289cccc
-c073b2c741abe8fb
-ee9b961bae66312a
-7be8cb9db2a34508
-55a8709eba0288d8
-4e3b0302c24e8f0b
-079f2aa90dcb884e
-d4ec3157b0652ee3
-126ec890c6352ef5
-0a7b207e55a5e99b
-4f78d900e7ce10b5
-295a7af328cd249e
-61adc50fd185af21
-b00789dc7213590c
-2e2eca61119434c5
-ee859f0f228ccdb9
-e9b0ad33a5aaa9b5
-8d96b7f901c7b895
+ac94e07ec841f0c3
+dbcc7098adb72a7e
+b988687a5cd16d11
+823fc15934c1817b
+df9f38486ac8de17
+385b188bd363301d
+cb93965a962c1226
+8c6204f79ef20549
+a5c513fba83ef61e
+3d7b3255487bff16
+be0697934e5c6b9d
+ddad4c06c15e3743
+9a987407eb13db33
+4d734abc1cdd163b
+fe9ed0565294aaf1
+f3ae753f4f85ed81
+bd5743477eb5a791
+06eec69b63ba6dc1
RRBLOCK:
0000010000010014
@@ -3415,33 +3428,33 @@ RRBLOCK:
6eae0bd307c893c4
85a873cf0cbbfd9d
54d04c13e3b7d284
-aadc29066b2db0e3
-690484e4396113fe
-d1c27d636b49863b
-85a0551d633b4213
-c1a0d47f5be7b6d1
-7632368b1ba4d57f
-8b2b5866bb8abe33
-61472e36e98d510e
-0005d8160d59693e
-92b722bc0289cccc
-c073b2c741abe8fb
-ee9b961bae66312a
-7be8cb9db2a34508
-55a8709eba0288d8
-4e3b0302c24e8f0b
-079f2aa90dcb884e
-d4ec3157b0652ee3
-126ec890c6352ef5
-0a7b207e55a5e99b
-4f78d900e7ce10b5
-295a7af328cd249e
-61adc50fd185af21
-b00789dc7213590c
-2e2eca61119434c5
-ee859f0f228ccdb9
-e9b0ad33a5aaa9b5
-8d96b7f901c7b895
+c81e8ec28b873200
+87890c9c5684d448
+118f4cdda8963e74
+d428647c81a65c0c
+f6a1714fc93cd5c4
+97aec1c72926ccd5
+cc2b32d5096a968b
+34a2eb997c608e0b
+0005d82a1a7f108e
+ac94e07ec841f0c3
+dbcc7098adb72a7e
+b988687a5cd16d11
+823fc15934c1817b
+df9f38486ac8de17
+385b188bd363301d
+cb93965a962c1226
+8c6204f79ef20549
+a5c513fba83ef61e
+3d7b3255487bff16
+be0697934e5c6b9d
+ddad4c06c15e3743
+9a987407eb13db33
+4d734abc1cdd163b
+fe9ed0565294aaf1
+f3ae753f4f85ed81
+bd5743477eb5a791
+06eec69b63ba6dc1
]]>
</artwork>
<t>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0001] branch master updated (58d255d -> 7520fd5),
gnunet <=
- [lsd0001] 02/05: pow, gnunet, 2022/02/16
- [lsd0001] 01/05: zkl lt or eq, gnunet, 2022/02/16
- [lsd0001] 03/05: various minor fixes, gnunet, 2022/02/16
- [lsd0001] 04/05: pow, gnunet, 2022/02/16
- [lsd0001] 05/05: last ISE updates; new TVs, gnunet, 2022/02/16