A. オブジェクト識別子と構文
EnglishSMIMECapability の構文は次の通りです。：
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters OPTIONAL ANY DEFINED BY capabilityID }
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
A.1 コンテント暗号化アルゴリズム
RC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2}
有効鍵ビット（鍵サイズ）が 32 以上、256 以下の場合、RC2-CBC
アルゴリズム パラメータは次のようにエンコードされます。：
RC2-CBC parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv OCTET STRING (8)}
有効鍵ビットが 40、64、および 128 の場合、rc2ParameterVersion の値はそれぞれ 160、120、58 となります。
DES-EDE3-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7}
DES-CBC および DES-EDE3-CBC
の場合、パラメータは次のようにエンコードされる必要があります：
CBCParameter :: IV
where IV ::= OCTET STRING -- 8 octets.
A.2 ダイジェスト アルゴリズム
md5 OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}
sha-1 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26}
A.3 非対称暗号アルゴリズム
rsaEncryption OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
rsa OBJECT IDENTIFIER ::=
{joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
A.4 署名アルゴリズム
md2WithRSAEncryption OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2}
md5WithRSAEncryption OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4}
sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
A.5 署名属性
signingTime OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}
smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," IEEE Spectrum, v. 16, n. 7, 1979年 7月, pp40-41.
[CHARSETS] Character sets assigned by IANA. See
<ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>.[CONTDISP] Troost, R., Dorner, S and K. Moore,
"Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field", RFC 2183, 1997年 8月.[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983年.
[MD5] Rivest, R.,
"The MD5 Message Digest Algorithm",
RFC 1321, 1992年 4月.[MIME-SPEC] The primary definition of MIME.
Freed, N., and N. Borenstein,
"MIME Part 1: Format of Internet Message Bodies",
RFC 2045, 1996年11月.Freed, N., and N. Borenstein,
"MIME Part 2: Media Types",
RFC 2046, 1996年11月.Moore, K.,
"MIME Part 3: Message Header Extensions for Non-ASCII Text",
RFC 2047, 1996年11月.Freed, N., Klensin, J., and J. Postel,
"MIME Part 4: Registration Procedures",
RFC 2048, 1996年11月.Freed, N., and N. Borenstein,
"MIME Part 5: Conformance Criteria and Examples",
RFC 2049, 1996年11月.[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, 1995年10月.[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, 1997年 3月.[PKCS-1] Kaliski, B.,
"PKCS #1: RSA Encryption Version 1.5",
RFC 2313, 1998年 3月.[PKCS-7] Kaliski, B.,
"PKCS #7: Cryptographic Message Syntax Version 1.5",
RFC 2315, 1998年 3月.[PKCS-10] Kaliski, B.,
"PKCS #10: Certification Request Syntax Version 1.5",
RFC 2314, 1998年 3月.[RC2] Rivest, R.,
"Description of the RC2(r) Encryption Algorithm",
RFC 2268, 1998年 1月.[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, DRAFT, 31 May 1994.
S/MIME は RSA データ セキュリティ社（RSA Data Security, Inc.）が開発したものです。 この文書の公開前に多くの開発者が S/MIME エージェントを実装していました。 S/MIME 受信エージェントはすべて、こうした古い S/MIME 実装と相互運用できるよう、あらゆる努力を払う必要があります（SHOULD）。
C.1 古い MIME タイプ
S/MIME エージェントの古い実装の中には、下記の MIME タイプを使用するものがあります：
application/x-pkcs7-mime application/x-pkcs7-signature application/x-pkcs10各タイプにある「x-」サブタイプは、この文書で「x-」を付さずに記述したサブタイプに対応しています。
C.2 プロフィール
以前の S/MIME 文書化は暗号化のための 2 つのプロフィールを持っていました。 「制限型」と「非制限型」がそれです。 これらのプロフィールの違いは、このセクションの最後で説明しているように、米国政府の輸出規則により歴史的に生じたものです。 将来的には、制限型プロフィールだけを使うエージェントがほとんどなくなることが期待されています。
簡単に説明すると、制限型プロフィールは、40 ビット鍵の CBC モードで RSA の trade-secret RC2 アルゴリズムを使って暗号化と解読を行う能力が要求されます。 非制限型プロフィールは、40 ビット鍵の CBC モードで RSA の trade-secret RC2 アルゴリズムを使って暗号化と解読を行う能力と、tripleDES を使って暗号化と解読を行う能力が要求されます。 制限型プロフィールはまた、他のアルゴリズムに対する非強制的な暗示を持っていますが、これは広く実装されてはいません。
現在の S/MIME 実装の多くが制限型プロフィールを使っていることに注意することが重要です。
C.2.1 2つの暗号化プロフィールが存在する歴史的な理由
米国政府の輸出規則のため、DES のような強力なコンテント暗号化アルゴリズムをサポートする S/MIME エージェントは、北米の域外に自由に輸出することはできません。 米国のソフトウェア業者は、広く輸出できる製品を製造するため、輸出可能な、すなわち「制限型」のコンテント暗号化アルゴリズムを採用することを余儀なくされてきました。 米国で製造され、米国内での使用（もしくは国務省の特別輸出許可のもとでの使用）を目的とする S/MIME エージェントは、より強力な「非制限型」のコンテント暗号方式を利用することができます。 しかし、相互運用性を達成するため、この種のエージェントは、制限型 S/MIME エージェントに採用された輸出可能なアルゴリズムをすべてサポートする必要があります。
RC2 対称暗号アルゴリズムは、特定の鍵サイズに限って許可する「便宜的」輸出のため、米国政府に認可されています。 その結果、すべての S/MIME 実装の基本的な相互運用性を確保するために、CBC モードの RC2 アルゴリズムのサポートが必要となっています。RC5 CBC や DES CBC、DES EDE3-CBC のような、コンテント暗号化のための他の強力な対称暗号アルゴリズムについては、可能であればサポートすることが強く奨励されます。
D.1 application/pkcs7-mime
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-mimeMIME media type name: application
MIME subtype name: pkcs7-mime
Required parameters: none
Optional parameters: name, filename, smime-type
Encoding considerations: Will be binary data, therefore should use base64 encoding
Security considerations: Described in [PKCS-7]
Interoperability considerations: Designed to carry data formatted with PKCS-7, as described in [PKCS-7]
Published specification: RFC 2311
Applications which use this media type: Secure Internet mail and other secure data transports.
Additional information:
File extension(s): .p7m and .p7c
Macintosh File Type Code(s):Person & email address to contact for further information:
Steve Dusse, spock@rsa.comIntended usage: COMMON
D.2 application/pkcs7-signature
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-signatureMIME media type name: application
MIME subtype name: pkcs7-signature
Required parameters: none
Optional parameters: name, filename
Encoding considerations: Will be binary data, therefore should use base64 encoding
Security considerations: Described in [PKCS-7]
Interoperability considerations: Designed to carry digital signatures with PKCS-7, as described in [PKCS-7]
Published specification: RFC 2311
Applications which use this media type: Secure Internet mail and other secure data transports.
Additional information:
File extension(s): .p7s
Macintosh File Type Code(s):
Person & email address to contact for further information: Steve Dusse, spock@rsa.comIntended usage: COMMON
D.3 application/pkcs10
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs10MIME media type name: application
MIME subtype name: pkcs10
Required parameters: none
Optional parameters: name, filename
Encoding considerations: Will be binary data, therefore should use base64 encoding
Security considerations: Described in [PKCS-10]
Interoperability considerations: Designed to carry digital certificates formatted with PKCS-10, as described in [PKCS-10]
Published specification: RFC 2311
Applications which use this media type: Secure Internet mail and other transports where certificates are required.
Additional information:
File extension(s): .p10
Macintosh File Type Code(s):Person & email address to contact for further information:
Steve Dusse, spock@rsa.comIntended usage: COMMON
複数の署名フォーマットの背後にある原理は、アプリケーションおよびトップ レベルのマルチパート タイプの規則をデフォルトする MIME サブタイプと、現在展開されているゲートウェイおよびメール ユーザ エージェントの動作を処理しなければなりません。multipart/signed フォーマットを唯一の使用フォーマットとすることが理想的です。 というのは、このフォーマットが MIME エンティティに署名するためのまったく遅れた互換的方法を提供しているからです。 純粋な MIME 環境で、極めて性能が高いユーザ エージェントなら、それは可能でしょう。 しかし世界はこれよりはるかに複雑です。
multipart/signed フォーマットでは、ゲートウェイで非 MIME 環境に 1 つの問題が発生します。 こうした環境においては、ゲートウェイは通常、S/MIME を感知せず、multipart/signed タイプを認識せず、MIME 規格の規定通りに、デフォルトの multipart/mixed として処理ます。 本当の問題は、署名されて multipart/signed 構造の冒頭部分に置かれたオリジナル メッセージの MIME 構造が、ゲートウェイによって変換された時に発生します。 たとえば、ゲートウェイがテキストやアタッチメントをローカル フォーマットに変換することなどです。 署名はオリジナル メッセージの MIME 構造全体に関わるものであるのに、オリジナル メッセージが分解、変形されたわけですから、署名はもう検証できません。 特定のボディ パート セットの MIME エンコーディングは、様々な方法で行うことができるため、その全体に署名が計算されたオリジナル MIME エンティティを復元する方法はありません。
既存のユーザ エージェントと 独自の S/MIME 機能を結合させようとした時にも同様の問題が発生します。標準的なユーザ エージェントは、独自のアプリケーションで使用可能なマルチパート サブエンティティを作る能力はありません。「ビューワ」アプリケーションで使用可能なリーフ MIME エンティティを作るのと同じようにはいかないのです。このようなユーザ エージェントの動作は、MIME 規格の求めるものではなく、したがって広く実装されてはいません。結論を言えば、ほとんどのユーザ エージェントにとって、multipart/signed エンティティ全体を独自のアプリケーションに委ねることは不可能です。
E.1 問題の解決策
この 2 つの問題の解決には、application/pkcs7-mime タイプを使うことができます。 このタイプはゲートウェイ通過の際、デフォルトのapplication/octet-stream MIME タイプとして扱われ、単一の不透明エンティティとして処理されます。 つまり、メッセージは未知のタイプのアタッチメントとして処理され、ローカル アタッチメント 表示に変換されるので、S/MIME 機能はこれを完全にもとのままで使用することができるのです。 ユーザ エージェントが同様にして、application/pkcs7-mime MIME エンティティを MIME 構造の単純なリーフ ノードとして処理し、ビューワ アプリケーションで使用できるようにする場合にも、同じような結果が得られます。
これらの問題のもう 1 つの解決方法は、ゲートウェイによる破損を受けない MIME エンティティの中に multipart/signed MIME エンティティをカプセル化することです。このメモの執筆時点では、「application/mime」MIME エンティティをこの目的に使うという提案があります。 しかし、このタイプのラッピングを使っている S/MIME 実装はありません。
E.2 非 MIME 環境下でのカプセル化
この文書は主にインターネットを対象に執筆されていますが、保護された S/MIME メッセージを非 MIME 環境下で作成したり受信したりするためにも有益です。 セキュリティの実装が終始求められるような場合には特にそうです。 ここでは、非 MIME 環境下での S/MIME の受信について検討を加えます。 また、multipart/signed エンティティの作成について説明します。
そうした環境でメッセージを送信する場合、multipart/signed エンティティが上で説明したようにして作成されます。 するとエンティティは不透明なビット ストリームとして処理され、アタッチメントとしてメッセージに付加されます。 これには「.aps」で終わるファイル名を付けなければなりません。 というのは、受信エージェントがそれを S/MIME メッセージと認識するための唯一の手がかりになるからです。
MIME 環境のもとに到達する時、こうしたメッセージは application/octet-stream MIME タイプを持っており、MIME パラメータがアタッチメントにファイル名を与えていると思われます。介在するゲートウェイがファイル タイプを運んできた場合には、「.aps」で終わっているはずで、これによって S/MIME メッセージであることが分ります。
このメモの執筆にあたっては、Jim Schaad、Jeff Thompson、Jeff Weinstein の各氏をはじめ多くの方々から多大な助力を得ました。
G. 著者のアドレス
Steve Dusse
RSA Data Security, Inc.
100 Marine Parkway, #500
Redwood City, CA 94065 USA
電話： (415) 595-8782
EMail： spock@rsa.com
Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060
電話： (408) 426-9827
EMail： phoffman@imc.org
Blake Ramsdell
Worldtalk
13122 NE 20th St., Suite C
Bellevue, WA 98005
電話： (425) 882-8861
EMail： blaker@deming.com
Laurence Lundblade
QUALCOMM Incorporated
Eudora Division
6455 Lusk Boulevard
San Diego, California 92121-2779
電話： (800) 238-3672
EMail： lgl@qualcomm.com
Lisa Repka
Netscape Communications Corporation
501 East Middlefield Road
Mountain View, CA 94043
電話： (415) 254-1900
EMail： repka@netscape.com
翻訳者
竹形 誠司
株式会社ヴェルテックE-mail： takegata@veltec.co.jp
H. 著作権表記全文
Copyright (C) The Internet Society (1998). All Rights Reserved.
この文書およびその翻訳は、複製し、他者に提供することができます。 また、この文書にコメントや解説を加えたり、実装の助けとなるような派生的著作を準備、複製、公表、配布することができます。 こうした行為は、複製や派生的著作に上記の著作権表示と本項が含まれていれば、全文であれ部分的にであれ、いかなる種類の制限もなく可能です。 しかし、この文書自体はいかなる方法であれ変更することはできず、著作権表示や Internet Society もしくは他のインターネット組織への照会を削除することは許されません。 ただし、インターネット規格の発展という目的にとって必要な場合は例外です。 このような場合には、インターネット規格プロセスで規定された著作権手続きを踏まなければなりません。 また、英語以外の言語に翻訳する場合も例外です。
上記の制限付き許諾は恒久的なものであり、Internet Society もしくはその継承者や譲受人によって撤回されることはありません。
この文書およびここに含まれる情報は「あるがままの形」を基本に提供されるものであり、Internet Society および Internet Engineering Task Force は、明示的であれ暗示的であれ、すべての保証を拒否します。 ここにある情報の使用が、いかなる権利も侵害せず、特定の目的のための商業性と適合性に対するいかなる暗示的保証も侵害しないという保証も含みますが、これに限定されるわけではありません。