idnits 2.17.1 draft-schaad-cbor-content-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 31, 2019) is 1700 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7049 (ref. 'CBOR') (Obsoleted by RFC 8949) == Outdated reference: A later version (-02) exists of draft-ietf-cbor-sequence-01 ** Obsolete normative reference: RFC 8152 (ref. 'COSE') (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Informational August 31, 2019 5 Expires: March 3, 2020 7 CMS Content Types for CBOR 8 draft-schaad-cbor-content-01 10 Abstract 12 CBOR is becoming a widely used method of doing content encoding. CMS 13 is still a widely used method of doing message based security. This 14 document defines a set of content types for CMS that hold CBOR 15 content. 17 Contributing to this document 19 This note is to be removed before publishing as an RFC. 21 The source for this draft is being maintained in GitHub. Suggested 22 changes should be submitted as pull requests at TBD. Editorial 23 changes can be managed in GitHub, but any substantial issues need to 24 be discussed on the COSE mailing list. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 3, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. CBOR Content Type . . . . . . . . . . . . . . . . . . . . . . 2 61 3. CBOR Sequence Content Type . . . . . . . . . . . . . . . . . 3 62 4. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 CBOR [CBOR] is a compact self describing binary encoding formation 71 that is starting to be used in many different applications. One of 72 the primary uses of CBOR is in the Internet of Things where the 73 constrained nature means that having minimal size of encodings 74 becomes very important. The use of the Cryptographic Message System 75 (CMS) [CMS] is still one of the most common method for providing 76 message based security, although in many cases the CBOR Object 77 Signing and Encryption (COSE) [COSE] message based security system is 78 starting to be used. Given that CBOR is going to be transported 79 using CMS, it makes sense to define CMS content types for the purpose 80 of denoting that the embedded content is CBOR. This document defines 81 two new content types: CBOR Content Type and CBOR Sequence Content 82 Type [CBOR-SEQ]. 84 2. CBOR Content Type 86 [CBOR] defines an encoded CBOR item. This section defines a new 87 content type for wrapping an encoded CBOR item in a CMS object. 89 The following object identifier identifies the CBOR content type: 91 id-ct-cbor OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) 92 rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) TBD1 } 94 The CBOR content type is intended to refer to a single object encoded 95 using the CBOR encoding format [CBOR]. Nothing is stated about the 96 specific CBOR object that is included. CBOR can always be decoded to 97 a tree as the encoding is self descriptive. 99 The CBOR content type is intended to be encapsulated in the signed 100 data and auth-enveloped data, but can be included in any CMS wrapper. 101 It cannot be predicted if the compressed CMS encapsulation will 102 provide compression as the content may be binary rather than text. 104 [RFC7193] defined an optional parameter "innerContent" to allow for 105 identification of what the inner content is for an application/cms 106 media type. This document defines the string "cbor" as a new value 107 that can be placed here when a CBOR content type is used. 109 3. CBOR Sequence Content Type 111 [CBOR-SEQ] defines a CBOR Sequence as a concatenation of zero or more 112 CBOR objects. This section defines a new content type for wrapping a 113 CBOR Sequence in a CMS object. 115 The following object identifier identifies the CBOR Sequence content 116 type: 118 id-ct-cborSequence OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) 119 rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) TBD2 } 121 The CBOR Sequence content type is intended to refer to a sequence of 122 objects encoded using the CBOR encoding format. The objects are 123 concatenated without any markers delimiting the individual CBOR 124 objects. Nothing is stated about the specific CBOR objects that are 125 included. CBOR can always be decoded to a tree as the encoding is 126 self descriptive. 128 The CBOR Sequence content type is intended to be encapsulated in the 129 signed data and auth-enveloped data, but can be included in any CMS 130 wrapper. It cannot be predicted if the compressed CMS encapsulation 131 will provide compression as the content may be binary rather than 132 text. 134 [RFC7193] defined an optional parameter "innerContent" to allow for 135 identification of what the inner content is for an application/cms 136 media type. This document defines the string "cborSequence" as a new 137 value that can be placed here when a CBOR Sequence content type is 138 used. 140 4. ASN.1 Module 141 CborContentTypes { iso(1) member-body(2) usa(840) 142 rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 0 id-mod-cbor-2019(TBD3) } 143 DEFINITIONS EXPLICIT TAGS ::= 144 BEGIN 145 IMPORTS 147 CONTENT-TYPE 148 FROM CryptographicMessageSyntax-2010 149 { iso(1) member-body(2) us(840) rsadsi(113549) 150 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 151 ; 153 id-ct-cbor OBJECT IDENTIFIER ::= { iso(1) member-body(2) 154 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) TBD1 } 156 id-ct-cborSequence OBJECT IDENTIFIER ::= { iso(1) member-body(2) 157 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) TBD2 } 159 -- Content is encoded directly and does not have any ASN.1 structure 160 ct-Cbor CONTENT-TYPE ::= { IDENTIFIED BY id-ct-cbor } 162 -- Content is encoded directly and does not have any ASN.1 structure 163 ct-CborSequence CONTENT-TYPE ::= { IDENTIFIED BY id-ct-cborSequence } 165 END 167 5. IANA Considerations 169 In the "SMI Security for S/MIME Module Identifier" registry, create a 170 new entry to point to this document. 172 +---------+------------------+-----------------+ 173 | Decimal | Description | References | 174 +=========+==================+=================+ 175 | TBD3 | id-mod-cbor-2019 | [[This Document | 176 +---------+------------------+-----------------+ 178 Table 1 180 In the "SMI Security for S/MIME Content Types" registry, add two new 181 entries for id-ct-cbor and id-ct-cborSequence that point to this 182 document. 184 +---------+--------------------+-------------------+ 185 | Decimal | Description | References | 186 +=========+====================+===================+ 187 | TBD1 | id-ct-cbor | [[This Document]] | 188 +---------+--------------------+-------------------+ 189 | TBD2 | id-ct-cborSequence | [[This Document]] | 190 +---------+--------------------+-------------------+ 192 Table 2 194 In the table "CMS Inner Content Types" add two new entries: 196 +--------------+------------------------------+-------------------+ 197 | Name | Object Identifier | Reference | 198 +==============+==============================+===================+ 199 | cbor | 1.2.840.113549.1.9.16.1.TBD | [[This Document]] | 200 +--------------+------------------------------+-------------------+ 201 | cborSequence | 1.2.840.113549.1.9.16.1.TBD2 | [[This Document]] | 202 +--------------+------------------------------+-------------------+ 204 Table 3 206 6. Security Considerations 208 This document only provides identification for content types, it does 209 not introduce any new security issues by itself. The new content 210 types does mean that id-data does not need to be used to identify 211 these content types and thus can reduce confusion. 213 7. Normative References 215 [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object 216 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 217 October 2013, . 219 [CBOR-SEQ] Bormann, C., "Concise Binary Object Representation (CBOR) 220 Sequences", draft-ietf-cbor-sequence-01 (work in 221 progress), August 30, 2019, 222 . 225 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 226 RFC 5652, DOI 10.17487/RFC5652, September 2009, 227 . 229 [COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 230 RFC 8152, DOI 10.17487/RFC8152, July 2017, 231 . 233 [RFC7193] Turner, S., Housley, R., and J. Schaad, "The application/ 234 cms Media Type", RFC 7193, DOI 10.17487/RFC7193, April 235 2014, . 237 Author's Address 239 Jim Schaad 240 August Cellars 242 Email: ietf@augustcellars.com