idnits 2.17.1 draft-ietf-smime-compression-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 244 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 50: '...CMS SHOULD include this extension....' RFC 2119 keyword, line 77: '...sion number. It MUST be 0. Details o...' RFC 2119 keyword, line 87: '...Implementations SHOULD use the SMIMECa...' RFC 2119 keyword, line 99: '...zlibCompression MUST be DER-encoded as...' RFC 2119 keyword, line 108: '...CMS implementations SHOULD include ZLIB [RFC1950] [RFC1951], which is...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (January 2002) is 8137 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? 'RFC2630' on line 134 looks like a reference -- Missing reference section? 'ASN1' on line 52 looks like a reference -- Missing reference section? 'RFC2119' on line 57 looks like a reference -- Missing reference section? 'RFC2633' on line 89 looks like a reference -- Missing reference section? 'RFC1950' on line 108 looks like a reference -- Missing reference section? 'RFC1951' on line 108 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Peter Gutmann 2 draft-ietf-smime-compression-05.txt University of Auckland 3 July 17, 2001 4 Expires January 2002 6 Compressed Data Content Type for CMS 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright (C) The Internet Society July 2001. All Rights Reserved. 30 Abstract 32 The Cryptographic Message Syntax data format doesn't currently contain 33 any provisions for compressing data before processing it. Compressing 34 data before transmission provides a number of advantages including the 35 elimination of data redundancy which could help an attacker, speeding 36 up processing by reducing the amount of data to be processed by later 37 steps such as signing or encryption, and reducing overall message size. 38 Although there have been proposals for adding compression at other 39 levels (for example at the MIME or SSL level) these don't address the 40 problem of compression of CMS content unless the compression is 41 supplied by an external means (for example by intermixing MIME and 42 CMS). This document defines a format for using compressed data as a 43 CMS content type. 45 1. Introduction 47 This document describes a compressed data content type for S/MIME. This 48 is implemented as a new ContentInfo type and is an extension to the 49 types currently defined in CMS [RFC2630]. Future implementations of 50 CMS SHOULD include this extension. 52 The format of the messages are described in ASN.1 [ASN1]. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 55 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 56 interpreted as described in [RFC2119]. 58 1.1 Compressed Data Content Type 60 The compressed-data content type consists of content of any type 61 compressed using a specified algorithm. The following object 62 identifier identifies the compressed-data content type: 64 id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 65 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 } 67 The compressed-data content type shall have ASN.1 type CompressedData: 69 CompressedData ::= SEQUENCE { 70 version CMSVersion, 71 compressionAlgorithm CompressionAlgorithmIdentifier, 72 encapContentInfo EncapsulatedContentInfo 73 } 75 The fields of type CompressedData have the following meanings: 77 version is the syntax version number. It MUST be 0. Details of the 78 CMSVersion type are discussed in CMS [RFC2630], section 10.2.5. 80 compressionAlgorithm is a compression algorithm identifier, as 81 defined in section 2. 83 encapContentInfo is the content which is compressed. Details of the 84 EncapsulatedContentInfo type are discussed in CMS [RFC2630], section 85 5.2. 87 Implementations SHOULD use the SMIMECapabilities attribute to indicate 88 their ability to process compressed content types. Details of 89 SMIMECapabilities are discussed in MSG [RFC2633], section 2.5.2 91 A compression SMIMECapability consists of the AlgorithmIdentifier for 92 the supported compression algorithm, in the case of the algorithm 93 specified in this document this is id-alg-zlibCompression as specified 94 in section 2. Alternatively, the use of compression may be handled by 95 prior arrangement (for example as part of an interoperability profile). 97 The SMIMECapability SEQUENCE representing the ability to process 98 content compressed with the algorithm identified by id-alg- 99 zlibCompression MUST be DER-encoded as the following hexadecimal 100 string: 102 30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 08 104 (but see also the implementation note in section 2.1). 106 2. Compression Types 108 CMS implementations SHOULD include ZLIB [RFC1950] [RFC1951], which is 109 free of any intellectual property restrictions and has a freely- 110 available, portable and efficient reference implementation. The 111 following object identifier identifies ZLIB: 113 id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2) 114 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 } 116 This algorithm has null parameters (but see the implementation note in 117 section 2.1 for comments on this field). 119 2.1. Implementation notes 121 ZLIB allows for a number of compression levels ranging from good but 122 slow compression to less good but fast compression. The compression 123 level is always compatible with the decompression algorithm, so there 124 is no need to specify the compression level as an algorithm parameter. 126 There are two possible encodings for the ZLIB null parameters field 127 which arise from the fact that when the 1988 syntax for 128 AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL 129 associated with the AlgorithmIdentifier parameters got lost. Later it 130 was recovered via a defect report, but by then everyone thought that 131 algorithm parameters were mandatory. Because of this some 132 implementations will encode null parameters as an ASN.1 NULL element 133 and some will omit them entirely (see for example section 12 of CMS 134 [RFC2630]). Although the correct encoding is to omit the parameters 135 field, implementations may encounter encodings which use an ASN.1 NULL 136 element for the parameters. 138 3. Security Considerations 140 This RFC is not concerned with security, except for the fact that 141 compressing data before encryption can enhance the security provided by 142 other processing steps by reducing the quantity of known plaintext 143 available to an attacker. 145 4. IANA Considerations 147 The CompressedData content type and compression algorithms are 148 identified by object identifiers (OIDs). OIDs were assigned from an 149 arc contributed to the S/MIME Working Group by the RSA Security. 150 Should additional compression algorithms be introduced, the advocates 151 for such algorithms are expected to assign the necessary OIDs from 152 their own arcs. No action by the IANA is necessary for this document 153 or any anticipated updates. 155 Author Address 157 Peter Gutmann 158 University of Auckland 159 Private Bag 92019 160 Auckland, New Zealand 161 pgut001@cs.auckland.ac.nz 163 References 165 ASN1 CCITT Recommendation X.208: Specification of Abstract Syntax 166 Notation One (ASN.1), 1988. 168 RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, 169 S.Bradner, March 1997. 171 RFC1950 ZLIB Compressed Data Format Specification version 3.3, 172 P.Deutsch and J-L Gailly, May 1996. 174 RFC1951 DEFLATE Compressed Data Format Specification version 1.3, 175 P.Deutsch, May 1996. 177 RFC2630 Cryptographic Message Syntax, R.Housley, June 1999. 179 RFC2633 S/MIME Version 3 Message Specification, B.Ramsdell, June 180 1999. 182 Appendix A: ASN.1 Module 184 CompressedDataContent 185 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 186 smime(16) modules(0) compress(11) } 188 DEFINITIONS IMPLICIT TAGS ::= 189 BEGIN 191 IMPORTS 192 CMSVersion, EncapsulatedContentInfo FROM CryptographicMessageSyntax 193 { iso(1) member-body(2) us(840) rsadsi(113549) 194 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }, 195 AlgorithmIdentifier FROM AuthenticationFramework 196 { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }; 198 CompressedData ::= SEQUENCE { 199 version CMSVersion, -- Always set to 0 200 compressionAlgorithm CompressionAlgorithmIdentifier, 201 encapContentInfo EncapsulatedContentInfo 202 } 204 CompressionAlgorithmIdentifer ::= AlgorithmIdentifier 206 -- Algorithm Identifiers 208 id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2) 209 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 } 211 -- Content Type Object Identifiers 213 id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 214 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 } 216 END 218 Full Copyright Statement 220 Copyright (C) The Internet Society 2001. All Rights Reserved. 222 This document and translations of it may be copied and furnished to 223 others, and derivative works that comment on or otherwise explain it or 224 assist in its implementation may be prepared, copied, published and 225 distributed, in whole or in part, without restriction of any kind, 226 provided that the above copyright notice and this paragraph are 227 included on all such copies and derivative works. However, this 228 document itself may not be modified in any way, such as by removing the 229 copyright notice or references to the Internet Society or other 230 Internet organizations, except as needed for the purpose of developing 231 Internet standards in which case the procedures for copyrights defined 232 in the Internet Standards process must be followed, or as required to 233 translate it into languages other than English. 235 The limited permissions granted above are perpetual and will not be 236 revoked by the Internet Society or its successors or assigns. 238 This document and the information contained herein is provided on an 239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 241 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 242 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 243 FITNESS FOR A PARTICULAR PURPOSE.