[要約] RFC 3274は、CMSで使用される圧縮データコンテンツタイプに関する仕様です。その目的は、データの圧縮と暗号化を組み合わせることで、効率的なデータ転送と保護を実現することです。

Network Working Group                                         P. Gutmann
Request for Comments: 3274                        University of Auckland
Category: Standards Track                                      June 2002
        

Compressed Data Content Type for Cryptographic Message Syntax (CMS)

暗号化メッセージ構文(CMS)の圧縮データコンテンツタイプ

Status of this Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright(C)The Internet Society(2002)。全著作権所有。

Abstract

概要

This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS).

このドキュメントでは、圧縮データを暗号化メッセージ構文(CMS)コンテンツタイプとして使用するための形式を定義します。送信前にデータを圧縮すると、攻撃者に役立つ可能性のあるデータの冗長性の排除、後の手順(署名や暗号化など)で処理するデータの量を減らして処理を高速化すること、メッセージ全体のサイズを減らすことなど、多くの利点があります。 。他のレベル(たとえば、MIMEまたはSSLレベル)で圧縮を追加する提案はありますが、これらは、外部手段(MIMEとMIMEの混合など)によって圧縮が提供されない限り、CMSコンテンツの圧縮の問題に対処しません。 CMS)。

1. Introduction
1. はじめに

This document describes a compressed data content type for CMS. This is implemented as a new ContentInfo type and is an extension to the types currently defined in CMS [RFC2630]. CMS implementations SHOULD include support for the CompressedData content type.

このドキュメントでは、CMSの圧縮データコンテンツタイプについて説明します。これは新しいContentInfoタイプとして実装され、CMS [RFC2630]で現在定義されているタイプの拡張です。 CMSの実装には、CompressedDataコンテンツタイプのサポートを含める必要があります(SHOULD)。

The format of the messages are described in ASN.1 [ASN1].

メッセージのフォーマットは、ASN.1 [ASN1]で説明されています。

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119]で説明されているように解釈されます。 。

1.1 Compressed Data Content Type
1.1 圧縮データコンテンツタイプ

The compressed-data content type consists of content of any type, compressed using a specified algorithm. The following object identifier identifies the compressed-data content type:

圧縮データコンテンツタイプは、指定されたアルゴリズムを使用して圧縮された任意のタイプのコンテンツで構成されます。次のオブジェクト識別子は、圧縮データのコンテンツタイプを識別します。

      id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 }
        

The compressed-data content type shall have ASN.1 type CompressedData:

圧縮データコンテンツタイプは、ASN.1タイプCompressedDataを持つ必要があります。

      CompressedData ::= SEQUENCE {
        version CMSVersion,
        compressionAlgorithm CompressionAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo
        }
        

The fields of type CompressedData have the following meanings:

タイプCompressedDataのフィールドには以下の意味があります。

version is the syntax version number. It MUST be 0. Details of the CMSVersion type are discussed in CMS [RFC2630], section 10.2.5.

versionは構文のバージョン番号です。 CMSVersionタイプの詳細は、CMS [RFC2630]のセクション10.2.5で説明されています。

compressionAlgorithm is a compression algorithm identifier, as defined in section 2.

compressionAlgorithmは、セクション2で定義されている圧縮アルゴリズムの識別子です。

encapContentInfo is the content which is compressed. Details of the EncapsulatedContentInfo type are discussed in CMS [RFC2630], section 5.2.

encapContentInfoは圧縮されたコンテンツです。 EncapsulatedContentInfoタイプの詳細については、CMS [RFC2630]のセクション5.2で説明しています。

Implementations SHOULD use the SMIMECapabilities attribute to indicate their ability to process compressed content types. Details of SMIMECapabilities are discussed in MSG [RFC2633], section 2.5.2.

実装では、SMIMECapabilities属性を使用して、圧縮されたコンテンツタイプを処理する機能を示す必要があります(SHOULD)。 SMIMECapabilitiesの詳細については、MSG [RFC2633]のセクション2.5.2で説明しています。

A compression SMIMECapability consists of the AlgorithmIdentifier for the supported compression algorithm. In the case of the algorithm specified in this document, this is id-alg-zlibCompression, as specified in section 2. Alternatively, the use of compression may be handled by prior arrangement (for example as part of an interoperability profile).

圧縮SMIMECapabilityは、サポートされている圧縮アルゴリズムのAlgorithmIdentifierで構成されています。このドキュメントで指定されているアルゴリズムの場合、これはセクション2で指定されているid-alg-zlibCompressionです。あるいは、圧縮の使用は、事前の取り決め(たとえば、相互運用性プロファイルの一部として)で処理できます。

The SMIMECapability SEQUENCE representing the ability to process content compressed with the algorithm identified by id-alg-zlibCompression MUST be DER-encoded as the following hexadecimal string:

id-alg-zlibCompressionで識別されたアルゴリズムで圧縮されたコンテンツを処理する機能を表すSMIMECapability SEQUENCEは、次の16進文字列としてDERでエンコードする必要があります。

30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 08

30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 03 08

(but see also the implementation note in section 2.1).

(ただし、セクション2.1の実装ノートも参照してください)。

2. Compression Types
2. 圧縮タイプ

CMS implementations that support the CompressedData content type MUST include support for the ZLIB compression algorithm [RFC1950] [RFC1951], which has a freely-available, portable and efficient reference implementation. The following object identifier identifies ZLIB:

CompressedDataコンテンツタイプをサポートするCMS実装には、ZLIB圧縮アルゴリズム[RFC1950] [RFC1951]のサポートが含まれている必要があります。これには、自由に利用できる、移植可能で効率的なリファレンス実装があります。次のオブジェクト識別子はZLIBを識別します。

      id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2)
        us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 }
        

This algorithm has no parameters. The parameters field SHOULD be encoded as omitted, but MAY be encoded as NULL (see the implementation note in section 2.1).

このアルゴリズムにはパラメーターがありません。パラメータフィールドは省略としてエンコードする必要があります(SHOULD)がNULLとしてエンコードされる場合があります(セクション2.1の実装ノートを参照)。

2.1. Implementation notes
2.1. 実装上の注意

ZLIB allows for a number of compression levels ranging from good but slow compression, to less good but fast compression. The compression level is always compatible with the decompression algorithm, so there is no need to specify the compression level as an algorithm parameter.

ZLIBは、圧縮率が高いが遅い圧縮から、圧縮率は低いが高速な圧縮まで、さまざまな圧縮レベルを可能にします。圧縮レベルは常に解凍アルゴリズムと互換性があるため、アルゴリズムパラメーターとして圧縮レベルを指定する必要はありません。

There are two possible encodings for the ZLIB null parameters field which arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later it was recovered via a defect report, but by then, everyone thought that algorithm parameters were mandatory. Because of this, some implementations will encode null parameters as an ASN.1 NULL element and some will omit them entirely (see for example section 12 of CMS [RFC2630]). Although the correct encoding is to omit the parameters field, implementations may encounter encodings which use an ASN.1 NULL element for the parameters.

ZLIB nullパラメータフィールドには、AlgorithmIdentifierの1988構文が1997構文に変換されたときに、AlgorithmIdentifierパラメータに関連付けられたOPTIONALが失われたという事実から生じる2つの可能なエンコーディングがあります。後でそれは欠陥レポートによって回復されましたが、それまでに、誰もがアルゴリズムパラメータが必須であると考えました。このため、一部の実装はnullパラメータをASN.1 NULL要素としてエンコードし、一部は完全に省略します(たとえば、CMS [RFC2630]のセクション12を参照)。正しいエンコーディングはパラメータフィールドを省略することですが、実装では、パラメータにASN.1 NULL要素を使用するエンコーディングが発生する場合があります。

3. Security Considerations
3. セキュリティに関する考慮事項

This RFC is not concerned with security, except for the fact that compressing data before encryption can enhance the security provided by other processing steps by reducing the quantity of known plaintext available to an attacker. However, implementations should be aware of possible security threats of combining security sensitive material with possibly untrusted data before the compression and encryption. This is because information about the sensitive data may be inferred from knowing the untrusted data and the compression ratio.

このRFCは、暗号化の前にデータを圧縮すると、攻撃者が利用できる既知の平文の量を減らすことにより、他の処理手順によって提供されるセキュリティを強化できるという事実を除いて、セキュリティには関係しません。ただし、実装では、圧縮と暗号化の前に、セキュリティ上重要な資料と信頼できない可能性のあるデータを組み合わせることで起こりうるセキュリティ上の脅威に注意する必要があります。これは、機密データに関する情報が、信頼できないデータと圧縮率を知ることから推測される可能性があるためです。

4. IANA Considerations
4. IANAに関する考慮事項

The CompressedData content type and compression algorithms are identified by object identifiers (OIDs). OIDs were assigned from an arc contributed to the S/MIME Working Group by RSA Security. Should additional compression algorithms be introduced, the advocates for such algorithms are expected to assign the necessary OIDs from their own arcs. No action by the IANA is necessary for this document or any anticipated updates.

CompressedDataコンテンツタイプと圧縮アルゴリズムは、オブジェクト識別子(OID)によって識別されます。 OIDは、RSA SecurityによってS / MIMEワーキンググループに提供された弧から割り当てられました。追加の圧縮アルゴリズムが導入された場合、そのようなアルゴリズムの擁護者は、独自のアークから必要なOIDを割り当てることが期待されます。このドキュメントまたは予想される更新については、IANAによるアクションは必要ありません。

References

参考文献

[ASN1] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.

[ASN1] CCITT勧告X.208:抽象構文記法1(ASN.1)の仕様、1988。

[RFC2119] Bradner, S., "Key Words for Use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC1950] Deutsch, P. and J-L Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.

[RFC1950] Deutsch、P。およびJ-L Gailly、「ZLIB Compressed Data Format Specification version 3.3」、RFC 1950、1996年5月。

[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.

[RFC1951] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、1996年5月。

[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

[RFC2630] Housley、R。、「Cryptographic Message Syntax」、RFC 2630、1999年6月。

[RFC2633] Rmasdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

[RFC2633] Rmasdell、B。、「S / MIMEバージョン3メッセージ仕様」、RFC 2633、1999年6月。

Appendix A: ASN.1 Module

付録A:ASN.1モジュール

   CompressedDataContent
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) compress(11) }
        
   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN
        
   IMPORTS
     CMSVersion, EncapsulatedContentInfo FROM CryptographicMessageSyntax
       { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
     AlgorithmIdentifier FROM AuthenticationFramework
       { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 };
        
   CompressedData ::= SEQUENCE {
     version CMSVersion,       -- Always set to 0
     compressionAlgorithm CompressionAlgorithmIdentifier,
     encapContentInfo EncapsulatedContentInfo
     }
        
   CompressionAlgorithmIdentifier ::= AlgorithmIdentifier
        

-- Algorithm Identifiers

-アルゴリズム識別子

   id-alg-zlibCompress OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 8 }
        

-- Content Type Object Identifiers

-コンテンツタイプオブジェクト識別子

   id-ct-compressedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 9 }
        

END

終わり

Author Address

著者アドレス

Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand

ピーターグットマンオークランド大学プライベートバッグ92019オークランド、ニュージーランド

   EMail: pgut001@cs.auckland.ac.nz
        

Full Copyright Statement

完全な著作権表示

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright(C)The Internet Society(2002)。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。