commit e5ebe17c915c48d9466790fb76ef4785f9140f1e
parent 84874958e6f66485f4912ad4274daf5d7ce85a6e
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Tue, 10 Sep 2019 14:17:32 +0200
update
Diffstat:
2 files changed, 447 insertions(+), 211 deletions(-)
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -61,19 +61,19 @@ Internet-Draft The GNU Name System July 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. GNS resource records . . . . . . . . . . . . . . . . . . . . 2
- 2.1. GNS record blocks . . . . . . . . . . . . . . . . . . . . 2
- 2.1.1. GNS record block data cryptography . . . . . . . . . 3
- 2.2. GNS records . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.4. Serialization format . . . . . . . . . . . . . . . . . . 5
- 2.5. Internationalization and Character Encoding . . . . . . . 5
- 2.6. Security Considerations . . . . . . . . . . . . . . . . . 5
- 3. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 6
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
- 6. Normative References . . . . . . . . . . . . . . . . . . . . 6
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Resource records . . . . . . . . . . . . . . . . . . . . . . 2
+ 3.1. GNS-specific resource record types . . . . . . . . . . . 3
+ 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 4
+ 4.1. Resource records block . . . . . . . . . . . . . . . . . 4
+ 4.1.1. Block data encryption . . . . . . . . . . . . . . . . 6
+ 4.2. Internationalization and Character Encoding . . . . . . . 7
+ 4.3. Security Considerations . . . . . . . . . . . . . . . . . 7
+ 5. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 7
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 8. Normative References . . . . . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
@@ -86,20 +86,20 @@ Table of Contents
considerations for use by implementors.
-2. GNS resource records
-
-2.1. GNS record blocks
-
- TODO
-
- A GNS record block has the following format:
-
-
-
-
+2. Zones
+ A zone in GNS is defined by a public/private ECC key pair (x,y),
+ where x is the private key and y the public key. The keys are
+ constructed using the Curve25519 ECC scheme as defined in [RFC7748].
+ The schemes defines that "y := x*P". The public key is used to
+ uniquely identify and refer to the zone. Records published in the
+ zone are signed using a private key derived from the private key as
+ described in Section XX.
+3. Resource records
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record wire format is defined as follows:
@@ -114,53 +114,53 @@ Schanzenbach Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | SIGNATURE |
- | |
- | |
- | |
- | |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | BDATA SIZE | PURPOSE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- / BDATA /
- / /
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA |
+ +-----+-----+-----+-----+ |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 1
where:
- SIGNATURE The GNS record block signature.
+ EXPIRATION Denotes the absolute expiration date of the record. In
+ microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.
- PUBLIC KEY A public key which is used to verify SIGNATURE. This key
- is not the public key of the namespace.
+ DATA SIZE The resource record data length in bytes and network byte
+ order.
- BDATA SIZE The GNS record block data length.
+ TYPE The resource record type. This type can be one of the GNS
+ resource records as defined in Section XX or a DNS record type as
+ defined in [RFC1035].
- PURPOSE The signature purpose.
+ FLAGS Resource record flags. Flags are defined in Section XX.
- EXPIRATION The GNS record block expiration.
+ DATA The resource record data payload. The contents are defined by
+ the respective type of the resource record.
- BDATA The GNS record block data
+3.1. GNS-specific resource record types
-2.1.1. GNS record block data cryptography
+ The a PKEY DATA entry has the following format:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 2
- Given a GNS record block a symmetric encryption scheme is used to
- en-/decrypt "BDATA". The keys are derived from the record label "l"
- and the public key "P". Both "l" and "P" are implicity known by the
- GNS resolver. The key material "K" is derived as follows:
@@ -170,37 +170,37 @@ Schanzenbach Expires 24 January 2020 [Page 3]
Internet-Draft The GNU Name System July 2019
- h := SHA512 (l,P)
- d := h*x mod n
- K := HKDF (P,l)
+4. Publishing records
- "HKDF" is a hash-based key derivation function as defined in
- [RFC5869]. For the XTR, we use HMAC-SHA512 and HMAC-SHA256 in PRF as
- proposed in (paper). Using this HKDF, we derive two symmetric
- 256-bit keys "Ka,Kt" from "K":
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels and published
+ together in a single block in the DHT. A resource records block is
+ published under a key which is derived from the respective label of
+ the contained records. Given a label "l", the DHT key "q" is derived
+ as follows:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ h := sha512 (l,y)
+ d := h*x mod p
+ q := sha512 (d*P)
- Figure 2
+ where:
- The two symmetric keys are used for a AES+TWOFISH combined cipher:
+ h is a SHA512 hash over the label "l" and public key "y".
- RDATA := TWOFISH256(Kt, AES256(Ka, BDATA))
+ d is a private key derived from the zone key x using the hash "h".
+
+ q Is the DHT key under which the resource records block is
+ published. It is the SHA512 hash over the public key "d*P"
+ corresponding to the derived private key "d".
+
+4.1. Resource records block
+
+ GNS records are grouped by their labels are published as a single
+ block in the DHT. The contained resource records are encrypted using
+ a symmetric encryption scheme. A GNS resource records block has the
+ following format:
-2.2. GNS records
- The RDATA consist of one or more entries in the following format:
@@ -228,85 +228,172 @@ Internet-Draft The GNU Name System July 2019
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
+ | SIGNATURE |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
+ | PUBLIC KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | RDATA SIZE | TYPE |
+ | BDATA SIZE | PURPOSE |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA |
- +-----+-----+-----+-----+ |
- / /
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ / BDATA /
/ /
- | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 3
- The a PKEY DATA entry has the following format:
+ where:
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ SIGNATURE A 512-bit ECDSA signature. TODO signature creation?
- Figure 4
+ PUBLIC KEY The 256-bit ECC public key "d*P" to be used to verify
+ SIGNATURE.
-2.3. Examples
+ BDATA SIZE A 32-bit value containing the length of the encrypted
+ resource records in network byte order.
- TODO
+ PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
+ network byte order).
-2.4. Serialization format
+ EXPIRATION The resource records block expiration time. This is the
+ expiration time of the resource record contained within this block
+ with the smallest expiration time. This is a 64-bit absolute date
+ in microseconds since midnight (0 hour), January 1, 1970 in
+ network byte order.
- TODO (Is this not the same as wire format?)
+ BDATA The encrypted resource records with a total size of "BDATA
+ SIZE".
-2.5. Internationalization and Character Encoding
- TODO
-2.6. Security Considerations
- TODO
+Schanzenbach Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
+4.1.1. Block data encryption
+ Given a GNS record block a symmetric encryption scheme is used to
+ en-/decrypt "BDATA". The keys are derived from the record label "l"
+ and a public key "dG", where "d" is an ECDSA private key and "G" is a
+ EC generator. "d" and "dG" are derived from the public/private key
+ pair "x,P" of a GNS zone. Both "l" and "P" are implicity known by
+ the GNS resolver. The key material "K" and initialization vector
+ "IV" are derived as follows:
-Schanzenbach Expires 24 January 2020 [Page 5]
+ h := sha512 (l,y)
+ d := h*x mod n
+ K := HKDF (dG,l,"gns-aes-ctx-key")
+ IV := HKDF (dG,l,"gns-aes-ctx-iv")
+
+ "HKDF" is a hash-based key derivation function as defined in
+ [RFC5869]. For the XTR, we use HMAC-SHA512 and HMAC-SHA256 in PRF as
+ proposed in (paper). We divide "K" into a 256-bit AES key "Kaes" and
+ a 256-bit TWOFISH key "Ktwo".
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 4
+
+ Similarly, we divide "IV" into a 128-bit initialization vector IVaes
+ and a 128-bit initialization vector IVtwo:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 5
+
+
+
+Schanzenbach Expires 24 January 2020 [Page 6]
Internet-Draft The GNU Name System July 2019
-3. Record Resolution
+ The symmetric keys and IVs are used for a AES+TWOFISH combined
+ cipher. Both ciphers are used in CFB (ref) mode.
+
+ RDATA := AES256(Kaes, IVaes, TWOFISH256(Ktwo, IVtwo, BDATA))
+ BDATA := TWOFISH256(Ktwo, IVtwo, AES256(Kaes, IVaes, RDATA))
+
+4.2. Internationalization and Character Encoding
TODO
-4. Namespace Revocation
+4.3. Security Considerations
TODO
-5. IANA Considerations
+5. Record Resolution
+
+ TODO
+
+6. Namespace Revocation
+
+ TODO
+
+7. IANA Considerations
This will be fun
-6. Normative References
+8. Normative References
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+ November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
+ [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
+ for Security", RFC 7748, DOI 10.17487/RFC7748, January
+ 2016, <https://www.rfc-editor.org/info/rfc7748>.
+
Author's Address
Martin Schanzenbach
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
+
+
+
+
+Schanzenbach Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
+
Germany
Email: schanzen@gnunet.org
@@ -333,4 +420,29 @@ Author's Address
-Schanzenbach Expires 24 January 2020 [Page 6]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach Expires 24 January 2020 [Page 8]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -53,14 +53,132 @@
</t>
</section>
+ <section anchor="zones" numbered="true" toc="default">
+ <name>Zones</name>
+ <t>
+ A zone in GNS is defined by a public/private ECC key pair (x,y), where x
+ is the private key and y the public key.
+ The keys are constructed using the Curve25519 ECC scheme as defined in
+ <xref target="RFC7748" />.
+ The schemes defines that "y := x*P".
+ The public key is used to uniquely identify and refer to the zone.
+ Records published in the zone are signed using a private key derived
+ from the private key as described in Section XX.
+ </t>
+ </section>
<section anchor="rrecords" numbered="true" toc="default">
- <name>GNS resource records</name>
+ <name>Resource records</name>
+ <t>
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record wire format is defined as follows:
+ </t>
+ <figure anchor="figure_gnsrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | EXPIRATION |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DATA SIZE | TYPE |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | FLAGS | DATA |
+ +-----+-----+-----+-----+ |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>EXPIRATION</dt>
+ <dd>
+ Denotes the absolute expiration date of the record.
+ In microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.
+ </dd>
+ <dt>DATA SIZE</dt>
+ <dd>
+ The resource record data length in bytes and network byte order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ The resource record type. This type can be one of the GNS resource
+ records as defined in Section XX or a DNS record type as defined in
+ <xref target="RFC1035" />.
+ </dd>
+ <dt>FLAGS</dt>
+ <dd>
+ Resource record flags. Flags are defined in Section XX.
+ </dd>
+ <dt>DATA</dt>
+ <dd>
+ The resource record data payload. The contents are defined by the
+ respective type of the resource record.
+ </dd>
+ </dl>
+ <section anchor="gnsrecords" numbered="true" toc="default">
+ <name>GNS-specific resource record types</name>
+
+ <t>The a PKEY DATA entry has the following format:</t>
+ <figure anchor="figure_pkeyrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PUBLIC KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ </section>
+ </section>
+
+ <section anchor="publish" numbered="true" toc="default">
+ <name>Publishing records</name>
+ <t>
+ GNS resource records are published in a distributed hash table (DHT).
+ Resource records are grouped by their respective labels and published
+ together in a single block in the DHT.
+ A resource records block is published under a key which is derived from
+ the respective label of the contained records.
+ Given a label "l", the DHT key "q" is derived as follows:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ h := sha512 (l,y)
+ d := h*x mod p
+ q := sha512 (d*P)
+ ]]></artwork>
+ <t>
+ where:
+ </t>
+ <dl>
+ <dt>h</dt>
+ <dd>
+ is a SHA512 hash over the label "l" and public key "y".
+ </dd>
+ <dt>d</dt>
+ <dd>
+ is a private key derived from the zone key x using the hash "h".
+ </dd>
+ <dt>q</dt>
+ <dd>
+ Is the DHT key under which the resource records block is published.
+ It is the SHA512 hash over the public key "d*P" corresponding to the
+ derived private key "d".
+ </dd>
+ </dl>
<section anchor="wire" numbered="true" toc="default">
- <name>GNS record blocks</name>
+ <name>Resource records block</name>
<t>
- TODO
+ GNS records are grouped by their labels are published as a single
+ block in the DHT.
+ The contained resource records are encrypted using a symmetric
+ encryption scheme.
+ A GNS resource records block has the following format:
</t>
- <t>A GNS record block has the following format:</t>
<figure anchor="figure_record_block">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
@@ -86,25 +204,43 @@
/ BDATA /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
+ ]]></artwork>
</figure>
<t>where:</t>
<dl>
<dt>SIGNATURE</dt>
- <dd>The GNS record block signature.</dd>
+ <dd>
+ A 512-bit ECDSA signature. TODO signature creation?
+ </dd>
<dt>PUBLIC KEY</dt>
- <dd>A public key which is used to verify SIGNATURE. This key is not the public key of the namespace.</dd>
+ <dd>
+ The 256-bit ECC public key "d*P" to be used to verify SIGNATURE.
+ </dd>
<dt>BDATA SIZE</dt>
- <dd>The GNS record block data length.</dd>
+ <dd>
+ A 32-bit value containing the length of the encrypted resource
+ records in network byte order.
+ </dd>
<dt>PURPOSE</dt>
- <dd>The signature purpose.</dd>
+ <dd>
+ A 32-bit signature purpose flag. This field MUST be 15 (in network
+ byte order).
+ </dd>
<dt>EXPIRATION</dt>
- <dd>The GNS record block expiration.</dd>
+ <dd>
+ The resource records block expiration time. This is the expiration
+ time of the resource record contained within this block with the
+ smallest expiration time.
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 in network byte order.
+ </dd>
<dt>BDATA</dt>
- <dd>The GNS record block data</dd>
+ <dd>
+ The encrypted resource records with a total size of "BDATA SIZE".
+ </dd>
</dl>
<section numbered="true" toc="default">
- <name>GNS record block data cryptography</name>
+ <name>Block data encryption</name>
<t>
Given a GNS record block a symmetric encryption scheme is used to
en-/decrypt "BDATA". The keys are derived from the record label "l"
@@ -116,7 +252,7 @@
are derived as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- h := SHA512 (l,P)
+ h := sha512 (l,y)
d := h*x mod n
K := HKDF (dG,l,"gns-aes-ctx-key")
IV := HKDF (dG,l,"gns-aes-ctx-iv")
@@ -127,40 +263,40 @@
HMAC-SHA256 in PRF as proposed in (paper). We divide "K" into a
256-bit AES key "Kaes" and a 256-bit TWOFISH key "Ktwo".
</t>
- <figure anchor="figure_hddf_keys">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:
- </t>
- <figure anchor="figure_hddf_keys">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
+ <figure anchor="figure_hkdf_keys">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY (Kaes) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY (Ktwo) |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <t>
+ Similarly, we divide "IV" into a 128-bit initialization vector IVaes
+ and a 128-bit initialization vector IVtwo:
+ </t>
+ <figure anchor="figure_hkdf_ivs">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES IV (IVaes) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH IV (IVtwo) |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
<t>
The symmetric keys and IVs are used for a AES+TWOFISH combined
@@ -173,57 +309,6 @@
</section>
</section>
- <section numbered="true" toc="default">
- <name>GNS records</name>
- <t>The RDATA consist of one or more entries in the following format:</t>
- <figure anchor="figure_gnsrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | EXPIRATION |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | DATA SIZE | TYPE |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | DATA |
- +-----+-----+-----+-----+ |
- / /
- / /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- <t>The a PKEY DATA entry has the following format:</t>
- <figure anchor="figure_pkeyrecord">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- <!-- <postamble>which is a very simple example.</postamble>-->
- </figure>
- </section>
- <section anchor="examples" numbered="true" toc="default">
- <name>Examples</name>
- <t>
- TODO
- </t>
- </section>
- <section anchor="serialization" numbered="true" toc="default">
- <name>Serialization format</name>
- <t>
- TODO (Is this not the same as wire format?)
- </t>
- </section>
<section anchor="encoding" numbered="true" toc="default">
<name>Internationalization and Character Encoding</name>
<t>
@@ -281,6 +366,45 @@
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</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="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="ISO20022">
<front>
<title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
