commit 97419af29dda19821b36115777b06ac349f3063c
parent 3ac66657c0b978ef6b4f538a2cd3b9200ec65097
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Sat, 5 Oct 2019 12:14:02 +0200
add resolution
Diffstat:
3 files changed, 611 insertions(+), 458 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1895,15 +1895,64 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-entry-zone" class="section-name selfRef">Entry Zone</a>
</h3>
<p id="section-6.1-1">
- There are three sources from which the entry zone can be determined:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-6.1-2.1">Local zone store<a href="#section-6.1-2.1" class="pilcrow">¶</a>
+ There are three sources from which the entry zone can be determined
+ which MUST be queried in this order:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal" id="section-6.1-2">
+ <li id="section-6.1-2.1">Check if top-level domain maps to a local zone key.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
</li>
- <li id="section-6.1-2.2">External prefix to zone key mappings<a href="#section-6.1-2.2" class="pilcrow">¶</a>
+ <li id="section-6.1-2.2">Check if top-level domain maps to a local zone name.<a href="#section-6.1-2.2" class="pilcrow">¶</a>
</li>
- <li id="section-6.1-2.3">Zone key TLD<a href="#section-6.1-2.3" class="pilcrow">¶</a>
+ <li id="section-6.1-2.3">Check if a configuration exists that maps a prefix to an
+ external zone key.<a href="#section-6.1-2.3" class="pilcrow">¶</a>
</li>
- </ul>
+ </ol>
+<p id="section-6.1-3">
+ If the TLD is a Base32-encoded public zone key "zk", the entry
+ zone of the resolution process is implicitly given by the name.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.1-4">
+<pre>
+ Example name: www.example.<Base32(zk)>
+ => Entry zone: zk
+ => Name to resolve from entry zone: www.example
+ </pre><a href="#section-6.1-4" class="pilcrow">¶</a>
+</div>
+<p id="section-6.1-5">
+ Each local zone is associated with a single GNS label. If this label
+ is the top-level domain (TLD) of the name to resolve, resolution
+ MUST start from this local zone.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.1-6">
+<pre>
+ Example name: www.example.gnu
+ Local zones:
+ fr = (d0,zk0)
+ gnu = (d1,zk1)
+ com = (d2,zk2)
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www.example
+ </pre><a href="#section-6.1-6" class="pilcrow">¶</a>
+</div>
+<p id="section-6.1-7">
+ If no matching local zone for the TLD is found, external prefix to
+ zone mappings are checked. External prefix to zone key mapping
+ SHOULD be configurable through the GNS implementation. A mapping
+ has the form "prefix = public zone key".
+ The prefix may consist of multiple GNS labels concatenated with a
+ ".". If multiple prefixes match the name to resolve, the longest
+ prefix is chosen. The prefix length of two results cannot be equal,
+ as this would indicate a misconfiguration.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-6.1-8">
+<pre>
+ Example name: www.example.gnu
+ Local prefix mappings:
+ gnu = zk0
+ example.gnu = zk1
+ example.com = zk2
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www
+ </pre><a href="#section-6.1-8" class="pilcrow">¶</a>
+</div>
</section>
</div>
<div id="recursion">
@@ -1921,7 +1970,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-namespace-revocation" class="section-name selfRef">Namespace Revocation</a>
</h2>
<p id="section-7-1">
- TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
@@ -1930,7 +1979,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<p id="section-8-1">
- TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
+ TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
@@ -1939,7 +1988,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-9-1">
- This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
+ This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
@@ -1947,107 +1996,107 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-test-vectors" class="section-name selfRef">Test Vectors</a>
</h2>
<p id="section-10-1">
- The following represents a test vector for a record of type MX with
- a priority of 10 and the mail hostname mail.example.com.<a href="#section-10-1" class="pilcrow">¶</a></p>
+ The following represents a test vector for a record of type MX with
+ a priority of 10 and the mail hostname mail.example.com.<a href="#section-10-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-10-2">
<pre>
- label := "mail"
-
- d :=
- 71199f7b287cc77a
- 0d21b5e40a77cb1d
- f89333903b284fe8
- 1878bf47f3b39da0
-
- zk (public zone key) :=
- dff911496d025d7e
- 0885c03d19153e99
- 4f213f23ea719eca
- 17fc32dc410e082e
-
- h :=
- 2af3275a9cf90e54
- f2dbf7930be76fb9
- 5e7c80b1416f8ca6
- dc50ce8e1fb759b9
- fedcdcf546c17e9b
- 4c4f23632855c053
- 6668e9f684f4dc33
- 6d656b27392b0fee
-
- d_h :=
- 01fb61f482c17633
- 77611c4c2509e0f3
- 81b0e7e4405c10bd
- 0017c802f7d32e18
-
- q (query key) :=
- 6fce4deddc5ad681
- f4e29a3310767e3b
- 8b38bc1b276ce2ba
- 9bf1b49df1e120a3
- 20ecc9dffb68416f
- 11729ad878ad3bdf
- d0b4db2626b620d7
- 8e0604e4393c66a3
-
- AES_KEY :=
- afefd21a087a150d
- 6757741a4eda02a5
- 65df7ca86ba44b21
- 3f8106c0071eaf01
-
- AES_IV :=
- a808b929bc9fad7a
- 686bbe3432bed77a
-
- TWOFISH_KEY :=
- c9d0089df01d0bf4
- e4c8db4b2ccc7328
- 3425e8a811ae59d2
- 99e2747285d2a479
-
- TWOFISH_IV :=
- 071be189a9d236f9
- b4a3654bb8c281d4
-
- RDATA :=
- 0000000100059412 RR COUNT | EXPIRA-
- 09ddea0f00000014 -TION | DATA SIZE (20)
- 0000000f00000000 TYPE (15=MX) | FLAGS (0)
- 000a046d61696c07 Priority (10) |4 | mail | 7
- 6578616d706c6503 example | 3
- 636f6d0000000000 com | \0 | Followed by
- 0000000000000000 24 bytes of padding to 2^6
- 0000000000000000
- 00000000
-
-
- BLOCK :=
- 055cb070e05fe6de SIGNATURE
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54
- 07e731a34680ee33
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46____________
- 8cb514a56c0eaae0 zk_h
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291____________
- 000000540000000f SIZE (=84) | PURPOSE (=15)
- 0005941209dde25b EXPIRATION
- d99d08fa123da096 BDATA
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
- </pre><a href="#section-10-2" class="pilcrow">¶</a>
+ label := "mail"
+
+ d :=
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
+
+ zk (public zone key) :=
+ dff911496d025d7e
+ 0885c03d19153e99
+ 4f213f23ea719eca
+ 17fc32dc410e082e
+
+ h :=
+ 2af3275a9cf90e54
+ f2dbf7930be76fb9
+ 5e7c80b1416f8ca6
+ dc50ce8e1fb759b9
+ fedcdcf546c17e9b
+ 4c4f23632855c053
+ 6668e9f684f4dc33
+ 6d656b27392b0fee
+
+ d_h :=
+ 01fb61f482c17633
+ 77611c4c2509e0f3
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
+
+ q (query key) :=
+ 6fce4deddc5ad681
+ f4e29a3310767e3b
+ 8b38bc1b276ce2ba
+ 9bf1b49df1e120a3
+ 20ecc9dffb68416f
+ 11729ad878ad3bdf
+ d0b4db2626b620d7
+ 8e0604e4393c66a3
+
+ AES_KEY :=
+ afefd21a087a150d
+ 6757741a4eda02a5
+ 65df7ca86ba44b21
+ 3f8106c0071eaf01
+
+ AES_IV :=
+ a808b929bc9fad7a
+ 686bbe3432bed77a
+
+ TWOFISH_KEY :=
+ c9d0089df01d0bf4
+ e4c8db4b2ccc7328
+ 3425e8a811ae59d2
+ 99e2747285d2a479
+
+ TWOFISH_IV :=
+ 071be189a9d236f9
+ b4a3654bb8c281d4
+
+ RDATA :=
+ 0000000100059412 RR COUNT | EXPIRA-
+ 09ddea0f00000014 -TION | DATA SIZE (20)
+ 0000000f00000000 TYPE (15=MX) | FLAGS (0)
+ 000a046d61696c07 Priority (10) |4 | mail | 7
+ 6578616d706c6503 example | 3
+ 636f6d0000000000 com | \0 | Followed by
+ 0000000000000000 24 bytes of padding to 2^6
+ 0000000000000000
+ 00000000
+
+
+ BLOCK :=
+ 055cb070e05fe6de SIGNATURE
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46____________
+ 8cb514a56c0eaae0 zk_h
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291____________
+ 000000540000000f SIZE (=84) | PURPOSE (=15)
+ 0005941209dde25b EXPIRATION
+ d99d08fa123da096 BDATA
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
+ </pre><a href="#section-10-2" class="pilcrow">¶</a>
</div>
</section>
<section id="section-11">
@@ -2073,7 +2122,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="RFC5869">[RFC5869]</dt>
<dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. Eronen</span>, <span class="refTitle">"
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
"</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>></span>. </dd>
<dt id="RFC5890">[RFC5890]</dt>
<dd>
@@ -2084,7 +2133,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="RFC6979">[RFC6979]</dt>
<dd>
<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"
- Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
"</span>, <span class="seriesInfo">RFC 6979</span>, <span class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08">August 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6979">https://www.rfc-editor.org/info/rfc6979</a>></span>. </dd>
<dt id="RFC7748">[RFC7748]</dt>
<dd>
@@ -2095,7 +2144,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"
- The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
+ The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
"</span>, <time datetime="1999-03">March 1999</time>. </dd>
</dl>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -75,13 +75,13 @@ Table of Contents
5. Internationalization and Character Encoding . . . . . . . . . 13
6. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.2. Recursive Resolution . . . . . . . . . . . . . . . . . . 14
- 7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 14
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 14
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 16
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.2. Recursive Resolution . . . . . . . . . . . . . . . . . . 15
+ 7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 15
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 17
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
@@ -732,13 +732,68 @@ Internet-Draft The GNU Name System July 2019
6.1. Entry Zone
- There are three sources from which the entry zone can be determined:
+ There are three sources from which the entry zone can be determined
+ which MUST be queried in this order:
- * Local zone store
+ 1. Check if top-level domain maps to a local zone key.
- * External prefix to zone key mappings
+ 2. Check if top-level domain maps to a local zone name.
- * Zone key TLD
+ 3. Check if a configuration exists that maps a prefix to an external
+ zone key.
+
+ If the TLD is a Base32-encoded public zone key "zk", the entry zone
+ of the resolution process is implicitly given by the name.
+
+ Example name: www.example.<Base32(zk)>
+ => Entry zone: zk
+ => Name to resolve from entry zone: www.example
+
+ Each local zone is associated with a single GNS label. If this label
+ is the top-level domain (TLD) of the name to resolve, resolution MUST
+ start from this local zone.
+
+ Example name: www.example.gnu
+ Local zones:
+ fr = (d0,zk0)
+ gnu = (d1,zk1)
+ com = (d2,zk2)
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www.example
+
+ If no matching local zone for the TLD is found, external prefix to
+ zone mappings are checked. External prefix to zone key mapping
+ SHOULD be configurable through the GNS implementation. A mapping has
+ the form "prefix = public zone key". The prefix may consist of
+ multiple GNS labels concatenated with a ".". If multiple prefixes
+ match the name to resolve, the longest prefix is chosen. The prefix
+ length of two results cannot be equal, as this would indicate a
+ misconfiguration.
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ Example name: www.example.gnu
+ Local prefix mappings:
+ gnu = zk0
+ example.gnu = zk1
+ example.com = zk2
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www
6.2. Recursive Resolution
@@ -759,118 +814,118 @@ Internet-Draft The GNU Name System July 2019
The following represents a test vector for a record of type MX with a
priority of 10 and the mail hostname mail.example.com.
- label := "mail"
+ label := "mail"
- d :=
- 71199f7b287cc77a
- 0d21b5e40a77cb1d
- f89333903b284fe8
- 1878bf47f3b39da0
+ d :=
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
- zk (public zone key) :=
- dff911496d025d7e
- 0885c03d19153e99
- 4f213f23ea719eca
- 17fc32dc410e082e
+ zk (public zone key) :=
+ dff911496d025d7e
+ 0885c03d19153e99
+ 4f213f23ea719eca
+ 17fc32dc410e082e
- h :=
- 2af3275a9cf90e54
- f2dbf7930be76fb9
- 5e7c80b1416f8ca6
- dc50ce8e1fb759b9
+ h :=
+ 2af3275a9cf90e54
+ f2dbf7930be76fb9
+ 5e7c80b1416f8ca6
+ dc50ce8e1fb759b9
+ fedcdcf546c17e9b
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
Internet-Draft The GNU Name System July 2019
- fedcdcf546c17e9b
- 4c4f23632855c053
- 6668e9f684f4dc33
- 6d656b27392b0fee
-
- d_h :=
- 01fb61f482c17633
- 77611c4c2509e0f3
- 81b0e7e4405c10bd
- 0017c802f7d32e18
-
- q (query key) :=
- 6fce4deddc5ad681
- f4e29a3310767e3b
- 8b38bc1b276ce2ba
- 9bf1b49df1e120a3
- 20ecc9dffb68416f
- 11729ad878ad3bdf
- d0b4db2626b620d7
- 8e0604e4393c66a3
-
- AES_KEY :=
- afefd21a087a150d
- 6757741a4eda02a5
- 65df7ca86ba44b21
- 3f8106c0071eaf01
-
- AES_IV :=
- a808b929bc9fad7a
- 686bbe3432bed77a
-
- TWOFISH_KEY :=
- c9d0089df01d0bf4
- e4c8db4b2ccc7328
- 3425e8a811ae59d2
- 99e2747285d2a479
-
- TWOFISH_IV :=
- 071be189a9d236f9
- b4a3654bb8c281d4
-
- RDATA :=
- 0000000100059412 RR COUNT | EXPIRA-
- 09ddea0f00000014 -TION | DATA SIZE (20)
- 0000000f00000000 TYPE (15=MX) | FLAGS (0)
- 000a046d61696c07 Priority (10) |4 | mail | 7
- 6578616d706c6503 example | 3
- 636f6d0000000000 com | \0 | Followed by
+ 4c4f23632855c053
+ 6668e9f684f4dc33
+ 6d656b27392b0fee
+
+ d_h :=
+ 01fb61f482c17633
+ 77611c4c2509e0f3
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
+
+ q (query key) :=
+ 6fce4deddc5ad681
+ f4e29a3310767e3b
+ 8b38bc1b276ce2ba
+ 9bf1b49df1e120a3
+ 20ecc9dffb68416f
+ 11729ad878ad3bdf
+ d0b4db2626b620d7
+ 8e0604e4393c66a3
+
+ AES_KEY :=
+ afefd21a087a150d
+ 6757741a4eda02a5
+ 65df7ca86ba44b21
+ 3f8106c0071eaf01
+
+ AES_IV :=
+ a808b929bc9fad7a
+ 686bbe3432bed77a
+
+ TWOFISH_KEY :=
+ c9d0089df01d0bf4
+ e4c8db4b2ccc7328
+ 3425e8a811ae59d2
+ 99e2747285d2a479
+
+ TWOFISH_IV :=
+ 071be189a9d236f9
+ b4a3654bb8c281d4
+
+ RDATA :=
+ 0000000100059412 RR COUNT | EXPIRA-
+ 09ddea0f00000014 -TION | DATA SIZE (20)
+ 0000000f00000000 TYPE (15=MX) | FLAGS (0)
+ 000a046d61696c07 Priority (10) |4 | mail | 7
+ 6578616d706c6503 example | 3
+ 636f6d0000000000 com | \0 | Followed by
+ 0000000000000000 24 bytes of padding to 2^6
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
Internet-Draft The GNU Name System July 2019
- 0000000000000000 24 bytes of padding to 2^6
- 0000000000000000
- 00000000
-
-
- BLOCK :=
- 055cb070e05fe6de SIGNATURE
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54
- 07e731a34680ee33
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46____________
- 8cb514a56c0eaae0 zk_h
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291____________
- 000000540000000f SIZE (=84) | PURPOSE (=15)
- 0005941209dde25b EXPIRATION
- d99d08fa123da096 BDATA
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
+ 0000000000000000
+ 00000000
+
+
+ BLOCK :=
+ 055cb070e05fe6de SIGNATURE
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46____________
+ 8cb514a56c0eaae0 zk_h
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291____________
+ 000000540000000f SIZE (=84) | PURPOSE (=15)
+ 0005941209dde25b EXPIRATION
+ d99d08fa123da096 BDATA
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
11. Normative References
@@ -893,7 +948,8 @@ Internet-Draft The GNU Name System July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
Internet-Draft The GNU Name System July 2019
@@ -949,7 +1005,7 @@ Authors' Addresses
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
+Schanzenbach, et al. Expires 24 January 2020 [Page 18]
Internet-Draft The GNU Name System July 2019
@@ -1005,4 +1061,4 @@ Internet-Draft The GNU Name System July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
+Schanzenbach, et al. Expires 24 January 2020 [Page 19]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -752,258 +752,306 @@
<section anchor="entry_zone" numbered="true" toc="default">
<name>Entry Zone</name>
<t>
- There are three sources from which the entry zone can be determined:
+ There are three sources from which the entry zone can be determined
+ which MUST be queried in this order:
</t>
- <ul>
- <li>Local zone store</li>
- <li>External prefix to zone key mappings</li>
- <li>Zone key TLD</li>
- </ul>
+ <ol>
+ <li>Check if top-level domain maps to a local zone key.</li>
+ <li>Check if top-level domain maps to a local zone name.</li>
+ <li>Check if a configuration exists that maps a prefix to an
+ external zone key.</li>
+ </ol>
+ <t>
+ If the TLD is a Base32-encoded public zone key "zk", the entry
+ zone of the resolution process is implicitly given by the name.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Example name: www.example.<Base32(zk)>
+ => Entry zone: zk
+ => Name to resolve from entry zone: www.example
+ ]]></artwork>
+
+ <t>
+ Each local zone is associated with a single GNS label. If this label
+ is the top-level domain (TLD) of the name to resolve, resolution
+ MUST start from this local zone.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Example name: www.example.gnu
+ Local zones:
+ fr = (d0,zk0)
+ gnu = (d1,zk1)
+ com = (d2,zk2)
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www.example
+ ]]></artwork>
+
+ <t>
+ If no matching local zone for the TLD is found, external prefix to
+ zone mappings are checked. External prefix to zone key mapping
+ SHOULD be configurable through the GNS implementation. A mapping
+ has the form "prefix = public zone key".
+ The prefix may consist of multiple GNS labels concatenated with a
+ ".". If multiple prefixes match the name to resolve, the longest
+ prefix is chosen. The prefix length of two results cannot be equal,
+ as this would indicate a misconfiguration.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Example name: www.example.gnu
+ Local prefix mappings:
+ gnu = zk0
+ example.gnu = zk1
+ example.com = zk2
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www
+ ]]></artwork>
+ </section>
+ <section anchor="recursion" numbered="true" toc="default">
+ <name>Recursive Resolution</name>
+ </section>
+
</section>
- <section anchor="recursion" numbered="true" toc="default">
- <name>Recursive Resolution</name>
+ <section anchor="revocation" numbered="true" toc="default">
+ <name>Namespace Revocation</name>
+ <t>
+ TODO
+ </t>
</section>
+ <section anchor="security" numbered="true" toc="default">
+ <name>Security Considerations</name>
+ <t>
+ TODO
+ </t>
+ </section>
+ <section anchor="iana" numbered="true" toc="default">
+ <name>IANA Considerations</name>
+ <t>
+ This will be fun
+ </t>
+ </section>
+ <!-- iana -->
+ <section>
+ <name>Test Vectors</name>
+ <t>
+ The following represents a test vector for a record of type MX with
+ a priority of 10 and the mail hostname mail.example.com.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ label := "mail"
- </section>
- <section anchor="revocation" numbered="true" toc="default">
- <name>Namespace Revocation</name>
- <t>
- TODO
- </t>
- </section>
- <section anchor="security" numbered="true" toc="default">
- <name>Security Considerations</name>
- <t>
- TODO
- </t>
- </section>
- <section anchor="iana" numbered="true" toc="default">
- <name>IANA Considerations</name>
- <t>
- This will be fun
- </t>
- </section>
- <!-- iana -->
- <section>
- <name>Test Vectors</name>
- <t>
- The following represents a test vector for a record of type MX with
- a priority of 10 and the mail hostname mail.example.com.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- label := "mail"
-
- d :=
- 71199f7b287cc77a
- 0d21b5e40a77cb1d
- f89333903b284fe8
- 1878bf47f3b39da0
+ d :=
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
- zk (public zone key) :=
- dff911496d025d7e
- 0885c03d19153e99
- 4f213f23ea719eca
- 17fc32dc410e082e
+ zk (public zone key) :=
+ dff911496d025d7e
+ 0885c03d19153e99
+ 4f213f23ea719eca
+ 17fc32dc410e082e
- h :=
- 2af3275a9cf90e54
- f2dbf7930be76fb9
- 5e7c80b1416f8ca6
- dc50ce8e1fb759b9
- fedcdcf546c17e9b
- 4c4f23632855c053
- 6668e9f684f4dc33
- 6d656b27392b0fee
+ h :=
+ 2af3275a9cf90e54
+ f2dbf7930be76fb9
+ 5e7c80b1416f8ca6
+ dc50ce8e1fb759b9
+ fedcdcf546c17e9b
+ 4c4f23632855c053
+ 6668e9f684f4dc33
+ 6d656b27392b0fee
- d_h :=
- 01fb61f482c17633
- 77611c4c2509e0f3
- 81b0e7e4405c10bd
- 0017c802f7d32e18
+ d_h :=
+ 01fb61f482c17633
+ 77611c4c2509e0f3
+ 81b0e7e4405c10bd
+ 0017c802f7d32e18
- q (query key) :=
- 6fce4deddc5ad681
- f4e29a3310767e3b
- 8b38bc1b276ce2ba
- 9bf1b49df1e120a3
- 20ecc9dffb68416f
- 11729ad878ad3bdf
- d0b4db2626b620d7
- 8e0604e4393c66a3
+ q (query key) :=
+ 6fce4deddc5ad681
+ f4e29a3310767e3b
+ 8b38bc1b276ce2ba
+ 9bf1b49df1e120a3
+ 20ecc9dffb68416f
+ 11729ad878ad3bdf
+ d0b4db2626b620d7
+ 8e0604e4393c66a3
- AES_KEY :=
- afefd21a087a150d
- 6757741a4eda02a5
- 65df7ca86ba44b21
- 3f8106c0071eaf01
+ AES_KEY :=
+ afefd21a087a150d
+ 6757741a4eda02a5
+ 65df7ca86ba44b21
+ 3f8106c0071eaf01
- AES_IV :=
- a808b929bc9fad7a
- 686bbe3432bed77a
+ AES_IV :=
+ a808b929bc9fad7a
+ 686bbe3432bed77a
- TWOFISH_KEY :=
- c9d0089df01d0bf4
- e4c8db4b2ccc7328
- 3425e8a811ae59d2
- 99e2747285d2a479
+ TWOFISH_KEY :=
+ c9d0089df01d0bf4
+ e4c8db4b2ccc7328
+ 3425e8a811ae59d2
+ 99e2747285d2a479
- TWOFISH_IV :=
- 071be189a9d236f9
- b4a3654bb8c281d4
+ TWOFISH_IV :=
+ 071be189a9d236f9
+ b4a3654bb8c281d4
- RDATA :=
- 0000000100059412 RR COUNT | EXPIRA-
- 09ddea0f00000014 -TION | DATA SIZE (20)
- 0000000f00000000 TYPE (15=MX) | FLAGS (0)
- 000a046d61696c07 Priority (10) |4 | mail | 7
- 6578616d706c6503 example | 3
- 636f6d0000000000 com | \0 | Followed by
- 0000000000000000 24 bytes of padding to 2^6
- 0000000000000000
- 00000000
+ RDATA :=
+ 0000000100059412 RR COUNT | EXPIRA-
+ 09ddea0f00000014 -TION | DATA SIZE (20)
+ 0000000f00000000 TYPE (15=MX) | FLAGS (0)
+ 000a046d61696c07 Priority (10) |4 | mail | 7
+ 6578616d706c6503 example | 3
+ 636f6d0000000000 com | \0 | Followed by
+ 0000000000000000 24 bytes of padding to 2^6
+ 0000000000000000
+ 00000000
- BLOCK :=
- 055cb070e05fe6de SIGNATURE
- ad694a50e5b4dedd
- b9fdcbdbae004f65
- afc99ba9c5a3bb54
- 07e731a34680ee33
- ae0de7bfeda7d2b7
- 8c6b854a008b1b54
- 10df4f39f5ba9f46____________
- 8cb514a56c0eaae0 zk_h
- 56745158a63ee4dd
- 76853cb9545e326e
- 76d7fa920f818291____________
- 000000540000000f SIZE (=84) | PURPOSE (=15)
- 0005941209dde25b EXPIRATION
- d99d08fa123da096 BDATA
- 66c2fb9bf020a85d
- e80818d0a84059a8
- 5eee901a66459e5e
- 3d1a10b29a5b8354
- 1b58636781166b9a
- 642920eee8e7a65a
- 001fd19a6406a721
- 713f0a0d
- ]]></artwork>
+ BLOCK :=
+ 055cb070e05fe6de SIGNATURE
+ ad694a50e5b4dedd
+ b9fdcbdbae004f65
+ afc99ba9c5a3bb54
+ 07e731a34680ee33
+ ae0de7bfeda7d2b7
+ 8c6b854a008b1b54
+ 10df4f39f5ba9f46____________
+ 8cb514a56c0eaae0 zk_h
+ 56745158a63ee4dd
+ 76853cb9545e326e
+ 76d7fa920f818291____________
+ 000000540000000f SIZE (=84) | PURPOSE (=15)
+ 0005941209dde25b EXPIRATION
+ d99d08fa123da096 BDATA
+ 66c2fb9bf020a85d
+ e80818d0a84059a8
+ 5eee901a66459e5e
+ 3d1a10b29a5b8354
+ 1b58636781166b9a
+ 642920eee8e7a65a
+ 001fd19a6406a721
+ 713f0a0d
+ ]]></artwork>
- </section>
- </middle>
- <back>
- <references>
- <name>Normative References</name>
- <reference anchor="RFC3492" target="https://www.rfc-editor.org/info/rfc3492"><front><title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title><author initials="A." surname="Costello" fullname="A. Costello"><organization/></author><date year="2003" month="March"/><abstract><t>Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3492"/><seriesInfo name="DOI" value="10.17487/RFC3492"/></reference>
- <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748"><front><title>Elliptic Curves for Security</title><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><author initials="M." surname="Hamburg" fullname="M. Hamburg"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2016" month="January"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="RFC" value="7748"/><seriesInfo name="DOI" value="10.17487/RFC7748"/></reference>
- <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826"><front><title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title><author initials="U." surname="Blumenthal" fullname="U. Blumenthal"><organization/></author><author initials="F." surname="Maino" fullname="F. Maino"><organization/></author><author initials="K." surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date year="2004" month="June"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
- <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
- <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
- <front>
- <title>
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
- </title>
- <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
- <organization/>
- </author>
- <author initials="P." surname="Eronen" fullname="P. Eronen">
- <organization/>
- </author>
- <date year="2010" month="May"/>
- <abstract>
- <t>
- This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="5869"/>
- <seriesInfo name="DOI" value="10.17487/RFC5869"/>
- </reference>
- <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><seriesInfo name="DOI" value="10.17487/RFC3629"/>
- </reference>
- <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
- <front>
- <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
- <author initials="S." surname="Josefsson" fullname="S. Josefsson">
- <organization/>
- </author>
- <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
- <organization/>
- </author>
- <date year="2017" month="January"/>
- <abstract>
- <t>
- This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="8032"/>
- <seriesInfo name="DOI" value="10.17487/RFC8032"/>
- </reference>
- <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013" month="April"/><abstract><t>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6895"/><seriesInfo name="DOI" value="10.17487/RFC6895"/></reference>
- <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"><front><title>Domain names - concepts and facilities</title><author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"><organization/></author><date year="1987" month="November"/><abstract><t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1034"/><seriesInfo name="DOI" value="10.17487/RFC1034"/></reference>
- <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
- <front>
- <title>Domain names - implementation and specification</title>
- <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
- <organization/>
- </author>
- <date year="1987" month="November"/>
- <abstract>
- <t>
- This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
- </t>
- </abstract>
- </front>
- <seriesInfo name="STD" value="13"/>
- <seriesInfo name="RFC" value="1035"/>
- <seriesInfo name="DOI" value="10.17487/RFC1035"/>
- </reference>
- <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
- <front>
- <title>
- Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
- </title>
- <author initials="T." surname="Pornin" fullname="T. Pornin">
- <organization/>
- </author>
- <date year="2013" month="August"/>
- <abstract>
- <t>
- This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="6979"/>
- <seriesInfo name="DOI" value="10.17487/RFC6979"/>
- </reference>
- <reference anchor="TWOFISH">
- <front>
- <title>
- The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
- </title>
- <author initials="B." surname="Schneier" fullname="B. Schneier">
- <organization/>
- </author>
- <date year="1999" month="March"/>
- </front>
- </reference>
+ </section>
+ </middle>
+ <back>
+ <references>
+ <name>Normative References</name>
+ <reference anchor="RFC3492" target="https://www.rfc-editor.org/info/rfc3492"><front><title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title><author initials="A." surname="Costello" fullname="A. Costello"><organization/></author><date year="2003" month="March"/><abstract><t>Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3492"/><seriesInfo name="DOI" value="10.17487/RFC3492"/></reference>
+ <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748"><front><title>Elliptic Curves for Security</title><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><author initials="M." surname="Hamburg" fullname="M. Hamburg"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2016" month="January"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="RFC" value="7748"/><seriesInfo name="DOI" value="10.17487/RFC7748"/></reference>
+ <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826"><front><title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title><author initials="U." surname="Blumenthal" fullname="U. Blumenthal"><organization/></author><author initials="F." surname="Maino" fullname="F. Maino"><organization/></author><author initials="K." surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date year="2004" month="June"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
+ <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
+ <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
+ <front>
+ <title>
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ </title>
+ <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
+ <organization/>
+ </author>
+ <author initials="P." surname="Eronen" fullname="P. Eronen">
+ <organization/>
+ </author>
+ <date year="2010" month="May"/>
+ <abstract>
+ <t>
+ This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="5869"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5869"/>
+ </reference>
+ <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><seriesInfo name="DOI" value="10.17487/RFC3629"/>
+ </reference>
+ <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
+ <front>
+ <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
+ <author initials="S." surname="Josefsson" fullname="S. Josefsson">
+ <organization/>
+ </author>
+ <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
+ <organization/>
+ </author>
+ <date year="2017" month="January"/>
+ <abstract>
+ <t>
+ This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="8032"/>
+ <seriesInfo name="DOI" value="10.17487/RFC8032"/>
+ </reference>
+ <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013" month="April"/><abstract><t>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6895"/><seriesInfo name="DOI" value="10.17487/RFC6895"/></reference>
+ <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"><front><title>Domain names - concepts and facilities</title><author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"><organization/></author><date year="1987" month="November"/><abstract><t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1034"/><seriesInfo name="DOI" value="10.17487/RFC1034"/></reference>
+ <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
+ <front>
+ <title>Domain names - implementation and specification</title>
+ <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
+ <organization/>
+ </author>
+ <date year="1987" month="November"/>
+ <abstract>
+ <t>
+ This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="STD" value="13"/>
+ <seriesInfo name="RFC" value="1035"/>
+ <seriesInfo name="DOI" value="10.17487/RFC1035"/>
+ </reference>
+ <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
+ <front>
+ <title>
+ Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
+ </title>
+ <author initials="T." surname="Pornin" fullname="T. Pornin">
+ <organization/>
+ </author>
+ <date year="2013" month="August"/>
+ <abstract>
+ <t>
+ This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
+ </t>
+ </abstract>
+ </front>
+ <seriesInfo name="RFC" value="6979"/>
+ <seriesInfo name="DOI" value="10.17487/RFC6979"/>
+ </reference>
+ <reference anchor="TWOFISH">
+ <front>
+ <title>
+ The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
+ </title>
+ <author initials="B." surname="Schneier" fullname="B. Schneier">
+ <organization/>
+ </author>
+ <date year="1999" month="March"/>
+ </front>
+ </reference>
- <!-- <reference anchor="ISO20022">
- <front>
- <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
- <author>
- <organization>International Organization for Standardization</organization>
- <address>
- <uri>http://www.iso.ch</uri>
- </address>
- </author>
- <date month="May" year="2013"/>
- </front>
- </reference>-->
- </references>
- <!-- Change Log
- v00 2017-07-23 MS Initial version
- -->
- </back>
-</rfc>
+ <!-- <reference anchor="ISO20022">
+ <front>
+ <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
+ <author>
+ <organization>International Organization for Standardization</organization>
+ <address>
+ <uri>http://www.iso.ch</uri>
+ </address>
+ </author>
+ <date month="May" year="2013"/>
+ </front>
+ </reference>-->
+ </references>
+ <!-- Change Log
+ v00 2017-07-23 MS Initial version
+ -->
+ </back>
+ </rfc>
