-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-blahaj-rsc-bis.xml
142 lines (130 loc) · 6.25 KB
/
draft-blahaj-rsc-bis.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
<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902" submissionType="IETF" category="std" version="3" docName="draft-blahaj-rsc-bis-latest"
consensus="true" updates="9323">
<front>
<title abbrev="RPKI Signed Checklists V2">RPKI Signed Checklists (RSCs) Version 2</title>
<seriesInfo name="Internet-Draft" status="standard" value="draft-blahaj-rsc-bis-latest"/>
<author fullname="Q Misell" initials="Q" surname="Misell" role="editor">
<organization abbrev="AS207960">AS207960 Cyfyngedig</organization>
<address>
<postal>
<street>13 Pen-y-lan Terrace</street>
<city>Caerdydd</city>
<code>CF23 9EU</code>
<country>United Kingdom</country>
</postal>
<email>[email protected]</email>
<email>[email protected]</email>
<uri>https://magicalcodewit.ch</uri>
</address>
</author>
<area>ops</area>
<workgroup>SIDR Operations</workgroup>
<abstract>
<t>This document defines an update to <xref target="RFC9323"/> to include an explicit purpose and audience for RSCs.
This alleviates possible security vulnerabilities in the original RSC specification caused by cross-protocol attacks.
</t>
</abstract>
<note removeInRFC="true">
<name>Discussion</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/AS207960/draft-blahaj-rsc-bis"/>.
</t>
</note>
</front>
<middle>
<section>
<name>Introduction</name>
<t>The current version of RPKI Signed Checklists <xref target="RFC9323"/> does not signal the purpose of an RSC,
nor its intended audience. In the context of processing by humans this is of little concern as the context in
which e.g. a signed PDF was sent makes its purpose evident. However, in automated machine-to-machine protocols
these ambiguities can lead to security vulnerabilities. This document updates RSCs to include this information
to make them suitable for automated processing.
</t>
<section>
<name>Requirements Language</name>
<t>The key words <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</bcp14>, <bcp14>SHALL</bcp14>,
<bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>,
<bcp14>NOT RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14> in this document are to be
interpreted as described in
<xref target="BCP14"/> (<xref target="RFC2119"/>, <xref target="RFC8174"/>) when,
and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section>
<name>Motivation for update</name>
<t>Protocols can assign the different meanings to the same data. In the context of human-to-human communication
the worst outcome of this is often a mere opportunity for a pun; however in the context of automated
machine-to-machine processing this can lead to serious security vulnerabilities.
</t>
<t>An RSC with ambiguous content could, for example, be used in a replay attack. One might argue that a protocol
which is vulnerable to such a replay attack is a poorly designed one; a counter-argument to this is that it
should not be possible to design such a vulnerability into a protocol built on top of RSCs.
</t>
<t>Further motivation for avoiding such ambiguity in protocols can be found in
<xref target="ascii-or-protobuf" format="title"/>.</t>
</section>
<section>
<name>Updates to RSCs</name>
<t><xref target="RFC9323"/> defines version 0 RSCs; this document defines version 1 RSCs with the following
modifications.</t>
<t>The RpkiSignedChecklist sequence is updated to the following:</t>
<sourcecode type="asn.1">
RpkiSignedChecklist ::= SEQUENCE {
version [1] INTEGER DEFAULT 0,
resources ResourceBlock,
digestAlgorithm DigestAlgorithmIdentifier,
checkList SEQUENCE (SIZE(1..MAX)) OF FileNameAndHash
purpose OBJECT IDENTIFIER
audience OBJECT IDENTIFIER OPTIONAL }
</sourcecode>
<t>Two new fields are defined:</t>
<dl>
<dt>purpose</dt>
<dd>An OID indicating for which purpose this RSC was created. An OID is chosen to avoid potential clashes
and to allow for easy private extensibility.</dd>
<dt>audience</dt>
<dd>An OID indication for whom the RSC was created. It <bcp14>MUST</bcp14> be set unless otherwise explicitly
allowed for by the RSCs purpose, e.g. an RSC intended for general widespread consumption.</dd>
</dl>
<t>RSCs with version 0 are still valid, and may still be used, but <bcp14>MUST NOT</bcp14> be used in the
context of automated processing.</t>
</section>
<section>
<name>IANA Considerations</name>
<t>This document contains no IANA considerations</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14">
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
</referencegroup>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9323.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="ascii-or-protobuf" target="https://sandstorm.io/news/2015-05-01-is-that-ascii-or-protobuf">
<front>
<title>Is that ASCII or is it Protobuf? The importance of types in cryptographic signatures.</title>
<author initials="K" surname="Varda" fullname="Kenton Varda"/>
<date month="May" year="2015"/>
</front>
</reference>
</references>
</references>
</back>
</rfc>