3. S/MIME メッセージの作成
Englishこのセクションでは、S/MIME メッセージのフォーマットと作成方法について説明します。S/MIME メッセージは、MIME ボディーと PKCS オブジェクトの組み合わせでできています。いくつかの MIME タイプと PKCS オブジェクトが使われています。保護されるデータはつねに標準的な MIME エンティティです。MIME エンティティと、証明、アルゴリズム識別子のようなその他のデータは、PKCS オブジェクトを作り出す PKCS 処理装置に与えられます。PKCS オブジェクトは最終的に MIME に包み込まれます。
S/MIME は、エンベロープ データ用のフォーマット 1 種類と、署名データ用のフォーマット数種類、署名Gンベロープ データ用のフォーマット数種類を提供しています。数種類の環境、とくに署名メッセージに対応するには、数種類のフォーマットが要求されます。これらのフォーマットの選択基準についても説明します。
このセクションの読者は、MIME を [MIME-SPEC] および [MIME-SECURE] で説明されたように理解していることが期待されます。
3.1 署名またはエンベロープ MIME エンティティの作成 English
S/MIME は MIME のエンティティを保護するのに使われます。MIME エンティティはサブパート、メッセージのサブパート、すべてのサブパートを含むメッセージ全体である場合があります。メッセージ全体が MIME エンティティの場合は、MIME ヘッダと MIME ボディだけを含み、RFC-822 ヘッダを含みません。注意していただきたいのは、S/MIMEはインターネット メール以外のアプリケーションで使われている MIME エンティティの保護にも使うことができるということです。
このセクションで説明されている保護された MIME エンティティは、「内部の」MIME エンティティと考えることができます。つまり、より大きな MIME メッセージの中で「最も内部の」オブジェクトということです。「外部の」MIME エンティティの PKCS #7 オブジェクトへの処理は、3.2、 3.4 その他で説明しています。
MIME エンティティの作成手順は、[MIME-SPEC] で説明されています。ここでは同じ手順が署名時のいくつかの追加的な規定とともに用いられています。ここでは [MIME-SPEC] の手順説明が繰り返されていますが、読者は厳密な手続きを記載した文書を参照する必要があります。このセクションでは、追加的な要求事項についても説明しています。
署名、エンベロープ、もしくは署名・エンベロープを前提とした MIME エンティティの作成には、単一の手続きが用いられます。破損から保護するため、いくつかの追加的な手順が推奨されています。この破損は、メールの通信中に発生し、multipart/signed フォーマットを用いたクリア署名に重大な影響を及ぼしかねないものとして知られています。エンベロープ メッセージや署名・エンベロープ メッセージにこれらの追加的な手順を適用し、どんな環境に対してもメッセージを修正せずに伝送できるようにすることが推奨されます。
次の手順は、命令的というよりは記述的なものです。同じ結果が得られる限り、どの手続きを用いるかは実装者の自由です。
手順 1. MIME エンティティの作成はローカル コンベンションに準拠します。 手順 2. MIME エンティティのリーフ部は標準的な形式に変換します。 手順 3. MIME エンティティのリーフには適切な転送エンコーディングを適用します。 S/MIME メッセージを受信すると、メッセージのセキュリティ サービスは削除され、MIME エンティティだけが残ります。MIME 能力を備えたユーザ エージェントに正常に届くと、MIME エンティティはそこで復号され、ユーザまたは受信したアプリケーションに送られます。
3.1.1 正規化(Canonicalization) English
各 MIME エンティティは、署名が作成されている環境、そして署名が検証される環境において、一意的かつ明瞭に記述できる正規化された形式に変換されなければなりません（MUST）。MIME エンティティは、エンベロープと署名のために正規化されねばなりません（MUST）。
正規化の正確な詳細は、実際の MIME タイプとエンティティのサブタイプによって決るので、ここでは説明しません。その代わり、特定の MIME タイプの規格について検討します。たとえば、text/plain タイプの正規化は、audio/basic の正規化とは異なります。テキスト タイプは別として、ほとんどのタイプは計算プラットフォームや環境に左右されずに一意的に記述されますが、これは正規化された記述と考えることができます。一般的に、正規化は S/MIME 実装ではなく送信エージェントによって行われます。
最も一般的でかつ重要なのは、異なる環境で異なる仕方で記述されることの多いテキストの正規化です。主要な「テキスト」タイプの MIME エンティティは、行末と文字セットの両方を正規化しなければなりません。行末は <CR><LF> という文字の組み合わせにしなければならず、また、文字セットは登録された文字セット [CHARSETS] とする必要があります。正規化の詳細は [MIME-SPEC] で定められています。選択した文字セットの名前は文字セット パラメータに明記し、使用されている文字セットを受信エージェントがはっきりと分るようにする必要があります（SHOULD）。
文字の中には ISO-2022 のように 1 つの文字を幾通りかに記述するものがあることを覚えておいてください。こうした文字を使って署名する場合は、指定された正規化された表記を使用しなければなりません（MUST）。
3.1.2 転送エンコーディング English
保護された MIME エンティティであれば、multipart/signed フォーマットを使った署名を除き、通信にあたっての転送エンコーディングはまったく不要です。S/MIME 実装はバイナリ MIME オブジェクトを処理できなければなりません（MUST）。Content-Transfer-Encoding （コンテント−転送−エンコーディング）ヘッダがない場合、転送エンコーディングは 7BIT と見なされます。
しかし、S/MIME 実装は、保護すべき MIME エンティティに対し、3.1.3 において説明している転送エンコーディングを例外なく使用する必要があります（SHOULD）。たとえ通信にさらされることのないエンベロープ データであっても、7 ビット MIME エンティティだけを保護するのは、どんな環境にあっても MIME エンティティを修正することなく処理できるようにするためです。たとえば、信頼できるゲートウェイは、まずメッセージの署名ではなく、エンベロープを除去し、それから署名メッセージを受信者に送るため、受信者は署名を直接検証できるようになっています。
単一のメール ゲートウェイをもつ広域ネットワークのように、サイトへの通信内容が 8 ビット クリーンでない場合、元の MIME エンティティが 7 ビット データのみでない限り、署名の検証は不可能になります。
3.1.3 multipart/signed を用いた署名の転送エンコーディング English
標準的なインターネット SMTP や、その他の7 ビット テキストに限定される通信インフラストラクチャでつねに送信する場合は、multipart/signed エンティティに転送エンコーディングを施し、7 ビット テキストとして記述されるようにしなければなりません（MUST）。7 ビット データの MIME エンティティは、あらためて転送エンコーディングする必要はありません。8 ビット テキストやバイナリ データのようなエンティティは、quoted-printable もしくは base-64 などの方式を用いてエンコードすることができます。
7 ビットが必要とされる第一の理由は、インターネット メール伝送インフラストラクチャが 8 ビット データやバイナリ データの伝送を保証できないからです。伝送インフラストラクチャのセグメントの多くは現在、8 ビット データのみならずバイナリ データも処理していますが、伝送パスが 8 ビット クリアかどうか分らないことが時々起きます。8 ビット データやバイナリ データを送信できないメッセージ転送エージェントが 8 ビット データのメール メッセージを受けた場合、このエージェントには次の 3 つの選択肢があります。ただし、いずれもクリア署名メッセージは受け付けません。
<
− エージェントは転送エンコーディングを変えることができます。
この場合、署名は無効になります。− エージェントはとりあえずデータを送信することができますが、8 ビット目が壊れる公算は大です。
この場合も署名は無効になります。− エージェントはメッセージを送信者に送り返すことができます。
[MIME-SECURE] は、エージェントがマルチパート/署名メッセージの冒頭部分の転送エンコーディングを変更するのを禁じています。8 ビット データやバイナリ データを送信できないエージェントが、冒頭部分に 8 ビット データやバイナリ データを含む multipart/signed メッセージを受けた場合は、送達不能としてメッセージを送信者に送り返さなければなりません。
3.1.4 正規化された MIME エンティティの例 English
ここでは、完全な転送エンコーディングを施した multipart/mixed メッセージの例を紹介します。このメッセージはテキスト部分とアタッチメントから成ます。例に挙げたメッセージ テキストは、転送エンコーディングが不可欠な US-ASCII 以外の文字を含んでいます。ここでは省略しましたが、各行の終端は<CR><LF>です。MIME ヘッダ、テキスト、転送エンコード部分の行末は、すべて<CR><LF>としなければなりません。
この例は S/MIME メッセージでないことに注意してください。
Content-Type: multipart/mixed; boundary=bar --bar Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A1Hola Michael! How do you like the new S/MIME specification? I agree. It's generally a good idea to encode lines that begin with From=20because some mail transport agents will insert a greater- than (>) sign, thus invalidating the signature. Also, in some cases it might be desirable to encode any =20 trailing whitespace that occurs on lines in order to ensure =20 that the message signature is not invalidated when passing =20 a gateway that modifies such whitespace (like BITNET). =20 --bar Content-Type: image/jpeg Content-Transfer-Encoding: base64 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= --bar--
3.2 application/pkcs7-mime タイプ English
application/pkcs7-mime タイプは、envelopedData（エンベロープ データ）や signedData（署名データ）など、いくつかのタイプの PKCS #7 オブジェクトを運ぶのに使われます。これらのエンティティの詳しい構成は後のセクションで説明しています。このセクションでは、application/pkcs7-mime タイプの一般的な特徴について説明します。
この MIME タイプはつねに、単一の PKCS #7 オブジェクトを運びます。PKCS #7 オブジェクトはつねに、オブジェクトを記述する ASN.1 シンタクスの BER に準拠してエンコードされなければなりません。運ばれる PKCS #7 オブジェクトの contentInfo（コンテント情報）フィールドはつねに、3.1 で説明したような方法で作成した MIME エンティティを含んでいます。contentInfo フィールドを空欄にしてはいけません。
PKCS #7 オブジェクトはバイナリ データであるため、ほとんどの場合は base-64 転送エンコーディングが適しています。SMTP 伝送を使う場合は特にそうです。使用される転送エンコーディングはオブジェクトを送信する伝送によって決まるものであり、MIME タイプの特性ではありません。
ここで検討しているのは PKCS #7 オブジェクトもしくは「外部の」MIME エンティティの転送エンコーディングであることに注意してください。これは、PKCS #7 オブジェクトや 3.1 において説明した「内部の」オブジェクトによって保護された MIME エンティティの転送エンコーディングとはまったく別物で、何の関係もありません。
application/pkcs7-mime オブジェクトは数種類あるため、送信エージェントは、受信エージェントがオブジェクトの内容について知るのをできる限り助け、受信エージェントがオブジェクトの ASN.1 を復号せずにすむようにする必要があります（SHOULD）。すべての application/pkcs7-mime オブジェクトの MIME ヘッダは、以下のセクションで説明するように、オプショナルな「smime-type」パラメータを含む必要があります（SHOULD）。
3.2.1 名前およびファイル名パラメータ English
application/pkcs7-mime を使用する場合、送信エージェントは Content-Type フィールドに「name（名前）」パラメータを適宜送出し、旧式のシステムとの互換性を確保する必要があります（SHOULD）。送信エージェントはまた、Content-Disposition（コンテント−処理）フィールド [CONTDISP] に「filename（ファイル名）」パラメータを適宜送出する必要があります（SHOULD）。送信エージェントが上記パラメータを送出する場合、パラメータ値は、適切な拡張子を付したファイル名とする必要があります（SHOULD）。：
MIME タイプ ファイル拡張子 application/pkcs7-mime
(signedData, envelopedData).p7m application/pkcs7-mime
(degenerate signedData "certs-only" message).p7c application/pkcs7-signature .p7s application/pkcs10 .p10 さらに、ファイル名は 8 文字に制限し、3 文字の拡張子を付す必要があります（SHOULD）。8 文字ベースのファイル名は、どんな名前をつけてもかまいませんが、「smime」ベースのファイル名を使用するにあたっては、MIME エンティティが S/MIME と関連づけられていることを示す必要があります（SHOULD）。
ファイル名を含めることには 2つの目的があります。ディスクに収めた S/MIME オブジェクトをより使いやすくします。また、タイプ情報をゲートウェイを越えて伝えることができます。（たとえば）application/pkcs7-mime タイプの MIME エンティティが S/MIME について特別の知識を持たないゲートウェイに到達した場合、エンティティの MIME タイプはデフォルトで application/octet-stream タイプとなり、一般のアタッチメントとして処理されるため、タイプ情報は失われます。しかし、アタッチメントのファイル名はしばしば、ゲートウェイを越えて伝送されます。これによって受信システムがアタッチメントを伝達するのに適切なアプリケーションを決定できることがよくあります。上に挙げた例でいえば、独立型の S/MIME 処理アプリケーションです。注意していただきたいのは、このメカニズムは特定の環境において実装の便宜をはかるためのものだということです。正規の S/MIME 実装は MIME タイプを使用しなければならず（MUST）、ファイル拡張子に頼ってはなりません（MUST NOT）。
3.3 Enveloped-only メッセージの作成 English
このセクションでは、MIME エンティティを署名せずにエンベロープするためのフォーマットについて説明します。
手順 1. エンベロープされる MIME エンティティは 3.1 に準拠して作成します。 手順 2. MIME エンティティその他の必要データは、envelopedData タイプの PKCS #7 オブジェクトに処理されます。 手順 3. PKCS #7 オブジェクトは application/pkcs7-mime MIME エンティティに挿入されます。
enveloped-only メッセージの smime-type パラメータは「enveloped-data」です。このタイプのメッセージのファイル拡張子は「.p7m」です。
メッセージの例は次のようになります：
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
3.4 Signed-only メッセージの作成 English
S/MIME 用の署名メッセージには 2 つのフォーマットがあります。application/pkcs7-mime および SignedDataと、multipart/signed の 2 つです。一般に送信側は multipart/signed 形式を好みますが、受信エージェントは両方を処理できる必要があります（SHOULD）。
3.4.1 Signed-only メッセージのフォーマットを選ぶ English
特定の signed-only フォーマットを選択する際には厳密な規則はありません。というのは、このフォーマットは受信者の能力によって、また、署名を検証できる S/MIME 機能を持った受信者とメッセージを見ることができる S/MIME ソフトウェアを持たない受信者のどちらが重要かによって決まるからです。
multipart/signed フォーマットを使って署名されたメッセージは、S/MIME ソフトウェアを持っているか否かにかかわりなく、いつでも受信装置で見ることができます。このメッセージはまた、MIME ネイティブ ユーザ エージェントを使っているか、ゲートウェイにメッセージを翻訳させているかにかかわりなく見ることができます。この文脈では、「見る」は、メッセージが持っているかもしれない他のすべての MIME 構造を含め、メッセージをあたかも署名メッセージではないかのように処理する能力を意味します。
signedData フォーマットを使って署名されたメッセージは、受信者が S/MIME 機能を持っていない限り見ることはできません。しかし、S/MIME 機能を持っていれば、メッセージは、送信中に変質していない限り、いつでも検証できます。
3.4.2 application/pkcs7-mime と SignedData を使った署名 English
この署名フォーマットは application/pkcs7-mime MIME タイプを使用します。このフォーマットを作成するための手順は次の通りです：
手順 1. MIME エンティティは 3.1 に準拠して作成します。 手順 2. MIME エンティティとその他の必要データは、signedData タイプの PKCS #7 オブジェクトに処理されます。 手順 3. PKCS #7 オブジェクトは application/pkcs7-mime MIME エンティティに挿入されます。 application/pkcs7-mime と SignedData を使ったメッセージの smime-type パラメータは「signed-data」です。
このタイプのメッセージのファイル拡張子は「.p7m」です。メッセージの例は次のようになります：
Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75
3.4.3 multipart/signed フォーマットを使った署名 English
このフォーマットはクリア署名フォーマットです。受信者は S/MIME または PKCS 処理機能を使わずにメッセージを見ることができます。使うのは、[MIME-SECURE] に記述された multipart/signed MIME タイプです。multipart/signed MIME タイプには 2 つの部分があります。第 1 の部分は署名をすべき MIME エンティティを含んでおり、第 2 の部分は PKCS #7 分離署名を含んでいます。
3.4.3.1 application/pkcs7-signature MIME タイプ
この MIME タイプはつねに signedData タイプの PKCS #7 オブジェクト 1 個を含んでいます。PKCS #7 オブジェクトの contentInfo フィールドは空欄でなければなりません。signerInfos フィールドは MIME エンティティ用の署名を含んでいます。登録されたタイプの詳細は付録 D にあります。
application/pkcs7-signature を使った signed-only メッセージのファイル拡張子は「.p7s」です。
3.4.3.2 multipart/signed メッセージの作成
| 手順 1. | 署名される MIME エンティティは、3.1 に準拠して作成し、クリア署名に特に配慮します。 |
|---|---|
| 手順 2. | MIME エンティティは、signedData タイプのオブジェクトを取得するため PKCS #7 処理に付され、contentInfo フィールドは空欄となります。 |
| 手順 3. | MIME エンティティは multipart/signed メッセージの第 1 の部分に挿入され、3.1 において説明した以外の処理は不要です。 |
| 手順 4. | 分離署名は転送エンコーディングされ、application/pkcs7-signature タイプの MIME エンティティに挿入されます。 |
| 手順 5. | application/pkcs7-signature のMIME エンティティは、multipart/signed エンティティの第 2 の部分に挿入されます。 |
multipart/signed コンテント タイプには 2つの必要パラメータがあります。
プロトコル パラメータと micalg パラメータです。プロトコル パラメータは「"application/pkcs7-signature"」でなければなりません（MUST）。注意していただきたいのは、プロトコル パラメータはクォーテーション マークで括る必要があることです。というのは、MIME ではパラメータ値の中の"/" はクォーテーション マークで括らなければならない（MUST）からです。
micalg パラメータ
micalg パラメータは、署名が検証されれば 1 パス処理を許可します。micalg パラメータ値は、メッセージ完全性チェック（Message Integrity Check）の計算で使われるメッセージ ダイジェスト アルゴリズムによって決まります。micalg パラメータ値は、次のどれかに該当する必要があります（SHOULD）。
使用アルゴリズム
値
MD5 md5 SHA-1 sha1 その他 unknown （歴史的な注釈：以前の S/MIME 実装の中には、micalg パラメータに "rsa-md5" と "rsa-sha1" を送出したり、期待するものがあります。）
受信エージェントは、認識していない micalg パラメータ値からすみやかに回復できる必要があります（SHOULD）。
3.4.3.3 multipart/signed メッセージの例
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42--
署名とエンベロープを行う際には、 signed-only フォーマットと encrypted-only フォーマットをネストして使うことができます。これが許されるのは、上記フォーマットがともに MIME エンティティであるからであり、また、ともに MIME エンティティを保護するからです。
S/MIME 実装は、ネストされた S/MIME を受信側コンピュータの妥当な資源制約の範囲内で随意に受信、処理できなければなりません（MUST）。
メッセージへの署名とエンベロープは、どちらを先にしてもかまいません。選択は実装者とユーザの意思に委ねられています。署名を先にする場合、署名者はエンベロープによって安全に隠されます。エンベロープを先にする場合、署名者は表に出ますが、エンベロープを除去することなく署名を検証することができます。これは、自動署名検証が望まれる環境下では便利かもしれません。この場合、署名の検証に秘密鍵マテリアルは不要なのですから。
3.6 Certificates-only メッセージの作成 English
certificates-only メッセージもしくは MIME エンティティは、登録要求に応答する際などに証明を伝送するのに使われます。
このフォーマットは CRL の伝送にも使うことができます。
手順 1. 証明は、signedData タイプの PKCS #7 オブジェクトを作成する PKCS #7 生成プロセスに対して使用可能になっています。
contentInfo フィールドと signerInfos フィールドは空欄にしなければなりません。手順 2. PKCS #7 signedData オブジェクトは、application/pkcs7-mime MIME エンティティに囲み込まれます。 certs-only メッセージの smime-type パラメータは「certs-only」です。
このタイプのメッセージのファイル拡張子は「.p7c」です。
暗号情報の生成をユーザに許可する標準的なアプリケーションは、認証局にその情報を提出し、証明に変換してもらわなければなりません。PKCS #10 には証明要求のためのシンタクスが記述されています。PKCS #10 証明要求の転送には、application/pkcs10 ボディ タイプが使われなければなりません（MUST）。
証明要求と証明獲得プロセスを詳述することは、このメモの範囲を超えますので、application/pkcs10 で使われるデータのフォーマットを定義するだけにとどめます。
3.7.1 application/pkcs10 ボディのフォーマット English
PKCS #10 は、証明要求を提出する際に使われる ASN.1 タイプの CertificationRequest を定義しています。したがって、application/pkcs10 MIME コンテント タイプが使われている場合は、ボディは基本エンコーディング規則（BER）を使ってエンコードした CertificationRequest でなければなりません（MUST）。
より厳格な DER の代りに BER が指定された場合でも、標準的なアプリケーションは DER を使うでしょう。というのは、CertificationRequest の CertificationRequestInfo は署名のため DER でエンコードされる必要があるからです。堅牢なアプリケーションは DER を出力する一方、BER もしくは DER の入力を許可する必要があります（SHOULD）。
BER もしくは DER で作られたデータは 8 ビットですが、多くの伝送は 7 ビットに制限されています。したがって、適切な 7 ビット Content-Transfer-Encoding（コンテント−転送−エンコーディング）を適用する必要があります（SHOULD）。すべての 7 ビット転送エンコーディングが有効ではありますが、application/pkcs10 には base64 Content-Transfer-Encoding を使う必要があります（SHOULD）。
3.7.2 application/pkcs10 ボディ パートの送受信 English
certificate-signing（証明−署名）要求の送信に際しては、PKCS #10 certificate-signing 要求を伝送するため、application/pkcs10 メッセージ フォーマットを使わなければなりません（MUST）。注意していただきたいのは、署名されたコンテントを含まない証明や CRL メッセージの送信に際しては、非生成的な PKCS #7 signedData "certs-only" メッセージを伝送するため、application/pkcs7-mime メッセージ フォーマットを使わなければならない（MUST）ということです。
application/pkcs10 ボディを送信するため、アプリケーションはユーザのために暗号情報を生成します。暗号情報について詳述することは、このメモの範囲を超えます。
手順 1. 暗号情報は PKCS #10 CertificationRequest 内に記載されます。 手順 2. CertificationRequest は BER もしくは DER に準拠してエンコードされます（DER が標準）。 手順 3. 標準的な手順として、DER でエンコードされた CertificationRequest は SMTP 転送に適した 7 ビット データであるため、base64 でもエンコードされます。
結果は次のようになります：
Content-Type: application/pkcs10; name=smime.p10 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p10 rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V標準的なアプリケーションで必要なのは証明要求の送信だけです。要求を受信、処理する必要があるのは証明当局です。メッセージから CertificationRequest を回復するための手順は簡単ですが、ここでは割愛します。証明要求を処理する手順は、この文書の範囲を超えます。
S/MIMEは非 MIME 環境下での相互運用性を考慮しているため、タイプ情報を伝送するためにいくつかの異なるメカニズムが使われており、その結果、S/MIME メッセージの識別がいくぶん難しくなっています。下記のテーブルでは、メッセージが S/MIME メッセージかどうかを決定するための基準を列挙しています。そのうち 1 つでも該当するものがあれば、メッセージは S/MIME メッセージと考えられます。
下記のテーブルのファイル拡張子は、content-type ヘッダの「name」パラメータか、または content-disposition ヘッダの「filename」パラメータから来ています。ファイル拡張子を与えるパラメータは、パラメータ セクションの一部としては挙げていません。
MIME タイプ: application/pkcs7-mime パラメータ: any ファイル拡張子: any MIME タイプ: application/pkcs10 パラメータ: any ファイル拡張子: any MIME タイプ: multipart/signed パラメータ: protocol="application/pkcs7-signature" ファイル拡張子: any MIME タイプ: application/octet-stream パラメータ: any ファイル拡張子: p7m, p7s, aps, p7c, p10