2. PKCS #7 オプション
EnglishPKCS #7 メッセージ形式では、コンテントとアルゴリズム サポートの多種多様なオプションが使えます。このセクションでは、S/MIME の全実装間の相互運用性の基本レベルを達成するため、サポートに関する要求事項と推奨事項を多数紹介しています。
2.1 ダイジェスト アルゴリズム識別子 （DigestAlgorithmIdentifier） English
受信エージェントは SHA-1 [SHA1] と MD5 [MD5] をサポートしなければなりません（MUST）。
送信エージェントは SHA-1 を使う必要があります（SHOULD）。
2.2 ダイジェスト暗号アルゴリズム識別子 （DigestEncryptionAlgorithmIdentifier) English
受信エージェントは [PKCS-1] で規定された rsaEncryption をサポートしなければなりません（MUST）。
受信エージェントは、512 ビット以上 1024 ビット以下のサイズの RSA 公開鍵を使った署名の検証をサポートしなければなりません（MUST）。
送信エージェントは rsaEncryption をサポートしなければなりません（MUST）。発信メッセージはユーザの秘密鍵によって署名されています。秘密鍵のサイズは鍵の生成の際に決められます。
2.3 鍵暗号アルゴリズム識別子 （KeyEncryptionAlgorithmIdentifier） English
受信エージェントは rsaEncryption をサポートしなければなりません（MUST）。暗号化された着信メッセージは、ユーザの秘密鍵で解読される対称鍵を含んでいます。秘密鍵のサイズは鍵の生成の際に決められます。
送信エージェントは rsaEncryption をサポートしなければなりません（MUST）。送信エージェントは、512 ビット以上 1024 ビット以下のサイズの RSA 公開鍵を使った対称鍵の暗号化をサポートしなければなりません（MUST）。
PKCS #7 は相異なる 6つのコンテント タイプを規定しています。「data（データ）」、「signedData（署名データ）」、「envelopedData（エンベロープ データ）」、「signedAndEnvelopedData（署名・エンベロープ データ）」、「digestedData（ダイジェスト データ）」、「encryptedData（暗号データ）」の 6つです。受信エージェントは「data」、「signedData」、「envelopedData」の各コンテント タイプをサポートしなければなりません（MUST）。送信エージェントがどのコンテント タイプを送信できるかできないかは、エージェントがサポートしているサービスによって決ります。
2.4.1 data コンテント タイプ English
送信エージェントは、当該コンテントを他のコンテント タイプ内で使う場合、メッセージ コンテントにセキュリティ サービスが適用されていることを明示するため、「data」コンテント タイプを使用しなければなりません（MUST）。
2.4.2 signedData コンテント タイプ English
送信エージェントは、メッセージにデジタル署名を付したり、署名情報がない場合には証明を伝達するため、signedData コンテント タイプを使わなければなりません（MUST）。
2.4.3 envelopedData コンテント タイプ English
このコンテント タイプはメッセージのプライバシー保護のために使われます。送信者は、このサービスを使うには、各メッセージの本来受信者の公開鍵にアクセスする必要があります。このコンテント タイプは認証を与えるものではありません。
SignerInfo（署名者情報）タイプでは、署名に付される非認証属性と認証属性を含めることができます。
受信エージェントは、このセクションで記述されている各署名属性のゼロまたは 1 インスタンスを処理できなければなりません（MUST）。
送信エージェントは、このセクションで記述されている各署名属性の 1 インスタンスを生成できる必要があり（SHOULD）、また、送信する各署名メッセージにこれらの属性を含める必要があります（SHOULD）。
これらの属性に付け加える属性や値は、おそらく今後に定義されるでしょう。受信エージェントは認知されていない属性や値を処理する必要があります（SHOULD）。
2.5.1 署名時刻属性 English
署名時刻（signing-time）属性は、メッセージが署名された時刻を伝えるのに使われます。信頼するに足りる時刻記録サービスが現れるまで、署名時刻はメッセージの発信者によって記録されると思われます。したがって、その信頼度は発信者しだいということになります。
送信エージェントは、西暦 2049年までは署名時刻を UTC 時刻でエンコードしなければなりません（MUST）。2050年以降は、署名時刻は一般化時刻でエンコードしなければなりません（MUST）。エージェントは次の要領で年フィールド（YY）を解釈しなけばなりません（MUST）。YY が 50以上であれば、19YY年と解釈します。YY が 50未満の場合は 20YY年と解釈します。
2.5.2 S/MIME 能力属性 English
S/MIME 能力属性は、署名アルゴリズム（「md5WithRSAEncryption」のような）、対称アルゴリズム（「DES-CBC」のような）、鍵暗号化アルゴリズム（「rsaEncryption」のような）を含んでいます。
また、署名データに優先する非アルゴリズム能力も含んでいます。SMIMECapability は柔軟性と拡張可能性を兼ね備えているため、将来、証明のような他の能力や優先度を識別する手段は、現在のクライアントも使えるような形で拡充することができます。
S/MIME 能力属性の書式は、クライアントが告知する SMIMECapability が何をサポートできるのかに関する部分的なリストを指定します。クライアントはサポートする能力のすべてを記載する必要はなく、おそらくは能力リストをあまり長くしないためにも、すべての能力を記載すべきではありません。SMIMECapability のエンコードにおいては、OIDはその優先度の順に記載されていますが、そのカテゴリー（署名アルゴリズム、対称アルゴリズム、鍵暗号アルゴリズムなど）に応じて論理的に分離される必要があります（SHOULD）。
SMIMECapability の構造は、簡潔なテーブル ルックアップとバイナリ比較で照合が行えるように設計されています。たとえば、SMIMECapability を DES EDE3 CBC に DER でエンコードする場合は、実装に関わりなく、等しくエンコードされなければなりません（MUST）。
対称アルゴリズムの場合は、OIDの関連パラメータは同一アルゴリズムの 2 つのインスタンスを区別するために必要な全パラメータを指定しなければなりません（MUST）。たとえば、キー長に加えて RC5 のラウンド数とブロック サイズを指定しなければなりません。
OID のリスト（登録された SMIMECapability のリスト）は、このメモとは別に一元的に保守されています。OID のリストはインターネット メール コンソーシアムが<http://www.imc.org/ietf-smime/oids.html>で保守しています。
アルゴリズムに対応する OID は、アルゴリズムがどの OID を使用しているかあいまいな場合を除き、実際のアルゴリズムと同じ OID を使用する必要があります（SHOULD）。たとえば、以前のメモでは、rsaEncryption は署名アルゴリズムと鍵暗号アルゴリズムの両方を参照することができるため、あいまいとされていました。OID があいまいな場合は、登録された S/MIME 能力リストの管理者がどのタイプのアルゴリズムが OID を使用するかを裁定する必要があります。また、新しい OID は他の OID の使用を満足するように smimeCapability OID に割り当てなければなりません（MUST）。
登録された S/MIME 能力リストは、OID の必要パラメータを指定しますが、最も重要なのは、様々な長さの対称暗号が使われる場合のキー長を指定することです。個々の OID を区別するパラメータがない場合は、パラメータは省略しなければならず（MUST）、NULL としてエンコードしてはいけません（MUST NOT）。
SMIMECapability の追加的な値は、今後定められることでしょう。受信エージェントは認知されていない値を持つ SMIMECapability のオブジェクトを処理しなければなりません（MUST）。
2.6 コンテント暗号アルゴリズム識別子 （ContentEncryptionAlgorithmIdentifier） English
受信エージェントは、RC2 [RC2] またはキー サイズ 40 ビットの互換アルゴリズム（以下 RC2/40 といいます）を使った暗号解読をサポートしなければなりません（MUST）。受信エージェントは、DES EDE3 CBC（以下、「tripleDES（トリプルDES）」 [3DES] [DES] といいます）を使った暗号解読をサポートする必要があります（SHOULD）。
送信エージェントは、RC2/40 と tripleDES を使った暗号解読をサポートする必要があります（SHOULD）。
2.6.1 どの暗号方式を使うかを決める English
送信エージェントが暗号化されたメッセージを作成する場合、どのタイプの暗号方式を使うか決める必要があります。決定にあたっては、受信者から受け取ったメッセージに含まれる能力リストから集めた情報のほか、私的な取り決めやユーザ選好、法的規制などの副次的な情報を利用します。
2.5 では、送信エージェントが優先度に応じて暗号化能力を選択的に告知できる方式を規定しました。着信した署名メッセージの暗号化能力属性を処理、記憶するには、次に挙げる方式を使う必要があります（SHOULD）。
- 受信エージェントが送信者の公開鍵の能力リストをまだ作成していない場合は、着信メッセージの署名を検証し、時刻記録をチェックした後、少なくとも署名時刻と対称能力を含んだ新しいリストを作成する必要があります（SHOULD）。
- そのようなリストがすでに存在する場合、受信エージェントは着信メッセージの署名時刻がリストに記載された署名時刻より後のものかどうか、また、署名が有効かどうかについて検証する必要があります（SHOULD）。この 2 点が検証された場合、受信エージェントは署名時刻とリストの能力を共に更新する必要があります（SHOULD）。はるか先を指す署名時刻（許容範囲内の時計の狂いを超えるもの）や、誰が署名したか検証できないメッセージの能力リストは受け入れてはなりません（MUST NOT）。
能力リストは、将来メッセージを作成する時のために記憶しておく必要があります（SHOULD）。
メッセージを送信する前に、送信エージェントはメッセージの中の特定データに弱い暗号を使うかどうかを決めなければなりません（MUST）。当該データが弱い暗号を受け入れられないと判断された場合、送信エージェントは RC2/40 のような弱いアルゴリズムを使用してはなりません（MUST NOT）。弱い暗号の使用、不使用の決定は、このセクションで触れている使用すべき暗号アルゴリズムに関する他のすべての決定に優先します。
セクション 2.6.2.1 から 2.6.2.4 では、送信エージェントがどのタイプの暗号方式をメッセージに適用するか決める際に従う必要がある（SHOULD）規則について説明しています。これらの規則は命令的性格のものであり、送信エージェントはこれに則って決定を行う必要があります（SHOULD）。
2.6.2.1 規則 1: 既知の能力
暗号化しようとしているメッセージの受信者から一連の能力を受け取っている場合、送信エージェントは、リストの中で暗号化方法を知っている最初の方法（これは受信者が最も望んでいる方法です）を選ぶ必要があります（SHOULD）。受信者がメッセージを解読できると期待する正当な理由がある場合、送信エージェントはリストの中の能力の 1 つを使う必要があります（SHOULD）。
2.6.2.2 規則 2: 未知の能力、既知の暗号化方法
もし：
| − | 送信エージェントが受信者の暗号能力を知らず、 |
| − | その受信者から少なくとも 1 つのメッセージを受け取り、 |
| − | その受信者から受け取った最後の暗号化されたメッセージに信頼できる署名が付されている場合、発信するメッセージは、その受信者から受け取った最後の有署名暗号メッセージで使われているのと同じ暗号アルゴリズムを使用する必要があります（SHOULD）。 |
2.6.2.3 規則 3: 未知の能力、解読不能のリスク
もし：
| − | 送信エージェントが受信者の暗号能力を知らず、 |
| − | 受信者がメッセージを解読できないかもしれないというリスクを冒しても良いなら、送信エージェントは tripleDES を使う必要があります（SHOULD）。 |
2.6.2.4 規則 4: 未知の能力、解読不能のリスクを回避
もし：
| − | 送信エージェントが受信者の暗号能力を知らず、 |
| − | 受信者がメッセージを解読できないかもしれないというリスクを冒すつもりがないなら、送信エージェントは RC2/40 を使わなければなりません（MUST）。 |
2.6.3 弱い暗号の選択 English
40ビット キーを用いる他のすべてのアルゴリズムと同様に、RC2/40 は多くの人々から弱い暗号と見なされています。人間が制御している送信エージェントは、人間の送信者がデータを送信する前に、RC2/40 やそれに類する弱い暗号アルゴリズムを使ったデータ送信のリスクを判断できるようにする必要があり、そして可能な場合は tripleDES のようなより強力な暗号方式を使えるようにする必要があります（SHOULD）。
2.6.4 複数の受信者 English
複数の受信者向けの暗号メッセージを作成し、しかもその受信者間の暗号能力が一致していない場合、送信エージェントは複数のメッセージを送信することを余儀なくされます。送信エージェントがまず強力なアルゴリズムで暗号化したメッセージを送り、次に同じメッセージを弱いアルゴリズムで暗号化して送信した場合、通信チャネルを監視している人は強力に暗号化したメッセージを解読できるということを忘れないでください。弱いほうの暗号メッセージを解読すればいいのですから。