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
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
|
<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-schaad-cbor-content-02" indexInclude="true" ipr="trust200902" number="8769" prepTime="2020-03-20T21:03:36" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-schaad-cbor-content-02" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8769" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front>
<title abbrev="CMS Content Types for CBOR">Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR)</title>
<seriesInfo name="RFC" value="8769" stream="IETF"/>
<author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization showOnFrontPage="true">August Cellars</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<date month="03" year="2020"/>
<area>Security</area>
<abstract pn="section-abstract">
<t pn="section-abstract-1">
Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding.
The Cryptographic Message Syntax (CMS) is still a widely used method of doing message-based security.
This document defines a set of content types for CMS that hold CBOR content.
</t>
</abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
<t pn="section-boilerplate.1-1">
This document is not an Internet Standards Track specification; it is
published for informational purposes.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8769" brackets="none"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-content-type">CBOR Content Type</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-sequence-content-type">CBOR Sequence Content Type</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1-module">ASN.1 Module</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" removeInRFC="false" toc="include" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
Concise Binary Object Representation (CBOR) <xref target="RFC7049" format="default" sectionFormat="of" derivedContent="CBOR"/>
is a compact self-describing binary encoding formation that is
starting to be used in many different applications.
One of the primary uses of CBOR is in the Internet of Things, the
constrained nature of which means that having minimal size of
encodings becomes very important.
The Cryptographic Message Syntax (CMS) <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="CMS"/> is still one of the most common methods for
providing message-based security, although in many cases, the CBOR
Object Signing and Encryption (COSE) <xref target="RFC8152" format="default" sectionFormat="of" derivedContent="COSE"/>
message-based security system is starting to be used.
Given that CBOR is going to be transported using CMS, it makes sense
to define CMS content types for the purpose of denoting that the
embedded content is CBOR.
This document defines two new content types: CBOR content type and
CBOR Sequence content type <xref target="RFC8742" format="default" sectionFormat="of" derivedContent="CBOR-SEQ"/>.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-2">
<name slugifiedName="name-cbor-content-type">CBOR Content Type</name>
<t pn="section-2-1">
<xref target="RFC7049" format="default" sectionFormat="of" derivedContent="CBOR"/> defines an encoded CBOR item.
This section defines a new content type for wrapping an encoded CBOR item in a CMS object.
</t>
<t pn="section-2-2">
The following object identifier identifies the CBOR content type:
</t>
<sourcecode type="asn.1" markers="false" pn="section-2-3">
id-ct-cbor OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 44 }
</sourcecode>
<t pn="section-2-4">
The CBOR content type is intended to refer to a single object encoded using the CBOR encoding format <xref target="RFC7049" format="default" sectionFormat="of" derivedContent="CBOR"/>.
Nothing is stated about the specific CBOR object that is included.
CBOR can always be decoded to a tree, as the encoding is self descriptive.
</t>
<t pn="section-2-5">
The CBOR content type is intended to be encapsulated in the signed
data and auth-enveloped data, but it can be included in any CMS wrapper.
It cannot be predicted whether the compressed CMS encapsulation will
provide compression, because the content may be binary rather than text.
</t>
<t pn="section-2-6">
<xref target="RFC7193" format="default" sectionFormat="of" derivedContent="RFC7193"/> defined an optional parameter,
"innerContent", to allow for identification of what the inner content
is for an application/cms media type.
This document defines the string "cbor" as a new value that can be
placed in this parameter when a CBOR content type is used.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3">
<name slugifiedName="name-cbor-sequence-content-type">CBOR Sequence Content Type</name>
<t pn="section-3-1">
<xref target="RFC8742" format="default" sectionFormat="of" derivedContent="CBOR-SEQ"/> defines a CBOR Sequence as a concatenation of zero or more CBOR objects.
This section defines a new content type for wrapping a CBOR Sequence in a CMS object.
</t>
<t pn="section-3-2">
The following object identifier identifies the CBOR Sequence content type:
</t>
<sourcecode type="asn.1" markers="false" pn="section-3-3">
id-ct-cborSequence OBJECT IDENTIFIER ::= { iso(1) member-body(2)
usa(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
45 }
</sourcecode>
<t pn="section-3-4">
The CBOR Sequence content type is intended to refer to a sequence of objects encoded using the CBOR encoding format.
The objects are concatenated without any markers delimiting the individual CBOR objects.
Nothing is stated about the specific CBOR objects that are included.
CBOR can always be decoded to a tree, because the encoding is self descriptive.
</t>
<t pn="section-3-5">
The CBOR Sequence content type is intended to be encapsulated in the
signed data and auth-enveloped data, but it can be included in any CMS
wrapper. It cannot be predicted whether the compressed CMS encapsulation will
provide compression, because the content may be binary rather than text.
</t>
<t pn="section-3-6">
<xref target="RFC7193" format="default" sectionFormat="of" derivedContent="RFC7193"/> defined an optional parameter, "innerContent", to allow for identification of what the inner content is for an application/cms media type.
This document defines the string "cborSequence" as a new value that
can be placed in this parameter when a CBOR Sequence content type is used.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-4">
<name slugifiedName="name-asn1-module">ASN.1 Module</name>
<sourcecode type="asn.1" markers="false" pn="section-4-1">
CborContentTypes { iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs9(9) smime(16) modules(0)
id-mod-cbor-2019(71) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
CONTENT-TYPE
FROM CryptographicMessageSyntax-2010
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
;
id-ct-cbor OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
44 }
id-ct-cborSequence OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1)
45 }
-- Content is encoded directly and does not have any ASN.1
-- structure
ct-Cbor CONTENT-TYPE ::= { IDENTIFIED BY id-ct-cbor }
-- Content is encoded directly and does not have any ASN.1
-- structure
ct-CborSequence CONTENT-TYPE ::= {
IDENTIFIED BY id-ct-cborSequence
}
END
</sourcecode>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-5">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t pn="section-5-1">
IANA has registered the following in the "SMI Security for S/MIME
Module Identifier (1.2.840.113549.1.9.16.0)" subregistry within the
SMI Numbers registry:
</t>
<table align="center" pn="table-1">
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Decimal</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">References</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">71</td>
<td align="left" colspan="1" rowspan="1">id-mod-cbor-2019</td>
<td align="left" colspan="1" rowspan="1">RFC 8769</td>
</tr>
</tbody>
</table>
<t pn="section-5-3">
IANA has registered the following in the
"SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)"
subregistry within the SMI Numbers registry:
</t>
<table align="center" pn="table-2">
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Decimal</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">References</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">44</td>
<td align="left" colspan="1" rowspan="1">id-ct-cbor</td>
<td align="left" colspan="1" rowspan="1">RFC 8769</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">45</td>
<td align="left" colspan="1" rowspan="1">id-ct-cborSequence</td>
<td align="left" colspan="1" rowspan="1">RFC 8769</td>
</tr>
</tbody>
</table>
<t pn="section-5-5">
IANA has registered the following in the "CMS Inner Content Types"
subregistry within the "MIME Media Type Sub-Parameter Registries":
</t>
<table align="center" pn="table-3">
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Name</th>
<th align="left" colspan="1" rowspan="1">Object Identifier</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">cbor</td>
<td align="left" colspan="1" rowspan="1">1.2.840.113549.1.9.16.1.44</td>
<td align="left" colspan="1" rowspan="1">RFC 8769</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">cborSequence</td>
<td align="left" colspan="1" rowspan="1">1.2.840.113549.1.9.16.1.45</td>
<td align="left" colspan="1" rowspan="1">RFC 8769</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-6">
<name slugifiedName="name-security-considerations">Security Considerations</name>
<t pn="section-6-1">
This document only provides identification for content types; it does
not introduce any new security issues by itself.
The new content types mean that id-data does not need to be used to
identify these content types; they can therefore reduce confusion.
</t>
</section>
</middle>
<back>
<displayreference target="RFC5652" to="CMS"/>
<displayreference target="RFC7049" to="CBOR"/>
<displayreference target="RFC8152" to="COSE"/>
<displayreference target="RFC8742" to="CBOR-SEQ"/>
<references pn="section-7">
<name slugifiedName="name-normative-references">Normative References</name>
<reference anchor="RFC7049" target="https://www.rfc-editor.org/info/rfc7049" quoteTitle="true" derivedAnchor="CBOR">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="October"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7049"/>
<seriesInfo name="DOI" value="10.17487/RFC7049"/>
</reference>
<reference anchor="RFC8742" target="https://www.rfc-editor.org/info/rfc8742" quoteTitle="true" derivedAnchor="CBOR-SEQ">
<front>
<title>Concise Binary Object Representation (CBOR) Sequences</title>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="February"/>
<abstract>
<t>This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.</t>
<t>Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8742"/>
<seriesInfo name="DOI" value="10.17487/RFC8742"/>
</reference>
<reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="CMS">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="September"/>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152" quoteTitle="true" derivedAnchor="COSE">
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="July"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8152"/>
<seriesInfo name="DOI" value="10.17487/RFC8152"/>
</reference>
<reference anchor="RFC7193" target="https://www.rfc-editor.org/info/rfc7193" quoteTitle="true" derivedAnchor="RFC7193">
<front>
<title>The application/cms Media Type</title>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="April"/>
<abstract>
<t>This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7193"/>
<seriesInfo name="DOI" value="10.17487/RFC7193"/>
</reference>
</references>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization showOnFrontPage="true">August Cellars</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
</section>
</back>
</rfc>
|
