4. 証明書の処理
English受信エージェントは、受信者に対するデジタル エンベロープされた証明書へのアクセスを得るため、何らかの証明書検索メカニズムを提供する必要があります。証明書検索メカニズムを実装するには多くの方法があります。X.500 ディレクトリ サービスは、証明書検索専用メカニズムの優れた例で、古典的な X.500 識別名と互換性があります。PKIX ワーキング グループは他のメカニズムを研究中です。IETF が検討しているもう 1 つの方法は、既存のドメイン ネーム システム（DNS）の一部として証明書検索サービスを提供するというものです。こうしたメカニズムが広く普及するまでは、その利用は検索可能な少数の通信相手の証明書に限定されるでしょう。少なくとも初期の S/MIME 展開については、ユーザ エージェントは署名付き返信メッセージを要求する目的の受信者へのメッセージを自動的に生成することができました。
受信および送信エージェントは、また、ユーザが後に検索できるような方法で通信相手への証明書を「記憶、保護」できるメカニズムを提供する必要があります（SHOULD）。多くの環境においては、証明書の検索・記憶メカニズムを何らかの種類の証明書データ ベースの中で互いにリンクさせることが望まれるでしょう。証明書データ ベースは特定ユーザにローカルであり、頻繁にやり取りする通信相手を記憶する「アドレス帳」と同じような働きをするでしょう。このように、証明書検索メカニズムは、ユーザが（おそらく着信メッセージから）記憶しておいた証明書に限定されることになります。包括的な証明書検索・記憶ソリューションは、2つかそれ以上のメカニズムを組み合わせ、ユーザにとって極めて柔軟性に富み、使いやすいものになることでしょう。たとえば、安全なインターネット メール エージェントは、ある証明書がユーザのローカル証明書記憶・検索データ ベースに見つからない場合は、集約型の証明書検索メカニズムをチェックすることができます。
受信および送信エージェントは、PKCS #7 証明書専用（certs-only）メッセージを使って、証明書をインポートしたりエクスポートしたりするためのメカニズムを提供 する必要があります（SHOULD）。これによって、完全な証明書チェインを単一の証明書とは対照的にインポートしたりエクスポートしたりすることができます。これについては [SMIME-MSG] で説明されています。
4.1 証明書取り消しリスト English
受信エージェントは、証明書取り消しリスト（CRL）の検索メカニズムにアクセスし、証明書チェインの確認の際に証明書取り消し情報にアクセスできるようにする必要があります（SHOULD）。受信もしくは送信エージェントはまた、ユーザが通信相手から受け取った証明書取り消し情報を、後で検索できるような方法で記憶できるメカニズムを提供する必要があります（SHOULD）。しかし、着信メッセージから蓄積された情報を得るよりは、CA から最新情報を手に入れるほうが常にベターです。
受信および送信エージェントは、ある証明書を証明書チェイン確認の一部として検証する際には、たとえ証明書が過去にすでに検証されていても、常に CRL 情報を検索、利用する必要があります（SHOULD）。しかし、多くの場合（オフライン検証のように）、最新の CRL 情報へのアクセスは困難か不可能であるかもしれません。したがって、CRL 情報の利用は、保護される情報の価値によって決まることでしょう。ある特定の文脈の中での CRL 情報の価値については、このメモの範囲を超えますが、特定の証明書階層に関連するポリシーによって決められることでしょう。
ユーザ エージェントが安全なメッセージを作成する場合、ユーザの便宜をはかって証明書、CRL および証明書チェインの確認を高度に自動化する必要があります（SHOULD）。通信相手の公開鍵を確認するときには、証明書、CRL およびチェインの確認を行わなければなりません（MUST）。これが必要になるのは、a) 通信相手からの署名を検証するとき、b) 受信者に想定する通信相手にデジタル エンベロープを作成するときです。
証明書と CRL はチェイン確認手続きの際には、a) 着信メッセージ、 b) 証明書および CRL 検索メカニズムの 2 通りの方法で利用できます。着信メッセージの中の証明書と CRL は、特に整然と配列される必要はなく、メッセージの送信者か受信者に何らかの形で関連づけられる必要もありません（もっとも、ほとんどの場合、送信者に関連づけられますが）。受け取った証明書と CRL は、チェイン確認での使用のためキャッシュし、また場合によっては後の使用のために記憶する必要があります（SHOULD）。こうした証明書と CRL の一時的なキャッシュは、受け取った署名付きメッセージのチェイン確認のための証明書および CRL 検索メカニズムの拡張に利用する必要があります（SHOULD）。
証明書と証明書取り消しリスト（CRL）には証明書の発行者が署名しています。受信エージェントは、[SMIME-MSG] に説明されているように、512 ビット以上 2048 ビット以下の鍵サイズを持ち、md5WithRSAEncryption および sha-1WithRSAEncryption 署名アルゴリズムでできた証明書と CRL の署名を検証できなくてはなりません（MUST）。受信エージェントは、512 ビット以上 2048 ビット以下の鍵サイズを持ち、md2WithRSAEncryption 署名アルゴリズムでできた証明書および CRL の署名を検証できる必要があります（SHOULD）。
4.4 X.509 Version 3 証明書拡張 English
X.509 v3 規格は、基本的な証明書情報を拡張できる拡張可能なフレームワークについて、また、そのような拡張を使って証明書の発行および確認プロセスをどのように管理できるのかについて説明しています。PKIX ワーキング グループは、特定の証明環境で価値を持つ拡張を特定し、作成するために努力を傾けています。どの v3 拡張を使うべきかについて幅広い合意が形成されるまでは、まだ多くの行うべきプロフィーリング作業があります。さらに、ビジネス用の X.509 v3 証明書の発行に向けて活発な努力が行われています。このメモでは、S/MIME 環境で最大の価値を持つような証明書の拡張の最低限の要求事項を特定しています。basicConstraints および keyUsage 拡張は [X.509] で定義されています。
送信および受信エージェントは、v3 基本制約証明書拡張、鍵用法証明書拡張、authorityKeyID、subjectKeyID および subjectAltNames がエンド ユーザ証明書に現れたとき、それらを正しく処理しなければなりません（MUST）。定義された v3 証明書拡張が中間証明書または CA 証明書に現れたとき、それを処理できる何らかのメカニズムが存在する必要があります（SHOULD）。
S/MIME 環境で発行された証明書は、ここに挙げた以外のクリティカルな拡張を含まないほうがいいでしょう（SHOULD NOT）。これらの拡張は、拡張の適切な処理が関連する証明書の正しい解読にとってクリティカルと思われない場合は、クリティカルでないものとしてマークされる必要があります（SHOULD）。他の拡張も含まれるかもしれませんが、これらの拡張はクリティカルなものとしてマークしないほうがいいでしょう（SHOULD NOT）。
4.4.1 基本制約証明書拡張 English
基本制約拡張サービスは、証明書のチェインにおける発行局またはエンド ユーザの証明書の役割と位置を規定するために使われます。
たとえば、CA および下位の CA に発行する証明書は、その証明書を発行局証明書として特定する基本制約拡張を含んでいます。エンド ユーザの購読者証明書は、証明書が発行局証明書であることに制約を加える拡張を含んでいます。
証明書は basicContstraints 拡張を含む必要があります（SHOULD）。
4.4.2 鍵用法証明書拡張 English
鍵用法拡張は、有効な証明書に記載された公開鍵の使用の技術的目的を制限するものです。発行局証明書は、署名付き証明書や証明書取り消しリストその他のデータの鍵を制約する、鍵用法拡張を含んでいる可能性があります。
たとえば、認証局は、対応する公開鍵がエンド ユーザ証明書および CRL への署名に使用できることを指定する keyUsage 拡張を含む下位の発行者証明書を作成することができます。