[ICT/OLD] S/MIME に関する最新インターネットドラフトの概要意訳 2001/10/27
S/MIME に関する最新インターネットドラフトの概要意訳集です。Written by Yukio Saitoh
Last Modified 10/27/2001
注意：IETF ドラフトですので、実際に実装されたプロダクト例の紹介は一切行いませんが、個人的に
実際のプロダクト評価を幾つか行っており、可能な限りソリューション実例を紹介できればと考えています。
Last Modified 10/27/2001
実際のプロダクト評価を幾つか行っており、可能な限りソリューション実例を紹介できればと考えています。
“S/MIME を使用したドメインセキュリティ”
オリジナル提案者 Tim Dean, William Ottaway 09/07/2001. (51351 bytes) ← ドラフト公開期限が切れ RFC.3183 となりました。
このドキュメントは S/MIME プロトコルがいかにしてセキュアサービスを
番号付けられたコミュニケーションシステムのコンポーネントを生成し
処理するように、メッセージ転送のエージェント、監視やゲートウェイによる
配送について記述します。
これらのサービスは集約して “ドメインセキュリティサービスである” と述べられています。
本ドキュメントで記述されたメカニズムは、
・２つのドメインがX.400 シリーズと SMTP / MIME のような互換性が無いメッセージ交換技術を使う時。
・異なったセキュリティドメインが確実に通信を行いたいと望む時
・１つのドメインが信用されてないドメインで存在し、そのメンバーの一人と通信したいと望む時。
これら生ずる多くの互換性問題と技術的な限界を解決するよう設計されています。
このドキュメントは同様に、外部からアクセス可能ではないが S/MIME プロトコルを
使用し確実に相互運用することを望む内部の PKIs を持つ組織、企業に適用できます。
“S/MIME 用パスワードベースの暗号化”
オリジナル 提案者 Peter Gutmann 08/08/2001 (26727 bytes) ← ドラフト公開期限が切れ RFC にはなっていないようです。（10/27/2001現在）
本ドキュメントは CMS用のパスワードベースの暗号化メカニズムを記述します。
これは新しい RecipientInfo タイプとして実装されます。そして、現在 RFC.2630 で定義
される RecipientInfo タイプへのエクステンションです。メッセージフォーマットは ANS.1 で
記述されます。
“CMS での ECC アルゴリズムの使用”
オリジナル 提案者 D Brown, Paul Lambert, Simon Black-Wilson 05/15/2001 (33497 bytes)
本ドキュメントは CMS (暗号メッセージ構文）で省略された ECC （カーブ暗号） の
公開鍵アルゴリズムをどのように使用すべきかを記述します。ECC アルゴリズムは
暗号化もしくは内容認証するためのディジタル署名の作成と鍵交換をサポートします。
アルゴリズム処理の定義は ANSI X9F1 ワークグループによって開発された ANSI X9.62
仕様と IEEE 1363 仕様と SEC1 仕様に基づいています。
このドキュメントの最後に知的所有権についての注意があります。
“S/MIME 用に圧縮されたデータのタイプ”
オリジナル提案者 Peter Gutmann 09/04/2001 (9659bytes)
暗号メッセージ構文のデータフォーマットはデータを圧縮処理する前にデータは含まれません。
送信によってアタッカーへ対して手を貸すことができるのデータ冗長性の除去を含め、
多くの利点を提供する前に署名または暗号化ステップの後に処理されるデータ量を減らす
ことにより、処理を速め、そして全体的なメッセージサイズを減らします。
“S/MIME セキュリティラベルと共に企業分類ポリシの実装”
オリジナル提案者 Weston Nicolls 05/08/2001 (23255 bytes)
本ドキュメントはデータ分類用に企業セキュリティポリシがどのように S/MIME セキュリティ
ラベルにマップされることができるか論じます。実際のポリシがもたらされる３つの事例を
提供します。
“S/MIME 対称鍵管理と分配”
オリジナル提案者 Sean Turner 08/20/2001 (191398 bytes)
本ドキュメントは対称鍵暗号アルゴリズムで使用（セットアップ、配布、再配布）され
管理するべきメカニズムを記述します。対称暗号のアルゴリズムを使い暗号化された
内容の分配をサポートするためにグループの中にユーザを組織化するためのメカニズムが
同様に定義されます。
メカニズムは CMS (暗号メッセージ構文）プロトコル[2] を使用し、そして証明書マネージ
メントが対称鍵を管理するために CMS (CMC) に関してプロトコル[3] を伝えます。
グループ中の任意メンバーでも対称鍵で他の CMS によって暗号化されたオブジェクトを
解読するために、そしてこの分散共有された鍵を使うことができます。
このメカニズムは S/MIME メールリストのエージェント (MLAs) をサポートするために
開発されました。
“長期間の電子署名用の署名フォーマット”
オリジナル提案者 D.Pinkas, J Ross, N Pope 04/09/2001 (169633 bytes)
情報的な RFC は長期間にわたって正当なままである電子署名のフォーマットを定義
します。たとえ署名者あるいは検証団体が確かめた後であっても、これは合意性に
ついての証拠を含む署名です。（すなわち、否認です。[ISONR} を参照してください）
このフォーマットは RFC.2630 [CMS] と RFC.2634 [ESS] 、適切な署名追加と無署名の
特性が定義されたとき、これはどこかの拡張であると考えることができます。情報的な
RFC が専門的に同等であるための著作権として、 ETSI ES 201 733 V.1.1.3 があります。
この ETSI は個別の配送コピーが、 http://www.etsi.org からダウンロードできます。
“CMSに含まれる暗号鍵の再利用”
オリジナル提案者 Stephan Farrell, Sean Turner 05/29/2001 (22155 bytes) ←ドラフト公開期限が切れ RFC.3185 となりました。
このノートでは、含まれている暗号化の鍵が、これ以外に含まれたデータパケットの
ために再利用できるように、CMS に含まれたデータ構造鍵に鍵認証標識を含める
方法を記述します。
“X.400 で S/MIME オブジェクトの配送”
オリジナル提案者 Paul Hoffman, Chisopher Bonatti 07/23/2001 (18314 bytes) ← ドラフト公開期限が切れ RFC にはなっていないようです。（10/27/2001現在）
本ドキュメントは CMS によって保護されたオブジェクトを配送するプロトコル追うションが
X.400 メッセージ転送システム上に S/MIME V.3 と結合されたことを記述しています。
“S/MIME を X.400 コンテントと共にセキュアにする”
オリジナル提案者 Paul Hoffman, Chitopher Bonatti, Anders Eggen 08/27/2001 (22818 bytes)
本ドキュメントは X.400 コンテントに暗号署名と暗号化サービスを加えるためのプロトコルを記述します。
“AES 暗号化アルゴリズムと CMS での RSA – OAEP 鍵配送の使用”
オリジナル提案者 Russ Houseley, Him Schaad 07/18/2001 (31290 bytes)
本ドキュメントは追加アルゴリズムとして S/MIME 暗号メッセージ構文 [CMS] に進化した
暗号化標準 (AES) アルゴリズム [AES] と 鍵交換管理の RSAES – OAEP 鍵配送方法を
どのように取り入れるべきか明示します。
“CMS に対するミリオンメッセージ攻撃の防止”
オリジナル提案者 E. Rescorla 09/24/2001 (14934 bytes)
データが RSA を使って暗号化されるとき、モジュール長に伸長されなければなりません。
— 典型的に 512 から 2048 ビットです。
これを行うための最もポピュラーなテクニックは [PKCS -1 V1.5] で記述されます。
しかしながら、1998年に Bleichenbacher は SSL [MMA] に対する適応性がある
選ばれた暗号文攻撃について記述しました。
“暗号のメッセージ構文 (CMS) アルゴリズム”
オリジナル提案者 Russ Housley 10/01/2001 (51291 bytes)
本ドキュメントは暗号メッセージ構文 (CMS) で使用するために幾つかの暗号
アルゴリズムを記述します、CMS はディジタル方式で任意のメッセージに署名して
ダイジェストし、認証あるいは暗号化するために使われます。
“暗号メッセージ構文”
オリジナル提案者 Russ Housley 10/01/2001 (12538 bytes)
本ドキュメントは暗号メッセージ構文 (CMS) を記述します。この構文はディジタル署名し
ダイジェストし、認証あるいは任意のメッセ０時を暗号化するために使われます。
“トリプル DES と RC2 鍵のラッピング”
オリジナル提案者 Russ Housley 09/18/2001 (21131 bytes)
片方の RC2 鍵で１つの RC2 鍵をラップすることに対して、このドキュメントはもう１つの
トリプル DES の鍵とアルゴリズムで１つのトリプル DES 鍵をラップすることに対しての
アルゴリズムを指定します。これらの鍵ラップアルゴリズムは、これまでの RFC.2630 に
よって支援された人たちを越えてコンテキストが有用であることが判明したので、それらは
再発行されます。
“暗号メッセージ構文 (CMS) のための所定された受取人”
オリジナル提案者 Russ Housley 09/26/2001 (13436 bytes)
このドキュメントとは暗号メッセージ構文 (CMS) で使用するための意図的な受取人特性を
記述します。意図的な受取人特性は署名された特性として、あるいは認証された特性と
して使われることができます。このドラフトは ‘IETF – SMIME’ メーリングリストで論じられて
います。リストを結びつけるために、メッセージの本文で１つの単語 ‘subscribe’ を送って
ください。同様に、メーリングリストのために Web サイトがあります。
“送信者認証と CMS と S/MIME での内密の転送攻撃”
オリジナル提案者 Donald Davis 10/01/2001 (36012 bytes)
デフォルトで、CMS 署名化と暗号化ドキュメントもしくはメッセージ認証はドキュメントを
暗号化した人ではなく、ドキュメントの創作者（オリジナルの作者）だけを認証します。
この微妙な制限は、CMS と S/MIME の 署名化と暗号化データは ‘内密の転送’ によって
晒します。セキュアメッセージ仕様は、秘密の転送をユーザーの不注意で解決できない
問題として取り扱い、そして長い間この攻撃の危険を受け入れました。
このドキュメントは攻撃のために容易な暗号の救済策を CMS と S/MIME 仕様編入に
適した内容で、[U2001] の要約です。
Referring Sites:
以上