idnits 2.17.1 draft-ietf-smime-compression-02.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: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 190 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 48: '...entations of CMS SHOULD include this e...' RFC 2119 keyword, line 83: '...Implementations SHOULD use the SMIMECa...' 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 (April 2001) is 8384 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? 'RFC 2630' on line 47 looks like a reference -- Missing reference section? 'ASN1' on line 50 looks like a reference -- Missing reference section? 'RFC2119' on line 55 looks like a reference -- Missing reference section? 'RFC 1950' on line 94 looks like a reference -- Missing reference section? 'RFC 1951' on line 94 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 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-02.txt University of Auckland 3 October 25, 2000 4 Expires April 2001 6 Compressed Data Content Type for S/MIME 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 20 material 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 Abstract 30 The Cryptographic Message Syntax data format doesn't currently 31 contain any provisions for compressing data before processing it. 32 Compressing data before transmission provides a number of advantages 33 including the elimination of data redundancy which could help an 34 attacker, speeding up processing by reducing the amount of data to be 35 processed by later steps such as signing or encryption, and reducing 36 overall message size. Although there have been proposals for adding 37 compression at other levels (for example at the MIME or SSL level) 38 these don't address the problem of compression of CMS content unless 39 the compression is supplied by an external means (for example by 40 intermixing MIME and CMS). This document defines a format for using 41 compressed data as a CMS content type. 43 1. Introduction 45 This document describes a compressed data content encryption type for 46 S/MIME. This is implemented as a new ContentInfo type and is an 47 extension to the types currently defined in CMS [RFC 2630]. Future 48 implementations of CMS SHOULD include this extension. 50 The format of the messages are described in ASN.1 [ASN1]. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 53 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 54 interpreted as described in [RFC2119]. 56 1.1 Compressed Data Content Type 58 The compressed-data content type consists of content of any type 59 compressed using a specified algorithm. The following object 60 identifier identifies the compressed-data content type: 62 id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 63 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 } 65 The compressed-data content type shall have ASN.1 type 66 CompressedData: 68 CompressedData ::= SEQUENCE { 69 version CMSVersion, 70 compressionAlgorithm CompressionAlgorithmIdentifier, 71 encapContentInfo EncapsulatedContentInfo 72 } 74 The fields of type CompressedData have the following meanings: 76 version is the syntax version number. It shall be 0. 78 compressionAlgorithm is a compression algorithm identifier, as 79 defined in section 2. 81 encapContentInfo is the content which is compressed. 83 Implementations SHOULD use the SMIMECapabilities attribute to 84 indicate their ability to process compressed content types. A 85 compression SMIMECapability consists of the AlgorithmIdentifier for 86 the supported compression algorithm, in the case of the algorithm 87 specified in this document this is id-alg-zlibCompression with 88 parameters NULL. Alternatively, the use of compression may be handled 89 by prior arrangement (for example as part of an interoperability 90 profile). 92 2. Compression Types 94 CMS implementations should include ZLIB [RFC 1950] [RFC 1951], which 95 is free of any intellectual property restrictions and has a freely- 96 available, portable and efficient reference implementation. The 97 following object identifier identifies ZLIB: 99 id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2) 100 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 } 102 The parameters for this algorithm are NULL. 104 3. Security Considerations 106 This RFC is not concerned with security, except for the fact that 107 compressing data before encryption can enhance the security provided 108 by other processing steps by reducing the quantity of known plaintext 109 available to an attacker. 111 Author Address 113 Peter Gutmann 114 University of Auckland 115 Private Bag 92019 116 Auckland, New Zealand 117 pgut001@cs.auckland.ac.nz 119 References 121 ASN1 Recommendation X.680: Specification of Abstract Syntax 122 Notation One (ASN.1), 1994. 124 RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, 125 S.Bradner, March 1997. 127 RFC1950 ZLIB Compressed Data Format Specification version 3.3, 128 P.Deutsch and J-L Gailly, May 1996. 130 RFC1951 DEFLATE Compressed Data Format Specification version 1.3, 131 P.Deutsch, May 1996. 133 RFC 2630 Cryptographic Message Syntax, R.Housley, June 1999. 135 Appendix A: ASN.1 Module 137 CompressedDataContent 138 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 139 smime(16) modules(0) compress(11) } 141 DEFINITIONS IMPLICIT TAGS ::= 142 BEGIN 144 IMPORTS 145 CMSVersion, EncapsulatedContentInfo FROM CryptographicMessageSyntax 146 { iso(1) member-body(2) us(840) rsadsi(113549) 147 pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }, 148 AlgorithmIdentifier FROM AuthenticationFramework 149 { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }; 151 CompressedData ::= SEQUENCE { 152 version CMSVersion, -- Always set to 0 153 compressionAlgorithm CompressionAlgorithmIdentifier, 154 encapContentInfo EncapsulatedContentInfo 155 } 157 CompressionAlgorithmIdentifer ::= AlgorithmIdentifier 159 END 161 Full Copyright Statement 163 Copyright (C) The Internet Society 2000. All Rights Reserved. 165 This document and translations of it may be copied and furnished to 166 others, and derivative works that comment on or otherwise explain it 167 or assist in its implementation may be prepared, copied, published 168 and distributed, in whole or in part, without restriction of any 169 kind, provided that the above copyright notice and this paragraph are 170 included on all such copies and derivative works. However, this 171 document itself may not be modified in any way, such as by removing 172 the copyright notice or references to the Internet Society or other 173 Internet organizations, except as needed for the purpose of 174 developing Internet standards in which case the procedures for 175 copyrights defined in the Internet Standards process must be 176 followed, or as required to translate it into languages other than 177 English. 179 The limited permissions granted above are perpetual and will not be 180 revoked by the Internet Society or its successors or assigns. 182 This document and the information contained herein is provided on an 183 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 184 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 185 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 186 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 187 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.