rfc9498.xml (204877B)
1 <?xml version="1.0" encoding="utf-8"?> 2 3 <!DOCTYPE rfc [ 4 <!ENTITY nbsp " "> 5 <!ENTITY zwsp "​"> 6 <!ENTITY nbhy "‑"> 7 <!ENTITY wj "⁠"> 8 ]> 9 10 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 11 version="3" 12 submissionType="independent" 13 category="info" 14 docName="draft-schanzen-gns-28" 15 number="9498" 16 ipr="trust200902" 17 sortRefs="false" 18 symRefs="true" 19 tocDepth="3" 20 tocInclude="true" 21 updates="" 22 obsoletes="" 23 xml:lang="en"> 24 25 <!-- xml2rfc v2v3 conversion 2.26.0 --> 26 <front> 27 <title abbrev="The GNU Name System">The GNU Name System</title> 28 <seriesInfo name="RFC" value="9498"/> 29 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 30 <organization>Fraunhofer AISEC</organization> 31 <address> 32 <postal> 33 <street>Lichtenbergstrasse 11</street> 34 <city>Garching</city> 35 <code>85748</code> 36 <country>Germany</country> 37 </postal> 38 <email>martin.schanzenbach@aisec.fraunhofer.de</email> 39 </address> 40 </author> 41 <author fullname="Christian Grothoff" initials="C." surname="Grothoff"> 42 <organization>Berner Fachhochschule</organization> 43 <address> 44 <postal> 45 <street>Hoeheweg 80</street> 46 <city>Biel/Bienne</city> 47 <code>2501</code> 48 <country>Switzerland</country> 49 </postal> 50 <email>christian.grothoff@bfh.ch</email> 51 </address> 52 </author> 53 <author fullname="Bernd Fix" initials="B." surname="Fix"> 54 <organization>GNUnet e.V.</organization> 55 <address> 56 <postal> 57 <street>Boltzmannstrasse 3</street> 58 <city>Garching</city> 59 <code>85748</code> 60 <country>Germany</country> 61 </postal> 62 <email>fix@gnunet.org</email> 63 </address> 64 </author> 65 <date month="November" year="2023"/> 66 <keyword>name systems</keyword> 67 68 <abstract> 69 <t> 70 This document provides the GNU Name System (GNS) technical 71 specification. 72 GNS is a decentralized and censorship-resistant domain name 73 resolution protocol that provides a privacy-enhancing alternative to the 74 Domain Name System (DNS) protocols. 75 </t> 76 <t> 77 This document defines the normative wire format of resource records, 78 resolution processes, cryptographic routines, and security and privacy 79 considerations for use by implementers. 80 </t> 81 <t> 82 This specification was developed outside the IETF and does not have 83 IETF consensus. It is published here to inform readers about the 84 function of GNS, guide future GNS implementations, and ensure 85 interoperability among implementations (for example, pre-existing 86 GNUnet implementations). 87 </t> 88 </abstract> 89 </front> 90 <middle> 91 <section anchor="introduction"> 92 <name>Introduction</name> 93 <t> 94 This specification describes the GNU Name System (GNS), a 95 censorship-resistant, privacy-preserving, and decentralized 96 domain name resolution protocol. GNS cryptographically secures 97 the binding of names to arbitrary tokens, enabling it to double 98 in some respects as an alternative to some of today's public 99 key infrastructures. 100 </t> 101 <t> 102 Per Domain Name System (DNS) terminology <xref target="RFC1035"/>, GNS roughly follows the idea of a local 103 root zone deployment (see <xref target="RFC8806"/>), with the 104 difference that the design encourages alternative roots and 105 does not expect all deployments to use the same or any specific 106 root zone. In the GNS reference implementation, users can 107 autonomously and freely delegate control of names to zones 108 through their local configurations. 109 GNS expects each user to be in control of their setup. 110 By following the guidelines in <xref target="namespace_ambiguity"/>, 111 users should manage to avoid any confusion as to how names are 112 resolved. 113 </t> 114 <t> 115 Name resolution and zone dissemination are based on the 116 principle of a petname system where users can assign local 117 names to zones. The GNS has its roots in ideas from the Simple 118 Distributed Security Infrastructure <xref target="SDSI"/>, 119 enabling the decentralized mapping of secure identifiers to 120 memorable names. One of the first academic descriptions of the 121 cryptographic ideas behind GNS can be found in <xref target="GNS"/>. 122 </t> 123 <t> 124 This document defines the normative wire format of resource 125 records, resolution processes, cryptographic routines, and 126 security and privacy considerations for use by implementers. 127 </t> 128 <section> 129 <name>Requirements Notation</name> 130 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", 131 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", 132 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", 133 "<bcp14>SHOULD NOT</bcp14>", 134 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", 135 "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document 136 are to be interpreted as described in BCP 14 137 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only 138 when, they appear in all capitals, as shown here.</t> 139 </section> 140 </section> 141 <section> 142 <name>Terminology</name> 143 <dl newline="false"> 144 <dt>Apex Label:</dt> 145 <dd> 146 This type of label is used to publish resource 147 records in a zone that can be resolved without providing a specific 148 label. It is the GNS method for providing what is called the "zone apex" in DNS 149 <xref target="RFC4033"/>. 150 The apex label is represented using the character U+0040 ("@" without the quotes). 151 </dd> 152 <dt>Application:</dt> 153 <dd> 154 An application is a component that uses a GNS implementation 155 to resolve names into records and processes its contents. 156 </dd> 157 <dt>Blinded Zone Key:</dt> 158 <dd> 159 A blinded zone key is a key derived from a zone key and a label. 160 The zone key and any blinded zone key derived from it are unlinkable 161 without knowledge of the specific label used for the derivation. 162 </dd> 163 <dt>Extension Label:</dt> 164 <dd> 165 This type of label is used to refer to the authoritative zone that the record is in. 166 The primary use for the extension label is in redirections where the redirection 167 target is defined relative to the authoritative zone of the redirection 168 record (see <xref target="gnsrecords_redirect"/>). 169 The extension label is represented using the character U+002B ("+" without the quotes). 170 </dd> 171 <dt>Label Separator:</dt> 172 <dd> 173 Labels in a name are separated using the label separator U+002E 174 ("." without the quotes). 175 In GNS, except for zone Top-Level Domains (zTLDs) 176 (see below) and boxed records (see <xref target="gnsrecords_box"/>), 177 every label separator in a name indicates delegation to another zone. 178 </dd> 179 <dt>Label:</dt> 180 <dd> 181 A GNS label is a label as defined in <xref target="RFC8499"/>. 182 Labels are UTF-8 strings in Unicode 183 Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. 184 The apex label and the extension label have 185 special purposes in the resolution protocol that are defined 186 in the rest of this document. 187 Zone administrators <bcp14>MAY</bcp14> disallow certain labels that 188 might be easily confused with other labels through registration policies 189 (see also <xref target="security_abuse"/>). 190 </dd> 191 <dt>Name:</dt> 192 <dd> 193 A name in GNS is a domain name as defined in <xref target="RFC8499"/>: 194 names are UTF-8 strings <xref target="RFC3629"/> consisting of an 195 ordered list of labels concatenated with a label separator. 196 Names are resolved starting from the rightmost label. 197 GNS does not impose length restrictions on names or labels. 198 However, applications <bcp14>MAY</bcp14> ensure that name and label lengths are 199 compatible with DNS and, in particular, Internationalized Domain Names for 200 Applications (IDNA) <xref target="RFC5890"/>. 201 In the spirit of <xref target="RFC5895"/>, applications <bcp14>MAY</bcp14> preprocess 202 names and labels to ensure compatibility with DNS or support 203 specific user expectations -- for example, according to 204 <xref target="Unicode-UTS46"/>. 205 A GNS name may be indistinguishable from a DNS name, and care must 206 be taken by applications and implementers when handling GNS names 207 (see <xref target="namespace_ambiguity"/>). 208 In order to avoid misinterpretation of example domains with (reserved) 209 DNS domains, this document uses the suffix ".gns.alt" in compliance with 210 <xref target="RFC9476"/>. ".gns.alt" is also registered in the GANA ".alt Subdomains" registry 211 <xref target="GANA"/>. 212 </dd> 213 <dt>Resolver:</dt> 214 <dd> 215 In this document, a resolver is the component of a GNS implementation that provides 216 the recursive name resolution logic defined in 217 <xref target="resolution"/>. 218 </dd> 219 <dt>Resource Record:</dt> 220 <dd> 221 A GNS resource record is the information associated with a label in a 222 GNS zone. 223 A GNS resource record contains information as defined by its 224 resource record type. 225 </dd> 226 <dt>Start Zone:</dt> 227 <dd> 228 In order to resolve any given GNS name, an initial Start Zone must be 229 determined for this name. 230 The Start Zone can be explicitly defined as part of the name using a 231 zTLD. 232 Otherwise, it is determined through a local suffix-to-zone mapping 233 (see <xref target="governance"/>). 234 </dd> 235 <dt>Top-Level Domain (TLD):</dt> 236 <dd> 237 The rightmost part of a GNS name is a GNS TLD. 238 A GNS TLD can consist of one or more labels. 239 Unlike DNS TLDs (defined in <xref target="RFC8499"/>), 240 GNS does not expect all users to use the same global root zone. Instead, 241 with the exception of zTLDs (see <xref target="zTLD"/>), 242 GNS TLDs are typically part of the configuration of the local resolver 243 (see <xref target="governance"/>) and thus might not be globally unique. 244 </dd> 245 <dt>Zone:</dt> 246 <dd> 247 A GNS zone contains authoritative information (resource records). 248 A zone is uniquely identified by its zone key. Unlike DNS zones, 249 a GNS zone does not need to have an SOA record under the apex label. 250 </dd> 251 <dt>Zone Key:</dt> 252 <dd> 253 The zone key is a key that uniquely identifies a zone. 254 It is usually a public key of an asymmetric key pair. 255 However, the established technical term "public key" is misleading, 256 as in GNS a zone key may be a shared secret 257 that should not be disclosed to unauthorized parties. 258 </dd> 259 <dt>Zone Key Derivation Function:</dt> 260 <dd> 261 The zone key derivation function (ZKDF) blinds a zone key using a label. 262 </dd> 263 <dt>Zone Publisher:</dt> 264 <dd> 265 The zone publisher is the component of a GNS implementation that provides 266 local zone management and publication as defined in 267 <xref target="publish"/>. 268 </dd> 269 <dt>Zone Owner:</dt> 270 <dd> 271 The zone owner is the holder of the secret (typically a private key), 272 which (together with a label and a value to sign) allows the creation of zone 273 signatures that can be validated against the respective blinded zone key. 274 </dd> 275 <dt>Zone Top-Level Domain (zTLD):</dt> 276 <dd> 277 A GNS zTLD is a sequence of GNS labels at 278 the end of a GNS name. The zTLD encodes a zone type and 279 zone key of a zone (see <xref target="zTLD"/>). 280 Due to the statistical uniqueness of zone keys, zTLDs are also globally unique. 281 A zTLD label sequence can only be distinguished from ordinary TLD label sequences 282 by attempting to decode the labels into a zone type and zone key. 283 </dd> 284 <dt>Zone Type:</dt> 285 <dd> 286 The type of a GNS zone determines the cipher system and binary encoding 287 format of the zone key, blinded zone keys, and cryptographic signatures. 288 </dd> 289 </dl> 290 </section> 291 <section anchor="overview"> 292 <name>Overview</name> 293 <t> 294 GNS exhibits the three properties that are commonly used to describe 295 a petname system: 296 </t> 297 <dl newline="true"> 298 <dt> 299 Global names through the concept of zTLDs:</dt><dd>As zones can be uniquely identified by their zone keys 300 and are statistically unique, zTLDs are globally unique mappings to zones. 301 Consequently, GNS domain names with a zTLD suffix are also globally unique. 302 Names with zTLD suffixes are not memorable.</dd> 303 <dt> 304 Memorable petnames for zones:</dt> 305 <dd>Users can configure local, memorable references to zones. 306 Such petnames serve as zTLD monikers that provide 307 convenient names for zones to the local operator. 308 The petnames may also be published as suggestions for other 309 users searching for a good label to use when referencing the 310 respective zone.</dd> 311 <dt> 312 A secure mapping from names to records:</dt> 313 <dd>GNS allows zone owners to map labels to resource records or to 314 delegate authority of names in the subdomain induced by a label to other zones. 315 Zone owners may choose to publish this information to make it 316 available to other users. 317 Mappings are encrypted and signed 318 using keys derived from the respective label before being published in remote storage. 319 When names are resolved, signatures on resource records, 320 including delegations, are verified by the recursive resolver.</dd> 321 </dl> 322 <t> 323 In the remainder of this document, the "implementer" refers to the developer building 324 a GNS implementation that includes the resolver, zone publisher, and 325 supporting configuration such as Start Zones (see <xref target="governance"/>). 326 </t> 327 <section anchor="names"> 328 <name>Names and Zones</name> 329 <t> 330 It follows from the above that GNS does not support names that are 331 simultaneously global, secure, and memorable. 332 Instead, names are either global and not memorable or not globally 333 unique and memorable. 334 An example for a global name pointing to the record "example" in 335 a zone is as follows: 336 </t> 337 <sourcecode> 338 example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884 339 </sourcecode> 340 <t> 341 Now consider the case where a user locally configured the petname 342 "pet.gns.alt" for the zone with the "example" record of the name 343 above. 344 The name "example.pet.gns.alt" would then point to the same record as the 345 globally unique name above, but name resolution would only 346 work on the local system where the "pet.gns.alt" petname is 347 configured. 348 </t> 349 <t> 350 The delegation of petnames and subsequent resolution of delegation 351 build on ideas from the Simple Distributed Security Infrastructure 352 <xref target="SDSI"/>. 353 In GNS, any user can create and manage any number of zones 354 (see <xref target="zones"/>) if their system provides a zone publisher implementation. 355 For each zone, the zone type determines the respective set of cryptographic operations 356 and the wire formats for encrypted data, public keys, and signatures. 357 A zone can be populated with mappings from labels to resource records 358 (see <xref target="rrecords"/>) by its owner. 359 A label can be mapped to a delegation record; this results in the 360 corresponding subdomain being delegated to another zone. Circular 361 delegations are explicitly allowed, including delegating a subdomain 362 to its immediate parent zone. In 363 order to support (legacy) applications as well as to facilitate the use 364 of petnames, GNS defines auxiliary record types in addition to 365 supporting existing DNS records. 366 </t> 367 </section> 368 <section anchor="publishing"> 369 <name>Publishing Binding Information</name> 370 <t> 371 Zone contents are encrypted and signed 372 before being published in remote key-value storage (see <xref target="publish"/>), 373 as illustrated in <xref target="figure_arch_publish"/>. 374 In this process, unique zone identification is hidden from the network 375 through the use of key blinding. 376 Key blinding allows the creation of signatures for zone contents 377 using a blinded public/private key pair. 378 This blinding is realized using a deterministic key 379 derivation from 380 the original zone key and corresponding private key using record label values 381 as inputs from which blinding factors are derived. 382 Specifically, the zone owner can derive blinded private keys for each record 383 set published under a label, and a 384 resolver can derive the corresponding blinded public keys. 385 It is expected that GNS implementations use decentralized remote 386 storage entities, such as distributed hash tables (DHTs), in order to facilitate 387 availability within a network without the need for dedicated infrastructure. 388 The specification of such a distributed or decentralized storage entity is out of 389 scope for this document, but possible existing implementations include those 390 based on <xref target="RFC7363"/>, <xref target="Kademlia"/>, or 391 <xref target="R5N"/>. 392 </t> 393 <figure anchor="figure_arch_publish"> 394 <name>An Example Diagram of Two Hosts Publishing GNS Zones</name> 395 <artwork name="" type="" alt=""> 396 Host A | Remote | Host B 397 | Storage | 398 | | 399 | +---------+ | 400 | / /| | 401 Publish | +---------+ | | Publish 402 +-----------+ Records | | | | | Records +-----------+ 403 | Zone |----------|->| Record | |<-|----------| Zone | 404 | Publisher | | | Storage | | | | Publisher | 405 +-----------+ | | |/ | +-----------+ 406 A | +---------+ | A 407 | | | | 408 +---------+ | | +---------+ 409 / | /| | | / | /| 410 +---------+ | | | +---------+ | 411 | | | | | | | | 412 | Local | | | | | Local | | 413 | Zones | | | | | Zones | | 414 | |/ | | | |/ 415 +---------+ | | +---------+ 416 </artwork> 417 </figure> 418 <t> 419 A zone publisher implementation <bcp14>SHOULD</bcp14> be provided as 420 part of a GNS implementation to enable users to create and manage zones. 421 If this functionality is not implemented, names can still be resolved 422 if zone keys for the initial step in the name resolution have been 423 configured (see <xref target="resolution"/>) or if the names end with a 424 zTLD suffix. 425 </t> 426 </section> 427 <section anchor="resolving"> 428 <name>Resolving Names</name> 429 <t> 430 Applications use the resolver to look up GNS names. 431 Starting from a configurable Start Zone, names are resolved by following zone 432 delegations recursively, as illustrated in <xref target="figure_arch_resolv"/>. 433 For each label in a name, the recursive GNS resolver 434 fetches the respective record set from the storage layer (see <xref target="resolution"/>). 435 Without knowledge of the label values and the zone keys, the 436 different derived keys are unlinkable to both the original zone key and each 437 other. 438 This prevents zone enumeration (except via expensive online 439 brute-force attacks): to confirm the affiliation of a 440 query or the corresponding encrypted record set with a 441 specific zone requires knowledge of both the zone key and the label, 442 neither of which is disclosed to remote storage by the protocol. 443 At the same time, the blinded zone key and digital signatures 444 associated with each encrypted record set allow resolvers and oblivious remote 445 storage to verify the integrity of the published information 446 without disclosing anything about the originating zone or the record sets. 447 </t> 448 <figure anchor="figure_arch_resolv"> 449 <name>High-Level View of the GNS Resolution Process</name> 450 <artwork name="" type="" alt=""> 451 Local Host | Remote 452 | Storage 453 | 454 | +---------+ 455 | / /| 456 | +---------+ | 457 +-----------+ Name +----------+ Recursive | | | | 458 | | Lookup | | Resolution | | Record | | 459 |Application|--------->| Resolver |-------------|->| Storage | | 460 | |<---------| |<------------|--| |/ 461 +-----------+ Results +----------+ Intermediate| +---------+ 462 A Results | 463 | | 464 +---------+ | 465 / | /| | 466 +---------+ | | 467 | | | | 468 | Start | | | 469 | Zones | | | 470 | |/ | 471 +---------+ | 472 </artwork> 473 </figure> 474 </section> 475 </section> 476 <section anchor="zones"> 477 <name>Zones</name> 478 <t> 479 A zone in GNS is uniquely identified by its zone type (ztype) and zone key. 480 Each zone can be referenced by its zTLD 481 (see <xref target="zTLD"/>), which is a string that encodes the zone type and zone key. 482 The ztype is a unique 32-bit number that corresponds to 483 a resource record type number identifying a delegation record type 484 in the GANA "GNS Record Types" registry <xref target="GANA"/>. 485 The ztype is a unique identifier for the set cryptographic functions 486 of the zone and the format of the delegation record type. 487 Any ztype registration <bcp14>MUST</bcp14> define the following set of cryptographic functions: 488 </t> 489 <dl newline="true"> 490 <dt>KeyGen() -> d, zkey</dt> 491 <dd> 492 A function for generating a new private key d and 493 the corresponding public zone key zkey. 494 </dd> 495 <dt>ZKDF(zkey, label) -> zkey'</dt> 496 <dd> 497 A ZKDF that blinds a zone key zkey 498 using a label. zkey and zkey' must be unlinkable. Furthermore, 499 blinding zkey with different values for the label must result 500 in different, unlinkable zkey' values. 501 </dd> 502 <dt>S-Encrypt(zkey, label, expiration, plaintext) -> ciphertext</dt> 503 <dd> 504 A symmetric encryption function that encrypts the plaintext 505 to derive ciphertext based on key material derived from the zone key zkey, 506 a label, and an expiration timestamp. 507 In order to leverage performance-enhancing caching features of certain 508 underlying storage entities -- in particular, DHTs -- a deterministic encryption 509 scheme is recommended. 510 </dd> 511 <dt>S-Decrypt(zkey, label, expiration, ciphertext) -> plaintext</dt> 512 <dd> 513 A symmetric decryption function that decrypts the ciphertext 514 into plaintext based on key material derived from the zone key, 515 a label, and an expiration timestamp. 516 </dd> 517 <dt>Sign(d, message) -> signature</dt> 518 <dd> 519 A function for signing a message using the private 520 key d, yielding an unforgeable cryptographic signature. 521 In order to leverage performance-enhancing caching features of certain 522 underlying storage entities -- in particular, DHTs -- a deterministic signature 523 scheme is recommended. 524 </dd> 525 <dt>Verify(zkey, message, signature) -> boolean</dt> 526 <dd> 527 A function for verifying that the signature was created using 528 the private key d corresponding to the zone key zkey 529 where d,zkey := KeyGen(). 530 The function returns a boolean value of "TRUE" if the signature is valid 531 and "FALSE" otherwise. 532 </dd> 533 <dt>SignDerived(d, label, message) -> signature</dt> 534 <dd> 535 A function for signing a message (typically encrypted record data) that 536 can be verified using the derived zone key zkey' := ZKDF(zkey, label). 537 In order to leverage performance-enhancing caching features of certain 538 underlying storage entities -- in particular, DHTs -- a deterministic signature 539 scheme is recommended. 540 </dd> 541 <dt>VerifyDerived(zkey', message, signature) -> boolean</dt> 542 <dd> 543 A function for verifying the signature using the derived zone key 544 zkey' := ZKDF(zkey, label). The function returns a boolean value 545 of "TRUE" if the signature is valid and "FALSE" otherwise. Depending 546 on the signature scheme used, this function can be identical to 547 the Verify() function. 548 </dd> 549 </dl> 550 <t> 551 The cryptographic functions of the default ztypes are specified with 552 their corresponding delegation records as discussed in <xref target="gnsrecords_delegation"/>. 553 In order to support cryptographic agility, additional ztypes <bcp14>MAY</bcp14> 554 be defined in the future that replace or update the default ztypes defined in this 555 document. 556 All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation 557 record types in the GANA "GNS Record Types" registry (see <xref target="GANA"/>). 558 When defining new record types, the cryptographic security considerations 559 of this document -- in particular, <xref target="security_cryptography"/> -- apply. 560 </t> 561 <section anchor="zTLD"> 562 <name>Zone Top-Level Domain (zTLD)</name> 563 <t> 564 A zTLD is a string that encodes the 565 zone type and zone key into a domain name suffix. 566 A zTLD is used as a globally unique reference to a 567 zone in the process of name resolution. 568 It is created by encoding a binary concatenation of the zone type and 569 zone key (see <xref target="figure_zid"/>). 570 The used encoding is a variation of the Crockford Base32 encoding 571 <xref target="CrockfordB32"/> called Base32GNS. 572 The encoding and decoding symbols for Base32GNS, including this 573 variation, are defined in <xref target="CrockfordB32Encode"/>, found in <xref target="app-c"/>. 574 The functions for encoding and decoding based on <xref target="CrockfordB32Encode"/> are called 575 Base32GNS-Encode and Base32GNS-Decode, respectively. 576 </t> 577 <figure anchor="figure_zid"> 578 <name>The Binary Representation of the zTLD</name> 579 <artwork name="" type="" alt=""> 580 0 8 16 24 32 40 48 56 581 +-----+-----+-----+-----+-----+-----+-----+-----+ 582 | ZONE TYPE | ZONE KEY / 583 +-----+-----+-----+-----+ / 584 / / 585 / / 586 +-----+-----+-----+-----+-----+-----+-----+-----+ 587 </artwork> 588 </figure> 589 <t> 590 The ZONE TYPE <bcp14>MUST</bcp14> be encoded in network byte order. The format 591 of the ZONE KEY depends entirely on the ZONE TYPE. 592 </t> 593 <t> 594 Consequently, a zTLD is encoded and decoded as follows: 595 </t> 596 <artwork name="" type="" alt=""> 597 zTLD := Base32GNS-Encode(ztype||zkey) 598 ztype||zkey := Base32GNS-Decode(zTLD) 599 </artwork> 600 <t> 601 where "||" is the concatenation operator. 602 </t> 603 <t> 604 The zTLD can be used "as is" as a rightmost label in a GNS name. 605 If an application wants to ensure DNS compatibility of the name, 606 it <bcp14>MAY</bcp14> also represent the zTLD as follows: 607 if the zTLD is less than or equal to 63 characters, it can 608 be used as a zTLD as is. 609 If the zTLD is longer than 63 characters, the 610 zTLD is divided into smaller labels separated by the label separator. 611 Here, the most significant bytes of the "ztype||zkey" concatenation 612 must be contained in the rightmost label of the resulting string and 613 the least significant bytes in the leftmost label of the resulting string. This allows the 614 resolver to determine the ztype and zTLD length from the rightmost 615 label and to subsequently determine how many labels the zTLD should span. 616 A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs 617 in DNS-compatible label lengths. 618 For example, assuming a zTLD of 130 characters, the division is as follows: 619 </t> 620 <artwork name="" type="" alt=""> 621 zTLD[126..129].zTLD[63..125].zTLD[0..62] 622 </artwork> 623 </section> 624 <section anchor="revocation"> 625 <name>Zone Revocation</name> 626 <t> 627 In order to revoke a zone key, a signed revocation message <bcp14>MUST</bcp14> be 628 published. 629 This message <bcp14>MUST</bcp14> be signed using the private key of the zone. 630 The revocation message is broadcast to the network. 631 The specification of the broadcast mechanism is out of scope for this 632 document. 633 A possible broadcast mechanism for efficient flooding in a distributed 634 network is implemented in <xref target="GNUnet"/>. 635 Alternatively, revocation messages could also be distributed via a 636 distributed ledger or a trusted central server. 637 To prevent 638 flooding attacks, the revocation message <bcp14>MUST</bcp14> contain a proof of work 639 (PoW). 640 The revocation message, including the PoW, <bcp14>MAY</bcp14> be calculated 641 ahead of time to support timely revocation. 642 </t> 643 <t> 644 For all occurrences below, "Argon2id" is the password-based key 645 derivation function as defined in <xref target="RFC9106"/>. For the 646 PoW calculations, the algorithm is instantiated with the 647 following parameters: 648 </t> 649 <dl newline="false"> 650 <dt>S:</dt> 651 <dd>The salt. Fixed 16-byte string: "GnsRevocationPow"</dd> 652 <dt>t:</dt> 653 <dd>Number of iterations: 3</dd> 654 <dt>m:</dt> 655 <dd>Memory size in KiB: 1024</dd> 656 <dt>T:</dt> 657 <dd>Output length of hash in bytes: 64</dd> 658 <dt>p:</dt> 659 <dd>Parallelization parameter: 1</dd> 660 <dt>v:</dt> 661 <dd>Algorithm version: 0x13</dd> 662 <dt>y:</dt> 663 <dd>Algorithm type (Argon2id): 2</dd> 664 <dt>X:</dt> 665 <dd>Unused</dd> 666 <dt>K:</dt> 667 <dd>Unused</dd> 668 </dl> 669 <t> 670 <xref target="figure_revocation"/> illustrates the format 671 of the data "P" on which the PoW is calculated. 672 </t> 673 <figure anchor="figure_revocation"> 674 <name>The Format of the PoW Data</name> 675 <artwork name="" type="" alt=""> 676 0 8 16 24 32 40 48 56 677 +-----+-----+-----+-----+-----+-----+-----+-----+ 678 | POW | 679 +-----------------------------------------------+ 680 | TIMESTAMP | 681 +-----------------------------------------------+ 682 | ZONE TYPE | ZONE KEY / 683 +-----+-----+-----+-----+ / 684 / / 685 / / 686 +-----+-----+-----+-----+-----+-----+-----+-----+ 687 </artwork> 688 </figure> 689 <dl newline="false"> 690 <dt>POW:</dt> 691 <dd> 692 A 64-bit value that is a solution to the PoW. In network byte order. 693 </dd> 694 <dt>TIMESTAMP:</dt> 695 <dd> 696 Denotes the absolute 64-bit date when the revocation was computed. 697 In microseconds since midnight (0 hour), January 1, 1970 UTC in network 698 byte order. 699 </dd> 700 <dt>ZONE TYPE:</dt> 701 <dd> 702 The 32-bit zone type in network byte order. 703 </dd> 704 <dt>ZONE KEY:</dt> 705 <dd> 706 The 256-bit public key zkey of the zone that is being revoked. 707 The wire format of this value is defined by the ZONE TYPE. 708 </dd> 709 </dl> 710 <t> 711 Usually, PoW schemes require that one POW value be found, such that 712 a specific number of leading zeroes are found in the hash result. 713 This number is then referred to as the difficulty of the PoW. 714 In order to reduce the variance in time it takes to calculate the 715 PoW, a valid GNS revocation requires that a number of different PoWs (Z, as defined below) 716 must be found that on average have at least D leading zeroes. 717 </t> 718 <t> 719 Given an average difficulty of D, the proofs have an 720 expiration time of EPOCH. Applications <bcp14>MAY</bcp14> calculate proofs 721 with a difficulty that is higher than D by providing POW 722 values where there are (on average) more than D bits of leading zeroes. 723 With each additional bit of difficulty, the 724 lifetime of the proof is prolonged by another EPOCH. 725 Consequently, by calculating a more difficult PoW, the lifetime of the 726 proof -- and thus the persistence of the revocation message -- 727 can be increased on demand by the zone owner. 728 </t> 729 <t> 730 The parameters are defined as follows: 731 </t> 732 <dl newline="false"> 733 <dt>Z:</dt> 734 <dd>The number of PoWs that are required. Its value is fixed at 32.</dd> 735 <dt>D:</dt> 736 <dd>The lower limit of the average difficulty. Its value is fixed at 22.</dd> 737 <dt>EPOCH:</dt> 738 <dd>A single epoch. Its value is fixed at 365 days in microseconds.</dd> 739 </dl> 740 <t> 741 The revocation message wire format is illustrated in 742 <xref target="figure_revocationdata"/>. 743 </t> 744 <figure anchor="figure_revocationdata"> 745 <name>The Revocation Message Wire Format</name> 746 <artwork name="" type="" alt=""> 747 0 8 16 24 32 40 48 56 748 +-----+-----+-----+-----+-----+-----+-----+-----+ 749 | TIMESTAMP | 750 +-----+-----+-----+-----+-----+-----+-----+-----+ 751 | TTL | 752 +-----+-----+-----+-----+-----+-----+-----+-----+ 753 | POW_0 | 754 +-----+-----+-----+-----+-----+-----+-----+-----+ 755 | ... | 756 +-----+-----+-----+-----+-----+-----+-----+-----+ 757 | POW_(Z-1) | 758 +-----------------------------------------------+ 759 | ZONE TYPE | ZONE KEY / 760 +-----+-----+-----+-----+ / 761 / / 762 / / 763 +-----+-----+-----+-----+-----+-----+-----+-----+ 764 / SIGNATURE / 765 / / 766 / / 767 / / 768 +-----+-----+-----+-----+-----+-----+-----+-----+ 769 </artwork> 770 </figure> 771 <dl newline="false"> 772 <dt>TIMESTAMP:</dt> 773 <dd> 774 Denotes the absolute 64-bit date when the revocation was computed. 775 In microseconds since midnight (0 hour), January 1, 1970 UTC in network 776 byte order. This is the same value as the timestamp used in the 777 individual PoW calculations. 778 </dd> 779 <dt>TTL:</dt> 780 <dd> 781 Denotes the relative 64-bit time to live of the record in 782 microseconds in network byte order. 783 The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1. 784 Given an average number of leading zeroes D', then the field value 785 <bcp14>MAY</bcp14> be increased up to (D'-D+1) * EPOCH * 1.1. 786 Validators <bcp14>MAY</bcp14> reject messages with lower or higher 787 values when received. 788 </dd> 789 <dt>POW_i:</dt> 790 <dd> 791 The values calculated as part of the PoW, in network byte order. 792 Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values. 793 To facilitate fast verification 794 of uniqueness, the POW values <bcp14>MUST</bcp14> be given in strictly 795 monotonically increasing order in the message. 796 </dd> 797 <dt>ZONE TYPE:</dt> 798 <dd> 799 The 32-bit zone type corresponding to the zone key in network byte order. 800 </dd> 801 <dt>ZONE KEY:</dt> 802 <dd> 803 The public key zkey of the zone that is being revoked and 804 the key to be used to verify SIGNATURE. 805 </dd> 806 <dt>SIGNATURE:</dt> 807 <dd> 808 A signature over a timestamp and the zone zkey of the zone 809 that is revoked and corresponds to the key used in the PoW. 810 The signature is created using the Sign() function of 811 the cryptosystem of the zone and the private key 812 (see <xref target="zones"/>). 813 </dd> 814 </dl> 815 <t> 816 The signature in the revocation message covers a 32-bit header 817 prefixed to the TIMESTAMP, ZONE TYPE, and ZONE KEY fields. 818 The header includes the key length and signature purpose. 819 The wire format is illustrated 820 in <xref target="figure_revsigwithpseudo"/>. 821 </t> 822 <figure anchor="figure_revsigwithpseudo"> 823 <name>The Wire Format of the Revocation Data for Signing</name> 824 <artwork name="" type="" alt=""> 825 0 8 16 24 32 40 48 56 826 +-----+-----+-----+-----+-----+-----+-----+-----+ 827 | SIZE | PURPOSE (0x03) | 828 +-----+-----+-----+-----+-----+-----+-----+-----+ 829 | TIMESTAMP | 830 +-----+-----+-----+-----+-----+-----+-----+-----+ 831 | ZONE TYPE | ZONE KEY / 832 +-----+-----+-----+-----+ / 833 / / 834 / / 835 +-----+-----+-----+-----+-----+-----+-----+-----+ 836 </artwork> 837 </figure> 838 <dl newline="false"> 839 <dt>SIZE:</dt> 840 <dd> 841 A 32-bit value containing the length of the signed data in bytes 842 in network byte order. 843 </dd> 844 <dt>PURPOSE:</dt> 845 <dd> 846 A 32-bit signature purpose flag. 847 The value of this field <bcp14>MUST</bcp14> be 3. 848 The value is encoded in network byte order. 849 It defines the context in which 850 the signature is created so that it cannot be reused in other parts 851 of the protocol that might include possible future extensions. 852 The value of this field corresponds to an entry in the 853 GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>. 854 </dd> 855 <dt>TIMESTAMP:</dt> 856 <dd> 857 Field as defined in the revocation message above. 858 </dd> 859 <dt>ZONE TYPE:</dt> 860 <dd> 861 Field as defined in the revocation message above. 862 </dd> 863 <dt>ZONE KEY:</dt> 864 <dd>Field as defined in the revocation message above.</dd> 865 </dl> 866 <t> 867 In order to validate a revocation, the following steps <bcp14>MUST</bcp14> be taken: 868 </t> 869 <ol> 870 <li>The signature <bcp14>MUST</bcp14> be verified against the zone key.</li> 871 <li>The set of POW values <bcp14>MUST NOT</bcp14> contain duplicates; this <bcp14>MUST</bcp14> be checked by verifying that the values are strictly monotonically increasing.</li> 872 <li>The average number of leading zeroes D' resulting from the provided 873 POW values <bcp14>MUST</bcp14> be greater than or equal to D. Implementers 874 <bcp14>MUST NOT</bcp14> use an integer data type to calculate or represent D'.</li> 875 </ol> 876 <t> 877 The TTL field in the revocation message is informational. 878 A revocation <bcp14>MAY</bcp14> be discarded without checking the POW 879 values or the signature if the TTL (in combination with TIMESTAMP) 880 indicates that the revocation has already expired. 881 The actual validity period of the 882 revocation <bcp14>MUST</bcp14> be determined by examining the leading 883 zeroes in the POW values. 884 </t> 885 <t> 886 The validity period of the revocation is calculated as 887 (D'-D+1) * EPOCH * 1.1. The EPOCH is extended by 888 10% in order to deal with poorly synchronized clocks. 889 The validity period added on top of the TIMESTAMP yields the 890 expiration date. 891 If the current time is after the expiration date, the 892 revocation is considered stale. 893 </t> 894 <t> 895 Verified revocations <bcp14>MUST</bcp14> be stored locally. 896 The implementation <bcp14>MAY</bcp14> discard stale revocations and 897 evict them from the local store at any time. 898 </t> 899 <t> 900 It is important that implementations broadcast received revocations 901 if they are valid and not stale. 902 Should the calculated validity period differ from the TTL field value, 903 the calculated value <bcp14>MUST</bcp14> be used as the TTL field value 904 when forwarding the revocation message. 905 Systems might disagree on the current time, so implementations 906 <bcp14>MAY</bcp14> use stale but otherwise valid 907 revocations but <bcp14>SHOULD NOT</bcp14> broadcast them. 908 Forwarded stale revocations <bcp14>MAY</bcp14> be discarded by the receiver. 909 </t> 910 <t> 911 Any locally stored revocation <bcp14>MUST</bcp14> be considered during 912 delegation record processing (see <xref target="delegation_processing"/>). 913 </t> 914 </section> 915 </section> 916 <section anchor="rrecords"> 917 <name>Resource Records</name> 918 <t> 919 A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism for creating and managing local 920 zones as well as a persistence mechanism (such as a local database) for resource 921 records. 922 A new local zone is established by selecting a zone type and creating a 923 zone key pair. 924 If this mechanism is not implemented, 925 no zones can be published in storage (see <xref target="publish"/>) 926 and name resolution is limited to non-local Start Zones 927 (see <xref target="governance"/>). 928 </t> 929 <t> 930 A GNS resource record holds the data of a specific record in a zone. 931 The resource record format is illustrated in 932 <xref target="figure_gnsrecord"/>. 933 </t> 934 <figure anchor="figure_gnsrecord"> 935 <name>The Resource Record Wire Format</name> 936 <artwork name="" type="" alt=""> 937 0 8 16 24 32 40 48 56 938 +-----+-----+-----+-----+-----+-----+-----+-----+ 939 | EXPIRATION | 940 +-----+-----+-----+-----+-----+-----+-----+-----+ 941 | SIZE | FLAGS | TYPE | 942 +-----+-----+-----+-----+-----+-----+-----+-----+ 943 | DATA / 944 / / 945 / / 946 </artwork> 947 </figure> 948 <dl newline="false"> 949 <dt>EXPIRATION:</dt> 950 <dd> 951 Denotes the absolute 64-bit expiration date of the record. 952 In microseconds since midnight (0 hour), January 1, 1970 UTC in network 953 byte order. 954 </dd> 955 <dt>SIZE:</dt> 956 <dd> 957 Denotes the 16-bit size of the DATA field in bytes in network byte 958 order. 959 </dd> 960 <dt>FLAGS:</dt> 961 <dd> 962 A 16-bit field indicating special properties of the resource record. 963 The semantics of the different bits are defined below. 964 </dd> 965 <dt>TYPE:</dt> 966 <dd> 967 The 32-bit resource record type in 968 network byte order. This type can be one of the GNS resource 969 records as defined in <xref target="rrecords"/>, a DNS record 970 type as defined in <xref target="RFC1035"/>, or any of the 971 complementary standardized DNS resource record types. 972 Note that values 973 below 2<sup>16</sup> are reserved for 16-bit DNS resource record types allocated by IANA <xref target="RFC6895"/>. 974 Values above 2<sup>16</sup> are allocated by the 975 GANA "GNS Record Types" registry <xref target="GANA"/>. 976 </dd> 977 <dt>DATA:</dt> 978 <dd> 979 The variable-length resource record data payload. The content is defined 980 by the 981 respective type of the resource record. 982 </dd> 983 </dl> 984 <t> 985 The FLAGS field is used to indicate special properties of the resource record. 986 An application creating resource records <bcp14>MUST</bcp14> set all bits 987 in FLAGS to 0 unless it specifically understands and 988 wants to set the respective flag. 989 As additional flags can be defined in future protocol versions, 990 if an application or implementation encounters a flag that it does not 991 recognize, the flag <bcp14>MUST</bcp14> be ignored. However, all implementations 992 <bcp14>MUST</bcp14> understand the SHADOW and CRITICAL flags defined below. 993 Any combination of the flags specified below is valid. 994 <xref target="figure_flag"/> 995 illustrates the flag distribution in the 16-bit FLAGS field of a 996 resource record: 997 </t> 998 <figure anchor="figure_flag"> 999 <name>The Resource Record Flag Wire Format</name> 1000 <artwork name="" type="" alt=""> 1001 0 13 14 15 1002 +--------...+-------------+-------+---------+ 1003 | Reserved |SUPPLEMENTAL |SHADOW |CRITICAL | 1004 +--------...+-------------+-------+---------+ 1005 </artwork> 1006 </figure> 1007 <dl newline="false"> 1008 <dt>CRITICAL:</dt> 1009 <dd> 1010 If this flag is set, it indicates that processing is critical. 1011 Implementations that do not support the record type or are otherwise 1012 unable to process the record <bcp14>MUST</bcp14> abort resolution upon encountering 1013 the record in the resolution process. 1014 </dd> 1015 <dt>SHADOW:</dt> 1016 <dd> 1017 If this flag is set, this record <bcp14>MUST</bcp14> be ignored by resolvers unless all (other) 1018 records of the same record type have expired. Used to allow zone publishers to 1019 facilitate good performance when records change by allowing them to put future 1020 values of records into storage. 1021 This way, future values can propagate and can be 1022 cached before the transition becomes active. 1023 </dd> 1024 <dt>SUPPLEMENTAL:</dt> 1025 <dd> 1026 This is a supplemental record. It is provided in addition to the 1027 other records. This flag indicates that this record is not explicitly 1028 managed alongside the other records under the respective name but 1029 might be useful for the application. 1030 </dd> 1031 </dl> 1032 <section anchor="gnsrecords_delegation"> 1033 <name>Zone Delegation Records</name> 1034 <t> 1035 This section defines the initial set of zone delegation record types. 1036 Any implementation <bcp14>SHOULD</bcp14> support all zone types defined here and 1037 <bcp14>MAY</bcp14> support any number of additional delegation records defined in 1038 the GANA "GNS Record Types" registry (see <xref target="GANA"/>). 1039 Not supporting some zone types will result in resolution failures if 1040 the respective zone type is encountered. 1041 This can be a valid choice if some zone delegation record types have been 1042 determined to be cryptographically insecure. 1043 Zone delegation records <bcp14>MUST NOT</bcp14> be stored or published 1044 under the apex label. 1045 A zone delegation record type value is the same as the respective ztype 1046 value. 1047 The ztype defines the cryptographic primitives for the zone that is 1048 being delegated to. 1049 A zone delegation record payload contains the public key of 1050 the zone to delegate to. 1051 A zone delegation record <bcp14>MUST</bcp14> have the CRITICAL flag set 1052 and <bcp14>MUST</bcp14> be the only non-supplemental record under a label. 1053 There <bcp14>MAY</bcp14> be inactive records of the same type that have 1054 the SHADOW flag set in order to facilitate smooth key rollovers. 1055 </t> 1056 <t> 1057 In the following, "||" is the concatenation operator of two byte strings. 1058 The algorithm specification uses character strings such as GNS labels or 1059 constant values. 1060 When used in concatenations or as input to functions, the 1061 zero terminator of the character strings <bcp14>MUST NOT</bcp14> be 1062 included. 1063 </t> 1064 <section anchor="gnsrecords_pkey"> 1065 <name>PKEY</name> 1066 <t> 1067 In GNS, a delegation of a label to a zone of type "PKEY" is 1068 represented through a PKEY record. The PKEY DATA entry wire format is illustrated in <xref target="figure_pkeyrecord"/>. 1069 </t> 1070 <figure anchor="figure_pkeyrecord"> 1071 <name>The PKEY Wire Format</name> 1072 <artwork name="" type="" alt=""> 1073 0 8 16 24 32 40 48 56 1074 +-----+-----+-----+-----+-----+-----+-----+-----+ 1075 | PUBLIC KEY | 1076 | | 1077 | | 1078 | | 1079 +-----+-----+-----+-----+-----+-----+-----+-----+ 1080 </artwork> 1081 </figure> 1082 <dl newline="false"> 1083 <dt>PUBLIC KEY:</dt> 1084 <dd> 1085 A 256-bit Ed25519 public key. 1086 </dd> 1087 </dl> 1088 <t> 1089 For PKEY zones, the zone key material is derived using the 1090 curve parameters of the twisted Edwards representation 1091 of Curve25519 <xref target="RFC7748"/> (the reasoning behind choosing 1092 this curve can be found in <xref target="security_cryptography"/>) 1093 with the ECDSA scheme <xref target="RFC6979"/>. 1094 The following naming convention is used for the cryptographic primitives of PKEY zones: 1095 </t> 1096 <dl newline="false"> 1097 <dt>d:</dt> 1098 <dd> 1099 A 256-bit Ed25519 private key (clamped private scalar). 1100 </dd> 1101 <dt>zkey:</dt> 1102 <dd> 1103 The Ed25519 public zone key corresponding to d. 1104 </dd> 1105 <dt>p:</dt> 1106 <dd> 1107 The prime of edwards25519 as defined in <xref target="RFC7748"/>, i.e., 1108 2<sup>255</sup> - 19. 1109 </dd> 1110 <dt>G:</dt> 1111 <dd> 1112 The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in 1113 <xref target="RFC7748"/>. 1114 </dd> 1115 <dt>L:</dt> 1116 <dd> 1117 The order of the prime-order subgroup of edwards25519 as defined in <xref target="RFC7748"/>. 1118 </dd> 1119 <dt>KeyGen():</dt> 1120 <dd>The generation of the private 1121 scalar d and the curve point zkey := d*G (where G is the group generator 1122 of the elliptic curve) as defined in <xref target="RFC6979" sectionFormat="of" section="2.2"/> represents the KeyGen() function. 1123 </dd> 1124 </dl> 1125 <t> 1126 The zone type and zone key of a PKEY are 4 + 32 bytes in length. This means that 1127 a zTLD will always fit into a single label and does 1128 not need any further conversion. 1129 Given a label, the output zkey' of the ZKDF(zkey, label) function is 1130 calculated as follows for PKEY zones: 1131 </t> 1132 <artwork name="" type="" alt=""> 1133 ZKDF(zkey, label): 1134 PRK_h := HKDF-Extract("key-derivation", zkey) 1135 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8) 1136 zkey' := (h mod L) * zkey 1137 return zkey' 1138 </artwork> 1139 <t> 1140 The PKEY cryptosystem uses an HMAC-based key derivation function (HKDF) as defined in 1141 <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/> for the extraction 1142 phase and SHA-256 <xref target="RFC6234"/> for the expansion phase. 1143 PRK_h is key material retrieved using an HKDF that uses the string 1144 "key-derivation" as the salt and the zone key as the initial 1145 keying material. 1146 h is the 512-bit HKDF expansion result and must be interpreted in 1147 network byte order. The expansion information input is 1148 a concatenation of the label and the string "gns". 1149 The multiplication of zkey with h in ZKDF() is a point multiplication, 1150 while the multiplication of d with h in SignDerived() below is a scalar multiplication. 1151 </t> 1152 <t> 1153 The Sign() and Verify() functions 1154 for PKEY zones are implemented using 512-bit ECDSA deterministic 1155 signatures as specified in <xref target="RFC6979"/>. 1156 The same functions can be used for derived keys: 1157 </t> 1158 <artwork name="" type="" alt=""> 1159 SignDerived(d, label, message): 1160 zkey := d * G 1161 PRK_h := HKDF-Extract("key-derivation", zkey) 1162 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8) 1163 d' := (h * d) mod L 1164 return Sign(d', message) 1165 </artwork> 1166 <t> 1167 A signature is valid for the derived public key zkey' := ZKDF(zkey, label) if the following holds: 1168 </t> 1169 <artwork name="" type="" alt=""> 1170 VerifyDerived(zkey', message, signature): 1171 return Verify(zkey', message, signature) 1172 </artwork> 1173 <t> 1174 The S-Encrypt() and S-Decrypt() functions use AES in counter mode 1175 as defined in <xref target="MODES"/> (CTR-AES256): 1176 </t> 1177 <artwork name="" type="" alt=""> 1178 S-Encrypt(zkey, label, expiration, plaintext): 1179 PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey) 1180 PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey) 1181 K := HKDF-Expand(PRK_k, label, 256 / 8) 1182 NONCE := HKDF-Expand(PRK_n, label, 32 / 8) 1183 BLOCK_COUNTER := 0x0000000000000001 1184 IV := NONCE || expiration || BLOCK_COUNTER 1185 return CTR-AES256(K, IV, plaintext) 1186 1187 S-Decrypt(zkey, label, expiration, ciphertext): 1188 PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey) 1189 PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey) 1190 K := HKDF-Expand(PRK_k, label, 256 / 8) 1191 NONCE := HKDF-Expand(PRK_n, label, 32 / 8) 1192 BLOCK_COUNTER := 0x0000000000000001 1193 IV := NONCE || expiration || BLOCK_COUNTER 1194 return CTR-AES256(K, IV, ciphertext) 1195 </artwork> 1196 <t> 1197 The key K and counter Initialization Vector (IV) are derived from 1198 the record label and the zone key zkey, using an HKDF as defined in <xref target="RFC5869"/>. 1199 SHA-512 <xref target="RFC6234"/> is used for the 1200 extraction phase and SHA-256 <xref target="RFC6234"/> for the expansion phase. 1201 The output keying material is 32 bytes (256 bits) for the symmetric 1202 key and 4 bytes (32 bits) for the NONCE. 1203 The symmetric key K is a 256-bit AES key <xref target="RFC3826"/>. 1204 </t> 1205 <t> 1206 The nonce is combined with a 64-bit IV and a 1207 32-bit block counter as defined in <xref target="RFC3686"/>. 1208 The block counter begins with a value of 1, and it is incremented 1209 to generate subsequent portions of the key stream. 1210 The block counter is a 32-bit integer value in network byte order. 1211 The format of the counter IV used by the S-Encrypt() and S-Decrypt() 1212 functions is illustrated in 1213 <xref target="figure_hkdf_ivs_pkey"/>. 1214 </t> 1215 <figure anchor="figure_hkdf_ivs_pkey"> 1216 <name>Structure of the Counter IV as Used in S-Encrypt() and 1217 S-Decrypt()</name> 1218 <artwork name="" type="" alt=""> 1219 0 8 16 24 32 1220 +-----+-----+-----+-----+ 1221 | NONCE | 1222 +-----+-----+-----+-----+ 1223 | EXPIRATION | 1224 | | 1225 +-----+-----+-----+-----+ 1226 | BLOCK COUNTER | 1227 +-----+-----+-----+-----+ 1228 </artwork> 1229 </figure> 1230 </section> 1231 <section anchor="gnsrecords_edkey"> 1232 <name>EDKEY</name> 1233 <t> 1234 In GNS, a delegation of a label to a zone of type "EDKEY" is 1235 represented through an EDKEY record. 1236 The EDKEY DATA entry wire format 1237 is illustrated in <xref target="figure_edkeyrecord"/>. 1238 </t> 1239 <figure anchor="figure_edkeyrecord"> 1240 <name>The EDKEY DATA Wire Format</name> 1241 <artwork name="" type="" alt=""> 1242 0 8 16 24 32 40 48 56 1243 +-----+-----+-----+-----+-----+-----+-----+-----+ 1244 | PUBLIC KEY | 1245 | | 1246 | | 1247 | | 1248 +-----+-----+-----+-----+-----+-----+-----+-----+ 1249 </artwork> 1250 </figure> 1251 <dl newline="false"> 1252 <dt>PUBLIC KEY:</dt> 1253 <dd> 1254 A 256-bit EdDSA zone key. 1255 </dd> 1256 </dl> 1257 <t> 1258 For EDKEY zones, the zone key material is derived using the 1259 curve parameters of the twisted Edwards representation 1260 of Curve25519 <xref target="RFC7748"/> (a.k.a. Ed25519) 1261 with the Ed25519 scheme <xref target="ed25519"/> as specified in 1262 <xref target="RFC8032"/>. 1263 The following naming convention is used for the 1264 cryptographic primitives of EDKEY zones: 1265 </t> 1266 <dl newline="false"> 1267 <dt>d:</dt> 1268 <dd> 1269 A 256-bit EdDSA private key. 1270 </dd> 1271 <dt>a:</dt> 1272 <dd> 1273 An integer derived from d using the SHA-512 hash function 1274 as defined in <xref target="RFC8032"/>. 1275 </dd> 1276 <dt>zkey:</dt> 1277 <dd> 1278 The EdDSA public key corresponding to d. It is defined 1279 as the curve point a*G where G is the 1280 group generator of the elliptic curve 1281 as defined in <xref target="RFC8032"/>. 1282 </dd> 1283 <dt>p:</dt> 1284 <dd> 1285 The prime of edwards25519 as defined in <xref target="RFC8032"/>, i.e., 1286 2<sup>255</sup> - 19. 1287 </dd> 1288 <dt>G:</dt> 1289 <dd> 1290 The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in 1291 <xref target="RFC8032"/>. 1292 </dd> 1293 <dt>L:</dt> 1294 <dd> 1295 The order of the prime-order subgroup of edwards25519 as defined in <xref target="RFC8032"/>. 1296 </dd> 1297 <dt>KeyGen():</dt> 1298 <dd> 1299 The generation of the private key d and the associated public 1300 key zkey := a*G (where G is the 1301 group generator of the elliptic curve and a is an integer 1302 derived from d using the SHA-512 hash function) 1303 as defined 1304 in <xref target="RFC8032" sectionFormat="of" section="5.1.5"/> 1305 represents the KeyGen() 1306 function. 1307 </dd> 1308 </dl> 1309 <t> 1310 The zone type and zone key of an EDKEY are 4 + 32 bytes in length. This means that 1311 a zTLD will always fit into a single label and does 1312 not need any further conversion. 1313 </t> 1314 <t> 1315 The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>. 1316 As noted above for KeyGen(), a is calculated from d using the 1317 SHA-512 hash function as defined in <xref target="RFC8032" sectionFormat="of" section="5.1.5"/>. 1318 Given a label, the output of the ZKDF function is 1319 calculated as follows: 1320 </t> 1321 <artwork name="" type="" alt=""> 1322 ZKDF(zkey, label): 1323 /* Calculate the blinding factor */ 1324 PRK_h := HKDF-Extract("key-derivation", zkey) 1325 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8) 1326 /* Ensure that h == h mod L */ 1327 h := h mod L 1328 1329 zkey' := h * zkey 1330 return zkey' 1331 </artwork> 1332 <t> 1333 Implementers <bcp14>SHOULD</bcp14> employ a constant-time scalar 1334 multiplication for the constructions above to protect against 1335 timing attacks. Otherwise, timing attacks could leak private key 1336 material if an attacker can predict when a system starts the 1337 publication process. 1338 </t> 1339 <t> 1340 The EDKEY cryptosystem uses an HKDF as defined in 1341 <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/> for the extraction 1342 phase and HMAC-SHA-256 <xref target="RFC6234"/> for the expansion phase. 1343 PRK_h is key material retrieved using an HKDF that uses the string 1344 "key-derivation" as the salt and the zone key as the initial 1345 keying material. 1346 The blinding factor h is the 512-bit HKDF expansion result. 1347 The expansion information input is 1348 a concatenation of the label and the string "gns". 1349 The result of the HKDF must be clamped and interpreted in network 1350 byte order. 1351 a is the 256-bit integer corresponding to the 256-bit private 1352 key d. 1353 The multiplication of zkey with h is a point multiplication. 1354 </t> 1355 <t> 1356 The Sign(d, message) and Verify(zkey, message, signature) procedures <bcp14>MUST</bcp14> 1357 be implemented as defined in <xref target="RFC8032"/>. 1358 </t> 1359 <t> 1360 Signatures for EDKEY zones use a derived private scalar d'; 1361 this is not compliant with <xref target="RFC8032"/>. 1362 As the private key that corresponds to the derived private scalar 1363 is not known, it is not possible to deterministically derive the 1364 signature part R according to <xref target="RFC8032"/>. 1365 Instead, signatures <bcp14>MUST</bcp14> be generated as follows for any given 1366 message and private zone key: 1367 a nonce is calculated from the highest 32 bytes of the 1368 expansion of the private key d and the blinding factor h. 1369 The nonce is then hashed with the message to r. 1370 This way, the full derivation path is included in the calculation 1371 of the R value of the signature, ensuring that it is never reused 1372 for two different derivation paths or messages. 1373 </t> 1374 <artwork name="" type="" alt=""> 1375 SignDerived(d, label, message): 1376 /* Key expansion */ 1377 dh := SHA-512(d) 1378 /* EdDSA clamping */ 1379 a := dh[0..31] 1380 a[0] := a[0] & 248 1381 a[31] := a[31] & 127 1382 a[31] := a[31] | 64 1383 /* Calculate zkey corresponding to d */ 1384 zkey := a * G 1385 1386 /* Calculate blinding factor */ 1387 PRK_h := HKDF-Extract("key-derivation", zkey) 1388 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8) 1389 /* Ensure that h == h mod L */ 1390 h := h mod L 1391 1392 d' := (h * a) mod L 1393 nonce := SHA-256(dh[32..63] || h) 1394 r := SHA-512(nonce || message) 1395 R := r * G 1396 S := r + SHA-512(R || zkey' || message) * d' mod L 1397 return (R,S) 1398 </artwork> 1399 <t> 1400 A signature (R,S) is valid for the derived public key zkey' := 1401 ZKDF(zkey, label) if the following holds: 1402 </t> 1403 <artwork name="" type="" alt=""> 1404 VerifyDerived(zkey', message, signature): 1405 (R,S) := signature 1406 return S * G == R + SHA-512(R, zkey', message) * zkey' 1407 </artwork> 1408 <t> 1409 The S-Encrypt() and S-Decrypt() functions use XSalsa20 1410 as defined in <xref target="XSalsa20"/> 1411 and use the XSalsa20-Poly1305 encryption function: 1412 </t> 1413 <artwork name="" type="" alt=""> 1414 S-Encrypt(zkey, label, expiration, plaintext): 1415 PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey) 1416 PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey) 1417 K := HKDF-Expand(PRK_k, label, 256 / 8) 1418 NONCE := HKDF-Expand(PRK_n, label, 128 / 8) 1419 IV := NONCE || expiration 1420 return XSalsa20-Poly1305(K, IV, plaintext) 1421 1422 S-Decrypt(zkey, label, expiration, ciphertext): 1423 PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey) 1424 PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey) 1425 K := HKDF-Expand(PRK_k, label, 256 / 8) 1426 NONCE := HKDF-Expand(PRK_n, label, 128 / 8) 1427 IV := NONCE || expiration 1428 return XSalsa20-Poly1305(K, IV, ciphertext) 1429 </artwork> 1430 <t> 1431 The result of the XSalsa20-Poly1305 encryption function is the encrypted 1432 ciphertext followed by the 128-bit authentication 1433 tag. 1434 Accordingly, the length of encrypted data equals the length of the 1435 data plus the 16 bytes of the authentication tag. 1436 </t> 1437 <t> 1438 The key K and counter IV are derived from 1439 the record label and the zone key zkey using an HKDF as defined in 1440 <xref target="RFC5869"/>. 1441 SHA-512 <xref target="RFC6234"/> is used for the 1442 extraction phase and SHA-256 <xref target="RFC6234"/> for the expansion phase. 1443 The output keying material is 32 bytes (256 bits) for the symmetric 1444 key and 16 bytes (128 bits) for the NONCE. 1445 The symmetric key K is a 256-bit XSalsa20 key 1446 <xref target="XSalsa20"/>. 1447 No additional authenticated data (AAD) is used. 1448 </t> 1449 <t> 1450 The nonce is combined with an 8-byte IV. 1451 The IV is the expiration time of the 1452 resource record block in network byte order. 1453 The resulting counter (IV) wire format is illustrated in 1454 <xref target="figure_hkdf_ivs_edkey"/>. 1455 </t> 1456 <figure anchor="figure_hkdf_ivs_edkey"> 1457 <name>The Counter Block Initialization Vector</name> 1458 <artwork name="" type="" alt=""> 1459 0 8 16 24 32 40 48 56 1460 +-----+-----+-----+-----+-----+-----+-----+-----+ 1461 | NONCE | 1462 | | 1463 +-----+-----+-----+-----+-----+-----+-----+-----+ 1464 | EXPIRATION | 1465 +-----+-----+-----+-----+-----+-----+-----+-----+ 1466 </artwork> 1467 </figure> 1468 </section> 1469 </section> 1470 <section anchor="gnsrecords_redirect"> 1471 <name>Redirection Records</name> 1472 <t> 1473 Redirection records are used to redirect resolution. 1474 Any implementation <bcp14>SHOULD</bcp14> support all redirection record types defined here 1475 and <bcp14>MAY</bcp14> support any number of additional redirection records defined in 1476 the GANA "GNS Record Types" registry <xref target="GANA"/>. 1477 Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set. 1478 Not supporting some record types can result in resolution failures. 1479 This can be a valid choice if some redirection record types have been 1480 determined to be insecure, or if an application has reasons to not 1481 support redirection to DNS for reasons such as complexity or security. 1482 Redirection records <bcp14>MUST NOT</bcp14> be stored or published under the apex label. 1483 </t> 1484 <section anchor="gnsrecords_rdr"> 1485 <name>REDIRECT</name> 1486 <t> 1487 A REDIRECT record is the GNS equivalent of a CNAME record in DNS. 1488 A REDIRECT record <bcp14>MUST</bcp14> be the only non-supplemental 1489 record under a label. 1490 There <bcp14>MAY</bcp14> be inactive records of the same type that have 1491 the SHADOW flag set in order to facilitate smooth changes of redirection 1492 targets. 1493 No other records are allowed. 1494 Details on the processing of this record are provided in <xref target="redirect_processing"/>. 1495 1496 A REDIRECT DATA entry is illustrated in <xref target="figure_redirectrecord"/>. 1497 </t> 1498 <figure anchor="figure_redirectrecord"> 1499 <name>The REDIRECT DATA Wire Format</name> 1500 <artwork name="" type="" alt=""> 1501 0 8 16 24 32 40 48 56 1502 +-----+-----+-----+-----+-----+-----+-----+-----+ 1503 | REDIRECT NAME | 1504 / / 1505 / / 1506 | | 1507 +-----+-----+-----+-----+-----+-----+-----+-----+ 1508 </artwork> 1509 </figure> 1510 <dl newline="false"> 1511 <dt>REDIRECT NAME:</dt> 1512 <dd> 1513 The name to continue with. 1514 This value can be a regular name or a relative 1515 name. 1516 Relative GNS names are indicated by an extension label (U+002B ("+")) 1517 as the rightmost label. 1518 The string is UTF-8 encoded and zero terminated. 1519 </dd> 1520 </dl> 1521 </section> 1522 <section anchor="gnsrecords_gns2dns"> 1523 <name>GNS2DNS</name> 1524 <t> 1525 A GNS2DNS record delegates resolution to DNS. 1526 The resource record contains a DNS name for the resolver to continue with 1527 in DNS followed by a DNS server. Both names are in the format defined in 1528 <xref target="RFC1034"/> for DNS names. 1529 There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label. 1530 There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other records used to 1531 secure the connection with the DNS servers under the same label. 1532 There <bcp14>MAY</bcp14> be inactive records of the same type or types that have 1533 the SHADOW flag set in order to facilitate smooth changes of redirection 1534 targets. 1535 No other non-supplemental record types are allowed in the same record set. 1536 A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsrecord"/>.</t> 1537 <figure anchor="figure_gns2dnsrecord"> 1538 <name>The GNS2DNS DATA Wire Format</name> 1539 <artwork name="" type="" alt=""> 1540 0 8 16 24 32 40 48 56 1541 +-----+-----+-----+-----+-----+-----+-----+-----+ 1542 | NAME | 1543 / / 1544 / / 1545 | | 1546 +-----+-----+-----+-----+-----+-----+-----+-----+ 1547 | DNS SERVER NAME | 1548 / / 1549 / / 1550 | | 1551 +-----------------------------------------------+ 1552 </artwork> 1553 </figure> 1554 <dl newline="false"> 1555 <dt>NAME:</dt> 1556 <dd> 1557 The name to continue with in DNS. The value is UTF-8 encoded and 1558 zero terminated. 1559 </dd> 1560 <dt>DNS SERVER NAME:</dt> 1561 <dd> 1562 The DNS server to use. This value can be an IPv4 address in dotted-decimal 1563 form, an IPv6 address in colon-hexadecimal form, or a DNS name. 1564 It can also be a relative GNS name ending with a 1565 "+" as the rightmost label. 1566 The implementation <bcp14>MUST</bcp14> check the string syntactically for 1567 an IP address in the respective notation before checking for a 1568 relative GNS name. 1569 If all three checks fail, the name <bcp14>MUST</bcp14> be treated as a DNS name. 1570 The value is UTF-8 encoded and zero terminated. 1571 </dd> 1572 </dl> 1573 <t> 1574 NOTE: If an application uses DNS names obtained from GNS2DNS records 1575 in a DNS request, they <bcp14>MUST</bcp14> first be converted to an IDNA-compliant 1576 representation <xref target="RFC5890"/>. 1577 </t> 1578 </section> 1579 </section> 1580 <section anchor="gnsrecords_other"> 1581 <name>Auxiliary Records</name> 1582 <t> 1583 This section defines the initial set of auxiliary GNS record types. Any 1584 implementation <bcp14>SHOULD</bcp14> be able to process the specified record types 1585 according to <xref target="record_processing"/>. 1586 </t> 1587 <section anchor="gnsrecords_leho"> 1588 <name>LEHO</name> 1589 <t> 1590 The LEHO (LEgacy HOstname) record is used to provide a hint for legacy hostnames: 1591 applications can use the GNS to look up IPv4 or IPv6 addresses of 1592 Internet services. 1593 However, connecting to such services sometimes not only requires 1594 the knowledge of an IP address and port but also requires the canonical 1595 DNS name of the service to be transmitted over the transport protocol. 1596 In GNS, legacy hostname records provide applications the DNS name that 1597 is required to establish a connection to such a service. 1598 The most common use case is HTTP virtual hosting and TLS Server Name 1599 Indication <xref target="RFC6066"/>, where a DNS name must 1600 be supplied in the HTTP "Host"-header and the TLS handshake, 1601 respectively. 1602 Using a GNS name in those cases might not work, as 1603 it might not be globally unique. Furthermore, even if uniqueness is 1604 not an issue, the legacy service might not even be aware of GNS. 1605 </t> 1606 <t> 1607 A LEHO resource record is expected to be found together with A or AAAA 1608 resource records with IPv4 or IPv6 addresses. 1609 A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/>. 1610 </t> 1611 <figure anchor="figure_lehorecord"> 1612 <name>The LEHO DATA Wire Format</name> 1613 <artwork name="" type="" alt=""> 1614 0 8 16 24 32 40 48 56 1615 +-----+-----+-----+-----+-----+-----+-----+-----+ 1616 | LEGACY HOSTNAME | 1617 / / 1618 / / 1619 | | 1620 +-----+-----+-----+-----+-----+-----+-----+-----+ 1621 </artwork> 1622 </figure> 1623 <dl newline="false"> 1624 <dt>LEGACY HOSTNAME:</dt> 1625 <dd> 1626 A UTF-8 string (which is not zero terminated) representing the legacy hostname. 1627 </dd> 1628 </dl> 1629 <t> 1630 NOTE: If an application uses a LEHO value in an HTTP request header 1631 (e.g., a "Host"-header), it <bcp14>MUST</bcp14> be converted to an IDNA-compliant representation 1632 <xref target="RFC5890"/>. 1633 </t> 1634 </section> 1635 <section anchor="gnsrecords_nick"> 1636 <name>NICK</name> 1637 <t> 1638 Nickname records can be used by zone administrators to publish a 1639 label that a zone prefers to have used when it is referred to. 1640 This is a suggestion for other zones regarding what label to use when creating a 1641 delegation record (<xref target="gnsrecords_delegation"/>) containing 1642 this zone key. 1643 This record <bcp14>SHOULD</bcp14> only be stored locally 1644 under the apex label "@" but <bcp14>MAY</bcp14> be 1645 returned with record sets under any label as a supplemental record. 1646 <xref target="nick_processing"/> details how a resolver must process 1647 supplemental and non-supplemental NICK records. 1648 A NICK DATA entry is illustrated in <xref target="figure_nickrecord"/>. 1649 </t> 1650 <figure anchor="figure_nickrecord"> 1651 <name>The NICK DATA Wire Format</name> 1652 <artwork name="" type="" alt=""> 1653 0 8 16 24 32 40 48 56 1654 +-----+-----+-----+-----+-----+-----+-----+-----+ 1655 | NICKNAME | 1656 / / 1657 / / 1658 | | 1659 +-----+-----+-----+-----+-----+-----+-----+-----+ 1660 </artwork> 1661 </figure> 1662 <dl newline="false"> 1663 <dt>NICKNAME:</dt> 1664 <dd> 1665 A UTF-8 string (which is not zero terminated) representing the preferred 1666 label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS label. 1667 </dd> 1668 </dl> 1669 </section> 1670 <section anchor="gnsrecords_box"> 1671 <name>BOX</name> 1672 <t> 1673 GNS lookups are expected to return all of the required useful 1674 information in one record set. This avoids unnecessary additional 1675 lookups and cryptographically ties together information that belongs 1676 together, making it impossible for an adversarial storage entity to provide 1677 partial answers that might omit information critical for security. 1678 </t> 1679 <t> 1680 This general strategy is incompatible with the 1681 special labels used by DNS for SRV and TLSA records. Thus, GNS 1682 defines the BOX record format to box up SRV and TLSA records and 1683 include them in the record set of the label they are associated 1684 with. For example, a 1685 TLSA record for "_https._tcp.example.org" will be stored in the record set of 1686 "example.org" as a BOX record with service (SVC) 443 (https), protocol (PROTO) 6 1687 (tcp), and record TYPE "TLSA". 1688 For reference, see also <xref target="RFC2782"/>. 1689 A BOX DATA entry is illustrated in <xref target="figure_boxrecord"/>. 1690 </t> 1691 <figure anchor="figure_boxrecord"> 1692 <name>The BOX DATA Wire Format</name> 1693 <artwork name="" type="" alt=""> 1694 0 8 16 24 32 40 48 56 1695 +-----+-----+-----+-----+-----+-----+-----+-----+ 1696 | PROTO | SVC | TYPE | 1697 +-----------+-----------------------------------+ 1698 | RECORD DATA | 1699 / / 1700 / / 1701 | | 1702 +-----+-----+-----+-----+-----+-----+-----+-----+ 1703 </artwork> 1704 </figure> 1705 <dl newline="false"> 1706 <dt>PROTO:</dt> 1707 <dd> 1708 The 16-bit protocol number in network byte order. 1709 Values 1710 below 2<sup>8</sup> are reserved for 8-bit Internet Protocol numbers allocated by IANA <xref target="RFC5237"/> 1711 (e.g., 6 for TCP). 1712 Values above 2<sup>8</sup> are allocated by the 1713 GANA "GNUnet Overlay Protocols" registry <xref target="GANA"/>. 1714 </dd> 1715 <dt>SVC:</dt> 1716 <dd> 1717 The 16-bit service value of the boxed record in network byte order. In the case of 1718 TCP and UDP, it is the port number. 1719 </dd> 1720 <dt>TYPE:</dt> 1721 <dd> 1722 The 32-bit record type of the boxed record in network byte order. 1723 </dd> 1724 <dt>RECORD DATA:</dt> 1725 <dd> 1726 A variable-length field containing the "DATA" format of TYPE as 1727 defined for the respective TYPE. Thus, for TYPE values below 2<sup>16</sup>, the 1728 format is the same as the respective record type's binary format in DNS. 1729 </dd> 1730 </dl> 1731 </section> 1732 </section> 1733 </section> 1734 <section anchor="publish"> 1735 <name>Record Encoding for Remote Storage</name> 1736 <t> 1737 Any API that allows storing a block under a 512-bit key and retrieving 1738 one or more blocks from a key can be used by an implementation for remote storage. 1739 To be useful, and to be able to support the defined zone delegation 1740 record encodings, the API <bcp14>MUST</bcp14> permit storing blocks of size 1741 176 bytes or more and <bcp14>SHOULD</bcp14> allow blocks of size 1024 bytes 1742 or more. 1743 In the following, it is assumed that an implementation realizes two 1744 procedures on top of storage: 1745 </t> 1746 <artwork name="" type="" alt=""> 1747 PUT(key, block) 1748 GET(key) -> block 1749 </artwork> 1750 <t> 1751 A GNS implementation publishes blocks 1752 in accordance with the properties and recommendations of the underlying 1753 remote storage. This can include a periodic refresh operation to preserve the 1754 availability of published blocks. 1755 </t> 1756 <t> 1757 There is no mechanism for explicitly deleting individual blocks from remote storage. 1758 However, blocks include an EXPIRATION field, which guides remote 1759 storage implementations to decide when to delete blocks. Given multiple blocks 1760 for the same key, remote storage implementations <bcp14>SHOULD</bcp14> try 1761 to preserve and return the block with the largest EXPIRATION value. 1762 </t> 1763 <t> 1764 All resource records from the same zone sharing the same label are 1765 encrypted and published together in a single resource record block 1766 (RRBLOCK) in the remote storage under a key q, as illustrated 1767 in <xref target="figure_storage_publish"/>. 1768 A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource 1769 records in blocks. 1770 An implementation <bcp14>MUST</bcp14> use the PUT storage procedure 1771 when record sets change to update the zone contents. Implementations 1772 <bcp14>MUST</bcp14> ensure that the EXPIRATION fields of RRBLOCKs 1773 increase strictly monotonically for every change, even if the smallest 1774 expiration time of records in the block does not increase. 1775 </t> 1776 <figure anchor="figure_storage_publish"> 1777 <name>Management and Publication of Local Zones in Distributed Storage</name> 1778 <artwork name="" type="" alt=""> 1779 Local Host | Remote 1780 | Storage 1781 | 1782 | +---------+ 1783 | / /| 1784 | +---------+ | 1785 +-----------+ | | | | 1786 | | +-----------+PUT(q, RRBLOCK) | | Record | | 1787 | User | | Zone |----------------|->| Storage | | 1788 | | | Publisher | | | |/ 1789 +-----------+ +-----------+ | +---------+ 1790 | A | 1791 | | Zone records | 1792 | | grouped by label | 1793 | | | 1794 | +---------+ | 1795 |Create / Delete / | /| | 1796 |and Update +---------+ | | 1797 |Local Zones | | | | 1798 | | Local | | | 1799 +-------------->| Zones | | | 1800 | |/ | 1801 +---------+ | 1802 </artwork> 1803 </figure> 1804 <t> 1805 Storage key derivation and record 1806 block creation are specified in the following sections and 1807 illustrated in <xref target="figure_storage_derivations"/>. 1808 </t> 1809 <figure anchor="figure_storage_derivations"> 1810 <name>Storage Key and Record Block Creation Overview</name> 1811 <artwork name="" type="" alt=""> 1812 +----------+ +-------+ +------------+ +-------------+ 1813 | Zone Key | | Label | | Record Set | | Private Key | 1814 +----------+ +-------+ +------------+ +-------------+ 1815 | | | | 1816 | | v | 1817 | | +-----------+ | 1818 | +---------->| S-Encrypt | | 1819 +----------|---------->+-----------+ | 1820 | | | | | 1821 | | | v v 1822 | | | +-------------+ 1823 | +---------------|-->| SignDerived | 1824 | | | +-------------+ 1825 | | | | 1826 | v v v 1827 | +------+ +--------------+ 1828 +----->| ZKDF |------->| Record Block | 1829 +------+ +--------------+ 1830 | 1831 v 1832 +------+ +-------------+ 1833 | Hash |------->| Storage Key | 1834 +------+ +-------------+ 1835 </artwork> 1836 </figure> 1837 <section anchor="blinding"> 1838 <name>The Storage Key</name> 1839 <t> 1840 The storage key is derived from the zone key and the respective 1841 label of the contained records. 1842 The required knowledge of both the zone key and the label in combination 1843 with the similarly derived symmetric secret keys and blinded zone keys 1844 ensures query privacy (see <xref target="RFC8324" sectionFormat="comma" section="3.5"/>). 1845 </t> 1846 <t> 1847 Given a label, the storage key q is derived as follows: 1848 </t> 1849 <artwork name="" type="" alt=""> 1850 q := SHA-512(ZKDF(zkey, label)) 1851 </artwork> 1852 <dl newline="false"> 1853 <dt>label:</dt> 1854 <dd>A UTF-8 string under which the resource records are published. 1855 </dd> 1856 <dt>zkey:</dt> 1857 <dd> 1858 The zone key. 1859 </dd> 1860 <dt>q:</dt> 1861 <dd> 1862 The 512-bit storage key under which the resource record block is 1863 published. 1864 It is the SHA-512 hash <xref target="RFC6234"/> over the derived zone key. 1865 </dd> 1866 </dl> 1867 </section> 1868 <section anchor="rdata"> 1869 <name>Plaintext Record Data (RDATA)</name> 1870 <t> 1871 GNS records from a zone are grouped by their labels such that all 1872 records under the same label are published together as a single 1873 block in storage. Such grouped record sets <bcp14>MAY</bcp14> be paired with 1874 supplemental records. 1875 </t> 1876 <t> 1877 Record data (RDATA) is the format used to encode such a group of GNS records. 1878 The binary format of RDATA is illustrated in 1879 <xref target="figure_rdata"/>. 1880 </t> 1881 <figure anchor="figure_rdata"> 1882 <name>The RDATA Wire Format</name> 1883 <artwork name="" type="" alt=""> 1884 0 8 16 24 32 40 48 56 1885 +-----+-----+-----+-----+-----+-----+-----+-----+ 1886 | EXPIRATION | 1887 +-----+-----+-----+-----+-----+-----+-----+-----+ 1888 | SIZE | FLAGS | TYPE | 1889 +-----+-----+-----+-----+-----+-----+-----+-----+ 1890 | DATA / 1891 / / 1892 / / 1893 +-----+-----+-----+-----+-----+-----+-----+-----+ 1894 | EXPIRATION | 1895 +-----+-----+-----+-----+-----+-----+-----+-----+ 1896 | SIZE | FLAGS | TYPE | 1897 +-----+-----+-----+-----+-----+-----+-----+-----+ 1898 | DATA / 1899 / / 1900 +-----+-----+-----+-----+-----+-----+-----+-----+ 1901 | PADDING / 1902 / / 1903 +-----+-----+-----+-----+-----+-----+-----+-----+ 1904 </artwork> 1905 </figure> 1906 <dl newline="false"> 1907 <dt>EXPIRATION, SIZE, TYPE, FLAGS, and DATA:</dt> 1908 <dd> 1909 Definitions for these fields are provided below <xref target="figure_gnsrecord"/> 1910 in <xref target="rrecords"/>. 1911 </dd> 1912 <dt>PADDING:</dt> 1913 <dd> 1914 When serializing records into RDATA, a GNS implementation <bcp14>MUST</bcp14> ensure that 1915 the size of the RDATA is a power of two 1916 using this field. The field <bcp14>MUST</bcp14> be set to zero and <bcp14>MUST</bcp14> be 1917 ignored on receipt. 1918 As a special exception, record sets with (only) a zone delegation 1919 record type are never padded. 1920 </dd> 1921 </dl> 1922 </section> 1923 <section anchor="records_block"> 1924 <name>The Resource Record Block</name> 1925 <t> 1926 The resource records grouped in an RDATA are encrypted using the S-Encrypt() 1927 function defined by the zone type of the zone to which the resource records belong 1928 and prefixed with metadata into a resource record block (RRBLOCK) for remote storage. 1929 The GNS RRBLOCK wire format is illustrated in 1930 <xref target="figure_record_block"/>. 1931 </t> 1932 <figure anchor="figure_record_block"> 1933 <name>The RRBLOCK Wire Format</name> 1934 <artwork name="" type="" alt=""> 1935 0 8 16 24 32 40 48 56 1936 +-----+-----+-----+-----+-----+-----+-----+-----+ 1937 | SIZE | ZONE TYPE | 1938 +-----+-----+-----+-----+-----+-----+-----+-----+ 1939 | ZONE KEY / 1940 / (BLINDED) / 1941 | | 1942 +-----+-----+-----+-----+-----+-----+-----+-----+ 1943 | SIGNATURE | 1944 / / 1945 / / 1946 | | 1947 +-----+-----+-----+-----+-----+-----+-----+-----+ 1948 | EXPIRATION | 1949 +-----+-----+-----+-----+-----+-----+-----+-----+ 1950 | BDATA | 1951 / / 1952 / / 1953 +-----+-----+-----+-----+-----+-----+-----+-----+ 1954 </artwork> 1955 </figure> 1956 <dl newline="false"> 1957 <dt>SIZE:</dt> 1958 <dd> 1959 A 32-bit value containing the length of the block in bytes in network byte order. 1960 Despite the message format's use of a 32-bit value, 1961 implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond a certain 1962 size significantly below the theoretical block size limit of 4 GB. 1963 </dd> 1964 <dt>ZONE TYPE:</dt> 1965 <dd> 1966 The 32-bit ztype in network byte order. 1967 </dd> 1968 <dt>ZONE KEY (BLINDED):</dt> 1969 <dd> 1970 The blinded zone key "ZKDF(zkey, label)" 1971 to be used to verify SIGNATURE. 1972 The length and format of the blinded public key depend on the ztype. 1973 </dd> 1974 <dt>SIGNATURE:</dt> 1975 <dd> 1976 The signature is computed over the EXPIRATION and BDATA fields 1977 as shown in <xref target="figure_rrsigwithpseudo"/>. 1978 The length and format of the signature depend on the ztype. 1979 The signature is created using the SignDerived() function of 1980 the cryptosystem of the zone (see <xref target="zones"/>). 1981 </dd> 1982 <dt>EXPIRATION:</dt> 1983 <dd> 1984 Specifies when the RRBLOCK expires and the encrypted block 1985 <bcp14>SHOULD</bcp14> be removed from storage and caches, as it is likely stale. 1986 However, applications <bcp14>MAY</bcp14> continue to use non-expired individual 1987 records until they expire. The RRBLOCK expiration value <bcp14>MUST</bcp14> be computed by first determining for each record type present in the RRBLOCK the maximum expiration time of all records of that type, including shadow 1988 records. Then, the minimum of all of these expiration times is taken. The final expiration time is then the larger value of (1) the previous EXPIRATION value of a previous RRBLOCK for the same storage key plus one (if any) and (2) the computed minimum expiration time across the contained record types. This ensures strict monotonicity (see <xref target="security_cryptography"/>). 1989 This is a 64-bit absolute date in microseconds since midnight 1990 (0 hour), January 1, 1970 UTC in network byte order. 1991 </dd> 1992 <dt>BDATA:</dt> 1993 <dd> 1994 The encrypted RDATA computed using S-Encrypt() with the 1995 zone key, label, and expiration time as additional inputs. 1996 Its ultimate size and content are determined by 1997 the S-Encrypt() function of the ztype. 1998 </dd> 1999 </dl> 2000 <t> 2001 The signature over the public key covers a 32-bit pseudo header 2002 conceptually prefixed to the EXPIRATION and BDATA fields. 2003 The wire format is illustrated 2004 in <xref target="figure_rrsigwithpseudo"/>. 2005 </t> 2006 <figure anchor="figure_rrsigwithpseudo"> 2007 <name>The Wire Format Used for Creating the Signature of the RRBLOCK</name> 2008 <artwork name="" type="" alt=""> 2009 0 8 16 24 32 40 48 56 2010 +-----+-----+-----+-----+-----+-----+-----+-----+ 2011 | SIZE | PURPOSE (0x0F) | 2012 +-----+-----+-----+-----+-----+-----+-----+-----+ 2013 | EXPIRATION | 2014 +-----+-----+-----+-----+-----+-----+-----+-----+ 2015 | BDATA | 2016 / / 2017 / / 2018 +-----+-----+-----+-----+-----+-----+-----+-----+ 2019 </artwork> 2020 </figure> 2021 <dl newline="false"> 2022 <dt>SIZE:</dt> 2023 <dd> 2024 A 32-bit value containing the length of the signed data in bytes 2025 in network byte order. 2026 </dd> 2027 <dt>PURPOSE:</dt> 2028 <dd> 2029 A 32-bit signature purpose flag in network byte order. The value of this 2030 field <bcp14>MUST</bcp14> be 15. It defines the context in which 2031 the signature is created so that it cannot be reused in other parts 2032 of the protocol that might include possible future extensions. 2033 The value of this field corresponds to an entry in the 2034 GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>. 2035 </dd> 2036 <dt>EXPIRATION:</dt> 2037 <dd> 2038 Field as defined in the RRBLOCK message above. 2039 </dd> 2040 <dt>BDATA:</dt> 2041 <dd>Field as defined in the RRBLOCK message above.</dd> 2042 </dl> 2043 </section> 2044 </section> 2045 <section anchor="resolution"> 2046 <name>Name Resolution</name> 2047 <t> 2048 Names in GNS are resolved by recursively querying the record storage. 2049 Recursive in this context means that a resolver does not provide 2050 intermediate results for a query to the application. 2051 Instead, it <bcp14>MUST</bcp14> respond to a resolution request with either the 2052 requested resource record or an error message if resolution 2053 fails. 2054 <xref target="figure_resolution"/> illustrates how an application 2055 requests the lookup of a GNS name (1). 2056 The application <bcp14>MAY</bcp14> provide a desired record type to the resolver. 2057 Subsequently, a Start Zone is determined (2) and the recursive 2058 resolution process started. 2059 This is where the desired record type is used to guide processing. 2060 For example, if a zone delegation record type is requested, the 2061 resolution of the apex label in that zone must be skipped, as 2062 the desired record is already found. 2063 Details on how the resolution process is initiated and each iterative 2064 result (3a,3b) in the resolution is processed are provided in the sections below. 2065 The results of the lookup are eventually returned to the application (4). 2066 The implementation <bcp14>MUST NOT</bcp14> filter the returned resource 2067 record sets according to the desired record type. 2068 Filtering of record sets is typically done by the application. 2069 </t> 2070 <figure anchor="figure_resolution"> 2071 <name>The Recursive GNS Resolution Process</name> 2072 <artwork name="" type="" alt=""> 2073 Local Host | Remote 2074 | Storage 2075 | 2076 | +---------+ 2077 | / /| 2078 | +---------+ | 2079 +-----------+ (1) Name +----------+ | | | | 2080 | | Lookup | | (3a) GET(q) | | Record | | 2081 |Application|----------| Resolver |---------------|->| Storage | | 2082 | |<---------| |<--------------|--| |/ 2083 +-----------+ (4) +----------+ (3b) RRBLOCK | +---------+ 2084 Records A | 2085 | | 2086 (2) Determination of | | 2087 Start Zone | | 2088 | | 2089 +---------+ | 2090 / | /| | 2091 +---------+ | | 2092 | | | | 2093 | Start | | | 2094 | Zones | | | 2095 | |/ | 2096 +---------+ | 2097 </artwork> 2098 </figure> 2099 <section anchor="governance"> 2100 <name>Start Zones</name> 2101 <t> 2102 The resolution of a GNS name starts by identifying the Start Zone 2103 suffix. Once the Start Zone suffix is identified, recursive resolution 2104 of the remainder of the name is initiated (see <xref target="recursion"/>). 2105 There are two types of Start Zone suffixes: zTLDs and local 2106 suffix-to-zone mappings. 2107 The choice of available suffix-to-zone mappings is at the sole 2108 discretion of the local system administrator or user. 2109 This property addresses the issue of a single hierarchy with a 2110 centrally controlled root and the related issue of distribution and 2111 management of root servers in DNS (see Sections <xref target="RFC8324" section="3.12" 2112 sectionFormat="bare"/> and <xref target="RFC8324" section="3.10" 2113 sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively). 2114 </t> 2115 <t> 2116 For names ending with a zTLD, the Start Zone is explicitly given in the 2117 suffix of the name to resolve. 2118 In order to ensure uniqueness of names with zTLDs, any 2119 implementation <bcp14>MUST</bcp14> use the given zone as the Start Zone. 2120 An implementation <bcp14>MUST</bcp14> first try to interpret the rightmost label of 2121 the given name as the beginning of a zTLD (see <xref target="zTLD"/>). 2122 If the rightmost label cannot be (partially) decoded or if it does not 2123 indicate a supported ztype, the name is treated as a normal name and 2124 Start Zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone 2125 mapping. 2126 If a valid ztype can be found in the rightmost label, the 2127 implementation <bcp14>MUST</bcp14> try to synthesize and decode the zTLD to retrieve 2128 the Start Zone key according to <xref target="zTLD"/>. 2129 If the zTLD cannot be synthesized or decoded, the resolution of 2130 the name fails and an error is returned to the application. 2131 Otherwise, the zone key <bcp14>MUST</bcp14> be used as the Start Zone: 2132 </t> 2133 <artwork name="" type="" alt=""> 2134 Example name: www.example.<zTLD> 2135 => Start Zone: zkey of type ztype 2136 => Name to resolve from Start Zone: www.example 2137 </artwork> 2138 <t> 2139 For names not ending with a zTLD, the resolver <bcp14>MUST</bcp14> determine the Start 2140 Zone through a local suffix-to-zone mapping. 2141 Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a local 2142 configuration file or database by the user or system administrator. 2143 A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels concatenated with a 2144 label separator. 2145 If multiple suffixes match the name to resolve, the longest 2146 matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two results 2147 <bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration, and the 2148 implementation <bcp14>MUST</bcp14> return an error. 2149 The following is a non-normative example mapping of Start Zones: 2150 </t> 2151 <artwork name="" type="" alt=""> 2152 Example name: www.example.xyz.gns.alt 2153 Local suffix mappings: 2154 xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0) 2155 example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zkey1) 2156 example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2) 2157 ... 2158 => Start Zone: zkey1 2159 => Name to resolve from Start Zone: www 2160 </artwork> 2161 <t> 2162 The process given above <bcp14>MAY</bcp14> be supplemented with other mechanisms if 2163 the particular application requires a different process. 2164 If no Start Zone can be identified, resolution <bcp14>MUST</bcp14> fail and an 2165 error <bcp14>MUST</bcp14> be returned to the application. 2166 </t> 2167 </section> 2168 <section anchor="recursion"> 2169 <name>Recursion</name> 2170 <t> 2171 In each step of the recursive name resolution, there is an 2172 authoritative zone zkey and a name to resolve. 2173 The name <bcp14>MAY</bcp14> be empty. 2174 If the name is empty, it is interpreted as the apex label "@". 2175 Initially, the authoritative zone is the Start Zone. 2176 </t> 2177 <t> 2178 From here, the following steps are recursively executed, in order: 2179 </t> 2180 <ol> 2181 <li>Extract the rightmost label from the name to look up.</li> 2182 <li>Calculate q using the label and zkey as defined in 2183 <xref target="blinding"/>.</li> 2184 <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li> 2185 <li>Check that (a) the block is not expired, (b) the SHA-512 hash 2186 of the derived authoritative zone key zkey' from the RRBLOCK matches 2187 the query q, and (c) the signature is valid. If any of these 2188 tests fail, the RRBLOCK <bcp14>MUST</bcp14> 2189 be ignored and, if applicable, the storage lookup GET(q) 2190 <bcp14>MUST</bcp14> continue to look for other RRBLOCKs.</li> 2191 <li>Obtain the RDATA by decrypting the BDATA contained in the 2192 RRBLOCK using S-Decrypt() as defined by the zone type, effectively 2193 inverting the process described in <xref target="records_block"/>.</li> 2194 </ol> 2195 <t> 2196 Once a well-formed block has been decrypted, the records from 2197 RDATA are subjected to record processing. 2198 </t> 2199 </section> 2200 <section anchor="record_processing"> 2201 <name>Record Processing</name> 2202 <t> 2203 In record processing, only the valid records obtained are considered. 2204 To filter records by validity, the resolver 2205 <bcp14>MUST</bcp14> at least check the expiration time and the FLAGS field of the 2206 respective record. 2207 Specifically, the resolver <bcp14>MUST</bcp14> disregard expired records. 2208 Furthermore, SHADOW and 2209 SUPPLEMENTAL flags can also exclude records from being considered. 2210 If the resolver encounters a record with the CRITICAL flag set and 2211 does not support the record type, the resolution <bcp14>MUST</bcp14> be aborted 2212 and an error <bcp14>MUST</bcp14> be returned. Information indicating that the critical 2213 record could not be processed <bcp14>SHOULD</bcp14> be returned in the error 2214 description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, 2215 merely complicating troubleshooting for the user. 2216 </t> 2217 <t> 2218 The next steps depend on the context of the name that is being 2219 resolved: 2220 </t> 2221 <dl newline="false"> 2222 <dt>Case 1:</dt> 2223 <dd>If the filtered record set consists of a single REDIRECT record, 2224 the remainder of the name is prepended to the REDIRECT DATA and the 2225 recursion is started again from the resulting name. 2226 Details are provided in <xref target="redirect_processing"/>.</dd> 2227 <dt>Case 2:</dt> 2228 <dd>If the filtered record set consists exclusively of one or more GNS2DNS records, 2229 resolution continues with DNS. 2230 Details are provided in <xref target="gns2dns_processing"/>.</dd> 2231 <dt>Case 3:</dt> 2232 <dd>If the remainder of the name to be resolved is of the format 2233 "_SERVICE._PROTO" and the record set contains one or more matching BOX 2234 records, the records in the BOX records are the final result and the recursion 2235 is concluded as described in <xref target="box_processing"/>.</dd> 2236 <dt>Case 4:</dt> 2237 <dd>If the current record set 2238 consists of a single delegation record, 2239 resolution of the remainder of the name is delegated to 2240 the target zone as described in <xref target="delegation_processing"/>.</dd> 2241 <dt>Case 5:</dt> 2242 <dd>If the remainder of the name to resolve is empty, 2243 the record set is the final result. 2244 If any NICK records are in the final result set, they <bcp14>MUST</bcp14> 2245 first be processed according to <xref target="nick_processing"/>. 2246 Otherwise, the record result set is directly returned as the final result.</dd> 2247 </dl> 2248 <t>Finally, if none of the above cases are applicable, resolution fails and the 2249 resolver <bcp14>MUST</bcp14> return an empty record set.</t> 2250 2251 <section anchor="redirect_processing"> 2252 <name>REDIRECT</name> 2253 <t> 2254 If the remaining name is empty and the desired record type is 2255 REDIRECT, the resolution concludes with the REDIRECT record. 2256 If the rightmost label of the REDIRECT NAME is the extension label 2257 (U+002B ("+")), 2258 resolution continues in GNS with the new name in the 2259 current zone. 2260 Otherwise, the resulting name is resolved via the 2261 default operating system name resolution process. 2262 This can in turn trigger a GNS name resolution process, depending 2263 on the system configuration. 2264 If resolution continues in DNS, the name <bcp14>MUST</bcp14> first be 2265 converted to an IDNA-compliant representation <xref target="RFC5890"/>. 2266 </t> 2267 <t> 2268 In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14> 2269 implement loop detection or limit the number of recursive 2270 resolution steps. 2271 The loop detection <bcp14>MUST</bcp14> be effective even 2272 if a REDIRECT found in GNS triggers subsequent GNS lookups via 2273 the default operating system name resolution process. 2274 </t> 2275 </section> 2276 <section anchor="gns2dns_processing"> 2277 <name>GNS2DNS</name> 2278 <t> 2279 A resolver returns GNS2DNS records when all of the following 2280 conditions are met: 2281 </t> 2282 <ol> 2283 <li>The resolver encounters one or more GNS2DNS records;</li> 2284 <li>The remaining name is empty; and</li> 2285 <li>The desired record type is GNS2DNS.</li> 2286 </ol> 2287 <t> 2288 Otherwise, it is expected that the resolver first resolves the 2289 IP addresses of the specified DNS name servers. 2290 The DNS name <bcp14>MUST</bcp14> be converted to an IDNA-compliant 2291 representation <xref target="RFC5890"/> for resolution in DNS. 2292 GNS2DNS records <bcp14>MAY</bcp14> 2293 contain numeric IPv4 or IPv6 addresses, allowing the resolver to 2294 skip this step. 2295 The DNS server names might themselves be names in GNS or DNS. 2296 If the rightmost label of the DNS server name is the extension label 2297 (U+002B ("+")), the rest of the name is to be 2298 interpreted relative to the zone of the GNS2DNS record. 2299 If the DNS server name ends in a label representation of a 2300 zone key, the DNS server name is to be resolved against 2301 the GNS zone zkey. 2302 </t> 2303 <t> 2304 Multiple GNS2DNS records can be stored under the same label, 2305 in which case the resolver <bcp14>MUST</bcp14> try all of them. 2306 The resolver <bcp14>MAY</bcp14> try them in any order or even in parallel. 2307 If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</bcp14> be 2308 identical for all of them. Otherwise, it is not clear which name 2309 the resolver is supposed to follow. If different DNS names are 2310 present, the resolution fails and an 2311 appropriate error <bcp14>SHOULD</bcp14> be returned to the application. 2312 </t> 2313 <t> 2314 If there are DNSSEC DS records or any other records used to 2315 secure the connection with the DNS servers stored under the label, 2316 the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the connection with 2317 the DNS server. 2318 </t> 2319 <t> 2320 Once the IP addresses of the DNS servers have been determined, 2321 the DNS name from the GNS2DNS record is appended 2322 to the remainder of the name to be resolved and is 2323 resolved by querying the DNS name server(s). 2324 The synthesized name has to be converted to an IDNA-compliant 2325 representation <xref target="RFC5890"/> for resolution in DNS. 2326 If such a conversion is not possible, the resolution <bcp14>MUST</bcp14> be aborted 2327 and an error <bcp14>MUST</bcp14> be returned. Information indicating that the critical 2328 record could not be processed <bcp14>SHOULD</bcp14> be returned in the error 2329 description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, 2330 merely complicating troubleshooting for the user. 2331 </t> 2332 <t> 2333 As the DNS servers 2334 specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14> 2335 support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delegate this to the 2336 authoritative DNS servers. 2337 The first successful recursive name resolution result 2338 is returned to the application. 2339 In addition, the resolver <bcp14>SHOULD</bcp14> return the queried DNS name as a 2340 supplemental LEHO record (see <xref target="gnsrecords_leho"/>) with a 2341 relative expiration time of one hour. 2342 </t> 2343 <t> 2344 Once the transition from GNS to DNS is made through a 2345 GNS2DNS record, there is no "going back". 2346 The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT</bcp14> 2347 delegate back into GNS and should only follow the DNS specifications. 2348 For example, names contained in DNS CNAME records <bcp14>MUST NOT</bcp14> be 2349 interpreted by resolvers that support both DNS and GNS as GNS names. 2350 </t> 2351 <t> 2352 GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration 2353 option to disable DNS processing to avoid information leakage 2354 and provide a consistent security profile for all name resolutions. 2355 Such resolvers would return an empty record set upon encountering 2356 a GNS2DNS record during the recursion. However, if GNS2DNS records 2357 are encountered in the record set for the apex label and a GNS2DNS record 2358 is explicitly requested by the application, such records <bcp14>MUST</bcp14> 2359 still be returned, even if DNS support is disabled by the 2360 GNS resolver configuration. 2361 </t> 2362 </section> 2363 <section anchor="box_processing"> 2364 <name>BOX</name> 2365 <t> 2366 When a BOX record is received, a GNS resolver must unbox it if the 2367 name to be resolved continues with "_SERVICE._PROTO". 2368 Otherwise, the BOX record is to be left untouched. This way, TLSA 2369 (and SRV) records do not require a separate network request, and 2370 TLSA records become inseparable from the corresponding address 2371 records. 2372 </t> 2373 </section> 2374 <section anchor="delegation_processing"> 2375 <name>Zone Delegation Records</name> 2376 <t> 2377 When the resolver encounters a record of a supported 2378 zone delegation record type (such as PKEY or EDKEY) 2379 and the remainder of the name is not empty, resolution continues 2380 recursively with the remainder of the name in the 2381 GNS zone specified in the delegation record. 2382 </t> 2383 <t> 2384 Whenever a resolver encounters a new GNS zone, it <bcp14>MUST</bcp14> 2385 check against the local revocation list (see <xref target="revocation"/>) to see 2386 whether the respective 2387 zone key has been revoked. If the zone key was revoked, the 2388 resolution <bcp14>MUST</bcp14> fail with an empty result set. 2389 </t> 2390 <t> 2391 Implementations <bcp14>MUST NOT</bcp14> allow multiple different zone 2392 delegations under a single label (except if some are shadow records). 2393 Implementations <bcp14>MAY</bcp14> support any subset of ztypes. 2394 Implementations <bcp14>MUST NOT</bcp14> process zone delegation records 2395 stored under the apex label ("@"). If a zone delegation record is encountered under 2396 the apex label, resolution fails and an error <bcp14>MUST</bcp14> be returned. The 2397 implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, 2398 merely impacting troubleshooting information for the user. 2399 </t> 2400 <t> 2401 If the remainder of the name to resolve is empty and a record set was 2402 received containing only a single delegation record, the recursion is 2403 continued with the record value as the authoritative zone and the 2404 apex label "@" as the remaining name. The exception is the case 2405 where the desired record type as specified by the application is 2406 equal to the ztype, in which case the delegation record is returned. 2407 </t> 2408 </section> 2409 <section anchor="nick_processing"> 2410 <name>NICK</name> 2411 <t> 2412 NICK records are only relevant to the recursive resolver 2413 if the record set in question is the final result, which is to 2414 be returned to the application. The encountered NICK records can be either 2415 supplemental (see <xref target="rrecords"/>) or 2416 non-supplemental. 2417 If the NICK record is supplemental, the resolver only returns the 2418 record set if one of the non-supplemental records matches the 2419 queried record type. 2420 It is possible that one record set contains both supplemental 2421 and non-supplemental NICK records. 2422 </t> 2423 <t> 2424 The differentiation between a supplemental and non-supplemental 2425 NICK record allows the application to match the record to the 2426 authoritative zone. Consider the following example: 2427 </t> 2428 <artwork name="" type="" alt=""> 2429 Query: alice.example.gns.alt (type=A) 2430 Result: 2431 A: 192.0.2.1 2432 NICK: eve (non-supplemental) 2433 </artwork> 2434 <t> 2435 In this example, the returned NICK record is non-supplemental. 2436 For the application, this means that the NICK belongs to the zone 2437 "alice.example.gns.alt" and is published under the apex label along with an A 2438 record. The NICK record is interpreted as follows: the zone defined by 2439 "alice.example.gns.alt" wants to be referred to as "eve". 2440 In contrast, consider the following: 2441 </t> 2442 <artwork name="" type="" alt=""> 2443 Query: alice.example.gns.alt (type=AAAA) 2444 Result: 2445 AAAA: 2001:db8::1 2446 NICK: john (supplemental) 2447 </artwork> 2448 <t> 2449 In this case, the NICK record is marked as supplemental. This means that 2450 the NICK record belongs to the zone "example.gns.alt" and is published under the 2451 label "alice" along with a AAAA record. Here, the NICK record should be 2452 interpreted as follows: the zone defined by "example.gns.alt" wants to be referred to as 2453 "john". This distinction is likely useful for other records published as 2454 supplemental. 2455 </t> 2456 </section> 2457 </section> 2458 </section> 2459 <section anchor="encoding"> 2460 <name>Internationalization and Character Encoding</name> 2461 <t> 2462 All names in GNS are encoded in UTF-8 <xref target="RFC3629"/>. 2463 Labels <bcp14>MUST</bcp14> be canonicalized using 2464 Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. 2465 This does not include any DNS names found in DNS records, such as CNAME 2466 record data, which is internationalized through the IDNA specifications; 2467 see <xref target="RFC5890"/>. 2468 </t> 2469 </section> 2470 <section anchor="security"> 2471 <name>Security and Privacy Considerations</name> 2472 <section anchor="security_availability"> 2473 <name>Availability</name> 2474 <t> 2475 In order to ensure availability of records beyond their 2476 absolute expiration times, implementations <bcp14>MAY</bcp14> allow 2477 relative expiration time values of records to be locally defined. 2478 Records can then be published recurringly with updated 2479 absolute expiration times by the implementation. 2480 </t> 2481 <t> 2482 Implementations <bcp14>MAY</bcp14> allow users to manage private records in 2483 their zones that are not published in storage. 2484 Private records are treated just like 2485 regular records when resolving labels in local zones, 2486 but their data is completely unavailable to non-local users. 2487 </t> 2488 </section> 2489 <section anchor="security_agility"> 2490 <name>Agility</name> 2491 <t> 2492 The security of cryptographic systems depends on both the strength of 2493 the cryptographic algorithms chosen and the strength of the keys used 2494 with those algorithms. This security also depends on the engineering 2495 of the protocol used by the system to ensure that there are no 2496 non-cryptographic ways to bypass the security of the overall system. 2497 This is why developers of applications managing GNS zones <bcp14>SHOULD</bcp14> 2498 select a default ztype considered secure at the time of 2499 releasing the software. 2500 For applications targeting end users that are not expected to 2501 understand cryptography, the application developer <bcp14>MUST NOT</bcp14> leave 2502 the ztype selection of new zones to end users. 2503 </t> 2504 <t> 2505 This document concerns itself with the selection of cryptographic 2506 algorithms used in GNS. 2507 The algorithms identified in this document are not known to be 2508 broken (in the cryptographic sense) at the current time, and 2509 cryptographic research so far leads us to believe that they are 2510 likely to remain secure into the foreseeable future. However, this 2511 is not necessarily forever, and it is expected that new revisions of 2512 this document will be issued from time to time to reflect the current 2513 best practices in this area. 2514 </t> 2515 <t> 2516 In terms of crypto-agility, whenever the need for an updated cryptographic 2517 scheme arises to, for example, replace ECDSA over Ed25519 for 2518 PKEY records, it can simply be introduced 2519 through a new record type. 2520 Zone administrators can then replace 2521 the delegation record type for future records. 2522 The old record type remains, 2523 and zones can iteratively migrate to the updated zone keys. 2524 To ensure that implementations correctly generate an error message 2525 when encountering a ztype that they do not support, 2526 current and future delegation records must always have the 2527 CRITICAL flag set. 2528 </t> 2529 </section> 2530 <section anchor="security_cryptography"> 2531 <name>Cryptography</name> 2532 <t> 2533 The following considerations provide background on the design choices 2534 of the ztypes specified in this document. 2535 When specifying new ztypes as per <xref target="zones"/>, the same 2536 considerations apply. 2537 </t> 2538 <t> 2539 GNS PKEY zone keys use ECDSA over Ed25519. 2540 This is an unconventional choice, 2541 as ECDSA is usually used with other curves. However, standardized 2542 ECDSA curves are problematic for a range of reasons, as described in 2543 the Curve25519 and EdDSA papers <xref target="RFC7748"/> <xref target="ed25519"/>. 2544 Using EdDSA directly is also 2545 not possible, as a hash function is used on the private key and 2546 will destroy the linearity that the key blinding in GNS depends upon. 2547 We are not aware of anyone suggesting that using Ed25519 instead 2548 of another common curve of similar size would lower the security of 2549 ECDSA. GNS uses 256-bit curves; that way, the encoded (public) 2550 keys fit into a single DNS label, which is good for usability. 2551 </t> 2552 <t> 2553 In order to ensure ciphertext indistinguishability, care must be 2554 taken with respect to the IV in the counter 2555 block. In our design, the IV always includes the expiration time of the 2556 record block. 2557 When applications store records with relative expiration times, 2558 monotonicity is implicitly 2559 ensured because each time a block is published in storage, its IV is 2560 unique, as the expiration time is calculated dynamically and increases 2561 monotonically with the system time. Still, 2562 an implementation <bcp14>MUST</bcp14> ensure that when relative expiration times 2563 are decreased, the expiration time of the next record block <bcp14>MUST</bcp14> 2564 be after the last published block. 2565 For records where an absolute expiration time is used, the implementation 2566 <bcp14>MUST</bcp14> ensure that the expiration time is always increased when the record 2567 data changes. For example, the expiration time on the wire could be increased 2568 by a single microsecond even if the user did not request a change. 2569 In the case of deletion of all resource records under a label, the 2570 implementation <bcp14>MUST</bcp14> keep track of the last absolute expiration time 2571 of the last published resource block. Implementations <bcp14>MAY</bcp14> define 2572 and use a special record type as a tombstone that preserves the last 2573 absolute expiration time but then <bcp14>MUST</bcp14> take care to not publish a 2574 block with such a tombstone record. 2575 When new records are added under this label later, the implementation 2576 <bcp14>MUST</bcp14> ensure that the expiration times are after the last published 2577 block. 2578 Finally, in order to ensure monotonically increasing expiration times, 2579 the implementation <bcp14>MUST</bcp14> keep a local record of the last time obtained 2580 from the system clock, so as to construct a monotonic clock if 2581 the system clock jumps backwards. 2582 </t> 2583 </section> 2584 <section anchor="security_abuse"> 2585 <name>Abuse Mitigation</name> 2586 <t> 2587 GNS names are UTF-8 strings. Consequently, GNS faces issues 2588 with respect to name spoofing similar to those for DNS with respect to internationalized 2589 domain names. 2590 In DNS, attackers can register similar-sounding or similar-looking 2591 names (see above) in order to execute phishing attacks. 2592 GNS zone administrators must take into account this attack vector and 2593 incorporate rules in order to mitigate it. 2594 </t> 2595 <t> 2596 Further, DNS can be used to combat illegal content on the Internet 2597 by having the respective domains seized by authorities. 2598 However, the same mechanisms can also be abused in order to impose 2599 state censorship. 2600 Avoiding that possibility is one of the motivations behind GNS. 2601 In GNS, TLDs are not enumerable. By design, the Start Zone of 2602 the resolver is defined locally, and hence such a seizure is 2603 difficult and ineffective in GNS. 2604 </t> 2605 </section> 2606 <section anchor="security_keymanagement"> 2607 <name>Zone Management</name> 2608 <t> 2609 In GNS, zone administrators need to manage and protect their zone 2610 keys. Once a private zone key is lost, it cannot be recovered, and 2611 the zone revocation message cannot be computed anymore. 2612 Revocation messages can be precalculated if revocation is 2613 required in cases where a private zone key is lost. 2614 Zone administrators, and for GNS this includes end users, are 2615 required to responsibly and diligently protect their cryptographic 2616 keys. 2617 GNS supports signing records in advance ("offline") in order to 2618 support processes (such as air gaps) that aim to protect private keys. 2619 </t> 2620 <t> 2621 Similarly, users are required to manage their local Start Zone configuration. 2622 In order to ensure the integrity and availability of names, users must 2623 ensure that their local Start Zone information is not compromised or 2624 outdated. 2625 It can be expected that the processing of zone revocations and an 2626 initial Start Zone are provided with a GNS implementation 2627 ("drop shipping"). 2628 Shipping an initial Start Zone configuration effectively establishes 2629 a root zone. 2630 Extension and customization of the zone are at the full discretion of 2631 the user. 2632 </t> 2633 <t> 2634 While implementations following this specification will be 2635 interoperable, if two implementations connect to different remote storage entities, 2636 they are mutually unreachable. 2637 This can lead to a state where a record exists in the global 2638 namespace for a particular name, but the implementation is not 2639 communicating with the remote storage entity that contains the respective 2640 block and is hence unable to resolve it. 2641 This situation is similar to a split-horizon DNS configuration. 2642 The remote storage entity used will most likely depend on the specific application 2643 context using GNS resolution. 2644 For example, one application is the resolution of hidden services 2645 within the Tor network <xref target="TorRendSpec"/>, which would suggest using Tor routers for remote storage. 2646 Implementations of "aggregated" remote storage entities are conceivable but 2647 are expected to be the exception. 2648 </t> 2649 </section> 2650 <section anchor="security_dht"> 2651 <name>DHTs as Remote Storage</name> 2652 <t> 2653 This document does not specify the properties of the underlying 2654 remote storage, which is required by any GNS implementation. 2655 It is important to note that the properties of the underlying 2656 remote storage are directly inherited by the 2657 GNS implementation. This includes both security and 2658 other non-functional properties such as scalability and performance. 2659 Implementers should take great care when selecting or implementing 2660 a DHT for use as remote storage in a GNS implementation. 2661 DHTs with reasonable security and performance properties exist 2662 <xref target="R5N"/>. 2663 It should also be taken into consideration that GNS implementations 2664 that build upon different DHT overlays are unlikely to be 2665 mutually reachable. 2666 </t> 2667 </section> 2668 <section anchor="security_rev"> 2669 <name>Revocations</name> 2670 <t> 2671 Zone administrators are advised to pregenerate zone revocations 2672 and to securely store the revocation information if the zone 2673 key is lost, compromised, or replaced in the future. 2674 Precalculated revocations can cease to be valid due to expirations 2675 or protocol changes such as epoch adjustments. 2676 Consequently, implementers and users must take precautions in order 2677 to manage revocations accordingly. 2678 </t> 2679 <t> 2680 Revocation payloads do not include a "new" key for key replacement. 2681 Inclusion of such a key would have two major disadvantages: 2682 </t> 2683 <ol> 2684 <li> 2685 If a revocation is published after a private key was compromised, 2686 allowing key replacement would be dangerous: if an 2687 adversary took over the private key, the adversary could then 2688 broadcast a revocation with a key replacement. For the replacement, 2689 the compromised owner would have no chance to issue a 2690 revocation. Thus, allowing a revocation message to replace a private 2691 key makes dealing with key compromise situations worse. 2692 </li> 2693 <li> 2694 Sometimes, key revocations are used with the objective of changing 2695 cryptosystems. Migration to another cryptosystem by replacing keys 2696 via a revocation message would only be secure as long as both 2697 cryptosystems are still secure against forgery. Such a planned, 2698 non-emergency migration to another cryptosystem should be done by 2699 running zones for both cipher systems in parallel for a while. The 2700 migration would conclude by revoking the legacy zone key only when 2701 it is deemed no longer secure and, hopefully, after most users have 2702 migrated to the replacement. 2703 </li> 2704 </ol> 2705 </section> 2706 <section anchor="privacy_labels"> 2707 <name>Zone Privacy</name> 2708 <t> 2709 GNS does not support authenticated denial of existence of names 2710 within a zone. 2711 Record data is published in encrypted form using keys derived from the 2712 zone key and record label. Zone administrators should 2713 carefully consider whether (1) a label and zone key are public or 2714 (2) one or both of these should be used as a shared secret to restrict access 2715 to the corresponding record data. 2716 Unlike public zone keys, low-entropy labels can be guessed by an attacker. If an attacker 2717 knows the public zone key, the use of well-known or guessable 2718 labels effectively threatens the disclosure of the corresponding records. 2719 </t> 2720 <t> 2721 It should be noted that the guessing attack on labels only applies if the 2722 zone key is somehow disclosed to the adversary. GNS itself 2723 does not disclose it during a lookup or when resource records are 2724 published (as only the blinded zone keys are used on the network). 2725 However, zone keys do become public during revocation. 2726 </t> 2727 <t> 2728 It is thus <bcp14>RECOMMENDED</bcp14> to use a 2729 label with sufficient entropy to prevent guessing attacks 2730 if any data in a resource record set is sensitive. 2731 </t> 2732 </section> 2733 <section anchor="sec_governance"> 2734 <name>Zone Governance</name> 2735 <t> 2736 While DNS is distributed, in practice it 2737 relies on centralized, trusted registrars to provide globally unique 2738 names. As awareness of the central role DNS plays on the Internet 2739 increases, various institutions are using their power (including legal means) 2740 to engage in attacks on the DNS, thus threatening the global availability 2741 and integrity of information on the Internet. 2742 While a wider discussion of this issue is out of scope for this document, 2743 analyses and investigations can be found in recent academic research 2744 works, including <xref target="SecureNS"/>. 2745 </t> 2746 <t> 2747 GNS is designed to provide a secure, privacy-enhancing alternative to the 2748 DNS name resolution protocol, especially when censorship or manipulation 2749 is encountered. 2750 In particular, it directly addresses concerns in DNS with respect to 2751 query privacy. 2752 However, depending on the governance of the root zone, any deployment 2753 will likely suffer from the issue of a 2754 single hierarchy with a centrally controlled root and the 2755 related issue of distribution and management of root servers in DNS, as 2756 raised in Sections <xref target="RFC8324" section="3.12" 2757 sectionFormat="bare"/> and <xref target="RFC8324" section="3.10" 2758 sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively. 2759 In DNS, those issues directly result from the centralized root 2760 zone governance at the Internet Corporation for Assigned Names and 2761 Numbers (ICANN), which allows it to provide globally unique names. 2762 </t> 2763 <t> 2764 In GNS, Start Zones give users local authority over their preferred 2765 root zone governance. 2766 It enables users to replace or enhance a trusted root zone 2767 configuration provided by a third party (e.g., the implementer or a 2768 multi-stakeholder governance body like ICANN) with secure delegation of 2769 authority using local petnames while operating under a 2770 very strong adversary model. 2771 In combination with zTLDs, this provides users of GNS with a global, 2772 secure, and memorable mapping without a trusted authority. 2773 </t> 2774 <t> 2775 Any GNS implementation <bcp14>MAY</bcp14> provide a default 2776 governance model in the form of an initial Start Zone mapping. 2777 </t> 2778 </section> 2779 <section anchor="namespace_ambiguity"> 2780 <name>Namespace Ambiguity</name> 2781 <t> 2782 Technically, the GNS protocol can be used to resolve names in the 2783 namespace of the global DNS. 2784 However, this would require the respective governance bodies and 2785 stakeholders (e.g., the IETF and ICANN) to standardize the use of GNS for this particular use 2786 case. 2787 </t> 2788 <t> 2789 This capability implies that GNS names may be 2790 indistinguishable from DNS names in their 2791 respective common display format <xref target="RFC8499"/> or 2792 other special-use domain names <xref target="RFC6761"/> if 2793 a local Start Zone configuration maps suffixes from the 2794 global DNS to GNS zones. 2795 For applications, which name system should be 2796 used in order to resolve a given name will then be ambiguous. 2797 This poses a risk when trying to resolve a name through DNS when 2798 it is actually a GNS name, as discussed in <xref target="RFC8244"/>. 2799 In such a case, the GNS name is likely to be leaked as part of the DNS 2800 resolution. 2801 </t> 2802 <t> 2803 In order to prevent disclosure of queried GNS names, it is 2804 <bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to resolve 2805 a given name in GNS before any other method, taking into account 2806 potential suffix-to-zone mappings and zTLDs. 2807 Suffix-to-zone mappings are expected to be configured by the user or 2808 local administrator, and as such the resolution in GNS is 2809 in line with user expectations even if the name could also be resolved 2810 through DNS. 2811 If no suffix-to-zone mapping for the name exists and no zTLD is found, 2812 resolution <bcp14>MAY</bcp14> continue with other methods such as DNS. 2813 If a suffix-to-zone mapping for the name exists or the name ends with 2814 a zTLD, it <bcp14>MUST</bcp14> be resolved using GNS, and 2815 resolution <bcp14>MUST NOT</bcp14> continue by any other means 2816 independent of the GNS resolution result. 2817 </t> 2818 <t> 2819 Mechanisms such as the Name Service Switch (NSS) of UNIX-like 2820 operating systems are an example of how such a resolution process 2821 can be implemented and used. 2822 The NSS allows system administrators to configure hostname resolution 2823 precedence and is integrated with the system resolver implementation. 2824 </t> 2825 <t> 2826 For use cases where GNS names may be confused with names 2827 of other name resolution mechanisms (in particular, DNS), the 2828 ".gns.alt" domain <bcp14>SHOULD</bcp14> be used. 2829 For use cases like implementing sinkholes to block 2830 malware sites or serving DNS domains via GNS to bypass censorship, 2831 GNS <bcp14>MAY</bcp14> be deliberately used in ways that interfere 2832 with resolution of another name system. 2833 </t> 2834 </section> 2835 </section> 2836 <section anchor="gana"> 2837 <name>GANA Considerations</name> 2838 <section anchor="gana_gnunet-sig-purposes"> 2839 <name>GNUnet Signature Purposes Registry</name> 2840 <t> 2841 GANA <xref target="GANA"/> has assigned signature purposes in its 2842 "GNUnet Signature Purposes" registry as listed in 2843 <xref target="tab_purposenums"/>. 2844 </t> 2845 2846 <table anchor="tab_purposenums"> 2847 <name>The GANA GNUnet Signature Purposes Registry</name> 2848 <thead> 2849 <tr> 2850 <th>Purpose</th> 2851 <th>Name</th> 2852 <th>References</th> 2853 <th>Comment</th> 2854 </tr> 2855 </thead> 2856 <tbody> 2857 <tr> 2858 <td>3</td> 2859 <td>GNS_REVOCATION</td> 2860 <td>RFC 9498</td> 2861 <td>GNS zone key revocation</td> 2862 </tr> 2863 <tr> 2864 <td>15</td> 2865 <td>GNS_RECORD_SIGN</td> 2866 <td>RFC 9498</td> 2867 <td>GNS record set signature</td> 2868 </tr> 2869 </tbody> 2870 </table> 2871 </section> 2872 <section anchor="gana_gnsrr"> 2873 <name>GNS Record Types Registry</name> 2874 <t> 2875 GANA <xref target="GANA"/> 2876 manages the "GNS Record Types" registry. 2877 </t> 2878 <t>Each entry has the following format: 2879 </t> 2880 <dl newline="false"> 2881 <dt>Name:</dt><dd>The name of the record type (case-insensitive ASCII 2882 string, restricted to alphanumeric characters). For zone delegation 2883 records, the assigned number represents the ztype value of the zone.</dd> 2884 <dt>Number:</dt><dd>A 32-bit number above 65535.</dd> 2885 <dt>Comment:</dt><dd>Optionally, brief English text describing the purpose of 2886 the record type (in UTF-8).</dd> 2887 <dt>Contact:</dt><dd>Optionally, the contact information for a person to contact for 2888 further information.</dd> 2889 <dt>References:</dt><dd>Optionally, references (such as an RFC) describing the record type.</dd> 2890 </dl> 2891 <t> 2892 The registration policy for this registry is "First Come First 2893 Served". This policy is modeled on that described in <xref target="RFC8126"/> 2894 and describes the actions taken by GANA: 2895 </t> 2896 <ul> 2897 <li> 2898 Adding new entries is possible after review by any authorized 2899 GANA contributor, using a 2900 first-come-first-served policy for unique name allocation. 2901 Reviewers are responsible for ensuring that the chosen "Name" is 2902 appropriate for the record type. 2903 The registry will define a unique number for the entry. 2904 </li> 2905 <li> 2906 Authorized GANA contributors for review of new entries are reachable at 2907 <gns-registry@gnunet.org>. 2908 </li> 2909 <li> 2910 Any request <bcp14>MUST</bcp14> contain a unique name and a point of contact. 2911 The contact information <bcp14>MAY</bcp14> be added to the registry, with the consent 2912 of the requester. 2913 The request <bcp14>MAY</bcp14> optionally also contain relevant references as well 2914 as a descriptive comment, as defined above. 2915 </li> 2916 </ul> 2917 <t> 2918 GANA has assigned numbers for the record types defined in this 2919 specification in the "GNS Record Types" registry as listed in 2920 <xref target="tab_rrtypenums"/>. 2921 </t> 2922 2923 <table anchor="tab_rrtypenums"> 2924 <name>The GANA GNS Record Types Registry</name> 2925 <thead> 2926 <tr> 2927 <th>Number</th> 2928 <th>Name</th> 2929 <th>Contact</th> 2930 <th>References</th> 2931 <th>Comment</th> 2932 </tr> 2933 </thead> 2934 <tbody> 2935 <tr> 2936 <td>65536</td> 2937 <td>PKEY</td> 2938 <td>(*)</td> 2939 <td>RFC 9498</td> 2940 <td>GNS zone delegation (PKEY)</td> 2941 </tr> 2942 <tr> 2943 <td>65537</td> 2944 <td>NICK</td> 2945 <td>(*)</td> 2946 <td>RFC 9498</td> 2947 <td>GNS zone nickname</td> 2948 </tr> 2949 <tr> 2950 <td>65538</td> 2951 <td>LEHO</td> 2952 <td>(*)</td> 2953 <td>RFC 9498</td> 2954 <td>GNS legacy hostname</td> 2955 </tr> 2956 <tr> 2957 <td>65540</td> 2958 <td>GNS2DNS</td> 2959 <td>(*)</td> 2960 <td>RFC 9498</td> 2961 <td>Delegation to DNS</td> 2962 </tr> 2963 <tr> 2964 <td>65541</td> 2965 <td>BOX</td> 2966 <td>(*)</td> 2967 <td>RFC 9498</td> 2968 <td>Box records</td> 2969 </tr> 2970 <tr> 2971 <td>65551</td> 2972 <td>REDIRECT</td> 2973 <td>(*)</td> 2974 <td>RFC 9498</td> 2975 <td>Redirection record</td> 2976 </tr> 2977 <tr> 2978 <td>65556</td> 2979 <td>EDKEY</td> 2980 <td>(*)</td> 2981 <td>RFC 9498</td> 2982 <td>GNS zone delegation (EDKEY)</td> 2983 </tr> 2984 </tbody> 2985 <tfoot> 2986 <tr> 2987 <td align="left" colspan="5">(*): gns-registry@gnunet.org</td> 2988 </tr> 2989 </tfoot> 2990 </table> 2991 </section> 2992 <section anchor="gana_alt"> 2993 <name>.alt Subdomains Registry</name> 2994 <t> 2995 GANA <xref target="GANA"/> 2996 manages the ".alt Subdomains" registry. This GANA-operated .alt registry 2997 may or may not be taken into account by any particular implementer, and 2998 it is not in any way associated with or sanctioned by the IETF or ICANN. 2999 </t> 3000 <t>Each entry has the following format: 3001 </t> 3002 <dl newline="false"> 3003 <dt>Label:</dt><dd>The label of the subdomain (in DNS "letters, digits, hyphen" (LDH) format as defined in <xref target="RFC5890" sectionFormat="of" section="2.3.1"/>).</dd> 3004 <dt>Description:</dt><dd>Optionally, brief English text describing the purpose of 3005 the subdomain (in UTF-8).</dd> 3006 <dt>Contact:</dt><dd>Optionally, the contact information for a person to contact for 3007 further information.</dd> 3008 <dt>References:</dt><dd>Optionally, references (such as an RFC) describing the record type.</dd> 3009 </dl> 3010 <t> 3011 The registration policy for this registry is "First Come First 3012 Served". This policy is modeled on that described in <xref target="RFC8126"/> 3013 and describes the actions taken by GANA: 3014 </t> 3015 <ul> 3016 <li> 3017 Adding new entries is possible after review by any authorized 3018 GANA contributor, using a 3019 first-come-first-served policy for unique subdomain allocation. 3020 Reviewers are responsible for ensuring that the chosen "Subdomain" is 3021 appropriate for the purpose. 3022 </li> 3023 <li> 3024 Authorized GANA contributors for review of new entries are reachable at 3025 <alt-registry@gnunet.org>. 3026 </li> 3027 <li> 3028 Any request <bcp14>MUST</bcp14> contain a unique subdomain and a point of contact. 3029 The contact information <bcp14>MAY</bcp14> be added to the registry, with the consent 3030 of the requester. 3031 The request <bcp14>MAY</bcp14> optionally also contain relevant references as well 3032 as a descriptive comment, as defined above. 3033 </li> 3034 </ul> 3035 <t> 3036 GANA has assigned the subdomain defined in this 3037 specification in the ".alt Subdomains" registry 3038 as listed in <xref target="tab_altsubdomains"/>. 3039 </t> 3040 <table anchor="tab_altsubdomains"> 3041 <name>The GANA .alt Subdomains Registry</name> 3042 <thead> 3043 <tr> 3044 <th>Label</th> 3045 <th>Contact</th> 3046 <th>References</th> 3047 <th>Description</th> 3048 </tr> 3049 </thead> 3050 <tbody> 3051 <tr> 3052 <td>gns</td> 3053 <td>(*)</td> 3054 <td>RFC 9498</td> 3055 <td>The .alt subdomain for GNS</td> 3056 </tr> 3057 </tbody> 3058 <tfoot> 3059 <tr> 3060 <td align="left" colspan="4">(*): alt-registry@gnunet.org</td> 3061 </tr> 3062 </tfoot> 3063 </table> 3064 3065 </section> 3066 </section> 3067 <section> 3068 <name>IANA Considerations</name> 3069 <t> 3070 This document has no IANA actions. 3071 </t> 3072 </section> 3073 <section> 3074 <name>Implementation and Deployment Status</name> 3075 <t> 3076 There are two implementations conforming to this specification, written 3077 in C and Go, respectively. The C implementation as part of GNUnet 3078 <xref target="GNUnetGNS"/> represents the original 3079 and reference implementation. The Go implementation 3080 <xref target="GoGNS"/> demonstrates how two implementations of GNS are 3081 interoperable if they are built on top of the same underlying 3082 DHT storage. 3083 </t> 3084 <t> 3085 Currently, the GNUnet peer-to-peer network <xref target="GNUnet"/> 3086 is an active deployment of GNS on top of its DHT <xref target="R5N"/>. The Go implementation <xref target="GoGNS"/> uses this deployment 3087 by building on top of the GNUnet DHT services available on any 3088 GNUnet peer. It shows how GNS implementations 3089 can attach to this existing deployment and participate in name 3090 resolution as well as zone publication. 3091 </t> 3092 <t> 3093 The self-sovereign identity system re:claimID <xref target="reclaim"/> 3094 is using GNS in order to selectively share identity attributes and 3095 attestations with third parties. 3096 </t> 3097 <t> 3098 The Ascension tool <xref target="Ascension"/> facilitates the migration of DNS zones to 3099 GNS zones by translating information retrieved from a DNS zone 3100 transfer into a GNS zone. 3101 </t> 3102 </section> 3103 </middle> 3104 <back> 3105 <references> 3106 <name>References</name> 3107 <references> 3108 <name>Normative References</name> 3109 3110 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> 3111 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> 3112 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/> 3113 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> 3114 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> 3115 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml"/> 3116 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml"/> 3117 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml"/> 3118 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/> 3119 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/> 3120 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml"/> 3121 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/> 3122 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"/> 3123 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml"/> 3124 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/> 3125 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/> 3126 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> 3127 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> 3128 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> 3129 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml"/> 3130 3131 <reference anchor="GANA" target="https://gana.gnunet.org/"> 3132 <front> 3133 <title>GNUnet Assigned Numbers Authority (GANA)</title> 3134 <author> 3135 <organization>GNUnet e.V.</organization> 3136 </author> 3137 <date year="2023"/> 3138 </front> 3139 </reference> 3140 3141 <reference anchor="MODES" target="https://doi.org/10.6028/NIST.SP.800-38A"> 3142 <front> 3143 <title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title> 3144 <author initials="M." surname="Dworkin" fullname="Morris Dworkin"> 3145 <organization>NIST</organization> 3146 </author> 3147 <date year="2001" month="December"/> 3148 </front> 3149 <refcontent>NIST Special Publication 800-38A</refcontent> 3150 <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/> 3151 </reference> 3152 <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html"> 3153 <front> 3154 <title>Base 32</title> 3155 <author initials="D." surname="Crockford" fullname="Douglas Crockford"> 3156 </author> 3157 <date year="2019" month="March"/> 3158 </front> 3159 </reference> 3160 3161 <reference anchor="XSalsa20" target="https://cr.yp.to/papers.html#xsalsa"> 3162 <front> 3163 <title>Extending the Salsa20 nonce</title> 3164 <author initials="D. J." surname="Bernstein" fullname="Daniel Bernstein"> 3165 <organization>University of Illinois at Chicago</organization> 3166 </author> 3167 <date year="2011"/> 3168 </front> 3169 </reference> 3170 3171 <reference anchor="Unicode-UAX15" target="https://www.unicode.org/reports/tr15/tr15-31.html"> 3172 <front> 3173 <title>Unicode Standard Annex #15: Unicode Normalization Forms</title> 3174 <author initials="M." surname="Davis" fullname="Mark Davis"> 3175 <organization/> 3176 </author> 3177 <author initials="K." surname="Whistler" fullname="Ken Whistler"> 3178 <organization/> 3179 </author> 3180 <author initials="M." surname="Dürst" fullname="Martin Dürst"> 3181 <organization/> 3182 </author> 3183 <date year="2009" month="September"/> 3184 </front> 3185 <refcontent>Revision 31, The Unicode Consortium, Mountain View</refcontent> 3186 </reference> 3187 3188 <reference anchor="Unicode-UTS46" target="https://www.unicode.org/reports/tr46"> 3189 <front> 3190 <title>Unicode Technical Standard #46: Unicode IDNA Compatibility Processing</title> 3191 <author initials="M." surname="Davis" fullname="Mark Davis"> 3192 <organization/> 3193 </author> 3194 <author initials="M." surname="Suignard" fullname="Michel Suignard"> 3195 <organization/> 3196 </author> 3197 <date year="2023" month="September"/> 3198 </front> 3199 <refcontent>Revision 31, The Unicode Consortium, Mountain View</refcontent> 3200 </reference> 3201 </references> 3202 <references> 3203 <name>Informative References</name> 3204 3205 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"/> 3206 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/> 3207 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/> 3208 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7363.xml"/> 3209 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8324.xml"/> 3210 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/> 3211 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml"/> 3212 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8244.xml"/> 3213 3214 <!-- draft-ietf-dnsop-alt-tld (RFC 9476; published) --> 3215 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9476.xml"/> 3216 3217 <reference anchor="TorRendSpec" target="https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt"> 3218 <front> 3219 <title>Tor Rendezvous Specification - Version 3</title> 3220 <author> 3221 <organization>Tor Project</organization> 3222 </author> 3223 <date month="June" year="2023"/> 3224 </front> 3225 <refcontent>commit b345ca0</refcontent> 3226 </reference> 3227 3228 <reference anchor="Tor224" target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135"> 3229 <front> 3230 <title>Next-Generation Hidden Services in Tor</title> 3231 <author initials="D." surname="Goulet" fullname="David Goulet"> 3232 </author> 3233 <author initials="G." surname="Kadianakis" fullname="George Kadianakis"> 3234 </author> 3235 <author initials="N." surname="Mathewson" fullname="Nick Mathewson"> 3236 </author> 3237 <date year="2013" month="November"/> 3238 </front> 3239 <refcontent>Appendix A.2 ("Tor's key derivation scheme")</refcontent> 3240 </reference> 3241 3242 <reference anchor="SDSI" target="https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367"> 3243 <front> 3244 <title>SDSI - A Simple Distributed Security Infrastructure</title> 3245 <author initials="R. L." surname="Rivest" fullname="Ron L. Rivest"> 3246 </author> 3247 <author initials="B." surname="Lampson" fullname="Butler Lampson"> 3248 </author> 3249 <date year="1996" month="October"/> 3250 </front> 3251 </reference> 3252 3253 <reference anchor="Kademlia" target="https://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf"> 3254 <front> 3255 <title>Kademlia: A Peer-to-peer Information System Based on the XOR Metric</title> 3256 <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov"> 3257 </author> 3258 <author initials="D." surname="Mazières" fullname="David Mazières"> 3259 </author> 3260 <date year="2002"/> 3261 </front> 3262 <seriesInfo name="DOI" value="10.1007/3-540-45748-8_5"/> 3263 </reference> 3264 3265 <reference anchor="ed25519" target="https://ed25519.cr.yp.to/ed25519-20110926.pdf"> 3266 <front> 3267 <title>High-speed high-security signatures</title> 3268 <author initials="D. J." surname="Bernstein" fullname="Daniel Bernstein"> 3269 <organization>University of Illinois at Chicago</organization> 3270 </author> 3271 <author initials="N." surname="Duif" fullname="Niels Duif"> 3272 <organization>Technische Universiteit Eindhoven</organization> 3273 </author> 3274 <author initials="T." surname="Lange" fullname="Tanja Lange"> 3275 <organization>Technische Universiteit Eindhoven</organization> 3276 </author> 3277 <author initials="P." surname="Schwabe" fullname="Peter Schwabe"> 3278 <organization>National Taiwan University</organization> 3279 </author> 3280 <author initials="B-Y." surname="Yang" fullname="Bo-Yin Yang"> 3281 <organization>Academia Sinica</organization> 3282 </author> 3283 <date year="2011"/> 3284 </front> 3285 <seriesInfo name="DOI" value="10.1007/s13389-012-0027-1"/> 3286 </reference> 3287 3288 <reference anchor="GNS" target="https://sci-hub.st/10.1007/978-3-319-12280-9_9"> 3289 <front> 3290 <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title> 3291 <author initials="M." surname="Wachs" fullname="Matthias Wachs"> 3292 <organization>Technische Universität München</organization> 3293 </author> 3294 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach"> 3295 <organization>Technische Universität München</organization> 3296 </author> 3297 <author initials="C." surname="Grothoff" fullname="Christian Grothoff"> 3298 <organization>Technische Universität München</organization> 3299 </author> 3300 <date month="October" year="2014"/> 3301 </front> 3302 <refcontent>13th International Conference on Cryptology and Network Security (CANS)</refcontent> 3303 <seriesInfo name="DOI" value="10.13140/2.1.4642.3044"/> 3304 </reference> 3305 <reference anchor="R5N" target="https://sci-hub.st/10.1109/ICNSS.2011.6060022"> 3306 <front> 3307 <title>R5N: Randomized Recursive Routing for Restricted-Route Networks</title> 3308 <author initials="N. S." surname="Evans" fullname="Nathan S. Evans"> 3309 <organization>Technische Universität München</organization> 3310 </author> 3311 <author initials="C." surname="Grothoff" fullname="Christian Grothoff"> 3312 <organization>Technische Universität München</organization> 3313 </author> 3314 <date month="September" year="2011"/> 3315 </front> 3316 <refcontent>5th International Conference on Network and System Security (NSS)</refcontent> 3317 <seriesInfo name="DOI" value="10.1109/ICNSS.2011.6060022"/> 3318 </reference> 3319 3320 <reference anchor="SecureNS" target="https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018"> 3321 <front> 3322 <title>Toward secure name resolution on the Internet</title> 3323 <author initials="C." surname="Grothoff" fullname="Christian Grothoff"> 3324 <organization>Bern University of Applied Sciences</organization> 3325 </author> 3326 <author initials="M." surname="Wachs" fullname="Matthias Wachs"> 3327 <organization>Technische Universität München</organization> 3328 </author> 3329 <author initials="M." surname="Ermert" fullname="Monika Ermert"> 3330 </author> 3331 <author initials="J." surname="Appelbaum" fullname="Jacob Appelbaum"> 3332 <organization>TU Eindhoven</organization> 3333 </author> 3334 <date month="August" year="2018"/> 3335 </front> 3336 <refcontent>Computers and Security, Volume 77, Issue C, pp. 694-708</refcontent> 3337 <seriesInfo name="DOI" value="10.1016/j.cose.2018.01.018"/> 3338 </reference> 3339 3340 <reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git"> 3341 <front> 3342 <title>gnunet.git - GNUnet core repository</title> 3343 <author> 3344 <organization>GNUnet e.V.</organization> 3345 </author> 3346 <date year="2023"/> 3347 </front> 3348 </reference> 3349 3350 <reference anchor="Ascension" target="https://git.gnunet.org/ascension.git"> 3351 <front> 3352 <title>ascension.git - DNS zones to GNS migrating using incremental zone 3353 transfer (AXFR/IXFR)</title> 3354 <author> 3355 <organization>GNUnet e.V.</organization> 3356 </author> 3357 <date year="2023"/> 3358 </front> 3359 </reference> 3360 3361 <reference anchor="GNUnet" target="https://gnunet.org"> 3362 <front> 3363 <title>The GNUnet Project (Home Page)</title> 3364 <author> 3365 <organization>GNUnet e.V.</organization> 3366 </author> 3367 <date year="2023"/> 3368 </front> 3369 </reference> 3370 3371 <reference anchor="reclaim" target="https://reclaim.gnunet.org"> 3372 <front> 3373 <title>re:claimID - Self-sovereign, Decentralised Identity Management and Personal Data Sharing</title> 3374 <author> 3375 <organization>GNUnet e.V.</organization> 3376 </author> 3377 <date year="2023"/> 3378 </front> 3379 </reference> 3380 3381 <reference anchor="GoGNS" target="https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns"> 3382 <front> 3383 <title>gnunet-go (Go GNS)</title> 3384 <author initials="B." surname="Fix" fullname="Bernd Fix"> 3385 </author> 3386 <date month="July" year="2023"/> 3387 </front> 3388 <refcontent>commit 5c815ba</refcontent> 3389 </reference> 3390 3391 <reference anchor="nsswitch" target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html"> 3392 <front> 3393 <title>System Databases and Name Service Switch (Section 29)</title> 3394 <author> 3395 <organization>GNU Project</organization> 3396 </author> 3397 </front> 3398 </reference> 3399 </references> 3400 </references> 3401 <section> 3402 <name>Usage and Migration</name> 3403 <t> 3404 This section outlines a number of specific use cases that may 3405 help readers of this technical specification better understand the protocol. 3406 The considerations below are not meant to be normative for the 3407 GNS protocol in any way. 3408 Instead, they are provided in order to give context and to provide 3409 some background on what the intended use of the protocol is 3410 by its designers. 3411 Further, this section provides pointers to migration paths. 3412 </t> 3413 <section anchor="day_in_zoneowner"> 3414 <name>Zone Dissemination</name> 3415 <t> 3416 In order to become a zone owner, it is sufficient to generate 3417 a zone key and a corresponding secret key using a GNS implementation. 3418 At this point, the zone owner can manage GNS resource records in a 3419 local zone database. 3420 The resource records can then be published by a GNS implementation 3421 as defined in <xref target="publish"/>. 3422 For other users to resolve the resource records, the respective 3423 zone information must be disseminated first. 3424 The zone owner may decide to make the zone key and labels known 3425 to a selected set of users only or to make this information available 3426 to the general public. 3427 </t> 3428 <t> 3429 Sharing zone information directly with specific users not only allows 3430 an implementation to potentially preserve zone and record privacy but also allows 3431 the zone owner and the user to establish strong trust relationships. 3432 For example, a bank may send a customer letter with a QR code that 3433 contains the GNS zone of the bank. 3434 This allows the user to scan the QR code and establish a strong 3435 link to the zone of the bank and with it, for example, the IP address 3436 of the online banking web site. 3437 </t> 3438 <t> 3439 Most Internet services likely want to make their zones available 3440 to the general public in the most efficient way possible. 3441 First, it is reasonable to assume that zones that are commanding 3442 high levels of reputation and trust are likely included in the 3443 default suffix-to-zone mappings of implementations. 3444 Hence, dissemination of a zone through delegation under such zones 3445 can be a viable path in order to disseminate a zone publicly. 3446 For example, it is conceivable that organizations such as ICANN 3447 or country-code TLD registrars also manage GNS zones 3448 and offer registration or delegation services. 3449 </t> 3450 <t> 3451 Following best practices, particularly those related to 3452 security and abuse mitigation, are methods that allow zone owners 3453 and aspiring registrars to gain a good reputation and, eventually, 3454 trust. 3455 This includes, of course, diligent protection of private zone key 3456 material. 3457 Formalizing such best practices is out of scope for this 3458 specification and should be addressed in a separate document that takes 3459 <xref target="security"/> of this document into account. 3460 </t> 3461 </section> 3462 <section> 3463 <name>Start Zone Configuration</name> 3464 <t> 3465 A user is expected to install a GNS implementation if it is not already 3466 provided through other means such as the operating system 3467 or the browser. 3468 It is likely that the implementation ships with a 3469 default Start Zone configuration. 3470 This means that the user is able to resolve GNS names ending on a 3471 zTLD or ending on any suffix-to-name mapping that is part of the 3472 default Start Zone configuration. 3473 At this point, the user may delete or otherwise modify the 3474 implementation's default configuration: 3475 </t> 3476 <ul> 3477 <li> 3478 Deletion of suffix-to-zone mappings may become necessary if the 3479 zone owner referenced by the mapping has lost the trust of the user. 3480 For example, this could be due to lax registration policies resulting 3481 in phishing activities. 3482 Modification and addition of new mappings are means to heal the 3483 namespace perforation that would occur in the case of a deletion 3484 or to simply establish a strong direct trust relationship. 3485 However, this requires the user's knowledge of the respective zone 3486 keys. 3487 This information must be retrieved out of band, as illustrated in 3488 <xref target="day_in_zoneowner"/>: 3489 a bank may send the user a letter with a QR code that contains the 3490 GNS zone of the bank. 3491 The user scans the QR code and adds a new suffix-to-name mapping 3492 using a chosen local name for their bank. 3493 Other examples include scanning zone information off the device of 3494 a friend, from a storefront, or from an advertisement. 3495 The level of trust in the respective zone is contextual and likely 3496 varies from user to user. 3497 Trust in a zone provided through a letter from a bank that 3498 may also include a credit card is certainly different from a zone 3499 found on a random advertisement on the street. 3500 However, this trust is immediately tangible to the user and can 3501 be reflected in the local naming as well. 3502 </li> 3503 <li> 3504 Users that are also clients should facilitate the modification of the Start Zone 3505 configuration -- for example, by providing a QR code reader or other 3506 import mechanisms. 3507 Implementations are ideally implemented 3508 according to best practices and addressing applicable points 3509 from <xref target="security"/>. 3510 Formalizing such best practices is out of scope for this 3511 specification. 3512 </li> 3513 </ul> 3514 </section> 3515 <section anchor="uc_virthost"> 3516 <name>Globally Unique Names and the Web</name> 3517 <t> 3518 HTTP virtual hosting and TLS Server Name Indication (SNI) are common 3519 use cases on the Web. 3520 HTTP clients supply a DNS name in the HTTP 3521 "Host"-header or as part of the TLS handshake, respectively. 3522 This allows the HTTP server to serve the indicated virtual host 3523 with a matching TLS certificate. 3524 The global uniqueness of DNS names is a prerequisite of those use cases. 3525 </t> 3526 <t> 3527 Not all GNS names are globally unique. 3528 However, any resource record in GNS can be represented as a 3529 concatenation of a GNS label and the zTLD of the zone. 3530 While not memorable, this globally unique GNS name can be 3531 leveraged in order to facilitate the same use cases. 3532 Consider the GNS name "www.example.gns.alt" entered in a GNS-aware 3533 HTTP client. 3534 At first, "www.example.gns.alt" is resolved using GNS, yielding a record 3535 set. 3536 Then, the HTTP client determines the virtual host as follows: 3537 </t> 3538 <t> 3539 If there is a LEHO record (<xref target="gnsrecords_leho"/>) 3540 containing "www.example.com" in the record set, then the HTTP 3541 client uses this as the value of the 3542 "Host"-header field of the HTTP request: 3543 </t> 3544 <sourcecode name="" type="http-message"><![CDATA[ 3545 GET / HTTP/1.1 3546 Host: www.example.com 3547 ]]></sourcecode> 3548 <t> 3549 In the absence of a LEHO record, an additional GNS resolution is 3550 required to check whether "www.example.gns.alt" itself points to a 3551 zone delegation record, which implies that the record set that was 3552 originally resolved is published under the apex label. 3553 </t> 3554 <t> 3555 If it does, the unique GNS name is simply the zTLD representation of 3556 the delegated zone: 3557 </t> 3558 <sourcecode name="" type="http-message"><![CDATA[ 3559 GET / HTTP/1.1 3560 Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 3561 ]]></sourcecode> 3562 <t> 3563 On the other hand, if there is no zone delegation record for 3564 "www.example.gns.alt", then the unique GNS name is the concatenation of 3565 the leftmost label (e.g., "www") and the zTLD representation of the zone: 3566 </t> 3567 <sourcecode name="" type="http-message"><![CDATA[ 3568 GET / HTTP/1.1 3569 Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 3570 ]]></sourcecode> 3571 <t> 3572 Note that this second GNS resolution does not require any additional 3573 network operation, as only the local record processing differs as per 3574 the exception mentioned in the last sentence of <xref target="delegation_processing"/>. 3575 </t> 3576 <t> 3577 If the HTTP client is a browser, the use of a unique GNS name 3578 for virtual hosting or TLS SNI does not necessarily have to be 3579 shown to the user. 3580 For example, the name in the URL bar may remain as "www.example.gns.alt" 3581 even if the used unique name in the "Host"-header differs. 3582 </t> 3583 </section> 3584 <section> 3585 <name>Migration Paths</name> 3586 <t> 3587 DNS resolution is built into a variety of existing software 3588 components -- most significantly, operating systems and HTTP clients. 3589 This section illustrates possible migration paths for both in order 3590 to enable legacy applications to resolve GNS names. 3591 </t> 3592 <t> 3593 One way to efficiently facilitate the resolution of GNS names 3594 is via GNS-enabled DNS server implementations. 3595 Local DNS queries are thereby either rerouted or explicitly configured 3596 to be resolved by a "DNS-to-GNS" server that runs locally. 3597 This DNS server tries to interpret any incoming query for a name 3598 as a GNS resolution request. 3599 If no Start Zone can be found for the name and it does not end in 3600 a zTLD, the server tries to resolve the name in DNS. 3601 Otherwise, the name is resolved in GNS. 3602 In the latter case, the resulting record set is converted to a DNS 3603 answer packet and is returned accordingly. 3604 An implementation of a DNS-to-GNS server can be found in 3605 <xref target="GNUnet"/>. 3606 </t> 3607 <t> 3608 A similar approach is to use operating system extensions such as 3609 the NSS <xref target="nsswitch"/>. 3610 It allows the system administrator to configure plugins 3611 that are used for hostname resolution. 3612 A GNS nsswitch plugin can be used in a fashion similar to 3613 that used for the DNS-to-GNS server. 3614 An implementation of a glibc-compatible nsswitch plugin for GNS 3615 can be found in <xref target="GNUnet"/>. 3616 </t> 3617 <t> 3618 The methods above are usually also effective for HTTP client 3619 software. 3620 However, HTTP clients are commonly used in combination with 3621 TLS. 3622 TLS certificate validation, and SNI in particular, require additional logic in HTTP clients when GNS names are 3623 in play (<xref target="uc_virthost"/>). 3624 In order to transparently enable this functionality for migration 3625 purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928"/> 3626 can be configured to resolve domain names. 3627 The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable 3628 of resolving both GNS and DNS names. 3629 In the event of a TLS connection request with a GNS name, the SOCKS5 3630 proxy can terminate the TLS connection 3631 and establish a secure connection against the requested host. 3632 In order to establish a secure connection, the proxy may use LEHO 3633 and TLSA records stored in the record set under the GNS name. 3634 The proxy must provide a locally trusted certificate for the GNS 3635 name to the HTTP client; this usually requires the generation and 3636 configuration of a local trust anchor in the browser. 3637 An implementation of this SOCKS5 proxy can be found in 3638 <xref target="GNUnet"/>. 3639 </t> 3640 </section> 3641 </section> 3642 <section> 3643 <name>Example Flows</name> 3644 <section> 3645 <name>AAAA Example Resolution</name> 3646 <figure anchor="figure_resolution_ex_aaaa"> 3647 <name>Example Resolution of an IPv6 Address</name> 3648 <artwork name="" type="" alt=""> 3649 Local Host | Remote 3650 | Storage 3651 | 3652 | +---------+ 3653 | / /| 3654 | +---------+ | 3655 +-----------+ (1) +----------+ | | | | 3656 | | | | (4,6) | | Record | | 3657 |Application|----------| Resolver |---------------|->| Storage | | 3658 | |<---------| |<--------------|--| |/ 3659 +-----------+ (8) +----------+ (5,7) | +---------+ 3660 A | 3661 | | 3662 (2,3) | | 3663 | | 3664 | | 3665 +---------+ | 3666 / v /| | 3667 +---------+ | | 3668 | | | | 3669 | Start | | | 3670 | Zones | | | 3671 | |/ | 3672 +---------+ | 3673 </artwork> 3674 </figure> 3675 <ol> 3676 <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li> 3677 <li>Determine Start Zone for "www.example.gnu.gns.alt".</li> 3678 <li>Start Zone: zkey0 - Remainder: "www.example".</li> 3679 <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li> 3680 <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record containing zkey1.</li> 3681 <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li> 3682 <li>Retrieve RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li> 3683 <li>Return record set to application.</li> 3684 </ol> 3685 </section> 3686 <section> 3687 <name>REDIRECT Example Resolution</name> 3688 <figure anchor="figure_resolution_ex_redir"> 3689 <name>Example Resolution of an IPv6 Address with Redirect</name> 3690 <artwork name="" type="" alt=""> 3691 Local Host | Remote 3692 | Storage 3693 | 3694 | +---------+ 3695 | / /| 3696 | +---------+ | 3697 +-----------+ (1) +----------+ | | | | 3698 | | | | (4,6,8) | | Record | | 3699 |Application|----------| Resolver |----------------|->| Storage | | 3700 | |<---------| |<---------------|--| |/ 3701 +-----------+ (10) +----------+ (5,7,9) | +---------+ 3702 A | 3703 | | 3704 (2,3) | | 3705 | | 3706 | | 3707 +---------+ | 3708 / v /| | 3709 +---------+ | | 3710 | | | | 3711 | Start | | | 3712 | Zones | | | 3713 | |/ | 3714 +---------+ | 3715 </artwork> 3716 </figure> 3717 <ol> 3718 <li>Look up AAAA record for name: "www.example.tld.gns.alt".</li> 3719 <li>Determine Start Zone for "www.example.tld.gns.alt".</li> 3720 <li>Start Zone: zkey0 - Remainder: "www.example".</li> 3721 <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li> 3722 <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record containing zkey1.</li> 3723 <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li> 3724 <li>Retrieve and decrypt RRBLOCK consisting of a single REDIRECT record containing "www2.+".</li> 3725 <li>Calculate q2=SHA512(ZKDF(zkey1, "www2")) and initiate GET(q2).</li> 3726 <li>Retrieve and decrypt RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li> 3727 <li>Return record set to application.</li> 3728 </ol> 3729 </section> 3730 <section> 3731 <name>GNS2DNS Example Resolution</name> 3732 <figure anchor="figure_resolution_ex_gnsdns"> 3733 <name>Example Resolution of an IPv6 Address with DNS Handover</name> 3734 <artwork name="" type="" alt=""> 3735 Local Host | Remote 3736 | Storage 3737 | 3738 | +---------+ 3739 | / /| 3740 | +---------+ | 3741 +-----------+ (1) +----------+ | | | | 3742 | | | | (4) | | Record | | 3743 |Application|----------| Resolver |------------------|->| Storage | | 3744 | |<---------| |<-----------------|--| |/ 3745 +-----------+ (8) +----------+ (5) | +---------+ 3746 A A | 3747 | | (6,7) | 3748 (2,3) | +----------+ | 3749 | | | 3750 | v | 3751 +---------+ +------------+ | 3752 / v /| | System DNS | | 3753 +---------+ | | Resolver | | 3754 | | | +------------+ | 3755 | Start | | | 3756 | Zones | | | 3757 | |/ | 3758 +---------+ | 3759 </artwork> 3760 </figure> 3761 <ol> 3762 <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li> 3763 <li>Determine Start Zone for "www.example.gnu.gns.alt".</li> 3764 <li>Start Zone: zkey0 - Remainder: "www.example".</li> 3765 <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li> 3766 <li>Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS record containing the name "example.com" and the DNS server IPv4 address 192.0.2.1.</li> 3767 <li>Use system resolver to look up a AAAA record for the DNS name "www.example.com".</li> 3768 <li>Retrieve a DNS reply consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li> 3769 <li>Return record set to application.</li> 3770 </ol> 3771 </section> 3772 </section> 3773 <section anchor="app-c"> 3774 <name>Base32GNS</name> 3775 <t> 3776 Encoding converts a byte array into a string of symbols. 3777 Decoding converts a string of symbols into a byte array. 3778 Decoding fails if the input string has symbols outside the defined set. 3779 </t> 3780 <t> 3781 <xref target="CrockfordB32Encode"/> defines the encoding and decoding symbols for a given 3782 symbol value. 3783 Each symbol value encodes 5 bits. 3784 It can be used to implement the encoding by reading it as follows: 3785 a symbol "A" or "a" is decoded to a 5-bit value 10 when decoding. 3786 A 5-bit block with a value of 18 is encoded to the character "J" when encoding. 3787 If the bit length of the byte string to encode is not a multiple of 5, 3788 it is padded to the next multiple with zeroes. 3789 In order to further increase tolerance for failures in character 3790 recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the same value as the 3791 letter "V" in Base32GNS. 3792 </t> 3793 <table anchor="CrockfordB32Encode"> 3794 <name>The Base32GNS Alphabet, Including the Additional Encoding Symbol "U"</name> 3795 <thead> 3796 <tr> 3797 <th>Symbol Value</th> 3798 <th>Decoding Symbol</th> 3799 <th>Encoding Symbol</th> 3800 </tr> 3801 </thead> 3802 <tbody> 3803 <tr> 3804 <td>0</td> 3805 <td>0 O o</td> 3806 <td>0</td> 3807 </tr> 3808 <tr> 3809 <td>1</td> 3810 <td>1 I i L l</td> 3811 <td>1</td> 3812 </tr> 3813 <tr> 3814 <td>2</td> 3815 <td>2</td> 3816 <td>2</td> 3817 </tr> 3818 <tr> 3819 <td>3</td> 3820 <td>3</td> 3821 <td>3</td> 3822 </tr> 3823 <tr> 3824 <td>4</td> 3825 <td>4</td> 3826 <td>4</td> 3827 </tr> 3828 <tr> 3829 <td>5</td> 3830 <td>5</td> 3831 <td>5</td> 3832 </tr> 3833 <tr> 3834 <td>6</td> 3835 <td>6</td> 3836 <td>6</td> 3837 </tr> 3838 <tr> 3839 <td>7</td> 3840 <td>7</td> 3841 <td>7</td> 3842 </tr> 3843 <tr> 3844 <td>8</td> 3845 <td>8</td> 3846 <td>8</td> 3847 </tr> 3848 <tr> 3849 <td>9</td> 3850 <td>9</td> 3851 <td>9</td> 3852 </tr> 3853 <tr> 3854 <td>10</td> 3855 <td>A a</td> 3856 <td>A</td> 3857 </tr> 3858 <tr> 3859 <td>11</td> 3860 <td>B b</td> 3861 <td>B</td> 3862 </tr> 3863 <tr> 3864 <td>12</td> 3865 <td>C c</td> 3866 <td>C</td> 3867 </tr> 3868 <tr> 3869 <td>13</td> 3870 <td>D d</td> 3871 <td>D</td> 3872 </tr> 3873 <tr> 3874 <td>14</td> 3875 <td>E e</td> 3876 <td>E</td> 3877 </tr> 3878 <tr> 3879 <td>15</td> 3880 <td>F f</td> 3881 <td>F</td> 3882 </tr> 3883 <tr> 3884 <td>16</td> 3885 <td>G g</td> 3886 <td>G</td> 3887 </tr> 3888 <tr> 3889 <td>17</td> 3890 <td>H h</td> 3891 <td>H</td> 3892 </tr> 3893 <tr> 3894 <td>18</td> 3895 <td>J j</td> 3896 <td>J</td> 3897 </tr> 3898 <tr> 3899 <td>19</td> 3900 <td>K k</td> 3901 <td>K</td> 3902 </tr> 3903 <tr> 3904 <td>20</td> 3905 <td>M m</td> 3906 <td>M</td> 3907 </tr> 3908 <tr> 3909 <td>21</td> 3910 <td>N n</td> 3911 <td>N</td> 3912 </tr> 3913 <tr> 3914 <td>22</td> 3915 <td>P p</td> 3916 <td>P</td> 3917 </tr> 3918 <tr> 3919 <td>23</td> 3920 <td>Q q</td> 3921 <td>Q</td> 3922 </tr> 3923 <tr> 3924 <td>24</td> 3925 <td>R r</td> 3926 <td>R</td> 3927 </tr> 3928 <tr> 3929 <td>25</td> 3930 <td>S s</td> 3931 <td>S</td> 3932 </tr> 3933 <tr> 3934 <td>26</td> 3935 <td>T t</td> 3936 <td>T</td> 3937 </tr> 3938 <tr> 3939 <td>27</td> 3940 <td>V v U u</td> 3941 <td>V</td> 3942 </tr> 3943 <tr> 3944 <td>28</td> 3945 <td>W w</td> 3946 <td>W</td> 3947 </tr> 3948 <tr> 3949 <td>29</td> 3950 <td>X x</td> 3951 <td>X</td> 3952 </tr> 3953 <tr> 3954 <td>30</td> 3955 <td>Y y</td> 3956 <td>Y</td> 3957 </tr> 3958 <tr> 3959 <td>31</td> 3960 <td>Z z</td> 3961 <td>Z</td> 3962 </tr> 3963 </tbody> 3964 </table> 3965 3966 </section> 3967 <section> 3968 <name>Test Vectors</name> 3969 <t> 3970 The following test vectors can be used by implementations to test 3971 for conformance with this specification. Unless indicated otherwise, 3972 the test vectors are provided as hexadecimal byte arrays. 3973 </t> 3974 <section> 3975 <name>Base32GNS Encoding/Decoding</name> 3976 <t> 3977 The following are test vectors for the Base32GNS encoding used for zTLDs. The input strings are encoded without the zero terminator. 3978 </t> 3979 <sourcecode name="" type="test-vectors"><![CDATA[ 3980 Base32GNS-Encode: 3981 Input string: "Hello World" 3982 Output string: "91JPRV3F41BPYWKCCG" 3983 3984 Input bytes: 474e55204e616d652053797374656d 3985 Output string: "8X75A82EC5PPA82KF5SQ8SBD" 3986 3987 Base32GNS-Decode: 3988 Input string: "91JPRV3F41BPYWKCCG" 3989 Output string: "Hello World" 3990 3991 Input string: "91JPRU3F41BPYWKCCG" 3992 Output string: "Hello World" 3993 ]]></sourcecode> 3994 3995 </section> 3996 <section> 3997 <name>Record Sets</name> 3998 <t> 3999 The test vectors include record sets with a variety 4000 of record types and flags for both PKEY and EDKEY zones. 4001 This includes labels with UTF-8 characters to demonstrate 4002 internationalized labels. 4003 </t> 4004 <t><strong>(1) PKEY zone with ASCII label and one delegation record</strong></t> 4005 <sourcecode name="" type="test-vectors"><![CDATA[ 4006 Zone private key (d, big-endian): 4007 50 d7 b6 52 a4 ef ea df 4008 f3 73 96 90 97 85 e5 95 4009 21 71 a0 21 78 c8 e7 d4 4010 50 fa 90 79 25 fa fd 98 4011 4012 Zone identifier (ztype|zkey): 4013 00 01 00 00 67 7c 47 7d 4014 2d 93 09 7c 85 b1 95 c6 4015 f9 6d 84 ff 61 f5 98 2c 4016 2c 4f e0 2d 5a 11 fe df 4017 b0 c2 90 1f 4018 4019 zTLD: 4020 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 4021 4022 Label: 4023 74 65 73 74 64 65 6c 65 4024 67 61 74 69 6f 6e 4025 4026 Number of records (integer): 1 4027 4028 Record #0 := ( 4029 EXPIRATION: 8143584694000000 us 4030 00 1c ee 8c 10 e2 59 80 4031 4032 DATA_SIZE: 4033 00 20 4034 4035 TYPE: 4036 00 01 00 00 4037 4038 FLAGS: 00 01 4039 4040 DATA: 4041 21 e3 b3 0f f9 3b c6 d3 4042 5a c8 c6 e0 e1 3a fd ff 4043 79 4c b7 b4 4b bb c7 48 4044 d2 59 d0 a0 28 4d be 84 4045 4046 ) 4047 4048 RDATA: 4049 00 1c ee 8c 10 e2 59 80 4050 00 20 00 01 00 01 00 00 4051 21 e3 b3 0f f9 3b c6 d3 4052 5a c8 c6 e0 e1 3a fd ff 4053 79 4c b7 b4 4b bb c7 48 4054 d2 59 d0 a0 28 4d be 84 4055 4056 Encryption NONCE|EXPIRATION|BLOCK COUNTER: 4057 e9 0a 00 61 00 1c ee 8c 4058 10 e2 59 80 00 00 00 01 4059 4060 Encryption key (K): 4061 86 4e 71 38 ea e7 fd 91 4062 a3 01 36 89 9c 13 2b 23 4063 ac eb db 2c ef 43 cb 19 4064 f6 bf 55 b6 7d b9 b3 b3 4065 4066 Storage key (q): 4067 4a dc 67 c5 ec ee 9f 76 4068 98 6a bd 71 c2 22 4a 3d 4069 ce 2e 91 70 26 c9 a0 9d 4070 fd 44 ce f3 d2 0f 55 a2 4071 73 32 72 5a 6c 8a fb bb 4072 b0 f7 ec 9a f1 cc 42 64 4073 12 99 40 6b 04 fd 9b 5b 4074 57 91 f8 6c 4b 08 d5 f4 4075 4076 ZKDF(zkey, label): 4077 18 2b b6 36 ed a7 9f 79 4078 57 11 bc 27 08 ad bb 24 4079 2a 60 44 6a d3 c3 08 03 4080 12 1d 03 d3 48 b7 ce b6 4081 4082 Derived private key (d', big-endian): 4083 0a 4c 5e 0f 00 63 df ce 4084 db c8 c7 f2 b2 2c 03 0c 4085 86 28 b2 c2 cb ac 9f a7 4086 29 aa e6 1f 89 db 3e 9c 4087 4088 BDATA: 4089 0c 1e da 5c c0 94 a1 c7 4090 a8 88 64 9d 25 fa ee bd 4091 60 da e6 07 3d 57 d8 ae 4092 8d 45 5f 4f 13 92 c0 74 4093 e2 6a c6 69 bd ee c2 34 4094 62 b9 62 95 2c c6 e9 eb 4095 4096 RRBLOCK: 4097 00 00 00 a0 00 01 00 00 4098 18 2b b6 36 ed a7 9f 79 4099 57 11 bc 27 08 ad bb 24 4100 2a 60 44 6a d3 c3 08 03 4101 12 1d 03 d3 48 b7 ce b6 4102 0a d1 0b c1 3b 40 3b 5b 4103 25 61 26 b2 14 5a 6f 60 4104 c5 14 f9 51 ff a7 66 f7 4105 a3 fd 4b ac 4a 4e 19 90 4106 05 5c b8 7e 8d 1b fd 19 4107 aa 09 a4 29 f7 29 e9 f5 4108 c6 ee c2 47 0a ce e2 22 4109 07 59 e9 e3 6c 88 6f 35 4110 00 1c ee 8c 10 e2 59 80 4111 0c 1e da 5c c0 94 a1 c7 4112 a8 88 64 9d 25 fa ee bd 4113 60 da e6 07 3d 57 d8 ae 4114 8d 45 5f 4f 13 92 c0 74 4115 e2 6a c6 69 bd ee c2 34 4116 62 b9 62 95 2c c6 e9 eb 4117 ]]></sourcecode> 4118 <t><strong>(2) PKEY zone with UTF-8 label and three records</strong></t> 4119 <sourcecode name="" type="test-vectors"><![CDATA[ 4120 Zone private key (d, big-endian): 4121 50 d7 b6 52 a4 ef ea df 4122 f3 73 96 90 97 85 e5 95 4123 21 71 a0 21 78 c8 e7 d4 4124 50 fa 90 79 25 fa fd 98 4125 4126 Zone identifier (ztype|zkey): 4127 00 01 00 00 67 7c 47 7d 4128 2d 93 09 7c 85 b1 95 c6 4129 f9 6d 84 ff 61 f5 98 2c 4130 2c 4f e0 2d 5a 11 fe df 4131 b0 c2 90 1f 4132 4133 zTLD: 4134 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 4135 4136 Label: 4137 e5 a4 a9 e4 b8 8b e7 84 4138 a1 e6 95 b5 4139 4140 Number of records (integer): 3 4141 4142 Record #0 := ( 4143 EXPIRATION: 8143584694000000 us 4144 00 1c ee 8c 10 e2 59 80 4145 4146 DATA_SIZE: 4147 00 10 4148 4149 TYPE: 4150 00 00 00 1c 4151 4152 FLAGS: 00 00 4153 4154 DATA: 4155 00 00 00 00 00 00 00 00 4156 00 00 00 00 de ad be ef 4157 4158 ) 4159 4160 Record #1 := ( 4161 EXPIRATION: 17999736901000000 us 4162 00 3f f2 aa 54 08 db 40 4163 4164 DATA_SIZE: 4165 00 06 4166 4167 TYPE: 4168 00 01 00 01 4169 4170 FLAGS: 00 00 4171 4172 DATA: 4173 e6 84 9b e7 a7 b0 4174 4175 ) 4176 4177 Record #2 := ( 4178 EXPIRATION: 11464693629000000 us 4179 00 28 bb 13 ff 37 19 40 4180 4181 DATA_SIZE: 4182 00 0b 4183 4184 TYPE: 4185 00 00 00 10 4186 4187 FLAGS: 00 04 4188 4189 DATA: 4190 48 65 6c 6c 6f 20 57 6f 4191 72 6c 64 4192 4193 ) 4194 4195 RDATA: 4196 00 1c ee 8c 10 e2 59 80 4197 00 10 00 00 00 00 00 1c 4198 00 00 00 00 00 00 00 00 4199 00 00 00 00 de ad be ef 4200 00 3f f2 aa 54 08 db 40 4201 00 06 00 00 00 01 00 01 4202 e6 84 9b e7 a7 b0 00 28 4203 bb 13 ff 37 19 40 00 0b 4204 00 04 00 00 00 10 48 65 4205 6c 6c 6f 20 57 6f 72 6c 4206 64 00 00 00 00 00 00 00 4207 00 00 00 00 00 00 00 00 4208 00 00 00 00 00 00 00 00 4209 00 00 00 00 00 00 00 00 4210 00 00 00 00 00 00 00 00 4211 00 00 00 00 00 00 00 00 4212 4213 Encryption NONCE|EXPIRATION|BLOCK COUNTER: 4214 ee 96 33 c1 00 1c ee 8c 4215 10 e2 59 80 00 00 00 01 4216 4217 Encryption key (K): 4218 fb 3a b5 de 23 bd da e1 4219 99 7a af 7b 92 c2 d2 71 4220 51 40 8b 77 af 7a 41 ac 4221 79 05 7c 4d f5 38 3d 01 4222 4223 Storage key (q): 4224 af f0 ad 6a 44 09 73 68 4225 42 9a c4 76 df a1 f3 4b 4226 ee 4c 36 e7 47 6d 07 aa 4227 64 63 ff 20 91 5b 10 05 4228 c0 99 1d ef 91 fc 3e 10 4229 90 9f 87 02 c0 be 40 43 4230 67 78 c7 11 f2 ca 47 d5 4231 5c f0 b5 4d 23 5d a9 77 4232 4233 ZKDF(zkey, label): 4234 a5 12 96 df 75 7e e2 75 4235 ca 11 8d 4f 07 fa 7a ae 4236 55 08 bc f5 12 aa 41 12 4237 14 29 d4 a0 de 9d 05 7e 4238 4239 Derived private key (d', big-endian): 4240 0a be 56 d6 80 68 ab 40 4241 e1 44 79 0c de 9a cf 4d 4242 78 7f 2d 3c 63 b8 53 05 4243 74 6e 68 03 32 15 f2 ab 4244 4245 BDATA: 4246 d8 c2 8d 2f d6 96 7d 1a 4247 b7 22 53 f2 10 98 b8 14 4248 a4 10 be 1f 59 98 de 03 4249 f5 8f 7e 7c db 7f 08 a6 4250 16 51 be 4d 0b 6f 8a 61 4251 df 15 30 44 0b d7 47 dc 4252 f0 d7 10 4f 6b 8d 24 c2 4253 ac 9b c1 3d 9c 6f e8 29 4254 05 25 d2 a6 d0 f8 84 42 4255 67 a1 57 0e 8e 29 4d c9 4256 3a 31 9f cf c0 3e a2 70 4257 17 d6 fd a3 47 b4 a7 94 4258 97 d7 f6 b1 42 2d 4e dd 4259 82 1c 19 93 4e 96 c1 aa 4260 87 76 57 25 d4 94 c7 64 4261 b1 55 dc 6d 13 26 91 74 4262 4263 RRBLOCK: 4264 00 00 00 f0 00 01 00 00 4265 a5 12 96 df 75 7e e2 75 4266 ca 11 8d 4f 07 fa 7a ae 4267 55 08 bc f5 12 aa 41 12 4268 14 29 d4 a0 de 9d 05 7e 4269 08 5b d6 5f d4 85 10 51 4270 ba ce 2a 45 2a fc 8a 7e 4271 4f 6b 2c 1f 74 f0 20 35 4272 d9 64 1a cd ba a4 66 e0 4273 00 ce d6 f2 d2 3b 63 1c 4274 8e 8a 0b 38 e2 ba e7 9a 4275 22 ca d8 1d 4c 50 d2 25 4276 35 8e bc 17 ac 0f 89 9e 4277 00 1c ee 8c 10 e2 59 80 4278 d8 c2 8d 2f d6 96 7d 1a 4279 b7 22 53 f2 10 98 b8 14 4280 a4 10 be 1f 59 98 de 03 4281 f5 8f 7e 7c db 7f 08 a6 4282 16 51 be 4d 0b 6f 8a 61 4283 df 15 30 44 0b d7 47 dc 4284 f0 d7 10 4f 6b 8d 24 c2 4285 ac 9b c1 3d 9c 6f e8 29 4286 05 25 d2 a6 d0 f8 84 42 4287 67 a1 57 0e 8e 29 4d c9 4288 3a 31 9f cf c0 3e a2 70 4289 17 d6 fd a3 47 b4 a7 94 4290 97 d7 f6 b1 42 2d 4e dd 4291 82 1c 19 93 4e 96 c1 aa 4292 87 76 57 25 d4 94 c7 64 4293 b1 55 dc 6d 13 26 91 74 4294 ]]></sourcecode> 4295 <t><strong>(3) EDKEY zone with ASCII label and one delegation record</strong></t> 4296 <sourcecode name="" type="test-vectors"><![CDATA[ 4297 Zone private key (d): 4298 5a f7 02 0e e1 91 60 32 4299 88 32 35 2b bc 6a 68 a8 4300 d7 1a 7c be 1b 92 99 69 4301 a7 c6 6d 41 5a 0d 8f 65 4302 4303 Zone identifier (ztype|zkey): 4304 00 01 00 14 3c f4 b9 24 4305 03 20 22 f0 dc 50 58 14 4306 53 b8 5d 93 b0 47 b6 3d 4307 44 6c 58 45 cb 48 44 5d 4308 db 96 68 8f 4309 4310 zTLD: 4311 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 4312 4313 Label: 4314 74 65 73 74 64 65 6c 65 4315 67 61 74 69 6f 6e 4316 4317 Number of records (integer): 1 4318 4319 Record #0 := ( 4320 EXPIRATION: 8143584694000000 us 4321 00 1c ee 8c 10 e2 59 80 4322 4323 DATA_SIZE: 4324 00 20 4325 4326 TYPE: 4327 00 01 00 00 4328 4329 FLAGS: 00 01 4330 4331 DATA: 4332 21 e3 b3 0f f9 3b c6 d3 4333 5a c8 c6 e0 e1 3a fd ff 4334 79 4c b7 b4 4b bb c7 48 4335 d2 59 d0 a0 28 4d be 84 4336 4337 ) 4338 4339 RDATA: 4340 00 1c ee 8c 10 e2 59 80 4341 00 20 00 01 00 01 00 00 4342 21 e3 b3 0f f9 3b c6 d3 4343 5a c8 c6 e0 e1 3a fd ff 4344 79 4c b7 b4 4b bb c7 48 4345 d2 59 d0 a0 28 4d be 84 4346 4347 Encryption NONCE|EXPIRATION: 4348 98 13 2e a8 68 59 d3 5c 4349 88 bf d3 17 fa 99 1b cb 4350 00 1c ee 8c 10 e2 59 80 4351 4352 Encryption key (K): 4353 85 c4 29 a9 56 7a a6 33 4354 41 1a 96 91 e9 09 4c 45 4355 28 16 72 be 58 60 34 aa 4356 e4 a2 a2 cc 71 61 59 e2 4357 4358 Storage key (q): 4359 ab aa ba c0 e1 24 94 59 4360 75 98 83 95 aa c0 24 1e 4361 55 59 c4 1c 40 74 e2 55 4362 7b 9f e6 d1 54 b6 14 fb 4363 cd d4 7f c7 f5 1d 78 6d 4364 c2 e0 b1 ec e7 60 37 c0 4365 a1 57 8c 38 4e c6 1d 44 4366 56 36 a9 4e 88 03 29 e9 4367 4368 ZKDF(zkey, label): 4369 9b f2 33 19 8c 6d 53 bb 4370 db ac 49 5c ab d9 10 49 4371 a6 84 af 3f 40 51 ba ca 4372 b0 dc f2 1c 8c f2 7a 1a 4373 4374 nonce := SHA-256(dh[32..63] || h): 4375 14 f2 c0 6b ed c3 aa 2d 4376 f0 71 13 9c 50 39 34 f3 4377 4b fa 63 11 a8 52 f2 11 4378 f7 3a df 2e 07 61 ec 35 4379 4380 Derived private key (d', big-endian): 4381 3b 1b 29 d4 23 0b 10 a8 4382 ec 4d a3 c8 6e db 88 ea 4383 cd 54 08 5c 1d db 63 f7 4384 a9 d7 3f 7c cb 2f c3 98 4385 4386 BDATA: 4387 57 7c c6 c9 5a 14 e7 04 4388 09 f2 0b 01 67 e6 36 d0 4389 10 80 7c 4f 00 37 2d 69 4390 8c 82 6b d9 2b c2 2b d6 4391 bb 45 e5 27 7c 01 88 1d 4392 6a 43 60 68 e4 dd f1 c6 4393 b7 d1 41 6f af a6 69 7c 4394 25 ed d9 ea e9 91 67 c3 4395 4396 RRBLOCK: 4397 00 00 00 b0 00 01 00 14 4398 9b f2 33 19 8c 6d 53 bb 4399 db ac 49 5c ab d9 10 49 4400 a6 84 af 3f 40 51 ba ca 4401 b0 dc f2 1c 8c f2 7a 1a 4402 9f 56 a8 86 ea 73 9d 59 4403 17 50 8f 9b 75 56 39 f3 4404 a9 ac fa ed ed ca 7f bf 4405 a7 94 b1 92 e0 8b f9 ed 4406 4c 7e c8 59 4c 9f 7b 4e 4407 19 77 4f f8 38 ec 38 7a 4408 8f 34 23 da ac 44 9f 59 4409 db 4e 83 94 3f 90 72 00 4410 00 1c ee 8c 10 e2 59 80 4411 57 7c c6 c9 5a 14 e7 04 4412 09 f2 0b 01 67 e6 36 d0 4413 10 80 7c 4f 00 37 2d 69 4414 8c 82 6b d9 2b c2 2b d6 4415 bb 45 e5 27 7c 01 88 1d 4416 6a 43 60 68 e4 dd f1 c6 4417 b7 d1 41 6f af a6 69 7c 4418 25 ed d9 ea e9 91 67 c3 4419 ]]></sourcecode> 4420 <t><strong>(4) EDKEY zone with UTF-8 label and three records</strong></t> 4421 <sourcecode name="" type="test-vectors"><![CDATA[ 4422 Zone private key (d): 4423 5a f7 02 0e e1 91 60 32 4424 88 32 35 2b bc 6a 68 a8 4425 d7 1a 7c be 1b 92 99 69 4426 a7 c6 6d 41 5a 0d 8f 65 4427 4428 Zone identifier (ztype|zkey): 4429 00 01 00 14 3c f4 b9 24 4430 03 20 22 f0 dc 50 58 14 4431 53 b8 5d 93 b0 47 b6 3d 4432 44 6c 58 45 cb 48 44 5d 4433 db 96 68 8f 4434 4435 zTLD: 4436 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 4437 4438 Label: 4439 e5 a4 a9 e4 b8 8b e7 84 4440 a1 e6 95 b5 4441 4442 Number of records (integer): 3 4443 4444 Record #0 := ( 4445 EXPIRATION: 8143584694000000 us 4446 00 1c ee 8c 10 e2 59 80 4447 4448 DATA_SIZE: 4449 00 10 4450 4451 TYPE: 4452 00 00 00 1c 4453 4454 FLAGS: 00 00 4455 4456 DATA: 4457 00 00 00 00 00 00 00 00 4458 00 00 00 00 de ad be ef 4459 4460 ) 4461 4462 Record #1 := ( 4463 EXPIRATION: 17999736901000000 us 4464 00 3f f2 aa 54 08 db 40 4465 4466 DATA_SIZE: 4467 00 06 4468 4469 TYPE: 4470 00 01 00 01 4471 4472 FLAGS: 00 00 4473 4474 DATA: 4475 e6 84 9b e7 a7 b0 4476 4477 ) 4478 4479 Record #2 := ( 4480 EXPIRATION: 11464693629000000 us 4481 00 28 bb 13 ff 37 19 40 4482 4483 DATA_SIZE: 4484 00 0b 4485 4486 TYPE: 4487 00 00 00 10 4488 4489 FLAGS: 00 04 4490 4491 DATA: 4492 48 65 6c 6c 6f 20 57 6f 4493 72 6c 64 4494 4495 ) 4496 4497 RDATA: 4498 00 1c ee 8c 10 e2 59 80 4499 00 10 00 00 00 00 00 1c 4500 00 00 00 00 00 00 00 00 4501 00 00 00 00 de ad be ef 4502 00 3f f2 aa 54 08 db 40 4503 00 06 00 00 00 01 00 01 4504 e6 84 9b e7 a7 b0 00 28 4505 bb 13 ff 37 19 40 00 0b 4506 00 04 00 00 00 10 48 65 4507 6c 6c 6f 20 57 6f 72 6c 4508 64 00 00 00 00 00 00 00 4509 00 00 00 00 00 00 00 00 4510 00 00 00 00 00 00 00 00 4511 00 00 00 00 00 00 00 00 4512 00 00 00 00 00 00 00 00 4513 00 00 00 00 00 00 00 00 4514 4515 Encryption NONCE|EXPIRATION: 4516 bb 0d 3f 0f bd 22 42 77 4517 50 da 5d 69 12 16 e6 c9 4518 00 1c ee 8c 10 e2 59 80 4519 4520 Encryption key (K): 4521 3d f8 05 bd 66 87 aa 14 4522 20 96 28 c2 44 b1 11 91 4523 88 c3 92 56 37 a4 1e 5d 4524 76 49 6c 29 45 dc 37 7b 4525 4526 Storage key (q): 4527 ba f8 21 77 ee c0 81 e0 4528 74 a7 da 47 ff c6 48 77 4529 58 fb 0d f0 1a 6c 7f bb 4530 52 fc 8a 31 be f0 29 af 4531 74 aa 0d c1 5a b8 e2 fa 4532 7a 54 b4 f5 f6 37 f6 15 4533 8f a7 f0 3c 3f ce be 78 4534 d3 f9 d6 40 aa c0 d1 ed 4535 4536 ZKDF(zkey, label): 4537 74 f9 00 68 f1 67 69 53 4538 52 a8 a6 c2 eb 98 48 98 4539 c5 3a cc a0 98 04 70 c6 4540 c8 12 64 cb dd 78 ad 11 4541 4542 nonce := SHA-256(dh[32..63] || h): 4543 f8 6a b5 33 8a 74 d7 a1 4544 d2 77 ea 11 ff 95 cb e8 4545 3a cf d3 97 3b b4 ab ca 4546 0a 1b 60 62 c3 7a b3 9c 4547 4548 Derived private key (d', big-endian): 4549 17 c0 68 a6 c3 f7 20 de 4550 0e 1b 69 ff 3f 53 e0 5d 4551 3f e5 c5 b0 51 25 7a 89 4552 a6 3c 1a d3 5a c4 35 58 4553 4554 BDATA: 4555 4e b3 5a 50 d4 0f e1 a4 4556 29 c7 f4 b2 67 a0 59 de 4557 4e 2c 8a 89 a5 ed 53 d3 4558 d4 92 58 59 d2 94 9f 7f 4559 30 d8 a2 0c aa 96 f8 81 4560 45 05 2d 1c da 04 12 49 4561 8f f2 5f f2 81 6e f0 ce 4562 61 fe 69 9b fa c7 2c 15 4563 dc 83 0e a9 b0 36 17 1c 4564 cf ca bb dd a8 de 3c 86 4565 ed e2 95 70 d0 17 4b 82 4566 82 09 48 a9 28 b7 f0 0e 4567 fb 40 1c 10 fe 80 bb bb 4568 02 76 33 1b f7 f5 1b 8d 4569 74 57 9c 14 14 f2 2d 50 4570 1a d2 5a e2 49 f5 bb f2 4571 a6 c3 72 59 d1 75 e4 40 4572 b2 94 39 c6 05 19 cb b1 4573 4574 RRBLOCK: 4575 00 00 01 00 00 01 00 14 4576 74 f9 00 68 f1 67 69 53 4577 52 a8 a6 c2 eb 98 48 98 4578 c5 3a cc a0 98 04 70 c6 4579 c8 12 64 cb dd 78 ad 11 4580 75 6d 2c 15 7a d2 ea 4f 4581 c0 b1 b9 1c 08 03 79 44 4582 61 d3 de f2 0d d1 63 6c 4583 fe dc 03 89 c5 49 d1 43 4584 6c c3 5b 4e 1b f8 89 5a 4585 64 6b d9 a6 f4 6b 83 48 4586 1d 9c 0e 91 d4 e1 be bb 4587 6a 83 52 6f b7 25 2a 06 4588 00 1c ee 8c 10 e2 59 80 4589 4e b3 5a 50 d4 0f e1 a4 4590 29 c7 f4 b2 67 a0 59 de 4591 4e 2c 8a 89 a5 ed 53 d3 4592 d4 92 58 59 d2 94 9f 7f 4593 30 d8 a2 0c aa 96 f8 81 4594 45 05 2d 1c da 04 12 49 4595 8f f2 5f f2 81 6e f0 ce 4596 61 fe 69 9b fa c7 2c 15 4597 dc 83 0e a9 b0 36 17 1c 4598 cf ca bb dd a8 de 3c 86 4599 ed e2 95 70 d0 17 4b 82 4600 82 09 48 a9 28 b7 f0 0e 4601 fb 40 1c 10 fe 80 bb bb 4602 02 76 33 1b f7 f5 1b 8d 4603 74 57 9c 14 14 f2 2d 50 4604 1a d2 5a e2 49 f5 bb f2 4605 a6 c3 72 59 d1 75 e4 40 4606 b2 94 39 c6 05 19 cb b1 4607 ]]></sourcecode> 4608 </section> 4609 <section> 4610 <name>Zone Revocation</name> 4611 <t> 4612 The following is an example revocation for a PKEY zone: 4613 </t> 4614 <sourcecode name="" type="test-vectors"><![CDATA[ 4615 Zone private key (d, big-endian): 4616 6f ea 32 c0 5a f5 8b fa 4617 97 95 53 d1 88 60 5f d5 4618 7d 8b f9 cc 26 3b 78 d5 4619 f7 47 8c 07 b9 98 ed 70 4620 4621 Zone identifier (ztype|zkey): 4622 00 01 00 00 2c a2 23 e8 4623 79 ec c4 bb de b5 da 17 4624 31 92 81 d6 3b 2e 3b 69 4625 55 f1 c3 77 5c 80 4a 98 4626 d5 f8 dd aa 4627 4628 zTLD: 4629 000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8 4630 4631 Difficulty (5 base difficulty + 2 epochs): 7 4632 4633 Signed message: 4634 00 00 00 34 00 00 00 03 4635 00 05 ff 1c 56 e4 b2 68 4636 00 01 00 00 2c a2 23 e8 4637 79 ec c4 bb de b5 da 17 4638 31 92 81 d6 3b 2e 3b 69 4639 55 f1 c3 77 5c 80 4a 98 4640 d5 f8 dd aa 4641 4642 Proof: 4643 00 05 ff 1c 56 e4 b2 68 4644 00 00 39 5d 18 27 c0 00 4645 38 0b 54 aa 70 16 ac a2 4646 38 0b 54 aa 70 16 ad 62 4647 38 0b 54 aa 70 16 af 3e 4648 38 0b 54 aa 70 16 af 93 4649 38 0b 54 aa 70 16 b0 bf 4650 38 0b 54 aa 70 16 b0 ee 4651 38 0b 54 aa 70 16 b1 c9 4652 38 0b 54 aa 70 16 b1 e5 4653 38 0b 54 aa 70 16 b2 78 4654 38 0b 54 aa 70 16 b2 b2 4655 38 0b 54 aa 70 16 b2 d6 4656 38 0b 54 aa 70 16 b2 e4 4657 38 0b 54 aa 70 16 b3 2c 4658 38 0b 54 aa 70 16 b3 5a 4659 38 0b 54 aa 70 16 b3 9d 4660 38 0b 54 aa 70 16 b3 c0 4661 38 0b 54 aa 70 16 b3 dd 4662 38 0b 54 aa 70 16 b3 f4 4663 38 0b 54 aa 70 16 b4 42 4664 38 0b 54 aa 70 16 b4 76 4665 38 0b 54 aa 70 16 b4 8c 4666 38 0b 54 aa 70 16 b4 a4 4667 38 0b 54 aa 70 16 b4 c9 4668 38 0b 54 aa 70 16 b4 f0 4669 38 0b 54 aa 70 16 b4 f7 4670 38 0b 54 aa 70 16 b5 79 4671 38 0b 54 aa 70 16 b6 34 4672 38 0b 54 aa 70 16 b6 8e 4673 38 0b 54 aa 70 16 b7 b4 4674 38 0b 54 aa 70 16 b8 7e 4675 38 0b 54 aa 70 16 b8 f8 4676 38 0b 54 aa 70 16 b9 2a 4677 00 01 00 00 2c a2 23 e8 4678 79 ec c4 bb de b5 da 17 4679 31 92 81 d6 3b 2e 3b 69 4680 55 f1 c3 77 5c 80 4a 98 4681 d5 f8 dd aa 08 ca ff de 4682 3c 6d f1 45 f7 e0 79 81 4683 15 37 b2 b0 42 2d 5e 1f 4684 b2 01 97 81 ec a2 61 d1 4685 f9 d8 ea 81 0a bc 2f 33 4686 47 7f 04 e3 64 81 11 be 4687 71 c2 48 82 1a d6 04 f4 4688 94 e7 4d 0b f5 11 d2 c1 4689 62 77 2e 81 4690 ]]></sourcecode> 4691 <t> 4692 The following is an example revocation for an EDKEY zone: 4693 </t> 4694 <sourcecode name="" type="test-vectors"><![CDATA[ 4695 Zone private key (d): 4696 5a f7 02 0e e1 91 60 32 4697 88 32 35 2b bc 6a 68 a8 4698 d7 1a 7c be 1b 92 99 69 4699 a7 c6 6d 41 5a 0d 8f 65 4700 4701 Zone identifier (ztype|zkey): 4702 00 01 00 14 3c f4 b9 24 4703 03 20 22 f0 dc 50 58 14 4704 53 b8 5d 93 b0 47 b6 3d 4705 44 6c 58 45 cb 48 44 5d 4706 db 96 68 8f 4707 4708 zTLD: 4709 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 4710 4711 Difficulty (5 base difficulty + 2 epochs): 7 4712 4713 Signed message: 4714 00 00 00 34 00 00 00 03 4715 00 05 ff 1c 57 35 42 bd 4716 00 01 00 14 3c f4 b9 24 4717 03 20 22 f0 dc 50 58 14 4718 53 b8 5d 93 b0 47 b6 3d 4719 44 6c 58 45 cb 48 44 5d 4720 db 96 68 8f 4721 4722 Proof: 4723 00 05 ff 1c 57 35 42 bd 4724 00 00 39 5d 18 27 c0 00 4725 58 4c 93 3c b0 99 2a 08 4726 58 4c 93 3c b0 99 2d f7 4727 58 4c 93 3c b0 99 2e 21 4728 58 4c 93 3c b0 99 2e 2a 4729 58 4c 93 3c b0 99 2e 53 4730 58 4c 93 3c b0 99 2e 8e 4731 58 4c 93 3c b0 99 2f 13 4732 58 4c 93 3c b0 99 2f 2d 4733 58 4c 93 3c b0 99 2f 3c 4734 58 4c 93 3c b0 99 2f 41 4735 58 4c 93 3c b0 99 2f fd 4736 58 4c 93 3c b0 99 30 33 4737 58 4c 93 3c b0 99 30 82 4738 58 4c 93 3c b0 99 30 a2 4739 58 4c 93 3c b0 99 30 e1 4740 58 4c 93 3c b0 99 31 ce 4741 58 4c 93 3c b0 99 31 de 4742 58 4c 93 3c b0 99 32 12 4743 58 4c 93 3c b0 99 32 4e 4744 58 4c 93 3c b0 99 32 9f 4745 58 4c 93 3c b0 99 33 31 4746 58 4c 93 3c b0 99 33 87 4747 58 4c 93 3c b0 99 33 8c 4748 58 4c 93 3c b0 99 33 e5 4749 58 4c 93 3c b0 99 33 f3 4750 58 4c 93 3c b0 99 34 26 4751 58 4c 93 3c b0 99 34 30 4752 58 4c 93 3c b0 99 34 68 4753 58 4c 93 3c b0 99 34 88 4754 58 4c 93 3c b0 99 34 8a 4755 58 4c 93 3c b0 99 35 4c 4756 58 4c 93 3c b0 99 35 bd 4757 00 01 00 14 3c f4 b9 24 4758 03 20 22 f0 dc 50 58 14 4759 53 b8 5d 93 b0 47 b6 3d 4760 44 6c 58 45 cb 48 44 5d 4761 db 96 68 8f 04 ae 26 f7 4762 63 56 5a b7 aa ab 01 71 4763 72 4f 3c a8 bc c5 1a 98 4764 b7 d4 c9 2e a3 3c d9 34 4765 4c a8 b6 3e 04 53 3a bf 4766 1a 3c 05 49 16 b3 68 2c 4767 5c a8 cb 4d d0 f8 4c 3b 4768 77 48 7a ac 6e ce 38 48 4769 0b a9 d5 00 4770 ]]></sourcecode> 4771 </section> 4772 </section> 4773 <section numbered="false"> 4774 <name>Acknowledgements</name> 4775 <t> 4776 The authors thank all reviewers for their comments. In particular, 4777 we thank <contact fullname="D. J. Bernstein"/>, <contact fullname="S. Bortzmeyer"/>, <contact fullname="A. Farrel"/>, <contact fullname="E. Lear"/>, and <contact fullname="R. Salz"/> for their 4778 insightful and detailed technical reviews. We thank <contact fullname="J. Yao"/> and <contact fullname="J. Klensin"/> for the 4779 internationalization reviews. We thank <contact fullname="Dr. J. Appelbaum"/> for suggesting the name "GNU Name System" and <contact fullname="Dr. Richard Stallman"/> for approving its use. We thank <contact fullname="T. Lange"/> and <contact fullname="M. Wachs"/> for their earlier contributions to the design and implementation of GNS. We thank NLnet and NGI DISCOVERY for funding 4780 work on the GNU Name System. 4781 </t> 4782 </section> 4783 </back> 4784 </rfc>