PKCS #7 メッセージ形式では、コンテントおよびアルゴリズム サポートの多種多様なオプションが可能です。このセクションでは、S/MIME の全実装間の相互運用性の基本レベルを達成するため、サポートに関する要求事項と推奨事項を多数紹介しています。S/MIME メッセージの PKCS #7 形式は、ほとんどが [SMIME-MSG] で定義されています。
2.1 CertificateRevocationLists English
受信エージェントは、[KEYM] で定義された証明書取り消しリスト（CRL）形式をサポートしなければなりません（MUST）。送信エージェントが発信メッセージに CRL を含める場合は、 [KEYM] で定義された CRL 形式を使わなければなりません（MUST）。
すべてのエージェントは、使用可能な場合、[KEYM] に従って CRL の有効性を確認し、CRL に対する証明書をチェックしなければなりません（MUST）。
すべてのエージェントは、CRL の中の現在時刻に対する nextUpdate フィールドをチェックする必要があります（SHOULD）。現在時刻が nextUpdate 時刻より遅い場合、エージェントが取る行動はローカル決定です。たとえば、エージェントは人間のユーザに警告したり、可能な場合は新しい CRL を検索することができる、などです。受信エージェントは、受信した S/MIME メッセージの中の CRL を認識しなければなりません（MUST）。
クライアントは、S/MIME メッセージの中の署名と証明書パスの有効性を検証する際、メッセージの中に CRL として含まれる取り消し情報を使用しなければなりません（MUST）。クライアントは、後でメッセージを処理する際に利用するため、メッセージの中で受け取った CRL を記憶する必要があります（SHOULD）。
クライアントは、同じサブジェクト名と同じ公開鍵を含んでいながら、バリディティ間隔がオーバーラップしているような、複数の有効な認証局（CA）の証明書を処理しなければなりません（MUST）。
2.2 ExtendedCertificateOrCertificate English
受信エージェントは、X.509 v1 証明書と X.509 v3 証明書をサポートしなければなりません（MUST）。証明書形式のプロフィールの詳細は [KEYM] をご覧ください。エンド エンティティの証明書は、3.1 で説明しているように、インターネット メール アドレスを含んでいなければなりません（MUST）。
2.2.1 PKCS #7 証明書についての歴史的な注釈 English
PKCS #7 メッセージ形式では、公開鍵コンテント タイプに X.509 拡張証明書と PKCS #6 拡張証明書の 2つの証明書形式を用いることができます。PKCS #6 形式は、あまり普及していません。さらに、X.509 証明書の改訂版は、PKCS #6 とまったく同等な機能性と柔軟性を備えています。したがって、送信エージェントと受信エージェントは PKCS #6 拡張証明書を使ってはなりません（MUST NOT）。
2.3 ExtendedCertificateAndCertificates English
受信エージェントは、任意の数、任意のメッセージ送信者および互の関係、任意の数の証明書を処理できなくてはなりません（MUST）。多くの場合、署名付きメッセージに含まれる証明書は、ある特定のルートに対する送信者からの証明のチェインを表示することができます。しかし、署名付きメッセージの証明書が関連づけられておらず、便宜的に含まれているような状況もあり得ます。
送信エージェントは、ユーザの公開鍵に対するあらゆる証明書と関連する発行者証明書を含める必要があります（SHOULD）。これによって、目的の受信者が発信者の公開鍵を信用できる可能性が大きくなります。これは、他のどんな方法によっても送信者の公開鍵にアクセスできない可能性のある受信者にメッセージを送信する場合や、新しい受信者に署名付きのメッセージを送信する場合に特に重要です。共有ディレクトリや手動署名配布のような他の方法によって、互いの証明書へのアクセスが確立されているような通信者グループの内部で S/MIME オブジェクトを送信する場合は、発信メッセージに証明書を含めなくても構いません。S/MIME 受信エージェントは、データベースやディレクトリ検索スキームを利用して証明書のないメッセージを処理できる必要があります（SHOULD）。
送信エージェントは、受信者が権威あるものとして信頼することができると信じられる認証局（CA）への（それを含まない）証明書のチェインを少なくとも 1 つ含む必要があります（SHOULD）。受信エージェントは任意の数の証明書とチェインを処理できる必要があります（SHOULD）。
クライアントは 、CA の証明書、つまり自己署名された証明書を送ることができ、他のチェインの「ルート」と見なされることができます(MAY)。受信エージェントは、自己署名された証明書だからといって、有効な CA としてたやすく信用すべきでなく（SHOULD NOT）、他の何らかのメカニズムを使って、それが信頼すべき CA であるかどうかを決定する必要がある（SHOULD）ことに注意してください。
受信エージェントは、識別名フィールドに基づくチェインをサポートしなければなりません（MUST）。証明書チェインの他の構築方法もサポートされるかもしれませんが、現在は推奨されていません。