aboutsummaryrefslogtreecommitdiff
path: root/draft-schanzen-gns.xml
diff options
context:
space:
mode:
Diffstat (limited to 'draft-schanzen-gns.xml')
-rw-r--r--draft-schanzen-gns.xml524
1 files changed, 286 insertions, 238 deletions
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index ce74c57..c00ad89 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -752,258 +752,306 @@
752 <section anchor="entry_zone" numbered="true" toc="default"> 752 <section anchor="entry_zone" numbered="true" toc="default">
753 <name>Entry Zone</name> 753 <name>Entry Zone</name>
754 <t> 754 <t>
755 There are three sources from which the entry zone can be determined: 755 There are three sources from which the entry zone can be determined
756 which MUST be queried in this order:
756 </t> 757 </t>
757 <ul> 758 <ol>
758 <li>Local zone store</li> 759 <li>Check if top-level domain maps to a local zone key.</li>
759 <li>External prefix to zone key mappings</li> 760 <li>Check if top-level domain maps to a local zone name.</li>
760 <li>Zone key TLD</li> 761 <li>Check if a configuration exists that maps a prefix to an
761 </ul> 762 external zone key.</li>
763 </ol>
764 <t>
765 If the TLD is a Base32-encoded public zone key "zk", the entry
766 zone of the resolution process is implicitly given by the name.
767 </t>
768 <artwork name="" type="" align="left" alt=""><![CDATA[
769 Example name: www.example.<Base32(zk)>
770 => Entry zone: zk
771 => Name to resolve from entry zone: www.example
772 ]]></artwork>
773
774 <t>
775 Each local zone is associated with a single GNS label. If this label
776 is the top-level domain (TLD) of the name to resolve, resolution
777 MUST start from this local zone.
778 </t>
779 <artwork name="" type="" align="left" alt=""><![CDATA[
780 Example name: www.example.gnu
781 Local zones:
782 fr = (d0,zk0)
783 gnu = (d1,zk1)
784 com = (d2,zk2)
785 ...
786 => Entry zone: zk1
787 => Name to resolve from entry zone: www.example
788 ]]></artwork>
789
790 <t>
791 If no matching local zone for the TLD is found, external prefix to
792 zone mappings are checked. External prefix to zone key mapping
793 SHOULD be configurable through the GNS implementation. A mapping
794 has the form "prefix = public zone key".
795 The prefix may consist of multiple GNS labels concatenated with a
796 ".". If multiple prefixes match the name to resolve, the longest
797 prefix is chosen. The prefix length of two results cannot be equal,
798 as this would indicate a misconfiguration.
799 </t>
800 <artwork name="" type="" align="left" alt=""><![CDATA[
801 Example name: www.example.gnu
802 Local prefix mappings:
803 gnu = zk0
804 example.gnu = zk1
805 example.com = zk2
806 ...
807 => Entry zone: zk1
808 => Name to resolve from entry zone: www
809 ]]></artwork>
810 </section>
811 <section anchor="recursion" numbered="true" toc="default">
812 <name>Recursive Resolution</name>
813 </section>
814
762 </section> 815 </section>
763 <section anchor="recursion" numbered="true" toc="default"> 816 <section anchor="revocation" numbered="true" toc="default">
764 <name>Recursive Resolution</name> 817 <name>Namespace Revocation</name>
818 <t>
819 TODO
820 </t>
765 </section> 821 </section>
822 <section anchor="security" numbered="true" toc="default">
823 <name>Security Considerations</name>
824 <t>
825 TODO
826 </t>
827 </section>
828 <section anchor="iana" numbered="true" toc="default">
829 <name>IANA Considerations</name>
830 <t>
831 This will be fun
832 </t>
833 </section>
834 <!-- iana -->
835 <section>
836 <name>Test Vectors</name>
837 <t>
838 The following represents a test vector for a record of type MX with
839 a priority of 10 and the mail hostname mail.example.com.
840 </t>
841 <artwork name="" type="" align="left" alt=""><![CDATA[
842 label := "mail"
766 843
767 </section> 844 d :=
768 <section anchor="revocation" numbered="true" toc="default"> 845 71199f7b287cc77a
769 <name>Namespace Revocation</name> 846 0d21b5e40a77cb1d
770 <t> 847 f89333903b284fe8
771 TODO 848 1878bf47f3b39da0
772 </t>
773 </section>
774 <section anchor="security" numbered="true" toc="default">
775 <name>Security Considerations</name>
776 <t>
777 TODO
778 </t>
779 </section>
780 <section anchor="iana" numbered="true" toc="default">
781 <name>IANA Considerations</name>
782 <t>
783 This will be fun
784 </t>
785 </section>
786 <!-- iana -->
787 <section>
788 <name>Test Vectors</name>
789 <t>
790 The following represents a test vector for a record of type MX with
791 a priority of 10 and the mail hostname mail.example.com.
792 </t>
793 <artwork name="" type="" align="left" alt=""><![CDATA[
794 label := "mail"
795
796 d :=
797 71199f7b287cc77a
798 0d21b5e40a77cb1d
799 f89333903b284fe8
800 1878bf47f3b39da0
801 849
802 zk (public zone key) := 850 zk (public zone key) :=
803 dff911496d025d7e 851 dff911496d025d7e
804 0885c03d19153e99 852 0885c03d19153e99
805 4f213f23ea719eca 853 4f213f23ea719eca
806 17fc32dc410e082e 854 17fc32dc410e082e
807 855
808 h := 856 h :=
809 2af3275a9cf90e54 857 2af3275a9cf90e54
810 f2dbf7930be76fb9 858 f2dbf7930be76fb9
811 5e7c80b1416f8ca6 859 5e7c80b1416f8ca6
812 dc50ce8e1fb759b9 860 dc50ce8e1fb759b9
813 fedcdcf546c17e9b 861 fedcdcf546c17e9b
814 4c4f23632855c053 862 4c4f23632855c053
815 6668e9f684f4dc33 863 6668e9f684f4dc33
816 6d656b27392b0fee 864 6d656b27392b0fee
817 865
818 d_h := 866 d_h :=
819 01fb61f482c17633 867 01fb61f482c17633
820 77611c4c2509e0f3 868 77611c4c2509e0f3
821 81b0e7e4405c10bd 869 81b0e7e4405c10bd
822 0017c802f7d32e18 870 0017c802f7d32e18
823 871
824 q (query key) := 872 q (query key) :=
825 6fce4deddc5ad681 873 6fce4deddc5ad681
826 f4e29a3310767e3b 874 f4e29a3310767e3b
827 8b38bc1b276ce2ba 875 8b38bc1b276ce2ba
828 9bf1b49df1e120a3 876 9bf1b49df1e120a3
829 20ecc9dffb68416f 877 20ecc9dffb68416f
830 11729ad878ad3bdf 878 11729ad878ad3bdf
831 d0b4db2626b620d7 879 d0b4db2626b620d7
832 8e0604e4393c66a3 880 8e0604e4393c66a3
833 881
834 AES_KEY := 882 AES_KEY :=
835 afefd21a087a150d 883 afefd21a087a150d
836 6757741a4eda02a5 884 6757741a4eda02a5
837 65df7ca86ba44b21 885 65df7ca86ba44b21
838 3f8106c0071eaf01 886 3f8106c0071eaf01
839 887
840 AES_IV := 888 AES_IV :=
841 a808b929bc9fad7a 889 a808b929bc9fad7a
842 686bbe3432bed77a 890 686bbe3432bed77a
843 891
844 TWOFISH_KEY := 892 TWOFISH_KEY :=
845 c9d0089df01d0bf4 893 c9d0089df01d0bf4
846 e4c8db4b2ccc7328 894 e4c8db4b2ccc7328
847 3425e8a811ae59d2 895 3425e8a811ae59d2
848 99e2747285d2a479 896 99e2747285d2a479
849 897
850 TWOFISH_IV := 898 TWOFISH_IV :=
851 071be189a9d236f9 899 071be189a9d236f9
852 b4a3654bb8c281d4 900 b4a3654bb8c281d4
853 901
854 RDATA := 902 RDATA :=
855 0000000100059412 RR COUNT | EXPIRA- 903 0000000100059412 RR COUNT | EXPIRA-
856 09ddea0f00000014 -TION | DATA SIZE (20) 904 09ddea0f00000014 -TION | DATA SIZE (20)
857 0000000f00000000 TYPE (15=MX) | FLAGS (0) 905 0000000f00000000 TYPE (15=MX) | FLAGS (0)
858 000a046d61696c07 Priority (10) |4 | mail | 7 906 000a046d61696c07 Priority (10) |4 | mail | 7
859 6578616d706c6503 example | 3 907 6578616d706c6503 example | 3
860 636f6d0000000000 com | \0 | Followed by 908 636f6d0000000000 com | \0 | Followed by
861 0000000000000000 24 bytes of padding to 2^6 909 0000000000000000 24 bytes of padding to 2^6
862 0000000000000000 910 0000000000000000
863 00000000 911 00000000
864 912
865 913
866 BLOCK := 914 BLOCK :=
867 055cb070e05fe6de SIGNATURE 915 055cb070e05fe6de SIGNATURE
868 ad694a50e5b4dedd 916 ad694a50e5b4dedd
869 b9fdcbdbae004f65 917 b9fdcbdbae004f65
870 afc99ba9c5a3bb54 918 afc99ba9c5a3bb54
871 07e731a34680ee33 919 07e731a34680ee33
872 ae0de7bfeda7d2b7 920 ae0de7bfeda7d2b7
873 8c6b854a008b1b54 921 8c6b854a008b1b54
874 10df4f39f5ba9f46____________ 922 10df4f39f5ba9f46____________
875 8cb514a56c0eaae0 zk_h 923 8cb514a56c0eaae0 zk_h
876 56745158a63ee4dd 924 56745158a63ee4dd
877 76853cb9545e326e 925 76853cb9545e326e
878 76d7fa920f818291____________ 926 76d7fa920f818291____________
879 000000540000000f SIZE (=84) | PURPOSE (=15) 927 000000540000000f SIZE (=84) | PURPOSE (=15)
880 0005941209dde25b EXPIRATION 928 0005941209dde25b EXPIRATION
881 d99d08fa123da096 BDATA 929 d99d08fa123da096 BDATA
882 66c2fb9bf020a85d 930 66c2fb9bf020a85d
883 e80818d0a84059a8 931 e80818d0a84059a8
884 5eee901a66459e5e 932 5eee901a66459e5e
885 3d1a10b29a5b8354 933 3d1a10b29a5b8354
886 1b58636781166b9a 934 1b58636781166b9a
887 642920eee8e7a65a 935 642920eee8e7a65a
888 001fd19a6406a721 936 001fd19a6406a721
889 713f0a0d 937 713f0a0d
890 ]]></artwork> 938 ]]></artwork>
891 939
892 </section> 940 </section>
893 </middle> 941 </middle>
894 <back> 942 <back>
895 <references> 943 <references>
896 <name>Normative References</name> 944 <name>Normative References</name>
897 <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> 945 <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>
898 <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> 946 <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>
899 <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> 947 <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>
900 <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> 948 <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>
901 <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869"> 949 <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
902 <front> 950 <front>
903 <title> 951 <title>
904 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) 952 HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
905 </title> 953 </title>
906 <author initials="H." surname="Krawczyk" fullname="H. Krawczyk"> 954 <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
907 <organization/> 955 <organization/>
908 </author> 956 </author>
909 <author initials="P." surname="Eronen" fullname="P. Eronen"> 957 <author initials="P." surname="Eronen" fullname="P. Eronen">
910 <organization/> 958 <organization/>
911 </author> 959 </author>
912 <date year="2010" month="May"/> 960 <date year="2010" month="May"/>
913 <abstract> 961 <abstract>
914 <t> 962 <t>
915 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. 963 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.
916 </t> 964 </t>
917 </abstract> 965 </abstract>
918 </front> 966 </front>
919 <seriesInfo name="RFC" value="5869"/> 967 <seriesInfo name="RFC" value="5869"/>
920 <seriesInfo name="DOI" value="10.17487/RFC5869"/> 968 <seriesInfo name="DOI" value="10.17487/RFC5869"/>
921 </reference> 969 </reference>
922 <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"/> 970 <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"/>
923 </reference> 971 </reference>
924 <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032"> 972 <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
925 <front> 973 <front>
926 <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title> 974 <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
927 <author initials="S." surname="Josefsson" fullname="S. Josefsson"> 975 <author initials="S." surname="Josefsson" fullname="S. Josefsson">
928 <organization/> 976 <organization/>
929 </author> 977 </author>
930 <author initials="I." surname="Liusvaara" fullname="I. Liusvaara"> 978 <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
931 <organization/> 979 <organization/>
932 </author> 980 </author>
933 <date year="2017" month="January"/> 981 <date year="2017" month="January"/>
934 <abstract> 982 <abstract>
935 <t> 983 <t>
936 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. 984 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.
937 </t> 985 </t>
938 </abstract> 986 </abstract>
939 </front> 987 </front>
940 <seriesInfo name="RFC" value="8032"/> 988 <seriesInfo name="RFC" value="8032"/>
941 <seriesInfo name="DOI" value="10.17487/RFC8032"/> 989 <seriesInfo name="DOI" value="10.17487/RFC8032"/>
942 </reference> 990 </reference>
943 <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> 991 <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>
944 <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> 992 <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>
945 <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035"> 993 <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
946 <front> 994 <front>
947 <title>Domain names - implementation and specification</title> 995 <title>Domain names - implementation and specification</title>
948 <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"> 996 <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
949 <organization/> 997 <organization/>
950 </author> 998 </author>
951 <date year="1987" month="November"/> 999 <date year="1987" month="November"/>
952 <abstract> 1000 <abstract>
953 <t> 1001 <t>
954 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. 1002 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.
955 </t> 1003 </t>
956 </abstract> 1004 </abstract>
957 </front> 1005 </front>
958 <seriesInfo name="STD" value="13"/> 1006 <seriesInfo name="STD" value="13"/>
959 <seriesInfo name="RFC" value="1035"/> 1007 <seriesInfo name="RFC" value="1035"/>
960 <seriesInfo name="DOI" value="10.17487/RFC1035"/> 1008 <seriesInfo name="DOI" value="10.17487/RFC1035"/>
961 </reference> 1009 </reference>
962 <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979"> 1010 <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
963 <front> 1011 <front>
964 <title> 1012 <title>
965 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) 1013 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
966 </title> 1014 </title>
967 <author initials="T." surname="Pornin" fullname="T. Pornin"> 1015 <author initials="T." surname="Pornin" fullname="T. Pornin">
968 <organization/> 1016 <organization/>
969 </author> 1017 </author>
970 <date year="2013" month="August"/> 1018 <date year="2013" month="August"/>
971 <abstract> 1019 <abstract>
972 <t> 1020 <t>
973 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. 1021 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.
974 </t> 1022 </t>
975 </abstract> 1023 </abstract>
976 </front> 1024 </front>
977 <seriesInfo name="RFC" value="6979"/> 1025 <seriesInfo name="RFC" value="6979"/>
978 <seriesInfo name="DOI" value="10.17487/RFC6979"/> 1026 <seriesInfo name="DOI" value="10.17487/RFC6979"/>
979 </reference> 1027 </reference>
980 <reference anchor="TWOFISH"> 1028 <reference anchor="TWOFISH">
981 <front> 1029 <front>
982 <title> 1030 <title>
983 The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition 1031 The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
984 </title> 1032 </title>
985 <author initials="B." surname="Schneier" fullname="B. Schneier"> 1033 <author initials="B." surname="Schneier" fullname="B. Schneier">
986 <organization/> 1034 <organization/>
987 </author> 1035 </author>
988 <date year="1999" month="March"/> 1036 <date year="1999" month="March"/>
989 </front> 1037 </front>
990 </reference> 1038 </reference>
991 1039
992 <!-- <reference anchor="ISO20022"> 1040 <!-- <reference anchor="ISO20022">
993 <front> 1041 <front>
994 <title>ISO 20022 Financial Services - Universal financial industry message scheme</title> 1042 <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
995 <author> 1043 <author>
996 <organization>International Organization for Standardization</organization> 1044 <organization>International Organization for Standardization</organization>
997 <address> 1045 <address>
998 <uri>http://www.iso.ch</uri> 1046 <uri>http://www.iso.ch</uri>
999 </address> 1047 </address>
1000 </author> 1048 </author>
1001 <date month="May" year="2013"/> 1049 <date month="May" year="2013"/>
1002 </front> 1050 </front>
1003 </reference>--> 1051 </reference>-->
1004 </references> 1052 </references>
1005 <!-- Change Log 1053 <!-- Change Log
1006 v00 2017-07-23 MS Initial version 1054 v00 2017-07-23 MS Initial version
1007 --> 1055 -->
1008 </back> 1056 </back>
1009</rfc> 1057 </rfc>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-26 14:59:55 +0000