idnits 2.17.1 draft-housley-contentcollection-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 38. -- Found old boilerplate from RFC 3978, Section 5.5 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 299. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 68: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 195: '...is specification SHOULD be prepared to...' RFC 2119 keyword, line 198: '...is specification SHOULD also be prepar...' RFC 2119 keyword, line 267: '... MUST be prepared to handle multiple...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2004) is 7092 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CMS' on line 327 looks like a reference -- Missing reference section? 'MSG' on line 55 looks like a reference -- Missing reference section? 'MIME' on line 56 looks like a reference -- Missing reference section? 'ASN1' on line 61 looks like a reference -- Missing reference section? 'STDWORDS' on line 70 looks like a reference -- Missing reference section? 'COMPRESS' on line 316 looks like a reference -- Missing reference section? 'X501' on line 227 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Housley 2 Internet Draft Vigil Security 3 expires in six months November 2004 5 Protecting Multiple Contents with the 6 Cryptographic Message Syntax (CMS) 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 IPR Statement 35 By submitting this Internet-Draft, I certify that any applicable 36 patent or other IPR claims of which I am aware have been disclosed, 37 or will be disclosed, and any of which I become aware will be 38 disclosed, in accordance with RFC 3668. 40 Abstract 42 This document describes a convention for using the Cryptographic 43 Message Syntax (CMS) to protect more than one content. If desired, 44 attributes can be associated with the content. 46 1 Introduction 48 This document describes a convention for using the Cryptographic 49 Message Syntax (CMS) [CMS] to protect more than one content. The 50 content collection content type is used to transfer one or more 51 contents, each identified by a content type. If desired, the content 52 with attributes content type can be used to associate arbitrary 53 attributes with the content. 55 When CMS is used with MIME [MSG], there is no need to use this 56 specification. In this processing environment, MIME multipart [MIME] 57 provides a straightforward and widely deployed mechanism for carrying 58 more than one content, each associated with a MIME type. 60 CMS is not always used with MIME. Sometimes CMS is used in an 61 exclusively ASN.1 [ASN1] environment. In this case, the content 62 collection content type is used to gather more than one content, each 63 with an object identifier to provide the content type. 65 1.1 Terminology 67 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 68 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 69 described in [STDWORDS]. 71 1.2 Content Collection Example 73 This section provides one simple example to motivate the need for the 74 content collection content type. 76 Consider an art collector who wants to sell one of his pieces, an 77 ancient Greek urn, called an amphora. The collector wants to compose 78 a digitally signed offer for sale. It includes three parts. The 79 first part contains the owner's offer for sale, including the asking 80 price. The second part contains a high-quality image of the amphora. 81 The final part contains an appraisal from a well-respected ceramics 82 expert. The final part is digitally signed by the expert. Figure 1 83 illustrates the structure, and the CMS SignedData content type is 84 used for the two digital signatures. 86 +---------------------------------------------------------+ 87 | | 88 | ContentInfo | 89 | | 90 | +-----------------------------------------------------+ | 91 | | | | 92 | | SignedData | | 93 | | | | 94 | | +-------------------------------------------------+ | | 95 | | | | | | 96 | | | ContentCollection | | | 97 | | | | | | 98 | | | +-----------+ +-----------+ +-----------------+ | | | 99 | | | | | | | | | | | | 100 | | | | Owner's | | Image | | SignedData | | | | 101 | | | | Offer to | | of the | | | | | | 102 | | | | Sell the | | Amphora | | +-------------+ | | | | 103 | | | | Amphora | | | | | | | | | | 104 | | | | | | | | | Appraisal | | | | | 105 | | | | | | | | | of Ceramics | | | | | 106 | | | | | | | | | Expert | | | | | 107 | | | | | | | | | | | | | | 108 | | | | | | | | +-------------+ | | | | 109 | | | | | | | | | | | | 110 | | | +-----------+ +-----------+ +-----------------+ | | | 111 | | | | | | 112 | | +-------------------------------------------------+ | | 113 | | | | 114 | +-----------------------------------------------------+ | 115 | | 116 +---------------------------------------------------------+ 118 Figure 1. Sample use of the ContentCollection Content Type. 120 1.3 Content with Attributes Example 122 This section provides one simple example to motivate the need for the 123 content with attributes content type. 125 Consider the same art collector as in the previous example. Instead 126 of providing a single image of the amphora, the collector provides 127 several images. To aid potential buyers, the collector attaches 128 several attributes to each image. The attributes provide information 129 about the resolution of the image, the date the image was taken, the 130 photographer, and so on. Figure 2 illustrates the collection of 131 images, showing only two images, each with three attributes. This 132 entire image content collection could be carried instead of the 133 single image shown in Figure 1, allowing it to be covered by the 134 collector's digital signature. 136 +----------------------------------------------------------+ 137 | | 138 | ContentCollection | 139 | | 140 | +-------------------------+ +-------------------------+ | 141 | | | | | | 142 | | ContentWithAttributes | | ContentWithAttributes | | 143 | | | | | | 144 | | +---------------------+ | | +---------------------+ | | 145 | | | | | | | | | | 146 | | | First Image of | | | | Second Image of | | | 147 | | | the Amphora | | | | the Amphora | | | 148 | | | | | | | | | | 149 | | | | | | | | | | 150 | | +---------------------+ | | +---------------------+ | | 151 | | | | | | 152 | | +---------------+ | | +---------------+ | | 153 | | | | | | | | | | 154 | | | Attribute 1 | | | | Attribute 1 | | | 155 | | | +--+ | | | +--+ | | 156 | | +-+-------------+ | | | +-+-------------+ | | | 157 | | | Attribute 2 | | | | Attribute 2 | | | 158 | | | +--+ | | | +--+ | | 159 | | +-+--------------+ | | | +-+--------------+ | | | 160 | | | Attribute 3 | | | | Attribute 3 | | | 161 | | | | | | | | | | 162 | | +-----------------+ | | +-----------------+ | | 163 | | | | | | 164 | +-------------------------+ +-------------------------+ | 165 | | 166 +----------------------------------------------------------+ 168 Figure 2. Sample use of the ContentWithAttributes Content Type. 170 2 Content Collection Content Type 172 The content collection content type is used to transfer one or more 173 contents, each identified by a content type. The syntax accommodates 174 contents with varying levels of protection. For example, a content 175 collection could include CMS protection content types as well as 176 unprotected content types. A content collection is expected to be 177 encapsulated in one or more CMS protecting content types, but this is 178 not required by this specification. 180 The following object identifier names the content collection content 181 type: 183 id-ct-contentCollection OBJECT IDENTIFIER ::= { 184 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 185 pkcs9(9) smime(16) ct(1) 19 } 187 The content collection content has the following syntax: 189 ContentCollection ::= SEQUENCE SIZE (1..MAX) OF ContentInfo 191 The ContentCollection contains a sequence of ContentInfo, one for 192 each content in the collection. The ContentInfo structure is defined 193 in CMS. The contentType object identifier within the ContentInfo 194 indicates the type of the associated content. Implementations of 195 this specification SHOULD be prepared to handle object identifiers 196 for the SignedData, EncryptedData, EnvelopedData, and 197 AuthenticatedData content types as specified in [CMS]. 198 Implementations of this specification SHOULD also be prepared to 199 handle the object identifier for the CompressedData content type as 200 specified in [COMPRESS]. 202 3 Content With Attributes Content Type 204 The content with attributes content type is used to transfer a single 205 content, which is identified by a content type, and a collection of 206 attributes associated with that content. The syntax accommodates an 207 arbitrary number of attributes; however, there must be at least one 208 attribute. 210 The following object identifier names the content with attributes 211 content type: 213 id-ct-contentWithAttrs OBJECT IDENTIFIER ::= { 214 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 215 pkcs9(9) smime(16) ct(1) 20 } 217 The content with attributes content has the following syntax: 219 ContentWithAttributes ::= SEQUENCE { 220 content ContentInfo, 221 attrs SEQUENCE SIZE (1..MAX) OF Attribute } 223 The ContentWithAttributes contains a sequence of a single 224 ContentInfo, followed by a sequence of attributes. The ContentInfo 225 structure is defined in CMS. The contentType object identifier 226 within the ContentInfo indicates the type of the content. The 227 Attribute structure was originally defined in X.501 [X501], and the 228 definition is repeated in CMS. 230 4 References 232 This section provides normative and informative references. 234 4.1 Normative References 236 ASN1 CCITT. Recommendation X.208: Specification of Abstract 237 Syntax Notation One (ASN.1). 1988. 239 COMPRESS Gutmann, P. Compressed Data Content Type for 240 Cryptographic Message Syntax (CMS). RFC 3274. 241 June 2002. 243 CMS Housley, R. Cryptographic Message Syntax. RFC 3852. 244 July 2004. 246 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 247 Requirement Levels. RFC 2119. March 1997. 249 4.2 Informative References 251 MIME Freed, N., and N. Borenstein. Multipurpose Internet Mail 252 Extensions (MIME) Part One: Format of Internet Message 253 Bodies. RFC 2045, November 1996. 255 X501 CCITT. Recommendation X.501: The Directory -- Models. 256 1988. 258 5 Security Considerations 260 The content collection content type is used to transfer one or more 261 contents, each identified by a content type. The syntax accommodates 262 contents with varying levels of protection. For example, a content 263 collection could include CMS protection content types as well as 264 unprotected content types. A content collection is expected to be 265 encapsulated in one or more CMS protecting content types, but this is 266 not required by this specification. As a result, implementations 267 MUST be prepared to handle multiple levels of encapsulation. 269 The security considerations discussed in [CMS] are relevant when CMS 270 is used to protect more than one content by making use of the content 271 collection content type or content with attributes content type. 273 6 IANA Considerations 275 No IANA actions are needed. 277 7 IPR Considerations 279 The IETF takes no position regarding the validity or scope of any 280 Intellectual Property Rights or other rights that might be claimed to 281 pertain to the implementation or use of the technology described in 282 this document or the extent to which any license under such rights 283 might or might not be available; nor does it represent that it has 284 made any independent effort to identify any such rights. Information 285 on the procedures with respect to rights in RFC documents can be 286 found in BCP 78 and BCP 79. 288 Copies of IPR disclosures made to the IETF Secretariat and any 289 assurances of licenses to be made available, or the result of an 290 attempt made to obtain a general license or permission for the use of 291 such proprietary rights by implementers or users of this 292 specification can be obtained from the IETF on-line IPR repository at 293 http://www.ietf.org/ipr. 295 The IETF invites any interested party to bring to its attention any 296 copyrights, patents or patent applications, or other proprietary 297 rights that may cover technology that may be required to implement 298 this standard. Please address the information to the IETF at ietf- 299 ipr@ietf.org. 301 8 Author's Address 303 Russell Housley 304 Vigil Security, LLC 305 918 Spring Knoll Drive 306 Herndon, VA 20170 307 USA 309 housley@vigilsec.com 311 Appendix A: ASN.1 Module 313 The ASN.1 module contained in this appendix defines the structures 314 that are needed to implement this specification. It is expected to 315 be used in conjunction with the ASN.1 modules in [CMS] and 316 [COMPRESS]. 318 ContentCollectionModule 319 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 320 pkcs-9(9) smime(16) modules(0) 26 } 322 DEFINITIONS IMPLICIT TAGS ::= 323 BEGIN 325 IMPORTS 326 Attribute, ContentInfo 327 FROM CryptographicMessageSyntax -- [CMS] 328 { iso(1) member-body(2) us(840) rsadsi(113549) 329 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }; 331 -- Content Collection Content Type and Object Identifier 333 id-ct-contentCollection OBJECT IDENTIFIER ::= { 334 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 335 pkcs9(9) smime(16) ct(1) 19 } 337 ContentCollection ::= SEQUENCE SIZE (1..MAX) OF ContentInfo 339 -- Content With Attributes Content Type and Object Identifier 341 id-ct-contentWithAttrs OBJECT IDENTIFIER ::= { 342 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 343 pkcs9(9) smime(16) ct(1) 20 } 345 ContentWithAttributes ::= SEQUENCE { 346 content ContentInfo, 347 attrs SEQUENCE SIZE (1..MAX) OF Attribute } 349 END 351 Full Copyright Statement 353 Copyright (C) The Internet Society (2004). This document is subject 354 to the rights, licenses and restrictions contained in BCP 78, and 355 except as set forth therein, the authors retain all their rights. 357 This document and the information contained herein are provided on an 358 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 359 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 360 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 361 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 362 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 363 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.