< draft-brotman-rdbd-01.txt   draft-brotman-rdbd-02.txt >
Network Working Group A. Brotman Network Working Group A. Brotman
Internet-Draft Comcast, Inc Internet-Draft Comcast, Inc
Intended status: Standards Track S. Farrell Intended status: Standards Track S. Farrell
Expires: September 7, 2019 Trinity College Dublin Expires: January 9, 2020 Trinity College Dublin
March 6, 2019 July 8, 2019
Related Domains By DNS Related Domains By DNS
draft-brotman-rdbd-01 draft-brotman-rdbd-02
Abstract Abstract
This document outlines a mechanism by which a registered domain can This document outlines a mechanism by which a DNS domain can publicly
publicly document a relationship with a different registered domain, document the existence or absence of a relationship with a different
called "Related Domains By DNS", or "RDBD". domain, called "Related Domains By DNS", or "RDBD".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. New Resource Record Types . . . . . . . . . . . . . . . . . . 4 2. New Resource Record Types . . . . . . . . . . . . . . . . . . 4
2.1. RDBDKEY Resource Record Definition . . . . . . . . . . . 4 2.1. RDBDKEY Resource Record Definition . . . . . . . . . . . 4
2.2. RDBD Resource Record Definition . . . . . . . . . . . . . 5 2.2. RDBD Resource Record Definition . . . . . . . . . . . . . 5
3. Directionality and Cardinality . . . . . . . . . . . . . . . 6 3. Directionality and Cardinality . . . . . . . . . . . . . . . 7
4. Required Signature Algorithms . . . . . . . . . . . . . . . . 6 4. Required Signature Algorithms . . . . . . . . . . . . . . . . 7
5. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Efficiacy of signatures . . . . . . . . . . . . . . . . . 7 6.1. Efficiacy of signatures . . . . . . . . . . . . . . . . . 8
6.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Lookup Loops . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Lookup Loops . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 9
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Sample Unsigned RDBD RR . . . . . . . . . . . . . . . . . 9 A.1. Unsigned Examples . . . . . . . . . . . . . . . . . . . . 10
A.2. Sample RSA Signature . . . . . . . . . . . . . . . . . . 10 A.2. RSA-signed Example . . . . . . . . . . . . . . . . . . . 11
A.3. Sample Ed25519 Signature . . . . . . . . . . . . . . . . 13 A.3. Ed25519-signed Example . . . . . . . . . . . . . . . . . 13
Appendix B. Changes and Open Issues . . . . . . . . . . . . . . 15 Appendix B. Ed25519 Signing Code . . . . . . . . . . . . . . . . 15
B.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 15 Appendix C. Changes and Open Issues . . . . . . . . . . . . . . 16
B.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 16 C.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 C.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 17
C.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[[Discussion of this draft is taking place on the dbound@ietf.org [[Discussion of this draft is taking place on the dbound@ietf.org
mailing list. There's a github repo for this draft at mailing list. There's a github repo for this draft at
<https://github.com/abrotman/related-domains-by-dns> - issues and PRs <https://github.com/abrotman/related-domains-by-dns> - issues and PRs
are welcome there.]] are welcome there.]]
Determining relationships between registered domains can be one of Determining relationships between registered domains can be one of
the more difficult investigations on the Internet. It is typical to the more difficult investigations on the Internet. It is typical to
skipping to change at page 3, line 18 skipping to change at page 3, line 20
the same company; the same company;
o following an acquisition, a domain holder might want to indicate o following an acquisition, a domain holder might want to indicate
that example.net is now related to example.com in order to make a that example.net is now related to example.com in order to make a
later migration easier; later migration easier;
o when doing Internet surveys, we should be able to provide more o when doing Internet surveys, we should be able to provide more
accurate results if we have information as to which domains are accurate results if we have information as to which domains are
related. related.
Similarly, a domain may wish to declare that no relationship exists
with some other domain, for example "good.example" may want to
declare that it is not associated with "g00d.example" if the latter
is currently being used in some cousin-domain style attack. In such
cases, it is more likely that there can be a larger list of names
(compared to the "positive" use-cases) for which there is a desire to
disavow a relationship.
It is not a goal of this specification to provide a high-level of It is not a goal of this specification to provide a high-level of
assurance that two domains are definitely related, nor to provide assurance as to whether or not two domains are definitely related,
fine-grained detail about the kind of relationship that may exist nor to provide fine-grained detail about the kind of relationship
between domains. that may exist between domains.
Using "Related Domains By DNS", or "RDBD", it is possible to declare Using "Related Domains By DNS", or "RDBD", it is possible to declare
that two domains are related. that two domains are related, or to disavow such a relationship.
We include an optional digital signature mechanism that can somewhat We include an optional digital signature mechanism that can somewhat
improve the level of assurance with which an RDBD declaration can be improve the level of assurance with which an RDBD declaration can be
handled. This mechanism is partly modelled on how DKIM [RFC6376] handled. This mechanism is partly modelled on how DKIM [RFC6376]
handles public keys and signatures - a public key is hosted at the handles public keys and signatures - a public key is hosted at the
relating-domain (e.g., "example.com") and a reference from the relating-domain (e.g., "example.com") and a reference from the
related-domain (e.g., "dept-example.com") contains a signature related-domain (e.g., "dept-example.com") contains a signature
(verifiable with the "example.com" public key) over the text (verifiable with the "example.com" public key) over the text
representation ('A-label') of the two domain names (plus a couple of representation ('A-label') of the two domain names (plus a couple of
other inputs). other inputs).
RDBD is intended to demonstrate a relationship between registered RDBD is intended to declare or disavow a relationship between
domains, not individual hostnames. That is to say that the registered domains, not individual hostnames. That is to say that
relationship should exist between "example.com" and "dept- the relationship should exist between "example.com" and "dept-
example.com", not "foo.example.com" and "bar.dept-example.com" (where example.com", not "foo.example.com" and "bar.dept-example.com" (where
those latter two are hosts). those latter two are hosts).
There already exists Vouch By Reference (VBR) [RFC5518], however this There already exists Vouch By Reference (VBR) [RFC5518], however this
only applies to email. RDBD could be a more general purpose solution only applies to email. RDBD could be a more general purpose solution
that could be applied to other use cases, as well as for SMTP that could be applied to other use cases, as well as for SMTP
transactions. transactions.
This document describes the various options, how to create records, This document describes the various options, how to create records,
and the method of validation, if the option to use digital signatures and the method of validation, if the option to use digital signatures
skipping to change at page 4, line 42 skipping to change at page 5, line 4
The wire and presentation format of the RDBDKEY resource record is The wire and presentation format of the RDBDKEY resource record is
identical to the DNSKEY record. [RFC4034] identical to the DNSKEY record. [RFC4034]
[[All going well, at some point we'll be able to say...]] IANA has [[All going well, at some point we'll be able to say...]] IANA has
allocated RR code TBD for the RDBDKEY resource record via Expert allocated RR code TBD for the RDBDKEY resource record via Expert
Review. Review.
The RDBDKEY RR uses the same registries as DNSKEY for its fields. The RDBDKEY RR uses the same registries as DNSKEY for its fields.
(This follows the precedent set for CDNSKEY in [RFC7344].) (This follows the precedent set for CDNSKEY in [RFC7344].)
No special processing is performed by authoritative servers or by No special processing is performed by authoritative servers or by
resolvers, when serving or resolving. For all practical purposes, resolvers, when serving or resolving. For all practical purposes,
RDBDKEY is a regular RR type. RDBDKEY is a regular RR type.
The flags field of RDBDKEY records MUST be zero. [[Is that correct/ The flags field of RDBDKEY records MUST be zero. [[Is that correct/
ok? I've no idea really:-)]] ok? I've no idea really:-)]]
There can be multiple occurrences of the RDBDKEY resource record in
the same zone
2.2. RDBD Resource Record Definition 2.2. RDBD Resource Record Definition
The RDBD resource record is published at the apex of the related- To declare a relationship exists an RDBD resource record is published
domain zone. at the apex of the related-domain zone.
To disavow a relationship an RDBD resource record is published at the
apex of the relating-domain zone.
[[All going well, at some point we'll be able to say...]] IANA has [[All going well, at some point we'll be able to say...]] IANA has
allocated RR code TBD for the RDBD resource record via Expert Review. allocated RR code TBD for the RDBD resource record via Expert Review.
The RDBD RR is class independent. The RDBD RR is class independent.
The RDBD RR has no special Time to Live (TTL) requirements. The RDBD RR has no special Time to Live (TTL) requirements.
There can be multiple occurrences of the RDBD resource record in the
same zone.
The wire format for an RDBD RDATA consists of a two octet rdbd-tag, The wire format for an RDBD RDATA consists of a two octet rdbd-tag,
the relating-domain name, and the optional signature fields which the relating-domain name(s), and the optional signature fields which
are: a two-octet key-tag, a one-octet signature algorithm, and the are: a two-octet key-tag, a one-octet signature algorithm, and the
digital signature bits. digital signature bits.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rdbd-tag | / | rdbd-tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ relating-domain name / / relating-domain name(s) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+|
| key-tag | sig-alg | / | key-tag | sig-alg | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ signature / / signature /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The rdbd-tag field MUST contain the value zero. Later specifications We define two possible values for the rdbd-tag in this specification,
can define new rdbd-tag values. later specifications can define new rdbd-tag values:
If an optional signture is included, the sig-alg field MUST contain o 0: states that no relationship exists between the domains
o 1: states that some relationship exists between the domains
The relating-domain name(s) field contains either a single domain
name, or an HTTPS URL. In the latter case, successfully de-
referencing that URL results in a JSON object that contains the list
of domain names, such as is shown in the figure below.
[
"example.com",
"example.net",
"foo.example"
]
If an optional signature is included, the sig-alg field MUST contain
the signature algorithm used, with the same values used as would be the signature algorithm used, with the same values used as would be
used in an RRSIG. The key-tag MUST match the RDBDKEY RR value for used in an RRSIG. The key-tag MUST match the RDBDKEY RR value for
the corresponding public key. the corresponding public key.
If the optional signature is omitted, then the presentation form of If the optional signature is omitted, then the presentation form of
the key-tag, sig-alg and signature fields MAY be omitted. If not the key-tag, sig-alg and signature fields MAY be omitted. If not
omitted then the sig-alg and key-tag fields MUST be zero and the omitted then the sig-alg and key-tag fields MUST be zero and the
signature field MUST be a an empty string. [[Is that the right way signature field MUST be a an empty string. [[Is that the right way
to have optional fields in RRs? Not sure.]] to have optional fields in RRs? Not sure.]]
The input to signing ("to-be-signed" data) is the concatenation of The input to signing ("to-be-signed" data) is the concatenation of
the following linefeed-separated (where linefeed has the value the following linefeed-separated (where linefeed has the value
'0x0a') lines: '0x0a') lines:
relating=<relating-domain> relating=<relating-domain name>
related=<related-domain> related=<related-domain name or URL>
rdbd-tag=<rdbd-tag value> rdbd-tag=<rdbd-tag value>
key-tag=<key-tag> key-tag=<key-tag>
sig-alg=<sig-alg> sig-alg=<sig-alg>
The relating-domain and related-domain values MUST be the 'A-label' The relating-domain and related-domain values MUST be the 'A-label'
representation of these names. representation of these names.
The trailing "." representing the DNS root MUST NOT be included in The trailing "." representing the DNS root MUST NOT be included in
the to-be-signed data, so a relating-domain value above might be the to-be-signed data, so a relating-domain value above might be
"example.com" but "example.com." MUST NOT be used as input to "example.com" but "example.com." MUST NOT be used as input to
signing. signing.
A linefeed MUST be included after the "sig-alg" value in the last A linefeed MUST be included after the "sig-alg" value in the last
skipping to change at page 6, line 34 skipping to change at page 7, line 20
See the examples in the Appendix for further details. See the examples in the Appendix for further details.
3. Directionality and Cardinality 3. Directionality and Cardinality
RDBD relationships are uni-directional. If bi-directional RDBD relationships are uni-directional. If bi-directional
relationships exist, then both domains can publish RDBD RRs and relationships exist, then both domains can publish RDBD RRs and
optionally sign those. optionally sign those.
If one domain has relationships with many others, then the relevant If one domain has relationships with many others, then the relevant
RDBD RRs (and RDBDKEY RRs) can be published to represent those. RDBD RRs (and RDBDKEY RRs) can be published to represent those or one
RDBD RR can contain an HTTPS URL at which one can provide a list of
names.
4. Required Signature Algorithms 4. Required Signature Algorithms
Consumers of RDBD RRs MAY support signature verification. They MUST Consumers of RDBD RRs MAY support signature verification. They MUST
be able to parse/process unsigned or signed RDBD RRs even if they be able to parse/process unsigned or signed RDBD RRs even if they
cannot cryptographically verify signatures. cannot cryptographically verify signatures.
Implementations producing RDBD RRs SHOULD support optional signing of Implementations producing RDBD RRs SHOULD support optional signing of
those and production of RDBDKEY RRs. those and production of RDBDKEY RRs.
skipping to change at page 7, line 12 skipping to change at page 7, line 46
RSA keys SHOULD use a 2048 bit or longer modulus. RSA keys SHOULD use a 2048 bit or longer modulus.
Implementations of this specification that support signing or Implementations of this specification that support signing or
verifying signatures SHOULD support use of Ed25519 (sig-alg==15). verifying signatures SHOULD support use of Ed25519 (sig-alg==15).
[RFC8080][RFC8032] [RFC8080][RFC8032]
5. Validation 5. Validation
A validated signature is solely meant to be additional evidence that A validated signature is solely meant to be additional evidence that
the two domains are related. The existence of this relationship is the relevant domains are related, or that one disavows such a
not meant to state that the data from either domain should be relationship. The existence or disavowal of a relationship does not
considered as more trustworthy. by itself mean that data or services from any domain should be
considered as more or less trustworthy.
6. Security Considerations 6. Security Considerations
6.1. Efficiacy of signatures 6.1. Efficiacy of signatures
The optional signature mechanism defined here offers no protection The optional signature mechanism defined here offers no protection
against an active attack if both the RDBD and RDBDKEY values are against an active attack if both the RDBD and RDBDKEY values are
accessed via an untrusted path. accessed via an untrusted path.
If the RDBDKEY value has been cached, or is otherwise known via some If the RDBDKEY value has been cached, or is otherwise known via some
sufficiently secure mechanism, then the RDBD signature does confirm sufficiently secure mechanism, then the RDBD signature does confirm
that the holder of the private key (presumably the relating-domain) that the holder of the private key (presumably the relating-domain)
considered that the relationship with the related-domain was real at considered that the relationship, or lack thereof, with a related-
some point in time. domain was real at some point in time.
6.2. DNSSEC 6.2. DNSSEC
RDBD does not require DNSSEC. Without DNSSEC it is possible for an RDBD does not require DNSSEC. Without DNSSEC it is possible for an
attacker to falsify DNS query responses for someone investigating a attacker to falsify DNS query responses for someone investigating a
relationship. Conversely, an attacker could delete the response that relationship. Conversely, an attacker could delete the response that
would normally demonstrate the relationship, causing the would normally demonstrate the relationship, causing the
investigating party to believe there is no link between the two investigating party to believe there is no link between the two
domains. An attacker could also replay an old RDBD value that is domains. An attacker could also replay an old RDBD value that is
actually no longer published in the DNS by the related-domain. actually no longer published in the DNS by the related-domain.
skipping to change at page 9, line 36 skipping to change at page 10, line 27
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
Algorithm (EdDSA) for DNSSEC", RFC 8080, Algorithm (EdDSA) for DNSSEC", RFC 8080,
DOI 10.17487/RFC8080, February 2017, DOI 10.17487/RFC8080, February 2017,
<https://www.rfc-editor.org/info/rfc8080>. <https://www.rfc-editor.org/info/rfc8080>.
Appendix A. Examples Appendix A. Examples
[[TODO: script up generation of all samples - it's not unlikely we This appendix provides examples of RDBD-related values. The
mucked up somewhere below when generating 'em partly-manually;-)]] following names and other values are used in these examples.
A.1. Sample Unsigned RDBD RR o Relating domain: my.example
When example.com is the relating-domain and dept-example.com is the o Related domain: my-way.example
related-domain, an unsigned RDBD RR would look like this in a zone
file:
dept-example.com. IN 3600 RDBD 0 example.com. o Unrelated domain: my-bad.example
The following is equivalent to tbe above: o URL for other related domains: <https://example.com/related-names>
dept-example.com. IN 3600 RDBD 0 example.com. 0 0 "" o URL for other unrelaed domains: <https://example.com/unrelateds>
A.2. Sample RSA Signature The github repo <https://github.com/abrotman/related-domains-by-dns>
has a script in sample/mk_samples.sh that generated this appendix.
Appendix C of [RFC6376] has some reference material on how to create A.1. Unsigned Examples
a set of keys for use in this type of use case. The RSA key length ;ZONE FILE FRAGMENT STARTS
is recommended to be at least 2048 bits instead of the 1024 ; assertion that my-way.example claims to be related
recommended in that appendix. ; to my.example
my-way.example. 3600 IN RDBD 1 my.example.
Creation of keys: ; assertion that my-way.example claims not to be
; related to my-bad.example
my-way.example. 3600 IN RDBD 0 my-bad.example.
$ openssl genrsa -out rsa.private 2048 ; assertion that my-way.example claims to be related
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM ; to whatever is at https://example.com/related-names
my-way.example. 3600 IN RDBD 1 https://example.com/related-names
Sample Key: ; assertion that my-way.example claims not to be
; related to whatever is at https://example.com/related-names
my-way.example. 3600 IN RDBD 0 https://example.com/unrelateds
rsa.private: ;ZONE FILE FRAGMENT ENDS
A.2. RSA-signed Example
# BASH SNIPPET STARTS
# HOWTO generate RSA key pair
$ openssl genrsa -out rsa.private 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.....................+++++
.....................+++++
e is 65537 (0x010001)
writing RSA key
$ openssl rsa -in rsa.private -out rsa.public -pubout \
-outform PEM
$ cat rsa.private
-----BEGIN RSA PRIVATE KEY----- -----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA2LNjBAdNAtZOMdd3hlemZF8a0onOcEo5g1KWnKzryDCfH4LZ MIIEowIBAAKCAQEA8qpGa2i6O76MdGiFVYGgd6UDYfUNl4qHpXfzmrqawUqb8JHM
kXOPzAJvz4yKMHW5ykOz9OzGL01GMl8ns8Ly9ztBXc4obY5wnQpl4nbvOdf6vyLy 5m8hjLTbKDGRpZJA5m9sQlaM41hQxpAPuW3mJXYvVOiqxtRCBlVTvUCR+Gkah7LU
7Gqgp+dj6RrycSYJdLitiYapHwRyuKmERlQL6MDWLU9ZSWlqskzLVPgwqtT80xch FT54U8PT+ciF2or2ArL7O1LIT1PnEL0AZsbM6FwYLsRE8RX89PqeL9N/U4xJ7jQq
U65HipKkr2luSAySZyyNEf58pRea3D3pBkLy5hCDhr2+6GF2q9lJ9qMopd2P/ZXx SRK88bnRRFs+W7F+iQuA5erHfIZHftq+yzRG8rtgTN7HvTOewkDa2XS2Tn/z0tRV
Hkvzl3TFtX6GjP5LTsb2dy3tED7vbf/EyQfVwrs4495a8OUkOBy7V4YkgKbFYSSk wNUX4Mi4e/DaEZU0u3kn7HqL0hyBXz/EEHUq9+57BURUT/ZQ41ORGgJ/4+tv2Gp8
GPmhWoPbV7hCQjEAURWLM9J7EUou3U1WIqTj1QIDAQABAoIBAH/eAgwrfq6w4/0X mp1ydOJaAhzgqky2zGBL1RS+mBFCio9dXBIJywIDAQABAoIBAQDwE7ITtcr6LKy8
Bgk4iQ9q6vnWpQCvW5Z40jRq+MnsnshKPrVL+krIGU/fvt7vaIzIPFTGrf7VWxl3 xmOTkul1NVZBZbYKxU0qUaA65n8Q2IWq3jR/jlb85DkmbNQRoL6AvJ+4ifRdQBS6
+oZg/1sRFPYUItjaluqjaxEhWvHH1saYCb2lAV1x9QtkgjBv4F6GZqfi1MJfro32 PfCwnZ/iVCjDsmSyzXB835I3XFiOET3kHvJgCiv1g3qGVvLGolB9nyGbMW1nvjSO
QP36s/hIaVjdHHNsB7BkDgr6VEVIR5y2PmW4aLjHCiqsyDIUM4zRcl4exzw+rst1 hM6O4AP9po9uRVOHyR84J3K1EmOX/PgmITPel61CEe+IdYwX3K3w1Mmm9C3ZSitx
z2seOhhJrnYdc+VnkEg5GKENldZ3tZoY3je/OsfNJtKjpArPRqkP1qve3h3uD+PK rx8gpWHknpAG9Z+DA+f406TFTFtuTQe6xCDjKl0/uUGsT62UQqEiw00wekm8e+2b
obZ7BM+xok29Fxf6AgC99eDr9BatTa/a8q7NYMkVRLq/JdOF1XUuDDNd3r93Ae4n rDdtqu61Lqq1aakhtGlozXIT7ED+oobp6cAnM1QbV09z7zZevXl95yrXt9xZ3odS
54qqucECgYEA/Xuct8ALG2/6Kd4Lmm9i055LVxdwB+1wG1JNE1IB+OI+6B8W49po HNcHnMCRAoGBAP6N00vMmplk76OOJ738Twf6fsaL+zkwNmL74Rv85LJn96p6xQUm
vK/fFVHMEV2BoRr4EB58Xxa+oICBImIzTUQXYQnMbDzL2N+X3FrkDSGCPZQy7GzD wJdMsa7HoD7LwuxhJkhDbdTiq+oV+Mc4J+FAe5xRK5vD7wVmPNWtUcvwdTZXnpNr
wFdpY3ceNShou1bRt4/hPWLLI35ZXM3yqBJeGhbTUmYVdWrkXTNo2wUCgYEA2tpE 6fU28PqL76feU22G/V2mthgKOXPvYehcteAJAEGbLwQoo1Q7qZa7Q9i/AoGBAPQL
+bg9iIYUJAg/CEpdWn+8ZxhRnBDziN88Grli+arSWaMWE809GyPaeiplbwywnXRb KSqcOzGHJ57iYN+HbN0cqXpBburA7dZstl6WiwQO0U4+KsJ3eyyuUE0Mz6epXeQD
vliskE43CcgstnhRKY8dWB2AQnRESvsJKO8rw/ONSxlWTpFc78xxmmNSvOBs4Srv Ry1W8yoH9ypfLDEP3YwP3wp7dqISyGAzsRospGyGJ0tHkQ3orW+/6PgSl9W2aJV2
quMc6HTMaetCM5/l0PddCY3/rls9FTESf36RXpECgYEA5AF6mHYwB4AT3/ERMtsa LqyfOPutrjfIRUkgALMq8cTRxR1xpx0HpVfOMCX1AoGAJi9SPfGgU1hf1lIRxh8e
ZAuw7Sfx58+V1Z2UItrTV1H7D8RXTKE7MO5plb2796rKXWXq2GTzrnzA/5JXldwL H91EvTXsZqTD089i8lbaW6Ta8xjdiytIAqo/kS9i62iXgewE2Rw8Uo36KfBH1GKp
FWc4OFsd/AY7vlpxOQ6wr3cCte1GWRAEjFCURZnyHBK7Ejgn8BuFmTfyTXzrWOUP INISeN14RDJ9HXs7rvYD6irU+mTkZcrvWph2R69MMQtZynlQcob6k9qcybZkIn4d
bksHRiRd9XJJvxJlU8hYexkCgYBhM9i24THTVVnUtyTn1b+o1lsjnxWAL7c674uO zlCrWCwWPnJ2JcGZbAIFaHMCgYBXIdD95LABu/a6dKsPxANrYrtj6g7XBDEmuMPY
gxCGu2w6C8leeiXNzBrZb8Mlk4lOJcQpwtDCNzsSySmy0bWas8ngvRmeam16sAzd O7nApiW24N1Vd2FkD4yeJe/SNddO/JiiKIRDQnrOBxL5JWf9hQEmdfRiY4BlUK9v
dX0Gx0HWPSasNrwEddVvMPYqlbNGPv+78quAQ4AW+zqoGzjDm1pjSAJrunJi2yzQ 3/aIxNEswI2awLODzao5QDIz3J+0lXCOs36d5WHpiriqJiH51mBh3F+bZqO66qrv
G7MNQQKBgCZktECUg2xr8vgVTB586sB7PiHp2j8Wabxh+dMiNUEB7qg4HZdzh8XA EbABLQKBgDUhcsEyIMI6oygKO/L+iVOZM+ao+64TtKxqUmgHU+gBgvdkY8h9GvxY
JXnJnZVQWBL0s10yPg9oITWVBcZ3MqgOqsN1QamN9KjzA46ILtpWptz2q3Nw2Tkl kL7L1hBOB9bAyP8ObU18R5CMbQgO7PITACRoU+uYIiQ67UREDKjBRtoDcgK0JrRX
m7RBP9R9gM9mnl9/azK7Y5uj11/O3cNJLEIWcraKqydPfvxNyEtP kqy4v6LuuFCpS5OJKQL6rKfk2XNSjDD1ZwLuBZjHQDdc/gnn7XRx
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
rsa.public: $ cat rsa.public
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2LNjBAdNAtZOMdd3hlem MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8qpGa2i6O76MdGiFVYGg
ZF8a0onOcEo5g1KWnKzryDCfH4LZkXOPzAJvz4yKMHW5ykOz9OzGL01GMl8ns8Ly d6UDYfUNl4qHpXfzmrqawUqb8JHM5m8hjLTbKDGRpZJA5m9sQlaM41hQxpAPuW3m
9ztBXc4obY5wnQpl4nbvOdf6vyLy7Gqgp+dj6RrycSYJdLitiYapHwRyuKmERlQL JXYvVOiqxtRCBlVTvUCR+Gkah7LUFT54U8PT+ciF2or2ArL7O1LIT1PnEL0AZsbM
6MDWLU9ZSWlqskzLVPgwqtT80xchU65HipKkr2luSAySZyyNEf58pRea3D3pBkLy 6FwYLsRE8RX89PqeL9N/U4xJ7jQqSRK88bnRRFs+W7F+iQuA5erHfIZHftq+yzRG
5hCDhr2+6GF2q9lJ9qMopd2P/ZXxHkvzl3TFtX6GjP5LTsb2dy3tED7vbf/EyQfV 8rtgTN7HvTOewkDa2XS2Tn/z0tRVwNUX4Mi4e/DaEZU0u3kn7HqL0hyBXz/EEHUq
wrs4495a8OUkOBy7V4YkgKbFYSSkGPmhWoPbV7hCQjEAURWLM9J7EUou3U1WIqTj 9+57BURUT/ZQ41ORGgJ/4+tv2Gp8mp1ydOJaAhzgqky2zGBL1RS+mBFCio9dXBIJ
1QIDAQAB ywIDAQAB
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
# To-be-signed data for RSA
$ cat to-be-signed-8.txt
relating=my.example
related=my-way.example
rdbd-tag=1
key-tag=38501
sig-alg=8
# Sign that
$ openssl dgst -sha256 -sign rsa.private -out rsa.sig \
to-be-signed-8.txt
# Hexdump of signature
$ hexdump rsa.sig
0000000 8664 bd57 8cbf a8e1 9182 1b5f a4fc 5eb9
0000010 49b4 fe21 f1c7 8097 ed90 44a5 bcb1 543c
0000020 f784 c190 e1d9 2f2b 18ca d3c2 640f 3823
0000030 7f8a e446 d0eb bd14 6077 0597 6015 a82b
0000040 42d7 8677 b1a3 37fa a1e8 8109 07ec ff62
0000050 16b8 3895 66de d992 dc4d ed99 9ec3 0a62
0000060 6a07 3baa 45f2 d528 1e83 a147 60ce 9b25
0000070 a967 4ba0 3fb5 98db 5ff3 b070 058b 4d8f
0000080 f198 6c1f e6b6 7a6c 1e8c ad42 237f 5440
0000090 7856 caac f96c f87d e79c 4dc5 b833 bc03
00000a0 c52e 5603 46a7 59b5 9fe3 fccd 04ee e908
00000b0 71e7 21f8 47ad fea8 40bf 14a5 9e6b b3d4
00000c0 c61a 5b96 c559 3491 4dfa 91a0 4c0b f3ff
00000d0 e460 484c 7e49 5368 85e3 16be fe6b 809a
00000e0 117d c2cb be19 c5ba 7594 2f60 16ad 1132
00000f0 f978 6ca1 5448 180f 8ca7 e73d 1137 7064
0000100
# BASH SNIPPET ENDS
To calculate the key-tag as specified in Appendix B of [RFC4034] we ; ZONE FILE FRAGMENT STARTS
used python code from: <https://www.v13.gr/blog/?p=239> ; The RDBDKEY RR for my.example is...
my.example. 3600 IN RDBDKEY 0 3 8 (
File containing to-be-signed data: LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5C
Z2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUE4
$ cat to-be-signed-8.txt cXBHYTJpNk83Nk1kR2lGVllHZwpkNlVEWWZVTmw0cUhwWGZ6
relating=example.com bXJxYXdVcWI4SkhNNW04aGpMVGJLREdScFpKQTVtOXNRbGFN
related=foo-example.com NDFoUXhwQVB1VzNtCkpYWXZWT2lxeHRSQ0JsVlR2VUNSK0dr
rdbd-tag=0 YWg3TFVGVDU0VThQVCtjaUYyb3IyQXJMN08xTElUMVBuRUww
key-tag=65498 QVpzYk0KNkZ3WUxzUkU4Ulg4OVBxZUw5Ti9VNHhKN2pRcVNS
sig-alg=8 Szg4Ym5SUkZzK1c3RitpUXVBNWVySGZJWkhmdHEreXpSRwo4
$ cnRnVE43SHZUT2V3a0RhMlhTMlRuL3owdFJWd05VWDRNaTRl
$ od -x to-be-signed-8.txt L0RhRVpVMHUza243SHFMMGh5Qlh6L0VFSFVxCjkrNTdCVVJV
0000000 6572 616c 6974 676e 653d 6178 706d 656c VC9aUTQxT1JHZ0ovNCt0djJHcDhtcDF5ZE9KYUFoemdxa3ky
0000020 632e 6d6f 720a 6c65 7461 6465 643d 7065 ekdCTDFSUyttQkZDaW85ZFhCSUoKeXdJREFRQUIKLS0tLS1F
0000040 2d74 7865 6d61 6c70 2e65 6f63 0a6d 6472 TkQgUFVCTElDIEtFWS0tLS0tCg== )
0000060 6462 742d 6761 303d 6b0a 7965 742d 6761 ; The RDBD RR to be published by my-way.example is...
0000100 363d 3435 3839 730a 6769 612d 676c 383d my-way.example. 3600 IN RDBD 1 my.example 38501 8 (
0000120 000a ZIZXvb+M4aiCkV8b/KS5XrRJIf7H8ZeAkO2lRLG8PFSE95DB
0000121 2eErL8oYwtMPZCM4in9G5OvQFL13YJcFFWArqNdCd4ajsfo3
6KEJgewHYv+4FpU43maS2U3cme3DnmIKB2qqO/JFKNWDHkeh
To sign that file: zmAlm2epoEu1P9uY819wsIsFj02Y8R9stuZseoweQq1/I0BU
Vnisymz5ffic58VNM7gDvC7FA1anRrVZ45/N/O4ECOnncfgh
$ openssl dgst -sha256 -sign rsa.private \ rUeo/r9ApRRrntSzGsaWW1nFkTT6TaCRC0z/82DkTEhJfmhT
-out rsa.sig to-be-signed-8.txt 44W+Fmv+moB9EcvCGb66xZR1YC+tFjIRePmhbEhUDxinjD3n
$ od -x rsa.sig NxFkcA== )
0000000 087c d5c9 375f dcba 9edf ce25 e353 9fb9 ; ZONE FILE FRAGMENT ENDS
0000020 6ef4 ca9f a167 6d91 71bb 7487 5edd fe30
0000040 452e d104 724f f593 009b be3f 6006 ba77
0000060 c1f5 edc6 e207 7ab0 69a1 79bf 18e6 eea3
0000100 3562 6ca4 dc73 22c3 1e35 d15c 44be 5f63
0000120 ac68 f61e ea34 432d 9e12 2325 d48c 2fd9
0000140 330d 1caf 5761 6714 eed2 c7e2 4f71 2c1a
0000160 c35b e45e 833b e343 a8e2 3dbf 1a73 02a8
0000200 c686 7240 aa69 df68 a086 8e3e 2a02 ad57
0000220 32df 0e62 4679 3f4e 8afb 0716 1ad6 4300
0000240 03c6 429f 7b6e bf4d ecae d074 9158 99be
0000260 ab0e 3d49 bb42 a84a 071a b959 2d27 3eea
0000300 c9de 0781 dc5b e205 7708 e50b e485 0cdb
0000320 2fbe adee f521 3b75 9c67 66a8 d217 4f6e
0000340 90da 9423 9d8d e683 7110 4368 f70e 80a2
0000360 3a8c 25f1 3655 44a2 a585 d87d ca99 aac9
0000400
The presentation fom of a signed RDBD record (with a 3600 TTL) would
be:
dept-example.com. 3600 RDBD 0 example.com. 65498 8 (
hfnhVSlTZMFltG2qU+4vyCPbfSMutxuV8zEyBv7GshOcKMOW
VLFBK116wRUb7wVgG9TSunXyIuCjDqtidEjWftwVZ8SsXBzo
tJPMq9HbvZaAnfmx4HxxAMHCpX9QJ2cOK/5VobdZm2eZnXl4
jd9JsLGuez2wVeiCkwk0x6z/tA61SHmDIFJb5zeKbuvbN14y
ABaNE88pxoj7EMVQD/nVoag2MqtsiaMS3kbvkYXC3gv25hgM
mzH+kRXGieaPeYly/ai8OSn3X2bksrffqPuiQsVC03UEm9Vn
YJgzSjnsvNXvwWJpJ9zyWmVbgdR3/vvUsz2pPvKyJsLT9Knl
fPNpvg== )
The base64 encoded value for the signature can be produced using: A.3. Ed25519-signed Example
# BASH SNIPPET STARTS
# HOWTO generate an Ed25519 key pair...
$ ./ed25519-signer.py -s rdbd-example0001rdbd-example0002 \
-r my.example -d my-way.example
private:b'726462642d6578616d706c6530303031726462642d6578616d
706c6530303032'
public:b'353fc31e1168c91f0af65d6c26fd441fb7df9671a23a746bb3e
c86be8d35b648'
b64pubkey: NT/DHhFoyR8K9l1sJv1EH7fflnGiOnRrs+yGvo01tkg=
keyid: 35988
to-be-signed:|relating=my.example
related=my-way.example
rdbd-tag=1
key-tag=35988
sig-alg=15
|
sig:b'64bc444ce759fb9435fe9c1875eb241c4ec6d0995cd8138a372782
32fc8e79f53cb8f88059f6040054c61be8cfd73fd44521f73994628fc7c3
0135fa929ab00f'
# hex dump of Ed25519 private
$ hexdump ed25519.priv
0000000 6472 6462 652d 6178 706d 656c 3030 3130
0000010 6472 6462 652d 6178 706d 656c 3030 3230
0000020
# hex dump of Ed25519 public
$ hexdump ed25519.pub
0000000 3f35 1ec3 6811 1fc9 f60a 6c5d fd26 1f44
0000010 dfb7 7196 3aa2 6b74 ecb3 be86 358d 48b6
0000020
# hex dump of Ed25519 signature
$ hexdump ed25519.sig
0000000 bc64 4c44 59e7 94fb fe35 189c eb75 1c24
0000010 c64e 99d0 d85c 8a13 2737 3282 8efc f579
0000020 b83c 80f8 f659 0004 c654 e81b d7cf d43f
0000030 2145 39f7 6294 c78f 01c3 fa35 9a92 0fb0
0000040
# BASH SNIPPET ENDS
$ base64 -w48 rsa.sig ; ZONE FILE FRAGMENT STARTS
hfnhVSlTZMFltG2qU+4vyCPbfSMutxuV8zEyBv7GshOcKMOW ; The RDBDKEY RR for my.example is...
VLFBK116wRUb7wVgG9TSunXyIuCjDqtidEjWftwVZ8SsXBzo my.example. 3600 IN RDBDKEY 0 3 15 (
tJPMq9HbvZaAnfmx4HxxAMHCpX9QJ2cOK/5VobdZm2eZnXl4 NT/DHhFoyR8K9l1sJv1EH7fflnGiOnRrs+yGvo01tkg= )
jd9JsLGuez2wVeiCkwk0x6z/tA61SHmDIFJb5zeKbuvbN14y ; The RDBD RR to be published by my-way.example is...
ABaNE88pxoj7EMVQD/nVoag2MqtsiaMS3kbvkYXC3gv25hgM my-way.example. 3600 IN RDBD 1 my.example 35988 15 (
mzH+kRXGieaPeYly/ai8OSn3X2bksrffqPuiQsVC03UEm9Vn ZLxETOdZ+5Q1/pwYdeskHE7G0Jlc2BOKNyeCMvyOefU8uPiA
YJgzSjnsvNXvwWJpJ9zyWmVbgdR3/vvUsz2pPvKyJsLT9Knl WfYEAFTGG+jP1z/URSH3OZRij8fDATX6kpqwDw== )
fPNpvg== ; ZONE FILE FRAGMENT ENDS
To verify, with "rsa.sig" containing the above signature: Appendix B. Ed25519 Signing Code
$ openssl dgst -sha256 -verify rsa.public \ Since OpenSSL does not yet support Ed25519 signing via its command
-signature rsa.sig to-be-signed.txt line tool, we generate our example using the python script below,
Verified OK which is called as "ed25519-signer.py" above. This uses the python
library from Appendix A of [RFC8032].
The RDBDKEY RR for this example would be: #!/usr/bin/env python3
# CODE_BEGINS
import argparse, sys, binascii
from eddsa2 import Ed25519
example.com. 3600 RDBDKEY 0 3 8 ( # from https://gist.github.com/wido/4c6288b2f5ba6d16fce37dca3fc2cb4a
LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5C def calc_keyid(flags, protocol, algorithm, dnskey):
Z2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUEy st=struct.pack('!HBB', int(flags), int(protocol), int(algorithm))
TE5qQkFkTkF0Wk9NZGQzaGxlbQpaRjhhMG9uT2NFbzVnMUtX st+=base64.b64decode(dnskey)
bkt6cnlEQ2ZINExaa1hPUHpBSnZ6NHlLTUhXNXlrT3o5T3pH cnt = 0
TDAxR01sOG5zOEx5Cjl6dEJYYzRvYlk1d25RcGw0bmJ2T2Rm for idx in range(len(st)):
NnZ5THk3R3FncCtkajZScnljU1lKZExpdGlZYXBId1J5dUtt s = struct.unpack('B', st[idx:idx+1])[0]
RVJsUUwKNk1EV0xVOVpTV2xxc2t6TFZQZ3dxdFQ4MHhjaFU2 if (idx % 2) == 0:
NUhpcEtrcjJsdVNBeVNaeXlORWY1OHBSZWEzRDNwQmtMeQo1 cnt += s << 8
aENEaHIyKzZHRjJxOWxKOXFNb3BkMlAvWlh4SGt2emwzVEZ0 else:
WDZHalA1TFRzYjJkeTN0RUQ3dmJmL0V5UWZWCndyczQ0OTVh cnt += s
OE9Va09CeTdWNFlrZ0tiRllTU2tHUG1oV29QYlY3aENRakVB return ((cnt & 0xFFFF) + (cnt >> 16)) & 0xFFFF
VVJXTE05SjdFVW91M1UxV0lxVGoKMVFJREFRQUIKLS0tLS1F
TkQgUFVCTElDIEtFWS0tLS0tCgo= )
A.3. Sample Ed25519 Signature def main():
parser=argparse.ArgumentParser(description='Ed25519 signing')
parser.add_argument('-s','--secret',
dest='secret', help='secret key')
parser.add_argument('-r','--relating',
dest='relating', help='relating domain')
parser.add_argument('-d','--related',
dest='related', help='related domain')
parser.add_argument('-n','--negative',
dest='negative', help='negative assertion')
args=parser.parse_args()
Since OpenSSL does not yet support Ed25519 singing via its command if args.secret is None:
line tool, we generate our example using the python script below. print("You do need a secret... - exiting")
This uses the python library from Appendix A of [RFC8032]. sys.exit(1)
# secret has to be 32 octets funnily enuugh:-)
# e.g. secret="rdbd-example0001rdbd-example0002".encode('utf-8')
if len(args.secret)!=32:
print("Secret has to be 32 octets... - exiting")
sys.exit(1)
if args.relating is None:
print("You do need a relating domain... - exiting")
sys.exit(1)
if args.related is None:
print("You do need a related domain... - exiting")
sys.exit(1)
secret=args.secret.encode('utf-8')
privkey,pubkey = Ed25519.keygen(secret)
print("private:"+ str(binascii.hexlify(privkey)))
print("public:"+ str(binascii.hexlify(pubkey)))
#!/usr/bin/env python3 b64pubkey=binascii.b2a_base64(pubkey).rstrip().decode("utf-8")
# CODE_BEGINS print("b64pubkey: " + b64pubkey)
import sys, binascii
from eddsa2 import Ed25519
# secret chosen to be 32 octets funnily enuugh:-) keyid=calc_keyid("0","3","15",b64pubkey)
secret="rdbd-example0001rdbd-example0002".encode('utf-8') print("keyid: " + str(keyid))
privkey,pubkey = Ed25519.keygen(secret)
msg=open('to-be-signed-15.txt','r').read().encode('utf-8')
signature = Ed25519.sign(privkey, pubkey, msg)
print("private:"+ str(binascii.hexlify(privkey))) rdbdtag="1"
print("public:"+ str(binascii.hexlify(pubkey))) if args.negative:
print("sig:"+ str(binascii.hexlify(signature))) rdbdtag="0"
print("to-be-signed:" + str(msg))
with open("ed25519.sig", "wb") as sigf: tbs="relating="+args.relating+"\nrelated="+\
sigf.write(signature) args.related+"\nrdbd-tag="+rdbdtag+\
with open("ed25519.pub","wb") as pubf: "\nkey-tag="+str(keyid)+"\nsig-alg=15\n"
pubf.write(pubkey) print("to-be-signed:|" + str(tbs)+"|")
# CODE_ENDS with open("ed25519.priv", "wb") as privf:
privf.write(privkey)
with open("ed25519.pub","wb") as pubf:
pubf.write(pubkey)
with open("to-be-signed-15.txt","wb") as tbsf:
tbsf.write(tbs.encode('utf-8'))
The to-be-signed-15.txt file contains: msg=tbs.encode('utf-8')
signature = Ed25519.sign(privkey, pubkey, msg)
print("sig:"+ str(binascii.hexlify(signature)))
with open("ed25519.sig", "wb") as sigf:
sigf.write(signature)
return
$ cat to-be-signed-15.txt if __name__ == "__main__":
relating=example.com main()
related=dept-example.com
rdbd-tag=0
key-tag=35988
sig-alg=15
$
The output when the above code is run (with some spacing added) is: # CODE_ENDS
$ ./ed25519-signer.py Appendix C. Changes and Open Issues
private:
b'726462642d6578616d706c6530303031
726462642d6578616d706c6530303032'
public:
b'353fc31e1168c91f0af65d6c26fd441f
b7df9671a23a746bb3ec86be8d35b648'
sig:
b'466a80ce6377b1e4bec563d85b8d55bd
4a51a5b91c1c1e46a9c4e22a16557c38
e85ccc8ac05e6046d0066c2c52b3a174
20b59af9627840ac312f5ab55e11be07'
to-be-signed:
b'relating=example.com\nrelated=dept-example.com\n
rdbd-tag=0\nkey-tag=35988\nsig-alg=15\n'
The presentation form for an RDBD RR would then be: [[RFC editor: please delete this appendix ]]
dept-example.com. 3600 RDBD 0 example.com. 35988 15 ( C.1. Changes from -01 to -02
RmqAzmN3seS+xWPYW41VvUpRpbkcHB5G
qcTiKhZVfDjoXMyKwF5gRtAGbCxSs6F0
ILWa+WJ4QKwxL1q1XhG+Bw== )
The RDBDKEY for this example would be: o Added negative assertions based on IETF104 feedback
example.com. 3600 RDBDKEY 0 3 15 ( o Added URL option based on IETF104 feedback
NT/DHhFoyR8K9l1sJv1EH7fflnGiOnRr
s+yGvo01tkg= )
Appendix B. Changes and Open Issues o Made sample generation script
[[RFC editor: please delete this appendix ]] o Typo fixes etc.
B.1. Changes from -00 to -01 C.2. Changes from -00 to -01
o Changed from primary/secondary to relating/related (better o Changed from primary/secondary to relating/related (better
suggestions are still welcome) suggestions are still welcome)
o Moved away from abuse of TXT RRs o Moved away from abuse of TXT RRs
o We now specify optional DNSSEC-like signatures (we'd be fine with o We now specify optional DNSSEC-like signatures (we'd be fine with
moving back to a more DKIM-like mechanism, but wanted to see how moving back to a more DKIM-like mechanism, but wanted to see how
this looked) this looked)
o Added Ed25519 option o Added Ed25519 option
o Re-worked and extended examples o Re-worked and extended examples
B.2. Open Issues C.3. Open Issues
Current open github issues include: Current open github issues include:
o #5: specify input for signing more precisely - e.g. is there a CR o #5: specify input for signing more precisely - e.g. is there a CR
or NULL or not or NULL or not
o #6: what, if anything, does rdbd for example.com mean for o #6: what, if anything, does rdbd for example.com mean for
foo.example.com? foo.example.com?
These can be seen at: <https://github.com/abrotman/related-domains- These can be seen at: <https://github.com/abrotman/related-domains-
 End of changes. 65 change blocks. 
245 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/