diff options
author | Martin Schanzenbach <schanzen@gnunet.org> | 2022-02-08 20:21:23 +0100 |
---|---|---|
committer | Martin Schanzenbach <schanzen@gnunet.org> | 2022-02-08 20:21:23 +0100 |
commit | a000871fddb6d29af43f532fde21fe743fd17251 (patch) | |
tree | fbca9682d6cf48d567ca07731fc3f82961cc9bd6 | |
parent | 700e2ffd06d749c532c4b5e6ddf54aaff57dc729 (diff) | |
download | lsd0001-a000871fddb6d29af43f532fde21fe743fd17251.tar.gz lsd0001-a000871fddb6d29af43f532fde21fe743fd17251.zip |
try to fix signatures
-rw-r--r-- | draft-schanzen-gns.xml | 115 |
1 files changed, 62 insertions, 53 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml index df41a8e..2c54320 100644 --- a/draft-schanzen-gns.xml +++ b/draft-schanzen-gns.xml | |||
@@ -192,8 +192,10 @@ | |||
192 | A GNS label is a label as defined in <xref target="RFC8499"/>. | 192 | A GNS label is a label as defined in <xref target="RFC8499"/>. |
193 | Within this document, labels are always assumed to be strings of | 193 | Within this document, labels are always assumed to be strings of |
194 | UTF-8 characters <xref target="RFC8499"/> with a maximum length of | 194 | UTF-8 characters <xref target="RFC8499"/> with a maximum length of |
195 | 63 bytes. Labels MUST be canonicalized using | 195 | 63 bytes for compatibility with applications enforcing DNS legacy |
196 | Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. | 196 | limitations. |
197 | Labels MUST be canonicalized using | ||
198 | Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. | ||
197 | </dd> | 199 | </dd> |
198 | <dt>Apex Label</dt> | 200 | <dt>Apex Label</dt> |
199 | <dd> | 201 | <dd> |
@@ -201,7 +203,7 @@ | |||
201 | quotes). | 203 | quotes). |
202 | The apex label is used to publish resource | 204 | The apex label is used to publish resource |
203 | records in a zone that can be resolved without providing a specific | 205 | records in a zone that can be resolved without providing a specific |
204 | name. It is the GNS method to provide what is the "zone apex" in DNS | 206 | label. It is the GNS method to provide what is the "zone apex" in DNS |
205 | <xref target="RFC4033"/>. | 207 | <xref target="RFC4033"/>. |
206 | </dd> | 208 | </dd> |
207 | <dt>Name</dt> | 209 | <dt>Name</dt> |
@@ -269,17 +271,10 @@ | |||
269 | A GNS resource record contains information as defined by its | 271 | A GNS resource record contains information as defined by its |
270 | resource record type. | 272 | resource record type. |
271 | </dd> | 273 | </dd> |
272 | <dt>Client</dt> | ||
273 | <dd> | ||
274 | The client is an implementation component which facilitates | ||
275 | zone management and name resolution. | ||
276 | It enables the user to manage zones (<xref target="publish"/>) and | ||
277 | resolve names (<xref target="resolution"/>). | ||
278 | </dd> | ||
279 | <dt>Application</dt> | 274 | <dt>Application</dt> |
280 | <dd> | 275 | <dd> |
281 | An application refers to a component which uses a GNS implementation | 276 | An application refers to a component which uses a GNS implementation |
282 | to resolve records from the network and (usually) processes its contents. | 277 | to resolve names into records and processes its contents. |
283 | </dd> | 278 | </dd> |
284 | </dl> | 279 | </dl> |
285 | </section> | 280 | </section> |
@@ -358,8 +353,7 @@ | |||
358 | Each zone can be represented by a Zone Top-Level Domain (zTLD) string. | 353 | Each zone can be represented by a Zone Top-Level Domain (zTLD) string. |
359 | </t> | 354 | </t> |
360 | <t> | 355 | <t> |
361 | <!-- FIXME: MUST or SHOULD? Was must reformulated SHOULD --> | 356 | A implementation SHOULD enable the user to create and manage zones. |
362 | A client implementation SHOULD enable the user to create and manage zones. | ||
363 | If this functionality is not implemented, names can still be resolved | 357 | If this functionality is not implemented, names can still be resolved |
364 | if zone keys for the initial step in the name resolution are available | 358 | if zone keys for the initial step in the name resolution are available |
365 | (see <xref target="resolution"/>). | 359 | (see <xref target="resolution"/>). |
@@ -419,7 +413,7 @@ | |||
419 | data based on key material derived from the zone key, | 413 | data based on key material derived from the zone key, |
420 | a label, and an expiration timestamp. | 414 | a label, and an expiration timestamp. |
421 | </dd> | 415 | </dd> |
422 | <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt> | 416 | <dt>Sign(d,message) -> signature, SignDerived(d,label,message) -> signature</dt> |
423 | <dd> | 417 | <dd> |
424 | is a function to sign a message (typically encrypted record data) using the (blinded) private | 418 | is a function to sign a message (typically encrypted record data) using the (blinded) private |
425 | key d (d'), yielding an unforgeable cryptographic signature. | 419 | key d (d'), yielding an unforgeable cryptographic signature. |
@@ -427,7 +421,7 @@ | |||
427 | underlying storages, in particular DHTs, a deterministic signature | 421 | underlying storages, in particular DHTs, a deterministic signature |
428 | scheme is recommended. | 422 | scheme is recommended. |
429 | </dd> | 423 | </dd> |
430 | <dt>Verify(zk,message,signature) -> boolean, Verify(zk',message,signature) -> boolean</dt> | 424 | <dt>Verify(zk,message,signature) -> boolean, VerifyDerived(zk,label,message,signature) -> boolean</dt> |
431 | <dd> | 425 | <dd> |
432 | is a function to verify the signature was created by | 426 | is a function to verify the signature was created by |
433 | the private key d (or derived key d') corresponding to | 427 | the private key d (or derived key d') corresponding to |
@@ -1040,8 +1034,21 @@ ZKDF-Public(zk,label) | |||
1040 | The Sign() and Verify() functions | 1034 | The Sign() and Verify() functions |
1041 | for PKEY zones are implemented using 512-bit ECDSA deterministic | 1035 | for PKEY zones are implemented using 512-bit ECDSA deterministic |
1042 | signatures as specified in <xref target="RFC6979" />. | 1036 | signatures as specified in <xref target="RFC6979" />. |
1043 | The same functions can be used for derived keys. | 1037 | The same functions can be used for derived keys: |
1044 | </t> | 1038 | </t> |
1039 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1040 | SignDerived(d,label,message): | ||
1041 | d' := ZKDF-Private(d,label) | ||
1042 | return Sign(d',message) | ||
1043 | ]]></artwork> | ||
1044 | <t> | ||
1045 | A signature (R,S) is valid if the following holds: | ||
1046 | </t> | ||
1047 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
1048 | VerifyDerived(zk,label,message,signature): | ||
1049 | zk' := ZKDF-Public(zk,label) | ||
1050 | return Verify(zk',message,signature) | ||
1051 | ]]></artwork> | ||
1045 | <t> | 1052 | <t> |
1046 | The S-Encrypt() and S-Decrypt() functions use AES in counter mode | 1053 | The S-Encrypt() and S-Decrypt() functions use AES in counter mode |
1047 | as defined in <xref target="MODES" /> (CTR-AES-256): | 1054 | as defined in <xref target="MODES" /> (CTR-AES-256): |
@@ -1191,22 +1198,24 @@ S-Decrypt(zk,label,expiration,ciphertext): | |||
1191 | </t> | 1198 | </t> |
1192 | <t> | 1199 | <t> |
1193 | The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>. | 1200 | The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>. |
1194 | For brevity, instead of using d as a parameter to the derivation, | ||
1195 | we define the ZKDF-Private() procedure on the derived integer a. | ||
1196 | The calculation of a is defined in Section 5.1.5 of <xref target="RFC8032" />. | 1201 | The calculation of a is defined in Section 5.1.5 of <xref target="RFC8032" />. |
1197 | Given a label, the output of the ZKDF-Private function for zone | 1202 | Given a label, the output of the ZKDF-Private function for zone |
1198 | key blinding is calculated as follows for EDKEY zones: | 1203 | key blinding is calculated as follows for EDKEY zones: |
1199 | </t> | 1204 | </t> |
1200 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1205 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1201 | ZKDF-Private(a,label): | 1206 | ZKDF-Private(d,label): |
1207 | a := SHA-512 (d) | ||
1208 | a[0] &= 248; | ||
1209 | a[31] &= 127; | ||
1210 | a[31] |= 64; | ||
1202 | zk := a * G | 1211 | zk := a * G |
1203 | PRK_h := HKDF-Extract ("key-derivation", zk) | 1212 | PRK_h := HKDF-Extract ("key-derivation", zk) |
1204 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) | 1213 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) |
1205 | h[31] &= 7 | 1214 | h[31] &= 7 |
1206 | a1 := a >> 3 | 1215 | a1 := a >> 3 |
1207 | a2 := (h * a1) mod L | 1216 | a2 := (h * a1) mod L |
1208 | a' = a2 << 3 | 1217 | d' := a2 << 3 |
1209 | return a' | 1218 | return d' |
1210 | ]]></artwork> | 1219 | ]]></artwork> |
1211 | <t> | 1220 | <t> |
1212 | Equally, given a label, the output of the ZKDF-Public function is | 1221 | Equally, given a label, the output of the ZKDF-Public function is |
@@ -1216,7 +1225,7 @@ ZKDF-Private(a,label): | |||
1216 | ZKDF-Public(zk,label): | 1225 | ZKDF-Public(zk,label): |
1217 | PRK_h := HKDF-Extract ("key-derivation", zk) | 1226 | PRK_h := HKDF-Extract ("key-derivation", zk) |
1218 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) | 1227 | h := HKDF-Expand (PRK_h, label | "gns", 512 / 8) |
1219 | h[31] &= 7 // Implies h mod L == h | 1228 | h[31] &= 7 |
1220 | zk' := h * zk | 1229 | zk' := h * zk |
1221 | return zk' | 1230 | return zk' |
1222 | ]]></artwork> | 1231 | ]]></artwork> |
@@ -1256,9 +1265,9 @@ ZKDF-Public(zk,label): | |||
1256 | be implemented as defined in <xref target="RFC8032" />. | 1265 | be implemented as defined in <xref target="RFC8032" />. |
1257 | </t> | 1266 | </t> |
1258 | <t> | 1267 | <t> |
1259 | Signatures for EDKEY zones using the derived private key a' | 1268 | Signatures for EDKEY zones using the derived private scalar d' |
1260 | are not compliant with <xref target="RFC8032" />. | 1269 | are not compliant with <xref target="RFC8032" />. |
1261 | As the corresponding private key to the derived private scalar a' | 1270 | As the corresponding private key to the derived private scalar d' |
1262 | is not known, it is not possible to deterministically derive the | 1271 | is not known, it is not possible to deterministically derive the |
1263 | signature part R according to <xref target="RFC8032" />. | 1272 | signature part R according to <xref target="RFC8032" />. |
1264 | Instead, signatures MUST be generated as follows for any given | 1273 | Instead, signatures MUST be generated as follows for any given |
@@ -1270,24 +1279,22 @@ ZKDF-Public(zk,label): | |||
1270 | of the R value of the signature, ensuring that it is never reused | 1279 | of the R value of the signature, ensuring that it is never reused |
1271 | for two different derivation paths or messages. | 1280 | for two different derivation paths or messages. |
1272 | </t> | 1281 | </t> |
1273 | <!-- Blinded key signatures need a different method signature | ||
1274 | FIXME Should we use a' | ||
1275 | nonce := SHA-256 (a')? Changed for now. Unclear if ok. | ||
1276 | --> | ||
1277 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1282 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1278 | Sign(d,message): | 1283 | SignDerived(d,label,message): |
1284 | d' := ZKDF-Private(d,label) | ||
1279 | dh := SHA-512 (d) | 1285 | dh := SHA-512 (d) |
1280 | nonce := SHA-256 (dh[32..63] | h) | 1286 | nonce := SHA-256 (dh[32..63] | h) |
1281 | r := SHA-512 (nonce | message) | 1287 | r := SHA-512 (nonce | message) |
1282 | R := r * G | 1288 | R := r * G |
1283 | S := r + SHA-512(R | zk' | message) * a' mod L | 1289 | S := r + SHA-512(R | zk' | message) * d' mod L |
1284 | return (R,S) | 1290 | return (R,S) |
1285 | ]]></artwork> | 1291 | ]]></artwork> |
1286 | <t> | 1292 | <t> |
1287 | A signature (R,S) is valid if the following holds: | 1293 | A signature (R,S) is valid if the following holds: |
1288 | </t> | 1294 | </t> |
1289 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 1295 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
1290 | Verify(zk',message,signature): | 1296 | VerifyDerived(zk,label,message,signature): |
1297 | zk' := ZKDF-Public(zk,label) | ||
1291 | (R,S) := signature | 1298 | (R,S) := signature |
1292 | return S * G == R + SHA-512(R, zk', message) * zk' | 1299 | return S * G == R + SHA-512(R, zk', message) * zk' |
1293 | ]]></artwork> | 1300 | ]]></artwork> |
@@ -1410,6 +1417,8 @@ S-Decrypt(zk,label,expiration,ciphertext): | |||
1410 | in DNS followed by a DNS server. Both names are in the format defined in | 1417 | in DNS followed by a DNS server. Both names are in the format defined in |
1411 | <xref target="RFC1034" /> for DNS names. | 1418 | <xref target="RFC1034" /> for DNS names. |
1412 | There MAY be multiple GNS2DNS records under a label. | 1419 | There MAY be multiple GNS2DNS records under a label. |
1420 | There MAY also be DNSSEC DS records or any other records used to | ||
1421 | secure the connection with the DNS servers under the same label. | ||
1413 | No other record types are allowed in the same record set. | 1422 | No other record types are allowed in the same record set. |
1414 | A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsrecord"/>.</t> | 1423 | A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsrecord"/>.</t> |
1415 | <figure anchor="figure_gns2dnsrecord"> | 1424 | <figure anchor="figure_gns2dnsrecord"> |
@@ -1592,7 +1601,8 @@ S-Decrypt(zk,label,expiration,ciphertext): | |||
1592 | </dd> | 1601 | </dd> |
1593 | <dt>SVC</dt> | 1602 | <dt>SVC</dt> |
1594 | <dd> | 1603 | <dd> |
1595 | the 16-bit service value of the boxed record, i.e. the port number. | 1604 | the 16-bit service value of the boxed record. In case of |
1605 | TCP and UDP it is the port number. | ||
1596 | In network byte order. | 1606 | In network byte order. |
1597 | </dd> | 1607 | </dd> |
1598 | <dt>TYPE</dt> | 1608 | <dt>TYPE</dt> |
@@ -1869,21 +1879,14 @@ q := SHA-512 (ZKDF-Public(zk, label)) | |||
1869 | <xref target="governance" />. | 1879 | <xref target="governance" />. |
1870 | </t> | 1880 | </t> |
1871 | <t> | 1881 | <t> |
1872 | <!-- FIXME removed client everywhere. We only have an implementation --> | 1882 | The application MAY provide a desired record type to the resolver. |
1873 | The client implementation MAY allow the user to provide a desired | ||
1874 | record type for the resolver. | ||
1875 | The desired record type is used to guide processing. | 1883 | The desired record type is used to guide processing. |
1876 | For example, if zone delegation record type is requested, the | 1884 | For example, if a zone delegation record type is requested, the |
1877 | resolution of the apex label in that zone may not be necessary, as | 1885 | resolution of the apex label in that zone must be skipped, as |
1878 | the desired record is already found. | 1886 | the desired record is already found. |
1879 | <!-- FIXME: Is this still necessary? Clarify the purpose of the | ||
1880 | provided record type and normatively define that resolver MUST NOT | ||
1881 | filter? THe normative statement for the CLIENT does not make sense. | ||
1882 | We need a normative statement for the implementer of GNS. --> | ||
1883 | The resolver implementation MUST NOT filter results according to the desired | 1887 | The resolver implementation MUST NOT filter results according to the desired |
1884 | record type. | 1888 | record type. |
1885 | Filtering of record sets MAY still be done by the client which | 1889 | Filtering of record sets is typically done by the application. |
1886 | could be a stub resolver. | ||
1887 | </t> | 1890 | </t> |
1888 | <section anchor="governance" numbered="true" toc="default"> | 1891 | <section anchor="governance" numbered="true" toc="default"> |
1889 | <name>Start Zones</name> | 1892 | <name>Start Zones</name> |
@@ -1892,7 +1895,7 @@ q := SHA-512 (ZKDF-Public(zk, label)) | |||
1892 | or only the client? Because the resolver needs to know the zones for | 1895 | or only the client? Because the resolver needs to know the zones for |
1893 | redirects, for example --> | 1896 | redirects, for example --> |
1894 | The resolution of a GNS name starts in an initial start zone. | 1897 | The resolution of a GNS name starts in an initial start zone. |
1895 | The local resolver may have one or more local start zones configured | 1898 | The resolver may have one or more local start zones configured |
1896 | which point to local or remote zone keys. | 1899 | which point to local or remote zone keys. |
1897 | A resolver may also determine the start zone from the | 1900 | A resolver may also determine the start zone from the |
1898 | suffix of the name given for resolution, or using information | 1901 | suffix of the name given for resolution, or using information |
@@ -1908,9 +1911,9 @@ q := SHA-512 (ZKDF-Public(zk, label)) | |||
1908 | management of root servers in DNS (see <xref target="RFC8324"/>, Section 3.10 and 3.12). | 1911 | management of root servers in DNS (see <xref target="RFC8324"/>, Section 3.10 and 3.12). |
1909 | </t> | 1912 | </t> |
1910 | <t> | 1913 | <t> |
1911 | In the following, we give examples how a local client SHOULD | 1914 | In the following, we give examples how a resolver SHOULD |
1912 | discover the start zone. The process given is not exhaustive and | 1915 | discover the start zone. The process given is not exhaustive and |
1913 | clients MAY supplement it with other mechanisms or ignore it if the | 1916 | resolvers MAY supplement it with other mechanisms or ignore it if the |
1914 | particular application requires a different process. | 1917 | particular application requires a different process. |
1915 | </t> | 1918 | </t> |
1916 | <t> | 1919 | <t> |
@@ -2107,6 +2110,12 @@ example.com = zk2 | |||
2107 | appropriate error is SHOULD be returned to the application. | 2110 | appropriate error is SHOULD be returned to the application. |
2108 | </t> | 2111 | </t> |
2109 | <t> | 2112 | <t> |
2113 | If there are DNSSEC DS records or any other records used to | ||
2114 | secure the connection with the DNS servers stored under the label, | ||
2115 | the DNS resolver SHOULD use them to secure the connection with | ||
2116 | the DNS server. | ||
2117 | </t> | ||
2118 | <t> | ||
2110 | Once the IP addresses of the DNS servers have been determined, | 2119 | Once the IP addresses of the DNS servers have been determined, |
2111 | the DNS name from the GNS2DNS record is appended | 2120 | the DNS name from the GNS2DNS record is appended |
2112 | to the remainder of the name to be resolved, and | 2121 | to the remainder of the name to be resolved, and |
@@ -2115,7 +2124,7 @@ example.com = zk2 | |||
2115 | support recursive DNS resolution and MUST NOT delegate this to the | 2124 | support recursive DNS resolution and MUST NOT delegate this to the |
2116 | authoritative DNS servers. | 2125 | authoritative DNS servers. |
2117 | The first successful recursive name resolution result | 2126 | The first successful recursive name resolution result |
2118 | is returned to the client. | 2127 | is returned to the application. |
2119 | In addition, the resolver SHOULD return the queried DNS name as a | 2128 | In addition, the resolver SHOULD return the queried DNS name as a |
2120 | supplemental LEHO record (see <xref target="gnsrecords_leho" />) with a | 2129 | supplemental LEHO record (see <xref target="gnsrecords_leho" />) with a |
2121 | relative expiration time of one hour. | 2130 | relative expiration time of one hour. |
@@ -2139,7 +2148,7 @@ example.com = zk2 | |||
2139 | still be returned, even if DNS support is disabled by the | 2148 | still be returned, even if DNS support is disabled by the |
2140 | GNS resolver configuration. | 2149 | GNS resolver configuration. |
2141 | </t> | 2150 | </t> |
2142 | <!-- FIXME: Loop detection --> | 2151 | <!-- FIXME: State the DNS resolution never "returns" to GNS. --> |
2143 | </section> | 2152 | </section> |
2144 | <section anchor="box_processing" numbered="true" toc="default"> | 2153 | <section anchor="box_processing" numbered="true" toc="default"> |
2145 | <name>BOX</name> | 2154 | <name>BOX</name> |
@@ -2176,7 +2185,7 @@ example.com = zk2 | |||
2176 | recursion is continued with the record value as authoritative zone | 2185 | recursion is continued with the record value as authoritative zone |
2177 | and the apex label "@" as remaining name. | 2186 | and the apex label "@" as remaining name. |
2178 | Except in the case where the desired record type as specified by | 2187 | Except in the case where the desired record type as specified by |
2179 | the client is equal to the ztype, in which case the delegation | 2188 | the application is equal to the ztype, in which case the delegation |
2180 | record is returned. | 2189 | record is returned. |
2181 | </t> | 2190 | </t> |
2182 | </section> | 2191 | </section> |
@@ -2185,7 +2194,7 @@ example.com = zk2 | |||
2185 | <t> | 2194 | <t> |
2186 | NICK records are only relevant to the recursive resolver | 2195 | NICK records are only relevant to the recursive resolver |
2187 | if the record set in question is the final result which is to | 2196 | if the record set in question is the final result which is to |
2188 | be returned to the client. The encountered NICK records may either | 2197 | be returned to the application. The encountered NICK records may either |
2189 | be supplemental (see <xref target="rrecords"/>) or | 2198 | be supplemental (see <xref target="rrecords"/>) or |
2190 | non-supplemental. | 2199 | non-supplemental. |
2191 | If the NICK record is supplemental, the resolver only returns the | 2200 | If the NICK record is supplemental, the resolver only returns the |
@@ -2196,7 +2205,7 @@ example.com = zk2 | |||
2196 | </t> | 2205 | </t> |
2197 | <t> | 2206 | <t> |
2198 | The differentiation between a supplemental and non-supplemental | 2207 | The differentiation between a supplemental and non-supplemental |
2199 | NICK record allows the client to match the record to the | 2208 | NICK record allows the application to match the record to the |
2200 | authoritative zone. Consider the following example: | 2209 | authoritative zone. Consider the following example: |
2201 | </t> | 2210 | </t> |
2202 | <artwork name="" type="" align="left" alt=""><![CDATA[ | 2211 | <artwork name="" type="" align="left" alt=""><![CDATA[ |
@@ -2207,7 +2216,7 @@ NICK: eve (non-Supplemental) | |||
2207 | ]]></artwork> | 2216 | ]]></artwork> |
2208 | <t> | 2217 | <t> |
2209 | In this example, the returned NICK record is non-supplemental. | 2218 | In this example, the returned NICK record is non-supplemental. |
2210 | For the client, this means that the NICK belongs to the zone | 2219 | For the application, this means that the NICK belongs to the zone |
2211 | "alice.example" and is published under the apex label along with an A | 2220 | "alice.example" and is published under the apex label along with an A |
2212 | record. The NICK record should be interpreted as: The zone defined by | 2221 | record. The NICK record should be interpreted as: The zone defined by |
2213 | "alice.example" wants to be referred to as "eve". | 2222 | "alice.example" wants to be referred to as "eve". |
@@ -2596,7 +2605,7 @@ Purpose | Name | References | Comment | |||
2596 | is an active deployment of GNS on top of its <xref target="R5N"/> | 2605 | is an active deployment of GNS on top of its <xref target="R5N"/> |
2597 | DHT. The <xref target="GoGNS"/> implementation uses this deployment | 2606 | DHT. The <xref target="GoGNS"/> implementation uses this deployment |
2598 | by building on top of the GNUnet DHT services available on any | 2607 | by building on top of the GNUnet DHT services available on any |
2599 | GNUnet peer. It shows how GNS implementations and client resolvers | 2608 | GNUnet peer. It shows how GNS implementations |
2600 | can attach to this existing deployment and participate in name | 2609 | can attach to this existing deployment and participate in name |
2601 | resolution as well as zone publication. | 2610 | resolution as well as zone publication. |
2602 | </t> | 2611 | </t> |