-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-feher-cds-epp-mapping.xml
266 lines (188 loc) · 12.8 KB
/
draft-feher-cds-epp-mapping.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.37 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-feher-cds-epp-mapping-latest" category="info">
<front>
<title abbrev="cdsEPPMapping">CDS to EPP Mapping</title>
<author initials="K." surname="Feher" fullname="Kal Feher">
<organization>None</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2021" month="July" day="11"/>
<area>General</area>
<workgroup>TODO Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>TODO Abstract</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>TODO Introduction</t>
</section>
<section anchor="conventions-and-definitions" title="Conventions and Definitions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="background" title="Background">
<t><xref target="RFC7344"/> specifies how DNS trust can be maintained across key rollovers in-band between parent and child. <xref target="RFC8078"/> added inband signalling DNSSEC status changes and documented 3 use cases. This document describes how the parent zone changes required by those use cases might be implemented via EPP. This document seeks to map the three use cases found in <xref target="RFC8078"/> section 2, to EPP operations.</t>
<section anchor="registries-and-registrars" title="Registries and Registrars">
<t>Support for CDS/CDNSKEY amongst Internet Registries is likely to remain inconsistent for some time. Therefore practices for updating the parent zone for a registered domain should allow for either the Registry or the sponsoring Registrar to observe a domain's CDS records and subsequent state changes. In most TLDs both the Registrar and Registry are capable of making the changes signaled by CDS records, to the parent zone.</t>
<t>Some Registrars may support CDS even if the Registry does not.</t>
<t>Some Registries may use EPP as the method by which CDS signals are applied to the registry system for subsequent entry into the registered domain's parent zone.</t>
</section>
</section>
<section anchor="registrar-initial-trust-models" title="Registrar Initial Trust Models">
<t>RFC8078 proposes several models that a parent may use for managing initial trust. These models assume that it is the parent which will observe any CDS/CDNSKEY signals and it will also be the parent which manages the initial trust solution.</t>
<t>When a Registry does not support <xref target="RFC8078"/> a Registrar can instead carry out the operations described in <xref target="RFC8078"/> section 3.</t>
<section anchor="accept-policy-via-authenticated-channel" title="Accept Policy via Authenticated Channel">
<t>The Registrar can use an authenticated channel to receive a notice that a CDS/CDNSKEY exists. Once the notice is received, the process documented in <xref target="RFC8078"/> section 3.1 should be followed.</t>
</section>
<section anchor="accept-with-extra-checks" title="Accept with Extra Checks">
<t>TODO</t>
</section>
<section anchor="accept-after-delay" title="Accept after Delay">
<t>TODO</t>
</section>
<section anchor="accept-with-challenge" title="Accept with Challenge">
<t>TODO</t>
</section>
<section anchor="accept-from-inception" title="Accept from Inception">
<t>TODO
# EPP Commands for CDS/CDNSKEY Use Cases</t>
</section>
<section anchor="enable-dnssec-validation" title="Enable DNSSEC Validation">
<t>Regardless of the method used to determine that the initial CDS/CDNSKEY signal is trustworthy, the Registrar or Registry SHOULD use the EPP <update> command with the secDNS extension documented in <xref target="RFC5910"/> in order to add the DS to the parent. A <secDNS:add> sub-element to <secDNS:update> MUST be used to indicate that security information is being added.
In the case of a CDS RRset the DS Data Interface MUST be used by including the <secDNS:dsData> child element to <secDNS:update>.
In the case of a CDNSKEY RRset, the Key Data Interface MUST be used by including the <secDNS:keyData> child element to <secDNS:update>.
If both CDS and CDNSKEY RRsets are present then a Registrar SHOULD choose the RRset based on the server policy.</t>
<t>TODO EPP Examples</t>
</section>
<section anchor="roll-over-the-ksk" title="Roll over the KSK">
<t>TODO</t>
</section>
<section anchor="turn-off-dnssec-validation" title="Turn off DNSSEC validation">
<t>TODO</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TODO Security</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC7344' target='https://www.rfc-editor.org/info/rfc7344'>
<front>
<title>Automating DNSSEC Delegation Trust Maintenance</title>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></author>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organization/></author>
<author fullname='G. Barwood' initials='G.' surname='Barwood'><organization/></author>
<date month='September' year='2014'/>
<abstract><t>This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.</t></abstract>
</front>
<seriesInfo name='RFC' value='7344'/>
<seriesInfo name='DOI' value='10.17487/RFC7344'/>
</reference>
<reference anchor='RFC8078' target='https://www.rfc-editor.org/info/rfc8078'>
<front>
<title>Managing DS Records from the Parent via CDS/CDNSKEY</title>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organization/></author>
<author fullname='P. Wouters' initials='P.' surname='Wouters'><organization/></author>
<date month='March' year='2017'/>
<abstract><t>RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.</t><t>Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.</t><t>This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).</t><t>It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.</t></abstract>
</front>
<seriesInfo name='RFC' value='8078'/>
<seriesInfo name='DOI' value='10.17487/RFC8078'/>
</reference>
<reference anchor='RFC5910' target='https://www.rfc-editor.org/info/rfc5910'>
<front>
<title>Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)</title>
<author fullname='J. Gould' initials='J.' surname='Gould'><organization/></author>
<author fullname='S. Hollenbeck' initials='S.' surname='Hollenbeck'><organization/></author>
<date month='May' year='2010'/>
<abstract><t>This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5910'/>
<seriesInfo name='DOI' value='10.17487/RFC5910'/>
</reference>
</references>
<section numbered="false" anchor="acknowledgments" title="Acknowledgments">
<t>TODO acknowledge.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAMft6mAAA51XbW/bNhD+rl/BJR/2JfaStkNbYxvm2u4a5HVxsqJYh4KS
TjYRiVRJKolb5L/vOVJS5KQbsBUILIn3+tzdw+toNEq88iVNxM5svhTeiMX5
uTiRda30aieRaWrpBodZ7nDQf89NpmUFrdzKwo8KWpMdQWZEdT2qotSolJ6c
TzL8rIzdTITShUkSVduJ8LZx/tn+/uv9Z4m0JCfiN9JkZZncGnu9sqapJ+Ly
bH4m3uMd1sRv/C25pg0E8ok41J6sJj+acwRJ4rzU+SdZGo2oNuQSV0nrP31u
DIKYCG2SWk3En95ke8IZ6y0VDk+bih/+ShLZ+LWxk0SMEoF/SkPpaCzecmbh
S8z3SJaDb8aupFZfpFdGT8QpfIfPVElVIl3yxa8BmkJWqtyMIZ4k2tgKCjcE
X+Li7ezZwcHrCVABNv0B/o1GIyFT563MkF1AYtq/8mGl8rykJNllKKzJm4yj
aEW3P0FmZvQNaX51AkCJORVKq/AOlTUJACsYWSd2Tq6Wlzt78VecnoXni8Xv
V4cXizk/L99Nj4/7h05i+e7s6hjnSfv0oDk7OzlZnM6jMr6KR59Oph/ww1Ht
nJ1fHp6dTo93UADh18pxpzUVIhfoEm7PlHCE0teWPOVCOpGTy6xK8QKdN7Nz
cfBCfP3aInt/j+fv8PLq4OWL+/vkdk06+jK6RMbh1a+RPJqWpGUbsixFJmvl
ZYkWgQe3NrdaoI40ZizfyCx0qM6TJBp/+fwFjAtXU6YKRU5AQcxPl7HNYUxz
3OgK7fHHYWfWOBdAt6YszQ1ZB9ejlCNLyd8SaVEjZU4cn7K1KvNxl8r+y1fw
JvM85Bx0nFppxM2DAr/LxUxgIHzjoCn1imLROyyh9lw0jhCYIzcWlwC6P+zx
jFkAmy6QL+jv3p6lz42ysJRuIGNgrDeI1lytfahUVZfUerxRkrnlsTdHdO24
sGCN4MyvLQ2NFQw0l2UreUeht8WzvY6zTA36CA3NRdoVF7RSmBfV5t6+SuuS
ZVPXYABYtgKk98MMiB0tPghZGb1CuTpqGZpAyKW6JrQM3FkecI2YMniDBOfB
xpypEL+qiJNEt+AbwOORVVnIxIqmzhEkqvQYVz6UsMweiXHNTXCC3mvKnHsS
xWAhUlC1Qb+NbwMeCu+uRjzGsvk+XY7XpI7sDcF+NPq947zhLAsDH/qngczn
JlQEjdPXeQw0RGWAyuXx3InU+PXQNewPwN2EIcXoyLQkYQrU9LrLteub2Kix
bwZBhDI+wgR1XDKiD6WDwQ1CjeVjbQKpCVVso5Eb+NHGP9LnMrI+txY3DAab
1SpC+4ZwbtcqWwezMUgX0gEvlArxtvHZzovboFBVrPsDePjDGeZ8KD2oJ6Df
zjDZHWB5yJSMG+Yy0MaJyal0Sdv0aCRTG54Ih6xxU6IsfA4/EiTRme0y5Lgq
qeWKC6Bau4GOQnNColWXzjXctmxFeW70QRkiJLcKjNg3kd5sTU2PFU+pj7J4
D0z9xFKIiKKLraAwO2XD0zsWSfIerIyMnhS0L/02Dw4AZKbF1e1JgjOl5dFo
fPD2QA/bF8Y3WeU5RwEOmWYZ1V6cm1Jlm8BgU6wJfI/yUpOLGZpaUxku0O0g
uAT4kVviWRSPFJKRCiOJvMAOXRWHyNIdDGICz3QWoWxFlevU870IsTXgFzfk
93/O7KCjlJSbhGmF8vEw21sQjFjcIRXkR9m1CyvFUAILFxhoTqXcPDkL2sCl
LAnz/uS4sKZCm/MzrybheDeM48xU6I7cPaHlK0A546sg2FnoQC7tJfeHLFUe
ypoAf2mxEQEHUwwnG6UI05tjYbAVrt+I9bAFn/ZzmANuTOxEfr3Ze0R6CLHv
znbd4YqzEOfy8afA8/TxF5HFtCIugaQp482A7nBtOC7Jt6r24+uDfVQN7yBH
CiSO6z7oxy39YbLGYgp/0eoEQvAJPhpRvHhZtj/tgwqbXUo9NErnoUUjMpBu
rPIb0e+kiBJ4pMRcEtaOcXKoI62jMIx36FxxceHId1HOpZfxLi0kunbLZ8rG
s7LJu+uhjzF3rMfA8coj/i2NbwYRixgCiUU7wo71/0LBdvZfYini7cg4cMG3
QolXCXZWFwxs8RvaqW2hbG1M20URyVRyhEa3jQP6taIOZDRuF33utsWd5D0r
zseFYa6+aTeEo+XRwwheNhb9VBTd8Nw8DE8rI5Zd6We82eQdZbbOutNwax1O
T6dPxbZ2u7Vk2o6SMut2s/jflxRLNJuZZtfa3GIhWLGKS75OdFOlfGP+vFPg
HqGd+9a77CVxb/4NbNnbjbkOAAA=
-->
</rfc>