5. 鍵要求と証明要求の生成 English
S/MIME エージェントもしくはそれに関連する管理ユーティリティや機能は、ユーザの公開鍵と関連する名前情報を記載した証明要求を作成できなくてはなりません（MUST）。ほとんどの場合、ユーザの公開鍵と秘密鍵の組み合わせが同時に生成されます。しかし、鍵情報が外部プロセスによって生成されるケースもあります（たとえば、鍵の組み合わせが鍵トークン上で生成されるケースや、「鍵回復」サービスによって生成されるケースなど）。
同じ鍵の組み合わせを異なる識別名に結び付ける有効な（つまり、有効期限内で撤回されていない）証明書を複数作るべきではありません（SHOULD NOT）。そうでないと、セキュリティ フローが生じてしまい、攻撃者がある有効な証明書を、メッセージの受信者に気付かれずに別の証明書に代用するのを許すことになります。ユーザ名を変更（もしくは別の名前を作成）したいときは、ユーザ エージェントは新しい鍵の組み合わせを生成する必要があります（SHOULD）。新しい名前や別の名前に既存の鍵の組み合わせを再利用したい場合は、まず、既存の取り消された公開鍵に対する有効な証明書を取得する必要があります（SHOULD）。
一般的に、同一名を持つ別個の公開鍵に対する証明書を、同一もしくは別個の認証局に要求することが可能です。これはエンド エンティティと発行者証明書の両方に受け入れ可能で、発行者鍵の変更をスムーズに行うのに便利です。
CA が自分の名前を別の鍵に再利用する場合は、発行する証明書に AuthorityKeyIdentifier 拡張を含めなければならず（MUST）、また、CA 自身の証明書の中に SubjectKeyIdentifier 拡張を持っていなければなりません（MUST）。CA は、これらの拡張を一律に用いる必要があります（SHOULD）。
クライアントは、同じサブジェクト（認証対象）名を持つ異なる公開鍵を証明する複数の有効な CA 証明書を処理する必要があります（この場合は当該 CA 名）（SHOULD）。
与えられた証明書の検証に使うための適切な発行者証明書を選択する場合、クライアントは AuthorityKeyIdentifier 拡張と SubjectKeyIdentifier 拡張を処理する必要があります（SHOULD）。
5.2 証明要求に PKCS #10 を使う English
PKCS #10 は、あるデータに対する暗号操作の結果を表示するための柔軟性に富み、拡張可能なメッセージ形式です。名前情報の選択は、目的の証明サービスに関連するポリシーと手続きによってその大部分が決まります。
鍵情報と名前情報に加え、PKCS #10 形式は、証明を要求するエンティティが署名したオプショナル属性も含めることができます。これによって、証明要求内で要求の処理に便利な情報を運ぶことができますが、必ずしも識別名が証明されている必要はありません。
受信エージェントは、X.509 で定義された rsa と rsaEncryption OID による RSA 鍵の識別をサポートしなければなりません（MUST）。認証局は sha-1WithRSAEncryption と md5WithRSAEncryption をサポートしなければならず（MUST）、[SMIME-MSG] に説明されているように、証明要求の署名の検証のために MD2WithRSAEncryption をサポートする必要があります（SHOULD）｡
証明要求を作成、発信するためには、RSA 鍵は rsaEncryption OID による識別を受け、sha-1WithRSAEncryption 署名アルゴリズムによって署名される必要があります（SHOULD）。証明要求には、md2WithRSAEncryption 署名アルゴリズムを使って署名してはなりません（MUST NOT）。
証明要求は、証明書の一部としても（3.2 で説明したように）、また PKCS #10 属性リストの一部としても、有効なインターネット メール アドレスを含めなければなりません（MUST）。認証局は、「From」ヘッダのアドレスが上記のアドレスと一致しているかどうかチェックしなければなりません（MUST）。CA は CA オペレータがアドレスの一致しないメッセージの処理を構成できるようにする必要があります（SHOULD）。
認証局は、次に挙げる着信メッセージの各証明要求属性のうちゼロまたは 1つを解析できる必要があります（SHOULD）。特定の実装がサポートしない属性は、要求者に対して警告メッセージを出したり、無視されたりすることがあります。証明要求の作成と発信の際に下記の属性を含めることは、対応する名前と公開鍵を証明する証明サービスの関連ポリシーによって決定されると思われます。
postalAddress
challengePassword
unstructuredAddress
postalAddress は [X.520] に説明されています。
5.2.1 チャレンジ パスワード English
チャレンジ パスワード属性タイプは、エンティティが証明書の取り消しを要求するためのパスワードを指定します｡パスワードの解釈は、証明書の発行者が指定することになっており、特定の解釈が要求されるわけではありません。チャレンジ パスワード属性タイプは PKCS #10 証明要求に対して用いられます。
チャレンジ パスワード属性値は ASN.1 タイプの ChallengePassword を持っています。：
ChallengePassword ::= CHOICE {
PrintableString, T61String }
チャレンジ パスワード属性は単一の属性値を持たなければなりません。
UCS が ASN.1 タイプ（たとえば UNIVERSAL STRING）になる場合、ChallengePassword は CHOICE タイプになることが期待されます:
ChallengePassword ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
5.2.2 非構造化アドレス English
非構造化アドレス属性タイプは、証明のサブジェクト（認証対象）の 1 つもしくは複数のアドレスを非構造化された ASCII もしくは T.61 文字列として指定します。アドレスの解釈は、証明書の発行者が指定することになっており、特定の解釈が要求されるわけではありません。適切な解釈は、X.520 postalAddress 属性タイプの代替です。非構造化アドレス属性タイプは PKCS #10 証明要求に対して用いられます。
非構造化アドレス属性値は ASN.1 タイプの UnstructuredAddress を持っています。：
UnstructuredAddress ::= CHOICE {
PrintableString, T61String }
非構造化アドレス属性値は複数の属性値を持つことができます。
注: T.61 のニューライン文字（16 進コード 0d）が複数行にわたるアドレスの行分離記号として推奨されます。
UCS が ASN.1 タイプ（たとえば UNIVERSAL STRING）になる場合、UnstructuredAddress は CHOICE タイプになることが期待されます:
UnstructuredAddress ::= CHOICE {
PrintableString, T61String, UNIVERSAL STRING }
認証局は、証明に署名する際には sha-1WithRSAEncryption 署名属性を使う必要があります（SHOULD）。
5.4 実行された証明の応答に PKCS #7 を使う English
[PKCS-7] は、コンテントに署名がない（したがって、コンテントの値は「irrelevant」）ような SignedData コンテント タイプの非生成的なケースをサポートします。このような非生成的なケースは、証明書と CRL 情報の伝達に使われます。認証局は、証明要求の首尾よい実施から得られる証明書情報を返送する際にこの形式を使わなければなりません（MUST）。少なくとも、実行された証明の応答は、実際のサブジェクト証明（証明要求の中の情報に対応した）を含まなければなりません（MUST）。応答には、発行者を上位の認証局や対応する証明書取り消しリストに結び付けるような他の証明書が含まれる必要があります（SHOULD）。関連性のない証明書と取り消し情報も受け入れ可能です。
受信エージェントは、このような非生成的な PKCS #7 メッセージ タイプを解析し、4章 の要求事項と推奨事項にしたがって証明書と CRL を処理しなければなりません（MUST）。